作者tinlans ( )
看板Programming
標題Re: UML正面的看得多了, 看點反面的吧
時間Wed Jun 4 02:48:23 2008
※ 引述《Lordaeron (Terry)》之銘言：
: 轉自大陸的翻譯
: 內容簡介:
: 1.由一個委員會設計；
但是還是有集思廣益，
目前 UML 2.1 的 13 種圖裡，
只有 5 張圖是受早期那三位大師直接影響而成的，
另外 8 張圖則是廣納各種設計方法整合進來的。
: 2.他們老想著把UML轉化成金錢；
會有這種誤解是因為很多人把 Rational 當成 UML 界的唯一主導公司
(我是知道它被 IBM 買了但這不重要)，
實際上也沒有這麼極端。
: 3.試圖統一所有的東西包括廚房水槽（規格文本大於800頁）；
沒有邏輯的評論。
: 4.想要一步登天，違反了程序員的認知；
明明是循序漸進，
最初制訂 UML 的三位大師分別主導的是：
1. 物件導向軟體工程 (OOSE) - Ivar Jacobson
2. 物件導向分析與設計 (OOAD) - Grady Booch
3. 物件導向塑模技術 (OMT) - James Rumbaugh
而且最初 UML 出來的時候，
就有 Ivar 主導而成的 Unified Process (UP) 做搭配，
它採用了比傳統 waterfall 開發模式更務實的 iterative 式開發模型，
雖然 UP 後來被商業化成 Rational Unified Process (RUP)，
但是 UML 本來就不是為了 UP 而生，
像是近幾年流行的各種 Agile Methods 也會使用 UML 來 modeling，
它也是一種務實而且循序漸進的軟體開發方式，
所以 UML 本身並沒有什麼想一步登天的問題。
: 5.觀念膨脹；
？
: 6.總是在追趕新的語言和新的概念；
並沒有，
UML 打算成為 platform-independent 的 modeling language，
事實上 MDA 這種東西就是把它拿來描述 PIM 模型用，
跟語言或特定平台的相依性差距非常遠。
有些人會質疑 deployment diagram 根本是為了 EJB 而設，
但它仍然能拿來描述傳統語言製作的分散式系統佈局。
而且隨著時代逐漸更新本來就沒什麼不好，
C 語言這種古老的東西還不是一路更新上來。
: 7.UML試圖成為一個程序語言；
承 6，
沒有這回事，
Executable UML 其實只能算 UML 的一個旁支，
事實上大多數的 UML 教科書都會開宗明義的說 UML 有幾種用途，
你要拿來當草稿也是可以。
: 8.需要昂貴的工具；
承 2，
把 UML 跟 Rational 綁在一起造成的誤解，
走 RUP 的開發模式才需要昂貴的工具，
事實上不少 Agile Methods 都提倡使用紙筆即可。
: 9.模式不清晰；
？
: 10.真正的軟件設計問題缺乏解決方法；
承 4，
UML 只是 object modeling language，
它本身還是需要搭配一些物件導向系統分析與設計的方法，
不然很單純就只是一些圖，
對 UML 認識過於膚淺才會說這種話。
: 11.在你寫第一行代碼前就假設你知道一切；
承 4，
其實現今搭配 UML 的軟體開發方式，
都屬於 iterative spiral model 的一種延伸，
每個 iteration 都會逐步更新和強化前一次 iteration 的模型，
完全沒有需要假設寫第一行 code 就需要知道一切這種事，
寫下去發現設計有問題的話可以先記錄下來，
在下一個 iteration 改善分析模型和設計模型即可。
很明顯是把 UML 套到 waterfall 模式造成的誤解。
: 12.對待軟件開發就像對待製造業；
這是對於 software engineering 本身的重要性不夠瞭解所致，
在沒有軟體工業這四個字存在的國家而言會講這種話很常見。
: 13.UML工具針對了錯誤的目標。
承 8，
UML 沒有特定的工具，
端看你選擇的開發模式而定，
難道要說紙筆這種工具也針對了錯誤的目標？
: 原文連結, 請將兩行接成一行:
: http://littletutorials.com/2008/05/15/
: 13-reasons-for-umls-descent-into-darkness/
--
Ling-hua Tseng (
[email protected])
Department of Computer Science, National Tsing-Hua University
Interesting: C++, Compiler, PL/PD, OS, VM, Large-scale software design
Researching: Software pipelining for VLIW architectures
Homepage:
https://it.muds.net/~uranus
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 61.230.222.182
※ 編輯: tinlans 來自: 61.230.222.182 (06/04 02:51)
1F：推 a1234957:沒有任何缺點? 122.123.5.251 06/04 03:15
2F：→ MasterChang:每個工具都有缺點和侷限性... 140.132.23.74 06/04 03:37
3F：→ MasterChang:要用在對的地方用對的工具... 140.132.23.74 06/04 03:38
4F：推 huggie:kitchen sink 是英文 slang 140.129.160.62 06/04 07:47
5F：推 huggie:看原文發現第四點不是那個意思 140.129.160.62 06/04 07:49
6F：→ tinlans:原文的第四點，對 UML 認知過度狹隘，只會 61.230.218.232 06/04 08:06
7F：→ tinlans:用 class/sequence diagram 的連 UML 入門 61.230.218.232 06/04 08:06
8F：→ tinlans:程度都不算，不能一堆人亂用就怪 UML 不好 61.230.218.232 06/04 08:06
9F：→ tinlans:實際上要過 CMMI Level 3 不可能 business 61.230.218.232 06/04 08:07
10F：→ tinlans:people 也沒受到相關訓練，像是 SPEM 的模 61.230.218.232 06/04 08:07
11F：→ tinlans:型之類的東西。 61.230.218.232 06/04 08:08
12F：→ tinlans:公司如果本身就不打算走那種路線，硬要用 61.230.218.232 06/04 08:08
13F：→ tinlans:就是選擇了錯誤的工具，這是人的問題。 61.230.218.232 06/04 08:09
14F：→ tinlans:如果你說的是第三點，我想問有沒有人學 61.230.218.232 06/04 08:16
15F：→ tinlans:C++ 會去看 C++ 標準規格書？而且他強調的 61.230.218.232 06/04 08:16
16F：→ tinlans:domain 問題可以用 profile 解決。 61.230.218.232 06/04 08:16