[转载] MDA—軟體開發的新思維

台湾人写的MDA入门介绍文章，是我喜欢的风格：一贯的实在和清晰，不用堆砌的名词、概念和不需要的形式化来砸人。这篇文章是2004年12月发的，但其中遗漏了对MDA中重要标准QVT的介绍。

转自http://nmlab.mis.nchu.edu.tw/course/93/nightelearning/wblog08/archives/002914.html

MDA—軟體開發的新思維

強調模型與實作分離的MDA，顛覆過去程式導向的開發方法，只要抽換底層的技術平臺，工具即可產生對應的程式碼...

需求搜集難以自動化
MDA的好處
由模型驅動程式的修改
強調模型與實作分離的MDA，顛覆過去程式導向的開發方法，只要抽換底層的技術平臺，工具即可產生對應的程式碼，因此開發人員應回過頭來重視設計與塑模，並強化本身的價值，純粹寫程式的工作，將淪為廉價勞工。



早期企業傾向自行開發應用程式，由於成本過高，1985年開始盛行商用套裝軟體，企業不再自行開發軟體，只要購買功能完整的商用軟體，再依各別需求加以客製化即可，省去自行開發的成本。1995年以後由於中介軟體（Middleware）的興起，資訊系統程式元件化的程度很高，MDA（Model-Driven Architecture）以模型驅動軟體開發的概念，也因此得以逐漸成形。



2001年OMG組織提出了MDA的架構，希望設計階段的模型與實作階段程式碼脫鉤。由OMG組織提供的MDA示意圖，解讀其概念，MDA運用UML、MOF、OCL及CWM等技術，建構業務導向的模型，只要抽換技術平臺，模型即可轉換成.NET、Java、CORBA、Web Services等程式架構，提供各類服務、事件處理、安全機制、交易及目錄服務等商務應用，甚至可因應抽象模型的調整，將商務應用對應到醫療、電子商務、製造業、財務、電信等不同領域。



從軟體開發的流程來看，需求分析、設計、開發、測試到部署上線的流程中，IDE（Integration Development Environment；整合發展環境）演進，第一、二代的產品專注於介面的友善及方便性；當功能發揮到極致，第三代的產品開始向程式開發的前後延伸，提供模型設計及功能測試的功能；第四代IDE尤其是Java的IDE工具，可針對不同的應用伺服器提供部署的機制。然而最開始需求分析階段的功能卻很缺乏，Borland大中華區技術總監李維認為：「需求分析牽涉各領域的產業知識與經驗，難以提供自動化的功能，因此呈現不對稱的發展。」



MDA以標準化的技術及方法，提供從需求搜集、需求分析、設計模型，以致對應各種技術平臺產生程式碼的解決方案。東海大學資訊工程科學系教授周忠信表示：「當企業的需求可具體模型化及圖像化，模型成為重要的資產，最有價值的產業知識將得以保存。」企業不必擔心人員異動引發系統維護的問題，即使資訊架構改變，例如由Java改成.NET，也只需底層技術平臺即可。



目前MDA的開發工具及CASE Tool，均實作PIM（Platform Independent Model）、PSM（Platform Specific Model）到產出程式碼的階段，CIM（Computation Independent Model）的技術尚未成熟，所以現今的工具著墨甚少。因為從使用者的角度，描述商務需求太過抽象，再轉換到技術實作困難度高。



軟體技術發展迅速不斷推陳出新，開發永遠追不上技術的腳步。模型是高階抽象化的表達方式，比解讀程式碼容易，因此MDA的構想是在設計階段完全不考慮技術平臺，CIM與PIM都是抽象的模型，CIM以使用者的角度描述業務需求；接著PIM則專注在各領域應用系統的模型化，但仍不考慮使用的技術；PIM可對應到各種技術平臺的PSM模型，進而自動產生程式碼。修改PIM對應到PSM即可自動產出不同的程式碼或資料庫綱要（Schema），系統維護工作也就變得容易。



李維說：「MDA是UML軟體技術很自然的延伸。」模型可細分為概念模型（Conceptual Model）及實作模型（Implementation Model），概念模型是用來描述需求及設計概念；實作模型與各種語言的實作有關。



程式導向（Code-Oriented）的開發方式，通常直接從實作模型開始，然後寫程式，沒有經過設計概念模型的過程；但對於有受過軟體工程教育的人，習慣從UML設計開始。不過，應用UML的困擾，在於概念模型與實作模型的轉換有潛在的問題，一種是對應資料庫，另一種模型與程式碼的對應，雖然模型透過標準的UML設計，但寫程式時摻雜個人習慣等會變動的因素。



