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