UML據我最近有限的study看來算是軟體的設計圖。
(如果有錯請小力鞭，我只研究了兩三天)
主要由SA負責將客戶的需求用UML的方式具象化，
就像是建築師畫設計圖一樣。
那請問SD跟SE對於UML的了解程度該到多少呢？
就像建築工自己不會畫設計圖，但是可以照著設計圖來做這樣？
（不太懂SD跟SE的分工就是）
感謝解惑。

設計圖通常是事後才做好的東西(無誤)

那請問沒有設計圖是要怎麼跟客戶溝通？

溝通也是事後才要做的事情(無誤)

溝通完如果才知道跟客戶要求差很多那工程師不是嘔死？

user story 寫好寫滿比較實在啊.

UML要也是給對方SA看, 不會直接跟end user用這講現在一些老師就提倡迭代方式阿, 反正都會有爭議不如就縮短

我跟user溝通都是用Prototyping

那爆肝工程師要做出來不是也是看UML嗎？

而且user往往也不知道自己真的要什麼, 翻盤不見得是溝通出錯沒有吧, SA給你什麼你就看什麼SA也不見得想畫這個, 除非案子要交付UML圖而且工程師看UML圖就做得出來系統? 頂多了解系統架構吧

可是不給UML的話SA要怎麼有系統的叫工程師寫程式？

SA兼SD的人就直接用html或是excel畫畫面, 功能簡單寫寫table 欄位寫夠詳細跟正確

我自己的理解是SA是把程式該有的功能全列出來(列出必要

公司要求更多的就會再加寫sudo code, 讓溝通更容易

的函式)，然後SD負責系統或介面，SE把SA要的函式依照SD的設計寫出來，這樣有無理解錯誤？

依照你說的這個流程, 哪一段非用UML不可?所以最後就都省掉了, 除非有人要求才去畫

user不知道但SASD要知道吧，什麼都不清楚下去做當然翻盤

可是一般來說user不知道怎麼定義很正常阿，好的SA不是應該藉由溝通引導user好好定義spec?我看了一些uml教學都說他的作用就是類似建築設計圖或ikea賣的組合櫃的組合說明，就是給工程師照著做的做出這種軟體設計圖不就是SA的工作？

use case, class, sequence diagram這三個學好。

UML規劃得好的確寫code會比較快，但需求常常變的話很麻煩

同意ptt大的那三張圖 另外本來就沒一定要UML才能定義spec

我好像沒畫過UML，也沒看過哪個architect畫UML...基本上"由architect設計，再給engineer實做"這點就是傳統waterfall思維，如果比較走Agile的，應該就是user story寫好，溝通一下，真正實做細節是engineer在做story時再去弄出來，通常在planning meeting會先過一遍，有問題這時就可以溝通，之後做到一半有問題還是可以溝通應該也不能說沒看過architect畫UML，確實看過幾次，但不是那種大系統整個用超複雜超大的UML表示，而是要表達一個很簡單的code架構細節時，可能就兩三個class/interface這種的UML，主要是講不清的時候才會畫一下

我覺得UML的本質就很不適合來當大系統的架構圖@@看完森林要來看小~中的樹枝時倒是還不錯

好的UML圖，讓coding變得更有效率

UML sometimes overkills但架構複雜的系統，UML還是蠻必要的

覺得UML畫的讓人看的懂就好，粗略的跟user好溝通，細節的跟工程師好溝通，反正來源都同一個，個人也覺得用這個比較能系統性的思考

把UML當作溝通用的草稿，而不是建築的藍圖達到溝通快速且正確理解的目的，就是好方式

Martin的UML for Java就有寫拉, 他認為UML是工程師輔助的工具, 拿來幫助自己記憶/回憶, 以及與其他工程師溝通他沒有說UML是要嚴謹的驗收用的標準規格書, 所以沒必要認為UML是一定要存在的. SA與PG內部溝通可以用這個, 但不是一定就要寫這個東西才能完成, 也不是沒寫專案就會失敗而且各種文件都有時效性, 沒有一直維護, 年代久遠也不會有人再去對照那些文件, 頂多看看目錄大概知道系統範圍

如果都你自己一個人做的東西我覺得不必要但是如果交接，或者是跨部門討論，這都是必要的

還有一個問題，怎麼驗證做出來的成品跟UML計劃的符合？UML給我的感覺不像pseudo code....很難理解怎麼"比較"

看UML做？不是都看word excel pdf的圖文敘述嗎

敏捷開發！！！

理論上有東西規劃出來照着做當然必要，現實就是user需求根本一直就在變，你這邊的經驗也無法套用到另外一個上面，反而UML畫好之後討論完，user還會說 不對 不是這樣，還不如不要畫，需求這種東西不可能不變的 除非你運氣真的超好

可是user不是應該跟SA把spec先定好才能寫UML?UML不合->spec改變->加錢乎？

UML 就像 NBA 教練畫的戰術圖，兩邊都看得懂就有溝通共識但未必溝通戰術就要百分之百使用戰術圖

powerpoint 才是王道

所以如果我能用visio把我的程式架構解釋清楚那不用uml也ok?

那只是溝通工具，其實我比較常看到的是畫白板或是ppt

你有辦法解釋清楚的話用唱歌的都可以 XD

感謝解惑！

我以為uml只有工程師在用，user也會用頗強

溝通最有效的方式還是對著半成品/試作做討論,紙上談兵通常沒啥鳥用

直接雕一個雛形 UI 給 user 看比較快，為什麼 UML 會拿來跟 user 溝通 XD而且實際 run 過 RUP 的應該會知道 use case 這邊還要寫use case specification，要寫 flow of events 跟alternative flows，這些都純文字，可以描述很清楚。一個好的工具還能讓你連結 activity diagram 和 systemsequence diagram 去做輔助說明。

