輕鬆談軟工

往花蓮的自強號上，旁邊坐著一位五十幾歲的長者，一直反覆的看著一本旅遊書籍，看起來是歐洲旅遊的書。我好奇便問他：『剛從歐洲旅遊回來嗎？』，他嚇了一跳，我連忙向他道歉，他親切說；『沒關係』，接著很興奮的告訴我他的攝影心得，就這麼聊了起來。 他一邊翻閱書上的照片，許多的地方他都去過，他說他喜歡研究別人取景的角度為何和他不同，借此學習更好的攝影技巧。看得出他對生命充滿熱情，喜歡思考、創作與分享。聊著聊著才知道他原來是台中知名建商的董事長。 除了生活上的樂趣外，他也跟我分享他的經營理念。他對員工的要求是 『不能凡事都照著規格書、設計圖走，那是官僚』 。為什麼？他們的員工每天都在接觸房子的買賣，久了就麻痺了，以為房子的買賣很輕鬆，但是對許多買房子的人可能是畢生的積蓄，一生可能只買一次房子。 他說他接觸過很多醫生、教授或高科技產業的客戶， 他們在自己的領域上十分的專業，"但對房子的事情真的就是不懂" ，所以不能拿規格書來壓他們，應該是要幫助他們。 姑且不論這位董事長是否真的做到這樣的原則（畢竟我跟他不熟），這些道理在軟體工程產業上也是相通的。寫軟體的如果在客戶搞不清楚規格的情況下一直以規格來壓客戶，那就是以專業的傲慢來欺騙客戶的無知。 當然，蓋房子跟寫軟體畢竟不同，各位覺的呢？

自從2002年Scott W. Ambler寫了一本叫" Agile Modeling - Effective Practices for eXtrem Programming and the Unified Process "以來，Agile Modeling(AM)的觀念與方法逐漸大行其道，由於AM的觀念可用之於各種物件導向軟體發展方法上，因此希望來輕鬆談談AM這種方法論(methodology)，以收拋磚引玉之效，同時也呼應『目』與『F』那篇文章。這篇文章所談的大部分來自Ambler的說法，我只不過摘要式地加以闡述，但仍然可做為軟體工程師創製模式時借鏡。 依照Ambler的定義，AM是一種渾沌、實用為基礎的方法論，其有效地用於模式化與文件化軟體系統，「渾沌」(chaordic)一詞可說道盡AM的精神，依個人的詮釋是「不受限但處理的事物漸趨規則」之意，也就是說，規則來自於渾沌的演進，至於此地所說的方法論(methodology)並非指發展軟體的方法，而是指每天由軟體專家們應用的一些常規(practices)，這些常規依照AM原則與真義(value)而定。Ambler依他的經驗，擬定了核心與補充原則共17項，以及共21項的常規，至於AM的真義有4項來自於XP(Bechk 2000)，但加上「謙卑」(humility)一項，而形成Ambler所說的AM真義，我想這5項真義值得加以簡單說明，因為所有的原則都源自於這5項真義： 溝通(Communication)： 發展團隊成員之間以及專案相關人士間的溝通必須有效。 簡單(Simplicity)： 發展符合需要的最簡單的解決方案。 反應(Feedback)： 盡早並且時常獲取對工作的回應。 勇氣(Courage)： 要有嘗試新技術的勇氣，而且成為決策。 謙卑(Humility)： 必須謙卑允許別人提供對於你專案工作的意見。 這五項真義以及各項常規與原則是引自於敏捷聯盟(Agile Alliance)的四項敏捷宣言，因篇幅受限，我不便在此地詳述這些17項原則與21項常規，讀者如有興趣可參考Ambler著作Agile Modeling，或網頁： http://www.agilemodeling.com/ ，不過我希望討論其中最主要與實用的「簡單」這一項真義所在。 Unix的發展者之一P.J.Plauge...

