?? umlcomoad002.htm
字號:
<head><meta NAME="´¡ãÍâÈí¼þ¹¡è³Ì" Content="Author:Asia Alien"><title>UML元元模型（中文）</title><meta http-equiv="Content-Type" content="text/html; charset=gb2312"><link REL="stylesheet" HREF="../../newcss.css" TYPE="text/css"></head><body><b><p><font size="5"><img border="0" src="i/umldilver.gif" WIDTH="606" HEIGHT="15"></font></p> <p><font size="5"><a name="1">1. 服務說明</a> <font size="5" face="宋體"><a href="umlcomoad001.htm">返回目錄</a></font></p> </font><font face="Arial" size="5"><p></font><font size="5"><a name="1.1">1.1 概述</a></p> </font><font face="Arial" size="4"><p></font><font size="4"><a name="1.1.1">1.1.1 背景</a></p> </font> </b><p>本文檔為瑞理公司（Rational）等組織向對象管理小組(CORBA) OADTF RFP-1 提交的文檔資料的一部分。CORBA小組成員可以從網點 <i><a href="http://www.omg.org/member/doclist-97.html">http://www.omg.org/member/doclist-97.html</a> </i>處獲得全部的提交資料(文檔ad/97-01-01到ad/97-01-14)。在網點 <a href="http://www.rational.com/UML"><i>http://www.rational.com/UML</i></a>處可獲得UML語言的最新資料。請把您對該文檔的意見通過電子郵件發送到以下地址：UML<i>_feedback@rational.com<font face="Times New Roman"></p> </font> </i><p>RFP的一個主要的目標是實現面向對象的可視化工具之間的相互協作，進而推動軟件工業的發展。OA&D工具定義了一些支持工具協作的接口。</p> <p>但要想使模型信息在不同工具之間的交換具有意義，各種工具的語義和模型表示應該基本一致。在文檔《<i>UML語義</i>》中定義的元模型說明了UML語言的語義和表示法。文檔《<i>UML到CORBAIDL的映射</i>》討論了如何把UML模型轉換成對應的IDL模型。本工具文檔中定義的IDL模型大部分都是從UML1.0版元模型直接對應過來的。</p> <p>提交給CORBARFP的大多數文檔都是首先定義一些接口，然后解釋接口中包含的語義概念。本文檔的結構稍微有一些不同。因為UML語言的語義非常復雜，我們把這部分內容放在文檔《<i>UML語義</i>》中討論，因此本工具文檔中不包括語義內容。</p> <b><font face="Arial" size="4"><p></font><font size="4"><a name="1.1.2">1.1.2 工具共享的方案</a></p> </font> </b><font face="Times New Roman"><p></font>OAD任務小組的主要工作是實現“OA&D工具之間的語義協作”。因此RFP在文檔的5.5.2節指出：“提交文檔必須定義支持工具訪問其他工具產生的模型或模型元素的接口。模型訪問工具可以是一個<i>輸入</i>工具，也可以是<i>連接</i>工具，或者兩者都是。”</p> <font face="Times New Roman" size="3"><p><img border="0" src="i/image51.gif" WIDTH="479" HEIGHT="359"></p> </font><p>如圖所示，對象模型的共享有三種可行的方案：</p> <b><p>庫（Repository）－</b>各種工具連接同一個庫，通過庫訪問模型。元對象工具（MetaObject Facility，簡稱MOF）可以作為這樣的庫，盡管這并不需要持久性。MOF工具無法指定依從UML的工具的基礎模型的豐富語義，因此從工具模型到MOF模型的轉換與具體的實現緊密相關。提交文檔沒有對庫方式進行過多的討論，但在文檔《<i>UML語義</i>》的附錄中有關于工具模型到MOF模型的轉換的內容。</p> <b><p align="JUSTIFY">模型傳送（Model Transfer）－</b>不同工具都支持同一種流格式，通過流（也可以是文件）來交換模型信息。RFP把這種流格式稱做“輸入工具”。對于沒有在CORBA環境下實現的工具，為了提供一個路徑，就必須定義這種接口。在文檔《<i>依從UML的交換格式</i>》中定義了這種流格式；該格式是CDIF主題領域定義的。這種格式的流可以通過OA&D工具的接口內部化為UML模型元素或者從UML模型元素外部化而來。</p> <b><p align="JUSTIFY">模型訪問（Model Access）－</b>不同工具之間逐部分交換模型信息。RFP把這種方法叫做“連接工具”。雖然對于共享整個模型，采用模型訪問的方案可能效率并不是最好，但這種方法可以允許最大限度的語義協作，對客戶程序更有幫助。文檔中定義了一些支持模型訪問的IDL接口。還定義了一些支持把流內部化為模型或從模型外部化為流的OA&D工具接口。</p> <p>總而言之，OA&D工具定義了支持模型訪問和模型傳送方式的接口。這些接口與文檔中的UML元模型是一致的。</p> <b><font face="Arial" size="4"><p></font><font size="4"><a name="1.1.3">1.1.3 OA&D工具的典型用戶</a></p> </font> </b><p>對于模型訪問方式，下列客戶可以使用OA&D工具：</p> <blockquote> <b><p align="JUSTIFY">傳統的CASE工具－</b>傳統的計算機輔助軟件工程工具（Computer Aided Software Engineering tools）可以通過OA&D工具接口共享模型<b>。</p> <p align="JUSTIFY">制圖/動畫工具（Drawing/Animation Tools）－</b>OA&D工具中包括支持模型繪制和<b>動畫</b>的詳細接口。傳統的CASE工具通常把應用程序的模型和模型的圖形表示合在一起。分別維護模型和模型的圖形表示可以使應用程序的圖表，<b>動畫</b>和文檔部分分開。</p> <b><p align="JUSTIFY">報告/代碼生成工具（Report/Code Generators）－</b>各種報告和代碼的生成工具可以通過OA&D工具的接口，訪問模型和模型的特征值。</p> <b><p align="JUSTIFY">商業對象工具（Business Object Facility）－</b>雖然BOF的定義時刻在發展，但BOF可以利用OA&D工具為商業對象的邏輯和物理特性（例如，UML的<i>組件</i>和<i>構件</i>）及它們之間的關系建模。BOF可以使用文檔定義的對象元模型以及模型的擴展機制來存儲模型，把元對象工具作為存儲商業對象實現的庫。</p> </blockquote> <p>文檔的提交人員都認為為用戶定義詳細的接口是實現工具協作的重要內容。</p> <b><font face="Arial" size="4"><p></font><font size="4"><a name="1.1.4">1.1.4 實例證明</a></p> </font> </b><p>文檔定義的規范在技術上是完全可行的。例如，瑞理公司開發的可視化建模工具 Rational Rose? 雖然不是一個CORBA環境的工具，也實現了不少特性。Rose 4.0 版中定義了一套“Rose擴展接口”（叫做“Rose Script”），包括OLE automation server格式和 Visual Basic for Applications (VBA)格式。Rose 4.0 版中定義了一套“Rose 擴展接口”，該擴展接口由OLE automation server 和Visual Basic for Applications (VBA) scripting接口（即Rose Script）共同提供。這些接口類似于文檔中定義的接口。有幾個報告和代碼生成工具已經使用了Rose Script，包括一個IDL的代碼生成器。盡管Rose Script并不是IDL的，但這些都是Rose“服務”的“客戶”。</p> <p>如果一些工具要實現用于信息交換的專利格式，我們認為CDIF（CASE工具數據交換格式/EIA）是比較好的選擇，會得到軟件工業界的廣泛認可。CDIF格式的語法和編碼標準是本文檔的基礎，已經有許多工具實現了這一標準。</p> <b><font face="Arial" size="4"><p></font><font size="4"><a name="1.1.5">1.1.5 存在的問題</a></p> </font> </b><p>這個文檔被定為 1.0 beta 1版本，是因為在工具定義中還存在著許多問題。這些問題將在1997年4月以前，向CORBA提交的修改文檔中得到解決。RFP包括的范圍太廣，它試圖同時實現語義的標準化和解決工具問題。然而，對語義的長期討論使得一些工具問題遲遲得不到解決。如下列問題：</p> <blockquote> <p align="JUSTIFY">雖然UML元模型只是一個語義模型，還沒有對工具上的問題進行修改，但作為向RFP的初次提交還是可以的。在預期于1997年4月完成的修改文檔中，應該定義一個獨立的工具元模型作為OA&D工具的基礎。UML元模型中還缺少一些工具標準所必需的行為（操作）。</p> <p align="JUSTIFY">為了防止模塊之間的循環依賴，工具中的IDL模塊一般規模都很大，而且結構也不是很好。如果不存在一個獨立的工具元模型，定義相互松耦合并且規模很小的模塊是很難的。對接口的依賴關系的要求不同，將導致不同的模塊集。</p> <p align="JUSTIFY">工具定義中的IDL模塊與文檔《<i>UML語義</i>》中的元模型并不完全一致。這是因為就在向CORBA小組提交該文檔之前，我們對UML的語義作了一些修改。IDL模型在有關<i>狀態</i>和<i>名字</i>的內容上與UML元模型略有出入，還有我們把元模型中的模式（pattern）改成了協同（collaboration）。</p> <p align="JUSTIFY">在這篇文檔中，我們只說明了工具的一部分用法。我們確信UML元模型中的所有語義對用戶都是有用的，因此我們為所有的語義都定義了相應的接口。在修改版的文檔中，我們將討論工具的其他一些用法。</p> <p align="JUSTIFY">目前，工具接口所聲明的異常泛指所有的異常情況，還沒有具體化。</p> <p align="JUSTIFY">我們還需要更深入的探討局部模型傳送的語法。例如，如果一個包（package）中包含與其他包中的類的雙向關聯，那么輸出這個包就有可能產生問題。在文檔《<i>依從UML的交換格式</i>》中涉及到了這個問題。</p> <p align="JUSTIFY">雖然UML1.0版的元模型定義了表示符號位置的類及其屬性，但并沒有制訂符號布局的標準。因此，無法保證工具實現的圖表設計。</p> <p align="JUSTIFY">目前的類型轉換還沒有使用國際化的字符串。</p> </blockquote> <p>文檔的作者歡迎各位提出寶貴意見。</p> <b><font face="Arial" size="4"><p></font><font size="4"><a name="1.1.6">1.1.6 工具的性能</a></p> </font> </b><p>采用<i>依從UML的交換格式</i>，模型的傳送可以不必實現OA&D工具，例如在非CORBA的環境中。</p> <p>本工具文檔定義了支持模型訪問和模型傳送服務的接口，這些接口基本上有兩層性能：</p> <font face="Times New Roman"><p></font>1) 模型傳送（Model Transfer）－0節中定義的“抽象”接口。</p> <font face="Times New Roman"><p></font>2) 模型訪問（Model Access）－上述接口，及0節中定義的“詳細”接口。</p> <b><font face="Arial" size="4"><p></font><font size="4"><a name="1.1.7">1.1.7 其他所要的特性</a></p> </font> </b><p>實現OA&D工具的開發人員還可以發現許多有用的特性，如（在內部化/外部化過程中間的）過濾器（filters）和查詢（queries）。工具開發人員還應該考慮定義和實現其他有價值的特性。</p> <b><font face="Arial" size="4"><p></font><font size="4"><a name="1.1.8">1.1.8 簡介OA&D工具接口的組成</a></p> </b><p>本節討論工具的接口類型。大部分的接口直接對應于UML的元模型。還有一些接口是從CORBA服務中繼承來的。</p> <b><font face="Arial"><p></font><a name="_Toc392905059">1.1.8.1 對應于UML元模型的接口</a></p> </b><p>作為一個基本的前提，OA&D工具的用戶應該能夠隨意查看和管理一個模型。因此，我們為整個模型定義了接口。</p> <p>文檔《<i>UML到CORBAIDL的映射</i>》中定義了可以直接從UML元模型導出的IDL模塊的基本構件，主要包括：模塊，界面，類型定義，枚舉，異常，結構，常量，聯合，屬性和操作。</p> <p>另外，還定義和使用了幾個轉換模式：</p> <blockquote> <i><p>集合（Collections）</i>－集合定義于使用集合服務的特定關聯上。集合與集合服務的關系將在后面討論。</p> <i><p>關鍵字/限定關系（Keys/Qualifiers）</i>－添加了按名字查找的操作。</p> <i><p>關聯類（Association Classes）</i>－繼承于LifeCycle。</p> </blockquote> <b><font face="Arial"><p></font><a name="_Toc392905060">1.1.8.2 內部化和外部化</a></p> </b><p>首先明確那些用于工具間傳送，表示局部模型的抽象“塊”。主要有如下UML元素：系統，模型，包和圖。</p> <p>如外部服務（Externalization Service）中定義的那樣，在工具的實現中，這些塊都是“可流動的”，可以從<i>內部化</i>進工具和從工具<i>外部化</i>而來流的格式可以是文檔《<i>依從UML的交換格式</i>》中定義的CDIF。小一些的塊和單個模型元素也可以通過OA&D工具的其它接口在工具之間交換。</p> <p>在內部化/外部化過程中發生的傳送“轉換”的語義在文檔《<i>依從UML的交換格式</i>》中討論。文檔還討論了名字域和對復用有重要意義的局部模型傳送等概念。轉換的語義并不影響工具接口的定義。</p> <p>工具與外部服務的關系在以后深入討論。</p> <b><font face="Arial"><p></font><a name="_Toc392905061">1.1.8.3 生命周期服務</a></p> </b><p>工具定義了工廠（Factories）及其它的一些生命周期接口。這在以后詳細討論。</p> <b><font face="Arial"><p></font><a name="_Toc392905062">1.1.8.4 擴展</a></p> </b><p>明確關鍵的UML擴展機制，<i>特征值（tagged value）</i>，是有用處的。通過工具的接口，可以使用特征值把任意數目的未注冊、未說明的索引包括到模型中。這可以作為一種結合機制，例如，在模型中添加從對象模型構件到構件實現的索引。</p> </body> ?? 快捷鍵說明
復制代碼
Ctrl + C
搜索代碼
Ctrl + F
全屏模式
F11
切換主題
Ctrl + Shift + D
顯示快捷鍵
?
增大字號
Ctrl + =
減小字號
Ctrl + -