功能强大的对象建模工具——UML.ppt

信息系统分析、设计与开发方法 第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的背景 u三个最流行的面向对象方法。OMT方法、Booch和 OOSE。 uBooch 方法，比较适合于系统的设计和构造，然 而在分析方面比较弱。 uOMT方法，分析是OMT方法的强项，但在设计方面 就比较弱。 uOOSE方法，在行为分析方面强大，但是在其它方 面比较弱。 5.1.1 UML的背景 5.1 UML的历史 UML的发展历程 5.1.2 UML发发展 5.1 UML的历史 UML特点 面向对象。UML支持面向对象技术的主要概念，提供了一 批基本的模型元素的表示图形和方法，能简洁明了地表达 面向对象的各种概念。 可视化，表示能力强。通过UML的模型图能清晰地表示系 统的逻辑模型和实现模型。 独立于过程。UML是系统建模语言，独立于开发过程。 独立于程序设计语言。用UML建立的软件系统模型可以用 Java、VC+、SmalltaIk等任何一种面向对象的程序设计 来实现。 易于掌握使用。UML图形结构清晰，建模简洁明了，容易 掌握使用。 5.1.3 UML特点 5.1 UML的历史 UML的面向对象分析设计过程 运用UML进行面向对象的系统分析设计，其过程通 常由以下3个部份组成： u识别系统的用例和角色 u进行系统分析，并抽取类 u进行系统设计，并设计类及其行为 5.1.3 UML特点 5.1 UML的历史 UML的定义包括UML语义和UML表示法两个部分。 uUML语义 描述基于UML的精确元模型定义。 uUML表示法 定义UML符号的表示法。 UML由图和元模型组成，图是语法，元模型是语义。UML主 要包括三个基本构造块：事物（Things）、关系（ Relationships）和图 （Diagrams）。 UML通过三类图形建立系统模型：用例（Use Case）图、 静态结构图（对象类图、对象图、组件图、配置图）和动 态行为图（顺序图、协同图、状态图、活动图），这些图 可以从不同的抽象角度实现系统的可视化。 5.1.4 UML的组组成 统一建模语言（Unified Modeling Language，简 称UML）是用来对软件密集系统进行可视化建 模的一种语言。UML为面向对象开发系统的产 品进行说明、可视化、和编制文档的一种标准 语言。 5.2 UML包含的内容 关系是事物间的连接，在面向对象建模中，有4个很 重要的关系：类属（Generalization）关系，关联 （Association）关系，依赖（Dependency）关系， 实现（Realization）关系。 u类属关系（Generalization） 类属关系描述了一般事物与该事物的特殊种类之 间的关系。表示为类与类之间的继承关系，接口与 接口之间的继承，类对接口的实现关系。类属关系 用一条带空心的三角箭头的实线表示，箭先尾端连 接子类，箭头指向父类。 5.2.1 关系 5.2 UML包含的内容 UML中，对类属关系有 三个要求： (1) 特殊元素与一般元 素完全一致。关联/属性 /操作 (2) 特殊元素应包含额 外信息。 (3) 特殊元素的应用场 合包含一般元素的应用 场合。 类属关系图 5.2 UML包含的内容 5.2.1 关系 u关联关系（ Association ） 关联关系表示两个类之间存在某种语义上的联 系。它是一种结构关系，规定了一种事物的对象 可以与另一种事物的对象相连。 5.2 UML包含的内容 5.2.1 关系 u关联关系又分为两种类型： 聚合关系(Aggregation Relationship) 聚合关系，聚合关系表示对象实例之间的整体与部分的 关系，它代表了“has-a”（拥有）关系，即作为整体的对象拥 有作为部分的对象，整体与部分可以分开。 组合关系（Composition Relationship） 组合关系，组合关系是聚合关系的一种特殊形式。在组合 关系中，整体和部分之间有着很强所有关系和一致的生命周 期，即整体与部分是不可以分开的。 5.2 UML包含的内容 5.2.1 关系 聚合关系 组合关系 5.2 UML包含的内容 5.2.1 关系 u依赖关系（Dependency） 依赖关系描述了两个模型元素间的语义联 系，其中一个模型元素的变化一定会影响另 一个模型元素（这种影响不必是可逆的）。 例如, 有两个类Customer类和Account类，如果 Customer类的变化引起Account类的变化，则说明 Account类依赖于Customer类。 5.2 UML包含的内容 5.2.1 关系 u依赖关系有如下三种情况： (1) Customer类是Account类的一个成员变量； (2) Customer类是Account类方法当中的一个参数； (3) Customer类向Account类发送消息，从而影响 Account类发生变化； 5.2 UML包含的内容 5.2.1 关系 u实现关系（Realize Relationship） 实现关系是用来规定接口和实现接口的类或者构建结构的 关系，接口是操作的集合，而这些操作就用于规定类或者构 建的一种服务。使用带空心箭头的虚线表示，箭头指向接口 。 5.2 UML包含的内容 5.2.1 关系 视与图 对于一个软件系统来说，往往需要从不同的角 度对它进行描述，由此产生了视的概念，不同的视 描述了软件系统的不同方面。Kruchten 提出了一个 “4+1”视图模型，从5个不同的视角描述软件体系 结构，它们是逻辑视、过程视、实现视、配置视和 用例视。每一个视图只关心系统的一个侧面，5个试 图结合在一起才能反映系统的软件体系结构的全部 内容。 5.2.2 视图视图 5.2 UML包含的内容 “4+1”视图模型 5.2 UML包含的内容 5.2.2 视图视图 用例（Use Case）模型主要用来描述客户的需求，即用 户希望系统所具备的功能。用例图是用例模型的图形表示， 能够准确地表达参与者以系统的交互情况和系统所提供的服 务。Use Case图是后续的系统分析与设计工作依据。 用例图主要包括3各部分： u用例（Usesr CAse）。 u参与者（Actor） u关系 5.2.3 用例图图 5.2 UML包含的内容 参与者（Actor）又可以称为活动者，是用户作 用于系统的一个（Role）。活动者有自己的目标， 通过与系统的交换到达目标。参与者是对系统边界 之外的对象的描述。参与者可以是人，也可以是外 部系统或其它设备。 图书管理员是图书借阅管理系统的用户， 是该 系统的外部实体，而用例借书管理、还书管理是系 统应该提供的功能，如下图所示。 5.2.3 用例图图-参与者 5.2 UML包含的内容 图书借阅管理系统图书管理员用例图 5.2 UML包含的内容 5.2.3 用例图图-参与者 用例是对系统行为的动态描述，促进设计人员、 开发人员与用户的沟通，正确理解用户的需求；规划 系统与外部实体的界限，是系统设计的起点，是类、 对象、操作的来源。 用例是从系统外部可见的行为，是系统为某一个 或几个参与者（Actor）提供的一段完整的服务。 5.2.3 用例图图-用例 5.2 UML包含的内容 用例之间关系有包含(include)、扩展(extend)和类 属(generalization)三种关系。 包含(include) 包含关系：使用包含（Inclusion）用例来封装一组跨 越多个用例的相似动作，以便多个基（Base）用例复 用。基用例控制与包含用例的关系，以及被包含用例 的事件流是否会插入到基用例的事件流中。 5.2.3 用例图图-用例关系 5.2 UML包含的内容 基于用例的需求分析 (1)用例图是用来收集和描述用户需求的最好方法，明确系 统的功能和参与者。需要强调的是用例图只是描述了系统 做什么，而没有规定怎么做的。为了明确系统是怎么做的 ，为此引入了用例事件流描述。 (2)用例事件流描述完成用例规定行为所需要的事件。 (3)用例及用例事件流描述是系统动态建模依据之一，强调 用例事件流描述的重要性。 5.2.3 用例图图-用例事件流描述 5.2 UML包含的内容 用例事件流描述 用例图只能告诉我们系统应具有的功能及参与者，而没 有说明用例的执行过程。因此，必须必须借助事件流描述用 例的行为。 (1) 用例什么时候开始，如何开始 (2) 用例什么时候结束，如何结束 (3) 用例和参与者之间有什么样的交互作用 (4) 用例需要什么数据 (5) 用例的标准的事件顺序 (6) 替代的或例外的事件流的描述 5.2.3 用例图图-用例事件流描述 5.2 UML包含的内容 在一般信息系统中，总是存在着维护某某信息的功能， 如果将它作为一个用例，那新建、编辑以及修改都要在用例 详述中描述，过于复杂；如果分成新建用例、编辑用例和删 除用例，则划分太细。这时包含关系可以用来理清关系，如 下图所示。 5.2.3 用例图图-用例包含关系 5.2 UML包含的内容 扩展(extend) 扩展关系：将基用例中一段相对独立并且可选的 动作，用扩展（Extension）用例加以封装，再让 它从基用例中声明的扩展点（Extension Point） 上进行扩展，从而使基用例行为更简练和目标更集 中。扩展用例为基用例添加新的行为。 5.2.3 用例图图-用例扩扩展关系 5.2 UML包含的内容 系统中允许用户对查询的结果进行导出、打印。对于查询而 言，能不能导出、打印查询都是一样的，导出、打印是不可 见的。导出、打印和查询相对独立，而且为查询添加了新行 为。因此可以采用扩展关系来描述,如下图所示。 5.2.3 用例图图-用例扩扩展关系 5.2 UML包含的内容 类属(generalization) 类属关系：用例间的类属关系如同类间的类属关 系。子用例继承父用例的行为和含义，但表现出更 特别的行为。子用例可以使用父用例的一段行为， 也可以重载它。父用例通常是抽象的。 5.2.3 用例图图-用例类类属关系 5.2 UML包含的内容 例如，在办公自动化系统中，可能存在许多需要部 门领导审批的事情，虽然审批的内容和类型不一样 ，但是领导审批的流程是很相似的，这时可以做成 类属关系表示，如下图所示。 5.2.3 用例图图-用例类类属关系 5.2 UML包含的内容 类图（class）是面向对象模型的最基本的模型 元素，描述对象模型的静态结构方面。表达了类集 、接口集、协作以及它们之间的关系，是定义其它 图的基础。 类图的组成部分包括： u类（class） u接口（Interface） u协作（Collaboration） u依赖（Dependency）、类属（Generalization） 、实现（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）表达对象之间 的交互，是描述一组对象如何合作完成每一个行为 的模型化工具。交互图主要用于对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包含的内容 l顺序图 顺序图是交互图的一种，重点在于完成每个行 为的对象类和这些对象类之间所传递的消息的时间 顺序。 顺序图将交互关系表示为一个二维图。纵向是 时间轴，时间沿竖线向下延伸。横向轴代表了在协 作中各独立对象的类元角色。类元角色用生命线表 示。当对象存在时，角色用一条虚线表示，当对象 的过程处于激活状态时，生命线是一个双道线。消 息用从一个对象的生命线到另一个对象生命线的箭 头表示。箭头以时间顺序在图中从上到下排列。 5.2 UML包含的内容 5.2.5 交互作用图图 5.2 UML包含的内容 l顺序图 l 协作图 协作图用于显示组件及其交互关系的空间组织 结构，它并不侧重于交互的顺序。 协作图显示了交互中各个对象之间的组织交互关系 以及对象彼此之间的链接。 协作图具有以下用途： u通过描述对象之间消息的移动情况来反映具体的 脚本 u显示对象及其交互关系的空间组织结构，而非交 互的顺序 5.2 UML包含的内容 5.2.5 交互作用图图 l协作图 5.2 UML包含的内容 5.2.5 交互作用图图 l顺序图与协作图 协作图和顺序图都表示出了对象间的交互作用， 但是它们侧重点不同。顺序图清楚地表示了交互作用 中的时间顺序，但没有明确表示对象间的关系。协作 图清楚地表示了对象间的关系，但时间顺序必须从顺 序图获得。顺序图常常用于表示方案，而协作图用于 过程的详细设计。另外，时序图与协作图在语义上是 等价的，因而它们可以相互转换而不损失信息。 5.2 UML包含的内容 5.2.5 交互作用图图 活动图主要是一个流图，描述从活动到活动的 控制流。 活动图的基本元素有：动作状态（或活动状态 ）、动作流、泳道和对象流。此外初始状态、终结 状态、判定（分支）、合并、分叉和联结也是常用 的图形元素和符号。 5.2.6 活动图动图 5.2 UML包含的内容 动作状态（Action State）描述了一个原子的 或不可中断的动作或操作的执行。也就是说动作状 态不能被分解。 例如：图书管理系统中的的借书与还书状态是 动作状态。 5.2.6 活动图动图 -动动作状态态 5.2 UML包含的内容 活动状态是非原子的，动作或操作的执行是可 以分解并能够中断的。通常活动状态需要很长的时 间才能完成。可以把活动状态看做是一个组合，该 组合的控制流由其它的活动状态和动作状态构成。 活动状态和动作状态的UML符号没有区别，但是活动 状态可以有入口、出口动作和子状态的规定。入口 动作和出口动作分别是进入或离开状态时要执行的 动作。 5.2.6 活动图动图 -活动动状态态 5.2 UML包含的内容 例如，制定计划和添加图书是活动状态。 5.2.6 活动图动图 -活动动状态态 5.2 UML包含的内容 动作流（Action Flow）是一个实体的不同动作 状态之间的联系，说明状态之间的控制流。在活动 图中动作流用实箭线表示，箭线从一个动作状态出 发指向另一个动作状态。动作流可以是无条件的， 也可以是有条件的。 5.2.6 活动图动图 -动动作流 5.2 UML包含的内容 活动图描述了从一个活动到另一个活动的控 制流，但没有说明该项活动由谁来完成。泳道解 决了这个问题。 泳道（Swimlanes）说明活动由谁来完成， 将活动图的逻辑描述与顺序图、合作图的责任描 述结合起来。 泳道用矩形框来表示，属于某个泳道的活动 置于该矩形框中，将对象名置于举行框的顶部， 表示泳道中的活动由该对象负责。 5.2.6 活动图动图 -泳道 5.2 UML包含的内容 5.2.6 活动图动图 -泳道 5.2 UML包含的内容 活动图能表示对象的值流和控制流。对象流状 态表示活动中输入或输出的对象，它是动作状态或 者活动状态与对象之间的依赖关系，表示动作使用 对象或动作对对象的影响。对输出值而言，虚线箭 头从活动指向对象流状态。对输入值而言，虚线箭 头从对象流状态指向活动。如果活动有多个输出值 或后继控制流，那么箭头背向分叉符号。同样，多 输入箭头指向结合符号。 5.2.6 活动图动图 -对对象流 5.2 UML包含的内容 对象流中的对象有以下特点： u一个对象可以由多个动作操作。 u一个动作输出的对象可以作为另一个动作输入的对象。 u在活动图中，同一个对象可以多次出现，它的每一次出现 表面该对象正处于对象生存期的不同时间点。 5.2.6 活动图动图 -对对象流 5.2 UML包含的内容 5.2.6 活动图动图 -对对象流 5.2 UML包含的内容 状态图（Statechart Diagrams）为系统的动态方面建 模的5个图之一。它主要是一个流图，描述从状态到状态的 流，包括一个特定对象的所有可能状态及引起状态跃迁的事 件。活动图是状态图的特例。状态图用来模拟对象按事件排 序的行为。 状态图描述一个实体基于事件反应的动态行为，显示了 该实体如何根据当前所处的状态对不同的时间做出反应的。 状态图中定义的状态有初始状态(一个状态图只能有一个初 始状态)、最终状态(可以有一个或多个最终状态)、中间状 态和复合状态 5.2.7 状态图态图 5.2 UML包含的内容 5.2.7 状态图态图 5.2 UML包含的内容 l组件图 组件图的主要目的是显示系统组件间的结构关系。在 UML 1.1 中，一个组件表现了实施项目，如文件和可运行的 程序。随着时间的推移及UML的连续版本发布，UML 组件已 经失去了最初的绝大部分含义。 组件图包含元素： (1) 组件。 (2) 接口。 (3) 依赖关系、类属关系、关联关系和实现关系。 5.2 UML包含的内容 5.2.8 组组件图图与配置图图 组件图 5.2 UML包含的内容 l配置图 配置图描述系统硬件的物理拓扑结构以及在此结 构上执行的软件。配置图可以显示计算结点的拓扑 结构和通信路径、结点上运行的软件构件、软件构 件包含的逻辑单元(对象、类)等。配置图常常用于 帮助理解分布式系统。 配置图中通常包含两种元素：节点(Node)和关 联关系(Association)。 5.2 UML包含的内容 5.2.8 组组件图图与配置图图 配置图的作用，通常用来描述3种 系统的静态配置视图： (1) 为嵌入式系统建模 (2) 为客户/服务器系统建模 (3) 为完全的分布式系统建模。 配置图 5.2 UML包含的内容 OMG的采纳和大公司的支持把它推上了实际上的工 业标准的地位，使它拥有越来越多的用户。它被广 泛地用于应用领域和多种类型的系统建模，如管理 信息系统、通信与控制系统、嵌入式实时系统、分 布式系统、系统软件等。近几年还被运用于软件再 工程、质量管理、过程管理、配置管理等方面。而 且它的应用不仅仅限于计算机软件，还可用于非软 件系统，例如硬件设计、业务处理流程、企业或事 业单位的结构与行为建模。 5.3 UML的应应用领领域 UML的应用领域 项目背景 某建筑设计研究院目前正处于快速发展的关键 时刻，设计院承接项目的种类、数量和规模都在不 断的增长，经常面临不同类型的项目和规模大小不 一项目并发进行的问题，以往手工的管理模式已经 很难对项目进行有效的管理。因此，迫切需要开发 综合项目管理信息系统。 5.4 案例分析 5.4.1 概述 建筑设计院组织结构图 5.4 案例分析 系统设计目标和开发策略 设计目标 引入先进的流程管理思想和协同设计思想，通过搭建 综合项目管理信息系统业务流程服务平台，改善与优化建筑 设计院核心业务流程和基础业务流程，藉此提升设计质量和 工作效率，缩短项目设计周期，快速地响应业主的设计需求 、增加设计过程的透明度、增强各设计专业内部、各设计专 业之间和部门间的数据共享及信息交互能力，提升项目负责 人对设计过程的控制能力与协调能力。 5.4 案例分析 5.4.1 概述 开发策略 系统设计目标和开发策略 业务流程图 用户业务流程描述 结构化方法 功能模块划分 面向对象方法 系统分析、设计 原型法 软件系统原型 5.4 案例分析 根据对设计院实际业务情况的详细调研和分析，将总体业 务划分核心业务和基础业务，其中核心业务为设计项目管理 业务。基础业务为经营合同管理业务、办公管理业务、人力 资源管理业务、资料图档管理业务和资产管理业务，各管理 业务之间的关系如图所示 综合项目管理系统框架 5.4 案例分析 5.4.1 概述 综合项目管理系统框架 5.4 案例分析 员工培训与考核系统 员工培训与考核系统是某建筑设计院综合项目管理 信息系统的一个子系统。目的实现企业员工培训管 理系统化、规范化。系统分为培训计划管理、员工 培训申请、培训申请审批、培训考核管理、员工资 质管理、信息查询与报表打印等功能。系统开发采 用Struts2.0+Spring2.5+Hibernate3.2+DWR2.0框架 技术，服务器是JBoss服务器，数据库管理系统采用 Microsoft SQL Server2000。 以员工培训与考核系统为例，结合理论教学讲解面向对象 的系统分析。 5.4 案例分析 5.4.1 概述 培 训 业 务 流 程 分 析 业务流程分析 5.4 案例分析 员工 考核 业务 流程 分析 行政办 员工考核表(含产值完成 情况) 部门意见 员 工填写考核表 部 门 院长意见院 长归档处理 员工考核档 案 业务流程分析 5.4 案例分析 识别系统参与者 （1）行政办总师办 （2）员工 （3）部门 （4）院长 用例图(1) 5.4 案例分析 5.4.2 系统统用例分析 识别培训用例： （1）员工或部门提出培训申请; （2）由行政办总师办编制计划和临时培训申请; （3）培训申请和计划提交到院长进行审批; （4）审批通过后，由行政办总师办组织培训并进行培训 记录生成培训记录表; （5）行政办总师办对培训结果进行汇总和进行培训资质 信息的维护; 用例图(2) 5.4 案例分析 5.4.2 系统统用例分析 维护培训 记录表 维护培训 资质信息 编制临时 申请表 审 批 申请培训 编制计表 培训用例 用例图(3) 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.后置条件 如果这个用例成功，在系统中建立并存储申请表格， 如果必要还要删除或修改申请记录。否则，系统的状 态没有变化。 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-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）提供培训申请相关信息。 （2）查询培训申请的表格信息。(E-2) （3）删除培训申请表的相关信息。 （4）从系统中删除该申请信息。 S-4:查看申请 （1）提供培训申请相关信息。 （2）查询培训申请的表格信息。(E-2) 2.3. 替代流 E-1:若系统中已经存在该申请，则用户可以选择该基流 的起始点，重新进行选择。或者取消登录，用例结束。 E-2:若系统中不存在该申请信息，系统提示信息，该用 例终止。 事件流描述(5) 5.4 案例分析 5.4.2 系统统用例分析 实体类 本系统中员工、部门、院长、行政办总师办、培训申请 表、培训记录表、员工资质信息表、培训计划表、考核表和 档案表都是实体类，需要存储在数据库中。 其中用户类是员工、部门、院长、行政办、总师办的父 类，为对象的持久存储提供了支持，它的子类必须实现从数 据库文件中读写对象属性的操作。 培训申请表类、培训记录表类、员工资质信息表类、培训 计划表类、考核表类、档案表类与用户类是关联关系。 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:审核 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) 系 统 架 构 图 用户界 面 业务数 据组织 和表示 MVC架构 模式的控 制层 控制业务 逻辑层与 表现层的 交互 业务逻辑 的实现 层 数据访问 对象 与持久化 对象交互 通过实体- 关系映射 O-R Mapping 由数据库 表得来对 象 存放数据 视图层Web层Service层DAO层持久化对象数据服务层 Struts2Spring2.5+Hibernate3.2 5.4 案例分析 系统特点是采用上述开发模型，不仅实现了视图、控制器 与模型的彻底分离，而且还实现了业务逻辑层与持久层的 分离。这样无论前端如何变化，模型层只需很少的改动， 并且数据库的变