第4章 UML建模技术.ppt

1、现代软件工程,主讲: 王伦友,Email: Cell Phone:13065012951,第4章 UML建模技术,清华大学出版社 张晓龙,13.变老是人生的必修课. 14.变成熟是选修课. 15.以锻炼为本，学会健康. 16.以适应为本，学会生存.,献给正在努力以及打算努力的你们 心态，决定你人生,http:/ UML建模技术,4.1 面向对象建模及UML简介 4.2 用例视图 4.3 动态模型图 4.4 静态模型图 4.5 本章小结,4.1 面向对象建模及UML简介,4.1.1 面向对象建模,建模是为了能够更好地理解正在开发的系统。所谓模型，就为了理解事物而对事物作出的一种抽象模拟，是对事物

2、的一种无歧义的书面描述。 通常，模型由一组图示符号和组织这些符号的规则组成，利用它们来定义和描述问题域中的术语和概念。 更进一步讲，模型是一种思考工具，利用这种工具可以把知识规范地表示出来。模型可以帮助思考问题、定义术语、在选择术语时作出适当的假设，并且可以保持定义和假设的一致性。,4.1 面向对象建模及UML简介,通过建模，可以达到四个个目的： 有助于按照实际情况或按照所需要的样式对系统进行可视化 能够规约系统的结构或行为 给出指导构造系统的模板 对做出的决策进行文档化,4.1.1 面向对象建模,4.1 面向对象建模及UML简介,统一建模语言UML是一种标准的建模语言，是用为面向对象开发系统

3、的产品进行说明、可视化和编制文档的方法。 它主要以图形的方式对系统进行分析、设计。 软件工程领域在1995年至1997年取得了前所未有的进展，其成果超过软件工程领域过去15年来的成就总和。其中最重要的、具有划时代重大意义的成果之一就是UML的出现。,4.1.2 UML简介,4.1 面向对象建模及UML简介,从第一个UML语言标准1.0于1997年推出以来，软件产业界支持UML的各种工具和平台也被迅速推出，UML及其平台已被广泛应用于软件开发的各个阶段，包括分析、设计、测实现、配织置和维护过程。 由于UML已由国际对象管理组OMG（Object Management Group）标准化为软件建模

4、的统一语言，因此在工业界、学术界已被广泛承认与采用。 在世界范围内，UML是面向对象技术领域内占主导地位的标准建模语言。,4.1.2 UML简介,4.1 面向对象建模及UML简介,4.1.2 UML简介,图4.1 UML建模结构图,4.2 用例视图,用例视图中可以包含若干个用例（Use Case）。用例图用来表示系统能够提供的功能（用法），一个用例是系统功能（用法）的一个通用描述。 用例视图是其它视图的核心和基础，其它视图的构造和发展依赖于用例图中所描述的内容。 因为系统的最终目标是提供用例视图中描述的功能，同时附带一些非功能的性质，因此用例视图影响着其它的视图。同时，用例视图还可用于测试系统

5、是否满足用户的需求和验证系统的有效性。,4.2 用例视图,在UML中，用例用椭圆来表示，它用来记录用户或外界环境从头到尾使用系统的一系列事件。 用户被称为“执行者”（Actor），执行者可以是人，也可以是另一个系统。它与当前的系统进行交互，向系统提供输入或从系统中获得输出，用一个人形（Stickman）来表示。 用例图显示了用例和执行者、用例与用例之间以及执行者与执行者之间的关系。关系描述模型元素之间的语义连接；在UML中，关系使用实线来表示，实线可以有箭头，也可以没有箭头。,4.2 用例视图,（1）执行者 执行者是指在系统外部与系统交互的人或其它系统，他以某种方式参与系统内用例的执行。 当划

6、分了系统的范围并明确了系统边界后，从系统应用的角度出发，找寻那些与系统进行信息交换（包括数据信息和控制信息）的外部事物，包括系统使用人员、硬件设备及外部系统，来确定执行者。我们 可以从以下角度来寻找和确定执行者：1）使用系统主要功能的人。2）需要借助于系统完成日常工作的人。,4.2 用例视图,3）维护、管理系统，保证系统正常工作的人。 4）系统是否使用使用外部资源。 5）系统和已经存在的系统是否存在交互。例如在学生成绩管理系统中，除了查询成绩 的学生之外，还有以下执行者： 1）系统管理员对系统的更新和维护。 2）老师对学生成绩查询和更新数据,4.2 用例视图,（2）用例用例代表的是一个完整的功

