${taskforce.name} Avatar
  1. OMG Task Force

UML2 Diagram Interchange FTF 2 — All Issues

  • Key: UMLDI
  • Issues Count: 30
Open Closed All
All Issues

Issues Summary

Key Issue Reported Fixed Disposition Status
UMLDI-30 Section: 8.5 Properties UMLDI 1.0 open
UMLDI-28 Invalid "diagram-interchange.xml" file in DI 2.0 's ptc/05-06-07 zip file UMLDI 1.0b1 open
UMLDI-27 Section: Annex C UMLDI 1.0b1 open
UMLDI-29 di-schema.xsd UMLDI 1.0b1 open
UMLDI-26 Diagram Interchange clarification UMLDI 1.0b1 open
UMLDI-25 UML Mapping in DI specification inadequate UMLDI 1.0b1 open
UMLDI-24 UML diagram interchange: list updating and nested graph nodes UMLDI 1.0b1 open
UMLDI-23 UML diagram interchange: size of graph node with autosize UMLDI 1.0b1 open
UMLDI-22 UML diagram interchange: use of bounds limiting UMLDI 1.0b1 open
UMLDI-21 UML diagram interchange: schema usage needed UMLDI 1.0b1 open
UMLDI-20 UML diagram interchange: limitation of complex properties UMLDI 1.0b1 UMLDI 1.0 Resolved closed
UMLDI-19 A schema definition has to be added for the completeness of the specificati UMLDI 1.0b1 UMLDI 1.0 Resolved closed
UMLDI-5 Introduce a 'Nesting Guide' UMLDI 1.0b1 UMLDI 1.0 Resolved closed
UMLDI-4 Change role name in DI metamodel UMLDI 1.0b1 UMLDI 1.0 Resolved closed
UMLDI-14 UML diagram interchange: unit of measurement UMLDI 1.0b1 UMLDI 1.0 Resolved closed
UMLDI-13 UML diagram interchange: translucent property unnecessary? UMLDI 1.0b1 UMLDI 1.0 Resolved closed
UMLDI-12 UML diagram interchange: do diagrams have to be nodes? UMLDI 1.0b1 UMLDI 1.0 Resolved closed
UMLDI-16 UML diagram interchange: containment vs reference UMLDI 1.0b1 UMLDI 1.0 Resolved closed
UMLDI-15 UML diagram interchange: association as a graph node UMLDI 1.0b1 UMLDI 1.0 Resolved closed
UMLDI-7 UML diagram interchange: inappropriate diagram properties UMLDI 1.0b1 UMLDI 1.0 Resolved closed
UMLDI-6 UML diagram interchange: views may need more context UMLDI 1.0b1 UMLDI 1.0 Resolved closed
UMLDI-11 UML diagram interchange: cut-out diagram feature UMLDI 1.0b1 UMLDI 1.0 Resolved closed
UMLDI-10 UML diagram interchange: dubious value of leaf elements UMLDI 1.0b1 UMLDI 1.0 Resolved closed
UMLDI-18 Rename the specification to OMG Diagram Interchange Specification UMLDI 1.0b1 UMLDI 1.0 Resolved closed
UMLDI-17 UML 2 Diagram Interchange / Assigning icons to stereotypes UMLDI 1.0b1 UMLDI 1.0 Resolved closed
UMLDI-9 UML diagram interchange: more features in schema? UMLDI 1.0b1 UMLDI 1.0 Resolved closed
UMLDI-8 UML diagram interchange: limitation of complex properties UMLDI 1.0b1 UMLDI 1.0 Resolved closed
UMLDI-1 property CoreSemanticModelBridge.element UMLDI 1.0b1 UMLDI 1.0 Resolved closed
UMLDI-3 Allow a Diagram Element to represent multiple Model Elements UMLDI 1.0b1 UMLDI 1.0 Resolved closed
UMLDI-2 UML Diagram interchange -- change Rational ref to IBM UMLDI 1.0b1 UMLDI 1.0 Resolved closed

Issues Descriptions

Section: 8.5 Properties

  • Key: UMLDI-30
  • Legacy Issue Number: 8179
  • Status: open  
  • Source: Gentleware AG ( Stefan Mueller)
  • Summary:

    In Table 1 a few standardized properties are defined. To be more conveniened with other standards (mainly SVG)the DI should use the property names 'fill' and 'stroke' instead of 'BackgroundColor' and 'ForegroundColor'

  • Reported: UMLDI 1.0 — Mon, 31 Jan 2005 05:00 GMT
  • Updated: Wed, 11 Mar 2015 23:48 GMT

