第5章-功能强大的对象建模工具——UML.ppt

1、信息系统分析、设计与开发方法,第5章 功能强大的对象建模 工具UML,5.1 UM L历史 5.2 UM L包含的内容 5.3 UM L应用领域 5.4 案例分析,目录,5.1 UML的历史,统一建模语言（Unified Modeling Language，简称UML）是用来对软件密集系统进行可视化建模的一种语言。UML为面向对象开发系统的产品进行说明、可视化、和编制文档的一种标准语言。,5.1 UML的历史,UML的背景 三个最流行的面向对象方法。OMT方法、Booch和OOSE。 Booch 方法，比较适合于系统的设计和构造，然而在分析方面比较弱。 OMT方法，分析是OMT方法的强项，但在

2、设计方面就比较弱。 OOSE方法，在行为分析方面强大，但是在其它方面比较弱。,5.1.1 UML的背景,5.1 UML的历史,UML的发展历程,5.1.2 UML发展,5.1 UML的历史,UML特点 面向对象。UML支持面向对象技术的主要概念，提供了一批基本的模型元素的表示图形和方法，能简洁明了地表达面向对象的各种概念。 可视化，表示能力强。通过UML的模型图能清晰地表示系统的逻辑模型和实现模型。 独立于过程。UML是系统建模语言，独立于开发过程。 独立于程序设计语言。用UML建立的软件系统模型可以用Java、VC+、SmalltaIk等任何一种面向对象的程序设计来实现。 易于掌握使用。UM

3、L图形结构清晰，建模简洁明了，容易掌握使用。,5.1.3 UML特点,5.1 UML的历史,UML的面向对象分析设计过程 运用UML进行面向对象的系统分析设计，其过程通常由以下3个部份组成： 识别系统的用例和角色 进行系统分析，并抽取类 进行系统设计，并设计类及其行为,5.1.3 UML特点,5.1 UML的历史,UML的定义包括UML语义和UML表示法两个部分。 UML语义 描述基于UML的精确元模型定义。 UML表示法 定义UML符号的表示法。 UML由图和元模型组成，图是语法，元模型是语义。UML主要包括三个基本构造块：事物（Things）、关系（Relationships）和图 （Di

4、agrams）。 UML通过三类图形建立系统模型：用例（Use Case）图、静态结构图（对象类图、对象图、组件图、配置图）和动态行为图（顺序图、协同图、状态图、活动图），这些图可以从不同的抽象角度实现系统的可视化。,5.1.4 UML的组成,统一建模语言（Unified Modeling Language，简称UML）是用来对软件密集系统进行可视化建模的一种语言。UML为面向对象开发系统的产品进行说明、可视化、和编制文档的一种标准语言。,5.2 UML包含的内容,关系是事物间的连接，在面向对象建模中，有4个很重要的关系：类属（Generalization）关系，关联（Association）

5、关系，依赖（Dependency）关系，实现（Realization）关系。 类属关系（Generalization） 类属关系描述了一般事物与该事物的特殊种类之间的关系。表示为类与类之间的继承关系，接口与接口之间的继承，类对接口的实现关系。类属关系用一条带空心的三角箭头的实线表示，箭先尾端连接子类，箭头指向父类。,5.2.1 关系,5.2 UML包含的内容,UML中，对类属关系有三个要求： (1) 特殊元素与一般元素完全一致。关联/属性/操作 (2) 特殊元素应包含额外信息。 (3) 特殊元素的应用场合包含一般元素的应用场合。,类属关系图,5.2 UML包含的内容,5.2.1 关系,关联关系

6、（ Association ） 关联关系表示两个类之间存在某种语义上的联系。它是一种结构关系，规定了一种事物的对象可以与另一种事物的对象相连。,5.2 UML包含的内容,5.2.1 关系,关联关系又分为两种类型： 聚合关系(Aggregation Relationship) 聚合关系，聚合关系表示对象实例之间的整体与部分的关系，它代表了“has-a”（拥有）关系，即作为整体的对象拥有作为部分的对象，整体与部分可以分开。 组合关系（Composition Relationship） 组合关系，组合关系是聚合关系的一种特殊形式。在组合关系中，整体和部分之间有着很强所有关系和一致的生命周期，即整体与

