※ 引述《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 ([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.218.232