关键字: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)的,后者在用户评价原型后获得较完整的需求说明将其抛弃,没有通常的生存周期;前者是把通过原形的不断增加与扩充,增量式的开发并实现系统全部需求,进而演化为最终产品的一部分或全部。