為什麼這篇uml用途鄉民發文收入到精華區：因為在uml用途這個討論話題中，有許多相關的文章在討論，這篇最有參考價值！作者wtchen (沒有存在感的人)看板Soft_Job標題[請益] UML對不同工作的必要性時間S...
UML據我最近有限的study看來算是軟體的設計圖。
(如果有錯請小力鞭，我只研究了兩三天)
主要由SA負責將客戶的需求用UML的方式具象化，
就像是建築師畫設計圖一樣。
那請問SD跟SE對於UML的了解程度該到多少呢？
就像建築工自己不會畫設計圖，但是可以照著設計圖來做這樣？
（不太懂SD跟SE的分工就是）
感謝解惑。
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 90.41.170.137
※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1475943832.A.681.html
→ Eleina: 設計圖通常是事後才做好的東西(無誤) 10/09 00:25
→ wtchen: 那請問沒有設計圖是要怎麼跟客戶溝通？ 10/09 00:28
推 kiwatami: 溝通也是事後才要做的事情(無誤) 10/09 00:29
→ wtchen: 溝通完如果才知道跟客戶要求差很多那工程師不是嘔死？ 10/09 00:30
→ qrtt1: user story 寫好寫滿比較實在啊. 10/09 00:33
→ atpx: UML要也是給對方SA看, 不會直接跟end user用這講 10/09 00:34
→ atpx: 現在一些老師就提倡迭代方式阿, 反正都會有爭議不如就縮短 10/09 00:34
推 zo6al: 我跟user溝通都是用Prototyping 10/09 00:34
→ atpx: 每個周期, 要錯也不會錯太大 10/09 00:34
→ wtchen: 那爆肝工程師要做出來不是也是看UML嗎？ 10/09 00:35
→ atpx: 而且user往往也不知道自己真的要什麼, 翻盤不見得是溝通出錯 10/09 00:36
→ atpx: 沒有吧, SA給你什麼你就看什麼 10/09 00:37
→ atpx: SA也不見得想畫這個, 除非案子要交付UML圖 10/09 00:37
→ atpx: 而且工程師看UML圖就做得出來系統? 頂多了解系統架構吧 10/09 00:39
→ wtchen: 可是不給UML的話SA要怎麼有系統的叫工程師寫程式？ 10/09 00:39
→ atpx: SA兼SD的人就直接用html或是excel畫畫面, 功能簡單寫寫 10/09 00:40
→ atpx: table 欄位寫夠詳細跟正確 10/09 00:41
→ wtchen: 我自己的理解是SA是把程式該有的功能全列出來(列出必要 10/09 00:42
→ atpx: 公司要求更多的就會再加寫sudo code, 讓溝通更容易 10/09 00:42
→ wtchen: 的函式)，然後SD負責系統或介面，SE把SA要的函式依照 10/09 00:43
→ wtchen: SD的設計寫出來，這樣有無理解錯誤？ 10/09 00:43
推 atpx: 依照你說的這個流程, 哪一段非用UML不可? 10/09 00:47
→ atpx: 所以最後就都省掉了, 除非有人要求才去畫 10/09 00:48
推 abccbaandy: user不知道但SASD要知道吧，什麼都不清楚下去做當然翻 10/09 01:06
→ abccbaandy: 盤 10/09 01:07
→ wtchen: 可是一般來說user不知道怎麼定義很正常阿，好的SA 10/09 01:45
→ wtchen: 不是應該藉由溝通引導user好好定義spec? 10/09 01:46
→ wtchen: 我看了一些uml教學都說他的作用就是類似建築設計圖 10/09 01:46
→ wtchen: 或ikea賣的組合櫃的組合說明，就是給工程師照著做的 10/09 01:47
→ wtchen: 做出這種軟體設計圖不就是SA的工作？ 10/09 01:48
→ pttworld: use case, class, sequence diagram這三個學好。 10/09 06:45
推 cphe: UML規劃得好的確寫code會比較快，但需求常常變的話很麻煩 10/09 07:52
推 ahli: 同意ptt大的那三張圖 另外本來就沒一定要UML才能定義spec 10/09 10:49
推 Wolfken: 我好像沒畫過UML，也沒看過哪個architect畫UML... 10/09 10:52
→ Wolfken: 基本上"由architect設計，再給engineer實做"這點就是傳統 10/09 10:52
→ Wolfken: waterfall思維，如果比較走Agile的，應該就是user story 10/09 10:53
→ Wolfken: 寫好，溝通一下，真正實做細節是engineer在做story時再去 10/09 10:53
→ Wolfken: 弄出來，通常在planning meeting會先過一遍，有問題這時 10/09 10:54
→ Wolfken: 就可以溝通，之後做到一半有問題還是可以溝通 10/09 10:54
→ Wolfken: 應該也不能說沒看過architect畫UML，確實看過幾次，但不 10/09 10:55
→ Wolfken: 是那種大系統整個用超複雜超大的UML表示，而是要表達一個 10/09 10:55
→ Wolfken: 很簡單的code架構細節時，可能就兩三個class/interface 10/09 10:56
→ Wolfken: 這種的UML，主要是講不清的時候才會畫一下 10/09 10:56
推 ahli: 我覺得UML的本質就很不適合來當大系統的架構圖@@ 10/09 11:01
→ ahli: 看完森林要來看小~中的樹枝時倒是還不錯 10/09 11:02
→ realbout: 好的UML圖，讓coding變得更有效率 10/09 11:36
推 gogogogo3333: UML sometimes overkills 10/09 11:49
→ gogogogo3333: 但架構複雜的系統，UML還是蠻必要的 10/09 11:50
推 popxpopxpop: 覺得UML畫的讓人看的懂就好，粗略的跟user好溝通，細 10/09 13:05
→ popxpopxpop: 節的跟工程師好溝通，反正來源都同一個，個人也覺得 10/09 13:05
→ popxpopxpop: 用這個比較能系統性的思考 10/09 13:05
推 landlord: 把UML當作溝通用的草稿，而不是建築的藍圖 10/09 13:21
→ landlord: 達到溝通快速且正確理解的目的，就是好方式 10/09 13:22
推 atpx: Martin的UML for Java就有寫拉, 他認為UML是工程師輔助的 10/09 14:13
→ atpx: 工具, 拿來幫助自己記憶/回憶, 以及與其他工程師溝通 10/09 14:13
→ atpx: 他沒有說UML是要嚴謹的驗收用的標準規格書, 所以沒必要認為 10/09 14:15
→ atpx: UML是一定要存在的. SA與PG內部溝通可以用這個, 但不是一定 10/09 14:15
→ atpx: 就要寫這個東西才能完成, 也不是沒寫專案就會失敗 10/09 14:16
推 atpx: 而且各種文件都有時效性, 沒有一直維護, 年代久遠也不會有 10/09 14:18
→ atpx: 人再去對照那些文件, 頂多看看目錄大概知道系統範圍 10/09 14:19
推 stosto: 如果都你自己一個人做的東西我覺得不必要 10/09 15:57
→ stosto: 但是如果交接，或者是跨部門討論，這都是必要的 10/09 15:57
→ wtchen: 還有一個問題，怎麼驗證做出來的成品跟UML計劃的符合？ 10/09 16:12
→ wtchen: UML給我的感覺不像pseudo code....很難理解怎麼"比較" 10/09 16:12
→ brucetu: 看UML做？不是都看word excel pdf的圖文敘述嗎 10/09 19:14
→ femlro: 敏捷開發！！！ 10/09 21:23
推 Ghosso: 理論上有東西規劃出來照着做當然必要，現實就是user需求 10/09 22:17
→ Ghosso: 根本一直就在變，你這邊的經驗也無法套用到另外一個上面， 10/09 22:18
→ Ghosso: 反而UML畫好之後討論完，user還會說 不對 不是這樣，還不 10/09 22:18
→ Ghosso: 如不要畫，需求這種東西不可能不變的 除非你運氣真的超好 10/09 22:19
→ wtchen: 可是user不是應該跟SA把spec先定好才能寫UML? 10/09 22:22
→ wtchen: UML不合->spec改變->加錢乎？ 10/09 22:23
推 CRPKT: UML 就像 NBA 教練畫的戰術圖，兩邊都看得懂就有溝通共識 10/09 22:40
→ CRPKT: 但未必溝通戰術就要百分之百使用戰術圖 10/09 22:40
→ remmurds: powerpoint 才是王道 10/10 00:13
→ wtchen: 所以如果我能用visio把我的程式架構解釋清楚 10/10 00:29
→ wtchen: 那不用uml也ok? 10/10 00:29
推 Wolfken: 那只是溝通工具，其實我比較常看到的是畫白板或是ppt 10/10 00:38
推 CRPKT: 你有辦法解釋清楚的話用唱歌的都可以 XD 10/10 01:53
→ wtchen: 感謝解惑！ 10/10 01:56
→ stosto: 我以為uml只有工程師在用，user也會用頗強 10/10 13:49
→ leolarrel: 溝通最有效的方式還是對著半成品/試作做討論,紙上談兵 10/11 13:11
→ leolarrel: 通常沒啥鳥用 10/11 13:11
→ tinlans: 直接雕一個雛形 UI 給 user 看比較快，為什麼 UML 會拿來 10/11 13:34
→ tinlans: 跟 user 溝通 XD 10/11 13:34
→ tinlans: 而且實際 run 過 RUP 的應該會知道 use case 這邊還要寫 10/11 13:37
→ tinlans: use case specification，要寫 flow of events 跟 10/11 13:38
→ tinlans: alternative flows，這些都純文字，可以描述很清楚。 10/11 13:38
→ tinlans: 一個好的工具還能讓你連結 activity diagram 和 system 10/11 13:42
→ tinlans: sequence diagram 去做輔助說明。 10/11 13:42
→ wtchen: 看起來UML沒那重要，那為啥一堆企業都要求UML？ 10/11 17:14
→ wtchen: 救我看來，SA跟user溝通的時候直接用qt把介面畫出來 10/11 17:15
→ wtchen: 然後一個個確定功能不是更快？ 10/11 17:15
→ tinlans: 台灣真正從頭到尾在用 UML 的不多吧，很多是事後補文件。 10/11 20:31
→ tinlans: 如果要說古典的 use case driven 玩法，談需求的首先要從 10/11 20:35
→ tinlans: 客戶模糊的描述中整理出 problem statement (這是專有名 10/11 20:36
→ tinlans: 詞)，再從中對名詞和動詞加以分析，找出 actor 和 use 10/11 20:36
→ tinlans: case。這些分割出來以後，再針對每個 use case 寫詳細的 10/11 20:37
→ tinlans: use case specification，輔以 activity digram (UML 中 10/11 20:38
→ tinlans: 很接近傳統流程圖，但能表達更多概念的東西)，這裡面包含 10/11 20:38
→ tinlans: 每個 use case 的正常工作流程，以及各種不同狀況發生時 10/11 20:39
→ tinlans: 該走的流程。除了以文字或圖描述外，還能使用虛擬碼。 10/11 20:40
→ tinlans: 為了詳細寫出這些細節，就需要跟客戶不斷確認每個 use 10/11 20:40
→ tinlans: case 是否符合客戶預期。這中間可以隨便拉幾個空殼 UI 跟 10/11 20:41
→ tinlans: user 溝通，這樣 user 講起來也比較有感覺。 10/11 20:42
→ tinlans: 至於 use case diagram 和 use case specification 這些 10/11 20:43
→ tinlans: 產出物，其實都不是給 user 看的，只是把 user 的需求 10/11 20:43
→ tinlans: 明確化後給內部的人看的。 10/11 20:43
→ tinlans: 這邊主要都是在建立 use case model，完成後才要開始建立 10/11 20:45
→ tinlans: analysis model，開始模塑 use case realizations，找出 10/11 20:47
→ tinlans: analysis class，並且找出它們之間的 relationship，以及 10/11 20:49
→ tinlans: 各自的 operations (就是 methods)。 10/11 20:50
→ tinlans: 找 analysis class 的方法很多，除了 RUP 的 ECB pattern 10/11 20:52
→ tinlans: 以外，還有傳統的 textual analysis (對 use case 10/11 20:53
→ tinlans: specification 等文字敘述做名詞動詞分析)、填 CRC card 10/11 20:54
→ tinlans: 等等，找出以後會開始畫 sequence/communication diagram 10/11 20:55
→ tinlans: ，再來還要建立 object diagram，最後才是一般人比較熟悉 10/11 20:57
→ tinlans: 的 class diagram，整個 analysis model 才算完成。 10/11 20:58
→ tinlans: 後續是把 analysis model 給 realize 成 design model 的 10/11 21:00
→ tinlans: 工作，把 analysis class 轉成 design class (可能會合併 10/11 21:00
→ tinlans: 或分割)，這些才是 programmer 比較熟悉的部分，所謂的 10/11 21:01
→ tinlans: design patterns 也是應用於這個階段。這邊很多人都比較 10/11 21:02
→ tinlans: 熟悉所以就不多說了。 10/11 21:02
→ tinlans: 以上是 RUP 搭 UML 的玩法，當然我省略掉了一堆東西。 10/11 21:04
→ tinlans: RUP 實際上是使用工具在跑，每個步驟工具都會提示你下一 10/11 21:04
→ tinlans: 步要幹嘛，誰該負責做什麼，產出物為何，其中還有一堆 10/11 21:05
→ tinlans: 都是字的文件。沒機會接觸的話也不用接觸太深，因為現代 10/11 21:05
→ tinlans: 沒幾間公司可以這樣玩 XD 10/11 21:05
→ tinlans: 但是概略瞭解這個流程，可以知道敏捷開發法到底跳過了 10/11 21:06
→ tinlans: 什麼，又或者說是把什麼簡化成什麼，會比較有感是真的。 10/11 21:07
→ tinlans: UML 當初被創造出來就是為了搭配一種軟體開發流程，RUP 10/11 21:11
→ tinlans: 只是其中一種，也是最囉唆最麻煩的一種。 10/11 21:11
→ tinlans: 除非一個企業有足夠的人力跟時間把這些文件工作做到極致 10/11 21:13
→ tinlans: ，不然說真的會點 UML 的皮毛，懂得用其中兩種圖的部分 10/11 21:14
→ tinlans: 功能就可以上了，只是一個構思草圖用的共通語言而已。 10/11 21:15
→ tinlans: 當然你全懂肯定沒有壞處，因為你腦袋裡會浮現所有被敏捷 10/11 21:20
→ tinlans: 開發法省略的各種細節，只是東西都在你腦中，需要成為 10/11 21:21
→ tinlans: 文件的部分很少，在旁人看來可能跟 user 談完，feature 10/11 21:23
→ tinlans: list 寫好，沒多久 design spec 就定了。中間在你腦中發 10/11 21:23
→ tinlans: 生過什麼大大小小的戰爭，只有你自己知道 XD 10/11 21:23
→ tinlans: 因為這些不可見，旁人難以模仿，會成為 SA/SD 的實力差。 10/11 21:25
→ tinlans: 講白了，敏捷開發法就是當初高手們覺得 RUP 這些古典方法 10/11 21:36
→ tinlans: 太繁瑣笨重緩慢，他們想要變得輕巧迅捷所以簡化流程。 10/11 21:37
→ tinlans: 但是在加速猛衝的時候，遇到困難，因為他們曾經慢慢爬過 10/11 21:38
→ tinlans: ，所以把速度降下來 (回到舊方法從基礎思考) 就解了。 10/11 21:39
→ tinlans: 但是對於從一開始就只懂快速衝刺，遇到問題也沒辦法減速 10/11 21:40
→ tinlans: (也就是缺乏基礎)，那也只能一頭撞上障礙物死掉而已 XD 10/11 21:41
→ tinlans: 有機會你可以觀察一下，當客戶丟一句要把什麼改成什麼的 10/11 21:45
→ tinlans: 時候，這兩類型表現出來的樣子可說是大不相同。 10/11 21:46
→ tinlans: 因為這個時候流程大都迭代過幾次，就算是 porgrammer 也 10/11 21:49
→ tinlans: 很容易看破 SA/SD 的手腳，會直接感受到他們是不是假會。 10/11 21:49
→ wtchen: 可是就算全知道好了，還是要有一定的溝通技巧才能引導user 10/11 22:15
→ wtchen: 詳細說出自己想要的(大部份user沒全局觀) 10/11 22:15
→ wtchen: 這點沒錯好底下的人就會被不斷變更的spec累死 10/11 22:16
→ wtchen: (我吃虧的就是這點，看來很難成為好SA，只好走SD/SE) 10/11 22:17
→ tinlans: user 會有才奇怪，但溝通絕對不是用 UML 跟 user 溝通啊 10/11 22:22
→ tinlans: 其實談需求有點超過 SA 範圍，但是國內都混在一起。 10/11 22:26
→ tinlans: 有涉獵過正規的需求工程相關知識嗎？ 10/11 22:26
→ wtchen: 可是要先跟user溝通才生的出UML(部份)阿 10/11 22:30
→ wtchen: 需求是PM還是SA該去談？ 10/11 22:30
→ tinlans: 有個公司會有 RA 這個職位，帶著 SA 一起去談。 10/11 22:31
→ tinlans: title 可能是需求分析師之類，但不常見。 10/11 22:32
→ tinlans: 一般都併入 SA 的職務裡了。 10/11 22:32
→ tinlans: 有的公司 第一句打錯 XD 10/11 22:32
→ tinlans: 感覺你要補的是 requirements elicitation 和 validation 10/11 22:33
→ tinlans: 這塊知識，但不確定你有沒有學過。 10/11 22:33
→ wtchen: 我沒有學過，半路出家非資工管出生 10/11 22:34
→ tinlans: 那先從第一線退下來補知識也好，這個急不來。 10/11 22:35
→ tinlans: 要讓 user 嘴裡吐出幾個有用句子光靠國語課本是天方夜譚 10/11 22:38
→ wtchen: 感謝分享，不過好像愈來愈複雜了@@ 10/11 22:39
→ wtchen: 我自己也曾站在user的立場過，真的很難講出有用的句子 10/11 22:40
→ wtchen: 真要做的好搞不好得練chat skill @@ 10/11 22:40
→ wtchen: 跟SA比起來，SD跟SE比較需要跟有跡可循的機器跟code搞 10/11 22:41
→ wtchen: 單純太多了.... 10/11 22:41
→ tinlans: chat skill 太抽象，可以先參考既有方法論，再發展出當下 10/11 22:43
→ tinlans: 公司跟團隊可以接受的形式出來。 10/11 22:43
推 gogogogo3333: T大高手啊！整個流程描述的好清晰 10/12 07:04
→ wtchen: 是阿，獲益良多 10/12 14:53
推 Clementtang: t大應該回文的 整段看下來好清楚 10/14 21:05