UML及软件建模 主讲人 ：李 唯 clx7000@163.com 1

第十二章 UML的总结 UML简介 UML的构成 其他 2

1、UML简介 UML（Unified Modeling Language,统一建模语言） 是一种可视化的建模语言，它能够让系统构造者用标准的 、易于理解的方式建立起能够表达他们设计思想的系统 蓝图，并且提供一种机制，以便于不同的人之间有效的共 享和交流设计成果。 (1)UML是一种语言 (2) UML是一种可视化的语言 (3) UML是一种可以用于详细描述的语言 (4) UML是一种构造语言

1.1、UML的用处 UML不是一门程序设计语言。但可以使用代码生成器工具将UML模型转换为多种程序设计语言代码，或使用反向生成器工具将程序源代码转换为UML。UML不是一种可用于定理证明的高度形式化的语言，这样的语言有很多种，但它们通用性较差，不易理解和使用。 UML是一种通用建模语言。对于一些专门领域，例如用户图形界面（GUI）设计、超大规模集成电路（VLSI）设计、基于规则的人工智能领域，使用专门的语言和工具可能会更适合些。 UML是一种离散的建模语言，不适合对诸如工程和物理学领域中的连续系统建模。它是一个综合的通用建模语言，适合对诸如由计算机软件、固件或数字逻辑构成的离散系统建模。

1.2、UML的核心组员

提出UML建议或进行UML标准修订工作的核心组员有下列人员： 数据存取公司：Tom Digre DHR 技术公司：Ed Seidewitz HP 公司：Martin Griss IBM 公司：Steve Brodsky, Steve Cook, Jos Warmer I—Lgix 公司：Eran Gery, David Harel ICON Computing 公司：Desmond D'Souza IntelliCorp and James Martin 公司：Conrad Bock, James Odell MCI 系统企业：Cris Kobryn, Joaquin Miller ObjecTime 公司：John Hogg, Bran Selic Oracle 公司：Guus Ramackers 铂技术公司：Dilhar Desilva Rational 软件公司：Grady Booch, Ed Eykholt, Ivar Jacobson, Gunnar Overgaard, Karin Palmkvist, James Rumbaugh SAP 公司：Oliver Wiegert SOFTEAM：Philippe Desfray Sterling 软件公司：John Cheesman, Keith Short Taskon 公司：Trygve Reenskaug

1.3、UML的历史

2、 UML的构成 作为一种建模语言,UML的定义包括UML语义和UML表示法两个部分

2.1、UML中的四种事物 1）结构事物 －－－ 类、接口、协作（它是一个交互，它是由一组共同工作以提供某协作行为的角色和其它元素构成的一个群体。）、用例、主动类（至少拥有一个进程或者线程，其元素的行为可以和其它元素的行为并发）、构件（如COM+和Java Bean）、节点。 2）行为事物 －－－ 交互、状态 （描述了一个对象或者一个交互在生命期内响应事件所经历的状态序列）。 3）分组事物 －－－ 包 。 Core Message: VM captures business process Key Point 1: Understanding business process is hard. If an architect and developers don’t understand the business process, which is the requirement for the system, you can’t build the proper system. Key Point 2: Use case is a technique to capture business process from user’s perspective. Use case is easy to understand because business process is defined in textual format, not in computer lingo. Example: Use the previous slide to describe use case. The system may handle order entry, inventory, and payroll processes. This particular use case only looks at order entry process. Conclusion: VM captures business process 4）辅助事物 －－－ 注解 4

2.2、UML中的四种关系 1）依赖 (Dependency)－－－ 两个事物间的语义关系 2）关联 (Association)－－－ 是一种结构关系，如聚合 3）泛化(Generalization)－－－ 一般/特殊关系 4）实现(Realization) －－－ 用在两种地方：接口和实现他们之间的类和构件之间；用例和实现他们的协作之间。 Core Message: VM is a communication tool. Key Point 1: Business analyst and domain experts define requirements. Software architects and developers build systems based on requirements. Typically, they have communication problems due to different use of terminology and different definition of concepts. Key Point 2: Take a look at the Rose development team. The team is distributed in three cities around the world; Sweden, Milwaukee, and Philadelphia. There is a common language - visual modeling. Key Point 3: With VM, there is a smooth transition between business domain and computer domain. Also, you can establish traceability from business domain to computer domain. Conclusion: VM is a communication tool. 5

