当前位置：首页 > 码农资料 > 正文内容

UML

CCSSRW1年前 (2023-10-20)码农资料10403

什么是UML？

统一建模语言（UML）是一种通用的可视化建模语言，可以用来描述、可视化、构造和文档化软件密集型系统的各种工件。

UML是独立于过程的，它适用于各种软件开发方法、软件生命周期的各个阶段、各种应用领域以及各种开发工具。

注：UML不是一种程序设计语言，其描述的模型可以和各种编程语言相联系。

UML的目标

1.为建模者提供可用的、富有表达力的、可视化的建模语言，以开发和交换有意义的模型。

2.提供可扩展性和特殊化机制以延伸核心概念。

3.支持独立于编程语言和开发过程的规范。

4.为理解建模语言提供正式的基础。

5.推动面向对象建模工具市场的成长。

6.支持更高级的开发概念。

UML的应用范围

UML的构造块：事物、关系、图

关系是模型元素之间具体化的语义连接，负责联系UML的各类事物，构造出结构良好的UML模型。

四种关系：

关联关系：描述不同类元的实例之间的连接。

依赖关系：描述一对模型元素之间的内在联系。

泛化关系：描述特殊到一般的一种归纳和分类关系。

实现关系：描述规格说明和其实现的元素之间的连接的一种关系。

UML图根据基本功能和作用，可分为：结构图与行为图。

结构图：捕获事物与事物之间的静态关系，用来描述系统的静态结构模型。

行为图：捕获事物的交互过程如何产生系统的行为，用来描述系统的动态行为模型。

类图

类图的定义：是显示一组类、接口、协作以及它们之间关系的图。

类图主要包含7种元素：、类、接口、协作、依赖关系、泛化关系、实现关系、关联关系。

类图：包、子系统，用来把模型元素聚集成更大的组块。

类图：约束、注解

类

1.类是一组拥有相同的属性、操作、方法、关系和行为的对象地描述符。

2.类定义了一组有着状态与行为的对象。类的状态由属性和关联来描述，个体行为由操作来描述，对象的生命周期则由附加给类的状态机来描述。

3.在UML中，类表达成一个有三个分隔区的矩形。其中顶端显示类名，中间显示类的属性，尾端显示类的操作。

类——属性

可见性：描述了该属性在那些范围内可以被使用。

可见性	英文限定符	UML标准图示	Rose图示	说明
公有	public	+		其他类可以访问
私有	private	-		只对本类可见，不能被其他类访问
保护	protected	#		对本类及其派生类可见

类型：属性的数据类型，可以系统固有，也可以用户自定义。属性的类型决定了该属性的所有可能取值的集合。

类——操作

可见性：同样描述该操作在那些范围内可以使用，与属性的可见性相同。

参数列表：是一些按照顺序排列的属性定义了操作的输入。例如：oper(out arg1:int, arg2:double=3.2)

返回类型即回送调用对象消息的类型。void关键字表示无返回值。

特性是对操作性质的约束说明。

类——职责

职责是类的契约或责任。当创建一个类时，就声明了这个类的所有对象具有相同种类的状态和相同种类的行为。在较高的抽象层次上，这些相应的属性和操作正式要完成类的职责的特征。

类的职责是自由形式的文本，在非正式的类图中，可以将职责列在类图操作下的另一分割栏中。

接口

1.接口是一个被命名的操作集合，用于描述类或组件的一个服务。

2.接口不包含属性与方法实现，但可以有一些操作。接口的所有内容都是公有的。

3.接口代表了一份契约，实现该接口的类元必须履行它。

4.在UML中，接口由一个带名称的小圆圈表示；也可以表示为带有<<interface>>构造型的类

类图中的关系

UML中最常用的四种关系，即关联关系、泛化关系、依赖关系和实现关系。

类图中的关系——关联关系

1）关联的实例被称为链，每个链由一组有序或无序的对象组成。

2）关联关系靠近被关联元素的部分称为关联端，关联的大部分描述都包含在一组关联端的列表里，每个端用来描述关联中类的对象的参与

3）二元关联、自关联、N元关联。

注意要点

关联名称：放在关联路径的旁边，但远离关联端。

角色：放在靠近关联端的部分，表示该关联端连接的类在这一关联关系中担任的角色。角色名上也可使用可见性修饰符号。

多重性：放在靠近关联端的部分，表示在关联关系中源端的一个对象可以与目标类的多少个对象之间有关联。

导航性：一个布尔值，用来说明运行时刻是否可能穿越一个关联。

限定符：是二元关联上的属性组成的列表的插槽，其中的属性值用来从整个对象集合里选择一个唯一的关联对象或者关联对象的集合。

约束：关联间的约束关系。

[现实例子]

比如客户和订单，每个订单对应特定的客户，每个客户对应一些特定的订单；再例如公司和员工，每个公司对应一些特定的员工，每个员工对应一特定的公司。

派生关联：属于一种派生元素。它不增加语义信息，只是一种可以由两个或两个以上的基础关联推算出来的虚拟关联。

两种特殊的关联关系：聚合关系与组合关系

1.聚合关系：描述“整体-部分”的关联关系

聚合关系没有改变整体与部分之间整个关联的导航含义，也与整体和部分的生命周期无关。

2.组合关系：描述“整体-部分”的关联关系

组合关系中的部分要完全依赖于整体。

关联与聚合的区别

(1)关联关系所涉及的两个对象是处在同一个层次上的。比如人和自行车就是一种关联关系，而不是聚合关系，因为人不是由自行车组成的。

聚合关系涉及的两个对象处于不平等的层次上，一个代表整体，一个代表部分。比如:电脑和它的显示器、键盘、主板以及内存就是聚集关系，因为主板是电脑的组成部分。

(2)对于具有聚集关系（尤其是强聚集关系）的两个对象，整体对象会制约它的组成对象的生命周期。部分类的对象不能单独存在，它的生命周期依赖于整体类的对象的生命周期，当整体消失，部分也就随之消失。比如张三的电脑被偷了，那么电脑的所有组件也不存在了，除非张三事先把一些电脑的组件（比如硬盘和内存）拆了下来。

聚合与组合的区别

聚合关系：涉及的两个对象处于不平等的层次上，一个代表整体，一个代表部分。比如:电脑和它的显示器、键盘、主板以及内存就是聚集关系，因为主板是电脑的组成部分。

组合关系：代表整体的对象负责代表部分对象的生命周期。公司不存在，部门也没有意义了。再例如：人和五脏六腑、四肢的关系。

类图中的关系——泛化关系

泛化关系定义为一个较普通的元素与一个较特殊的元素之间的类元关系。其中描述一般的元素称为父，描述特殊的元素称为子。（子类是父类的继承，则父类就是子类的泛化。）

通过泛化对应的继承机制使子类共享父类的属性和操作，小了模型的规模，同时也防止了模型的更新所导致的定义不一致的意外。

泛化关系的特征：

传递性：一个类子类的子类同样继承了这个类的特性。在父方向上经过了一个或几个泛化的元素被称为祖先，在子方向上则被称为后代。

反对称性：泛化关系不能成环，即一个类不可能是自己的祖先和自己的后代。

泛化关系的两种情况

单继承：每个类之多能拥有一个父类。

编程语言：C#、Java等

多重继承：子类可以有多个父类并继承了所有父类的结构、行为和约束。

编程语言：C++等

类图中的关系——依赖关系

依赖关系表示的是两个元素之间语义上的连接关系。对于两个元素X和Y，如果元素X的变化会引起对另一个元素Y的变化，则称元素Y依赖于X。其中，X被称为提供者，Y被称为客户。

[现实例子]比如说你要去拧螺丝，你是不是要借助(也就是依赖)螺丝刀(Screwdriver)来帮助你完成拧螺丝(screw)的工作。

