Issues for UML 2.0 Diagram Interchange Finalization Task Force

List of issues (green=resolved, yellow=pending Board vote, red=unresolved)

List options: All ; Open Issues only; or Closed Issues only

Issue 6971: property CoreSemanticModelBridge.element
Issue 6973: UML Diagram interchange -- change Rational ref to IBM
Issue 7165: Allow a Diagram Element to represent multiple Model Elements
Issue 7252: Change role name in DI metamodel
Issue 7257: Introduce a 'Nesting Guide'
Issue 7258: UML diagram interchange: views may need more context
Issue 7260: UML diagram interchange: inappropriate diagram properties
Issue 7261: UML diagram interchange: limitation of complex properties
Issue 7262: UML diagram interchange: limitation of complex properties
Issue 7263: UML diagram interchange: more features in schema?
Issue 7264: UML diagram interchange: dubious value of leaf elements
Issue 7265: UML diagram interchange: cut-out diagram feature
Issue 7266: UML diagram interchange: do diagrams have to be nodes?
Issue 7267: UML diagram interchange: translucent property unnecessary?
Issue 7268: UML diagram interchange: unit of measurement
Issue 7272: UML diagram interchange: association as a graph node
Issue 7273: UML diagram interchange: containment vs reference
Issue 7305: UML 2 Diagram Interchange / Assigning icons to stereotypes
Issue 7568: Rename the specification to OMG Diagram Interchange Specification
Issue 7788: A schema definition has to be added for the completeness of the specificati

Issue 6971: property CoreSemanticModelBridge.element (uml2di-ftf)

The property CoreSemanticModelBridge.element should reference the class
MOF::Object rather than Elements::Element. MOF::Object is the implicit
superclass of everything in UML2/MOF2.
Making this change allows diagram elements to refer to instances of any
metamodel: not just UML2.

The intension of the draft is to reference a superclass of all metamodels specified with MOF so the change is to MOF::Object is necessary

The current draft spec still refers to Rational Software in the front matter. Any references to this should be changed to IBM Rational Software

Replace all occurences of 'Rational Software Corporation' with 'IBM Rational Software'.
There are two occurences:
- Copyright entry on page 4
- Chapter 6.3, Acknowledgement

SemanticModelBridge.element (actually realized on its subclasses
currently) has a multiplicity of 1. 
There are several cases where one visual diagram element will represent
multiple elements in the metamodel (abstract syntax).
For example 'AssemblyConnector' which I think should be a single symbol
consisting of joined 'cup and ball' (see p148 of Superstructure
ptc/03-08-02).


Proposed resolution: change the multiplicity of
SemanticModelBridge.element from 1 to 1..*.

The intension of the specification is to reference only one semantic model element directly from a SemanticModelBridge and therefore a GraphElement references only one semantic model element. If a GraphElement has to represent multiple semantic model elements the GraphElement has contained diagram elements which reference the set of semantic model elements. Each contained diagram element references one of the model elements which the container GraphElement has to represent. So every possible structure can be represented with a hierarchy of nested diagram elements.
Disposition:	Closed, no change has to be made

Change role name in DI metamodel of the SemanticModelBridge associated with the Diagram from 'namespace' to 'owner'

 

Explanation:

The association between the class 'Diagram' and 'SemanticModelBridge' in the DI metamodel has the intension to model which namespace is assigned to a diagram. So the name of the role of the SemanticModelBridge has been 'namespace'. But state diagrams and activity diagrams belong to a state machine. So the name 'owner' fits better in this context.

Introduce a 'Nesting Guide' to specify the contained-container hierarchies
of the diagram elements to represents all model elements of the semantic
model


Explanation:


The semantic model elements are typically represented by a hierarchy of
nested diagram elements which have a container-contained relationship. To
specify which hierarchy of diagram elements is needed to model a special
represenation of a model element we need a nesting guide which describes the
hierachies for all model elements. This nesting guide should be an appendix
to the diagram interchange specification and is added as an appendix to this
document.


Gentleware will provide a nesting guide that refers to the UML 1.4
metamodel. As soon as the super- and infrastructure of the UML 2.0 is
finally adopted a nesting guide for UML 2.0 should be created.

Add the 'Nesting Guide' as Appendix C to the specification. (The 'Nesting Guide' is contained on the following pages.)

The semantic bridge contains either a single reference property or a simple string. Some views, however, need more semantic context than that. (eg: pattern instance views need two semantic references to represent the semantic context).

Discussion:	
The concept is that every GraphElement represents at most one semantic element. If needed the GraphElements are nested. Each nested GraphElement is 'responsible' for one of the semantic model elements and one GraphElement is the container and represents the whole semantic item. This container-GraphElement has typically a SimpleSemanticModelElement.
 
Disposition:	Closed, no change has to be made

Some properties like the diagram zoom level or viewport positions might not be suitable for a team environment, where each person could change them without having to share this preference with the rest of the team. By persisting these properties in the mode, team members would have to share these (not necessary the expectation). Alternatively, these properties could be part of the workspace preferences. 

These properties can be seen as a default for the view the author has preferred.
The viewport and zoomfactor of the DiagramLink can be useful for example if a class diagram is linked to a package and the diagram is displayed inside this package with a reduced zoomfactor. 
In another context this diagram is displayed with a different zoom factor without the package as container.
Tools which support team development could easily ignore these properties if the zoomfactor should be stored individually for every team member. But this is not the scope of the DI standard.
Disposition:		Closed, no change has to be made

The representation of properties as a collection of string key-value pairs means that non-string properties need to be encoded as strings. Can this present a limitation for more complex properties (references, maps, lists…etc)? 