2.3 UML的视图(View)和图( Diagram) UML中的各种组件和概念之间没有明显的划分界限，但为方便起见，我们用视图来划分这些概念和组件。视图只是表达系统某一方面特征的UML建模组件的子集。视图的划分带有一定的随意性，但我们希望这种看法仅仅是直觉上的。在每一类视图中使用一种或两种特定的图来可视化地表示视图中的各种概念。 Core Message: VM manages complexity Key Point 1: This is a model of typical system. Sale has information about purchase order, sales person, and customer. In a system, you may get hundreds or thousands of these things (or objects). Key Point 2: Human mind can only handle 7 plus or minus things at once. VM allows you to raise your level of abstraction. There are constructs to group things into more manageable number of things. Example: One new developer joins the group. How do you describe your software system? Conclusion: VM manages complexity 标准建模语言UML的重要内容可以由下列五类视图(共9种图形)来定义: 6

·2.3.1、第一类是用例视图(Use case View),强调从用户角度看到的或需要的系统功能,并指出各功能的操作者。包括用例图。 用例图用来描述系统功能

（1） 用例图示例 用例的发起者在用例图的左侧，接受者在用例图的右侧。参与者的名字放在参与者图标的下方。关联线连接参与者和用例并且表示参与者与用例之间有通信关系。关联线是实线，和类之间的关联线类似。 用例分析的一个好处是它能够展现出系统和外部世界之间的边界。参与者是典型的系统外部实体，而用例是典型的属于系统内部。系统的边界用一个矩形来代表，里面写上系统的名字。系统的用例装入矩形之内。 系统 参与者 参与者 用例

（2）用例图的建立步骤： 1) 找出系统外部的活动者和外部系统，确定系统的边界和范围。 2) 确定每一个活动者所希望的系统行为。 3) 把这些系统行为命名为用例。 4) 把一些公共的系统行为分解为一批新的用例，供其它的用例引用。把一些变更的行为分解为扩展用例。 5) 绘制用例图。 6) 区分主业务流和例外情况的事件流。可以把表达例外的情况的事件流的用例图画成一个单独的子用例图。 7) 细化用例图，解决用例间的重复与冲入问题，简化用例中的对话序列，用例图可以有不同的层次，高层次系统的用例可以分解为若干个下属子系统中的子用例。

3.2.2 、第二类是静态视图(Static View),展现系统的静态或结构组成及特征。包括类图、对象图和包图。 其中类图描述系统中类的静态结构。不仅定义系统中的类,表示类之间的联系如关联、依赖、聚合等,也包括类的内部结构(类的属性和操作)。类图描述的是一种静态关系,在系统的整个生命周期都是有效的。 对象图是类图的实例,几乎使用与类图完全相同的标识。他们的不同点在于对象图显示类的多个对象实例,而不是实际的类。 一个对象图是类图的一个实例。由于对象存在生命周期,因此对象图只能在系统某一时间段存在。 包由包或类组成,表示包与包之间的关系。包图用于描述系统的分层结构。

（1）类图示例 在UML中一个矩形表示一个类的图标。 属性是类的一个特性，它描叙了类的对象（也就是类的实例）所具有的一 系列特性值。一个类可以具有零个到多个属性。属性名列表放在类名之下， 并且和类名之间用分隔号隔开。 操作是类能够做的事情或者你（或者另一个类）能对类做的事情。 操作名列表要放在属性名列表之下，两者之间用分隔线隔开 WashingMachine brandName modeName serialNumber addClothes(C：String) removeClothes(C：string) turnON()：Boolean

（2）对象图示例 类的属性在该类的每个对象中都有具体值。 对象名首写字母小写，后面根一个冒号，冒号后面是该对象 所属的类名，并且整个名字要带下划线。 myWasher:WashingMachine brandName＝“海尔” modeName＝“小神童” serialNumber＝“GL0214”