对于类图而言，主要有以下需要使用依赖的情况：

1）客户类向提供者类发送消息。

2）提供者类是客户类的属性类型。

3）提供者类是客户类操作的参数类型。

类图中的关系——实现关系

　　实现关系用来表示规格说明与实现之间的关系。在类图中，实现关系主要用于接口与实现该接口的类之间。

一个类可以实现多个接口，一个接口也可以被多个类实现。

实现关系的两种表示法：

　　a.当接口元素以带构造型的类的方式表示时，用虚线三角形箭头表示。

　　b.当接口元素以小圆圈方式表示时，用实线表示。

综合例子：

补充

涉及类的其他概念——抽象类

　　抽象类即不可实例化的类，也就是说，抽象类没有直接的实例。

　　在UML中，抽象类通过对类名添加斜体修饰来表示。

涉及类的其他概念——模板类

　　模板又称为参数化元素是对一类带有一个或者多个未绑定的形式参数的元素的描述。模板应用在类上时称为模板类。

　　对应概念：C++中的模板与Java中的泛型

　　模板类可以根据参数来定义类，而不用说明属性和操作参数及返回值的具体类型，使用时通过实际值代替参数即可创建新的类，这样就可以避免建立大量功能相似的类。

涉及类的其他概念——关联类

　　具有类的特性的关联关系，称为关联类。关联类具有关联和类二者的特性，它既可以关联类元素，也可以拥有属性和操作。

　　关联类在UML中被表示为一个类符号，并通过一条虚线连接到关联路径。

涉及类的其他概念——分析类

　　分析类是一个主要用于开发过程中的概念，用来获取系统中主要的“职责簇”，代表系统的原型类，是带有某些构造型的类元素。

　　边界类：用于对系统外部环境与其内部运作之间的交互进行建模的类。

　　控制类：对一个或多个用例所特有的控制行为进行建模的类。

　　实体类：用于对必须存储的信息和相关行为建模的类。

类图的建模技术

对逻辑数据库模式建模

　　识别模型中那些状态必须超过应用程序生存时间的类作为需要作为永久数据存储的类。

　　创建一个包含这些类的类图。可以自己定义相关的构造型和标记值组合。

　　对类的结构细节进行细化。包括属性的细节、类之间的关联及其多重性。

　　注意那些增加数据库设计复杂化的公共模式并尽量简化，如循环关联、一对一的关联和N元关联等。

　　考虑类的行为。这些行为主要包括对数据存取和数据完整性约束重要的操作。一般情况下，这些业务规则应该被封装在这些永久类的上一层中。

如何阅读类图？

阅读顺序应遵循的原则：

1）先看清有哪些类；

2）然后看看类之间存在的关系；

3）结合多重性来理解类图的结构特点以及各个属性和方法的含义

案例：

1.确定类:Customer、Consignee、Order、OrderItem、DeliverOrder、Peddlery、Product。

2.读出关系：从图中关系最复杂（也就是线最密集）的类开始阅读，本图中最复杂的就是Order类。
1）OrderItem和Order之间是组合关系，根据箭头的方向可知Order包含了OrderItem。
2）Order类和Customer、Consignee、DeliverOrder是关联关系。也就是说，一个订单和客户、收货人、送货单是相关的。

3.多重性来理解类图的结构特点

4．理解方法与图

如何建立类图？

1、建立类图的步骤

　　1）分析问题域，确定需求；

　　2）寻找类，确定类的含义和职责；

　　3）定义类的属性和操作；

　　4）确定类之间的关系；

　　5）精化类和类间的关系；

　　6）绘制类图。

2、寻找类的方法

使用名词/动词寻找类：

1）收集相关信息

　　a.补充的需求规格说明

　　b.用例

　　c.项目说明文档

　　d.其他文档

2）分析信息

　　名词、名词短语类或属性

　　动词、动词短语操作

3、寻找类的方法

使用CRC分析法寻找类：

　　C-class（类）

　　R-responsibility（职责）

　　C-collaboration（协作）

　　CRC分析法是根据类所要扮演的职责来确定类。

　　　　a.脑力风暴收集信息。

　　　　b.关键业务用类表示，其它卡片作为属性。

案例：

需求描述如下：

　　李小平是一个爱书之人，家里各类书籍已过千册，而平时又时常有朋友外借，因此需要一个个人图书管理系统。该系统应该能够将书籍的基本信息按计算机类、非计算机类分别建档，实现按书名、作者、类别、出版社等关键字的组合查询功能。在使用该系统录入新书籍时系统会自动按规则生成书号，可以修改信息，但一经创建就不允许删除。该系统还应该能够对书籍的外借情况进行记录，可对外借情况列表打印。另外，还希望能够对书籍的购买金额、册数按特定时间周期进行统计。

发现类：

筛选备选类

“李小平”、“人”、“家里”很明显是系统外的概念，无须对其建模；

而“个人图书管理系统”、“系统”指的就是将要开发的系统，即系统本身，也无须对其进行建模；

很明显“书籍”是一个很重要的类，而“书名”、“作者”、“类别”、“出版社”、“书号”则都是用来描述书籍的基本信息的，因此应该作为“书籍”类的属性处理，而“规则”是指书号的生成规则，而书号则是书籍的一个属性，因此“规则”可以作为编写“书籍”类构造函数的指南。

“基本信息”则是书名、作者、类别等描述书籍的基本信息统称，“关键字”则是代表其中之一，因此无需对其建模；

功能”、“新书籍”、“信息”、“记录”都是在描述需求时使用到的一些相关词语，并不是问题域的本质，因此先可以将其淘汰掉；

筛选修选类

　　“计算机类”、“非计算机类”是该系统中图书的两大分类，因此应该对其建模，并改名为“计算机类书籍”和“非计算机类书籍”，以减少歧义；

　　“外借情况”则是用来表示一次借阅行为，应该成为一个候选类，多个外借情况将组成“外借情况列表”，而外借情况中一个很重要的角色是“朋友”—借阅主体。虽然到本系统中并不需要建立“朋友”的资料库，但考虑到可能会需要列出某个朋友的借阅情况，因此还是将其列为候选类。为了能够更好地表述，将“外借情况”改名为“借阅记录”，而将“外借情况列表”改名为“借阅记录列表”；

　　“购买金额”、“册数”都是统计的结果，都是一个数字，因此不用将其建模，而“特定时限”则是统计的范围，也无需将其建模；不过从这里的分析中，我们可以发现，在该需求描述中隐藏着一个关键类—书籍列表，也就是执行统计的主体。

得到候选类

书籍计算机类书籍非计算机类书籍

借阅记录借阅记录列表书籍列表

分析与建模

用例图

用例图是用来描述系统功能的技术，表示一个系统中用例与参与者及其关系的图，主要用于需求分析阶段。

用例图的基本组成元素：参与者、用例、元素之间的关系。

用例图使用范围：需求分析

1.捕获需求。描述功能需求、行为需求（系统要完成什么任务）

2.分析需求。明确类和对象，建立之间的关系

用例图的基本概念

1、用例图是表示一个系统中用例与参与者关系之间的图。它描述了系统中相关的用户和系统对不同用户提供的功能和服务。

2、用例图相当于从用户的视角来描述和建模整个系统，分析系统的功能与行为。

3、用例图中的主要元素包括参与者、用例以及元素之间的关系。此外，用例图还可以包括注解和约束，也可以使用包将图中的元素组合成模块。

如：

参与者的概念

1、参与者是与系统主体交互的外部实体的类元，描述了一个或一组与系统产生交互的外部用户或外部事物。

2、参与者位于系统边界之外，而不是系统的一部分。

3、参与者是从现实世界中抽象出来的一种形式，却不一定确切对应的现实中的某个特定对象。

符号：

如何确定参与者？

