|
2008 年 7 月 24 日
在本文中，使用 Eclipse Modeling Framework (EMF) 和 Graphical Modeling Framework (GMF) 技術來為領域特定語言產(chǎn)生領域特定建模輔助工具。了解定義領域特定語言的價值，探索基本概念和不同的建模方法，以及獲取有關創(chuàng)建良好元模型的提示。
引言
在體系結(jié)構(gòu)設計和軟件工程中，您需要清楚理解體系結(jié)構(gòu)的領域，并且能夠有效地將該信息傳達給其他人員。可以使用各種技術和工具來應對此挑戰(zhàn)，例如使用領域特定語言（domain-specific language，DSL）和領域特定建模（domain-specific modeling，DSM）。DSM 充當 DSL 的前端，并允許用戶通過可視化的表示形式來表示構(gòu)造。
本文集中于使用 Eclipse Modeling Framework (EMF) 和 Graphical Modeling Framework (GMF) 技術來說明如何為 DSL 產(chǎn)生 DSM 輔助工具。
要使用 EMF 和 GMF 來開發(fā) DSL 和 DSM，您需要以下工具：
- 建模和元模型建模概念和技術
- 使用 EMF 的建模
- 使用 GMF 模型來進行工具開發(fā)
- 模型轉(zhuǎn)換概念和技術的建模
- 構(gòu)件轉(zhuǎn)換概念和技術的建模
- 軟件工程和編程：
領域特定語言和建模
日常生活中存在許多適用或使用 DSL 的領域。一些實際 DSL 包括：交通和道路標志、平裝家具組裝圖、象棋游戲（和大多數(shù)其他臺式游戲）以及電路設計。與 IT 相關的 DSL 示例包括 HTML、SQL、WS-* 標準、業(yè)務流程執(zhí)行語言（Business Process Execution Language，BPEL）和 POV 場景描述語言。
與這些 IT 示例相關的 DSM 示例包括所見即所得 (WYSIWYG) HTML 編輯器、BPEL 編輯器和 POV Modeler。
使用 DSL 來定義范圍
定義 DSL 是非常有價值的，因為 DSL 通過設置非常特定的范圍來幫助集中于特定的領域。一方面，小心設置的范圍可以確保領域?qū)＜乙越Y(jié)構(gòu)化和詳細的方式捕獲知識和專門技術。另一方面，專門知識和技能可由該領域的用戶提取并重用。
 |
