第三章 建立需求模型

如何获取用况？
活动者希望系统执行什么任务？ 活动者在系统中访问哪些信息（创建、存储、 修 改、删除等）？ 需要将外界的哪些信息提供给系统？ 需要将系统的哪个事件告诉活动者？ 如何维护系统？
2 定义及表示法
用况是对参与者使用系统的一项功能时所进行的交互过程的一个文 字描述序列。 几点说明：
（1）一个用况描述参与者对一项或几项系统功能的使用情况。而且只有当外 部的参与者与该系统或类目进行交互时，该功能才发挥作用。 （2）用况中描述的行为实际上是系统级的。在用况内所描述的交互中的动作 应该是详细的，准则是对用况的理解不产生歧义即可;若描述得过于综合，则 不易认识清楚系统的功能。 （3）陈述参与者和系统在交互过程中双方所做的事。而且描述彼此为对方直 接地做什么事，不描述怎么做，内部细节不要在其中描述。 （4）用况既表达了系统的功能需求，也表达了系统的功能划分。
3．2 参与者
简言之，参与者是在系统之外的与系统进行交互的任何事物。
3．2．1 概念与表示法
• 一个参与者定义了用况的使用者在与这些用况交互时所扮演的 一组功能高内聚的角色。 参与者是与系统交互的任何事务。
收款
售货员
检查
•参与者可以发出对系统服务的请求
参与者能够初始系统部分的动作
•按系统的要求提供服务
从如下方面寻找参与者
■ 用户
从直接使用系统的人员中发现参与者。 这里强调的是直接使用，而不是间接的。
特定的人，在系统中可扮演不同的角色。
例如，添加数据、使用数据及产生报告的那个人就扮演了三种不同的角 色，反映为三种不同的参与者。
例如，用户角色的类别可为：目标终端用户、管理员、经理或顾客。
■ 外部系统
1）扩展关系
IF… A IF …C ……
A C
用况X
If… A IF… C …… 用况Y
<<extend>>
<<extend>>
IF…(A) IF… (C) …… 用况X
IF… (A) IF… (C) …… 用况Y
从基用况到扩展用况的扩展关系表明：按基用况中指定的 扩展条件，把扩展用况的行为插入到由基用况中的扩展点定义 的位置。一个用况（在某些扩展点上）扩展另一个用况的功能 ，构成新
系统：是由“用户”使用的软件，以及所有与其相关的硬件。指 被开发的计算机软硬件系统，不是指现实世界的系统。 系统边界：一个系统所包含的所有系统成分与系统以外各种事物 的分界线。 系统成分：在OOA和OOD中定义，在编程时加以实现的系统元素— —对象
系统边界
参与者：在系 统边界以外， 与系统进行交 互的事物—— 人员、设备、 外系统
（5）描述应力求准确、清晰，允许概括，但不要把双方的行为混在 一起。 （6）系统执行该动作序列来为参与者产生一个可观察的结果值。 （7）用况描述的是一个参与者所使用的一项系统功能，该项功能应 该相对完整。这就要求一个用况描述的功能，即不能过大以至于包含 过多的内容，也不能过小以至于仅包含完成一项功能的若干步骤。 （8）用况描述中的一个步骤应该描述且仅描述参与者或系统要完成 的一件事情。 （9）可以使用类图、活动图等对用况进行详细说明。
所有与系统交互的外部应用系统都是参与者。
从系统边界的角度，应该把与软件系统一起运行以完成特定任务的应用 系统，看作是外部的应用。相对于当前在正在开发的系统而言，外部应用系统可 以是其他子系统、上级系统、下级系统或任何与它进行协作的系统，但对它的开 发并不是当前系统的开发小组的责任。
■ 设备
识别所有与系统交互的设备。
•有助于发现主动对象
•对系统测试来说，产生测试用况。 •有助于人机界面设计 •……
怎样确定用况的粒度？
用况的粒度（用况的大小）可大可小，一般一个系 统宜控制在20个 用况左右。
用况是系统级的、抽象的描述，不是细化的（是做 什么，非怎样 做） 对复杂的系统可以划分为若干子系统处理。
3.1 系统边界
外系统——
上级系统 子系统 其它系统
系统外部的参与者，可以是人、外部硬件、其他系 统，甚 至时间。
参与者举例
通过事件表获得参与者：
事件 触发 源
读者
操作
输出
目标
读者检查 书目查询 库存书目 请求 读者借书 借书单
提供书目 书籍列表 读者 供检索 读者 登记借书 书 记录 借书记录
百度文库
读者
参与者可以从“源”得到启发，但“源” 表示数据最 初的提供者，不一定对应功能的执行者。
例如，在ATM 系统中，描述一个用况“验证用户” 可以采用以下方式：
基本流：在系统提示顾客输入PIN编号时，用况开始。顾客通过按键输入PIN 号。顾客按“输入”按钮确认登录。系统校验这个PIN 号是否有效。如果有效， 系统承认这次登录，该用况结束。
可选流：顾客可以在任何时间通过按“取消”按钮取消一个事务，这样，该 用况重新开始。顾客的账户未发生改变。
B
A
3．2．2 识别参与者
下面是一些指导： 1．首先将精力集中于启动系统行为的参与者。这些是最容易识别 的参与者，从中可以找出其他参与者。 2．从用户的角度考虑，怎样使用这个系统。 3．识别单个参与者在系统中可能担当的角色，然后确定参与者的 各个角色。 4. 对识别出来的参与者，记录它们的责任。 5. 通过识别一般的或较特殊的角色来组织参与者。
《extend》
一个扩展用况可以扩展多个用况，一个用况也 可以被多个用况扩展，甚至一个扩展用况自身 也可以被其他扩展用况来扩展。
扩展用况
定义：一个扩展点是用况中的一个位
置，在这样的位置上，如果扩展条件为 真，可就以插入扩展用况中描述的全部 动作序列或其中的一部分，并予以执行。 执行完后，基用况继续执行扩展点下面 的行为。如果扩展条件为假，扩展不会 发生。
可以把扩展点列在用况中的一个题 头为“扩展点”的分栏中。以一种适当 的方式给出扩展点的位置描述，通常采 用普通的文本。
这样的设备与系统相连，向系统提供外界信息，或在系统的控制下运 行。通常，不包括监视器、键盘、鼠标和其它的标准的用户接口类型设备，但 我们考虑外部传感器（输入信息）和受控马达（输出信息）。
总结：如何发现参与者？ 人员——
系统的直接使用者 直接为系统服务的人员
设备——
与系统直接相联的设备 为系统提供信息 在系统控制下运行 不与系统相联的设备 × 计算机设备 ×
为开发者提供一种认识和理解系统的方法。系统、子系统可能会很复杂，充 满了操作和其它部分。通过用况，可以帮助这些元素的使用者根据他们将如何使 用这些元素而直接地认识它们。用况使一个元素的作者可以就元素应该如何被使 用，表达意图。 用况是开发期间随着演化而测试每个元素的基础。 使用用况，有助于捕获界面需求。
输入开始本次收款的命令； 作好收款准备，应收款总 数置为0，输出提示信息； for 顾客选购的每种商品 do 输入商品编号； if 此种商品多于一件 then 输入商品数量 end if； 检索商品名称及单价； 货架商品数减去售出数； if 货架商品数低于下限then 通知供货员请求上货 end if； 计算本种商品总价并打印编号、 名称、数量、单价、总价； 总价累加到应收款总数； end for； 打印应收款总数； 输入顾客交来的款数； 计算应找回的款数， 打印以上两个数目， 应收款数计入帐册。
收款员
超市销售管理系统
上级系统 供货员 收款员、供货员、导购员、经理、保安、顾客 收款机？
3．3用况
用况是对参与者使用系统的一项功能时所进行的交互过程的描述。
1、使用用况的原因
用况是对用户需求（主要是功能需求）的规范化的描述。用户需求是分析工 作的起点，但分析员能够得到的反映用户需求的材料常常是不够规范或不够准确 的。通过全面、认真地定义用况，可把用户对系统的功能需求比较准确地在用况 中表达出来，并且在形式上是较为规范的。 为领域专家、最终用户和开发者提供一种相互交流的手段。
只通过有限的 接口与外部交 互
把内外交互情况描 述清楚，就确切地 定义了系统的需求
用况图：主要用于对系统(子系统)的功能行为进行建模。 系统、子系统或类与外部的参与者（actor）交互的动作序列 的说明，包括各种序列及出错序列。 用况分析可以认为是对 系统功能的分解。 益处： •通过表示在语境中参与者如何与系统交互，使得系统、子系 统和类对于用户和开发者易于探讨和理解。 •易于对需求规范化 •有利于进行OOA
用况； 扩展用况依赖于被扩展依赖（基本用况），只是部 分片断组成，不 是完整的独立用况，无法单独执 行； 通过敞开的虚线箭头表示用况之间的扩展关系，该箭头从提供扩展的 用况指向基用况。这个箭头用关键字<<extend>>标记。可以在这个关键字 附近表示这个关系的条件。
基用况
基用况是可单独存在的，但是在一定的条件下， 它的行为可以被另一个用况的行为扩展。扩展 用况定义一组行为增量，扩展用况定义的行为 离开基用况单独是没意义的。
参与者(人员)
参与者(外系统) 参与者(设备)
现实世界中的事物与系统的关系包括如下几种情况： ■某些事物位于系统边界内，作为系统成分。如超市中的商品， 抽象为系统内的“商品”对象。 ■ 某些事物位于系统边界外，作为参与者。
■某些事物可能既有一个对象作为其抽象描述，而本身（作为现 实世界中的事物）又是在系统边界以外与系统进行交互的参与者。 如超市中的收款员，他本身是现实中的人，作为参与者；在系统 边界内，又有一个相应的“收款员”对象来模拟其行为或管理其 信息，作为系统成分。 ■某些事物即使属于问题域，也与系统责任没有什么关系。如超 市中的保安员，在现实中与超市有关系，但与所开发的系统超市 商品管理系统无关系。这样的事物既不位于系统边界内，也不作 为系统的参与者。 认识清楚上述事物之间的关系，也就划分出了系统边界。
第三章 用况图
面向对象分析与设计 电子商务系
杨 潇（yangxiao@cdut.cn)
第3章
用况图
本章的主要概念—系统边界、参与者、用况、包含、扩展、泛化
问题的提出：在系统尚未存在时，如何描绘用户需要一个什么样的 系统？如何规范地定义用户需求？
考虑问题的思路：把系统看作一个黑箱，看它对外部的客观世界发 挥什么作用，描述它外部可见的行为。 系统是由一条 边界包围起来 的未知空间 系统边界以外 是与系统进行 交互的参与者
可选流：顾客可以在确认之前的任何时刻清除PIN号，并重新输入一个新的 PIN号。 可选流：如果顾客输入了一个无效的PIN 号，用况重新开始。如果连续3 次 无效，系统将取消整个事务，并在60 秒内阻止该顾客与ATM 进行交易。
用况示例
表示形式：
名称（参与者，功能） 行为描述 控制语句 括号或标号
收款员收款
把参与者和用况之间的关联表示成参与者和用况之间的一条实线。
一个用况可能要与系统的一个或几个参与者交互。
收款
售货员
统计员
检查
4 用况之间的关系
在下述情况下，就需要考虑产生新的用况，并在用况间 建立关系： •在一个用况中存在着几处重复使用的动作序列； •在几个用况中存在着重复使用的动作序列； •一个用况中的主要动作序列或分支动作序列过于冗长或 复杂，而且分离它们有助于管理和理解。
响应系统的请求
•通过参与者和系统之间服务请求的复杂对话与系统交互
•所有参与者的请求/响应的完全集构成了可以觉察到的系统的 问题域边界。
•一个参与者的一个实例代表以一种特定的方式与系统进行的单 独的交互。
尽管在模型中使用参与者，但参与者实际上并不是系统的一部分。它 们存在于系统之外。
一些参与者可能具有共同的对系统调用的请求。一种做法是显 式地将这样的每一个请求与每一个参与者相关联。（不推荐） 如果一组参与者具有共同的性质，可以把这些性质抽取出来放 在另一个参与者中，它们再从中继承，把这种关系称为参与者之 间的泛化关系。 从参与者A到参与者B之间的泛化关系是指，A的实例能与和B实例 进行通讯的用况实例进行通信。
例
用况的一个场景是指用况执行过程 中的一个特定的实例或执行路径。
收款员收款
3 用况与参与者之间的关系
用况与参与者间的关联是参与者在用况中的参与（也就是参与者 实例与用况实例之间的相互通信）。
若没有进行特殊的说明，任何一方都可发送和接收消息。即交互 是双向的，参与者能够产生对系统的请求，或系统要求参与者采 取某些动作。 这是参与者和用况之间的唯一关系。