详解UML建模之用例图关系

一．UML简介

UML（统一建模语言，Unified Modeling Language）是一种定义良好、易于表达、功能强大且普遍适用的可视化建模语言。它融入了软件工程领域的新思想、新方法和新技术。它的作用域不限于支持面向对象的分析与设计，还支持从需求分析开始的软件开发的全过程。在系统分析阶段，我们一般用UML来画很多图，主要包括用例图、状态图、类图、活动 图、序列图、协作图、构建图、配置图等等，要画哪些图要根据具体情况而定。其实简单的理解，个人理解，UML的作用就是用很多图从静态和动态方面来全面描述我们将要开发的系统。

二、什么是用例

用例是对包括变量在内的一组动作序列的描述，系统执行这些动作，并产生传递特定参与者的价值的可观察结果。这是UML对用例的正式定义，可能有点难懂。我们可以这样去理解，用例是参与者想要系统做的事情。对于用例的命名，我们可以给用例取一个简单、描述性的名称，一般为带有动作性的词。用例在画图中用椭圆来表示，椭圆下面附上用例的名称。

三、什么是用例图

用例图（use case diagram）就是由主角、用例以及它们之间的关系构成的图。该图说明了用例模型中的关系。

可以将用例图组织到用例包中，并归用例包所有，让特定包中仅显示互为关联关系的内容。

用例图由参与者（Actor）、用例（Use Case）、系统边界、箭头组成，用画图的方法来完成。

参与者不是特指人，是指系统以外的，在使用系统或与系统交互中所扮演的角色。因此参与者可以是人，可以是事物，也可以是时间或其他系统等等。还有一点要注意的是，参与者不是指人或事物本身，而是表示人或事物当时所扮演的角色。比如小明是图书馆的管理员，他参与图书馆管理系统的交互，这时他既可以作为管理员这个角色参与管理，也可以作为借书者向图书馆借书，在这里小明扮演了两个角色，是两个不同的参与者。参与者在画图中用简笔人物画来表示，人物下面附上参与者的名称。

如何发现角色：

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

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

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

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

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

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

用例：用例代表的是一个完整的功能。

如何发现用例：

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

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

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

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

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

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

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

四、UML用例图中用例之间的关系：

主要用来图示化系统的主事件流程，它主要用来描述客户的需求，即用户希望系统具备的完成一定功能的动作，通俗地理解用例就是软件的功能模块，所以是设计系统分析阶段的起点，设计人员根据客户的需求来创建和解释用例图，用来描述软件应具备哪些功能模块以及这些模块之间的调用关系，用例图包含了用例和参与者，用例之间用关联来连接以求把系统的整个结构和功能反映给非技术人员（通常是软件的用户），对应的是软件的结构和功能分解。

1）包含关系——include

包含关系：使用包含（Inclusion）用例来封装一组跨越多个用例的相似动作（行为片断），以便多个基（Base）用例复用。基用例控制与包含用例的关系，以及被包含用例的事件流是否会插入到基用例的事件流中。基用例可以依赖包含用例执行的结果，但是双方都不能访问对方的属性。

UML用例图关系中包含关系最典型的应用就是复用，也就是定义中说的情景。但是有时当某用例的事件流过于复杂时，为了简化用例的描述，我们也可以把某一段事件流抽象成为一个被包含的用例；相反，用例划分太细时，也可以抽象出一个基用例，来包含这些细颗粒的用例。这种情况类似于在过程设计语言中，将程序的某一段算法封装成一个子过程，然后再从主程序中调用这一子过程。　

例如：业务中，总是存在着维护某某信息的功能，如果将它作为一个用例，那添加、删除以及修改都要在用例详述中描述，过于复杂；如果分成添加用例、修改用例和删除用例，则划分太细。这时包含关系可以用来理清关系。

2）、扩展关系——extend

扩展关系：将基用例中一段相对独立并且可选的动作，UML用例图关系中用扩展（Extension）用例加以封装，再让它从基用例中声明的扩展点（ExtensionPoint）上进行扩展，从而使基用例行为更简练和目标更集中。扩展用例为基用例添加新的行为。扩展用例可以访问基用例的属性，因此它能根据基用例中扩展点的当前状态来判断是否执行自己。但是扩展用例对基用例不可见。

对于一个扩展用例，可以在基用例上有几个扩展点。

例如，系统中允许用户对查询的结果进行导出、打印。对于查询而言，能不能导出、打印查询都是一样的，导出、打印是不可见的。导入、打印和查询相对独立，而且为查询添加了新行为。因此可以采用扩展关系来描述：

在以下几种情况下，可使用扩展用例：

2.1）.表明用例的某一部分是可选的系统行为（这样，您就可以将模型中的可选行为和必选行为分开）；

2.2）.表明只在特定条件（如例外条件）下才执行的分支流；

2.3）.表明可能有一组行为段，其中的一个或多个段可以在基本用例中的扩展点处插入。所插入的行为段和插入的顺序取决于在执行基本用例时与主角进行的交互。

3）、泛化关系——generalization

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