「UML 有什麼好處」?

與 Ringle 上個月至某家承包政府機構單位的專案開發公司,應該公司總經理的邀請,請我們過去與該公司約 10 餘位軟體開發人員作一個軟體設計課程的說明。

作了約半個多小時的軟體課程與工具應用的說明後,當然也開放軟體人員們提問,針對專案開發上,是否有沒有現實上的問題。

嗯,這些軟體人員很年輕,好幾位女孩子看來還是從學校剛畢業的,問題不多,比較關心的是工具上的應用,是否如 EA 有沒有支援 VS.NET 2005 這類的問題。

倒是他們總經理,問了一個很直接的問題:UML 對我們在專案開發上,有什麼實質的好處?

嘿,當你面對這樣的問題,而且感受到軟體開發人員們普遍對軟體設計並沒有深刻的概念,且專案規模並不大,感受不到利用 UML 從事設計到底對他們的 “現實開發環境與維護等” 有何好處時,若你從正向來推銷 UML、軟體設計,例如,塑模? 讓系統有彈性? 保留軟體開發的資產? 促進團隊成員們的溝通? ...這些,對年輕資淺的軟體開發人員們,那是不容易讓他們有感覺的。

我就用了一個反問的方式來提問:請問,貴單位的需求訪談紀錄,是否可以直接交付給程式人員,落實為實做的程式碼?

理所當然,他們認為當然不可能,無論如何簡化開發,總是必須仍透過傳統基本的 SA/SD 程序才能寫成程式碼啊。我跟他們說,當我們將傳統需求訪談紀錄整理成 UML 標準的使用案例後,先不用管結構分析與設計,就可以產出程式碼,甚至,包括功能測試程式碼,不需要花上一天就可以作出來,當然,我們也有準備簡報,來展示這一段的過程。

但是,他們仍然不相信,席間,有個女孩子說:聽你們說的如此的神,但是我們希望能 “眼見為憑”,能否直接舉出個案實例呢?

顯然,他們對簡報的內容,並不相信,可能,他們受過太多產品工具廠商們作假的謊言了吧。 🙂
我就說,好吧,應觀眾的要求,我直接請 Ringle,由他們提出一個案例,然後開始從畫使用案例圖,表達使用案例的實現(Realization),利用 EA 產出程式碼框架,加上程式碼細節,還有,再加上功能測試程式碼。當場示範與操作,整個過程,不到 30 分鐘就完成了。 :p

這下沒話可說了吧? 我跟他們說,這根本不神,我只是懂得將需求紀錄利用 UML 的使用案例圖,讓需求能更加有條理的組織與功能切割而已,況且,軟體的問題,不在於能不能寫得出來,要寫出來,我實在看不出來有什麼困難的,”How-to” 太容易從 google 來找到的。軟體最大的挑戰在於如何讓系統具有 “應變” 的能力,讓其具 “生生不息” 的繁衍,這就真的很難了,窮究一輩子也研究不完的。

對我而言,UML 只是手段,我很早就已經清楚這一點了。只是,確實 UML 是截至目前為止,要表達出我個人的軟體設計思維,最佳的呈現工具,如此而已。我沒有必要為 UML 說好話,有更佳的手段或更好用的工具,當然就可以把它換掉,沒必要依依不捨。

同時,對於別人提問的問題,不要試著去 “捍衛” 你的觀點或要推銷的產品、工具等,也不要提太多非常美好、理想的 “境界”,那離現實太遠了!

從「美麗新境界」拉回到現實面,尋找貼近現實的手段,發現問題,採漸增、循環的方式,協助往前走一步,解決問題,逐步推進。這絕對勝過給了太多承諾與夢想,想要一步登高望遠,結果因現實的困難而放棄,到最後才發現原來是一場破碎的夢,好上太多了。

文章導覽

   

共有 5 則迴響

  1. Hi 大頭小胖:
    “至於要怎樣學UML達到專案可用的地步…就…花錢請人教最快…”
    這句話最實在,也是我們擔任顧問的價值與回饋之所在。 ^^

  2. 重點在於[如果能熟用UML畫圖,你就能怎樣..這樣..]
    作者是想要表達這句話,至於要怎樣熟UML作者有他的一套教法,
    反正作者強調UML的好處,也證明過…
    至於要怎樣學UML達到專案可用的地步…就…花錢請人教最快…

  3. 我直接請 Ringle,由他們提出一個案例,然後開始從畫使用案例圖
    又是請呂布級戰將,老話一句,如果公司沒有呂布級戰將時,空有分析/需求有何用呢?

  4. Hi M:

    ya, 那是偏方,其實就如同 2-tier 架構下,從 Form 寫 script 連資料庫撈資料處理一般的簡單,卻沒有結構性可言。我在文章的敘述,一再強調此點。

    我只是透過實做去證明從 Model 至實做程式碼的過程,並不困難。

  5. 那個案例由自己人提出有球員兼裁判的缺點,
    我見識過好幾個UML老師都是這樣的。
    我也看過各種tools在預設的案例下快速產生程式碼,
    除非你從頭開始,不然基本上架構在framework下可能性很小。

發佈留言

發佈留言必須填寫的電子郵件地址不會公開。 必填欄位標示為 *