--- title: "B.4 Diagram Interchange" chapter: "Annex B — Diagram Interchange" source: "OMG BPMN 2.0.2 — formal/2013-12-09" pages: "487-497" --- > Annex B — Diagram Interchange · páginas 487-497 · [índice](../README.md) ## B.4 Diagram Interchange The Diagram Interchange (DI) package contains a model enabling interchange of graphical information that language users have control over, such as position of nodes and line routing points. Language specifications specialize elements of DI to define diagram interchange for a language. ### B.4.1 Overview The Diagram Interchange (DI) package contains a number of types used in the definition of diagram interchange models. The package imports the Diagram Common package (see “Diagram Common” on page 483), as shown in Figure B.5, that contains various relevant data types. The DI package contains mainly abstract types that are to be properly extended and refined by concrete types in domain-specific DI packages. In this sense, the DI package plays the role of a framework that is meant for extension rather than a component that is ready to be used out of the box. The benefit of this design is capture common assumptions in the DI package in order to facilitate the integration between various graphical domains that define their DI packages as extensions. Diagrams are generally considered depictions of part or all of the elements in a domain-specific model. Therefore, one of the best practices adopted in the design of the DI package and that can be subsumed by the extending domain-specific DI packages is to minimize any redundancy with the depicted model when possible. For example, the text representing the name of a UML class is not defined as part of the UML class shape. This is primarily achieved by the fact that diagram elements reference their counterparts in the domain model as their context model elements instead of duplicating data from them. This design has the side effect of coupling the diagram models with their corresponding domain models, which is generally a common practice by tools. However, the DI package does not enforce this best practice and domain-specific DI packages can decide to have some level of duplication to decouple the models. Another best practice adopted by the DI package is to avoid defining any data that is not changeable by the user but is rather derivable from the diagram’s model context, like graphical rendering details. For example, the option to render a UML actor as a stick man or a as rectangle can be defined in a DI model as a boolean property to allow a user to choose between them. However, the definition of the actual line segments making up such shapes need not be interchanged in a DI model as it can be defined in the tool itself. Other decisions that are left to the individual domain-specific DI packages include: whether to allow 1-n vs. m-n relationships between the domain elements and their referencing diagram elements, the formatting properties (styles) that affect the aesthetics of diagrams rather than their semantics that are allowed to be interchanged, and the degree of pragmatic redundancy that is allowed in the DI models to balance their footprint with the ease of their import/export. ### B.4.2 Abstract Syntax **Figure B.5 – Dependencies of the DI package** **Figure B.6 – Diagram Element** **Figure B.11 – Labeled Edge** **Figure B.12 – Labeled Shape** ### B.4.3 Classifier Descriptions #### B.4.3.1 Diagram [Class] Diagram is a container of a graph of diagram elements depicting all or part of a model. #### Description Diagram represents a depiction of all or part of a MOF model. A model can have one or more diagrams, each of which has a name and a description. A diagram contains the root of a graph of diagram elements that could reference various elements in a model. The root element is defined as a derived union, allowing domain-specific diagrams to specialize the root. All lengths specified by diagram elements are expressed in logical units of lengths. This unit of length would map to a unit of screen resolution (i.e., pixel) when rendering to the screen. To allow for predictable lengths when printing diagrams to paper, a diagram can also specify an intended printing resolution in Unit Per Inch (UPI). For example, a UPI of 300 means that a diagram element that is 300 unit wide would print as 1 inch wide on paper. A diagram can also own a collection of styles that are referenced by its diagram elements. Styles contain unique combination of formatting properties used by different elements across the diagram. This allows for a large number of diagram elements to reference a small number of unique styles, which would dramatically reduce a diagram’s footprint. #### Abstract Syntax - Figure B.9 Diagram #### Attributes - + name : String [0..1] - + documentation : String [0..1] - + resolution : Real [0..1] the printing resolution of the diagram expressed in Unit Per Inch (UPI). #### Associations - ? + /rootElement : DiagramElement [1] {readOnly, union} - ? + /ownedStyle : Style [*] {readOnly, union} #### B.4.3.2 DiagramElement [Class] DiagramElement is the abstract supertype of all elements that can be nested in a diagram. It has two subtypes: Node and Edge. #### Description DiagramElement specifies an element that can be owned by a diagram and rendered to graphics. It is an abstract class that is further specialized by classes Node and Edge. A diagram element can either depict (reference) another context model element from an abstract syntax model (like UML or BPMN) or be purely notational (i.e., for enhancing the diagram understanding). In the case of depiction, data from both the diagram element and the model element are used for rendering. For example, the text of the name label of a UML class shape comes from the class, while the color of the label comes from the diagram element. A diagram element can reference a maximum of one model element, which can be any MOF-based element. The model element reference is a derived union and can be specialized in a domain-specific DI metamodel to be of a more concrete type. Diagram elements can also own other diagram elements in a graph-like hierarchy. The collection of owned diagram elements is defined as a derived union. Domain-specific DI metamodels can specialize this collections to define what other diagram elements can be nested in a given diagram element. Diagram elements can be specialized in a domain-specific DI metamodel to have domain-specific properties. Some of those properties augment the semantics of diagram elements and are therefore defied on the diagram elements. Other properties are considered formatting properties that influence the visual rendering of diagram elements but do not contribute to their semantics. Examples of such formatting properties include font, fill and stroke properties. Such properties tend to have similar values for diagram elements across the diagram and therefore to reduce the footprint of diagrams, they are defined in Style elements that are owned by the diagram and referenced by individual diagram elements. For every unique combination of values for the style properties there would be a separate style element that is owned by the diagram. See “DiagramElement [Class]” on page 491 for more details. There shall always be other properties that some tools wish to interchange that cannot be made normative. These can be interchanged using the extensibility mechanism that is native to the used interchange format (for example, an XSD schema following the XMI mapping would allow extraneous data to be placed on elements within tags, while a different XSD schema could allow this through xsd:any and xsd:anyAttribute elements placed in the definitions of extensible complex types). #### Abstract Syntax - Figure B.6 Diagram Element - Figure B.7 Node - Figure B.8 Edge - Figure B.9 Diagram - Figure B.10 Plane #### Specializations - Node - Edge #### Associations - + /owningDiagram : Diagram [0..1] {readOnly, union} - + /owningElement : DiagramElement [0..1] {readOnly, union} - ? + /ownedElement : DiagramElement [*] {readOnly, union} - + /modelElement : Element [0..1] {readOnly, union} - + /style : Style [0..1] {readOnly, union} #### B.4.3.3 Edge [Class] Edge specifies a given edge in a graph of diagram elements. It represents a polyline connection between two graph elements: a source and a target. #### Description Edge represents a given connection between two elements in a diagram, a source element and a target element. An edge often references a relationship element (like a UML generalization or a BPMN message flow) as a context model element. It can also be purely notational, i.e., does not reference any model element. When referencing a relationship model element, the edge’s source and target reference the relationship's source and target respectively as their model elements. If the edge’s source and target can be derived unambiguously from other info (like the edge’s model element or the edge’s class type), they are not explicitly set on the edge to avoid redundancy, otherwise they need to be set. The source and target are defined as derived unions to allow domain-specific DI metamodels to specialize them appropriately. An edge is often depicted as a line with 2 or more points (i.e., one or more connected line segments) in the coordinate system, called waypoints. The first point typically intersects with the edge’s source, while the last point typically intersects with the edge’s target. Any points in between establish a route for the line to traverse in the diagram. #### Abstract Syntax - Figure B.8 Edge - Figure B.11 Labeled Edge #### Generalizations - DiagramElement #### Specializations - LabeledEdge #### Attributes - + waypoint : Point [2..*] {ordered, nonunique} #### Associations - + /source : DiagramElement [0..1] {readOnly, union} - + /target : DiagramElement [0..1] {readOnly, union} #### B.4.3.4 Label [Class] Label represents a node that is owned by another main diagram element in a plane and that depicts some (usually textual) aspect of that element within its own separate bounds. #### Description Label represents an owned node of another diagram element, typically a LabeledShape or a LabeledEdge. A label typically depicts some (usually textual) aspect of its owning element that needs to be laid out separately using the label’s own bounds. The bounds are optional and if not specified, the label will be positioned in its default position. A label’s model element is typically not specified as it can be derived from its owning element. However, if the model element cannot be unambiguously derived, then a label could be given ts own separate model element to disambiguate it. #### Abstract Syntax - Figure B.11 (Labeled Edge) - Figure B.12 Labeled Shape #### Generalizations - Node #### Attributes - + bounds : Bounds [1] #### B.4.3.5 LabeledEdge [Class] LabeledEdge represents an edge that owns a collection of labels. #### Description LabeledEdge is an edge that owns a collection of labels (see “LabeledEdge [Class]” on page 494) that depict some aspects of it. An example is a UML association that has a number of labels (e.g., a name label, two role name labels and two multiplicity labels) positioned beside it. The existence of a label in this collection specifies that it is visible. The separate optional bounds of the label indicate where it should be positioned and if not specified the label can be positioned in its default position. #### Abstract Syntax - Figure B.11 Labeled Edge #### Generalizations - Edge #### Associations - ? + /ownedLabel : Label [*] {readOnly, union, subsets ownedNode} #### B.4.3.6 LabeledShape [Class] LabeledShape represents a shape that owns a collection of labels. #### Description LabeledShape is a shape that owns a collection of labels (see “LabeledShape [Class]” on page 494) that depict some aspects of it. An example is a UML port shape that is rendered as a filled box and has a name label positioned beside it. The existence of a label in this collection specifies that it is visible. The separate optional bounds of the label indicate where it should be positioned and if not specified the label can be positioned in its default position. #### Abstract Syntax - Figure B.12 Labeled Shape #### Generalizations - Shape #### Associations - ? + /ownedLabel : Label [*] {readOnly, union, subsets ownedNode} #### B.4.3.7 Node [Class] Node specifies a given node in a graph of diagram elements. #### Description Node represents a given node (or vertex) in a diagram, which is a graph of diagram elements. A node often references a non-relationship element (like a UML class or a BPMN activity) as a model element. It can also be purely notational, i.e., does not reference any model element. The abstract node class does not have any particular layout characteristics. However, it may gets specialized in a domain-specific DI metamodel to define nodes that have certain layout characteristics. Examples include planes with infinite bounds, shapes with limited bounds, tree items and graph vertices...etc. #### Abstract Syntax - Figure B.7 Node - Figure B.10 Plane - Figure B.11 Labeled Edge - Figure B.12 Labeled Shape - Figure B.13 Shape #### Generalizations - DiagramElement #### Specializations - Label - Shape - Plane #### B.4.3.8 Plane [Class] Plane is a node with an infinite bounds in the x-y coordinate system that owns a collection of shapes and edges that are laid out relative to its origin point. #### Description Plane has an origin point (0, 0) and an infinite size along the x and y axes. The coordinate system of the plane increases along the x-axis from left to right and along the y-axis from top to bottom. All the nested shapes and edges are laid out relative to their plane’s origin. A plane is often chosen as a root element for a two dimensional diagram that depicts an inter-connected graph of shapes an edges. A plane may have its own reference to a model element, in which case the whole plane is considered a depiction of that element. Alternatively, a plane without a reference to a model element is simply a layout container for its shapes and edges. The collection of plane elements (shapes and edges) in a plane is ordered with the order specifying the z-order of these plane elements relative to each other. The higher the z-order, the more to the front (on top) the plane element is. #### Abstract Syntax - Figure B.10 Plane #### Generalizations - Node #### Associations - ? + planeElement : DiagramElement [*] {subsets ownedNode} #### B.4.3.9 Shape [Class] Shape represents a node that has bounds that is relevant to the origin of a containing plane. #### Description Shape represents a node that is directly or indirectly owned by a plane (See “Shape [Class]” on page 496.) and that is laid out according to a given bounds that is relevant to the origin of the plane. A shape does not have any particular graphical rendering, i.e., the rendering is domain-specific. A shape can be purely notational (i.e., does not reference any model element), like a block arrow pointing to a UML class shape with some textual message or an overlay rectangle with some transparent fill enclosing a bunch of shapes on the diagram to make them stand out. However, a shape often represents a depiction of a non-relational element from a business model (like UML class or BPMN activity) and hence references such an element as its model element. #### Abstract Syntax - Figure B.13 Shape - Figure B.12 Labeled Shape #### Generalizations - Node #### Specializations - LabeledShape #### Attributes - + bounds : Bounds [1] #### B.4.3.10 Style [Class] A style is a container for a collection of properties that affect the formatting of a set of diagram elements rather than their structure or semantics. #### Description A style represents a bag of properties that affect the appearance of a group of diagram elements. A style property (like font, fill, or stroke) is distinguishable from a property on a diagram element in that it is meant for the aesthetics of the element rather than being part of its intrinsic syntax. A style tends to have only a few unique value combinations for its properties across the diagram. Such combinations are represented by different style instances owned by the diagram and referenced by the diagram elements. This allows for conserving the footprint of diagrams (over making style instances owned by diagram elements). Style is defined as an abstract class without prescribing any style properties to leave it up to domain-specific DI metamodels to define concrete style classes that are applicable to their diagram element types. #### Abstract Syntax - Figure B.6 Diagram Element - Figure B.9 Diagram