iweroulsdjf

由于這周六IBM DB2認證考試，并且今天晚上公司項目組還要集體出去Happy一下，聚餐一頓，就當(dāng)休息了。所以計劃有些打亂，不過還好，前幾天也弄出些文檔來。那么今天下午大家就抓緊看DB2吧，晚上痛痛快快的玩一把。周六考完DB2就再全身心投入文檔的編寫討論和下一步的計劃制定中來。

今天看了一些ESB方面的資料，對其又有一些理解，下面說說：

ESB是一個總線，是SOA的核心，IBM對ESB的支持有２種產(chǎn)品可用。一個是WESB，它是基于WAS構(gòu)建的一個平臺，他支持的是將所有服務(wù)都"插"到ESB上，對其中的服務(wù)進行消息路由，消息格式轉(zhuǎn)換等。其中一個關(guān)鍵的地方就是里面的Mediation Flow Components,它是Service 提供方和Service請求方的中間件。它所做的就是在兩者之間建立一個Flow，對其中的消息做處理，有效地通過一定的邏輯連接兩者。
第二個產(chǎn)品是WMB,或者叫AdvanceEBS,它是基于WMQ構(gòu)建的。它除了能夠?qū)崿F(xiàn)WESB的功能外，還能夠支持除了服務(wù)之外的東西，支持的協(xié)議也多。比如"插"在ESB上的可以是一個Application，甚至是word,和excel文檔也能”插“。

其實選擇哪種產(chǎn)品要根據(jù)實現(xiàn)系統(tǒng)的需求而定，現(xiàn)在依據(jù)我們的需求用到了ERP和CRM，就應(yīng)該用WMB。

IBM WebSphere的企業(yè)集成構(gòu)架分六類:
1 業(yè)務(wù)邏輯服務(wù)
?1.1 整合已有應(yīng)用 - 應(yīng)用和信息訪問服務(wù)
??1.1.1 可接入服務(wù)(On-Ramp Service)
??1.1.2 事件發(fā)現(xiàn)服務(wù)(Event Detect Service)
?1.2 整合新開發(fā)的應(yīng)用 - 業(yè)務(wù)應(yīng)用服務(wù)
??1.2.1 組件服務(wù)(Component Service)
??1.2.2 核心服務(wù)(Core Service)
??1.2.3 接口服務(wù)(Interface Service)
?1.3 整合客戶和業(yè)務(wù)伙伴（B2C/B2B）－伙伴服務(wù)
??1.3.1 社區(qū)服務(wù)(Community Service)
??1.3.2 文檔服務(wù)(Document Service)
??1.3.3 協(xié)議服務(wù)(Protocol Service)
2 控制服務(wù)
?2.1 數(shù)據(jù)整合－信息服務(wù)
??2.1.1 聯(lián)邦服務(wù)(Federation Service)
??2.1.2 復(fù)制服務(wù)(Replication Service)
??2.1.3 轉(zhuǎn)換服務(wù)(Transformation Service)
??2.1.4 搜索服務(wù)(Search Service)
?2.2 流程整合- 流程服務(wù)
??2.2.1 編排服務(wù)(Choreography Service)
??2.2.2 事務(wù)服務(wù)(Transaction Service)
??2.2.3 人工服務(wù)(Staff Service)
?2.3 用戶訪問整合 - 交互服務(wù)
??2.3.1 交付服務(wù)(Delivery Service)
??2.3.2 體驗服務(wù)(Experience Service)
??2.3.3 資源服務(wù)(Resource Service)
3 連接服務(wù)
?企業(yè)服務(wù)總線ESB
4 業(yè)務(wù)創(chuàng)新和優(yōu)化服務(wù)
?4.1 公共事件框架服務(wù)(Common Event Infrastructure Service)
?4.2 采集服務(wù)(Collection Service)
?4.3 監(jiān)控服務(wù)(Monitoring Service)：
5 開發(fā)服務(wù)
?5.1 建模服務(wù)(Model Service)
?5.2 設(shè)計服務(wù)(Design Service)
?5.3 實現(xiàn)服務(wù)(Implementation Serivice)
?5.4 測試服務(wù)
6 IT服務(wù)管理
?6.1 安全和目錄服務(wù)(Security and Directory Service)
?6.2 系統(tǒng)管理和虛擬化服務(wù)(System Management and Virtualization Service)

用例(Use Case)是一種描述系統(tǒng)需求的方法，使用用例的方法來描述系統(tǒng)需求的過程就是用例建模。用例方法最早是由Iva Jackboson博士提出的，后來被綜合到UML規(guī)范之中，成為一種標準化的需求表述體系。用例的使用在RUP中被推崇備至，整個RUP流程都被稱作是"用例驅(qū)動"(Use-Case Driven)的，各種類型的開發(fā)活動包括項目管理、分析設(shè)計、測試、實現(xiàn)等都是以系統(tǒng)用例為主要輸入工件，用例模型奠定了整個系統(tǒng)軟件開發(fā)的基礎(chǔ)。

1. 什么是用例？

在介始用例方法之前，我們首先來看一下傳統(tǒng)的需求表述方式-"軟件需求規(guī)約"(Software Requirement Specification)。傳統(tǒng)的軟件需求規(guī)約基本上采用的是功能分解的方式來描述系統(tǒng)功能，在這種表述方式中，系統(tǒng)功能被分解到各個系統(tǒng)功能模塊中，我們通過描述細分的系統(tǒng)模塊的功能來達到描述整個系統(tǒng)功能的目的。一個典型的軟件需求規(guī)約可能具有以下形式：

采用這種方法來描述系統(tǒng)需求，非常容易混淆需求和設(shè)計的界限，這樣的表述實際上已經(jīng)包含了部分的設(shè)計在內(nèi)。由此常常導(dǎo)致這樣的迷惑：系統(tǒng)需求應(yīng)該詳細到何種程度？一個極端就是需求可以詳細到概要設(shè)計，因為這樣的需求表述既包含了外部需求也包含了內(nèi)部設(shè)計。在有些公司的開發(fā)流程中，這種需求被稱為"內(nèi)部需求"，而對應(yīng)于用戶的原始要求則被稱之為"外部需求"。

功能分解方法的另一個缺點是這種方法分割了各項系統(tǒng)功能的應(yīng)用環(huán)境，從各項功能項入手，你很難了解到這些功能項是如何相互關(guān)聯(lián)來實現(xiàn)一個完成的系統(tǒng)服務(wù)的。所以在傳統(tǒng)的SRS文檔中，我們往往需要另外一些章節(jié)來描述系統(tǒng)的整體結(jié)構(gòu)及各部分之間的相互關(guān)聯(lián)，這些內(nèi)容使得SRS需求更象是一個設(shè)計文檔。

1.1 參與者和用例

從用戶的角度來看，他們并不想了解系統(tǒng)的內(nèi)部結(jié)構(gòu)和設(shè)計，他們所關(guān)心的是系統(tǒng)所能提供的服務(wù)，也就是被開發(fā)出來的系統(tǒng)將是如何被使用的，這就用例方法的基本思想。用例模型主要由以下模型元素構(gòu)成：

• 參與者(Actor)
  參與者是指存在于被定義系統(tǒng)外部并與該系統(tǒng)發(fā)生交互的人或其他系統(tǒng)，他們代表的是系統(tǒng)的使用者或使用環(huán)境。
• 用例(Use Case)
  用例用于表示系統(tǒng)所提供的服務(wù)，它定義了系統(tǒng)是如何被參與者所使用的，它描述的是參與者為了使用系統(tǒng)所提供的某一完整功能而與系統(tǒng)之間發(fā)生的一段對話。
• 通訊關(guān)聯(lián)(Communication Association)
  通訊關(guān)聯(lián)用于表示參與者和用例之間的對應(yīng)關(guān)系，它表示參與者使用了系統(tǒng)中的哪些服務(wù)（用例），或者說系統(tǒng)所提供的服務(wù)（用例）是被哪些參與者所使用的。

這大三種模型元素在UML中的表述如下圖所示。

以銀行自動提款機(ATM)為例，它的主要功能可以由下面的用例圖來表示。ATM的主要使用者是銀行客戶，客戶主要使用自動提款機來進行銀行帳戶的查詢、提款和轉(zhuǎn)帳交易。

通訊關(guān)聯(lián)表示的是參與者和用例之間的關(guān)系，箭頭表示在這一關(guān)系中哪一方是對話的主動發(fā)起者，箭頭所指方是對話的被動接受者；如果你不想強調(diào)對話中的主動與被動關(guān)系，可以使用不帶箭頭的關(guān)聯(lián)實線。在參與者和用例之間的信息流不是由通訊關(guān)聯(lián)來表示的，該信息流是缺省存在的（用例本身描述的就是參與者和系統(tǒng)之間的對話），并且信息流向是雙向的，它與通訊關(guān)聯(lián)箭頭所指的方向亳無關(guān)系。

1.2 用例的內(nèi)容

用例圖使我們對系統(tǒng)的功能有了一個整體的認知，我們可以知道有哪些參與者會與系統(tǒng)發(fā)生交互，每一個參與者需要系統(tǒng)為它提供什么樣的服務(wù)。用例描述的是參與者與系統(tǒng)之間的對話，但是這個對話的細節(jié)并沒有在用例圖中表述出來，針對每一個用例我們可以用事件流來描述這一對話的細節(jié)內(nèi)容。如在ATM系統(tǒng)中的"提款"用例可以用事件流表述如下：

