摘要：
軟件模式，特別是設計模式在現今的軟件開發中越來越重要。在許多的標准，工具，以及開發方法中都引入了模式的概念。本文介紹了如何在UML中對軟件模式進行建模，並結合具體的工具Rational XDE，對如何定義，如何應用模式作了詳細地介紹，並指出了一些相關的問題。
第一部分：模式的UML表示
1.1 軟件模式
軟件模式（Software Pattern）的概念由來已久，當初軟件業從建築業等其他的工程行業中汲取模式的概念，並把它演化成為軟件模式的時候，無疑的是軟件工程領域中一項革命的成果。而GoF對設計模式的分類與描述，更使得模式這一概念具體入微，能夠被成熟的應用在軟件開發之中。
所謂模式，簡單而言，是一種針對某一特定的，反復出現的問題的成功的解決方案。就問題本身而言，可以使任意領域和范疇的。在諸如建築，音樂，寫作，管理等等領域中，都有模式的概念存在。在軟件領域中，模式被以一種約定的文檔形式表現出來，以便於紀錄，學習和交流。經驗豐富的程序員，可以將他們的知識，通過模式這種更形式化的東西，傳遞給別人。因而，模式可以看作是一種具體化的，文檔化的經驗和知識。
在將近十年的時間裡，軟件模式的有了很大的發展，它不僅僅只是一種經驗的表達，現在已經能夠作為程序開發的一種驅動力了。模式驅動的軟件開發過程（Pattern Based Development），已經不是一種新事物。但是，在今天的軟件開發領域中，一個開發思想，或者過程，如果沒有一種強有力的工具支持，它就很難得到廣泛的應用。
軟件模式，就其抽象的級別，可以分為體系結構模式，設計模式和Idiom三種。
1、體系結構模式：提供對體系結構設計中所遇到的問題的解決方案。體系結構的例子包括有：Pipe-Filter模式，白板模式，MVC模式，ORB模式等等。體系結構模式並不一定是面向對象的，它的思想可以為任何開發方法所使用。因而，在利用UML進行描述的時候會有一些困難，而通常使用一些特定專有的描述方法，比如C2（Component-Connector）等。對它的工具支持比較的少，現在大多數尚處於研究階段。
2、設計模式：提供對面向對象的具體設計中的問題的解決方案，使得設計的結果更具有良好的可擴展性和重用性。通常所說的設計模式，是指的GoF一書中所分類的好了的23個模式。設計模式更具其設計功用，被分為構建型，結構型和行為型三類，包括橋接模式，工廠模式，組合模式等等。對這些模式的描述以及工具支持已經比較成熟。現在已經出現了一些支持設計模式的CASE工具，比如TogetherJ，Rational XDE等。其中以XDE對模式的支持最好。本文將在後面的文章中就XDE中的模式開發展開討論。
3、習慣用法（Idiom）：是針對具體語言的使用模式。主要涉及的問題是，如何用特定方法來解決程序代碼編寫過程中所遇到的問題，如何更優的編寫程序代碼。通常一種語言，比如Java，C++等，都會有相應的Idiom。這種模式的抽象層次比較低，且涉及到具體的語言，在這兒不予過多的討論。
1.2 UML的模式機制--協作，參數化協作
在早期的UML中，並沒有提供對模式的支持。而隨著模式的日益普及，OMG也終於在新版的UML引入了新的概念來提供對模式建模（主要是設計模式）的支持。
稍稍熟悉UML的人，會對協作圖（Collaboration Diagram）的非常地了解，協作圖是UML的9大視圖之一，主要用來提供對模型的動態描述。
而協作（Collaboration）的概念同協作圖其實並不太一樣。在面向對象的模型中，一個特定的行為，是由一組對象以及對象之間的消息傳遞來實現的。這種模型信息就是由協作來表示。協作描敘了在一定的語境中一組對象以及用以實現特定行為的這些對象之間的相互作用。它包含結構和行為兩個方面，結構方面與靜態視圖相似，包含一個對象（更為確切的說應該是角色）的集合和他們之間的關系。行為方面是一個消息的集合，這些消息在具有某一角色的各對象之間進行傳遞交換，也就是所謂的交互（Interaction）。協作的靜態方面可以用類圖來表示，協作圖實際上也給出了一些靜態的模型信息，而動態方面的描述通常使用順序圖（Sequence Diagram）或者協作圖來表示。
從這個角度來看，模式就是一種協作。對設計模式而言，它實質上描述的就是對象的結構以及對象之間的交互--並應用這樣的一種協作來解決某一個問題。在UML中，模式使用的是一種特殊的協作，參數化的協作（parameterized collaboration）來表示的。
在一個參數化的協作中，協作的參與者（比如類，也可以是關系等其它元素）可以是一個泛化的協作的參數。每當應用這個協作到一個具體的模型中去的時候，用具體的模型元素來替代這些參數。這樣，在這個協作中參數之間的關系就被固定在這個模型中了。雖然對設計模式而言，它包含了比協作更多的含義。但是這樣的一種參數化協作的建模方式，已經能夠描述模式大部分的語義信息。模式還可以包括使用背景，使用指導，以及使用後果等其他的描述，這些內容可以作為注釋寫在單獨的文本文件中。
在使用UML來對模式進行建模的時候，可以遵循如下的步驟：
1. 對一個重復出現的問題給出一種普遍的解決方案，並將其細化成一種機制。因為方案往往只是概念層次上的，要有具體的實現，才能夠稱其為模式。而普遍的含義更為重要，重復出現的問題，通常會有不同的問題背景，要在這些不同的背景中找出公共的問題域，也並不是一件容易的事情。
2. 在抽象出的問題域中，將上述的機制建模為一個協作，即包含了其靜態的結構和動態的交互的一個名稱空間，這可以看作是一種抽象，模式也就是這種抽象的產物。
3. 找出模式中必須要綁定到具體的應用中去的部分，將其建模為協作的參數。參數提供了對模式進行擴展以及實現的可能。正因為問題背景的復雜與不同，才需要具體的參數來訂制模式。
實際上對模式的捕捉以及實現，是一個很復雜的過程，已經超出了本文要討論的范疇，這兒給出的步驟，也不一定就能夠應用到所有的情況。這兒關注的是，如何用UML來表達一個模式的內容，下面來看一個例子。
1.3 一個例子
下面我們將試驗一個簡單的設計模式：命令（Command）模式，看如何將其用UML表示出來。並如何應用到一個具體的模型中去。這兒不再詳述命令模式的具體的語義，如果有不太熟悉的地方可以參考GoF的《設計模式》一書。
命令模式有如下的結構：
圖1：命令模式的結構類圖
我們將其每一個部分都看作是一個協作的參數，得到如下的一個參數化協作：
圖2：命令模式對應的參數化協作
或者，我們還可以用一個額外的順序圖來表示這個模式的動態行為：
圖3：命令模式的動態行為順序圖
我們再來看一看模式的的應用，在一個具體的模型中，比如說EJB的模型，假如設計需要使用命令模式來完成一個Command的EJB調用層（關於EJB中的命令模式，具體可以參見《EJB模式語言》一書，這而為了簡便起見，作了一些的簡化。）根據命令模式的語義，可以對模板參數作如下的綁定：
模板參數 綁定對象 Invoker Containerr Command Command（自動生成） ConcreteCommand ConcreteCommand（自動生成） Receiver Bean Context State State（自動生成） Client Remote
表一：命令模式到EJB模型的綁定
在UML中，模式的綁定表示為構造型為<<bind>>的依賴關系，從被綁定的協作指向模式所代表的參數話協作。可以可選的在依賴關系上給出綁定的結果。如下圖所示：
圖4：模式的綁定之一
可以用UML來表示具體的綁定結果：為了生成協作而綁定模式用虛線橢圓表示，橢圓中包含了模式的名稱；在從橢圓到每一個參與協作的類之間畫一條虛線，並在虛線上標明參數的名稱。
圖5：模式的綁定之二
綁定之後，模型中引入的命令模式的語義，得到這樣的一個結果：
圖6：綁定的結果
1.4 關於協作的一些後續話題
協作說明了眾多參與者之間的交互方式，而這些參與者，並不僅僅局限於類或者接口。它可以是一個類元或者鏈。實際上，在協作中的參與者，並非是類或者，接口，是一種新的建模元素，稱之為協作角色。協作角色代表了一個對象結構中的命名槽（slot），表示出在特定語境中的元素的行為。它並不表示實際存在的對象或者鏈，而是當協作實例化時，對象或者鏈被替代的位置。從這種意義上講，協作角色相當於一個函數中的參數。
一個類元也擁有具體的類型，比如說類，接口，或者子系統等等。就像函數調用時提供給其的參數值要滿足參數的類型一樣，在應用模式時，類元的類型也需要得到滿足。比如，你不能夠把一個接口類型的類元角色綁定到一個類上去。從傳統意義上的類或者接口，到協作中的協作角色，可以說是一種建模思想上的變化。角色這個詞，也很好的體現了這個概念。可以用它同電影中的角色進行類比，只要任何人，瞞住了角色所提出的要求（比如性別，年齡，演技，等等），都可以充當這個角色的扮演者。而角色並不是一個具體的對象，而是由一個對象來承擔。在這一點上，同Java中的接口的概念比較類似，但更為抽象。
協作角色包括類元角色和關聯角色。對這一點，後面還會提到，在XDE中，角色的概念已經被擴充，而不僅僅只是能標是類元或者關聯，而能夠表示任何合法的UML模型元素。比如屬性，方法，甚至視圖。這樣，模式的表達能力被大大地增強了，模式也能夠擁有更為豐富的語義。
在後續的系列中，我們會使用Rational公司最新的XDE工具來實現對模式的建模與使用。XDE是最新的集建模與編碼於一體的IDE，在很大程度上代表了今後IDE的發展方向，它所提供的強大的模式機制，能夠將UML中對模式的建模能力，現實的轉化為提高軟件生產率的有效工具。讓我們在下一期的系列文章中再見吧。
