特性、用例、需求-- Rational软件白皮书 - 第八基地

软件开发的家园,编程爱好者的天地.

现在是:北京时间 2016/4/14 上午11:50:51 星期四

设为首页  |  加入收藏  |  网站地图

特性、用例、需求-- Rational软件白皮书
发布于:第八基地 来源:互联网 作者:天堂路上 时间:2011-10-14 点击:214
引言作为BU(UML出现之前)时代面向对象技术的追随者和支持者,我必须承认当时的业内思想领袖所传播的各种方法和表示法对我具有某种魔力。在UML出现之前的两到四年中,您可以走进一个挤满OO鼓吹者的房间,并提问以下问题:我认为这种OO技术很有前途,但是告诉我,既然对象共享行为和数据,那么您如何称呼对象为实现它的行为义务而做的事情呢?

您可能得到如下答案:

"它是一个职责!"(Wirfs-Brock)"它是一项操作"(Booch)"它是一项服务"(Coad/Yourdon)"它是一个(虚)函数"(Stourstrup)"它是一个方法"(其他很多人)如果这还不足以让您混淆的话,那么就不要问您如何用图形表示我们称之为对象和类的东西了。(它是一个矩形、一片云,等等。)虽然这看上去很愚蠢,但是实际情况是,我们软件工程领袖的其中一些最显著的共识(继承、关系、封装),由于在术语和表示法上的微小区别而无法得到共享,或者至少变得混乱。换言之,不管是OO工程科学还是将要获得的利益都不能继续向前发展,因为还没有发明用来描述该科学的语言。当然,要在这些作者、方法学家和独立思想者中达成共识不是一件小事情,但是最终UML面世了,软件工程科学又向前迈进了一大步。

虽然需求管理方法学可能不像UML出现之前的OO方法学所形成的巴比塔那样糟,但是它却经历了同样的一些问题--尤其是对常见词汇的模糊、不一致和过度使用非常盛行。这些词汇(包括诸如"用例"、"特性"和"需求"这样的基本概念)是"每个人都理解"的日常词汇,但是在给定的上下文中每个人又赋予了它们自己的含义。结果就是沟通不畅。这种情况仅在将达成共识作为成功标准的领域中发生。Booch[Booch1994]引用了Stepp的说法:

科学中普遍存在的一个问题是为观察到的对象和情形构造有意义的分类。这样的分类能推动人们对观察以及后续的科学理论开发的理解。

为了推动需求的"科学理论",我们不得不面对术语的问题。

本文的目的在于,通过定义并描述用于说明系统软件需求的一些最常见术语和概念,来初步探讨一下软件工程的原理。为此,我们希望提供一个能让所有涉众(用户、经理、开发人员等)达成共识的基础。当然如果我们更有效地交流并因此获得一致看法,那么就可能更快地开发并交付更高质量的系统。

本文重点不在于需求管理的原理--关于这方面笔者在建议读物中推荐了很多参考书目。本文的目的仅是帮助该领域中的从业者提高他们对系统正确行为的基本认识。

问题域与解决方案域的对比在开始描述具体的术语之前,我们首先要意识到需要从两个完全不同的方面定义术语:问题方面和解决方案方面。我们分别称之为问题域和解决方案域。

问题域如果我们在问题域上做一次"低空滑翔",就会发现许多实际生活周围的事物。比如"滑翔"过人力资源部门时,会看到雇员、负责发工资的职员以及工资支票。"滑翔"过重型设备工厂时,我们会看到焊工、焊接控制器、焊接机器人和电极。"滑翔"过万维网时,我们会看到路由器和服务器群集,以及具有浏览器、电话机和调制解调器的用户。换句话说,在任何问题域中,我们可以轻易地识别出我们看到和接触到的事物(实体)。有时候,我们甚至可以看到这些事物之间的关系;比如,web用户和浏览器之间就是一对一的关系。我们可能还会看到从一个事物传递到另一个事物的消息:"焊接工似乎正在往焊接机器人的'大脑'中编制工作次序"。

对我有帮助
(0)
0%
对我没帮助
(0)
0%
返回顶部
在线反馈
在线反馈