第4章 面向对象方法——UML
UML作为一种图形化建模语言，紧紧围绕着“系统都是由客体组成的，它们之间相互作用构成了大千世界各式各样的系统”这一观点，给出表达客体、客体关系的术语以及表达模型的工具。
长期以来，关于如何建造一个软件系统中的模块，先后出现了4中基本观点。第一种观点是以“过程”或“函数”来构造一个模块，使每个模块实现一项功能，由此产生了结构化方法；第二种观点是围绕一个数据结构来构造一个模块，使每个模块实现该数据结构上的操作，由此产生了面向数据结构的软件开发方法；第三种观点是围绕一类事件来构造一个模块，使每个模块能够识别该类事件并对该类事件作出响应，由此产生了事件驱动的软件开发方法；第四种观点是围绕问题域中的一个客体来构造一个模块，使每个模块实现该客体对系统承担的责任，由此产生了当今流行的面向对象方法。
面向对象方法是一种根据客体之间的关系来建造系统模型的系统化方法。
4.1 UML术语表
1.类与对象
类是一组具有相同属性、操作、关系和语义的对象的描述。对象是类的一个实例。通常把类表示为具有3个栏目的矩形，每个栏目分别代表类名、属性和操作。
1）类的属性（Attribute）。类的属性是类的一个命名特性，该特性是由该类的所有对象所共享、用于表达对象状态的数据。
可见性：可见性指明该属性是否可以被其他类（类目）所使用。可见性的值有以下几种：
+ 公有的。该属性可供其他类（类目）使用。
# 受保护的。该属性只有其子类（类目）才能使用。
- 私有的。该属性只有本类的操作才能使用。
~ 包内的。该属性只有在同一包中声明的类（类目）才能使用。
另外，可以使用关键字public、protected和private来表示属性可见性，它们分别表示属性是“公有的”、“受保护的”和“私有的”。
所谓信息隐蔽是指在每个模块中所包含的信息（包括具有特定语义的数据和处理过程）不允许其他不需要这些信息的模块访问。
属性名：属性名是一个表示属性名字的标识串，通常以小写字母开头，左对齐。
类型：类型是对属性实现类型的规约，与具体实现语言有关。
多重性：多重性用于表达属性只的数目，即该类实例的这一特性可以具有的值的范围。
初始值：初始值是与语言相关的表达式，用于为新创建的对象赋予初始值。
性质串：如果说“类型”、“多重性”以及“初始值”都是围绕一个属性的取值而给出的，那么“性质串”则是为了表达该属性所具有的性质而给出的。
UML把属性分为两类，即类范围的属性和对象范围的属性。所谓类范围的属性是指该属性被该类所有对象所共享。在UML中，通过在属性名和类型表达式之下画出一条线段的方式，表达该属性是类范围的属性。
2）类的操作（Operation）。操作是对一个类中的所有对象要做的事情的抽象。
操作可以被其他对象所调用，调用一个对象上的操作可能会改变该对象的数据或状态。从另一个角度来说，操作是对外提供的一种服务。
可见性：如同属性的可见性一样，其值可以有以下几种：
+ 公有的。该操作可供其他类（类目）访问。
# 受保护的。该操作只有其子类（类目）才能访问。
- 私有的。该操作只有本类的操作才能访问。
~ 包内的。该操作只有在同一包中声明的类（类目）才能访问。
操作名：操作名是该操作的标识，是一正文串。通常是以小写字母开头的动词或动词短语。若操作是一个抽象操作，则以斜体字表示。
参数表：参数表用于给出该操作的参数。
返回类型：返回类型是对操作的实现类型或操作的返回值类型的规约，它与具体的实现语言有关。
性质串：性质串给出应用于该属性的特性值。该项可选的，但若省略操作的特性串，就必须省略括号。UML提供了以下标准的性质值：
leaf 指明该操作是“叶子”操作。
abstract 指明该操作是抽象操作。
query 指明该操作的运行不会改变系统状态。
sequential 指明在该类对象中，一次仅有一个控制流。当出现多个控制流时，就不能保证该对象的语义和完整性。
guarded 指明执行该操作的条件，实现操作调用的顺序化，即一次只能调用对象的一个操作，以保证在出现多控制流的情况下，对象具有的语义和完整性。
Concurrent 指明来自并发控制流的多个调用可以同时作用于一个对象的任何一个并发操作，而所有操作均能以正确的语义并发进行。并发操作必须设计成，在对一个对象同时进行顺序或监护的操作情况下仍能正确地执行。
static 指明该操作没有关于目标对象的隐式参数，其行为如同传统的全局过程。
3）关于类语义的进一步表达。
① 详细叙述类的职责（Responsibility）。
② 通过类的注解和/或操作的注解，以结构化文本的形式和/或编程语言，详述注释整个类的语义和/或各个方法。
③ 通过类的注解或操作的注解，以结构化的文本形式，详述注释各个操作的前置条件和后置条件，甚至注释整个类的不变式。
④ 详述类的状态机。
⑤ 详述类的内部结构。
⑥ 类与其他类的协作。
4）类在建模中的主要用途。
在建立系统模型时，问题域中的大量信息均可用类来规约，形成系统模型中具有特定结构的成分。具体地说，类的作用主要有3个。
① 模型化问题域中的概念（词汇）。
② 建立系统的职责分布模型。
③ 模型化建模中使用的基本类型。
在系统建模中，由于类是使用最多的一个术语，因此应是系统中的每一个类成为符合以下条件的结构良好的类：
l 明确抽象了问题域或解域中某个有形的事物或概念。
l 包含了一个小的、明确定义的职责集，并能很好地实现。
l 清晰地分离了抽象和实现。
2.接口（Interface）
接口是操作的一个集合，其中每个操作描述子类、构件或子系统的一个服务。接口表示通常有两种形式。
（1）采用具有分栏和关键字《interface》的矩形符号来表示。
（2）采用小圆圈和半圆圈来表示。其中，左边的圈表示由类提供的接口，简称供接口；右边的半圈表示类需要的接口，简称需接口。
在系统/产品建模中，接口的主要作用可概括为一句话，即对系统/产品中的“接缝”予以模型化。换言之，通过声明一个接口，表明一个类、构件、子系统为其他类、构件、子系统提供了所需要的、且与实现无关的行为；或表明一个类、构件、子系统所要得到的、且与实现无关的行为。
一般来说，接口的类（类目）与该接口之间的实现关系，用带有空三角箭头的虚线表示；接口的类（类目）与该接口之间的使用关系，用带有《use》标记的虚线箭头表示。
在建立系统模型中，若使用接口对系统中那些“接缝”进行模型化时，应注意以下问题：
接口只可以被其他类目使用，而其本身不能访问其他类目。
接口描述类（构件或子系统）的外部可见操作，通常是该类（构件或系统）的一个特定有限行为。这些操作可以使用可见性、并发性、衍型、标记值和约束来修饰。
接口不描述其中操作的实现，也没有属性和状态。据此可见，接口在形式上等价于一个没有属性、没有方法而只有抽象操作的抽象类。
接口之间没有关联、泛化、实现和依赖，但可以参与泛化、实现和依赖。
3.协作（Collaboration）
协作是一个交互，涉及交互的三要素：交互各方、交互方式以及交互内容。在UML中，协作表示为虚线椭圆。
在系统/产品建模中，可以通过协作来刻画一种由一组特定元素参与的，具有特定行为的结构。其中，这组特定元素可以是给定的类或对象，因此，协作可以表现系统/产品实现的一种构成模式。
4.用况（Use Case）
用况是对一组动作序列的描述，系统执行这些动作应产生对特定参与者有值的、可观察的结果。有的书籍把use case翻译为用例。在UML中，把用况表示为实线椭圆。
在系统/产品建模中，用况一般用于模型化系统中的功能行为，是建立系统功能模型的一个重要术语。
5.主动类（Active Class）
主动类是一种至少具有一个进程或线程的类。由此可见，主动类能够启动系统的控制活动，并且，其对象的行为通常是与其他元素行为并发的。
在UML中，主动类的表示与类的表示形式相似，只是多了两条竖线。
在系统/产品建模中，主动类一般用于模型化系统中的并发行为。
6.构件（Component）
构件是系统设计中的一种模块化部件，通过外部接口隐藏了它的内部实现。
在一个系统中，具有共享的、相同结构的构件是可以相互替代的，但其中要保持相同的逻辑行为。构件是可以嵌套的，即一个构件可以包含一些更小的构件。
在系统/产品建模中，构件一般用于表达解空间中可独立标识的成分。换言之，构件这一术语不能用于问题定义。
7.制品（Areifact）
制品是系统中包含物理信息（比特）的、可替代的物理部件。
在软件开发中，制品通常用于代表有关源代码信息或运行时信息的一个物理打包，因此在一个系统中，可能存在不同类型的部署制品，例如源代码文件、可执行程序和脚本。
8.节点（Node）
节点是在运行时存在的物理元素，通常表示一种具有记忆能力和处理能力的计算机资源。一个构件可以驻留在一个节点中，也可以从一个节点移到另一个节点。
4.1.2 表达关系的术语
为了表达各类事物之间的相互依赖和作用，即为了表达各类事物之间的关系，UML给出了4个术语，它们是关联（association）、泛化（generalization）、细化（realization）、依赖（dependency）。
通过使用这4个术语，可以表达类目之间各种具有特定语义的关系，构造一个结构良好的UML模型。
1.关联（Association）
关联是类目之间的一种结构关系，是对一组具有相同结构、相同链（links）的描述。链是对象之间具有特定语义关系的抽象，实现之后的链通常称为对象之间的连接（connection）。
关联用一条连接两个类目的线段表示，并可对其命名。如果其结构具有方向性，可用一个实心三角形来指示关联的方向。
如果一个关联只连接两个类目，称为二元关联；如果一个关联连接n个类目，称为n元关联。
为了表达关联的语义，UNL采用了以下途径。
（1）关联名（Name）。关联可以有一个名字，用于描述该关联的一定“内涵”。
（2）导航。对于一个给定的类目，可以找到与之关联的另一个类目，这称为导航。
（3）角色（Role）。角色是关联一端的类目对另一端的类目的一种呈现。当一个类目参与一个关联时，如果它具有一个特定的角色，那么就要显式地给出端点名，以此来给出该类目在关联中的角色。
（4）可见性。通过导航可以找到另一类目的实例，但在有些情况下，需要限制该关联之外的实例通过关联访问相关的对象。
其中，UML通过在角色名前添加符号+、- 、# 和 ~ ，来描述该关联的可见性。
+ ：公共可见的。
- ：对该关联之外的任何对象而言，该端的对象是不可见的。
# ：该端的对象只有另一端“子孙”是可以访问的。
~ ：在同一包中声明的类是可访问的。
（5）多重性（Multiplicity）。类（类目）中对象参与一个关联的数目，称为该关联的多重性。
一般来说，表达多重性的基本格式为下限..上限。其中的下限和上限都是整型值，表达的是一个从下限到上限的整数闭区间。星号（*）可以用于上限，表明不限制上限。
如果多重性只是一个整型值，那么该值是一个整数区间的上限。如果多重性是单个“*”，那么表明无穷的非负正整数的范围，即等价于0..*。多重性0..0是没有实际意义的，表明没有实例能产生。
（6）限定符（Qualifier）。限定符是一个关联的属性或属性表，这些属性的值将与该类关联相关的对象集做了一个划分。
（7）聚合（Aggregation）。分类是增强客观实际问题予以的一种手段。通过“一个类（类目）是另一个类（类目）的一部分”这一性质，对关联集进行分类，凡满足这一性质的关联，都称为一个集合。显然聚合是关联的一种特殊形式，表达的是一种“整体/部分”关系。
聚合表示为带有空心菱形的线段，其中空心菱形在整体类那一边。
聚合可以使用多重性，表示各类（类目）参与该聚合的数码。
聚合是对象之间的一种结构关系，不是类（类目）之间的一种结构关系。
（8）组合（Composition）。组合又是聚合的一种特殊形式。如果在一个时间段内，整体类的实例中至少包含一个部分类的实例，并且该整体类的实例负责创建和消除部分类的实例，特别是如果整体类的实例和部分类的实例具有相同的生存周期，那么这样的聚合称为组合。
根据组合的定义，不难得出以下结论：
l 在一个组合中，组合末端的多重性显然不能超过1。
l 在一个组合中，由一个链锁连接的对象而构成的任何元组，必须都属于同一个整体类的对象。
组合表示有3中形式，一种形式是将部分类的名字直接放到整体类的属性栏中；一种是用带有实心菱形的线段，其中实心菱形在整体类那一边；一种形式是将部分类放到整体类的一个栏目中。
（9）关联类。关联类是一种具有关联和类特性的模型元素。一个关联类，可以被看做一个关联，但还有类的特性；或被看做一个类，但有关联的特性。
（10）约束。为了进一步描述关联一段类的性质，UML还给出了6个约束。
① 有序（ordered）：表明类（类目）中实例是有序的。如果没有给出这一约束，就表明是无序的。
② 无重复对象（set）：表明类（类目）中对象是没有重复的。
③ 有重复对象（bag）：表明类（类目）中对象是有重复的。
④ 有序集合（order set）：表明类（类目）中对象有序且无重复。
⑤ 列表（list）或序列（sequence）:表明类（类目）中对象有序但可重复。
⑥ 只读（readonly）：表明一旦一个链由于对象而被添加到所参与的关联中，及作为该关联的一个实例时，该链不能修改和删除。
2.泛化（Generalization）
泛化是一般性类目（称为超类或父类）和它的较为特殊性类目（称为子类）之间的一种关系，有时称为“is-a-kind-of”关系。
在UML中，把泛化表示成从子类（特殊类）到父类（一般类）的一条带空心三角形的线段，其中空心三角形在父类端。
一个类可以有0个、一个或多个父类。没有父类且最少有一个子类的类被称为根类或基类；没有子类的类称为叶子类。
在很多情况里，可以采用委派的方式来代替多继承，即子类仅从一个父类继承，而后通过聚合来获得其他父类的结构和行为。
但要注意，这种处理方式也带来一个问题，即在语义上失去了其他父类的可替换性。
为了进一步表达泛化的语义，UML给出了4个约束。、
① 完整（Complete）：表明已经在模型中给出了泛化中的所有子类，尽管在表达的图形中有所省略，但也不允许增加新的子类。
② 不完整（Incomplete）：表明在模型中没有给出泛化中的所有子类，因此可以增加新的子类。
③ 互斥（Disjoint）：表明父类的对象最多允许该泛化中的一个子类作为它的类型。
④ 重叠（Overlapping）：表明父类的对象可能具有该泛化中的多个子类作为它的类型。
3.细化（Realization）
细化是类目之间的语义关系，其中一个类目规约了保证另一个类目执行的契约。
在UML中，把细化表示为一个带空心三角形的虚线段。
应用中，一般在以下两个地方会使用细化关系：
l 接口与实现他们的类和构件之间。
l 用况和实现他们的协作之间。
4.依赖
依赖是一种使用关系，用于描述一个类目使用另一个类目的信息和服务。
在UML中，把依赖表示为一条有向虚线段，其中，为了讲解方便，把箭头那一端的类目称为目标，而把另一端的类目称为源。
为了进一步表达依赖的语义，UML对依赖进行了分类，并给出了相应的标记。
① 绑定（Bind）：表明源的实例化是使用目标给定的实际参数来达到的。
② 导出（Derive）：表明可以从目标推导出源。
③ 允许（Permit）：表明目标对源而言是可见的。
④ 实例（InstanceOf）：表明源的对象是目标的一个实例。
⑤ 实例化（Instantiate）：表明源的实例是由目标创建的。
⑥ 幂类型（Powertype）：表明源是目标的幂类型。
⑦ 精化（Refine）：表明源比目标更精细。
⑧ 使用（Use）：表明源的公共部分的语义依赖于目标的语义。
按照UML的观点，客观世界一切事物之间的关系都可用依赖来规约，但为了对各种关系赋予特定的语义，采用分类手段将他们分为4类。
关联、泛化和细化都是一类特定的依赖。
使用这4个术语，可以模型化以下各种关系：
（1）结构关系。系统中存在大量的结构关系，包括静态结构和动态结构。可以使用“关联”来模型化这样的关系。
在对系统中各种结构关系进行模型化时，可以采用两种驱动方式。
1）以数据驱动：即对标识的每一个类，如果一个类需要导航到另一个类的对象，那么就要在这两个类之间给出一个关联。
2）以行为驱动：即对所标识的每一个类，如果一个类的对象需要与另一个类的对象进行交互，那么就要在这两个类之间给出一个关联。
（2）继承关系。对于系统中存在的一般/特殊关系，可以使用“泛化”对它们进行规约。
在对系统中一般/特殊关系进行模型化时，应以共同的职责为驱动，发现一组类中所具有的相同职责，继而抽取其共同职责及其相关的共同属性和操作，作为一个一般类，并标明该一般类和这组类之间的泛化关系。
（3）精化关系。对于系统中存在的精化关系，可以使用“细化”对它们进行规约。精化关系一般是指两个不同抽象层之间的一种关系，一个抽象层上的事物通过另一个抽象层上的术语细化，并增加一些必要的细节。
在对系统中的精化关系进行模型化时，应以一个抽象层中的概念为驱动，使用下一抽象层的概念来对其进行细化。
（4）依赖关系。人类在认识客观世界中，最常用的构造方法有3个：一是分类，二是整体/部分，三是一般/特殊。
一般只有在操作没有给出或省略明显的操作标记，或一个模型还需要描述目标类的其他关系的情况下，才把其中的关系模型化为依赖，换言之，如果操作给出了明显的操作标记，一般就不需要给出这个依赖。
4.1.3 表达组合信息的术语——包
为了控制信息组织的复杂性，UML提供了组织信息的一种通用机制——包，支持形成一些可管理的部分。换言之，包可以作为“模块化”和“构件化”的一种机制。
包是模型元素的一个分组。一个包本身可以被嵌套在其他包中，并且可以含有子包和其他种类的模型元素。
在UML中，把包表示为一个大矩形，并且在这一矩形的左上角还有一个小矩形。
通过在包的名字前加上一个可见性符号（+ ，- ，#），来指示该包的可见性。
+ 表示对其他包而言都是可见的。
# 表示对子孙包而言是可见的。
- 表示对其他包而言都是不可见的。
为了模型化包之间的关系，UML给出了两种依赖，即访问和引入，用于描述一个包可以访问和引入其他包。
（1）访问（Access）：表明目标包中的内容可以被源包所引用，或被那些递归嵌套在源包中的其他包所引用。
（2）引入（Import）：表明目标包中具有适当可见性的内容（名字）被加入到源包的公共名称空间中，这相当于源包对它们做了声明，因此对它们的引用就没有必要通过一个路径名。
在UML中，把“访问”和“引入”这两种依赖表示为从源包到目标包的一条带箭头的虚线段，并分别标记为<<access>>和<<import>>。
4.2 UML的模型表达格式
UML的图形化工具分为两类，一类是结构图，用于表达系统或系统成分的静态结构模型，给出系统或系统成分的一些说明性信息；一类是行为图，用于表达系统或系统成分的动态结构模型，给出系统或系统成分的一些行为信息，例如行为的功能性信息，行为的交互信息以及行为的生存状态信息。
1.类图（Class Diagram）
类图是可视化地表达系统静态结构模型的工具，通常包含类、接口、关联、泛化和依赖关系等。
2.用况图（UseCase Diagram）
实践经验告诉人们，认识行为的一个有效途径是要从多个视角对其进行抽象。一般来说，一是从（行为）功能的视角，而是从（行为）交互的视角，三是从（行为）生存周期的视角。
用况图是一种表达系统功能模型的图形化工具，其中，一个用况图通常包含6个模型元素，它们是主题（Subject）、用况（Use cases）、参与者（Actor）、关联、泛化、依赖。
用况图中所包含的内容，确定了一个特定的抽象层，该抽象层决定了系统（或系统成分）模型的形态。
（1）主题（Subject）。主题是一组用况所描述的一个类，通常是一个系统或子系统。在主题中所包含的用况描述了该主题的完整行为，而参与者则表示与该主题进行交互的另一种类。显然这里所说的主题和参与者均是类的变体。
（2）用况（Use Case）。从外延上来说，用况表达了参与者使用系统的一种方式。从内涵上来说，一个用况规约了系统可以执行的一个动作（action）序列，包括该序列的一些可能变体，并对特定的参与者（actor）产生可见的，有值的结果。
（3）参与者（Actor）。参与者表达了一组高内聚的角色，当用户与用况交互时，该用户扮演这组角色。
（4）关联、泛化与依赖。在一个用况图中，关联时一种参与关系，即参与者与一个用况。
在一个用况图中，用况之间可以具有3种关系，即泛化、扩展和包含。泛化是指用况A和用况B之间具有一般/特殊关系；包含是指用况A的一个实例包含用况B所规约的行为；扩展是指一个用况A的实例在特定的条件下可以由另一用况B所规约的行为予以扩展，并依据定义的扩展点位置，B的行为被插入到A的实例中。其中包含和扩展是依赖的变体，分别记为<<include>>和<<extend>>。
3.状态图
状态图是显示一个状态机的图，其中强调了从一个状态到另一个状态的控制流。一个状态机是一种行为，规约了一个对象在其生存期间因响应事件并作出响应而经历的状态。
状态图中所包含的内容，确定了一个特定的抽象层，该抽象层决定了状态图表达的模型形态。
（1）状态。一个状态是一个类目的一个实例在其生存中的一种条件（condition）或情况（situation），期间该实例满足这一条件，执行某一活动或等待某一消息。
一个状态表达了一个实例所处的特定阶段、所具有的对外呈现（外征）以及所能提供的服务。一个对象的所有状态是一个关于该对象的“生存历程”的偏序集合，刻画了该对象的生存周期。
在UML中，通常把一个状态表示成一个具有圆角的矩形。
UML把状态分为3类，即初态、终态和通常状态。初态和终态是两种特殊的状态。初态表达状态机默认的开始位置，用实心圆来表示；终态表达状态机的执行已经完成，用内含一个实心圆的圆来表示。实际上，初态和终态都是伪状态，即只有名字的状态。
一个活动是指状态机中一个可中断的计算，中断处理后仍可继续；而一个动作是指不可中断的原子计算，它可导致状态的改变或一个值的返回。一般来说，一个活动往往是由多个动作组成的。
为了有效地组织状态，控制对象状态的复杂性，UML提供了组合状态。如果在一个状态机中引入了一个状态机，那么被引入的状态机就被称为子状态机。子状态是被嵌套在另一状态中的状态。相对地，把没有子状态的状态称为简单状态；而把含有子状态的状态称为组合状态。组合状态可包含两种类型的的子状态机，即顺序子状态机（非正交）和并发子状态机（正交）。
（2）事件。一个事件是对确定的时空内一个有意义发生的规约。在状态机的语境下，一个事件就意味着存在一个可能引发状态转移的激励。
在UML中，可以把信号、调用、时间和变化模型化为事件，分别称为信号事件、调用事件、时间事件和变化事件。
1）信号（Signal）事件。信号是消息的一个类目，是一个消息类型。像类一样，信号可以有属性（以参数形式出现）、操作和泛化。
信号事件是一种异步事件，信号通常由状态机处理。
2）调用（Call）事件。调用表示对象接受到一个操作的请求。
调用事件往往是一个同步事件，即发送者和接受者都处在该操作执行期间的一个汇合点上，发送者的控制流一直被挂起直到该操作执行完成。但可以把调用规约为异步调用。
3）时间事件。时间事件是表示推移一段时间的事件。
4）变化事件。变化事件表示状态的一个变化，或表示某一条件得到满足。
（3）状态转移。除以上讲述的状态和事件外，状态转移是状态图的一个重要元素。
状态转移是另个状态间的一种关系，意指一个对象在一个状态中将执行一些确定的动作，当规约的事件发生和规约的条件满足时，进入第二个状态。
描述一个状态转换，一般涉及5个部分。
① 源状态：发生状态转移的那个状态。
② 转移触发器：在源状态中由对象识别的事件，并且一旦满足其监护条件，则使状态发生转移。
③ 监护（guard）条件：一个布尔表达式，当某个事件触发器接收一个事件时，如果该表达式有值为真，则触发一个转移；若值为假，则不发生状态转移，并且此时如果没有其他可以被触发的转移，那么该事件就被丢失。
④ 效应（effect）：一种可执行的行为。例如可作用于对象上的一个动作，或间接作用于其他对象的动作，但被效应所影响的其他对象对该效应所属对象是可见的。
⑤ 目标状态：转移完成后所处的状态。
在UML中，把状态转移表示为从源状态出发、并在目标状态上终止的带箭头的实线。
4，顺序图
顺序图是一种交互图，即由一组对象以及按时序组织的对象之间的关系组成，其中还包括这些对象之间所发送的消息。
顺序图中所包含的内容，确定了一个特定的抽象层，该抽象层决定了系统（或系统成分）模型的形态。
（1）术语解析。
1）消息。消息是用于表达交互内容的术语。在UML中，把消息表示为一条箭头线，从参与交互的一个对象的生命线指向另一个对象的生命线。如果消息是异步的，则用枝形箭头线表示；如果消息是同步的（调用），则用实心三角形箭头线表示；同步消息的回复用枝形箭头虚线表示。
2）对象生命线。对象生命线用于表示一个对象在一个特定时间段中的存在。对象生命线被表示为垂直的虚线。一条生命线上的时序是非常重要的，使消息集合称为一个关于时间的偏序集。
3）聚焦控制（the Focus of Control）
聚焦控制用于表达一个对象执行一个动作的时间段。聚焦控制表示为细高矩形。根据需要，可以使用嵌套的聚焦控制。
（2）控制操作子。为了控制交互行为描述的复杂性，以便更清晰地表达顺序图中的复杂控制，UML给出了4中最常用的控制操作子。
1）选择执行操作子（Operator for Optional Execution）。该控制操作子记为“Opt”，由两部分组成，一是监护条件，二是控制体。
2）条件执行操作子（Operator for Conditional Execution）。该控制操作子记为“alt”，控制体通过水平线将其分成一些部分，每一部分表示一个条件分支，每个分支有一个监护条件。
3）并发执行操作子（Operator for Parallel Execution）。该控制操作子记为“par”，该控制操作子的体通过水平线将其分为多个部分。每一部分表示一个并行计算。在大多数情况下，每一部分涉及不同的生命线。该控制操作子表明，当进入该控制操作子时，所有部分并发执行。
4）迭代操作子（Operator for Iterative Execution）。该控制操作子记为“loop”。其中一个监护条件出现在控制体中一条生命线的顶端。该控制操作子表明，只要在每一次迭代至二千该监护条件为真，那么该控制体就反复执行；当该体上面的监护条件为假时，控制绕过该控制操作子。