複雜軟件驅動系統的UCM與UML

複雜軟件驅動系統的UCM與UML

複雜軟件驅動系統有許多類型，包括面向對象、基於代理、實時和分佈式系統。它們具備許多屬性，例如大規模、協同性、分散控制、及時性、可靠性、變化無窮及特點豐富的功能、運行時組織的流暢性，以及系統的升級需求等，這些屬性使得它們不管從技術仍是從管理複雜性的角度來看都是難以理解的。這些複雜系統常常被用於電信、防衛、宇航和工業控制等領域。

UML（統一建模語言）是一種通用目的建模語言，它可用於詳細說明和構造軟件系統（特別是面向對象和基於組件的系統）工件並使其可視化與文檔化，也可用於商業建模和非軟件系統。它包括用於各類模型描述與文檔化的許多概念和表示符，而且擁有技術和工業團體的堅決支持。

做爲UML的重要特點，用例（Use Case）被定義爲某一特定用戶（執行者）看得見具體結果的系統運行動做序列。在過去幾年中，用於腳本和用例的各類表示法，以及基於它們的設計過程已經很是流行了。例如，「Rational統一過程」就是一種用例驅動的（Use-case driven）基於UML的方法學。在這種方法中，用例將5類模型（需求、分析、設計、實現和測試）捆綁在一塊兒，這種模型描述了系統的局部表示。UML 1.3容許使用9種不一樣的圖描述複雜軟件驅動系統及其模型，每一種圖提供了特定角度的模型觀點，每一種圖在語義上必須與全部其餘圖一致。本文中，這些圖被分爲兩類。第1類稱爲「行爲圖」（Behavioral diagram），主要着眼於系統的功能和動態方面，它由以下5種類型的UML圖組成。

① 用例圖（Use case diagram）：展現了執行者、用例以及彼此之間的關係，以用戶的觀點描述系統功能。

② 順序圖（Sequence diagram）：描述了對象之間按先後次序排列的交互模型，它來源於信息序列流程圖。

③ 合做圖（Collaboration diagram）：展現了系統的整體結構和交互行爲。

④ 狀態圖（Statechart diagram）：展現了特定內容的狀態空間、引發狀態變化的事件，以及產生這種結果的動做等。

⑤ 活動圖（Activity diagram）：從操做方面捕捉系統的動態行爲，着眼於內部進程驅動的流程。

第2類稱爲「結構圖」（Structural diagram），與系統構件及靜態特徵有較大關係，它包含以下4類UML圖。

① 類圖（Class diagram）：捕捉系統的詞彙表，展現了系統的各類實體及其之間的整體關係。

② 對象圖（Object diagram）：一個運行系統的「快照」，展現了特定時刻的各類對象實例（帶有數據值）及其之間的整體關係。

③ 構件圖（Component diagram）：展現了軟件構件之間的依賴性。

④ 配置圖（Deployment diagram）：展現了運行時刻進程元素的結構及其與之相伴的軟件構件、進程和對象。

UML包含了兩類圖之間的幾種隱含的鏈接（例如，順序圖和合做圖可使用類圖中定義的實體），但UML並無強調許多系統構件協同工做（例如，跨越網絡的事務處理）時出現的大規模行爲單元的首要的和緊密的描述方式。

本文描述了一種稱爲「用例映射圖」（Use Case Map，UCM）的製圖技術，做爲一種之外在且以可視方式鏈接行爲與結構的手段。UCM是第一流的架構實體，它描述了捆綁到底層且以組織化的抽象構件結構的各類職能（responsibility）之間的因果關係。本文試圖圖解UCM如何幫助在用例模型中的用例和分析設計模型中的其餘行爲圖（順序圖、狀態圖和活動圖）之間的概念缺口上搭建橋樑。UCM還提供了從行爲圖中的各類活動到結構圖中的各類構件（及對象）組織之間的鳥瞰圖，這將使貫穿系統設計發展全過程的架構推導成爲可能。

1.4.1  用例映射圖

1．基本表示法

UCM用於強調一個系統的最實質、最引人注目且最關鍵的功能，沿因果路徑的各類職能能夠是某一構件內部，或者外部可見的。UCM能夠表現特定的腳本，也能夠被抽象，而且能夠覆蓋多個腳本實例。使用UCM時，腳本創建在構件間消息交換的上層，因此它們沒必要捆綁到特定的組織結構上。UCM提供了以路徑爲中心的系統功能視圖，而且提升了腳本可重用性的級別。