提款-基本事件流

1. 用戶插入信用卡

2. 輸入密碼

3. 輸入提款金額

4. 提取現(xiàn)金

5. 退出系統(tǒng)，取回信用卡

但是這只描述了提款用例中最順利的一種情況，作為一個實用的系統(tǒng)，我們還必須考慮可能發(fā)生的各種其他情況，如信用卡無效、輸入密碼錯、用戶帳號中的現(xiàn)金余額不夠等，所有這些可能發(fā)生的各種情況（包括正常的和異常的）被稱之為用例的場景(Scenario)，場景也被稱作是用例的實例(Instance)。在用例的各種場景中，最常見的場景是用基本流(Basic Flow)來描述的，其他的場景則是用備選流(Alternative Flow)來描述。對于ATM系統(tǒng)中的"提款"用例，我們可以得到如下一些備選流：

提款-備選事件流

備選流一：用戶可以在基本流中的任何一步選擇退出，轉(zhuǎn)至基本流步驟5。

備選流二：在基本流步驟1中，用戶插入無效信用卡，系統(tǒng)顯示錯誤并退出信用卡，用例結(jié)束。

備選流三：在基本流步驟２中，用戶輸入錯誤密碼，系統(tǒng)顯示錯誤并提示用戶重新輸入密碼，重新回到基本流步驟2；三次輸入密碼錯誤后，信用卡被系統(tǒng)沒收，用例結(jié)束。

…

通過基本流與備選流的組合，就可以將用例所有可能發(fā)生的各種場景全部描述清楚。我們在描述用例的事件流的時候，就是要盡可能地將所有可能的場景都描述出來，以保證需求的完備性。

1.3 用例方法的優(yōu)點

用例方法完全是站在用戶的角度上（從系統(tǒng)的外部）來描述系統(tǒng)的功能的。在用例方法中，我們把被定義系統(tǒng)看作是一個黑箱，我們并不關(guān)心系統(tǒng)內(nèi)部是如何完成它所提供的功能的。用例方法首先描述了被定義系統(tǒng)有哪些外部使用者（抽象成為Actor），這些使用者與被定義系統(tǒng)發(fā)生交互；針對每一參與者，用例方法又描述了系統(tǒng)為這些參與者提供了什么樣的服務(wù)（抽象成為Use Case），或者說系統(tǒng)是如何被這些參與者使用的。所以從用例圖中，我們可以得到對于被定義系統(tǒng)的一個總體印象。

與傳統(tǒng)的功能分解方式相比，用例方法完全是從外部來定義系統(tǒng)的功能，它把需求與設(shè)計完全分離開來。在面向?qū)ο蟮姆治鲈O(shè)計方法中，用例模型主要用于表述系統(tǒng)的功能性需求，系統(tǒng)的設(shè)計主要由對象模型來記錄表述。另外，用例定義了系統(tǒng)功能的使用環(huán)境與上下文，每一個用例描述的是一個完整的系統(tǒng)服務(wù)。用例方法比傳統(tǒng)的SRS更易于被用戶所理解，它可以作為開發(fā)人員和用戶之間針對系統(tǒng)需求進行溝通的一個有效手段。

在RUP中，用例被作為整個軟件開發(fā)流程的基礎(chǔ)，很多類型的開發(fā)活動都把用例作為一個主要的輸入工件(Artifact)，如項目管理、分析設(shè)計、測試等。根據(jù)用例來對目標系統(tǒng)進行測試，可以根據(jù)用例中所描述的環(huán)境和上下文來完整地測試一個系統(tǒng)服務(wù)，可以根據(jù)用例的各個場景(Scenario)來設(shè)計測試用例，完全地測試用例的各種場景可以保證測試的完備性。

回頁首

2. 建立用例模型

使用用例的方法來描述系統(tǒng)的功能需求的過程就是用例建模，用例模型主要包括以下兩部分內(nèi)容：

• 用例圖(Use Case Diagram)
  確定系統(tǒng)中所包含的參與者、用例和兩者之間的對應(yīng)關(guān)系，用例圖描述的是關(guān)于系統(tǒng)功能的一個概述。
• 用例規(guī)約(Use Case Specification)
  針對每一個用例都應(yīng)該有一個用例規(guī)約文檔與之相對應(yīng)，該文檔描述用例的細節(jié)內(nèi)容。

在用例建模的過程中，我們建議的步聚是先找出參與者，再根據(jù)參與者確定每個參與者相關(guān)的用例，最后再細化每一個用例的用例規(guī)約。

2.1 尋找參與者

所謂的參與者是指所有存在于系統(tǒng)外部并與系統(tǒng)進行交互的人或其他系統(tǒng)。通俗地講，參與者就是我們所要定義系統(tǒng)的使用者。尋找參與者可以從以下問題入手：

• 系統(tǒng)開發(fā)完成之后，有哪些人會使用這個系統(tǒng)？
• 系統(tǒng)需要從哪些人或其他系統(tǒng)中獲得數(shù)據(jù)？
• 系統(tǒng)會為哪些人或其他系統(tǒng)提供數(shù)據(jù)？
• 系統(tǒng)會與哪些其他系統(tǒng)相關(guān)聯(lián)？
• 系統(tǒng)是由誰來維護和管理的？

這些問題有助于我們抽象出系統(tǒng)的參與者。對于ATM機的例子，回答這些問題可以使我們找到更多的參與者：操作員負責(zé)維護和管理ATM機系統(tǒng)、ATM機也需要與后臺服務(wù)器進行通訊以獲得有關(guān)用戶帳號的相關(guān)信息。

2.1.1 系統(tǒng)邊界決定了參與者

參與者是由系統(tǒng)的邊界所決定的，如果我們所要定義的系統(tǒng)邊界僅限于ATM機本身，那么后臺服務(wù)器就是一個外部的系統(tǒng)，可以抽象為一個參與者。

如果我們所要定義的系統(tǒng)邊界擴大至整個銀行系統(tǒng)，ATM機和后臺服務(wù)器都是整個銀行系統(tǒng)的一部分，這時候后臺服務(wù)器就不再被抽象成為一個參與者。

值得注意的是，用例建模時不要將一些系統(tǒng)的組成結(jié)構(gòu)作為參與者來進行抽象，如在ATM機系統(tǒng)中，打印機只是系統(tǒng)的一個組成部分，不應(yīng)將它抽象成一個獨立的參與者；在一個MIS管理系統(tǒng)中，數(shù)據(jù)庫系統(tǒng)往往只作為系統(tǒng)的一個組成部分，一般不將其單獨抽象成一個參與者。

2.1.2 特殊的參與者――系統(tǒng)時鐘

有時候我們需要在系統(tǒng)內(nèi)部定時地執(zhí)行一些操作，如檢測系統(tǒng)資源使用情況、定期地生成統(tǒng)計報表等等。從表面上看，這些操作并不是由外部的人或系統(tǒng)觸發(fā)的，應(yīng)該怎樣用用例方法來表述這一類功能需求呢？對于這種情況，我們可以抽象出一個系統(tǒng)時鐘或定時器參與者，利用該參與者來觸發(fā)這一類定時操作。從邏輯上，這一參與者應(yīng)該被理解成是系統(tǒng)外部的，由它來觸發(fā)系統(tǒng)所提供的用例對話。

2.2 確定用例

找到參與者之后，我們就可以根據(jù)參與者來確定系統(tǒng)的用例，主要是看各參與者需要系統(tǒng)提供什么樣的服務(wù)，或者說參與者是如何使用系統(tǒng)的。尋找用例可以從以下問題入手（針對每一個參與者）：

• 參與者為什么要使用該系統(tǒng)？
• 參與者是否會在系統(tǒng)中創(chuàng)建、修改、刪除、訪問、存儲數(shù)據(jù)？如果是的話，參與者又是如何來完成這些操作的？
• 參與者是否會將外部的某些事件通知給該系統(tǒng)？
• 系統(tǒng)是否會將內(nèi)部的某些事件通知該參與者？

綜合以上所述，ATM系統(tǒng)的用例圖可表示如下，

在用例的抽取過程中，必須注意：用例必須是由某一個主角觸發(fā)而產(chǎn)生的活動，即每個用例至少應(yīng)該涉及一個主角。如果存在與主角不進行交互的用例，就可以考慮將其并入其他用例；或者是檢查該用例相對應(yīng)的參與者是否被遺漏，如果是，則補上該參與者。反之，每個參與者也必須至少涉及到一個用例，如果發(fā)現(xiàn)有不與任何用例相關(guān)聯(lián)的參與者存在，就應(yīng)該考慮該參與者是如何與系統(tǒng)發(fā)生對話的，或者由參與者確定一個新的用例，或者該參與者是一個多余的模型元素，應(yīng)該將其刪除。

可視化建模的主要目的之一就是要增強團隊的溝通，用例模型必須是易于理解的。用例建模往往是一個團隊開發(fā)的過程，系統(tǒng)分析員在建模過程中必須注意參與者和用例的名稱應(yīng)該符合一定的命名約定，這樣整個用例模型才能夠符合一定的風(fēng)格。如參與者的名稱一般都是名詞，用例名稱一般都是動賓詞組等。