通过对参与者进行关注和分析，我们可以把重点放在如何与系统交互这一问题上，便于进一步确定系统的边界。另外，参与者也决定了系统需求的完整性。

确定参与者可以从以下几个角度来考虑：

1）为系统提供输入的人或事物

2）接收系统输出的人或事物

3）需要接入的第三方系统或设备

4）时间是否会触发某些事件

5）负责支持或维护系统中信息的人

系统中的参与者一般可以分为四类：

主要业务参与者：主要从用例的执行中获得好处的关联人员。

主要系统参与者：直接同系统交互以发起或触发业务或系统事件的关联人员。

外部服务参与者：响应来自用例的请求的关联人员。

外部接收参与者：从用例中接收某些价值或输出的非主要的关联人员。

参与者的泛化关系

当系统中的几个参与者既扮演自身的角色，同时也有更一般化的角色时，可以通过建立泛化关系来进行描述。

与类相似，父参与者可以是抽象的，即不能创建一个父参与者的直接实例，这就要求属于抽象父参与者的外部对象一定能够属于其子参与者之一。

用例的概念

用例是类元提供的一个内聚的的功能单元，表明系统与一个或多个参与者之间信息交换的顺序，也表明了系统执行的动作。

简单来说，用例就是某一个参与者在系统中做某件事从开始到结束的一系列活动的集合，以及结束时应该返回的可观测、有意义的结果，其中也包含可能的各种分支情况。

用例与用例图被广泛使用于系统的需求建模阶段，并在系统的整个生命周期中被不断细化。

符号：

用例与参与者的关系

一个用例可以隶属一个或多个参与者，一个参与者也可以参与一个或多个用例。用例与参与者之间存在关联关系。

主参与者与次参与者：通常来说主参与者是用例的重要服务对象，而次参与者处于一种协作地位。

用例的特征

用例的特征保证用例能够正确地捕捉功能性需求，同时也是判断用例是否准确的依据。

1）用例是动宾短语

2）用例是相对独立的

3）用例是由参与者启动的

4）用例要有可观测的执行结果

5）一个用例是一个单元

用例之间的关系

1．泛化关系

2.依赖关系（包含、扩展）

泛化关系：与参与者的泛化关系相似，用例的泛化关系将特化的用例与一般化的用例联系起来。子用例继承了父用例的属性、操作和行为序列，并且可以增加属于自己的附加属性和操作。父用例同样可以定义为抽象用例。

用例之间的泛化关系表示为一根实线三角箭头，箭头指向父用例一方。

依赖关系——包含

包含指的是一个用例（基用例）可以包含其他用例（包含用例）具有的行为，其中包含用例中定义的行为将被插入基用例定义的行为中。

包含的两个基本约束：

1）基用例可以看到包含用例，并需要依赖于包含用例的执行结果，但是它对包含用例的内部结构没有了解；

2）基用例一定会要求包含用例执行。

包含表示为一个虚线箭头附加上《include》的构造型，箭头从基用例指向包含用例。

依赖关系——扩展

扩展指的是一个用例（扩展用例）对另一个用例（基用例）行为的增强。

扩展使用一个附加了《enxtend》构造型的虚线箭头表示，箭头指向基用例。

注意：扩展与包含的箭头方向是相反的，这表明扩展取决于扩展用例而非基用例，扩展用例决定扩展的执行时机，基用例对此一无所知。

扩展用例的使用包括四个部分：

基用例：需要被扩展的用例，“注册”用例。

扩展用例：提供所添加的行为序列的用例，如图5-10中的“检查实名信息”用例。

扩展关系：使用虚线箭头表示，箭头指向基用例。

扩展点：基用例中的一个或多个位置，表示在该位置会根据某条件来决定是否要中断基用例的执行从而执行扩展用例中的片段。

包含、扩展的区别：

根本区别，包含是无条件执行，扩展是有条件执行。图的起点不同，终点也不同。

特性	include	extend
作用	增强基用例的行为	增强基用例的行为
执行过程	包含用例一定会执行	扩展用例可能被执行
对基用例的要求	在没有包含用例的情况下，基用例可以是也可以不是良构的	在没有扩展用例的情况下，基用例一定是良构的
表示法	箭头指向包含用例	箭头指向基用例
基用例对增强行为的可见性	基用例可以看到包含用例，并决定包含用例的执行	基用例对扩展用例一无所知
基用例每执行一次，增强行为的执行次数	只执行一次	取决于条件（0到多次）

用例描述与文档

用例描述概述：一个完整的用例模型应该不仅仅包括用例图部分，还要有完整的用例描述部分。

一般的用例描述主要包括以下几部分内容：

用例名称：描述用例的意图或实现的目标，一般为动词或动宾短语。

用例编号：用例的唯一标识符，在其他位置可以使用该标识符来引用用例。

参与者：描述用例的参与者，包括主要参与者和其他参与者。

用例描述：对用例的一段简单的概括描述。

触发器：触发用例执行的一个事件。

前置条件：用例执行前系统状态的约束条件。

基本事件流（典型过程）：用例的常规活动序列，包括参与者发起的动作与系统执行的响应活动。

扩展事件流（替代过程）：记录如果典型过程出现异常或变化时的用例行为，即典型过程以外的其他活动步骤。

结论：描述用例何时结束。

后置条件：用例执行后系统状态的约束条件。

补充约束：用例实现时需要考虑的业务规则、实现约束等信息。

前置条件与后置条件

前置条件指的是用例执行前系统和参与者应处于的状态。前置条件是用例的入口限制，它便于我们在进行系统分析及设计的时候注意到，在何时何地才可以合法地触发这个事件。

后置条件是用例执行完毕后系统处于的状态。后置条件是对用例执行完毕后系统状况的总结，用来确保用户理解用例执行完毕后的结果，并非其他用例的触发器。

前置条件与后置条件分别是用例在开始和结束时的必要条件。

事件流

事件流是对用例在使用场景下的交互动作的抽象，应该包括用例何时以及怎样开始和结束，用例何时与参与者交互，该行为的基本流和可选择的流。

基本事件流：描述的是用例中最核心的事件流，是用例大部分时间所进行的场景。

扩展事件流：描述的是用例处理过程中的一些分支或异常情况。

补充约束

补充约束用来描述用例在系统功能之外的内容，例如非功能需求、业务规则等等。

数据需求：与该用例相关的一些数据项的说明。

业务规则：与业务相关的逻辑和操作规则。

非功能性需求：例如性能、支持的并发量等。

设计约束：是从多个角度对用例或系统的约定。

用例文档实践

用例名称	提交订单
用例编号	UC002
参与者	会员
用例描述	该用例描述一个系统会员提交一份订单的行为
触发器	当订单被提交时，用例触发。
前置条件	提交订单的一方需要完成登录操作
后置条件	如果订单中的商品有库存，则发货；否则提示用户当前缺货
基本事件流	1 参与者将订单信息提交至系统。 2 系统验证用户信息及订单信息合法后作出响应。 3 对于订单中的每种产品，系统根据订单中的数量检查产品库存数量。 4 系统统计订单中产品的总价格。 5 系统从会员的系统账户余额中扣除相应金额。 6 系统生成并保存订单信息并将订单发送至分销中心。 7 系统生成订单确认页面并发送给会员。
扩展事件流	A-2 如果订单信息非法，系统通知会员并提示重新提交订单。 A-3 如果订单中产品数量超过产品库存量，则提示会员库存不足，暂无法购买，取消订单同时终止用例。 A-5 如果会员账户余额不足，系统给出相应提示，取消订单并终止用例。
结论	当会员收到系统发送的订单确认页面或其他异常信息时，用例结束。
数据需求	D-1 订单信息包括订单号、参与者的会员账户名、商品种类数量、商品种类名称以及每种商品的数量。
业务规则	B-1 只有当订单中商品信息确认无误后才能要求会员进行支付。