（3）对象类图的建立步骤 1〉研究分析问题领域，确定系统的需求。 2〉发现对象和类，明确他们的含义和责任，确定属性和操作。 3〉发现类之间的静态联系。着重分析找出类之间的一般和特殊关系，部分 与整体关系，研究类的继承性和多态性，把类之间的静态联系用关联、泛化、 聚合、组合、依赖等联系表达出来，虽然对象类图表达的是系统的静态结构特 征，但是应当把对系统的静态分析与动态分析结合起来，更能准确地了解系统 的静态结构特征。 4〉设计类与联系。调整和细化已得到的对象类和类之间的联系，解决诸如命名 冲突、功能重复等问题。 5〉绘制对象类图并编制相应的说明。上述做法是直接从领域分析抽取对象和类 开始的，这是常规的面向对象的系统分析与设计的做法。Rational统一过程 主张采用用例驱动的系统分析与设计方法。从业务领域的分析中先抽取活动者 和用例，建立业务模型。业务模型包括业务用例模型、设计模型、实现模型和 测试模型。

（4）包图示例 包用附有标签的矩形表示 包图名

（5）包图的建立步骤 1〉分析系统模型元素（通常是类），把概念上或语义上相近的模型元素 纳入一个包。注意可以从类的功能的相关性来确定纳入包中的类。以下 几点可作为分析对象类的功能相关性的参考 （1）如果一个类的行为和/或结构的变更要求另一个相应的变更，则这 两个类是功能相关的。 （2）如果删除一个类后，另一个类便变成是多余的，则这连个类是功 能相关的，这说明该剩余的类只为那个被删除的类所使用，他们之间有 依赖关系。 （3）如果两个类之间大量的频繁交互或通信，则这两个类是功能相关 的。 （4）如果两个类之间有一般/特殊关系，则这两个类是功能相关的。 （5）如果一个类激发创建另一个类的对象，则这两个类是功能相关的。 （6）如果两个类不涉及统一个外部活动着，则这两个类不应放在同一 个包中。 （7）一个包应当具有高内聚性，包中的类应该是功能相关的。

2〉对于每一个包，标出其模型元素的可视性：公共、保护或私有。 3〉确定包与包之间的依赖关系，特别是输入依赖。 4〉确定包与包之间的泛化关系，确定包元素的多态性和重载。 5〉绘制包图。

·2.2.3、第三类是行为视图(Behavior View),描述系统的动态模型和组成对象间的交互关系。包括状态图和活动图 状态图描述类的对象所有可能的状态以及事件发生时 状态的转移条件。通常,状态图是对类图的补充。在实用上并 不需要为所有的类画状态图,仅为那些有多个状态其行为受外 界环境的影响并且发生改变的类画状态图。 活动图描述满足用例要求所要进行的活动以及活动间的 约束关系,有利于识别并行活动。

(1)状态图示例 状态用具有圆形拐角的矩形表示,状态间带箭头的实线代表状态的迁移，箭头指向目标状态。 图中的实心圆代表状态转移的起点，带圆圈的实心圆代表终点。 Initialization Canceled

(2)状态图的建立步骤 1〉确定状态机的上下文，它可以是一个类、子系统或整个系统。 2〉选择初始状态和终结状态。 3〉发现对象的各种状态。注意应当仔细找出对问题有意义的对象状态属 性，这些属性具有少量的值，且该属性的值的转换受限制。状态属性值 的组合，结合行为有关的事件和动作，就可以确定具有特定的行为特征 的状态。 4〉确定状态可能发生的装移。注意从一个状态可能转移到哪些状态，对象的哪些行为可引起状态的转移并找出触发状态转移的事件。 5〉把必要的动作加到状态或转移上。 6〉要超状态、子状态、分支、历史状态等概念组织和简化一个复杂的状 态机。 7〉分析状态的并发和同步情况。 8〉绘制状态图。 9〉确认每一个状态在某个时间组合之下都是可到达的。

(3) 活动图示例 活动状态表示成带有圆形边线的矩形，它含有活动的描述（普通的状态盒为直边圆角）。简单的完成转换用箭头表示。和状态图相似，活动图也有起点和终点符号，表示法和状态图一样。 ● 活动1 活动2 ●

(5) 活动图的建立步骤 1〉找出负责实现工作流的业务对象。这些对象可以是现实业务领域中的实体，也可以是一种抽象的概念或事物。为每一个重要的业务对象建立一条泳道。 2〉确定工作流的初始状态和终结状态，明确工作流的边界。 3〉从工作流的初始状态开始，找出随时间而发生的活动和动作，把他们表示成活动状态或动作状态。 4〉对于复杂的动作或多次重复出现的一组动作，可以把他们组成一个活动状态，并且用另外一个活动图来展开表示。 5〉给出连接活动和动作的转移（动作流）。首先处理顺序动作流，然后处理条件分支。最后处理分劈和接合。 6〉在活动图中给出与工作流有关的重要对象，并用虚箭线把他们与活动状态或动作状态相连接。

