用例图

用例图

1. 参与者(Actor)：

是指系统以外的–需要使用系统或与系统交互的东西–包括人-设备-外部系统等。
参与者这个概念更确切的术语应该是角色(role)–参与者是他们相对系统而言(与系统交互时)所扮演的角色(而非特定的人或事物–实际上是版型化的类)。

版型：既构造型(Stereotype) – 必须从UML中已有的基本构造块上派生 - 解决特定问题(在已有的元素上增加新的语义但没有增加新的语法) - 这就是UML的扩展机制 P38。
例如：参与者是类的构造型 – 接口是类的构造型 – 子系统是包的构造型

2. 参与者之间的关系：

泛化(generalization)关系：一般事物(称为超类或父类)和该事物的较为特殊的种类之间的(分类)关系-子类继承(共享)父类的特性(特别是属性和操作)-也可以用自己特性 P36。

3. 参与者和用例之间的关联关系：

关联(association)关系：是一种结构关系–说明一个事物的实例与另一个事物的实例间的(通信)联系(P36) – 参与者和用例之间的关联关系-表明了哪个参与者与用例通信。

4. 用例的概念：

(1)用例由一组用例实例(场景)组成-在商场购物“付款”的用例中-一个是使用现会成功付款的场景-一个是由于银行卡付款被拒绝造成的付款失败场景。
(2)用例从使用系统的角度描述系统–即站在系统外部察看系统功能-而不考虑系统内部对该功能的具体实现。
(3)用例的执行结果对参与者来说是有意义的–登录系统是一个有效的用例–但输入密码却不是–因为登录系统对参与者有价值–这样他可以获得身份认证和授权。
(4)用例是对系统行为的动态描述-属于动态建模部分–不存在没有参与者的用例用例不是全部的系统需求–只是功能性的需求。

5. 用例之间的关系：

(1)泛化关系：泛化(Generalization)代表一般与特殊的关系，与继承关系类似。在泛化关系中，子用例继承了父用例的行为和含义，也可以增加新的行为和含义，或覆盖父用例中的行为和含义。当发现系统中有两个或多个用例在行为、结构和目的方面存在共性时，就可以使用泛化关系。这时，可以用一个新的(通常也是抽象的)用例(父用例)来描述这些共有部分。

(2)包含关系：一个用例(基本用例)的行为包含(Include)了另一个用例(包含用例) 的行为。包含关系是依赖关系的版型–也就是说包含关系是比较特殊的依赖关系–它们比一般的依赖关系多了一些语义。当发现系统中有两个或多个用例有某些相同的动作–就可以这些相同的动作提取出来–单独构成一个用例(包含用例)–基本用例仅仅依赖包含用例执行的结果–而不依赖包含用例执行的内部结构。

(3)扩展关系：一个用例(基本用例)的行为包含了另一个用例(扩展用例)的行为。扩展(Extend)关系也是依赖关系的版型。相对于包含关系，扩展用例(Extension Use Case)有更多的规则限制，即基本用例必须申明若干“扩展点” (Extension Point)，而扩展用例只能在这些扩展点上增加新的行为和含义。

在基本用例的每一次执行时，包含用例都一定会执行，而扩展用例只是偶尔被执行。

6. 用例描述：

没有描述的用例就像一本书的目录–人们只知道该该目录标题–但并不知道该目录的具体内容是什么；系统所要执行的一系列动作序列(事件流)是用例描述(Use Case Specification)主要内容。