UML发展现状与实际应用——希赛嘉宾聊天实录

        本文是我在2007年1月作为希赛(CSAI)嘉宾的聊天实录，希望对大家能够有所帮助，来自www.csai.cn。

聊天记录：

【希赛主持人】各位希赛的网友大家上午好，欢迎大家再次光临希赛嘉宾聊天室，让您们久等了，今天我们有幸请到的是希赛顾问团顾问刘伟作客希赛嘉宾聊天室。
先请刘顾问与我们打个招呼吧！

【希赛嘉宾】大家好！我是刘伟，很高兴在希赛聊天室和大家交流一下UML的现状和应用方面的问题！

【希赛主持人】今天我们要聊的是“UML发展现状与实际应用”，首先我们还是请刘顾问介绍一下UML吧，UML这些年来在不少地方都得到了应用，UML做为一种建模语言，它现在在我们国家的使用状况如何呢，UML在实践应用的多吗？

【希赛嘉宾】UML这几年在我国发展还是比较迅速的，但是与美国、印度等国家相比还是有差距，越来越多的公司开展了UML系列的培训与学习，也购置了一些UML的CASE工具，但是在我们国家的使用情况效果并不是太好，我认为UML的发展与应用还需要一个过程。

【希赛主持人】UML现在使用得广吗？它主要应用在哪些地方呢？

【希赛嘉宾】它的应用领域很广泛，实际上除了软件界可以使用之外，其他行业也可以使用，我甚至看到有用UML的方法绘制的军事战略部署图，当然最主要的还是应用于计算机领域；它可以用于各种类型的软件的开发，无论是制造业、游戏开发、医疗卫生系统、还是OA，EAI，DSS，ERP...都可以使用到UML。

【希赛主持人】 网友[miskitter]: UML建模语言是不是对所有应用系统都实用呢？

【希赛嘉宾】这样看具体的情况，对于使用面向对象技术开发的系统更加合适，当然在需求分析等阶段对所有的应用系统都实用。像一些流程化很强的系统，或者小型的项目有时候没有必要一定使用UML。像敏捷开发中就提到系统的开发人员应该从技术和工具灵活的选择，找到最合适的工具，像做一个小软件，如一个小的网站就不需要用到UML来进行建模。

【希赛主持人】UML为什么会受到这么广泛的使用呢？

【希赛嘉宾】这与UML的特点有关，它综合了软件工程领域的一些主流的软件思想，并在20世纪90年代进行了综合，是公认的目前最流行的软件分析与设计方法，同时它推出了一套标准，使项目开发人员可以不考虑技术细节对系统达成共识，这套标准与应用系统无关，与采用的编程语言无关，开发工具无关。UML是程序员之间的交流语言，RUP之类的工具也保证了软件开发过程的规范性，严格保证了先设计后开发，设计阶段有规范详细的规范化的文档等不是唯一的，它不能完全取代传统的软件工程方法，实际上在现在的XP理念中对于建模方法的选择不是唯一的，需要根据实际的业务来选择合适的建模方式，像传统的业务流程建模，数据建模也有它们的优势，我们可以取长补短。

【希赛主持人】网友[meisong]说: 在现实软件工程应用中，面向对象UML建模方法是否是唯一的，是否取代了传统的软工方法？

【希赛嘉宾】不是唯一的，它不能完全取代传统的软件工程方法，实际上在现在的XP理念中对于建模方法的选择不是唯一的，需要根据实际的业务来选择合适的建模方式，像传统的业务流程建模，数据建模也有它们的优势，我们可以取长补短。

【希赛主持人】那UML在项目开发过程中是一个什么样的地位？

【希赛嘉宾】UML主要用于系统的分析和设计阶段，现在大部分的UML case工具都能自动生成一些程序代码，实际上也可以用于一些基本的系统实施阶段，同时从UML分析中可以得到一些测试用例，另外UML对系统的维护与设计也有所帮助，好的UML模型让维护人员在发现问题后可以很快找到问题的根源，在项目开发的全过程中就可以见到UML，但是主要还是分析和设计。

【希赛主持人】那在我国是否存着对UML只是一种形式主义，是一种盲目的炒作与跟风？

【希赛嘉宾】确实对于某些公司和个人来说存在这个现象，但是随着对象建模技术的发展和应用，越来越多的人会理解怎样正确使用UML来分析与设计系统的。

       这里说一个题外话：有时我到长沙的一些高校附近的书店去逛，看到计算机类图书问老板有没有UML的书，很多书店老板说不好卖，现在的学生很少买这方面的书。

       大学教材一般还是用数据流图来描述系统，系统设计也主要就是对数据流的分解，我觉得应该让计算机专业的学生在高校就有对UML的知识一个系统学习更好。

