第2章用例图教学课件.pptVIP

* 下图显示了用例间的泛化关系。在图书管理系统中，用例“查找书籍”负责在图书馆的数据库中查找符合输入信息的书籍。该用例有两个子用例“精确查找”和“模糊查找”。 * 下图显示了用例间的包含关系。在图书管理系统中，用例“删除书籍”和“修改书籍信息”与用例“图书查询”之间是一种包含关系。不管是删除书籍还是修改书籍信息，都必须先进行该书籍的查询工作。 有时当某一个用例的事件流过于复杂时，为了简化用例的描述，我们也可以把某一段事件流抽象成为一个被包含的用例。这种情况类似于在过程设计语言中，将程序的某一段算法封装成一个子过程，然后再从主程序中调用这一子过程。 * 在图书管理系统中，假设有一个基础用例“还书”，规定了一般情况下的还书流程。但是，如果读者所借书籍超期，在还书的时候是要交纳罚金的，这时基础用例“还书”不能描述超期情况下的还书流程。如果修改基础用例，可能会增加基础用例的复杂性，因此可以考虑在基础用例中添加扩展点，特定条件是超期，如果满足特定条件，将执行“交纳罚金”这个扩展用例。 2.2.2 泛化参与者 与用例一样，也可以对参与者进行泛化。泛化后的参与者也在系统中扮演较为具体的角色。如图2-12所示，假设图书管理系统中，管理员分为对系统进行维护的管理员和完成借书、还书等日常操作的图书管理员。参与者Manager描述了参与者Librarian和Administrator所扮演的一般角色。如果不考虑与系统交互时的职责，可以使用一般角色的参与者Manager。如果强调管理员的职责，那么用例须使用精确的参与者。即子类Librarian和Administrator。 * * 2.3 描述用例 用例图描述了参与者和系统特征之间的关系，但是它缺乏描述系统行为的细节。所以一般情况下，还会以书面文档的形式对用例进行描述，每个用例应具有一个用例描述。在UML中对用例的描述并没有硬性规定，但一般情况下用例描述应包括以下几个方面： 名称 名称无疑应该表明用户的意图或用例的用途，如上面示例中的“借阅图书”、“归还图书”。 标识符[可选] 惟一标识符一个用例，如UC200601。这样就可在项目的其他元素（如类模型）中用它来引用这个用例。 * 参与者[可选] 与此用例相关的参与者列表。尽管这则信息包含在用例本身当中，但在没有用例图时，它有助于增加对该用例的理解。 状态[可选] 指示用例的状态，通常为以下几种之一：进行中、等待审查、通过审查或未通过审查。 频率（参与者使用此用例的频率） 前置条件 * 2.4 用例之间的关系 用例描述系统满足需求的方式。当细化描述用例操作步骤时，就可以发现有些用例以几种不同的模式或特列在运行，而有些用例在整个执行期间会出现多重流程。如果将用例中重要的可选性操作流程从用例中分隔出来，以形成一个新的用例，这对整个系统的好处是显而易见的。当分离可重复使用的用例后，用例之间就存在着某种特殊关系。包含和扩展在是两个用例紧密相关时，关联用例的两种方法。包含关系用于表示用例为执行其功能时需要从其他用例引入功能。类似，扩展关系则表示用例的功能可以通过其他用例的功能得到扩充。 * 2.4.1 包含关系 在对系统进地分析时，通常会发现有些功能在不同的环境下都可以被使用。在编写代码时，我们希望编写可重用的构件，这些构件包括诸如可以从其他代码中调用或参考的类库、子过程以及函数。在用例图中UML支持同样的做法。用例之间的包含关系在UML中的标记符如图2-14所示。注意图中虚线箭头是指向被包含用例的。 * 包含举例（一）： 包含举例（二）： 2.4.2 扩展关系 扩展关系是一种依赖关系,它指定了一个用例可以增强另一个用例的功能。扩展关系与包含关系一样，只是将单词include替换成了表示扩展关系的单词extend。扩展关系如图所示。 * 扩展举例（一）： 扩展举例（二）： 2.5 用例建模 为了加深对前面所介绍知识的理解，本节将通过一个实际的系统用例图来说明用例图的创建过程。在本节所采用的实例为一个图书馆的图书管理系统。绘制用例图一般要经过以下几个步骤： 确定系统涉及的总体信息 确定系统的参与者 确定系统的用例 构造用例模型 * 2.5.1 确定系统涉及的总体信息 图书管理系统是对图书馆中的藏书以及借阅者进行统一管理的系统。系统的主要事务包括，图书管理员的书籍借出处理、书籍归还处理和查看借阅者的借阅信息；还有系统管理员对系统的维护，包括对管理员的维护、书籍的维护、借阅者信息的维护等。在确定了系统的总体信息后就可以分析系统的参与者，并确定系统用例。 * 2.5.2