用例图使用要点

1.构建结构良好的用例。用例图中应该只包含对系统而言必不可少的用例与相关的参与者。

2.用例的名称不应该简化到使读者误解其主要语义的程度。

3.摆放元素时应尽量减少连接线的交叉，以提供更好的可视化效果。

4.组织元素时应使在语义上接近的用例和参与者在图的位置上也同样接近，便于读者5.理解用例图。

5.可以使用注解或给元素添加颜色等方式突出图中相对重要的内容。

6.用例图中不应该有太多的关系种类。

用例图建模技术

对系统的语境建模

　　识别系统边界。

　　识别参与者。

　　如果需要，将具有相同特征的参与者使用泛化关系加以组织。

　　如果需要，对某些参与者应用一个构造型以便加深理解。

　　将参与者应用到用例图中，并描述参与者与用例间的通信路径。

对系统的需求建模

　　识别参与者。

　　对于某个参与者，考虑其期望系统提供的行为或与系统的交互。

　　将行为提炼成用例。

　　完善其他用例。分解用例中的公共行为与扩展行为，放入新的用例中以供其他用例使用。

　　创建用例图。

　　如果需要，在用例图中添加一些注解或约束来陈述系统的非功能需求。

案例（1）学生选课系统

某学校的网上选课系统主要包括如下功能：

管理员通过系统管理界面进入，建立本学期要开的各种课程，将课程信息保存在数据库中并可以对课程进行改动和删除。

学生通过客户机浏览器根据学号和密码进入选课界面，在这里学生可以进行三种操作：查询已选课程，选课以及付费。

同样，通过业务层。这些操作结果存入数据库中。

步骤：1。确定系统边界。2.确定参与者（名词）。3.确定用例（动宾结构）。4.确定关系（联系）

参与者：学生、教务人员、数据库

用例：选课、查询、支付课时费用、登陆、修改课程、添加课程、删除课程

关系：关联关系、泛化关系

对象图

对象图概述：对象图显示了某一时刻的一组对象及它们之间的关系。

　　对象图可以看做是类图的实例，用来表达各个对象在某一时刻的状态。

　　对象图中的建模元素主要有对象和链，对象是类的实例，链是类之间的关联关系的实例。

对象图的组成元素——对象

对象是类的实例，是一个封装了状态和行为的具有良好边界和标识符的离散实体。对象通过其类型、名称和状态区别于其他对象而存在。

对象名：在矩形框的顶端显示。

类型：具体的类目

状态：由对象的所有属性以及运行时的当前值组成。

表示法：在对象名后跟一个冒号加上类型名，并且使用下划线与类进行区分。

对象图的组成元素——链

链是关联关系的实例，是两个或多个对象之间的独立连接。因此，链在对象图中的作用就十分类似于关联关系在类图中的作用。

在UML中，链同样使用一根实线段来表示。

链主要用来导航。链一端的一个对象可以得到另一位置上的一个或一组对象，然后向其发送消息。链的每一端也可以显示一个角色名称，但不能显示多重性。

对象图的建模技术：

为对象结构建模

识别建模机制。建模机制被描述为系统的某些功能或行为，经常会被耦合为用例，由一组类、接口和其他事物的交互产生。可以创建协作来描述机制。

识别参与的类和接口等元素，以及这些元素之间的关系。

识别并选择对象。考虑这个机制的脚本在某时刻被冻结时的情况，识别并选择出各个对象。

按需要显示每个对象的状态。

识别并显示出对象之间的链，即对象的类目之间关联的实例。

对象图的建模步骤:

1、确定对象及对象状态（从类图中来）

2、建立链（从类图中来）

对象图使用要点:

1）注重于表达系统静态设计视图或静态交互视图的一个方面。

2）表示由一个交互图描绘的动态场景的一个画面。

3）只包含对理解该方面不可缺少的那些元素。

4）提供与它的抽象层次相一致的细节，应该只显露出对理解是不可缺少的那些属性值和其他修饰。

5）不要过分的简化，这样会使读者对重要的语义产生误解。

包图

基本概念: 包图是用来描述模型中的包和所包含元素的组织方式的图，是维护和控制系统总体结构的重要内容。

包图能够组织许多UML中的元素，不过其最常用的用途是用来组织用例图和类图。

包图中包含包元素以及包之间的关系。与其他图类似，包图中可以创建注解和约束。

包的概念: 包是用于把模型组织成层次结构的通用机制，它不能执行。

包名：包有简单名、路径名

包中的元素：包中可以容纳各种高级的模型元素，如类和类的关系、状态机、用例图、交互、协作等，甚至是一个完整的UML图。

另外，包中还可以含有包，这被称为包的嵌套。

包元素的可见性：控制包外元素对包内元素的访问权限。

公有（+）：只要当前包被引入，包内的公共元素即对引入者可见。

保护（#）：仅对当前包的子包可见。

私有（-）：仅对该包可见，外部无法访问。

另外，如果某元素对于一个包是可见的，则它对于嵌套在这个包中的任何包都是可见的。

包的构造型：可以使用构造型来描述包的种类。UML预定义了一些构造型，用户也可自行定义新的构造型。

高内聚，低耦合：

在外部观察包时，可以将内部元素视作一个整体，方便将多个元素一同处理。

包内部的元素应该保证有相似、相同的语义，或者其元素有同时更改和变化的性质。

注：在实际应用中，包对包含的元素的作用相当于C++和C#中命名空间的概念或Java中的包概念。和这些概念不同的是，UML包中的内容不限于类和接口，包中的元素种类要丰富的多。

元素的分包原则：

1）元素不能“狡兔三窟”：树形结构的一个节点不能同时拥有两个父节点，一个元素也不允许在两个包中重复出现。

2）相同包内元素不能重名：包所具有的命名空间的作用要求用一个包中的同种类元素名称必须是唯一的。

3）包内元素要紧密联系：分在同一个包中的元素应该具有某些相同的性质，即包的高内聚性。

4）包与包尽可能保持独立：包和包之间需要尽可能减少耦合度，要求包内元素与外部元素有尽可能少的依赖关系。

包的依赖关系：

包之间的依赖关系实际上是从一个更高的层次来描述包内某些元素之间的依赖关系。也就是说，如果不同包中任何元素之间存在着一个依赖，则两个包之间就存在着依赖关系。

包之间的依赖关系首先需要包中的某些元素具有某种外部可见性，即可以被包外部的元素所引用。

容易出现的问题：循环依赖

循环依赖的出现是令人困惑、也是非常容易产生错误的。尤其是当依赖关系表示包的引入时，循环依赖会导致将模型转化成代码后因为包之间互相引入而出现错误。

解决方案：重新分包，引入第三个包，重新建立依赖关系。

包图的建模技术

对成组元素建模

浏览模型中的元素，找出概念或语义上接近的元素分组。

将分好组的元素组织在一个包里，同时考虑包的嵌套。

对每一个包，区分哪些元素需要在包外被访问，进而确定包内元素的可见性。这一步骤类似于类的封装过程：没有必要对外开放的元素一定要预先标注为私有，随后逐一检查，如果必须开放再考虑开放可见性为受保护或公有。若设计完成时发现部分公有元素未被使用，还应该将这些元素重新置为私有元素。

使用引入依赖显式地在包之间建立关系。

对体系结构视图建模

我们已经知道，视图是对系统的组织和结构的某个方面的投影，表达了对系统某个方面的关注。理论上，我们完全可以利用包元素来创建自己的体系结构视图。实际上，现在绝大部分的UML建模工具的视图结构也是使用包元素来划分其体系结构视图的。

通信图的概念：通信图（协作图）是表现对象交互关系的图，它展现了多个对象在协同工作达成共同目标的过程中互相通信的情况，通过对象和对象之间的链、发送的消息来显示参与交互的对象。