　　实际上，采用UML作的建模语言是完全必要的:首先，各种各样的面向对象的建模语言都是相互独立的，而UML可以消除一些潜在的不必要的差异，以免用户混淆；
　　第二，通过统一语义和符号表示，能够稳定我国的面向对象技术市场，使项目根植于一个成熟的标准建模语言，从而可以大大拓宽所研制与开发的软件系统的适用范围，并大大提高其灵活程度。

【希赛主持人】在现在来讲。现在常用的UML建模工具有哪些呢？

【希赛嘉宾】UML建模工具有很多，常用的有：Rational Rose、ArgoUML、Visio、Power Designer、Jude、Enterprise Architect、Together等等，我用的比较多的是Rational Rose，Visio，Power Designer和Jude。现在好象出现了一个中国自己的UML建模工具，叫在Trufun Plato，有兴趣的网友也可以去了解下，毕竟据说是第一款中国的UML建模工具。

【希赛主持人】这些工具有什么区别呢？我们该如何选择？

【希赛嘉宾】我个人认为选择的标准如下：价格、是不是符合UML最新的标准(如:UML2.0)，能不能和数据建模集成，双向工程，HTML 文档化，代码的自动生成，表图操作的容易性，自动化程度；像正版的Rose 很贵，IBM Rational的这个工具很庞大，适合企业级的一些应用，但是如果只是为了学习没有必要；Jude是个免费的小工具，可以自动生成Java代码，还不错，推荐大家用做学习；Visio有些图不太标准，和UML标准有点冲突，但是因为符合office软件的风格，上手很快；Power Designer在数据建模领域是世界第一，它对UML标准的支持也比较全面，遗憾的是有些图，如活动图、状态图等提供的功能不完善 ；当然还有其他工具 像EA，Together也是很不错的UML工具。
　　学哪个工具并不是最重要的，关键是UML建模中的思想。

【希赛主持人】刘顾问向我们介绍了UML的一些现状问题和UML建模工具，现在我们聊一下UML在实际上的东西吧。
　　刘顾问，您有过多年的项目开始与管理经验，在你的项目中都会用到UML吗？

【希赛嘉宾】不是所有的项目都用到，想用非面向对象语言设计的一些系统或者项目比较小，需求很清晰的系统就可以不需要用到UML，毕竟UML本身也是个比较复杂的建模方式，要均衡一下成本和时间。

【希赛主持人】那使用UML的应用是怎样的一个流程呢？在项目当中的什么地方会用到UML？

【希赛嘉宾】这个问题比较复杂，呵……
　　从项目的最开始进行需求分析时需要进行需求建模，要使用到UML中的用例图，撰写相应的用例描述文档之后可以从用例描述文档和SRS中寻找名词和关键词，开始进行静态建模和动态建模，现从这些名词得到一些类，对类进行整理和抽象，确定类之间的关系，绘制类图，有时候需要绘制对象图，注意的是对于大的项目类图实际上也有一些模块化的思想在里面，不可能把一个系统所有的类都画出来，像一些界面类，控件类在类图中有时候并不需要表示，因为分析设计和开发人员都明白是怎么回事。
　　我一般对一些复杂的部分，才绘制详细的类图，有时候在识别类之间关系时，需要时序图和协作图，实际上静态建模和动态建模是结合使用的，不需要一定要等一个图全部画完了再考虑绘制另一类图。
对于一些复杂的需求用例，可以绘制活动图，我个人把活动图理解为对象建模和流程建模的一个交叉点，对于一些复杂的流程，我们用活动图来表示，但是又加入一些对象的思想，以便清晰知道哪个流程中会与哪些类或对象有关联。
　　对于一个状态比较多的类，可以考虑画状态图，以便了解在系统运行中，状态之间是怎么转换的，什么时候转换，然后把一些类组织起来，形成包，或者是组件创建组件图，在java 里面有个包图，实际上也是类的集合之间的关系，这些都是更加宏观的视图。
　　最后考虑到系统的真实运行环境，画部署图，后面这两个有时候也叫做构架建模，实际上把UML建模分成四个子建模，可以为：需求建模（第一步）、静态建模和动态建模（第二步）、构架建模（第三步）。

【希赛主持人】刘顾问，还能谈谈UML在这些项目上的经验或者一些心得吗？