對于同一個系統(tǒng)，不同的人對于參與者和用例都可能有不同的抽象結(jié)果，因而得到不同的用例模型。我們需要在多個用例模型方案中選擇一種"最佳"（或"較佳"）的結(jié)果，一個好的用例模型應(yīng)該能夠容易被不同的涉眾所理解，并且不同的涉眾對于同一用例模型的理解應(yīng)該是一致的。

2.3 描述用例規(guī)約

應(yīng)該避免這樣一種誤解――認為由參與者和用例構(gòu)成的用例圖就是用例模型，用例圖只是在總體上大致描述了系統(tǒng)所能提供的各種服務(wù)，讓我們對于系統(tǒng)的功能有一個總體的認識。除此之外，我們還需要描述每一個有例的詳細信息，這些信息包含在用例規(guī)約中，用例模型是由用例圖和每一個用例的詳細描述――用例規(guī)約所組成的。RUP中提供了用例規(guī)約的模板，每一個用例的用例規(guī)約都應(yīng)該包含以下內(nèi)容：

• 簡要說明 (Brief Description)
  簡要介紹該用例的作用和目的。
• 事件流 (Flow of Event)
  包括基本流和備選流，事件流應(yīng)該表示出所有的場景。
• 用例場景 (Use-Case Scenario)
  包括成功場景和失敗場景，場景主要是由基本流和備選流組合而成的。
• 特殊需求 (Special Requirement)
  描述與該用例相關(guān)的非功能性需求（包括性能、可靠性、可用性和可擴展性等）和設(shè)計約束（所使用的操作系統(tǒng)、開發(fā)工具等）。
• 前置條件 (Pre-Condition)
  執(zhí)行用例之前系統(tǒng)必須所處的狀態(tài)。
• 后置條件 (Post-Condition)
  用例執(zhí)行完畢后系統(tǒng)可能處于的一組狀態(tài)。

用例規(guī)約基本上是用文本方式來表述的，為了更加清晰地描述事件流，也可以選擇使用狀態(tài)圖、活動圖或序列圖來輔助說明。只要有助于表達的簡潔明了，就可以在用例中任意粘貼用戶界面和流程的圖形化顯示方式，或是其他圖形。如活動圖有助于描述復(fù)雜的決策流程，狀態(tài)轉(zhuǎn)移圖有助于描述與狀態(tài)相關(guān)的系統(tǒng)行為，序列圖適合于描述基于時間順序的消息傳遞。

2.3.1 基本流

基本流描述的是該用例最正常的一種場景，在基本流中系統(tǒng)執(zhí)行一系列活動步驟來響應(yīng)參與者提出的服務(wù)請求。我們建議用以下格式來描述基本流：

1) 每一個步驟都需要用數(shù)字編號以清楚地標明步驟的先后順序。

2) 用一句簡短的標題來概括每一步驟的主要內(nèi)容，這樣閱讀者可以通過瀏覽標題來快速地了解用例的主要步驟。在用例建模的早期，我們也只需要描述到事件流步驟標題這一層，以免過早地陷入到用例描述的細節(jié)中去。

3) 當(dāng)整個用例模型基本穩(wěn)定之后，我們再針對每一步驟詳細描述參與者和系統(tǒng)之間所發(fā)生的交互。建議采用雙向(roundtrip)描述法來保證描述的完整性，即每一步驟都需要從正反兩個方面來描述:(1)參與者向系統(tǒng)提交了什么信息；(2)對此系統(tǒng)有什么樣的響應(yīng)。具體例子請參見附錄。

在描述參與者和系統(tǒng)之間的信息交換時，需指出來回傳遞的具體信息。例如，只表述參與者輸入了客戶信息就不夠明確，最好明確地說參與者輸入了客戶姓名和地址。通常可以利用詞匯表讓用例的復(fù)雜性保持在可控范圍內(nèi)，可以在詞匯表中定義客戶信息等內(nèi)容，使用例不至于陷入過多的細節(jié)。

2.3.2 備選流

備選流負責(zé)描述用例執(zhí)行過程中異常的或偶爾發(fā)生的一些情況，備選流和基本流的組合應(yīng)該能夠覆蓋該用例所有可能發(fā)生的場景。在描述備選流時，應(yīng)該包括以下幾個要素：

1) 起點：該備選流從事件流的哪一步開始；

2) 條件：在什么條件下會觸發(fā)該備選流；

3) 動作：系統(tǒng)在該備選流下會采取哪些動作；

4) 恢復(fù)：該備選流結(jié)束之后，該用例應(yīng)如何繼續(xù)執(zhí)行。

備選流的描述格式可以與基本流的格式一致，也需要編號并以標題概述其內(nèi)容，編號前可以加以字母前綴A(Alternative)以示與基本流步驟相區(qū)別。

2.3.3 用例場景

用例在實際執(zhí)行的時候會有很多的不同情況發(fā)生，稱之為用例場景；也可以說場景是用例的實例，我們在描述用例的時候要覆蓋所有的用例場景，否則就有可能導(dǎo)致需求的遺漏。在用例規(guī)約中，場景的描述可以由基本流和備選流的組合來表示。場景既可以幫助我們防止需求的遺漏，同時也可以對后續(xù)的開發(fā)工作起到很大的幫助：開發(fā)人員必須實現(xiàn)所有的場景、測試人員可以根據(jù)用例場景來設(shè)計測試用例。

2.3.4 特殊需求

特殊需求通常是非功能性需求，它為一個用例所專有，但不適合在用例的事件流文本中進行說明。特殊需求的例子包括法律或法規(guī)方面的需求、應(yīng)用程序標準和所構(gòu)建系統(tǒng)的質(zhì)量屬性（包括可用性、可靠性、性能或支持性需求等）。此外，其他一些設(shè)計約束，如操作系統(tǒng)及環(huán)境、兼容性需求等，也可以在此節(jié)中記錄。

需要注意的是，這里記錄的是專屬于該用例的特殊需求；對于一些全局的非功能性需求和設(shè)計約束，它們并不是該用例所專有的，應(yīng)把它們記錄在《補充規(guī)約》中。

2.3.5 前置和后置條件

前置條件是執(zhí)行用例之前必須存在的系統(tǒng)狀態(tài)，后置條件是用例一執(zhí)行完畢后系統(tǒng)可能處于的一組狀態(tài)。

2.4 檢查用例模型

用例模型完成之后，可以對用例模型進行檢查，看看是否有遺漏或錯誤之處。主要可以從以下幾個方面來進行檢查：

• 功能需求的完備性
  現(xiàn)有的用例模型是否完整地描述了系統(tǒng)功能，這也是我們判斷用例建模工作是否結(jié)束的標志。如果發(fā)現(xiàn)還有系統(tǒng)功能沒有被記錄在現(xiàn)有的用例模型中，那么我們就需要抽象一些新的用例來記錄這些需求，或是將他們歸納在一些現(xiàn)有的用例之中。
• 模型是否易于理解
  用例模型最大的優(yōu)點就在于它應(yīng)該易于被不同的涉眾所理解，因而用例建模最主要的指導(dǎo)原則就是它的可理解性。用例的粒度、個數(shù)以及模型元素之間的關(guān)系復(fù)雜程度都應(yīng)該由該指導(dǎo)原則決定。
• 是否存在不一致性
  系統(tǒng)的用例模型是由多個系統(tǒng)分析員協(xié)同完成的，模型本身也是由多個工件所組成的，所以我們要特別注意不同工件之前是否存在前后矛盾或沖突的地方，避免在模型內(nèi)部產(chǎn)生不一致性。不一致性會直接影響到需求定義的準確性。
• 避免二義性語義
  好的需求定義應(yīng)該是無二義性的，即不同的人對于同一需求的理解應(yīng)該是一致的。在用例規(guī)約的描述中，應(yīng)該避免定義含義模糊的需求，即無二義性。

回頁首

3. 系統(tǒng)需求

RUP中根據(jù)FURPS+模型將系統(tǒng)需求分為以下幾類：

• 功能(Functionality)
• 可用性(Usability)
• 可靠性(Reliability)
• 性能(Performance)
• 可支持性(Supportability)
• 設(shè)計約束等

除了第一項功能性需求之外的其他需求都歸之為非功能性需求。

3.1 需求工件集

用例模型主要用于描述系統(tǒng)的功能性需求，對于其他的非功能性需要用其他文檔來記錄。RUP中定義了如下的需求工件集合。

• 用例模型：記錄功能性需求
  • 用例圖：描述參與者和用例之間的關(guān)系
  • 用例規(guī)約：描述每一個用例的細節(jié)信息
• 補充規(guī)約：記錄一些全局性的功能需求、非功能性需求和設(shè)計約束等
• 詞匯表：記錄一些系統(tǒng)需求相關(guān)的術(shù)語

在實際應(yīng)用中，除了這些工件之外，我們還可以根據(jù)實際需求靈活選用其他形式的文檔來補充說明需求。并不是所有的系統(tǒng)需求都適保合用用例模型來描述的，如編譯器，我們很難用用例方法來表述它所處理的語言的方法規(guī)則，在這種情況下，采用傳統(tǒng)的BNF范式來表述更加合適一些。在電信軟件行業(yè)中，很多電信標準都是采用SDL語言來描述的，我們也不必用UML來改寫這些標準（UML對SDL存在著這樣的兼容性），只需將SDL形式的電信標準作為需求工件之一，在其他工件中對其加以引用就可以了。總之，萬萬不可拘泥于用例建模的形式，應(yīng)靈活運用各種方式的長處。