首先通信图一样是一种交互图，它描述的是对象和对象之间的关系，即一个类操作的实现。简而言之就是，对象和对象之间的调用关系，体现的是一种组织关系。

通信图中的元素主要有对象、消息和链三种。对象和链分别作为通信图中的类元角色和关联角色出现，链上可以有消息在对象间传递

从结构方面来看，通信图包含了一个对象的集合并且定义了它们之间的行为方面的关系，表达了一些系统的静态内容。

从行为方面来看，通信图包含了在各个对象之间进行传递交换的一系列的消息集合，以完成协作的目的。

通信图是一种描述协作在某一语境下的空间组织结构的图形化方式，在使用其进行建模时，主要具有以下三个作用。

1）通过描绘对象之间消息的传递情况来反映具体使用语境的逻辑表达。

2）显示对象及其交互关系的空间组织结构。

3）表达一个操作的实现。

通信图的组成元素: 对象、链、消息

对象

　　通信图中的对象与顺序图中对象的概念相同，都是表示类的实例。

　　通信图只关注相互有交互作用的对象和对象关系，而忽略其他对象。

　　由于通信图中不表示对象的创建与销毁，因此，对象在通信图中的位置没有限制。

　　与顺序图中对象的表示法不同的是，通信图中的无法显示对象的生命线。

链

　　通信图中的链与对象图中的链在语义以及表示法上都相同，都是两个（或多个）对象之间的独立连接，是关联的实例。链同时也是通信图中关联角色的实例，其生命受限于协作的生命。

　　链连接的两个对象之间允许在交互执行过程中进行消息传递和交互。UML也允许对象自身与自身之间建立一条链。链可以通过对自己命名来进行区分和说明，也可以仅仅做连接而不进行命名。

消息

　　通信图的消息需要附加在对象之间的链上，链用于传输或实现消息的传递。

　　通信图中的消息通过在链的上方或下方添加一个短箭头来表示，通常需要使用阿拉伯数字作为序号来表示通信图中发送消息的顺序。

通信图与顺序图的异同点:

通信图与顺序图的共同点主要有如下3点：

1）主要元素相同。两种图中的主要元素都是对象与消息，且都支持所有的消息类型。

2）表达语义相同。两种图都是对系统中的交互建模，描述了系统中某个用例或操作的执行过程，二者的语义是等价的。

3）对象责任相同。两种图中的对象都担任了发送者与接收者的角色并承担了发送与接收消息的责任。通过对象之间消息的传递来实现系统的功能。

两种图之间的不同点也有如下3点：

1）通信图偏重于将对象的交互映射到连接它们的链上，这有助于验证类图中对应的类之间关联关系的正确性或建立新的关联关系的必要性。然而顺序图偏重描述交互中消息传递的逻辑顺序。因此通信图更适用于展示系统中的对象结构，而顺序图则擅长表现交互中消息的顺序。

2）顺序图可以显式地表现出对象创建与撤销的过程，而在通信图中，只能通过消息的描述隐式地表现这一点。

3）顺序图还可以表示对象的激活情况，而对于通信图来说，由于缺少表示时间的信息，除了对消息进行解释，无法清晰地表示对象的激活情况。

通信图与顺序图对比

　　　　　　　　　　　　　　　　时序图

　　　　　　　　　　　　　　　　通信图

通信图建模技术

按组织对控制流建模

　　识别交互的语境，即交互所处的环境。

　　识别出图中应该存在的对象。

　　识别可能有消息传递的对象并设置链。

　　设置对象间的消息。

　　如果需要更多约束，如时间或空间的约束，可以使用其他的约束来修饰这些消息。

案例（1）添加新书

案例（2）学位初评

　　教务人员通过学号在学位初评系统查询学生的初评情况。学位初评系统分别在成绩管理系统、奖罚管理系统、毕业设计管理系统查询成绩、奖罚、毕业设计情况。并根据情况生成学位初评结果，通过信息打印模块打印初评情况。

案例（3）登录系统

案例（4）添加用户信息

顺序图的概念: 顺序图是按时间顺序显示对象交互的图。它显示了参与交互的对象和所交换信息的先后顺序，用来表示用例中的行为，并将这些行为建模成信息交换。

顺序图是一种交互图，强调消息的时间顺序，亦称时序图

顺序图主要包括四个元素：对象、生命线、激活和消息。

在UML中，顺序图将交互关系表示为一张二维图。

其中纵向是代表时间维度，时间向下延伸，按时间依次列出各个对象所发出和接收的消息。水平方向是代表对象的维度，排列着参与交互的各个独立的对象。

顺序图的三种主要作用：

1）细化用例的表达。本章前面我们已经提到，使用顺序图的一大用途，就是讲用例所描述的需求与功能转化为更加正式、层次更加分明的细化表达。

2）有效地描述类职责的分配方式。我们可以根据顺序图中各对象之间的交互关系和发送的消息来进一步明确对象所属类的职责。

3）丰富系统的使用语境的逻辑表达。系统的使用语境即为系统可能的使用方式和使用环境。

顺序图的组成元素：对象、生命线、激活、消息。

对象

　　顺序图中的对象与对象图中的概念一样，都是类的实例。顺序图中的对象可以是系统的参与者或者任何有效的系统对象。

　　对象的创建由头符号来表示，即在对象创建点的生命线顶部使用显示对象名和类名的矩形框来标记。

　　在位置上，一个被放置于顺序图顶端的对象，意味着在这个交互的开始之前，我们已经拥有这样一个对象了。如果一个对象出现在其它位置上（不在顶端），则说明这个对象是在交互执行到某些步骤的时候被创建出来的。被创建出来的对象可以在接下来的时间里被其它对象的消息所激活，也可以以同样的方式被销毁。

生命线

　　生命线代表了一次交互中的一个参与对象在一段时间内存在。具体地说，在生命线所代表的时间内，对象一直是可以被访问的——可以随时发送消息给它。

　　在顺序图中，生命线位于每个对象的底部中心位置，显示为一条垂直的虚线，与时间轴平行，带有一个显示对象的头符号。

　　对于在交互过程中被创建的对象，其生命线从接收到新建对象的消息时开始。对于在交互过程中被销毁的对象，其生命线在接收到销毁对象的消息时或在自身最后的返回消息之后结束，同时用一个“X”标记表明生命线的结束。

激活

　　激活，又称为控制焦点，表示一个对象执行一个动作所经历的时间段，既可以是直接执行，也可以是安排下级过程执行。同时，激活也可以表示对应对象在这段时间内不是空闲的，它正在完成某个任务，或正被占用。

　　激活在UML中用一个细长的矩形表示，显示在生命线上，如图8-5所示。矩形的顶部表示对象所执行动作的开始，底部表示动作的结束。

消息

　　除了以上这些消息类型以外，Rose还扩充了两种消息类型，分别是阻止消息与超时消息。

　　　　阻止消息：当消息的发送者传递消息给接收者，如果接收者无法立即接收，则发送者放弃该消息。

　　　　超时消息：若发送消息后接收者无法在指定时间内接收，则发送者放弃该消息。

顺序图中的结构化控制

在UML 2中，顺序图提供了“片段” 机制，可以通过顺序图来表达更加复杂的动作序列。

可选片段：关键字为opt，表示一种单条件分支。

条件片段：关键字为alt，表示一种多条件分支。

并行片段：关键字为par，表示片段内有多个并行子片段的片段。

循环片段：关键字为loop，表示一个循环。

交互片段：关键字为ref，表示对一段交互的引用。

顺序图建模技术

按时间顺序对控制流建模：

　　设置交互的语境。交互语境即交互所在的环境，包括交互属于那个系统、子系统，包含哪些类和对象，对应于哪个用例或协作的脚本等。

