---

1 用例图

OOAD，Object Oriented Analysis Design，面向对象的分析和设计。

用例是OOAD中最常用的分析技术，系统分析师使用用例之后通常有两个结果：

• 提交用例图(use case diagram)
• 完成用例描述(use case narrative)

在实际应用中，用例与用例描述二者缺一不可。下面是订购书籍的一个用例图：

下面是订购书籍的用例描述：

用例图定义了系统的功能需求，它完全是从系统外部观看系统功能，并不描述系统内部对功能的具体实现。用例图描述的是用例、参与者以及它们之间的关系。UML符号如下：

用例是一种系统分析技术，使用用例图进行分析时，要先确定系统边界，具体的做法是：先区分内外，然后向系统内找用例，最后向系统外找参与者。

1.1 参与者

参与者(Actor)是与系统交互的外部实体。参与者既可以是使用该系统的用户，也可以是与系统交互的其他外部系统、硬件设备或组织结构。如下：

参与者之间可以存在泛化的关系，类似的参与者可以利用泛化关系组成一般与特殊的层次结构，如下：

1.2 用例

用例(Use Case)从用户角度描述系统的行为，它将系统的一个功能描述成一系列事件，这些事件最终对参与者产生有价值的可观测的结果。用例可以促进与用户的沟通、理解正确的需求，同时也可以用来划分系统与外部实体的界限。用例之间的关系有：

1、包含(include)。包含关系是指一个基本用例的行为包含了另一个用例的行为。包含关系是对用例之间的共性部分进行建模。UML符号如下：

2、扩展(extend)。在执行过程中，用例可能会出现异常行为，也可能会在不同的流程分支中选择性地执行用例，这时可以将异常行为或可选分支抽象成一个单独的扩展用例，它与主用例之间形成扩展关系。UML符号如下：

3、泛化(generalization)。泛化描述的是用例之间一般与特殊的关系，不同的子用例代表了父用例的不同实现方法。UML符号如下：

以上三种关系的比较如下：

下面给出一个案例。

某银行管理系统分为顾客业务和银行管理员操作两类实体。其中：

• 顾客实体包含登陆、查询、存款、取款等主要业务，其中顾客取款时会打印凭据，存款和取款都会同时更新银行系统数据库信息。
• 银行管理员实体包含系统登录、生成业务报表、取现金、补充现金、管理员查询等主要功能，其中查询继承了管理员查询的功能。

1、分析某银行管理系统的实体，有：顾客实体和管理员实体，如下：

2、分析实体之间的关系：顾客实体和管理员实体都是系统的使用者，是系统使用者实体的泛化。如下：

3、分析实体所具有的属性：

(1)顾客：

(2)管理员：

4、最终的用例图：

1.3 用例描述

用例描述采用自然语言来描述参与者与系统进行交互时双方的行为。用例描述的主要内容有：用例的目的、用例如何被启动、参与者与用例之间的事件流(包括基本流与可选流)、前置条件、后置条件、扩展点等。

需要说明的是，在用例描述中应该只描写“可观测的”结果，并且使用主动语句，句子的主语应该是参与者或者系统，不要涉及系统的实现细节，也不要涉及界面的细节。

1.4 一个示例

下面通过一个书店系统的用例图设计来进行实战演练(下面有很多图我也没搞懂，乱糟糟的)。

1、参与者的问题列表如下：

2、回收的问题列表如下：

3、有三种参与者：

4、参与者特性如下：

5、参与者种类(与3有部分是重合的)如下：

6、系统简述如下：

7、跟顾客有关的用例如下：

8、用例的问题列表如下：

9、顾客买书的流程如下：


10、如下：

11、用例要点表如下：

12、如下：

13、如下：

14、如下：

15、如下：

16、如下：

17、如下：

18、如下：

19、如下：

20、如下：

21、如下：

【1.4 一个示例】这一节有很多图我也没搞懂，乱糟糟的。

---

2 顺序图

2.1 基本概念

用例图用来描述系统需求，类图用来描述组成系统结构的各种类型。但单凭用例和类还无法描述系统实际上的运行情况。使用交互图可以对其进行补充，为系统各部分交互进行建模。

交互图(interaction diagram)通常用来描述一个用例或者多个用例的行为，显示该用例中所涉及的对象和这些对象之间的消息传递情况，即对动态交互行为进行建模。交互图包括顺序图(sequence diagram)和协作图(collaboration diagram)两种形式。顺序图显示了一组对象和由这组对象发送和接受的消息，着重描述对象之间消息交换的时间顺序。顺序图详细而直观地表现了一组相互协作的对象在执行一个(或少量几个)用例时的行为依赖关系，以及服务和消息的时序关系。顺序图的用途如下：

