三、面向对象的需求

9.1 面向对象的需求获取概述

9.1.1 对需求获取的总的看法

需求获取 将注意力放在系统目标的描述上。开发者、客户和用户共同标识了一个问题域，定义了解决这一问题域的系统。这类定义称为 需求规格说明 ，这类定义可用于开发者和用户之间的沟通。

需求获取包括如下活动：

•  标识参与者 。开发者需要标识出未来系统将支持的不同用户类型。

•  标识场景 。为了获得未来系统将提供的典型功能，开发者对用户活动进行观察并开发出一组带有细节的场景。开发者使用这些场景与用户进行沟通并加深开发者对应用域的理解。

•  标识用例 。一旦用户和开发者确认了一组场景，开发者将从场景中导出一组能够完全表示未来系统的用例。当场景所表示的是一种具体实例时，将从中抽象出用例，以描述所有可能情况。在描述用例时，开发者即决定了系统的范围。

•  求精用例 。通过细化每一个用例，以及使用带有错误处理的用例和使用异常条件处理的用例，描述系统的行为。开发者应确保需求规格说明是完全的。

•  标识用例之间的关系 。开发者标识出用例之间的依赖关系。通过提取相同功能，开发者可以巩固用例模型。这一做法保证了需求规格说明是一致性的。

•  标识非功能需求 。开发者、用户和客户需要对用户可见的非功能需求的方方面面进行标识。这些内容包括系统性能上的约束、文档、将要消耗的资源、其安全性和其质量等。 在需求获取期间，开发者将访问不同的信息资源，包括：

•  客户所提供的、与应用域相关的文档和手册；

•  将被未来系统替换的遗留系统的技术文档；

•  用户和客户本人。第三个方面是最重要的信息资源，因为开发者在需求获取活动期间的最多活动是与用户和客户之间的交流。

在需求工程期间，常常使用一种称为 联合应用设计（ Joint Application Design ， JAD ） 的沟通技术，即用户和开发者联合开发需求规格说明，将注意点放在营造开发者、用户和客户之间容易进行沟通的气氛上。需求工程中的 跟踪性 将注意点放在记录、形式化、联结、分组和操作需求之间的依赖关系，以及需求和其它工作产品之间的依赖关系上。

9.1.2 需求获取概念

在本节中，我们主要描述需求获取概念，特别描述如下内容：功能需求；非功能需求；需求规格说明的确认；需求规格说明的属性；需求规格说明的类型和描述需求获取活动。

1. 功能需求

功能需求 描述了系统与其独立于系统实现的环境之间的交互。环境包括用户和任何其它与该系统进行交互的外部系统。

2. 非功能需求

非功能需求 描述了不直接关联到系统功能行为方面。

可用性 包括用户可学会的操作、对输入需要进行的准备、对一个系统可进行的解释以及对输出状况的分析等。

可靠性 使得我们对系统提交的服务具有足够的信心，它 包括 可靠性 、 健壮性 等。

性能 需求是系统要考虑的定量属性，例如 响应时间 、 吞吐量 、 有效性 。

可维护性 需求关注的是在部署改变后系统所处的状况，包括 可适配性 、 可维护性 、 国际化 。

3. 需求规格说明的确认

确认需求规格说明 包括检查需求规格说明是否是完全、一致、无二义性和正确的。

4. 需求规格说明的属性

需求规格说明中最重要的属性是可现实性、确认性和可追踪性。需求规格说明是 可 现实性 的，如果系统在约束下是可实现的话。需求规格说明是 可 确认 的，如果系统一旦构建起来后，就能够使得设计结论能进行测试，以说明系统实现了该需求规格说明。

如果针对每一个需求规格说明，均可通过软件开发过程，实现其对应的系统功能，且如果每一个系统功能可逆向追踪到其对应的需求规格说明集合上的话 , 则我们说需求规格说明是 可追踪 的。

5. 需求获取的类型

依据需求的来源，需求获取活动可分为三类：首次工程、再工程和界面工程。

首次工程 是因为没有现成系统存在，开发过程将从打草稿开始，因此需要从用户和客户处获取需求。首次工程项目由用户需求或新的市场需求启动。例如，卫星表可看成是一个首次工程项目。

