如果你沒聽過UML，容我在此做個(gè)解釋。這三個(gè)字就是U Must Learn的縮寫，指的就 是你一定得學(xué)(you must learn)，如果有下一句，應(yīng)該是You Must Pay。這是幾個(gè)大師級(jí)的人物，為了要把學(xué)術(shù)理論順利轉(zhuǎn)化成現(xiàn)金，所想出來的好點(diǎn)子?；镜南敕ㄊ牵喝绻梢耘鲆惶桌碚?，讓全世界想要學(xué)軟件開發(fā)的人都得要來學(xué)習(xí)，那他們光賣這 套理論的教育訓(xùn)練、認(rèn)證、顧問咨詢、以及難用的開發(fā)工具，就可以讓公司上市，變成億萬富翁。開玩笑的。
這是三位對(duì)象導(dǎo)向軟件工程界的大師(Grady Booch, James Rumbaugh, Ivar Jacobson)，為了濟(jì)世救人所整合出來的一種模型語(yǔ)言，稱為Unified Modeling Language。算是把三個(gè)人的東西，切成小塊以后煮一煮，放在碗里面用湯匙攪一攪，整合成一個(gè)大雜燴… 嗯，不是，是把三個(gè)人的理論去蕪存菁，所整理出來的結(jié)果。
UML主要的目的，在于讓所有進(jìn)行系統(tǒng)分析設(shè)計(jì)的工程師，可以有一個(gè)共同的圖形化語(yǔ)言，來描述他們所想要建立的系統(tǒng)。至于讓公司上市，以及讓所有學(xué)習(xí)UML的工程師，可以有比較顯赫的履歷表，則算是產(chǎn)品附加價(jià)值，不算是主要的目的。
因?yàn)檫@個(gè)語(yǔ)言，現(xiàn)在正流行，算是當(dāng)紅炸子雞，所以許多軟件公司，莫不努力地往這個(gè)方向發(fā)展，期望引進(jìn)UML，可以為軟件開發(fā)，帶來前所未有的助益。很多人的想法，當(dāng)然還是圍繞著可以做出被重復(fù)使用(reuse)的軟件組件，以加速系統(tǒng)開發(fā)為核心。
吉娜：布魯斯，老板問我什么是UML？他說他到研討會(huì)里聽到，超人公司已經(jīng)在采用這個(gè)東西了，聽說有非常好的成果。他覺得我們所有的工程師也應(yīng)該學(xué)習(xí)這種新的skill，這到底是什么東西？
布魯斯：這是幾個(gè)對(duì)象導(dǎo)向分析設(shè)計(jì)界的大師，所共同建立的新的Modeling Language。
吉娜：Modeling language是什么東西？算了，我不需要知道這些detail。既然老板已經(jīng)說需要引進(jìn)這種新的趨勢(shì)，這就是我們今年的目標(biāo)。你先找一些人去上課，然后回來我們拿幾個(gè)項(xiàng)目開始試試這種新的方法。
既然這只是一種語(yǔ)言，其實(shí)并沒有好壞的問題。這就像中文是否比英文優(yōu)秀一樣，每個(gè)人會(huì)有不同的看法。只要在使用的時(shí)候，它可以發(fā)揮它的用處，可以讓看到文件的每個(gè)人，都很清楚了解你想描述的模型，我覺得它就發(fā)揮了這個(gè)模型的功用。
然而大師或是大師的徒子徒孫們，不會(huì)光把UML這三個(gè)字從頭到尾念一遍就了事，他們除了介紹這個(gè)語(yǔ)言，還會(huì)講其它的理論。這些話，就跟著UML的推廣，跟著被信眾們奉為圭臬，當(dāng)作是神諭。例如引進(jìn)UML的團(tuán)隊(duì)，通常會(huì)采用Use Case Driven的OOAD(對(duì)象導(dǎo)向分析設(shè)計(jì))，也通常會(huì)想要采用大師建議的開發(fā)流程：RUP(Rational Unified Process)，來開發(fā)項(xiàng)目。
對(duì)很多老板來說，這些東西就跟用來殺狼人的純銀子彈一樣，可以讓專案所面臨的所有問題都順利解決。所以每次聽到一個(gè)比較新潮的理論，就會(huì)想要叫屬下用用這么神奇的理論。而這些東西看起來是這么的有連貫性，從OOA開始進(jìn)行需求分析，到使用OOD進(jìn)行系統(tǒng)設(shè)計(jì)，接著再用OOP來開發(fā)程序，在開發(fā)過程中，都依循RUP的規(guī)范，再使用共同的UML語(yǔ)言。只有依照這樣完美的方法，才可以確保整個(gè)項(xiàng)目的品質(zhì)，并且開發(fā)出可以被重復(fù)使用的軟件組件。
老板的思考的確比較單純，然而不少信徒也吃這一套，于是乎根本就不管三七二十一，直接就狠狠地給他用在項(xiàng)目上，絲毫沒有考慮中國(guó)社會(huì)的特色，應(yīng)該要先想想師夷之長(zhǎng)技以制夷，要盡量中學(xué)為體，西學(xué)為用才對(duì)啊。結(jié)果當(dāng)然是撞的滿頭包。
還好對(duì)于信徒來說，通常他們還可以自我安慰：“美國(guó)這么先進(jìn)的國(guó)家都采用這么新穎的方法來開發(fā)，跟著世界趨勢(shì)走，一定不會(huì)錯(cuò)?，F(xiàn)在的問題，一定是因?yàn)槲覀兊娜速Y質(zhì)太過魯鈍，沒有完全依照大師的指示來做。下一次，我們一定要按照大師精辟的理論來開發(fā)，一定不會(huì)遇到什么問題。”
然后這些信眾們，就會(huì)繼續(xù)抱著眾人皆醉我獨(dú)醒的悲壯，繼續(xù)努力下去。一邊做的時(shí)候，一邊為自己又累積一些OOAD的開發(fā)經(jīng)驗(yàn)而自豪。
當(dāng)然，我個(gè)人也覺得，大師一定不會(huì)錯(cuò)，一定是我們資質(zhì)比較魯鈍，又缺乏經(jīng)驗(yàn)，所以沒有正確地體悟大師的講法以及采取正確的做法，才會(huì)導(dǎo)致這樣的結(jié)果。只是除了我們比較笨以外，總也要找一些理由，把責(zé)任推給大師們，不然鐵定會(huì)被客戶砍頭。大師既然要濟(jì)世救人，就只好請(qǐng)你們抱持著我不入地獄，誰(shuí)入地獄的決心啰。
所以我會(huì)針對(duì)我觀察到的幾個(gè)因?yàn)椴捎肙OAD，以及RUP在臺(tái)灣做案子所發(fā)生的幾個(gè)問題，提出我個(gè)人的看法。幾個(gè)我觀察到的主要問題如下：
-沒有依據(jù)項(xiàng)目的特性來選擇項(xiàng)目開發(fā)方式。
-使用者或者是客戶的信息人員，看不懂相關(guān)的文件。
-信息人員本身不了解UML, OOAD以及RUP。
-Relational Database
以下我會(huì)針對(duì)這些問題，進(jìn)行我個(gè)人的看法。
沒有依據(jù)項(xiàng)目的特性來選擇項(xiàng)目開發(fā)方式
臺(tái)灣的軟件項(xiàng)目，通常規(guī)模都不是很大，除非你將人力外包給企業(yè)使用，否則一般的軟件項(xiàng)目，價(jià)格則多半是在一開始就定下來了，項(xiàng)目進(jìn)行的過程里，通常沒什么機(jī)會(huì)可以調(diào)整金額。
項(xiàng)目成員人數(shù)，多半在二十人以下。所以如果你要采用RUP來開發(fā)項(xiàng)目，你的第一個(gè)問題會(huì)是，你湊不到足夠的人頭，來?yè)?dān)任每一個(gè)RUP所介紹的角色。
此外，你通常也沒有那樣的預(yù)算，可以讓每個(gè)角色，都把他們?cè)撟龅奈募甲龀鰜怼Ｋ阅銜?huì)省略一些流程。每次有人跑RUP跑的不順，他們第一個(gè)想法就是：“RUP的體系博大精深，這是多少前人智能的結(jié)晶，一定是因?yàn)槲沂÷粤薠X步驟，這次才會(huì)走的不順利，下回一定要…”
RUP的另一個(gè)問題是，它是iterative的開發(fā)方式，也就是說，因?yàn)轫?xiàng)目一定會(huì)有變更需求發(fā)生，所以它預(yù)期沒有辦法一次就開發(fā)出使用者所要的東西。因此在開發(fā)時(shí)，會(huì)重復(fù)來個(gè)好幾回。每次都會(huì)要求使用者提出評(píng)估。
這怎么會(huì)是個(gè)問題呢？實(shí)時(shí)取得使用者的響應(yīng)是一件功德無量的事情啊。問題在于臺(tái)灣的使用者通常都有正職在身，他們多半是利用農(nóng)閑時(shí)進(jìn)行專案的開發(fā)。所以他們的時(shí)間非常寶貴，有機(jī)會(huì)跟你談一次需求，他就認(rèn)為這是非常大的恩惠。
在臺(tái)灣，進(jìn)行使用者需求訪談，就像在火車站把一個(gè)要趕著去搭車的人攔下來進(jìn)行問卷調(diào)查差不多。一開始，他可能還會(huì)基于禮貌，填寫問卷。當(dāng)他需要第四次還是第五次回 答同一張問卷的話，他會(huì)覺得你是否聽不懂人類所說的語(yǔ)言，還是存心找他麻煩。如果你開發(fā)一個(gè)系統(tǒng)，得要使用者評(píng)估個(gè)好幾回的話，God bless you。
就算使用者對(duì)你十分仁慈，沒有把你轟出去，采用iterative的做法會(huì)有的另外一個(gè)問題，其實(shí)是在于你的系統(tǒng)是一個(gè)iteration，一個(gè)iteration慢慢調(diào)整，逐漸形成的。所以到底什么算是在系統(tǒng)的范圍(scope)里面，其實(shí)很難界定。所以如果使用者覺得這個(gè)iteration的成品，與他原始需求還有距離，你大概都會(huì)被迫再多幾個(gè)iteration。而這幾個(gè)iteration，是收不到錢的。這跟以前的所謂螺線型的開發(fā)方式，在臺(tái)灣遇到的困難是一樣的?？蛻舨粫?huì)因?yàn)槟愣嘧隽藥讉€(gè)循環(huán)(cycle)，而多給你錢。然而，你會(huì)因?yàn)槎嘧隽藥讉€(gè)cycle，投入超出預(yù)期的人力與時(shí)間。
事情多做了，可是賺不到錢，這怎么劃算呢？要知道，開發(fā)項(xiàng)目跟開發(fā)產(chǎn)品是不同的。開發(fā)項(xiàng)目，就是要在最少的資源之下，提供給客戶一個(gè)可以接受的爛貨?？梢曰?00萬就讓客戶愿意結(jié)案，絕對(duì)不要花101萬，讓客戶擁有一個(gè)比較好用的系統(tǒng)。越好用的東西越難做，出槌的機(jī)率也越高，為什么要這樣做呢？
除非今天客戶是人力外包，花錢買你的人月，去幫他開發(fā)。這個(gè)時(shí)候，當(dāng)然是盡量選擇可以做得長(zhǎng)長(zhǎng)久久的方式來開發(fā)啰。
所以我覺得應(yīng)該要以項(xiàng)目的特性來選擇項(xiàng)目開發(fā)方式。大部分的項(xiàng)目，應(yīng)該用傳統(tǒng)的軟件生命周期開發(fā)方式來開發(fā)。
**使用者或者是客戶的信息人員，看不懂相關(guān)的文件**
開發(fā)項(xiàng)目到底會(huì)遇到什么樣的客戶？其實(shí)就像是跟網(wǎng)友見面差不多，還沒有看到真人，你永遠(yuǎn)不知道哪個(gè)每天跟你聊天分享心事的超級(jí)美女，其實(shí)是一個(gè)中年男子。就算你運(yùn)氣好，以前已經(jīng)跟這個(gè)使用者接觸過，彼此混的很熟，還是有可能會(huì)發(fā)生變化。
如果以前的項(xiàng)目做得好，這個(gè)人有可能升官，所以他就不會(huì)做這個(gè)專案了；如果以前的項(xiàng)目做得不好，有可能這個(gè)人就被列入下次裁員的黑名單里，所以他也不會(huì)做這個(gè)項(xiàng)目。更不要提有些時(shí)候，你是跟一些從來都沒有打過交道的人一起開始做一個(gè)新的項(xiàng)目。
既然我們?cè)诿枋龅膶?duì)象是項(xiàng)目，大部分的項(xiàng)目，都是從需求分析開始。使用者便會(huì)提出他們的需求，系統(tǒng)分析師聽到使用者的需求以后，就會(huì)開始把他所收集到的需求寫成文件，接著會(huì)去跟使用者確認(rèn)需求是否便是如此。
采用use case driven的OOA(object oriented analysis)，你會(huì)請(qǐng)使用者確認(rèn)的文件，當(dāng)然就是use case。
接著你會(huì)依據(jù)use case，開始進(jìn)行OOD(object oriented design)。當(dāng)你畫好sequence diagram, class diagram，你可能會(huì)希望客戶的信息人員，可以幫忙確認(rèn)，這些文件所描述的系統(tǒng)，是否正確。
問題是，大部分的使用者，以及客戶的信息人員，其實(shí)并沒有足夠的能力，來確認(rèn)這些文件的正確性與完整性。因?yàn)槟闼峁┑奈募?，他們看不懂。通常需要你的帶領(lǐng)，才看得懂。當(dāng)他們需要靠你解釋才看得懂時(shí)，這時(shí)候通常會(huì)有一些問題隨之產(chǎn)生。他們通常可以挑出專業(yè)領(lǐng)域上的錯(cuò)誤，可是他們通常會(huì)忽略掉整個(gè)系統(tǒng)的完整性。因?yàn)樗麄儠?huì)覺得，你所沒有描述的東西，可能寫在另外的文件中。所以如果你提供的文件有錯(cuò)，通常是你所提供的文件可能不完整，其實(shí)要到蠻后期的時(shí)候才會(huì)發(fā)現(xiàn)。這時(shí)候修改的成本就會(huì)變得非常高了。
為什么采用use case來描述一個(gè)系統(tǒng)，通常會(huì)發(fā)生遺漏呢？或許我們應(yīng)該先看看use case是什么。
根據(jù)我的一知半解呢，use case就是嘗試著用文字來描述系統(tǒng)與外界之間的交互作用。對(duì)于沒有看過use case的人來說，我在此舉一個(gè)例子來說明。書上最常看到的例子呢，就是一個(gè)人用提款機(jī)在領(lǐng)錢。雖然我沒有寫過類似的程序，我可以想象一下，這個(gè)use case應(yīng)該包含的內(nèi)容。
1.Brief Description
這個(gè)use case說明，怎么樣透過提款機(jī)來領(lǐng)錢。
2.Flow of Events
這個(gè)use case，開始于客戶把卡片插入提款機(jī)后，完成身分認(rèn)證，并且已經(jīng)選擇要提款。
2.1 Basic Flow
1. 客戶輸入要領(lǐng)取的金額。
2. 系統(tǒng)檢查客戶的金額與次數(shù)，是否超過系統(tǒng)中所定義每次提領(lǐng)金額與提領(lǐng)次數(shù)的上限。
3. 系統(tǒng)從客戶的存款余額文件中扣去存款金額的資料。并產(chǎn)生一筆提領(lǐng)紀(jì)錄在客戶的交易文件中。
4. 如果是跨行客戶，系統(tǒng)應(yīng)該產(chǎn)生一筆扣除手續(xù)費(fèi)的資料到信息交換中心。并且更新本行對(duì)于清算中心的應(yīng)收帳款--手續(xù)費(fèi)資料。
5. 進(jìn)入吐鈔use case。
2.2-- Alternative Flows
2.2.1 超過每次允許的提領(lǐng)金額
1. 如果超過每次允許的金額，系統(tǒng)應(yīng)顯示錯(cuò)誤訊息：“你不識(shí)字嗎？-- 一次只能領(lǐng)兩萬！”。
2. 系統(tǒng)應(yīng)該回到功能選擇畫面。
3. 回到功能選擇use case。
2.2.2- 超過提領(lǐng)次數(shù)
1. 如果超過提領(lǐng)次數(shù)，系統(tǒng)應(yīng)顯示錯(cuò)誤訊息：『你這張卡片已經(jīng)刷爆了！-- 趕快去補(bǔ)刷存折吧！』。
2. 系統(tǒng)應(yīng)該回到功能選擇畫面。
3. 回到功能選擇use case。
2.2.3- 客戶選擇取消
1. 如果客戶在輸入金額時(shí)，沒有按下確定，卻是按下取消，系統(tǒng)應(yīng)顯示-- 錯(cuò)誤訊息：“不要玩我！快滾吧！”。
2. 系統(tǒng)應(yīng)該把卡片吐出來。
3. 回到吐卡片use case。
3. Special Requirements
無
4.- Preconditions
客戶要正確插入卡片，輸入正確的密碼，通過身分認(rèn)證，提款機(jī)還有足夠的鈔票在里面。
5.- Postconditions
進(jìn)入吐鈔use case。
6.- Extension Points
無
通常會(huì)被找到的遺漏：
1.為什么沒有檢查金額是否正確？臺(tái)灣的提款機(jī)，只能夠輸入100的倍數(shù)。（待續(xù)）
聯(lián)系客服
