软件架构案例分析.docx

上传人:b****3 文档编号:6559637 上传时间:2023-05-10 格式:DOCX 页数:10 大小:830.12KB
下载 相关 举报
软件架构案例分析.docx_第1页
第1页 / 共10页
软件架构案例分析.docx_第2页
第2页 / 共10页
软件架构案例分析.docx_第3页
第3页 / 共10页
软件架构案例分析.docx_第4页
第4页 / 共10页
软件架构案例分析.docx_第5页
第5页 / 共10页
软件架构案例分析.docx_第6页
第6页 / 共10页
软件架构案例分析.docx_第7页
第7页 / 共10页
软件架构案例分析.docx_第8页
第8页 / 共10页
软件架构案例分析.docx_第9页
第9页 / 共10页
软件架构案例分析.docx_第10页
第10页 / 共10页
亲,该文档总共10页,全部预览完了,如果喜欢就下载吧!
下载资源
资源描述

软件架构案例分析.docx

《软件架构案例分析.docx》由会员分享,可在线阅读,更多相关《软件架构案例分析.docx(10页珍藏版)》请在冰点文库上搜索。

软件架构案例分析.docx

软件架构案例分析

票务系统架构案例分析

•10.1ATAM方法表述

•10。

2商业动机的表述

•10。

3构架的表述

•10.4质量属性效用树

•10.5质量场景的构架分析

•10.6对系统构架的再分析

•10。

7评审结论

10.1ATAM方法表述

(1)概述

ATAM(ArchitectureTradeoffAnalysisMethod):

SEI提出的一种软件构架评估方法。

ATAM评估方法的主

要目的:

1)提炼出软件质量属性需求的精确描述;

2)提炼出构架设计决策的精确描述;

3)评估这些构架设计决策,并判定其是否令人满意的实

现了这些质量需求。

ATAM评估方法:

并非把每个可以量化的质量属性都进行详尽的分析,而是使众多的风险承担者(包括经理、开发人员、测试人员、用户、客户等等)都参与进来,由此而达到上述目标的。

ATAM是一种挖掘潜在风险,降低或者缓和现有风险的软件构架评估方法。

因此,以下三点是评估中要特别注重的

风险、敏感点和权衡点。

(2)构架涉众

·普通用户

·用户管理员

·票务管理员

·开发人员

·测试人员

(3)

评估步骤

ATAM主要分以下几个步骤:

1)ATAM描述;

2)商业动机表述;

3)软件构架表述;4)确定构架方式;

5)生成效用树;

6)分析构架方式;

7)确定场景及其优先级;

8)进一步分析构架方式;

9)得出结论。

10。

2商业动机的描述

项目经理从开发组织和客户角度,来表述票务系统的商业目标,综合如下:

•从开发组织角度:

开发一个模块性强、实时高效、界面良好、与外部其他系统兼容良好的系统,这使得开发组织能够把整个产品或某个模块卖给其他客户,同时由于良好的界面和业务处理效率而受市场欢迎。

•从客户角度:

系统容易操作,可维护性好、系统稳定、可以及时准确的处理用户的在线订票或查询业务。

根据上述目标,质量属性可以划分为两类:

高优先级质量属性:

1)性能

2)安全性

3)易用性

4)可用性

重要但优先级较低的属性:

1)模块性

2)可维护性

3)可修改性

4)可测试性

10。

3架构表述

(1)与构架商业周期的关系

(2)系统的整体结构

(3)质量属性及采用的战术

10.4质量属性效用树

10。

5质量场景的构架分析

在质量属性效用树中,我们对场景的优先级进行了划分,而同时由于分析时间宝贵,所以我们应该把宝贵的分析时间最先用于最重要且最难实现的场景上,即标注为(H,H)的场景。

在质量属性效用树的表格中,仅在性能和可用性这2个质量属性下发现标注有(H,H)的场景,下面根据系统的体系结构和实现质量属性所采用的战术分别给出这些重要场景的构架方法分析表格。

•性能

•可用性

10。

6对系统构架的再分析

(1)风险决策和敏感点

(2)问题分析

在前面对系统结构的描述中,系统采用基于B/S的分层结构,系统部署在一台应用服务器上,这种结构有它独特的优点.但经过构架方法的分析,特别是对系统的关键质量属性和优先级最高的质量属性场景的分析,发现系统在上述场景下会出现如下的问题:

(1)性能方面:

在非常多的用户并发操作的情况下,单服务器系统将不能对用户的请求做出及时的响应,严重情况下服务器还会崩溃.

(2)可用性方面:

在仅有的一台应用服务器出现故障或者崩溃的情况下,用户将不能访问系统,故障恢复需要花费较长时间。

(3)改进系统的构架

考虑到使用票务系统的用户数目非常庞大,这样造成用户对系统的访问请求数目和对系统进行业务操作的请求数目也非常庞大,改进后的系统采用多层分布式结构,使用Web服务器集群和应用服务器集群来实现,这种集群机制支持动态负载平衡(LoadBalance)和容错机制,可以将用户的请求以及对用户请求的处理分发到负载低的服务器中,非常适合具有并发用户数多,服务地点分散等这些特点,有较高的稳定性,能有效避免访问流量过多导致服务器瘫痪以及整个系统因为某台服务器崩溃而彻底瘫痪。

为了使系统达到集群分布式的目的,在第一套方案的基础上,我们采用Spring介入EJB容器的方式,使用EJB的无状态会话Bean来封装业务逻辑,即调用POJO中的业务逻辑操作(POJO中包含了业务逻辑处理,在原来的SSH框架中它是指业务层的JavaBean,通过持久层与数据库交互,这些POJO通过IOC容器来管理)。

这相当于在

Struts和业务逻辑层之间增加了EJB,重用原SSH框架的业务逻辑,即系统框架变Struts+EJB+Hibernate+Spring

,这种组合可以将视图和业务逻辑以及对数据库的操作很好的分离。

(4)新的框架如下:

10。

7评审结论

总体而言,通过对质量属性场景的分析,我们发现了最先提出的构架方案的不足,由此得出改进后的构架方案.采用改进后的构架方案可以获得了良好的性能、易用性、安全性、可用性等等,达到了设计目的符合质量属性需求分析的要求!

展开阅读全文
相关资源
猜你喜欢
相关搜索
资源标签

当前位置:首页 > 农林牧渔 > 林学

copyright@ 2008-2023 冰点文库 网站版权所有

经营许可证编号:鄂ICP备19020893号-2