中科院需求工程 需求工程(第七讲)问题框架方法_

b: EnterPeriod, EnterRange,
a
EnterPatientName, EnterFactor
b
医生
c: Notify d: PatientName, FactorValue
e: RegisterValue
c
f: FactorEvedence
护士工作站
d
e
数据库
模拟设备 f 病人
FE!{WaterTemp, FlameState, BlowerSpeed}
d: HR+FE:{WaterFlow, WaterHeat}
面板显示 (PD)
供暖房间+火 炉设备(HF)
显示~状 态和功能
火炉控制 器(FC)
控制面板+手 工操作控制器
(CH)
火炉设备 (FE)
安全开/ 关操作
基本问题框架类
计算机与外部世界
计算机及其 上的软件
计算机以外的 现实世界
这里是解 决方案
现实世界和计 算机之间的连
接
这里是 问题
初始问题关注点（结构化分析）
客户
订购，付款 帐单
订购
信用状态
零售企 业系统
供应商
财务报告
银行帐 户部门
帐单，查询
运送报告
发货通知
仓库
初始问题关注点（用例）
会员
借书 还书 续借
建模元素和问题分析
基本问题类和问题框架
• 问题类：
– 软件开发问题可能完全不同 – 但可能有相同或者相似的子问题
• 问题框架：
– 可重复出现的问题模式 – 可根据上下文以及领域特征、接口特征和需求
特征来定义 – 以现象的分类为基础
• 划分基本问题类的意义：
– 不同的问题类有不同的需求分析关注点
领域特征
• 因果领域（causal domain）：在它与外界 共享的因果现象之间存在可预测的因果关 系。
如何关注于问题?
• 区别欲关注解决方案：
– 应该用什么SQL语句来写数据库？ – 监护过程应该如何调度，以便每个病人都按所
需要的频度得到监护？ – 系统应该有哪些对象类？ – 病人列表应保留在Java向量中吗？
如何关注于问题？
• 图书馆管理问题
• 需要一个系统来管理一个外借图书馆。借 书的必须是会员，但在馆内阅览不需要。 图书可以预借并从有联系的图书馆那里获 得。过期要交罚款。需要各种管理报告。
和/或所连接领域的行为
问题图：问题是什么
• 在上下文图的基础上，进 一步显示：
– 现象的进一步细化
控制现象的领域！具体现象的集合
– 需求 – 需求引用和/或需求约束
需求陈述 引用的现象 约束的现象
问题图（病人监护问题）
监护机器
周期和范围
a
医生
b
c
护士工作站
d
e
数据库
g
监护病人、通知护士工
f
作站、检查设备、j将参
– 真值。不能随时间发生变化的个体间的关系。 – 角色。一个事件和用一种特殊的方式参与这个
事件的个体之间的关系。
现象的类型
• 因果现象：
– 包括事件、或是角色、或是状态关系实体。 – 它们是直接由一些领域引起的或控制的，并且
它们能够反过来引发其它现象。
• 符号现象：
– 包括值、真值以及只与值相关的状态。 – 它们被用来符号化其它现象及其它们之间的关36.源自km/h50436.9km
车的后轮在旋转时产生脉冲，计算机能够检测到这些脉冲，并用它们来 确定在仪表盘计数器上显示出来的当前速度和总行驶公里数。这个计数 器的基本寄存器由计算机和显示器共享。
a 行驶的汽车
（CR）
c
里程表显示
领域（标识上下文）
• 机器领域：我们所要构建 的
• 设计领域：设计出来作为 信息的物理表示的
• 给定领域：物理领域，其 特性是不能改变的
现象（共享现象）
• 两个领域之间的接口 • 所连接的两个领域共同参与和共享 • 现象的种类：
– 事件：比如，机器和护士工作站共享 “监护报警通知”事件
– 状态：比如，机器和模拟设备共享病 人皮肤阻抗的状态
OnIgnition, OffIgnition, OnBlower, OffBlower}
FE!{WaterTemp, FlameState, BlowerSpeed}
d: HR+FE:{WaterFlow, WaterHeat}
显示机器 (DM)
供暖房间
控制面板 a (CP)
b 供暖控制
器(HC)
A
D
C
还是划分?
AB
D
B
C
E
•子问题是完整的，有自己的问题图，自己的机器， 自己的问题领域，自己的需求 •子问题之间是并行结构，而不是层次结构 •子问题之间的交互具有并发性，是带有共享变量的 多个问题领域机器的并发执行引起的
家庭供暖控制
• 一个家庭供暖系统使用热水散热器，每个房间有一个温度 感应器，一个温度控制按钮，一个红外线房间占用感应器， 一个或多个散热器，以及一个开关计算机控制的散热器阀 门。水由一个燃油炉加热，让流过阀门的油吹进燃烧区并 点燃，燃油炉有一个火焰感应器，一个燃料流感应器，一 个喷射马达速度感应器，和一个水温感应器。一个水泵使 水在这个系统中循环。
问题分析
上下文图显示了机器将处于的外部世界（问题领
域）的各个部分，但没有显示要解决的问题
• 需求（需求现象）
– 客户希望在问题领域中 为真的事情
• 问题领域中将成立的关 系
• 问题领域将展现的行为 • ……
– 希求式的陈述
• 领域特性
– 每个问题领域中要关注 的特性
– 关于领域的客观事实 – 陈述式的描述
– 取值：比如，机器和模拟设备共享要 监测的病人的相关数据取值
上下文图：问题在何处
• 领域
– 机器领域
– 外部环境
• 给定领域
• 设计领域
• 接口（共享现象）
– 事件
– 状态 – 取值
领域
共享 现象
领域
上下文图（病人监护问题）
监护机器
周期和范围 a: Period, Range, PantientName, Factor
如何关注于问题？
• 关注于问题意味着要考虑如下问题：
• 是所有馆藏书都可以外借，还是有一部分只能在 馆内阅读？
• 借书期限可延长吗？如果可以，延长的期限是多 少？
• 会员可以预留书吗？如果可以，预留多长时间？ • 非会员可以预留书吗？ • 会员要交费吗？会员持续多长时间？ • 允许从有三卷的书中借走其中的一卷吗？
– 实体。是一直存在的个体，它可以在不同时间 点有不同的特性和状态。一些实体可以启动事 件；一些实体的状态可能会自发地变化；一些 实体可能是被动的由其它实体改变。
– 值。一个无形的实体，它存在于时间和空间之 外，是不会改变的。
现象的表示
• 关系：一组个体间的关联
– 状态。实体和值之间的一个关系；它可以随时 间而变化。
如何关注于问题?
• 关注于问题意味着考虑如下问题？
• 所有的病人都要被监护，还是其中的一部分需要被监护？ • 是对不同的病人有不同的参数，还是所有的病人有相同的
参数？ • 是医生还是其他什么人指明参数读取周期以及范围？ • 模拟设备在什么情况下可能失效？这些失效能被检测到和
诊断出来吗？ • 在病人被监护过程中，病人的监护需求会发生变化吗？
系。
需求式行为框架
– 存在物理世界的某个部分，它的行为要 被控制，以使得它满足确定的条件。
– 问题是要构建一个机器，这个机器将施加 所需要的控制。
控制机器 CM!C1 被控制的领 C3 （CM） CD!C2 域（CD）C
希求的行为
需求式行为框架例
灯控制器 (LC)
a
灯组(LU)
b
灯光变化 规则
a: LC!{RPulse[i],GPulse[i]} b: LU!{Stop[i], Go[i]}
• 有一个控制面板，通过它可以命令控制器打开还是关上取 暖炉；
• 这个面板上还提供一个显示，指明系统的状态和任何的故 障。
• 计算机必须控制系统的行为，来使房间的温度保持在控制 按钮所设置的温度。从经济方面考虑，没有人住的房间应 该比按钮设置的温度低5度，系统可以使用来自房间占用 感应器的信息来判断房间的使用情况。
• 顺从的领域（可叫牌领域）（biddable domain）：通常由人组成，其重要特征是 它是物理的，但却没有明确的可预测的内 部因果性。
• 词法领域（lexicon domain）：是数据的物 理表示，即符号现象。
现象的表示和建模
• 个体：可以命名并区别于其它个体
– 事件。某个特定时间点上发生或出现的个体， 时间点是不可分并且瞬时的：事件没有中间结 构，它的发生也不化时间。
• 机器需求
– 机器与问题领域接口上 的期望行为
领域特性是客户需求和机器需求之间的桥梁
需求引用和需求约束
• 需求引用和需求约束都是关于问题领域的 • 所以它们都只连接到问题领域 • 需求引用
– 该需求涉及到所连接领域的特定现象
• 需求约束
– 该需求不仅涉及到所连接领域的特定现象， – 而且还规定了这些现象之间的希望满足的关系，
(HR) d
c 火炉设备
(FE) a: CP!{Commands}, HC!{CmdsDisplay}
b: HR!{TempKnob, Temp, OccupancySensor}
c: HC!{OnPump, OffPump, OpenOil, CloseOil,
OnIgnition, OffIgnition, OnBlower, OffBlower}
数存储在数据库中,允许
i
输入周期和范围
j
k
l
模拟设备 f 病人
问题和子问题
• 分解：控制问题复杂性的关键，常用
– 自顶向下的功能分解 – 用例分解
• 如何判定好的分解？如何判定分解后的不 分解前的要容易解决？如何保证分解后的 部分正好可以并起来解决原有问题？
问题结构化
识别出问题 中的子问题
是投影?
命令式行为框架
• 存在物理世界的某个部分，其行为要 按照一个操作者发出的命令来控制。
• 问题是构建一个机器，它将接受操作者
的命令并相应地施加控制。
CM!C1 被控制的领
CD!C2
控制机器
域（CD）C
C3
（CM）
OP!E4
操作者
E4
（OP） B
命令行为
命令式行为框架例
水闸门控制 一个小水库有一个升降水闸，需要一个计算机系统来控制这个水闸。每三个 小时有十分钟这个水闸要处于全开的位置，其余时间让它处于全关的位置。 这个水闸用一个垂直转轮来打开和关上，这个转轮由一个小马达来驱动，它 可以用顺时针、逆时针、开、关四种脉冲来控制，水闸的顶端和底端各有一 个感应器；水闸处于顶端为全开，处于底端为全关。与计算机的连接由四根 用于控制马达的脉冲线和两根连接感应器的状态线组成。
• 开发者的失败在于捕获和理解问题上，而 不是设计和实现一个解决方案上。
• 通过关注问题，可以识别出关键的困难， 准确理解用户的意图。
如何关注于问题?
• 病人监护问题
– 医院的重症监护室需要一个病人监护系统。每 个病人都要有一个模拟设备来监护，这些设备 用来测量诸如脉搏、体温、血压、以及皮肤阻 抗等参数。这个系统按（对每个病人特定的） 一定周期来读取这些参数，并存储到一个数据 库中。医生需指明每个病人各个参数的安全范 围。如果某参数的值超出了该病人的安全范围， 或者模拟设备失效，则要通知护士工作站。
需求工程
金芝 中国科学院数学与系统科学研究院
zhijin@
第七讲：问题框架方法
• 关注和定位问题 • 建模元素和问题分析 • 基本问题框架类 • 问题框架关注点 • 总结 • 课程实践
关注和定位问题
为什么要关注于问题？
• 硬件和软件运行是正确的，但它们完成的 功能不是所需要的。
门和马达
a
（GM）
b
水闸控制器
（SC）
c 水闸操作者
c
（SO）
升高和降 低水闸们
a: SC!{Clockw, Anti, On, Off} GM!{Top, Bottom}
b: GM!{Open, Shut, Rising, Falling} c: SO!{Raise, Lower, Stop}
信息显示框架
• 存在物理世界的某个部分，连续地需要关 于它的状态和行为的确定信息。
• 问题是构建一个机器，这个机器将从物理 世界中获得这些信息，并按所要求的格式 呈现在所要求的地方。
RW!C1
信息机器 （IM）
IM!E2
现实世界 （RW） C
显示（D）C
C3
显示~现实世 界对应规则
Y4
信息显示框架例
里程表显示 需要一个芯片计算机来控制汽车中的速度计和里程计。它们的 显示形式如下图所示：
供暖房间
b
(HR)
控制面板 a
供暖控制
(CP)
器(HC)
d
c 火炉设备
a: CP!{Commands}, HC!{CmdsDisplay}
(FE)
b: HR!{TempKnob, Temp, OccupancySensor}
c: HC!{OnPump, OffPump, OpenOil, CloseOil,