【IT168 分析评论】
1、引言
需求是软件开发最困难的部分[1],以需求工程方法学为指导进行需求建模是实现软件需求的重要途径。现有需求工程方法大致分为五大类，即面向过程、面向数据、面向控制、面向目标及面向对象的分析方法[2, 3]。每一种方法都有自己的测重点和局限性，根据具体的软件项目及其环境，从这些方法学的各种软件工具包中提炼出针对性的关键技术，结合应用于不同的问题，用“非常好的方法”[4]建立需求模型，以提高开发效率和软件质量，是软件需求实施的最终目的。
用例技术是面向对象的需求工程方法学中的主要工具。原型法为需求建模提供了强有力的技术。本文在比较二者各自特点的基础上，将面向对象的抽象、封装与可继承、复用的思想[5]应用于原型法，并将用例技术与之相结合，建立一种新的需求模型。
2、用例与原型法比较分析
2.1、用例技术
Jacobson最先提出用例(use case)这一概念[6]，经过Rational公司规范后，被UML（Unified Modeling Language）中进一步的采用，目前该技术被广泛的应用于需求分析、系统设计和软件测试。
用例是系统执行一系列的动作，通过这些动作能获得主角 (Actor)有价值的结果[7]。Actor是外部行为者(可以是人或外部系统)与系统交互时可扮演的一组相关角色。用例模型描述的是外部行为者(Actor)所理解的结果即系统功能。以用例图可视化地表达系统的需求，具有直观、规范等优点[8]，克服了纯文字性说明的不足，是面向对象方法中需求表达的一种有效手段。
用例着重于对事件流的描述[9]，强调的是任务，一般不适用于用户界面设计。同时，用例技术要求开发人员有深入业务领域知识。否则，对于提取用例、精确用例之间的关系、用例的粒度如何确定、如何避免用例冗余等问题难以解决。这时，基于UML的用例图的需求驱动缺乏可操作性。
2.2、原型法
原型法(Prototyping)是在软件开发的早期就建立目标系统的实现化的原型。一个软件原型是所提出新项目的部分实现[4]， 建立原型主要原因是为了解决软件项目开发早期的不确定问题，通过用户对原型的评价，以最低的成本解决需求中的二义性和不完整性问题，使系统达到非常好的的可用性。
原型法解决了传统瀑布模型[10]难以胜任需求变化、二义性及不确定性问题，也在某种程度上避免了用例技术对业务领域知识的强依赖。但原型法同时也引入自身的风险，最大的风险在于：（1）、用户把一个正在运行原型视为产品[4]，勿视了原型难以实现的非功能性需求，这对用户来讲“不可视”[11]，如系统的可靠性与性能(实现中时间延迟与数据规模的扩充)等。（2）、用户不断用新的需求否定旧的需求，软件开发总停留一个重构新原型，造成开发过程的不确定性[12]，导致工作效率下降、软件结构变“坏”[11]。
2.3、面向对象的演化原型
演化型原型(Evolutionary Prototype)是相对抛弃型原型而言(Throwaway Prototype)的，后者在用户评价原型后获得较完整的需求说明将其抛弃，没有通常的生存周期；前者是把通过原形的不断增加与扩充，增量式的开发并实现系统全部需求，进而演化为最终产品的一部分或全部。
面向对象的方法把分析建立在系统对象以及对象间交互的基础上，通过对象的属性、分类结构和集合结构定义和描述需求，具有抽象性、封装性、继承性、易维护性的特性，对象之间的独立性好。用面向对象的方法产生的原型，为其在评价后的演化提供了极大的灵活性与自适应性，保证了软件结构的相对一致性，加快了开发周期。同时，演化原型从初始原型不断演化、发展（演进）直到最终产品，贯穿于软件开发的全过程。因此，演化原型是螺旋式软件开发生存周期模型的组成部分，也是面向对象软件开发过程的一部分[13]。目前，互联网的普遍应用和行业信息化的深入发展，使得基于B/S模式下的软件应用项目已成为主流，演化原型因其内在特性，很适用于Web开发项目[4]。
2.4、分析比较
通过上面的比较，得出如下结论：（1）、用例技术与原型法具有互补性：原型法适用于描述非确定的需求，而这类需求，很难直接通过用例图可视化表达，通过原型法可以将以用例为基础构建出来的用户界面机制在计算机上可视实现。原型法由于其快速和粗略的特点，往往达不到系统对健壮和产品质量级代码的需求，而基于UML面向对象的用例技术可进行增量与迭代开发，实现代码重用，同时用例还克服了原型对非功能性需求实现上困难。在原型演进的过程中，由于用例技术在系统测试中的良好表现[9]可以为演化原型提供高效的测试实例，从而加快开发速度。（2）、用例技术与原型法具有一致性：虽然用例注重系统任务的可视表示[4]，原型注重软件功能目标的真实实现，但两者都是以系统功能和用户为中心的。尤其是面向对象演化原型与用例技术都需要与用户交互，通过对象的不断的封装、继承、自适应的增量/迭代设计达到向产品模型的演化。
