在CSDN 上看到這篇文章, 雖然已經是兩年前了, 但依然很有趣.
UML, OOAD and RUP （上）
如果你沒聽過UML，容我在此做個解釋。這三個字就是U Must Learn的縮寫，指的就是你一定得學(you must learn)，如果有下一句，應該是You Must Pay。這是幾個大師級的人物，為了要把學術理論順利轉化成現金，所想出來的好點子。基本的想法是，如果可以弄出一套理論，讓全世界想要學軟件開發的人都得要來學習，那他們光賣這套理論的教育訓練、認證、顧問咨詢、以及難用的開發工具，就可以讓公司上市，變成億萬富翁。
開玩笑的。
這是三位對像導向軟件工程界的大師(Grady Booch, James Rumbaugh, Ivar Jacobson)，為了濟世救人所整合出來的一種模型語言，稱為Unified Modeling Language。算是把三個人的東西，切成小塊以後煮一煮，放在碗裡面用湯匙攪一攪，整合成一個大雜燴…嗯，不是，是把三個人的理論去蕪存菁，所整理出來的結果。
UML主要的目的，在於讓所有進行系統分析設計的工程師，可以有一個共同的圖形化語言，來描述他們所想要建立的系統。至於讓公司上市，以及讓所有學習UML的工程師，可以有比較顯赫的履歷表，則算是產品附加價值，不算是主要的目的。
因為這個語言，現在正流行，算是當紅炸子雞，所以許多軟件公司，莫不努力地往這個方向發展，期望引進UML，可以為軟件開發，帶來前所未有的助益。很多人的想法，當然還是圍繞著可以做出被重複使用(reuse)的軟件組件，以加速系統開發為核心。
吉娜：布魯斯，老闆問我什麼是UML？他說他到研討會裡聽到，超人公司已經在採用這個東西了，聽說有非常好的成果。他覺得我們所有的工程師也應該學習這種新的skill，這到底是什麼東西？
布魯斯：這是幾個對像導向分析設計界的大師，所共同建立的新的Modeling Language。
吉娜：Modeling language是什麼東西？算了，我不需要知道這些detail。既然老闆已經說需要引進這種新的趨勢，這就是我們今年的目標。你先找一些人去上課，然後回來我們拿幾個項目開始試試這種新的方法。
既然這只是一種語言，其實並沒有好壞的問題。這就像中文是否比英文優秀一樣，每個人會有不同的看法。只要在使用的時候，它可以發揮它的用處，可以讓看到文件的每個人，都很清楚瞭解你想描述的模型，我覺得它就發揮了這個模型的功用。
然而大師或是大師的徒子徒孫們，不會光把UML這三個字從頭到尾念一遍就了事，他們除了介紹這個語言，還會講其它的理論。這些話，就跟著UML的推廣，跟著被信眾們奉為圭臬，當作是神諭。例如引進UML的團隊，通常會採用Use Case Driven的OOAD(對像導向分析設計)，也通常會想要採用大師建議的開發流程：RUP(Rational Unified Process)，來開發項目。
對很多老闆來說，這些東西就跟用來殺狼人的純銀子彈一樣，可以讓專案所面臨的所有問題都順利解決。所以每次聽到一個比較新潮的理論，就會想要叫屬下用用這麼神奇的理論。而這些東西看起來是這麼的有連貫性，從OOA開始進行需求分析，到使用OOD進行系統設計，接著再用OOP來開發程序，在開發過程中，都依循RUP的規範，再使用共同的UML語言。只有依照這樣完美的方法，才可以確保整個項目的品質，並且開發出可以被重複使用的軟件組件。
老闆的思考的確比較單純，然而不少信徒也吃這一套，於是乎根本就不管三七二十一，直接就狠狠地給他用在項目上，絲毫沒有考慮中國社會的特色，應該要先想想師夷之長技以制夷，要盡量中學為體，西學為用才對啊。結果當然是撞的滿頭包。
還好對於信徒來說，通常他們還可以自我安慰：『美國這麼先進的國家都採用這麼新穎的方法來開發，跟著世界趨勢走，一定不會錯。現在的問題，一定是因為我們的人資質太過魯鈍，沒有完全依照大師的指示來做。下一次，我們一定要按照大師精闢的理論來開發，一定不會遇到什麼問題。』
然後這些信眾們，就會繼續抱著眾人皆醉我獨醒的悲壯，繼續努力下去。一邊做的時候，一邊為自己又累積一些OOAD的開發經驗而自豪。
當然，我個人也覺得，大師一定不會錯，一定是我們資質比較魯鈍，又缺乏經驗，所以沒有正確地體悟大師的講法以及採取正確的做法，才會導致這樣的結果。只是除了我們比較笨以外，總也要找一些理由，把責任推給大師們，不然鐵定會被客戶砍頭。大師既然要濟世救人，就只好請你們抱持著我不入地獄，誰入地獄的決心囉。
所以我會針對我觀察到的幾個因為採用OOAD，以及RUP在台灣做案子所發生的幾個問題，提出我個人的看法。幾個我觀察到的主要問題如下：
-沒有依據項目的特性來選擇項目開發方式。
-使用者或者是客戶的信息人員，看不懂相關的文件。
-信息人員本身不瞭解UML, OOAD以及RUP。
-Relational Database
以下我會針對這些問題，進行我個人的看法。
沒有依據項目的特性來選擇項目開發方式
台灣的軟件項目，通常規模都不是很大，除非你將人力外包給企業使用，否則一般的軟件項目，價格則多半是在一開始就定下來了，項目進行的過程裡，通常沒什麼機會可以調整金額。
項目成員人數，多半在二十人以下。所以如果你要採用RUP來開發項目，你的第一個問題會是，你湊不到足夠的人頭，來擔任每一個RUP所介紹的角色。
此外，你通常也沒有那樣的預算，可以讓每個角色，都把他們該做的文件都做出來。所以你會省略一些流程。每次有人跑RUP跑的不順，他們第一個想法就是：『RUP的體系博大精深，這是多少前人智能的結晶，一定是因為我省略了XX步驟，這次才會走的不順利，下回一定要…』
RUP的另一個問題是，它是iterative的開發方式，也就是說，因為項目一定會有變更需求發生，所以它預期沒有辦法一次就開發出使用者所要的東西。因此在開發時，會重複來個好幾回。每次都會要求使用者提出評估。
這怎麼會是個問題呢？實時取得使用者的響應是一件功德無量的事情啊。問題在於台灣的使用者通常都有正職在身，他們多半是利用農閒時進行專案的開發。所以他們的時間非常寶貴，有機會跟你談一次需求，他就認為這是非常大的恩惠。
在台灣，進行使用者需求訪談，就像在火車站把一個要趕著去搭車的人攔下來進行問卷調查差不多。一開始，他可能還會基於禮貌，填寫問卷。當他需要第四次還是第五次回答同一張問卷的話，他會覺得你是否聽不懂人類所說的語言，還是存心找他麻煩。如果你開發一個系統，得要使用者評估個好幾回的話，God bless you。
就算使用者對你十分仁慈，沒有把你轟出去，採用iterative的做法會有的另外一個問題，其實是在於你的系統是一個iteration，一個iteration慢慢調整，逐漸形成的。所以到底什麼算是在系統的範圍(scope)裡面，其實很難界定。所以如果使用者覺得這個iteration的成品，與他原始需求還有距離，你大概都會被迫再多幾個iteration。而這幾個iteration，是收不到錢的。這跟以前的所謂螺線型的開發方式，在台灣遇到的困難是一樣的。客戶不會因為你多做了幾個循環(cycle)，而多給你錢。然而，你會因為多做了幾個cycle，投入超出預期的人力與時間。
事情多做了，可是賺不到錢，這怎麼划算呢？要知道，開發項目跟開發產品是不同的。開發項目，就是要在最少的資源之下，提供給客戶一個可以接受的爛貨。可以花100萬就讓客戶願意結案，絕對不要花101萬，讓客戶擁有一個比較好用的系統。越好用的東西越難做，出槌的機率也越高，為什麼要這樣做呢？
除非今天客戶是人力外包，花錢買你的人月，去幫他開發。這個時候，當然是盡量選擇可以做得長長久久的方式來開發囉。
所以我覺得應該要以項目的特性來選擇項目開發方式。大部分的項目，應該用傳統的軟件生命週期開發方式來開發。 (待續)
**使用者或者是客戶的信息人員，看不懂相關的文件**
開發項目到底會遇到什麼樣的客戶？其實就像是跟網友見面差不多，還沒有看到真人，你永遠不知道哪個每天跟你聊天分享心事的超級美女，其實是一個中年男子。就算你運氣好，以前已經跟這個使用者接觸過，彼此混的很熟，還是有可能會發生變化。
如果以前的項目做得好，這個人有可能陞官，所以他就不會做這個專案了；如果以前的項目做得不好，有可能這個人就被列入下次裁員的黑名單裡，所以他也不會做這個項目。更不要提有些時候，你是跟一些從來都沒有打過交道的人一起開始做一個新的項目。
既然我們在描述的對象是項目，大部分的項目，都是從需求分析開始。使用者便會提出他們的需求，系統分析師聽到使用者的需求以後，就會開始把他所收集到的需求寫成文件，接著會去跟使用者確認需求是否便是如此。
採用use case driven的OOA(object oriented analysis)，你會請使用者確認的文件，當然就是use case。
接著你會依據use case，開始進行OOD(object oriented design)。當你畫好sequence diagram, class diagram，你可能會希望客戶的信息人員，可以幫忙確認，這些文件所描述的系統，是否正確。
問題是，大部分的使用者，以及客戶的信息人員，其實並沒有足夠的能力，來確認這些文件的正確性與完整性。因為你所提供的文件，他們看不懂。通常需要你的帶領，才看得懂。當他們需要靠你解釋才看得懂時，這時候通常會有一些問題隨之產生。他們通常可以挑出專業領域上的錯誤，可是他們通常會忽略掉整個系統的完整性。因為他們會覺得，你所沒有描述的東西，可能寫在另外的文件中。所以如果你提供的文件有錯，通常是你所提供的文件可能不完整，其實要到蠻後期的時候才會發現。這時候修改的成本就會變得非常高了。
為什麼採用use case來描述一個系統，通常會發生遺漏呢？或許我們應該先看看use case是什麼。
根據我的一知半解呢，use case就是嘗試著用文字來描述系統與外界之間的交互作用。對於沒有看過use case的人來說，我在此舉一個例子來說明。書上最常看到的例子呢，就是一個人用提款機在領錢。雖然我沒有寫過類似的程序，我可以想像一下，這個use case應該包含的內容。
1.Brief Description
這個use case說明，怎麼樣透過提款機來領錢。
2.Flow of Events
這個use case，開始於客戶把卡片插入提款機後，完成身份認證，並且已經選擇要提款。
2.1 Basic Flow
1. 客戶輸入要領取的金額。
2. 系統檢查客戶的金額與次數，是否超過系統中所定義每次提領金額與提領次數的上限。
3. 系統從客戶的存款餘額文件中扣去存款金額的資料。並產生一筆提領紀錄在客戶的交易文件中。
4. 如果是跨行客戶，系統應該產生一筆扣除手續費的資料到信息交換中心。並且更新本行對於清算中心的應收帳款–手續費資料。
5. 進入吐鈔use case。
2.2 Alternative Flows
2.2.1 超過每次允許的提領金額
1. 如果超過每次允許的金額，系統應顯示錯誤訊息：『你不識字嗎？ 一次只能領兩萬！』。
2. 系統應該回到功能選擇畫面。
3. 回到功能選擇use case。
2.2.2 超過提領次數
1. 如果超過提領次數，系統應顯示錯誤訊息：『你這張卡片已經刷爆了！ 趕快去補刷存折吧！』。
2. 系統應該回到功能選擇畫面。
3. 回到功能選擇use case。
2.2.3 客戶選擇取消
1. 如果客戶在輸入金額時，沒有按下確定，卻是按下取消，系統應顯示 錯誤訊息：『不要玩我！快滾吧！』。
2. 系統應該把卡片吐出來。
3. 回到吐卡片use case。
3. Special Requirements
無
4. Preconditions
客戶要正確插入卡片，輸入正確的密碼，通過身份認證，提款機還有足夠的鈔票在裡面。
5. Postconditions
進入吐鈔use case。
6. Extension Points
無
通常會被找到的遺漏：
1.為什麼沒有檢查金額是否正確？台灣的提款機，只能夠輸入100的倍數。
你要領512元是不行的。
2.怎麼沒有顯示要不要換百元鈔？
3.怎麼沒有檢查，機器裡面的鈔票是否足夠？有可能沒有小面額的鈔票啊。
通常不會被找到的遺漏：
1. 跟金資中心如何達成聯機的問題。因為這可能被include到另一個use case裡面去了。
2. 沒有扣除機器的鈔票餘額檔。
3. 吐鈔口要開開關關測試是否可以正常吐錢。
4. 如果吐鈔成功的話，要扣機器本身的餘額檔。
5. 如果成功的話，要把客戶未登折次數加1。
…因為我沒有寫過ATM程序，只能隨隨便便想像可能會有的問題。
我想，用use case開發比較大的問題在於你其實有可能會遺漏掉一些系統該做的事情。在單一use case中，有可能你會有非常多的alternative flow。每個假設，都有可能不成立。所以你得要定義如果這個假設不成立的時候，系統要響應什麼。問題在於一般的使用者，他們提出規則的時候，會把預期系統的反應寫在旁邊。例如，如果系統沒錢，就顯示沒錢錯誤訊息。
問題是用了use case以後，很多這樣的規則，因為你把系統的整個行為模式全部都展開出來，篇幅就會拉的非常長；如果你把共享的部分抽出來，放在include的use case中，user又要交叉比對才可以看到對的東西。當你看到長篇大論的時候，眼睛看的久了，很容易就漏掉該寫的東西。除非我先把所有的規則都寫下來，整個if then else的決策樹也畫出來，不然哪記得你應該寫25個alternative flow而不是24個？而這裡就會變成是user還要花時間去一個一個比對，他們的requirement是否都被use case cover到了。通常使用者會把這個工作交給SA來做，他們再來看結果。因為user通常都很忙，所以SA整理出來的結果他們通常也沒有時間詳細地walk through。所以該遺漏的東西還是會遺漏。
另外一個問題，則在於有些東西，是剛好介於use case與use case之間。因此他會預期在use case A中發現的東西，他沒看到，他就會覺得可能是寫在use case B之中吧。當他去看use case B的時候，他還是沒看到，這時候他不見得會記得，他還想看到什麼。因為我們在review文件時，通常都只會看到這份文件描述的scenario對不對，比較少去想到底缺了什麼。
所以有時候一少，就是少掉一整組use case。例如關於一些系統在運轉時會用到的參數檔，應該要有如何去維護這些參數的use case。這就常常被user忽略掉。這在採用傳統結構化分析畫DFD(數據流程圖)的世界裡，是不太可能發生的，因為每個data，都要描述它是怎麼樣去maintain，或是怎麼樣進入系統中。資料不是來自其它系統，就是來自使用者的輸入，或是系統本身運算出來的結果。透過DFD，資料的流向與加工會非常清楚。然而使用use case就沒有這個好處。我覺得遺漏是OOA的天性，難怪得要配合iterative的process。
特別強調要用這樣的方法，另外還會衍生出來的問題是，有些客戶因為看不懂這些文件，所以會堅持以他們所提供的文件當作是系統的範圍。這通常就會產生非常多的事端。
客戶使用者甲：布魯斯，你們寫的這個use case我們研究了很久，我們看不懂。這樣我們不敢在這份文件上簽名。
布魯斯：你們看不懂，我可以隨時來解釋啊。你們一定要在這份需求文件上簽名啦。我們一定要有一個基準，不然以後發生問題怎麼辦？
客戶信息部門人員乙(幫忙打圓場)：布魯斯，我知道use case這個東西是最新的方法論。可是我們的user就是水準還沒有到這邊。
客戶使用者甲：其實系統的範圍，我們一直都寫得很清楚啊。我上次寄給你的power point文件就把系統的功能都寫的很清楚了。
布魯斯心想，狗屎，這麼不詳細的東西也可以拿來算數的喔？：我是覺得那份power point文件是已經把系統的功能大方向都點出來了啦，可是還是有很多細微的地方沒有提到。(這應該算是一次成功的防禦。)
客戶信息部門人員乙(幫忙打圓場)：不然，我們請user把他們的想法寫的更明確好了，我想可能要把他們的作業流程跟需求寫的更清楚一點。
客戶使用者甲：好吧，我把以前提供給你們的規則寫的更清楚一點，再加上我們以前的會議記錄，就是我們系統應該達成的範圍。
布魯斯 ：這樣不行啦。我們的人都是base on我們這份use case來開發呢？
客戶使用者甲：好啦，我辛苦一點，我盡量把你的use case看一看，挑挑看有沒有問題。可是你在今天的會議記錄上要寫清楚喔，系統的功能應該以我以前提供給你們的規則為基準，再加上我們以前的會議記錄，就是我們系統應該達成的範圍。至於你們的use case，我是不會簽名的。
布魯斯想，看來要他們確認是很難的啦：好吧，那就只好辛苦你了。你需要多久的時間？…
過了幾個月，使用者看到頭一個版本後，雙方再度開會。
客戶使用者甲：我們在文件裡面提到的功能，你們都沒有做到。
布魯斯 ：那是因為你在review use case時，也沒有提出這一點啊。 這樣啦，我們在下一個iteration把它納進來。我會回頭改過use case，再讓你double check一次。
客戶使用者甲：好吧。希望下一個版本就可以看得到。
過了幾個月，已經把原有預計要走的幾個iteration全部都走完了，功能還是不如預期，所以雙方再度開會。
客戶使用者甲：我們已經看過多少個版本了，你們一直到這版，都還是問題百出。你們到底有沒有認真去看過我們所提供的文件啊？
布魯斯：我記得上次我們已經應你們的要求，把requirement跟use case的對應都做成excel，一條規則一條規則讓你們確認了，你們還是沒有確認出來，還提出這麼多change request。我不管，這些我們得要收費。
客戶使用者甲：收錢？你翻翻我們7/5的會議記錄。雖然在我們原始文件提出的規則裡面沒有描述到這條規則，可是我們在會議記錄裡面有提到這個功能需要檢查員工到職不滿一年，不適用這個狀況啊。這是我們在去年6月底檢討作業辦法時修訂的啊。
布魯斯：這應該算是change request。況且你們review use case已經review那麼多次了。我記得我們在12/14的會議裡面有提到，凡是沒有列在use case裡面的需求，都應該算是change request。
客戶使用者甲：那是你單方面的想法，誰同意啊？況且你們改過那麼多次版本，我們哪有能力去看你每個版本，記得你每個版本裡面到底寫什麼？我都跟你說我們看不懂use case了，是你說你們的人一定要看，其他的文件看不懂，才幫你檢查的。現在問題就都在我身上？
布魯斯：話不是這樣講…
過了不曉得又多少個iteration…
客戶使用者甲：我下個禮拜要調到BOS部門去了。
布魯斯：那我們怎麼辦？
客戶使用者甲：我還在我們公司啊。新的承辦人不錯啦，我會有空多幫他的忙。
過了一個禮拜…
客戶使用者丙：這個use case是什麼東西啊？
布魯斯：……
信息人員本身不瞭解UML, OOAD以及RUP
其實客戶不瞭解UML, OOAD以及RUP是很正常的事情。我除了在看新人的履歷表，可以找到精通UML，熟悉OOAD，以及專精RUP的人以外，在現實生活中，大概只有在Rational這家公司出來的顧問中，才找得到自認為他非常熟悉這些東西的人。
大部分聽過這些term自認瞭解的人其實都一知半解。(這不包括我，我是根本不瞭解。)可是最怕的就是不懂裝懂。如果你遇到客戶的信息人員不瞭解這些東西，卻在上完短期的課程後，想要給你來些良心的建議，還是卓越的指導，你就完了。
客戶IT人員甲：我覺得你這個圖這裡畫錯了。這個關係，應該用實心的菱形？
布魯斯：你誤會我們想要描述的關係，其實我們在圖上並沒有刻意去…
過了半小時…
客戶IT人員甲：我覺得你這個use case這裡用『當使用者輸入email後，系統應檢查email正確性。』這樣寫不夠清楚，你應該還要描述email格式有錯時的alternative flow。不然programmer怎麼會知道，系統要怎麼響應？
布魯斯：我們針對這些問題…
過了一小時…
客戶IT人員甲：你的文件我們看得差不多了，現在我們來看RUP的artifact…
布魯斯心想，殺了我吧，這種無聊的會還要開多久啊…
我遇過最狠的，是在use case的敘述裡面挑語句是否通順。原則上呢，就是在改作文。如果你用英文寫，就是抓你第三人稱是否記得加s之類的問題；如果你用中文寫，就是嫌你作文寫得太差。
隨筆提到另一個更狠的客戶，這位小姐的挑錯就跟use case沒啥關係。她只是強調我們用html做成的prototyping上面所有error message的標點符號，要統一變成全角中文。這樣error message才不會有的比較寬，有的比較窄。儘管我們再三解釋prototyping的用途不在於此，她還是堅持要我們把所有的標點符號換成全角，她才願意繼續review下去。我們換了好幾次，每次只要一有漏掉，就會被她抱怨，我們低下的作業品質，似乎為她想要找人出氣的生活，帶來不少樂趣與練功的靶子。
我年少蒙懂時，遇過另一個活生生的例子。
客戶IT人員甲：為什麼你們在use case裡面沒有描述，可以在class diagram裡面設計出這個class？這分明是你們分析與設計不連貫。
我：use case與class diagram沒有一對一的關係啊。
客戶IT人員甲心想，你分明是在狡辯：你們沒有遵照RUP來開發程序…
後來經過我引經據典，舌戰群儒，終於贏得了這場辯論。比較年少無知的我，以為在辯論上獲得勝利，應該獲得英雄式的肯定，客戶應該要跪拜在真理面前向我膜拜。
後來才發現，我自己需要接受卡內基訓練。因為從我在辯論中獲勝開始，就種下了一個超級不好的因，讓我在後來做這個案子的時候，吃盡了苦頭。對於大多數講求思辯方法的人來說，科學是冰冷的事實；可是對於凡人，通常也就是客戶來說，你把我惹毛了，我會讓你的日子很難過。所以從我開始說明真理的那一天開始，這些被我惹毛的信徒們，就繼續用不符合邏輯的言論，不斷地折磨我們。
對信徒來說，要先做OO的analysis才能進行OO的design，有了OO的design
，才可以找出design pattern，才可以建立可以被reuse的component。這幾乎是跟先有雞，才會有蛋一樣真實；只是對我來說，我們現在所謂的OOA跟OOD之間的關係，比較像是狗跟蛋之間的關係。明明就是兩個不相同的物種，怎麼會有什麼關係呢？我記得我小時候學習OOP時，class都是從天上掉下來的禮物，跟use case driven的OOA中間有什麼直接的關係呢？在我的那個年代，只要你有眼睛，學過data structure與algorithm，觀察現象，就可以想出class出來。只是這種好日子已經過去了。
做苦工做久了，就會想要偷懶，就把共享的東西拉出來。偷懶是所有程式設計師設計出超強component的原動力之一。又懶惰又聰明的人，才會想出一些把戲，讓他可以出一張嘴，就叫計算機自己把程序寫好。這就是reuse的由來啊。
我認識不少超強的程序設計師，開發共享組件的驅動力在於讓他有時間，可以用上班的時間去逛色情網站，還可以在規定的時間內，把該做的事情做完。通常逛色情網站只對男性有誘因，女性總有比較重要的事情要做，例如減肥。所以這些我所認識的超人，清一色都是好色的男性。
這些好色的高手，最喜歡做的事情，當然就是寫程序去把所有色情網站的內容抓回家，然後與同好共賞。我個人覺得軟件工業有蠻多進步，就在於設立色情網站的人，與好色的超強程序設計師之間相互鬥法，所激盪出來的。
認識這些好色的強人以後，我就覺得OOA、OOD跟可以被reuse的component
之間，根本一點因果關係都沒有。難道他們是在逛色情網站的時候，在腦袋裡面同時多任務去寫use case嗎？還是同時多任務去畫sequence diagram嗎？有誰在看著小澤圓、飯島愛跟白石瞳時，可以同時想這些東西呢？
除了客戶不瞭解UML，OOAD跟RUP以外，另外一個更糟糕的現象就是Project team裡面的人也不懂。我預期這種情況，會隨著學校教育洗腦的成功而改善。有些小朋友從來都沒聽過也沒畫過DFD，就跟我們拿建構式數學去荼毒下一代是一樣的道理。教導比較年輕的一代採用比較笨的方法，可以確保老人的競爭力。
在我剛開始接觸UML的這幾年，遇到的現象是project team自己都看不懂這些東西是什麼。於是彼此之間都在摸索。有經驗的老鳥，對於UML，OOAD一點概念也沒有。可是被逼上梁山，一定得要用，所以就用自己的經驗胡亂使用。沒經驗的菜鳥，雖然懂得UML，可是缺乏process的實踐經驗，也不懂任何domain knowledge，所以只能任人宰割。
問題是當菜鳥發現老鳥畫出來的圖，還是寫出來的文件不怎麼樣的時候，除了要面對年輕人因為夢想幻滅而心生怨懟以外，還得要面對老鳥漫長的學習曲線。通常在這種情況之下呢，會面臨成員間永不停止的爭辯，大多數都是引經據典關於正統的辯論，無形之中，耗費了相當多開發的時間。
接著就看到原先預設的schedule，像是自由落體一樣墜落。每次遇到這種場景，就讓我不禁懷念起那個使用結構化分析的年代。一切都是那麼簡單、直覺與美好。沒辦法，每個時代都有屬於它自己的流行。就像是關係型數據庫一樣。
Relational Database
儘管OO的聲音喊的震天響，Relational database(關係型數據庫)還是在IT產業中扮演一個非常重要的角色。很多人一直在想，要用支持OO的database。問題是在這個業界裡，有太多人熟悉SQL以及relational database。有太多錢花在買Oracle, Sybase, db2, Informix, MS SQL Server上。這讓人relational database退休的機會變得非常小。而relational database的基本精神，跟OO就不太有關了。這讓我們想要用Object的方式來思考，遇到RDBMS，就O不下去了。你可以想像一個從懸崖邊大聲喊著O，然後跳下去的人，當你聽到聲音越來越小，著地之前那個低沉的o(已經變成小寫了喔)，這跟你用OO的觀念遇到Relational Database差不多。這個無聊的比喻雖然沒什麼用，可是又讓我多賺幾個字的稿費。
有些人是用object的觀念，把table包起來。然而，在performance不好時，SQL statement還是會直接寫在程序裡，真要沒辦法，還要寫stored procedure
。如果已經到了要寫stored procedure這樣子的階段，還有什麼OOD可以對應呢？還有什麼object可以用呢？
這個業界有太多熟悉SQL的programmer。對於這些人來說，SQL的威力這麼強大，要去抗拒直接使用SQL statement的誘惑，改用純粹以Object的觀點來解問題，手會變得很癢。遇到有些很容易透過SQL解決的問題時，心會變得更癢。根據研究男性心裡的醫學報告指出(在此再次感謝靈犬萊西的顯靈)，忍耐太久是會生病的。所以只要他們一忍不住出手，通常performance就會有鉅幅的改善。只是這就跟OO沒啥關係了。不過，這對於所有audit這個項目的人來說，這算是瑕不掩瑜。睜一隻眼，閉一隻眼也就過去了。Project可以結案最重要，誰還管OOAD啊？這多少也算是OOAD面臨的問題之一吧。
**結語**
念過大學，準備過考試的人都知道，文不如表，表不如圖。要描述你的觀念，用一張適當的圖形來表示是最強而有力，也是最容易讓人理解的途徑。然而為什麼在系統分析的這個領域裡，我們會希望透過use case來描述這個系統，而不是透過其它的方法呢？
如果你採用結構化分析(Structure Analysis)的方法，而你做的項目規模也比較小，其實使用者會有能力畫出他們的作業流程圖。有了流程圖，其實拿給development team看，大概也知道要做什麼了。認真一點的使用者還可以幫你確認你的DFD(data flow diagram數據流程圖)。
畫出DFD以後，就可以讓系統的範圍用一個圖形化的方法加以確認。也可以認清Data與process之間的關係與流向，接著只要依據資料的流向，寫出function spec，再定義出data dictionary，大部分的SA工作就已經完成了。只剩下如何跟客戶確認需求了。
如果你又採用了RAD(快速應用程序開發rapid application development)的工具，你就可以迅速地建立起系統的雛形(prototype)。透過雛形的展示，以及function spec，在大部分的項目中，你可以跟使用者建立起一個共識的基礎。系統的範圍就可以隨之確定下來。
一旦SA有了共識，要求使用者確認相關的文件，接著採用傳統的瀑布式開發方式(SDLC, System Development Life Cycle)來開發系統。當你遇到需求變更的時候，透過SA文件的確認，雙方也就可以在一套溝通與討論的基礎上繼續下去。
接著你再去採用OOD的方法來設計系統，用OOP(Object Oriented Programming)
的方式來開發系統，這不是很好嗎？
還有人喜歡寫use case嗎？或許在超大型的項目，例如要一百萬個人做個數百年，有個幾萬個iteration的項目裡，寫use case就會是一件很有意義的事情。我想當年蓋大金字塔的建築師，一定寫過use case。
至於RUP，我個人覺得如果仔細研究RUP，會對於大型項目開發的流程有很清楚的瞭解。至於對於中小型項目來說，在你進行項目管理的時候，你可以從RUP裡面找到許多可以參考的模板。
只是iterative的開發方式，不怎麼適用在台灣社會中。尤其是與大多數的項目互斥。如果你是開發自有產品，或許可以考慮採用這樣的方式。不過我可不是開發產品的專家。出了問題，除了『你資質比較魯鈍，又缺乏經驗，所以沒有正確地體悟大師的講法以及採取正確的做法，才會導致這樣的結果…』之外，我可是沒有其它比較好的理由喔。 (完)