关于UML的几点看法
　

---

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

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，的确是有很大的提高。

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

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

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

RT

 并非一个类的不同实例，或许应是不同继承类
　

---

我想我可能没表达清楚，在这里解释一下，欢迎讨论。

如果按OO的抽象想法，应该是有一个abstract class，用来描述电梯的一层（可能我们要表达的是每层的control panel），而顶层，底层与中间层从这各类继承。那么一些通讯类（control panel与电梯control center part间）定义在这个抽象类中。

电梯是各非常有意思的case study，几乎每种建模语言的出现都会用来model a lift ，用于检验语言的完整性。因为电梯几乎包括了一个系统的所有方面，静态结构，状态变化，通讯，分布式（如电梯组）等等。

 UML有用，但没那么牛
　

---

谢谢。 小的认为，把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牛得多 ：）

欢迎各位大哥指教！

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

例如:

Class Lift {
...
public void run() {
// LiftControlSystem keep a queue of waiting levels
int level = LiftControlSystem.getWaitingLevel(this);

if (level != null) {
this.moveTo(level);
}
}
...
}

在这种设计中,楼层只是一个整数而已

您说的很对，设计肯定是多样化的。

看到你的程序框架，我想你指的是电梯内部选择楼层的panel，而我所指考虑楼层不同影响到的panel是外部上下的panel。你把楼层考虑成系统内一个变量，而不是类，是我们考虑的boundry不同。

另外，我对你拉出一个程序来讨论模型，还是不懂。我始终认为，考虑模型是代码无关的。

************************
欢迎技术争论

 关于静态与动态
　

---

我并未觉得我用静态观点看待动态模型。建模方法有很多种，但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了，也许他们的参与能搞点什么新玩意儿出来吧。


************************
欢迎技术争论

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

呵呵，刚一看觉得电梯组挺复杂，实际想了想，也没那么复杂，只10多种状态（也可能我想的不全），不过你说的不错，它的涵盖面确实很广，是一个很好的测试建模工具的case。另外，它算不上是一个完全的automation模型，所以题目我以此为例说明automation复杂性不太准确。

只有两个类,LiftControlSystem和Lift,Lift可能有多个实例,接受LiftControlSystem的调度

不管有人在外面按,还是在内部按,楼层都只是一个数字. 有人在外面按时,LiftControlSystem选择一个Lift去满足这个需求;内部按时,LiftControlSystem就让被按的这个Lift去满足这个需求.

LiftControlSystem随时可查询每个Lift的运行状态,根据状态来决定那个Lift将去响应外部按的事件

 为此人感到些委屈
　

---

看了讨论，受到启发。
你言：“过去我招聘系统分析员时，有个简历上标明精通UML的GG来，我问他，什么是UML，他告诉我－－画图工具，我就叫他回家等消息了。”我为此人感到些委屈。
以前做论文时，用UML设计了一个滤波器，用VC实现，没有用双工，全过程一气完成，感觉还可以。现在没有机会做编码，甚至设计也少做了，但项目也好、产品也好，风风雨雨到是见到了一些。
说实在，在开发上真正为技术所困的不多，这可能与我们公司的具体情况有关吧，再说，真有纯技术困难，往往也可以用钱解决。
困难，很多时候在需求和过程管理，而尤其是系统的业务复杂时，厚厚的技术文档与管理文档固然比什么东西都没有好，但技术文档中的许多东西能用UML模型化，真的很好哦。
什么叫系统分析？与设计有何区别？何谓实现等，可能不同公司的流程规定差异性较大，但市场业务员参与做系统分析也未尝不可。事实上，我个人做过实验，既可以把UML资料（分析设计阶段）转化为传统表示法，也可以把传统表示法转化为UML表示法。
至于思想，就不在此讨论了。
所以，我为此人感到些委屈。

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

形式化与可理解程度之矛盾的不可调和性正是图示化模型语言产生的原动力，而
不同的图示化模型言语间的差异性与图示化模型语言作为交流手段的矛盾则正是UML产生的原动力

我对newjing兄所指的formal model（形式化模型）中的formal(形式化)理解为把模型表达成有数学意义上的逻辑严密性的模型，不知对也不对？
首先，非常同意“UML更适合于分析和设计思想的表达与演示，软件工程思想的表达，而非进行精确设计的语言”
其实，UML正是被设计以用于表达与演示分析和设计思想的，它的目的是用于开发人员之间的交流，精确地说，在不同的情景下，分别用于系统涉众与系统分析员的交流、系统分析员与系统设计员的交流，系统设计员与编码程序员的交流。这种图示化的语言如UML等暂且叫直观化语言吧，为了方便和形式化语言说起话来容易区别。
每一个新软件系统的设计，起点和终点都是一样的，不外乎是从涉众表达需要和
环境约束到实现人员实现目标系统。理想的情况是，双方都可以用达到数学意义
上的逻辑严密性的表达手段来精确表达各自的意途。但就我所知，要达到数学意
义上的逻辑严密性的表达手段，不外乎二种，一种是数学方程式，一种程序式语
言（如我们平时用的高级语言如Pascal、C等)，其他的小弟还不知道，如果有的
话请不吝赐教，让小弟学多两招。
说到数学方程式，不知各位脑袋有没有开始发涨，小弟是数学专业科班出身（没
补过考的那种），都觉得有点头皮发麻，即使各位高手没有发麻，那验证数学方
程式所表达的内容是否正是用户所需要的这个问题有没有让贵脑袋的头皮开始发
麻？:)但是，如果没有个前提，那形式化就是一种赌博，双方都把注押在该议程
式所表达的内容正好是所需要的，但押中的机会有多少呢？我想这和双方的数学
能力成正比，这种方式对大多数情形而言显然是不适用的。
再说说程序式语言，请大家不要忘记了，我们为什么要引入模型，就是因为直接
用程序式语言来直接（直接的意思是不建模，从需求直接翻译成实现语言程序）
实现系统在工程学上所遇到的困难，对稍大一点的系统来说就是不可行性。
因此，我可以打赌说，想单单依靠模型表达手段上建立形式化模型是在工程实践
上不可行的，必须要依靠其他的手段配合来进行，当然现在还看不到成果，不过
我猜想会是过程和工具，也就是，经过适当定义和设计的模型语言、开发过程和
开发工具三者相配合，将来有可能可以建立在工程实践上有意义的形式化的模型
。

 UML正在往FUML方向上走
　

