文档介绍：第三章建立需求模型——用况图
用户需求就是用户对所要开发的系统提出的各种要求和期望,其中包括系统的功能、性能、保密要求和交互方式等技术性要求以及成本、交付时间和资源使用限制等非技术性要求。 本章着重讲述对功能需求建模。
要进行软件开发,首先要准确地描述用户需求中的功能需求,形成功能规格说明。当前的一种主流做法是使用用况图来描述系统需求。用况图用于对系统的功能以及与系统进行交互的外部事物建模。通过找出与系统交互的外部事物,并说明它们如何与系统交互,易于对系统进行探讨和理解。用况图是进行OOA的基础。对OOD阶段的人机交互设计和系统测试来说,用况也是非常重要的。
用况图:主要用于对系统(子系统)的功能行为进行建模。
益处:
通过表示在语境中参与者如何与系统交互,使得系统、子系统和类对于用户和开发者易于探讨和理解。
易于对需求规范化
有利于进行OOA
有助于发现主动对象
对系统测试来说,产生测试用例。
有助于人机界面设计
在建立需求模型时,先要确定系统边界,找出在系统边界以外与系统交互的事物,然后从这些事物与系统进行交互的角度,通过用况来描述这些事物怎样使用系统,以及系统向它们提供什么功能。
考虑问题的思路:把系统看作一个黑箱,看它对外部的客观世界发挥什么作用,描述它外部可见的行为。
本文所说的系统是指被开发的计算机软件系统,而不是泛指问题域中的全部事物所构成的现实系统。问题域中的某些事物〈如使用系统的一些人员)位于系统边界之外,作为系统的外部实体处理,而系统内的成分(简称系统成分)是指在OOA和OOD中定义的那些系统元素。
系统边界是一个系统所包含的所有系统成分与系统以外各种事物的分界线。
系统是由一条边界包围起来的未知空间
只通过有限的接口与外部交互
系统边界以外是与系统进行交互的参与者
把内外交互情况描述清楚,就确切地定义了系统的需求
系统边界
系统成分:在OOA和OOD中定义,在编程时加以实现的系统元素——对象
现实世界中的事物与系统的关系包括如下几种情况:
■某些事物位于系统边界内,作为系统成分。如超市中的商品,抽象为系统内的“商品”对象。
■某些事物位于系统边界外,作为参与者。
■某些事物可能既有一个对象作为其抽象描述,而本身(作为现实世界中的事物)又是在系统边界以外与系统进行交互的参与者。如超市中的收款员,他本身是现实中的人,作为参与者;在系统边界内,又有一个相应的“收款员”对象来模拟其行为或管理其信息,作为系统成分。
■某些事物即使属于问题域,也与系统责任没有什么关系。如超市中的保安员,在现实中与超市有关系,但与所开发的系统超市商品管理系统无关系。这样的事物既不位于系统边界内,也不作为系统的参与者。
认识清楚上述事物之间的关系,也就划分出了系统边界。
参与者
概念与表示法
简言之,参与者是在系统之外的与系统进行交互的任何事物。——人员、设备、外系统
收款
检查
收款员
例如,超市里的每个具体的收款员的首要职责为收款,可能他还要负责检验购物篮中商品的质量以及验证顾客的信誉卡以给予优惠。这样,每个收款员可能就要扮演三种在功能上紧密相关的角色。把这组角色定义为一个参与者,对其命名为"收款员"。该参与者的一个实例就是扮演上述角色的一个具体人。这个具体的人,可能还扮演其他参与者(例如商品供货员)的角色,这说明一个系统的用户可以扮演不同的参与者中的角色。
系统边界
参与者(人员)
参与者(设备)
参与者(外系统)
参与者:在系统边界以外,与系统进行交互的事物——人员、设备、外系统
参与者可以发出对系统服务的请求, 要求系统提供服务。系统以某种方式对其做出响应,把响应的结果返回给该参与者或者给其他的参与者。
系统也可以向参与者发出请求,参与者对此做出响应。
为了完成某项功能,一组参与者和系统之间请求与响应的对话可能是复杂的。
尽管在模型中使用参与者,但参与者实际上并不是系统的一部分。它们存在于系统之外。
参与者的标准图符是一个"人形符号",参与者的名字放在图符的下方,如图3-2所示。
顾客
一些参与者可能具有共同的对系统调用的请求。一种做法是显式地将这样的每一个请求与每一个参与者相关联。(不推荐)
引入包含这些共同的交互的一般参与者,并对这些参与者进行特殊化处理,特殊参与者从一般参与者中继承执行这些交互的能力。从特殊参与者到一般参与者之间的继承关系,意味着特殊参与者的实例能够同与一般参与者的实例进行交互的用况实例进行通信。
账户
网络账户
柜台账户
识别参与者
从如下方面寻找参与者
■  用户
从直接使用系统的人员中发现参与者。这里强调的是直接使用,而不是间接的。这样的人可能要启动、维护和关闭系统,更多的可能是这样的人要从系