MDA希望彌補兩者之間的鴻溝，利用MOF、OCL、CWM等標準，讓概念模型以標準化的方法轉換成實作模型。一旦有了標準，開發工具廠商也就可研發自動化的工具，產生結構良好的實作模型。開發人員可專注於解決各領域產業的問題，減少寫程式的苦工。未來修改時，以正規中立的OCL設定模型的商業邏輯，不會影響到類別或物件的狀態，因為與實際的程式語言無關，所以對應到各種程式語言都可保證條件存在，不用擔心技術平臺的遷移，會導致遺漏任何商業邏輯。



雖然UML也是圖形化的表達方式，但產出的文件是概念模型，不貼近程式碼，現在已有CASE Tool例如Together，使UML的圖與程式碼達到雙向同步的機制，可確保模型與程式的一致性。然而叡揚資訊系統軟體服務事業處經理楊有進表示：「UML是站在技術的角度設計模型，MDA則是抽象層次以商業需求定義模型。」



雖然支援雙向同步的CASE Tool，協助企業解決設計文件與系統最終成品不一致的問題；然而對MDA而言，業務導向的塑模應該不包含逆向工程，所有的改變應從業務出發，以由上而下（Top-Down）的方式，因為需求改變而調整業務模型，後續由工具驅動程式碼的改變。此即Sybase系統顧問向質彬所謂：「Modeling即Coding的行為。」修改程式碼反向影響模型，是技術領導業務的作法，已經不符合MDA的理論基礎。



李維也認同MDA不具備逆向工程的概念，但是從技術的角度分析：「設計階段的塑模不可能深入所有的類別。」在UML的工具中，使用者可隨設計者或建構師等角色，選擇檢視不同層面的模型內容，設計階段的概念模型的確不應由程式驅動模型的修改；但在實作的階段，會隨著特定程式語言、技術、中介元件或GUI介面，加入特有的模型，這部分是可以雙向修改的。

不只是程式框架，是可執行的程式碼
UML、CASE Tool及MDA的差別
從學校教育著手，較易改變行為模式
相較於UML產生的Class Name、Method Name等程式框架，MDA透過PSM產生的程式碼不只是骨幹，還包括與商業邏輯有關「可執行」的程式碼，將大幅減少撰寫程式的負擔。



軟體設計與發展無需考慮平臺問題，了解產業知識的高階使用者，可輕易定義需求，從業務導向出發，依需求定義模型再產生程式碼，系統的彈性變大。業務模型從軟體架構抽離更大的好處，是不被底層技術綁死，不同程式語言的轉換不用重新改寫系統，可同時享有軟體基礎架構更新帶來的優勢，又確保業務模型的準確性，不用擔心寫錯或遺漏重要的功能。



在MDA的規格中，PIM及PSM均可利用UML設計模型，因此容易讓人產生混淆，UML與MDA有何不同？



李維表示：「UML是靜態的模型，MDA則是動態模型，可以更精確的方法描述模型的商業邏輯。」MDA與UML兩者的差別，在於UML用自然語言描述商業邏輯，例如薪水大於五百萬；而MDA利用OCL技術，以更精確的數學運算式描述商業邏輯，例如Revenue>5000000。運算式沒有模糊地帶，因此工具可依據OCL的定義產出實作的程式碼。



即使MDA相關的MOF、OCL、XMI、UML等各種技術已有清楚的規格，但OMG並沒有明確的規定，要具備哪些技術或標準才算MDA，所以各家實作的範圍及方法並不相同。



就因為實作MDA沒有一定的標準，UML是MDA的標準之一，支援UML就可以聲稱支援MDA，不禁令人懷疑CASE Tool及MDA工具兩者有什麼不同？到底有沒有界定的標準，可判斷市面上的CASE Tool只是以MDA作為行銷名詞的UML工具，還是正宗的MDA產品？



楊有進說：「CASE Tool仍在PSM層級的技術性模組，若能設計業務導向的模組，才能稱得上MDA。」而周忠信認為：「MOF及XMI是指標。」李維則表示：「MDA的規格即說明，MDA工具必須包含UML、MOF、OCL及自動化的工具。」自動化的工具是各家廠商自行的實作，從模型的外觀來看，很難察覺UML或MDA的圖形。當初UML只定義方法論及圖形表示方法，拆解模型的結構，如果只是UML工具，通常不會使用OCL，MDA模型的邏輯設定不會用程式語言實作，會用正規的OCL定義。



不過各方專家建議的衡量標準均未必絕對，OMG沒有強制規定MDA一定要具備哪些標準，工具為在市場競爭，必然拿MDA大作文章，企業若選擇以MDA為軟體工程，只能依自身著重的層面，尋求適合的工具。



MDA是一個新興熱門且快速發展領域，工具廠商才會不斷炒作這個話題。然而目前MDA的技術尚未成熟，所以並沒有真正可從CIM直接轉換到程式碼一步到位的工具，仍需透過層層轉換及設定，或鎖定特定語言的實作，才能直接產出程式碼。



