Community
Participate
Working Groups
Investigate possibility of modelling an association between two classes so that the classes are not modified.
Created attachment 86765 [details] Patterns used to model different types of binary associations Looking at the CMOF specification it looks like it only specifies support for binary associations so I won't concern myself with n-ary assocations where n > 2. The attachment is a complete generated project. The interesting part is the Association.ecore in the the model folder. Note that the derived relationships are not properly implemented in the generated code. I'm hoping to specify the derived relationship in a declarative way to ensure that these models will work dynamically as well as statically. E.g., for the two owned ends pattern the "a" feature of the ABLink is derived from aBMapEntry/a, i.e., traverse the abMapEntry container feature and return the a feature of that. I'll try to write some decent documentation, likely in the form of a blog: http://www.ed-merks.blogspot.com/
The specific blog entry describing the design is http://ed-merks.blogspot.com/2008/01/modeling-associations-with-ecore.html
Thanks, Ed. I've updated the UML2 bug with the equivalent UML model. In order to support (bidirectional) conversion to/from UML, here are some issues that would need to be addressed: - we still need metadata (even if it's an annotation) to indicate that the Ecore link/association classes actually represent associations in CMOF/UML; I don't think we can rely on naming conventions - the reference names in the end type classes do not match the names in the link classes (the former are plural whereas the latter are not) - the serialization format for the patterns that involve association classes is inconsistent with the patterns that involve just link classes; more importantly, though, the serialization format for the patterns that involve association classes (and map entry classes) don't match what one might expect (i.e. an element for each link, with attributes that reference the objects involved)
I've created a bugzilla to start investigating support for specifying the behavior of a derived features in https://bugs.eclipse.org/bugs/show_bug.cgi?id=216701 since that will be necessary to support the types of derived features in the patterns we use here. With regard to the three issues Kenn listed below. The first, the round tripping of CMOF/UML, is not an EMF issue so the convention or annotation for supporting this can be defined by UML itself. The second issue is of the same ilk. The serialization issue is more interesting. In a sense, I don't really care that it doesn't serialize that way one might expect. It can be argued that links are being serialized and that having transient features that don't serialize is reasonable and not actually a deviation from the XMI specification; it's not a strong argument. It can also be argued that the serialization that's naturally produced is reasonable and perhaps even desirable since it avoids duplicating references to the A and B instances; each is mentioned only once as the key of its corresponding map entry. This is a much stronger argument. It's also clearly possible to produce the map structure given only a series of links and to produce such a serialization given the structure we have. Serialization is the simpler of the two problems. I'm not sure we really have a lot of examples where the exchange of serialized links is needed, so I can't make this a high priority issue to address. The enabling of derived features seems the most important thing at this point, so that will be addressed in the other bugzilla.
OK. Perhaps, as an EMF committer, I'll make the remaining changes myself. Here's what I propose: - annotate association classes with an annotation of source 'http://www.eclipse.org/emf/2002/Ecore#//EAssociation' and link classes with an annotation of source 'http://www.eclipse.org/emf/2002/Ecore#//ELink' - add new save and load options to XMIResource that, when used, will serialize/deserialize instances of link classes as root elements (and treat instances of association classes as transient) I'll try to find some spare time to put together a patch for review...
It would seem to make more sense to use some kind of UML or CMOF URI since this really has nothing directly to do with EMF. Now do you deal with other kinds of information that's lost when doing UML -> Ecore -> UML?
Created attachment 152328 [details] preliminary patch, originally attached to bug 216701
I think there is no real significant interest in this going forward.