1、帮助分析员对照检查每个用户状况中描述的用户需求是否已经落实到某些对象的实现中去，提醒分析员去补充遗漏的对象类或服务。

2、帮助分析员分析哪些对象是主动对象。

3、通过对一个特定群体的动态方面建模，深刻理解对象之间的交互。

顺序图将交互关系表示为一个二维图。下面是一个示例：

其中，有：

1、横轴代表了在协作中各个独立的对象。

2、纵轴是时间轴，时间沿竖线向下延伸。

3、沿时间方向按时间递增顺序列出各个对象所发出和接收的消息。

2.2 组成部分

顺序图由对象、生命线、激活、消息组成。

2.2.1 对象

顺序图中对象的符号和对象图中对象所用的符号一样。对象的命名方式有3种，分别为：

1、对象名和类名。

2、类名(此时为匿名对象)。

3、对象名(此时不关心类)。

其符号表示分别如下：

2.2.2 生命线

每个对象都有自己的生命线，生命线在顺序图中表示为从对象图标向下延伸的一条虚线，表示对象在特定时间内存在。符号表示如下：

如果目标对象的生命结束，则用注销符号"×"表示。

2.2.3 激活

对象生命线上的窄矩形条称为激活，激活表示该对象正在执行某个操作，激活的长短表示执行操作的时间。一个被激活的对象要么执行自己的代码，要么等待另一个对象的返回结果。激活在顺序图中不能单独存在，必须与生命线连在一起使用，当一条消息传递给对象的时候，该消息将触发该对象的某个行为，此时该对象就被激活了。

矩形的顶点是消息和生命线交汇的地方，表示对象从此时开始获得控制权，而矩形的底部表示此次交互已经结束，或者对象的控制权已经交出。

符号表示如下：

2.2.4 消息

消息定义的是对象之间某种形式的通信，它可以激发某个操作、发送信号或导致目标对象的创建或撤销。消息是两个对象之间的单路通信，是从发送方到接收方的控制信息流，从源对象指向目标对象，用于触发目标对象中的特定操作。消息可以用于在对象间传递参数。

在UML中，消息使用箭头来表示，箭头的类型表示了消息的类型。UML中有7种消息及对应的符号表示，如下：

1、消息(Simple)消息。

2、同步(Synchronous)消息。调用消息的发送者把控制传递给消息的接受者，然后发送者停止活动并进入等待状态，直到消息接收者执行某种操作并返回控制后才继续活动。

3、异步(Asynchronous)消息。消息发送者在消息发送后继续自己的操作，不需要等待消息接收者。常用于并发。

4、阻止(Balking)消息。消息发送者发送消息给接收者后，如果接收者无法立即接收消息，则发送者放弃继续发送这个消息。

5、超时(Timeout)消息。消息发送者发送消息给接收者后，按指定时间等待，如果接收者无法在指定时间内接受消息，则发送者放弃发送这个消息。

6、过程调用(Procedure Call)消息。

7、返回(Return)消息。

2.3 对象的创建和销毁

如果对象位于顺序图的顶部，说明在交互开始之前该对象就已经存在了。如果对象是在交互的过程中创建的，那么它应当位于图的中间部分。在顺序图中，创建对象操作的执行使用消息的箭头表示，箭头指向被创建对象的框。如果要撤销一个对象，只要在其生命线终止点放置一个“×”符号即可。

下面是一个示例：

2.4 顺序图的建模步骤

1、确定交互范围。

2、识别参与交互活动的对象和活动者。

3、设置对象生命线的开始和结束。

4、设置消息。

5、细化消息。

2.5 一个示例

下面是一个示例——自动饮料售货机“买饮料”场景。

假设自动饮料销售机有3个部分：

1、前端(front)：

• 接受顾客的选购和现钞；
• 显示诸如Out of selection(所选饮料已售完)和User correct change(使用合适零钱)等信息；
• 从记录仪接收找回的零钱并返还给顾客。

2、钱币记录仪(register)：

• 从前端获取顾客输入的信息(即选购的饮料的种类和现钞)；
• 更新现钞存储；
• 如果缺少零钱，将不让系统服务，并在前端显示没有零钱；若零钱充足则正常地找零钱。

3、分配器(dispenser)：

• 负责检查选购的饮料是否还有货；
• 分发一罐饮料。

在饮料售货机购买饮料的所有情况中，都需要顾客往前端放入金钱，由钱币记录仪判定钞票面额。

