《大象：thinking in uml 》(第二版) 4章 UML核心视图

只供参考，喜欢请支持正版图书

如果说UML是一门语言，上一章学习的元素是UML的基本词汇，那么视图就是语法，UML通过视图将基本元素组织在一起，形成有意义的句子。

UML可视化的特性是由各种视图来展现的，每一种视图都从不同的角度对同一个软件产品的方方面面进行展示，说明将要开发的软件到底是什么样子。描述软件和描述现实世界一样，一方面我们需要描述系统的结构性特征，结构决定了这个系统能做什么；另一方面我们需要描述系统的运行时行为，这些行为特征决定了系统怎么做。两者结合起来才能把系统描述清楚。

在UML里，结构性特征是用静态视图来表达的，行为性特征是用动态视图来表达的。下面就来看看UML定义了哪些视图来表达软件的视角。

4.1 静态视图

故名思义，静态视图就是表达静态事物的。它只描述事物的静态结构，而不描述其动态行为。我们将要介绍的静态视图包括用例图、类图和包图

4.1.1 用例图

用例视图采用参与者和用例作为基本元素，以不同的视角展现系统的功能性需求。用例视图是了解系统的第一个关口，人们通过用例视图得知一个系统将会做什么。对客户来说，用例视图是他们业务领域的逻辑化表达，对建设单位来说，用例视图是系统蓝图和开发的依据。

用例视图是用来展现参与者和用例的，因此前提条件是参与者和用例都已经获取，不过在实际中，绘制用例视图和发现用例一般都是并行的，一边发现参与者和用例，一边绘制用例视图，而绘制过程中则有可能回头修改已经获取的参与者和用例。最终，建模者通过用例视图将获得的参与者和用例从某个角度进行展示，表达软件某个方面的视角。一般来说，有以下用例视图：

4.1.1.1 业务用例视图

业务用例视图使用业务主角和业务用例展现业务建模的结果。大多数情况下，业务用例视图需要从业务主角和业务模块两个视角进行展示。

■　业务主角视角
从业务主角视角来展示业务主角在业务中使用哪些业务用例来达成业务目标。这个视角有利于向业务主角确认其业务目标是否都已经齐全，以此来检查是否有遗漏的业务用例没有发现。
图4.1展示了借书管理系统的借阅人业务用例视角，这个视图的含义是借阅人业务主角在借书管理系统中有借阅图书和办理借阅证两个业务目标。如果业务主角认为其所有目标都已经齐全，则认为针对此主角的业务用例定义完成。

■　业务模块视角
从业务模块视角来展示业务领域的业务目标，将参与了达成这一业务目标的业务主角与业务用例展现在这个视图中。这个视角有利于从业务的完整性角度出发，检查完成某个业务的所有业务主角和业务用例是否已经齐全，以此来检查是否有遗漏的业务用例没有发现。

图4.2展示了参与借书业务的所有业务主角和业务用例，这个视图的含义是这些主角和业务用例完整地概括了借书业务的业务目标。如果这项业务能够被这些业务主角和业务用例完整地说明，则认为针对此业务模块的业务用例定义完成。

■　其他视角

例如可以从部门的视角绘制一个部门所参与的全部业务用例视图，或者从一个重要业务实体的生命周期角度，例如一份文件，来描述文件从产生到销毁的整个生命周期过程中涉及的业务主角和业务用例视图。

业务用例视图展现了业务系统的功能性需求，如果要描述这些需求的实现途径，则需要借助下节介绍的业务用例实现视图。

4.1.1.2 业务用例实现视图

业务用例实现视图展现业务用例有哪些实现途径。

业务用例是业务需求，而业务用例实现则是业务的实现途径，从软件工程的角度说，这个视图展示了需求的可追溯特点。在实际工作中，如果一个业务用例只有一个实现途径，那么绘制业务用例实现视图似乎不是那么必要，有点多此一举。但是如果一个业务用例有多种实现途径，则应当绘制业务用例实现视图来组织实现业务的那些业务对象和业务过程。

图4.3展示了借阅图书业务用例的两个业务用例实现，它的含义是借阅人可以到图书馆借阅，也可以通过网上借阅，两个实现途径都达到了同样的借阅图书业务目标