【希赛嘉宾】使用UML来对应用系统进行建模，要注意不能为绘图而绘图，就象传统软件工程中的文档一样，不能为写文档而写文档。
　　还有几点是：图一定要准确反映系统的真实情况，并不是每个系统所有的图都要，不同的图表示系统的不同侧面，不要幻想用几个UML图就能描述整个系统的所有细节，采用最新的标准技术，因为UML1.1和后面的1.3以及2.0还是有点区别的，需要在使用的时候了解一下。
　　实际上在UML建模中也有一个简明规则，就是尽量让图画简单一些，要是画到客户也能够看懂，但是又能够表示系统的真实面貌是最好不过的了。

【希赛主持人】那有没有发现UML不足的地方？

【希赛嘉宾】世界上没有完美的东西，记得在2002年吧，在《程序员》杂志上看到一篇文章好象叫《UML的三大硬伤》，网友们可以去看看，说到了UML存在的一些缺陷，虽然UML不断在发展，但是有些问题是一直存在的，那篇文章讲到UML在获取需求，对编程工作的指导，建模图形之间的关系方面都存在不足，所有对于一些复杂的业务流程，我们还是需要用到一些传统的建模方式来辅助。还有一个就是UML本身也比较复杂，UML工具不统一，大家用过这些工具就知道，不同的工具绘制出来的图形有时候并不一致，首先对于需求的捕获，因为UML太专业了，不象一些流程图，客户一看就懂，你想画个类图给客户看他能看懂吗？

【希赛主持人】 网友[cjp106] 说: 能大体说下三大硬伤是那几个吗？

【希赛嘉宾】首先对于需求的捕获困难，因为UML太专业了，不象一些流程图，客户一看就懂，你想画个类图给客户看他能看懂吗？
　　第二，UML建模不像软件工程中的详细设计文档，代码规范什么都有了，程序员看到这些图还是要花很多时间去研究怎么实现这些功能
　　第三、图太多了，图与图之间的关系不明确，很容易造成冲突，建议你去网上找这篇文章看看。
UML的书确实很多，首先大家现在购买的话尽量选择采用2.0标准的，UML用户指南，UML参考手册，UML精髓，UML与模式应用都是不错的经典。
　　对于需求的描述可以使用UML用例，这与面向对象无关。
       如果是面向对象技术来实现系统，要了解的是要不要滥用UML，这样反而会导致系统看上去很复杂。例如状态图，没有必要任何一个类都画一个。
　　有时候初学者喜欢卖弄，例如一个公交反馈系统，像这个系统中一个很关键的名词是反馈，在代码中会被设计为一个类，被实例化成一个对象后就存在多个状态，例如刚被提交的反馈，通过调查确定其真实性的反馈，对真实反馈进行跟踪最后采取了纠正行动的反馈，所有操作都完成的历史反馈，这些状态在系统分析时有时候把人搞晕了，如果画个状态图那就清晰很多了。但是并不是所有的类都有这么多状态的。

　　初学者首先下载个免费的工具，像Jude，拿一个小项目出来，一边分析一边学，理解每个图的含义和作用，重点是三个图先理解：用例图、类图、时序图，其他图再慢慢理解，是否使用UML的关键决定因素是需求的稳定性，系统的规模，是否采用面向对象的开发方式，系统的可维护性与团队的协作能力等。

【希赛主持人】最后，刘顾问对要即将涉足UML的企业或要学习UML个人有什么建议？

【希赛嘉宾】首先要有一个完整的学习，特别是对于软件企业，美国UML使用相对成功的原因之一是他们的企业对客户都进行了UML培训，另外还是那句话——UML图形要保持简洁，不要太过复杂，不需要的图尽量不画。

　　理解对象建模的一些原则，选择合适的CASE工具，对于小型项目可以不使用UML的不要滥用，有意识培养程序员的分析设计能力。
　　从一开始学就养成一些好的绘图习惯，一定要对图中的一些关键字进行注释。

【希赛主持人】由于时间的关系，今天聊天就到这里，可能些有网友还有问题，可以在希赛社区中发贴与大家交流，我们的嘉宾也会给您解答的。

　　谢谢刘顾问的参与，也谢谢各位网友的参与，我们下次嘉宾聊天再见！

【希赛嘉宾】如果大家在UML方面还有一些想法，我们可以进一步交流。我的邮箱地址是weiliu_china@hotmail.com再见！

【作者：刘伟 http://blog.csdn.net/lovelion】