輕鬆談軟工

『簡單』- 讓混亂發展成規則 (Order from Chaos) 我在治療期間，抽空讀了一本肯恩‧西格爾(Ken Segall)著作，書名為『簡單』的書 (應該稱為『極致簡單』- Insanely Simple)，西格爾主要在闡述史蒂夫‧賈伯斯(Steve Jobs)以『簡單』至上的觀念引導蘋果的成功故事，其實，賈伯斯曾經被蘋果「放逐」11年，於1997年再度回到蘋果擔任執行長，賈伯斯不在期間，蘋果每下愈況，一直到賈伯斯回來時，蘋果已經岌岌可危，幾近破產邊緣，賈伯斯以『簡單』至上的觀念重振蘋果。『簡單』至上的概念很難說得清楚，它可能是一種選擇，一種氛圍或一種指引，視你的需要而定，簡言之，『簡單』就是『打破複雜，創造絕對優勢』，你/妳如果用過蘋果的產品如iPad，可能就會有所感受，例如更新作業系統(iOS)就很簡單，總之，蘋果的基本理念是：『硬體簡單化，而背後的軟體卻豐富化』。賈伯斯如何以『簡單』至上的觀念讓蘋果起死回生，有興趣的朋友可看看西格爾的書。 發展軟體的需求，開始時都顯得比較混亂，不過『簡單』可以讓混亂發展成規則，我想，『簡單』這種觀念是否可以運用在軟體發展上，謹提供個人的看法。眾所熟悉的"KISS"原則 (Keep It Simple, Stupide) ，就是勸導人們撰寫程式與設計軟體時，要保持簡單清楚但不要太複雜，發展C語言的P.J. Plauger與B.W. Kernighan在他們的"The Elements of Programming Style"書裡，提供數十條寫程式必須遵循的『簡單』原則，例如其中有一則原則是說"Keep it simple to make it faster"，所以程式如寫得太複雜，則可能會降低效率。此外，『簡單』也可以說是敏捷方法的原則之一，2001年Agile Alliance所發表的敏捷宣言(manifesto)，是『簡單』的價值闡述，『簡單』的優點是你不必花費太多的時間去實作困難的解決方案(除非簡單的方案無法解決你的問題)，總之，簡單的解決方案容易保養也容易改進。 談到『簡單』，我想到去年12/8我在本部落格po了一篇題為『CRC cards - 非正規物件導向發展技術』的文章(惜因少有反應，所以最近我把它列入草稿)，CRC cards雖然屬...

最近看到Kent Beck與Martin Fowler講的一句『諺語』，說："Stick with simple tool, like pencil, paper, and whiteboard. Communication is more important than whizbang." 我才想到PO這篇短文，提供學生們(至少選我開授的OOSE的學生)參考。這句諺語我認為最重要的是『溝通』，溝通在軟體發展的過程中十分重要，尤其想使用『敏捷方法』發展軟體的工程師們更為重要(可參考Agile Alliance在2001年發表的『宣言』(manifesto)，此地不宜對宣言多做闡述)，問題是你要使用何種工具或方法來溝通？我想除use cases外，CRC cards可能是最佳工具之一，它是隨時隨地可得的低技術工具，易學易用。 軟體開發與維護時，工作夥伴的合作十分重要，換言之，團隊合作是發展工作成敗的關鍵，夥伴合作必須有好的工具或技術協助，CRC cards可能是適當的工具之一，據我所知，在台灣發展軟體的工程師很少使用像CRC cards這種簡單但被認為是一種『驚奇』(wonderful)的發明 (David Bellin, et al. 1997)，而這種技術雖然簡單，但卻可避免發展早期陷入太細節或者產生雜亂且定義不清楚的類別，因此希望這篇報導能引起從事軟體發展的人士注意到這種『老而彌堅』的技術，而且也希望各界人士能予指正。 CR C cards (Class-Responsibility-Collaborator cards) 是1989由Kent Beck與Ward Cunningham所共同介紹 (http:\\c2.com/doc/oopsla89/paper.html)， 其出現時期與WWW相同，至今約有20幾年的歷史，這個工具開始是用來教導新學員如何學習物件導向的觀念與程式製作，後來的演變卻超乎在教室內的需要，而成為軟體分析、設計以及敏捷思考的工具。CRC cards的軟體發展方法屬於一種非正規方法 (informal approach)，雖然屬非正規方法，但CRC cards可做為正規方法的輸入或前端作業，如Booch方法、James Rumbaugh, et al. 的OMT、Ivar Jacoson, et al.的OOS...

