作者tinlans ( )
看板Programming
标题Re: UML正面的看得多了, 看点反面的吧
时间Wed Jun 4 02:48:23 2008
※ 引述《Lordaeron (Terry)》之铭言：
: 转自大陆的翻译
: 内容简介:
: 1.由一个委员会设计；
但是还是有集思广益，
目前 UML 2.1 的 13 种图里，
只有 5 张图是受早期那三位大师直接影响而成的，
另外 8 张图则是广纳各种设计方法整合进来的。
: 2.他们老想着把UML转化成金钱；
会有这种误解是因为很多人把 Rational 当成 UML 界的唯一主导公司
(我是知道它被 IBM 买了但这不重要)，
实际上也没有这麽极端。
: 3.试图统一所有的东西包括厨房水槽（规格文本大於800页）；
没有逻辑的评论。
: 4.想要一步登天，违反了程序员的认知；
明明是循序渐进，
最初制订 UML 的三位大师分别主导的是：
1. 物件导向软体工程 (OOSE) - Ivar Jacobson
2. 物件导向分析与设计 (OOAD) - Grady Booch
3. 物件导向塑模技术 (OMT) - James Rumbaugh
而且最初 UML 出来的时候，
就有 Ivar 主导而成的 Unified Process (UP) 做搭配，
它采用了比传统 waterfall 开发模式更务实的 iterative 式开发模型，
虽然 UP 後来被商业化成 Rational Unified Process (RUP)，
但是 UML 本来就不是为了 UP 而生，
像是近几年流行的各种 Agile Methods 也会使用 UML 来 modeling，
它也是一种务实而且循序渐进的软体开发方式，
所以 UML 本身并没有什麽想一步登天的问题。
: 5.观念膨胀；
？
: 6.总是在追赶新的语言和新的概念；
并没有，
UML 打算成为 platform-independent 的 modeling language，
事实上 MDA 这种东西就是把它拿来描述 PIM 模型用，
跟语言或特定平台的相依性差距非常远。
有些人会质疑 deployment diagram 根本是为了 EJB 而设，
但它仍然能拿来描述传统语言制作的分散式系统布局。
而且随着时代逐渐更新本来就没什麽不好，
C 语言这种古老的东西还不是一路更新上来。
: 7.UML试图成为一个程序语言；
承 6，
没有这回事，
Executable UML 其实只能算 UML 的一个旁支，
事实上大多数的 UML 教科书都会开宗明义的说 UML 有几种用途，
你要拿来当草稿也是可以。
: 8.需要昂贵的工具；
承 2，
把 UML 跟 Rational 绑在一起造成的误解，
走 RUP 的开发模式才需要昂贵的工具，
事实上不少 Agile Methods 都提倡使用纸笔即可。
: 9.模式不清晰；
？
: 10.真正的软件设计问题缺乏解决方法；
承 4，
UML 只是 object modeling language，
它本身还是需要搭配一些物件导向系统分析与设计的方法，
不然很单纯就只是一些图，
对 UML 认识过於肤浅才会说这种话。
: 11.在你写第一行代码前就假设你知道一切；
承 4，
其实现今搭配 UML 的软体开发方式，
都属於 iterative spiral model 的一种延伸，
每个 iteration 都会逐步更新和强化前一次 iteration 的模型，
完全没有需要假设写第一行 code 就需要知道一切这种事，
写下去发现设计有问题的话可以先记录下来，
在下一个 iteration 改善分析模型和设计模型即可。
很明显是把 UML 套到 waterfall 模式造成的误解。
: 12.对待软件开发就像对待制造业；
这是对於 software engineering 本身的重要性不够了解所致，
在没有软体工业这四个字存在的国家而言会讲这种话很常见。
: 13.UML工具针对了错误的目标。
承 8，
UML 没有特定的工具，
端看你选择的开发模式而定，
难道要说纸笔这种工具也针对了错误的目标？
: 原文连结, 请将两行接成一行:
: http://littletutorials.com/2008/05/15/
: 13-reasons-for-umls-descent-into-darkness/
--
Ling-hua Tseng (
[email protected])
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.222.182
※ 编辑: tinlans 来自: 61.230.222.182 (06/04 02:51)
1F：推 a1234957:没有任何缺点? 122.123.5.251 06/04 03:15
2F：→ MasterChang:每个工具都有缺点和局限性... 140.132.23.74 06/04 03:37
3F：→ MasterChang:要用在对的地方用对的工具... 140.132.23.74 06/04 03:38
4F：推 huggie:kitchen sink 是英文 slang 140.129.160.62 06/04 07:47
5F：推 huggie:看原文发现第四点不是那个意思 140.129.160.62 06/04 07:49
6F：→ tinlans:原文的第四点，对 UML 认知过度狭隘，只会 61.230.218.232 06/04 08:06
7F：→ tinlans:用 class/sequence diagram 的连 UML 入门 61.230.218.232 06/04 08:06
8F：→ tinlans:程度都不算，不能一堆人乱用就怪 UML 不好 61.230.218.232 06/04 08:06
9F：→ tinlans:实际上要过 CMMI Level 3 不可能 business 61.230.218.232 06/04 08:07
10F：→ tinlans:people 也没受到相关训练，像是 SPEM 的模 61.230.218.232 06/04 08:07
11F：→ tinlans:型之类的东西。 61.230.218.232 06/04 08:08
12F：→ tinlans:公司如果本身就不打算走那种路线，硬要用 61.230.218.232 06/04 08:08
13F：→ tinlans:就是选择了错误的工具，这是人的问题。 61.230.218.232 06/04 08:09
14F：→ tinlans:如果你说的是第三点，我想问有没有人学 61.230.218.232 06/04 08:16
15F：→ tinlans:C++ 会去看 C++ 标准规格书？而且他强调的 61.230.218.232 06/04 08:16
16F：→ tinlans:domain 问题可以用 profile 解决。 61.230.218.232 06/04 08:16