　　设置交互的场景，即识别对象在交互中扮演的角色，根据对象的重要性排列对象的顺序。

　　为对象设置生命线。

　　按时间顺序排列消息。

　　设置激活期。

　　附加时间和空间约束。

　　设置前置与后置条件。

补充

顺序图的变体——时间图

时间图是UML 2中新增加的图，相当于另一种显示顺序图的方法。

时间图与顺序图的主要不同之处有：

1）时间轴与对象轴交换了位置。在时间图中，纵向表示不同对象，横向表示时间的延伸。

2）不同对象的生命线在独立的矩形框中显示，矩形框纵向堆砌成整个图。

3）对象可以有不同的状态。每个对象的状态在其生命线的最左侧纵向排列，生命线通过上下起伏来表示对象当前所处的状态。

4）可以显示一个时间标尺。时间标尺上有时间刻度，用来表示时间间隔。

5）不同对象生命线上的时间是同步的。

建立顺序图的步骤：

1.确定需要建模的工作流

2.从左到右布置对象

3.添加消息和条件以便创建工作流

例子：系统用户注册模块

案例（1）就餐

需求描述如下：

客人到餐厅就餐，服务员提供菜单，客人点菜后把菜单交给服务员。服务员向客人确定菜单后，将菜单提交给大堂经理。大堂经理把菜单提交给大厨，大厨完成菜品后传递给大堂经理，大堂经理安排服务员传菜。有的客人可能需要酒水，有的客人不需要酒水。客人结束用餐后，服务员提供账单，客人结账。

确认对象

确定出现顺序

确定消息

案例（2）ATM机取款

需求描述如下：

　　用户通过ATM机，插入银行卡。系统提示输入密码，用户输入密码。系统检查密码是否正确，密码正确用户选择取款。系统提示输入取款金额。用户输入金额，系统判断其合法性。在获取用户输入金额后，系统开始事物处理，减少账户金额，输出相应现金。

案例（3）成绩查询

需求描述如下：

　　老师通过学号在系统查询成绩，有存在、不存在两种情况。存在显示成绩，不存在显示查无此人。

状态机图

基本概念: 状态机图，UML 1.x规范中称状态图，是一个展示状态机的图。

状态机图基本上就是一个状态机中元素的投影，这也就意味着状态机图包括状态机的所有特征。状态机图显示了一个对象如何根据当前状态对不同事件做出反应的动态行为。

状态机图主要由状态和转换两种元素组成。

状态机

　　状态机是一种行为，它说明对象在其生命周期中响应事件所经历的状态变化序列以及对那些时间的响应。

　　一般情况下，一个状态机依附于一个类，用来描述这个类的实例的状态及其转换，和对接收到的事件所做出的响应。此外，状态机也可以依附于用例、操作、协作等元素上，描述它们的执行过程。

　　状态机从对象的初始状态开始，响应事件并执行某些动作，从而引起状态的转换；在新状态下又继续响应事件并执行动作，如此循环进行到对象的终结状态。

状态机主要由状态、转换、事件、动作和活动5部分组成。

1）状态表示对象的生命周期中的一种条件或情况。

2）转换表示两种状态间的一种关系。

3）事件表示在某一时间与空间下所发生的有意义的事情。

4）动作表示一个可执行的原子操作，是UML能够表达的最小计算单元

5）活动表示状态机中的非原子执行，一般由一系列动作组成。

状态机图作用：状态机图用于对系统的动态方面进行建模，适合描述一个对象在其生命周期中的各种状态及状态的转换。

状态机图的作用主要体现在以下几点：

1）状态机图描述了状态转换时所需的触发事件和监护条件等因素，有利于开发人员捕捉程序中需要的事件。

2）状态机图清楚地描述了状态之间的转换及其顺序，这样就可以方便地看出事件的执行顺序，状态机图的使用节省了大量的描述文字。

3）清晰的事件顺序有利于开发人员在开发程序时避免出现事件错序的情况。

4）状态机图通过判定可以更好地描述工作流在不同的条件下而出现的分支。

状态机图的组成: 简单状态、转换、伪状态。

简单状态

　　状态是状态机图的重要组成部分，它描述了一个对象稳定在的某一个持续过程或所处状况，与动态行为的执行所产生的结果。

　　当对象满足某一状态的条件时，该状态被称为激活的。

　　在UML中，状态分为简单状态与复合状态。

　　　　a.简单状态就是没有嵌套的状态。

　　　　b.初态和终态是两个特殊的状态，分别表示状态机的入口状态和出口状态。对于一个不含嵌套结构的状态机，只能有一个初态，可以有一个或多个终态甚至没有终态。

状态一般由状态名称、子状态、入口动作和出口动作、内部执行活动、内部转换和可推迟事件组成。对于简单状态而言，不会有子状态。

状态名称：可以把一个状态与其他状态分别开来，即状态名称必须在当前层次内保持唯一。没有名称的状态被称为匿名状态。

入口动作与出口动作：由其它状态转移到当前状态或从当前状态转移到其它状态时要附带完成的动作。表示为“entry /动作表达式”和“exit /动作表达式”。

内部执行活动：当对象进入一个状态时，在执行完入口动作后就开始执行该活动。使用“do/活动表达式”来表示。

内部转换：指的是不导致状态改变的转换。内部转换只有源状态而没有目标状态。表示为“事件名称（事件参数）/活动表达式”。

可推迟事件：不会触发状态的转换，且当对象处于该状态时事件可能会被推迟，但不会丢失。格式为“事件名称/defer”。

转换

转换是两种状态间的一种关系。它指明当特定事件发生或特定条件满足时，处于某状态（源状态）的对象将执行某一动作或活动并进入另一状态（目标状态）。

转换表示为从源状态指向目标状态的实线箭头，并附有转换的标签。转换的标签格式如下：

⌊转换名称:⌋opt 事件名称opt ⌊(参数列表)⌋opt ⌊[监护条件]⌋opt ⌊/效果列表⌋opt

转换——转换名

转换名称是转换的标识符。在实际使用中，为了防止转换名称与转换的触发器或监护条件混淆，一般不必为转换命名。

对于一个转换，除了源状态、目标状态外，还要有事件、监护条件和效果列表等内容。这三个部分的内容对转换不是必需的，在使用时要根据转换所表达的具体语义来添加相应内容。

转换——事件

事件是在某一时间与空间下所发生的有意义的事情，是系统执行中发生的值得建模的事物。

事件一般被状态或转换所发送和接收。在转换中被接收的事件也被称为该转换的触发器或触发事件。

事件包含一个参数列表（可能为空），用于从事件的产生者向其接收者传递信息。

对应于触发器转换，没有明确的触发器的转换成为结束转换或无触发器转换，是在状态的内部活动执行完毕后隐式触发的。

能够在触发器中接收的事件有以下四种：

1）调用事件：调用事件表示对象接收到一个调用操作的请求。其期待的结果是事件的接收者触发一个转换并执行相应的操作。

2）改变事件：改变事件的发生依赖于事件中某个表达式所表达的布尔条件。改变事件没有参数，要一直等到条件被满足才能发生。

3）信号事件：信号由一个对象准确地送给另一个或一组对象。发送给一组对象的信号可能触发每个对象的不同转换。

4）时间事件：时间事件的发生依赖于事件中的一个时间表达式。比如，可以让对象进入某状态后经过一段给定的时间或到达某个绝对时间后发生该事件。

转换——监护条件

监护条件是一个转换被激发之前必须满足的一个条件。

监护条件是一个布尔表达式，可以根据触发器事件的参数、属性和状态机所描述的对象的链接等写成。当转换接收到触发事件后，只有监护条件为真，转换才能被激活。

对监护条件的检验是触发器计算过程的一部分，对于每个事件监护条件只检查一次。如果事件被处理时监护条件为假，那么除非再次接收到一个触发事件，将不会再重新计算监护条件的值。