| 閱讀 Wikipedia 對 DSL 和 DSM 的定義。有關這些術語的更多信息，請參見 參考資料。還可以在 Web 上找到更多有關 DSL 和 DSM 的信息。 |
|
DSL 的另一個重要方面在于，它使您可以指定粒度，這意味著在詳細描述和模糊描述之間尋求妥協(xié)，定義 DSL 部分將對此進行介紹。
為什么應該使用 DSL 而不是使用通用語言（general purposed language，GPL）呢？與 DSL 相比，GPL 使用足夠簡單和基本的詞匯來描述任何領域，而不描述明確細節(jié)?？梢允褂?GPL 來實現(xiàn)相同級別的領域表示和理解，但是與 DSL 方法相比，GPL 對關于該領域和通用語言的預期知識級別要求是相當高的。DSL 的一個主要優(yōu)點在于，它需要很少的時間即可理解和傳達某個領域的詳細信息。它需要很少的時間來學習使用相關工具。
例如，業(yè)務應用程序通常是使用復雜的軟件解決方案來實現(xiàn)的，但是大多數(shù)解決方案都使用相同的構(gòu)件（模式）來交付業(yè)務功能。DSL 使您可以對軟件解決方案進行抽象，并隱藏實現(xiàn)細節(jié)。DSL 還可以使用來自業(yè)務領域的詞匯，并為 IT 領域提供轉(zhuǎn)換。
遺憾的是，存在使用得非常糟糕的 DSL 的實例（或反模式）。在這樣的情況下，DSL 被用在錯誤的上下文中，并且通常是用于錯誤的目的。幾個反模式的示例如下：
- 具有錯誤上下文的 DSL，并混合了抽象級別（例如，混合了用例和用戶界面細節(jié)）
- 具有錯誤上下文的 DSL，并且未能分離關注事項（例如，混合了持久性細節(jié)和用戶界面細節(jié)）
- 具有太多約束的 DSL，這是由僵化的結(jié)構(gòu)所導致的（例如，復雜應用程序的配置細節(jié)）
- 具有太多元素（通常是由于未確定模式而導致的）或模型元素實例最終出現(xiàn)在元模型中的 DSL
- 具有冗余內(nèi)容（例如，混合了用于不同類型的用戶界面的用戶交互流，包括 Web 瀏覽器，以及網(wǎng)頁交互流）
定義領域
領域 是一個良好定義的主題方面，并使用一組有限的概念進行描述。DSL 和 DSM 中的領域通常以元模型的形式捕獲，如 圖 1 所示。設置恰當?shù)念I域范圍和正確地定義邊界是關鍵成功因素（將在稍后討論）。
可以使用不同的表示法、技術和工具以許多不同的方式定義 DLS 的領域。大多數(shù)情況下，為 DSL 指定的領域被描述為元模型。這是一種流行的方法，因為：
- 元模型是自描述性的，并使用 DSL 來捕獲 DSL 的元模型（領域）。
- 元模型相對容易理解；它們與實體關系模型非常相似。
- 元模型易于使用和重用于進一步的處理（模型驅(qū)動的開發(fā)）。
- 元模型非常適應模型驅(qū)動的體系結(jié)構(gòu)方法。
圖 1. 元-實例象限中的概念
使用實體關系模型是一種定義 DSL 的形式。還存在其他方法和形式，但是本文將集中于實體關系建模技術，因為此項技術與稍后將描述的技術更密切相關。Eclipse 的 EMF 項目也正在遵循實體關系建模技術來捕獲 DSL。實體關系模型相對易于捕獲、易于維護、易于使用工具來支持，并且概念通常得到了很好的理解。
定義 DSL
成功的領域規(guī)范的秘訣是擁有描述該領域的良好元模型。（稍后將討論良好元模型的要素。）捕獲元模型并不是無足輕重的任務，而是需要大量的技能和經(jīng)驗。技能可以通過實踐來獲得。捕獲元模型是某種類型的抽象，通常是架構(gòu)師應該具備的技能。此活動所需要的實際技能是能夠平面化層次（樹形）結(jié)構(gòu)。
存在各種捕獲元模型的不同方法和技術。以下示例也許可以幫助您著手開始此任務。
- 使用紙和鉛筆，開始繪制您希望獲得的結(jié)果的模型實例。務必記住以下幾個簡單概念：
- 您是在繪制圖而不是樹（盡管樹也是圖）。
- 使用方框來表示元素。
- 在方框之間使用直接連接。
- 使用方框中的方框來表示包含。
- 此時不要過于擔心外觀，雖然大致了解以后將如何表示元素也是不錯的。其他元素也是如此，例如連接。
- 開始考慮各個方框的屬性。
- 不要考慮元素的可視化放置；例如，左側(cè)的方框、位于 (10,10) 的方框 (x,y)。
- 考慮捕獲和繪制多個實例。
- 考慮捕獲同一個模型的不同表示形式（結(jié)構(gòu)）。此方法可以幫助您更好了解領域，優(yōu)化元模型，并使您可以開發(fā)工具友好的元模型。
- 一旦擁有了一組很好的模型實例，并且這組模型實例似乎表示了您希望捕獲和傳達的概念，即可開始使用建模工具（此處為 EMF）來捕獲元模型并平面化元素層次結(jié)構(gòu)。建模環(huán)境和工具的約束將指導您開發(fā)有效的元模型。
- 不存在用于測試元模型的簡單方法，因此最好的選項是反復試驗，直到該模型（基于已構(gòu)建的元模型）與預想的結(jié)果密切匹配。幸運的是，創(chuàng)建工具是方便快捷的，因此試驗過程也相對快速。
不要直接從該元模型的第一個實例構(gòu)建關系圖編輯器；應該首先使用更簡單的模型編輯器，例如 EMF 樹編輯器。
- 在樹編輯器按預期工作以后，就可以開始構(gòu)建第一個關系圖編輯器了。這很可能也是一個迭代過程，同樣應該使用反復試驗的方法。
該元模型可能不是“工具友好”的，意味著該元模型的約束不允許您按最初計劃的方式構(gòu)建可視化編輯器。在此情況下，唯一的選項是返回到最初的元模型，并嘗試使用不同的結(jié)構(gòu)和構(gòu)造來捕獲相同的概念。設計工具友好的元模型是一項從經(jīng)驗中獲得的技能。
在嘗試捕獲良好的元模型時考慮以下事項。
- 定義范圍
- 確保模型中捕獲的信息級別一致并且相關。僅捕獲相關信息；不要構(gòu)建或使用復雜的通用模型。在模型中捕獲適當級別的詳細信息，而不是混合不同的抽象級別。在捕獲元模型時應用關注事項分離原則（將模型組件化）。確保模型中捕獲的信息不會在開發(fā)過程中在其他模型中重復 DSM。在理想的情況下，所有的信息具有單個權威視圖或模型，其他模型只是反映內(nèi)容。
例如，基礎設施建模將從集中于位置和可能功能的概念性節(jié)點的捕獲開始，而不是考慮針對性能、可用性或類似特性的關注事項。下一步，您可以構(gòu)建一個更特定的模型，其中包括前面放棄的關注事項（性能、可用性等等）。在非常詳細的級別，該模型可以包括基礎設施的物理細節(jié)，包括網(wǎng)絡地址、計算機類型、規(guī)格等等。
- 粒度
- 不存在用于計算或決定正確粒度級別的神奇公式?？梢蕴岢鲆韵聠栴}以幫助您做出決定：
- 模型中應該捕獲多少信息？
- 需要多少信息才足以充分理解該領域并且易于傳達？
- 信息在什么情況下太多？
考慮粒度的一種方法是在模型中捕獲細節(jié)和在轉(zhuǎn)換中捕獲細節(jié)之間尋找平衡：
- 捕獲太多的細節(jié)就像是在使用某個模型或領域特定語言來開發(fā)代碼。在此情況下，留給轉(zhuǎn)換的細節(jié)所剩無幾。
- 未在模型中捕獲足夠的信息會妨礙適當級別的理解和傳達。在此情況下，大多數(shù)細節(jié)不得不包括在轉(zhuǎn)換中。
- 確定領域
- 使用 DSL，提出應該確定多少個領域的問題是恰當?shù)?。答案取決于領域的上下文。與許多 IT 術語一樣，領域 是一個被反復使用的術語。通常，在考慮要指定的領域數(shù)量時，您需要在兩件事情之間進行區(qū)分。
首先，始終存在可正確地稱為領域的更大領域。這始終適用于其中某些元素僅遠程相關的更大上下文。Java? 2 Platform, Enterprise Edition (J2EE) 應用程序就是一個示例。這個大型領域包括 Enterprise JavaBeans (EJB)、Servlet 和 JavaServer Pages (JSP) 組件以及其他相關構(gòu)件。
其次，DSL 中的領域上下文要比前一情況更小和更集中。在無法用特定的領域術語來表述的情況下，應該將這些領域稱為子領域或微領域。J2EE 應用程序中的 EJB 模塊就是一個示例。這個特定領域僅考慮各種類型的 EJB 和與之相關的構(gòu)件。
- 處理語義
- 所有可能的元素安排（詞匯）在領域中都具有特定的解釋。不存在有關如何安排語言元素或如何解釋這些元素的歧義性。需要在所定義的領域范圍中表示的所有事物都可以使用該語言 (DSL) 來表示。
元模型中定義的約束是語義的關鍵驅(qū)動因素。約束可以確保無效的安排不會出現(xiàn)在模型中。
- 工具友好性
- 對于元模型，工具友好性是指為特定元模型 (DSL) 設計和開發(fā)工具的容易程度?！肮ぞ哂押谩辈皇强茖W度量；它是一種從工具開發(fā)的角度表示模型質(zhì)量的方法。決定工具友好性是一項簡單的測試：如果很容易為模型開發(fā)工具（在此例中為關系圖編輯器），則模型是工具友好的。采用工具友好性是用于實現(xiàn)以下目的的很好做法：
- 更容易和更快的工具開發(fā)
- 快速的原型開發(fā)
- 加強的工具易用性
- 更好的領域理解
- 更好的模型構(gòu)造和更高的模型重用機會
遺憾的是，在捕獲元模型時，減輕工具開發(fā)人員的工作不屬于優(yōu)先考慮的事項。自底向上的方法通常產(chǎn)生工具不友好的元模型。然而，遵循自頂向下的方法（或任何其他方法）來捕獲元模型并不能保證工具友好性。
領域特定建模
在諸如 IT 等工程科學中，專家使用模型、關系圖和草圖來描述問題或解決方案的特定細節(jié)。對可視化表示形式的需要起因于圍繞該行業(yè)的高度復雜性。抽象和自動化論證了可視化建模需要的合理性。
IT 中的工程師處理各種輸入、輸出、工作產(chǎn)品和可交付件。一個輸出可能成為另一個工作產(chǎn)品的輸入。模型和關系圖通常就是實際工作產(chǎn)品或其中的一部分。信息流、先前成果的重用以及工作流自動化論證了使用模型而不是使用簡單關系圖的合理性。
構(gòu)建和使用工具方法應該實現(xiàn)：
- 架構(gòu)師或程序員對領域的更好理解
- 工具友好的元模型
- 非常高的重用可能性
- 有關易用性和可用性的信息
- 更接近元模型的設計
- 所捕獲的模型中可潛在地在其他場合共享和重用的語義
將 DSM 投入實踐
根據(jù)“一幅圖勝過千言萬語”的精神，使用為特定領域定義的元素的可視化模型表示形式可以完整地描述整個解決方案。盡管可以使用許多技術和技巧來為 DSM 提供工具支持，但是本文僅討論一個選項：使用 EMF 和 GMF 的 DSM。
 |