4.1.1.3 概念用例视图

概念用例视图用于展现从业务用例中经过分析分解出来的关键概念用例，并表示概念用例和业务用例之间的关系。一般来说这些关系有扩展、包含和精化。
图4.4展示了借阅图书业务的概念用例视图，它表达的含义是借阅图书业务必须经过检查借阅证、借出图书、归还图书这三个关键业务单元，同时可能需要交纳借阅费用。

概念用例视图不是必需的，如果业务用例是一个复杂的业务，绘制概念用例视图有助于细化和更准确地理解业务用例。同时，概念用例视图也对下一节获取系统用例有很好的帮助。

4.1.1.4 系统用例视图

系统用例视图展现系统范围，将对业务用例进行分析以后得到的系统用例展现出来。

一般来说系统用例视图是以业务用例为单位展现的，即将视图名称命名为业务用例名称。这样做本身就表达了从系统需求向业务需求的映射，保证了过程的可追溯性，因此可以省略从系统用例向业务用例的追溯视图。

系统用例视图就是系统的开发范围。图4.5展示了借阅图书的系统用例视图。
与业务用例实现类似，系统用例也可能有多种实现途径，这些途径是用下一节的系统用例实现视图来表达的。

4.1.1.5 系统用例实现视图

与业务用例实现视图类似，如果一个系统用例有多种实现方式，也应当为其绘制实现视图
图4.6展示了系统用例实现视图，它表达了从系统实现到系统需求的追溯。同时，它表达的含义是每个系统用例都有其实现，其中交纳费用系统用例则有两种实现方式

4.1.2 类图

类图用于展示系统中的类及其相互之间的关系。
本质上说，类图是现实世界问题领域的抽象对象的结构化、概念化、逻辑化描述

实际上，UML解决面向对象的困难的方法源于面向对象方法中对类理解的三个层次观点，这三个层次是概念层、说明层和实现层。在UML中，从开始的需求到最终的设计类，类图也是围绕着这三个层次的观点进行建模的。类图建模是先概念层而说明层，进而实现层这样一个随着抽象层次的逐步降低而逐步细化的过程

4.1.2.1 概念层类图

概念层的观点认为，在这个层次的类图描述的是现实世界中问题领域的概念理解，类图中表达的类与现实世界的问题领域有着明显的对应关系，类之间的关系也与问题领域中实际事物的关系有着明显的对应关系。需要注意的是，概念层类图中的类和类关系与最终的实现类并不一定有直接和明显的对应关系。在概念层上，类图着重于对问题领域的概念化理解，而不是实现，因此类名称通常都是问题领域中实际事物的名称。概念层的类图是独立于实现语言和实现方式的。

图4.7展示了网上购物的业务实体图，这个类图表达了概念层的类观点。说明在问题领域中，网上购物主要由商品、定单、支付卡这几个关键类构成，这几个类的交互能够完成网上购物这个业务目标。

4.1.2.2 说明层类图

说明层的观点认为，在这个层次的类图考察的是类的接口而不是实现，类图中表达的类和类关系应当是对问题领域在接口层次抽象的描述。也就是说，这时候我们不必关心类最终是用什么语言编码的、是用什么设计模式设计的、是遵循什么标准的，我们所关心的只是这样一些类，它们通过接口进行交互，进而完成了问题领域中的业务目标

图4.8展示了网上购物的分析类图，这个类图表达了从计算机的视角来说，网上购物这个业务目标是由哪些类来完成的，这些类的接口保证了这个业务目标的达成

4.1.2.3 实现层类图

实现层观点认为，类是实现代码的描述，类图中的类直接映射到可执行代码。在这个层次上，类必须明确采用哪种实现语言、什么设计模式、什么通信标准、遵循什么规范等。

实现层的类图大概是用得最普遍的，许多人在建模的时候根本没有概念层和说明层的类图而直接跳到实现层类图。原因不是他们确认对问题领域已经足够了解，并且设计经验十分丰富，而通常是因为他们不知道类图还有三个层次的观点。

图4.9展示了J2EE架构实现查询商品功能的类图。可以看到，到了实现层类图，类描述和类关系已经是伪代码级别了。

