I just had a quick look and
org.argouml.model.euml.ModelEventPumpEUMLImpl.mapPropertyName(String)
is basically unimplemented, so I wouldn't expect anything with a name
change between UML 1.4 and UML 2.x to work (lots of stuff, probably).

Here's the current implementation (note the big TODO):

    private String mapPropertyName(String name) {
        // TODO: map UML2 names to UML1.x names
        if (name.equals("ownedAttribute")) { //$NON-NLS-1$
            return "feature"; //$NON-NLS-1$
        }
        return name;
    }

The other thing I noticed right off the bat is that all of the debug
stuff that I implemented for MDR like
org.argouml.model.mdr.ModelEventPumpMDRImpl.verifyAttributeNames(RefObject,
String[]), which checks to make sure that the event that's being
registered for is actually one which is valid for the current
metamodel, is missing for eUML.  I added this late in the process for
the UML 1.3 to 1.4 transition and regretted not having done it
earlier.  I'd recommend that this get moved to the head of the queue
for implementation priorities.  It's very useful in helping to debug
missing/incorrect mappings, bad client code, etc.

Tom

On Thu, Apr 8, 2010 at 12:47 PM, Tom Morris <[email protected]> wrote:
> On Thu, Apr 8, 2010 at 10:13 AM, Bob Tarling <[email protected]> wrote:
>
>> I've been trying to resolve issue 6056 but I'm getting lost between
>> the notation, fig and model event pump of the euml implementation.
>>
>> Certainly the Fig is not receiving an event when the multiplicity
>> changes in the model but is this wrong registration of the listener,
>> event pump not working or are we dropping and reattaching listeners
>> too often and so losing the event?
>>
>> If anyone can help here I'd be grateful as this is about the last UML2
>> problem that I'm aware of in class diagrams.
>
> I'm afraid I can't help directly.  Any free time I get I'm going to
> try and put into fixing the MDR profile problem (I've got a pretty
> clear picture of the problem, but need to generate a patch).
>
> Having said that, here are some ideas on debug strategy:
>
> - There is debug logging for event registration and unregistration.
> Enabling it should give you an idea if the right registrations are
> being made.
> - If metamodel properties/attributes have different names in UML2 they
> need to be mapped back to the UML 1.4 names for things to work with
> unchanged client code.  You can investigate whether this might be the
> issue by comparing the two metamodels (or specs) for the metaclass of
> interest.
> - As a last resort, modifying the event delivery code to include some
> conditional code for the specific event that you're looking for an
> either adding extra logging or just setting a breakpoint might give
> more insight into where an event is getting swallowed/ignored.
>
> Hope that helps.
>
> Tom
>

------------------------------------------------------
http://argouml.tigris.org/ds/viewMessage.do?dsForumId=450&dsMessageId=2524782

To unsubscribe from this discussion, e-mail: 
[[email protected]].
To be allowed to post to the list contact the mailing list moderator, email: 
[[email protected]]

Reply via email to