專家教你如何使用模式集成UML視圖
本節(jié)向大家介紹一下使用模式集成UML視圖方面的知識，主要包括視圖和模型，試圖集成框架等內(nèi)容，希望通過本節(jié)的學(xué)習(xí)你能夠掌握使用模式集成UML視圖的方法。下面是具體介紹。
使用模式集成UML視圖
模式在系統(tǒng)組合（合成）期間對養(yǎng)成重用可重復(fù)設(shè)計和體系結(jié)構(gòu)配置的習(xí)慣很重要。本論文研究關(guān)于模式的知識，它也可用于系統(tǒng)分析檢驗系統(tǒng)模型的完整性。為了支持自動分析過程，該工作引入一個視圖集成框架。自從每個視圖（例如，框圖）增加一個額外針對模型的軟件系統(tǒng)觀點，來自一個視圖的信息可能用于驗證其它視圖的完整性。這種形式的集成要求對視圖表明什么以及它們可以共享（或約束）什么信息有更深的理解。因此關(guān)于模式在結(jié)構(gòu)和行為上的知識，也是一個用于視圖集成自動化的有價值的來源。
介紹
為支持軟件產(chǎn)品開發(fā)，我們頻繁使用通用軟件開發(fā)模型（和工具），例如統(tǒng)一建模語言(UML)。然而，通常意義的軟件開發(fā)和特定的軟件設(shè)計（正是我們工作的主要焦點）要求不僅僅是大多數(shù)通用模型所能提供的內(nèi)容。體系構(gòu)造是關(guān)于：
1) 對實際問題充分建模
2) 解決模型問題并
3) 在現(xiàn)實世界中解釋模型方案
這樣做的主要重點被置于體系結(jié)構(gòu)的視圖（例如框圖）內(nèi)和之間不匹配的鑒別與調(diào)和上。我們經(jīng)常發(fā)現(xiàn)這方面的情況，分析和（體系結(jié)構(gòu)的）說明的解釋在大多數(shù)通用語言中是次重點的。我們構(gòu)造體系不僅僅是因為我們想建立（創(chuàng)作），而且因為我們要理解。這樣，體系構(gòu)造有許多分析和校驗產(chǎn)品模型的概念完整性、一致性和徹底性的工作要完成。
已完全成為事實上OO軟件開發(fā)標(biāo)準(zhǔn)的UML的出現(xiàn)，在這個問題上也沒有任何例外。本工作闡述在UML視圖中體系結(jié)構(gòu)不匹配的原因，以及說明模式和集成技術(shù)怎么能夠以更自動化的方式應(yīng)用于識別并解決他們。為了做到這一點，本工作討論視圖集成框架，它的主要活動――映射（Mapping）、變換(Transformation)和分化(Differentiation)。
本論文將研究模式的角色，而不是集中于大量的集成技術(shù)（它們支持上述活動）。這樣，我們將研究模式的知識怎樣有助于保證軟件系統(tǒng)模型一致性。通過那樣，我們按以往很少使用的方式利用模式：我們用模式用作系統(tǒng)分析，而不是將模式用作構(gòu)建材料作為系統(tǒng)成分。
UML視圖和模型
在軟件開發(fā)中，我們利用模型和視圖處理軟件系統(tǒng)的復(fù)雜性。在這里，模型是指視圖的集合或者視圖可以看作模型的一個方面（或視點）。IEEE標(biāo)準(zhǔn)（草案）1471[AT&T1993]將視圖歸結(jié)于“提出一個或多個系統(tǒng)利益關(guān)聯(lián)者（Stakeholder）的利害關(guān)系”。對于利益關(guān)聯(lián)者，我們定義為分享系統(tǒng)注意或興趣個體或組（例如，開發(fā)者，用戶，消費者等等）。應(yīng)用于我們的語境，視圖是模型的片段，它也要細(xì)小到我們能夠理解，但是也包含關(guān)于特定關(guān)系的關(guān)聯(lián)信息。在UML中，視圖本質(zhì)上是圖形的，且往往通過框圖來實現(xiàn)。視圖（例如類或序列圖）服務(wù)于下列意圖：
抽象并簡化模型
使得不同的利益關(guān)聯(lián)者協(xié)調(diào)工作
為不同解釋進行補充（不同觀眾/利益相關(guān)者）
提取關(guān)于特定關(guān)聯(lián)的相關(guān)信息
因此，將會用到什么類型的視圖以及什么時候用到它們是強烈依賴于哪個人正在使用和需要完成的相關(guān)任務(wù)。然而，視圖并不是軟件開發(fā)的銀彈，因為它們具體表達(dá)基本問題；它們內(nèi)部及它們之間表現(xiàn)出對等數(shù)量的建模元素冗余。
要給出一個簡單例子，考慮我們有個設(shè)計（例如按照UML類圖的形式）的軟件開發(fā)案例和產(chǎn)品實現(xiàn)（例如，C++代碼）。類圖和代碼表述不同的視圖，用不同的方法表達(dá)相同或類似的信息。雖然，代碼可以從設(shè)計中自動產(chǎn)生，這種逼近是有限的，還必須多次加入一些信息。更糟糕的是，現(xiàn)在這些冗余的信息片斷必須保持一致――后者大多是手工活動。這樣，無論什么時候設(shè)計變更了，代碼就會變得不一致（反之亦然），我們要應(yīng)用一些視圖調(diào)和活動找到產(chǎn)生的不一致并一再保證模型概念的完整性。
UML視圖不匹配和冗余
既然視圖是我們處理復(fù)雜性***有效手段，我們不能指望用某些較少冗余的事物來替代它們。我們需要視圖在任何給定的時間對軟件開發(fā)者不得不處理的信息總數(shù)進行分解。“這不是帶來復(fù)雜性的細(xì)節(jié)數(shù)量本身，而是我們不得不同時了解的細(xì)節(jié)的數(shù)量。”[Siegfried 1996]
然而，冗余性是一個必需的不幸。這暗示我們需要某種鑒別和解決視圖之間不匹配的自動化活動的方法。這樣，我們所需要就是一些集成和分析視圖的框架形體。有趣的是，視圖不匹配問題可能的逼近方法是基于它特有的問題――冗余性。我們利用一套視圖之間的冗余性意味著一個視圖包含關(guān)于其它視圖并可用作約束該視圖的信息。這樣，我們使用冗余信息來檢驗視圖之間的一致性和完整性。
例如，如果我們使用一些體系結(jié)構(gòu)模式的形態(tài)來構(gòu)造系統(tǒng)（例如，分層風(fēng)格），那么設(shè)計必須反映體系結(jié)構(gòu)對立的約束。這意味著如果體系結(jié)構(gòu)定義了三層結(jié)構(gòu)，那么體系結(jié)構(gòu)隱含地定義了處理中***層不使用第二層而與第三層直接對話是不允許的。如果后來系統(tǒng)使用UML設(shè)計（例如，使用類和序列圖），那么設(shè)計元素之內(nèi)的調(diào)用依賴要求與上述的體系結(jié)構(gòu)約束一致。我們將在后面說明一個例子。
UML視圖描述 vs 集成
啟用視圖集成來確定和調(diào)和視圖要求兩個層次的集成――符號集成和語義集成。對于符號集成，意思是模型需要完整表達(dá)視圖的能力。語義集成通過定義什么信息可以交換以及怎樣交換作更進一步精煉。只有在什么和怎樣在確立之后，不一致性才可以確定。
統(tǒng)一建模語言（UML），像其他通用軟件系統(tǒng)開發(fā)模型一樣，只是不能很滿足上述語義集成。UML提供一個模型用于表達(dá)不同框圖的視圖來處理類、對象、活動、狀態(tài)、包及其它（參看圖 1 ）。然而，UML 不擅長集成他們。在UML視圖之間的關(guān)聯(lián)和依賴關(guān)系很少被捕獲。如果后者沒有完成，模型僅僅是松散耦合的或完全無關(guān)聯(lián)的視圖集。雖然UML及其元模型在細(xì)節(jié)上定義了單個視圖的符號和語義特征，視圖內(nèi)關(guān)聯(lián)的獲取仍然是不夠的（在視圖之間只存在一些微弱形式的依賴關(guān)系，例如類和對象）。
圖 1 也表明問題的另一個方面――那就是擴展UML以表達(dá)新的和外部概念（例如，風(fēng)格和模式）。例如，怎樣才能在UML中使用更高級的模式例如分層的體系結(jié)構(gòu)模式【[1]】或代理設(shè)計模式？在UML中，我們需要再次區(qū)分僅僅表述模式和完整集成它們。
圖 1 UML中表示法 vs. 集成
UML視圖集成框架
視圖集成的主要的障礙是缺乏完好定義的（工程的）模型基礎(chǔ)。視圖經(jīng)常使用迥然不同的表示信息方法，而這使得確定它們在哪里和怎樣出現(xiàn)重疊非常困難。這樣，組合和比較視圖的任務(wù)經(jīng)常是手工的而且潛伏著錯誤的。集成框架的目標(biāo)是要補償鑒別和解決體系結(jié)構(gòu)不匹配自動化輔助手段的不足。
如前面簡短的敘述，這樣做的時候，我們的框架需要處理什么信息和怎樣進行交換。我們在那里寫到什么信息可被交換以及它怎么能交換的判斷需求。在我們的視圖集成框架中，我們提到映射和變換這兩個活動。我們也說只有在這些活動定義之后，才能夠嘗試鑒別不一致性。后者我們稱之為分化（參看圖 2 ）。
圖 2 在高層次式樣上描寫我們的視圖集成框架。在那里，系統(tǒng)模型用于表達(dá)軟件系統(tǒng)的知識基礎(chǔ)。軟件開發(fā)者使用視圖增加新的數(shù)據(jù)到系統(tǒng)模型并且復(fù)審現(xiàn)有數(shù)據(jù)（視圖綜合）。對于UML，系統(tǒng)模型可能被看作通過UML設(shè)計工具（例如Rational Rose）完成的UML模型和視圖綜合。
系統(tǒng)模型和視圖綜合兩者交互影響就是視圖分析。一旦加入新的信息，它就可以針對系統(tǒng)模型進行驗證以保證其概念完整性。圖 2 表示視圖分析可以怎樣進一步細(xì)分為其上述三個主要活動：
圖 2 視圖集成活動
映射：通過使用命名字典、跟蹤和跟蹤仿真（例如相同物理類和方法的使用）以及某種關(guān)聯(lián)/模式形式（例如公共接口）來確定相關(guān)的信息片。
變換：在視圖中操作模型元素以便它們（或它們的片段）可以在其他視圖中共享（或在系統(tǒng)模型自身中表述）。例如，我們可以使用抽象技術(shù)泛化一個詳細(xì)的框圖，我們可使用視圖轉(zhuǎn)化在不同類型的視圖之間交換信息，或者我們可以按不同的風(fēng)格重新排列模型元素（或片段）產(chǎn)生新的視角（例如拼結(jié)和分割）。
分化：詳細(xì)研究系統(tǒng)模型鑒別系統(tǒng)模型中（潛在的）不匹配。（潛在的）不匹配按規(guī)則和約束的形式討論。此外，不匹配解決規(guī)則可與將要怎樣解決它們可選方法的不匹配標(biāo)識規(guī)則相關(guān)聯(lián)。分化是強依賴于變換和映射的。
然而，必須注明的是，那些活動不是相互正交的。顯然地，我們只有在知道模型元素的正確映射時才能做出有用的變換。這種依賴關(guān)系反之也是成立的。通過視圖變換導(dǎo)出的信息可以澄清許多映射中的二義性。這樣，一個視圖可以用于澄清其它視圖中的二義性。
此外，如圖 2 所示，UML視圖集成不只局限于模式，然而，模式對視圖集成構(gòu)成了非常重要的基礎(chǔ)。我們將在后續(xù)章節(jié)中討論這種面向模式的視圖集成方向。其他非模式相關(guān)的視圖集成方向在[Egyed1999a]和[Egyed1999b]中論述。上述框架通常在UML之外也適用。
【編輯推薦】
