威廉·库克（William Cook）在一条推文中写道：
“ UML对MDD来说是最糟糕的事情。幸运的是，现在许多人意识到了这一点…… ”
我想知道该说法背后的原因（显然，我不是在指他的个人观点）。
我注意到那里的许多人不太喜欢UML。同样值得一提的是，他在学术界，UML成为有效设计和建模的圣杯。
Answers:
好吧，我是发布原始推文的学者。推文并不意味着学术文章。它们是广告，我认为它们也可能引起争议。这是我的后续推文：
1）创建UML来建模OO设计。这会影响您正在对系统代码进行建模，而不是对系统行为进行建模。UML处于错误级别。
2）UML中的7（或13）种图表格式可以涵盖所有内容的想法是疯狂的。GUI，Web线框，授权等如何？
3）UML鼓励了模型必须是图形化的想法。荒谬！文本和图形模型既有用又经常可以互换
4）UML既太大又复杂，同时又非常有限。刻板印象和配置文件对可用扩展无效。
请注意，我并不一定要说UML不好。我只是说这对我感兴趣的“模型驱动开发”目标无济于事。我不理解关于“圣杯”的评论。
UML相当于拿起螺丝刀和锤子，将它们敲击在一起，然后称其为“通用紧固工具”。从理论上讲，它可以用来表示大量细节，实际上，它是一堆声称集成为单一工具的集成不良的工具，这使得完成任何一项任务都比拥有合适的工具更困难。
我认为还有一种情况可以说MDD是UML发生的最糟糕的事情（为什么我们还要拥有我们拥有的UML2？），但是暂时忽略了这一点...
MDD =模型驱动<设计|开发>。这个想法是为了能够在适合问题域的抽象级别上开发解决方案-也就是说，这是尝试以最自然的语法来表达问题的解决方案，以表达那些解决方案。问题域本身的特征在于操作模型（即，可以由计算机执行的模型）。因此，MDD可能是一种非常有吸引力的方法，尽管它有两个主要要求：
我的理解是，UML2的工作旨在解决第1点，这可能是基于以下信念：UML的行业经验表明，对于某些较大的问题域子集，第2点已得到满足。不幸的是，这就是我认为William Cook所要达到的目标，UML对于所考虑的问题范围之内的任何地方都不满足第2点的要求。我并不是从个人经验谈起的，但是我认为将MDD与UML结合使用的行业经验有两个共同的结果：
无论哪种情况，MDD的承诺都无法实现。UML可能被认为是MDD发生的最糟糕的事情，因为它引起了MDD工具开发人员的注意，即排除了可能实际起作用的模型（尽管存在较少的软件问题）。
只要它只是一种建模语言，UML就很棒。如果您尝试将MDD连接到UML以获取图形视图，则它是无用的。没有UML的MDD以及没有MDD的UML都会很棒。
假设UML和MDD今天离婚是为了不再拥有更好的生活:-)