UML之图框架标题类型之谬

在UML中，我们可以用一个被称为“框架”的边界框围绕着UML图形，当然在很多情况下，框架可以省略，也就是不将它描画出来。但是对于某些图形类型而言，框架具有语义意义，在这些图形类型中，图形元素可以放置在框架之内或跨越框架边界以表示不同的含义。因此在这些图形类型中，使用框架是必要的，以便可以表达某些特定的含义。除了这个目的之外，其他情况下是否使用框架通常由建模者自行决定。

当我们决定使用框架时，我们需要为框架设定一个“框架标题”，框架标题是当前图形的名字。

框架标题位于框架的左上角，它书写于一个被砍掉了右下角的矩形而形成的不规则五边形内，如下图所示。



框架标题的命名并不是随意的，而是有其命名规则，它由两个可选部分与一个必选部分组成：[][]

其中可选的kind值应为下列值之一：activity（或act）、class、component（或cmp）、deployment（或dep）、interaction（或sd）、package（或pkg）、state machine（或stm）、use case（或uc）。

自然而然地，我们会认为kind表明了图形的类型。例如，在下图中，它描画了一个actor和两个use case，不出意外的话，你会将它的kind选择为use case（或者uc）。然而，不幸的是，这是错误的。



事实上，由于一组use case通常应当属于一个包（如果你没有意图让这些use case隶属于某个特定的包，那它们将自动隶属于一个被称为“默认包”的包），而描画的这一组use case是在说明“当前包”中有哪些use case，其kind应当是package（或pkg）。所以正确的图形应当如下图所示。



我们可以更进一步地考虑更多的图形所在框架标题kind值的选择设定。通常对于大多数结构图（structure diagram）和用例图（use case diagram）而言，其kind都应当被设定为package（或pkg）；而对于行为图（behavior diagram）则一般使用与图形匹配的类型，但它依然有一个令人迷惑的地方需要注意，即所有的交互图（interaction diagram，包含时序图sequence diagram、时序时态图timing diagram、交互总览图interaction overview diagram、通信图communication diagram）框架标题的kind应被设定为sd。

准确选择框架标题的kind值，关键点在于要理解当前框架所包含的图的真正含义是什么。例如上例中“描画了一个actor和两个use case”的图形，它描述的是一组use case及一个actor与它们的关联，所以这个图形并不是用来描述单个use case的，它描述的是“一组在一起”的use case，因此其框架标题kind也就不能是use case（或者uc），相反它应当是容纳这一组use case的“包”，所以其kind应为package（或pkg）。

如果上面的说明还是不能清晰说明框架标题kind如何选择，我们可以看另外一个更明确的例子。

假设当前我们需要用图描绘类Car，这个图将只描绘与类Car的定义相关的内容，也就是类Car的内部信息。类Car可能的一个描绘不完整地图如下：



由于上图的目的就是描述类Car的，图中的所有元素是属于类Car的，因而，上图框架标题的kind应当被设定为class。

假设在另外一张图中，它包含了类Car，如下图所示。图中类Car作为一个元素呈现而不是图的全部内容（在这张图中描绘类Car时，如果类Car已在其他地方单独描画，则可以省略类Car的细节，仅保留类名称Car及类的图形即可）。如果需要，图中还可以有类Car的一个实例或多个实例，或者也可添加其他元素，它们共同被容纳在一个包中，因此这张图的框架标题kind应设定为package（或pkg）。



而行为图的框架kind值之所以一般使用与图形匹配的类型，其原因在于一个行为图所描述的就是当前的“那个”行为，而不是“一组”行为，故其框架标题类型应与当前行为图匹配。

参考文献：

1.《OCUP 2 Certification Guide_ Preparing for the OMG Certified UML 2.5 Professional 2 Foundation Exam》 Michael Jesse Chonoles

2.《OMG Unified Modeling Language (OMG UML) Version 2.5.1》