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