輕鬆談軟工

「所有具優良結構的物件導向軟體架構，其內部都充滿樣式(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

對於軟體開發人員而言，好的測試案例應該是很有價值的東西，因為如果一個軟體在依據一個測試案例進行測試執行時無法得到正確的預期結果，就知道有某個特定的錯誤存在；而如果這個軟體能在依據所有的測試案例進行測試執行時都得到預期的正確結果，那就不會有人可以說什麼話了，乖乖地付錢給寫程式的人吧。(當然，這必須是針對所謂「好的測試案例」才有意義，否則隨便寫兩、三個測試案例，寫程式的人也可以隨便寫幾行程式就應付自如，只是程式還是無法使用，自欺欺人而已。) 從這個角度來看，會設計「好的測試案例」的人應該在軟體開發團隊裡是有其一定地位的，這種人與一般寫程式的人在心態上就不一樣，大多是以「防禦性」或「預防性」的方式來處理程式邏輯；譬如從來不假設所有可使用的資源(如記憶體)是永遠不會有問題的，因此只要需要任何資源都會先確定這個資源的取得沒有問題才開始動作，否則就進入特殊狀況處理程序。這種人設計的測試案例非常細緻，專門找平常不容易出現的錯誤。(正常狀況都無法得到正確結果的實在不夠資格稱為軟體，真的。) 經驗豐富的軟體從業朋友在工作時是很有樂趣的，旁人只見到高來高去的溝通，而且非常有效率，一點都不八股，同時生產力與品質都有一定的水準(agility?)。在這種環境之下，似乎需求說明文件或需求規格都可以抽象化，文件規模大量減少，幾頁的文圖就可以描述一個應用系統，尤其是不太需要人機介面的核心模組。這些文件原有內容跑到那裡去了？答案是測試案例，那些細緻的、正常狀況下都不會發生的可能預防作為描述，都在測試案例說明裡面。 專家們相信，測試案例與需求規格兩者很可能是相同的東西，就像是拓樸學裡介紹的梅比烏斯帶子(Mobius Strip)，沒有裡面或外面之分；而測試案例比需求規格略佔優勢的地方是，測試案例的描述一般比較明確，需求規格的描述則會弱一些。對軟體開發階段與轉換程序而言，越是明確的描述，越能讓轉換所得的軟體堅實(solid)。這個觀點目前應該是還沒有方法來證明，所以只在提出與討論的階段；雖然有可能是亂想一通(研究的過程之一)，但感覺上似乎不離譜。 你的看法如何呢？難道只是又把需求分析的工作藏到測試案例設計去了？

寫程式的人也要負責最基本的軟體測試工作，那就是單元測試的部份。也因為如此，這類測試常常會跟除錯一併進行，反正一個人要能負責把程式弄好(最起碼在自己能設想到的普通狀況下要能算出正確的答案)，用什麼方法都行。 除錯器(debugger)是最有效的軟體開發輔助工具了，設定中斷點，程式執行到那裡的時候可以逐次檢查各個暫存器的內容、變數的值等等，所有狀況清清楚楚，好不威風。如果沒有除錯器支援怎麼辦？沒關係，自己來。沒有把握的程式部份就在裡面多加一些指令或敘述，把當時的環境狀況、變數現值印(顯示)出來，然後追蹤看看到底自己腦子裡想的、手裡寫出來的，以及編譯器、函數庫、作業系統等系統軟體所轉換出來、認知的，究竟有什麼差異。通常弄明白以後，錯誤就能除掉了。 如果這個概念明確，那是不是可以考慮把測試案例就寫在原來的程式裡呢(怎麼寫先不管它，因為現代的程式語言都蠻複雜的，相關測試輔助系統也還不夠人性化)？當程式執行時「恰好」遇到與測試案例所規劃的狀況相同時，就表示在作單元測試了，預期正確結果可以與當時的計算結果比較，如果兩者相同就不作任何動作，否則就進入例外特殊處理的程式部份。如此，雖然有一點吹牛，但以後當我再說「給我測試案例，其他免談」的要求時，是否表示我這個寫程式的可能已經到了精益求精的水準，負責測試的同仁也不敢不給我了？ 事實上，XP(eXtreme Programming) 派軟工朋友所提倡的 Test Driven Development 方法就是在這些方面表現其功力。他們定義的 unit test 就是一段 code，能達到相當於處理單元測試工作的功能，而不是傳統的一個程序(到 Wikipedia 網站上查一下就可以找到很多相關資訊)。

最近，RFID 開始紅了起來，也應用在許多很多地方，改變人類生活的方式，例如，你到超市買隻魚，可透過 RFID 知道這隻魚從出生到販賣的所有流程：他在哪裡被飼養、吃的是哪些飼料、什麼時候捕獲、什麼時候配送等。 簡單的說，過去我們只在乎魚這個『產品』，現在，我們在乎它被產生的『過程』。 為什麼？ 因為過程代表著品質 。光看魚的眼睛或紅鰓並沒有辦法完全代表他的品質（有聽過一些不肖的商人用漂本粉的吧），當我們瞭解他被生產的過程，例如是不受污染的環境與飼料，我們更能相信它的品質。 軟體工程裡所談的需求管理或 需求追溯（requirements traceability） 有類似的概念。過去我們寫程式、產生系統，也僅重視他最後的產品：能夠順利的執行、畫面十分的平順就好了。但軟體是需要維護的，如果我們沒有紀錄軟體的歷程，那麼一旦需求變更，我們就很難知道所要對應修改的模組。 進一步思考，我們的軟體系統有沒有 RFID？可不可以透過一個機制記錄它被生產的資訊，例如：經過哪些人設計、分析、測試，它的版本修改為何？如果一個沒有被完整測試過的系統，我想我們應該不會有買的意願吧。

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

以寫程式為生(領薪水)的朋友一般都不會擔心程式太大寫不完，但都討厭要配合所謂客戶要求的「需求變更」而常常要把已經寫好的程式不斷改來改去，作很多虛功。依據我的觀察，對這些程式設計高手而言，原來已經寫好的程式要再修改，大概超過 3 次就是耐心的極限了；因為此時的程式已經幾乎是變得體無完膚，不但客戶不會滿意，連寫程式的人自己看了也會想吐血。 對程式設計高手而言，寫程式從來不會有什麼問題，而要寫出「什麼程式才是真正你要的東西」才是大問題。偏偏，「需求變更」就是一個他人常用的藉口(因為不一定是客戶要求的，只要之前有人在需求分析階段有錯誤或偷懶沒有詳細分析，最後都可歸咎於需求變更)，反正是你先去寫，然後他再去看，刺激他的神經之後，再提出他的修改看法叫你改，如此永不疲憊。另一種狀況是，需求分析說明文件的內容只是應付軟體工程開發階段的記錄，非常抽象，譬如是「能令使用者感到愉快的一個小型輸入畫面」。 如果我是負責程式設計的，在看完那種「不可能的任務」(Mission Impossible)需求分析說明文件之後，我因為要繼續領薪水、又要能融入傳統的軟體開發工作團隊之中，我就可能會轉而要求負責軟體測試的團隊成員趕快先把測試案例設計出來，不要等到我把程式寫好了再用這些案例去測我的程式，請他們先把完整的測試案例給我。因為既然以後是要用這些測試案例來測我的程式，那我就依據這些案例的內容來設計我的程式，只要在測試執行時這些案例都能順利通過，我的程式就找不到與這些測試案例目的相關的錯誤了。 給我測試案例，其他免談。

CMMI(Capability Maturity Model Integration) 將軟體開發流程視為一種工程 ( 製造 ) 流程，利用控制、量測、改善 (control, measure, and improve) 等循序漸進的方法，達到軟體流程改善的一個框架。 CMMI 是在美國國防部 DoD 以及國防工業協會 (NDIA) 的支持下， CMU 的軟體工程學院 (Software Engineering Institute, SEI) 發展出來的模型。 CMMI 中許多的概念與原理來自於創立 SEI 軟體流程計畫 (software process program) ，並曾任職於 IBM 、領導大型系統軟體開發的 Watts Humphrey 。根據 IBM 與 SEI 的經驗， Humphrey 將廣泛運用在製造流程中的統計流程控管 (Statistical process control, SPC) 的概念，加以修正、擴充後運用於軟體流程管理中。 在一方面，定義軟體開發流程中的各種活動與其彼此間的關係，是將軟體開發流程視為一種製造流程，並實施量化控制的前提之一。在另一方面，由於這些活動相當繁多、複雜且彼此牽動，故唯有在軟體開發活動結構定義清楚之後，方能找出可量測事物，並根據其關連性推論量測值的意義。 CMMI 將軟體開發相關活動的實務作法分為 25 個流程領域 (process area, PA) ，定義其需管理的項目，含一般目標、特定目標、具體作法等，並找出其彼此間的關連性。 依性質來分，這些 PA 分屬於流程管理、專案管理、工程、與支援等四大類 流程管理 ： CMMI 的目的是流程改善，因此流程的定義、維護、修正等均為重要活動。 專案管理 ：因為軟體開發、維護均以專案為單位，以便在專案進行前進行人力、資源、時間、經費計算以及專案進行中管控，如需求變更、進度監控等。 工程 ：軟體開發實質上涵蓋許多軟體工程的原理與具體作法，如需求發展、分析、應用設計、系統設計、實作、測試、部署、維護等相關活動，這些活動需要加以管理。 支援 ：支持前三類活動進行之環境與工具之支援活動等，例如提供產出物與組態管控、議題追蹤等活動。 CMMI 有連續式 (continuous) 與階段 (staged) 式兩種表示法。採用連續表示法