关键字：soa 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)的，后者在用户评价原型后获得较完整的需求说明将其抛弃，没有通常的生存周期；前者是把通过原形的不断增加与扩充，增量式的开发并实现系统全部需求，进而演化为最终产品的一部分或全部。
文章来源于领测软件测试网 https://www.ltesting.net/