7、能，是执行者想要系统 做的事情；它是特定执行者对系统的“使用情况”。 用例一般具有以下的特征 1 用例总是从执行者的角度来编写的 用例所代表的功能必须由执行者激活，然后才能执行。 2 用例总是从执行者的角度来编写的 由于用例描述的是用户的功能需求，只能从用户的角度 出发才能真正了解用户需要什么样的功能。,4.2 用例视图,3 用例具有完全性 用例是一个完整的描述。虽然在编程实现时，一个用例 可以被分解成为多个小用例（函数或方法），用例之间 可以互相调用执行，但是只有最终产生了返回给执行者 的结果值，才能说用例执行完毕。,4.2 用例视图,(3)用例图内元素的关系一般将执行者和用例之间的关系称为

8、通信，而用例 与用例之间可以存在的关系分为泛化（eneralization） 包含（Include）、扩展（Extend）和使用（Use）四 种。 另外执行者与执行者之间也可以存在泛化关系。,4.2 用例视图,(1)泛化关系UML中的泛化关系就是通常所说的继承关系，表示几 个元素某些共性。它是通用元素和具体元素之间的一种 分类关系。在UML中，用一端为空心三角形的连线表示泛 化关系，三角形的顶角紧挨着通用元素。例如在买票系统中，个人购买和团体定购都是买票 的特例，肯有一些共同的特征，将这些共同的特征抽象 出来，定义一个“买票”的基本用例（基用例），个人 购买和团体定购从“买票”的基用例继承。可

9、以用图4.3所 示的用例图来表示。,4.2 用例视图,图4.3 用例的泛化关系,图4.4 执行者的泛化关系,4.2 用例视图,如果多个执行者之间存在很多共性，就可以使用泛 来分解共性行为。比如学生成绩管理系统中，涉及用户 包括系统管理员（Admin）和学生（Student），他们都 是用例图中的执行者，他们的主要特征相似，都具有姓 名、账号等信息，所以可以抽象出“基”执行者。用例 图可以表示为图4.4的形式。,4.2 用例视图,（2） 包含关系 包含关系指的是两个用例之间的关系，其中一个用例 （基用例）的行为包含了另一个用例的功能。如果两个 以上的用例有相同的功能，则可以将这个功能分解到另 一

10、个用例中，基用例则包含了分解出来的新用例的功 能。例如在学生成绩管理系统中，学生和系统管理员都 需要先登录然后才能进行相关的操作。这时就可以分解 一个登录用例出来，让学生和系统管理员都包含它。在 UML中使用表示包含关系，如图4.5所示。,4.2 用例视图,包含关系是比较特殊的依赖关系，它们比一般的依 赖关系多了一些语义。在包含关系中，箭头的指向是从 基本用例到包含用例，也就是说，基本用例依赖于包含 用例。,图4.5 学生成绩管理系统用例图中的包含关系,4.2 用例视图,（3）扩展关系 扩展关系的基本含义与泛化关系类似，但对扩展用例有 更多的限制，即基用例必须具有“扩展点”。而扩展用 例只能在

11、扩展点上增加新的行为和含义。也就是说，扩 展关系允许一个用例（可选）扩展另一个用例（基用 例）提供的功能。与包含关系一样，扩展关系也是依赖 关系，而包含关系是特殊的依赖关系，这两个关系都是 把相同功能分离到另一个用例中。,4.2 用例视图,在UML中使用表示扩展关系，箭头的方向 是从扩展用例到基用例。例如，在自动售货机系统中，“售货”是一个基本的 用例，如果顾客购买罐装饮料，售货功能可以顺利完成。 但是，如果顾客要购买用纸杯装的散装饮料，则不能执行 该用例提供的常规动作，而要做些改动。我们可以修改售 货用例，使之既能提供售罐装饮料的常规动作又能提供售 散装饮料的非常规动作。我们可以把常规动作放

