深入浅出的看——UML用例图中泛化、包含、扩展关系

用例图中泛化、包含、扩展关系

用例图使用户 与开发人员交流的一种重要的方式，是对用户需求的一种描述。开发人员从用户的角度整体上理解系统的功能。

用例图主要有三种元素：参与者（Actor），用例，以及用例图中对象间到的关系。其中包含、扩展是用例图中特有的关系，泛化在其他类图中同样存在。

1、包括（include）

当能够从两个或两个以上的用例图中提取公共行为时，应该使用包括关系来表示它们。 当中这个提取出来的公共用例成为抽象用例，而把原始用例成为基本用例或基础用例。
比如，下图中的 “登记外借信息” 和 “查询外借信息” 两个用例都须要登陆，为此，能够定义一个抽象用例 “用户登录”。用例 “登记外借信息” 和 “查询外借信息” 与用例 “用户登录” 之间的关系就是包括关系。当中 << include >> 是包括关系的构造型，箭头指向抽象用例。

   注意： 当多个用例需用使用同一段事件流时，抽象成为公共用例，能够避免在多个用例中反复地描写叙述这段事件流，也能够防止这段事件流在不同用例中的描写叙述出现不一致。当须要改动这段公共的需求时，也仅仅要改动一个用例，避免同一时候改动多个用例而产生的不一致性和反复性工作。另外，当某个用例的事件流过于复杂时，为了简化用例的描写叙述，也能够将某一段事件流抽象成为一个被包括的用例。

2、 扩展（extend）关系

假设一个用例明显的混合了两种或两种以上的不同场景，即依据情况可能发生多种分支，则能够将这个用例分为一个基本用例和一个或多个扩展用例，这样使描写叙述可能更加清晰。
如上图中的图书管理员进行 “查询书籍信息” 操作时，假设发现书籍信息有误，他能够使用 “修改书籍信息” 用例来完成更正错误的改动。所以用例 “查询书籍信息” 和 “修改书籍信息” 之间的关系就是扩展关系。当中 << extend >> 是扩展关系的构造型，箭头指向基本用例。

总结： 从UML事物关系的本质上来看，包括关系和扩展关系都属于依赖关系，所以是虚线。

3、 泛化

当多个用例共有一种类似的结构和行为时，能够将它们的共性抽象成为父用例，其它的用例作为泛化关系中的子用例。 在用例的泛化关系中，子用例是父用例的一种特殊形式，子用例继承了父用例全部的结构、行为和关系。比例如以下图中：用户缴费有多种方式，能够是 “线上缴费” 也能够是 “线下缴费”。所以 “用户缴费” 用例就是 “现上缴费” 和 “线下缴费” 用例的泛化。当中三角箭头指向父用例。

总结： 继承关系是泛化关系的反关系，也就是说子类是从父类继承的，而父类则是子类的泛化。

---

最后再给大家一个用例图，希望参考上面的例子大家能够理解