---

billiondelly兄弟，就OCL的加入和不断完善，我的判断是，UML就是在往FUML的路上走，完全同意你的观点。OCL语言最开始出来的时候，很明显的看得出来有VDM和ObjectZ得痕迹，只是为了简单性，仍然大量使用了自然语言。UML2。0我还没太仔细看里面得OCL，不好说什么。
此外，MIT的Daniel Jackson搞了套Alloy，走的就是综合UML的方便性和FM的精确性结合的路。

 一点儿不同意见
　

---

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

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

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

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

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

 UML和FM没有涉及到需求分析么？
　

---

hihint老兄，我完全反对您的这个观点。

无论是UML还是FM，创建处理的根本之一就是描述需求。无论你打开哪篇论文，都会看到类似于：How to capture the requirements of complex systems is always a big problem, so...... 极端一点儿甚至可以理解为，UML和FM存在的根本目的就是为了描述需求。

建模，可以是建需求模型，不就是需求分析么。举例，当用户罗嗦的告诉你，我们有N个员工，每个人需要有个员工号码，每个人有个银行工资帐号，这些都不能重复的，而且都是对应的。。。。。。 你写到需求模型里 “员工号与帐号一一映射”不就是用建模语义描述需求么。

FM与需求不是更脱节了，而是描述方式更简练更精确了 ：） ID --> CardID就说明问题了。

非功能性需求并非不可描述的，UML里可以加Note，可以有Documentation，这两个我们也看做是UML component.

针对观点，不针对个人，望老兄见谅。
　

 我理解您的模型了
　

---

我想我明白您的意思了，我们划分子系统的思路没有区别，上次回复里我扯远了，谈论的是LiftControlSystem里面的panel问题，不好意思。

 回复: 形式化与可理解程度之矛盾的不可调和性正是图示化模型语言产生的原动力
　

---

Formal是否理解为把模型表达成有数学意义上的逻辑严密性的模型，我和老兄的理解是一样的，至于具体定义，嘿嘿，我也不知道，你得问问 Tony Hoare之类的人。
你说的数学公式问题，的确让我头皮发麻 ：）小的过去做Z语言，完全基于集合论的，苦于数学功底不扎实（非数学科班，就上过门课），的确有些问题描述不了太精确，只要用些类似于stereotype类的东西来绕开。学数学的人搞这些可能就轻松多了，爱丁堡大学计算机系那帮牛人大多是数学出身的，搞些天书似的categary theory。软件所林院士好像也是那里出来的，手下也是一帮牛人，呵呵我扯远了。
我猜想你最后谈论的那个问题本质是refinement问题，现在也争论不休。

电梯问题好像还是很复杂的。我过去和你看法一样，后来碰到个搞电梯的人，告诉我无数的博士整个期间就研究电梯。他给我举过个例子，如果对单电梯两个人同时按，一个向上，一个下，同时的意思是按的间隔系统无非区分，如果设计时没做考虑可能就是系统死角了。电梯我也不懂，看过几篇论文就昏了 ：）

电梯的按钮不是和计算机键盘一样是单缓冲系统吗，同时按键我觉得问题不大。当然，我是从控制程序设计的角度考虑的，电气和机械问题没有考虑，从电梯测试的角度考虑可能会比较复杂吧。其实十几种状态的状态图也不是很简单，我说不复杂是考虑它还是一个事件驱动的系统，其复杂性我觉得比不上一个完全的时间驱动的automation（这是automation里相对比较复杂的一种），没表达清楚，对不起。博士论文使用它来做我想主要是研究调度算法吧，因为这么典型的例子是不好找的，如果只是找一个可行的设计应该是不难的。

如果没有OOA和OOD，UML只是一个画图的标准而以。

身边有一些满口术语的人，也仔细的听过他们对自己所说术语的理解，
简直是一派胡言。
形而上学，急功近利，很多所谓的专家不过是满嘴术语的词汇表，真正的理解又有多少啊。

如果真正能形而上学也不错，我认为，形而上是获得可靠质量的重要途径，或许也是唯一途径。