票务系统架构设计案例分析.ppt

1、第六章票务系统架构设计案例分析，6.1项目背景，6.2需求分析，6.3系统架构设计，6.4总结，6.1项目背景。由于票务类型的多样性，客户信息量大且复杂。因此，它的管理有很大的困难，特别是在早期，它是由人力和纸张管理。它导致信息不完整和错误率高，并且由于存储介质的限制，长期以来难以有效管理。随着计算机网络的发展，电子商务的普及。基于B/S模式的票务系统提出了这一需求。由于票务的特殊性，系统需要很强的稳定性、快速的响应速度和多点同时请求。此外，票务的所有相关信息都需要在后台完整记录。完成历史信息的保存和查询；输入、查询、修改和删除当前信息。6.2需求分析，主要任务是创建一个表示“当前”业务情况的

2、业务模型，并将该业务模型转换为“未来”系统模型，包括功能需求和非功能需求。非功能性需求包括质量属性和各种约定。通过分析客户当前的业务，我们得到了当前业务的基本要求。6.2.1定义系统根据业务的功能需求，系统的主要利益相关者是系统经理和客户，系统经理分为票务经理和用户经理。票证管理人员将维护票证信息，用户管理人员将维护客户信息。由此，我们得到系统角色，分析其对系统的具体需求，并找出系统的每个用例。根据以上分析，我们可以得到系统用例视图：6.2.2详细定义(1)细化用例，细化业务用例模型，以便更详细地分析和描述用例。同时，业务用例模型被转化为系统用例模型。接下来，以“角色”用户的购票为例。在细化用

3、例之后，有必要详细描述用例，直到所有涉众都同意所描述的内容能够正确表达他们的需求。在RUP方法论中，指出用例可以通过阐述其名称、简要描述、事件流、特殊需求、前提条件和后置条件来描述。下面是对用例“用户买票”的详细描述。详细描述“用户购买门票”(续)、“用户购买门票”(续)和“用户购买门票”(续)。然后以活动图的形式进行建模，如下所述：(2)结构化用例结构化用例的目的是观察这些细化的用例，看它们是否能够提取公共和可选的行为，并将这些公共内容构建到新的用例中。这样做的好处是消除了对冗余的需求，提高了整个系统需求的可维护性。像“用户信息维护”的用例一样，“查询用户信息”应该作为一个新的用例来提取，以

4、提高上述需求的可维护性。6.3系统架构设计，将需求转化为设计模型和用户体验模型的原型。其目的是建立整个系统的初步解决方案，为详细设计活动奠定基础。这一阶段的具体活动如下：6.3.1架构的选择，早期的售票系统只针对售票单元，而只针对简单的数量控制和售票记录。新的售票系统不仅具有以前的所有功能，而且最近还利用网络来吸纳顾客。客户操作方便，网络允许客户在有网络的地方直接连接到系统。由于有了计算机的支持，数据库中有了所有的客户信息，方便了售票人员管理客户，提供更好的服务。该系统采用基于B/S的分层结构，该结构具有以下特点：节省投资，跨区域广；维护和升级方法简单，如果您想修改功能，可以方便地进行修改，从

5、而大大降低维护成本。系统的结构视图如下：在J2EE开发中，匹配良好的框架可以降低开发人员解决复杂问题的难度，以及如何集成框架，使每一层都以松散的方式提供与其他层的接口，同时三个组合框架在每一层都以松散耦合的方式相互通信，这与下层的技术透明性无关，这是框架分析的目的和要求。因此，我们结合Structs、Hibernate和Spring的目标是实现系统的“低耦合、高内聚”。也就是说，该系统易于维护、适应变化并可重用。根据前面的需求分析，决定构建基于SSH框架的分布式信息管理系统。SSH的多层架构模式自上而下包括视图层、控制器层、模型层、持久层和数据库层，如下图所示：框架说明：视图层：其职责是提供一

