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