面向对象分析和总结.docxVIP

第二部分 面向对象分析 第三章 用况图 用况图主要用于对系统（子系统）的功能进行建模，建立基于用况概念的需求分析模型。用况分析首先要确定系统边界；进而找出在系统边界以外直接与系统进行交互的各类参与 者；然后从参与者与系统进行交互的角度，定义系统应该对外提供的每一项功能，即用况； 最后对系统边界、参与者、用况等模型元素进行可视化表示，形成需求模型，即为用况图。本章的主要介绍系统边界、参与者以及用况的基本概念和使用方法，包括识别方法、概念和 表示方法等，并给出用况分析的具体实例。 系统边界 在系统尚未存在时，如何描绘用户需要一个什么样的系统？如何规范地定义用户需求？ 解决这个问题的思路：把系统看作一个黑箱，看它对外部的客观世界发挥什么作用，描述它外部可见的行为。 系统边界是一个系统所包含的所有系统成分与系统以外各种事物的分界线。在这条分界 线以内，是系统本身所包含的全部对象；在系统边界以外，是与系统进行信息交换的各种事物——人员、设备和外系统等各种参与者。 系统边界 参与者（人员） 参与者（设备） 参与者（外系统） 现实世界中的事物与系统的关系包括如下几种情况： 某些事物位于系统边界内，作为系统成分。如超市中的商品，抽象为系统内的“ 商品”对象； 某些事物将是与系统进行交互的参与者，系统中没有相应的成分作为它们的抽象表示。 某些事物可能既有一个对象作为其抽象捞述，而本身（作为现实世界中的事物） 又在系统边界以外与系统进行交互。如超市中的收款员，他本身是现实中的人，并作为系统的参与者；在系统边界内，又可设立一个相应的“收款员”对象作为系统成分来模拟其行为或管理其信息。 某些事物即使属于问题域，也与系统责任没有什么关系。如超市中的保安员，在 现实中与超市有关系，但与所开发的系统超市商品管理系统无关系。这样的事物既不位于系 统边界内，也不作为系统的参与者。认识清楚上述事物之间的关系，也就划分出了系统边界。 参与者 参与者是与系统、子系统或类交互的外部人员进程或事务的理想化。在运行时，具体人员会充当系统的多个参与者，不同的用户可能会成为同一个参与者，从而代表同一个参与者定义中的不同实例。 概念与表示法 一个参与者定义了用况的使用者在与这些用况交互时所扮演的一组功能高内聚的角色。参与者是在系统之外（透过系统边界）与系统进行交互的任何事务。参与者具有如下特征： 参与者可以发出对系统服务的请求，能够初始系统部分的动作； 按系统的要求提供服务，响应系统的请求； 通过参与者和系统之间服务请求的复杂对话与系统交互； 所有参与者的请求/响应的完全集构成了可以觉察到的系统的问题域边界; 一个参与者的一个实例代表以一种特定的方式与系统进行的单独的交互。尽管在模型中使用参与者，但参与者实际上并不是系统的一部分，它们存在于系统之外。 表示法：参与者的标准图符是一个“人形符号”，参与者的名字放在图符的下方。如下图 3-2-1 所示。 顾客 图 3-2-1 参与者“顾客”的表示法 如果一些参与者与系统的交互有一部分是相同的，引入包含这些共同的加护的一般参与 者，并对这些参与者进行特殊化处理，特殊参与者从一般参与者中继承执行这些交互的能力。 识别参与者 下面讲述如何从人员、设备、外部系统三个方面识别参与者： 人员 从直接使用系统的人员中发现参与者，这里强调的是直接使用，而不是间接的。他们可能要从系统获得什么信息或向系统提供什么信息。特定的人在系统中可扮演不同的角色。例如，添加数据、使用数据及产生报告的那个人就扮演了三种不同的角色，反映为三种不同的参与者。例如，用户角色的类别可分为：目标终端用户、管理员、经理或顾客。 外部系统 所有与系统交互的外部应用系统都是参与者。从系统边界的角度，应该把与软件系统一 起运行以完成特定任务的应用系统，看作是外部的应用。相对于当前在正在开发的系统而言， 外部应用系统可以是其他子系统、上级系统、下级系统或任何与它进行协作的系统，但对它 的开发并不是当前系统的开发小组的责任。 设备 识别所有与系统交互的设备。这样的设备与系统相连，向系统提供外界信息，或在系统的控制下运行。通常，不包括监视器、键盘、鼠标和其它的标准的用户接口类型设备，但外部传感器（输入信息）和受控马达（输出信息）这样的与系统交互的设备可作为参与者。 用况 用况是对用户需求（主要是功能需求）的规范化的描述。用户需求是分析工作的起点， 但分析员能够得到的反映用户需求的材料常常是不够规范或不够准确的。通过全面、认真地 定义用况，可把用户对系统的功能需求比较准确地在用况中表达出来，并且在形式上是较为 规范的。为领域专家、最终用户和开发者提供一种相互交流的手段。为开发者提供一种认识 和理解系统的方法。系统、子系统可能会很复杂，充满了操作和其它部分。通过用况，可以帮助这些元素的使用