7、部分是不可以分开的。,5.2 UML包含的内容,5.2.1 关系,聚合关系,组合关系,5.2 UML包含的内容,5.2.1 关系,依赖关系（Dependency） 依赖关系描述了两个模型元素间的语义联系，其中一个模型元素的变化一定会影响另一个模型元素（这种影响不必是可逆的）。 例如, 有两个类Customer类和Account类，如果Customer类的变化引起Account类的变化，则说明Account类依赖于Customer类。,5.2 UML包含的内容,5.2.1 关系,依赖关系有如下三种情况： (1) Customer类是Account类的一个成员变量； (2) Customer类是A

8、ccount类方法当中的一个参数； (3) Customer类向Account类发送消息，从而影响 Account类发生变化；,5.2 UML包含的内容,5.2.1 关系,实现关系（Realize Relationship） 实现关系是用来规定接口和实现接口的类或者构建结构的关系，接口是操作的集合，而这些操作就用于规定类或者构建的一种服务。使用带空心箭头的虚线表示，箭头指向接口。,5.2 UML包含的内容,5.2.1 关系,视与图 对于一个软件系统来说，往往需要从不同的角度对它进行描述，由此产生了视的概念，不同的视描述了软件系统的不同方面。Kruchten 提出了一个“4+1”视图模型，从5个

9、不同的视角描述软件体系结构，它们是逻辑视、过程视、实现视、配置视和用例视。每一个视图只关心系统的一个侧面，5个试图结合在一起才能反映系统的软件体系结构的全部内容。,5.2.2 视图,5.2 UML包含的内容,“4+1”视图模型,5.2 UML包含的内容,5.2.2 视图,用例（Use Case）模型主要用来描述客户的需求，即用户希望系统所具备的功能。用例图是用例模型的图形表示，能够准确地表达参与者以系统的交互情况和系统所提供的服务。Use Case图是后续的系统分析与设计工作依据。 用例图主要包括3各部分： 用例（Usesr CAse）。 参与者（Actor） 关系,5.2.3 用例图,5.2

10、 UML包含的内容,参与者（Actor）又可以称为活动者，是用户作用于系统的一个（Role）。活动者有自己的目标，通过与系统的交换到达目标。参与者是对系统边界之外的对象的描述。参与者可以是人，也可以是外部系统或其它设备。 图书管理员是图书借阅管理系统的用户， 是该系统的外部实体，而用例借书管理、还书管理是系统应该提供的功能，如下图所示。,5.2.3 用例图-参与者,5.2 UML包含的内容,图书借阅管理系统图书管理员用例图,5.2 UML包含的内容,5.2.3 用例图-参与者,用例是对系统行为的动态描述，促进设计人员、开发人员与用户的沟通，正确理解用户的需求；规划系统与外部实体的界限，是系统设

11、计的起点，是类、对象、操作的来源。 用例是从系统外部可见的行为，是系统为某一个或几个参与者（Actor）提供的一段完整的服务。,5.2.3 用例图-用例,5.2 UML包含的内容,用例之间关系有包含(include)、扩展(extend)和类属(generalization)三种关系。 包含(include) 包含关系：使用包含（Inclusion）用例来封装一组跨越多个用例的相似动作，以便多个基（Base）用例复用。基用例控制与包含用例的关系，以及被包含用例的事件流是否会插入到基用例的事件流中。,5.2.3 用例图-用例关系,5.2 UML包含的内容,基于用例的需求分析 (1)用例图是用来收

12、集和描述用户需求的最好方法，明确系统的功能和参与者。需要强调的是用例图只是描述了系统做什么，而没有规定怎么做的。为了明确系统是怎么做的，为此引入了用例事件流描述。 (2)用例事件流描述完成用例规定行为所需要的事件。 (3)用例及用例事件流描述是系统动态建模依据之一，强调用例事件流描述的重要性。,5.2.3 用例图-用例事件流描述,5.2 UML包含的内容,用例事件流描述 用例图只能告诉我们系统应具有的功能及参与者，而没有说明用例的执行过程。因此，必须必须借助事件流描述用例的行为。 (1) 用例什么时候开始，如何开始 (2) 用例什么时候结束，如何结束 (3) 用例和参与者之间有什么样的交互作用

13、 (4) 用例需要什么数据 (5) 用例的标准的事件顺序 (6) 替代的或例外的事件流的描述,5.2.3 用例图-用例事件流描述,5.2 UML包含的内容,在一般信息系统中，总是存在着维护某某信息的功能，如果将它作为一个用例，那新建、编辑以及修改都要在用例详述中描述，过于复杂；如果分成新建用例、编辑用例和删除用例，则划分太细。这时包含关系可以用来理清关系，如下图所示。,5.2.3 用例图-用例包含关系,5.2 UML包含的内容,扩展(extend) 扩展关系：将基用例中一段相对独立并且可选的动作，用扩展（Extension）用例加以封装，再让它从基用例中声明的扩展点（Extension Poi