转换——效果列表

效果列表是一个过程表达式，在转换被激活时执行，表示转换附加的效果。

效果列表包括多个动作，可以根据操作、属性、拥有对象的连接、触发器事件的参数等写成。动作可以是一个赋值语句、算术运算、发送事件、调用对象的属性或操作、创建或销毁对象等。

效果的表达语法与其实现的具体内容有关。

例子（1）：简单的状态机图—吃饭状态

做需求时，需要了解以下六种元素：起始、终止、现态、次态（目标状态）、动作、条件，我们就可以完成一个状态机图了

①现态：是指当前所处的状态。

②条件：又称为“事件”，当一个条件被满足，将会触发一个动作，或者执行一次状态的迁移。

③动作：条件满足后执行的动作。动作执行完毕后，可以迁移到新的状态，也可以仍旧保持原状态。动作不是必需的，当条件满足后，也可以不执行任何动作，直接迁移到新状态。

④次态：条件满足后要迁往的新状态。“次态”是相对于“现态”而言的，“次态”一旦被激活，就转变成新的“现态”了。

画状态机图的注意事项：

1、避免把某个“程序动作”当作是一种“状态”来处理。那么如何区分“动作”和“状态”？“动作”是不稳定的，即使没有条件的触发，“动作”一旦执行完毕就结束了；而“状态”是相对稳定的，如果没有外部条件的触发，一个状态会一直持续下去。

2、状态划分时漏掉一些状态，导致跳转逻辑不完整。所以在设计状态机时，我们需要反复的查看设计的状态图或者状态表，最终达到一种牢不可破的设计方案。

例子（2）需求岗工作状态

伪状态

概念：伪状态指的是在状态机中具有状态的形式，却具有特殊行为的顶点。

　　当一个伪状态处于活动时，系统不会处理事件，而是瞬间自动转换到另一个状态，并且这种转换是没有事件进行显式触发的。

最常见的伪状态包括初态、选择、分叉与结合、历史状态等。

　　a.初态：初态实际上不是一个真正的状态，它更像是状态机的入口。初态的具体语义概念是模糊的且是瞬时的，不能存在触发器进行触发，否则对象将可能会长时间停留在一个语义不明的初态中。

　　b.选择是状态机中的一个伪状态节点，用于表达状态机中的分支结构。

　　　　一个选择节点将一个转换分割为两个片段，即将触发事件与监护条件分离。

　　　　选择节点不同分支上的监护条件应该覆盖所有情况，否则状态机将不知道如何运行。

例子（3）订单状态机图

复合状态

概念：复合状态是指包含有一个或多个嵌套状态机的状态。

a.顺序复合状态：当顺序复合状态被激活时，只有一个子状态会被激活。

b.并发复合状态：复合状态中包括两个或多个并发执行的子状态机。

在复合状态中，我们可以先将一部分细小的状态组合成一个状态机，把这个新的状态机作为总状态机图中的一个复合状态来呈现。

顺序复合状态

顺序复合状态又被称为非正交状态，是仅含一个状态机的复合状态。

当顺序复合状态被激活时，只有一个子状态会被激活。它只增加了一层子结构，没有增加额外的并发性。

并发复合状态

并发复合状态，也称正交复合状态，是包括两个或多个并发执行的子状态机的复合状态。

并发复合状态将复合状态分成若干个正交区域，每个区域都有一个相对独立的子状态机。如果该并发复合状态是激活的，那么该状态中每个区域都将有一个状态是激活的。

历史状态

历史状态是应用于复合状态的一种伪状态，它代表上次离开该复合状态时的最后一个子状态。

当一个来自于复合状态外的转换为复合状态内的历史状态时，将使历史状态所记录的子状态被激活。

深历史状态保存的更深的嵌套层次中的子状态。

状态机图的建模技术

为对象的生命周期建模

　　确定状态机的语境。

　　设置状态机的初态和终态。

　　决定该对象的状态机中可能需要响应的事件。

　　从初态到终态，列出这个对象可能处于的所有顶层状态。用转移将这些状态连接起来，明确转移的触发器和监护条件，接着向转移中添加效果动作。

　　识别状态是否需要有入口动作和出口动作。

　　如果需要，使用子状态来对顶层状态进行嵌套。

　　检查状态机中提供的事件是否与所期望的相匹配；检查所有事件是否都已经被状态机所处理。

　　检查状态机中的动作是否能由类或对象的关系、操作等支持。

　　跟踪状态机，确保状态机是良构的，即不存在无法到达的状态，也不会发生停机。

例子（4）音乐播放

例子（5）取消航班

例子（6）系统进程状态机图

案例

新生入学后，学校在三个月内按照国家招生规定对其进行复查。复查合格者予以注册，取得学籍。复查不合格者，学校区别情况予以处理，直至取消入学资格。

学生有如下情况之一者，应予休学：

（一）因伤病经学校指定医院诊断，须停课治疗、休养一学期1/3时间；

（二）一学期请假缺课超过该学期总学时的1/3；

（三）传染性肝炎、肺结核等传染性疾病；

（四）因某种特殊原因，学校认为必须休学。

学生休学至少一学期，一般以一年为限。学生复学后，休学之前已记入成绩档案的考核成绩继续有效，并作为学籍处理依据.

学生复学按下列规定办理：

（一）学生因伤病休学申请复学时，须持有二级甲等以上医院诊断书，证明身体健康，并经学校指定医院复查合格，方可复学；

（二）学生休学期满后应于学期的注册期内持有关证明，经教务处核准后编入原专业相应班级选课学习；

学生有下列情况之一者，应予退学：

（一）学生在读期间，3次出现在一学期中取得的课程学分不足10学分（不含重修和补考学分；毕业学期除外；第一次提出警告，第二次提出退学警告，由教务处公布名单，院系负责通知学生家长）；

（二）休学、保留学籍期满，在规定期限内不办理复学手续；

（三）休学累计满二年，经复查不合格；

（四）因伤病需要休学，经学校动员后仍不办理休学手续；

（五）经学校指定医院确诊患有疾病，或意外伤残无法继续在校学习；

（六）未请假离校连续2周末参加学校规定的教学活动；

(七) 超过学校规定期限未注册而又无正当事由；

（八）本人要求退学。

学生在规定的学习年限（4年制3～6年，5年制4～7年）内修完本专业培养计划规定的全部教学环节，取得注册专业规定的毕业学分，准予毕业，发给毕业证书。

基本概念：是UML中一种重要的用于表达系统动态特性的图

　　活动图的作用是描述一系列具体动态过程的执行逻辑，展现活动和活动之间转移的控制流，并且它采用一种着重逻辑过程的方式来叙述。

　　在对软件密集系统建模的时候，有时需要详细地模拟系统在运作时的业务流程。面对这种需要，我们可以分析对象间发生的活动和触发条件，选用活动图对这些动态方面进行建模。

　　活动图的主要组成元素包括动作、活动、动作流、分支与合并、分叉与汇合、泳道和对象流等。

活动图组成元素：动作和活动节点、开始和终止、控制流、判断节点、合并节点、泳道。

动作和活动节点

　　动作代表一个原子操作，操作可能是任何合法的行为。

　　动作可以是并且不限于：创建或删除对象、发送消息、调用接口，甚至数学运算以及返回表达式的求值结果。

　　活动节点是一系列动作，主要用于实现动作序列的简化和动作图的嵌套。活动节点在图例上的表达方式和动作相同。、

开始和终止

　　活动图中的开始和终止是两个标记符号，分别标记了业务流程的起始位置和结束位置。

　　活动图中必须有且仅有一个开始标记，一般至少有一个结束标记。（存在一些特殊的无穷过程不存在终止标记。）

控制流

