UML用例图总结来源于网络

前言

 

用例图主要用来描述“用户、需求、系统功能单元”之间的关系。它展现一个外部用户可以观察到的系统功能模型图。用例图多用于静态建模阶段（主要是业务建模和需求建模），帮助开发团队以一种可视化的方式理解系统的功能需求。下面将从各个部分来分析和理解用例图。

参与者（Actor）

在系统外部与系统直接交互的人或事物；须要注意如下两点：

1. 参与者是角色而不是具体的人，它表明了参与者在与系统打交道的过程当中所扮演的角色。因此在系统的实际运做中，一个实际用户可能对应系统的多个参与者。不一样的用户也能够只对应于一个参与者，从而表明同一参与者的不一样实例。
2. 参与者做为外部用户（而不是内部）与系统发生交互做用，是它的主要特征。

在UML中，参与者使用如图所示的一个小人表示：

用例（Use Case）

系统外部可见的一个系统功能单元。系统的功能由系统单元所提供，并经过一系列系统单元与一个或多个参与者之间交换的消息所表达。用椭圆表示，椭圆中的文字简述系统的功能：

子系统（Subsystem）

用来展现系统的一部分功能，这部分功能联系紧密。

关系（Relationship）

用例图中涉及的关系有：

1. 关联
2. 泛化
3. 包含
4. 扩展

关联（Association）

表示参与者与用例之间的交互，通讯途径，任何一方均可发送或接受消息。
箭头指向：指向消息接收方。

泛化（Inheritance）

在编程中，泛化关系是一种很重要的关系，咱们随处可见。
泛化关系是通常和特殊关系，就是一般理解的继承关系，子用例和父用例类似，但表现出更特别的行为；子用例将继承父用例的全部结构、行为和关系。子用例可使用父用例的一段行为，也能够重载它。父用例一般是抽象的。
箭头指向（须要特别注意）：指向父用例。

包含（Include）

包含关系用来把一个较复杂用例所表示功能分解成较小的步骤。包含用例是必须的，若是缺乏包含用例，基用例就不完整；包含用例必须被执行。
箭头指向：指向分解出来的功能用例。

扩展（Extend）

扩展关系是指用例功能的延伸，至关于为基础用例提供一个附加功能。扩展用例是可选的，若是缺乏扩展用例，不会影响到基用例的完整性。
箭头指向（须要特别注意）：指向基用例

下图提供一个完整的系统的用例图，让你们有一个感官上的全面认识。

总结

用例图虽然做为UML中的一部分，给团队成员提供一种形象的系统表述，可是，用例图也由它自己的缺陷，用例图通常在需求分析阶段就给出了，有的时候对于系统的需求，并不能很好的表述，对于没有UML背景的人来讲，更是一种痛苦与折磨，可是，话又说回来，做为软件开发人员，没有UML背景是说不过去的；有的时候，咱们须要借助用例图对客户讲解系统，而让客户去理解用例图则是很困难的。
虽然，在用例图中的关系种类不是不少，也不是很复杂，可是UML的表示确实很让人费解的，别的还好，特别是扩展（Extend）和包含（Include），表示方式都同样的，仅靠上面的说明来进行区分，在一个复杂的系统中，是很容易看错的，从而理解出错，同时，扩展（Extend）中的箭头指向一直是让我很费解的，为何须要让箭头指向基用例呢？
鉴于用例图有的时候并不能清楚地表达功能需求，开发中你们一般用用例描述表来补充某些不易表达的用例，请你们参考下图：