14、nt）上进行扩展，从而使基用例行为更简练和目标更集中。扩展用例为基用例添加新的行为。,5.2.3 用例图-用例扩展关系,5.2 UML包含的内容,系统中允许用户对查询的结果进行导出、打印。对于查询而言，能不能导出、打印查询都是一样的，导出、打印是不可见的。导出、打印和查询相对独立，而且为查询添加了新行为。因此可以采用扩展关系来描述,如下图所示。,5.2.3 用例图-用例扩展关系,5.2 UML包含的内容,类属(generalization) 类属关系：用例间的类属关系如同类间的类属关系。子用例继承父用例的行为和含义，但表现出更特别的行为。子用例可以使用父用例的一段行为，也可以重载它。父用例通常

15、是抽象的。,5.2.3 用例图-用例类属关系,5.2 UML包含的内容,例如，在办公自动化系统中，可能存在许多需要部门领导审批的事情，虽然审批的内容和类型不一样，但是领导审批的流程是很相似的，这时可以做成类属关系表示，如下图所示。,5.2.3 用例图-用例类属关系,5.2 UML包含的内容,类图（class）是面向对象模型的最基本的模型元素，描述对象模型的静态结构方面。表达了类集、接口集、协作以及它们之间的关系，是定义其它图的基础。 类图的组成部分包括： 类（class） 接口（Interface） 协作（Collaboration） 依赖（Dependency）、类属（Generalizat

16、ion）、实现（Realization）、关联（Association）,5.2.4 类图与对象图,5.2 UML包含的内容,5.2 UML包含的内容,5.2.4 类图与对象图,对象图（Object Diagram）是类图的一个实例。对象图表示在某一时刻系统对象的状态、对象之间联系的状态以及对象行为静态方面的状态。 对象图的表示方法和类的表示方法相同。对象之间的连接（Link）是类之间的关联关系的实例。对象图中通常含有：对象、连接。,5.2 UML包含的内容,5.2.4 类图与对象图,交互图（Interaction Diagram）表达对象之间的交互，是描述一组对象如何合作完成每一个行为的模型

17、化工具。交互图主要用于对Use Case中的控制流的建模。一般情况下一个交互图表达一个Use Case的行为，表示了该Use Case中若干个实例对象和对象之间所传递的消息。 UML1.X的交互图有两种即顺序图（Sequence Diagram）和协作图（Collaboration Diagram）。在UML2.0中，协作图改称为通信图（Communication Diagram），并增加了交互概观图（Interaction Overview Diagram）和计时图（Timing Diagram）。,5.2.5 交互作用图,5.2 UML包含的内容,顺序图 顺序图是交互图的一种，重点在于完成

18、每个行为的对象类和这些对象类之间所传递的消息的时间顺序。 顺序图将交互关系表示为一个二维图。纵向是时间轴，时间沿竖线向下延伸。横向轴代表了在协作中各独立对象的类元角色。类元角色用生命线表示。当对象存在时，角色用一条虚线表示，当对象的过程处于激活状态时，生命线是一个双道线。消息用从一个对象的生命线到另一个对象生命线的箭头表示。箭头以时间顺序在图中从上到下排列。,5.2 UML包含的内容,5.2.5 交互作用图,5.2 UML包含的内容,顺序图,协作图 协作图用于显示组件及其交互关系的空间组织结构，它并不侧重于交互的顺序。 协作图显示了交互中各个对象之间的组织交互关系以及对象彼此之间的链接。 协作

19、图具有以下用途： 通过描述对象之间消息的移动情况来反映具体的脚本 显示对象及其交互关系的空间组织结构，而非交互的顺序,5.2 UML包含的内容,5.2.5 交互作用图,协作图,5.2 UML包含的内容,5.2.5 交互作用图,顺序图与协作图 协作图和顺序图都表示出了对象间的交互作用，但是它们侧重点不同。顺序图清楚地表示了交互作用中的时间顺序，但没有明确表示对象间的关系。协作图清楚地表示了对象间的关系，但时间顺序必须从顺序图获得。顺序图常常用于表示方案，而协作图用于过程的详细设计。另外，时序图与协作图在语义上是等价的，因而它们可以相互转换而不损失信息。,5.2 UML包含的内容,5.2.5 交互

