Prevent creating message view when one exists in extended/reused model

[Céline Bensoussan]

It is possible for a user to create a message view for an operation that already has a message view defined in an extended or reused model.

There should be a warning or a way to prevent a user from doing so.

[Matthias Schoettle]

#390 covers mapped operations. In case of extended models, I don't think it should be possible to replace operations from the extended model (i.e., by creating the exact same operation in the extending model). So for extended models I think renaming is usually done, which would mean the operation is mapped (covered by my fix in #390).

Or is there another use case that I didn't consider?

[Céline Bensoussan]

If you do not allow the creation of the exact same operation in an extending model, how would you be able to create an aspect message view that advises the operation ? Or would you allow the creation of the operation but prevent the creation of a message view if the operation already exists in an extended model ?

Other than that, I think that covers the cases I can think about.

[Matthias Schoettle]

At least right now, when an operation and message view already exists, a MessageViewReference is used, which references that message view and adds the advice (which is in the same model as the MessageViewReference, i.e., the extending model).

Of course, that only works if a message view was defined for that operation in the extended model.

[Matthias Schoettle]

Issue #395 was marked as a duplicate of this issue.

[Matthias Schoettle]

References #396: Adds tests for aspect message view creation.

→ <<cset 67021ceb99c7>>

[Matthias Schoettle]

References #396: Updates definition of isMessageViewDefined.

Also, adds getMappedFrom operation to return a mapped operation.

A message view is considered to be defined, if it actually exists in the current model. Or, if the operation is mapped and the "from" operation is not partial. This means that the message view has to be defined in the other model. I.e., the message view in the other model might not actually exist yet, but isMessageViewDefined still returns true.

→ <<cset e5c5dbaa847b>>

[Matthias Schoettle]

Resolves #396: Adds the creation of MessageViewReference when creating an AspectMessageView.

When the message view already exists, a MessageViewReference is created, instead of creating a new MessageView. If the MessageView should exist in another model, but it doesn't, an exception is thrown.

→ <<cset b989b3552da8>>

[Matthias Schoettle]

References #396: Adds error handling to handler when advicing operations.

→ <<cset dc6377191210>>

[Matthias Schoettle]

References #396: Ensures that existing reference is further adviced.

When a MessageViewReference already exists, it should be further adviced instead of another one being created. Adds a test case and fixes the controller method.

→ <<cset 69a9641c7f3e>>

[Matthias Schoettle]

References #396, #373: Adds check to also find existing MessageViewReference and adds selector.

When advicing, checks for an existing MessageView or MessageViewReference and displays any existing AspectMessageView or creates a new one. If at least one exists, a selector allows to open a specific AspectMessageView or create another one.

→ <<cset abec00e99bed>>