Issue 12455: Section 14 Interaction (uml2-rtf) Source: (, ) Nature: Revision Severity: Significant Summary: As it is intended by the current specification, an Interaction may be modeled independent of any BehavioredClassifier, which owns it. This would e.g. allow to use Interactions to model communication between analysis objects at a very early analysis stage, where no classes have been designed yet. The intention is manifested in the specification by allowing that a Lifeline or Messages does not have to specify a Property (Multiplicity of 0..1 of Lifelines->represents) or a Connector (Multiplicity of 0..1 of Message->connector) respectively (and that an Interaction does not have to be owned by a BehavioredClassifier). However, the restriction that every OccurrenceSpecification, and as such also every MessageOccurenceSpecification has to be associated with an event (compare Figure 14.5 on page 462) prevents that an Interaction may be used in above described manner. The reason for this is is as follows: 1) As the absense of a MessageEnd has another semantics (the MessageKind is inferred from it), in above described scenario, MessageEnds should indeed be specified (a complete message would be the only appropriate kind to model communication between objects as in above described scenario) 2) Because of above described multiplicity constraint, the MessageOccurenceSpecifications serving as sendEvent and receiveEvent of the message have to refer to some SendSignalEvent/ReceiveSignalEvent or SendOperationEvent/ReceiveOperationEvent respectively. 3) Those events in turn require to specify a Signal or Operation (see Figure 14.2 on page 459). 4) The Signal or Operation would have to be owned by some Classifier. There is however no Classifier in above described scenario, with exception of the Interaction itself (adding the Signals or Operations to the Interaction itself, would however require that all Signals and Operations are named unique, which is inappropriate). I would thus propose to change the specification, so that MessageOccurenceSpecifications (or OccurenceSpecifications) may, but do not have to specify an event (i.e. change multiplicity from 1 to 0..1). Resolution: Revised Text: Actions taken: May 14, 2008: received issue Discussion: End of Annotations:===== m: webmaster@omg.org Date: 14 May 2008 03:30:58 -0400 To: Subject: Issue/Bug Report -------------------------------------------------------------------------------- Name: Alexander Nyßen Company: Research Group Software Construction, RWTH Aachen mailFrom: any@informatik.rwth-aachen.de Notification: Yes Specification: OMG Unified Modeling Language (OMG UML), Superstructure, V2.1.2 Section: 14 FormalNumber: 07-11-01 Version: 2.1.1 RevisionDate: 01/11/07 Page: 462 Nature: Revision Severity: Significant HTTP User Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; SLCC1; .NET CLR 2.0.50727; .NET CLR 3.0.04506; .NET CLR 1.1.4322) Description As it is intended by the current specification, an Interaction may be modeled independent of any BehavioredClassifier, which owns it. This would e.g. allow to use Interactions to model communication between analysis objects at a very early analysis stage, where no classes have been designed yet. The intention is manifested in the specification by allowing that a Lifeline or Messages does not have to specify a Property (Multiplicity of 0..1 of Lifelines->represents) or a Connector (Multiplicity of 0..1 of Message->connector) respectively (and that an Interaction does not have to be owned by a BehavioredClassifier). However, the restriction that every OccurrenceSpecification, and as such also every MessageOccurenceSpecification has to be associated with an event (compare Figure 14.5 on page 462) prevents that an Interaction may be used in above described manner. The reason for this is is as follows: 1) As the absense of a MessageEnd has another semantics (the MessageKind is inferred from it), in above described scenario, MessageEnds should indeed be specified (a complete message would be the only appropriate kind to model communication between objects as in above described scenario) 2) Because of above described multiplicity constraint, the MessageOccurenceSpecifications serving as sendEvent and receiveEvent of the message have to refer to some SendSignalEvent/ReceiveSignalEvent or SendOperationEvent/ReceiveOperationEvent respectively. 3) Those events in turn require to specify a Signal or Operation (see Figure 14.2 on page 459). 4) The Signal or Operation would have to be owned by some Classifier. There is however no Classifier in above described scenario, with exception of the Interaction itself (adding the Signals or Operations to the Interaction itself, would however require that all Signals and Operations are named unique, which is inappropriate). I would thus propose to change the specification, so that MessageOccurenceSpecifications (or OccurenceSpecifications) may, but do not have to specify an event (i.e. change multiplicity from 1 to 0..1). Subject: RE: issue 12455 -- UML 2 RTF issue Date: Wed, 14 May 2008 12:56:26 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: issue 12455 -- UML 2 RTF issue thread-index: Aci12SqjoJafai4aR+mkmIgDhjjM4AACg78g From: "Ed Seidewitz" To: Actually, I signal is a classifier and doesn.t have to be owned by anything. It seems to me that, if you are modeling the sending of a message, then you are modeling that something is being sent. This .something. can be modeled as a signal, even if, at an early stage of analysis, this is just a placeholder for more detail to be added later. -- Ed -------------------------------------------------------------------------------- From: Juergen Boldt [mailto:juergen@omg.org] Sent: Wednesday, May 14, 2008 11:14 AM To: issues@omg.org; uml2-rtf@omg.org Subject: issue 12455 -- UML 2 RTF issue From: webmaster@omg.org Date: 14 May 2008 03:30:58 -0400 To: Subject: Issue/Bug Report -------------------------------------------------------------------------------- Name: Alexander Nyßen Company: Research Group Software Construction, RWTH Aachen mailFrom: any@informatik.rwth-aachen.de Notification: Yes Specification: OMG Unified Modeling Language (OMG UML), Superstructure, V2.1.2 Section: 14 FormalNumber: 07-11-01 Version: 2.1.1 RevisionDate: 01/11/07 Page: 462 Nature: Revision Severity: Significant HTTP User Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; SLCC1; .NET CLR 2.0.50727; .NET CLR 3.0.04506; .NET CLR 1.1.4322) Description As it is intended by the current specification, an Interaction may be modeled independent of any BehavioredClassifier, which owns it. This would e.g. allow to use Interactions to model communication between analysis objects at a very early analysis stage, where no classes have been designed yet. The intention is manifested in the specification by allowing that a Lifeline or Messages does not have to specify a Property (Multiplicity of 0..1 of Lifelines->represents) or a Connector (Multiplicity of 0..1 of Message->connector) respectively (and that an Interaction does not have to be owned by a BehavioredClassifier). However, the restriction that every OccurrenceSpecification, and as such also every MessageOccurenceSpecification has to be associated with an event (compare Figure 14.5 on page 462) prevents that an Interaction may be used in above described manner. The reason for this is is as follows: 1) As the absense of a MessageEnd has another semantics (the MessageKind is inferred from it), in above described scenario, MessageEnds should indeed be specified (a complete message would be the only appropriate kind to model communication between objects as in above described scenario) 2) Because of above described multiplicity constraint, the MessageOccurenceSpecifications serving as sendEvent and receiveEvent of the message have to refer to some SendSignalEvent/ReceiveSignalEvent or SendOperationEvent/ReceiveOperationEvent respectively. 3) Those events in turn require to specify a Signal or Operation (see Figure 14.2 on page 459). 4) The Signal or Operation would have to be owned by some Classifier. There is however no Classifier in above described scenario, with exception of the Interaction itself (adding the Signals or Operations to the Interaction itself, would however require that all Signals and Operations are named unique, which is inappropriate). I would thus propose to change the s .)1..0 ot 1 morf yticilpitlum egnahc .e.i( tneve na yficeps ot evah ton od tub ,yam )snoitacificepSecneruccO ro( snoitacificepSecneruccOegasseM taht os ,noitacificep Juergen Boldt Director, Member Services Object Management Group 140 Kendrick St Building A Suite 300 Needham, MA 02494 USA tel: +1 781 444 0404 x 132 fax: +1 781 444 0320 email: juergen@omg.org www.omg.org