3.2 補充規(guī)約

補充規(guī)約記錄那些在用例模型中不易表述的系統(tǒng)需求，主要包括以下內(nèi)容。

• 功能性
  功能性需求主要在用例模型中刻畫，但是也有部分需求不適合在用例中表述。有些功能性需求是全局性的，適用于所有的用例，如出錯處理、I18N支持等，我們不需要在所有的用例中描述這些功能性需求，只需要在補充規(guī)約中統(tǒng)一描述就可以了。
• 可用性
  記錄所有可用性相關(guān)的需求，如系統(tǒng)的使用者所需要的培訓(xùn)時間、是否應(yīng)附合一些常見的可用性標準如Windows界面風(fēng)格等。
• 可靠性
  定義系統(tǒng)可靠性相關(guān)的各種指標，包括：
  
  • 可用性：指出可用時間百分比(xx.xx%)，系統(tǒng)處于使用、維護、降級模式等操作的小時數(shù)；
  • 平均故障間隔時間(MTBF)：通常表示為小時數(shù)，但也可表示為天數(shù)、月數(shù)或年數(shù)；
  • 平均修復(fù)時間(MTTR)：系統(tǒng)在發(fā)生故障后可以暫停運行的時間；
  • 精確度：指出系統(tǒng)輸出要求具備的精密度（分辨率）和精確度（按照某一已知的標準）；
  • 最高錯誤或缺陷率：通常表示為bugs/KLOC（每千行代碼的錯誤數(shù)目）或bugs/function-point（每個功能點的錯誤數(shù)目）。
• 性能
  記錄系統(tǒng)性能相關(guān)的各種指標，包括：
  
  • 對事務(wù)的響應(yīng)時間（平均、最長）；
  • 吞吐量（例如每秒處理的事務(wù)數(shù)）；
  • 容量（例如系統(tǒng)可以容納的客戶或事務(wù)數(shù)）；
  • 降級模式（當(dāng)系統(tǒng)以某種形式降級時可接受的運行模式）；
  • 資源利用情況：內(nèi)存、磁盤、通信等。
• 可支持性
  定義所有與系統(tǒng)的可支持性或可維護性相關(guān)的需求，其中包括編碼標準、命名約定、類庫、如何來對系統(tǒng)進行維護操作和相應(yīng)的維護實用工具等。
• 設(shè)計約束
  設(shè)計約束代表已經(jīng)批準并必須遵循的設(shè)計決定，其中包括軟件開發(fā)流程、開發(fā)工具、系統(tǒng)構(gòu)架、編程語言、第三方構(gòu)件類庫、運行平臺和數(shù)據(jù)庫系統(tǒng)等等。

3.3 詞匯表

詞匯表主要用于定義項目特定的術(shù)語，它有助于開發(fā)人員對項目中所用的術(shù)語有統(tǒng)一的理解和使用，它也是后續(xù)階段中進行對象抽象的基礎(chǔ)。

回頁首

4. 調(diào)整用例模型

在一般的用例圖中，我們只表述參與者和用例之間的關(guān)系，即它們之間的通訊關(guān)聯(lián)。除此之外，我們還可以描述參與者與參與者之間的泛化(generalization)、用例和用例之間的包含(include)、擴展(extend)和泛化(generalization)關(guān)系。我們利用這些關(guān)系來調(diào)整已有的用例模型，把一些公共的信息抽取出來重用，使得用例模型更易于維護。但是在應(yīng)用中要小心選用這些關(guān)系，一般來說這些關(guān)系都會增加用例和關(guān)系的個數(shù)，從而增加用例模型的復(fù)雜度。而且一般都是在用例模型完成之后才對用例模型進行調(diào)整，所以在用例建模的初期不必要急于抽象用例之間的關(guān)系。

4.1 參與者之間的關(guān)系

參與者之間可以有泛化(Generalization)關(guān)系（或稱為"繼承"關(guān)系）。例如在需求分析中常見的權(quán)限控制問題（如下圖所示），一般的用戶只可以使用一些常規(guī)的操作，而管理員除了常規(guī)操作之外還需要進行一些系統(tǒng)管理工作，操作員既可以進行常規(guī)操作又可以進行一些配置操作。

在這個例子中我們會發(fā)現(xiàn)管理員和操作員都是一種特殊的用戶，他們擁有普通用戶所擁有的全部權(quán)限，此外他們還有自己獨有的權(quán)限。這里我們可進一步把普通用戶和管理員、操作員之間的關(guān)系抽象成泛化(Generalization)關(guān)系，管理員和操作員可以繼承普通用戶的全部特性（包括權(quán)限），他們又可以有自己獨有的特性（如操作、權(quán)限等）。這樣可以顯著減速少用例圖中通訊關(guān)聯(lián)的個數(shù)，簡化用例模型，使之更易于理解。

4.2 用例之間的關(guān)系

用例描述的是系統(tǒng)外部可見的行為，是系統(tǒng)為某一個或幾個參與者提供的一段完整的服務(wù)。從原則上來講，用例之間都是并列的，它們之間并不存在著包含從屬關(guān)系。但是從保證用例模型的可維護性和一致性角度來看，我們可以在用例之間抽象出包含(include)、擴展(extend)和泛化(generalization)這幾種關(guān)系。這幾種關(guān)系都是從現(xiàn)有的用例中抽取出公共的那部分信息，然后通后過不同的方法來重用這部公共信息，以減少模型維護的工作量。

4.2.1 包含(include)

包含關(guān)系是通過在關(guān)聯(lián)關(guān)系上應(yīng)用<<include>>構(gòu)造型來表示的，如下圖所示。它所表示的語義是指基礎(chǔ)用例(Base)會用到被包含用例(Inclusion)，具體地講，就是將被包含用例的事件流插入到基礎(chǔ)用例的事件流中。

包含關(guān)系是UML1.3中的表述，在UML1.1中，同等語義的關(guān)系被表述為使用(uses)，如下圖。

在ATM機中，如果查詢、取現(xiàn)、轉(zhuǎn)帳這三個用例都需要打印一個回執(zhí)給客戶，我們就可以把打印回執(zhí)這一部分內(nèi)容提取出來，抽象成為一個單獨的用例"打印回執(zhí)"，而原有的查詢、取現(xiàn)、轉(zhuǎn)帳三個例都會包含這個用例。每當(dāng)以后要對打印回執(zhí)部分的需求進行修改時，就只需要改動一個用例，而不用在每一個用例都作相應(yīng)修改，這樣就提高了用例模型的可維護性。

在基礎(chǔ)用例的事件流中，我們只需要引用被包含用例即可。

查詢-基本事件流

1. 用戶插入信用卡

2. 輸入密碼

3. 選擇查詢

4. 查看帳號余額

5. 包含用例"打印回執(zhí)"

6. 退出系統(tǒng)，取回信用卡

在這個例子中，多個用例需要用到同一段行為，我們可以把這段共同的行為單獨抽象成為一個用例，然后讓其他的用例來包含這一用例。從而避免在多個用例中重復(fù)性地描述同一段行為，也可以防止該段行為在多個用例中的描述出現(xiàn)不一致性。當(dāng)需要修改這段公共的需求時，我們也只需要修改一個用例，避免同時修改多個用例而產(chǎn)生的不一致性和重復(fù)性工作。

有時當(dāng)某一個用例的事件流過于復(fù)雜時，為了簡化用例的描述，我們也可以把某一段事件流抽象成為一個被包含的用例。這種情況類似于在過程設(shè)計語言中，將程序的某一段算法封裝成一個子過程，然后再從主程序中調(diào)用這一子過程。

4.2.2 擴展(extend)

擴展（extend）關(guān)系如下圖所示，基礎(chǔ)用例(Base)中定義有一至多個已命名的擴展點，擴展關(guān)系是指將擴展用例(Extension)的事件流在一定的條件下按照相應(yīng)的擴展點插入到基礎(chǔ)用例(Base)中。對于包含關(guān)系而言，子用例中的事件流是一定插入到基礎(chǔ)用例中去的，并且插入點只有一個。而擴展關(guān)系可以根據(jù)一定的條件來決定是否將擴展用例的事件流插入基礎(chǔ)用例事件流，并且插入點可以有多個。

例如對于電話業(yè)務(wù)，可以在基本通話(Call)業(yè)務(wù)上擴展出一些增值業(yè)務(wù)如：呼叫等待(Call Waiting)和呼叫轉(zhuǎn)移(Call Transfer)。我們可以用擴展關(guān)系將這些業(yè)務(wù)的用例模型描述如下。

在這個例子中，呼叫等待和呼叫轉(zhuǎn)移都是對基本通話用例的擴展，但是這兩個用例只有在一定的條件下（如應(yīng)答方正忙或應(yīng)答方無應(yīng)答）才會將被擴展用例的事件流嵌入基本通話用例的擴展點，并重用基本通話用例中的事件流。

值得注意的是擴展用例的事件流往往可以也可抽象為基礎(chǔ)用例的備選流，如上例中的呼叫等待和呼叫轉(zhuǎn)移都可以作為基本通話用例的備選流而存在。但是基本通話用例已經(jīng)是一個很復(fù)雜的用例了，選用擴展關(guān)系將增值業(yè)務(wù)抽象成為單獨的用例可以避免基礎(chǔ)用例過于復(fù)雜，并且把一些可選的操作獨立封裝在另外的用例中。