對技術人員而言， MDA最重要的是思維的改變，楊有進評估：「從學校教育開始推廣，改變開發人員的行為模式，推估仍需兩年的時間，MDA的觀念才會普及。」周忠信站在學界的立場來看：「目前學校多有教育UML的觀念，但提及MDA的還很少，研究所可能有以MDA作為研究的主題。」MDA是軟體工程的一個門派，雖然是不錯的趨勢但目前並非主流，可能是相關課程中的一個章節。



李維預測：「未來軟體工程應會像程式語言的發展一樣，呈現百花齊放的榮景。」隨著網際網路及不同平臺的交流越來越發達，每個人會自由選擇最適合及偏好的語言開發系統，相同的，軟體工程不會只有單一方法存在。



相對於輕量級的XP方法論，及重量級的RUP方法論，MDA是比XP麻煩卻比RUP簡單的軟體工程。與其他領域不同的是，程式語言及軟體工程存在一種信仰的成分，所以未來不太可能是一枝獨秀，在多元的發展的情況下，MDA可能成為主流之一，但不是唯一的選擇。

工具降低門檻，但門檻不會消失
沒有任何軟體技術是萬靈丹
既有的系統如何MDA？
雖然MDA的構想很完美，不過包含UML、MOF、OCL及CWM等許多的標準及技術，單單要了解這些背景知識就令人望而卻步。周忠信認為：「當工具包裝隱藏了理論的枯燥及困難度，即可降低MDA的門檻，提升市場的接受度。」各家產品的展示過程中，幾乎都可藉由直覺的拖拉點選及設定功能，即自動產生程式碼，使用者不見得知道，也分不清楚PIM、PSM、MOF或OCL是哪一步驟。工具的便利性，確實大大降低了使用者對艱澀難懂理論的恐懼。



不過，李維表示：「工具的確可以降低門檻，但門檻不會消失。」工具展示的畢竟是陽春的應用，在不懂MDA技術的情形下，開發簡單的系統，有可能透過工具直覺的設定，產出程式碼即完成。但企業級應用的系統，仍需有經驗且具備MDA相關知識的人，運用技術描述商業邏輯才可能完成。



現在已有很多開發工具提供拖拉點選的方式，自動產生SQL陳述式的功能，然而複雜的資料庫關連及巢狀式的條件，仍需回歸技術人員專業的功力，因此工具不可能包辦所有的事情。李維反問：「沒有背景知識為基礎，如何確認模型的正確性？」即使未來MDA的工具，提供驗證邏輯的功能，但沒有足夠的了解，也無法運用得宜。所以開發人員不能忽略蹲馬步基本功夫的重要性。



即使工具支援MDA，開發人員也不見得會運用，只有在金字塔頂端的領域，喜歡用正規塑模的方式開發軟體的專業人士，較會採用MDA的技術，但若要深入到所有開發人員日常的生活，還有很長的路要走，因為MDA的門檻較高。除要了解UML、MOF、OCL等觀念，還要認同設計與塑模的重要性。如果思維無法改變，MDA就只是一個空洞的理論，不會落實。



李維：「沒有一個軟體技術是萬靈丹。」MDA可以解決部分的問題，但不會解決所有的問題，當初RUP及XP方法論出現時，大家都認為很理想，但也沒解決所有的問題，這也是促使軟體工程不斷進步的原因。



既有的系統若已執行得很平順，未來不會有太大的調整，轉換至MDA的架構意義不大；若有持續修改的可能，套用MDA的架構，將可降低後續維護的成本，並提高系統調整的彈性。



不過，不是所有的應用程式都可套用MDA，至少得是物件導向的架構，可透過UML工具以逆向工程產生PIM模型，再匯入MDA工具，才能以模型驅動程式碼。以程序導向架構開發的應用程式，就無法反推成MDA的架構。

軟體代工有機會實現
只會寫程式將淪為廉價勞工
過去軟體代工的構想，無法像晶圓代工一樣可以成形，是因為使用者需求難以透過語言或文字精確的表達。需求的表達需要頻繁的溝通，單純以文件清楚描述需求過於困難，常透過視訊會議即時溝通。



對於非英語系國家，外語表達能力普遍不佳，語言及文化上的差異，使得軟體代工更顯困難。由於認知的不同，導致使用者需要桌子，開發團隊卻產出椅子的情況。



MDA降低對語言的依靠及文化的認知，以圖像模型表達降低語言及文字產生的認知混淆，彌補需求與成品之間的差距。因此未來將走向軟體代工的趨勢，由臺灣設計及塑模，委外大陸或印度開發，降低生產成本。不但需求可被精準完成，不再桌椅不分，再搭配測試功能，品質也可獲得保證。