12、在售货用 例中，把非常规动作放置于售散装饮料用例中，这两个用 例之间的关系就是扩展关系，如图4.6所示。,4.2 用例视图,图4.6 自动售货系统用例中的扩展关系,4.2 用例视图,（4）使用关系使用关系也是一种继承关系。在使用关系中，一个 用例使用另一个用例的功能和行为。在UML中，用例之 间的使用关系的图形描述和用例的继承关系一样，用一 条带空心箭头的实线连接一个子用例和一个父用例，实 线上方标明构造型表明两个用例是使用关系。 如图4.7所示：,4.2 用例视图,图中表明，子用例在使用父用例的功能和行 为。如果有多个子用例使用同一个父用例，表明 这些子用例在共享父用例的功能和行为。,图4.

13、7 用例之间的使用关系,4.3 动态模型图,用例图显示系统应该做什么，活动图则指明了系统将 如何实现它的目标。活动图显示链接在一起的高级动作， 代表系统中发生的操作流程。活动图在面向对象系统的不 同组件之间建模工作流和并发过程行为。活动图用来描述 采取何种动作、做什么（对象状态改变）、何时发生（动 作序列）以及在何处发生（泳道）。在UML中，活动图可以用作下述目的： 描述一个操作执行过程中所完成的工作（动作），这是活动图最常见的用途。,4.3.1活动图,描述对象内部的工作。 显示如何执行一组相关的动作以及这些动作如何影响它们周围的对象。 显示用例的实例如何执行动作以及如何改变对象状态。 说明一

14、次商务活动中的人（角色）工作流组织和对象是如何工作的。 （1）活动图的基本要素活动图的基本元素包括活动、迁移、起始活动、终 止活动、条件判定以及并发活动，如图4.9所示。,4.3 动态模型图,4.3 动态模型图,图4.9 活动图的基本元素,（2）泳道活动图告诉人们发生了什么，但是不能告诉该项活动 由谁来完成。对于程序设计而言，活动图没有指出每个活 动是由哪个类负责。而对于建模而言，活动图没有表达出 某些活动是由哪些人或哪些部门负责。虽然可以在每个活 动上标记出其所负责的类或者部门，但难免带出诸多麻烦 。泳道的引用解决了这些问题。泳道将活动图划分为若干 组，每一组指定给负责这组活动的业务组织，即

15、对象。在 活动图中泳道区分了负责活动的对象，它明确地表示了哪 些活动是由哪些对象进行的。在包含泳道的活动图中每个 活动只能明确地属于一个泳道。,4.3 动态模型图,（3）活动图建模步骤 建模活动图时，可以按照以下五步来进行： 1)标识需要活动图的用例。 2)建模每一个用例的主路径。 3)建模每一个用例的从路径。 4)添加泳道来标识活动的事务分区。 5)改进高层活动并添加到更多活动图。,4.3 动态模型图,（4）活动图中的并发与同步活动 活动图中，一个动作（或活动）状态的迁移可以分劈成 两个或多个导致并行动作（或活动）状态的迁移；若干 个来自并行动作（或活动）的迁移也可以接合成一个迁 移。值得注

16、意的是，一个动作（或活动）状态迁移分劈 后，在接合之前并行迁移上的活动必须全部完成。也就 是说，动作状态的同步分劈和同步接合要成对的出现。 在一个同步分劈与同步接合对中，可以嵌套另一个同步 分劈与同步合并对。图4.14中就出现了同步分劈与同步 接合对。活动图的基本元素包括活动、迁移、起始活动 、终止活动、条件判定以及并发活动，如图4.9所示。,4.3 动态模型图,4.3.2 顺序图,4.3 动态模型图,顺序图用来描述对象之间动态的交互关系，着重体现对象间消息传递的时间顺序，是一种强调消息的时序交互图。它由执行者、对象、消息、生命线和激活期组成。在UML中对象表示为一个矩形，其中对象名称标有下标