圖1-25所示爲一個簡單的UCM。

圖1-25  一個簡單的UCM

其中，一個用戶（Alice）試圖經過代理網絡創建與另外一個用戶（Bob）之間的電話呼叫。每一個用戶有一個代理負責管理預訂的電話功能，如源呼叫屏蔽（OCS）。Alice首先經過其代理向網絡發出鏈接請求（req），這一請求引發被呼代理檢查（vrfy）被呼當事人是「空閒」仍是「忙」（圖中的「條件」是斜體）。假如空閒，一些狀態將被更新（upd）。在Bob一方，振鈴信號將被激活；不然一個聲明Bob沒法通話的消息將準備好（mb）並被回送給Alice（msg）。

腳本以一個觸發事件和（或）一個初始條件（標號req的實心圓）開始，以一個或多個結束事件和（或）後繼條件（槓）結束（在咱們的例子中是ring或msg）。咱們將鏈接緣由與結果的路徑稱爲「路由」（route），中間的各類職能（vrfy、upd和mb）沿此路徑被激活。能夠將職能看作任務或者是被執行的計算功能。在這個例子中，各類職能被分配到不一樣的抽象構件中（Alice、Agent A、Bob和Agent B等盒子），這些構件能夠看作對象、進程、代理、數據庫，甚至能夠看作角色、執行者或人。咱們將這種疊加圖稱爲「約束圖」（bound map）。

UCM的構造能夠用多種方式完成，例如，開始能夠肯定各類職能（圖1-25（a）），雖然在一個如此簡單的圖中是沒必要要的。而後將這些職能分配給腳本（圖1-25（b））或構件（圖1-25（c））。構件能夠沿路徑發現。最後，兩個視圖合併造成約束圖（圖1-25（d））。

圖1-25是一個至關簡單的圖，但它以一種緊湊的形式傳遞了大量的信息，而且容許需求工程師和設計者使用二維信息（結構和行爲）選擇其系統架構。

2．附加表示法

爲了進一步介紹UCM的符號元素，能夠在這個基本用例中增長几項新功能。

圖1-26所示由圖1-25中介紹的實例抽象而來，構件再也不涉及Bob和Ａlice，而是更爲通常的主叫方和被叫方（不管用戶仍是代理）。虛的構件稱爲「槽」（Slot），能夠由不一樣時刻的不一樣實例來填充，這些實例能夠扮演構件的某一特定類的角色。下面的例子僅僅提供幾點直覺的說明，此處所涉及的構件的天然屬性實際上與本論文強調的UCM特性並不矛盾。

圖1-26  更復雜的調用鏈接和新的符號

圖1-26的中部展現了圖1-25（d）中UCM的加強版，它表現了與用例實例有關的整個類。這種UCM稱爲「根圖」，由於它擁有一些含有各類子圖（稱爲「插件」）的「容器」（稱爲「樁」），樁有以下兩種。

① 靜態樁：表現爲一個普通的菱形（見ST樁），它們僅包含一個插件程序，所以容許複雜圖的層次分解。

② 動態樁：表現爲一個虛的菱形（見SO樁），它們可能包含多個插件程序，運用時根據選擇方針（一般用預設條件描述）肯定具體選擇。也可能同時順序或並行地選擇多個，儘管這樣須要UCM圖以外的更詳細的說明。

輸入和輸出樁的路徑段已經在根圖中標明（斜體標號），雖然它們並不要求以可視的方式顯示，但其存在有助於完成插件與樁的明確連接。例如，主叫方的SO樁有兩個插件（ORIGINATING和OCS）。ORIGINATING插件的起點in1鏈接到輸入路徑段in1，終點out1鏈接到輸出路徑out1。爲了顯示插件和樁之間的清楚的連接關係，圖1-26使用了類似的標號。但在一般狀況下，名字是不一樣的，而且這種關係必須明確描述。

OCS插件顯示了一個新的構件（被動對象OCSlist），它表現爲一個屏蔽號碼列表，這些號碼禁止主叫用戶（UserO）接通。假如UserO預訂了源呼叫屏蔽服務，則選擇OCS插件代替ORIGINATING插件。在這種狀況下，將檢查被呼號碼是否在屏蔽列表之中（chk）。若是呼叫被拒絕，相應的消息被送回主叫方（md）。

