软件架构案例分析.doc

  1. 1、本文档共25页,可阅读全部内容。
  2. 2、原创力文档(book118)网站文档一经付费(服务费),不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。
  3. 3、本站所有内容均由合作方或网友上传,本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺!文档内容仅供研究参考,付费前请自行鉴别。如您付费,意味着您自己接受本站规则且自行承担风险,本站不退款、不进行额外附加服务;查看《如何避免下载的几个坑》。如果您已付费下载过本站文档,您可以点击 这里二次下载
  4. 4、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“版权申诉”(推荐),也可以打举报电话:400-050-0827(电话支持时间:9:00-18:30)。
查看更多
精选文档 票务系统架构事例剖析 ?10.1ATAM方法表述 . 精选文档 ?10.2商业动机的表述 ?10.3构架的表述 ?10.4质量属性功效树 ?10.5质量场景的构架剖析 ?10.6对系统构架的再剖析 ?10.7评审结论 10.1ATAM方法表述 概括 ATAM(ArchitectureTradeoffAnalysisMethod): SEI提出的一种软件构架评估方法。ATAM评估方法的 主 要目的: . 精选文档 提炼出软件质量属性需求的精准描绘; 提炼出构架设计决议的精准描绘; 评估这些构架设计决议,并判断其能否令人满意的实现了这些质量需求。 ATAM评估方法: 并不是把每个能够量化的质量属性都进行详细的剖析,而是使众多的风险担当者(包含经理、开发人员、测试人员、用户、客户等等)都参加进来,由此而达到上述目标的。 ATAM是一种发掘潜伏风险,降低或许和缓现有风险的软件构架评估方法。所以,以下三点是评估中要特别着重的:风险、敏感点和衡量点。 构架涉众·一般用户 . 精选文档 ·用户管理员 ·票务管理员 ·开发人员 ·测试人员 评估步骤 ATAM主要分以下几个步骤: ATAM描绘; 商业动机表述; 软件构架表述;4)确立构架方式; 生收功效树; 剖析构架方式; 确立场景及其优先级; 进一步剖析构架方式; . 精选文档 得出结论。 10.2商业动机的描绘 项目经理从开发组织和客户角度,来表述票务系统的商业目标,综合以下: 从开发组织角度:开发一个模块性强、及时高效、界面优秀、与外面其余系统兼容优秀的系统,这使得开发组织能够把整个产品或某个模块卖给其余客户,同时因为优秀的界面和业务办理效率而受市场欢迎。 从客户角度:系统简单操作,可保护性好、系统稳固、能够及时正确的办理用户的在线订票或查问业务。依据上述目标,质量属性能够区分为两类:高优先级质量属性: 性能 安全性 . 精选文档 易用性 可用性 重要但优先级较低的属性: 模块性 可保护性 可改正性 可测试性 . 精选文档 10.3架构表述 与构架商业周期的关系 . 精选文档 系统的整体构造 . 精选文档 质量属性及采纳的战术 . 精选文档 . 精选文档 . 精选文档 10.4质量属性功效树 . 精选文档 . 精选文档 . 精选文档 . 精选文档 10.5质量场景的构架剖析 在质量属性功效树中,我们对场景的优先级进行了区分,而同时因为剖析时间可贵,所以我们应当把可贵的剖析 时间最初用于最重要且最难实现的场景上,即标明为(H,H)的场景。在质量属性功效树的表格中,仅在性能和可用性这 2个质量属性下发现标明有(H,H)的场景,下边依据系统的系统构造和实现质量属性所采纳的战术分别给出这些重要场景的构架方法剖析表格。 性能 . 精选文档 . 精选文档 可用性 . 精选文档 10.6对系统构架的再剖析 风险决议和敏感点 . 精选文档 (2)问题剖析 在前面对系统构造的描绘中,系统采纳鉴于B/S的分层构造,系统部署在一台应用服务器上,这类构造有它独到的优 点。但经过构架方法的剖析,特别是对系统的重点质量属性和优先级最高的质量属性场景的剖析,发现系统在上述场景下会出现以下的问题: 性能方面:在特别多的用户并发操作的状况下,单服务器系统将不可以对用户的恳求做出及时的响应,严重状况下服务器还会崩溃。 可用性方面:在仅有的一台应用服务器出现故障或许崩溃的状况下,用户将不可以接见系统,故障恢复需要花销较长时间。 . 精选文档 改良系统的构架 考虑到使用票务系统的用户数量特别宏大,这样造成用户对系统的接见恳求数量和对系统进行业务操作的恳求数量也非 常宏大,改良后的系统采纳多层散布式构造,使用Web服务器集群和应用服务器集群来实现,这类集群体制支持动向负载平 衡(LoadBalance)和容错体制,能够将用户的恳求以及对用户恳求的办理散发到负载低的服务器中,特别合适拥有并发用户数多,服务地址分别等这些特色,有较高的稳固性,能有效避 . 精选文档 免接见流量过多致使服务器瘫痪以及整个系统因为某台服务器崩溃而完全瘫痪。为了使系统达到集群散布式的目的,在第一 套方案的基础上,我们采纳Spring介入EJB容器的方式,使用EJB的无状态会话Bean来封装业务逻辑,即调用POJO中的业务逻辑操作(POJO中包含了业务逻辑办理,在本来的SSH框架中它是指业务层的JavaBean,经过长久层与数据库交 互,这些POJO经过IOC容器来管理)。这相当于在 Struts和业务逻辑层之间增添了EJB,重用原SSH框架的业务逻辑,即系统框架变 Struts+EJB+Hibernate+Spring ,这类组合能够将视图和业务逻辑以及对数据库的操作很好的分别。 (4)新的框架以下: . 精选文档 10.7评审结论 整体而言,经

文档评论(0)

150****0527 + 关注
实名认证
内容提供者

该用户很懒,什么也没介绍

1亿VIP精品文档

相关文档