面向对象技术学习笔记4：用例建模

用例建模的作用：捕获系统场景，获取软件需求

需求：需求是描述系统必须符合的条件或者必须具备的能力  描述的是系统应该做什么而不是怎么构建系统

需求获取：是定义系统的过程，可以从用户需求中导出，也可以在合同，标准，规范，等文档的陈述得到

用例：是系统执行的一系列事务，这些事务可以给特定参与者产生可度量的结果（目标）或者值

它由一系列动作组成，用户必须执行这些动作，以完成一些有用的工作，才能实现目标

用例反映了在实现这些目标的过程中系统可能发生的所有事件

可用于设计师与用户交流

用例是参与者和系统之间对话的抽象，描述了可能的交互，而不深入每个场景的详细细节

好的用例：从用户角度描述期望系统的行为

允许系统分析师从高层次的业务观点来理解系统并为之建模

表示系统提供给外部实体的接口，以及参与者和系统之间的相互关系

用例必须从用户的角度描述所期望的系统行为，完整的用例集合指定了系统所有可能的行为方式，因而定义了系统的所有需求(行为)，规定了系统的范围，用例应该看作需求定义单元或者仅作为一个用户目标，如"查询余额"


用例建模技术：因为用例的“用户视角，定义做什么而不是怎么做”特点，所以用例分析的重点是系统外部可见的视图，而不是内部视图建模，关注需求而非实现


用例模型:是一幅图或者一组图，还可有给出所提交软件系统要做的工作的文档,用例图由三部分组成:

       参与者

       用例和用例之间的通信

       其他的文档（如用例描述，问题陈述）

       此外，用例图还可能包括系统边界

参与者：

"参与者"更应该起名为为"角色"，表示的是事物或者人对系统扮演的角色

参与者是系统交互的实体，包括需要与系统交换信息的一切实体，因此，参与者是所设计系统的外部实体

参与者可能是以下几类:人，计算机硬件和设备，外部系统

识别用例的通用方法是直接操作系统的用户交谈，满足用户需求，但开发阶段可能漏掉系统的其他涉众的需求

系统的涉众的需求有时会矛盾，需要开会确定所有需求，并解决相互矛盾的需求

系统边界：定义了所开发系统的范围，所有用例共同组成了系统的总需求

在UML中，系统边界用矩形表示，所有用例都应该放在系统边界以内，参与者放到系统边界以外

表示方法：用人形简笔画表示（无论参与者是否是人）或者用带有<<actor>>构造型的类的图标，将<<actor>>放在图标上半部分中类名的上方


主要参与者和次要参与者：

主要参与者是系统设计面向的主要用户或实体，可以从系统中受益

主要参与者完全位于系统外部，并驱动系统需求

主要参与者使用系统以实现某个可以观测的用户目标

（灵活性低）

次要参与者是监督，操作和管理系统的用户或者实体，他们扮演着支撑的角色，以帮助主要参与者的角色实现他们的目标

次要参与者经常更多地出现在系统内部而不是外部

次要参与者通常指定很多系统需求，这些需求不能直接从陈述中得到

（设计师指定时选择灵活）

泛化参与者：

参与者是类，可以泛化，泛化参与者是具体参与者的父类

表示泛化关系的UML图标是指向该参与者超类的空心小箭头

<<include>>用于两个或者多个用例中，以共享时间流中的某些公共部分，然后将该公共部分分组并提取出来，形成一个包含用例，在两个或者多个用例中共享

<<extend>>用于两个用例相似但是一个执行的任务比另一个稍多一些

泛化关系用于子用例继承父用例的行为，关系和通信链接

基本用例和抽象用例：

基本用例基本上就是主用例，它可以直接由某个参与者实例化，因为它本身可以实现可观测的用户目标，抽象用例只有由基本用例实例化，因为它只包含两个或者多个用例之间共享的部分公共行为，因此从用户看来，它不是一个完整的用户目标

参与者直接调用的是基本用例，抽象用例由基本用例实例化，它必须返回到调用用例（基本用例），是基本用例的子程序

通常，只有定义了所有用例之后，才能识别和提取不同用例中相似的行为

使用关系组织用例

UML支持3种用例关系类型:<<include>>,<<extend>>,泛化（UML构造型<<...>>扩展UML语义）

开发用例模型

(1)开发问题描述

(2)识别主要参与者

针对每个参与者编写一段简短的文字描述

(3)识别用例

从采访用户（参与者）开始，通常采用自底而上的方法，要求客户描述业务活动的场景。

每个这样的描述都可能是一个用例，然后可以将这些潜在的用例详细描述，修改，分解成更小的用例或者更大的用例中去

有用的问题：

每个参与者要完成的主要任务是什么

系统要操作和处理什么数据

系统要解决什么问题

参与者使用本系统想要实现什么目标

当前系统主要存在什么主要问题，预期系统如何简化用户的工作

命名用例

由一个动词和一个名词或者名词短语构成

(4)创建初始用例图

初始用例模型特供了系统功能的概貌，可以用作系统的一致的需求规约，对于规划不同用例的开发优先级很有用

可以用层次结构来组织到包中

(5)描述用例

用表记录用例的：名称，ID,参与者，描述

(6)执行文本分析

识别/细化候选业务(领域)类

识别出来的类将用作编写扩展用例描述的词汇表的一部分

对象和类的识别在整个系统开发的每个阶段中逐步细化

通过用例的简要描述，识别系统的类，关注名词和名词短语，作为候选类包含进去，分析的结果是一组带有描述的候选类

画出初始类图现实类之间的静态关系（如果已经进行领域分析来开发类模型，这个步骤的结构将包含在领域类模型中以产生初始类模型）

需要根据每个用例的描述对各个用例进行文本分析，在此过程中将产生一组候选类，然后将这些类包含在领域类模型中，作为初步的类模型，用于后续的初始类模型的开发

扩展初始用例模型

在系统开发中的后续阶段中渐增地扩展初始模型

在每个阶段选取并分析一些用例，以产生必要行为和功能需求的详细说明

当扩展和分析用例时，识别出公共的行为和其他行为，提取这些行为以形成包含，扩展和泛化用例，使用例模型更易于维护

用例中识别出来的类用来更新和细化类模型

(7)开发基本用例描述
不要在描述中使用计算机或者领域的术语，要通俗易懂，要求开发人员和用户都能理解
完全不考虑计算机，而应该只关注用户和系统服务
填充用例模版来捕获有用信息，扩充用例模版中的简要描述，以包含参与者和用例之间的交互细节

用例模版

用例名称
用例ID
超用例
参与者
简要描述
前件
后件
优先级
事件流
其他流和异常
非行为需求
假设
问题
来源

(8)构造用例

根据上面的信息构造用例，使用关系组织用例

开发实例场景:有时开发用例的实例场景来演示某个复杂用例的执行，它还可以用作系统测试中的测试案例

(9)优选用例

选择优先开发的用例

优选用例的主要原则是尽早降低项目的风险和不确定性

如根据对于成功完成系统的相对重要性，或者不熟悉的技术

下面的因素可能会提高用例的优先级

用例在构架上的重要性

使用了未经测试的新技术

需要仔细研究的问题

能够明显提高业务的处理效率或者收益

支持主要业务过程的用例


常用高中低来排序，也可以为每个因素指定一个分值，计算总分来排序