TERMINATING插件在原來的UCM的基礎上作了一些改進，在被叫方更新（upd）和振鈴的同時，返回主叫方一個回鈴信號（mrb），此處用一個AND分支表示併發性。在UCM表示法中，選擇性路徑（如同TERMINATING插件中的OR分支和OR鏈接）、併發性路徑（AND分支和AND鏈接）、職能共享、例外路徑、計時、故障點、錯誤處理，以及路徑之間的同步／異步交互做用等都有相應的命名，除了個別元素以外。

經過在集成視圖中爲樁選擇插件，咱們能夠獲得一張展開圖，它依然包含多種可能的頭尾相接的腳本。一旦樁被定義爲路徑上的一個關鍵點，很容易加入新的插件，這些插件在咱們的例子中體現了新的功能。現有的圖和插件能夠進一步分解或使用新的路徑及新的靜態樁和動態樁進行進行擴張（例如，當加入一個徹底不一樣的服務時）。

3．拼版中的UCM和用例

UML用例定義爲用例實例的集合，而用例實例則是某一特定執行者看得見具體結果的系統運行動做序列。用例一般以普通文本的方式描述，雖然有時這種表示法能夠被活動圖、狀態圖、預設條件或後置條件等其餘行爲描述技術所替代。當描述系統和有關的外部執行者之間的交互做用時，用例一般將系統看作內部不可見的黑盒子。因爲用例的實現過程體如今行爲圖中，而在行爲圖中系統內核被提煉爲子構件，所以在用例與實現之間存在一個大的概念缺口。使用現行的UML圖去研究這麼一個缺口和這麼大的一個圖片常常令人迷惑，由於將不一樣類型的許多圖中的許多詳細資料集成在一塊兒須要很高的智力。

圖1-27所示爲現行UML拼版的各塊，而UCM正是缺乏的那塊。有了UCM，再也不必須將其餘塊合在一塊兒，而且再也不必須理解這麼一張大圖。UCM並不只僅被看作是一個附加步驟，更重要的是，它能夠追蹤從着眼於系統行爲的用例（黑盒）到最終着眼於構件行爲的更詳細的行爲圖（玻璃盒）的足跡，所以能夠看作一個合理的「灰盒」（gray box），咱們使用灰盒這一術語表示某些設計信息是可見的。

另外，UCM表示法還包含一些表達動態情形的功能，它可以以一種緊湊的方式描述整個系統。首先，構件的動態組織能夠從代碼結構和配置方面抽象出來，用樁、構件池和系統級的動態職能（本節不討論）來表示；其次，隨時間變化的腳本模型能夠用樁和插件表示，如圖1-26所示。

本文並未宣稱使用現行的UML圖和過程在上述概念缺口上搭建橋樑或表示動態情形是不可能的，可是UCM在解決這一迷團使大型圖片可視化方面彷佛具備獨特的優點。下一節進一步圖解UCM中與現有UML圖有關的幾種優點。

圖1-27  UCM做爲一個迷宮的缺乏部分

1.4.2  UCM和行爲圖

本節說明UCM和行爲圖。

1．UCM和用例圖

用例圖顯示了角色、用例及其關係，它們主要致力於捕捉用例模型中的功能需求或現有功能，但也可用於其餘類型的模型。

UML用例是黑盒描述，而UCM更相似灰盒，由於它顯示了系統的某些細節（例如，抽象構件的拓撲結構和動做的內部流程等）。和用例同樣，UCM與系統外部角色通訊（尤爲在起點和終點）時使用信號、事例和消息。當UCM與系統內部元素通訊時，可能使用其餘通訊語義。在這一抽象級別上，不會過早地作出系統詳細設計的決定，這一決定要留給使用更恰當的表示法（例如順序圖）的其餘模型。

UML用例圖能夠得到用例之間的3類關係，即包含關係、擴展關係和概括關係。UCM表示法在此基礎上作了很大的擴展，它以一種緊湊的方式，全面展現了用例及其關係。

① 包含關係：經過隔離和封裝複雜的細節（以便使用例的實際意義明顯化）和提升一致性（經過分解包含在幾個基用例之中的行爲）的方法幫助闡明一個用例。

