UML死了,但是形式方法能成功吗? •Buttondown


上周二的文章“为什么UML“真的”死了”风靡一时。我很高兴人们喜欢它,我也很高兴使用所有休闲研究它,但是有些事情困扰着我。人们并没有从UML切换到其他东西。他们完全摆脱了思维定势。UML并没有满足程序员的有意义的用例,因此,当它不起作用时,他们就不会寻找替代方案。
排除所有环境上的优势,例如“它具有文本格式”和“复杂程度大大降低”,然后考虑必要的附加值。UML的“重点”是蓝图。
人们可以在实施软件项目之前对其进行设计。这也是形式方法的重点。
人们不寻求UML替代品的事实应该让我感到担忧。这可能意味着建模对软件工程师没有用,考虑到这太可怕了,所以我转而采取更加乐观的态度:建模虽然有用,但是UML却不值得。
使用UML实际上能为您带来什么?梦想是UML与代码之间的来回代码同步,以进行模型驱动的开发,但是这个梦想从未实现。
在整个生命周期中,UML的价值一直在于拥有UML图。它应该可以帮助您与团队进行精确的沟通,并可以作为编写实际代码的参考。
但是,这些还不足以使其有用,即使捍卫UML的人也仅使用了少数图表,并且将其作为草绘符号,而不是蓝图符号。而且,如果也有任何东西可以代替它,那么从原则上讲,设计没有任何用处。
...
 
网友评论: 
在我的职业生涯中,我发现在很少项目中能有效使用了形式化方法。的确,我认为UML在v 2.0的道路上走下坡路的主要原因是努力使其更加形式化。
 
UML最初被设计为一种用于可视化和推理系统的语言。它从来没有打算成为一种可视化编程语言,而正是通过引入相当大的复杂性来削减了它被使用的原因。
 
UML的重点不是“让我们可视化编程语言可以实现的一切”,而是“让我们提供一种我们可以用来协作,交流和进行设计推理的媒介”。
 
UML之所以死亡,是因为人们对它的要求超出了预期。它被认为是一种设计工具,可以捕获,可视化设计并进行讨论。但是全世界都坚持认为它也是一种编码方法,其结果对两者都没有好处。
 
我确实相信,敏捷及其相关的文化转变对UML衰落的影响比其他任何因素都大得多。可以肯定的是,UML似乎太详细,太复杂,工具很烂等等。
 
“我们是敏捷的”,“这是敏捷中不会期望的”,“我们不想告诉开发人员该怎么做”,“您会被视为过时的”,这是团队放弃UML的原因类型。知名的敏捷传教士实际上是在告诉人们他们不需要UML;引入敏捷宣言后,还有一个很大的“我们不需要架构师”运动,进一步将前端设计,文档,UML等推后。我曾与大型组织的架构师进行过多次对话,他们告诉我在这段时间他们感到非常被敏捷运动排斥在外。众所周知,团队部门仍然需要这些架构技能。没有它们,就不可能是“全栈式”的。我听过所有这些故事...团队内部/外部没有标准的交流方法,重复/浪费的工作,难以招募新员工,代码库乱七八糟,因为开发人员对它的工作方式有不同的看法,等等。
 
banq:实际上事件风暴替代了UML序列图和状态图,而DDD聚合非常适合使用UML类图表达。这些都是不同的新旧形式化方法,也是一种非正式的形式化,形式化方法越是规范严格,虽然逻辑更严谨,更能直接生成代码,但是使用人员掌握起来就复杂,不如直接学习编程,两者之间是一种矛盾,但是通过一种快速方法能够对需求实现摸着石头快速过河是永远需要的,不管敏捷还是UML或低代码或BPMN或快速可视乎开发都是试图实现这点。