用例图中的关系
一、用例图概述
用例图，是一种客户与开发者之间可以沟通、理解的表现形式。可以认为用例图是开发者与客户之间的可视化契约。我认为最主要的一点就是，在这个用例模型中，一直是以用户的角度为主的，做为开发人员也要时刻站在用户的角度来看待整个系统。
从原则上来讲，用例之间都是独立、并列的，它们之间并不存在着包含从属关系。但是为了体现一些用例之间的业务关系，提高可维护性和一致性，用例之间可以抽象出包含(include)、扩展(extend)和泛(generalization)几种关系。共性：都是从现有的用例中抽取出公共的那部分信息，作为一个单独的用例，然后通后过不同的方法来重用这个公共的用例，以减少模型维护的工作量。
二、用例图中的四个基本组件
用例图包括：参与者或角色（actor）、用例（use case)、关系、系统。
- 1、
参与者：是系统外的一个实体，它以某种方式参与用例我执行过程。参与者通过向系统输入或请求系统输入某些事件来触发系统的执行，所以参与者可以是人，可以是事物，可以是时间、气压等环境因素或者其他系统等。它在系统之外，与系统直接交互。用一个群体概念给参与者命名，反映该参与者的身份与行为（如客户、管理员等）。
- 2、
用例：用例代表系统的某项完整的功能，是动作步骤的集合。系统的功能是通过参与者使用用例来实现的。在这里，我们把用例看做是一个“黑盒”，只反映的是系统的一项功能，不涉及实现细节。
用例的命名：用例是从用户的角度来描述系统的功能，也就是从参与者的角度出发进行命名（如，使用“登录”，而不用“身份验证“）。还有，用例最好使用行业专业术语。
- 3、关系：除了参与者与用例之间的关联关系外，还可以定义参与者之间的泛化关系，用例之间的包含、泛化与扩展关系。应用这些关系的目的是从系统中抽取出公共行为及其变体。
- 4、 系统：系统指一个软件系统、一项业务、一个商务活动、一台机器等等。系统的功能通过用例来表现，换句话说，就是所有的用例构成了整个系统。从这个角度来说，用例（use case)也可以称为系统的子功能。系统用矩形表示，也可以省略。
三、用例图中的关系
1、包含关系
在包含关系中，基本用例吸收了被包含用例的行为，如果没有后者它将是不完整的。
包含关系的划分有两个好处：一是被包含用例被抽取出来，基本用例得以简化；二是可以抽象出公共事件流，实现代码复用。
有时当某用例的事件流过于复杂时，为了简化用例的描述，我们也可以把某一段事件流抽象成为一个被包含的用例；相反，用例划分太细时，也可以抽象出一个基用例，来包含这些细颗粒的用例。如:
2、扩展
将基用例中一段相对独立并且可选的动作，用扩展（Extension）用例加以封装，再让它从基用例中声明的扩展点（Extension
Point）上进行扩展，从而使基用例行为更简练和目标更集中。扩展用例为基用例添加新的行为。扩展用例可以访问基用例的属性，因此它能根据基用例中扩展点的当前状态来判断是否执行自己。但是扩展用例对基用例不可见。
对于一个扩展用例，可以在基用例上有几个扩展点。
例如，系统中允许用户对查询的结果进行导出、打印。对于查询而言，能不能导出、打印查询都是一样的，导出、打印是不可见的。导入、打印和查询相对独立，而且为查询添加了新行为。因此可以采用扩展关系来描述：
3、泛化关系
1）参与者之间的泛化关系
例如，一个网上订购系统，可以有网上客户、电话客户、直接客户等。可以看出，他们有共同的行为特征，这就是可以用到面向对象的抽象，抽象出更为一般的化的参与者——客户。通过泛化来描述多个参与者之间的共同行为，不同的参与者以独特的方式来使用系统。
2）用例与用例之间的关系
用例与用例之间也存在着泛化关系，通常用于表示同一业务目的（父用例）的不同技术实现（各个子用例）。
例如某购物系统为用户提供不同的支付方式，那么”支付”这个复杂用例就可以用泛化关系表示。
四、包含关系与扩展关系共同点
扩展用例与包含用例都是基用例的一部分.
基本用例不执行，扩展用例与包含用例都不会执行
扩展用例可以扩展多个基本用例，包含用例可以被多个基本用例包含
区别：
扩展关系中基本用例的基本流执行时，扩展用例不一定执行，即扩展用例只有在基本用例满足某种条件的时候才会执行。
包含关系中基本用例的基本流执行时，包含用例一定会执行。