移动端UML图应用之UML行为图——用例图、活动图和状态机图

系列文章目录

移动端UML图应用之UML图简述
移动端UML图应用之UML行为图——用例图、活动图和状态机图
移动端UML图应用之UML交互图——顺序图和通信图
移动端UML图应用之UML结构图——包图、部署图和组件图
移动端UML图应用之UML结构图——类图

---

---

一、用例图

什么是用例

用例是文本形式的情节描述，用以说明某参与者使用系统以实现某些目标，广泛应用于需求的发现和记录工作中，以及测试工作中。简单的说，用例就是需求，主要是说明系统如何工作的功能性或行为性需求。虽然UML用例图易于学习，但是要将确定和编写良好用例的众多指导原则融会贯通，还需要数周或更长的时间。实际上，比用例图更重要的，是用例文本。用例图和用例关系在编写用例工作中是次要的，用例是文本文档，编写用例意味着编写文本。


用例相关名词定义

参与者——任何具有行为的事物，可以是人所扮演的角色，例如收银员，也可以是组织、软件和计算机。
场景——参与者和系统之间的一系列特定的活动和交互，参与者使用系统的一个特定情节。这一系列的活动产生了对某个参与者而言可观察的返回值，例如，使用现金成功购买商品的场景，或者由于信用卡付款被拒绝造成的购买失败场景。
用例——一组相关的成功和失败场景集合，用来描述参与者如何使用系统来实现其目标。

参与者包含以下三种类型：

主要参与者——具有用户目标，并通过使用所讨论系统的服务完成。例如，收银员。为何确定主要参与者？发现驱动用例的用户目标。
协助参与者——为所讨论系统提供服务，协助参与者通常是计算机系统，但也可以是组织或人。为何确定协助参与者？为了明确外部接口和协议。
幕后参与者——在用例行为中具有影响或利益，但不是主要或协助参与者。例如，政府税收机构。为何要确定幕后参与者？这是为了确保确定并满足所有必要的重要事物。如果不明确地对幕后参与者进行命名，则有时很容易忽略其影响或利益。


用例图表示法

UML提供了用例图表示法，用以描述用例名称和参与者及其之间的关系。简单的用例图能够为系统提供简洁可视的语境图，能够阐述外部参与者及其对系统的使用，能够展示系统边界、位于边界之外的事物以及系统如何被使用。用例图可以作为沟通的工具，用以概括系统及其参与者的行为。

用例图中，左侧是主要参与者，中间是由表示系统边界的方框框起来的所讨论系统，右侧是支持性参与者，系统中间是一个个的用例。连接系统之外的参与者与系统中的用例的实线表示通信。
参与者分为两种类型，计算机系统参与者与人类参与者。计算机参与者建议使用类框的方式表示，类框内用《actor》表明这是一个参与者，以区别于人类参与者。


用例关联

用例关联指的是将用例联系在一起的关系，包含关系是用例图中最常见、最重要的关系，其他关系还包括扩展、泛化。通过关联将用例组织起来，能够促进对用例的理解和沟通、减少文本重复、改善用例文档的管理，但复杂的关联关系会导致复杂结果，并且会花费大量徒劳的时间。大部分涉及用例间关系的问题，都可以使用包含关系处理。

用例建模专家Cockburn建议优先使用包含关系：
使用包含关系来处理用例之间的关系是首要原则。遵循这条原则的人们介绍说：与那些混淆包含、扩展和泛化关系的人们相比，他们和他们的读者很少会对其所编写的用例产生迷惑。

如下情形可以分解出子功能用例并使用包含关系：

• 当在两个或多个独立用例中存在重复。
• 用例非常复杂并冗长，将其分解为子单元可以方便对其的理解。

上图展示了使用包含关系的UML表示法。

用例关系具有一些价值，但更重要的工作是编写用例文本。说明需求是通过编写用例文本完成的，而不是通过组织用例完成的。在项目开始阶段，如同瀑布方法那样，试图定义和精化完整的用例图及其关系，并没有益处。将用例关系组织起来可以在细化阶段逐步演化。

二、活动图

