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大应该回文的 整段看下来好清楚