概念: Model-Driven Development (MDD) 與 Model Driven Architecture (MDA)
本指引介紹 MDD 和 MDA, 這兩者的主要目的是要強調模型在軟體工程中的角色。
關係
相關元素
主要說明

簡介

在 Rational Unified Process 中,模型是一種重要的工作成果, 並且(在 RUP 中)通常是用和工具及環境中立的「統一建模語言 (Unified Modeling Language, UML)」表示, 因此 RUP 可以用許多不同的工具集部署以及用在許多種環境中。 支援資料:視覺化建模會探討建立模型的某些原因,這些包括:

  • 協助瞭解複雜的系統
  • 作為低成本的實作基礎,用來探討及比較各種不同的設計方式
  • 精確地掌握需求
  • 明確地表達決策

模型可以看作是用來解說系統行為(屬意的行為和實際實現的行為)和結構, 以及用來向感興趣的關係人表達這些思慮計劃的一種方式。 MDD 和 MDA 著重於將模型的角色當作是實作方式的基礎元素,並認為模型 除了可供開發人員用來作為撰寫程式碼的藍圖,同時視支援工具集的功能, 還可以可以啟用和執行到某種程度。這個方式從很早開始就依循一個趨勢, 逐漸提高開發人員處理的抽象層次。這種方式將焦點從我們都熟知的程式碼, 轉移到以更高層次的語言,並且可能是圖形的方式,來表達模型。 RUP 會將某些構件當作模型,而不是當作包含模型圖片的文件(例如用於擷取需求和設計), 來隱含地支援這種可行性。

見解與視圖 頁面頂端

見解如其名所暗示,是一種概念性的位置,用來顯示出系統(或代表系統的一組模型) 的一些層面或是對於系統的顧慮、暗示一組概念的應用方式,以及構成概念過濾器的一些規則。 「視景」一詞的用法也很相似,是用來說明用於檢視和瞭解最適合各式各樣關係人的 不同定位與顧慮的模型。

視圖是模型的投射,可以顯示出和特定的見解或視景相關的實體。

在 MDD 中,見解和視圖是用來區分顧慮,例如,用來將邏輯結構和實體結構及流程結構分開處理。 模型和問題領域愈接近,見解或視景就能愈完整地對映到關係人的商業考量; 所開發的模型愈接近可執行型式,就愈能照顧到運算方面的顧慮。 在這種情況中,其目標都不僅只是產生被動的例證而已, 但是有可能產生實作方式的模型,至少都可以滿足這些不同的顧慮。

詳述與轉換 (轉換)頁面頂端

這些術語通常是用來區分由手動(詳述)完成的模型變更,以及由工具(轉換)完成的模型變更。 在 RUP 中,詳述則擁有極為不同的正式意義,在其中詳述是某個生命週期階段的名稱, 但是在本節中,我們卻要用這個名詞來非正式地說明模型演進的各種極為不同的方式。

轉換和詳述也具有極為不同的步驟大小意義,在此模型會在許多個小步驟中進行詳述, 直到具有足夠的詳細資料(包括語言、基礎架構或作業系統明細)可以供工具或以手動方式產生程式碼為止。 在這裡的手動是指人員透過查看模型之後,就能撰寫 Java、C++ 或其他語言, 並且可能會在撰寫過程中進一步的詳述。而在與此對照的轉換中,模型仍然是處於 不受語言、基礎架構或作業系統顧慮影響的抽象層次,並且只需要做少量的進一步詳述, 或完全不需要進一步詳述,就可以會轉換為可以執行並產生屬意的結果。 請注意,屬意的結果包括效能以及其他非功能方面的性質。 因此,這種方式的隱藏涵意是這種跨越架構的顧慮,會以模型的建構方式,以及模型說明資源需求的方式表達。

換句話說,術語定義:轉換在這裡是用來說明依照一組規則,從來源模型產生目標模型, 並且依照一組參數工作的過程。請注意,模型在這裡的用法和在 RUP 中相同, 因此目標模型可以是實作元素,例如,程式碼或文字。當然,轉換也可以手動進行, 這種方式會進行和詳述相等的一連串轉換(添加詳細資料),並且其規則可以極為複雜, 並深植於現有技術和領域的使用經驗。不過,它的預設意義是轉換是自動完成的, 這會在下一節的 Model Driven Architecture® 中再度探討。

