用例建模笔记

第一章用例建模简介

1.1参与者和用例
参与者：代表了以某种方式与系统交互的人或事
用 例：代表了为参与者所执行的有价值的操作
1.2用例图
表示参与者与用例之间关系的图，头部的箭头表示参与者

1.3需求和用例之间的关系
用例主要是表达需求的一种方式，主要描述系统的行为方面
1.3.1需求的类型
需求描述了系统主要遵循的某种条件或能力

1. 需要：涉众认为系统需要完成的事情
2. 特性：系统功能的非正式说明，通常用于市场推广和产品定位，可以作为系统行为的简要说明
3. 软件需求：系统必须要遵循的条件或功能的单独陈述
   

可追踪性是双向的
1.3.2功能性需求和非功能性需求
例：

1. 功能性：当呼叫者挂机时，系统应该停止呼叫
2. 非功能性：在完成拨号和呼叫设备响铃的响应时间，应在95%的情况下控制在0.5秒

第二章用例建模基础

2.1用例模型
是所有用于描述指定系统的用例、参与者和用例–参与者关联关系的组合，UML（统一建模语言）将模型定义为主观系统在语义上封闭的抽象，可用于描述系统的功能性需求和系统的其他分类
2.2.1参与者
表示人或其他系统
2.2.2用例

• 要由参与者来启动 由系统提供

• 可以涉及多个参与者 描述了系统及其参与者如何协作完成至少一个参与者的目标

• 提供了如何使用系统及系统所能完成任务的概括
  2.2.3连接参与者和用例

• 无箭头的连接：表示参与者和用例要使用通信之间的关联关系

• 右箭头的连接：使用箭头的位置表示了启动用例的元素
  2.2.4用例描述
  

用例描述提供了用例模型的实质内容，是大多数用例建模的基础
1）事件流：事件流是地图，描述了系统和参与者如何协作来传递用例所承诺的价值。
a：基本流：是对用例中常规、预期路径的描述，仅仅是一个概括
b：备选流：一个主题上可选的文本或变体，异常或出错条件
2）前置条件：用例发生前系统所处的状态
3）后置条件：用例发生后系统所处的状态
例子：
用例名称：测试歌曲
参与者：歌词编辑者
简要说明：歌词编辑者用来测试歌词文件中添加的时间戳是否与音频播放速度一致
前置条件：歌词编辑者已经导入了歌词文件和相应音频文件
基本事件流： 歌词编辑人鼠标点击播放歌曲按钮和开始测试按钮
系统开始播放歌曲，当播放至相应歌词时歌词文件中对应歌词高亮