|
|
內容: |
|
什麼是繪圖法? |
為什麼使用建模工具? |
選擇一種繪圖的方法 |
範例繪圖法 |
使用IBM Rational XDE Modeler/Developer |
建模工具:對任何複雜系統都是有用的 |
鳴謝 |
注釋 |
關於作者 |
文章打分 |
|
|
Nathalie Gaertner IBM 2004 年 4 月
本文來自於 Rational Edge :本文描述了一種建模的方法,這種方法可以被應用到技術的和非技術的系統中,併產生一種繪圖法 — 內部依賴的系統或者相互依賴的系統模型。
在我們的工業裡,多數的建模工作是瞄準建立定義了軟體系統將如何被設計和實現的分析、設計和實現模型。但是,如果我們能夠使用相同的工具來建模軟體和非軟體的系統,那對我們不是更加有協助嗎? 本文討論了一個建模方法,這個建模方法圍繞著系統的類型和產生一種繪圖法,或者是內部依賴的/相互依賴的系統模型。本文描述了如何建立這樣一種繪圖法,它可以更進一步的體現使用基於 UML1 的建模工具(比如 IBM Rational Rose 或者 IBM Rational Rose XDE Modeler/Developer )的好處,而不是僅僅使用一般的畫圖工具。 什麼是繪圖法? “繪圖法”這個詞已經被定義成為了一種“形成表徵圖或者地圖的技術或者業務,”2 地圖所表示的是“通過正確的空間位置的縮小比例的圖解方式表示顯示世界的一個地區。” 在本文的環境中,我們將使用術語繪圖法代表一個互動的和內部相關的系統抽象的可視化的表示。 通常,建立軟體的繪圖法包括擷取已存在資訊系統的詳細目錄並用一個全域的視圖描述他們。換句話說,繪圖工作就是清點工作 — 或者,如果資訊沒有被文檔化或者是不可得到的,繪圖就是考古的工作 。在任何情況下,開發一個軟體繪圖法都會產生以下的利益“
- 更好的理解已存在的系統和對系統更好的管理能力。
- 理解在哪裡存在著資訊或者功能的重複。
- 在對系統進行變更前分析變更所導致的影響的能力。
- 更好的對系統進行溝通的方式。
讓我們假設你想要說明和文檔化你公司中的系統、位置和人。你可以指出、可視化和文檔化部門的和在這些部門中負責管理和維護系統的人的抽象,這些部分所依靠的軟體系統和這些軟體被安裝的電腦的抽象等等。一個可視化的模型 — 一種繪圖法 — 能夠給你這樣的畫面。繪圖法擴充了”傳統的“軟體開發模型的範圍。 為什麼使用建模工具? 大多數的時候,在”非常規的“情況下(也就是,當我們不建立一個將要建立的軟體應用的分析或者設計模型時),我們使用畫圖工具(比如 Visio、CorelDRAW 等等)。然而,這些工具對軟體的建模來說是不適合的。他們只適於建立單個的圖畫;如果我們想要建立幾個圖,我們必須可以手工的保證在多個維護點上的一致性。同時,如果你嘗試著通過一個大圖來描述系統,你將發現在視圖中添加甚至一個元素都將是”不可能完成的任務“。你將需要找到自由的空間來畫新的元素,並要避免交叉關係連線。最終,你將個到一個非常複雜的圖,這個圖是讓人難以理解的,不是真正有用的和幾乎不可能僅在一張紙中列印的下的。 建模工具能夠比畫圖工具更好的支援這種複雜的建模工作。它提供了建立系統不同視圖(圖)、視圖之間的依賴關係和環境的方法。使用適當的建模工具提供了以下的好處:
- 你可以通過以下的好處管理模型的複雜性:
- 建立幾個僅僅顯示少量元素的圖。
- 僅定義一個元素一次,就可以使它在幾個圖中顯示(建模工具確保一致性;如果你在一個模型或者任何顯示了這個元素的圖中修改了一個元素,修改將自動的在其他多處引用了這個元素的圖中被進行)。
- 在某個圖中顯示或者隱藏元素的細節/屬性。
- 你可以查詢模型以得到指定的資訊並瞭解元素內部和元素之間的依賴。例如,你可以讓建模工具建立一個圖,圖中的所有元素與其他元素存在著特定類型的關係。你也可以匹配你的搜尋標準來得到所有顯示了元素的圖(然後瀏覽他們中的每一個)。
- 你可以檢查並確保圖的元素符合 UML 的規範。
- 你可以添加原型和相應的表徵圖。自訂的表徵圖能夠很大程度的改進易讀性並能夠可視化的表達意圖(甚至讀者還不熟悉 UML)。
- 你可以在團隊中使用相同的模型工作。
IBM Rational Rose and IBM XDE Rose Modeler/Developer 提供了這些好處,並完美的融入到了繪圖建模的環境中。此外,他們還給你下面的額外好處:
- IBM Rational Rose 擴充介面或者 IBM Rational XDE Development Kit (XDK) 能夠擴充建模工具的能力以支援複雜的報告和管理功能。
- 你可以根據你的需要使用 IBM Rational SoDA 來產生 MS Word 或者 FrameMaker 報告。
選擇繪圖的方法 為了成功的進行繪圖建模,定義一種語言是首要的任務,這個語言應該包括能夠表示各種類型的元素和他們之間的關係、依靠和語義的能力。所有項目中的成員都必須一致認可一種公用的語言,以保證在產出模型上的公用理解。此外,項目中的所有成員都應該對建模過程的範圍達成一致。 在接下來的部分,我們將描述完成這些事情的最好方法,使用 IBM Rational Rose 中嵌入的 UML 。 類和對象方法的缺點 假設你想管理一個複雜的部門集合,包括這些部分依賴的系統、他們用來運行軟體的電腦和負責管理和維護系統的人員。 使用 Rational Rose 建立一個繪圖模型的一個方法是為抽象建立類,然後建立 UML 對象圖(例如,沒有訊息的共同作業圖表)。你可以通過識別主要的抽象開始。這些抽象的一個子集顯示在圖 1 中。 圖 1: 在一個管理例子中的主要抽象的子集 然後你可以象在圖 2 中的那樣建立一個共同作業圖表。 圖 2: 顯示了圖1 中的類的執行個體(比如,對象)的範例圖 圖 2 ,和所有其他的共同作業圖表一起建模環境對象。也要注意有意義的建模工作將添加大量的對象。 然而,這個方法存在著它的缺點:
- 如果不使用大量的 UML 注釋,你將不能對共同作業圖表添加所有有用的細節。例如,你如何顯示 Tom Joad 是 OrderEntry_V3 系統的管理員?如何顯示OrderEntry_V3 系統的屬性 OrderEntry_V3 的值?
- 你不能檢查在共同作業圖表與類模型之間的語義的一致性。你如何能夠驗證每一個系統對象都被串連到至少一個管理員呢?你如何能夠驗證每一個系統對象,比如在我們的例子中的 OrderSystem_V3 ,對於ProductionDate 屬性有相應的值呢?
- 你不能簡單的查詢共同作業圖表的內容。IBM Rational Rose 僅僅對類圖提供了有趣的過濾和查詢功能。這類建模工作的目標不是產生代碼,而是獲得抽象目前狀態的建模方法的利益。例如,你可以真正的從建立一個顯示了 Tom Joad 的新圖中獲益,然後使用 Rational Rose 中的 ”Expand selected elements“ 功能找到並顯示Tom Joad擔任使用者或者管理員的所有系統。
- 你不能在一個對象之下組織其他元素(對象和/或圖)。然而,你能在模型瀏覽器中組織建模實體階層。
- 你不能在不同的共同作業圖表中重用相同的對象。
最佳方法:元類和類 為了避免我們提出的對於類和對象方法的缺點,你可以使用一個 meta 層級。如果你建模 Tom Joad 作為一個類(代替一個對象),你可以使用類圖並得到以下的好處: 你可以在 IBM Rational Rose 中使用查詢和過濾菜單來探究和理解被建模環境的內部和相互的依賴:
- 你可以展開被選定的元素並自動化的建立有意義的包含類及其類與其他被選定的類之間的關聯類型的圖。
- 你可以通過指定的名字添加類。
- 你可以隱藏被選定的類。
- 你可以在當前的圖中過濾串連類的關係(顯示或者隱藏特定的關聯類型)。
- 你可以根據圖來隱藏或者顯示類的細節(屬性或者操作)。
- 你可以使用角色的名字進一步的限定類之間的關聯。
- 你可以在不同的圖中重用相同的元素,這與在互動圖中對象屬於,並僅屬於一個圖正相反。
- 你可以在一個階層中組織被建模的實體,比如,在其他類下被組織的類。
- 通過使用 IBM Rational Rose 擴充介面 (REI) 和/或 IBM Rational SoDA,你可以得到更加前強大的報告能力。
通過使用這種方法,你現在可以在圖 2 中建模象圖 3 中的元素了。 圖 3: 由執行個體層級到類層級的轉化 你然後也可以推進類向上一個層級,就像圖4 所示。
圖 4: 元模型和模型方法 就像你能夠看到的,這將產生一個元模型(模型的模型)。 ”流行的 meta“能夠被反覆的應用;在一個場合的元模型能夠是另一個場合下的模型。這也就是使用 UML 和 Meta Object Facility (MOF)3所發生的事情。 在這種方法中,元模型是一種繪圖法語言。它定義了建模工作的範圍,因為它定義了
- 在模型層使用的元素”類型“,
- 在模型層這些元素間可能的關係。
- 在類和關係背後的語義。
作為類的模型繪圖法實體 在元模型中的類的名字將變成在模型中原型的名字。在圖 4 中,元模型中的 Person 類是模型中的原型的名字。 在你的模型中使用原型類的好處是你能夠關聯一個表徵圖到一個類,這是模型更加的直觀、易於理解和易讀,甚至對於不熟悉 UML 的人。在 IBM Rational Rose 中你能以一種方便使用的方式擴充圖工具列,以便你可以通過使用滑鼠點擊來建立模型類,並且被期望的原型名將已經被定義了。 我推薦你通過繪圖法的字母縮寫來作為你期望的原型名字的開始。也就是說,你的所有原型的名字將出現在下拉式清單和自訂工具列視窗。對於我們的例子,我們可以使用 System Cartography 作為屬名,他的字母縮寫為 SC 。 在 IBM Rational Rose 中的自訂的工具列 (Toolbox)看起來象圖 5 中所示。 圖 5: 自訂 IBM Rational Rose 工具列的例子 建模繪圖法實體的特徵作為特性的屬性 繪圖法的類(模型層級)擁有特性。比如,系統 OrderEntry_V3 有一個生產日期。你可以列出你期望的特性作為在元模型類中的屬性(見圖 6 )。 圖 6: 定義元模型類的特性作為屬性 你該如何執行個體化這些屬性以得到你的模型資訊呢?一種在你的模型中輸入這個資訊的方法是使用被標記的 UML 值。在 IBM Rational Rose 中,被標記的值為所有類定義的特性。不幸的是,特性不能被顯示在圖中。然而,這些類的特性值應該在圖中可見:記住,你不要對工程代碼建模!相反,你應該建模繪圖法以評估和文檔化已存在環境的目前狀態。 在 Rational Rose 中,我們可以使用屬性代替特性顯示在圖中。 7 所示,這些屬性的名字包括特性的名字(例如,ProductionDate)和初始值(例如,12.12.2000)。 圖 7: 模型類擁有初始值的屬性 不幸的是,我們必須手工的在特性名和它的值中進行輸入。對所有<<System>> 的類輸入特性的名字(比如,ProductionDate)是耗時的並且容易產生錯誤。 然而,你可以使用一個基於 Rational Rose 指令碼的自動化的方案。這個指令碼能夠根據所有被需要特性的名字(僅僅是被需要的特性)建立一個對話方塊,通過這個對話方塊你僅僅能夠添加初始值(見圖 8 )。這使 Rational Rose 能夠解釋並迫使在模型層級的規則與那些已經在元模型層級被指定的規則相一致。 此外,假設對每一個元模型類你都有多於 5 個屬性,並且對於每一個元模型類你將至少建立 20 個類。如果你不必找到並建立 100 個或者更多的屬性名稱,這對你來說將是巨大的協助。 圖 8: IBM Rational Rose 指令碼使用建立必要的屬性名稱並輸入初始值 然而,不是所有在元模型類中的屬性都是最好的在模型中作為屬性被執行個體化的。例如,如果你在元模型類中有一個 comment 屬性,在模型中這個屬性最好是使用文檔域來執行個體化。類似的,一些屬性可以作為串連的文檔被執行個體化。 為了更加準確的知道每一個元模型類的屬性是如何在模型中被執行個體化的,你可以使用表 1 中顯示的原型。 表 1: 對於元模型屬性的原型
對於元模型屬性的原型 |
模型中的執行個體化 |
<<>> |
屬性 |
<<URL>> |
附件文檔 |
<<DESC>> |
文檔域 |
<<Name>> |
指示類名 |
|
例如,在圖 9 中的元模型類被 10 那樣執行個體化。 圖 9: 元模型類 圖 10: 模型類執行個體化圖 9 中的元模型類 圖 10 中的 Tom Joad 類也有一個指向一個圖片的附件和一個可以被用於額外資訊的文件視窗。你也可以添加表徵圖到原型類。例如,你可以為 <<SC Person>>: 使用圖 11 中的表徵圖。 圖 11: 用於原型類的表徵圖 在模型中的關係 在模型的模型中的類存在與其他類之間的關係。例如,系統 OrderEntry_V3 有一個或者幾個對類型 Person 類的關聯。多少關聯是被允許的?每一個為什麼存在?這個資訊被包含在元模型中。 在元模型類之間的關係被作為模型類之間的關係執行個體化。在元模型中的多樣性定義了在模型中有多少(最少和最多)關係被定義了。元模型的角色名稱字或者關聯的名字進一步的限定了關聯的端點或者關聯;這些名字能夠在模型層級作為原型的名字或者角色的名字被重用。例如,在圖 12 中的元模型指示了一個系統有一個或者幾個管理員( Person 類型)和零個或者幾個使用者( Person 類型)。模型資訊(元模型的執行個體化)看起來 12 。 圖 12: 模型類之間的關係 我們仍然不知道選擇什麼樣的關係類型。我們應該選擇關聯和/或依靠和/或其他的什嗎?我的建議是使用關聯,因為
- 你想要的關聯模型:結構關係。
- 如果你正使用 IBM Rational SoDA 報告工具,過濾/得到一種關聯類型是更加容易的。
- 如果語義比關聯之一更加符合的話,你也可以使用其他的關係。
構建模型 一個重要的成功因素是模型類在模型瀏覽器中是如何被組織的。核心的原則是避免重複資訊。. 這對於類來說看起來非常明顯:你不應該複製類的定義。然而,這個原則不僅僅應用到類本身。考慮一下在包中的組織:你需要包來組織你的模型內容,但是你也希望避免過多的包名。因此你不應該僅僅從元類名中產生包。例如,不要總是建立包 Persons ,在這個包中你放入了所有的 <<SC Person >> 執行個體,包 Systems, 在這個包中放入了所有的 <<SC System>> 執行個體,包 Software ,在這個包中放入了所有的 <<SC Software>> 執行個體,等等。 考慮一 13 顯示的模型組織: 圖 13: 在瀏覽器中可能的模型組織 注意這產生了完全相同的子包。更好的方案被顯示在圖 14 中。 圖 14: 避免了複製子包的模型組織 如果有必要的話,你也可以在類之下組織類(嵌套類)。例如,如果你也必須對服務和人的位置建模 Country ,你應該為 Location 建立類並在他們下面組織其他的類。 注意,你也可以在模型組織中添加圖以顯示你的繪圖元素:類圖(上面顯示的)和其他類型的圖,如果需要的話,可以添加比如活動或者狀態圖。 當你構建你的模型時,你也應該考慮團隊協作;你可以協調模型組織和包的結構以使並行開發成為可能。在 IBM Rational Rose 中,你可以在單獨的被稱作控制單元的單元中儲存包,然後將這些控制單元的每一個放入到版本控制之中;IBM Rational Rose 提供了一個內建的和 IBM Rational ClearCase 以及所有的 Source Code Control (SCC) 相容的版本控制工具的整合。有越多的人在相同的模型之上工作,就會有越多的控制單元應該被定義,以使每個人可以在他自己的控制單元上工作。分配指定的責任給團隊成員(例如,分配一些人建模 Person,另一些人建模 System ,等等)並建立相應的控制單元。你甚至可以建立子包,並且如果你需要更細的粒度,你可以將子包做成控制單元。如果你正獨自的開發你的繪圖法,記住放整個模型在版本控制下以跟蹤變更仍然是好的實踐。 查詢和報告 一旦你在模型層級輸入了資訊,你就可以使用 IBM Rational Rose 來實現查詢和過濾。例如,使用 IBM Rational Rose 的 "Expand selected elements..." 特性對被選定的類來描述所有被串連的類是容易的。你可以拖放一個如 OrderSystem_V3 類到一個新圖上,並且查詢所有與它相串連的類。你也可以繼續得到完整的包括所有錯綜複雜的和相關的元素的層次圖。結果產生的可視化的顯示將使理解更加容易。 報告的能力是被 IBM Rational SoDA 和/或 IBM Rational RoseWeb publisher 提供的。如果你需要自訂的報告能力,你可以使用 Rational SoDA 。 如果你想要一個根據元模型的強大的模型查詢機制,請跟隨下面的步驟:
- 定義元模型作為一個單獨的 IBM Rational Rose 模型。
- 為繪圖法本身建立一個 Rational Rose 模型。
- 動態閱讀元模型,並為檢查模型構建規則。
你既可以使用 IBM Rational Rose scripts 也可以使用一個 COM 伺服器來執行這些步驟。 現在,你具備了所有你需要用來建立幾個類圖和你的繪圖法抽象的條件了。根據你所選擇的範圍,建模的工作是相當花時間的。通常,圖顯示大量的資訊(類)。盡量的將元素進行邏輯分組並且使用有意義的名字來限定類圖。當有必要時不要忘記顯示或者隱藏屬性。 在接下來的部分我們將介紹一個範例繪圖法的建立。 範例繪圖法 下面的範例是基於我們上面討論過的繪圖法模型的,它包括一個公司的系統、軟體和他們需要的電腦,還有負責管理和使用系統的人員 使用 IBM Rational Rose ,這個範例應用了所有的在上面定義的概念,並產生了一個顯示繪圖法模型快照的報告。當然,使用 IBM Rational Rose 的“瀏覽”和“查詢/過濾/報告”的特性是一種進階的可視化、掌握和使用一個繪圖法的方法。 首先,就像我們上面討論過的,我們想要建立一個元模型(圖 15 )來為繪圖法定義一種語言。 圖 15: 為範例繪圖法定義語言的元模型 通過看這個元模型,我們可以發現:
- 繪圖法應該顯示系統、人、軟體和伺服器。
- 系統能夠運行在一台或者幾台伺服器上。
- 系統可以依賴零個或者幾個軟體部分。
- 軟體本身可以依賴其他軟體。
- 每個系統將至少有一個扮演管理員角色的人和零個或者更多的扮演使用者角色的人。
- 繪圖法的每一個元素的特性通過在圖 15 中的類的屬性被定義。
然後,我們可以構建圖 16A、 B、 C 和 D 來執行個體化元模型並建立繪圖法本身。 圖 16A: 軟體視圖 圖 16A 顯示了一個被公司系統使用軟體視圖。在這張圖中顯示的所有的類是在圖 15 中定義的 Software 類的執行個體,並且有原型 <<Software>> 。這張圖的設定表明這個原型應該使用一個表徵圖表示:一個磁碟片。這些 <<Software>> 類之間的關聯表示了他們之間的相互依賴。 圖 16B: OrderEntry_V3 系統檢視表 圖 16B 顯示了一個公司的 OrderEntry_V3 系統的視圖。在圖中間的OrderEntry_V3 類有原型 <<System>> ;這張圖的設定表明這個原型用了一個盒子的表徵圖表示。這些設定也指明了類的屬性應該被隱藏。圖中顯示了 OrderEntry_V3 系統僅有一個管理員(Daniel Diebolt)和兩個使用者(Christophe Tournier and Thierry Duvanel);它運行在名為 CH-Server1 的伺服器上,並且使用了軟安全性關聯P R/3, v4.6 。 圖 16C: 軟體開發環境視圖 圖 16C 顯示了一個公司軟體開發環境系統的視圖,並能夠顯示了 <<system>> Software Development Environment 類的屬性。系統有一個管理員和兩個使用者。系統運行在一個伺服器上並使用相互依賴的軟體。 圖 16D: Christophe Tournier 的詳細視圖 使用所有被輸入的資訊來建立了在圖 16B 和 圖 16C 中的圖,我們現在可以使用建模工具的查詢機制來建立子圖 16D 中的圖:Christophe Tournier 作為管理員或者使用者使用的所有系統的視圖。這個類圖被設定來顯示 Person 和 System 類的屬性。 使用 IBM Rational XDE Modeler/Developer IBM Rational Rose XDE Modeler/Developer 通過建立 XDE profile 提供了一種非常好的 UML 擴充以支援元模型/模型的方法。一個 profile 是一系列的被標記的值和原型。被標記的值捕獲模型元素中的額外資訊,原型添加語義到模型元素。 為了使用 Rational Rose XDE Modeler/Developer 建立繪圖法,你應該使用一種類似於我們剛剛描述的 IBM Rational Rose 的方法。首先,你應該定義你的 profile ,它將變成你的“語言”(例如,元模型)。就像使用 Rational Rose 一樣,你可以使用被標記的值(在 Rational Rose 中成為特性)。但是要記住,你將不會在圖中看到那些被標記的值。就像我們前面建議的,最好是使用屬性和屬性值來代替特性。 在 IBM Rational Rose XDE Modeler/Developer 中,模型瀏覽器層次應該被良好的定義,但是你可以操作引用了其他模型的不同模型。Rational Rose XDE Modeler/Developer 是可以使用多個模型的。 查詢和過濾也是可得到的:選項一個類,右鍵點擊,並選擇 "Add related shapes" 。然而,在 Rational Rose XDE Modeler/Developer 中,你擁有對相關元素更好的控制。例如,你可以對你希望選擇的類選擇相關的關聯類型。 在 IBM Rational Rose XDE Modeler/Developer 中,報告也是可以得到的。就像 IBM Rational Rose 一樣,通過與 IBM Rational SoDA 可以使你產生指定的、自訂的和靈活的報告。 IBM Rational Rose XDE Modeler/Developer 也提供了一個開發的應用編程介面(API)來讀模型資訊。這個 API 被命名為 Rational XDE Extensibility (RXE)。 它提供了所有你需要建立額外模型檢查的能力。 建模工具:對任何系統都是有用的 不論是 IBM Rational Rose 還是 IBM Rational Rose XDE Modeler/Developer 都支援繪圖法的建立,並且能夠更加有效被擴充以支援它。如果你正在建模一個複雜的系統,並且不需要產生代碼,你將可以獲得建模工具帶來的巨大利益。 想象一下建立公司中所有資料庫的繪圖法是多麼有用。如果你有一個在公司中使用他們的介面和位置的所有已存在系統的圖,你就可以有效控制、整合和管理那些系統。 IBM Rational Rose 和 IBM Rational Rose XDE Modeler/Developer 可以協助你在繪圖法元素上建立、維護、可視化、理解、查詢 繪圖法元素並執行元素之間的衝突分析。你可以容易的建立顯示不同方面的不同的圖,同時保證他們的一致性。添加新的元素和更新圖以反映變化是一個直接了當的過程。一旦你將你的模型置於版本管理之下,你就可以跟蹤變化,並且當你構建你的繪圖法時,你可以在團隊之中工作。 雖然你可以假設建立對象圖是最具合理的開始構建一個繪圖法方法,但實際上你需要更加強大的工具來支援你通過使用類圖來獲得這種能力。“流行的 meta ”是最好的方法,因為它允許你在 meta 層級上定義一種語言,然後在模型層級上使用類圖建模真正的實體。 我們可以總結一下建立一個繪圖法的步驟:
- 定義一種穩定的語言,或者元模型,它包含類、屬性和關係。
- 自訂 IBM Rational Rose 或者 IBM Rational Rose XDE 工具列,並且建立可以簡單的輸入模型類屬性的指令碼。
- 在 Rational Rose 中定義一個模型瀏覽結構,這可以合理的組織資訊,並且實現可以容易的得到模型元素的方法。
- 使用 IBM Rational SoDA 建立必要的報告。
- 將你的模型置於版本控制之下以方便團隊的協調和變更的跟蹤。
一旦你執行了這些步驟,你已經準備好了使用類圖和類圖元素建立你的繪圖法。當然,如果有必要的話,你也可以添加其他類型的圖。 鳴謝 非常感謝 Christophe Tournier ,他推動了我寫這篇文章,同時我和他進行了討論並發展了我的想法和概念。同時非常感謝 Catherine Southwood ,她提供了非常有簡直的注釋和編輯工作。 注釋 1 UML, 或者整合模組化語言, 是用於說明、可視化和文檔化軟體和非軟體系統的圖形化的語言。 更多的資訊參見 http:// www.omg.org/uml/ 2Webster's Revised Unabridged Dictionary, MICRA, Inc., 1998. 3 MOF 是一個抽象語言和架構,它被用來說明、構建和管理技術中立的元模型。MOF meta-metamodel 是一種被用來定義 UML 元模型的語言。
關於作者 Nathalie Gaertner 在 1983 年開始進入電腦科學領域。現在她仍然對軟體工程十分熱衷。在她獲得了電腦科學博士學位和聯合著作了 Modélisation Objet avec UML -2000 年被發表在 Eyrolles 上- 之後,她於 1999 年作為一名諮詢顧問加入了 Rational 軟體。她一致在協助客戶評估他們的軟體需求和實施 IBM Rational 的解決方案。 |
|