|
|
|
结构化方法和面向对象方法有一个共同点：在系统开发初期必须明确系统的功能要求，确定系统边界。从工程学角度来看，这是十分自然的，解决问题之前必须明确要解决的问题是什么，然而对于信息系统建设而言，明确问题本身不是一件轻松的事情。
|
|
|
|
通常，原型是指模拟某种产品的原始模型。在软件开发中，原型是软件的一个早期可运行的版本，它反映最终系统的部分重要特性。如果在获得一组基本需求说明后，通过快速分析构造出一个小型的软件系统，满足用户的基本要求，使得用户可在试用原型系统的过程中得到亲身感受和受到启发，做出反应和评价，然后开发者根据用户的意见对原型加以改进。随着不断试验、纠错、使用、评价和修改，获得新的原型版本，如此周而复始，逐步减少分析和通信中的误解，弥补不足之处，进一步确定各种需求细节，适应需求的变更，从而提高了最终产品的质量。
|
|
|
|
|
|
软件原型是所提出的新产品的部分实现，建立原型的主要目的是为了解决在产品开发的早期阶段的需求不确定的问题，其目的是：明确并完善需求、探索设计选择方案、发展为最终的产品。
|
|
|
|
原型有很多种分类方法。从原型是否实现功能来分，软件原型可分为水平原型和垂直原型两种。水平原型也称为行为原型，用来探索预期系统的一些特定行为，并达到细化需求的目的。水平原型通常只是功能的导航，但并未真实实现功能。水平原型主要用在界面上。垂直原型也称为结构化原型，实现了一部分功能。垂直原型主要用在复杂的算法实现上。
|
|
|
|
从原型的最终结果来分，软件原型可分为抛弃型原型和演化型原型。抛弃型原型也称为探索型原型，是指达到预期目的后，原型本身被抛弃。抛弃型原型主要用在解决需求不确定性、二义性、不完整性、含糊性等。演化型原型为开发增量式产品提供基础，是螺旋模型的一部分，也是面向对象软件开发过程的一部分。演化型原型主要用在必须易于升级和优化的系统，以适用于Web的项目。
|
|
|
|
有些文献把原型分为实验型、探索型和演化型。探索型原型的目的是要弄清对目标系统的要求，确定所希望的特性，并探讨多种方案的可行性。实验型原型用于大规模开发和实现之前，考核方案是否合适，规格说明是否可靠。演化型原型的目的不在于改进规格说明，而是将系统建造得易于变化，在改进原型的过程中，逐步将原型演化成最终系统。
|
|
|
|
还有些文献也把原型分为抛弃式原型、演化式原型和递增式原型。
|
|
|
|
|
|
如果是在需求分析阶段要使用原型化方法，必须从系统结构、逻辑结构、用户特征、应用约束、项目管理和项目环境等多方面来考虑，以决定是否采用原型化方法。
|
|
|
|
（1）系统结构：联机事务处理系统，相互关联的应用系统适合于用原型化方法，而批处理、批修改等结构不适宜用原型化方法。
|
|
|
|
（2）逻辑结构：有结构的系统，如操作支持系统、管理信息系统、记录管理系统等适于用原型化方法，而基于大量算法的系统不适宜用原型化方法。
|
|
|
|
（3）用户特征：不满足于预先做系统定义说明，愿意为定义和修改原型投资，不易肯定详细需求，愿意承担决策的责任，准备积极参与的用户是适合使用原型的用户。
|
|
|
|
（4）应用约束：对已经运行系统的补充，不能用原型化方法。
|
|
|
|
（5）项目管理：只有项目负责人愿意使用原型化方法，才适于用原型化的方法。
|
|
|
|
（6）项目环境：需求说明技术应当根据每个项目的实际环境来选择。
|
|
|
|
当系统规模很大、要求复杂、系统服务不清晰时，在需求分析阶段先开发一个系统原型是很值得的。特别是当性能要求比较高时，在系统原型上先做一些试验也是很有必要的。
|
|
|
|
|
|
原型的开发和使用过程叫做原型生存期。下图（a）是原型生存期的模型，下图（b）是模型的细化。
|
|
|
|
|
|
|
|
（1）快速分析：在分析者和用户的紧密配合下，快速确定软件系统的基本要求。
|
|
|
|
（2）构造原型：在快速分析基础上，根据基本需求，尽快实现一个可运行的系统。构造原型时要注意2个基本原则，即集成原则（尽可能用现有软件和模型来构成，这需要相应的原型工具）和最小系统原则（耗资一般不超过总投资的10%）。
|
|
|
|
（3）运行和评价原型：用户在开发者指导下试用原型，在试用的过程中考核、评价原型的特性，分析其运行结果是否满足规格说明的要求，以及规格说明描述是否满足用户的愿望。
|
|
|
|
（4）修正和改进：根据修改意见进行修改。如果用修改原型的过程代替快速分析，就形成了原型开发的迭代过程。开发者和用户在一次次的迭代过程中不断将原型完善，以接近系统的最终要求。
|
|
|
|
（5）判定原型完成：如果经过修改或改进的原型，达到参与者一致认可，则原型开发的迭代过程可以结束。为此，应判断有关应用的实质是否已经掌握，迭代周期是否可以结束等。判定的结果有两个不同的转向，一是继续迭代验证，另外则是进行详细说明。
|
|
|
|
（6）判断原型细部是否说明：判断组成原型的细部是否需要严格地加以说明。原型化方法允许对系统必要成分或不能通过模型进行说明的成分进行严格的和详细的说明。
|
|
|
|
（7）原型细部的说明：对于那些不能通过原型说明的所有项目，仍需通过文件加以说明。严格说明的成分要作为原型化方法的模型编入词典。
|
|
|
|
（8）判定原型效果：考查用户新加入的需求信息和细部说明信息，看其对模型效果有什么影响？是否会影响模块的有效性？如果模型效果受到影响，甚至导致模型失效，则要进行修正和改进。
|
|
|
|
|
|
总之，利用原型化技术，可为软件的开发提供一种完整的、灵活的、近似动态的规格说明方法。
|
|
|
|
|
|
通常用于构造原型的一些技术包括可执行规格说明、基于场景的设计、自动程序设计、专用语言、可复用的软件构件、简化假设和面向对象技术等。其中前三种还适用于用户界面的设计。
|
|
|
|
（1）可执行规格说明：可执行规格说明是用于需求规格说明的一种自动化技术。可执行规格说明语言可描述系统要“做什么”，但它并不描述系统要“怎样做”。使用这种方法，人们可以直接观察他们用语言规定的任何系统性行为。可执行规格说明包括形式化规格说明、有限状态模型和可执行的数据流图。
|
|
|
|
（2）基于场景的设计：一个场景可模拟在系统运行期间用户经历的事件。由于它提供了输入—处理—输出的屏幕格式和有关对话的模型。因此，场景能够给用户显示系统的逼真的视图，使用户得以判断是否符合他的意图。
|
|
|
|
（3）自动程序设计：自动程序设计是可执行规格说明的替身，主要是指在程序自动生成环境的支持下，利用计算机实现软件的开发。它可以自动地或半自动地把用户的非过程性问题的规格说明转换为某种高级语言程序。
|
|
|
|
（4）专用语言：专用语言是应用领域的模型化语言。在原型开发中使用专用语言，可方便用户和软件开发者在计划中的系统特性方面的交流。
|
|
|
|
（5）软件复用技术：软件复用技术可分为两大类：合成技术和生成技术。
|
|
|
|
①合成技术：可复用的软件构件可以是对某一函数、过程、子程序、数据类型、算法等可复用软件成分的抽象，利用这些构件来构造软件系统。用构件合成较大的构件有三种方式：一是连接；二是消息传递和继承；三是管道机制。
|
|
|
|
②生成技术：利用可复用的模式，通过生成程序产生一个新的程序或程序段，产生的程序可以看做是模式的实例。可复用的模式有两种不同的形式：代码模式和规则模式。前者的例子是应用生成器，可复用的代码模式就存在于生成器自身。通过特定的参数替换，生成抽象软件模块的具体实体。后者的例子是变换系统，它通常采用超高级的规格说明语言，形式化地给出软件的需求规格说明，利用程序变换系统（有时要经过一系列的变换），把用超高级规格说明语言编写的程序转化成某种可执行语言的程序。
|
|
|
|
（6）简化假设：简化假设是在开发过程中使设计者迅速得到一个简化的系统所做的假设。尽管这些假设可能实际上并不能成立，但它们在原型开发过程中可以使开发者的注意力集中在一些主要的方面。
|
|
|
|
（7）面向对象技术：通常是指OO程序设计语言和面向对象的数据库等有关分析与设计技术的综合。使用OO技术，可以把现实世界中已存在的问题与实体，都采用对象去构成，能更好地体现出自然性、模块化、共享特性、并发特性、继承性、封装隐蔽性与可重用性等一系列功能化要求。如果能把OO数据库和OO程序设计语言等技术用于可重用的构件与原型语言，并且在其中体现出一致的“对象模型”本质，那么就有可能去统一“重用构件库”语言与原型化语言等。
|
|
|
|
原型法适合于用户需求不明确的场合。它是先根据已知的和分析的需求，建立一个原始模型，这是一个可以修改的模型。在软件开发的各个阶段都把有关信息相互反馈，直至模型的修改，使模型渐趋完善。在这个过程中，用户的参与和决策加强了，缩短了开发周期，降低了开发风险，最终的结果是更适合用户的要求。原型法成败的关键及效率的高低，在于模型的建立及建模的速度。
|
|
|
