關鍵字：soa 1、引言
需求是軟件開發最困難的部分[1],以需求工程方法學為指導進行需求建模是實現軟件需求的重要途徑�，F有需求工程方法大致分為五大類，即面向過程、面向數據、面向控制、面向目標及面向對象的分析方法[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)的，后者在用戶評價原型后獲得較完整的需求說明將其拋棄，沒有通常的生存周期；前者是把通過原形的不斷增加與擴充，增量式的開發并實現系統全部需求，進而演化為最終產品的一部分或全部。
文章來源于領測軟件測試網 http://www.kjueaiud.com/