請注意,轉換構想只包括來源模型和目標模型。一般的情況是目標模型的抽象程度要比來源模型來得低, 也就是說,目標要比來源具體,但是轉換構想中並沒有隱含這個涵義。 請注意轉換也可以添加詳細資料至模型,因而產生更精細的目標模型, 同時仍大致保留相同的抽象層次,因此就不會引進和其他領域無關的資訊。 與此不同的是會從 UML 模型產生程式碼的轉換,這種轉換會在此目標模型中引進 商業關係人不重視的內容,只要目標模型仍然維持必要的行為和非功能性質即可。

是否有能力調整轉換構想的大小,是看工具的功能,以及我們是否有能力 編撰、擷取及重複使用資深人員採用的知識而定。 所需要擷取和編撰的知識數量,是看用以進行轉換步驟的抽象層次而定, 抽象層次愈高,通常就需要愈多知識,並且愈和領域相關。

在 MDD 中,我們的宗旨是要將用來自動產生可作業系統的抽象層次提高。 模型會詳述到可以用來產生一些結果的階段。 接下來較偏好的做法,是輸出不需要做進一步的詳述,就可以執行。 此外,我們的企圖是要使用一連串的自動化轉換,將領先的詳述推得愈深入愈好。 因此,這兩種方法的涵蓋面是:轉換由一連串的自動化轉換步驟實現,並且盡可能愈多自動化愈好。 最終的轉換為執行系統步驟是在模型說明仍處於高抽象層次時發生, 這會使用轉換引擎中編撰選擇的技術、基礎架構和目標語言,以及使用提供給轉換的規則與資料。

MDD 的另一項優點是我們希望它可以重複使用轉換,這個做法是在轉換中編撰平台規則與領域知識, 以及由相對應的領域專家建立的最佳實務。採用這種做法是,只要使用少量的資深開發人員, 就可以促進重複使用,並且可以避免在每個新的應用程式都從頭開始重新建立。

何謂高抽象層次?頁面頂端

這個有幾種看法。一是從語言的角度來看,我們可以看到產生諸如可執行的 UML 型式。 另一種是從領域工程的角度來看,其中的語言和建模概念都和領域相關。 例如,UML 是一般用途的語言,因此在這個角度中,您可以看出使用術語定義:UML 設定檔來指定 UML 的用途。另一種方式是要避免使用特定的供應商、 基礎架構特定的模型,以便能採用新的技術。

就詳細的動態表示而言,在 UML 動作語意完成的工作就已經可以產生可執行的 UML 型式,但是具體的語法和表示法卻沒有標準化, 並且「動作語意」的層次也和其他物件導向 (OO) 語言不同。因此,UML 加上「動作語意」不一定是最終做法, 不過可以指出一個方向。

