2003?年?8?月?01?日

商業流程執行語言BPEL4WS(Business?Process?Execution?Language?For?Web?Services)是專為整合Web?Services而制定的一項規范標準。它從本質上來說是IBM的WSFL和Microsoft的XLANG的結合物，目前已經成為業界標準。WSFL?支持圖形化的流程，而XLANG在結構化構造方面有獨到的方法，而BPEL4WS正是吸取了兩者的優點，同時摒棄了一些復雜繁瑣的部分，形成了一種較為自然的描述商業活動的抽象高級語言。
引言

在本文的前三篇文章中(商業流程開發新紀元--BPEL4WS語言介紹，第1部分：特點介紹及使用技巧提示，第2部分：如何有針對性的利用RUP來規范BPEL4WS系統開發流程，BPEL4WS語言介紹，第3部分：利用UML對BEPL4WS系統進行建模)，已經向讀者介紹了BPEL4WS語言的主要特點，BPEL4WS主要元素使用技巧以及利用外部Web服務的一些技巧；在軟件過程方面著重介紹了在利用BPEL4WS語言進行系統開發時如何合理利用現有成熟軟件過程RUP(Rational?Unified?Process)進行有針對性的系統開發；在BPEL4WS系統建模方面簡要介紹了在開發過程中為什么要利用UML(Unified?Modeling?Language)對BPEL4WS系統進行建模以及如何用UML來構架BPEL4WS系統的體系結構。在本中將向讀者介紹如何有針對性的利用UML核心架構對BPEL4WS系統進行建模。希望本文的內容會對您對UML核心架構的理解有所幫助。?

（注：對于BPEL4WS的基本語法介紹以及UML的詳細語言規范由于篇幅原因并沒有包括在本文中，讀者可以參閱附錄中的相關資料介紹；?
在文中出現的"BPEL4WS系統"與"用BPEL4WS語言開發的商業系統"同義）?

正文

根據不同系統的不同性質，一些模型可能比另一些模型要重要。例如，對于數據密集型系統，表達靜態設計視圖的模型將占主導地位。對于圖形用戶接口密集型系統，靜態和動態用況視圖就顯得相當重要。在實時系統中，動態進程視圖尤為重要。而在多層分布式系統中，尤其是在BPEL4WS系統中，實現模型和實施模型相對于其它系統來說就變得更加的重要。?

在利用BPEL4WS語言進行系統開發的過程中利用UML進行建模的方法和對普通的軟件系統進行建模的方法大體上是相同的，但由于BPEL4WS系統本身的特點決定了只有針對性地進行建?；顒硬拍苋〉酶袃r值的成果，再加上利用UML建模的過程實際上就是在遵循UML?Specification的基礎上，利用UML提供的一些核心要素對要開發的系統進行可視化、詳述、構造和文檔化的過程，所以我們可以針對UML的三個基本核心要素(基本構造塊、規則、公共機制)來結合BPEL4WS語言的特點來有針對性地進行建模活動。而如何有針對性的利用UML核心架構對BPEL4WS系統進行建模成為了一個重要的問題，在下面的內容中將會較細致的介紹UML中主要元素的特點和如何在建?；顒又杏袃A向性地向BPEL4WS系統靠攏。?

<一>基本構造塊

在UML中的基本構造塊可以劃分為主要的三大類，每一類又可以細分為上圖所示的許多小類。對于一個小型的項目來說，也許我們只會用到這些元素的一部分，但對于一個規模較大、較復雜的項目，特別是像BPEL4WS系統這樣的多層分布式系統來說，在我們建模的過程中，基本上會用到上面的每一種構造塊，只是側重點要根據項目的特點的不同而定了。在UML的構造塊中，我們利用"事物"可以對BPEL4WS模型中最具代表性的成分進行抽象；利用"關系"把BPEL4WS系統中的各種相關事物結合在一起；利用"圖"來聚集整個BPEL4WS系統中的相關的事物。接下來讓我們來分析每一類基本構造塊的特點，以及如何有針對性地利用它們對BPEL4WS系統進行建模。?

<1.1>基本構造塊中的4種事物：

<1.1.1>結構事物（Structural?thing）：是整個UML模型中的名詞。它們通常是模型的靜態部分，在BPEL4WS系統中，我們可以利用結構事物來描述一些重要的概念或者物理元素，我們必須能夠捕捉到整個BPEL4WS系統中存在的所有的相關的結構事物，只有在完整的系統語義的基礎上，我們才可能進一步地發現和得到系統的動態特性。在利用UML建模時，我們一共可以用到7種結構事物，它們分別是：?

