关于UML的几点看法

这篇有些长,估计要花些时间，我摘了一些精彩的
全文地址:http://www.umlchina.com/best/g35/u1153383.htm

newjing:
我今天才加入这个论坛，发现大家讨论得很热闹，我也写点自己的感受与大家分享。

UML能火成这样既是我所期待的（嘿嘿，小的过去的专业方向是建模）也是出乎意料的。但我对于不少人追捧UML当什么神明之物还是不以为然，不过也有不少很牛B的GG，过去我招聘系统分析员时，有个简历上标明精通UML的GG来，我问他，什么是UML，他告诉我－－画图工具，我就叫他回家等消息了。不管学习UML是为了提高自己分析能力还是为了找工作，都得先明白，UML仅仅是一种语言，仅仅是一种交流工具，是由一些业界约定俗成的Notation，Metamodel统一构建的一个语言集合，真正指导我们进行需求分析和系统设计的，还不外是自身软件工程素养和工程经验。再以招聘举例，我给出的动手题目是描述一个简单的电梯模型，一人能绘制非常复杂详细的class diagram, sequence diagram等等，另一人对diagram的细节掌握的不好，但另一方面，后者考虑到了电梯的顶层和底层与中间层是不一样的，不能用同一个class描述，请问我该聘用谁呢，肯定不会是个能画很漂亮的UML图但让电梯上天入地的GG吧。

对于UML里面众多的图形描述，可能很多人觉得非常头痛，不知道从哪里入手开始学。作为较早接触UML的同行，我希望能给大家提供一点儿建议。对于初级入门，UML distilled 绝对是首选书籍，同时多去Rational公司的论坛，上面由不少的案例分析和问题解答，会有很大作用。如果深入了解UML，就涉及到语义层次了，比如synchronized , asynchronized是什么意思什么时候用，建模时考虑的同步不同步和程序实现是不太相同的，如果有兴趣的话，建议读一些形式化语言Formal methods方面的书，稍微了解一下Z语言，CSP等，会非常有用。

另外，UML是可以用来建模，但绝对不是什么神物，虽然版本在不断升级，从简单的图形到加入OCL到加入各种Pattern，但还是有很大的语义上缺陷。大家知道，一种语言如果语义不完整，就会造成歧义，用于精确系统的设计，如果完全依赖UML，会带来很大的问题，其实这也是数学语言如Z/VDM/CSP等等存在的原因。但UML用于我们普遍的工程，相对于过去的word文档和visio，的确是有很大的提高。

我的意见肯定有失偏颇，希望和大家讨论。

smilemac:
在程序设计已经变成了流行品，到处都是连进程和程序的区别的都搞不清楚却敢奢谈操作系统设计，操作系统主要干些什么都不明白却敢胡说八道什么操作系统的需求怎么做，看了两天《XXX21天》和软件工程时尚杂志（说实话，现在不少书的水平实在不能恭维）就敢自居为XX专家的人。

“我问他，什么是UML，他告诉我－－画图工具，我就叫他回家等消息了。”
呵呵，这样招聘效率很高。

newjing:
小的认为，把UML当作开发的核心工件是有一定道理的。一个软件开发的过程，就是一组对需求的理解，对系统的设计从头贯彻到底的过程。而开发过程的最难点，就是当出现分工（即使不分工，一个人长时间开发）时如何保障系统的一致性，例如，需求分析是否真正抓住了用户的核心需求，设计是否与需求分析一致，程序实现是否与设计一致，各个开发人员的风格是否保持一致，接口是否统一，测试工作是否依照需求进行，等等。 那么，我们必须有一种手段来维持我们整个工程思想的延续性和统一性，UML的出现恰好一定程度解决了这个问题。

但UML是否能在任何工程中都起到这个作用，我是投反对票。可能是因为本人过去是研究如何用Formal Methods补充UML的（呵呵，可笑过去一直靠攻击UML混论文，现在靠UML混饭吃），我觉得UML的很多先天缺陷还是无法弥补的，这也是FM无可替代的原因。比如，UML缺乏根本的语义支持，很容易证明，一个formal model可以开发工具来进行 type checking, model checking，但现在就是最好的rational rose / iLogix， 也只能进行简单的词法分析，所以对于精确的系统，UML很难在详细设计阶段保障精确性。当然，UML在提高精确性方面一直在努力，象OCL的加入起到了一定的作用（但仍然是加了简单逻辑判断的类自然语言）。但即使是目前这种状况，又有多少人真正理解和准确的应用UML呢，IBM的工程师拿出来的UML设计图都惨不忍睹，一个class画出两个箭头，总要表达清楚是concurrent 还是sequential吧。

我仍坚持，UML更适合于分析和设计思想的表达与演示，软件工程思想的表达，而非进行精确设计的语言。越抽象的方向，UML起到的作用可能越大。连Booch不也表示，他要把余生献于UML在Software Architect的研究么。所以我一直认为，理论研究上David Garlan比Booch牛得多 ：）

欢迎各位大哥指教！

