软件架构案例分析

软件架构案例分析

ID:42708601

大小:489.49 KB

页数:11页

时间:2019-09-20

软件架构案例分析_第1页
软件架构案例分析_第2页
软件架构案例分析_第3页
软件架构案例分析_第4页
软件架构案例分析_第5页
资源描述:

《软件架构案例分析》由会员上传分享,免费在线阅读,更多相关内容在教育资源-天天文库

1、票务系统架构案例分析•1案例背景•2质量属性需求和功能需求•3架构表述•4构件解决方案•5评审结论•1案例背景开发的软件系统的名称:铁路售票管理系统 本软件产品是一项独立的软件,而且全部内容自含。实现网络化铁路售票管理。一般用户可以通过上网来进行铁路车票业务的管理,实现网络化售票业务。构建标准的铁路车票,火车管理基础数据库。构建起火车信息,车票信息基础数据库。 实现列车及车票信息查询、信息管理、车票的销售与退票列车及车票管理等子系统的流程化管理。 2质量属性需求和功能需求质量属性需求:项目经理从开发组织和客户角度,来表述票务系统的商业目标,综合如下:•从开

2、发组织角度:开发一个模块性强、实时高效、界面良好、与外部其他系统兼容良好的系统,这使得开发组织能够把整个产品或某个模块卖给其他客户,同时由于良好的界面和业务处理效率而受市场欢迎。•从客户角度:系统容易操作,可维护性好、系统稳定、可以及时准确的处理用户的在线订票或查询业务。根据上述目标,质量属性可以划分为两类:高优先级质量属性:a性能b安全性c易用性d可用性重要但优先级较低的属性:a可修改性b可测试性质量属性及采用的战术功能需求:  a列车查询  按车次或目的站信息来查询列车的静态信息 b 车票查询  按车次或目的站信息来查询车票的静态信息 c 车次查询  

3、 按已知车次来查询列车及车票信息 d目的站查询  按已知目的站来查询需要的列车及车票信息 3架构表述(1)与构架商业周期的关系构架涉众·普通用户·用户管理员·票务管理员·开发人员·测试人员(2)系统的整体结构4构件解决方案(1)风险决策和敏感点(2)问题分析在前面对系统结构的描述中,系统采用基于B/S的分层结构,系统部署在一台应用服务器上,这种结构有它独特的优点。但经过构架方法的分析,特别是对系统的关键质量属性和优先级最高的质量属性场景的分析,发现系统在上述场景下会出现如下的问题:a.性能方面:在非常多的用户并发操作的情况下,单服务器系统将不能对用户的请求

4、做出及时的响应,严重情况下服务器还会崩溃。b.可用性方面:在仅有的一台应用服务器出现故障或者崩溃的情况下,用户将不能访问系统,故障恢复需要花费较长时间。(3)改进系统的构架考虑到使用票务系统的用户数目非常庞大,这样造成用户对系统的访问请求数目和对系统进行业务操作的请求数目也非常庞大,改进后的系统采用多层分布式结构,使用Web服务器集群和应用服务器集群来实现,这种集群机制支持动态负载平衡(LoadBalance)和容错机制,可以将用户的请求以及对用户请求的处理分发到负载低的服务器中,非常适合具有并发用户数多,服务地点分散等这些特点,有较高的稳定性,能有效避免

5、访问流量过多导致服务器瘫痪以及整个系统因为某台服务器崩溃而彻底瘫痪。为了使系统达到集群分布式的目的,在第一套方案的基础上,我们采用Spring介入EJB容器的方式,使用EJB的无状态会话Bean来封装业务逻辑,即调用POJO中的业务逻辑操作(POJO中包含了业务逻辑处理,在原来的SSH框架中它是指业务层的JavaBean,通过持久层与数据库交互,这些POJO通过IOC容器来管理)。这相当于在Struts和业务逻辑层之间增加了EJB,重用原SSH框架的业务逻辑,即系统框架变Struts+EJB+Hibernate+Spring,这种组合可以将视图和业务逻辑以

6、及对数据库的操作很好的分离。(4)新的框架如下:5评审结论总体而言,通过对质量属性场景的分析,我们发现了最先提出的构架方案的不足,由此得出改进后的构架方案。采用改进后的构架方案可以获得了良好的性能、易用性、安全性、可用性等等,达到了设计目的符合质量属性需求分析的要求!

当前文档最多预览五页,下载文档查看全文

此文档下载收益归作者所有

当前文档最多预览五页,下载文档查看全文
温馨提示:
1. 部分包含数学公式或PPT动画的文件,查看预览时可能会显示错乱或异常,文件下载后无此问题,请放心下载。
2. 本文档由用户上传,版权归属用户,天天文库负责整理代发布。如果您对本文档版权有争议请及时联系客服。
3. 下载前请仔细阅读文档内容,确认文档内容符合您的需求后进行下载,若出现内容与标题不符可向本站投诉处理。
4. 下载文档时可能由于网络波动等原因无法下载或下载错误,付费完成后未能成功下载的用户请联系客服处理。