再工程 项目是针对一个现存系统或遗留系统进行的再设计和再实现，其启动原因是可行的技术或商业需求。有时再工程是因为在二次开发活动中系统扩展了新功能，而基本系统的目标保持不变。新系统的需求从现存系统或遗留系统中获取。

界面工程 项目是对一个现存系统用户界面的再设计。除了界面外，现存系统或遗留系统中的功能，将毫无悬念地被保留下来，只需对其界面进行再设计和再实现。这类项目是再工程项目，在此项目中，如果开销代价不高的话，现存系统或遗留系统是不可能丢弃的。

 

9.2 需求获取活动

9.2.1 标识参与者

图 9.4 卫星表系统中的参与者

需求获取的第一步是标识参与者。这一步骤定义了系统边界，并从开发者角度描述了系统中的所有观察点。

9.2.2 标识场景

场景中的主要类型包括： 当前场景 ； 原型场景 、 评价场景 和 培训场景 。

在标识场景的过程中，开发者可通过如下问题的提出，来获取和确认场景：

•  参与者希望系统完成的任务是什么？

•  参与者要访问的信息是什么？谁创建了这些数据？这些数据可以做修改或删除吗？由谁完成这些工作？

•  参与者需要告知系统，相关外部交换是什么？怎样交换？何时交换？

•  系统需要向参与者询问的事件是什么？最迟时期多长？

结合火灾报警与调度系统实例，我们可标识出四个任务场景： 1 ） 仓库火灾场景； 2 ） 挡泥板被撞场景； 3 ）轿车撞树场景； 4 ）地震场景。

9.2.3 标识用例

场景 是 用例 的实例，即对一个给定功能而言，一个用例可以说明所有可能场景，参与者可启动用例。在用例被启动后，该用例也可以与其它参与者进行交互。一个用例标识了贯穿相关系统事件的全部流程，在这种情况下，用例描述了一系列从初始情况出发的相关交互。通过用例可以定义开发范围，即通过泛化场景和标识系统，使得开发者能够在高层用例层定义系统的开发范围。具体做法是，在初始时，开发者对用例进行命名，将这些用例与初始参与者关联起来。用例的名字应该是一个动词短语，以说明参与者将完成什么功能。

9.2.4 求精用例

通过求精用例，将会产生大量细节，这些细节涉及未来系统应提供的特征和与系统相关联的约束。特别要注意在初始时那些有意或无意忽略用例的相关情况，这些内容在用例求精过程中被细化：

•  细化系统操纵的元素；

•  说明参与者和系统之间的低层交互序列；

•  说明访问权限（这些权限约束了参与者可引用的那些用例）；

•  标识出遗失的异常情况，说明对这些异常情况的处理；

•  分离出用例之间的公共功能。

9.2.5 标识初始的分析对象

为了标识出对象，在此给出其中的一些准则：

•  对于理解用例而言，开发者和用户所使用的术语，其含义必须是清楚的；

•  在用例中出现可重复的名词（例如，事件）应该引起注意；

•  如果是系统必须跟踪的现实世界中的实体（例如，现场工作人员，资源），则要引起注意；

•  如果是系统必须跟踪的现实世界中的处理（例如，危机处理计划），则要引起注意；

•  如果是用例（例如，报告紧急情况），则应产生一个对应的对象；

•  如果是数据源和数据汇（例如，打印机），则应认真分析；

•  与用户进行交互的人工制品（例如，工作站）应引起注意；

•  总是 出现在应用域中的术语要特别引起注意。

 

9.3 需求获取管理

9.3.1 客户谈判规格说明：联合应用设计

联合应用设计 （ JAD ）是由 IBM 公司在 70 年代末提出的一种需求开发方法。

JAD 由五个活动组成（参见图 9.13 ）。

1. 项目定义

2. 调研

3. 准备

4. 会议

5. 最终文档

图 9.13 JAD 的活动

9.3.2 追踪性维护

追踪性是对需求进行跟踪的能力。这一能力包括跟踪需求从哪里来（例如，谁组织需求？该需求要解决哪一个客户的需要？），到系统的哪一部分去，以及对项目的影响（例如，哪一个构件实现了该需求，哪一个测试检查了其实现）。追踪性使得开发者看到的系统是完全的，测试者看到的系统是否与其需求相符合，设计者记录系统内部的机理，以及维护者评价变化带来的影响。