2.2.4、第四类是交互图(Interactive View),描述对象间的交互关系。包括顺序图和协作图 顺序图显示对象之间的动态合作关系,它强调对象之间 消息发 送的顺序,同时显示对象之间的交互; 协作图描述对象间的协作关系,协作图跟顺序图相似,显示对 象间的动态合作关系。除显示信息交换外,协作图还显示对 象以及它们之间的关系。 如果强调时间和顺序,则使用顺序图;如果强调上下级关系,则 选择协作图。 Core message -- second bullet UML can be used to communicate system and software design throughout the life cycle 9

（1）顺序图示例

（2）顺序图的建立步骤 1〉 找出参与交互的对象角色，把他们横向排列在顺序图的顶部，最重要的对象安置在最左边，交互密切的对象尽可能相邻。在交互中创建的对象在垂直方向应安置在其被创建的时间点处。 2〉 对每一个对象设置一条垂直的向下的生命线。 3〉 从初始化交互的信息开始，自顶向下在对象的生命线之间安置信息。注意用箭头的形式区别同步消息和异步消息。根据顺序图是属于说明层还是属于实例层，给出消息标签的内容，以及必要的构造型与约束。 4〉 在生命线上绘出对象的激活期，以及对象创建或销毁的构造型和标记。 5〉 更具消息之间的关系，确定循环结构及循环参数和出口条件。

(3)协作图示例 协作图是对象的扩展，协作图除了展示出对象之间的关联，还显示出对象之间的消息传递。通常在协作图中省略掉关联的名字。 关联线附近的箭头线表示对象之间传递的消息，箭头指向消息接收对象。消息名称和消息序号附在箭头线附近。消息的一般含义是触发接收消息的对象执行它的一个操作。在协作图中，在消息名前面加上消息的序号，它代表该消息在消息序列中的顺序。消息名和序号之间用冒号隔开。 :对象名1 3：update（） 1：add（） 2：modify（） :对象名2 :对象名3

（4）协作图的建立步骤 1〉找出参与交互的对象角色，把他们作为图形的节点置在协作图中。最重 要的对象安置在图的中央，与他有直接交互的对象安置在邻近。 2〉设置对象的初始性质。 3〉说明对象之间的链接。首先给出对象之间的关联连接，然后给出其它连 接，并且给出必要的装饰，如构造型《global》《local》等。 4〉从初始化交互的消息开始，在链接上安置相应的消息，给出消息的序号 。注意用箭头的形式区别同步消息和异步消息。根据顺序图是属于说明层 还是属于实例层，给出消息标签的内容，以及必要的构造型和约束。 5〉处理一些特殊情况，如循环、自调用、回调、多对象等。

·2.2.5、 第五类是实现视图( Implementation VIew)。包括构件图和部署图 构件图描述代码部件的物理结构及各部件之间的依赖 关系。 一个部件可能是一个资源代码部件、一个二进制部件 或一个可执行部件。它包含逻辑类或实现类的有关信息。部 件图有助于分析和理解部件之间的相互影响程度。 部署图定义系统中软硬件的物理体系结构。它可以显示 实际的计算机和设备(用节点表示)以及它们之间的连接关系 也可显示连接的类型及部件之间的依赖性。 在节点内部,放 置可执行部件和对象以显示节点跟可执行软件单元的对应关 系。

（1）构件图示例 构件用一边有两个小矩形的一个长方形表示，它可以用实线与代表构件接口的圆圈相连 。 构件图表示了构件之间的依赖关系。每个构件实现（支持）一些接口，并使用另一些接口。如果构件间的依赖关系与接口有关，那么构件可以被具有同样接口的其他构件替代。