4.2.3 泛化(generalization)

當(dāng)多個用例共同擁有一種類似的結(jié)構(gòu)和行為的時候，我們可以將它們的共性抽象成為父用例，其他的用例作為泛化關(guān)系中的子用例。在用例的泛化關(guān)系中，子用例是父用例的一種特殊形式，子用例繼承了父用例所有的結(jié)構(gòu)、行為和關(guān)系。在實際應(yīng)用中很少使用泛化關(guān)系，子用例中的特殊行為都可以作為父用例中的備選流存在。

以下是一個用例泛化關(guān)系的例子，執(zhí)行交易是一種交易抽象，執(zhí)行房產(chǎn)交易和執(zhí)行證券交易都是一種特殊的交易形式。

用例泛化關(guān)系中的事件流示例如下：

4.3 調(diào)整用例模型

用例模型建成之后，我們可以對用例模型進行檢視，看是否可以進一步簡化用例模型、提高重用程度、增加模型的可維護性。主要可以從以下檢查點(checkpoints)入手:

• 用例之間是否相互獨立？如果兩個用例總是以同樣的順序被激活，可能需要將它們合并為一個用例。
• 多個用例之間是否有非常相似的行為或事件流？如果有，可以考慮將它們合并為一個用例。
• 用例事件流的一部分是否已被構(gòu)建為另一個用例？如果是，可以讓該用例包含(include)另一用例。
• 是否應(yīng)該將一個用例的事件流插入另一個用例的事件流中？如果是，利用與另一個用例的擴展關(guān)系(extend)來建立此模型。

回頁首

5. 管理用例模型復(fù)雜度

一般小型的系統(tǒng)，其用例模型中包含的參與者和用例不會太多，一個用例圖就可以容納所有的參與者，所有的參與者和用例也可以并存于同一個層次結(jié)構(gòu)中。對于較復(fù)雜的大中型系統(tǒng)，用例模型中的參與者和用例會大大增加，我們需要一些方法來有效地管理由于規(guī)模上升而造成的復(fù)雜度。

5.1 用例包

包(Package)是UML中最常用的管理模型復(fù)雜度的機制，包也是UML中語義最簡單的一種模型元素，它就是一種容器，在包中可以容納其他任意的模型元素（包括其他的包）。在用例模型中，我們可以用構(gòu)造型(Sterotype)<<use case>>來擴展標準UML包的語義，這種新的包叫作用例包(Use Case Package)，用于分類管理用例模型中的模型元素。

我們可以根據(jù)參與者和用例的特性來對它們進行分類，分別置于不同的用例包管理之下。例如對于一個大型的企業(yè)管理信息系統(tǒng)，我們可以根據(jù)參與者和用例的內(nèi)容將它們分別歸于人力資源、財務(wù)、采購、銷售、客務(wù)服務(wù)這些用例包之下。這樣我們將整個用例模型劃分成為兩個層次，在第一層次我們看到的是系統(tǒng)功能總共分為五部分，在第二層次我們可以分別看到每一用例包內(nèi)部的參與者和用例。

一個用例模型需要有多少個用例包取決你想怎么樣來管理用例模型的復(fù)雜度（包括參與者和用例的個數(shù)，以及它們之間的相互關(guān)系）。UML中的包其實就類似于文件系統(tǒng)中的目錄，文件數(shù)量少的時候不需要額外的目錄，文件數(shù)量一多就需要有多個目錄來分類管理，同樣一組文件不同的人會創(chuàng)建不同的目錄結(jié)構(gòu)來進行管理，關(guān)鍵是要保證在目錄結(jié)構(gòu)下每一個文件都要易于訪問。同樣的道理存在于用例建模之中，如何創(chuàng)建用例包以及用例包的個數(shù)取決于不同的系統(tǒng)和系統(tǒng)分析員，但要保證整個用例模型易于理解。

5.2 用例的粒度

我的系統(tǒng)需要有多少個用例？這是很多人在用例建模時會產(chǎn)生的疑惑。描述同一個系統(tǒng)，不同的人會產(chǎn)生不同的用例模型。例如對于各種系統(tǒng)中常見的"維護用戶"用例，它里面包含了添加用戶、修改用戶信息、刪除用戶等操作，這些操作在該用例的事件流可以表述成為基本流的子事件流(subflow)。

維護用戶-基本事件流

該基本流由三個子事件流構(gòu)成：

1) 添加用戶子事件流
…

2) 修改用戶 子事件流
…

3) 刪除用戶子事件流
…

但是你也可以根據(jù)該用例中的具體操作把它抽象成為三個用例，它所表示的系統(tǒng)需求和單個用例的模型是完全一樣的。

應(yīng)該如何確定用例的粒度呢？在一次技術(shù)研討會上，有人問起Ivar Jacoboson博士，一個系統(tǒng)需要有多少個用例？大師的回答是20個，當(dāng)然他的意思是最好將用例模型的規(guī)模控制在幾十個用例左右，這樣比較容易來管理用例模型的復(fù)雜度。在用例個數(shù)大致確定的條件下，我們就很容易來確定用例粒度的大小。對于較復(fù)雜的系統(tǒng)，我們需要控制用例模型一級的復(fù)雜度，所以可以將復(fù)雜度適當(dāng)?shù)匾仆恳粋€用例的內(nèi)部，也就是讓一個用例包含較多的需求信息量。對于比較簡單的系統(tǒng)，我們則可以將復(fù)雜度適度地曝露在模型一級，也就是我們可以將較復(fù)雜的用例分解成為多個用例。

用例的粒度不但決定了用例模型級的復(fù)雜度，而且也決定了每一個用例內(nèi)部的復(fù)雜度。我們應(yīng)該根據(jù)每個系統(tǒng)的具體情況，因時因宜地來把握各個層次的復(fù)雜度，在盡可能保證整個用例模型的易理解性前提下決定用例的大小和數(shù)目。

5.3 用例圖

用例圖的主要作用是描述參與者和用例之間的關(guān)系，簡單的系統(tǒng)中只需要有一個用例圖就可以把所有的關(guān)系都描述清楚。復(fù)雜的系統(tǒng)中可以有多個用例圖，例如每個用例包都可以有一個獨立的用例圖來描述該用例包中所有的參與者和用例的關(guān)系。

在一個用例模型中，如果參與者和用例之間存在著多對多的關(guān)系，并且他們之間的關(guān)系比較復(fù)雜，如果在同一個用例圖中表述所有的參與者和用例就顯得不夠清晰，這時我們可創(chuàng)建多個用例圖來分別表示各種關(guān)系。

如果想要強調(diào)某一個參與者和多個用例的關(guān)系，你就可以以該參與者為中心，用一個用例圖表述出該參與者和多個用例之間的關(guān)系。在這個用例圖中，我們強調(diào)的是該參與者會使用系統(tǒng)所提供的哪些服務(wù)。

如果想要強調(diào)某一個用例和多個參與者之間的關(guān)系，你就可以以該用例為中心，用一個用例圖表述出該用例和多個參與者之間的關(guān)系。在這個用例圖中，我們強調(diào)的是該用例會涉及到哪些參與者，或者說該用例所表示的系統(tǒng)服務(wù)有哪些使用者。

總之在用例建模過程中，你可以根據(jù)自己的需要創(chuàng)建任意多個用例圖，用不同的用例來強調(diào)參與者和用例之間不同的關(guān)系。但是最重要的是要考慮整個用例模型的可理解性，如果可以用一個用例圖把意思表述清楚，就不要再用第二個，因為越是簡潔的模型越易于理解。

看完了一些資料，對SCA的理解清晰了一些了。
SCA Module是包裝SCA Component的，SCA Module上有對外的接口（這個接口可以是Java的，也可以是WSDL的），而且SCA Module可以放在WPS上進行測試，WPS上有自己設(shè)定的一些UI來幫助測試。如果有JSP之類的東西要訪問SCA Component的話，要在SCA Module中建立一個StandAlone reference，之后JSP就通過StandAlone reference訪問SCA Component。
SCA Component可以有多種實現(xiàn)方法，包括Java,Human Task,BPEL,Business rules等。比如業(yè)務(wù)流程中有5個服務(wù)，那么我們就可以建立6個SCA Module，其中的一個SCA Module中的SCA Component是用BPEL實現(xiàn)的，BPEL連接的5個業(yè)務(wù)模塊是靠調(diào)用另5個SCA Module中的SCA Component來實現(xiàn)。而這5個SCA Component可以是不同的實現(xiàn)方法，比如分別為：Java,Business rules,Java,Human Task,Business rules。這樣就可以實現(xiàn)一種面向服務(wù)的開發(fā)。每個SCA Component中可能包括1個或者多個再細分的服務(wù)，這就依情況而定了。

呵呵，希望理解的到位一些了。

WBM, RSA, WID, WPS, WBM(Monitor),RAD?or WAD,?WESB or WMB.

經(jīng)過昨天的商討，文檔由三人分開編寫。
Merlin：業(yè)務(wù)模型分析和設(shè)計（包括商業(yè)價值分析）
April：系統(tǒng)外觀界面設(shè)計，服務(wù)模型分析和設(shè)計
Tory：系統(tǒng)架構(gòu)設(shè)計