類(Class):是對一組具有相同屬性、相同操作、相同關系和相同語義的對象的描述。我們利用一個類可以實現一個或多個接口。在BPEL4WS系統中，類是最基礎的系統構造部分，值得我們多加注意的是我們應該把外部服務抽象成類的概念來進行建?；顒樱@在后面的類圖介紹中會進行解釋。?

接口(Interface):是描述了一個類或構件的一個服務的操作集合。因此，接口描述元素的外部可見行為。一個接口可以描述一個類或構件的全部行為或部分行為。值得我們注意的是，我們只是利用接口定義了一組操作的描述（即特征標記），而不是操作的實現，所有具體的實現都由類或者構件來完成。在BPEL4WS系統中，如果外部的Web服務提供給我們的服務是"暗盒操作"，也就是我們不知道操作的具體內部流程，我們就可以把這些操作抽象到某個接口中，而這些接口由那些抽象成類的Web服務來實現。?

協作(Collaboration):定義了一個交互，它是由一組共同工作以提供某協作行為的角色和其他一些相關元素構成的一個群體，這些協作行為從范圍上來說要大于所有元素的各自行為的總和。因此，協作是有結構、行為和維度的。要注意的一點是，一個給定的類可以參與幾個協作，而這些協作表現了系統構成模式的實現。我們在對BPEL4WS系統建模的時候，在抽象出系統相應的用況之后，就要用協作來實現這些用況，用況就好比是一篇論文的前言，告訴了我們這篇論文是講什么的，而協作就是具體的內容。?

用況(Use?case):是對一組動作序列的描述，系統執行這些動作序列將產生一個對某個特定的參與者有特定價值的結果。我們利用用況來對BPEL4WS模型中的行為事物結構化，我們通常通過協作來實現某一個用況。如果想建立一個完善的BPEL4WS系統模型，用況可以說是至關重要的部分，因為所有的用戶需求我們都要在用況中體現出來，可以說用況是開發人員與用戶進行交互的窗戶，在系統的測試階段，測試用例的創建也要以用況為基礎，不論是BPEL4WS系統還是其他系統，用戶滿意度才是判斷這個系統是否成功的最重要的因素。?

主動類(Active?class):是這樣的一種特殊的類，其對象至少擁有一個進程或線程，并且它能夠啟動控制活動。主動類的對象所描述的元素的行為與其他元素的行為并發，除了這一點之外，它和類是一樣的。由于BPEL4WS流程本身就具有主動類的特征（每一個流程擁有自己的進程，并能自動啟動控制活動），所以我們可以把流程本身抽象成主動類。?

構件(Component):是整個系統中物理的、可替代的部件，它遵循且提供一組接口的實現。在一個系統中，你將遇到不同類型的部署構件，如?C?O?M?+構件和Java?Beans，以及在開發過程中所產生的制品構件，如源代碼文件。通常構件是一個描述了一些邏輯元素（如類、接口和協作）的物理包。對于構件在BPEL4WS系統中的使用，我們可以把每一個為我們提供Web服務的服務站點抽象成是一個特殊的"構件"，具體介紹在構件圖的介紹中說明。?

節點(Node):是在運行時存在的物理元素，它表示了一種可計算的資源，它通常至少有一些記憶能力和處理能力。一個構件集可以駐留在一個節點內，也可以從一個節點遷移到另一個節點。在一般的系統建模時，如在C/S模式的時候，節點往往就是客戶機和服務器；而在N-Tier模式時，也就是多層架構時，除了客戶機和服務器外，還要將應用服務器，也就是中間層建模為相應的節點。在BPEL4WS系統中，比較特殊的一點是我們應該將一個服務提供商抽象成是一個節點，在這個特殊的節點中提供了一系列的Web服務，更詳細的內容在實施圖的說明中介紹。?

<1.1.2>行為事物（Behavioral?thing）：是UML模型的動態部分。我們可以把它們看作是模型中的動詞，它們描述了系統中存在的行為動作。在利用UML對BPEL4WS系統進行建模時，共有兩類主要的行為事物可以供我們使用：?

交互(Interaction):是這樣一種行為，它由在特定語境中共同完成一定任務的一組對象之間交換的消息組成。一個對象群體的行為或單個操作的行為可以用一個交互來描述。交互涉及一些其他元素，包括消息、動作序列（由一個消息所引起行為）和鏈（對象間的連接）。?

