UML，OOAD，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語言。只有依照這樣完美的方法，才可以確保整個項目的品質，并且開發出可以被重復使用的軟件組件。 

　　老板的思考的確比較單純，然而不少信徒也吃這一套，于是乎根本就不管三七二十一，直接就狠狠地給他用在項目上，絲毫沒有考慮中國社會的特色，應該要先想想師夷之長技以制夷，要盡量中學為體，西學為用才對啊。結果當然是撞的滿頭包。 

　　還好對于信徒來說，通常他們還可以自我安慰：“美國這么先進的國家都采用這么新穎的方法來開發，跟著世界趨勢走，一定不會錯?，F在的問題，一定是因為我們的人資質太過魯鈍，沒有完全依照大師的指示來做。下一次，我們一定要按照大師精辟的理論來開發，一定不會遇到什么問題?！?/P>

　　然后這些信眾們，就會繼續抱著眾人皆醉我獨醒的悲壯，繼續努力下去。一邊做的時候，一邊為自己又累積一些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，投入超出預期的人力與時間。 

　　事情多做了，可是賺不到錢，這怎么劃算呢？要知道，開發項目跟開發產品是不同的。開發項目，就是要在最少的資源之下，提供給客戶一個可以接受的爛貨?？梢曰?00萬就讓客戶愿意結案，絕對不要花101萬，讓客戶擁有一個比較好用的系統。越好用的東西越難做，出槌的機率也越高，為什么要這樣做呢？ 

　　除非今天客戶是人力外包，花錢買你的人月，去幫他開發。這個時候，當然是盡量選擇可以做得長長久久的方式來開發啰。

所以我覺得應該要以項目的特性來選擇項目開發方式。大部分的項目，應該用傳統的軟件生命周期開發方式來開發。

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

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

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

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

　　采用use case driven的OOA(object oriented analysis)，你會請使用者確認的文件，當然就是use case。 

　　接著你會依據use case，開始進行OOD(object oriented design)。當你畫好sequence diagram, class diagram，你可能會希望客戶的信息人員，可以幫忙確認，這些文件所描述的系統，是否正確。 

　　問題是，大部分的使用者，以及客戶的信息人員，其實并沒有足夠的能力，來確認這些文件的正確性與完整性。因為你所提供的文件，他們看不懂。通常需要你的帶領，才看得懂。當他們需要靠你解釋才看得懂時，這時候通常會有一些問題隨之產生。他們通?？梢蕴舫鰧I領域上的錯誤，可是他們通常會忽略掉整個系統的完整性。因為他們會覺得，你所沒有描述的東西，可能寫在另外的文件中。所以如果你提供的文件有錯，通常是你所提供的文件可能不完整，其實要到蠻后期的時候才會發現。這時候修改的成本就會變得非常高了。 

　　為什么采用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的倍數。（待續）

原文轉自：http://www.anti-gravitydesign.com