看起來UML沒那重要，那為啥一堆企業都要求UML？救我看來，SA跟user溝通的時候直接用qt把介面畫出來然後一個個確定功能不是更快？

台灣真正從頭到尾在用 UML 的不多吧，很多是事後補文件。如果要說古典的 use case driven 玩法，談需求的首先要從客戶模糊的描述中整理出 problem statement (這是專有名詞)，再從中對名詞和動詞加以分析，找出 actor 和 usecase。這些分割出來以後，再針對每個 use case 寫詳細的use case specification，輔以 activity digram (UML 中很接近傳統流程圖，但能表達更多概念的東西)，這裡面包含每個 use case 的正常工作流程，以及各種不同狀況發生時該走的流程。除了以文字或圖描述外，還能使用虛擬碼。為了詳細寫出這些細節，就需要跟客戶不斷確認每個 usecase 是否符合客戶預期。這中間可以隨便拉幾個空殼 UI 跟user 溝通，這樣 user 講起來也比較有感覺。至於 use case diagram 和 use case specification 這些產出物，其實都不是給 user 看的，只是把 user 的需求明確化後給內部的人看的。這邊主要都是在建立 use case model，完成後才要開始建立analysis model，開始模塑 use case realizations，找出analysis class，並且找出它們之間的 relationship，以及各自的 operations (就是 methods)。找 analysis class 的方法很多，除了 RUP 的 ECB pattern以外，還有傳統的 textual analysis (對 use casespecification 等文字敘述做名詞動詞分析)、填 CRC card等等，找出以後會開始畫 sequence/communication diagram，再來還要建立 object diagram，最後才是一般人比較熟悉的 class diagram，整個 analysis model 才算完成。後續是把 analysis model 給 realize 成 design model 的工作，把 analysis class 轉成 design class (可能會合併或分割)，這些才是 programmer 比較熟悉的部分，所謂的design patterns 也是應用於這個階段。這邊很多人都比較熟悉所以就不多說了。以上是 RUP 搭 UML 的玩法，當然我省略掉了一堆東西。RUP 實際上是使用工具在跑，每個步驟工具都會提示你下一步要幹嘛，誰該負責做什麼，產出物為何，其中還有一堆都是字的文件。沒機會接觸的話也不用接觸太深，因為現代沒幾間公司可以這樣玩 XD但是概略瞭解這個流程，可以知道敏捷開發法到底跳過了什麼，又或者說是把什麼簡化成什麼，會比較有感是真的。UML 當初被創造出來就是為了搭配一種軟體開發流程，RUP只是其中一種，也是最囉唆最麻煩的一種。除非一個企業有足夠的人力跟時間把這些文件工作做到極致，不然說真的會點 UML 的皮毛，懂得用其中兩種圖的部分功能就可以上了，只是一個構思草圖用的共通語言而已。當然你全懂肯定沒有壞處，因為你腦袋裡會浮現所有被敏捷開發法省略的各種細節，只是東西都在你腦中，需要成為文件的部分很少，在旁人看來可能跟 user 談完，featurelist 寫好，沒多久 design spec 就定了。中間在你腦中發生過什麼大大小小的戰爭，只有你自己知道 XD因為這些不可見，旁人難以模仿，會成為 SA/SD 的實力差。講白了，敏捷開發法就是當初高手們覺得 RUP 這些古典方法太繁瑣笨重緩慢，他們想要變得輕巧迅捷所以簡化流程。但是在加速猛衝的時候，遇到困難，因為他們曾經慢慢爬過，所以把速度降下來 (回到舊方法從基礎思考) 就解了。但是對於從一開始就只懂快速衝刺，遇到問題也沒辦法減速(也就是缺乏基礎)，那也只能一頭撞上障礙物死掉而已 XD有機會你可以觀察一下，當客戶丟一句要把什麼改成什麼的時候，這兩類型表現出來的樣子可說是大不相同。因為這個時候流程大都迭代過幾次，就算是 porgrammer 也很容易看破 SA/SD 的手腳，會直接感受到他們是不是假會。

可是就算全知道好了，還是要有一定的溝通技巧才能引導user詳細說出自己想要的(大部份user沒全局觀)這點沒錯好底下的人就會被不斷變更的spec累死(我吃虧的就是這點，看來很難成為好SA，只好走SD/SE)

user 會有才奇怪，但溝通絕對不是用 UML 跟 user 溝通啊其實談需求有點超過 SA 範圍，但是國內都混在一起。有涉獵過正規的需求工程相關知識嗎？

可是要先跟user溝通才生的出UML(部份)阿需求是PM還是SA該去談？

有個公司會有 RA 這個職位，帶著 SA 一起去談。title 可能是需求分析師之類，但不常見。一般都併入 SA 的職務裡了。有的公司 第一句打錯 XD感覺你要補的是 requirements elicitation 和 validation這塊知識，但不確定你有沒有學過。

我沒有學過，半路出家非資工管出生

那先從第一線退下來補知識也好，這個急不來。要讓 user 嘴裡吐出幾個有用句子光靠國語課本是天方夜譚

感謝分享，不過好像愈來愈複雜了@@我自己也曾站在user的立場過，真的很難講出有用的句子真要做的好搞不好得練chat skill @@跟SA比起來，SD跟SE比較需要跟有跡可循的機器跟code搞單純太多了....

chat skill 太抽象，可以先參考既有方法論，再發展出當下公司跟團隊可以接受的形式出來。

T大高手啊！整個流程描述的好清晰

是阿，獲益良多

t大應該回文的 整段看下來好清楚