再看包括、扩展和泛化、继承

    我们知道包括和扩展是用例图中所特有的关系，而泛化和继承则不仅用于用例图，同一时候也适用于其它图，如类图。这两对概念相信对于学习面向对象中的我们来说是非常easy混淆的，非常多时候自己都不知道包括和扩展箭头究竟该指向哪里，是虚线还是实线，泛化究竟跟继承什么关系？常常为此大家争

得面红耳赤，以下我就来捋一捋(本篇博客想要表达的意思已经用红色标出,假设有什么不妥之处欢迎批评不吝赐教~)。

（1）   包括（include）关系

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

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

（2）   扩展（extend）关系

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

（3）   泛化和继承

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

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

    从UML事物关系的本质上来看，包括关系和扩展关系都属于依赖关系（所以呢，都是虚线啦）。对包括关系而言，抽象用例中的事件流是一定会插入到基本用例中取得，而且插入点仅仅有一个。扩展用例的事件流往往能够抽象为基本用例的备选事件流，在扩展关系中，能够依据一定的条件来决定是否将扩展用例的事件流插入到基本用例的事件流中，而且插入点能够有多个。在实际应用中，非常少使用泛化关系，子用例的特殊行为都能够作为父用例中的备选事件流而存在。

    在实际工作中，要慎重选用这些关系。从上面的介绍能够看出，包括、扩展和泛化关系都会添加�用例的个数，从而添加�用例模型的复杂度。另外，一般都是在用例模型完毕之后才对它进行调整，在用例模型建立之初不必急于抽象用例之间的关系。