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

[tinlans ( )]

※ 引述《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 ([e-mail])
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
→ tinlans:另外 UML 可以用 collaboration 直接表示
→ tinlans:一些 well-known 的 design patterns，簡
→ tinlans:潔又能快速消除 ambiguities。
→ tinlans:另外主導設計模型的通常是 Architect，要
→ tinlans:是做到 Architect 能力還這麼差，那阿貓阿
→ tinlans:狗都能當 Architect 了。
→ Lordaeron:anyway,我從來都只相信, 一切都是人的
→ Lordaeron:問題, 什麼L 不L 的, 就隨便就好.
→ tinlans:有共通的語言可以溝通，至少能解決一些人
→ tinlans:的問題，至於是什麼 L 倒不重要。
→ Lordaeron:根據我的經驗, 不管用什麼L 到後來都是
→ Lordaeron:要花大量時間和口水, 去跟一堆牛解釋.
→ Lordaeron:更會有牛來跟你魯哪明明不是哪意思, 是
→ Lordaeron:他的意思才對.
推 abcdefghi:至少UML提供了大量的圖庫,想畫圖描述架
→ abcdefghi:構時,不用再花腦袋想要用圓形還是矩形.
→ Lordaeron:是的, 你不用去想, 但還是要講(解釋)給
→ Lordaeron:客戶聽
→ tinlans:請問是工程師直接跟客戶解釋嗎？一般公司
→ tinlans:不應該這麼做才對，而且真要跟客戶談也頂
→ tinlans:多是拿 use-case 講 what 而不是 how。
→ Lordaeron:因為你待的不是一般公司囉, 你的系統
→ Lordaeron:也不用轉移, 所以有這種想法, 很正常.
推 huggie:他並沒有特別執著，他只是說 management
→ huggie:常會被 code gen 吸引
推 abcdefghi:唉~~以前也很著迷codegen,Tau,Rhapsody,
→ abcdefghi:visualSTATE,到現在單純拿來作文件而已.
→ tinlans:原作者一直提 code gen 然後怎樣怎樣的啊
→ tinlans:感覺他完全把 UML 當成只能 gen code 用。