從7月份起，我陸續發表了3+1篇有關MDA的介紹文章，其中+1這篇是：『利用「原型樣式」快速發展軟體』一文，對於這種快速發展軟體的方式可能一般人不太熟悉，但無妨。對於這幾篇MDA相關的文章，讀者反應卻十分冷淡，可能與文章的內容有關，其實我盡可能不談理論，只談一些觀念與技術。這一篇「MDA續篇」仍然不涉及太多的理論敘述，但仍然無法避免，我盡可能平述基本理論概念。我假設讀者已看過3+1等四篇文章，對於MDA的輪廓諒有所了解，這篇文章希望補充一點MDA的基本原理。 MDA的基本原理： 下圖顯示MDA之所以可用的原因。 (點選放大) 圖中，除CIM->PIM的轉換須依賴人工技巧之外，其他模式轉換通常可借助工具來作業 (註： M2M = Model-to-Model，M2C = Model-to-Code)。對於MDA而言，模式間的轉換有重要的意涵，就是在較高抽象層次(abstraction level)作分析，也就是建構PIM，設計的抽象層次較低，程式的產生更低，從高抽象層次轉換到低層次的作業則盡可能借助自動化工具(理由已如3+1文章內所述)，例如M2M以及M2C則自動化轉換，這種不同抽象層次的作業完全符合所謂「事務分離」(separation of concern - SoC)的架構法(architectural approach)，SoC可以讓業務分析者集中在業務邏輯的分析與設計而不必考慮系統的細節，簡言之，分析者只要管好(包括發展與保養)PIM即可，為達到這種SoC，OMG因此定義不同抽象層次的觀點(view)，即CIM、PIM、PSM、與Code (OMG的MDA樣式並不包括Code)。 MDA是軟體發展的一種骨架(framework)，因此適用於你所使用的任何軟體發展方法，例如你可以用傳統的分析與設計法，或敏捷模式化(agile modeling)，或+1文章內所談的「原型樣式」(archetype patterns)來描述CIM與製作PIM，所以不用改變你所學的東西，就如Grady Booch所說的：公司要訓練MDA專家並無困難，也就是說只要懂一點UML而且仍然可保持所學，以減低訓練費用，同時，使用MDA技術尚可加速ROI。(註：最近有人提議使用OMG最近所提供的Business Process Modeling Notation (BPMN) 來描述C...

這次辛樂克怪颱侵台，重創台灣，其中后豐大橋斷橋，造成1死5失蹤的大不幸事件，照理颱風來前就必須封閉該危橋，但事後我們的官員說依照「程序」處理，這種說法讓我想起陳振炎教授文章所談的敏捷方法，我曾在其「意見」箱內談到，使用任何敏捷方法時不要忘記敏捷宣言的精神，我認為宣言的精神不但使用敏捷方法時必須時時在意，處理日常事務亦須念茲在茲，宣言第四項"Responding to change over following a plan"，"plan"可解釋為一種「程序」，程序故然重要，但反應變動應高於程序(不含法律)，這位官員在這個時候的這種說法有待商榷，也許他的字典裡沒有「敏捷」這種東西吧! 敏捷(agility)最重要的定義是：快速與彈性反應改變(rapid and flexible response to change)，或說"embrace change"，change就是一種變動，能快速並彈性處理各種變動(如封橋)才符合敏捷精神，因此如能活用敏捷之義，其功能大矣! 總之，如果不懂embrace change，可能會誤用各種發展「流程」的真義，我們可以看看CMMI ML5：具調整與修正流程的能力‧‧‧，(本部落格中鄭有進教授文章：CMMI是什麼？)，將發展流程客戶化就是調整與修正流程，可想見使發展流程適合自己專案之需的重要性，但這要靠人，所以說"People over Process"。

台灣軟體業積弱不振, 可能因思維較舊所致: 工廠思維: 軟體工程在 1968 NATO 大會出現時, 仿效其他工程領域, 把軟體視為工廠生產, 講求精細分工 嚴格控管 注意產量成本等. 但新趨勢是, 軟體講求創意及合作, 像 工藝家聯合工作室, 而不像工廠. 電機思維: 軟體本由電機電子而來, 從The Institute of Electrical and Electronic Engineers, Inc, IEEE 這代表性機構的名稱, 即可看出此沿革, 但演進至今, 軟體已與電機無關. 軟體業界深知軟體開發(含物件導向開發)需製作大量文件( 含程式)，構成龐大負擔，常導致很多溝通不準或思考不週之處 (即 Bugs)。有些公司製作不少文件卻乏人閱讀，全無溝通之效；甚 或冀望多年後維修程式時，將會閱讀文件， 殊不知程式是不斷變動的，文件更新常趕不上變動的。 敏捷方法視開發為合作活動(如攀岩)，力求以面對面直接溝通， 來取代目前文件製作及閱讀的間接溝通，使開發變得快而準(即 agile)。 又，敏捷方法以測試來帶動開發 (Test-driven development)，軟體品質極佳。 最後，除國外重視的溝通訓練外，吾人亦加強國人不足的思考訓練， 溝通及思考乃深層基本功；–練功後人人紮實、軟體優質， 再用逆向工程工具動態產生class diagram, sequence diagram等，有可能敏捷達 成CMMI 一些process areas 的 goals。 此敏捷方法係陳振炎教授擴充極限開發法 (extreme programming)而得， 方法細節請見下面網站的上課教材：敏捷方法苗圃 ( www.agilemethod.csie.ncu.edu. tw ) 陳振炎教授 國立中央大學資訊工程系

「所有具優良結構的物件導向軟體架構，其內部都充滿樣式(patterns)」，Grady Booch這句話乃是提供本人寫這篇 輕鬆談 的動機。其實，在各種行業中，製作複雜系統時樣式往往扮演重要的角色，由樣式所建構的軟體具有彈性、模組化、可重用以及易解的特性，軟體系統如具有這些特性則不旦能夠符合需求，而且能夠輕鬆反應需求變更，我想這種軟體應該就是品質好的軟體。樣式有許多類型，如分析樣式(analysis patterns)，架構樣式(architectural patterns)，設計樣式(design patterns)，程式樣式(idioms)，或「 原型樣式 」(archetype patterns)等等。本文所要談的是，原在『漫談「模式驅動架構」(二)』中所設計的MDA過程( CIM->PIM->PSM->Code )，我們將利用 原型樣式 改變成為： 選用業務原型樣式->產生PIM->自動化轉換成PSM->自動化產生程式 CIM則成為選用適當原型樣式的指引，這個過程的重點在於PIM的產生，適應原型樣式產生的PIM比一般標準的物件導向分析與設計(OO analysis & design)快速而且簡單，符合敏捷精神。本文約略來談談利用「原型樣式」快速發展軟體。 何謂原型(archetype)？有多種定義，這裡所談的原型是指「一種原始的(primordial)事物或環境，這些事物或環境前後一貫地重覆發生，而且被認為具有普遍性的觀念或狀況」，如果這些事物或環境是指業務範疇與業務軟體系統，則稱為「業務原型」(business archetypes)，業務原型之間的合作(collaborations)則稱為「業務原型樣式」。Jim Arlow與Ila Neustadt提供9種業務原型樣式，包括： Party ， PartyRelationship ， CRM ， Product ， Inventory ， Order ， Quantity ， Money ，以及 Rule 等業務原型樣式，這些原型樣式皆重覆發生在業務範疇之內，你/妳可以現用或經修改這些原型樣式來建構分析模式，這種技術稱為 「元件基塑模」(component-based modeling)。我們利用經修改的Order原型樣式發展Order Processing S...

敏捷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的觀念，其價值應較受關切，敏捷方法都與這四項宣言有關，這四項宣言都關係到人的運用與活動，例如發展者之間的溝通重於過程與工具的使用，專案的施行不能只有過程而沒有(好的)人，其他諸如迅速產生可執行的軟體、客戶的合作以及...

CIM - PIM - PSM 樣式 在「漫談模式驅動架構」(一)中我們談到，OMG將MDA建構成CIM-PIM-PSM樣式，程式則由PSM轉換(transformation)而成，這是依照一種較合宜而方便的觀點(viewpoints)所形成的樣式，事實上MDA卻允許有其他的觀點，而產生其他的樣式，但CIM-PIM-PSM樣式的重點在於其提供「事務分離」的概念，因此我們仍然以大家接受的OMG樣式來漫談 ，實際運作時，該樣式可以延伸成CIM-PIM-PSM-Code 。 何謂CIM，CIM有時稱為「範疇模式」(domain model)或「業務模式」(business model)，用來描述業務系統，但本身並非軟體，這個模式表示系統的關鍵需求，以及描述問題範疇的字彙(vocabulary)，但不涉及系統的細節，一般物件導向系統分析方法就可用來建構這個模式，PIM就是依據這個模式而產生。 PIM是表示業務邏輯(business logic)的模式，這個模式顯示系統的工作內容，但不涉及與任何特殊技術平台(technology platform)的關係，如EJB，.NET或關聯性資料庫等，PIM類似OOA的分析模式(analysis model)但更為詳盡完整，每一種業務只有一種PIM。至於PSM則結合PIM所擬定的規格來顯示系統將如何在特殊技術平台上實作，因此它是由PIM轉換而來，程式則由PSM轉換而得。PIM，PSM與程式之間的轉換可以用人工，但一般皆使用MDA工具來擔任，因人工不但費時而且可能出錯。在此我們引用Booch等人的所謂「MDA宣言」(The MDA Manifesto)來支持這個觀點，宣言有三點：(1) Direct representation; (2) Automation ; (3) Open standards，因篇幅關係我們不在此地詳談這三點宣言，因為自動化涉及MDA的運用甚巨，因此我們希望強調第(2)點 - 自動化轉換。以上說明對於不熟悉物件導向軟體工程的人士可能較為抽象，也許下圖(雖然不很完整)可以協助了解MDA的運作方式： （點圖形放大） 圖中我們同時將MDA與傳統的發展過程做比較，兩者之間的生命週期差異不大，但MDA主要特點在於 PIM->PSM->Code的自動化轉換，保養是在PIM而不是程式，PIM是唯一代表業務邏輯的模...

「模式驅動架構」(Model Driven Architecture - MDA)的由來 「漫談模式驅動架構」將分3期來簡述 MDA 技術的內容及其影響，讀者如有興趣可參閱學會發行的 Journal of Software Engineering Studies, 2(1), pp.3-12 本人發表的文章，我們在這一系列漫談中並不深談MDA 的理論，而只希望談談這種技術到底為何，至於專有名詞不易翻譯者，原則上將延用原文，但必要時會加以解釋。要了解這一系列漫談的文章，讀者最好具備物件導向的一般觀念。 2002年早期, Object Management Group (OMG ) 聲明，MDA 為其策略方向，並於2003年6月發表"MDA Guide Version 1.0.1"，至此 MDA 的發展有其「官方」依據。 MDA 是基於所謂 "事務分離" (Separation of Concern) 以及 "抽像化" (Abstraction) 的原理與觀念而設計，因此系統分析師與發展者可以集中精神在事務邏輯的分析與設計上，而不必顧慮系統層次的細節，例如將來系統要在何種平台上實作等問題，為達到這項目的，OMG 在發表的 「MDA指引」中定義 MDA的三種模式，建構這三種模式同時也顯示使用MDA來發展軟體系統的基本過程(process)，包括: Computation Independent Model(CIM); Platform Independent Model(PIM); 以及Platform Specific Model(PSM)，PIM 與 PSM是使用事實標準(de facto standard)的視覺化建模語言UML來描述，PIM代表業務邏輯，PSM由PIM轉換(transformation)而來，其顯示在特殊平台上的系統模式，程式則由PSM轉換產生, 這種轉換固然可以人工為之，但一般皆使用MDA工具自動化轉換，因人工轉換費時而且易錯，軟體產品如果依PIM-PSM-Code過程產生就可在「標的平台」 (target platform)上使用，我們將在往後的漫談簡介這三種模式如何形成。 雖然 MDA 在軟體工程中並非 "銀製子彈"(silver bullet)，那麼企業接受這...