（2）构件图的建立步骤 1〉确定构件。首先要分解系统，考虑有关系统的组成管理、软件的重用核物理节点的配置等因素，把关系密切的可执行程序和对象库分别归入组件，找出相应的对象类、接口等模型元素。 2〉对构件加上必要的构造型。可以使用uml的标准构造型《executable》、《library》、《table》、《file》、《document》，或自定义新的构造型，说明组件的性质。 3〉确定构件之间的联系。最常见的构件之间的联系是通过接口依赖。一个构件使用某个接口，另一个构件实现该接口。 4〉必要时把构件组织成包。构件和对象、协作等模型元素一样可以组织成包。 5〉绘制构件图。

（3）部署图示例 节点用带有节点名称的立方体表示，节点间的关联代表通信路径。关联有用来辨别不同路径的构造型。节点也有泛化关系。

（4）配置图的建立步骤 1〉确定节点。注意：标示系统中的硬件设备，包括大型主机、服务器、前端机、网络设备、输入/输出设备等。一个处理机是一个节点，它具有处理功能，能够执行一个组件；一个设备也是一个节点，她没有处理功能，但他是系统和现实世界的接口。 2〉对节点加上必要的构造型。可以使用uml的标准构造型或自定义新的构造型，说明节点的性质。 3〉确定联系。这是关键步骤。配置图中的联系包括节点与节点之间的联系，节电与组件之间的联系，组件与组件之间的联系，可以使用标准构造型或自定义新的构造型说明联系的性质。把系统的组件如可执行程序，动态连接库等分配到节点上，并确定节点与节点之间，节点与组件之间，组件与组件之间的联系，以及他们的性质。 4〉绘制配置图。

3、视图和图的总结 3.1、视图总结 用例视图(Use case View), 动态视图(Dynamic View) ，也称为行为视图(Behavior View), 也称为并发视图(Concurrent View) 交互视图(Interactive View) 静态视图(Static View),也称为逻辑视图(Logic View)，也称为结构模型视图(Structural Model View) 实现视图( Implementation View)，也称为组件（构件）视图(Component View)

3.2、图的总结 用例图(Use Case Diagram) 类图(Class Diagram) 静态视图 对象图(Object Diagram) 组件图(Component Diagram) 也被称为构件图 配置图(Deployment Diagram)， 也被称为部署图， 实施图

时序图(Sequence Diagram)， 也被称为顺序图，序列图 动态视图 协作图(Collaboration Diagram) 状态图(StateChart Diagram) 活动图(Activity Diagram)

Static Diagrams Dynamic Diagrams 结构 行为 Use-Case Diagrams Class Sequence Diagrams Object Diagrams Collaboration Diagrams Component Diagrams Models 行为 Statechart Diagrams Deployment Diagrams Activity Diagrams Dynamic Diagrams

4、UML结构图 UML 事物 关系 图 结构 事物 行为 事物 分组 事物 辅助 事物 关联 关系 依赖 关系 泛化 关系 实现 关系 静态 图 动态 图 交 互 状 态 机 包 注 释 用 例 图 类 图 对 象 图 构 件 图 部 署 图 用 例 类 接 口 协 作 活 动 类 组 件 节 点 顺 序 图 协 作 图 状 态 图 活 动 图

5、UML元素列表 主要的域 视图 图 主要概念 结构 静态视图 类图 类、关联、泛化、依赖关系、实现、接口 用例视图 用例图 用例、参与者、关联、扩展、包括、用例泛化 实现视图 构件图 构件、接口、依赖关系、实现 部署视图 部署图 节点、构件、依赖关系、位置 动态 状态视图 状态图 状态、事件、转换、动作、 活动视图 活动图 状态、活动、完成转换、分叉、结合 交互视图 顺序图 交互、对象、消息、激活 协作图 协作、交互、协作角色、消息 模型管理 模型管理视图 包图 包、子系统、模型 可扩展性 所有 约束、构造型、标记值

6、扩展组件 UML提供了几种扩展机制，允许建模者在不用改变基本建模语言的情况下做一些通用的扩展。这些扩展机制已经被设计好，以便于在不需理解全部语义的情况下就可以存储和使用。 这种扩展的方法很可能不能满足出现的多种要求，但是它以一种易于实现的简单方式容纳建模者对UML裁制的大部分要求。 一定要记住扩展是违反UML的标准形式的，并且使用它们会导致相互影响。在使用扩展机制之前，建模者应该仔细权衡它的好处和代价，特别是当现有机制能够合理工作时。典型地，扩展用于特定的应用域或编程环境，但是它们导致了UML方言的出现，包括所有方言的优点和缺点。 扩展机制包括约束、标记值和构造型。