场景1：理想状态下买饮料，顾客塞入合适的零钱，顾客选的饮料还有存货，买饮料的顺序如下：

• 顾客从机器前端的钱币口塞入纸币，然后选择想要的饮料。
• 钱币到达钱币记录仪，记录仪更新自己的现钞存储。
• 分配器检查饮料是否还有存货，记录仪通知分配器分发一罐饮料到机器前端。

对应的顺序图如下：

场景2：在场景1的基础上，饮料卖完。对应的顺序图如下：

场景3：顾客投入的钱需要找钱，饮料机里有可用零钱，有所选饮料的情况。对应的顺序图如下：

---

3 状态图

状态图建立的是软件系统的行为模型。状态是任何可以被观察到的系统行为模式，一个状态代表系统的一种行为模式，它规定系统对事件的响应方式有三种：

1、改变一个或一些动作。

2、改变系统本身的状态。

3、既改变状态又做动作。

状态图中3种状态的符号如下：

事件是指某个特定时刻所发生的事情，是引起系统做动作或状态发生转换的控制信息。

状态图的表示符号如下：

上图表明系统在初始事件的驱动下，由初始状态转移到状态1，又在事件表达式所对应事件的驱动下到达状态2，最后在结束事件的作用下到达终止状态。

活动表的语法格式是：事件名(参数表)/动作表达式。例如：do/振铃。活动表常用的3种标准事件：

1、entry：指定进入该状态的动作。

2、exit：退出该状态的动作。

3、do：在该状态下执行的动作。

事件表达式的语法是：事件名(参数名)[守卫条件]/动作表达式。其中，守卫条件是一个布尔表达式，表示仅当该条件为真时，状态转换才发生；动作表达式是一个过程表达式，当状态转换开始时执行该表达式。

示例1：电梯状态转换图：

示例2：热水壶工作的状态图：

---

4 活动图

4.1 初步认识

在【1 用例图】一节中，用文本描述了用例的流程。文本描述的优缺点如下：

1、好处：易于创建和修改(不需要复杂的工具)，在任何地方均可创建(只需纸和笔)，容易由业务和开发人员使用和分享。

2、坏处：用文字描述复杂用例，业务过程和算法可能难以理解。

复杂流程用可视化来表示效果更好，这样易看到一些潜在的问题，用文本描述则不易看到这些问题。活动图提供了活动流程的可视化描述，可以被用在系统、业务、工作流或其他过程中。活动图关注被执行的活动以及由谁负责执行这些活动，图的组成元素包括动作节点、控制节点和对象节点。

有三种类型的控制节点：

• 初始节点，和终止节点(分为活动终止和流程终止)。
• branch和merge。
• fork和join。

4.2 基本概念

4.2.1 动作

在活动图中，动作是行为的基本单元。下图展示了水培园艺系统案例中执行的一个动作——检查储水量(Check Tank Levels)：

上图右下角的耙形符号表示callBehavior类型的动作，是对象和链接操作、计算以及对象间的通信进行建模的简单动作，它会调用一个活动，该活动由动作节点、控制节点和对象节点组成，比如“检查储水量”这个动作需要调用“查看报告”这个活动。高层活动图的大部分动作都属于该类型。

4.2.2 开始与终止

活动图展示了一个处理流程，且必须有开始和结束。开始节点被表示为一个实心圆点，终止节点被表示为一个牛眼似的圆点(如下图右面的那个)。下面是一个简单的活动图，仅由动作Check Tank Level构成：

还有另一种类型的终止节点，即流程终止节点，用于停止一个流程，但不会停止整个活动，将在下面merge的讨论中介绍。

4.2.3 branch和merge

branch和merge被用来控制活动图中的流程，每种节点都由一个菱形来表示，带有进入和离开的箭头。其中：

1、branch具有一个进入和多个离开流程，离开流程通常有一些警戒条件，用于选择离开的路径，branch上没有等待和同步。如下图的水培园艺系统中，在检查水箱容量之后进行判断，如果各指标在可允许的范围之内，则终止活动，否则发出警铃：

2、merge接受多个进入进程，全部导向一个离开进程，merge上没有等待和同步。如下图的水培园艺系统中，不论三个进入流程中的哪一个到达merge，都会通过它被导向Log System Event动作，因此多个事件都被计入日志，最后是一个流程终止节点：

4.2.4 分区

活动图中的元素可以利用分区来进行分组，分区的目的是说明执行具体活动的责任。其中：

1、在业务模型中，分区可以是一个业务单位、部门或组织机构。

2、对于系统来说，分区可以是其他系统或该系统的子系统。

3、在应用建模中，分区可以是应用中的对象。