20、作用图,活动图主要是一个流图，描述从活动到活动的控制流。 活动图的基本元素有：动作状态（或活动状态）、动作流、泳道和对象流。此外初始状态、终结状态、判定（分支）、合并、分叉和联结也是常用的图形元素和符号。,5.2.6 活动图,5.2 UML包含的内容,动作状态（Action State）描述了一个原子的或不可中断的动作或操作的执行。也就是说动作状态不能被分解。 例如：图书管理系统中的的借书与还书状态是动作状态。,5.2.6 活动图-动作状态,5.2 UML包含的内容,活动状态是非原子的，动作或操作的执行是可以分解并能够中断的。通常活动状态需要很长的时间才能完成。可以把活动状态看做是一个组合，该

21、组合的控制流由其它的活动状态和动作状态构成。活动状态和动作状态的UML符号没有区别，但是活动状态可以有入口、出口动作和子状态的规定。入口动作和出口动作分别是进入或离开状态时要执行的动作。,5.2.6 活动图-活动状态,5.2 UML包含的内容,例如，制定计划和添加图书是活动状态。,5.2.6 活动图-活动状态,5.2 UML包含的内容,动作流（Action Flow）是一个实体的不同动作状态之间的联系，说明状态之间的控制流。在活动图中动作流用实箭线表示，箭线从一个动作状态出发指向另一个动作状态。动作流可以是无条件的，也可以是有条件的。,5.2.6 活动图-动作流,5.2 UML包含的内容,活动

22、图描述了从一个活动到另一个活动的控制流，但没有说明该项活动由谁来完成。泳道解决了这个问题。 泳道（Swimlanes）说明活动由谁来完成，将活动图的逻辑描述与顺序图、合作图的责任描述结合起来。 泳道用矩形框来表示，属于某个泳道的活动置于该矩形框中，将对象名置于举行框的顶部，表示泳道中的活动由该对象负责。,5.2.6 活动图-泳道,5.2 UML包含的内容,5.2.6 活动图-泳道,5.2 UML包含的内容,活动图能表示对象的值流和控制流。对象流状态表示活动中输入或输出的对象，它是动作状态或者活动状态与对象之间的依赖关系，表示动作使用对象或动作对对象的影响。对输出值而言，虚线箭头从活动指向对象流

23、状态。对输入值而言，虚线箭头从对象流状态指向活动。如果活动有多个输出值或后继控制流，那么箭头背向分叉符号。同样，多输入箭头指向结合符号。,5.2.6 活动图-对象流,5.2 UML包含的内容,对象流中的对象有以下特点： 一个对象可以由多个动作操作。 一个动作输出的对象可以作为另一个动作输入的对象。 在活动图中，同一个对象可以多次出现，它的每一次出现表面该对象正处于对象生存期的不同时间点。,5.2.6 活动图-对象流,5.2 UML包含的内容,5.2.6 活动图-对象流,5.2 UML包含的内容,状态图（Statechart Diagrams）为系统的动态方面建模的5个图之一。它主要是一个流图，

24、描述从状态到状态的流，包括一个特定对象的所有可能状态及引起状态跃迁的事件。活动图是状态图的特例。状态图用来模拟对象按事件排序的行为。 状态图描述一个实体基于事件反应的动态行为，显示了该实体如何根据当前所处的状态对不同的时间做出反应的。 状态图中定义的状态有初始状态(一个状态图只能有一个初始状态)、最终状态(可以有一个或多个最终状态)、中间状态和复合状态,5.2.7 状态图,5.2 UML包含的内容,5.2.7 状态图,5.2 UML包含的内容,组件图 组件图的主要目的是显示系统组件间的结构关系。在 UML 1.1 中，一个组件表现了实施项目，如文件和可运行的程序。随着时间的推移及UML的连续版

25、本发布，UML 组件已经失去了最初的绝大部分含义。 组件图包含元素： (1) 组件。 (2) 接口。 (3) 依赖关系、类属关系、关联关系和实现关系。,5.2 UML包含的内容,5.2.8 组件图与配置图,组件图,5.2 UML包含的内容,配置图 配置图描述系统硬件的物理拓扑结构以及在此结构上执行的软件。配置图可以显示计算结点的拓扑结构和通信路径、结点上运行的软件构件、软件构件包含的逻辑单元(对象、类)等。配置图常常用于帮助理解分布式系统。 配置图中通常包含两种元素：节点(Node)和关联关系(Association)。,5.2 UML包含的内容,5.2.8 组件图与配置图,配置图的作用，通常