6.1、约束 约束是用文字表达式表示的语义限制。每个表达式有一种 隐含的解释语言，这种语言可以是正式的数学符号，如set- theoretic表示符号；或是一种基于计算机的约束语言，如OCL ；或是一种编程语言，如C++；或是伪代码或非正式的自然语 言。当然，如果这种语言是非正式的，那么它的解释也是非正 式的，并且要由人来解释。即使约束由一种正式语言来表示， 也不意味着它自动为有效约束。 约束可以表示不能用UML表示法来表示的约束和关系。 约束用大括弧内的字符串表达式表示。约束可以附加在表元素 、依赖关系，或注释上。

6.2、标记值 标记值是一对字符串—一个标记字符串和一个值字符串—存储着有关元素的一些信息。标记值可以与任何独立元素相关，包括模型元素和表达元素。标记是建模者想要记录的一些特性的名字，而值是给定元素的特性的值。例如，标记可以是author，而值是对元素负责的人的名字，如Charles Babbage。 　　标记值可以用来存储元素的任意信息，对于存储项目管理信息尤其有用的，如元素的创建日期、开发状态、截止日期和测试状态。除了内部元模型属性名外，任何字符串可以作为标记名（这是因为标记和属性在一起会被认为是一个元素的属性并且可以被工具一起访问），而一些标记名已经被预定义了。 　　

标记值也可以用来存储有关构造型模型元素的信息。 　　 标记值用字符串表示，字符串有标记名、等号和值。它们被规 则地放置在大括弧内。

6.3、构造型 许多建模者希望为了一种特定的应用域裁制一种建模语言，这带来一些风险，因为被裁制的语言不易普遍为人理解，但人们仍然试图这么做。 　　构造型是在一个已定义的模型元素的基础上构造的一种新的模型元素。构造型的信息内容和形式与已存在的基本模型元素相同，但是含义和使用不同。 构造型建立在已存在的模型元素基础上，构造型元素的信息内容与已存在的模型元素相同。这样便可允许工具以相同的方式存储和使用新元素和已存在的元素。构造型元素可以有它自己的区别符号，并且这很容易由工具所支持。 　　 　　

构造型可以用标记值来存储不被基本模型元素所支持的附加特性。 构造型用双尖括号内的文字字符串表示，它可以放在表示基本模型元素的符号的里边或旁边，建模者也可以为特殊的构造型创建一个符号，这个符号替代了原来的基本模型元素的符号。

6.4、裁制UML 约束的扩展机制、标记值和构造型使得为了特殊的应用域而裁制UML轮廓成为可能。并已经形成了几种轮廓，此外用户还提出了其他。这种裁制建模语言的能力意味着应用域的用户可以使建模语言适应应用域的需要，还能够共享在所有领域中通用的概念。

6.5、扩展组件的应用实例 下图举例说明了约束、构造型，和标记值的使用。 下图中对剧目类的约束保证了剧目具有唯一的名称，用文字表达约束 效果较好。 TicketdDB构件构造型表明这个是一个数据库构件，建模者可以增加 新的构造型来表示专门的模型元素。一个构造型可以带有多个约束、标 记值。如图所示，建模者可以为命名的构造型定义一个图标，作为可视 化的辅助工具。 Scheduling包中的标记值说明Frank Martin要在1999年年底前完成计划的 制定。使用文字有益于描述项目管理和代码生成参数。大部分标记值 保存为编辑工具中的弹出信息，在正式打印出的图表中通常没有标记值。

7、UML建模 从应用的角度看,当采用面向对象技术设计系统时,首先是描述需求;其 次根据需求建立系统的静态模型,以构造系统的结构;第三步是描述系统的 行为。 其中在第一步与第二步中所建立的模型都是静态的,包括用例图、类图(包 含包)、对象图、组件图和配置图等五个图形,是标准建模语言UML的静态 建模机制。 其中第三步中所建立的模型或者可以执行,或者表示执行时的时序状态或 交互关系。它包括状态图、活动图、顺序图和合作图等四个图形,是标准 建模语言UML的动态建模机制。 因此,标准建模语言UML的主要内容也可以归纳为静态建模机制和动态建 模机制两大类。