4.1.3 包图

包图一般都用来展示高层次的观点

在实际项目中，建模过程中获得的元素是非常多的，如果要将这些元素的关系都绘制出来，将如同蜘蛛网一样难以辨别。通过包这个容器来从大到小、从粗到细地建立关系是一种很好的办法。

例如图4.10展示了网上购物的领域包图，它表达了关键业务领域及其依赖关系

图4.11展示了查询商品功能的类层次，它表达了实现类位于哪个层次的软件架构的观点

4.2 动态视图

动态视图是描述事物动态行为的。需要注意的是，动态视图不能够独立存在，它必须特指一个静态视图或UML元素，说明在静态视图规定的事物结构下它们的动态行为。

本节讲述的动态视图包括活动图、状态图、时序图和协作图。

4.2.1 活动图

活动图描述了为了完成某一个目标需要做的活动以及这些活动的执行顺序。UML中有两个层面的活动图，一种用于描述用例场景，另一种用于描述对象交互。

我们使用活动图来描述用例场景，帮助我们认识问题领域，从问题领域中发现关键的对象，然后就应该把活动图中的流程忘掉，而专心研究关键对象的特性。最后，再来验证一下这些关键对象的某个交互结果是否的确能够达到用例场景所描述的业务目标

4.2.1.1 用例活动图

活动图用来描述用例场景，也就是通常所说的业务流程。业务流程一般包括一个基本业务流程和一个或多个备选业务流程，而业务流程则通过多个活动按照一定的条件和顺序执行来推进。活动可以是手动执行的任务，也可以是自动执行的任务，每个活动完成一个工作单元。

图4.12展示了办理登机手续用例的用例场景，这个活动图中用到了活动图中最主要的一些元素，图中给出了标注
■　起始点
起始点标记业务流程的开始。一个活动图，或者说一个业务流程有且仅有一个起始点。

■　活动
活动是业务流程中的一个执行单元。在UML中，活动被赋予了四个特定的事件。entry指进入（启动）活动时要执行的动作（或者类方法）；do指活动执行过程中要进行的动作（或者类方法）；event事件指活动在执行中接收到某个事件时执行的动作；exit指活动在退出（结束）时要进行的动作。

■　判断
判断根据某个条件进行决策，执行不同的流程分支。
■　同步
同步分为同步起始和同步汇合。同步起始表示从它开始多个支流并行执行；同步汇合表示多个支流同时到达后再执行后续活动。
■　结束点
结束点表示业务流程的终止。一个活动图（或者说一个业务流程）可以有一个或多个结束点。
■　基本流
基本流表示最主要、最频繁使用的、默认的业务流程分支。例如，图4.12所示的从开始到结束办理的业务流程
■　支流
支流表示不经常使用的、由某个条件触发的、非默认的业务流程分支。例如，图4.12所示的无行李分支（假设绝大部分客户都需要托运行李）。
■　异常流
异常流表示非正常的、不是业务目标期待的、容错性的、处理意外情况的业务流程分支。例如，图4.12所示的身份核对错误分支。异常流通常导致业务目标的失败。
■　组合活动
如图4.13所示，组合活动可以用嵌套的活动来表示。不过这种方式会导致活动图太复杂而不清晰，建议不使用，宁可另外用一幅活动图来展示这些子活动。
图4.13还展示了一个特殊的返回活动自身的执行顺序。它一般用在条件循环的情况下。

用例活动图用于展示用例场景，一般可理解为业务流程；对象活动图则用于展示对象交互。下面就来学习对象活动图。

4.2.1.2 对象活动图

对象活动图用于展示对象的交互。我们以4.1.2类图一节中的图4.9为例，根据查询商品的对象交互过程绘制出如图4.14所示的对象活动图。
不论是上述的用例活动图还是对象活动图，如果说它是一个业务流程，我们总觉得差了点什么。是的，我们只知道活动的执行顺序，却不知道谁在执行这些活动。这就是下一节将要引入的概念：泳道

4.2.1.3 泳道