17、线；消息在顺序图中由有标记的箭头表示；生命线由虚线表示，激活期由薄薄的矩形表示。,4.3 动态模型图,(1)对象 顺序图中所包含的每个对象用一个对象框表示，对象名需 带下划线。 对象名后面可以跟“：”及其创建该对象的类名。 对象一般位于顺序图的顶部。 交互频繁的对象尽量靠拢，可以使画面清晰。 对整个交互活动进行初始化的对象放在图的最左边。 在交互过程中产生的对象应放在产生该对象的时间点处,4.3 动态模型图,过程中对象改变了属性值、状态或角色，则在生命线上该对象的改变点处画上该对象的图符副本，并注明有关的变更。 （2）生命线 对象框下面的一条垂直虚线，称为该对象的生命线，表示该对象的生存时间。

18、 生命线从该对象创建开始到释放，其生存期多长，虚线就有多长。 生命线表示该对象的生命处在休眠期，等待消息的激活,4.3 动态模型图,（3）消息 在顺序图中，对象之间消息的传递用两个对象生命线之间 的消息箭头线表示，用来指出该对象执行期间的时序。 在顺序图中，不同的消息表示对象间不同类型的通信 简单消息表示消息类型未知或与类型无关，或是一个同步消息的返回 同步消息表示发送对象必须等接收对象完成消息的处理后才能继续执行 异步消息表示发送对象在消息发送后继续执行，而不等待接收对象的返回消息,4.3 动态模型图,传送延迟可用倾斜的箭头表示，意思是消息发送后需经历一段延迟时间才被接收,（4）激活期 对象

19、生命线上的一个细长方形框，表示该对象的激活时间 段。 当一个休眠的对象接收到一个消息时，该对象开始活动，称为激活 激活展示了某时间点哪个对象能够响应或发送消息，执行动作或活动 一个激活的对象要么执行自己的代码，要么在等待另一个对象的返回,4.3 动态模型图,接垂直坐标从上到下的次序读顺序图，可以观察到随时间的前进消息通信的顺序,激活期长方形的上端与动作的开始时间齐平，下端与动作的完成时间齐平 激活期外，对象处在休眠期，什么事都不做，但它仍然存在，等待消息的激活,4.3 动态模型图,图4.13 学生成绩查询顺序图,4.3 动态模型图,协作图由执行者、对象、连接和消息基本元素组成。 （1）对象与顺

20、序图一样，协作图中的对象也用短式标记，即在一个方框内标识对象名。对象一般在协作图中担当一个具体的角色，可以把对象名写为对象的角色名。如果不标明角色名，则说明该对象角色为匿名对象。 （2）连接在协作图中，对象之间的连接用连接两个对象的实线表示。在连接上可以标明角色名。连接角色名用来说明连接路径，规定在交互中对象之间连接的角色类型。,4.3.3 协作图,4.3 动态模型图,（3）消息 协作图画成对象图，图中的消息箭头表示对象之间的消息 流，消息上标以序号，说明消息发送的顺序，还可以指明 条件、重复和回送值等。一个协作图从一个引起整个系统 交互或协作的消息开始，例如调用某一个操作。,图4.14是一个

21、蜂窝电话的协作图.,4.3 动态模型图,图4.14 蜂窝电话的协作图,4.3 动态模型图,4.3.4 状态图,状态图是众多开发人员都十分熟悉甚至经常使用的工具，它描述了一个特定对象的所有可能状态以及由于各种事件的发生而引起的状态之间的转移。大多数面向对象技术都使用状态图来描述一个对象在其生命周期中的行为，尤其是通过给单个类绘制图以表示该类单个对象的生存期行为。状态图适合于描述跨越多个用例的单个对象的行为，而不适合描述多个对象之间的行为协作。状态图由表示状态的结点和表示状态之间转换的带箭头的直线组成。若干个状态由一条或者多条转换箭头连接，状态的转换由事件触发。模型元素的行为可以由状态图,4.3

22、动态模型图,中的一条通路表示，沿着此通路执行一系列动作。在UML中，状态图由状态、迁移、初始状态、终止 状态、条件判定等元素组成。,4.3 动态模型图,图4.15 图书对象的状态图,4.4 静态模型图,4.4.1 类图,类图是描述类、接口以及它们之间关系的图，它显示了系统中各个类的静态结构，是一种静态模型。类图根据系统中的类以及各个类的关系描述系统的静态视图。可以用某种面向对象的语言实现类图中的类。类图是面向对象系统建模中最常用和最基本的图之一，其它许多图，如状态图、协作图、组件图和配置图等都是在类图的基础上进一步描述了系统其它方面的特性。类图中可以包含了七个模型元素，它们分别是：类、接口、依