Invalid "diagram-interchange.xml" file in DI 2.0 's ptc/05-06-07 zip file

  • Key: UMLDI-28
  • Legacy Issue Number: 10660
  • Status: open  
  • Source: Adaptive ( Mr. Gene Mutschler)
  • Summary:

    I tried to load the diagram-interchange.xml file in the referenced zip file into the Rational Rose UML 1.4 xmi addin. This addin reports 4 errors:

    Could not add DataType "Image" to Logical View – probably duplicate name.
    Could not add DataType "Dimension" to Logical View – probably duplicate name.
    Could not add DataType "Point" to Logical View – probably duplicate name.
    Relation "Generalization" @ in 'Image' was not resolved – not added.

    The first three are cases where data type names duplicate classes in the same package. This is at least bad form, if not actually illegal. Rose does not allow it.

    THe final error is a case where one of the "generalization" references of the "Image" class points to a Generalization object that is not in the file:

    <UML:GeneralizableElement.generalization>

    <UML:Generalization xmi.idref="EAID_B3BDA775_38C1_4989_87D1_A4CDF297DA06"/>

    </UML:GeneralizableElement.generalization>

    There is no object with an ID of "EAID_B3BDA775_38C1_4989_87D1_A4CDF297DA06" in the file.

  • Reported: UMLDI 1.0b1 — Fri, 9 Feb 2007 05:00 GMT
  • Updated: Wed, 11 Mar 2015 04:40 GMT

Section: Annex C

  • Key: UMLDI-27
  • Legacy Issue Number: 10499
  • Status: open  
  • Source: PCMS ( Russell Block)
  • Summary:

    I was looking over the specification wanting to create a program that will be able to produce and read the format. However, I could use some clarification in Annex C, C.2.1 Class Diagram. There is no representation for an association. I had been, for a short time, believed that it was DiAssociationClass, but upon looking that up, I found it was not. For DiAssociationEnd, the tree does not match up with the example, as I understand it, in Annex B. Annex C says that the RoleAdornment should product a node with simpleSemanticModelElement of 'RoleAdornment'. But there is no such nesting. The GraphNode(<AssociationEnd>)'s next nestings go straight to 'name', 'visibility', and 'multiplicity'. Could you clarify this for me? Also in the zip example, there is an undefined compartment used called 'ExpressionCompartment'. DiAssociationClass refers to 'Stereotypes'. Is that supposed to be StereotypeCompartment? In C.1, there are a few areas where ',' appears that is should be '<'.

  • Reported: UMLDI 1.0b1 — Sat, 2 Dec 2006 05:00 GMT
  • Updated: Wed, 11 Mar 2015 04:40 GMT

di-schema.xsd

  • Key: UMLDI-29
  • Legacy Issue Number: 13533
  • Status: open  
  • Source: NHS ( Ravi Natarajan)
  • Summary:

    The di-schema.xsd available from the link http://www.omg.org/cgi-bin/doc?ptc/05-06-07 import namespace <xsd:import namespace="http://www.omg.org/XMI" schemaLocation="XMI.xsd"/>. XMI.xsd is not present in the same package throws schema error on di-schema.xsd. Where can be the approved XMI.xsd found that the di-schema refers to.

  • Reported: UMLDI 1.0b1 — Fri, 20 Feb 2009 05:00 GMT
  • Updated: Wed, 11 Mar 2015 04:40 GMT

Diagram Interchange clarification

  • Key: UMLDI-26
  • Legacy Issue Number: 8971
  • Status: open  
  • Source: gmx.de ( Ludger Goeke)
  • Summary:

    The following figure shall picture a Part of a composite structure
    diagram. Are the graphically informations like the colon that seperates the
    name and the type of the part, the brackets that surround the multiplicity,
    and the ".." points that display the range of the Multiplicity legal
    Diagram Interchange informations ? Till now I saved
    those informations as TextElements with a SimpleSemanticModelElement.
    Is this ok or can I disregard those informations ?

    ______________________________________

     
    myPart : myPartType [1..*]
    _____________________________________
  • Reported: UMLDI 1.0b1 — Fri, 19 Aug 2005 04:00 GMT
  • Updated: Wed, 11 Mar 2015 04:40 GMT