26、用来描述3种系统的静态配置视图： (1) 为嵌入式系统建模 (2) 为客户/服务器系统建模 (3) 为完全的分布式系统建模。,配置图,5.2 UML包含的内容,OMG的采纳和大公司的支持把它推上了实际上的工业标准的地位，使它拥有越来越多的用户。它被广泛地用于应用领域和多种类型的系统建模，如管理信息系统、通信与控制系统、嵌入式实时系统、分布式系统、系统软件等。近几年还被运用于软件再工程、质量管理、过程管理、配置管理等方面。而且它的应用不仅仅限于计算机软件，还可用于非软件系统，例如硬件设计、业务处理流程、企业或事业单位的结构与行为建模。,5.3 UML的应用领域,UML的应用领域,项目背景 某建筑

27、设计研究院目前正处于快速发展的关键时刻，设计院承接项目的种类、数量和规模都在不断的增长，经常面临不同类型的项目和规模大小不一项目并发进行的问题，以往手工的管理模式已经很难对项目进行有效的管理。因此，迫切需要开发综合项目管理信息系统。,5.4 案例分析,5.4.1 概述,建筑设计院组织结构图,5.4 案例分析,系统设计目标和开发策略,设计目标 引入先进的流程管理思想和协同设计思想，通过搭建综合项目管理信息系统业务流程服务平台，改善与优化建筑设计院核心业务流程和基础业务流程，藉此提升设计质量和工作效率，缩短项目设计周期，快速地响应业主的设计需求、增加设计过程的透明度、增强各设计专业内部、各设计专业

28、之间和部门间的数据共享及信息交互能力，提升项目负责人对设计过程的控制能力与协调能力。,5.4 案例分析,5.4.1 概述,开发策略,系统设计目标和开发策略,用户业务流程描述,功能模块划分,系统分析、设计,软件系统原型,5.4 案例分析,根据对设计院实际业务情况的详细调研和分析，将总体业务划分核心业务和基础业务，其中核心业务为设计项目管理业务。基础业务为经营合同管理业务、办公管理业务、人力资源管理业务、资料图档管理业务和资产管理业务，各管理业务之间的关系如图所示,综合项目管理系统框架,5.4 案例分析,5.4.1 概述,综合项目管理系统框架,5.4 案例分析,员工培训与考核系统,员工培训与考核系

29、统是某建筑设计院综合项目管理信息系统的一个子系统。目的实现企业员工培训管理系统化、规范化。系统分为培训计划管理、员工培训申请、培训申请审批、培训考核管理、员工资质管理、信息查询与报表打印等功能。系统开发采用Struts2.0+Spring2.5+Hibernate3.2+DWR2.0框架技术，服务器是JBoss服务器，数据库管理系统采用Microsoft SQL Server2000。,以员工培训与考核系统为例，结合理论教学讲解面向对象的系统分析。,5.4 案例分析,5.4.1 概述,培 训 业 务 流 程 分 析,业务流程分析,5.4 案例分析,员工 考核 业务 流程 分析,员工考核表(含产

30、值完成情况),部门意见,填写考核表,院长意见,归档处理,员工考核档案,业务流程分析,5.4 案例分析,识别系统参与者,（1）行政办总师办 （2）员工 （3）部门 （4）院长,用例图(1),5.4 案例分析,5.4.2 系统用例分析,识别培训用例：,（1）员工或部门提出培训申请; （2）由行政办总师办编制计划和临时培训申请; （3）培训申请和计划提交到院长进行审批; （4）审批通过后，由行政办总师办组织培训并进行培训 记录生成培训记录表; （5）行政办总师办对培训结果进行汇总和进行培训资质 信息的维护;,用例图(2),5.4 案例分析,5.4.2 系统用例分析,编制计表,培训用例,用例图(3),

31、5.4 案例分析,5.4.2 系统用例分析,培训用例图,用例图(4),5.4 案例分析,5.4.2 系统用例分析,用例图(5),考核用例识别： （1）由员工填写考核表; （2）提交到部门，部门或院长对考核表填写意见; （3）由行政办总师办对考核进行归档处理;,填写考核表,填写意见,归档,考核用例,5.4 案例分析,5.4.2 系统用例分析,用例图(6),考核用例图,填写意见,员工,部门,填写考核表,行政办,总师办,填写意见,院长,归档,5.4 案例分析,5.4.2 系统用例分析,培训用例事件流描述： 1.申请培训 1.1.前置条件 在这个用例开始前，用户或部门必须登录到系统中。 1.2.后置条