6、个控制器，将页面请求委托给其他层进行处理，并提供一个业务数据模型进行显示。控制层：职责是根据预定的业务逻辑处理视图层提交的请求。(1)处理业务逻辑和业务验证(2)事务管理(3)管理业务层对象之间的依赖关系(4)向表示层提供特定业务服务的实现类模型层：其职责是将模型状态转移到视图层，为浏览器提供页面。数据持久层：职责是建立持久类和它们的属性以及数据库中的表和字段之间的对应关系。提供了一种简化SQL语句的机制。实现基础数据操作(添加、删除、读取和修改)。数据库层：数据库的建立和管理。规则(约束):(1)系统的所有级别和级别内的子级别不得跨级别调用。(2)通过bean传递模型状态。(3)表示层中需要

7、绑定到列表的数据由关系数据集传输。(4)每个数据库表对应一个数据库实体类，Hibernate完成映射。(Hibernate需要支持一些跨数据库或跨表的操作(如复杂的联邦查询)。(6)表示层和控制层禁止任何SQL语句。SSH框架介绍：视图层和控制器层由Structs框架实现，模型层的功能由Spring完成。Hibernate实现用于持久化该层，DAO模式用于该层。Structs使用MVC模型将页面呈现与业务逻辑分离，从而实现页面呈现与业务逻辑之间的低耦合。当作为表示层的页面需要改变时，只需要修改特定的页面，而不影响业务逻辑Bean等。同样，当业务逻辑需要改变时，只需要修改相应的Java程序。使用

8、Spring可以使用IoC技术来减少业务逻辑中不同类之间的相互依赖。如果甲类因为需要函数F而调用乙类，甲类通常需要引用乙类，所以甲类依赖于乙类，也就是说，甲类不能在乙类不存在时使用。在IoC中，类a只调用一个实现函数f接口的类，它可以是类b或类c，由Spring的XML配置文件决定。这样，a类不再依赖b类，耦合度降低，可重用性提高。使用Hibernate可以将业务逻辑与数据持久化分开，也就是说，将数据存储到数据库中的操作。在业务逻辑中，您只需要将数据放入值对象，然后将它交给Hibernate，或者从Hibernate获取值对象。至于是使用DB2、甲骨文、MySQL还是SQL Server，如何

9、执行操作与具体的系统无关，只需要在Hibernate的相关XML文件中根据具体的系统进行配置。现在，让我们通过下表来看看架构如何满足系统的关键质量属性要求。6.3.2系统架构分析与设计，1质量场景1)性能场景：在系统高峰期，确保每个登录的客户所做的选择和查询的响应时间在5s以内，如果需要等待，给出友好的提示。该系统能够以最快的速度响应500个用户的操作。2)安全场景：防止非法用户试图绕过应用服务器，直接连接到数据库服务器的端口，防止非法窃取注册用户的个人信息；在短时间内屏蔽掉大量无意义的访问，以防止被普通用户挤出和使用。确保系统数据的机密性和完整性。易用性场景：在这个系统中，用户希望尽快取消一

10、个操作，以最大限度地减少错误的影响，并且取消发生在1秒钟内；如果你想让人们具备基本的计算机操作知识，你可以根据良好的界面设计快速学习如何使用它，并让熟练的用户使用快捷键。可用性场景：在正常工作时间，系统必须具有极高的可用性，以确保最低的故障概率。如果出现故障，系统有相应的处理机制。数据持久层的体系结构分析在数据持久层，我们用Hibernate来处理。让我们看看如何通过Hibernate来满足系统的质量属性要求。从图中可以看出，Hibernate通过配置文件和映射文件实现了与数据库和对象关系映射(ORM)的交互。通过这种机制，java程序中的对象被自动持久化到关系数据库中，对持久化对象的更改将反

11、映在数据库中。配置文件主要用于配置数据库连接的各种参数和定义数据映射文件，通常采用hibernate.cfg.xml或perties的形式。XML映射配置文件是数据库中表的数据映射文件，通常以*.hbm.xml的形式出现.让我们更详细地看看Hibernate运行时架构方案。这个方案从底层的JDBC/JTA应用编程接口中抽象出应用层，并让Hibernate处理这些细节。Hibernate架构方案，图中的每个对象定义如下：SessionFactory是一个单一数据库映射关系的编译内存映像，它是线程安全的(不可变的)。它是生成会话的工厂，并且它需要连接提供者。此对象可以为数

