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

[tinlans ( )]

※ 引述《huggie (huggie)》之銘言：
: ※ 引述《tinlans (  )》之銘言：
: : 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.
: : 會有這種現象一般是人為疏失，
: 先聲明我不懂 UML，
: 我想原作者想要強調的是，並不見得是 UML 本身有很大的技術問題，
: 而是 UML 有一定的複雜度，然後它的功能常常被誤會。
不是，
是描述得不夠精確的話會發生一張圖可以有多種解讀方式，
譬如 class diagram 裡 B 和 C 被 aggregate 到 A，
然後 B 跟 C 之間有一條 association 關係，
那麼假設 runtime 有物件 A1 B1 C1 和 A2 B2 C2，
A1 aggregate B1 和 C1，
B2 aggregate B2 和 C2，
這時 B 跟 C 之間的 association 關係就至少有兩種解讀方式，
譬如 B1 associate 到 C2、C1 associate 到 B2，
可是 designer 想表達的卻是 B1 associate 到 C1，
以及 B2 associate 到 C2；
如果只有繪製 class diagram，
那麼它在實作或被當文件來瞭解軟體系統時，
就會有類似的岐義現象發生，
這時就需要使用 constraint 或 note，
或是 attach 其它的圖，
如合成結構圖 (composite structure diagram) 來進一步說明，
因為 class diagram 對描述被包含在內的物件之間的關聯性很弱，
所以需要搭配其它的圖來加以輔助。
: 這就好像說  SGML 是相好東西，但是太過複雜了所以設計初 XML
: XML 還是有人嫌對一般工作太複雜所以有 json，
: 並不代表 XML 有 technical 問題..
這要說明一下了，
UML 是以 MOF 為基底，
MOF 是所謂的 metametamodel (位於 M3 抽象層)，
UML 是所謂的 metamodel (位於 M2 抽象層)，
一般使用 UML 做出來的 model (或 spec) 則是位於 M1 抽象層，
application 成品則是 M0 層，
真要拿 SGML 比較的話，
MOF 比較接近 SGML 的層級。

比較進階的 UML 使用者會在 M2 層撰寫 profile 擴充 UML，
也就是跟 UML 平行的那一層，
事實上衍生自 MOF 的除了 UML 還有 SysML 跟 SPEM 等等，
SPEM 跟 UML 有部分交集，
但圖的表示法跟意義會和 UML 有些差異，
它是 Rational 拿來做 business modeling 用的。
: 把程式設計師當成使用產品的顧客，原作者強調的是 UML 不是個好產品，
: 而你強調的是 technically 他是個好產品。即使 technically superior
: 如果離實際面差太多，大多programmer 心裡不願意花時間來達到應有的程度
: 那就可能有問題。
: 可能角度要從沒有不對的顧客來思考。再來思考如何讓顧客接受。
UML 被定位在 metamodel，
所以基本上並不會是一個「產品」，
原作者一直認為 UML 一定要搭配昂貴的 tool 使用，
而且幾乎認定 UML 就是被設計來做 code gen 用的，
所以可以確定原作者對 UML 的認識並不深。

回到前段，
岐義的問題以 Unified Process (UP) 為例，
它在 Design Model 下就應該被完全消除，
因為在相關技術資料上就記載著：
    Design model must define enough of the system so it can be
    implemented unambiguously.

在 UP 規範的 Design Model 裡活動的主要 workers (在 RUP 稱 roles)，
有 Architect、Use-case engineer 和 Component engineer 三種，
這幾種人基本上都不是很 junior 的 engineers，
結果原作者卻又說了：
4. Departure from what programmers perceived as the initial goal
...
I think most programmers still use only the class diagram and maybe
occasionally when they write a document the sequence diagram.
...

只能說他可能完全不知道 UML 實際上必須搭配一套軟體工程方法論運行，
而且還把 object modeling 的工作當成一人遊戲在玩，
從他整體的言論來看，
他對 UML 的認知可能還只到 UML 1.x，
然而 UML 跟其它 language 一樣也是會進化的，
現在用 UML 的人如果只會 class diagram 和 sequence diagram，
UML 2.1 裡 13 種圖只會用 2 種，
如果是很 senior 的 engineers 那實在也太遜了；
當然每個人都曾經遜過是一定的，
但原作者顯然對相關方法論的分工方式完全沒有涉獵。

我要說的是，
很 senior 的 engineers 如果會犯到他在 9 列出來的錯誤，
那應該早就被開除了，
如果採用物件導向方法來開發軟體的公司，
會讓很 junior 的 engineers 去參與 design model 的制訂，
那這種公司也早就該倒一倒了。

--
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         來自: 61.230.218.232       (06/05 14:33)
推 huggie:我想你會我說產品的意思了，使用UML的人是
→ huggie:程社師，那程社師就是顧客，UML就是產品
推 huggie:1F    ^誤會
→ tinlans:其實我覺得這樣比喻不是很好，因為 UML 不
→ tinlans:過就是 flow chart 和 DFD 之類的東西...
→ tinlans:對 programmer 而言的產品應該更具體，像
→ tinlans:compile這類的東西。
→ tinlans:compiler
→ tinlans:原作者把 UML 看得太過具體，這就像在提倡
→ tinlans:寫程式畫流程圖沒用一樣的論點，可是原作
→ tinlans:者好像誤會了 UML 的定位。
→ tinlans:簡單說 programmer 接觸到的應該是以 UML
→ tinlans:製作而成的 model，也就是 spec，而 UML
→ tinlans:是 spec 的 spec，所以被稱為 meta-model
→ tinlans:，UML 的直接 user 並不是 programmer。
推 huggie:但是是programmer要去畫?至少是architect
→ tinlans:所以 programmer 不用畫啊，或是單純用來
→ tinlans:做為實作用草圖，不會成為正式文件。
→ tinlans:但原文作者把這些都搞混了。
推 huggie:嗯嗯
推 abcdefghi:不過目前幾家做UML工具的公司,都喜歡把
→ abcdefghi:codegen的功能包進來,一堆軟工的東西混
→ abcdefghi:在一起,很容易讓人誤會UML就是那一坨東
→ abcdefghi:西,尤其是Rational.
→ Lordaeron:理論上,分工是對的, 但實際上, 可以這
→ Lordaeron:麼清楚的分工, 我是還未看過可行的案例