23、赖关系、泛化关系、关联关系和实现关系等模型元素。在类图中也可以包含注释、约束、包或子系统。,4.4 静态模型图,4.4.1 类图,（1）寻找类从用例图中寻找类，一般是从用例的事件流开始，查处事件流中的名词来获得类，在事件流中，名词可以分为角色、类、类属性和表达式四种类型；也可以检查顺序图和协作图中的对象，通过对象的共性来寻找类，顺序图和协作图中每一个对象都要映射到相应的类。当然，可能有些类无法通过以上方法找到。类可以分为实体类（Entity）边界类（Boundary）和控制类（Control）三种类型。,4.4 静态模型图,（2）类表示在UML中一个类用一个矩形方框表示，它被分成三个区域。最上

24、面的区域是类名，中间的区域是类的属性，下面的区域是类的操作。类图就是由这些类和表明类之间如何关联的连线组成。例如在一个学校的任意一个学生都具有学号和姓名两个属性，以及改变学号和姓名的操作，这样就可以建立如图4.17所示的Student类。,4.4 静态模型图,图4.17 学生类的类图,4.4 静态模型图,（3）类关系 类图由类及类与类之间的关系组成。在类图中，常用的关系主要有关联、聚集、泛化、依赖和实现等四种关系关联。 1）关联 表示类的实例之间存在的某种关系，定义了对象之间的关系准则，在应用程序创建和使用关系时，关联提供了维护关系完整性的规则，通常用一个无向线段表示。只要在类与类之间存在连接

25、关系就可以用普通关联表示。普通关联的图示符号是连接两个类之间的直线。通常，关联是双向的，可在一个方向上为关联起一个名字，在另一个方向上起另一个名字。,4.4 静态模型图,在表示关联的直线两端可以写上重数（Multiplicity），用“”分隔开的区间，它表示该类有多少个对象与对方的一个对象连接。具体示例如图4.18所示。,图4.18 普通关联示例图,4.4 静态模型图,表4.2 重数的表示方法,重数的表示方法通常如表4.2所示。,4.4 静态模型图,图4.19 共享聚集示意图,2）聚集聚集是一种特殊类型的关联，它指出类间的“整体与部分”关系。聚集是关联的特例，它可以有重数、角色、限制符号等。聚

26、集关联有共享聚集和组合聚集两种。,4.4 静态模型图,组合聚集是指整体拥有它的部分，它具有强的物主身份，表示事物的整体与部分关系较强的情况。实心菱形表示组合聚集，它画在代表事物整体的一端部分生存在整体中不可分离，它与整体一起存在或消亡。整体的重数必须是0或1，而部分重数可以是任意的。例如，菜单和按钮不能脱离窗口对象而独立存在，如果组合被破坏，则其中的成员对象不会继续存在，如图4.20所示。,4.4 静态模型图,图4.20 组合聚集示意图,4.4 静态模型图,3）泛化UML中的泛化关系就是通常所说的继承关系，它是通用元素和具体元素之间的一种分类关系。具体元素完全拥有通用元素的信息，并且还可以附加

27、一些其它信息。在UML中，用一端为空心的三角形连线表示泛化关系，三角形的顶角紧挨着通用元素。泛化关系描述了“is a kind of”（是的一种）的关系。例如，彩色电视机和黑白电视机都是电视机的一种。在类中，通用元素被称超类或父类，而具体元素被称为子类，如图4.21所示,4.4 静态模型图,图4.21 泛化关系示意图,4.4 静态模型图,图4.20 组合聚集示意图,图4.22 依赖关系示意图,4.4 静态模型图,4）依赖依赖是两个模型元素之间的语义连接，一个独立的 模型元素，另一个是依赖的模型元素，独立元素的变化 会影响依赖的元素。例如，一个类把另一个类的对象作 为参数，一个类访问另一个类的全

