SysML(5)—用例图

babylemon828

图1 SysML图概览

介绍完模块的属性以及模块之间的关系，模块定义图的主要内容就告一段落了，我们来简单总结一下：

模块定义图是一种结构图（学习了模块之间的“泛化”关系之后，图1中的带有空心三角箭头的实线读者就知道什么意思了）。模块定义图一般用来表达系统结构化的信息，它描述了系统内部以及系统外部环境中存在的结构类型。

模块定义图主要说明每种结构所提供和需要的服务类型、它们必须遵循的约束类型以及系统中存在的值类型。

结构图中的其它三种图我们根据实际需要在后面介绍，这篇文章开始介绍行为图中的用例图。

“用例”这个词大家应该都很熟悉，在平时工作中也经常使用，最常见和最典型的就是“测试用例”。

对于任何一个系统来说，系统的用例(use case)从字面的含义就可以理解，在这个语境下，英文的case可以理解为具体情况、实例或者案例。比如case by case，就是具体问题具体分析，就事论事的意思。

系统的用例（use case）其含义就是使用系统的实例或者案例，这里的核心关键词是使用，既然是使用，必然涉及2个关键问题：谁来使用系统和如何使用系统。

谁来使用系统：所有可能使用系统的人或外部系统，我们统一称之为利益相关者(stakeholders)。

如何使用系统：显而易见，“使用”是一个动词，因此如何使用系统必然包含一系列的动作，你可以正确地使用系统，你也可以错误地使用系统（比如测试工程师，错误地使用系统是测试工作的重要内容）。

在正式开始介绍如何画用例图之前，先说明一下有关用例的基础知识。

用例是利益相关者在使用系统时，系统会执行的一种行为，因此用例的名称一般用一个“动宾结构”来表达，比如开启近光灯，切换整车电源模式等。

用例是系统的行为，但系统的行为并非都是用例。用例是利益相关者能够直接触发或者参与的那一部分系统行为，换句话说，用例是系统所有行为的子集。

触发系统执行用例的可以是一个人或者是一个外部系统，它们在用例图中统称为执行者，执行者通过接口触发系统执行用例。触发用例的执行者叫做主执行者，参与到用例中的执行者叫做次执行者，主执行者也可以是次执行者。

用例的名称应该表达出主执行者触发系统执行用例的目的，即用例名称中的“动宾结构”应该从执行者使用系统的目的去命名，而不是从系统的角度来命名。例如，如果外灯控制系统在执行者操作近光灯开关后需要驱动近光灯点亮，那用例的名称应该是“开启近光灯”，而不是“接收近光灯开关信号”。

用例的名称无法表达出如何使用系统的详细信息，因此需要为用例编写用例说明书，以便准确而详细地描述执行者如何通过用例使用系统。用例说明书一般包括以下几个部分（参考书籍《编写有效用例》）：
用例名称：一个“动宾结构”的动词短语；范围：拥有用例的实体（组织、系统、子系统或者组件的名称）；
主执行者：触发用例的执行者（用例代表了该执行者使用系统的目的）；次要（支持）执行者：为系统提供服务的执行者（通过执行动作参与到用例中）；

利益相关者：和系统行为之间有既定利益关系的某人或某物；

预置条件：必须满足才能让用例开始的条件；
保证（后置条件）：在用例结束时必须为真的条件；触发器：能够触发用例开始执行的事件；
主要成功场景：没有出现任何错误的场景（一系列的动作）；扩展（可置换分支）：可置换的系列动作，它们从主要成功场景中分支出来；

相关信息：为了得到额外信息而需要的内容；

看到以上关于如何编写用例说明书的介绍，很多读者（特别是测试工程师）是不是觉得很眼熟，因为在编写测试用例时也会涉及一些类似的部分，比如执行测试之前需要满足的前提条件，执行测试时的具体操作步骤，编写测试用例所基于的功能使用场景等。

其实，我们实际工作中的做法或者说是最佳实践绝大部分都可以在权威书籍中找到依据，笔者之所以写SysML这个专题，也是为了让架构工程师知道架构设计工作的背后，也同样有很多的书籍和方法论做支撑，如果想做好架构工作，不能只局限于实践，更要不断深入理解和掌握其背后的底层技术和设计逻辑。

言归正传，我们来介绍如何画用例图。

用例图是一种分析工具，在系统设计开发的早期阶段（概念设计阶段），架构工程师可以通过用例图来分析系统的功能性需求。



图2 外灯控制子系统用例图

1、用例图外框

用例图的外框代表的模型元素类型可能是：包、模型、模型库或者视图。如图2所示，用例图的名称是“外灯控制子系统用例”，图的头部显示这幅图代表系统模型中的“行为”包，它是用例图中所显示用例的命名空间，或者说它包含了用例图中所显示的所有用例。

2、用例

如图2所示，用例的标识法是一个椭圆形，同模块一样，用例之间也可以存在泛化关系，子类型用例会继承超类型用例所拥有的一切。

3、系统边界

系统边界（主题）代表拥有并执行用例图中的用例的系统。系统边界的标识法是围绕用例的边框。系统边界的名称显示在边框的顶部，与用例名称的“动宾结构”不同，它必须是一个名词短语，如图2中的“外灯控制子系统”。

在架构设计的概念设计阶段，系统边界的名称应该是架构师正在设计的实系统的名称，架构师把系统看做一个黑盒，并设计系统为执行者提供的功能需求。

4、执行者

执行者有两种标识法：火柴人或者名称前带有《执行者》关键字的边框。系统建模中通常的做法是：火柴人代表人，边框代表外部系统。

5、执行者与用例的关系

为了使执行者能够触发和参与到用例中，执行者与用例之间需要创建交互关系。模块定义图中模块之间的关联关系同样适用于用例图，执行者的实例可能会触发或者参与到用例的实例中。

图2中也展示了关联关系的多重性（默认为1，不显示）。可以有1个或者多个集成测试工程师（执行者）、1个信息显示子系统（执行者）、执行者在任意给定时间内，可以关联0个或者1个用例图中所包含的用例。

6、基础用例

基础用例是通过关联关系与主执行者连接在一起的用例，基础用例代表主执行者使用系统的目的。如图2中的“开启近光灯”和“开启远光灯”。

7、内含用例

内含关系的标识法是带有箭头的虚线，并带有关键字《包含》。如图2所示，“发送灯光状态网络信号”就是内含用例。这里需要特别注意，内含关系并不是一种依赖关系，尽管它们都有带箭头的虚线。

内含关系的含义是：当不带箭头的一端（源端）的用例被触发时，带箭头的一端（目标端）的内含用例也会执行，也就是说内含用例的行为是源端用例所需要的组成部分。

8、扩展用例

扩展关系的标识法与内含关系类似，区别在于关键字是《扩展》，另外扩展用例位于扩展关系的源端。

扩展关系的含义是：当带箭头的一端（目标端）的用例被触发时，不带箭头的一端（源端）的扩展用例有可能（取决于触发条件是否满足）执行。

可以在扩展关系的注释中说明执行扩展用例需要满足的触发条件，还可以指定扩展点，扩展用例会在扩展点在目标用例的行为中生成分支。为了让用例图保持简洁，扩展用例的触发条件和扩展点建议放在与目标用例相关联的活动图中去表达。

下一篇文章我们来介绍活动图。

未完待续。。。。。。