UML Mapping in DI specification inadequate

  • Key: UMLDI-25
  • Legacy Issue Number: 7663
  • Status: open  
  • Source: gmail.com ( Guus Ramackers)
  • Summary:

    The current mapping from the Diagram Interchange meta model to UML is inadequately specified in Appendix A of the DI specification. It will not enable a standard encoding of DI models from the UML 2.0 meta model across vendors. Specifically:

    • the mapping does not cover UML 2.0
    • the mapping solely consists of a table listing a subset of UML meta classes
    • the mapping does not cover the complexities of UML 2.0 decomposition details, as specified in the UML 2.0 specification in the area of Sequence Diagrams, Activity Diagrams and State Machines.
  • Reported: UMLDI 1.0b1 — Wed, 25 Aug 2004 04:00 GMT
  • Updated: Wed, 11 Mar 2015 04:40 GMT

UML diagram interchange: list updating and nested graph nodes

  • Key: UMLDI-24
  • Legacy Issue Number: 7271
  • Status: open  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    If you are going to represent list items like attributes or operations by nested graph nodes, what happens if the semantic element has changed (lost an operation or gained an attribute) after the diagram is created. When should the list be updated?

  • Reported: UMLDI 1.0b1 — Thu, 22 Apr 2004 04:00 GMT
  • Updated: Wed, 11 Mar 2015 04:40 GMT

UML diagram interchange: size of graph node with autosize

  • Key: UMLDI-23
  • Legacy Issue Number: 7270
  • Status: open  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    In case of autosize (the size property is omitted) all across the aggregation hierarchy, how would you calculate the size of a graph node?

  • Reported: UMLDI 1.0b1 — Thu, 22 Apr 2004 04:00 GMT
  • Updated: Wed, 11 Mar 2015 04:40 GMT

UML diagram interchange: use of bounds limiting

  • Key: UMLDI-22
  • Legacy Issue Number: 7269
  • Status: open  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    The use of Bounds (x, y, width, height) as layout constraints maybe acceptable for rendering diagrams, but is not very suitable for editing ones that employ other types of layout algorithms that might not necessarily use a Bounds constraint. (attributes could be laid out in their compartment using a flow layout that only considers the order of attributes in their collection to be what is relevant to the layout).

  • Reported: UMLDI 1.0b1 — Thu, 22 Apr 2004 04:00 GMT
  • Updated: Wed, 11 Mar 2015 04:40 GMT

UML diagram interchange: schema usage needed

  • Key: UMLDI-21
  • Legacy Issue Number: 7259
  • Status: open  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    The proposal mainly talks about the schema of the UML diagram notation. It does not detail the expected usage of that schema or the “format”. The format should at least include the view aggregation hierarchies and the view properties assignment (what properties are installed for every view). Recently there was an appendix that talks about the aggregation hierarchy.

  • Reported: UMLDI 1.0b1 — Thu, 22 Apr 2004 04:00 GMT
  • Updated: Wed, 11 Mar 2015 04:40 GMT

UML diagram interchange: limitation of complex properties

  • Key: UMLDI-20
  • Legacy Issue Number: 7262
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    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)?

  • Reported: UMLDI 1.0b1 — Thu, 22 Apr 2004 04:00 GMT
  • Disposition: Resolved — UMLDI 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

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

  • Key: UMLDI-19
  • Legacy Issue Number: 7788
  • Status: closed  
  • Source: Gentleware AG ( Marko Boger)
  • Summary:

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

  • Reported: UMLDI 1.0b1 — Wed, 29 Sep 2004 04:00 GMT
  • Disposition: Resolved — UMLDI 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Introduce a 'Nesting Guide'

  • Key: UMLDI-5
  • Legacy Issue Number: 7257
  • Status: closed  
  • Source: Gentleware AG ( Marko Boger)
  • Summary:

    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.

  • Reported: UMLDI 1.0b1 — Fri, 16 Apr 2004 04:00 GMT
  • Disposition: Resolved — UMLDI 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Change role name in DI metamodel

  • Key: UMLDI-4
  • Legacy Issue Number: 7252
  • Status: closed  
  • Source: Gentleware AG ( Marko Boger)
  • Summary:

    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.

  • Reported: UMLDI 1.0b1 — Fri, 16 Apr 2004 04:00 GMT
  • Disposition: Resolved — UMLDI 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

UML diagram interchange: unit of measurement

  • Key: UMLDI-14
  • Legacy Issue Number: 7268
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    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?

  • Reported: UMLDI 1.0b1 — Thu, 22 Apr 2004 04:00 GMT
  • Disposition: Resolved — UMLDI 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