軟體系統常常背上許多莫需有罪名，有時候是需求的提供者沒把需求說清楚（或根本說了錯誤的需求），有時候是使用者不會用 （沒參與教育訓練或沒看說明書）造成操作不當。當後者的情況發生時，使用者通常會怪罪『介面設計不好』。 的確多數的軟體工程師對於介面的設計不重視也不在行，但有時候使用者也太無理取鬧，把所有的錯誤都賴在介面設計上。 張大叔最近開始使用線上照片沖洗的功能，但照片卻遲遲沒有寄到，他上網查了一下，發現住址寫錯了。他打電話到客服中心發飆。 『你們的系統有問題不穩定，把我家的地址記錯了。明明是100號，怎麼會記成200號？』 客服查了一下，回應說： 『張先生，有可能是您打錯了，系統記錄的的確是200號』 『怎麼可能？我打過無數次了，怎麼可能會把自己的住址打錯？』 客服有耐心的說： 『有可能1和2相鄰，您打的時候打太快了，所以不小心打錯了』 『那你們系統要做檢查嘛，哪有那們笨的系統？要做防呆嘛』 客服楞了一下，還好他邏輯還清楚： 『張先生，我們系統不知道你住100號，怎麼知道您打錯了？沒有辦法喔...』 這下換張大叔楞了一下，但他還是很生氣。 『這照片是我送給老婆的生日禮物，照片我選了好久，沒有按時寄過來這個禮物就沒有意義了』 ，頓了一下又說： 『你們要怎麼賠償我的損失？』 『先生，這是您打字錯誤所造成的，我們沒有辦法賠償。我們會通知郵局將包裹重寄，但您要再負擔一次運輸費用』 客服說。 張大叔一聽還要多負擔就生氣： 『都是你們系統的問題為什麼要我負擔？你們介面設計的太糟，介面要儘量防呆嘛... 比如說不要讓我們用打的，讓我們用選的...』 客服有點聽不下去了： 『先生，忠孝東路門排很多，我們不可能把所有門排都列出來讓你選』 『怎麼不可以，你可以每一個位數都用一個下拉式選單，三個位數只需要三個下拉式選單，你們設計要用點腦筋嘛』 ...

古時候，中國有一則寓言是說：有四個人走到一面高牆前面，高牆的通門用鐵鍊與鎖鎖住，其中三人試圖用盡各種方法要打開門鎖，用石頭打、火燒、以及用木棒挖鎖等方法，但最後仍然無功，這時候，忽然看到那第四人從森林走出，手握一把長竹竿，走到牆面前以撐竿跳的方式跳過那一面牆。 第四人並沒解決門鎖的問題，而是避開重新定義問題，創造新的而可解決的問題 ，因此基本上問題不在門鎖，而目的是人要到達牆的另一面。 這則故事顯示，"what"與"how"的問題，前面三個人只想『我如何打開那道門』(how)，至於另外一個人則避開那三個人的困境，只是想『我要做甚麼』(what)，答案是『我要過那面牆』，一旦他將問題放在"what"上面，他就可以設計如何執行而獲得成功，他解決問題不只是解決，而是問題要合理解決。 發展軟體就應如這則寓言中第四人的作法，要如何達到有許多方法，其中CRC cards (Class-Responsibility-Collaborator cards)技術，可能是最佳方法之一，但似乎未在國內引起廣泛注意，我們另文討論。

Continuous Integration 在討論版本控管時，我們曾經提到WiMAX計畫使用一個輔助工具「 JCIS 」進行持續整合(Continuous Integration)的工作。那麼，為什麼要做持續整合呢？維基百科中對於 持續整合 的理論有些初步的介紹，包含下列十個重要的Practices： 維護一個程式庫(Maintain a code repository) 將建置自動化 (Automate the build) 使建置能進行自我測試(Make the build self-testing) 每人每天送交程式碼(Everyone commits every day) 每次送交都應該被建置(Every commit should be built) 維持快速的建置時間(Keep the build fast) 在實際運行的環境下進行測試(Test in a clone of the production environment) 簡化取得最新可交付版本的方法(Make it easy to get the latest deliverables) 每個人都能看到最新版建置的測試結果(Everyone can see the results of the latest build) 將佈署自動化 (Automate deployment) 上述許多Practices都要求自動化，自動化又可以分為半自動和全自動，以半自動為例，可能是有人每天固定手動執行make指令，將所有要建置的檔案編譯與連結，接著有人將結果複製到實際運行的環境，再下指令讓電腦執行所有的測試，這個過程雖然必須由人來操作，但只要下少許指令就可以完成了。那麼全自動呢？就是在專案開始的時候進行若干設定，之後由電腦自動處理一切編譯、連結、測試等工作，這就需要一套輔助工具了。 要確實完成這麼多的Practices，其實門檻是很高的。即使是在企業界，也難免會有不遵守遊戲規則的軟體工程師，更何況我們的開發主力是學校裡沒什麼專案成敗壓力的學生。舉例說，要做到「每人每天送交程式碼」幾乎是不可能的，基本上學生開發程式是有一天沒一天的，最多只能要求到「有修改就必須送交程式碼」。另外像是「每次送交都應該被建置」，在我們第一年的WiMAX計畫中可以說是完全失敗。在開發環境未能統一的...

