原型法和面向对象的分析与设计方法（3）

9.1.2  原型法的基本思想

　　原型法是确定需求策略，是对用户需求进行抽取、描述和求精。它快速地、选代地建立最终系统工作模型，对问题定义采用启发的方式，由用户作出响应。实际上是一种动态定义技术。

　　原型法被认为，对于大多数企业的业务处理来说，需求定义几乎总能通过建立目标系统的工作模型来很好地完成，而且这种方法和严格定义方法比较起来，成功可能性更大。

1. 原型定义策略

　　原型法为预先定义技术提供了一种很好的选择和补充。人们对物理模型的理解要比对逻辑模型的理解来得准确。原型法就是在人们这种天性的基础上建立起来的，它考虑到用户有时也难免有判断错误，不可能在系统开发过程中，提出更多、更好的要求。原型法以一种与预先定义完全不同的观点来看待定义问题。

　　与预先定义技术完全不同，原型法开发策略的假设(hypothesis)是

　　1、并非所有的需求在系统开发以前都能准确地说明

　　人们发现，要想详细而精确地定义任何事情都是有困难的。实际上，用户很善于叙述其目标、对象以及他们想要前进的大致方面，但对于他们要如何实现那些事情的细节却不甚清楚和难以确定。对于所有参加者，建造一个系统都是一个持续不断地学习和实践的过程。当人们仅有局部经验的时候，怎么可能要求人们对全局需求进行叙述呢？

　　2、有快速的系统建造工具

　　原型的修正和完善需要有快速的系统建造工具支持，只有快速系统生成工具，才能使应用系统得以快速模型化，而且能快速地进行修改。没有快速系统建造工具，原型不能得到快速修改完善，原型法就失去存在的基础。

　　用于完成原型开发的工具一般有集成数据字典、高适应性的数据库管理系统(DBMS)、非过程的报告书写器、非过程查询语言、屏幕生成器、超高级语言、自动文档编排等部分组成。

　　原型技术今天存在于各种形式的开发活动中。如果“原型”可以快速地构造，那么就可以测试一个“好的设想”。如果设想有错，那么就把它丢掉，而不致造成大的损失；如果设想是对的，就可以进一步求精，而对于想法、概念、观点和要求的正确性，都可以在原型试验室中加以验证，而这一切都必须借助于快速生成工具的支持。目前所谓应用生产器（AG）和第四代生产语言（4GL），都是原型法的有力支持工具。

　　3、项目参加者之间通常都存在通信上的障碍

　　即使定义很完善的规格说明，不同的项目参加者也会存在或多或少的理论上的差异。何况文字性的描述，总是缺乏一般工程说明语言所具有的精确性。

　　而另一种形式是，用户和原型人员基于一组屏幕进行对话和讨论，其方式简单、明确。所有的项目参加人员也可以以一种简明的方式同原型进行通信，从他们自身的理解出发来测试原型。原型提供了一种沟通所有项目参加者的生动活泼的实际系统模型。

　　因此，对于开发人员通信上障碍的排除，不是试图将每一个项目参加者都培养成职业的系统定义人员，而是让每个人以一种易于接受的方式去理解规格说明。从常识上来理解，一个具体的工作原型，由于其直观性、动态性而能够担当和胜任这一任务。

　　4、需要实际的、可供用户参与的系统模型(system modal)

　　文字和静态图形是一种比较好的通信工具，然而其最大的缺点是缺乏直观的、感性的特征，因而往往不易理解对象的全部含义。交互式原型系统能够提供生动活泼的规格说明，用户见到的是一个“活”的、运行着的系统。理解纸面上的系统和操作运行在机器上的系统，其差别是十分显著的。因此，当能够提供一个生动的规格说明成为可能的话，人们就不会满足于一个静止的、被动的规格说明。

　　总之，当提供一个活生生的系统模型时，人们对它的了解将比说明性材料好得多。

　　5、需求一旦确定，就可以遵从严格的方法。

　　原型法的采纳，并不排除和放弃严格方法的运用，一旦通过建立原型并在演示中得到明确的需求定义后，即可运用行之有效的结构化方法来完成系统的开发。

　　6、大量的反复是不可避免的、必要的，应该加以鼓励

　　应该鼓励用户改进他们的系统，改进建议的产生是来自经验的发展。应该意识到，当把模型展示在面前，由你积极思考去改进一个现有的系统时，应该是一件令人兴奋、而不是让人厌恶的事情。应该提供友好的环境，最大限度地发挥他们的潜在能力去接受这种改变。从某种意义上讲，严格定义隐含着抑制定义阶段以后的再变化的要求，并认为变化意味着分析工作有缺陷，而把自己禁限在一个很小的活动范围以内。

　　因此，在开发最终的需求时，反复是完全需要和值得提倡的，只有做必要的改变后，才可能达到用户和系统间的良好匹配。