泳道，顾名思义，就像一个游泳运动员只能在一个泳道里进行比赛一样，一个对象也只能在一个业务流程中担任一个（或一类）职责。泳道代表了一个特定的类、人、部门、层次等对象的职责区，这些对象在业务流程中负责执行的活动集合构成了它们的职责

我们先来看看原来不太清晰的对象交互图4.14加入泳道后的情况，相比较而言，虽然不如时序图或协作图来得直接，图4.15还是要比图4.14清晰得多了。
即使加入泳道后对象交互图有了些模样，笔者仍然不推荐使用它。泳道最主要的用途是在分析用例场景时用来获取角色职责。让我们看看图4.12办理登机手续活动图加入泳道后的情况，图4.16所示的泳道代表了客户和登机岛服务人员在登机业务流程中各自的职责，它对我们获得角色职责非常有帮助。

上面我们学习了活动图的基本知识，在实际的建模过程中，活动图主要应用于业务场景建模和用例场景建模。下面分别进行讲解。

4.2.1.4 业务场景建模

我们经常以业务主角（客户代表）作为泳道，以从业务主角处获取的业务用例作为活动来编排活动图。这种活动图对我们获取正确的业务用例和检查已经获得的业务用例有着很好的帮助。它能够：
■　帮助发现业务用例
如果用现有的业务用例不能完整地编排出实际的业务流程，那么可能是遗漏了业务用例。

■　帮助检查业务用例粒度
如果用现有的业务用例编排活动图感觉到别扭，那么可能是业务用例的粒度不统一。

■　帮助检查业务主角
如果有些业务主角难以编排进活动图，那么可能是业务主角定义错误。

■　帮助检查业务用例
如果有些业务用例在活动图中用不上，那么可能是业务用例获取错误

4.2.1.5 用例场景建模

获得业务用例之后，我们得到了参与者的业务目标，我们通过用例场景来说明如何达到业务目标。我们经常以业务主角和业务工人作为泳道、以工作单元作为活动来编排活动图来描述用例场景。这种活动图对我们获得概念用例、角色和业务对象（业务实体）有着很好的帮助，图4.16就是一个用例场景活动图。它能够：

■　帮助发现概念用例
概念用例是客户业务中的关键业务。如果发现在多个用例场景中类似的工作单元经常出现，那么可以考虑将它抽象出来，再根据情况采用包含、扩展或者泛化的关系将其连接到基本用例（即它们所贡献的业务用例）。这些概念用例通常构成了业务架构中的关键业务，而那些仅出现一次的工作单元不需抽象成概念用例，它们通常对业务架构仅起到参与作用，不必过于关心

■　助发现角色
通常，一个泳道（业务主角或业务工人）可以缺省地定义一个角色，但是如果多个用例场景中发现同一个或同一类工作单元（活动）位于不同的泳道，即被不同的业务主角或业务工人使用，那么应该考虑为这些使用了同一活动的业务主角和业务工人抽象出更高级别的角色。

■　帮助发现业务实体
我们会发现所有活动都有着相同的命名规则：动词＋名词，这些名词就是很好的业务实体（对象）来源，如图4.16中的机票、登机牌

■　帮助建立领域模型

领域模型描述那些对业务有着重要意义的业务对象。如果在同一个或多个用例场景的不同活动中发现某个名词重复出现，那么应当对这个名词给予重视。它很可能就是一个关键的业务对象，这个业务对象在不同活动中的状态以及它与活动图中其他名词之间的关系很可能就决定了业务的结构。绘制出这个结构就能够获得领域模型

4.2.2 状态图

状态图显示一个状态机。状态机用于对模型元素的动态行为进行建模，更具体地说，就是对系统行为中受事件驱动的方面进行建模。通常使用状态图来说明业务角色或业务实体可能的状态——导致状态转换的事件和状态转换引起的操作。状态图常常会简化对类的设计的确认。对于类的对象所有可能的状态，状态图都显示它可能接收的消息、将执行的操作和在此之后类的对象所处的状态

状态机主要用于描述对象的状态变化以确定何种行为改变了对象状态，以及对象状态变化对系统的影响。我们可以用状态机来描述业务实体对象、分析类对象和设计类对象。通常，状态机用于描述实体类对象的整个生命周期内的状态变迁以获得对这个实体对象的理解，同时获得系统和实体对象相互影响的关系。需要注意的是，状态图通常只用于描述单个对象的行为，如果要描述对象间的交互，最好采用时序图或协作图。