32、件 如果这个用例成功，在系统中建立并存储申请表格， 如果必要还要删除或修改申请记录。否则，系统的状 态没有变化。 1.3扩充点 没有。,事件流描述(1),5.4 案例分析,5.4.2 系统用例分析,2 事件流 2.1 基流 当员工或部门填写培训申请表时，用例启动。 （1）如果员工或部门选择“创建”，则执行分支流S-1： 创建申请。 （2）如果对已提交，但为经过行政办处理的申请，选 择活动是“修改”，可以执行分支流S-2：修改培训申请表.,事件流描述(2),5.4 案例分析,5.4.2 系统用例分析,2.1 基流 （3）如果对已提交，但为经过行政办处理的申请，选择活动是“删除”，可以执行分支流S

33、-3：删除培训申请表 （4）如果对已提交，选择活动是“查看”，可以执行分支流S-4：查看培训申请表,事件流描述(3),5.4 案例分析,5.4.2 系统用例分析,2.2. 分支流 S-1:创建申请 （1）员工或部门登录系统后，点击进入系统。 （2）找到培训模块，并进入培训申请。 （3）填写培训申请的相关内容。 （4）填写好表格后，提交或保存。(E-1) S-2:修改申请 （1）提供培训申请相关信息。 （2）查询培训申请的表格信息。（E-2） （3）修改培训申请表的相关信息。 （4）从系统中修改该申请信息,事件流描述(4),5.4 案例分析,5.4.2 系统用例分析,S-3:删除申请 （1）提供

34、培训申请相关信息。 （2）查询培训申请的表格信息。(E-2) （3）删除培训申请表的相关信息。 （4）从系统中删除该申请信息。 S-4:查看申请 （1）提供培训申请相关信息。 （2）查询培训申请的表格信息。(E-2) 2.3. 替代流 E-1:若系统中已经存在该申请，则用户可以选择该基流的起始点，重新进行选择。或者取消登录，用例结束。 E-2:若系统中不存在该申请信息，系统提示信息，该用例终止。,事件流描述(5),5.4 案例分析,5.4.2 系统用例分析,实体类 本系统中员工、部门、院长、行政办总师办、培训申请表、培训记录表、员工资质信息表、培训计划表、考核表和档案表都是实体类，需要存储在数

35、据库中。 其中用户类是员工、部门、院长、行政办、总师办的父类，为对象的持久存储提供了支持，它的子类必须实现从数据库文件中读写对象属性的操作。 培训申请表类、培训记录表类、员工资质信息表类、培训计划表类、考核表类、档案表类与用户类是关联关系。,5.4 案例分析,5.4.3 系统静态模型,类 图,5.4 案例分析,5.4.3 系统静态模型,用 户 界 面 类 图,5.4 案例分析,5.4.3 系统静态模型,培训界面类和实体类关系类图,5.4 案例分析,5.4.3 系统静态模型,培训 界面 类和 实体 类关 系类 图,5.4 案例分析,5.4.4 系统动态模型,培 训 审 批 通 过 顺 序 图,5

36、:审核,5.4 案例分析,5.4.4 系统动态模型,培 训 审 批 未 通 过 的 顺 序 图,5:审核,5.4 案例分析,5.4.4 系统动态模型,培训活动图,5.4 案例分析,5.4.4 系统动态模型,本系统基于B/S软件开发模式，采用基于Java的面向对象开发技术，将业务逻辑组件、数据访问组件运行以JavaBean的形式运行于中间层即Web逻辑处理层， 底层数据处理则采用数据管理安全性稳定性较强的SQL Sever 2000。在数据库管理层也是通过Hibernate完成对后台数据库服务的访问，整个逻辑处理过程如图,5.4 案例分析,5.4.5 系统架构,5.4 案例分析,5.4.5 系统架构,Struts2.0+Spring2.5+Hibernate3.2(1),系 统 架 构 图,5.4 案例分析,系统特点是采用上述开发模型，不仅实现了视图、控制器与模型的彻底分离，而且还实现了业务逻辑层与持久层的分离。这样无论前端如何变化，模型层只需很少的改动，并且数据库的变化也不会对前端有所影响，大大提高了系统的可复用性。而且由于不同层之间耦合度小，有利于团队成员并行工作，大大提高了开发效率。,Strut