我們的結論是就這個定義來看,以 UML 表示,或是使用 UML 設定檔的模型, 若其中沒有包含和供應商相依的元素,就不需要仰賴特定的基礎架構平台,例如 J2EE 或 Microsoft® .NET,並且其結構和行為的語意完整,不需要依賴特定的程序語言(Java、C# 等等), 就是高抽象層次,不過仍然有「動作語意」的層次議題存在。

從問題領域的角度來看,也就是使用者或商業客戶的見解, 一項可行並且吸引人的解決方案是構成領域特定的建模語言。 這些語言是抽象的,因為它們都是特定領域的工作者熟悉的名詞和概念, 但是卻有完整的能力可以表示模型動態,但同時是以 UML 為基礎。

這和 RUP 有何相關? 頁面頂端

「RUP 分析」、「設計」及「實作模型」的關係彰顯了這些信念:分析模型代表使用案例中表示的行為要如何實現的初期觀點;行為會以說明型式串連起來,以處理問題領域, 並且其中包含的分析類別,會被當作是必要的職責與行為的概念分組。 「分析模型」通常不會完整到可以執行,因為其中會缺少許多東西, 只有人員在讀取模型進行思考實驗時,自行填入許多空白時例外。 因此「分析模型」必須通過細調過程、添加詳細資料和精準度,才能產生設計模型

RUP 可讓專案使用個別的「分析模型」,或將「分析模型」視為演進為「分析模型」基礎。 RUP 作業會詳盡說明修正過程,並且其預設的前提為扮演「軟體架構師」和「設計師」的工作人員 會達成此項演進工作,當然此過程可能會藉助使用一些工具。 請注意,此項修正可以想成是一系列的模型轉換,其中的部份工作可能可以自動化, 例如在架構分析識別設計機制等 RUP 作業中用名詞定義:分析型樣名詞定義:設計型樣等型樣。

設計模型在什麼時候算完成? 頁面頂端

在專案生命週期內,「設計模型」會經過多個重複作業而不斷演進; 因此,「設計模型」(或其中的一部份)何時能轉換為程式碼,亦即我們什麼時候可以開始產生 實作元素,並將實作元素整合到屬意的系統建置中?RUP 有針對從設計對映到程式碼提供一些指引,不過,基本上這個問題並沒有確定且快速的回答。 進入實作程序的時機,是例如當您在進行審查時,您認為您已經可以開始進行實作了, 不過這個時間點卻可能會因組織和專案而異。 RUP 有提供多個方法可以從設計轉為程式碼,我們會在這裡討論其中兩個方法, 說明如何決定設計是否完成了:

1. 以草稿撰寫程式
RUP 指出「進行設計的一個常用方法是草擬出仍然很抽象的設計, 然後直接移到程式碼。設計模型是由人工維護」。

若要成功使用這種方式,程式開發人員必須能銜接設計和實作層次之間的間隙。 維護設計模型通常被視為是次要的,並且程式會成為注意的焦點。

2. 使用單一演進設計模型的來回工程 (RTE)
RUP 指出:「在這種方式中,只會有一個「設計模型」。初步草擬的設計元素都會演進為和程式碼同步」。

在這裡,開發人員會透過一系列的建模步驟,來銜接抽象間隙。這種方式和「以草稿撰寫程式」 的差異在於這種方式會顯現出中介步驟,並且在最後階段時,設計模型的抽象版本就會消失不見。

在這兩種方式中,都會喪失抽象設計模型的潛在價值:在「以草稿撰寫程式」中, 由於通常並不會維護抽象設計模型,因此在一段時間後,設計模型就會和程式脫節, 而在「單一演進設計模型」中,抽象版本則是會消失不見。 即使是有保留初步的版本,也仍然會遇到和以草稿撰寫程式的設計模型相同的情況。 請注意,使用 RTE 的設計模型在最後時,事實上就是程式視覺化, 並且只要運用適當的工具,就可以將以草稿撰寫程式所產生的程式碼, 以反推工程方式進行類似的視覺化。在 RUP 中,我們會略微減輕抽象設計模型的流失, 我們的做法是在「軟體架構文件」的重要處,擷取大量的架構視圖與設計理論基礎。

MDD 可以協助使用抽象的設計模型來產生程式碼,並使抽象的設計模型可以存留久一點。 抽象的設計模型成為主要的維護基準,並且事實上可能是唯一的維護基準。 抽象的設計模型也對設計的最終狀態提供了清楚的定義,亦即就轉換引擎而言, 這時模型已經完成、一致、明確,並且可以轉換為可執行系統。模型的抽象層次會視可用的技術和工具集而定 (如需範例請參閱說明書籍圖示 導覽:Rational Software Architect 概觀),並且也可能和領域有關。 請注意,就 MDD 而言,這只是其中一項轉換(由設計轉為程式碼),不過這卻是跨越抽象層次的一個重要轉換。

下一節會說明 MDD 的新興架構標準,稱為 Model Driven Architecture® (MDA®), 這是 Object Management Group (OMG) 的創作。

Model Driven Architecture (MDA) 頁面頂端

動機 頁面頂端

MDA 是 OMG 的創作,OMG 是一個由約 800 名成員組成的業界公會, 該公會的使命是要建立一套標準準則和規格,為應用程式開發作業提供一個通用的非關供應商架構, 並促進主要硬體和軟體基礎架構平台之間的交互作業能力能力。 「統一建模語言」就是 OMG 的產品之一。OMG 目前在促銷 MDA 作為其旗鑑規格, 並且以 OMG 的地位作為實用標準的傳播者,希望使那些標準能廣被業界 IC、慣例、產品和工具支援, 由於 UML 的成功引用,使得 MDA 值得進一步認識瞭解。有關 MDA 的資訊相當多, 這包括在 OMG 網站上提供的 最新 MDA 準則 [OMG03]。 此外也有一些書籍可以參考,例如 [FRA03], [KLE03], and [MEL04], 以及許多文章,例如 2004 年 5 月版的 The MDA Journal 之 An MDA Manifesto, 作者為 Grady Booch、Alan Brown、Sridhar Iyengar、James Rumbaugh 以及 Bran Selic。

MDA 的核心構想To top of page

MDA 引進一些特定的概念和術語,將一般的做法和 MDD 做區分,這些會在以下的章節中定義及討論。

以現有的標準為基礎 頁面頂端

MDA 是由一些現有的 OMG 標準界定,這些標準包括:

  • Meta-Object Facility (MOF) - 除了定義建構 Meta 模型的語言,如 UML 和 CWM, MOF 也定義了實作模型及 Meta 模型儲存庫的架構,以便在使用 MDA 時,能以一致的方法來操控這些模型。 因此 MOF 就變成 MDA 的必要技術。
  • 統一建模語言 (UML) - UML 中定義了 PIMPM 以及 PSM, 因此 UML 是 MDA 的基礎表示法。
  • XML Meta 資料交換 (XMI) - XMI 依據 XML 來定義 UML 模型交換格式。
  • 共用倉儲中間模型 (CWM) - 如同 UML 是用來建立應用程式模型,CWM 則是用來建立資料模型。

平台獨立頁面頂端

根據名詞定義:平台的字面意義,是它可以支援較高的架構層次,它的做法是用一組定義完整的介面服務, 來隱藏實作細節。OMG 的平台定義(在 MDA 準則中)為:

「一組子系統/技術,透過介面和指定的使用型樣提供一組一致的功能, 讓依賴平台的任何子系統在使用時,都不需要顧及平台提供功能時的實作細節。」

這和 RUP 中使用的名詞定義:層次概念相似。

平台相依一詞則比較不明確:這是指模型的一種品質或性質,例如如果 模型沒有參照由特定的平台提供的任何服務或功能時,我們可以說該模型是與該平台獨立。 不過,此項陳述是相對的,因為平台獨立極難界定。 「MDA 準則」有指出這一點,並且承認與特定平台有關的平台獨立可能性程度, 例如模型使用特定平台的一般特性。

要達到平台獨立,是要靠諸如 J2EE、.NET 和 WebSphere 等的平台演進協助, 才能提高外曝於應用程式的抽象層次。這種方式就比較容易追蹤識別與平台無關的建構, 並且也比較容易撰寫用於轉換那些建構的平台專用轉換。

平台獨立的模型 (PIM) 頁面頂端

這裡的準則是模型如果不限定於特定平台的用法,並且適用於同類型的任何平台, 該模型就可以稱為 PIM。在先前的章節中,我們討論過高抽象層次的構想, 並且結論是以 UML 表示(或是使用 UML 設定檔)的模型,若其中沒有包含和供應商相依的元素, 該模型就不需要仰賴特定的基礎架構平台,並且其結構和行為的語意完整,不需要依賴特定的程序語言, 在理論上至少是可以執行,並且是高抽象層次。這種模型算是平台獨立嗎? 答案是「是」和「不是」。如果是假想的 UML Virtual Machine 時,是「不是」, 但如果是這種 Virtual Machine 依賴的整個平台類別時,則為「是」。

平台模型頁面頂端

平台模型是指一些概念(代表零件和服務)、規格、介面定義、限制定義以及應用程式要使用 特定平台時,所需要的任何其他需求等的集合。在 MDA 中,會以如 UML 來詳述及格式化平台模型, 並且置於符合 MOF 的儲存庫中。例如,可以針對 J2EE 或 .NET 等建立平台模型。

平台特定的模型 (PSM) 頁面頂端

將 PIM 加上一些資訊,使其適用於特定的一或多個平台,就可以將 PIM 轉換為一或多個 PSM。 PIM 和 PSM 都會指定相同的系統,不過 PSM 會受限於特定的技術,並且可能會包含平台專用的元素。 請注意,這並不是暗示轉換步驟(PIM 轉換為 PSM、或其相關聯的平台)是大或小。 轉換是指應用一小組型樣來修正模型,並且在某種程度內,將該模型設定為更專用; 因此此動作會專注於 PIM 和 PSM 的術語相關性。

見解與視圖頁面頂端

這些術語在 MDA 中的用法和在 MDD 討論過的用法相同:

  • 見解如其名所暗示,是一種概念性的位置,用來顯示出有關系統的一些層面或是對於系統的顧慮、 暗示一組概念的應用方式,以及構成概念過濾器的一些規則。 只要有抑制有關系統的某些資訊,就是一種抽象型式。視景一詞的用法也類似。
  • 從見解中,您可以看到視圖,視圖是模型的投影,會顯示與該見解相關的實體。

MDA 會指定系統上的三個見解:一個與運算獨立的見解、一個與平台無關的見解, 以及一個平台特定的見解。

運算獨立的見解 頁面頂端

從與運算獨立的見解中,您注重的是系統的環境定義、用於操作系統的需求與限制, 以及系統必須與之互動的環境項目。從這個見解中,並不會看到系統結構或行為的詳細資料。

運算獨立的模型 (CIM) 是運算獨立的見解之系統或備援系統之視圖。 CIM 在概念上等於 RUP 中的「領域模型」組合,「領域模型」是一組構件, 其中包括「商業名詞解釋」以及「企業分析模型」,它是「作業:開發領域模型」(在「商業模型」中) 以及「使用案例模型」(這是系統行為中,與運算無關的說明)的輸出。 CIM 是以主題或領域專家的語言表示,這是在分析與設計期間, 識別備援系統的主要摘要時的重要鏈結。

平台獨立的見解 頁面頂端

平台獨立的見解是和特定的平台相對。您可以從該見解中看出系統的結構和行為, 但不會看到該平台的詳細資料。PIM 是平台獨立的見解中的一個系統視圖。

平台特定的見解 頁面頂端

從也是和特定的平台相對的平台特定的見解中,您可以看到會在平台獨立見解中出現的項目, 但現在也可以看到平台使用情況詳細資料。PSM 是平台特定的見解中的一個系統視圖。

自動化轉換頁面頂端

轉換是 MDA 的基礎構想,並且將模型轉換定義為「將一個模型轉換為相同系統中的另一個模型的流程」。 MDA 也會定義一個小的型樣,來顯示出轉換,並說明使用我們已經看過的一些術語:

MDA 型樣,顯示 PIM 及其它相關資訊作為轉換輸入,並顯示 PSM 和轉換記錄作為輸出。

MDA 型樣

這個圖解的用意是要顯示出轉換是極為重要的事情:轉換會合併 PIM 及其它相關資訊,以產生 PSM。

當然,模型轉換也可以手動進行。不過這會和軟體設計通常採用的方式略微不同。 即使在這裡,MDA 也有助於描繪及格式化轉換構想、過程以及要使用的額外資訊。 MDA 也建議製作轉換記錄;轉換記錄可以為從 PIM 轉換為 PSM 提供絕佳的追蹤能力, 因為其中會包括從 PIM 元素轉換為 PSM 元素的對映表。 大部分的運用都是來自有能力進行自動化轉換,即使只是做局部的轉換, 也因為使用高階語言取代組合程式設計,而獲得相同的好處。

轉換如何進行? 頁面頂端

MDA 並未規定要使用單一方式來進行轉換:它只準備一個平台選擇的對映表, 來提供如何針對該平台,將 PIM 轉換為 PSM 的規格;這個對映表因而產生了一項轉換定義 (可能是以一組轉換規則表示),其中可能包含轉換參數,並且是以轉換定義語言撰寫。 請注意,OMG 發佈了 RFP (MOF 2.0 Query/Views/Transformations RFP), 希望將建立模型視圖、查詢模型以及撰寫轉換定義的語言(針對 MOF)標準化。 「MDA 準則」中有說明進行轉換的數個方法,包括:

  • Meta 模型轉換 - 這個方式假設用於建置 PIM 的語言中,有 PIM 層次的 MOF Meta 模型存在。 同理,在選擇的平台中,在用於建置 PSM 的語言中,也有 PSM 層次的 Meta 模型存在。 這兩個 Meta 模型的對映表可以用來建構轉換定義;再用轉換定義將 PIM 轉換為 PSM。
  • 標示 - 備妥選擇的平台對映表。此對映表可以用來建構轉換定義, 轉換定義中包括一組標記,可以用來標示 PIM 的元素,因而產生一個「標示的 PIM」, 以及應對做這種標示的元素採取什麼動作之定義。接著轉換標示的 PIM,以產生 PSM。 標記通常是一項手動過程,不過後續的轉換則可以自動化。
  • 模型轉換 - 依據平台無關的類型建置 PIM, 並在模型中指定 PIM 內的元素, 是和平台無關類型的次類型。選擇一個特定的平台,將該平台和一組平台專用的類型建立關聯。 在兩個類型集之間建立對映表,以產生轉換定義,再將此轉換定義套用至 PIM, 即產生以平台專用類型的次類型表示的 PSM。這個方法和 Meta 模型轉換類似, 不過這裡的轉換受限於模型類型,而不是 MOF Meta 模型的概念。
  • 型樣應用 - 用一組和平台無關的類型與抽象型樣建置 PIM。 在選擇的平台中,會有一組平台專用的類型和型樣存在。在兩個類型和型樣集之間建立對映表, 產生出轉換定義,以便套用至 PIM。如此產生的 PSM,其中的抽象型樣會和平台相關。

如需詳細資訊,請讀者參考 MDA 準則 [OMG03]。

如何套用轉換? 頁面頂端

最簡單的 MDA 應用實務為:

  1. 準備一個 PIM
  2. 選取一個平台
  3. 如果還沒有對映表存在,就準備一個對映表
  4. 套用轉換,以產生 PSM
  5. 將 PSM 轉成程式碼。如果 PSM 不需要做進一步的修正,並且可以直接實作時, 這就是如下一節說明的實作

也可以用相同的方式,產生適用於其他平台的 PSM。

重複應用 MDA 型樣頁面頂端

不過,MDA 型樣也可以重複應用:在某個層次產生的 PSM,就變成下一個層次的 PIM, 也就是說,下一個更特殊化的平台選擇。請注意在 MDD 中,如在 RUP 中的說明並且以 IBM Rational 工具集支援時, 我們的希望是要縮減修正步驟數目,亦即盡量直接從接近客戶的問題陳述表示,推進到可執行型式。

MDA 型樣的三種重複的應用,適用於三個不同平台

重複應用 MDA 型樣

上圖展示 MDA 型樣的三種應用,最初的 PIM 變成依賴平台 1 的 PSM,然後再度轉換成依賴平台 2,最後再轉換成依賴平台 1、2 和 3。

一般的模型轉換模型頁面頂端

這個概念也可以套用在一般的轉換,亦即從任何模型轉換為任何模型。 假如有兩個 Meta 模型存在,並使用 Meta 模型語言來表示模型, 在原則上,就可以建立對映表,來產生轉換定義。這個原則適用於我們先前已經討論過的由 PIM 轉換為 PSM。

實作頁面頂端

MDA 準則使用「實作」的方式,和 RUP 的「實作模型」用法類似。 這是指建構、部署、安裝以及操作系統時,所需要的所有實作元素

PSM 本身也可以實作,或可能需要做進一步的修正後,才能轉為程式碼。 請注意,產生實作 PSM 時,可以略過顯示 PSM 的步驟,直接跳到程式碼。 在此情況下,愈抽象的 PIM,就容易由轉換引擎直接轉成程式。但是仍可能要向程式開發人員提供程式的視覺化型式, 以協助他們瞭解程式,不過視覺化型式可以從程式進行反推工程產生。

假想的好處頁面頂端

可攜性與交互作業能力頁面頂端

MDA 提供可以控制成本以及技術更動的希望,它的做法是可以依據新技術的任何需求, 重新產生一組相當穩定的 PIM。這個做法的希望是提高 MDA 的可接受度, 讓新技術的開發人員也能同時提供對映表,以便更快速完成轉換。

MDA 建議在延伸兩個平台之間的 PIM-PSM 對映表時,能建立兩個 PSM 之間的「銜接」, 以及最後兩個實作之間的銜接,使 PIM 能分散到多個平台。大部分公司都會面臨針對 混雜新舊技術的異質環境開發系統的現實情況,因此這項實現交互作業能力的能力,就具有極大的潛在好處。

縮減生命週期成本頁面頂端

生產力頁面頂端

使用 MDA 進行開發時,會產生更抽象的 PIM。使用功能更強的工具集來產生 PSM(或程式)時, 這種環境的生產力,應該和使用高階語言會比使用組合程式更有生產力一樣, 特別是通常會開發的 PIM 或和其類似的東西,例如作為 RUP 中的「設計模型」。 在生產力方面的效益,是看在轉換過程中,需要多少人工介入而定。

品質頁面頂端

在 MDA,理想的情況是其維護的目標是 PIM。因此,只要 PIM 的架構完整, 在產品的生命週期中出現的問題就會較少,因為透過自動化轉換的好處, 人為產生錯誤的機會會減少,並且所發現的問題只要花極少的成本就可以更正。 專注於 PIM 也會和領域的顧慮緊緊相連,因此更有可能滿足使用者的需求。