如完成后還有時間，就繼續(xù)鉆研老師給的光盤資料。周末討論并整理這些文檔，并制定下一步文檔計劃。

引言

雖然 SOA 可以帶來許多好處，但同時也可能受到以下一個或多個問題的困擾：

• 高復(fù)雜性和短上市時間，這樣會增加失敗的風(fēng)險
• 由于高成本和量化投資回報 (ROI) 困難而導(dǎo)致較難容忍出現(xiàn)錯誤
• 需要恰當(dāng)管理的動態(tài)要求和業(yè)務(wù)需求

如果您使用了軟件方法——軟件開發(fā)的系統(tǒng)方法——來在初始 SOA 推出期間提供所需的嚴格控制和過程，并在優(yōu)化 SOA 的過程中進行調(diào)整，就可以避免這些問題。在考慮此處給出的軟件方法之前，請閱讀本系列的第二篇文章，該文指出，在面向服務(wù)的體系結(jié)構(gòu)成熟度模型的第 3 級或第 4 級的“面向服務(wù)的體系結(jié)構(gòu)成熟度模型”組織應(yīng)使用 RUP 等正式的軟件方法進行開發(fā)工作。只要達到了第 5 級，他們就應(yīng)該使用 XP 之類的靈活方法了。

您的企業(yè)如何在保持開發(fā)過程一致的前提下過渡到較高的成熟度級別呢？本文將介紹一種最佳組合的方法，面向服務(wù)的統(tǒng)一過程 或 SOUP，用于開展構(gòu)建工作并隨后進行持續(xù)優(yōu)化。在繼續(xù)閱讀本文之前，您應(yīng)當(dāng)對 RUP 和 XP 的工作方式有基本的了解。請參閱參考資料，以獲得可幫助您了解相關(guān)知識的鏈接。

什么是 SOUP？

SOUP （Service-Oriented Unified Process）是一種使用 RUP 和 XP 中的最佳部分來構(gòu)建和管理 SOA 項目的軟件方法。它的目標是任何組織中正在進行的 SOA 項目。

典型的軟件開發(fā)項目包含應(yīng)用程序開發(fā)過程、項目管理以及所使用的技術(shù)。此外，軟件開發(fā)項目通常具有四個變量：時間、預(yù)算、范圍 和質(zhì)量。任何一個變量的變化對整個項目都有影響。不斷變化的業(yè)務(wù)需求使得范圍和質(zhì)量成為兩個最難管理的因素。技術(shù)復(fù)雜性可能導(dǎo)致時間和預(yù)算管理方面出現(xiàn)問題。

SOA 項目比通常的軟件項目復(fù)雜得多，因為它們要求配備更大的跨功能的團隊，并且還有因此而帶來更復(fù)雜的團隊間溝通和日常管理工作。

雖然 SOA 可以為組織帶來許多好處，但同時也可能帶來很大的成本支出和時間消耗。如果項目沒有經(jīng)過良好定義，并且在項目啟動時沒有關(guān)于最終結(jié)果的遠景，則失敗的可能性就非常大。

可以幫助 SOA 成功完成的關(guān)鍵因素有：

• 明確定義的開發(fā)過程
• 與業(yè)務(wù)相關(guān)的項目團隊之間增強的溝通渠道
• 明確的支持和控制策略

在初始開發(fā)過程中，采用正式軟件方法是盡可能地減少已確定的風(fēng)險的最好辦法。成功建立了 SOA 項目后，可利用正式的維護和增量開發(fā)方法來增加項目的 ROI。然而，XP 之類的靈活方法可能不夠正式，不適合在初始階段使用。SOUP 方法可幫助減少 SOA 推出階段的風(fēng)險，并能讓您隨后進行持續(xù) SOA 優(yōu)化工作。

SOUP 是一個由六個階段組成的軟件開發(fā)方法。每個階段代表對于 SOA 成功推出非常關(guān)鍵的一組特有的活動。當(dāng)然，和在任何項目中一樣，您將需要根據(jù)所在組織的情況對相關(guān)過程進行調(diào)整。

圖 1 顯示了 SOUP 過程。此方法也沒有非常特別的地方：所有軟件或 SOA 項目都是采用類似的方式定義的。

圖 1. SOUP 過程模型

我將 SOUP 過程分為兩類：

• 用于初始 SOA 部署的 SOUP
• 用于后續(xù) SOA 管理的 SOUP

用于初始 SOA 部署的 SOUP

圖 2 顯示了用于初始 SOA 部署的 SOUP 的各個階段。

圖 2. SOUP 與 RUP 模型

每個階段都包含主要交付內(nèi)容和活動：

初始

在此階段，將確定組織對 SOA 項目的需求。您可以通過應(yīng)用 SOA 成熟度模型來確定組織的體系結(jié)構(gòu)成熟度水平并確定 SOA 的驅(qū)動因素。此時，您將需要向為業(yè)務(wù)服務(wù)的所有項目團隊說明 SOA 的基本概念，并擬訂與反饋和建議流程有關(guān)的策略計劃。

此階段的主要交付內(nèi)容有：

• SOA 遠景和范圍：給出項目的整體遠景。它還提供了確定項目范圍的邊界，該范圍至少應(yīng)包含兩個業(yè)務(wù)線或項目。
• SOA 策略：說明項目將如何執(zhí)行的概略計劃。
• ROI 分析：給出此項目將帶來的成本支出和節(jié)省情況。
• 溝通計劃：說明 SOA 團隊將如何與其他項目團隊和業(yè)務(wù)用戶進行溝通。

客戶（即業(yè)務(wù)干系人）通常并不能完全了解新軟件產(chǎn)品可以帶來的好處。定義 SOA 策略的企業(yè)團隊需要利用項目團隊的專業(yè)知識來幫助確定業(yè)務(wù)問題以及簡化操作的方法。

跨功能分析人員和項目管理人員將對客戶的業(yè)務(wù)進行分析，以確定基于 SOA 的解決方案的優(yōu)勢。分析人員將對客戶的內(nèi)部操作進行研究，此外還要分析其與合作伙伴、供應(yīng)商以及他們的客戶的交互情況，而且也會研究其總體業(yè)務(wù)模型。這些因素有助于分析人員制定 SOA 策略并向客戶推薦。

在此階段，您還需要對推薦的 SOA 策略進行全面的 ROI 分析。此分析應(yīng)當(dāng)清楚地表明短期、中期和長期的成本優(yōu)勢。

此階段最重要的交付內(nèi)容是溝通計劃。項目 IT 團隊和業(yè)務(wù)干系人比體系結(jié)構(gòu)團隊和分析人員更了解業(yè)務(wù)。溝通計劃可以確保這些內(nèi)部干系人能夠理解并參與到開發(fā)過程中來。

定義

到目前為止，定義階段是 SOA 項目中最為關(guān)鍵的階段。此階段業(yè)務(wù)和項目團隊的參與將最終決定項目的成功。團隊成員需要積極地參與到作為初始 SOA 推出的一部分開發(fā)的需求定義和用例方面的工作中來。

項目生命周期的此階段的活動包括：

• 收集需求
• 分析需求
• 定義非功能需求
• 制定項目計劃，其中包含時間安排和項目估算
• 定義技術(shù)基礎(chǔ)設(shè)施
• 定義和實現(xiàn)用例
• 定義和記錄總的體系結(jié)構(gòu)

此階段的主要交付內(nèi)容有：

• 功能需求文檔：詳細描述 SOA 將作為業(yè)務(wù)服務(wù)提供的所有業(yè)務(wù)流程。
• 非功能需求文檔：包括性能注意事項、服務(wù)水平協(xié)議 (SLA) 和基礎(chǔ)設(shè)施要求。
• 用例和用例實現(xiàn)：詳細說明將構(gòu)建的所有業(yè)務(wù)服務(wù)的用例。
• SOA 體系結(jié)構(gòu)文檔：描述項目總的體系結(jié)構(gòu)，包括硬件和軟件組件。
• SOA 適用性文檔：說明哪些項目將在 SOA 項目的范圍內(nèi)以及如何在 SOA 的基礎(chǔ)上構(gòu)建后續(xù)項目。
• 基礎(chǔ)設(shè)施定義文檔：包括詳細的基礎(chǔ)設(shè)施部署圖，其中列出相關(guān)服務(wù)器以及實現(xiàn) SOA 所需的服務(wù)器的連接和連接位置。
• 項目計劃：整個項目的詳細計劃，包括里程碑和依賴關(guān)系。
• 支持和控制模型：描述將如何支持和控制 SOA。其中包括各種注意事項，如 SLA 監(jiān)視和管理。

研究（請參閱參考資料）表明，與需求相關(guān)的問題是軟件項目失敗的首要原因；SOA 項目也不例外。軟件質(zhì)量 有時定義為軟件對其需求的滿足情況。但是，測定軟件質(zhì)量的更好辦法可能是通過其滿足的需求的質(zhì)量 測定，而不是通過其滿足的需求的數(shù)量 測定。

