使用模式集成UML視圖VIP

使用模式集成UML視圖分化

圖3使用UML包說明我們系統(tǒng)的高層設計視圖。該圖顯示主要訂單系統(tǒng)部件（或子系統(tǒng)）的交互。關(guān)于分層體系結(jié)構(gòu)的知識現(xiàn)在可以幫助我們在表格1中的體系結(jié)構(gòu)和圖3的設計之間自動確定不匹配。表格2總結(jié)兩個視圖對立的約束。

體系結(jié)構(gòu)視圖約束從表格1導出。它們定義我們系統(tǒng)層次之間的調(diào)用依賴關(guān)系（例如，用戶界面依賴于訂單框架）。圖3是設計視圖約束的基礎。該圖說明一個含有一套包以及它們之間調(diào)用依賴的UML包圖（包和依賴的語義在[Booch-Jacobson-Rambaugh1997]中定義）。表格2體系結(jié)構(gòu)上和設計視圖對立的約束

建立這些約束是變換的責任，并且在這種情形下能夠自動完成。例如，利用我們在表格1中的分層模式的知識我們可以自動導出層間的調(diào)用依賴關(guān)系。優(yōu)點是模式的語義只需要定義一次并且可以在以后重用。視圖的語義和符號也可以看作模式。這樣，圖3的包圖帶有一套預定義的相關(guān)約束。一旦定義，就可以對包圖的不同實例導出設計約束。

表格2的映射部分定義了體系結(jié)構(gòu)視圖（表格1）和設計視圖（圖3）部件之間的關(guān)系。在這個例子中，用于映射的模式使用不是那么明顯。我們將在后面討論它們對于映射的使用。表格2中最后兩個部分是部分的分化活動。在那里，定義了兩類規(guī)則，一個用于一致性，另一個用于完整性。如果體系結(jié)構(gòu)定義的一些部件或連接器沒有反映在設計中，就可能顯示潛在的不完整。在另一方面，如果設計與體系結(jié)構(gòu)抵觸，那么這可能指出潛在的不一致性。另外，對于每套我們比較的視圖，規(guī)則只需要定義一次；那些規(guī)則然后可以重用。在體系結(jié)構(gòu)和設計實現(xiàn)之間確定不匹配現(xiàn)在是評估規(guī)則和約束的事情。這樣揭示了沒有完整性方面的不匹配情況，然而，有些不一致性方面的不匹配：1)存貨UI部件對于存貨系統(tǒng)的依賴與分層體系沖突，用戶界面不允許不經(jīng)過訂單框架直接與存貨系統(tǒng)進行交流。

2)類似地，訂單系統(tǒng)要求使用存貨系統(tǒng)訪問網(wǎng)絡。

圖3UML中的高層設計（包圖和依賴）

確定這些不匹配并沒有對他們的起因給出任何反饋。例如，是體系結(jié)構(gòu)還是設計錯誤？表格3說明通過提升存貨系統(tǒng)到訂單框架同一個級別來解決上述所有不匹配而不會引入新的不匹配的可能方法。我們不相信實際的不匹配解決方法將徹底地自動完成。這種方法與先前的自我糾錯源代碼編譯器的嘗試相同，這種努力最后因為所包含的社會和技術(shù)的復雜性而失敗了。可是，我們相信提供給設計者不僅僅使用（潛在的）不匹配，而且用關(guān)于怎樣在處理不匹配以及理解它們這兩者高度有利的情況下解決它們。此外，它可能對發(fā)現(xiàn)處理具有更好選擇情形的技術(shù)非常有好處。我們將在[Egyed1996]中更詳細地討論這種情形。

映射

圖4表明我們系統(tǒng)的另一個視圖，圖3的一個精煉。另外，該視圖可以對修訂的體系結(jié)構(gòu)和高層設計都能進行校驗，然而，并沒有發(fā)現(xiàn)不匹配。該視圖用另外的設計模式例如模板【[2]】（Template）模式（通過<>構(gòu)造型指定）和代理【[3]】（Proxy）模式（通過《Proxy》構(gòu)造型指定）。我們將使用它們進一步探究模式在視圖集成中的價值。

圖4高層設計視圖使用UML類和包的精煉

圖5低層設計視圖使用UML類圖

圖5描寫了對應的低層實現(xiàn)，它不只是解決用于圖4中的模式，而且也精煉其它的一些建模元素。頂部三個類對應用戶界面層，存貨系統(tǒng)可以通過存貨代理來訪問，倉庫可以類似地通過倉庫代理來訪問。要找出該視圖是否和先前的視圖一致，我們可以運用幾個集成技術(shù)。首先，我們需要找出哪些模型元素互相對應（映射）。這有幾種技術(shù)可以應用，例如名字的相似性等等?？墒?，在該例子中模式的廣泛使用使我們能夠開發(fā)關(guān)于它們用于映射的知識。通過圖4中的高層設計我們明白幾個事實：模板模式用于訂單行（OrderLine）

代理模式用于橋接訂單行（OrderLine）（產(chǎn)品）與存貨系統(tǒng)

代理模式用于使用Oracle數(shù)據(jù)庫橋接訂單框架子系統(tǒng)

接口特征（例如，消費者類與訂單、付款、和消費者UI接口）

圖6結(jié)構(gòu)化模式知識（改編自[Buschmanetal.1996]）

雖然從技術(shù)上講，最后一項并不是一個清楚定義的模式，然而它構(gòu)成類配置的知識――這樣，接口特征可以看作模式，即使它們大部分只是領域模式。關(guān)于領域的模式知識如同預定義的模式（參看圖6）一樣使我們現(xiàn)在可以推論建模信息的關(guān)系。映射圖4和圖5的任務被精簡為使用如圖6所論述的預定義結(jié)構(gòu)化模式知識來確定上述模式和（接口）特征的位置。用圖6作為指導，我們可以容易地確定模板模式（產(chǎn)品，隊列，以及產(chǎn)品隊列對應于訂單行（OrderLine））的對應。雖然，它也可以容易找到代理模式，怎樣能夠區(qū)分它們卻不夠清楚。注意到目標是使得計算機自動鑒別它們。要在后來做到這一點，我們可以使用上面討論的接口特征（模式）。想法是，至少存在一些映射或者能夠通過名稱相似性來建立。使用該額外信息它可能自動從Oracle模式區(qū)分存貨（Inventory）模式。不幸的是，通過模式的映射仍然比上述例子可說明的要更困難一些。我們作了簡化的假定，就是模式的結(jié)構(gòu)和行為是靜態(tài)的。雖然，通常模式不是那些精確定義的，并且我們需要它們更一般的描述。圖5表明這樣一個例子，倉庫代理模式看上去不象定義的那樣。然而，既然網(wǎng)絡是部分代理類，它就可以合并到代理類中，并且代理類繼承它所有的依賴關(guān)系（下一節(jié)的Rose/Architect將表達一個模型來這樣做）。該映射技術(shù)的另一個問題