Re: UML正面的看得多了, 看點反面的吧

看板Programming作者tinlans ( )時間17年前 (2008/06/04 08:03)推噓3(3推 0噓 26→)

留言29則, 4人參與討論串4/7 (看更多)

※ 引述《Lordaeron (Terry)》之銘言： : 請針對原文來回應, 我只是將別人的簡介列出. : 針對簡介來回應, 實在是有點會摸不著邊. 其實那樣回只是預防標題殺人，畢竟會真的進去認真看原文的中文語系 user 並不多，所以實際上我是把簡介當成另一篇來回沒錯，因為既然原文是以簡介形式被翻譯和重新散佈的，所以比較理想的方式還是針對中文標題回應為主。基本上原作者對 UML 有一定程度的誤解，我要表達的東西也很簡單，就像 programming language 是一種工具，你要寫出好程式不可能不學些資料結構跟演算法一樣， UML 它也是一種輔助物件導向軟體開發的工具，但是你還是必須搭配一套物件導向方法論才行；此外，原作者對 UML 的定位實在不是很正確，也過度狹義的解釋 UML 被設計出來的意圖，我不曉得為什麼他對 generate code 這項功能特別執著；原作者對相關的方法論認知顯然也不足，譬如： 9. Lack of model clarity Pictures are interpretable. I heard this kind of complaints from programmers trying to understand the design of a system from UML diagrams: you need to read the code to understand what the diagrams mean. 會有這種現象一般是人為疏失，有 ambiguous 現象發生時應該盡可能 attach 更多資訊到圖上，譬如 attach 一些 note 或 constraint，甚至 attach 一張 activity diagram 或 object diagram，也可以針對該專案所屬的領域製作專屬的 profile 來規範和擴充；即使不另外製作 profile，很多人應該知道某些社群會把 UML 分類為靜態圖跟動態圖兩大族系，而描述不清楚的模型通常是只有描述靜態圖 (如 class diagram)，這樣自然會有 ambiguities 發生，而使用動態族系的圖或使用 constraint 都能解決這方面的問題；我想讀過 GoF 那本 design pattern 的應該也知道，有時候作者會用 sequence diagram 和 object diagram 補足 class diagram 的不足，而且也會 attach 一些內含 pseudo code 的虛擬碼。 UML 明明提供了一堆 adornment 的功能但是都沒在用，不能因為不會睡覺就怪床歪。逐字逐句回原作也實在太花時間，不過也歡迎板友從原文中提出真的覺得是缺點的片段來做討論。 -- Ling-hua Tseng (uranus@it.muds.net) 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.218.232

→