在明確說明了交付內(nèi)容后，SOUP 方法將建議一個用于進行需求收集和管理的正式流程。XP 并不定義用于收集和記錄需求的正式流程；而 XP 開發(fā)人員將創(chuàng)建一些用戶案例（請參閱參考資料）并按邏輯順序?qū)@些案例進行排列，以提供一個需求序列。在此開發(fā)階段，這樣的流程并不夠用。在 RUP 中，相應(yīng)的流程更為詳細，并使用更多的正式技術(shù)來確保舉行相關(guān)的需求收集會議、對需求進行記錄并加以驗證。我建議使用需求存儲庫，該存儲庫將與用例、設(shè)計和代碼緊密結(jié)合，以在項目進行的整個過程中提供可跟蹤性。該存儲庫可以為 IBM Rational? RequisitePro? 工具或您組織選用的任何其他需求管理工具。更改管理流程也很重要。

此階段最重要的交付內(nèi)容是支持和控制模型。組織將如何支持 SOA？控制指導(dǎo)方針有哪些？如果推出了一個 SOA，但沒有人使用，則項目就失敗了。支持和控制模型文檔可以防止發(fā)生這種情況。

企業(yè)應(yīng)當(dāng)在制定了真實可行的計劃和目標的情況下啟動項目。其他需求應(yīng)留待以后解決。如果在預(yù)期的時間和預(yù)算內(nèi)，可以完成有關(guān)需求的有效業(yè)務(wù)-IT (B2IT) 協(xié)作，則可以幫助確保項目的成功。

請在項目早期定義支持整個 SOA 所需的技術(shù)基礎(chǔ)設(shè)施。這包括服務(wù)器、網(wǎng)絡(luò)基礎(chǔ)設(shè)施和培訓(xùn)要求方面的詳細評估。

設(shè)計

在設(shè)計階段，您將對定義階段確定的設(shè)計構(gòu)件進行細化。用例實現(xiàn)和軟件體系結(jié)構(gòu)文檔將轉(zhuǎn)化為詳細的設(shè)計文檔。

此時，SOA 架構(gòu)師（通常為企業(yè)架構(gòu)師中的一部分）需要與項目架構(gòu)師合作，以確保 SOA 團隊給出的設(shè)計可以供具體的項目使用。SOA 架構(gòu)師甚至可能選擇完成一些概念驗證 (proof-of-concept) 項目，以證明 SOA 遠景。此階段的主要交付內(nèi)容有：

• 詳細設(shè)計文檔：描述如何設(shè)計和構(gòu)建服務(wù)。
• 應(yīng)用程序編程模型：提供有關(guān)設(shè)計開發(fā)項目的結(jié)構(gòu)的指南。涉及的主題包括使用的流程和技術(shù)、編碼標準以及部署過程。
• 數(shù)據(jù)庫模型：包括 SOA 使用的數(shù)據(jù)庫的實體關(guān)系圖。
• 測試和 QA 計劃：詳細說明測試和 QA 計劃，并在其中包括測試用例。

構(gòu)造

在構(gòu)造階段，將使用您選擇的迭代構(gòu)建方法來構(gòu)建 SOA。此階段中包括新的開發(fā)和集成活動。您的活動不僅限于軟件方面，還涉及到與基礎(chǔ)設(shè)施相關(guān)的子項目，如硬件整合項目或服務(wù)器承載集中化工作。雖然整個工作是在單個 SOA 項目中進行管理的，但仍然很有可能將由各種小型子團隊進行不同的構(gòu)造活動。

項目生命周期的此階段將涉及到各種活動，如：

• 迭代開發(fā)
• 迭代 QA 和測試
• 用戶文檔

此階段的主要交付內(nèi)容有：

• 基本代碼：該代碼應(yīng)存儲在某類源代碼管理存儲庫中。
• 測試結(jié)果：執(zhí)行測試用例和 QA 計劃的結(jié)果應(yīng)可供進行檢查分析。
• 文檔：文檔中應(yīng)包含關(guān)于代碼以及對設(shè)計文檔的任何更新的詳細信息。

部署

在部署階段，您將向各個項目團隊推出 SOA，這些項目團隊將開始在其生產(chǎn)環(huán)境中的項目上使用此 SOA。此階段最明顯的主要交付內(nèi)容或許就是投入生產(chǎn)環(huán)境中使用的應(yīng)用程序。然而，SOA 試驗項目的計劃卻是更為重要的交付內(nèi)容。這將導(dǎo)致進入 SOUP 方法的下一個步驟，該步驟將確定后續(xù)項目如何使用新體系結(jié)構(gòu)。此階段的其他主要交付內(nèi)容有：

• 部署模型：給出總的 SOA 部署結(jié)構(gòu)。
• 用況模型：提供有關(guān)如何使用 SOA 的指南。隨著各個項目團隊和業(yè)務(wù)線開始使用新體系結(jié)構(gòu)，此模型會變得非常重要。
• 后續(xù)支持級別模型：將對定義階段開發(fā)的支持和控制模型的任何更新進行系統(tǒng)化。

支持

軟件開發(fā)周期的這最后一個步驟非常重要。在支持階段，您將確保提供后續(xù) SOA 支持、錯誤修正和進行新功能開發(fā)。項目生命周期的此階段將涉及到各種活動，如：

• 維護
• 錯誤修正
• 培訓(xùn)
• 持續(xù)項目投入

您的 SOA 現(xiàn)在已經(jīng)投入生產(chǎn)了。但項目團隊如何從該體系結(jié)構(gòu)受益呢？為了構(gòu)建使用現(xiàn)有服務(wù)的應(yīng)用程序，或設(shè)計使用現(xiàn)有 SOA 的新服務(wù)，他們是否需要遵循上面詳細列出的所有步驟？正如您將在下面的部分中看到的，實際上，他們可以從一個更為輕量級的方法中獲益。

用于后續(xù) SOA 管理的 SOUP

SOUP 方法可以用于那些使用已經(jīng)推出的 SOA 的項目。在這種情況下，SOUP 對 XP 進行了大量的參考。圖 3 表明了 SOUP 和 XP 過程彼此重疊。

圖 3. 重疊的 SOUP 和 XP 過程

這種方法主要帶來什么樣的好處呢？SOA 項目的價值在于，它可提供良好定義的體系結(jié)構(gòu)和嚴格的技術(shù)指南。您獲得了一個框架，可以在其中以服務(wù)的形式構(gòu)建應(yīng)用程序。項目團隊的主要任務(wù)是構(gòu)建和使用服務(wù)。他們最適合執(zhí)行這些任務(wù)，因為他們具有必要的業(yè)務(wù)領(lǐng)域知識。但是，他們并不需要考慮技術(shù)體系結(jié)構(gòu)或技術(shù)的創(chuàng)新，因為這些任務(wù)將由 SOA 團隊完成。

此類項目將遵循上一部分中列出的相同 SOUP 指南；不過，您將發(fā)現(xiàn)，每個階段的工作量都大幅度地減少了。這一部分的許多交付內(nèi)容都和前面描述的一樣；必要時，我會說明它們與從頭構(gòu)建 SOA 時的項目中的對等項之間的差異。

初始

啟動 SOA 并運行后，仍然需要進行一些開發(fā)工作。您無疑將希望構(gòu)建使用現(xiàn)有服務(wù)或公開新服務(wù)的項目。初始階段的主要交付內(nèi)容有：

• 項目遠景和范圍：這僅包含單個項目的范圍，而不包含更大的 SOA 計劃的范圍。
• 項目策略：描述此具體項目的策略和流程，并說明其如何利用 SOA。
• ROI 分析：項目的詳細成本優(yōu)勢分析，這對于幫助進行與實現(xiàn)有關(guān)的決策非常關(guān)鍵。

定義

在定義階段，您將構(gòu)建與 SOA 項目有關(guān)的各項內(nèi)容，并了解如何利用 SOA。您需要標識 SOA 可以提供的服務(wù)和仍然需要構(gòu)建以滿足您的項目目標的服務(wù)。

項目生命周期的此階段的活動包括：

• 收集需求
• 標識服務(wù)
• 制定項目計劃，其中包括時間安排和項目評估
• 開發(fā)測試用例

此階段的主要交付內(nèi)容有：

• 功能需求文檔：軟件項目的典型需求文檔。
• 用例和用例實現(xiàn)：涵蓋所有正在構(gòu)建的新業(yè)務(wù)流程。
• SOA 適用性文檔：說明現(xiàn)有 SOA 框架如何應(yīng)用到此項目。
• 項目計劃：詳細說明整個項目，包括里程碑和依賴關(guān)系。
• 服務(wù)策略：標識已經(jīng)存在并能夠使用的服務(wù)以及可以公開的新服務(wù)。
• 測試計劃：其中包括項目的測試用例。

在此階段，您不需要嚴格遵循在 SOA 推出期間遵循的正式需求收集標準。相反，可以通過用戶案例或類-責(zé)任-協(xié)作者（Class, Responsibilities, Collaborator，CRC）卡（請參閱參考資料）來簡化需求收集。根據(jù) XP 的思想，測試案例是在這種類型的項目的早期構(gòu)建的。

設(shè)計

此階段可以迅速完成，因為大部分服務(wù)都在初始 SOA 推出時已經(jīng)完成。在設(shè)計階段，只需要關(guān)心如何使用這些服務(wù)，需要在現(xiàn)有服務(wù)的基礎(chǔ)上構(gòu)建什么功能，以及需要構(gòu)建哪些新服務(wù)。

此階段的主要交付內(nèi)容有：

