原型法是在20世纪80年代中期为了快速开发系统而推出的一种开发模式，旨在改进传统的结构化生命周期法的不足，缩短开发周期，减少开发风险。原型法的理念是：在获取一组基本需求之后，快速地构造出一个能够反映用户需求的初始系统原型，让用户看到未来系统概貌，以便判断哪些功能是符合要求的，哪些方面还需要改进，不断地对这些需求进一步补充、细化和修改，依次类推，反复进行，直到用户满意为止并由此开发出完整的系统。
面向对象是近20年来国内外IT行业最为关注的技术之一，面向对象技术是一种按照人们对现实世界习惯的认识论和思维方式来研究和模拟客观世界的方法学。它将现实世界中的任何事物都视为“对象”，将客观世界看成是由许多不同种类的对象构成的，每一个对象都有自己的内部状态和运动规律，不同对象之间的相互联系和相互作用就构成了完整的客观世界。面向对象方法（Object
Oriented,简称OO方法）克服了传统的功能分解方法只能单纯反映管理功能的结构状态、数据流程模型只侧重反映事物的信息特征和流程、信息模拟只能被动地迎合实际问题需要等缺点，构成以系统对象为研究中心，为信息管理系统的分析与设计提供了一种全新的方法。
在本章中将详细介绍原型法的提出背景和缘由、基本思想、基本步骤、关键成功因素以及和生命周期法的比较；介绍面向对象的基本概念和原理，面向对象的信息系统分析、设计与实施方法。
一、原型法
1.1 原型法的提出
20世纪60年代末至70年代初，出现了“软件危机”，为了对软件开发项目进行有效管理，信息系统开发生命周期法诞生了。由于开发过程规范、层次清晰，系统开发生命周期法得到广泛应用。但这种方法的应用前提是需要在早期就确定用户的需求，而不允许修改，这对于很多应用系统（如商业信息系统）来说是不现实的。用户需求定义方面的错误是信息系统开发中出现的后果最严重的错误。在此背景下，提出了基于循环模型的快速原型法。
1．原型法的提出背景
“软件危机”出现于20世纪70年代初，“软件危机”的表现为：软件开发速度满足不了实际需求，软件成本在计算机系统总成本中所占比例逐年上升，软件产品的质量不可靠，软件难以维护，没有适当的文档资料，开发进度难以控制。
产生“软件危机”的原因在于：用户需求不明确，缺乏正确的理论指导，软件规模越来越大且复杂度也越来越高。那么如何解决“软件危机”呢？人们越来越重视软件开发方法的研究，通过多年的研究和努力，软件开发方法走向两个方面：一方面是着重研究与机器本身相关的软件开发工具，即高级语言及软件开发环境；另一方面，着重研究软件设计和规格说明等。这时系统开发生命周期（Systems
Development Life Cycle , SDLC）应运而生。它是一种用于规划、执行和控制信息系统开发项目的组织和管理方法，是工程学的原理在信息系统开发中的具体应用。
正如第三章介绍，生命周期法是一种结构化方法，把信息系统开发视为一个生命周期，把软件看作是人工制品，必然有其产生、成长、成熟、运作、消亡的生命过程。生命周期法把系统开发分为多个阶段，一般分为五个阶段：系统规划、系统分析、系统设计、系统实施。系统运行与维护。严格按阶段进行，每个阶段都有明确的目标和任务。每一阶段完成以后，要完成相应的文档资料，作为本阶段工作的总结，也作为下一阶段的依据。这种方法特别强调阶段完整性和开发的顺序性，它要求开发者首先确定系统的完整需求和全部功能。
生命周期法具有明显的优点。它采用系统观点和系统工程方法，自顶向下进行分析与设计并自下而上进行实施。开发过程阶段清楚，任务明确，并有标准的图、表、说明等组成各阶段的文档资料。生命周期法引入了用户观点，适用于大型信息系统的开发，将逻辑设计与物理设计分开。
但是，生命周期法的应用前提是严格的需求定义方法和策略。需求定义(the Definition of Requirement
)方法是一种严格的、预先定义的方法。从理论上讲，一个负责分析设计的项目小组应完全彻底地预先指出对应用来说是合理的业务需求，并期待用户进行审查、评价和认可，并在此基础上顺利开展工作。
这种严谨的需求定义方法是在一定假设的前提下形成的，它们是：
（1）所有的需求能被预先定义
这一假设的确切含义是，在没有系统实际工作经验的情况下，所有的系统需求在逻辑上是可以预先说明的。在某种情况下，虽然不能保证项目参加者个人都能确知系统需求和逻辑模型，但通过大多数人对系统的建议和合理判断，完全可以描述一个明确的系统需求，所有需求都能被准确预先定义。
但实际情况，需求定义方法假设的有效性是比较脆弱的。现实中，往往提供详细说明材料的人不是本领域的专业权威和职业分析人员；去定义复杂度甚高的事情又是十分困难的；大多数用户绝非面面俱到，只能是有选择性的说明。即使预先定义工作做得很好，往往系统仍旧需要进一步地修改和经过若干次反复，这是因为以下的事实是经常存在的。①个人对系统的认识往往与实际不完全吻合；②实地观察和使用系统会刺激用户对系统提出新的需求；③观看和经历会修改和取消对系统的事先需求。
（2）项目参加者之间能够清晰而准确地通信
严格需求定义方法的又一项重要假设是：在系统开发的进程中，项目组、项目经理、分析人员、用户开发人员、审计人员、保密分析员、数据管理员、人际关系专家等都能够清晰而有效地进行通信。虽然每个人都有自己的专业、观点和行动，但用图形／描述文档等工具，使得大家可能得到清晰、有效的沟通。
而实际情况往往是复杂的，对于共同的约定，每个人往往会有自己的解释和理解，对规格说明上应该有而尚未有的规定和说明，会有各种意见或加进个人看法。而文字叙述，如英语或汉语及其它文字描述，并非是一种准确的通信工具，即使提供了结构化的文字语言，如结构化英语以及判定表、树等较严格的通信的高级方式，当然这较叙述性的文字描述肯定是一种改进，减少了模糊性，但它仍然缺乏精确的技术上的通信语言的“严密性”、“专业性”和“行业性”。
因此，在多学科、多行业人员之间架起通信的桥梁是困难的。人们早就认识到，相互间通信的有效性的损失乃是开发过程中失败的主要原因之一。
（3）静态描述／图形模型对应用系统的反映是充分的
使用预先定义技术时，主要的通信工具是定义报告，包括工作报告和最终报告。采用叙述文字、图形模型、逻辑规则、数据字典等形式，这些具体形式因各自的技术有所不同，但其作用是相似的。
所有技术工具的共同特点是：它们都是被动的通信工具和静止的通信工具，不能表演，因而无法体现所建议的应用系统的动态特性，而要求用户根据一些静态的信息和静止的画面来认可系统则似乎近于苛求。
因此，严格定义技术本质上是一种静止、被动的技术，要它们来描述一个有“生命”的系统是困难的。理解和评价一个应用系统的最好方式，应该是去体验它，而不仅仅是去阅读和讨论它。
综合上述各点可见，严格需求定义的合理性在许多情况下并不满足，因此建立在脆弱基础上的开发策略在实施中一旦导致系统的失败就绝非意外之事。为了更好地处理由于缺乏支持严格方法的假设而给项目带来的风险，需要探求一种变通的方法。
解决需求定义不断变化问题一种思路是在获得一组基本的需求后，快速地加以“实现”。随着用户或开发人员对系统理解的加深而不断地对这些需求进行补充和细化。系统的定义是在逐步发展的过程中进行的，而不是一开始就预见一切，这就是原型法。
2．原型法（prototyping）
（1）原型法定义
原型法是指在获取一组基本的需求定义后，利用高级软件工具可视化的开发环境，快速地建立一个目标系统的最初版本，并把它交给用户试用、补充和修改，再进行新的版本开发。反复进行这个过程，直到得出系统的“精确解”，即用户满意为止。经过这样一个反复补充和修改过程，应用系统
“最初版本”就逐步演变为系统 “最终版本”。
原型法就是不断地运行系统“原型”来进行启发、揭示、判断、修改和完善的系统开发方法。
（2）原型(prototype)
原型(prototype)即样品、模型的意思。把系统主要功能和接口通过快速开发制作为“软件样机”，以可视化的形式展现给用户，及时征求用户意见，从而明确无误地确定用户需求。同时，原型也可用于征求内部意见，作为分析和设计的接口之一，可方便于沟通。
对原型的基本要求包括：体现主要的功能；提供基本的界面风格；展示比较模糊的部分以便于确认或进一步明确；原型最好是可运行的，至少在各主要功能模块之间能够建立相互连接。
原型可以分为三类：
① 淘汰(抛弃)式(disposable)：目的达到即被抛弃，原型不作为最终产品。
② 演化式(evolutionary)：系统的形成和发展是逐步完成的，它是高度动态迭代和高度动态的循环，每次迭代都要对系统重新进行规格说明、重新设计、重新实现和重新评价，所以是对付变化最为有效的方法。
③ 增量式(incremental)：系统是一次一段地增量构造，与演化式原型的最大区别在于增量式开发是在软件总体设计基础上进行的。很显然，其应付变化的能力比演化式差。
在信息系统设计的过程中，常用的各种不同形式的部分原型有：
① 对话原型
原型模拟预期的终端交互，使用户可以从屏幕上查看他们将接收什么、进行的操作，并提出遗漏之处，从而加深正确的理解。终端对话的设计效果直接影响着系统的可用性和用户对系统的接受程度。
② 数据输入原型
建立数据输入的原型，可以检查数据的输入速度和正确性，还能进行有效性和完整性的检查。
③ 报表系统原型
提供给用户的各种报告应在整个系统实现之前给用户看，报表子系统需要经常进行大量修改以满足系统的需要，因此，可以把报表生成器作为原型。
④ 数据系统原型
首先生成一个含有少量记录的原型数据库，这样用户和分析员与它可以进行交互，生成报表和显示有用信息。这种交互经常导致产生对不同的数据类型、新的数据域或不同的数据组织方式的需求，还可以在原型化工具的帮助下探索用户将如何使用信息以及数据库是什么样的。
⑤ 计算和逻辑原型
有时一个应用逻辑或计算是复杂的。审计员、工程师、投资分析员和其他用户可以使用高级程序设计语言建立他们所需的计算实例。这些实例可以组合在一起构成一个大的系统，与其它应用系统、数据库或终端相连接，用户可以使用这些计算原型检验他们所求结果的准确性。
⑥ 应用程序包原型
在一个应用程序包和其它应用系统相连或实际使用之前，可以通过一个小组用户来鉴定这个应用程序包是否令他们满意，若不满意可以进行大量的修改，直到令他们满意。
⑦ 概念原型
有时，一个应用概念不能被正确全面地理解，这是信息系统设计中存在的问题。在花费大额经费来建立这个系统之前，需要进行测试和细化。可以用一个快速实现的数据管理系统来测试，使用标准的数据输入屏幕和标准的报表格式，以减少测试和细化其概念的工作量。在测试和细化之后，对概念有了明确的理解，再进行建立该应用的特定报表和屏幕等细节工作。
（3）原型法意义
原型法意义是可视化，强化沟通，降低风险，节省后期变更成本，提高项目成功率。一般来说，采用原型法后可以改进需求质量；虽然投入了较多先期的时间，但可以显著减少后期变更的时间；原型法投入的人力成本代价并不大，但可以节省后期成本；对于较大型的软件来说，原型系统可以成为开发团队的蓝图；另外，原型通过充分和客户交流，还可以提高客户满意度。
原型法是在计算机技术发展到一定阶段，用户应用需求高涨的情况下发展的一种方法论，但它同时又是对开发人员有高要求的一种方法论。
9.1.2 原型法的基本思想
原型法是确定需求策略，是对用户需求进行抽取、描述和求精。它快速地、选代地建立最终系统工作模型，对问题定义采用启发的方式，由用户作出响应。实际上是一种动态定义技术。
原型法被认为，对于大多数企业的业务处理来说，需求定义几乎总能通过建立目标系统的工作模型来很好地完成，而且这种方法和严格定义方法比较起来，成功可能性更大。
1. 原型定义策略
原型法为预先定义技术提供了一种很好的选择和补充。人们对物理模型的理解要比对逻辑模型的理解来得准确。原型法就是在人们这种天性的基础上建立起来的，它考虑到用户有时也难免有判断错误，不可能在系统开发过程中，提出更多、更好的要求。原型法以一种与预先定义完全不同的观点来看待定义问题。
与预先定义技术完全不同，原型法开发策略的假设(hypothesis)是：
1、并非所有的需求在系统开发以前都能准确地说明
人们发现，要想详细而精确地定义任何事情都是有困难的。实际上，用户很善于叙述其目标、对象以及他们想要前进的大致方面，但对于他们要如何实现那些事情的细节却不甚清楚和难以确定。对于所有参加者，建造一个系统都是一个持续不断地学习和实践的过程。当人们仅有局部经验的时候，怎么可能要求人们对全局需求进行叙述呢？
2、有快速的系统建造工具
原型的修正和完善需要有快速的系统建造工具支持，只有快速系统生成工具，才能使应用系统得以快速模型化，而且能快速地进行修改。没有快速系统建造工具，原型不能得到快速修改完善，原型法就失去存在的基础。
用于完成原型开发的工具一般有集成数据字典、高适应性的数据库管理系统(DBMS)、非过程的报告书写器、非过程查询语言、屏幕生成器、超高级语言、自动文档编排等部分组成。
原型技术今天存在于各种形式的开发活动中。如果“原型”可以快速地构造，那么就可以测试一个“好的设想”。如果设想有错，那么就把它丢掉，而不致造成大的损失；如果设想是对的，就可以进一步求精，而对于想法、概念、观点和要求的正确性，都可以在原型试验室中加以验证，而这一切都必须借助于快速生成工具的支持。目前所谓应用生产器（AG）和第四代生产语言（4GL），都是原型法的有力支持工具。
3、项目参加者之间通常都存在通信上的障碍
即使定义很完善的规格说明，不同的项目参加者也会存在或多或少的理论上的差异。何况文字性的描述，总是缺乏一般工程说明语言所具有的精确性。
而另一种形式是，用户和原型人员基于一组屏幕进行对话和讨论，其方式简单、明确。所有的项目参加人员也可以以一种简明的方式同原型进行通信，从他们自身的理解出发来测试原型。原型提供了一种沟通所有项目参加者的生动活泼的实际系统模型。
因此，对于开发人员通信上障碍的排除，不是试图将每一个项目参加者都培养成职业的系统定义人员，而是让每个人以一种易于接受的方式去理解规格说明。从常识上来理解，一个具体的工作原型，由于其直观性、动态性而能够担当和胜任这一任务。
4、需要实际的、可供用户参与的系统模型(system modal)
文字和静态图形是一种比较好的通信工具，然而其最大的缺点是缺乏直观的、感性的特征，因而往往不易理解对象的全部含义。交互式原型系统能够提供生动活泼的规格说明，用户见到的是一个“活”的、运行着的系统。理解纸面上的系统和操作运行在机器上的系统，其差别是十分显著的。因此，当能够提供一个生动的规格说明成为可能的话，人们就不会满足于一个静止的、被动的规格说明。
总之，当提供一个活生生的系统模型时，人们对它的了解将比说明性材料好得多。
5、需求一旦确定，就可以遵从严格的方法。
原型法的采纳，并不排除和放弃严格方法的运用，一旦通过建立原型并在演示中得到明确的需求定义后，即可运用行之有效的结构化方法来完成系统的开发。
6、大量的反复是不可避免的、必要的，应该加以鼓励
应该鼓励用户改进他们的系统，改进建议的产生是来自经验的发展。应该意识到，当把模型展示在面前，由你积极思考去改进一个现有的系统时，应该是一件令人兴奋、而不是让人厌恶的事情。应该提供友好的环境，最大限度地发挥他们的潜在能力去接受这种改变。从某种意义上讲，严格定义隐含着抑制定义阶段以后的再变化的要求，并认为变化意味着分析工作有缺陷，而把自己禁限在一个很小的活动范围以内。
因此，在开发最终的需求时，反复是完全需要和值得提倡的，只有做必要的改变后，才可能达到用户和系统间的良好匹配。
在“需求分析”、“原型设计”两个阶段中，开发者和用户一起为想象中的系统的某些主要部分定义需求和规格说明，并由开发者在规格说明级用原型描述语言构造一个系统原型，它代表了部分系统，包括那些为满足用户需求的必要属性。该原型可用来帮助分析和设计工作，而不是一个软件产品。
在演示原型期间，用户可以根据他所期望的系统行为来评价原型的实际行为。如果原型不能满意地运行，用户能立刻找出问题和不可接受的地方，并与开发者重新定义需求。该过程一直持续到用户认为该原型能成功地体现想象中的系统的主要部分功能为止。在这期间，用户和开发者都不要为程序算法或设计技巧等枝节问题分心，而是要确定开发者是否理解了用户的意思，同时试验实现它们的若干方法。
有了满意的系统原型，同时也积累了使用原型的经验，用户常会提出新目标，从而进一步重新原型周期。新目标的范围要比修改或补充不满意的原型大。
软件原型(software prototype)是软件的最初版本，以最少的费用、最短的时间开发出的、以反映最后软件的主要特征的系统。它具有以下特征：
1.它是一个可实际运行的系统
2.它没有固定的生存期。一种极端是扔掉原型（以最简便方式大量借用已有软件，做出最后产品的模型，证实产品设想是成功的，但产品中并不使用）；另一种极端是最终产品的一部分即增量原型（先做出最终产品的核心部分，逐步增加补充模块），演进原型居于其中（每一版本扔掉一点，增加一点，逐步完善至最终产品）。
3.从需求分析到最终产品都可作原型，即可为不同目标作原型。
4.它必须快速、廉价。
5.它是迭代过程的集成部分，即每次经用户评价后修改、运行，不断重复双方认可。
9.1.3 原型法的工作步骤
利用原型法进行信息系统的设计过程中，分四步进行：首先快速分析，弄清用户/设计者的基本信息需求；然后构造原型，开发初始原型系统；之后，用户和系统开发人员使用并评价原型；最后系统开发人员修改和完善原型系统。
1. 原型法中的两个角色
在信息系统的设计过程中主要有两种角色：用户和系统设计者。
（1）用户(user)
用户是信息应用系统的使用者，能从管理信息系统中寻求帮助，能胜任他的职能领域工作。
（2）系统设计者(system designer)
系统专业人员是系统的设计者，他能够使用各种有效的开发工具、能知道系统的数据资源、在信息系统的设计中已建立第四代语言。
2. 原型法的工作步骤
(1) 快速分析，弄清用户的基本信息需求。（Plan）
在分析者和用户的紧密配合下，快速确定软件系统的基本要求。根据原型所要体现的特性（或界面形式、或处理功能、或总体结构、或模拟性能等），描述基本规格说明，以满足开发原型的需要。快速分析的关键是要注意选取分析和描述的内容，围绕使用原型的目标，集中力量，确定局部的需求说明，从而尽快开始构造原型。
如果是在需求分析阶段要使用原型法，必须从系统结构、逻辑结构、用户特性、应用约束、项目管理和项目环境等多方面来考虑，以决定是否采用原型法。
当系统规模很大、要求复杂、系统服务不清晰时，在需求分析阶段先开发一个系统原型是很值得的。特别当性能要求比较高时，在系统原型上先做一些试验也是很必要的。
这个步骤的目标是：讨论构造原型的过程；写出一简明的骨架式说明性报告，反映用户的信息需求方面的基本看法和要求；列出数据元素和它们之间的关系；确定所需数据的可用性；概括出业务原型的任务并估计其成本；考虑业务原型的可能使用。
用户的基本责任是根据系统的输出来清晰地描述自己的基本需要。设计者和用户共同负责来规定系统的范围，确定数据的可用性。设计者的基本责任是确定现实的用户期望，估价开发一原型的成本。
这个步骤的中心是用户和设计者定义基本的信息需求。讨论的焦点是数据的提取、过程模拟。
(2) 构造原型，开发初始原型系统。(Implement)
在快速分析的基础上，根据基本规格说明，尽快实现一个可运行的系统。为此需要强有力的软件工具的支持，例如采用非常高级的语言实现原型，引入以数据库为核心的开发工具等。并忽略最终系统在某些细节上的要求，例如安全性、健壮性、异常处理等。主要考虑原型系统应充分反映的待评价的特性，暂时忽略一切次要的内容。例如，如果构造原型的目的是确定系统输入界面的形式，可以利用输入界面自动生成工具，由界面形式的描述和数据域的定义立即生成简单的输入模块，而暂时不考虑参数检查、值域检查和后处理工作，从而尽快地把原型提供给用户使用。如果要利用原型确定系统的总体结构，而忽略转储、恢复等维护功能，使用户能够通过运行菜单来了解系统的总体结构。
初始原型的质量对于原型生存期的后续步骤的成败是至关重要的。如果它有明显的缺陷，会带给用户一种不好的思路；如果为追求完整而做得太大，就不容易修改。这时，会增加修改的工作量。因此，要有一个好的初始原型。
提交一个初始原型所需要的时间根据问题的规模、复杂性、完整程度的不同而不同。3——6周提交一个系统的初始原型应是可能的，最大限度不能超过两个月。两个月后提交的应是一个系统而不是一个原型。
综上所述，本步骤的目标是：建立一个能运行的交互式应用系统来满足用户的基本信息需求。
在这一步骤中用户没有责任，由设计者去负责建立一个初始原型，其中包括与设计者的需求及能力相适应的对话，还包括收集用户对初始原型的反映的设施。
设计者的主要工作有：编辑设计所需的数据库；构造数据变换或生成模块；开发和安装原型数据库；建立合适的菜单或语言对话来提高友好的用户输入/输出接口；装配或编写所需的应用程序模块；把初始原型交付给用户，并且演示如何工作、确定是否满足设计者的基本需求、解释接口和特点、确定用户是否能很舒适地使用系统。
本步骤的原则是：
① 建立模型的速度是关键因素，而不是运行的效率。
② 初始原型必须满足用户的基本需求。
③ 初始原型不求完善，它只响应用户的基本已知需求。
④ 用户使用原型必须要很舒适。
⑤ 用户－系统接口必须尽可能简单，使用户在用初始原型工作时不致于受到阻碍。
(3) 用户和开发人员使用并评价原型。(Measure)
这阶段是频繁通信，发现问题，消除误解的重要阶段。其目的是验证原型的正确程度，进而开发新的并修改原有的需求。它必须通过所有相关人员的检查、评价和测试。
由于原型忽略了许多内容，它集中反映了要评价的特性，外观看起来可能会有些残缺不全。用户要在开发者的指导下试用原型，在试用的过程中考核评价原型的特性，分析其运行结果是否满足规格说明的要求，以及规格说明的描述是否满足用户的愿望。纠正过去交互中的误解和分析中的错误，增补新的要求，并为满足环境变化或用户的新设想而引起系统需求的变动而提出全面的修改意见。
为了鼓励用户来评价原型，应当充分地解释原型的合理性，但不要为它辩护，以求能广泛征求用户的意见，在交互中达到完善。
在演示/评价/修改的迭代初期，主要达到的目的是：
① 原型通过用户验收，让用户能获得有关系统的亲身经验，必须使之更好地理解实际的信息需求和最能满足这些需要的系统种类。；
② 总体检查，找出隐含的错误；
③ 在操作原型时，使用户感到熟悉和舒适。
而在迭代的后期，要达到的主要目的是：
① 应发现丢失和不正确的功能；
② 测试思路和提出建议；
③ 改善/系统界面。
开发者不应认为提供了完整的模型就等于系统的成功。因为即使开发过程完全正确，用户还是可以提出一些有意义的修改意见，这不能看作是对开发者的批评，而是在开发过程中的一种自然的现象。原型化的目标是鼓励改进和创造，而不是仅仅保持某种设想。
在本步骤中的原则是：对实际系统的亲身经验能产生对系统的真实理解；用户总会找到系统第一个版本的问题；让用户确定什么时候更改是必需的，并控制总开发时间；如果用户在一定时间里（比如说一个月）没有和开发者联系，那么用户可能是对系统表示满意，也可能是遇到某些麻烦，设计者应该与用户联系。 |
|
|