版本控管 在整合國科會CMMI文件與程式開發的過程中，總計劃與各子計畫的文件與程式都需要一個版本管理的機制，一方面萬一有電腦當機或是檔案損毀時，可以迅速還原最新的版本，解決資料備份的問題，另一方面還可以在歷史紀錄中往返，將刪去的文件或程式找回來。對於文件或程式整合而言，版本控管十足是一個Time Machine。 我們在第一年開發之前就已經預期到版本控管的重要性，因此在專案初期便架設可透過Web介面存取的版本控管伺服器(Apache + Subversion)，並且安排Subversion的教育訓練。但是，可能是一開始時教育訓練的內容安排不符合需求，也可能是開發團隊不夠用心，導致版本控管並不上軌道。最常發生的問題包括：團隊成員未確實解決衝突(Conflicts)、久久不送交(Commit)程式、送交無法編譯的程式、送交時不寫註解等。 這些問題的原因，有部分與先前討論過的缺乏一致的開發環境有關，部分團隊使用的IDE沒有支援版本控管，所以得在IDE編譯完後才知道有沒有問題，然後再使用其他版本控管軟體(TortoiseSVN等)送交程式；或在Windows上取出(Check out)程式然後複製到Linux的機器上修改與編譯，然後再複製回Windows上覆蓋舊版本後送交，然而在取出後到送交前的這段時間，如果沒有進行更新(Update)和合併(Merge)的動作，這些行為常常會導致衝突。 久而久之，有些團隊成員開始害怕使用版本控管系統，導致送交的週期越來越長，甚至有超過二個禮拜沒有送交程式碼，失去使用版本控管的優點。長時間的修改送交週期，也讓成員忘記曾經修改過什麼東西，自然不知道要寫什麼註解，這些都是讓版本控管失去威力的錯誤行為。經過一整年的觀察後，總計畫在第二年開始前，重新規劃Subversion的使用方式。 首先，我們將版本控管的支援加入一致的開發環境中。在Virtual Machine中，我們使用Eclipse搭配Subclipse套件，讓IDE與版本控管合而為一，之前也提到，單元測試的執行也加到程式中，這些都是確保程式無誤的前置作業。另外，針對文件撰寫的環境(通常是Windows平台)，撰寫TortoiseSVN的操作手冊，讓新加入的成員快速進入狀況。 接著，我們訂定幾個需要遵守的原則(Principle)，在文件部分，要進行編輯的文件一定要...

以往學生在學軟體工程時，總覺得這門課就是在「寫文件」，對於為什麼要寫文件，以及文件的用途，不甚了解，甚至覺得寫文件是很枯燥乏味的一件事。的確，為了交作業而寫文件，我想沒有人會認為寫文件是有用的，特別是對於一個虛擬的軟體專案而言，即使必須開發對應的軟體，充其量也是一個小品，而且一個學期的時間又很有限，所以不是文件品質不好就是軟體沒寫好，更別提要維護了， 而學生無法對軟體跟專案產生情感，自然無法體會文件的意義。 過去三年，筆者因為主持國科會整合型計畫「WiMAX 無線通訊系統軟體與工具開發(I),(II),(III)」的關係，需要主導撰寫其Light-weight CMMI文件，剛開始的第一年，參與計畫的學生們也是哀鴻遍野，學生們即便已經參加過國科會舉辦的Light-weighted CMMI研討會，寫出來的文件，和實際的軟體設計仍有一段很大的落差，一直到第二年，需要開始維護第一年的軟體時，學生才慢慢體會到軟體工程要的不只是文件，而是文件所帶來的價值：溝通與管理。 有一個經常被提到的問題是「軟體流程」？我們的WiMAX整合行計畫到底有多大呢？是否真的需要軟體工程或是完善的軟體流程才能完成呢？這裡先簡單描述一下我們的案子，大家都知道WiMAX被視為M-Taiwan重點發展項目，WiMAX(802.16e)是一個相當複雜的通訊協定，而我們的目標是開發一套完整的「WiMAX網路模擬軟體」，由於WiMAX由上到下包含許多子層，而各子層又各須非常專業的知識，因此，這個案子需要軟體工程加入，才能有效地整合各種跨領域的知識，構成一個完整的系統。也因此我們(北科大軟體研發中心)才提出這個跨領域的整合型計畫，希望開發出WiMAX網路模擬軟體，以開放原始碼的方式貢獻給業界作為WiMAX參考模型，並分享我們的開發經驗。 在WiMAX的案子中分成三個主要項目：「應用」、「協定」與「輔助工具」，應用有「即時視訊傳輸應用」與「適地性資訊服務」；協定負責WiMAX通訊協定的所有子層包含媒體存取控制、安全加密、實體層編碼、實體層調變與通道模擬；輔助工具則提供通訊軟體模型建構工具與持續整合等輔助。由此可知，計畫規模頗大，最多曾經有12個子計畫。軟體流程不能保證專案如期完工，但能用來監控時程與進度，如果沒有流程，進度落後或是超前，都無法掌握，那軟體勢必是無法順利開發與整合的。 有了第一年的...