12、据提供可选的L2缓存，这些数据可以在进程或集群级别的事务之间重用。会话表示一个单线程对象，它在应用程序和持久存储层之间进行互操作，并且该对象的生命周期很短。它隐藏了JDBC的联系，也是交易的工厂。它将保存持久对象所需的(1级)缓存，当遍历对象图或根据持久标识查找对象时将使用该缓存。持久对象及其集合是具有持久状态和业务功能的单线程对象，它们的生命周期很短。这些对象可能是普通的JavaBeans/POJO，但唯一特别的是它们只与一个会话相关联。一旦该会话关闭，这些对象将脱离持久状态，因此它们可以由应用程序的任何层自由使用。(例如，它用作数据传输对象来处理表示层。)暂时和分离的对象及其集合；那些当前

13、不与会话相关联的持久类实例。它们可能是在被应用程序实例化后没有被持久化的对象。也有可能他们会话的实例化已经关闭，留下了持久对象。事务(可选)应用程序用于指定原子操作单元范围内的对象，该对象是单线程的，并且生命周期较短。它通过抽象将应用程序与底层的JDBC、JTA和CORBA事务隔离开来。在某些情况下，一个会话可能包含多个事务对象。尽管使用或不使用该对象是可选的，但是无论是使用底层的应用编程接口还是事务对象，都有必要打开和关闭事务边界。ConnectionProvider(可选)为JDBC连接生成一个工厂(也充当连接池)。它通过抽象将应用程序与底层数据源或驱动管理器隔离开来。它仅由开发人员用于扩

14、展/实现，并不向应用程序公开。事务工厂(可选)生成事务对象实例的工厂。它仅由开发人员用于扩展/实现，并不向应用程序公开。扩展接口Hibernate提供了许多可选的扩展接口，您可以通过实现它们来定制持久层的行为。Hibernate符合质量属性要求。(1) Hibernate本质上是为数据操作打包JDBC。由于Hibernate优化了JDBC调用，并尽可能多地使用优化和最高效的JDBC调用，因此性能令人满意。同时，当应用程序需要在关联之间导航时，Hibernate会获取关联对象，Hibernate提供的持久数据缓存机制也对提高系统性能起到了很大的作用。(Hibernate提供的悲观锁/乐观锁机制可

15、以在多个用户执行并发操作时保持数据库中数据的一致性和完整性，从而避免数据库中数据的破坏。(3)易用性当操作票据信息时，用户受Hibernate支持。3业务逻辑层架构设计作为系统的关键部分，业务逻辑层在实现系统的灵活性方面起着决定性的作用。在系统的业务逻辑层的体系结构层，采用了MVC模式。下面简要介绍了MVC模式的优点：(1)客户端表示层和业务逻辑层完全分离；(2)高效可靠的交易处理；(3)良好的可用性、安全性和MVC模式访问流程；MVC模式在这个系统中得到了应用：当一个客户端使用网络浏览器发送一个HTTP请求时，它通常涉及到表单数据的发送。Servlet接收并解析这些数据。Servlet扮演控

16、制器的角色，处理您的请求，并且通常向模型(通常是数据库)发送请求。处理结果通常以JavaBean的形式打包。视图是JSP，JSP的唯一工作是生成页面，显示模型的视图和进一步操作所需的所有控件。当页面返回到浏览器并显示为视图时，用户提出的进一步请求将以相同的方式处理。由于JSP继承了J2EE良好的可用性和安全性，它为实现系统的关键质量属性奠定了基础。在MVC模式中，视图不再是经典模型的观察者。当模型改变时，视图确实间接地从控制器接收到相当于通知的东西，并且控制器可以向视图发送bean，以便视图可以获得模型的状态。因此，视图只需要在向浏览器返回HTTP响应时更新状态信息。只有当页面被创建并返回时，创建一个视图并组合模型状态才有意义。这使得改进系统成为可能。只有在执行相应的操作时，系统才会得到关联的对象，视图不会直接注册到模型中来接收状态信息，这大大提高了系统的安全性。业务逻辑层框架：业务逻辑层架构分析：业务逻辑层架构是以前MVC模式的变体，继承了MVC模式的优点。同时，在我们的架构中，它将表示层和业务层完全分开。在业务逻辑层，我们使用Sprin