　　控制流是活动图中用于标示控制路径的一种符号。它负责当一个动作或活动节点执行完毕后，将执行主体从当前已完毕的节点转移到过程的下一个动作或动作节点。

　　控制流从活动图的开始标记开始运行，经过顺序、分支等结构引导着各个动作的连续执行。

判断节点

　　判断节点是活动图中进行逻辑判断、并创造分支的一种方法。

　　判断节点具有一个进入控制流和至少两个导出控制流。

　　判断节点具有多个导出流，对于每条导出流而言，应当在表示该控制流的箭头上附加控制条件。

合并节点

　　合并节点将多个控制流进行合并，并统一导出到同一个离开控制流。

　　合并节点仅有逻辑意义而没有时间和数据上的意义：几个动作都指向同一个合并节点也并不意味着这些动作要在进入之后互相等待或进行同步数据之类的操作。

泳道

　　泳道是将活动中的具体活动按照负责进行该活动的对象进行分区，一条泳道中的所有活动由同一个对象来执行。

　　除了以上的对线性流程进行分区以外，使用泳道表示法可以更清晰地表示并发。

工时审批流程

员工填写工时，项目工时报项目经理审批后再报部门经理审批、非项目工时直接报部门经理审批。

活动图的高级概念：分叉节点、结合节点、对象流、扩展区域

分叉节点与结合节点

　　分叉节点是从线性流程进入并发过程的过渡节点，它拥有一个进入控制流和多个离开控制流。分叉节点的所有离开流程是并发关系，即分叉节点使执行过程进入多个动作并发的状态。

　　结合节点是将多个并发控制流收束回同一流程的节点标记，功能上与合并节点类似。结合节点的各个进入控制流间具有并发关系，它们在系统中同时运行。

例子：学生选课的活动图

学生选上课后需要上课、复习、考试、查询成绩，查询成绩后可以申请复核、查询复核结果、成绩如果及格庆祝、未通过补考或重修。

对象流

　　对象流是UML为填补活动图与面向对象思想之间的疏离而出现的。如果需要在活动图中表现对象流，则首先需要绘制出泳道，且对象应该作为泳道的负责对象出现。

扩展区域

　　扩展区域是表示过程中的某个活动片段的模型。扩展区域可以将一个需要体现在活动图中的循环过程进行提取（不需要体现在活动图中的，可以直接使用活动节点来略写）。

活动图建模技术

对业务流程建模

　　选择一个将要描述的重要过程，过程中尽量涉及数量少但是关键的对象或参与者，将无关或关联很小的对象排除在外，为每一个对象或参与者绘制泳道。

　　在总体业务流程中提取关键的动作或活动节点，并且将他们与对象或参与者相对应；若发现有些动作无法对应，则考虑动作是否在这个流程中起关键作用，或者是否遗漏了某些对象或参与者。

　　规定初始状态；确定过程可能的结束位置，为活动图添加开始和结束节点。

　　从业务流程的开始节点开始，把过程中发生的动作按事件顺序排列，依次把这些动作添加到活动图中。

　　把局部的过于复杂的动作序列加以总结，绘制成一个活动节点；如果需要，把这个动作序列使用另外的活动图进行建模。

　　找出连接这些动作和活动节点的控制流，并且准确找到过程中的分支、分叉、合并与结合节点。

　　如果业务流程中有一些关键对象的值或状态需要加以描述，使用对象流添加这些对象在某些动作或活动节点前后的状态描述。

对用例交互建模

　　选择概念用例——即从系统对客户提供的各种服务中确定出一个关键业务，这个关键业务可能是在多个相同或不同的情况下反复出现，或者是系统需要提供的一个关键服务或进行的关键操作。

　　对于当前选择的用例，通过事件流进行顺序叙述，并找出所有的参与者主动动作，把这些动作整理成动作或活动节点。

　　把参与者和系统划分为两个泳道，如果有除了主参与者以外的其它参与者，也为它们分别划分泳道。

　　把活动节点纵向按照事件发生顺序、横向按照参与者角色和系统角色对应填入活动图中。

绘制活动图

　　“活动图” 比较直观易懂；与传统的流程图十分的相近，只要能够读懂活动图，就不难画出活动图

　　绘制时首先决定是否采用泳道：主要根据活动图中是否要体现出活动的不同实施者

　　然后尽量使用分支、分岔和汇合等基本的建模元素来描述活动控制流程

　　如果需要，加入对象流以及对象的状态变化，利用一些高级的建模元素（如辅助活动图、汇合描述、发送信号与接收信号、引脚、扩展区）来表示更多的信息

　　活动图的建模关键是表示出控制流，其它的建模元素都是围绕这一宗旨所进行的补充

例子（1）上班活动图

　　早上起来，心里斗争是否去上班。如果决定睡懒觉，就打电话请假，继续睡觉。如果决定上班，洗漱后出门上班。上班时要决定吃不吃早餐，吃就买早餐在途中食用，不吃就回公司再做打算。

例子（2）汽车租赁

例子（3）客户下单

　　用户下单后，生成送货清单时让客户选择支付方式。若支付成功后，将收款清单和送货地址交到供货商，供货商修改订单状态，如果送货完成则订单完成否则返回供货商。若支付超时、或支付失败，则结束。

基本概念：组件图即是用来描述组件与组件之间关系的一种UML图。组件图在宏观层面上显示了构成系统某一个特定方面的实现结构。

　　组件图中主要包含三种元素，即组件、接口和关系。

　　组件图通过这些元素描述了系统的各个组件及之间的依赖关系，还有组件的接口及调用关系。此外，组件图还可以使用包来进行组织，使用注解与约束来进行解释和限定。

　　组件图在面向对象设计过程中起着非常重要的作用：它明确了系统设计，降低了沟通成本，而且按照面向对象方法进行设计的系统和子系统通常保证了低耦合度，提高了可重用性。

组件图的组成元素：组件、接口、组件图中的关系、组件的内部结构。

组件

　　组件，是系统设计的一个模块化部分，它隐藏了内部的实现，对外提供了一组接口。

　　组件是一个封装完好的物理实现单元，它具有自己的身份标示和定义明确的接口。并且由于它对接口的实现过程与外部元素独立，所以组件具有可替换性。

　　组件在系统中一般存在三种类型，分别为部署组件、工作产品组件和执行组件。

　　　　a．配置组件是构成系统所必要的组件，是运行系统时需要配置的组件。

　　　　b.工作产品组件主要是开发过程的产物，是形成配置组件和可执行文件之前必要的工作产品，是部署组件的来源。工作产品组件并不直接参与到可执行系统中，而是用来产生系统的中间产品。

　　　　c．执行组件代表可运行的系统最终运行产生的运行结果，并不十分常见。

一个ATM机的组件：

系统设计的一个模块化部分

显示界面

读卡机

业务操作----查询、取款、转账、挂失

学校教务系统的组件：

系统设计的一个模块化部分

登录界面、业务动作、层业务实现层

学生管理、教师管理、成绩维护、选课

接口

　　对于一个组件而言，它有两类接口，提供接口与需求接口。

　　　　a.提供接口：又被称为导出接口或供给接口，是组件为其他组件提供服务的操作的集合。

　　　　b.需求接口：又被称为引入接口，是组件向其他组件请求相应服务时要遵循的接口。

端口

　　端口（port）是一个被封装的组件的对外窗口。在封装的组件中，所有出入组件的交互都要通过端口。组件对外可见的行为恰好是它端口的综合。此外，端口是有标识的。别的组件可以通过一个特定端口与另一个组件通信。在实现时，组件的内部组件通过特定的外部端口来与外界交互，因此，组件的每个部件都独立与其他部件的需求。端口允许把组件的接口划分为离散的并且可以独立使用的几部分。端口提供的封装性和独立性更大程度上保证了组件的封装性和可替换性。