billiondelly:
Martin fowler就对UML的未来有质疑，和他的意见一致，我认为UML未来可能会有两种用法：
1) 和过去一样，作为沟通的桥梁，表达建模思想的可视化的简单清晰的方法。
2) 精确的语义定义，成为新的“编程”语言！
newjing既然原来所做工作正是“研究如何用Formal Methods补充UML”，不会你的研究结果就是“不可行”吧？
UML2的方向也正是这样，不过我没有仔细看，不知道是否可以达到或者未来可以达到2)的要求。UML是不是有可能成为完全形式化的语言呢？当然，可能达到之后会面目全非……变成FUML了，但只要能够在保证语义精确的同时维持UML原有的简单易用、直观等优点的话，又有何不可呢？

newjing:
关于静态与动态我并未觉得我用静态观点看待动态模型。建模方法有很多种，但usecase driven 也好，data driven也好，都是以静态类图为基础。我想建模和编码的人很大一个区别是，（整体）考虑让哪个对象干什么和（局部）怎么实现什么功能。

电梯是各非常复杂的模型，有很多人整个博士阶段就研究一个电梯模型。里面有无数的变化点，比如同步性，算法。。。 三年前我参加微软面试时，他们给我出过一个题目就是，if u are an elevator engineer, how would you test a lift? 我当时绞尽脑汁说了一堆，考官还一个劲的问 and? and? and more? 比如说，我就没考虑到测试电梯启动时加速度对拉索的影响。

我同意你的观点，UML没有提供权衡动态模型的机制。其实，UML里面就有两各图是有精确语义的，一个是ER演化过来的class diagram 另一个是statechart（可惜michael Jones的名字都不象Booch一样广为人知）。UML，图形都Unified了（？），但语义没有unified。这种拼拼凑凑的方式能建立统一的语义么，我很怀疑。也就是因为class diagram的语义简练而清晰，所以现在UML的CASE工具声称的代码生产也好反相工程也好都只能处理一些静态的东西。
象下面billiondelly提到的，他觉得UML可能演变成一种新编程语言，我都不太相信，从model到code间的这个过程，也就是refinement，到现在也没有说服力的研究成果出来，而且无数的人不相信refinement有用，人的参与少不了。目前的建模语言里refinement效果比较好的，也就B语言，但也只使用与一些小程序，更多的是做automation。 现在微软有个小组在研究FM了，也许他们的参与能搞点什么新玩意儿出来吧。

smilemac:
另外，模型与代码无关，讨论也不需要一定写出代码，但代码却是可以最准确反映设计思想的东西，千言万语，不如几行代码说的明白。

rode:
关于静态和动态，实际上在此涉及到一个建模的对象问题。即为电梯建模对电梯的控制软件建模，是两个截然不同的问题。
为电梯建模，目的是将电梯的运行进行抽象化，将各种外界的影响作为边界条件或者是输入参数，同时为此模型建立相应的约束，在此基础上我们开始讨论电梯的模型，例如：同步、通信等等（对于我来说是很高深的问题，不敢深谈）；这是很多的问题都需动态模型来描述，或者说使用方程来描述。
但是对于电梯的控制软件建模，则不同。首先：对于电梯软件建模，是建立在上面的电梯模型的基础上的，也就是说电梯模型是电梯控制软件的理论基础。在软件建模，此时需要加入另外一个很中要的元素，就是人（使用软件的人）和与该软件进行通讯的其他系统，此时使用者、外部系统均作为建模元素的形式存在，那么在此我们的动态模型主要体现在使用者和电梯进行交互的方面。而描述电梯的运行机制的模型，实际上是作为一个算法而存在（或者是一段代码存在，是电梯模型描述的内容）。
而软件建模，从较高的角度来看，他的元素实际上是：子系统、类（或者接口）、构件和节点的模型和在他们之间实现系统功能的动态交互（可以认为是动态模型）。

bbmud:
UML，统一建模语言，从名字就可以知道了，这只是一个描述模型的表达手段，并非建模过程本身，如果说它们之间有关系的话，那就是UML用来描述建模过程的中间和最终结果。

newjing:
呵呵，老兄说的有些道理。

什么叫系统分析？与设计有何区别？ 老兄提的这个问题，我想说两句。分析和设计之间的确很难划分界限，这个boundry的问题同时存在与需求描述内部以及需求和设计之间，这和个人的习惯有关，而与不同公司的流程规定无关。即使用FM建模也存在这个问题。

我有个比较模糊的原则来区分，把用户（非软件人员）能描述清楚的功能层面当做界限。举例，过去设计一栋楼的照明系统，屋内灯光根据窗户进来的自然光强度进行调整，那么就需要有个对自然光的感应器。对于这个sensor，在需求描述中我就将其当个stereotype，有接口，并不考虑其内部。而在设计阶段，则对其内部怎样运行进行描述（这是个典型的Asynchorized sensor)。

传统方法和UML能不能互相转换，我同意你的看法，肯定是能，因为无非就是语言和语言之间的转换。比如数学语言讲“一一映射”，四个字就让大家都明白了，但自然语言可能就要解释半天。但是否能那么精确丝毫不差的用传统方法描述UML模型，难说。两种语言的语义不同，必然有找不到匹配的地方，需要扩展一方的semantics来匹配。

市场业务员参与做系统分析也未尝不可，我不太同意，如果系统分析是由市场人员做的，那么在设计之前必然还有一道转换为软件系统描述的分析过程，也就是说，经过了两道分析。当然，这取决于对系统分析的定义了。