• 詳細設(shè)計文檔：說明您的設(shè)計如何利用總體 SOA，并建立設(shè)計與應(yīng)用程序編程模型。
• 數(shù)據(jù)庫模型：封裝供此特定項目使用的邏輯和物理數(shù)據(jù)設(shè)計。

構(gòu)造

構(gòu)造階段涉及更多的是裝配，而不是新部署。隨著提供的服務(wù)越來越多，每個項目都將有越來越多的可重用服務(wù)，而需要構(gòu)建的新服務(wù)也就越來越少。XP 的迭代開發(fā)技術(shù)是此開發(fā)階段的最佳選擇。在 XP 中，理論上的迭代周期設(shè)置為兩周，當(dāng)在 SOA 環(huán)境中構(gòu)建小型服務(wù)和使用一組服務(wù)時，這一時間對于一個開發(fā) Development-QA 周期來說絕對足夠了。使用此迭代方法，SOA 可以通過快速軟件發(fā)布提供有價值的業(yè)務(wù)靈活性。

項目生命周期的構(gòu)造階段的活動包括：

• 迭代開發(fā)
• 迭代 QA 和測試
• 用戶文檔

此階段的主要交付內(nèi)容有：

• 新服務(wù)：在本階段結(jié)束時，任何將要公開的新服務(wù)都會準備就緒。
• 測試結(jié)果：執(zhí)行測試用例所得到的結(jié)果應(yīng)提供給所有相關(guān)方。
• 文檔：此開發(fā)階段應(yīng)產(chǎn)生詳細的代碼文檔以及對以前創(chuàng)建的其他文檔的所有必要更新。

部署

在此階段，將啟動使用多個服務(wù)的應(yīng)用程序，或啟動新服務(wù)。由于基礎(chǔ)設(shè)施是由 SOA 團隊進行管理的，因此該流程相對比較簡單。

支持

在此階段，將僅為您的新服務(wù)提供支持。在進行此項工作的過程中，請遵循在原始 SOA 項目期間制定的支持指南。單個項目不需要花很多時間制定新的支持指南。

管理 SOA 生命周期

本文向您介紹了 SOUP，這種新的軟件方法可用于構(gòu)建 SOA 并將此體系結(jié)構(gòu)的好處帶給各個項目。文中說明了可以如何使用類似于 RUP 的正式方法來對 SOA 進行初始構(gòu)建，然后轉(zhuǎn)向 XP 樣式的靈活流程，以進行后續(xù)服務(wù)推出工作。通過實現(xiàn)這兩個過程的最佳組合，您可以依靠一個統(tǒng)一的開發(fā)模式來進行相關(guān)工作，此模式可提供足夠的靈活性，以便對 SOA 生命周期的不同階段進行管理。

1． 服務(wù)組件往往是粗粒度的，而傳統(tǒng)組件以細粒度居多。

2． 服務(wù)組件的接口是標準的，主要是WSDL接口，而傳統(tǒng)組件常以具體API形式出現(xiàn)。

3． 服務(wù)組件的實現(xiàn)與語言是無關(guān)的，而傳統(tǒng)組件常綁定某種特定的語言。

4． 服務(wù)組件可以通過組件容器提供QoS的服務(wù)，而傳統(tǒng)組件完全由程序代碼直接控制。

現(xiàn)在瀏覽器端以 JavaScript 為核心，基于各種 Web 標準（即：早已完成標準化的XHTML/CSS/DOM/XML/XSLT 和正在進行標準化的XMLHTTP）的技術(shù)正在加速整合，Ajax 就是這一系列技術(shù)的一個統(tǒng)稱。

雖然網(wǎng)絡(luò)上已經(jīng)有大量的相關(guān)資源，但是為了打好基礎(chǔ)，認真讀上幾本書還是很有必要的。好在 Ajax 并不是什么全新的技術(shù)，它僅僅是傳統(tǒng)技術(shù)的發(fā)展和增值，是對于這些基于 Web 標準的傳統(tǒng)技術(shù)的重新包裝，使其更加適合于企業(yè)應(yīng)用，并且和服務(wù)器端結(jié)合地更加緊密。因此學(xué)習(xí) Ajax，首先就要從深入學(xué)習(xí)這些傳統(tǒng)的技術(shù)開始。我由淺入深地列出一些我讀過的書籍，提供給大家做參考：

1、XHTML 教程（XHTML）

作者：Chelsea Valentine, Chris Minnick

New Riders 原版，人民郵電出版社中文版

是的，今天你最應(yīng)該學(xué)習(xí)的是 XHTML，而不是 HTML。HTML 4.x 已經(jīng)是一個被廢棄了的標準，今天的標準是 XHTML 1.0。XHTML 1.0 也不是 XHTML 最新的版本，但是它是目前唯一得到瀏覽器廣泛支持和唯一實用的 XHTML 版本。

2、JavaScript 權(quán)威指南第四版（JavaScript: The Definitive Guide）

作者：David Flanagan

O'Reilly 原版，中國電力出版社中文版

JavaScript 愛好者親切地稱之為“犀牛書”，因為 O'Reilly 以犀牛作為這本書的封面。這是目前 JavaScript 領(lǐng)域最深入和最權(quán)威的入門書。與其它 JavaScript 相關(guān)書籍的區(qū)別是這本書一半以上的篇幅著重于深入介紹 JavaScript 語言本身的基礎(chǔ)知識，而不是象其它的書一樣把基礎(chǔ)知識和與 HTML 相結(jié)合做 Web 開發(fā)的內(nèi)容（這些內(nèi)容往往偏重于細節(jié)，使得其篇幅很容易就超出了 1000 頁，例如《JavaScript Bible》）混雜在一起。對于剛剛開始學(xué)習(xí) JavaScript 的初學(xué)者，這本書毫無疑問是最佳的入門書。

3、XML 高級編程（Professional XML）

Didier Martin等著

Wrox 原版，機械工業(yè)出版社中文版

這本書是關(guān)于 XML 開發(fā)技術(shù)非常詳盡的著作。雖然因為作者眾多（第一版 12 個人，第二版好像又多了幾個），無法擺脫 Wrox 紅皮書系列大雜燴的印記，但是這本書可以說是紅皮書系列中少有的精品。

這本書可以作為 XML 技術(shù)參考書，雖然很厚，但是沒有必要從頭到尾全部讀完。其中與 Ajax 相關(guān)的內(nèi)容包括 XML DOM、XSLT 等等。

4、網(wǎng)站重構(gòu)（Designing with Web Standards）

作者：Jeffrey Zeldman

New Riders 原版，電子工業(yè)出版社中文版

這本書詳細地介紹了如何摒棄遠古時代（按照我的理解，3 年以前吧）不符合標準，專門針對某種瀏覽器（90%以上的情況下是 IE）做開發(fā)的惡習(xí)，真正采用符合標準的方式來做開發(fā)，最終走上向后兼容（注意：不是與瀏覽器以前不能完整支持 Web 標準的版本相兼容，而是與瀏覽器以后的版本相兼容）的平坦大路上來。這本書雖然不是 CSS 的專著，但是其中充分展示了使用 CSS 的一些高級技巧。尤其是最后一章展示了完全基于 CSS 做布局，摒棄使用 table 做布局的老方法的具體做法。

非常遺憾的是這本書的中文版翻譯的非常爛，如果不對照原文，很容易誤入歧途。讀這本書有任何疑問的朋友都可以直接和我聯(lián)系。

上面列出的是與 Ajax 涉及到的技術(shù)相關(guān)的書籍。我沒有列出 CSS 的書，是因為我并沒有專門讀過一本 CSS 方面的專著。附件是網(wǎng)上流傳很廣的 CSS 2.0 中文手冊，可以作為這方面的參考。

讀了以上這些書，你已經(jīng)在技術(shù)方面打下了極為堅實的基礎(chǔ)，你還需要有一個經(jīng)常的討論場所，JavaEye 毫無疑問是你最值得來的地方。

下面我再列出幾本與技術(shù)沒有直接關(guān)系的書籍。

5、面向使用的軟件設(shè)計（Software for Use）

作者：Larry Contantine, Lucy Lockwood

ACM Press 原版，機械工業(yè)出版社中文版

大部分的軟件都是給人使用的。我在 BEA User Group上的演講中說到，Ajax 為什么會越來越流行，主要的原因就是它能比傳統(tǒng)的基于 HTML FORM 的交互模式帶給用戶更好的交互體驗，也就是 Ajax 可以實現(xiàn)更好的 Web 可用性（Web Usability，這是目前國外的一個專門的研究領(lǐng)域），這才是 Ajax 最大的價值。軟件的可用性永遠都是一個大的話題，《面向使用的軟件設(shè)計》正是這方面最權(quán)威的專著。我們只要在做最終用戶直接使用（有一個可視的界面）的軟件開發(fā)，提高可用性就是我們需要孜孜不倦追求的目標。

6、軟件創(chuàng)新之路（Inmates Are Running the Asylum）

作者：Alan Cooper

Sams Publishing 原版，電子工業(yè)出版社中文版

7、About Face 2.0

作者：Alan Cooper

John Wiley & Sons 原版，中文版即將出版

上面兩本書都是交互設(shè)計大師 Alan Cooper 的名著，相信很多朋友都知道 Alan Cooper 的大名，這兩本書是交互設(shè)計愛好者必讀的著作。