12.1 概述
UML 模型被用在环境中使用。多数人使用建模技术为了达到一个目的，即为了开发性能优良的系统，而不是为了使用模型本身。模型的目的和对模型的解释也受环境之外的因素影响。在广阔的外部环境中，另一些工具包括：跨越多种语言的元模型、模型编辑工具、程序设计语言、操作系统和主系统构件以及那些使用系统的商业和工程背景。确定模型的意义和使用目的取决于所有这些工具，其中也包括UML语言。
模型在不同的具体层次中出现。UML 是一种通用建模语言，包括语义和表示法，适用于不同的工具和实现语言。应用中的每个层次需要使用不同层次的UML建模思路。
12.2 语义职责
元模型是对模型的一种描述。建模语言描述模型，因此，它可以用元模型描述。元模型试图通过定义语义使语言精确，但是为适应新情况它必须允许扩展。元模型的实际形式对于用工具实现模型和模型的互换很重要，但多数用户并不关心它。因此，我们在本书中未涉及到它。对此有兴趣的读者可以参阅配套光盘上的原始标准文献[UML-98]。
元模型和语言必须能够覆盖多大的背景信息并具有很强的解释力。现存系统有不同的执行和存储模型，从中选择一种作为正确的解释是不可能的。实际上，甚至考虑这样的选择都可能产生误导。我们可以将执行模型的不同解释作为语义变更点。语义变更点是一个随执行的具体语义而不同的点，但它与系统的其他方面无关。例如，一个环境可以选择或不选择支持动态类元，即对象具有在运行时改变所属类的能力。现在，许多程序设计语言不允许这么做，主要是因为程序设计语言的实现方面的原因，但有些语言实现了这一功能。在静态语义中这种区别是不能辨认的。选择静态分类还是动态分类可以用一个具有两个选项（静态分类或动态分类）的语义变更点来标明。当这些选择存在时，人们经常辩论哪一种是正确的解释。相反，如果明确了这仅仅只是一种选择，并给选项起一个名字，这样任何一种选择都可以使用。
元模型描述一个结构良好的模型的内容，正如一种程序设计语言描述一个结构良好的程序一样。只有结构良好的模型才有意义和恰当的语义；询问一个结构糟糕的模型的意义是没有意义的。然而，多数开发中的模型的结构是不完善的。它们不完整并有可能相互矛盾。但是模型编辑工具必须支持不完整的模型，而不仅只支持完整的模型。UML元模型描述正确的、结构完善的模型。分离的元模型能描述可能的模型片段。我们让工具开发者决定在哪里划定支持模型片段的界限和支持结构不完善的模型用哪种语义。
UML包含一些内置的扩展机制以适应特殊领域的应用。这些机制包括定义构造型和标记值的能力。通过定义一组构造型和标记值并采用相应的使用约定，这些机制可以用于裁制UML的变体。例如，可以开发出以不同程序设计语言的执行语义为核心的UML变体语言。使用扩展机制会很有效，但也会带来潜在的危险。因为这些语义不是在UML中定义的，UML不支持它们的含义，这种解释取决于建模者。此外，如果你不注意，某些含义可能是二义性的甚至是矛盾的。建模工具能够自动支持由工具定义的构造型和标记值，但不支持用户自定义的扩展。不论是否支持扩展，任何扩展的使用都会使用户偏离语言标准所提供标准定义，并损害模型的互换性和易理解性。当然，使用特殊的类库也会偏离所谓的最完美的互换性，所以不用担心这些。当扩展有帮助时就使用，但当扩展不必要时则避免使用它。
12.3 表示法职责
表示法并不是给模型增加含义，而是帮助用户理解模型的含义。表示法没有语义，但它经常为用户加入一些内在涵义，如在一张图中基于相近意义的两个概念的密切联系。
UML文档[UML-98]和本书定义了一套规范的UML 表示法，可以称作模型的格式出版。这和许多程序设计语言类似，把期刊文章中的程序印刷成有吸引力的格式，包括仔细的规划、用黑体保留字表示的，且每个过程用不同的图形来说明。而实际的编译者不得不接受较为凌乱的输入。我们期望编辑工具能把表示法扩展成屏幕格式，包括诸如使用不同的字体和颜色加亮条目，简单地删除和过滤不需要使用的条目的能力，放大图像以展示图中的嵌套元素的能力，通过超文本热链转入其他模型和视图的能力，以及动画功能。试图将所有这些可能的项目都标准化是不可能的，也是愚蠢的，因为没有这个必要，而且这样还会限制有益的创新。这种表示法的扩展能力是工具制造者的工作。在交互式工具中，产生二义性的危险不大，因为用户总能找到一个明确的解释。这也许比坚持一种粗看上去没有任何二义性的表示法更有用。这个观点是说：当需要时，一个工具必须能生成规范化的表示法，特别是在印刷格式中，但在使用交互式工具中也应该采用合理的扩展。
我们仍期望工具能让用户有限制但又有效地扩展表示法。我们已经规定构型型可以有自己的图标。对其他的表示法的扩展也是允许的，但用户要谨慎使用这些扩展机制。
注意，表示法不仅仅是图片，它还包括基于文本格式的信息和元素中间不可见的超链接。
12.4 程序语言职责
UML 必须在没有与不同的实现语言明确地合并时与它们共同使用。我们认为 UML应该允许任何程序设计语言（至少是多数）的使用，包括规格说明和目标代码生成。问题是每种程序设计语言都存在许多我们不想吸收到UML中的语义，因为它们作为程序设计语言来说很好控制，而在执行语义中有相当大的变化。例如，并发的语义在不同的语言中存在不同的处理方法（如果能够处理这些语义）。
UML中没有详细地描述简单数据类型，这么做是经过深思熟虑的，因为我们不想把我们偏爱的一种程序设计语言的语义合并到其他所有语言中。对于多数的建模目的，这不是一个问题。应使用适合于你的目标语言的语义模型。这是语义变更点的一个例子。
详尽的语言实现特性的表示使得在不把实现特性的语义内置到UML的情况下，带来了捕获其信息的问题。我们的方法是通过构造型和标记值捕获超越了UML内置能力的语言特性，这些可以由工具或代码生成器分配给语言给性和代码生成选项。一般的编辑器不需要理解它们。事实上，用户可以用一个不支持目标语言的工具创建一个模型，然后把最终模型转换到适用于最终处理的工具。当然，如果工具不能理解构造型和标记值，那么它不能对它们进行一致性检查。但这并不比用文本编辑器和编译器差。如果必要，可以创建一个工具来使用UML语言的一组特定的扩展。
在可预知的未来，代码生成和逆向转换不仅需要UML模型，还需要设计者的输入信息。代码生成器需要的指导和提示可以由标记值和构造型提供。例如，建模者可以指定哪种包容器类用于实现一个关联。当然，这种工具中的代码生成设置方法也许是矛盾的，但目前没有一种标准化的实际设置方法。目前不同的工具均使用对自己有竞争优势的代码生成器，但最终将会出现缺省设置并发展为成熟的标准。
12.5 使用建模工具建模
在实际的系统中模型需要工具支持，工具提供了观察和编辑模型的交互方式。工具提供了一层超出UML自身作用域的组织，可以帮助用户理解并获得信息。通过搜索和过滤已经存在的资料，工具有助于在大型模型中查找信息。
12.5.1 工具问题 工具处理模型的物理组织和存储。它必须支持一个项目的若干工作组同时工作，以及支持跨越多个项目的重用。以下几点问题超出了规范的UML 的作用域，但在运用实际工具中必须予以考虑。
＊ 二义性和未详尽说明的信息 在初期阶段，许多事物不能用语言表达。工具必须能够调整模型的精确性并且不能强迫每个值都要进行详细说明。可参看以下两小节。
＊ 表示选项 用户不想在任何时候都看到所有的信息。工具必须能够过滤和隐藏那些某一时间不需要的信息。工具还要通过显示器硬件的功能提供交替的可视化支持。这一点已经在12.3节讲过了。
＊ 模型管理 模型单元的配置控制、访问控制和版本超出了UML的作用域，但是它们对于软件工程过程十分重要，并且位于元模型的上层。
＊ 与其他工具的接口 模型需要由代码生成器、规格计算机、报表书写器、执行引擎和其他后台工具处理。其他工具所需要的信息要包含到模型中，但这不是UML信息。标记值适合保存这些信息。
12.5.2 工作进展过程中产生的不一致模型 建模的最终目标是生成一定细化层次的系统描述。最后的模型必须满足不同的有效性约束才有意义。但是，正如许多创造性的过程一样，结果不必以线性方式产生，中间产品不必每一步都满足所有的有效性约束。实际上，一个工具不仅要处理语义上满足有效性约束的模型，还要处理在句法上有效的模型，这些模型满足一定的构造规则但可能会违背一些有效性约束。语义上无效的模型不能直接使用。相反，它们可以看作是通向最终目标的进展中的工作。
12.5.3 空值和未详细说明的值 一个完整的模型包含了它的所有元素的所有属性值。在许多情况下空值（无值）是一种可能出现的值，一个值是否可能为空是属性类型描述的一部分。例如，空值对集合大小的上 限没有意义。有的集合有固定的大小，有的则没有固定的上限值，在这种情况下，集合的大小是无限的，所以具有空值与否实际上取决于一种数据类型的可能值的范围。
另一方面，在设计的早期，开发者也许没有注意到特殊特性的值。在特定的阶段，这个值可能没有意义，如建立领域模型时的可视性。或者，这个值有含义但建模者还未详细说明它，开发者应当记住它仍然需要细化。这种情况下，这个值是没有详尽说明的，这表示一个值最终是需要的但目前还没有被详细说明。它和空值不同，空值在最终模型里是合法值。许多情况下，特别是字符串中，空值是表示一个未被详尽说明的值的好方法，但并非全是这样。未被详细说明的值在结构完善的模型中是无意义的，UML定义不处理没有详细说明的值。这是支持UML的工具的
本文地址：http://com.8s8s.com/it/it2080.htm