体系结构-第6章-票务系统架构设计案例分析课件.ppt
- 【下载声明】
1. 本站全部试题类文档,若标题没写含答案,则无答案;标题注明含答案的文档,主观题也可能无答案。请谨慎下单,一旦售出,不予退换。
2. 本站全部PPT文档均不含视频和音频,PPT中出现的音频或视频标识(或文字)仅表示流程,实际无音频或视频文件。请谨慎下单,一旦售出,不予退换。
3. 本页资料《体系结构-第6章-票务系统架构设计案例分析课件.ppt》由用户(晟晟文业)主动上传,其收益全归该用户。163文库仅提供信息存储空间,仅对该用户上传内容的表现方式做保护处理,对上传内容本身不做任何修改或编辑。 若此文所含内容侵犯了您的版权或隐私,请立即通知163文库(点击联系客服),我们立即给予删除!
4. 请根据预览情况,自愿下载本文。本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。
5. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007及以上版本和PDF阅读器,压缩文件请下载最新的WinRAR软件解压。
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 体系结构 系统 架构 设计 案例 分析 课件
- 资源描述:
-
1、 6.1 项目背景 6.2 需求分析 6.3 系统架构设计 6.4 小结6.1 项目背景 由于票务种类的繁多,客户信息的量大复杂。所以在其管理上存在较大困难,特别是早期单用人力和纸张进行管理。导致信息的不全面和错误率高,加之存储介质的约束,难以长期有效的管理。随着计算机网络的发展,电子商务的普及。一种基于B/S模式的票务系统提出了需求。由于票务的特殊性,需要系统有很强的稳定性,要求较快的反应速度,响应多点同时请求。另外后台对票务的所有相关信息需要完全记录。完成历史信息的保存,查询;对当前信息的录入,查询,修改,删除。6.2 需求分析 主要任务 创建代表“目前”业务情况的业务模型,并将此业务模型
2、转换成“将来”的系统模型,包括功能需求和非功能需求。非功能需求又包括质量属性和各种约定。通过对客户的当前业务的分析,我们得到当前业务的基本需求。功能需求功能说明客户信息管理用户的创建、登录、删除和维护票务信息管理票务的添加、删除和维护票务查询查看相应的票务信息预定购票票务的预定、购买和取消 非功能需求质量属性说明性能用户访问的系统应该能在规定的时间内做出响应,如果系统由于网络或者数据库原因不能在规定时间内做出反应,那么系统应该提出警告,不能出现用户无故长时间等待的情况。安全性在web数据库客户端,web服务器和数据库服务器之间,都应该有防火墙保护,防止网络上的非法数据请求。易用性不同的用户应该
3、能够以不同形式访问不同的内容 可用性系统提供7X24小时的服务,且很少停机 可测试性系统是的各部分易于单独测试,并能方便地进行整体测试 6.2.1 定义系统 根据业务的功能需求,该系统主要的涉众有系统管理人员和客户,系统管理人员又分为票务管理人员和用户管理人员。票务管理人员会对票务信息进行相关维护,用户管理人员对客户信息进行相关的维护。由此得出系统角色,分析其对系统的具体要求,并找出系统的各个用例。用例说明票务信息查询用户输入相关查询条件信息,查看到相关票务的具体信息,当查询条件不符合规定时,系统给出相应提示。票务操作用户根据查询出来的票务信息对票务信息进行预订,购买,取消等操作票务信息维护票
4、务管理员对票务信息进行维护,如添加,删除等用户信息维护用户管理员根据用户资料,维护系统中记录的用户相关信息。根据上述分析,可以得到系统用例视图:6.2.2 细化定义 (1)细化用例 细化业务用例模型,是为了更加详细地分析和描述用例。同时,将业务用例模型转换成系统的用例模型。下面,以“角色”用户进行票务购买为例。要素说明用例名称用户购买票务简要描述用户根据当前票务信息购买相应票务事件流基本事件流(1)用户在购票的名称栏中输入要购买的票务的起始地与目的地(2)系统根据客户输入,列出相应的票务信息 细化用例后,还需对用例进行详细描述,直到所有涉众都认可描述的内容已经能够正确表达出他们的需求为止。在R
5、UP方法论中指明通过阐述一个用例的名称、简要描述、事件流、特殊需求、前置条件和后置条件等六个方面可以对用例进行描述。下面以用例“用户购买票务”为例细化描述。要素说明事件流(3)用户根据自己的实际情况选择符合自己相应条 件的票务,如票价、时间等。(4)系统显示购买成功,或者显示交易失败。(5)该“用户购买票务”用例结束。“用户购买票务”用例细化描述(续)要素说明备选事件流系统查询不到票务相关信息,则按下一步步骤进行:(1)提示用户票务交易无法进行,并给出交易失败原因(2)其次,撤销此次交易的记录。特殊需求系统不可伪造数据,交易失败原因要合理并且详尽“用户购买票务”用例细化描述(续)要素说明前置条
6、件用户必须先登陆后置条件交易成功后数据库及时更新票务信息“用户购买票务”用例细化描述(续)上面对用例的描述仅限于文字描述,还不够形象。再以活动图的形式进行建模描述如下:(2)结构化用例 结构化用例的目的是通过观察这些已经细化的用例,看能不能抽取出共有的、可选的行为,把这些共同的内容建立为新的用例。这样的好处是,可以消除冗余的需要以及改善系统整体需求内容的可维护性。像“用户信息维护”用例中,“查询用户信息”应作为一个新的用例提取出来,以提高上面所说的需求内容的可维护性。6.3 系统架构设计 将需求内容转换成设计模型的雏形以及用户体验模型,其目的是建立整个系统初步的解决方案,为详细设计活动打下基础
7、,这一阶段的具体活动如下:6.3.1 体系结构的选择 早期的票务系统仅仅针对售票单位,只是简单的数量控制,票务记录。而新的票务系统不仅仅具有以前的所有功能,还利用网络将客户包括近来。方便客户进行操作,利用网络可以让客户在任何有网络的地方就可以直接连入系统。又由于计算机的支持,数据库中有所有客户的信息,可以方便售票方对客户进行管理,提供更好的服务。本系统采用基于B/S的分层结构。这种结构有如下特点:节省投资、跨地域广;维护和升级方式简单,如果想对功能修改,可以方便的进行更改,大大减少维护成本。系统的结构视图如下:在J2EE开发中,搭配良好的框架可以降低开发人员解决复杂问题的难度,而如何将框架整合
8、起来,以使每一层都向另外的层次以松散的方式来提供接口,同时让组合的三个框架在每一层都以一种松耦合的方式彼此沟通,从而与低层的技术透明无关,这就是框架分析的目的和要求。所以我们把Structs、Hibernate和Spring组合起来的目标就是希望能实现系统的“低耦合、高内聚”。也就是要求系统易于维护、易于适应变更、可重用性的特点。根据前期对需求的分析,决定采用基于SSH框架来构建此分布式的信息管理系统。SSH多层的构架模式,从上到下依次为视图层、控制器层、模型层、持久化层和数据库层,如下图所示:框架讲解:视图层:职责是提供控制器,将页面的请求委派给其他层进行处理,为显示提供业务数据模型。控制层
9、:职责是按预定的业务逻辑处理视图层提交的请求。(1)处理业务逻辑和业务校验 (2)事务管理 (3)管理业务层对象间的依赖关系 (4)向表示层提供具体业务服务的实现类 模型层:职责是将模型的状态转交视图层,以提供页面给浏览器。数据持久层:职责是建立持久化类及其属性与数据库中表及其字段的对应关系。提供简化SQL语句的机制。实现基本的数据操作(增、删、读、改)数据库层:数据库的建立与管理。规则(约束):(1)系统各层次及层内部子层次之间都不得跨层调用。(2)由bean传递模型状态。(3)需要在表示层绑定到列表的数据采用基于关系的数据集传递。(4)对于每一个数据库表(Table)都有一个DB Enti
10、ty class与之对应,由Hibernate完成映射。(5)有些跨数据库或跨表的操作(如复杂的联合查询)也需要由Hibernate来提供支持。(6)表示层和控制层禁止出现任何SQL语句。SSH框架介绍:视图层、控制器层用Structs框架来实现,模型层的功能Spring来完成。持久化层时使用Hibernate实现,在这层使用了DAO模式。Structs应用MVC模型使页面展现与业务逻辑分离,做到了页面展现与业务逻辑的低耦合。当充当表示层的页面需要变更时,只需要修改该具体的页面,不影响业务逻辑Bean等;同样,业务逻辑需要变更的时候,只需要修改相应的Java程序。使用Spring能运用IoC技
11、术来降低了业务逻辑中各个类的相互依赖:假如,类A因为需要功能F而调用类B,在通常的情况下类A需要引用类B,因而类A就依赖于类B了,也就是说当类B不存在的时候类A就无法使用了。使用了IoC,类A调用的仅仅是实现了功能F的接口的某个类,这个类可能是类B,也可能是类C,由Spring的XML配置文件来决定。这样,类A就不再依赖与类B,耦合度降低,重用性得以提高。使用Hibernate能让业务逻辑与数据持久化分离,就是将数据存储到数据库的操作分离。在业务逻辑中只需要将数据放到值对象中,然后交给Hibernate,或者从Hibernate那里得到值对象。至于用DB2、Oracle、MySQL还是SQL
展开阅读全文