为什么UML“真的”死了? • Buttondown

21-04-28 banq

互联网上有一篇名为“UML就这么悄悄死掉了吗?”帖子,文章中Ernesto Garbarino说,UML被降低标准的程序员所杀死:“敏捷是刺客,而用户故事是她致命的、有毒的箭头。” 如果本新闻稿有一个主题,那就是我们不应该相信简单的答案。现实世界很复杂。

碰巧的是,几年前,我正计划编写UML的历史:它来自何处,为何如此流行如此之快,为什么它死了等等。作为其中的一部分,我采访了许多UML的知名人士。早期包括Grady Booch,Bertrand Meyer和Ed Seidewitz。现在我仍然记得一点一滴,足以自信地说,这个故事比“敏捷做到这一点”要复杂得多。免责声明,我的记忆力和四年前我放弃的一个项目的字迹模糊不清,所以我可能弄错了一些细节。

 

史前史

UML产生了两个重要的趋势。首先是“方法大战”。在Smalltalk和C ++成为主流的OOP之后,人们真正大量宣传并最终创建用于设计软件系统的正式统一的流程。这引发了不同设计方法的爆炸式增长。Bertrand Meyer在他的《 Business Object Notation》一书中列出了26种竞争方法。我记得阅读过列出50多个文档,但似乎无法再次找到它们,因此可能是错误的记忆。

大约在同一时间,人们还制作了第一个计算机辅助软件工程(CASE)工具。现在,CASE只是一个脚注,但在当时是一个巨大的行业,预计将比CAD或IDE大得多。CASE工具与方法集成在一起,不仅为开发人员,而且为测试人员,项目经理和客户提供了一种整体的软件创建方法。但是,制作CASE工具非常昂贵,并且必须针对特定的设计方法进行定制。随着时间的流逝,CASE供应商选择了以下三个:

  • Grady Booch的面向对象的分析和设计
  • Ivar Jacobson的面向对象软件工程
  • 詹姆斯·朗博(James Rumbaugh)的对象建模技术

格雷迪·布奇(Grady Booch)为Rational效力,后者也有大量的CASE产品,且他们大部分的收入都来自Ada工具。Booch还和Rumbaugh是私人朋友,随着时间的流逝,他们的想法趋于一致。在此之后,一致的想法给他们施加了很大的驱动力,要求他们进行明确的协作,以便CASE供应商仅支持两种方法,而不是三种。然后,由于一种方法优于两种方法,他们购买了Jacobson的咨询公司,并逐步淘汰了OOSE。

OOSE,OOAD和OMT是整体方法,涵盖了表示法和过程。消除符号差异要比处理差异更容易,因此Rational将统一分为两部分。统一建模语言于1996年问世,并移交给对象管理小组(OMG),而Rational Unified Process则于1997年问世。UML在大约十年中被证明非常受欢迎,并且大约在2004年开始引起人们的广泛关注,直到今天,也就是我们发布“ UML死了吗?”之类的文章时,那么为什么UML死了?

 

这意味着什么?

这个问题有两个歧义。首先是我们所说的“死”。程序员通常使用“死亡”来表示“相对市场份额的下降”,而不是绝对市场份额。许多意见领袖Thought Leaderz抱怨几乎没有开发人员会真正了解底层系统,但是与30年前相比,内核黑客总数有所增加,但这些黑客数量只是占用所有程序员数量中较低的一部分。

这意味着UML可以同时增长和“消亡”,具体取决于您使用的度量标准。现在,我假设UML无疑是“垂死中”。

另一个歧义是我们所说的UML。首先,UML包含十几种不同的图类型。我仍然看到人们经常使用顺序图。其次,人们使用UML图的方式有很多。UML和敏捷领域的杰出人物Martin Fowler ,确定三种用途:草绘,蓝图和编程。

以UML编程的方式在婴儿期就死了,因为即使UML的大多数支持者也认为这是一个可怕的想法。以UML进行需求快速捕捉(速写)却没有死,只是类似一种水上漂流状态而已。

人们使用非正式草图符号与UML标准保持同步,因此随着时间的流逝,它逐渐演变为多种相互难以理解的方言。所以我们不会看到在不同公司中的两个团队,一个在加利福尼亚,另一个在纽约,使用相同的符号,除非有人故意使它们保持同步。

这使UML蓝图成为最复杂的情​​况。据我了解,它也是Rational最想要的一种。作为蓝图的UML和作为草图的UML之间有两个相关的区别。

首先,他们目的是让设计人员编写蓝图,并由程序员实施蓝图。这意味着不同的技能和不同的工具。其次,UML-as-blueprint集成了不同的图类型。您不仅要编写一个类图和一个需求图,还要为实现了需求图的类编写一个类图。这意味着使用CASE工具进行蓝图。

因此,UML的下降通常与CASE工具的下降联系在一起。 这意味着“为什么CASE工具会失败”与为什么UML蓝图“会死”一样有趣。

 

UML将死的原因