维持 追踪性的最简单方法是在文档、模型和代码制品之间进行交叉参考。

 

9.4 面向对象分析

9.4.1 分析的概述

分析 将关注点放在系统模型的产生上，这一模型称为分析模型，该模型应该是正确的、完全的、一致性的和可确认的。

9.4.2 分析的概念

1. 对象模型和动态模型分析

分析模型表示从用户视点出发，分析将开发的系统。 分析对象模型 是分析模型的一部分，该模型将注意点放在由系统、系统特征和系统关系操纵的单一概念上。用 UML 类图描述的分析对象模型，包括类、属性和操作。分析对象模型是对用户是可见的。

动态模型 将注意点放在系统的行为上。动态模型用顺序图或者用状态图描述。顺序图表示在单一用例期间，一组对象之间的交互。状态图表示了单一对象（或者一组关联紧密的处理对象）的行为。状态图将责任分配给某一类，并且在这一过程中标识出新类、关联和属性，并将之加入分析对象模型中。

2. 实体、边界和控制对象

在分析对象模型中，包括了实体对象、边界对象和控制对象三种类型。 实体对象 表示系统将跟踪的持久信息。 边界对象 表示参与者与系统之间的接口和交互。 控制对象 负责用例实现。例如，在具有两个按钮的卫星表实例中，年、月和日是实体对象；按钮和液晶显示器是边界对象；改变数据控制是控制对象，以表示通过按下组合按钮改变日期的活动。我们将实体对象、边界对象和控制对象所构成的分析对象模型称为 三对象模型 。

3. 泛化和特化

继承 使得我们能够将概念组织成层次结构。

泛化 是建模中的活动，该活动标明了从多个底层概念中得到的抽象概念。例如，我们可以将交通事故和火灾抽象为紧急情况，以描述交通事件和火灾的共同（或泛化）特征。 特化 是建模中的活动，该活动将一个源于高层的概念特化为多个实例。

.5 小结

需求获取活动是高度迭代和增量化的开发活动。对用户和客户而言，大粒度功能被表示成框架和建议的结构。客户增加需求，评价现存的功能，修改现存的需求。通过原型法，开发者对非功能需求进行调研，并挑战每一个需求。在初始的时候，需求获取是一次集思广益的活动。随着系统需求的扩大，以及需求变得越来越具体后，开发者需要用更有序的方式扩展和修改需求分析模型，以管理信息的复杂性。

典型的分析活动序列是，在开发初始用例模型时，用户、开发者和客户将参与进来，他们一起标识各个概念，并建立起参与对象的术语表，定义用例和定义参与对象的活动。开发者将参与对象分类成实体对象、边界对象和控制对象。这些活动持续循环进行，直到系统的绝大多数功能均标识成用例为止。随后开发者构造顺序图，以找出任何未标识的对象。当所有的实体对象均已命名并进行了主要描述后，分析模型在其求精之前进入了相对稳定的状态。

习题 9

9-1. 考虑一下带有图形用户界面的文件系统，如 Macintosh 的 Finder 、 Microsoft 的 Windows Explorer 和 Linux 的 KDE 。从描述怎样从一个软盘拷贝一个文件到硬盘的用例中标识出了如下对象： File 、 Icon 、 TrashCan 、 Folder 、 Disk 和 Pointer 。说明哪些对象是实体对象，哪些对象是边界对象，哪些对象是控制对象。

9-2. 假设如前所述的同一文件系统，考虑一个包含了从软盘上选择文件并拖动该文件到 Folder 再释放鼠标的场景。标识和定义至少一个关联到此场景的控制对象。

9-3. 在顺序图中水平地排列习题 9-1 和习题 9-2 中列出的对象，将边界对象放在左边，将你要标识的控制对象放在中间，将实体对象放在右边。画出将文件拖入文件夹的交互顺序。在本题中，忽略异常情况。

9-4. 检查你在练习 9-3 中画出的顺序图，标识出这些对象之间的关联。

9-5. 标识出与场景（将一个文件从一张软盘拷贝硬盘）相关的每一个对象的属性。考虑如下异常情况“在该文件夹中存在同一文件名”和“磁盘中没有足够的空间”。