4、每个分区都可以被命名，代表具体的负责者。

下面是一个示例。

水培园艺系统中“维护储水箱”用例规格说明：

1、用例名称：维护储水箱。

2、用例目的：提供了维护储水箱中储水量的功能，让执行者维护一组水箱和营养液箱。

3、一般流程：

• 执行者首先执行步骤A-D：
  A.执行者检查出水箱的当前容量。
  B.执行者决定水箱是否需要加注。
  C.水箱正常的水培园艺系统操作被执行者挂起。
  D.执行者选择水箱并设置加注量。
• 对于每个选定的水箱，执行步骤E-G。
  E.如果水箱正在加热，系统停止加热器。
  F.系统加注水箱。
  G.当水箱加注完成后，如果水箱是不在加热的，系统启动加热器。
• 对于每个选定的营养液箱，执行步骤H。
  H.系统加注营养液箱。
• 在水箱和营养液箱的操作都完成之后，执行者执行步骤I。
  I.执行者继续正常的水培园艺系统操作。

则有以下内容。

责任划分：

1、执行者(Gardener)

2、水箱(Water Tank)

3、营养液箱(Nutrient Tank)

动作：

1、检查储水箱容量(Check Tank Levels)

2、系统操作被挂起(Suspend Operations)

3、设置加注量(Set Fill Levels)

4、停止加热(Disable Heating)

5、加注(Fill)

6、启动加热(Enable Heating)

7、恢复操作(Resume Operations)

4.3 高级概念

4.3.1 fork、join、并发

在操作系统中，并发是指一个时间段中有几个程序都处于已启动运行到运行完毕之间，且这几个程序都是在同一个处理机上运行，但任一个时刻点上只有一个程序在处理机上运行。

branch和fork节点的异同点如下：

1、相同点：branch和fork节点都具有一个进入流程和多个离开流程。

2、不同点：branch选择一个离开流程，而进入fork节点的一个流程会导致多个离开流程，且所有离开流程是并发的。

下面是一个示例：

在上图中，来自Set Fill Levels动作的一个流程进入fork节点，即第一根粗横线。此后Nutrient Tank流程(包含Fill动作)和Water Tank流程(包含Disable Heating、Fill和Enable Heating动作)是并发的。

merge和join节点的异同点如下：

1、相同点：merge和join节点都具有多个进入流程和一个离开流程。

2、不同点：对于merge，不论哪个进入流程到达merge，都被导向离开流程；而对于join节点，必须完成所有进入流程之后，才能够进入离开流程。

下面是一个示例：

上图中第二根粗横线就是一个join节点，必须在两个进入流程Water Tank和Nutrient Tank完成之后，离开流程才能继续Resume Operations动作。

与join的词义相似，当有多个流程进入一个动作时，不论是控制流还是对象流，在所有流程都到达该动作后，它才可以开始。当动作结束时，离开这个动作的所有流程(控制流和对象流)将开始。

4.3.2 对象流

有时候看到活动中操作的对象可能比较重要，通过添加对象流，可以在活动图中显示对象。但是不推荐所有的活动图都这样做，因为添加过多甚至所有对象会使活动图变得复杂而笨拙。下图展示了前面的活动图中添加的一个对象流：

在Water Tank分区中两个对象节点(标有WaterTank的矩形)被添加到流程中，这表明在加热器停止以后，水箱水位低于了它的操作下限，在Fill动作之后，水箱被加满了，之后对水箱继续加热。WaterTank对象的状态[below low limit]、[full]显示在对象名称的下面。

4.3.3 其他元素

活动图具有丰富的语义，其他类型的对象节点、可中断的区域、引脚等也可以出现在活动图中。

4.3.4 一个练习

对下面几个示例判断所需要的节点类型(已标注在括号中)：

1、用户在选择饮料和投币之后，系统有两个线程同时工作(fork)，钱柜查看投币金额是否足够以及能否找零钱(branch)，饮料柜检验是否有用户所选的饮料(branch)，当两个线程同时符合条件之后才给用户销售饮料(join)。

2、移动公司系统把用户打电话、接电话、发短信、上网等各个事件都记录进日志。(merge)

3、植物大战僵尸游戏中，植物每次被僵尸啃咬，僵尸每次受到植物打击，都要减少生命值。(merge)

4、植物大战僵尸游戏开始之后，僵尸开始进攻，植物开始防御。(fork)

5、僵尸和植物的生命值是否耗尽？如果耗尽则销毁对象，否则让其继续进攻或者防御。(branch)

4.4 两个示例

下面是示例1：

下面是示例2：

---

END