Issue 16572: OccurrenceSpecification should have at least an optional notation (uml2-rtf) Source: Fraunhofer FOKUS (Mr. Marc-Florian Wendland, marc-florian.wendland(at)fokus.fraunhofer.de) Nature: Revision Severity: Significant Summary: 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. Resolution: Revised Text: Actions taken: September 29, 2011: received issue Discussion: End of Annotations:===== m: webmaster@omg.org Date: 29 Sep 2011 03:43:01 -0400 To: Subject: Issue/Bug Report ******************************************************************************* Name: Marc-Florian Wendland Employer: Fraunhofer FOKUS mailFrom: marc-florian.wendland@fokus.fraunhofer.de Terms_Agreement: I agree Specification: UML Superstructure Section: 14.3.23 FormalNumber: ptc/2010-11-14 Version: 2.4 Doc_Year: 2011 Doc_Month: January Doc_Day: 01 Page: 5011 f. Title: OccurrenceSpecification should have at least an optional notation Nature: Revision Severity: Significant CODE: 3TMw8 B1: Report Issue Description: 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.