软件测试开发技术UML环境概述和语义职责

软件测试开发技术UML环境概述和语义职责 UML模型

关键字：UML 环境 语义 · 概述 

UML 模型被用在环境中使用。多数人使用建模技术为了达到一个目的，即为了开发性能优良的系统，而不是为了使用模型本身。模型的目的和对模型的解释也受环境之外的因素影响。在广阔的外部环境中，另一些工具包括：跨越多种语言的元模型、模型编辑工具、程序设计语言、操作系统和主系统构件以及那些使用系统的商业和工程背景。确定模型的意义和使用目的取决于所有这些工具，其中也包括 UML 语言。 

　　模型在不同的具体层次中出现。 UML 是一种通用建模语言，包括语义和表示法，适用于不同的工具和实现语言。应用中的每个层次需要使用不同层次的 UML 建模思路。 

· 语义职责 
元模型是对模型的一种描述。建模语言描述模型，因此，它可以用元模型描述。元模型试图通过定义语义使语言精确，但是为适应新情况它必须允许扩展。元模型的实际形式对于用工具实现模型和模型的互换很重要，但多数用户并不关心它。因此，我们在本书中未涉及到它。对此有兴趣的读者可以参阅配套光盘上的原始标准文献 [UML-98] 。 

　　元模型和语言必须能够覆盖多大的背景信息并具有很强的解释力。现存系统有不同的执行和存储模型，从中选择一种作为正确的解释是不可能的。实际上，甚至考虑这样的选择都可能产生误导。我们可以将执行模型的不同解释作为语义变更点。语义变更点是一个随执行的具体语义而不同的点，但它与系统的其他方面无关。例如，一个环境可以选择或不选择支持动态类元，即对象具有在运行时改变所属类的能力。现在，许多程序设计语言不允许这么做，主要是因为程序设计语言的实现方面的原因，但有些语言实现了这一功能。在静态语义中这种区别是不能辨认的。选择静态分类还是动态分类可以用一个具有两个选项（静态分类或动态分类）的语义变更点来标明。当这些选择存在时，人们经常辩论哪一种是正确的解释。相反，如果明确了这仅仅只是一种选择，并给选项起一个名字，这样任何一种选择都可以使用。 

　　元模型描述一个结构良好的模型的内容，正如一种程序设计语言描述一个结构良好的程序一样。只有结构良好的模型才有意义和恰当的语义；询问一个结构糟糕的模型的意义是没有意义的。然而，多数开发中的模型的结构是不完善的。它们不完整并有可能相互矛盾。但是模型编辑工具必须支持不完整的模型，而不仅只支持完整的模型。 UML 元模型描述正确的、结构完善的模型。分离的元模型能描述可能的模型片段。我们让工具开发者决定在哪里划定支持模型片段的界限和支持结构不完善的模型用哪种语义。 

UML 包含一些内置的扩展机制以适应特殊领域的应用。这些机制包括定义构造型和标记值的能力。通过定义一组构造型和标记值并采用相应的使用约定，这些机制可以用于裁制 UML 的变体。例如，可以开发出以不同程序设计语言的执行语义为核心的 UML 变体语言。使用扩展机制会很有效，但也会带来潜在的危险。因为这些语义不是在 UML 中定义的， UML 不支持它们的含义，这种解释取决于建模者。此外，如果你不注意，某些含义可能是二义性的甚至是矛盾的。建模工具能够自动支持由工具定义的构造型和标记值，但不支持用户自定义的扩展。不论是否支持扩展，任何扩展的使用都会使用户偏离语言标准所提供标准定义，并损害模型的互换性和易理解性。当然，使用特殊的类库也会偏离所谓的最完美的互换性，所以不用担心这些。当扩展有帮助时就使用，但当扩展不必要时则避免使用它。 

 

原文转自：http://www.ltesting.net