UML系列 - 整体概括和用例图总结

作者 | 颜超敏

欢迎关注我的微信公众号：craft6-cn

【注】本文全部图型均使用VP UML EE 10.0 版本来制作。感谢Visual Paradigm International公司

开发了这么好的UML工具。

UML V1.2规范总共有13种图型，如上图中绿色部分。

图型分为两大类：结构图 和 行为图。

• 结构图

描述系统静态模型的定义，如构造模块、模型视图、显示行为和属性等。

• 行为图

描述系统的动态模型和组成对象间的交互关系。

虽然总共有13种图，但是我们项目中常用到的图主要是5种，其它的图在现在互联网快速开发的节奏下，仅在少量的场合会用到，

而且这些图型也可以用活动图来代替描画：

• 用例图

描述“用户、需求、系统功能单元”之间的关系。它展示了一个外部用户能够观察到的系统功能模型图。

【注】用例图和功能清单有些类似，要画好用例图关键在于注意参与者和用例的关系，用例之间的各种关系，而不是简单的把用例罗列出来。

• 序列图

序列图是对对象之间传送消息的时间顺序的可视化表示。序列图的主要用途是把用例表达的需求，转化为进一步、更加正式层次的精细表达。

用例常常被细化为一个或者更多的序列图。

• 状态图

状态图（Statechart Diagram）主要用于描述一个对象在其生存期间的动态行为，表现为一个对象所经历的状态序列，引起状态转移的事件

（Event），以及因状态转移而伴随的动作（Action）。

【注】状态流转方式、事件和触发动作是画图的关键。而后面两者往往被忽略了。

• 活动图

活动图描述满足用例要求所要进行的活动以及活动间的约束关系，有利于识别并行活动。活动图是一种特殊的状态图，它对于系统的功能建模

特别重要，强调对象间的控制流程。

【注】实际上，笔者也经常用活动图来表达状态流转（因为画图时可用的组件更多）

• 类图

用来显示系统中的类、接口以及它们之间的静态结构和关系的一种静态模型。

【注】唯心画类图主要为了表达出类、接口之间的关系，并只画出主要的方法，对于周边的方法、属性均不会在类图中表达，以免类图过于复杂，

被细节掩盖了整体。

唯心的讲解将按用例图、序列图、状态图、活动图和类图的顺序阐述。

这个顺序也符合从需求描述、分析、业务状态、流程分析和类建模的过程，前面四个图和需求关系更紧密，而类图则是和代码关系更紧密。

用例简单而言就是参与者想要系统做的事情。

对于用例的命名，我们可以给用例取一个简单、描述性的名称，一般为带有动作性的词。

一个完整的UML用例建模产出包含：

l 用例图

参与者和用例的可视化表示，以便从整体的角度来把握系统的功能点。

l 用例文档化（规格说明）

对每个用例的的文档化的定义和说明，开发和测试的工作实际上是基于这个规格说明文档开展。（规格说明有些类似测试用例说明）。

参与者不是特指人，是指系统以外的，在使用系统或与系统交互中所扮演的角色。

参与者可以是角色、岗位、组织、系统、硬件设备或软件设备等等。

注意参与者并不是某个具体的实例，虽然你可以用具体的名称实例来表示一个参与者，但是对于用例图而言，要关注的是这个人（或其它类型实例）

所代表的角色身份。

比如：唯心这个用户，在电商系统里面，他可以是客户、也可以是店员，也可以是店长，或者是平台管理员等。所以在表示参与者时，注意要用抽象的

【角色】来命名。

    参与者一般使用木头人来表示，如下图：

参与者之间可以存在泛化关系，表示B参与者集成A参与者的功能，一般高级别的角色会泛化低级别的角色。

    泛化用上图的空心三角符号线表示。

定义参与者其实就是定义角色，我们对系统进行分析时可以从下面几个角度来思考：

上图详述：

1. 使用系统的主要功能的人是谁（即主要角色）？

2.  需要借助于系统完成日常工作的人是谁？

3. 谁来维护，管理系统（次要角色），保证系统正常工作？