在基用例路徑上放置一個靜態樁，便可實現包含關係。這個樁將其細節隱含在其插件中（內含用例），而這個插件能夠在多個樁中重用，所以改進了UCM的一致性。包含點的位置在路徑上以可視的方式表述，許多靜態樁能夠用於表現多種包含。例如，圖1-26中的ST樁和TERMINATING。

② 擴展關係：擴展的目標是代表一個用例的某一部分是（潛在）可選擇的，即在必定條件（有時是異常條件）下才執行一個子流程。或者有一系列的行爲段，其中一個或幾個能夠插入基用例中的擴展點。

這種關係在UCM術語中用OR分支表示，可能有多於兩個的選擇，OCS插件的拒絕路徑和TERMINATING插件的忙路徑（圖1-26）都是其各自基用例的擴展。UCM可以使用路徑標籤、顏色、陰影和加粗等可視化標誌強調原始的基用例（以區分來自可選或異常事件的基本流程）；不然會迷失在繁亂的圖中。舉個例子，OCS插件的許可路徑（粗線）表明基用例，而拒絕路徑則是一個擴展。UCM表示法還爲異常的、超時的和錯誤處理的路徑提供了其餘可視化標識。

動態樁展現了擴展關係的另外一層次，這種樁可能有一個默認的行爲（一個一般包含空路徑的插件），它能夠被其餘插件覆蓋。選擇某一非默認插件的條件在選擇方針中描述，例如，圖1-26中SO樁有一個默認插件（ORIGINATING）。當預訂者的OCS功能被激活時，OCS插件取代了默認插件。

UML用例明肯定義了其餘行爲能夠插入的擴展點，UCM中無此概念。由於任何路徑段都是潛在的擴展（例如，一個OR分類）的隱含擴展點，而對於動態樁來講則是外在的擴展點。

③ 概括關係：當兩個或多個用例在行爲、結構和目的方面有共同點時，其共享部分隨即又可描述爲這些子用例所專用的父用例。

擁有公共段和公共目標的各類UCM腳本能夠被集成爲OR分支和OR鏈接的結合體，或者更有可能被概括爲一個多分支動態樁。父UCM表明了原來用例圖中的公共部分，它包含一些擁有行爲分支（插件）的動態樁。子UCM被父UCM所構造，而其樁被適當的插件所佔據。可是從多個父UCM生成子UCM（多重繼承）時，在定義插件及子UCM做用這些插件的方式以前，須要先將各個父UCM集成。

做爲一個例子，一個基本呼叫的UCM能夠看作是圖1-26中根圖的簡化版。其中默認的 ORIGINATING插件佔據了SO樁，而TERMINATING佔據了ST樁，但一個OCS呼叫將在SO樁中使用OCS插件。不管是基本調用仍是OCS調用，都是其父UCM（根圖）的子UCM，父UCM的結構和行爲已被子UCM繼承和修改。

2．UCM和交互圖

UML定義了兩類交互圖，其中順序圖顯示了觸發事件沿縱向時間軸（稱爲「生命線」）的外在順序，比較適合於實時說明和複雜腳本；合做圖顯示了實例之間的關係，有助於理解一個給定實例的全部做用和程序設計。它們在本質上包含了相似的概念，但以不一樣方式表達。這一節主要着眼於順序圖。

UCM可以幫助從（用例模型中的）用例獲得（分析和設計模型中的）交互做用圖。UCM並無明肯定義構件之間的消息交換，但消息的構造應使得來自不一樣構件的職能之間的因果關係明確化。構造消息一般有多種方式，依賴於所用的接口、信道和協議。

圖1-25（d）中UCM抽象而來的基用例的因果關係路徑<req，vrfy，upd，ring>，能夠做爲一個例子。如圖1-28所示，這一順序圖被連接到相同的構造層，咱們所加入的明確的信道（線）約束了每一消息的潛在發送者與接收者，關於協議與控制的不一樣決定能夠致使多種解決方案。

圖1-28（b）所示爲4個併發實體經過簡單協議通訊產生直接信息交換的狀況。可是假如兩個代理之間使用了更復雜的協議（例如協商協議）而且這一控制被認爲是有差異的，那麼就應該採納圖1-28（c）中的源自相同因果關係路徑的順序圖。哪一個圖是最適當的依賴於設計決定，這一決定並不在UCM級別上作出，它須要在具備進一步追蹤能力的適當模型中以文檔形式表現出來。

