需求之用例视图

1、软件工程（补充）需求之用例视图1议程：什么是用例图关键要素例子21.什么是用例图（use case）UML 的用例图可以表示客户的需求，通过用例建模可以对外部的角色以及它们所需要的系统功能建模。32.关键要素用例图 use case diagram从系统的使用者的角度所理解的系统的总体功能。建立于系统需求阶段，是开发者和用户对系统需求达成的共识。用例 描述一个系统做什么 参与者 表示用例的使用者在与这些用例交互时所扮演的角色 可以是：人、硬件设备或一个系统客 户取款43.例子ATM（自动柜员机）系统的用例图 54. 要素包：包是模型的一部分，模型的每一部分必须属于某个包。建模者可以将模型的内容

2、分配到包中。但是为了使其能够工作，分配必须遵循一些合理的原则，如公用规则、紧密耦合的实现和公用观点等。 UML 对如何组包并不强制使用什么规则，但是良好的解组会很大地增强模型的可维护性。 64. 要素通信： 不带箭头的线段将执行者与用例连接到一起，表示两者之间交换信息，称之为通信联系。执行者触发用例，并与用例进行信息交换。单个执行者可与多个用例联系；反过来，一个用例可与多个执行者联系。对同一个用例而言，不同执行者有着不同的作用；他们可以从用例中取值，也可以参与到用例中。 74. 要素使用（包含）： 一个用例使用另一个用例时，这两个用例之间就构成了使用关系。一般情况下，如果若干个用例的某些行为是

3、相同的，则可以把这些相同的行为提取出来单独作为一个用例，这个用例称作抽象用例。这样当某个用例使用该抽象用例时，就好像这个用例包含了抽象用例的所有行为。84. 要素扩展（泛化）： 一个用例中加入一些新的动作后则构成另一个用例这两个用例之间的关联是概括化关系称作扩展关联后者通过继承前者的一些行为得来前者通常称为概括化用例后者常称作扩展用例。94. 要素约束： 在UML中,可以用约束(Constraint)表示规则。约束是放在括号中的一个表达式,表示一个永真的逻辑陈述。在程序设计语言中,约束可以由断言(Assertion)来实现。 105. 确定目标确定参与者： （1）确定谁会直接使用该系统，即参与

4、者（Actor），为了发现参与者，我们可以尝试问如下问题：a. 谁/什么使用系统？b. 谁/什么从系统获得信息？c. 谁/什么向系统提供信息？d. 谁/什么支持、维护系统？e. 哪些其它系统使用此系统？f. 公司的哪个部门使用系统？ 115. 确定目标确定用例： （2）定义该参与者希望系统做什么，参与者希望系统做的每件事成为一个用例，为了发现用例，我们可以尝试问如下问题：a. 为什么该参与者想要使用此系统？b. 该参与者是否要创建、保存、更改、移动或读取系统的数据？如果是，为什么？c. 该参与者是否要通知系统外部事件或变化？d. 该参与者是否需要知道系统内部的特定事件 ？126. 验证目标正确性验证参与者： （1）是否您已找到所有的参与者？也就是说，是否您已经对系统环境中的所有参与者都进行了说明和建模？ （2）每个参与者是否至少涉及到一个用例？（3）您能否列出至少两名可以作为特定参与者的人员？（4）是否有参与者担任与系统相关的相似参与者？如果有，您应该将他们合并到一个参与者中。136. 验证目标正确性验证用例： （1）用例模型的简介部分简明清晰地概述此系统的目的和功能；（2）所有的用例已确定，这些用例共同说明所有的必要行为；（3）所有的功能性需求都至少映射到一个用例；（4）该用例模型不包含多余的行为，所有的用例都可回溯到某个功能性