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

敏捷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)。

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

留言

  1. agility 給人的感覺是少文件, MDA 又需要劃許多的模組文件,兩者之間不知道是否會有一些衝突?是不是一定要依賴 MDA 工具才能成功(因為可以降低使用者繪製模組塗得時間)?

    nlh, FCU

    回覆刪除
  2. 使用MDA須先建立PIM,PIM是較嚴格的分析模式,代表軟體系統的業務邏輯,並非模組,當然PIM的產生仍然須經過需求與分析等階段,只是PIM可經工具迅速自動化產生程式,此外,因PIM抽象層次較高,容易被了解也容易保養,文件也就比較節省,因此我說MDA可協助敏捷軟體發展,這是agility的主要精神。至於是否一定要用工具,答案是不一定,只是用工具有它的好處,我在文章內有所說明。如何產生PIM可用傳統的需求分析方法,不過我將在下一篇文章闡述如何迅速建構PIM,你如有興趣可先參考JoSES 2(1)的一篇文章。

    回覆刪除
  3. 補充:MDA是須要畫一些圖,與其他物件導向方法一樣,會畫一些UML的圖,如use case diagrams,class diagrams,activity diagrams,sequence diagrams等等,但主要是class diagrams,其他都是協助PIM的產生,也不一定全會用到,我在漫談「模式驅動(一)」中引用Grady Booch的意見,要用MDA的人不一定要是UML專家,我將在下一篇文章使用archetype patterns產生PIM。

    回覆刪除

張貼留言

這個網誌中的熱門文章

CMMI是什麼?

TCSE 2017

加油站與小鎮