程式開發人員常戲稱軟體開發是純手工的傳統產業，事實上一點也沒錯，開發人員應尋求新的定位，不能只專注於程式語言的學習，否則將淪為廉價勞工。周忠信表示：「軟體工程比技術更重要，因為IT技術變化太快。」產業知識、軟體分析、計設模式與解決問題的能力，才是最有價值的部分，唯有加值自身的能力，才能避免被工具取代的危機。



企業投資龐大的團隊寫程式並不划算，資訊委外是不得不的趨勢， MIS的價值不在於撰寫繁瑣的程式。節省苦工的時間，學習軟體設計及塑模，思考如何建置更好的系統架構、強化系統效能，並提供使用者更好的服務，才是有價值的投資。

MDA相關技術介紹
雖然MDA可加速軟體開發的效率，但不見得容易普及，最主要的原因是MDA牽涉不少技術及概念，要資訊人員改變既有的思維，並學習相關知識，需要一段時間的醞釀。



資訊人員研究MDA理論很容易誤解，以為完全不用寫程式，事實上還是要寫程式，但不是寫繁瑣的運算邏輯，而是描述轉換的規則，相較於以往已大幅降低寫程式的負擔。未來MDA的工具日趨成熟後，有可能幾乎不用寫程式，多數的程式碼直接由工具產生。不過，塑模的技術及邏輯與關連的正確性，將是另一個重要的課題。



CIM（Computation Independent Model）：不展示系統的架構，以與電腦無關的觀點看待系統。CIM也可稱為Domain Model，是商務使用者在訪談中，以他們的角度描述需求。



PIM（Platform Independent Model）：以與技術平臺無關的觀點描述系統，稱為System Type Model，完全不思考底層以何種技術實作，專注在模型化財務、生產管理等商業邏輯。



PSM（Platform Specific Model）：PIM的模型可對應到CORBA、Java、.NET或Web 等Services的PSM模型，然後自動產生對應的程式碼。



UML（Unified Modeling Language）：所有MDA的規格將有PIM及PSM兩種層次的模型，作為規範的基準，而這兩種模型將以UML定義，也可說是MDA的基礎。



UML 1.4是目前官方正式的版本，透過UML格式記錄模型，以視覺化的角度，利用9種不同型態的標準圖形，描述軟體的設計架構，提供設計與開發人員共通的表達方式，達到溝通的目的。



MOF（Meta-Object Facility）：在PIM轉換到與特定技術有關的PSM過程中，可能是轉換成Oracle、Sybase、SQL Server等資料庫，或轉換成Java、.NET、Web Services等IT技術。以人類的語言為例，英文是動詞在前，副詞在後；中文則是副詞在前，動詞在後。同樣的，各種平臺或程式語言的表示方式不同，工具很難符合不同技術的描述方法，MOF即以中立一致的標準描述模型，並定義各種底層應用技術轉換的規則，使模型可轉換成各種技術對應的語法。



CWM（Common Warehouse Model）：CWM提供了一個完整、廣泛的標準化元模型（MetaModel），讓企業的資料採礦可跨越資料庫的範圍，而且做得更好。就像UML Profile，不過不是在應用程式的部分，而是在資料的部分，制定MDA對應資料庫的綱要（Schema）。CWM是由OMG及MDC（Meta-Data Coalition）共同努力的成果，CWM專注在資料的塑模；而UML專注在應用程式的塑模。



XMI（XML Metadata Interchange）：XMI以標準化的XML文件格式及DTD，定義以XML為基礎的UML模型交換格式。也就是說，XMI也定義了UML轉換至XML的對應。



OCL（Object Constraint Language）：OCL是分析設計軟體系統的註釋性語言，是UML延伸的標準，允許開發人員撰寫物件模型的限制條件並利於查詢。模型的限制條件非常有用，開發人員可建立規則以控管物件。當軟體專案需要獨特及複雜的規則定義在商業模組中，OCL變成物件發展不可缺的一部分。



在模型中設定商業邏輯的好處是維護容易。即使開發系統的人員已離職，當商業邏輯改變，接手維護的人員無需研讀及修改程式，只要修改OCL的定義，MDA工具即自動變更程式。



不將商業邏輯隱藏在程式碼中的好處，還包括未來改變技術平臺，若由人工重新打造企業必須承擔風險。MDA的架構無需重新開發，只要對應到不同的PSM，即自動產生程式碼，OCL可避免轉換的過程中，遺漏任何商業邏輯。不過，OCL運算式可以回傳數值，但是不能使用OCL來改變模型中定義的元素，也就是說OCL可定義商業邏輯，但若將新增、刪除、修改等系統行為定義在OCL中，則不符合OCL的精神。文⊙李延華