UML diagram interchange: translucent property unnecessary?

  • Key: UMLDI-13
  • Legacy Issue Number: 7267
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

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

  • Reported: UMLDI 1.0b1 — Thu, 22 Apr 2004 04:00 GMT
  • Disposition: Resolved — UMLDI 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

UML diagram interchange: do diagrams have to be nodes?

  • Key: UMLDI-12
  • Legacy Issue Number: 7266
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    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). )

  • Reported: UMLDI 1.0b1 — Thu, 22 Apr 2004 04:00 GMT
  • Disposition: Resolved — UMLDI 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

UML diagram interchange: containment vs reference

  • Key: UMLDI-16
  • Legacy Issue Number: 7273
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    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).

  • Reported: UMLDI 1.0b1 — Thu, 22 Apr 2004 04:00 GMT
  • Disposition: Resolved — UMLDI 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

UML diagram interchange: association as a graph node

  • Key: UMLDI-15
  • Legacy Issue Number: 7272
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    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?

  • Reported: UMLDI 1.0b1 — Thu, 22 Apr 2004 04:00 GMT
  • Disposition: Resolved — UMLDI 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

UML diagram interchange: inappropriate diagram properties

  • Key: UMLDI-7
  • Legacy Issue Number: 7260
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    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.

  • Reported: UMLDI 1.0b1 — Thu, 22 Apr 2004 04:00 GMT
  • Disposition: Resolved — UMLDI 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

UML diagram interchange: views may need more context

  • Key: UMLDI-6
  • Legacy Issue Number: 7258
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    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).

  • Reported: UMLDI 1.0b1 — Thu, 22 Apr 2004 04:00 GMT
  • Disposition: Resolved — UMLDI 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

UML diagram interchange: cut-out diagram feature

  • Key: UMLDI-11
  • Legacy Issue Number: 7265
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    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.

  • Reported: UMLDI 1.0b1 — Thu, 22 Apr 2004 04:00 GMT
  • Disposition: Resolved — UMLDI 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

UML diagram interchange: dubious value of leaf elements

  • Key: UMLDI-10
  • Legacy Issue Number: 7264
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    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.

  • Reported: UMLDI 1.0b1 — Thu, 22 Apr 2004 04:00 GMT
  • Disposition: Resolved — UMLDI 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Rename the specification to OMG Diagram Interchange Specification

  • Key: UMLDI-18
  • Legacy Issue Number: 7568
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    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

  • Reported: UMLDI 1.0b1 — Wed, 7 Jul 2004 04:00 GMT
  • Disposition: Resolved — UMLDI 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

UML 2 Diagram Interchange / Assigning icons to stereotypes

  • Key: UMLDI-17
  • Legacy Issue Number: 7305
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    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.

  • Reported: UMLDI 1.0b1 — Wed, 5 May 2004 04:00 GMT
  • Disposition: Resolved — UMLDI 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

UML diagram interchange: more features in schema?

  • Key: UMLDI-9
  • Legacy Issue Number: 7263
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    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

  • Reported: UMLDI 1.0b1 — Thu, 22 Apr 2004 04:00 GMT
  • Disposition: Resolved — UMLDI 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

UML diagram interchange: limitation of complex properties

  • Key: UMLDI-8
  • Legacy Issue Number: 7261
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    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)?

  • Reported: UMLDI 1.0b1 — Thu, 22 Apr 2004 04:00 GMT
  • Disposition: Resolved — UMLDI 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

property CoreSemanticModelBridge.element

  • Key: UMLDI-1
  • Legacy Issue Number: 6971
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    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.

  • Reported: UMLDI 1.0b1 — Tue, 3 Feb 2004 05:00 GMT
  • Disposition: Resolved — UMLDI 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Allow a Diagram Element to represent multiple Model Elements

  • Key: UMLDI-3
  • Legacy Issue Number: 7165
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    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..*.

  • Reported: UMLDI 1.0b1 — Thu, 18 Mar 2004 05:00 GMT
  • Disposition: Resolved — UMLDI 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

UML Diagram interchange -- change Rational ref to IBM

  • Key: UMLDI-2
  • Legacy Issue Number: 6973
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

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

  • Reported: UMLDI 1.0b1 — Mon, 9 Feb 2004 05:00 GMT
  • Disposition: Resolved — UMLDI 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT