表示法并不是给模型增加含义，而是帮助用户理解模型的含义。表示法没有语义，但它经常为用户加入一些内在涵义，如在一张图中基于相近意义的两个概念的密切联系。
　　 UML文档[UML-98]和本书定义了一套规范的UML 表示法，可以称作模型的格式出版。这和许多程序设计语言类似，把期刊文章中的程序印刷成有吸引力的格式，包括仔细的规划、用黑体保留字表示的，且每个过程用不同的图形来说明。而实际的编译者不得不接受较为凌乱的输入。我们期望编辑工具能把表示法扩展成屏幕格式，包括诸如使用不同的字体和颜色加亮条目，简单地删除和过滤不需要使用的条目的能力，放大图像以展示图中的嵌套元素的能力，通过超文本热链转入其他模型和视图的能力，以及动画功能。试图将所有这些可能的项目都标准化是不可能的，也是愚蠢的，因为没有这个必要，而且这样还会限制有益的创新。这种表示法的扩展能力是工具制造者的工作。在交互式工具中，产生二义性的危险不大，因为用户总能找到一个明确的解释。这也许比坚持一种粗看上去没有任何二义性的表示法更有用。这个观点是说：当需要时，一个工具必须能生成规范化的表示法，特别是在印刷格式中，但在使用交互式工具中也应该采用合理的扩展。
　　 我们仍期望工具能让用户有限制但又有效地扩展表示法。我们已经规定构型型可以有自己的图标。对其他的表示法的扩展也是允许的，但用户要谨慎使用这些扩展机制。
注意，表示法不仅仅是图片，它还包括基于文本格式的信息和元素中间不可见的超链接。

· 程序语言职责

UML 必须在没有与不同的实现语言明确地合并时与它们共同使用。我们认为 UML应该允许任何程序设计语言（至少是多数）的使用，包括规格说明和目标代码生成。问题是每种程序设计语言都存在许多我们不想吸收到UML中的语义，因为它们作为程序设计语言来说很好控制，而在执行语义中有相当大的变化。例如，并发的语义在不同的语言中存在不同的处理方法（如果能够处理这些语义）。
　　 UML中没有详细地描述简单数据类型，这么做是经过深思熟虑的，因为我们不想把我们偏爱的一种程序设计语言的语义合并到其他所有语言中。对于多数的建模目的，这不是一个问题。应使用适合于你的目标语言的语义模型。这是语义变更点的一个例子。
　　 详尽的语言实现特性的表示使得在不把实现特性的语义内置到UML的情况下，带来了捕获其信息的问题。我们的方法是通过构造型和标记值捕获超越了UML内置能力的语言特性，这些可以由工具或代码生成器分配给语言给性和代码生成选项。一般的编辑器不需要理解它们。事实上，用户可以用一个不支持目标语言的工具创建一个模型，然后把最终模型转换到适用于最终处理的工具。当然，如果工具不能理解构造型和标记值，那么它不能对它们进行一致性检查。但这并不比用文本编辑器和编译器差。如果必要，可以创建一个工具来使用UML语言的一组特定的扩展。
　　 在可预知的未来，代码生成和逆向转换不仅需要UML模型，还需要设计者的输入信息。代码生成器需要的指导和提示可以由标记值和构造型提供。例如，建模者可以指定哪种包容器类用于实现一个关联。当然，这种工具中的代码生成设置方法也许是矛盾的，但目前没有一种标准化的实际设置方法。目前不同的工具均使用对自己有竞争优势的代码生成器，但最终将会出现缺省设置并发展为成熟的标准。