圖1-28  從UCM路徑中產生的順序圖

3．UCM和狀態圖

「狀態機」形式上是Harel狀態圖的基於對象的變種，它混合了ROOMchart中定義的多個相似概念，也可看作ROOM建模語言的狀態圖的一個變種。

有了狀態圖，焦點直接轉到了構件行爲。UCM並不替換這些圖，但能夠指導其構造。UCM腳本中的路徑段（可能不少）被鏈接到一個構件，這個構件須要被集成化以便肯定其邏輯和狀態。與此同時，覆蓋不一樣構件職能之間的因果關係路徑的綜合需求被提煉爲消息交換的形式，穿越構件邊界的路徑段也能夠幫助描述構件接口。狀態可能被類圖中定義（也多是獨立定義）的可利用的對象類所影響，須要在UCM的抽象構件和構造狀態機的對象、進程和模塊之間創建一種映射。此外，這一綜合過程能夠致使許多有效的解決方案，所以設計決定須要在適當模型中被激發（可能被UCM以外的需求）而且要以文檔的形式表現出來。

圖1-29（a）所示爲從圖1-25（d）穿越構件Agent B 的UCM路徑，圖1-29（b）所示爲這一路徑的潛在狀態圖。其中職能、保護信息和消息已經分別被映射到狀態、條件轉換和正常轉換。這一特定的例子假定代理有本身的線程，而且在一開始就等待一個特定消息。很明顯，不一樣的假定和需求將致使不一樣的狀態圖。

圖1-29  由UCM路徑產生的狀態圖

從UCM路徑到狀態圖的映射並不老是直接的，例如，圖1-26的構件將要求更復雜的狀態圖，以便集成多種插件（Agent 0）、集成多種路徑起點和終點（Agent O）而且覆蓋併發性路徑（Agent T）。

直接從UCM產生狀態機要邁出很大的步伐，常常用順序圖做爲中間步驟。在順序圖這一級別，將作出與提煉構件之間因果關係有關的決定，狀態機還須要集成這些順序圖以便覆蓋每一個構件所扮演的不一樣角色。

4．UCM和活動圖

活動圖是狀態圖的特殊情形，它着眼於內部進程驅動的流程（相對於普通狀態圖中的外部事件）。所以從本質上說，它表明了一個過程或一個商業工做流的狀態機。活動圖更強調動做順序和條件，而不是執行動做的構件。

活動圖享有UCM的許多概念，甚至享有它的多個表示符。UCM中的「職能」相似於「活動」，兩種表示法都支持動做序列、可選擇性和併發性，起點和終點也有相似的用途。

一個複雜的活動能夠被提煉出來成爲另外一個活動圖，正如UCM使用樁進行路徑分解同樣，但樁彷佛更通用。樁容許多個輸入和輸出路徑，並且動態樁還准許使用基於某種選擇方針的許多插件。在表示複雜系統的動態行爲和結構時，UCM的樁被證實是一個很是有用的創造。

UCM的優點之一體如今職能與構件之間的鏈接能力，活動圖一般並不以這種方式使用，雖然它支持兩者之間的有限程度的映射。活動圖能夠被可視地化分爲「泳道」，每條泳道與其相鄰的泳道被其兩邊的縱向實線分離。每一泳道表明了所有活動中的其中一部分職能，最終可由一個或多個對象實現。每一個動做被分配到一個泳道。「轉移」可能會跨泳道，但轉移路徑的路由並不明顯。泳道可用最簡單的形式解釋爲構件，它們是一維的，而且不以任何方式（例如，根據其相關位置或真實屬性）顯示構件之間的關係。UCM提供了包含這一信息的集成化鳥瞰圖，這一鳥瞰圖對於理解表現爲路徑和（動態）職能的行爲如何影響和修改動態系統中構件的運行結構，幾乎是必須的。

1.4.3  UCM和結構圖

本節說明UCM和結構圖。

1．UCM和基於構件的圖

一個UML構件圖是一個被依賴關係所鏈接的各類構件的圖，某些構件也可能以物理包含的方式鏈接到另一些構件，這種物理包含體現了構件之間的複合關係。UML配置圖顯示了運行進程元素的結構和軟件構件、進程，以及與其相關的對象。UML對象圖呈現了運行系統的「快照」，由於它展現了某一特定時刻的對象實例及其關係。

