獨孤木專欄之三＞ UML, OOAD and RUP （下）

**使用者或者是客戶的資訊人員，看不懂相關的文件**

開發專案到底會遇到什麼樣的客戶？其實就像是跟網友見面差不多，
還沒有看到真人，你永遠不知道哪個每天跟你聊天分享心事的超級美
女，其實是一個中年男子。就算你運氣好，以前已經跟這個使用者接
觸過，彼此混的很熟，還是有可能會發生變化。

如果以前的專案做得好，這個人有可能升官，所以他就不會做這個專
案了；如果以前的專案做得不好，有可能這個人就被列入下次裁員的
黑名單裡，所以他也不會做這個專案。更不要提有些時候，你是跟一
些從來都沒有打過交道的人一起開始做一個新的專案。

既然我們在描述的對象是專案，大部分的專案，都是從需求分析開始
。使用者便會提出他們的需求，系統分析師聽到使用者的需求以後，
就會開始把他所收集到的需求寫成文件，接著會去跟使用者確認需求
是否便是如此。

採用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的開發方式，不怎麼適用在台灣社會中。尤其是與大多數
的專案互斥。如果你是開發自有產品，或許可以考慮採用這樣的方式。不
過我可不是開發產品的專家。出了問題，除了『你資質比較魯鈍，又缺乏
經驗，所以沒有正確地體悟大師的講法以及採取正確的做法，才會導致這
樣的結果…』之外，我可是沒有其他比較好的理由喔。 (完)