4. 系统控制的硬件设备有哪些？

5. 系统需要与哪些其他系统交互？其他系统包括计算机系统，也包括该系统将要使用的计算机中的其他应用软件。其他系统也分成两类，一类是启动该系统的系统，另一类是该系统要使用的系统。

6. 对系统产生的结果感兴趣的人或事是哪些？

用例表示对于参与者有价值的功能单元，通过一个名词对系统功能进行概括性的描述。

    用例用椭圆型来表示。

用例的命名方式一般是基于它所归属的参与者的角度来进行命名，比如对于电商系统：下订单是客户的行为，接受订单是系统的被动行为，

所以用例应该命名为下订单，归属客户。

1. 角色需要从系统中获得哪种功能？角色需要做什么？

2. 角色需要读取，产生，删除，修改或存储系统中的某种系统吗？

3. 系统中发生的事件需要通知角色吗？或者角色需要通知系统某件事吗？这些事件（功能）能干些什么？

4. 如果用系统的新功能处理角色的日常工作是简单化了，还是提高了工作效率？

5. 还有一些与当前角色可能无关的问题，也能帮助建模者发现用例，例如：

1. 系统需要的输入/输出是什么信息？这些输入/输出信息从哪儿来到哪儿去？

2. 系统当前的这种实现方法要解决的问题是什么（也许用自动系统代替手工操作）?

    用于区分系统的一部分关系密切的用例，在一些用例特别多的用例图中，用子系统的概念来界定用例归属会更方便了解用例关系和边界。

子系统不一定非得对应系统某一个模块，只要关系密切的一组用例，我们都可以把它们定义在一个子系统框里面，方便阅读和任务分配。

• 关联和依赖
  

表示A用例和B用例存在业务关联，或者A依赖B，箭头由A指向B。一般由同类型的特定功能指向通用功能。

    【箭头指向】指向关联方或依赖方。

• 扩展

扩展用例为基用例添加新的行为。扩展用例可以访问基用例的属性，因此它能根据基用例中扩展点的当前状态来判断是否
执行自己。但是扩展用例对基用例不可见。

扩展点指向是扩展用例指向基用例，注意对于基用例而言，它是不知道扩展用例的存在的。

【箭头指向】指向基础用例。

• 包含

使用包含（Inclusion）用例来封装一组跨越多个用例的相似动作（行为片断），以便多个基（Base）用例复用。
有时当某用例的事件流过于复杂时，为了简化用例的描述，我们也可以把某一段事件流抽象成为一个被包含的用例；
相反，用例划分太细时，也可以抽象出一个基用例，来包含这些细颗粒的用例。

【箭头指向】指向分解出来的子用例。

• 泛化

子用例和父用例相似，但表现出更特别的行为；子用例将继承父用例的所有结构、行为和关系。子用例可以使用父用例的
一段行为，也可以重载它。父用例通常是抽象的。UML用例图关系中泛化关系在实际应用中很少使用，子用例中的特殊行为都
可以作为父用例中的备选流存在。

    【箭头指向】指向父用例。

单纯画用例图，如果不配合文档，开发者从一个名词很难准确把握到该功能具体要完成什么目的，具体要怎么做。

用例文档化可以使用Excel方式管理，也可以使用Word文档管理，看管理习惯。

一个典型的用例文档化描述应该包含下面的信息：

l 标题

l 用例描述

l 涉及的参与者（1~N个）

l 用例开始所需要的前置条件

l 事件流的详细描述，包括：

n 基本路径。可以分解为若干子路径，扩展路径。

n 异常情况的备选流

l 后置条件：定义用例结束后系统的状态。

可选的一些描述信息有：

l 状态：表示该用例是否还有效、是否开发中，是否挂起等。

l 字段列表：表示该用例涉及的数据结构

l 业务规则：描述该用例必须遵循的规则。

l 关联用例：描述开发本用例时需要参考或者依赖其它的一些用例。

l 待解决问题：表示开发本用例之前，需要解决的一些的业务或技术难点。

修订记录：记录该用例的变化历史，方便追溯。