默認的UCM構件表示法，如同Buhr和Casselman在中所定義的那樣，具備高度的歸納性，它可以展示這3類UML結構圖中所發現的許多重要特點。它們能夠圖解包含關係和其餘不一樣類型的（被動或主動等）依賴關係，甚至能夠展現運行時刻的實例（無數據）。可是，UCM的主要優點在於它具備以靜態圖的方式描述動態結構的能力。藉助於樁、構件池，以及具備動態職能的UCM路徑，構件可被創造或撤銷，能夠四處移動，可讓其餘構件看到等，帶有這種構件的UCM能夠用一種外表靜態和簡練的方式表示複雜的動態結果。若是沒有UCM，則須要用UML基於構件的圖的許多快照來表述。

在UCM路徑下，咱們並不阻止其餘結構化表述。這種路徑能夠用在幾類基於構件的圖的頂部，如同在UML或相似的表示法中同樣。

2．使用UCM推導架構

UCM可經過功能（用例）和形式（結構）的鏈接進行架構選擇的早期評估。經過在結構中減弱功能的方法，咱們能夠將功能與形式同時或者分別考慮。前面的UCM圖圖解了相同構件結構的不一樣路徑，UCM還容許咱們重用不一樣的可選結構中的相同路徑。例如圖1-30與圖1-28（a）同樣重用了相同的因果路徑，可是在不一樣的構件集上。此處沒有涉及通訊代理，而是採用不一樣的依賴機制（例如通訊鏈接）將職能分配給更加傳統的電話構件，如開關和服務節點（SN）。這將依次導向另外一個不一樣集合的有效順序圖和不一樣的狀態機，從而進一步延續設計週期。

圖1-30  由UCM路徑產生的順序圖

因爲UCM路徑可以很容易地從結構中減弱，從而改進腳本的可重用性，而且導向行爲模型，這種模型能夠用於普遍的應用軟件。在許多場合，UCM能夠提供有幫助性的可視模型。它能夠觸發關於系統問題的思考和討論，而且能夠被重用。

還應注意到架構選擇的評估是在抽象高層進行的，並無如同在順序圖中那樣關於消息與協議的任何早期約定。當潛在的結構被修改時，修改順序圖須要付出更多的努力並可能形成浪費。

架構推導還需處理系統需求的改進，複雜系統不多由草圖創建；相反它們是經過不斷接收新技術和新功能而不斷改進的。正如Velthuijsen描述的那樣，新功能的增長並非單調的，它們可以而且將要改變現有功能的操做，新技術也可以改變一些基於功能的假定。UCM提供了處理系統改進的非單調特性的一種機制（例如樁和插件），並且還展現了實踐中UCM如何辨別「分解」（例如小規模對象、線程、進程、模塊和包等）和「分層」（例如操做系統、信息棧和網絡中間件等），這兩種體系概念的區分能夠幫助提升處理系統的可升級性和可維護性。

1.4.4  討論

1．UCM的語義和工具

UCM的語義和良好的規則是以超圖的方式定義的。XML中所表示的UCM文本的線性形式，一樣已經被定義，這種形式適合於不一樣工具的輸入和文檔的生成。有了XML文檔類型定義，UCM與即將制定的UML標準能夠很容易地集成，這些標準包括XML元數據交換（XML）和UML交換格式（UXF）等。

UCM導航器（一個構造和編輯UCM的工具）使用超圖語義和規則提供可靠的轉換以確保構造正確的圖，這個工具支持路徑表示和Bahr的構件表示，而且使用XML形式做爲文件格式。它可用來產生嵌套的樁和插件，能夠很容易地將職能鏈接到構件。並支持代理系統和表演模型的擴展表示，可生成支持PDF的PostScript文檔。這個工具可用於3種平臺（Linux、Solaris 和HP-UX）。

2．UCM用於正式確認及驗證

