For GraphNodes, an optional size can be provided using the DataType Dimension, which encapsulates width and height of type double. None of these are allowed to be negative. If the size is not given, it is determined by its semantic model and the nested DiagramElements within this GraphNode. The following two cases are to be considered:
1. If the semantic model indicates that a graphical representation for the given GraphNode is necessary, its size must be
calculated from its nested DiagramElements. For example, if not given, the size of a GraphNode representing a class must be determined by recursively examining the extent of the contained compartments. If the size of a compartment is not given, its contained DiagramElements, e.g., attributes, must be analyzed and so on.
2. If the semantic model indicates an Element of the semantic model with no or a fixed graphical representation, this
calculation is not necessary. An example for such a case is an AssociationEnd. Although, for example, GraphNodes containing TextElements for multiplicity and role name may be nested as contained into such a GraphNode, the Asso-ciationEnd's GraphNode itself has no size--it is simply being used as a container. Even if the AssociationEnd is visi-ble in a sense, e.g., a filled rhombus to indicate a composition, this is considered a fixed graphical representation which therefore does not have an extent.
The general rendering order of DiagramElements is defined through the following two mechanisms:
1. The nesting tree of DiagramElements within GraphElements has the highest priority. To render the Diagram Elements, the tree is processed using a preorder traversal. This means that the most deeply nested DiagramElement of a path is drawn last and thus is shown on top in z-order.
2. The ordered association container--contained between GraphElement and DiagramElement--specifies the rendering
sequence of DiagramElements contained within the same GraphElement. The first DiagramElement is drawn first, the second next, and so on.
There is a less common situation in which this straightforward rendering concept alone is not sufficient. LeafElements are employed to enrich a diagram with elements not belonging to UML. It may be useful to show such a LeafElement as a background for more than one GraphElement. An example for this case is an ellipse which is drawn through an Image. The ellipse contains two classes A and B from two different packages a and b, while being drawn on top of the two packages. Figure 8 illustrates this situation.
Rendering Figure 8 is impossible with the two mechanisms described above, since any DiagramElement, i.e., the Image, may only be part of a single path in the tree of DiagramElements. In order to be shown in this way, it must be part of both paths. To accomplish this, the Reference is used. The Image is included in a single path as a DiagramElement. For any other path in which it is wanted to be displayed, a Reference is included. Its reference points to the Image which indicates that it is part of both paths and is being rendered accordingly.