Yes, this is a limitation. But the properties are not designed to store complex model information. There are some standard properties for style issues and the properties are meant to be used for non-standard extension but it is no concept to store complicated tool specific information.
Disposition:		Closed, no change has to be made

The representation of properties as a collection of string key-value pairs means that non-string properties need to be encoded as strings. Can this present a limitation for more complex properties (references, maps, lists…etc)? 

Duplicated (Issue 7271)

Vendors usually add more features to UML diagrams which could require more features in the schema. Is it expected for these features to be omitted when exporting to DI? If no, then there has to be an agreement on those formats as well

Discussion:	
 Generally additional features should be omitted or stored in the properties.
Disposition:		Closed, no change has to be made

Rendering UML shapes is the responsibility of the tool. Therefore, there is no value in using Leaf Elements in the aggregation of UML views. If the intention of using them is notational (like whether attribute visibility should be textual or iconic) then a property is the better way to represent it. 

The intension is not to store redundant information in the DI. The aggregation/composition information is available in the semantic model and there is no need to store them again. 
If there are different representation possible and the information of the representation is not available in the semantic model, then the current representation is available from the 'presentation' attribute of the 'SemanticModelBridge'. The Actor is an example for the use of it.
Disposition:		Closed, no change has to be made

Regarding the cut-out diagram feature, I cannot see how the large diagram can layout out its referenced diagrams without explicitly store layout information. Is there any? This should be documented.

Discussion:	
 The part of a diagram which is shown as a cut-out has the same layout as the original diagram. The cut-out can be moved as a whole if it is nested in another GraphElement because all positions are relative. If the layout should be changed a cut-out cannot be used but a new diagram should be created. 
The cut-out can be used to avoid the need of updating the diagram if the original diagram has changed because the changes are reflected in the cut-out.
Disposition:		Closed, no change has to be made

If you considered zoom and viewport position to be in the workspace, then a diagram just has a name. This means a diagram does not have to be a node. It could just be a GraphElement. Also the diagram link having the same properties will have the same issue (By persisting these properties in the mode, team members would have to share these (not necessarily the expectation). ) 

The zoom and viewport should be stored for every Diagram and DiagramLink, see resolution of issue 7260.
Disposition:		Closed, no change has to be made

Is the ‘Translucent’ property needed? Cannot be inferred by not having a background color property? 

 No, if the background color is not set the element inherits the background color from its container. This is the strategy for all color and font properties. So if an element should be translucent an extra property has to be set. This strategy avoids the need to specify a lot of properties in a deep nested element hierarchy.
Disposition:		Closed, no change has to be made

The coordinate system assumes ‘pixel’ to be the unit of measurement. Often publishing applications use a physical measurement instead (like himetric). Do we need to consider that? Which is more common for the types of applications in consideration?

The relative coordinates and size is important for the layout of the diagrams not the absolute measurement. The scaling of the presentation depends on the representation medium. The unit 'pixel' can be easily handled. It was one goal of the standard not to redefine complex graphic issues like measurement or color systems but to preserve the layout information which are important for the readily understanding of the model.
(Previously recommended Disposition: Resolved, no change has to be made)
Based on the concerns from FTF members and the inability to develop a revised resolution within the given timeframe, this issue has been deferred and should be re-addressed in the future Diagram Interchange RTF.

Disposition:		Deferred.

You gave an example about the adornment of an association and its representation as a graph node. I thought this information can be deduced from the semantic relationship! Why do you need to explicitly represent it as a node? 

The position of the representation of an adorment is not defined by the semantic context. It can be freely moved. Other properties like the font, font size or color can only be defined with a GraphElement representing the adorment too.
Disposition:		Closed, no change has to be made

With regard to the OMG issue of changing the semantic bridge’s association with the diagram role from ‘namespace’ to ‘owner’, the request is appropriate but the justification that state diagrams are owned by state-machines and therefore the role name has to change is not correct. In fact, the important relationship between a state diagram and its state-machine should not be the containment but rather the reference relationship. A state diagram references a state-machine element through the semantic bridge’s ‘semantic model’ role. The containment relationship is optional; a state diagram could legitimately be referencing a state-machine but contained within another namespace (although not typical). 

 The 'semantic model' role of a diagram is defined with a SimpleSemanticModelElement with a 'typeInfo'. This typeInfo defines the type of a diagram, e.g. a state diagram has the typeInfo 'StateDiagram'. Therefore the owner for diagrams must be defined with an extra link to the according element in the semantic model. This is done by the owner-role for the Diagram.
Disposition:		Closed, no change has to be made

There is a need to uniquely assign one or more stereotype icons to a stereotype, when that stereotype is defined. It should be explained how this stereotype is displayed and how multiple stereotypes are handled. 

Each stereotype is represented with its own GraphElement. If the stereotype should be represented by an image an instance of the class Image is nested in the GraphNode. The nesting of the GraphElement and the 'Image' is described in the Nesting Guide in detail (e.g. the GraphNode has a SemanticModelElement with representation= "StereotypeImage"). The Nesting Guide is subject of issue 7257 and can be found in ballot 1.
Disposition:		Closed, no change has to be made

The current title of the document reflects the original RFP but is far
too specific for the standard produced and unnecessarily limits how
people may think it can be applied.


Proposed resolution:
 Rename the specification to OMG Diagram Interchange Specification

The scope of the specification is UML 2.0 and the title should represent this scope. Therefore the title should not be changed to a title which excludes this scope.
 
Disposition:		Closed, no change has to be made

A schema definition has to be added for the completeness of the specification