BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

UML2.5值得期待吗

| 作者 崔康 关注 1 他的粉丝 发布于 2013年12月18日. 估计阅读时间: 7 分钟 | ArchSummit北京2018 共同探讨机器学习、信息安全、微服务治理的关键点

UML2.5的Beta版自2012年底发布以来在开发社区中引起了不少争议,其正式版本预计会在最近发布。Scott W. Ambler认为,UML虽然已经成为业界的通用标准,但是其实际的存在价值和意义并不是很高。 

Scott是一位有着三十多年开发经验的开发者和布道师,他编写了不少UML的著作,包括《UML 2.0 Style》(2005)、《The Object Primer》(2004)、以及荣获Jolt奖的“生产力奖”的《Building Object Applications that Work》(1997)。他认为尽管OMG已经在营销UML上取得了成功,但它在生产一些人们觉得有用的产品上变得不尽如人意了。

从1996年开始,对象管理组织(OMG)的统一建模语言(UML)标准已经成为IT界内的普遍标准。UML对我们行业的影响令人印象深刻——有数十种UML的书籍被出版、数以千计的博客和文章被发表、还有成千上万的的培训课程因此开展——其中有些是我开办的。而现在UML v2.5版本即将发布,但我甚至不确定我是否关心(它的发布)。

对于UML的发展历史,Scott做了简要总结:

UML最初由Rational Software公司所开发,现在则是IBM公司(我的前任雇主)的一个部门分支。1996年时,UML处于“The Three Amigos”(三个朋友)的领导之下,即Jim Rumbaugh、Grady Booch、和Ivar Jacobson。UML版本1.0在1997年的一月被提出,并在那年的晚些时候被OMG正式通过。此后,UML已经经历了多次版本修改,如2005年发布的UML 2.0版以及最近于2001年8月发布的UML 2.4.1 版本。一个“处理中版本”的UML 2.5已经在2012年的十月被发布了,并且预计不久将会正式发布。我猜测正式版本将在下次OML技术会议中被发布,此次会议将在十二月于Santa Clara(圣克拉拉)举行。

虽然Scott丝毫不怀疑每个参与发布UML 2.5版本的人都做了大量的工作,但他仍需要努力寻找一个理由来对这个版本产生兴趣。首先就是UML的简化,Scott指出,UML 2.5的目标是简化并阐明一个规范文档来减少实施中的问题并且促进工具间的互用性。由于曾经因为UML 2.0版本的复杂性而产生过显著的反对,因此简化规范是朝着正确方向迈出的一步。

UML中的复杂性之一的表现是增加了图表,似乎这对于大多数使用者来说几乎没有任何价值。举个例子,你有没有见过,更别说用过组合结构图(composite structure)、交互概览图(interaction overview)或者通信图(communication )?你是不是甚至不知道我在说的是什么?好消息是在UML 2.5版中,语言本身基本保持不变。然而新的图表已经被增加到总共19个了(由UML 2.0中的16个图)。

新增的图分别是:

  • 模型图(Model)。这是包图中的一个特例(类似于自由形式的架构图)。
  • 表现形式图(Manifestation)。是部署图或者组件图的一个特例,展示了组件在物理解决方案中是如何体现的。
  • 网络架构图(Network Architecture)。这实际上是一个高层次的部署图。

但是,令Scott失望的是,依然没有特定用于用户界面或者数据库开发的图。

UML 2.5的第二个复杂之处,至少对于工具厂商来说,是规范本身在语义方面的不一致。UML 2.5版本发布的主要重点将是清理规范,也就是理论上说,应该使工具的互通性变得更好。

由于SysML空间中的一些意外,自从计算机辅助软件工程(CASE)工具在80年代末期问世后,工具的互通性一直维持在“构架(marchitecture-- marketing和architecture的复合词)”水平上。我会让基于UML模型驱动架构(MDA)工具的市场份额为自己说话。对于我来说,工具互通性的底线意味着我可以在工具A中编辑一个模型,将其导出到工具B中,并在那里更新,然后再将其导入回工具A中,并且这过程中不会有任何信息的损失。此外,工具B并不一定得是一个建模工具。我真正需要的是在我的整个工具包中都能达到这种级别的互通性,而且无论我是用于捕捉高层次的需求还是一路下降到底层运行代码中都应该可以满足。不过更好的是工具能够真正做到无缝的即插即用并且提供一个功能齐全的传递解决方案的堆栈。

Scott指出,除了在那种定义非常良好的,如在典型要用到SysML的地方之外,他怀疑到底能不能理解有意义建模工具的互通性。互通性的主要挑战并不是技术性质的,而是政治上的挑战。

建模工具的厂商,无论他们的营销主张是什么,都不愿去生产与其它工具兼容的很好的工具,因为这对他们来说也是失去顾客群的方式之一。更糟糕的是,甚至有一些厂商提供了很多甚至不与自身兼容互通的工具,更别说与其它厂商的产品互通了。因此建模工具的互通性已经“指日可待”了十多年,并且我怀疑它很长一段时间都可能会停在那了。

为了支持自己的观点,Scott之前针对UML的实际意义做了调查:

我并不是唯一一个对UML感到厌倦不堪的人。在2013年10月的最后一周里,我进行了一个小型的调查来探索出人们是如何进行建模的,包括同时使用UML和业务流程建模与标注(BPMN)的人。此次调查总共有162个回应,并且调查的详情可以免费下载。每位受访者都听说过UML(如同我之前说的,UML确实是无处不在的),但是有26%的人从来没听说过BPMN。只有13%的人认为UML是非常有用的,并且45%的人表示UML是有用的,不过他们如果没有UML也可以完成自己的任务。另外20%的人表示UML带来的麻烦比它的价值还要多,并且22%的人表示他们根本不用UML(尽管这些人里10%的人表示他们曾在过去的一个月中看过一个UML图)。总之,OMG已经非常成功的推广了UML,但并没有成功的生产出人们觉得有用的东西。

Scott认为,也许有一天,基于UML的工具将真正提供长期有保证的更高水平的抽象层,从而使软件开发的生产力产生飞跃。但在这个阶段,他怀疑任何这种类型的生产力的提高都将来自于一个完全不同的方向。

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

我们需要UML吗?不需要吗? by Wong Peter

总之,OMG已经非常成功的推广了UML,但并没有成功的生产出人们觉得有用的东西。

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

1 讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT