漫談Agile Modeling
自從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.Plauger曾在1974年著作一本叫"The Elements of Programming Style" (revised 1978)，其中提出一句名言："Keep It Simple, Stupid"，俗稱KISS rule，"Stupid"的意思是說，不要設計複雜難解的程式架構(skeleton)，這項規則雖然是指撰寫程式所應遵循者，但是我認為對於創造模式一樣適用，簡言之，保持你需要的模式越簡單越好，也就是說遵守KISS rule但不要遵循KICK rule (Keep It Complex Kamikaze(神風)"(Ambler言)，就是說不要將模式搞成複雜不已，有如神風特攻隊不怕死。在17項AM原則以及21項AM常規中，應用簡單的原則與常規有下列各項：
- Travel light: 創造剛好夠用的模式與文件即可。
- Assume simplicity：設定最簡單的解決方案就是最好的方案。
- Create simple content：創造的模式其實際的內涵能滿足專案需要即可，包括需求、分析、結構或者設計。
- Depict model simply: 使用簡單的符號以表示你想了解的關鍵功能即可。
- Use the simplest tools：使用的工具越簡單越容易工作，因此主要的模式可以在白板、紙張甚至餐巾背後繪製，當然這並不意味CASE工具無用，如果你認為CASE工具比較能顯示你的設計，那麼就使用它。
正如Kent Beck與Martin Fowler在"Planning Extreme Programming"中的一句話：Stick with simple tools, like pencil, paper, and whiteboard. "，因此我想談談比較有趣的「(盡可能)使用最簡單的工具」這一項。簡單工具最大的優點是：(1) 便宜而且垂手可得；(2) 每個人都會使用而且容易使用；(3) 可促進「反覆與漸增」的發展方式；(4) 用完即可拋棄；(5) 因工具簡單不可能產生太複雜的模式系統。當然也有些缺點，例如不易為某些人所接受、不能做為永續的文件、功能顯示受限而且不易在團隊中分發等。不過你如果只要顯示模式中的關鍵功能，而且希望以模式做為溝通媒介以及描繪系統輪廓(sketch)之用時，簡單工具是最好的選擇。
我舉一簡單的「玩具範例」，不過根據反覆與漸增發展方式或許可以擴大成為實際系統。話說，如果我想發展一套學生選課系統，我可以根據上述常規：Assume simplity, Create simple content, 以及Depict model simply等，使用Class-Responsibilities-Collaborators (CRC) card選擇3個key abstractions：Student, Course, Professor如下：
(註一：CRC card中的類別，其responsibilities分成"know"與"do"兩種，如上圖所顯示。註二：Key abstractions的擬定有兩種方式：(1) 發現(discovery) ─ 由專家提供；(2) 發明(invention) ─ 自己創造新類別與物件，這些物件不一定是問題範疇的一部分，但卻是設計與實作所需要，例如GUI。)
依據上述CRC card所選擇的key abstractions，並且仍然根據KISS規則，我們設計類別輪廓圖如下：
這個類別輪廓可以用反覆與漸增方式擴大成較完整的系統。上圖所顯示的「玩具範例」如利用MDA工具可以快速產生雛型，以測試上述類別圖設計是否另人滿意，以下是Student與Course的Web圖形。
(點選放大)
這篇介紹AM的文章只不過在顯示「簡單」這種敏捷精神，包括上述5項原則與常規，但並非在提供完整的軟體發展步驟，事實上AM技術是可以使用在各種發展方法上。
從事電腦多年，也不是第一次聽到KISS 原則，但再次看到還是給我當頭棒喝的感覺。不只是程式，生活也是。自己的生活很亂，不知道在追求什麼，把每件事情都搞的很複雜、很混亂。很想回到最原始最簡單的生活：沒有汽車、沒有電腦、沒有股票、沒有政治的生活。
回覆刪除可是真的很難吧！人類『升級』到現代文明後還有辦法用簡單來過生活嗎？程式也是吧！一開始的時候還可以保持簡單、有寫註解、遵守命名原則等，但系統慢慢變大以後，就保持不了『簡單』了，最後連自己寫什麼都不知道了。就像人難以回到原始生活一樣。
想要請教：有什麼辦法可以保持一直『簡單』『乾淨』的設計。
回應匿名的意見(黃為德)：
回覆刪除1. 如言，「人類『升級』到現代文明」，我想就很難過原始簡單的生活，只不過記得文章內所提到"Travel light"的原則，就是『夠就好』之意，換言之，用在生活上就是『滿足』，用在軟體設計上就是KISS而不是KICK。
2. 要保持簡單乾淨的設計，可遵守所謂"Open-Closed Principle"，這個設計原則是說，"Modules should be both open for extension but closed for modification in ways that affect client." (很抱歉，這句話一時之間很難用中文表達)，此地的module可以指軟體模組、類別或程式，這個原則看起來有點矛盾，但是舉例來說明，也許容易體會。在設計樣式中有一很重要的樣式叫"Observer"，當你增加新的"Observers"時等於你隨時在延伸"Subject"但不必增加程式。
在看完黃老師對AM介紹,有以下的感想:
回覆刪除1.敏捷要以簡單為出發點
2.對解決問題要以簡單易懂方式與回歸問題的本質去想
3.因為簡單所以不論溝通,設計,使用上都會更迅速
所Agile(敏捷)我覺得這字選的真好,
也讓我想到Apple ipod,Asus eepc...
這些產品設計理念都有共通的特點:由簡單出發
,卻引起市場上很大的共鳴!
謝謝分享!
很喜歡這篇文章^_^
我有點不同意見. 真實的世界中, 我沒法認同 Assume simplicity and Create simple content這兩點. 我覺得這兩點要是能被使用, 應該要有些附帶條件, 否則即容易被濫用.
回覆刪除我假設完整的需求稱為RR,而完全能滿足RR的設計稱為AA.
專案開始後,第一手接觸的BA,SA聽聽需求或許知道了RR長啥樣但,覺得很硬很複雜,就說建議分階段.抓了些好做不互相牴觸的需求R1來說,這些是第一階段,然後就依據R1做出了A1,並開發了.
很有趣的是,這些第一階段的設計者,都很有能耐,在第一階段搞出個看似能用的東西給了客戶,的確,他們都滿足了他們定義第一階段該完成的工作.(廢話,自己已經先挑過了,當然撿軟的吃)
接著,換人接手,上來的SA看了看...R1=RR-R2,挑出了還沒列為第二階段的東西,比了比A1....一整個傻眼,依據A1做出來的東西,R2中複雜的變化通通沒有考慮進去,若得完成,基本上不是直接付加個A2的部分上去即可;根本是得要把崛大部分依據A1做出來的東西打掉,重新做出一個東西,才能滿足RR.所以第二階段才是真正開始在開發.而且是幾乎100%的整個專案.
當然,這還是好的狀況...要是有人不知道壯志斷腕早早直接放棄第一階段不合用的東西,或是時間不允許這樣搞,最後,搞到自己累死,還要被客戶和老闆罵到臭頭.甚至被認為能力不足.
這是真實軟體開發實際碰到的例子,我對那種專門指參與前面階段的人非常感冒.因為通常這種人都很號稱自己很厲害.厲害,厲害怎麼不把專案完全完成呢?
我認為,設計一定要跟據完全完整分析過後的東西來做;完整分析一定要根據所有的需求(有意義的需求,可實做的需求)來做分析. 這樣才能依據整體藍圖,來分階段實做. 若兩階段間的實作範圍有相依性,也必須考量可能暫時以一個虛擬的機制來暫時代替尚未實做的第二階段模組,而第一階段本身的模組必須幾乎是獨立且完整的.這樣才能事先替第二階段先留好未來實做的後路,否則...案子很難搞得好吧.
從匿名的意見看來，他應具有相當的實務經驗，甚至「痛苦」的經驗，因此我願意花點心思回應他的意見如下：
回覆刪除1. 意見中提到實務上碰到的問題，例如某種人「號稱自己很厲害」，我在文章中提到AM的真義(value)第5項：謙卑(Humility)，也就是說，好的軟體發展者，尤其模式製造者，應該承認他們並非什麼都懂，事實上也不可能，因此做為敏捷塑模者必須允許別人提供或協助對專案工作的意見，這個道理很普通，只不過要做到就不太容易，不過這項真義可讓你的工作成功，而且才能與團隊其他人一起工作。
2. 關於Assume Simplicity原則：當你在發展軟體時，首先先必須承認或假定，最簡單的問題解決方案是最好的方案，也就是說一開始花太多的時間去實作困難的解答，你必須先確定簡單的方案是否可work，因此製作模式時不要over-mdole，簡言之，不要加入今天尚不需要的功能(features)，至於將來如改進需求時再refactor你的系統，軟體設計的原則有一種所謂"Open-Closed Principle"或許可以參考。
3. 關於Create Simple Content原則：這項原則就是勸你保持模式的內涵簡單而能滿足專案的需求即可，問題是你怎麼知道你的模式內涵是簡單，我舉Kent Beck在2000年提出XP時的建議參考：
(1) 模式只要傳達你要傳達的東西就可。
(2) 模式不要有重覆的資訊在內。
(3) 模式必須只含蓋最少可能的原素(elements)。
也就是說，不要over-model，當然這些只是原則，如何落實，有時要靠「直覺」(instinct)，正確的直覺是來自經驗，所以說"Work with people's instincts"也是可放在心中的原則。
4. "Iterative & Incremental(I&I)"是目前軟體發展方法或說敏捷方法的主要精神，開始時不要設計太大，就是模式不要一下子就想滿足全部目標，原則上，「今天解決今天需要的事，明天解決明天的事」，這也是Kent Beck的建議。
5. 從你的意見，我感覺你或你的團隊可能並未體會到I&I的精神而應用它，在「漫談Agile Modeling」最後談到：「這類類別輪廓可以用反覆與漸增方式擴大成完整的系統」，是否完整並不重要，我要表達的就是上述2-4各點所談的詮釋，希能體會。
6. 如有其他意見可再提供你的高見，我將再做回應，謝謝。
今天(1/6)上午11:37本人提供的意見有些筆誤，謹修正如下：
回覆刪除2.第2行：「也就是說開始花太多的時間去實作困難的解答」應改成「也就是說開始不要花太多的時間去實作困難的解答」。
又第3行：over-mdole應改成over-model 。
謹致歉意。
黃為德