漫談「模式驅動架構」(三)

敏捷MDA (Agile MDA)

在「模式驅動架構」(二)中，我們以圖形表示MDA過程 (MDA Process)，理論上，Code，PSM，與PIM之間可以反向轉換，但事實上十分困難，因此圖中只顯示向前轉換，實際上也是依照這種方式在運用MDA，只要發展PIM，其他模式皆可以以自動轉換方式產生，因此，PIM可視之為可執行的模式 (executable model)，這顯示MDA支持敏捷軟體發展(agile software development)。我們要在本文漫談MDA與敏捷(agility)的結合，稱之為「敏捷MDA 」(Agile MDA)，這個名詞可能是由參與擬定MDA標準的Stephen J. Mellor首創。

那麼， 我們先談談「敏捷」(agility)的基本概念。依據世上許多公司行號的經驗，軟體發展專案的成功率偏低，以美國為例，有30%的專案未完成就得取消，一半以上的專案費用幾乎超過預測的兩倍，種種這些危機，主要原因是因為發展軟體費時費力，而且無法建造完全符合客戶需求的應用系統，多年來，各種各樣的軟體發展方法都在嘗試處理這類問題，但只不過增加一些文件而忽略人的因素，因此2001年2月11-13日在美國猶他州的Snowbird鎮有17位方法學專家聚會研議，共同發表所謂「敏捷宣言」(The Agile Manifesto)，這是該宣言產生的由來，宣言有4項，為不失真我們引用原文如下(讀者不仿參考：http://www.agilealliance.com/)：

• Individuals and interactions over processes and tools


• Working software over comprehensive documents


• Customer collaboration over contract negotiation


• Responding to change over following a plan

"over"右邊各項並非不重要仍然有其價值，只不過左邊各項依據agilty的觀念，其價值應較受關切，敏捷方法都與這四項宣言有關，這四項宣言都關係到人的運用與活動，例如發展者之間的溝通重於過程與工具的使用，專案的施行不能只有過程而沒有(好的)人，其他諸如迅速產生可執行的軟體、客戶的合作以及對(需求)改變的反應皆必須被高度重視，而並非只重視文件、契約與計劃。

發展應用系統，如果價高而且緩慢，或只是快但錯誤百出，都不是具有效果與效率的發展工作。Agility觀念可帶給系統發展者「做對的事物」(doing the right things)，也就是「有效」(effectiveness)之意，而MDA則可讓發展者「把事物做對」(doing things right)，也就是有「效率」(efficiency)，Agile MDA係結合agility與MDA而提供發展時有力的解決問題之道。

那麼何種問題須要解決？基本上，發展應用系統專案時常遭遇兩種問題：(1) 業務與IT單位間如何對專案需求達到共同認知；(2) 如何有效率轉換業務需求成為可執行的應用系統。可惜需求的獲取往往以行政管理的手段借助文件與圖形來顯示，客戶或使用者無法參與這種「紙件」(paperware)的產生，要將這些紙件實作成為應用系統須經過漫長的時間而且勞力密集(labor-intensive)，這是十分無效率的機制，最好的辦法是使用MDA技術來解決這類問題，也就是需求(即PIM)轉換成系統能夠自動化。自動化轉換可讓客戶，甚至在發展早期或發展中，參與擬定或改變需求，而不致影響發展進度與品質，這就是敏捷宣言的第三項：「客戶的合作勝於契約磋商」，不但如此，需求的改變就可十分敏捷處理，這就是敏捷宣言的第四項：「對改變的反應勝於遵循計畫」，Compuware公司的Frank Baerveldt稱之為「活的需求」(live requirements)，Agile MDA可以讓這種活的需求成為可能，這要歸功於MDA有效率的特性，因而使需求的不斷改變不致成為軟體發展的障礙。

"The Architecture of Choice for a Changing World"

OMG稱MDA為「給無常世界所選擇的架構」，這是經過註冊的研討會名稱。軟體工程的困境在於如何克服系統的「複雜」以及需求不斷「改變」的特性」，複雜可以用「反覆與漸增」(iterative and incremental)方法解決，這就是敏捷方法的座右銘，至於對付改變的方法之一就是使用MDA技術，因模式間可以以自動化方式轉換之故。自動化轉換是依據兩種樣式，一種是「技術樣式」(technology patterns)，可將PIM轉換成多種技術平台上的PSM，再經過「實作樣式」(implementation patterns)，將多種PSM轉換成相對應的程式，這些樣式實際上就是轉換規則，之所以稱為樣式是因這些規則設計在所謂「抽象類別」(meta-class)的層次而且可以重用之故。

雖然MDA尚未完全成熟，但已經讓軟體發展法產生根本性(radically)的改變，撰寫程式的工作已經轉為建構模式，只要嚴格發展代表業務的PIM即可，而不必理會施作的技術平台，借助自動化轉換技術，迅速而且正確地將代表業務需求的PIM轉成可運作的軟體。

後語：漫談「模式驅動架構」雖僅提供一些MDA與agilty的初步概念，但期望引起讀者對敏捷與MDA技術的興趣與重視，進而願使用這項技術從事發展軟體系統，但讀者必須具備物件導向以及UML的基本素養，可惜在三篇漫談中，我們只能闡述「知其然」，但未能深入述明「知其所以然」，例如未探討MDA所依據的OMG標準，希望有機會再來探討較深入的細節。為讓讀者對於三篇漫談內容產生「真實感」，我們將另外提供一篇文章，以範例闡述如何運用Agile MDA技術發展軟體。最後我們嘗試做一些總結：

• 雖然MDA是一種創新的軟體發展方法，但是並非能夠解決所有IT的問題，它並非軟體工程的「銀製子彈」，不過MDA如結合敏捷觀念，則比其他技術更能有效率解決問題。


• MDA是一種發展軟體的框架 (framework)，因此並不要求特殊發展過程的配合，例如使用者可以選擇適用於本身專案的需求擬定與分析的方法。


• 由撰寫程式轉為建構模式將提高軟體發展法的抽象層次，因而簡化軟體發展的過程。


• 使用MDA，一旦模式建構完成 (即PIM)，則比程式更「長命」，因保養模式比保養程式更有效而且簡單。


• 自動化產生程式尚無法做到100%，但是一旦MDA成為成熟的技術，發展軟體或許不必要有程式撰寫員(大膽預測)。


• 雖然MDA尚未完全成熟，但世界上有許多單位已經在使用MDA發展軟體，這顯示MDA可用而且將逐漸根本改變軟體發展方法 (請參考OMG網站： http://www.omg.org/mda/products_success.htm)。

(註) 讀者如有問題，歡迎透過部落格的「意見」機制提供高見，作者將盡其所能回應，多謝。