图4.17展示了图书业务实体的状态图。

图4.17中用到了状态图中的一些关键元素，下面分别进行一些解释
■　初始状态
初始状态是状态机的起始位置，它不需要事件的触发。

■　状态
状态是对象执行某项活动或等待某个事件时的条件

■　复合状态
具有子状态（或者称为嵌套状态）的状态被称为复合状态。在复合状态中子状态也可能有一个初始状态和一个终止状态。特别的，当触发事件加载到复合状态时最先进入子状态中的初始状态，这时触发事件不能直接指定子状态，子状态如何变迁由复合状态决定。子状态的终止状态表示退出复合状态。另外，如果需要，子状态可以再嵌套子状态到任意级别。

■　转移
转移是两个状态之间的关系，它表示当发生指定事件并且满足指定条件时，第一个状态中的对象将执行某些操作并进入第二个状态。一般来说，转移总是由一个事件来驱动的，不过有时候转移是不需要事件的。没有事件的转移称为“完成转移”，它表示某个状态的“默认发生”，例如当图书处于借出状态时，它可以默认的转移为“不可借出”状态。

■　事件
事件是一个特定的动作或行为，有时候也包括系统时钟之类的定时器。如果条件满足，事件的发生将触发一个转移

■　条件
条件是一个布尔表达式，当事件发生时将检查这个表达式的值。条件求值结果可能决定转移的分支，或者拒绝转移。条件有可能引用当前状态。

■　最终状态
最终状态表示状态机执行结束，或者对象生命周期结束

4.2.3 时序图

时序图用于描述按时间顺序排列的对象之间的交互模式；它按照参与交互的对象所具有的“生命线”和它们相互发送的消息来显示这些对象。在时序图中包含对象和主角实例，以及说明它们如何交互的消息。

通常我们使用时序图来描述用例实现，通过贡献于该用例实现的对象之间的交互来说明用例是如何被对象实现的。使用时序图来描述用例实现是一种从现实世界到对象世界的映射方法，它对我们确定对象职责和接口有着显著的作用。而对象的核心就是职责和接口。

在4.1.2类图一节中我们提到过类有三个层次的观点：概念层、说明层和实现层，它们分别对应于业务建模阶段、概念建模阶段和设计建模阶段。相应的，也可以在这三个层次上分别对业务实体对象、分析类对象和设计类对象绘制时序图。

下面就结合4.1.2类图一节中三个层次的静态类图来看看时序图如何应用于这三个层次，并且实现网上购物这一业务目标。相应的，三个层次的时序图是业务模型时序图、概念模型时序图和设计模型时序图。

4.2.3.1 业务模型时序图

图4.18展示了图4.7所示业务实体如何实现网上购物过程的时序图。这个时序图对这些业务实体对象如何参与业务提供了非常直观的描述，从图中我们可以非常容易地分辨出对象的职责、生命周期和会话过程。对业务模型时序图的理解将有助于我们了解业务架构
■　对象
表示参与交互的对象。每个对象都带有一条生命周期线，对象被激活（创建或者被引用）时，生命周期线上会出现一个长条（会话），表示对象的存在。

■　生命周期线
生命周期线表示对象的存在，当对象被激活（创建或者被引用）时，生命周期线上出现会话，表示对象参与了这个会话。

■　消息
消息由一个对象的生命周期线指向另一个对象的生命周期线。如果消息指到空白的生命周期线，将创建一个新的会话；如果消息指到已有的会话，表示该对象延续已有会话。

与实际的编程环境相似，消息有许多不同的类型。

为简单消息。简单消息适用于大多数情况。它不强调消息的类型，仅表示一个交互。一般情况下使用简单消息就足够了，除非在设计模型的类交互时需要强调消息类型时才使用其他消息类型

为返回消息。返回消息为源消息的返回体，而非新的消息。一般来说不需要为每个源消息都绘制返回消息，一方面因为默认情况下源消息都有返回，另一方面太多的返回消息会使图变得更复杂

