Issues for Mailing list of the Diagram Definition Finalization Task Force
To comment on any of these issues, send email to dd-ftf@omg.org. (Please include the issue number in the Subject: header, thusly: [Issue ###].) To submit a new issue, send email to issues@omg.org.
List of issues (green=resolved, yellow=pending Board vote, red=unresolved)
Issue 15902: Simplify DI metamodel
Issue 15994: The Diagram metaclass should be abstract
Issue 15995: Waypoints should be optional
Issue 15996: Bounds should be optional
Issue 15997: Diagram::resolution default
Issue 16001: Interchange extension
Issue 16250: DG::GraphicalElement::local/sharedStyle should have unbounded upper multiplicity
Issue 16251: Rename DG::Canvas::style to packagedStyle
Issue 16252: Cascade specification in DG isn't as specific as DI
Issue 16371: Merge DI diagrams
Issue 16372: Update Annex A
Issue 16386: MOF Compliance
Issue 16387: Owning styles
Issue 16388: Cascading called inheritance
Issue 16389: Optional bounds
Issue 16390: Annex B
Issue 16392: Optional waypoints
Issue 16408: Spurious question marks
Issue 16409: Visibility markers not needed
Issue 16410: Collections => sets
Issue 16485: Diagram description
Issue 15902: Simplify DI metamodel (dd-ftf)
Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary: The DI metamodel can be simplified by removing
planes (diagrams can be nested) and leaving
packaging out of scope (DiagramCollection, and
the association between Diagram and Style).
Resolution: The DI metamodel is simplified by merging planes and plane elements into diagrams and diagram elements, respectively, and removing labels and diagram collections
Planes are removed. These were to support nested diagrams, but it was decided the additional layer of terminology wasn't necessary, especially when some communities simply call them "nested diagrams". In the revised text, diagrams can be nested. Top level diagrams are those diagrams that happen not to be nested. We discussed various possibilities for modeling this, and settled on treating everything as a nestable diagram element, including diagrams, which are taken as a kind of shape. This means diagrams can have model elements, for example, as in UML composite structure. Top level diagrams won't use bounds. Diagrams can be connected by edges, for diagrams of diagrams.
Labels are removed. The only difference from shapes is they are rendered as strings, which would often be determined by the mapping to DG. Language-specific DI's can define these as kinds of shapes if needed.
It was decided that packaging should be out of scope, because domain languages usually have their own packaging mechanisms, resulting in these changes:
The existing association between Diagram and Style is removed, because it was only packaging styles, it didn't mean styles applied to the diagram, like the association between DiagramElement and Style, which Diagram now inherits.
DiagramCollection is removed, and its packaging associations to Style.
Packaging of styles is left in Diagram Graphics, because DG is not intended to extend a domain language that might have its own packaging mechanism.
Updates to the Annexes for these changes will be addressed in separate issues.
Revised Text: Move Figure 9.6 (Shape) to above Figure 9.3 (Diagram), and replace the image with
In the original Figure 9.3 (Diagram), replace the image with
Remove the original Figure 9.4 (Plane).
In the original Figure 9.5 (Edge), caption, replace “PlaneElement” with “DiagramElement”, and change the multiplicity of Edge::waypoint to [*].
In Section 9.3.1 (Diagram)
First sentence
Replace “is a” with “is an abstract”.
Remove “that is rooted with a plane”.
After the first sentence, add a new sentence “Diagrams are diagram elements with an origin point in the x-y coordinate system. Their elements are laid out relative to their origin point.”
Description
Remove the first paragraph.
Second paragraph
Replace the first sentence with “A diagram does not need to be nested.”
Last sentence, remove “by a DiagramCollection element (see section 9.3.2)”.
After the second paragraph, insert the following three paragraphs, adapted from the text removed from Plane and PlaneElement, see below:
“A diagram represents a two dimensional x-y coordinate system that is used to layout nested and inter-connected diagram elements. A diagram has an origin point (0, 0) on the x and y. The coordinate system of a diagram increases along the x-axis from left to right and along the y-axis from top to bottom. All the nested diagram elements are laid out relative to their nesting diagram's origin.
As a kind of diagram element, a diagram may reference a model element from an abstract syntax model, in which case the whole diagram is considered a depiction of that element (e.g. an activity diagram is a depiction of a UML activity). Alternatively, a diagram without such a reference is simply a layout container for its diagram elements (e.g. a class diagram is a container for UML class shapes and edges).
The collection of nested elements in a diagram is ordered and the order specifies the z-order of these diagram elements relative to each other. The higher the z-order, the more to the front (i.e. the more visible) the diagram element is. The z-order of a nested diagram element is higher than the z-order of its nesting element.”
Original third paragraph, first sentence, replace “description” with “documentation”.
Last paragraph
First sentence
remove “a collection of”
At end of the sentence, insert “(see section 9.3.3)” with “9.3.3” updated to the section number for DiagramElement.
Last sentence, replace “diagram elements” with “elements in a diagram”.
Abstract Syntax, first bullet, update figure number for reordering of metamodel figures above.
Before Attributes subsection, insert new subsection with title “Generalizations” containing one bullet before the word “Shape”.
Remove the Associations subsection.
Remove Section 9.3.2 (DiagramCollection).
In 9.3.3 (DiagramElement)
First sentence
Replace “that can be nested in a diagram” with “in diagrams, including diagrams themselves”.
After the first sentence, insert a new sentence “When contained in a diagram, diagram elements are laid out relative to the diagram’s origin.”.
Description
Delete first paragraph.
Next to last paragraph, next to last sentence, replace “or even a diagram collection level” with “, or other diagram elements with nested elements,”.
Abstract Syntax subsection
Replace the text after the second bullet with “Figure 9.6 (Shape)”, with the figure number updated for reordering of metamodel figures above.
Add a third bullet, followed by the text “Figure 9.5 (Edge)” with the figure number updated for reordering of metamodel figures above.
Specializations subsection, replace the text after the first bullet with “Edge”, the text after the second bullet with “Shape”, and remove the third bullet.
Associations
Remove the last sentence in the text after the second bullet.
Remove “?” at the beginning of the text after the third and fourth bullets.
In 9.3.4 (Edge)
First sentence, replace each of the four occurrences of “plane” with “diagram”.
Description
First paragraph, replace each of the four occurrences of “plane” with “diagram”.
Second paragraph, replace the one occurrence of “plane” with “diagram”.
Abstract Syntax, first bullet, update figure number for reordering of metamodel figures above.
Generalizations, replace the text after the bullet with “DiagramElement”.
Attributes, in the text after the bullet
Remove “2..” from between the brackets.
Replace “plane” with “diagram”.
Associations, in both bullets:
After the colon, replace “PlaneElement” with “DiagramElement”
In the text after the hyphen, replace “plane” with “diagram”.
Remove Section 9.3.5 (Label).
Remove 9.3.6 (Plane). Some of its contents is moved to Diagram, see above.
Remove 9.3.7 (PlaneElement). Some of its contents is moved to Diagram, see above.
Section 9.3.8 (Shape)
First sentence, replace each of the two occurrences of “plane” with “diagram”.
Description
First paragraph
Remove the first sentence.
Second sentence, replace “It” with “Shape”.
Abstract Syntax, first bullet, update figure number for reordering of metamodel figures above.
Generalizations, replace text after the bullet with “DiagramElement”.
After Generalizations, insert new subsection titled “Specializations” with one bullet, followed by the text “Diagram”.
Attributes, first bullet, replace “1” with “0..1”.
Section 9.3.9 (Style)
First sentence, at end, insert “, including diagram themselves.”.
Description
First paragraph, first sentence, replace “Style represents a bag” with “A style is a set”.
Second paragraph
First sentence, replace “a diagram collection” with “other diagram elements with nested elements”.
Last sentence, after “concrete style classes” insert “with their own properties”.
Last paragraph, first sentence, after the colon, replace “oif” with “if”.
Abstract Syntax, remove the second bullet.
Actions taken:
December 15, 2010: received issue
January 11, 2012: closed issue
Discussion: figures on page 10 of ptc/2011-07-11
Issue 15994: The Diagram metaclass should be abstract (dd-ftf)
Click here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Clarification
Severity: Minor
Summary:
The other DI classes are abstract.
Resolution: Agreed that it should be abstract. This is addressed in the resolution to 15902.
Revised Text:
None
Disposition: Duplicate
Revised Text:
Actions taken:
January 31, 2011: received issue
January 11, 2012: closed issue
Discussion: The Diagram metaclass should be abstract
Issue 15995: Waypoints should be optional (dd-ftf)
Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary: Some tools might autoplace edge end points.
Resolution: Agreed that Edge::waypoints should be optional. This is addressed in the resolution to 15902.
Revised Text:
None
Disposition: Duplicate
Revised Text:
Actions taken:
January 31, 2011: received issue
January 11, 2012: closed issue
Issue 15996: Bounds should be optional (dd-ftf)
Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary: For example, as in compartmented property strings
Resolution: Agreed that Shape::bounds should be optional. This is addressed in the resolution to 15902.
Revised Text:
None
Disposition: Duplicate
Revised Text:
Actions taken:
January 31, 2011: received issue
January 11, 2012: closed issue
Issue 15997: Diagram::resolution default (dd-ftf)
Click here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Clarification
Severity: Minor
Summary: The default for Diagram::resolution should be shown in the metamodel figures.
Resolution: It is shown in Figure 9.3 (Diagram).
Revised Text:
None
Disposition: Closed, no change
Revised Text:
Actions taken:
January 31, 2011: received issue
January 11, 2012: closed issue
Discussion:
Issue 16001: Interchange extension (dd-ftf)
Click here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Enhancement
Severity: Significant
Summary: The last pagraph of the DiagramElement section says:
Other properties of diagram elements that tools need to interchange
but are not defined in the metamodel can be interchanged using the
extensibility mechanism that is native to the used interchange
format. For example, in an XMIbased interchange, extended data can be
placed on diagram elements within <xmi:extension> tags.
I'm not sure we should be mentioning interchange level extensions,
especially without mentioning metamodel extensions, and domain-specific
extensions like profiles. Can we remove this paragraph, or generalize
it to include other kinds of extension mechanisms?
Resolution: The specification should not suggest ways of interchanging non-standard information
Revised Text: In Section 9.3.3 (DiagramElement), Description, remove the fifth paragraph (the one starting “Other properties of diagram”).
Actions taken:
January 31, 2011: received issue
January 11, 2012: closed issue
Discussion:
Issue 16250: DG::GraphicalElement::local/sharedStyle should have unbounded upper multiplicity (dd-ftf)
Click here for this issue's archive.
Nature: Revision
Severity: Significant
Summary: DG::GraphicalElement::local/sharedStyle should have unbounded upper multiplicity, to enable DI and the mapping to DG to both introduce styles. The style properties from these two sources might overlap for properties with upper multiplicity greater than one. Use ordering to prioritize styles in case of conflict.
Resolution: Change the multiplicities as suggested above, and explain the use case.
Revised Text: In Figure 10.2 (GraphicalElement), replace the contents with:
In Section 10.3.10 (GraphicalElement),
Description, second paragraph,
First sentence, replace “a local and/or a shared style that defines” with “local and/or shared styles that define”.
Second sentence, replace “a local” with “local”, “a shared” with “shared”, and “style,” with “styles,”.
At the end of the paragraph, add a new sentence “If the same style property is set by multiple local styles or multiple shared styles, then the property on the style earlier in the ordering has higher precedence.”
Associations, replace the localStyle and sharedStyle entries with:
• + localStyle : Style [*] {ordered} - a list of locally-owned styles for this graphical element.
• + sharedStyle : Style [*] {ordered} - a list of shared styles for this graphical element.
In Section 10.3.31 (Style), Description, replace the first bullet under second paragraph with two bullets:
• If there is a cascading value set on a local style, use it. If the same value is set by multiple local styles, then use the value earlier in the style ordering.
• Otherwise, if there is cascading value set on a shared style, use it. If the same value is set by multiple shared styles, then use the value earlier in the style ordering.
In Section 10.3.11 (Group), Description, second sentence, replace “styles defined (owned or referenced)” with “(local or shared) styles defined.”
Actions taken:
May 17, 2011: received issue
January 11, 2012: closed issue
Discussion: figure on page 16 of ptc/2011-07-11
Issue 16251: Rename DG::Canvas::style to packagedStyle (dd-ftf)
Click here for this issue's archive.
Nature: Revision
Severity: Significant
Summary: Rename DG::Canvas::style to packagedStyle (and fills and markers) to clarify it is not applied to the canvas, like the one inherited from GraphicalElement::localStyle.
Resolution: Rename all the composite associations on Canvas to have a “packaged” prefix
Revised Text: In Figure 10.4 (Group Elements), replace the contents with
In Section 10.3.1 (Canvas), Associations,
In “fill” entry, replace “fill : Fill” with “packagedFill : Fill”, and “owned” with “packaged”.
In “marker” entry, replace “marker : Marker” with “packagedMarker : Marker”, and “owned” with “packaged”.
In “style” entry, replace “style : Style” with “packagedStyle : Style”, and “owned” with “packaged”.
In Section 10.3.31 (Style), Description, first paragraph, second sentence, change “owned by the canvas” to “packaged by the canvas”.
Actions taken:
May 17, 2011: received issue
January 11, 2012: closed issue
Discussion: figure on page 18 of ptc/2011-07-11
Issue 16252: Cascade specification in DG isn't as specific as DI (dd-ftf)
Click here for this issue's archive.
Nature: Revision
Severity: Significant
Summary: Cascade specification in DG isn't as specific as DI. DG should align with DI (local overrides shared overrides inherited), so the mapping from DI to DG won't need to repeat the cascade algorithm. Multiple styles in DG can be ordered to resolve conflicts
Resolution: The algorithms only appear different because of a typographic error.
Revised Text: In Section 9.3.9 (Style), Description, fourth paragraph, insert a line break and bullet before “oif”, and replace that bullet by the following two:
• If there is a cascading value set on a local style, use it.
• Otherwise, if there is a cascading value set on a shared style, use it.
Actions taken:
May 17, 2011: received issue
January 11, 2012: closed issue
Issue 16371: Merge DI diagrams (dd-ftf)
Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary: After the first FTF ballot, the DI diagrams are small enough to be merged into one
Resolution: The DI metamodel is indeed small enough after Ballot 1 that all concepts can fit in one diagram.
Revised Text: Replace Figures 9.2 through 9.6 (all figures in Clause 9.2 after Figure 1) with the following:
In clauses 9.3.1 through 9.3.9 (all subclauses of Clause 9.3), replace the bullets under the Diagram heading with
• Figure 9.2 (DI Package)
Actions taken:
July 19, 2011: received issue
January 11, 2012: closed issue
Discussion: figure on page 21 of ptc/2011-07-11
Issue 16372: Update Annex A (dd-ftf)
Click here for this issue's archive.
Nature: Revision
Severity: Significant
Summary: Update Annex A (UML Diagram Definition Example) for the changes in FTF ballot 1 and complete the example.
Resolution: Add a small example defining a subset of the UML Class diagram with DD
Revised Text: Replace Annex A’s title and text with the following:
Annex A - UML Class Diagram Definition Example
(Informative)
This annex gives an example of using the DD specification to define a small subset of the UML class diagram. Subsection A.1 gives the UML DI metamodel as an extension of the DI metamodel. Subsection A.2 gives the mapping from this UML DI metamodel to the DG metamodel.
The UML class diagram is chosen due to its widespread use and familiarity. However, to control the scope, the example is limited to representative subset of class diagram elements consisting of three classifiers (Class, Interface and DataType) and three relations (Association, Generalization and InterfaceRealization). This subset exemplifies the notation of shapes (with labels, compartments and alternative notation) and edges (with labels, markers and line styles) of the class diagram.
Note: This example is adapted from the following paper:
Elaasar, M., and Labiche, Y., “Diagram Definition: a Case Study with the UML Class Diagram”, ACM/IEEE 14th International Conference on Model Driven Engineering Languages and Systems (MODELS), October 2011.
A.1 UML DI
Some design principles used in this example are:
• Avoid interchanging notational information that can be derived from the UML model to minimize redundancy between the DI and UML models.
• Interchange simple layout constraints (bounds for all shapes/labels and waypoints for all edges) and avoid constraints of more complex layout algorithms to make it easier for tools to map to/from their native layouts.
• Interchange the overlapping order of sibling diagram elements (which can happen when a diagram is crowded) by making all nested element collections ordered (a higher index implies a higher overlap order).
• Avoid interchanging purely stylistic properties (e.g., colors/fonts) that tools may give users control over since they may vary dramatically between tools. However, we made an exception to some font properties (e.g., name and size) that we suspected could affect layout.
• Keep the DI class hierarchy small, thus easier to maintain and evolve, by avoiding extensive sub-classing (resembling the UML class hierarchy). Instead, we allow DI classes to have a mixed bag of optional properties that apply in specific UML contexts only.
The UML DI metamodel (Figure A.1) extends the DI metamodel, where appropriate, using metamodel extension semantics (subclassing and property subsetting and redefinition). Specifically, the class UMLDiagram composes a collection of elements of type UMLDiagramElement. The latter optionally references an element from a UML model and can be styled with instances of class UMLStyle, which has two properties: fontName and fontSize.
Note ? the reason property UMLDiagramElement::modelElement can redefine DiagramElement::modelElement even though UML::Element is not explicitly a subclass of CMOF::Element is due to the semantics of clause 9.1 of MOF, which says that class Element is an implicit superclass of all MOF-based model elements.
Classes are defined for interchanging the chosen shapes and edges of the class diagram, based on three notational patterns in the UML specification (Figure A.2):
• pattern (a): a shape that has a label and an optional list of compartments, each of which has an optional list of other labels (e.g., the classifier box notation).
• pattern (b): a shape that has a label only (e.g., the interface ball notation)
• pattern (c): an edge that has an optional list of labels (e.g., the association notation)
However, pattern (b) is really a special case of (a) when there is no compartment. Based on that, three shape classes (UMLShape, UMLLabel and UMLCompartment) and one edge class (UMLEdge) are defined and related with the multiplicities of patterns (a) and (c). These classes (except UMLCompartment) are subclasses of UMLDiagramElement to enable them to be styled independently, to reference their own UML elements, and to be connectable (an edge is made to only connect elements of type UMLDiagramElement). Properties on the classes disambiguate their notation. For example, a kind can be set on a label to indicate what aspects of the UML element to show textually. A flag showClassifierShape can be set on a classifier’s shape to indicate whether to use the box notation (this covers only a subset of the possible notational options for brevity).
Figure A.1 - UML DI Metamodel
Figure A.2 - UML DI Notational Patterns
A.2 Mapping UML DI to DG using QVT Operational
Recall from Section 7 that a modeling language can specify its concrete graphical syntax as a mapping from its DI metamodel, which references its abstract syntax metamodel, to the DG metamodel. The mapping can be expressed using any suitable mapping language. This examples expresses the mapping using the QVT Operational (QVTO) transformation language (for brevity, only selected parts of the transformation are shown). QVTO is a standard language and has an available implementation (on Eclipse). This assumes reader’s familiarity with QVTO, OCL and the UML 2.x metamodel.
The UML class diagram’s concrete syntax is defined with a QVTO transformation (Figure A.3) from the UML DI metamodel (Section A.1) to the DG metamodel. The transformation starts by looking for all instances of UMLDiagram and initiating the mapping for them (lines 2-4). Mappings (like operations) are defined on UML DI classes and have DG classes as return types. For example, a mapping named toGraphics is defined on the class UMLDI::UMLDiagram and has DG::Canvas as a return type (line 5). This maps an instance of UMLDiagram to an instance of Canvas, and initializes the properties of the latter according to the body of the mapping. In this case, the body iterates on all the owned elements of the diagram, mapping each one in turn to graphics, and adding the resulting graphical elements as members of the canvas (line 6).
Furthermore, a UMLShape maps to a Group (lines 12-17) consisting of the following: a graphic for the model element (line 14), a graphic for the owned label (line 15) and a graphic for each owned compartment (line 16). These graphics are produced by other nested mappings (defined later). A similar mapping is defined for UMLEdge (lines 18-22). However, the mapping for UMLCompartment (lines 23-26) is different as the first member graphic is fixed as a Rectangle whose bounds are defined by the compartment. The mapping for UMLLabel (lines 27-40) is also different as it maps to a Text whose bounds are defined by the label and whose data value is defined based on the label’s kind. For example, if the kind is signature, the value is defined by a query getSignature defined on UML::NamedElement (line 33-34). Also notice how the mapping inherits (line 28) another mapping (lines 8-11) that copies over the local and shared styles. Another local style is added (line 39) based on the label’s model element (e.g., the fontItalic property is set to true for the signature label in the case of an abstract classifier).
Some of the queries used for the label mapping are shown in Figure A.4. The getSignature query (lines 1-3) returns the (simple or qualified) name of an element based on a flag. The query is overridden for different UML types to specify their unique signatures. For example, UML::Interface (lines 4-6) overrides it to prefix the name with the «Interface» keyword. UML::Property (lines 12-17) overrides it to return the full signature of a property in an attribute compartment (with type, multiplicity, etc.).
Figure A.5 shows mappings between UML classifiers and their corresponding graphical elements (e.g., box or ball notation). The first mapping (lines 1-3), defined on UML::Element, delegates to other mappings depending on the type of the element. Notice that both UML::Class (lines 4-6) and UML::DataType (lines 7-9) have one mapping each creating a rectangle, while UML::Interface has two mappings, one creating a DG::Rectangle (lines 10-13) and the other creating a DG::Circle (lines 14-20), based on the flag showClassifierShape (lines 11, 15) on UMLShape.
Figure A.6 shows mappings between UML relations and poly lines. The first mapping (lines 10-13), defined on UML::Element, delegates to other mappings depending on the type of the element. The mapping of relation UML::InterfaceRealization (lines 14-19) copies the edge’s waypoints to the poly line’a points (line 15). As the notation of this relation depends on whether the interface shape was shown as a box or a ball, this is checked first (line 16). If it is shown as a box, a shared style with a dash pattern (lines 1-2) and a closed arrow marker (lines 3-9) are used (lines 17-18).
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40 transformation UMLDIToDG(in umldi : UMLDI, out DG);
main() {
umldi.objectsOfType(UMLDiagram)->map toGraphics();
}
mapping UMLDiagram::toGraphics() : Canvas {
member += self.ownedElement->map toGraphics();
}
mapping UMLDiagramElement::toGraphics() : Group {
localStyle := copyStyle(self.localStyle);
sharedStyle := copyStyle(self.sharedStyle);
}
mapping UMLShape::toGraphics() : Group
inherits UMLDiagramElement::toGraphics {
member += self.modelElement.map toGraphics(self);
member += self.ownedLabel.map toGraphics ();
member += self.ownedCompartment->map toGraphics();
}
mapping UMLEdge::toGraphics() : Group
inherits UMLDiagramElement::toGraphics {
member += self.modelElement.map toGraphics(self);
member += self.ownedElement->map toGraphics ();
}
mapping UMLCompartment::toGraphics() : Group {
member += object Rectangle {bounds := self.bounds};
member += self.ownedElement->map toGraphics ();
}
mapping UMLLabel::toGraphics () : Text
inherits UMLDiagramElement::toGraphics {
var e := self.modelElement;
var q := self.showQualified;
bounds := self.bounds;
data := switch {
case (self.kind = LabelKind::signature)
e.oclAsType(NamedElement).getSignature(q);
case (self.kind = LabelKind::role)
e.oclAsType(Property).getRole();
...
};
localStyle += e.map toStyle(self);
}
Figure A.3 - QVTO Mapping from UML D to DG
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24 query NamedElement::getSignature(q : Boolean) : String {
return self.getName(q);
}
query Interface::getSignature(q : Boolean) : String {
return “«Interface»\n” + self.getName(q);
}
query Property::getSignature(q : Boolean) : String {
var t := if self.type->notEmpty() then ":" +
self.type.getSignature(q) else "" endif;
return self.getRole()+ t + self.getAdornment();
}
query Property::getRole() : String {
var d := if self.isDerived then “/” else “” endif;
var v := if self.visibility = VisibilityKind::public
then “+” else ... endif;
return d + v + self.getName(false);
}
query NamedElement::getName(q : Boolean) : String {
return if q then self.qualifiedName
else self.name endif;
}
query Property::getAdornment() : String {
return “{“ + ... + “}”;
}
Figure A.4 - Queries used by the UML Label Mapping
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
20 mapping Element::toGraphics(s:UMLShape):GraphicalElement
disjuncts Interface::toRectangle, Interface::toCircle,
Class::toRectangle, DataType:toRectangle {}
mapping Class::toRectangle (s:UMLShape) : Rectangle {
bounds := s.bounds;
}
mapping DataType::toRectangle (s:UMLShape) : Rectangle {
bounds := s.bounds;
}
mapping Interface::toRectangle (s:UMLShape) : Rectangle
when { s.showClassifierShape=true } {
bounds := s.bounds;
}
mapping Interface::toCircle (s:UMLShape) : Circle
when { s.showClassifierShape=false } {
var b := s.bounds;
center := object Point{b.x+b.width/2;b.y+b.height/2};
radius := if b.width<b.height then b.width/2
else b.height/2 endif;
}
Figure A.5 - UML Classifier Mapping to Graphics
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19 property interfaceRealStyle = object DG::Style {
strokeDashLength := Sequence {2, 2} };
property interfaceRealMarker = object Marker {
size := object Dimension {width := 10; height := 10};
reference := object Point {x := 10; y := 5};
member += object Polylgon {
point += object Point{ x:=0; y:=0 };
point += object Point{ x:=10; y:=5 };
point += object Point{ x:=0; y:=10 }; }; };
mapping Element::toGraphics(e:UMLEdge):GraphicalElement
disjuncts Association::toPolyline,
Generalization::toPolyline,
InterfaceRealization::toPolyline {}
mapping InterfaceRealization::toPolyline(e:UMLEdge):Polyline{
point := e.waypoint;
var s = e.target.showClassifierShape;
sharedStyle := if s then interfaceRealStyle endif;
endMarker := if s then interfaceRealMarker endif;
}
Figure A.6 - UML Relation Mapping to Graphics
Actions taken:
July 19, 2011: received issue
January 11, 2012: closed issue
Discussion: figure on page 24 of ptc/2011-07-11
Issue 16386: MOF Compliance (dd-ftf)
Click here for this issue's archive.
Nature: Revision
Severity: Significant
Summary: Update for compliance with MOF 2.4 (for example UML:Element instead of MOF:Element), and change text to not refer to MOF, just "metamodel extension".
Resolution: MOF 2.4 is not formalized yet. It is valid to leave the property typed by CMOF::Element as it is the super class of all metaclasses. We should add a package import from DI to CMOF to make the dependency explicit.
Revised Text: Replace figure 9.1 by the following to add a package import to CMOF:
In Clause 9.1, first paragraph, after “(Section 8)” insert “and CMOF”.
Disposition: Resolved
Actions taken:
July 22, 2011: received issue
January 11, 2012: closed issue
Discussion: figure 9.1 on page 29 of ptc/2011-07-11
Issue 16387: Owning styles (dd-ftf)
Click here for this issue's archive.
Nature: Revision
Severity: Significant
Summary: After issue 15902, the spec should not refer to owning styles, for example, see DI, DiagramElement, fourth paragraph, next to last sentence, and DI, Style, second paragraph, first sentence.
Resolution: Revise as suggested
Revised Text: In Clause 9.3.1 (Diagram), Description, last paragraph, remove the first sentence (the one starting “A diagram can own”).
In 9.3.2 (DiagramElement), Description, last paragraph, replace the next to last sentence, as modified by issue 15902, with “Shared style elements are owned by other elements, which might be packaging elements in the language incorporating diagram interchange.”.
In Clause 9.3.5 (Style), Description, second paragraph, first sentence, as modified by 15902, replace “owned by other elements at a higher level like a diagram or other diagram elements with nested elements” with “owned elsewhere (e.g., by packaging elements in the language incorporating diagram interchange)”.
Actions taken:
July 22, 2011: received issue
January 11, 2012: closed issue
Issue 16388: Cascading called inheritance (dd-ftf)
Click here for this issue's archive.
Nature: Revision
Severity: Significant
Summary: The spec sometimes refers to style cascading incorrectly as inheritance. Inheritance applies to classes, cascading applies to instances. Search on "inherit" to find them.
Resolution: Revise as suggested
Revised Text: Clause 9.3.5 (Style), Description, third paragraph, replace “style inheritance”, with “cascading styles”, and “inherits its” with “gets its”.
Clause 10.3.11 (GraphicalElement), Description, second paragraph, second sentence, replace “gets inherited” with “gets its value”.
Clause 10.3.12 (Group), Description, second sentence, replace “are inherited by” with “cascade to”.
Clause 10.3.18 (Marker), Description, third paragraph, next to last sentence, replace “Even though referencing marked elements are not in the group chain of a marker, it inherits their styles in the context of every reference” with “The styles of marked elements cascade to their referenced markers in each case”.
Clause 10.3.23 (Pattern), Description, next to last sentence, replace “Even though referencing graphical elements filled with patterns are not in the group chain of the pattern's tile, the tile inherits their styles in the context of every reference” with “The styles of those graphical elements cascade to the pattern tiles in each case”.
Clause 10.3.32 (Style), Description, second paragraph, last sentence, replace “style inheritance” with “cascading styles”, and replace “inherits” with “gets”.
Actions taken:
July 22, 2011: received issue
January 11, 2012: closed issue
Issue 16389: Optional bounds (dd-ftf)
Click here for this issue's archive.
Nature: Revision
Severity: Significant
Summary: After 15996, bounds should not be required, for example, search on "with a given bounds". Explain that if DI does not specify bounds, then the mapping to DG does.
Resolution: The only text remaining after 15902 that implies the presence of bounds is examples were bounds is supposed to be specified.
Revise the description of bounds to indicate it is optional.
Revised Text: In clause 9.3.4 (Shape), under associations, in the text of the bounds bullet, before "bounds of the shape", insert "optional ".
Actions taken:
July 22, 2011: received issue
January 11, 2012: closed issue
Issue 16390: Annex B (dd-ftf)
Click here for this issue's archive.
Nature: Revision
Severity: Significant
Summary: Update or remove Annex B (DG to SBV Mapping).
Resolution: Remove the annex until we have content for it.
Revised Text: Remove Annex B (DG to SVG Mapping).
Actions taken:
July 22, 2011: received issue
January 11, 2012: closed issue
Issue 16392: Optional waypoints (dd-ftf)
Click here for this issue's archive.
Nature: Revision
Severity: Significant
Summary: After 15959, multiple waypoints should not be required, for example, see DI Edge, first paragraph, and in the attribute description.
Resolution: Revise and suggested.
Revised Text: Clause 9.3.4 (Edge),
Description,
First sentence, remove “two or more”.
Second sentence, replace “as follows: the first waypoint is positioned at the source element, the last waypoint is positioned at the target element and the waypoints in between specify” with “, specifying”.
Under Attributes, replace “a list of two or more” with “an optional list of”.
Actions taken:
July 24, 2011: received issue
January 11, 2012: closed issue
Issue 16408: Spurious question marks (dd-ftf)
Click here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Significant
Summary: Remove "?"s before attribute names
Resolution: The “•” (composition) symbols got replaced by “?” symbols by mistake during the editing process of the Beta 2 specification. The fix is to restore the “•” symbols
Revised Text: In all bulleted lists, replace any “?” found just after the bullet with “•”.
Actions taken:
July 31, 2011: received issue
January 11, 2012: closed issue
Issue 16409: Visibility markers not needed (dd-ftf)
Click here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Significant
Summary: Would be easier to read the specification with the "+" visibilitiy markers in the figures and attribute/association sections.
Resolution: We agree with the proposal to remove the visibility symbol as it is not relevant for metamodels
Revised Text: In clause 8, 9 and 10, under attribute/associations sections, remove the “+” symbol from the beginning of the bulleted items,
Update figures (8.2, 8.3, 9.2, 10.2, 10.3, 10.4, 10.5, 10.6, 10.7 and 10.8) to remove the “+” symbols.
Actions taken:
July 31, 2011: received issue
January 11, 2012: closed issue
Issue 16410: Collections => sets (dd-ftf)
Click here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Significant
Summary: Collections should be called sets, except when they are non-unique
Resolution: The word collection is valid as it is a generic way of describing sets, lists, sequences...etc. All metamodel properties are already annotated with the specific kinds of collections.
Disposition: Closed, No Change
Revised Text:
Actions taken:
July 31, 2011: received issue
January 11, 2012: closed issue
Issue 16485: Diagram description (dd-ftf)
Click here for this issue's archive.
Nature: Revision
Severity: Significant
Summary: Some of the clause 9.3.1 description is redundant with 8.1.3, and it does not make sense after changes from ballot 1.
Resolution: Remove the redundant paragraph as suggested
Revised Text: In clause 9.3.1 (Diagram), under description, remove the third paragraph starting with “The collection of nested elements in a diagram is ordered and”.
Actions taken:
August 4, 2011: received issue
January 11, 2012: closed issue