28、局对象，或者一个类 调用另一个类的类操作。依赖用带箭头的虚线表示，位 于虚线箭头尾部的类（称为客户）依赖于箭头所指向的 类（称为供应者）。 5）实现实现是规格说明和其实现之间的关系，它将一种模 型元素与另一种模型元素连接起来，比如类与接口。,4.4 静态模型图,虽然实现关系意味着要具有接口一样的说明元素，但是 也可以用一个具体的实现元素来暗示它的说明必须被支 持。例如，实现关系可以用来表示类的一个优化形式和 一个简单低效的形式之间的关系。在UML中，实现关系 的符号与泛化关系的符号类似，用一条带指向接口的空 心三角箭头的虚线表示，如图4.23所示。,图4.23 实现关系示意图,4.4 静态模型

29、图,4.4.2 组件图,组件是系统中可以进行替换的物理部分，它不仅将系统如何实现包装起来，而且提供一组实现了的接口。所以它表示实现后的实体，也就是物理实体。组件是可以复用的单元，具有非常广泛的定义。每个组件可能包含很多类，实现很多接口。组件图描述了软件的各种组件和它们之间的依赖关系。组件图中通常包含组件、接口和依赖关系三种元素。每个组件实现一些接口，并使用另一些接口。如果组件间的依赖关系与接口有关，那么可以被具有同样接口的其它组件所替代。,4.4 静态模型图,4.4.2 组件图,例如，在选课系统中包括MainProgram类，People类、FormObject类、ControlObject类

30、、Student类、Rgistrar类、Course类和DataBase类。People类是Student类和Registrar类的基类，所以Student类和Registrar类依赖于People类。FormObject类和ControlObject类都和Course类相关，FormObject类和ControlObject类依赖Course类。 ControlObject类和DataBase类相关，ControlObject类依赖DataBase类，将每个类单独设计成一个组件。图4.24是网上选课系统的组件图。,4.4 静态模型图,图4.24 选课系统组件图,4.4 静态模型图,4.4.3

31、 配置图,一个面向对象系统模型包括软件和硬件两方面的模型，经过开发得到的软件系统的组件和重用模块，必须配置在某些硬件上予以执行。在UML中，硬件系统体系结构模型由配置图建模。配置图由结点和结点之间的联系组成，描述了处理器、设备和软件组件运行时的体系结构。在这个体系结构中可以看到某个结点上在执行哪个组件，在组件中实现了哪些逻辑元素（类、对象、协作等），完成了何种功能，最终可以从这些元素追踪到系统的需求分析（用例图）。组成配置图的基本元素有结点、组件、连接、依赖等。,4.4 静态模型图,配置图的最基本元素是结点。结点代表计算机资源，通常为处理理器或其它硬件设备。结点既可看作类型，也可看作实例。当结

32、点被看作实例时，结点名应有下划线。结点的图符用三维立方休表示，有短式图符和长式图符两种表示形式，如图4.25所示。,图4.25 结点的图符表示,4.4 静态模型图,配置图建模包括如下步骤： 1)确定结点 根据硬件设备和软件体系结构的功能要求统一考虑系统结点。 2)确定驻留组件 根据软件体系结构和系统功能要求分配相应组件驻留到结点上。 3)注明结点性质 用UML标准的或自定义的构造型描述结点的性质。 4)确定结点之间的联系 如果是简单通信联系，用关联连接描述结点之间的联系；,4.4 静态模型图,可在关联线上标明使用的通信协议或网络类型。 5)绘制配置图 对于一个复杂的大系统，可以采用打包的方式对系统的众多结点进行组织和分配，形成结构清晰具有层次的配置图,4.5 本章小结,统一建模语言UML是国际对象管理组织OMG批准的基于面向对象技术的标准建模语言。通常，使用UML的类图来建立对象模型，使用UML的状态图来建立动态模型，使用UML的用例图来建立功能模型。在UML中把用例图建立起来的系统模型称为用例模型。本章主要介绍了UML语言的各种图的画法，结合具体的例子对UML建模中常用的用例图、活动图、交互图、类图、状态图、组件图等作了比较详细的介绍，通过对本章的学习读者可以充分了解面向对象建模的基本方法。,