Thanks for your help, now all is clear. I already has fixed the problems. Very thanks again.
2007/7/12, Tom Morris <[EMAIL PROTECTED]>:
> I've discovered what is happening with the events and what > are the valid values for property names. > If I'm wrong please ping me. You've got it basically right. The property names are either the name of an attribute from the metamodel or the special string "remove". > So, the problem now is to test if the propertyNames for > Association Ends and attributes of elements are the same in > MDR and Eclipse UML2. Actually the question is "Are the attribute names the same between the UML 1.4 and the UML 2.1.1 metamodels?" and the answer is "Most definitely not." We could attempt to abstract this so that ArgoUML sees the same property names for both metamodels, but usually when the name has been changed, some aspect of the behavior or semantics has changed, so I'm not sure this would be a useful exercise. > because the AssociationEvent (from MDR) has no source code or javadoc. > The events are using AssociationEvent#getNewElement(), > AssociationEvent#getEndName(), AssociationEvent#getFixedElement(), > which I do not know what are doing. Javadoc is here http://www.netbeans.org/download/dev/javadoc/org-netbeans-api-mdr/org/netbea ns/api/mdr/events/AssociationEvent.html Source is at http://mdr.netbeans.org/source/browse/mdr/ There's a non-obvious aspect of the implementation to watch out for. When I was trying to get the MDR event pump implementation to work, it appeared that parts of ArgoUML were expecting AttributeChangeEvents for changes to associations. Also MDR only reports an association change event on one end of the association and there appeared be code in ArgoUML that was listening for the property name on the other end. I took a brute force approach to solving these problems, creating multiple variants of the events so that all possible listeners would get invoked. Association{Add|Remove}Events are duplicated as AttributeChangeEvents and we also look up the name of the opposite AssociationEnd and create events with that name too. One other thing to be aware of is that there may be parts of ArgoUML which are registering for events which will never get delivered because the names don't exist in the metamodel. I started to add some code to verify event registrations against the metamodel, but it isn't complete. I would recommend that you implement this for the UML 2.1.1 metamodel (presuming that you can access it through EMF) so that you'll know where there are pieces of ArgoUML depending on UML 1.4 (or even UML 1.3) names which don't exist in the UML 2.1.1 metamodel. > DeleteInstanceEvent uses the source UML element (the notifier) and a > property name (a string) that in some parts of ArgoUML is expected to > be "remove" and in other parts it doesn't matter it's value, the only > test done is if the event is instance of DeleteInstanceEvent. The code that is looking for the string "remove" is left over from the NSUML (UML 1.3 model library) implementation. It should probably be updated to look for DeleteInstanceEvents (but it still needs to know to register for the "remove" property name, so this isn't really as opaque as it could be). Let me know if any of this is unclear. Tom --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