为同步消息。同步消息表示发出消息的对象将停止所有后续动作一直等到接收消息方响应。同步消息将阻塞源消息对象的所有行为。同步消息最为常用，通常程序之间的方法调用都是同步消息

为限时消息。限时消息是同步消息的一种特殊情况。源消息对象发出消息后将等待响应一段时间，在限定时间内还没有响应时，源消息对象将取消阻塞状态而执行后续操作。限时消息也很常用，例如访问一个网站，在限定时间内没有响应时浏览器会显示“找不到指定网址”的信息

为异步消息。异步消息表示源消息对象发出消息后不等待响应，而可以继续执行其他操作。异步消息一般需要消息中间件的支持，如JMS、MQ等

■　会话
会话表示一次交互，在会话过程中所有对象共享一个上下文环境。例如事务上下文、安全上下文等。

■　销毁
销毁绘制在生命周期线上，表示对象生命周期的终止。虽然示例图中绘制了，但销毁也没有必要强

最后，绘制业务模型时序图时要注意：第一，时序图以达成业务目标为准则；第二，这个阶段处于业务阶段，使用的描述语言应当采用业务术语；第三，时序图表达的内容会对将来的分析设计带来帮助，但是相对于编码实现来讲由于太粗略而不能够作为依据。

4.2.3.2 概念模型时序图

概念阶段的时序图采用分析类来绘制，目标同样是实现业务用例。但是，由于分析类本身代表了系统原型，所以这个阶段的时序图已经带有计算机理解

概念用例时序图通常是依据业务模型场景图来绘制的，它将业务模型场景用分析类重新绘制一遍，这样，既保留了实际业务需求，又得到了计算机实现的基本理念。图4.19展示了图4.8所示的说明层类图的一个时序图片段，描述了分析类实现查询商品的过程

4.2.3.3 设计模型时序图

图4.20展示了图4.9所示的实现层类图在J2EE架构下实现查询商品过程的片断。在这个例子中，所有的类和方法都与实际编程无异，已经可以看作是伪代码了

4.2.4 协作图

协作图描述了对象间交互的一种模式；它通过对象之间的连接和它们相互发送的消息来显示参与交互的对象

协作图中可以有对象和主角实例，以及描述它们之间关系和交互的连接和消息。通过说明对象间如何通过互相发送消息来实现通信，协作图描述了参与对象中发生的情况。可以为用例事件流的每一个变化形式制作一个协作图

协作图用于显示对象之间如何进行交互以执行特定用例或用例中特定部分的行为，协作图的建模结果用于获取对象的职责和接口

如果你更在意对象间的结构关系，请选择使用协作图；如果你更在意对象交互的执行顺序，则请选择使用时序图

4.2.4.1 业务模型协作图

业务模型协作图同样采用业务实体来绘制，目标也是实现用例场景。不过有时候协作图并不要求实现完整的场景，只需要将影响对象的关键消息绘制出来即可。因为协作图更在意的是对象的结构及其相互的影响

协作图与时序图相比，对象间的结构一目了然，并且很容易就能知道哪些消息影响了对象（或者说对象需要提供哪些接口）。不过虽然用数字标明了消息的顺序，从图中我们还是很难看出执行的顺序，更无法了解一次完整的会话过程。协作图和时序图展示着对象不同的方面

■　对象
表示参与协作的对象。对象可以指定它的类，也可以直接用空对象表示，在将来再指定它的类。

连接两个对象，表示两者的关联。与类关系不同，协作图中的对象关联是临时关联，即只在本次交互中存在；而类关系是永久关联，例如继承关系不论在什么情况下都是存在的。Rose中还定义了对象关联的可见属性，它们是：
■　消息
协作图中的消息与时序图中的消息定义完全一样。请参看4.2.3.1业务模型时序图一节中关于消息的解释部分。不过在Rose中并不能展示不同消息类型的不同符号，消息类型在打开消息属性对话框时才能看到

■　消息序号
其实消息序号也是消息的一部分，这里分开讲只是为了强调。序号表明消息传递的先后顺序

4.2.4.2 概念模型协作图

4.2.4.3 设计模型协作图

只供参考，喜欢请支持正版图书