雖然UCM擁有半正式的語義，但可以指導爲複雜系統生成更正式的模型和詳細說明。最近幾年，圍繞着從UCM引出LOTOS詳細說明的問題，已經作了大量工做。LOTOS是一種代數語言，它甚至能夠在缺乏構件結構的狀況下使UCM中發現的事件序列正規化。於是容許需求、規格說明與設計的正式確認及驗證，其中的某些內容正是許多面向對象的CASE工具所缺乏的。其餘目標形式包括ROOM，不久還將包括SDL。還應注意，如何使用ROOM模型實現LOTOS詳細說明，這一工做近來還在進行。

UCM當前被用於幾類工程，其中的一些工程處理與動態代理有關的問題（在描述複雜的代理關係時，UCM被證實是強大的）、電話間不受歡迎的交互行爲的探測與避免、功能測試組件的生成，以及日益涌現的移動電話服務標準的描述等。

創建執行模型是UCM的另外一應用，在有關文獻中，執行變成了路徑的一種屬性。而不是一般想像的那樣，做爲整個系統的一種非功能屬性。擴展的UCM表示法包含了時間戳記、時間的約束、事件分配，以及設備進程與任務的聯合等，不管是XML生成器，仍是UCM導航器都支持這些擴展。有關其餘類型的非功能需求的集成化問題，也在研究之中。

3．UCM和UML的集成

UML的應用很是普遍，但通常不能有擴展，由於這些擴展可能不被廣泛理解、支持和贊成。UML配置文件（profile）提供了在特定領域使用UML，而無須擴展或修改UML的標準使用方式。配置文件是一個預約義的集合，其中包括常規、標記值、約束和表示圖標等，它們共同剪裁UML使其專用於某一特定領域或過程（例如，對象過程模板和商業工程模板）。一個配置文件並不增長新的基本概念以擴展UML；與此相反，它使標準的UML專用於某一特定環境或領域。

在UML中集成了UCM的概念，便可經過剪裁適當的配置文件實現某些擴展。雖然這樣並不要求對UML標準作任何修改，但有許多最引人注目的UCM概念，很難被現行的UML圖和語義所覆蓋。

在UML圖集中增長UCM表示法是另外一種顯而易見的選擇，這種方法雖然看起來簡單合理，但也所以增長了冗餘，而在一個稍微大一點的UML圖中就存在一些冗餘。

擴展示有的製圖技術（例如活動圖）和語義，支持新穎的UCM概念，能夠認爲是第3種選擇。

最後，使用UCM替換（或改編）一個或多個UML圖，也被考慮爲一個潛在的選擇。但因爲當前標準和工具的現有投資，這種方法實現起來是很困難的。

最好和最適當的選擇仍然是一個研究話題，然而獨立於具體選擇方式的UCM概念的標準化的實現彷佛是很是重要的。假如這種標準化可以在不遠的將來產生，UML一定是一個傑出的候選者。

1.4.5  小結

UCM與現有的UML製圖技術密切相關，但它幫助填補了用例和行爲圖之間的概念性（灰盒）缺口。UCM還展現了關於架構推導的一種引人注目的觀點，它尤爲適合於複雜和動態的軟件驅動系統。在這種系統中，行爲從多個構件中不斷涌現，一般很難使其可視化。

這篇論文圖解了關於UCM表示法與運用的一些最重要的概念，雖然UCM也容許人們獨立運用行爲圖和狀態圖，但它在系統級上爲兩者創建了一種有用的鏈接。經過使用樁、插件和動態構件，UCM在設計週期的早期推動了架構推導。未被鏈接的UCM路徑成爲可重用的腳本模型，它能夠鏈接到多個底層構件的結構中。雖然UCM定義在比消息交換更高的抽象級別上，但它能夠指導生成詳細的圖（例如，順序圖和狀態圖），甚至生成正式的詳細說明。

UCM表示法能夠從UCM的許多要領中獲益，並已普遍應用於不一樣的工程，因此變得更穩定、更健壯。UCM工具開始涌現，UCM用戶羣已初具規模。做爲UML拼版中最佳位置的那一塊，UCM仍然有待進一步闡明。

致謝

筆者很是感謝Ray Buhr和Luigi Logrippo在過去6年中關於UCM的大量討論，很是感謝Tom Gray和Darcy Quesnel對於早期草案所提出的有用建議。本研究工做獲得了FCAR、NSERC和CITO的部分支持。

筆者很是感謝個人導師——西安交通大學鄧良鬆教授的精心指導與熱情幫助。

（《中國系統分析員》2003年第3期  殷建民）