UMLR — OccurrenceSpecification should have at least an optional notation

Until UML 2.3, OccurrenceSpecification (OS) was an abstract superclass for the concrete occurrence specifications MessageOccurrenceSpecificatio (MOS) and ExecutionOccurrenceSpecification (EOS). In UML 2.3 OS became concrete. This apparently subtle change has a significant impact of the usage of domain-specific events in Interaction. A user can now place an OS along a lifeline directly, instead of using using the already existent ActionExecutionSpecification or BehaviorExecutionSpecification. This eases the definition of domain-specific occurrence specifications (let's call it events from henceforth) by defining stereotypes directly for an OS.

For example, in the UML Testing Profile, there are some test-specific events (e.g. ValidationAction, a sterotype for CallOperationAction) which can be used inside Interaction. Until UML 2.3 the steps for including such a domain-specific actions in Interactions have been the following:

1. Create an Action and let it being contained by the Interaction
2. Configure that Action and apply the corresponding stereotype
3. Create the ActionExecutionSpecification
4. Create the EOS as the start EOS and link the ActionExecutionSpecification with the EOS
5.Create the EOS as the finish EOS and link the ActionExecutionSpecification with the EOS
6. Link the ActionExecutionSpecification with the Action

The whole procedure involved a lot of very fine-grained and subtled concepts and requires an advanced knowledge of the Interactions metamodel (frankly, only few tools support this complex procedure).

Since UML 2.4, the steps are reduced to the following one:
1. Create an OccurrenceSpecification on a lifeline
2. Apply a stereotype to the OS and configurethe OS

The stereotyped OS assumes the semantics provided by the domain-specific OS (in UTP ValidationOccurrenceSpecification). This reduces the complexity of integrating such domain-specific events, reduces the memory foorprint and eases the handling and creation of interactions containing such stereotyped OS.

The problem is that OS does not declare a national representation, and we doubt that this concept will be provided by tools if there is not standardized representation.

Therefore, we suggest to define a (at least optional) notation for OS as a rectangle or rounded rectangle with a compartment for stereotype visualization and a compartment for an optional label (name of the OS or an expression within the stereotype).

This change would not affect the XMI or metamodel, but has a significant impact of the way interaction are perceived and created.