獨孤木專欄之三＞ 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萬，讓客戶
擁有一個比較好用的系統。越好用的東西越難做，出槌的機率也越高，為
什麼要這樣做呢？

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

所以我覺得應該要以專案的特性來選擇專案開發方式。大部分的專案，應
該用傳統的軟體生命週期開發方式來開發。 (代續)