UML建模语义

Question

在今天关于使用UML的MDD建模技术的讲座中，这位讲师说，绝对有必要对您生成的每个图的语义进行(可能的)文本描述。

在我看来，没有必要描述已经被UML标准化的图元素的语义。我可以看到，如果您以任何理由通过构造型/标记值扩展标准UML，这是完全合适的。

相反，我认为标准化在普通情况下有一个意图，就是让人们去推理和谈论图表，而不必每次都解释语义。当然，唯一的先决条件是它们都依赖于相同的UML规范。

MDD的另一点是，在相同的图类中不时使用不同的语义，最终会使代码生成和自动模型转换变得困难。

1. 我说得对吗？
2. UML中是否存在一些固有的解释歧义，以使其更通用？

Answer 1

在我看来，没有必要描述已经被UML标准化的图元素的语义。

是的，当图元素的语义在UML标准的某个地方被正确定义时，就不需要描述这种语义了。问题是，特别是对于MDD，完整的语义取决于这些元素的代码生成，而且由于没有广泛接受的UML到代码映射标准，UML标准根本就没有为其元素定义整个语义。事实上，即使是标准中的“UML语义”段落也主要处理UML语法，并且只给出了一个非常非正式的语义概念。

当然，在进行MDD时，并且代码生成器已经就绪，您可以只创建一次元描述，告诉您/您的团队/您的项目/您的项目/您的公司应用了哪种语义，而不是一次又一次地对每个图表部署相同的描述。

这是一篇科学论文处理的问题是，UML语义大多是非正式的。谷歌搜索"uml语义规则“将为您带来更多深入讨论该主题的论文。

Answer 2

您是对的，构造型不应该需要明确的解释(除了定义它们的位置，如果您是出于某种原因使用自定义原型的话)；这就是使用原型的意义所在。这通常并不意味着您可以避免描述事物，因为很少有软件只是一个原型的协调。另外，在一些有趣的部分(如发出ID或执行计算)上的一些描述也可以在其他地方节省大量的复杂性。请注意，用人类可读的语言编写的文本并不是进行这种描述的唯一方法；根据您正在做的事情，来自本体的数学方程、语义注释，甚至链接到适当的学术论文都可能更适合。这一切都取决于。

可以使用UML和适当的代码生成来编写几乎整个程序。但是，您可能不想在任何真实的情况下这样做，因为要管理描述即使中等大小的程序所需的图表大小的复杂性，这将使像UML这样的图形设计模型的使用相当不切实际。UML对体系结构很好，它的真正目的是向程序员展示，以便他们了解更大的情况，但不太适合于详细的工作。(如果我把所有的东西都扩展到…之外，我会不寒而栗地想到我的程序在UML级别上的复杂性)

Answer 3

我不认为讲师的意思是评论应该反复教导UML所代表的内容。相反，我将您的问题解释为一个特例:我需要注释我的代码吗？如果是，怎么做？

通常的争议在于您的产品(作为代码或UML)是否是自我记录的，因此不需要注释，或者注释是否确实为您的产品增加了一些价值，或者评论是否与您的产品保持一致。