使用UML最显着的缺点是什么？

Question

UML是一种很好的语言,可以根据业务需求为软件建模,但是有一个不断增长的社区为某些缺乏功能指出了一些缺点.

您认为UML最重要的缺点是什么？它可以成为解决这些缺乏功能的好方法？

Answer 1

最大的问题是,它是另一层繁文缛节,只会让$#%$#%编码并使其正常工作.

Answer 2

事实上,人们使用它来"为业务需求建模软件",正如你所说,以及其他这样的面向过程的哗众取宠.UML最初是作为程序员以图形形式向其他程序员传达软件的传统方式.从这个意义上讲,这只是正式的餐巾纸涂鸦 - 因此它非常有效.你可以在白板上绘制一个UML类图,我可以理解它,而不需要对符号进行讨论.

但是在某个地方有人认为绘图符号可能在某种程度上是一个独立的过程,或者至少是一个更大过程的正式部分.那太傻了.UML图表是一种很好的说明书籍的方法,对于工程师来回抄写想法非常有用.但那就是应该结束的地方.

Answer 3

我至少可以说三个:

1. 保持图表合理并与实际代码同步需要花费大量时间.UML图不运行,但需要很多时间.因此,只有当您的组织规模可以管理它们时它们才是好的
2. 您不能代表序列图中的每个条件.如果你想交付,这是不可能的.所以状态图应该传达基本事实,而不是所有可能的结果.
3. 好的UML软件需要花钱,而且需要一些时间才能正确掌握.

因此,我认为UML作为一个补充文档角色是好的,并且只有在您的组织规模允许的情况下.

解决方案......最后,图表只是一种在空间或时间向另一个人传达高级信息的方式(例如,某些年份可能是你).极限编程将信息检索的负担从死树转移到活脑.当然,它假设活着的大脑永远不会忘记,永不退出.极限编程使用冗余来减少此类事件的影响.在一家大公司中,强大的裁员可以消灭整个团队,因此将信息存储到大脑中可能会有风险.另一方面,大公司有人力浪费,因此图表.

另外,正如WDuffy指出的那样,如果你是一名设计师,并且你必须与程序员团队沟通他们必须实现的东西,那么使用UML图会容易得多.当然,一个拥有小团队的小公司通常目标很小,你可以组织不同风格的人.一家小公司UMLing只生产其革命性产品的UML图表,然后它就会破产.

UML不好也不坏.它可以是一个很好的工具,但必须在适当的环境中使用.

缺乏功能？

好吧,我发现UML强烈瞄准了面向对象的世界愿景.我们公司主要以python开发,重点关注模块级例程.对象是轻量级数据容器,但所有逻辑都是在模块级别完成的.除非你在术语中使用一些"黑客",否则很难在UML级别正确建模这种实现方式.我想用UML模拟功能或过程语言是很困难的.

我觉得烦人的另一件事是将用例建模假设为图表.我的经验是,传达用例的最佳方式是编写一个简短的故事或简短的代码,将您要传达的功能整理出来.故事应该简短,最多一页.这种方法有两个优点:如果您的故事是书面散文,Q/A团队可以轻松阅读和测试.如果您的故事是代码,您可以将其作为功能测试并让它在夜间运行.图表不满足任何这些增值需求.