3/21本人寫了一篇文章介紹OCP設計原則 (意即：要延伸一個類別時不能要求修改該類別) ，多少引起一些反應，現在我們利用這篇短文來輕鬆談談，另外一項重要的軟體設計原則：「依存反向原則」(Dependency Inversion Principle - DIP)。 首先我們談談何謂軟體「設計原則」，在軟體發展的領域中，所謂設計原則是：「在發展軟體系統的動作中，一種可接受的規則或方法，也就是說可使用的工作原則」( http://dictionary.reference.com/ )，好的設計原則必須是能夠協助發展者產生設計主意(idea)，而且可以讓設計者能夠透過設計意涵來思考其實際的設計(Rebecca J. Wirfs-Brock 2009)，依據這樣的定義，我們所要談的設計原則是可實地應用的，不過原則並非嚴格的設計規則，有如設計樣式(design patterns)一樣，僅在某種環境中使用，過份使用設計原則，可能會增加程式的負擔與工作量，因此，如果你確定類別的功能將來不致改變，則不一定要去使用設計原則，不過大部分的設計原則，都是將實作(implementation)引藏起來，以保持設計的彈性，如OCP或本文即將介紹的DIP。 DIP的定義可見諸於各類設計樣式的書本或網頁，簡言之就是：『抽象不能依存於細節，而細節必須依存於抽象』(Abstraction shouldn't depend on details. Details should depend on abstraction - Rebecca J. Wirfs-Brock 2009)，這是何意？我們舉一個簡單的例子：一家公司顧有許多員工，也就是說公司就必須直接依存於這些員工，以軟體結構語言來說，公司是屬於「高階模組」(high-level module)，就是上述DIP定義所謂的「抽象」，而員工則屬於「低階模組」(low-level modeule)，也就是定義所說的「細節」，如果公司因業務需要必須增聘具有高強能力或專長的員工(也許稱之為super employee)，而沒想到使用DIP，則必須修改複雜的公司模組內容，這種修改將影響公司模組的結構，這樣就違反DIP，如果希望增加任何員工而不想影響到公司模組，DIP告訴我們，可以在公司模組與員工模組之間介入一種「抽象層」(abstract layer...

『如果我問我的顧客想要什麼，他們會回答我一匹跑的更快的馬』- 亨利 福特 最近上了一本新書『 Inside Steve's Brain 』，說的是蘋果賈柏斯對經營、設計的一些理念。我想大家對賈柏斯轟轟烈烈的事蹟一定很熟悉（特別是蘋果迷），在此不做贅述。我個人雖不是蘋果迷，但也深深的佩服他對設計的執著與相關產品的簡約。我一直覺得台灣需要的不是系統實作人才，應是軟體設計人才。設計是什麼？我所說的並不是什麼結構性設計、物件導向設計、架構設計等技術的東西。 而是態度。一種對設計的態度。 什麼是設計的態度？答案也許在這本書中。推薦各位看看。 一般而言，軟體工程裡都教我們系統分析時要做需求訪談，聽顧客的話。但在某個領域中，特別是創新的領域中，傾聽自己內心的渴望（對產品的渴望）是更重要的：我們如何能做出讓人能夠感動的產品？Steve 相當欣賞亨利 福特的一句話：『如果我問我的顧客想要什麼，他們會回答我一匹跑的更快的馬』。 在顧客的框框下，你所開發出來的產品是不會感動人的 ，所以 Steve 在開發產品的時候是不做市調的，這相當有自信且冒險。但對 Steve 而言是行得通的，畢竟能讓一個工作團隊花『六』個月的時間調整一個 scrollbar 的人並不多。

看到「好人難為」一文，主角是一位專班學生，看來他似乎很委曲，因此我在意見箱內提議，他可以好好研究一下軟體設計的第一原則：Open-Closed Principle (OCP)，或許可以解決他的困擾，這件事涉及到軟體工程的教育與訓練的問題，也就是說，學以致用的問題，因此有必要寫一篇短文以OCP為例，來談談軟體設計原則的運用，這些原則並非軟體發展的食譜(cookbook)，而是發展者必須放在心裡的「指引」(guideline)，這種指引必須落實成為diciplines，其他如設計樣式(design patterns)也具有指引特性，因此才能廣泛運用，也就是說，可以重覆使用(reuse)，學習時最好蒐集一些範例，可能有助於這些設計原則或樣式的運用，有如念法律的人必須研究一些判例一樣，學習軟體發展方法時也不例外。 OCP是物件導向方法的核心，1988年由Bertrand Meyer在他的著作" Object-Oriented Software Construction "一書提出，它是說：「軟體實體必須能夠延伸但不能修改」(Software entities should be open for extension but closed for modification)，換言之，必要時可以延伸軟體實體的功能但不必修改它，該軟體實體可以是類別、模組、功能、程式、或組件，完全看你用在何處。Meyer的原意是說，類別實作(或程式)除了須要除錯外，如要改變功能或增加新功能時不得改變父類別(superclass)，而由子類別(subclass)來達成，子類別可以利用繼承(inheritance)機制重用父類別的屬性或作業元，但可改變或增減其功能，因此繼承不旦可以重用父類別的實作，同時可以延伸原功能，該子類別的介面可以異於父類別的介面，這是一般具有物件導向的人所熟悉的繼承機制。 到1990年代OCP被重新定義為，新介面可以繼承自「抽象類別」，但非繼承實作部分，原介面不得修改，也就是說，你設計的組件或模組不能改變，當需求改變時，你可以增加新程式以延伸該模組的功能，但不能改變你也許認為十分完美而能作業的原程式，請看下圖(R.C. Martin)， 左邊圖形表示，如果Client想使用另一個Server時，Client必須改變，因為兩者皆是concrete，這樣就不...

從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...

物件導向設計是近十年來軟體工程很重要的課題，除了物件程式設計的技巧、方法論、設計流程以外，工具也是相當重要。在Rational Rose 被IBM併購之前我就使用過它的 UML 設計工具，當時它是我電腦的必備軟體之一，因為不只是上課、做系統需要，我甚至會用它來做一般事務的知識管理。 但隨著UML的快速改版，Rose的改版速度也相當的快，不僅如此，價格飆升也相當的快，快到我追不到。於是，我開始改用open source的一些方案，例如 ArgoUML以及在 Eclipse 上的UML。然而，這些系統的穩定性都不夠。後來，在資訊處中開始使用搭配 power builder 的 power designer，雖然功能與穩定性不錯，但推廣的狀況卻不是很好。 這幾年的感覺是，不要太拘泥於軟體工具的選擇，應該回歸到設計的本質， 其實紙筆就是最好的工具，相互討論就是最好的方法論 。軟體工具採用反而造成相互討論的困難，對設計造成傷害。一群人圍在圓桌上討論設計圖才是最重要的。 用紙筆做UML的設計還是有技巧的。過去我劃類別圖時先劃上一個像『目』的圖案 -- 其中最上面的格子寫上類別名稱、第二個格子寫上屬性、第三個格子寫上方法名稱 -- 但這個方法不好。因為屬性與方法的個數會在討論的過程中不斷的新增，所以固定大小的『目』造成了許多的不便。如左上圖的『F』則保留討論上的彈性，你可以在討論的過程中不斷的加上屬性與類別名稱，且名稱的長度也不會受限。直到你的設計告一段落（例如討論好一些 sequence diagram）才將F關住，成為『目』。 我特別將『F』設計成一個圖形，藉此，傳達軟體設計上『互動』、『敏捷』、『慎重』的重要性。工具依舊是重要的，但在設計初期的時候。我還是強烈的建議使用紙筆來做腦力激盪。

「所有具優良結構的物件導向軟體架構，其內部都充滿樣式(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)，那麼企業接受這...