在方法战和CASE工具兴起之后,UML出现了。市场上已经有大量用于OOAD,OOSA和OMT的CASE工具,而UML必须与这三个工具都向后兼容。从一开始就增加了很多摩擦。如果UML不必与传统供应商打交道,它本来可以更简单并且在概念上更加统一。

  • 缺乏形式化

UML留下了许多未指定的内容,例如图表交互的方式以及许多关键字的实际含义。UML 1.3在类图中给出了“generalization”箭头的示例:

其中Sailboat(帆船)是WindPoweredVehicle(风能驱动运输工具)和WaterVehicle(水驱动运输工具)的specializations ,它们都是Vehicle(运输工具)的specializations 。从设计角度来看,这实际上意味着什么?我们是否应该使用继承以特定方式实现它?这与细化关系(efinement relation)有何不同?在实践中,用户可以决定这些关系的含义,而CASE供应商可以决定要实现的功能。

这可能使您想起C语言:C89具有如此多的未定义和用户定义的行为的原因是,它需要容纳所有冲突的编译器。OMG(1.0版后UML的维护者)也有同样的问题。他们无法对UML标准进行任何更新,以免破坏现有的供应商决策,从而进一步减慢了UML的开发速度,并增加了每个修订的复杂性。

  • IBM公司

这是我从一位外围人那里得到的八卦。当时,虽然OMG受现有供应商差异的约束,但他们仍有一定的余地来为“更大的利益”做出重大改变。我怀疑Rational作为UML的原始开发者和最大的CASE工具供应商之一,Rational特别愿意更新其旧版软件。但是后来IBM在2003年收购了Rational,他们很快就停产了Rational的UML工具,并开始销售专有的CASE工具Rational Software Architect。因为他们不想继续发展传统的Rational项目,他们封锁了甚至任何UML变化轻微不相容的,UML作为一个整体停滞不前。

当UML的市场占有率开始下降时,2003年也差不多。我不认为这两件事是巧合。

  • 太复杂

现在,我们要探讨UML的特定问题。UML包含许多不同的图和规则,导致最终产品非常复杂。每个人都为此感到难过,这使学习UML变得多么困难。这也使开发工具变得困难。您只需要了解几张图就可以逃脱,但是在整个规范中,任何工具都必须是全面的。如果您想构建比“生成图”更复杂的内容,则需要一个庞大的团队和大量资金,这限制了您可以实际增长生态系统的数量。开源世界并没有大量的CASE工具,而您获得的工具却很薄弱。

这并不是说商用CASE工具可以创造奇迹。您的表示法越复杂,为其开发任何工具的难度就越大。 如果CASE工具能够完成令人兴奋的创新工作,那么UML的使用时间可能会显着延长,但是事实并非如此。

  • 无文字格式

这是对工具的又一拖累。这意味着您无法在自己喜欢的文本编辑器中编辑UML图表,也无法对其进行grep编写,也无法编写自己的定制解析器等等。

已经尝试过为UML创建文本表示形式,例如PlantUML或Mermaid,但是这些遇到了两个问题。首先,它们只是单向的:您不能将现有图转换为文本形式。第二个问题是我所说的Graphviz问题:文本格式在表示视觉布局方面很糟糕。在最好的你已经有了一个繁琐的系统,该系统比使用一个图形编辑器显著恶化。

  • 完全没有数据格式

这使得导入和导出UML基本上是不可能的。一旦开始使用工具,就会被该工具所困扰。在明显的问题中,这又是生态系统的杀手。您无法制作独立的UML工具,验证器或必须作为CASE工具扩展运行的任何东西。OMG试图通过XMI(一种UML的XML格式)来纠正这一问题,但是据信它从来没有那么好过。而且它在XMI和UML版本上都向后不兼容,这使其异常脆弱。

  • 无法正向逆向

一些工具可能会从UML规范中生成代码,但是可能会对某些修改后的代码进行逆向工程图处理。没有人能做的很好。就像所有蓝图一样,UML和代码将不可避免地不同步。

  • 文化转变

最后一个高度投机的理由。Garbarino在原始文章中说,UML之所以死是因为敏捷接管了文化。我确实认为文化转变在UML的下滑中发挥了作用,但这并不是出于他的想法。

CASE工具仅对大型软件项目有意义,因为在大型软件项目中,很多人长时间从事相同的工作。它也是高度“官僚”的。虽然我们今天认为敏捷取代了占主导地位的瀑布,但在那时,大多数开发人员都是临时性地和渐进式地工作的。由于这些原因,CASE工具最初是由强制内部使用的企业采用的,这似乎是合理的。正如Garbarino自己所说的那样,UML受到了业务人员而不是程序员的喜爱。

 

传统企业在1990年代是软件的主要雇主,这意味着技术趋势可能反映了他们的兴趣。这将是UML最初兴起的一个很好的解释。但是,在过去的二十年中,软件文化逐渐向大型技术优先的公司和初创公司转移。从历史上看,两者都不是CASE供应商的目标受众。随着时间的流逝,传统企业开始从技术和初创企业那里借鉴学习,反之则相反,这导致CASE在现有领域中的地位逐渐下降。

 

猜你喜欢