狀態機(state?machine):是這樣一種行為，它描述了一個對象或一個交互在生命期內響應事件所經歷的狀態序列。單個類或一組類之間協作的行為可以用狀態機來描述。一個狀態機涉及到一些其他元素，包括狀態、轉換（從一個狀態到另一個狀態的流）、事件（觸發轉換的事物）和活動（對一個轉換的響應）。?

在這里，由于篇幅關系，只介紹了行為事務的基本概念，在我們對BPEL4WS系統建模的時候，對于行為事務的建模是體現在相應的系統圖模型中，這在下面的圖模型說明中會有介紹。?

<1.1.3>分組事物（Group?thing）：是UML模型的組織部分。它們一般是由整體系統分解下來的小的功能集合。在所有的分組事物中，最主要的分組事物是包，而在對BPEL4WS系統建模時我們利用最多的也是包。?

包(Package):是把元素組織成組的機制，這種機制具有多種用途。結構事物、行為事物甚至其他的分組事物都可以放進包內。包不像構件（僅在運行時存在），它純粹是概念上的（即它僅在開發時存在）。在BPEL4WS系統中，包的使用比較自由，我們可以根據自己的需要劃分系統中的各個部分，例如可以按外部Web服務的功能來劃分這些Web服務。?

(注：包是用來組織UML模型的基本分組事物。它也有變體，如框架、模型和子系統等（它們是包的不同種類）。在JAVA中已經直接支持了包的概念，而在C#中雖然沒有明確提出包的概念，但是C#中的命名空間概念實際上與包的概念是一致的)?

<1.1.4>注釋事物（Annotation?thing）：是UML模型的解釋部分。我們可以用注釋事物來描述、說明和標注整個UML模型中的任何元素。有一種最主要的注釋事物，我們稱為注解。?

注解(Note)：是一個依附于一個元素或一組元素之上，對它進行約束或解釋的簡單符號。注解可能是大家最容易忽視的部分，當我們編碼的時候，程序注釋的重要性我想大家都知道，而當我們對BPEL4WS系統或其他系統建模的時候，確容易忘掉為我們建立的系統模型元素加上詳細的注釋，對一個中小型系統來說，也許并不會有太大的危害，而對于一個復雜的系統模型來說，也許一時的偷懶會造成以后致命的潛伏的錯誤，所以寧可在建模時放慢進度也要爭取建立一個完備的系統模型，為以后的review和測試階段打下良好的基礎。?

<1.2>基本構造塊中的4種關系：

依賴（Dependency）：?
是兩個事物之間的一種語義關系，其中一個事物（獨立事物）發生變化會影響另一個事物（依賴事物）的語義。在BPEL4WS系統中，我們要善于挖掘系統中存在的依賴關系，如在BPEL4WS系統中，外部Web服務之間就可能存在著依賴關系。?

關聯（Association）：?
是一種結構關系，我們用它來描述一組鏈，鏈是對象之間的連接。不論是對BPEL4WS系統還是其他系統來說，關聯關系恐怕是我們在建模時用到的最多的一種關系，系統元素之間的關系如果不能明顯的由其他三類關系來表示，都可以抽象為關聯關系。?

(注：聚合是一種特殊類型的關聯，它描述了整體和部分間的結構關系)?

泛化（Generalization）：?
是一種特殊/一般關系，特殊元素（子元素）的對象可替代一般元素（父元素）的對象，也就是我們在面向對象學中常常提起的繼承。用這種方法，子元素共享了父元素的結構和行為。在BPEL4WS系統中，泛化關系的使用并沒有什么特殊的地方，只要注意能清楚明了地刻畫出系統相關元素之間所存在的繼承關系就行了。?

實現（Realization）：?
是UML元素之間的語義關系，其中的一個元素制定了由另一個元素保證執行的契約。在圖形上，我們可以把實現看作是泛化和依賴關系兩種圖形的結合體。?

在BPEL4WS系統中，一般來說，我們會在兩個地方需要使用實現關系，一是用在接口和實現它們的類或構件之間，另一種是用在用況和實現它們的協作之間，這些地方都是具有BPEL4WS系統特性的地方，大家在建模的時候要多加注意。?

<1.3>基本構造塊中的9種圖：

類圖（Class?diagram）：展現了一組對象、接口、協作和它們之間的關系。?
在對面向對象系統的建模中所建立的最常見的圖就是類圖。我們可以用類圖來給出系統的靜態設計視圖，我們可以通過主動類的類圖給出整個系統的靜態進程視圖。類圖恐怕是大家最熟悉使用的一種圖形了，因為自從有了面向對象的理論以后，類和類圖就成為最基礎的面向對象理論。在對BPEL4WS系統建模的時候，開始時最困難的部分可能就是識別系統中到底有哪些相關對象，也就是抽象出有哪些類，對于識別對象并抽象出類的方法，由于篇幅關系在這里就不詳細說了，大家可以參看清華大學出版的一本很有名的書《面向對象的分析》（邵維忠，楊芙清），很實用的教材。在這里要提醒大家注意的是，在BPEL4WS系統中，應該把所有的外部Web服務抽象成類（用版類Stereotype擴展過的），而對于流程本身，也應該抽象成類的概念，這樣所有BPEL4WS系統的元素都被抽象成類這種有固定形態特點的事物，這樣就為以后的系統動態分析打好了基礎。?

對象圖（Object?diagram）：展現了一組對象以及它們之間的關系。?
對象圖描述了在類圖中所建立的事物的實例的靜態快照。雖然對象圖也給出了系統的靜態設計視圖或者靜態進程視圖，但它們都是從真實的或原型案例的角度建立起來的。對于BPEL4WS系統的建模來說，對象圖并不是重點，因為過細致的對象圖會降低系統模型的抽象程度，這是不利于我們從更高的層次理解整個系統的架構和運作，但有的時候對象圖也是必不可少的，特別是當我們要表示出位于某個確定狀態的類對象之間的關系時。?

用況圖（Use?case?diagram）：展現了一組用況、參與者（一種特殊的類，可以為用戶或者是別的系統）及其它們之間的關系。?
我們通常利用用況圖給出整個系統的靜態用況視圖。這些圖對于系統的行為進行組織和建模是非常重要的。值得注意的是，在用況圖中，我們應該很好地利用用況之間的泛化關系，也就是繼承關系，這樣可以更清晰地把一個較復雜的商業用況劃分為幾個較簡單的用況（父用況和子用況），這對于我們在BPEL4WS系統中理解一些復雜的商業行為很有好處。?

順序圖（Sequence?diagram）：?
在系統中，順序圖是一種強調消息的時間順序的交互圖。對于BPEL4WS系統的建模來說，順序圖應該說是最重要的一種圖，雖然順序圖和協作圖是同構的，也就是說是可互相轉化的，但由于順序圖強調了時間上的概念，這與一個實際商業流程的運作是完全一致的，再加上BPEL4WS系統中所調用的各種外部Web服務在順序圖中可以很好的、形象的表現出來，所以當我們要對具體的商業流程建模的時候，順序圖是我們最好的選擇。?

協作圖（Collaboration?diagram）：?
協作圖也是一種交互圖，不過它主要強調了收發消息的對象的結構組織的交互圖。對于一般的系統建模（如MIS系統）來說，協作圖與順序圖是一樣重要的，而對于BPEL4WS系統來說，由于我們所關心的商業流程是有時間順序的，所以我們應該先考慮創建完備的順序圖，對于一些用順序圖表示不太適合的交互（如涉及到復雜的消息傳遞），我們可以用協作圖將其表示出來。?

(注：在這里，我要對交互圖作一些補充說明，首先，順序圖和協作圖都是交互圖，而且順序圖和協作圖是同構的，這也就意味著它們是可以相互轉換的。另外一點需要注意的事，我們在系統建模的時候應該使交互圖專注于整個系統的動態視圖，這是因為UML中的交互圖本質上展現了一種交互，而這種交互是由一組對象和它們之間的關系組成的，包括了在它們之間可能發送的消息)?

狀態圖（Statement?diagram）：展現了一個狀態機，它由狀態、轉換、事件和活動組成。?
狀態圖也主要專注于整個系統的動態視圖，系統的狀態圖對于接口，類或協作的行為建模尤為重要，而且它還強調了對象行為的時間順序，這一點是非常有助于對反應式系統建模的，也就是說對BPEL4WS系統建模來說是非常重要的（因為BPEL4WS系統實際上也帶有一部分反應式系統的特點）。在為BPEL4WS系統所建立的模型中，狀態圖最重要的用處就是為流程本身的狀態以及外部Web服務的狀態建模。隨著流程的運行，系統各個部分的狀態可能都會發生變化，我們一定要能捕捉到這些變化，并把這些變化體現在相應的狀態圖中。?

活動圖（Activity?diagram）：是一種特殊的狀態圖，它展現了在系統內從一個活動到另一個活動的流程。?
活動圖在專注于系統的動態視圖的同時，強調了對象間的控制流程，這對系統的功能建模特別的重要。在利用活動圖對BPEL4WS系統建模的時候我們要注意，最好能把商業流程中發生的一系列商業事件（如客戶身份認證，信用卡號認證等）以一一對應的關系對應到流程的活動圖中的每一個活動；如果有必要的話，再對每一個活動進行更深層次的分析，構建出每一個活動本身的交互圖和活動圖。?

構件圖（Component?diagram）：展現了一組構件之間的組織和依賴。?
對于構件圖，我們首先要知道的是構件圖不能反映出系統的動態特性，構件圖專注于描述系統的靜態實現視圖。在我們對任何一個系統建模時（當然包括BPEL4WS系統），構件圖不可避免的要與類圖相關聯，因此我們通常把構件映射成一個或多個類、接口或協作。對于一般的系統來說，大部分的構件都存放在本地系統上，我們可以從大體上把這些構件分為兩類，一類是"內部構件"，也就是自己開發的構件；另一類是"外部導入構件"，也就是通常所說的第三方構件，而對于BPEL4WS系統來說，由于它本身的特殊性（對外部Web服務的依賴性）決定了我們在建模時一定要用構件圖完整地體現出整個流程所涉及到的所有的外部Web服務以及本地提供的Web服務，我們可以把每一個為我們提供Web服務的服務站點抽象成是一個"構件"，而在這個特殊的"構件"中為我們提供了一系列的Web服務功能。?

實施圖（Deployment?diagram）：展現了對運行時處理節點以及其中的構件的配置。?
通過構造系統的實施圖，我們就可以構造出整個系統體系結構的靜態實施視圖。在我們對BPEL4WS系統建模的時候，實施圖往往都要與構件圖相關，通常在系統的每個節點中都包含一個或多個構件。我們可以擴展實施圖中節點的概念，在擴展出的新的節點的概念中，一個節點不一定就是一個處理節點，我們可以將一個服務提供商抽象成是一個節點，而一個服務提供商可能會為我們提供幾種不同的Web服務（即幾個不同的服務站點），那這些服務站點就可以被抽象為"構件"，這樣就可以很好的與構件圖結合起來對BPEL4WS系統建模。?

(注：?在對BPEL4WS系統建模時，并不限定僅使用這9種圖，但這9種圖在實際應用中是最常用也是最方便使用的)?

<二>規則

在對BPEL4WS系統建模的時候，我們不能簡單地把UML構造塊按隨機的方式放在一起。像任何語言一樣，UML有它自身的一套規則，這些規則描述了一個結構良好的模型看起來應該像什么。對于為BPEL4WS系統所構建的模型，我們要求這個模型應該在語義上是前后一致的，并且與所有的相關模型協調一致。在建模的時候，UML有用于描述如下事物的語義規則：?

命　　名：為事物、關系和圖起名。?

范　　圍：給一個名稱以特定含義的語境。?

可見性：怎樣讓其他人使用或看見名稱。?

完整性：事物如何正確、一致地相互聯系。?

執　　行：運行或模擬動態模型的含義是什么。?

值得注意的一點是，當我們對BPEL4WS系統進行建模時除了要建造一些結構良好的模型以外，我們在系統的開發期間所建造的模型往往需要發展變化，并可以由許多人員（所有的項目涉及人即Stakeholders）以不同的方式、在不同的時間進行觀察。由于這個原因，下述的情況是常見的，即我們不僅要建造一些結構良好的模型，也要建造一些這樣的臨時模型：?

省　　　略：隱藏某些元素以簡化視圖。?

不完全性：可以遺漏某些的元素。?

不一致性：不保證模型的完整性。?

在BPEL4WS系統開發的整個生命期內，隨著系統細節的展開和變動，不可避免地要出現這些不太規范的模型。但我們應該時刻牢記，我們的任務是專注于BPEL4WS系統中最重要的分析、設計和實現，而為了解決這些重要問題，將促使我們不斷地修改我們所建立的模型、完善我們所建立的模型，這樣隨著時間的推移和系統設計的深入，我們為BPEL4WS系統所建立的模型將具有更好的結構。?

?<三>公共機制

在UML中有4種貫穿整個語言且一致應用的公共機制，因此使得UML變得較為簡單；而特別值得我們注意的是，對于BPEL4WS系統的建模來說，這些機制顯得尤為的重要，如果沒有這些公共機制，我們是不可能構建出語義上完備的BPEL4WS系統的。這4種公共機制分別是：?

<3.17>詳述：在建模的過程中，我們利用UML的圖形表示發來對BPEL4WS系統進行可視化，利用UML的詳述來描述BPEL4WS系統的細節問題。在文章前面提到的注釋的問題實際上就是詳述機制的問題，一個完備的BPEL4WS系統不僅要包括完整的系統模型元素，還要有詳細的詳述才能稱得上是一個健壯的系統。?

<3.2>修飾：UML表示法中的每一個元素都有一個基本符號，可以把各種修飾細節加到這個符號上以擴展其含義。在BPEL4WS系統中，我們可以較自由的對系統中的各個元素進行修飾以擴充其含義，但要注意要保證這種擴充是在受控制的范圍中。?

<3.3>通用劃分：在對BPEL4WS系統建模時，我們可以采用兩種通用劃分的手段，一種是對類和對象的劃分（類是一個抽象，而對象是這種抽象的一個具體形式）；第二種是對接口和實現的分離（接口聲明了一個契約，而實現則表示了對該契約的具體實施，它負責如實地實現接口的完整語義）。?

<3.4>擴展機制：擴展機制是對已有的UML語義按不同系統的特點合理地進行擴展。?

UML擴展機制包括：?

<3.4.1>構造型（Stereo?type）：?
我們在對BPEL4WS系統建模的時候，會發現現有的UML構造塊不能完整無歧義地表示出BPEL4WS系統中的每一元素，因此我們可以利用構造型來擴展UML的詞匯，我們可以利用它來創造新的構造塊，這個新創造的構造塊既可以從現有的構造塊派生，又專門針對我們要解決的問題。?

<3.4.2>標記值（Tagged?value）：?
利用標記值，我們可以擴展UML構造塊的特性，我們可以根據我們的需要來創建詳述元素的新元素。?

<3.4.3>約束（Constraint）：?
如果我們需要對UML構造塊的語義進行擴展，我們就可以使用約束機制，這種機制使我們可以增加新的規則和修改現有的規則。?

(注：由于BPEL4WS系統本身所固有的特點，決定了在我們對其進行建模時不得不對UML中的一些部分進行擴展，但有一點我們必須要注意，那就是我們一定要讓我們對UML所作出的擴展保持在我們的控制范圍內，簡單的說就是我們只可以以受控的方式來進行擴展，而不能任意地、無限制地進行擴展，我們必須保證我們利用UML擴展機制對BPEL4WS系統所作的建?；顒邮强衫斫?、可控制的，如果任意地擴展，就會使我們在對系統進行建模的過程中偏離利用UML建模的真正目的--信息交流)?

給開發者的建議

"不積跬步無以至千里"，學習掌握UML的過程是一個漫長的過程，有時還會覺得有些乏味，但當你真真掌握了它并靈活的運用它在你的工作中的時候，你就會發現你不曾想到的樂趣?，F在UML2.0已經問世了，而BPEL4WS語言也有了新的版本，它們都添加了很多的新的東西，也去掉了一些舊的東西，但我相信本文的內容對于新的Specification來說也是同樣適用的，對于新技術新知識我覺得我們應該抱著一種積極的態度去學習和掌握它們，而不應該處于一種被動的狀態，越早行動起來就能越早的收到回報，千萬不要猶豫不決，就像《誰偷了我的奶酪》中說的那樣，讓我們都作一只敢于迎接變化的小老鼠吧！?

結束語

在本文中向讀者簡要介紹了有關如何有針對性的利用UML核心架構對BPEL4WS系統進行建模的問題。在下一篇文章中，我將會在簡要的介紹一些有關商業系統和商業流程的特點之后，為大家舉一個實際的例子(貫穿分析，設計和實現)來闡明有關利用BPEL4WS進行系統開發和商業流程架構時應注意的細節問題，例子可能不長，但會涵蓋UML中最重要的部分。?

參考資料?

BPEL4WS語言規范?v.1.1?
http://www.ibm.com/developerworks/library/ws-bpel/?

UML(Unified?Modeling?Language)語言規范?v.1.5?
http://www.omg.org/technology/documents/formal/uml.htm?

RUP(Rational?Unified?Process)語言規范?
http://www.rational.com/products/rup/index.jsp?

?