-
Key: UML14-48
-
Legacy Issue Number: 3682
-
Status: closed
-
Source: David Frankel Consulting ( David Frankel)
-
Summary:
The CWM submitters needed to display inherited associations on some class
diagrams to enhance understandability. These were not intended to be
derived associations; that is, there was no intention to specify additional
computational machinery when showing these inherited associations.
Unfortunately, the MOF and UML have no succint way to display inherited
associations. The CWM submitters placed the "/" derived prefix on the
association end names in the class diagrams. At the same time, in order to
prevent the generation of additional computational machinery, they omitted
the inherited association from the normative XMI rendition of the metamodel.
This was probably a reasonable choice under the circumstances. However, it
means that the class diagrams and the XMI representation of the metamodel
conflict with one another.It is very common to need to show inherited associations on a class diagram.
We ran into this when we specified the CORBA metamodel for the CORBA
Component Model submission. We used derived associations in the class
diagrams as well. However, we retained the derived associations in the XMI
rendition of the metamodel. In order to prevent additional computational
machinery from being generated, we stereotyped the associations as
<<implicit>>. This stereotype is defined in the UML specification but not
in the MOF specification and says that an association is only conceptual and
not manifest. We then made sure that the generator producing the IDL and
XML DTDs was sensitive to the <<implicit>> stereotype. This had the
advantage of maintaining consistency between the class diagrams and the XMI
rendition of the metamodel. Of course this is also a non-standard
approach--since <<implicit>> is not defined in the MOF, we can't expect MOF
generators to understand it.The lack of a standard means for representing inherited associations in
class diagrams is thus resulting in a proliferation of non-standard
approaches in adopted OMG metamodels. This could become unmanageable as the
number of metamodels grows. A standard means should be specified. -
Reported: UML 1.3 — Mon, 3 Jul 2000 04:00 GMT
-
Disposition: Resolved — UML 1.4.2
-
Disposition Summary:
No Data Available
-
Updated: Fri, 6 Mar 2015 20:58 GMT