软件工程学习笔记第九章

9.1用例建模概念

1.用例在需求管理过程中的作用

分析问题--理解干系人的需求--定义需求--用例规约（提纲）--管理领域--完善系统--用例规约（详细）--管理变化的需求

2.用例模型包含的部分

• 关联干系人需要以及软件需求
• 确认与系统交互的人或对象（参与者）
• 定义系统的边界
• 捕捉和传达系统的理想行为

3.用例模型的表示

（1）文本描述：包括用例模型概要和用例规约描述

用例模型概要：系统的功能和意义、参与者列表、用例列表

用例规约描述：对每一个用例进行简要描述和事件流程

（2）用例图

• 参与者
• 用例：注意命名为动宾结构（系统的功能）；一定要有可观测的结果；不能定义的太细或太粗
• 关联：箭头和直线；注意箭头只表示消息的传递方向，而不表示参与者创建用例

4.每一个交互关联代表一个完整对话

5.场景是用例的实例

针对不同的场景，会有不同的事件流。

所以在进行文本描述时，要分别进行描述。

9.2用例建模的过程

1.构建用例模型的步骤

• 第一步：找到所有的参与者和用例

        • 识别出参与者并做简单的描述

        • 识别出用例并做简单的介绍

• 第二步：编写用例

        • 列出用例

        • 给用例事件流程划分重要等级

        • 按照重要程度排序详细描述事件流程

2.参与者

一.寻找参与者

• 谁可以使用系统
• 谁会从系统中获取信息
• 谁会向系统提供信息
• 公司的哪个部门会使用系统
• 谁负责系统的维护
• 还有哪些其它系统会使用系统

二.识别参与者

谁是真正与系统进行交互

三.参与者的描述

不能将参与者命名为”用户“，因为这个词很模糊，很难了解其身份

四.参与者建模的检查项

• 是否找全所有的参与者？是否对系统环境中所有的角色进行了描述和建模？

• 每个参与者是否至少与一个用例发生了交互？

• 是否可以为每一个角色找到至少两个实例？

• 不同参与者与系统的交互是否一致，扮演的角色是否相似？如果有，则应该要合并这些参与者作为同一种角色

3.用例（动宾结构）

注意：在用例建模中，去掉所有的CRUD类的用例（即创建(Create), 查找(Retrieve), 更新(Update), 删除(Delete)），可以合并为一个用例叫做维护用户信息。

4.第一步得到的用例图---用例提纲---用例详细规约

用例图（得到用例的简单描述）

用例提纲（得到粗略事件流程）

详细规约（得到详细事件流程描述，包括前置后置条件，特殊的规约说明）

5.用例建模总结

注意：1.系统边界设定的不同，那么用例模型建立也会不同

以下有三种系统边界

2.不要把用例定义成功能分解

3.用例图的主要图标