用况图的绘制

用户需求：用户对所要开发的系统提出的各种要求和期望，包括技术需求和非技术需求，系统的功能需求是分析阶段考虑的核心

---

建立需求模型：一种主流做法——使用用况图来描述系统需求

---

需要明确的概念：

1. 用况图的作用：用于对系统的功能以及与系统进行交互的外部事物建模（即描述系统内外交互的情况）

2. 用况：描述事物怎样使用系统，以及系统向外部事物提供什么功能。是描述系统的一项功能的一组动作序列，这样的动作序列表示参与者与系统间的交互，系统执行该动作序列要为参与者产生结果

3. 问题域：被开发系统的应用领域，即在现实世界中由这个系统进行处理的业务范围

4. 系统责任：所开发的系统应该具备的职能

5. 系统成分：系统内部成分，指在OOA和OOD中定义的系统元素

6. 系统边界：一个系统所包含的所有系统成分与系统以外各种事物的分界线

7. 参与者：一个参与者定义了一组在功能上密切相关的角色，是系统之外与系统进行交互的任何事物（一个系统用户可以扮演不同的参与者的角色，一个参与者也可以由一组用户来扮演；可以把参与者与系统之间的关系看作请求与响应，即对话），包括人员、外部系统、设备（标准用户接口设备由操作系统管理不包含在内，如键盘鼠标等）

   ---

用例图举例：（ATM维护和修理用例图、学生选课系统用例图）

---

---

---

---

---

需求模型构建步骤（用况图的绘制）：

1.确定系统边界

现实世界的事物（问题域）和系统的关系：

a.边界内
b.边界外
c.既在边界内又在边界外（如收银员）
d.不在边界内也不在边界外（属于系统责任之外）

---

2.确定参与者

• 人员——系统的直接使用者、直接为系统服务的人员
• 设备——与系统直接相联的设备、为系统提供信息、在系统控制下运行
• 外部系统——上级系统、子系统、其它系统

---

Who will supply, use, or remove information? （提供，使用，或删除信息）
Who will supply, use, or remove information? （提供，使用，或删除信息）
Who will use this functionality（使用功能）?
Who is interested in a certain（对某一需求感兴趣） requirement?
Where in the organization is the system used? （组织中使用部门）
Who will support and maintain the system?支持和维护
What are the system’s external resources?外部资源
What other systems will need to interact（外部系统交互）with this one?

---

3.确定用况

用况的粒度：

• 概念级（描述商业目标，包括多个用户目标级用况，用于初期需求讨论）
• 用户目标级（描述执行者或用户完成工作或使用系统的目的，完成一项任务的描述）
• 子功能级（比用户目标级用例再低一级的用例）
  

  ---

用况描述方式：
图符（包含用况名字的椭圆）+用况文字描述（自然语言/活动图/伪码/表格）。
用于区分用况交互序列的基本流和可选流（包括常规变型、异常情况、例外情况）即事件流是描述用况的常用方式。

---

注意事项：
A.用况与场景的关系：用况（类）被参与者使用（实例化）成为一个场景（即该用况类的一个实例）
B.用况是不分层的，要保证一个用况类是某项功能的完整说明，包括可能出现的各种情况并进行概括
C.用况描述参与者和系统的直接交互，不描述间接交互和怎么交互
D.用况描述的准则：对用况的理解不产生歧义。

---

---

用况的捕获：

A.利用参与者捕获：

• 每个参与者的主要任务是什么？——粗粒度

是什么事件引起了与系统进行交互的序列？ ——细粒度

为了达到某种目的，参与者参加什么活动？
该参与者是否将读写系统的任何信息？
参与者是否把系统外部的变化通知系统？
参与者是否希望系统把预料之外的变化通知自己？ ——细粒度
在交互过程中，它们是怎样使用系统的服务来完成它们的任务以达到目的？ ——细粒度

• 它们参加了什么在本质上是不同的过程？

B.从系统功能角度捕获：

（1）以穷举的方式检查用户对系统的功能需求是否能在各个用况中体现出来。

（2）以穷举的方式考虑每一个参与者与系统的交互情况，看看每个参与者要求系统提供什么功能，以及参与者的每一项输入信息将要求系统作出什么反映，进行什么处理。

（3）考虑对例外情况的处理。针对用况描述的基本流，要详尽地考虑各种其他的情况

（4） 一个用况描述一项功能，这项功能不能过大。例如，把一个企业信息管理系统粗略地分为生产管理、供销管理、财务管理和人事管理等几大方面的功能，就显得粒度太大了，应该再进行细化。

（5）一个用况应该是一个完整的任务，通常应该在一个相对短的时间段内完成。如果一个用况的各部分被分配在不同的时间段，尤其被不同的参与者执行，最好还是将各部分作为单独的用况对待。

---

4.确定用况图元素之间的关系

A.用况与参与者之间：关联（参与者实例与用况实例之间的相互通信）

B.用况与用况之间：

• 继承（特殊与一般的关系）

• 包含（基用况包含供应者用况，把重复的交互行为放到一个用况中）

• 扩展（扩展用况是基用况的扩展，基用况可以单独存在，把可选<即满足一定条件才会发生>的交互行为抽取出来）

C.参与者和参与者之间：继承

---

5.检查与调整