| 其他 developerWorks 文章介紹了如何將 UML 用于軟件工程，甚至用于 DSL/DSM 目的。（請參閱 參考資料。） |
|
在深入到使用 EMF 和 GMF 的細節(jié)之前，讓我們看一下 DSL/DSM 與統(tǒng)一建模語言（Unified Modeling Language，UML）路線之間的簡要比較。務必理解的是，存在不同的路線不是為了彼此競爭。
選擇 DSL/DSM 還是 UML？
在某些方面，使用 DSL 和 UML 的建模處于該范圍的兩個對立端。UML 是一種統(tǒng)一（或通用）建模語言；它可以支持幾乎任何模型。DSM 是一種領域特定 建模語言。它只能支持特定類型的模型。
使用 LEGO 玩具作為類比，將 UML 看作是一堆具有幾種不同顏色和幾種不同大小的基本標準積木塊。DSL 就像是中世紀騎士城堡工具箱中的一組大尺寸的砌塊、具有不同顏色和紋理的石塊——與中世紀城堡的整段石墻類似的大型元素。可以想象人們?nèi)绾瓮ㄟ^該工具箱建造非常吸引人的實用城堡。但是，在基本石塊基礎上建造起來的城堡缺乏適當?shù)念伾?、紋理和中世紀特征。
存在兩個單獨的技能方面：定義 DSL 所需要的技能，以及使用該語言所需要的技能。
- 開發(fā)該語言 (DSL) 或建模工具 (DSM)
- 使用 EMF 和 GMF 需要 EMF 的知識，EMF 不過就是一個實體關系建模工具。GMF 本身就是一種 DSL，您必須理解它才能開發(fā)圖形關系圖編輯器。
使用 UML2 的開發(fā)需要充分了解 UML2 元素、元素之間的關系，以及如何定義構(gòu)造型來對元素進行自定義。以圖形關系圖編輯器為例。如果該編輯器的功能不足夠，則存在某種程度的自定義空間，此自定義需要特定的開發(fā)技能。
- 使用該語言 (DSL) 或建模工具 (DSM) 本身進行開發(fā)
- 對于 EMF 和 GMF，一旦了解了特定的領域，開發(fā)是非常簡單的。
在 UML2 的情況下，開發(fā)人員必須熟悉特定的領域和 UML2 本身。
UML2 的用戶群比 EMF 和 GMF 更大，但是 EMF/GMF 陣營正在不斷發(fā)展（通過郵件列表上的活動和有關該主題的日益增加的文章數(shù)量可以判斷出這一點）。相反，談到開發(fā) DSL/DSM，EMF 和 GMF 通常是首選的技術。選擇 EMF 和 GMF 的主要原因是 UML 關系圖中缺乏對某些更復雜的構(gòu)造的支持。
在將 IBM? Rational? Software Architect 中的 UML2 與 RSA 中的 EMF 和 GMF 做比較時，團隊開發(fā)是一個重要的方面。除了基于 Eclipse 工作臺的標準團隊開發(fā)支持以外，Rational Software Architect 中的 UML2 工具還具有高級的建模功能以支持團隊開發(fā)。這些功能包括模型比較、差異突出顯示和模型合并。EMF 目前不具備相同級別的團隊開發(fā)支持。
探索 EMF 和 GMF 路線
EMF 是來自 Eclipse 工作臺的成熟技術。有關使用 EMF 的詳細信息超出了本文的范圍。有關高級功能的概述和信息，請參見 參考資料。
使用 GMF 進行圖形建模
作為 Eclipse 中的一個相對較新的項目，GMF 提供了一個為 Eclipse 工作臺開發(fā)圖形工具和關系圖編輯器的框架。該框架包括兩個部分：
- GMF 運行時（Eclipse 的一部分，并提供用于圖形工具的基本的公共元素和服務）
- GMF 工具（幫助進行使用 GMF 運行時的 Eclipse 插件的開發(fā)，以交付最終的建模工具）
GMF 本身的工具是一組專用于圖形建模工具開發(fā)的 DSL。從本質(zhì)上講，GMF 合并各種圖形建模工具中的功能、能力和模式（超集），從該工具超集中提取可變性，并最終為開發(fā)模式提供一個建模前端。
GMF 是用于為 DSL/DSM 開發(fā)工具的理想選擇，因為它：
- 方便快捷
- 遵循模型驅(qū)動的方法，無需編寫任何一行代碼即可產(chǎn)生結(jié)果
- 提供了可滿足圖形建模工具環(huán)境的大多數(shù)復雜和苛刻要求的完善級別
- 產(chǎn)生高質(zhì)量的工具
建模方法
圖 2 顯示了用于構(gòu)建建模工具、建模本身和在模型基礎上產(chǎn)生構(gòu)件的最基本方法。
圖 2. 基本建模方法
從本質(zhì)上講，如圖所示，存在兩個起點：
- 首先創(chuàng)建元模型，而不考慮最終構(gòu)件的關注事項
- 使用最終構(gòu)件來驅(qū)動元模型的開發(fā)或在最終構(gòu)件基礎上生成元模型
從元模型開始，開發(fā)人員必須建立該特定領域的元模型或語言。約束可以充實元模型，以確保模型實例的語義正確性和有效性。大多數(shù)圖形編輯器都可以在元模型的基礎上生成，但是其他部分則必須手動進行定義?？梢詾閳D形編輯器指定一組新的約束，因為圖形表示形式可能使用與原始元模型不同的構(gòu)造來進行建模?？梢允褂脠D形編輯器來創(chuàng)建和編輯模型實例。這些模型是模型驅(qū)動的開發(fā)的結(jié)果。模型成為轉(zhuǎn)換的輸入，以生成最終構(gòu)件（例如代碼）。
前面提到的兩個入口點與兩種基本的建模方法相關：自頂向下和自底向上。
自頂向下的建模方法首先捕獲元模型，然后開發(fā)轉(zhuǎn)換和代碼生成器以產(chǎn)生構(gòu)件。表 1 顯示了自頂向下的建模方法的優(yōu)點和缺點：
表 1. 自頂向下的建模方法的優(yōu)點和缺點
| 優(yōu)點 |
缺點 |
|
|
- 可能不會產(chǎn)生預期的構(gòu)件或提供用于生成構(gòu)件的理想輸入。
- 由于前述原因，正反向工程可能中斷。
|
自底向上的建模方法從構(gòu)件開始，基于實例構(gòu)建模型，最后在模型的基礎上定義元模型。表 2 顯示了自底向上的建模方法的優(yōu)點和缺點。
表 2. 使用自底向上建模方法的優(yōu)點和缺點
| 優(yōu)點 |
缺點 |
- 代碼（構(gòu)件）生成器要么很容易開發(fā)，要么是其中一個副產(chǎn)品。
|
- 開發(fā)元模型來表示構(gòu)件的概念和上下文是非常繁瑣的。
- 創(chuàng)建工具友好的元模型非常繁瑣，需要技能和專業(yè)知識。
|
上述兩種方法的組合是“中間相遇”(meet in the middle) 方法，此方法利用了前述兩種方法的優(yōu)點。開發(fā)從兩個方向開始，在概念元模型基礎上創(chuàng)建工具，同時基于構(gòu)件創(chuàng)建元模型。通過一組轉(zhuǎn)換建立所獲得的兩個元模型之間的聯(lián)系。表 3 顯示了這種組合方法的優(yōu)點和缺點。
表 3. 使用“中間相遇”方法的優(yōu)點和缺點
| 優(yōu)點 |
缺點 |
- 從現(xiàn)有的模型和構(gòu)件開始；不需要開發(fā)新的模型和構(gòu)件。
- 可能獲得預期用于圖形建模和用于生成構(gòu)件的結(jié)果。
|
- 需要深入理解現(xiàn)有的元模型（自頂向下和自底向上），因為它們很可能來自于不同的來源。
- 很可能需要附加的開發(fā)或使用映射工具來進行轉(zhuǎn)換。
|
實際上，自頂向下的方法很少產(chǎn)生元模型以支持開發(fā)構(gòu)件的生成。這種方法對于捕獲概念及其關系是非常出色的。類似地，自底向上的方法很少產(chǎn)生可有效地傳達或描述特定領域的元模型。盡管可以遵循純粹的自頂向下或自底向上的方法，但這樣充滿了挑戰(zhàn)。
約束
約束和驗證經(jīng)常作為與元模型和 DSL 相關的主題一并進行討論。約束 確保模型實例在語義上是正確的。驗證 是檢查模型實例上的約束的過程。驗證還可以為建模人員提供反饋，從而幫助糾正模型。
用 DSL 術語來說，約束確保使用該語言的詞匯來構(gòu)造的句子是有意義的。可以通過不同的形式定義元模型的約束，包括使用：
- 某種約束語言，例如 OCL
- 特定擴展點的某種編程語言，例如 Java
- 正則表達式，例如 regexp
約束不僅限制模型中的某些構(gòu)造，其中某些約束還可以計算和填充元素的值。還可以在元模型中捕獲一些較簡單的約束，而不需要用于支持復雜約束的擴展。這些約束可以是必需屬性、基數(shù)或預定義（缺?。┲怠?
|
| 有關約束和使用約束來進行圖形建模的更多信息，請參見 參考資料。 |
|
轉(zhuǎn)換
轉(zhuǎn)換用于將表示源實例的數(shù)據(jù)和結(jié)構(gòu)映射到表示目標實例的新結(jié)構(gòu)和數(shù)據(jù)。轉(zhuǎn)換中的源和目標可以是模型或任何其他構(gòu)件。用 DSL 術語來說，轉(zhuǎn)換是不同領域之間或某個領域和其他構(gòu)件之間的映射操作。之所以需要轉(zhuǎn)換，通常是因為實例（模型或構(gòu)件）在不同的領域中、具有不同的格式或具有不同的版本。實際上，轉(zhuǎn)換可用于各種目的，例如：
- 在模型基礎上生成代碼
- 將一個或多個模型映射到另一個模型（一對一或多對一）
- 在代碼構(gòu)件基礎上生成模型
在使用轉(zhuǎn)換時，具有相同元模型的模型實例之間的幾個轉(zhuǎn)換示例包括：
- 充實或擴展源模型
- 初始化源模型
- 更改源模型中的數(shù)據(jù)（包括版本更新）
GMF 應用程序的開發(fā)過程中有一組用作示例的很好轉(zhuǎn)換。GMF 儀表板（Eclipse 視圖）甚至提供了轉(zhuǎn)換步驟、構(gòu)件及其關系的可視化表示形式。
開發(fā)過程
為 DSL/DSM 開發(fā)工具是一個高度迭代的過程，如下所述。
- 開發(fā)元模型?？梢酝ㄟ^各種格式捕獲元模型，例如 XML 模式 (XSD)、帶注釋的 Java 代碼、ECore 模型或 Rational Rose? UML 模型。
- 生成基本工具將產(chǎn)生一個簡單的樹形編輯器。此編輯器已經(jīng)是一個可用的工具，沒有新奇的功能，僅用于滿足基本的編輯需要。
- 使用該基本工具來測試模型。重復從步驟 1 開始的步驟，直到達到預期的結(jié)果。
- 通過以下方式創(chuàng)建并指定工具模型：
- 創(chuàng)建工具面板 (.gmftool)。
- 創(chuàng)建圖形元素及其可視化表示形式 (.gmfgraph)。
- 創(chuàng)建領域模型、圖形和可視化元素以及工具面板之間的映射 (.gmfmap)。
- 在前面步驟中指定的模型的基礎上生成工具。
- 測試該圖形建模工具。
從步驟 4 開始重復，直到達到預期的結(jié)果。
此時，基于某個元模型的圖形建模工具已經(jīng)可用了。如果該建模工具產(chǎn)生輸出，此輸出可能只是一個持久化的模型實例，則無需做其他工作。如果預期該模型將用作所生成的構(gòu)件的基礎，則很可能必須開發(fā)一組轉(zhuǎn)換。
下面的圖來自于 GMF Eclipse 項目中附帶的 Mindmap 示例。這些圖顯示了一組用于開發(fā) GMF 工具的典型模型和項目構(gòu)件。圖 3 顯示了 Mindmap 工具。
圖 3. 用于 Mindmap 工具的 .ecore 模型
圖 4 顯示了工具面板定義。
圖 4. 工具面板定義
圖 5 顯示了圖形元素和形狀定義。
圖 5. 圖形元素和形狀定義
圖 6 顯示了 .ecore 模型、工具面板以及圖形節(jié)點和形狀之間的映射定義。
圖 6. .ecore 模型、工具面板以及圖形節(jié)點和形狀之間的映射定義
圖 7 顯示了項目細節(jié)和構(gòu)件。
圖 7. 項目細節(jié)和構(gòu)件
圖 8. 帶有所有模型的 GMF Dashboard
開發(fā)和運行時環(huán)境
Eclipse 是使用 EMF 和 GMF 來進行 DSL 和 DSM 開發(fā)的開發(fā)環(huán)境。IBM 的 Rational Software Architect 包括了為 DSL 和 DSM 開發(fā)工具所必需的所有 Eclipse 項目。相關項目包括 EMF、GEF、GMF、UML2 和 EMFT。Eclipse Modeling Project 具有這些項目的詳細信息。前面描述的工具開發(fā)的結(jié)果是 Eclipse 插件。本質(zhì)上，工具的運行時環(huán)境是 Eclipse 工作臺。
主要開發(fā)用于建模的插件的兩種使用形式如下：
- 安裝在現(xiàn)有的 Eclipse 工作臺之上，使其成為開發(fā)環(huán)境不可或缺的一部分。
- 安裝為獨立插件，仍然使用 Eclipse 工作臺，但是獨立于 Rich Client Platform 之上的其余開發(fā)工具而運行。
總結(jié)
領域特定語言和領域特定建模是許多不同 IT 角色（甚至 IT 以外的角色）的工具箱中的強大工具。通過使用 DSL 和 DSM，IT 架構(gòu)師可以清楚理解他們所處理的領域，并且能夠更有效地傳達該領域的細節(jié)。然而，務必記住 DSL 和 DSM 不是解決所有問題的萬能答案——它們的適用性取決于所構(gòu)建的語言和工具的優(yōu)劣情況。
參考資料
學習
獲得產(chǎn)品和技術
討論
關于作者
|
|
|
|
Peter Kovari 是英國 Hursley 的 IBM Software Group Services 組織的成員。他的職責范圍從專家領域到各種 IT 體系結(jié)構(gòu)。他經(jīng)常前往客戶所在的地點，幫助客戶正確地采用 IBM 的各軟件產(chǎn)品系列。在此以前，Peter 曾是北卡羅萊納州 Raleigh 的 ITSO 的一名 IT 專家、項目負責人，并與其他來自世界各地的 IBM 專業(yè)人員一同編寫 IBM Redbooks?。
|
|
