体系结构--第6章--票务系统架构设计案例分析.ppt

第6章票务系统架构设计案例分析 6.1项目背景6.2需求分析6.3系统架构设计6.4小结6.1 项目背景 由于票务种类的繁多，客户信息的量大复杂。所以在其管理上存在较大困难，特别是早期单用人力和纸张进行管理。导致信息的不全面和错误率高，加之存储介质的约束，难以长期有效的管理。随着计算机网络的发展，电子商务的普及。一种基于B/S模式的票务系统提出了需求。由于票务的特殊性，需要系统有很强的稳定性，要求较快的反应速度，响应多点同时请求。另外后台对票务的所有相关信息需要完全记录。完成历史信息的保存，查询；对当前信息的录入，查询，修改，删除。6.2需求分析 主要任务 创建代表“目前”业务情况的业务模型，并将此业务模型转换成“将来”的系统模型，包括功能需求和非功能需求。非功能需求又包括质量属性和各种约定。通过对客户的当前业务的分析，我们得到当前业务的基本需求。功能需求功能说明客户信息管理用户的创建、登录、删除和维护票务信息管理票务的添加、删除和维护票务查询查看相应的票务信息预定购票票务的预定、购买和取消 非功能需求质量属性说明性能用户访问的系统应该能在规定的时间内做出响应，如果系统由于网络或者数据库原因不能在规定时间内做出反应，那么系统应该提出警告，不能出现用户无故长时间等待的情况。安全性在web数据库客户端，web服务器和数据库服务器之间，都应该有防火墙保护，防止网络上的非法数据请求。易用性不同的用户应该能够以不同形式访问不同的内容 可用性系统提供7X24小时的服务，且很少停机 可测试性系统是的各部分易于单独测试，并能方便地进行整体测试 6.2.1 定义系统 根据业务的功能需求，该系统主要的涉众有系统管理人员和客户，系统管理人员又分为票务管理人员和用户管理人员。票务管理人员会对票务信息进行相关维护，用户管理人员对客户信息进行相关的维护。由此得出系统角色，分析其对系统的具体要求，并找出系统的各个用例。用例说明票务信息查询用户输入相关查询条件信息，查看到相关票务的具体信息，当查询条件不符合规定时，系统给出相应提示。票务操作用户根据查询出来的票务信息对票务信息进行预订，购买，取消等操作票务信息维护票务管理员对票务信息进行维护，如添加，删除等用户信息维护用户管理员根据用户资料，维护系统中记录的用户相关信息。根据上述分析，可以得到系统用例视图：6.2.2 细化定义 (1)细化用例 细化业务用例模型，是为了更加详细地分析和描述用例。同时，将业务用例模型转换成系统的用例模型。下面，以“角色”用户进行票务购买为例。要素说明用例名称用户购买票务简要描述用户根据当前票务信息购买相应票务事件流基本事件流（1）用户在购票的名称栏中输入要购买的票务的起始地与目的地（2）系统根据客户输入，列出相应的票务信息 细化用例后，还需对用例进行详细描述，直到所有涉众都认可描述的内容已经能够正确表达出他们的需求为止。在RUP方法论中指明通过阐述一个用例的名称、简要描述、事件流、特殊需求、前置条件和后置条件等六个方面可以对用例进行描述。下面以用例“用户购买票务”为例细化描述。要素说明事件流（3）用户根据自己的实际情况选择符合自己相应条 件的票务，如票价、时间等。（4）系统显示购买成功，或者显示交易失败。（5）该“用户购买票务”用例结束。“用户购买票务”用例细化描述（续）要素说明备选事件流系统查询不到票务相关信息，则按下一步步骤进行：（1）提示用户票务交易无法进行，并给出交易失败原因（2）其次，撤销此次交易的记录。特殊需求系统不可伪造数据，交易失败原因要合理并且详尽“用户购买票务”用例细化描述（续）要素说明前置条件用户必须先登陆后置条件交易成功后数据库及时更新票务信息“用户购买票务”用例细化描述（续）上面对用例的描述仅限于文字描述，还不够形象。再以活动图的形式进行建模描述如下：(2)结构化用例结构化用例的目的是通过观察这些已经细化的用例，看能不能抽取出共有的、可选的行为，把这些共同的内容建立为新的用例。这样的好处是，可以消除冗余的需要以及改善系统整体需求内容的可维护性。像“用户信息维护”用例中，“查询用户信息”应作为一个新的用例提取出来，以提高上面所说的需求内容的可维护性。6.3 系统架构设计将需求内容转换成设计模型的雏形以及用户体验模型，其目的是建立整个系统初步的解决方案，为详细设计活动打下基础，这一阶段的具体活动如下：6.3.1 体系结构的选择 早期的票务系统仅仅针对售票单位，只是简单的数量控制，票务记录。而新的票务系统不仅仅具有以前的所有功能，还利用网络将客户包括近来。方便客户进行操作，利用网络可以让客户在任何有网络的地方就可以直接连入系统。又由于计算机的支持，数据库中有所有客户的信息，可以方便售票方对客户进行管理，提供更好的服务。本系统采用基于B/S的分层结构。这种结构有如下特点：节省投资、跨地域广；维护和升级方式简单，如果想对功能修改，可以方便的进行更改，大大减少维护成本。系统的结构视图如下：在J2EE开发中，搭配良好的框架可以降低开发人员解决复杂问题的难度，而如何将框架整合起来，以使每一层都向另外的层次以松散的方式来提供接口，同时让组合的三个框架在每一层都以一种松耦合的方式彼此沟通，从而与低层的技术透明无关，这就是框架分析的目的和要求。所以我们把Structs、Hibernate和Spring组合起来的目标就是希望能实现系统的“低耦合、高内聚”。也就是要求系统易于维护、易于适应变更、可重用性的特点。根据前期对需求的分析，决定采用基于SSH框架来构建此分布式的信息管理系统。SSH多层的构架模式，从上到下依次为视图层、控制器层、模型层、持久化层和数据库层，如下图所示：框架讲解：视图层：职责是提供控制器，将页面的请求委派给其他层进行处理，为显示提供业务数据模型。控制层：职责是按预定的业务逻辑处理视图层提交的请求。（1）处理业务逻辑和业务校验（2）事务管理（3）管理业务层对象间的依赖关系（4）向表示层提供具体业务服务的实现类模型层：职责是将模型的状态转交视图层，以提供页面给浏览器。数据持久层：职责是建立持久化类及其属性与数据库中表及其字段的对应关系。提供简化SQL语句的机制。实现基本的数据操作（增、删、读、改）数据库层：数据库的建立与管理。规则（约束）：（1）系统各层次及层内部子层次之间都不得跨层调用。（2）由bean传递模型状态。（3）需要在表示层绑定到列表的数据采用基于关系的数据集传递。（4）对于每一个数据库表（Table）都有一个DBEntityclass与之对应，由Hibernate完成映射。（5）有些跨数据库或跨表的操作（如复杂的联合查询）也需要由Hibernate来提供支持。（6）表示层和控制层禁止出现任何SQL语句。SSH框架介绍：视图层、控制器层用Structs框架来实现，模型层的功能Spring来完成。持久化层时使用Hibernate实现，在这层使用了DAO模式。Structs应用MVC模型使页面展现与业务逻辑分离，做到了页面展现与业务逻辑的低耦合。当充当表示层的页面需要变更时，只需要修改该具体的页面，不影响业务逻辑Bean等；同样，业务逻辑需要变更的时候，只需要修改相应的Java程序。使用Spring能运用IoC技术来降低了业务逻辑中各个类的相互依赖:假如，类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 Server，如何执行的操作，与具体的系统无关，只需在Hibernate的相关的XML文件里根据具体系统配置好。现在我们通过下表来看看构架是如何来满足系统的关键质量属性需求。6.3.2系统架构的分析与设计1 质量场景 1）性能场景：在系统处于高峰时期，保证登陆的每个顾客所作的选择和查询的响应时间能在5s以内，如果需要等待则给出有友好的提示。系统可以保证以最快速度同时响应500个用户的操作。制品：制品：系统刺激：刺激：提交请求响应：响应：请求被正确处理环境：环境：在正常操作下1 2 3响应度量：响应度量：平均等待时间在5秒内源：用户 2）安全性场景：杜绝非法用户试图绕过应用服务器直接连接到数据库服务器的端口上，防止非法窃取注册用户个人息；屏蔽某IP短时间内的大量无意义的访问，以防被挤爆，使正常用户无法使用。保证系统数据的机密性和完整性。制品：制品：系统刺激：刺激：试图非法操作信息响应：响应：系统维持审核踪迹环境：环境：在正常操作下1 2 3响应度量：响应度量：半天内恢复校正数据源：系统外部 3）易用性场景：在该系统中，用户希望在运行时能尽快取消某操作使错误的影响降到最低，取消在1秒内发生；要求具有基本电脑操作常识的人，可以根据良好的界面设计迅速学会使用方法，让熟手用户使用快捷键。制品：制品：系统刺激：刺激：使错误的影响最低响应：响应：提示操作希望取消环境：环境：运行时1 2 3响应度量：响应度量：在2秒内源：用户 4)可用性场景：在正常的工作时间内，系统必须具有极高的可用性，保证出故障几率最低。出现故障时系统有相应的处理机制。制品：制品：系统刺激：刺激：错误或异常发生响应：响应：系统给出警告信息环境：环境：在正常操作下1 2 3响应度量：响应度量：系统不停机源：系统内部2 数据持久层的架构分析 在数据持久层，我们使用Hibernate来进行处理，通过下面我们来看看如何通过Hibernate来满足系统的质量属性需求。Hibernate体系结构概要图从这个图可以看出，Hibernate通过配置文件和映射文件来实现与数据库的交互及实现对象关系映射（Object Relational Mapping，简称ORM），通过这种机制，将java程序中的对象自动持久化到关系数据库中，对持久化对象的改动都会反映到数据库中。其中配置文件主要用来配置好数据库连接的各种参数以及定义数据映射文件，通常以hibernate.cfg.xml或者hibernate.properties形式出现；XML Mapping配置文件是数据库中表的数据映射文件，通常以*.hbm.xml形式出现。下面我们来更详细地看一下Hibernate运行时体系结构方案。这种方案将应用层从底层的JDBC/JTA API中抽象出来，而让Hibernate来处理这些细节。Hibernate体系结构方案图中各个对象的定义如下：SessionFactory 针对单个数据库映射关系经过编译后的内存镜像，是线程安全的（不可变）。它是生成Session的工厂，本身要用到ConnectionProvider。该对象可以在进程或集群的级别上，为那些事务之间可以重用的数据提供可选的二级缓存。Session 表示应用程序与持久储存层之间交互操作的一个单线程对象，此对象生存期很短。其隐藏了JDBC连接，也是Transaction的工厂。其会持有一个针对持久化对象的必选（第一级）缓存，在遍历对象图或者根据持久化标识查找对象时会用到。持久的对象及其集合持久的对象及其集合 带有持久化状态的、具有业务功能的单线程对象，此对象生存期很短。这些对象可能是普通的JavaBeans/POJO，唯一特殊的是他们正与（仅仅一个）Session相关联。一旦这个Session被关闭，这些对象就会脱离持久化状态，这样就可被应用程序的任何层自由使用。（例如，用作跟表示层打交道的数据传输对象。）瞬态瞬态(transient)和脱管和脱管(detached)的对象及其集合的对象及其集合 那些目前没有与session关联的持久化类实例。他们可能是在被应用程序实例化后，尚未进行持久化的对象。也可能是因为实例化他们的Session已经被关闭而脱离持久化的对象。事务事务Transaction （可选的）应用程序用来指定原子操作单元范围的对象，它是单线程的，生命周期很短。它通过抽象将应用从底层具体的JDBC、JTA以及CORBA事务隔离开。某些情况下，一个Session之内可能包含多个Transaction对象。尽管是否使用该对象是可选的，但无论是使用底层的API还是使用Transaction对象，事务边界的开启与关闭是必不可少的。ConnectionProvider （可选的）生成JDBC连接的工厂（同时也起到连接池的作用）。它通过抽象将应用从底层的Datasource或DriverManager隔离开。仅供开发者扩展/实现用，并不暴露给应用程序使用。TransactionFactory （可选的）生成Transaction对象实例的工厂。仅供开发者扩展/实现用，并不暴露给应用程序使用。扩展接口扩展接口 Hibernate提供了很多可选的扩展接口，你可以通过实现它们来定制你的持久层的行为。Hibernate满足的质量属性需求 (1)性能 Hibernate本质上是包装了JDBC来进行数据操作的，由于Hibernate在调用JDBC上面是优化了JDBC调用，并且尽可能的使用最优化的，最高效的JDBC调用，所以性能令人满意，同时应用程序需要在关联关系间进行导航的时候，由Hibernate获取关联对象，Hibernate提供的对持久化数据的缓存机制也对系统的性能的提高起了很大的作用。(2)安全性 Hibernate提供的悲观锁/乐观锁机制，能够在多个用户进行并发操作时保持数据库中数据的一致性与完整性，避免了对数据库中数据的破坏。(3)易用性 用户在对票务信息进行操作时都得到Hibernate的支持。3业务逻辑层架构设计 业务逻辑层作为该系统的关键部分，对系统的灵活性实现起着决定性的 作用。在本系统的业务逻辑层架构层中，采取了MVC模式，下面简单介绍一 下MVC模式的好处：(1)实现了客户端表示层和业务逻辑层的完全分离 (2)高效可靠的事务处理 (3)具有良好的易用性，安全性MVC模式访问流程：MVC模式在本系统中应用：当客户利用网页浏览器，发出HTTP请求时，这通常会牵涉到送出表单数据，例如用户名和密码。Servlet收到这样的数据并解析数据。Servlet扮演控制器的角色，处理你的请求，通常会向模型（一般是数据库）发出请求。处理结果往往以JavaBean的形式打包。视图就是JSP，而JSP唯一的工作就是产生页面，表现模型的视图以及进一步动作所需要的所有控件。当页面返回浏览器作为视图显示出来，用户提出的进一步请求，也会以同样的方式处理。由于JSP继承了J2EE良好的易用性和安全性，从而为实现系统的关键质量属性奠定了基础。在MVC模式中，视图不再是经典意义上的模型的观察者。当模型发生改变时，视图的确间接的从控制器收到了相当于通知的东西，控制器可以把bean送给视图，以使得视图取得模型的状态。所以，视图在HTTP响应返回到浏览器时只需要一个状态信息的更新。只有当页面被创建和返回时，创建视图并结合模型状态才有意义。这使得提升系统的系能成为可能。只有当相应的操作被执行，系统才会去获取关联对象，并且视图不会直接模型向注册去接受状态信息，使得系统的安全性得到大大提高。业务逻辑层的框架：业务逻辑层架构分析：该业务逻辑层的架构是前面MVC模式的一种变形，他继承了MVC模式的优点，同时，具体到我们的架构中，它又实现了表示层与业务层的完全分离。在业务逻辑层我们使用Spring框架作为容器，以便实现业务层与表示层和数据层的松耦合。该业务逻辑层架构具备良好的易用性、安全性和性能。下表给出spring容器如何满足系统关键质量属性 (1)与构架商业周期的关系6.3.3构架表述(2)整体的构架如下：因为具体持久化层数据源是多样化的，可能是XML方式或其他不同厂商的关系数据库。我们通过使用DAO模式，业务部分就不用关心具体数据层是如何实现对数据库的操作的，对数据库的操作全部有DAO类实现，如图所示：6.4小结 本章通过案例分析描述了设计师是如何通过质量属性来驱动系统设计的过程，根据质量属性选择相应的战术以及场景来进行分析。