> 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]

Reply via email to