UML活动图提供了丰富的表示法来表示一个过程中的多个顺序活动和并行活动。这些活动图有助于对业务过程、工作流、数据流和复杂算法进行建模，常用于可视化业务工作流及过程和用例。活动图能够既表示控制流又表示数据流，活动图在本质上就是一种流程图。


业务过程建模

下图表示的是一个包裹快递业务过程。本质上讲，此图显示了一系列动作，其中某些动作可以是并行的。

上图演示了基本的UML活动图表示法。
实心圆表示活动图的起点，含有实心圆的空心圆表示活动图的终止。
竖的长实线表示分区，每个分区代表了特定含义的状态职责的部分，用于区分参加过程的不同参与者。不同分区的活动既可以顺序进行，也可以并发进行。
横的粗黑线表示分叉点和连接点。分叉点具有一个输入转换，两个或多个输出。连接点有两个或多个输入转换，只有一个输出转换。先完成的控制流需要在此等待，只有所有控制流都到达连接点时，控制才能继续进行。
动作用圆角矩形表示。对象节点由矩形框表示。箭头表示控制流的走向。


数据流建模

下图表示的是一个学生向学校的注册系统提交申请之后的数据流模型。

上图出现了较多的对象节点，如果箭头从动作指向对象节点，表示输出。输出表示动作对对象施加了影响，影响包括创建、修改等。如果箭头从对象节点指向动作，则表示输入。输入表示动作使用了对象节点。


常用元素

当出现条件分支时，使用决策符号来表示。合并符号表示分支的汇合。决策符号跟合并符号都使用菱形表示。

当某个活动需要在另外一个活动图中展开时，可以使用“耙子”符号来表示。
当你需要对时间触发动作或取消请求等诸如此类的事件建模时，信号非常有用。

准则

保持较高的抽象水平，从而使图形具有清晰、简洁的品质。
尽量保持同一张图中所有动作节点的抽象水平一致。
活动图通常对于涉及众多参与者的非常复杂的业务过程建模具有价值。对于简单的业务过程，用例文本就够用了。

三、状态机图

同活动图一样，UML状态图是动态视图。如下图所示，UML状态机图描述了某个对象的状态和感兴趣的事件以及对象响应该事件的行为。转换用标记有事件的箭头表示。状态用圆角的矩形表示。通常的做法是会包含一个初始伪状态，当实例创建时，自动从初始伪状态转换到另外一个状态。

状态机图显示了对象的生命周期：对象经历的事件、对象的转换和对象在这些事件之间的状态。状态机图不必描述所有可能的事件；如果所发生的事件未在图中表示，则说明其不影响该状态机图所关注的内容。因此，我们可以根据需要创建状态机图，在任意简单或复杂的细节程度上描述对象的生命周期。


事件、状态和转换

事件是指一件值得注意的事情的发生。例如：电话接线员拿起话筒。状态是指对象在事件发生之间某时刻所处的情形。例如：接线员挂机之后再次拿起话筒之前电话处于“idle”状态。转换是两个状态之间的关系。它表明当某事件发生时，对象从先前的状态转换到后来的状态。例如：当事件“off hook”发生时，电话从“idle”状态转换为“active”状态。


状态无关和状态依赖对象

如果一个对象对某事件的响应总相同，则认为此对象对于该事件状态无关。如果，对于所有事件，对象的响应总是相同的，则该对象是一个状态无关对象。相反，状态依赖对象对事件的响应根据对象的状态或模式而不同。考虑为具有复杂行为的状态依赖对象而不是状态无关对象建立状态机图。例如，电话的行为依赖于状态。电话对于按下某个按钮这一事件的响应方式依赖于电话的当前状态——“摘机”、“使用中”等。


嵌套状态

一个状态允许嵌套，以包含子状态，子状态被嵌套地放入父状态的框图里，它使简洁的状态机图成为可能。

使用状态机图进行UI导航建模

对于有复杂的页面流的应用程序，譬如移动应用程序，在设计阶段，状态机是很有用的工具，可用于为页面流建立文档以便于人们理解其含义，也可用于建模页面流。状态表示页面，事件表示引起从一个页面向另外一个页面转换的用户事件，例如按钮被按下。

---

参考书籍

[1] UML和模式应用（原书第3版）作者：拉曼