Issue 18131: 17 Semantics of interactions (uml25-ftf) Source: NASA (Dr. Nicolas F. Rouquette, nicolas.f.rouquette(at)jpl.nasa.gov) Nature: Uncategorized Issue Severity: Summary: 17 Semantics of interactions (missing constraints for resolving Operations, Signals and Actions in MessageOccurrenceSpecifications & ExecutionOccurrenceSpecifications in the scope of the Interaction itself) Consider Figure 17.2 (in the UML2.5 Revised August draft): Clearly we expect that: "oper1()" is a Message whose Message::signature refers to A::oper1() "callback()" is a Message whose Message::signature refers to C::callback() However, there is nothing in the spec that constrains the ownership of a Message::signature : NamedElement relative to the Interaction context of that Message. In fact, other possible interpretations because UML does not prescribe a particular resolution process for determining the Behavior for a given BehavioralFeature or Reception (see section 13.2.3) The spec does not currently specify any kind of bound on this resolution process — that is, Behaviors could be found potentially anywhere in the model. This is obviously absurd: it is unreasonable to expect that Figure 17.2 corresponds to a model where neither A nor C define "oper1()" or "callback()" but rather that these 2 operations are defined in an completely unrelated class not involved in the interaction at all -- e.g., B. Resolution: Revised Text: Actions taken: October 2, 2012: received issue Discussion: From: <Wendland>, Marc-Florian <marc-florian.wendland@fokus.fraunhofer.de> Date: Tuesday, October 2, 2012 12:02 AM To: JPL <nicolas.f.rouquette@jpl.nasa.gov>, "uml-spec-simplification@omg.org" <uml-spec-simplification@omg.org> Subject: AW: 17 Semantics of interactions (missing constraints for resolving Operations, Signals and Actions in MessageOccurrenceSpecifications & ExecutionOccurrenceSpecifications in the scope of the Interaction itself) Hi Nicolas, I don’t think that this has been filed yet. I flicked briefly through the Interaction-related issues in preparation for my contribution to FTF. However, I might have overlooked something, of course. Anyway, I agree that there is a need for more clarification on this, however, I don’t think that this is a trivial thing due to the very flexible concepts of Messages etc. There are several possibilities where those Operations can be located, respectively what Operations are actually invokable via that Message. Possible locations for any invoked BehavioralFeatures <!--[if !supportLists]-->1. <!--[endif]-->Directly owned or inherited by the Type of the ConnectableElement the Lifeline represents (simplest possibility) <!--[if !supportLists]-->2. <!--[endif]-->Directly owned or inherited by the Type of a Port of the ConnectableElement the Lifeline represents <!--[if !supportLists]-->3. <!--[endif]-->Directly owned or inherited by a realized (via InterfaceRealization) Interface of the Type of a Port of the ConnectableElement the Lifeline represents – we are using this kind of BehavioralFeature offering a lot when modeling test architectures with UTP Offered BehavioralFeatures for a Message sent via Connector <!--[if !supportLists]-->4. <!--[endif]-->If the Message is send via a specific Connector that is connected to a Port (e.g., owned by C), only those BehavioralFeatures are allowed to be invoked by the Message which are offered by the Type of the Port that is connected by the Connector over which the Message is sent – we are using this kind of Message sending when modeling test cases with UTP that can be executed via TTCN-3 or JUnit etc. These are just four possible ways on how to determine the offered BehavioralFeature of a called Lifeline. I guess there are even more. In any case, your statement “This is obviously absurd: it is unreasonable to expect that Figure 17.2 corresponds to a model where neither A nor C define "oper1()" or "callback()" but rather that these 2 operations are defined in an completely unrelated class not involved in the interaction at all -- e.g., B.” Is not absurd, but for what we doing a normal matter of fact. In that case B would be a (I call them InterfaceComponent, simply a Type of a Port that realizes Interfaces) Type of a Port that is connected with a Connector over which the Message is sent. But I agree: There is a need to identify and clarify all possibilities for invoking a Behavior. Regards, Marc-Florian End of Annotations:===== iler: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 02 Oct 2012 14:23:09 -0400 To: issues@omg.org, uml25-ftf@omg.org From: Juergen Boldt Subject: issue 18131 -- UML 2.5 FTF issue From: "Rouquette, Nicolas F (313K)" To: "issues@omg.org" CC: "Wendland, Marc-Florian" , Steve Cook Subject: UML2.5 issue in clause 17 Semantics of interactions (missing constraints for resolving Operations, Signals and Actions in MessageOccurrenceSpecifications & ExecutionOccurrenceSpecifications in the scope of the Interaction itself) Thread-Topic: UML2.5 issue in clause 17 Semantics of interactions (missing constraints for resolving Operations, Signals and Actions in MessageOccurrenceSpecifications & ExecutionOccurrenceSpecifications in the scope of the Interaction itself) Thread-Index: AQHNnaULudE+Xe1KdUyBbtebIrdf0Zelk3zggADC1AA= Date: Tue, 2 Oct 2012 18:07:43 +0000 Accept-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.4.120824 x-originating-ip: [128.149.137.114] X-Source-Sender: nicolas.f.rouquette@jpl.nasa.gov X-AUTH: Authorized Juergen, Please file the last message as an issue for UML 2.5 and attach Marc's reply to the discussion of that issue. - Nicolas. From: , Marc-Florian < marc-florian.wendland@fokus.fraunhofer.de> Date: Tuesday, October 2, 2012 12:02 AM To: JPL < nicolas.f.rouquette@jpl.nasa.gov>, " uml-spec-simplification@omg.org" < uml-spec-simplification@omg.org> Subject: AW: 17 Semantics of interactions (missing constraints for resolving Operations, Signals and Actions in MessageOccurrenceSpecifications & ExecutionOccurrenceSpecifications in the scope of the Interaction itself) Hi Nicolas, I don.t think that this has been filed yet. I flicked briefly through the Interaction-related issues in preparation for my contribution to FTF. However, I might have overlooked something, of course. Anyway, I agree that there is a need for more clarification on this, however, I don.t think that this is a trivial thing due to the very flexible concepts of Messages etc. There are several possibilities where those Operations can be located, respectively what Operations are actually invokable via that Message. Possible locations for any invoked BehavioralFeatures 1. Directly owned or inherited by the Type of the ConnectableElement the Lifeline represents (simplest possibility) 2. Directly owned or inherited by the Type of a Port of the ConnectableElement the Lifeline represents 3. Directly owned or inherited by a realized (via InterfaceRealization) Interface of the Type of a Port of the ConnectableElement the Lifeline represents . we are using this kind of BehavioralFeature offering a lot when modeling test architectures with UTP Offered BehavioralFeatures for a Message sent via Connector 4. If the Message is send via a specific Connector that is connected to a Port (e.g., owned by C), only those BehavioralFeatures are allowed to be invoked by the Message which are offered by the Type of the Port that is connected by the Connector over which the Message is sent . we are using this kind of Message sending when modeling test cases with UTP that can be executed via TTCN-3 or JUnit etc. These are just four possible ways on how to determine the offered BehavioralFeature of a called Lifeline. I guess there are even more. In any case, your statement .This is obviously absurd: it is unreasonable to expect that Figure 17.2 corresponds to a model where neither A nor C define "oper1()" or "callback()" but rather that these 2 operations are defined in an completely unrelated class not involved in the interaction at all -- e.g., B.. Is not absurd, but for what we doing a normal matter of fact. In that case B would be a (I call them InterfaceComponent, simply a Type of a Port that realizes Interfaces) Type of a Port that is connected with a Connector over which the Message is sent. But I agree: There is a need to identify and clarify all possibilities for invoking a Behavior. Regards, Marc-Florian Von: Rouquette, Nicolas F (313K) [ mailto:nicolas.f.rouquette@jpl.nasa.gov] Gesendet: Freitag, 28. September 2012 20:14 An: uml-spec-simplification@omg.org Betreff: 17 Semantics of interactions (missing constraints for resolving Operations, Signals and Actions in MessageOccurrenceSpecifications & ExecutionOccurrenceSpecifications in the scope of the Interaction itself) This question came up in a forum at NASA's Systems Engineering "early adopters" group (folks from several NASA centers) Consider Figure 17.2 (in the UML2.5 Revised August draft): Clearly we expect that: "oper1()" is a Message whose Message::signature refers to A::oper1() "callback()" is a Message whose Message::signature refers to C::callback() However, there is nothing in the spec that constrains the ownership of a Message::signature : NamedElement relative to the Interaction context of that Message. In fact, other possible interpretations because UML does not prescribe a particular resolution process for determining the Behavior for a given BehavioralFeature or Reception (see section 13.2.3) The spec does not currently specify any kind of bound on this resolution process . that is, Behaviors could be found potentially anywhere in the model. This is obviously absurd: it is unreasonable to expect that Figure 17.2 corresponds to a model where neither A nor C define "oper1()" or "callback()" but rather that these 2 operations are defined in an completely unrelated class not involved in the interaction at all -- e.g., B. Has this issue already been filed? - Nicolas. image00131.png Juergen Boldt Director, Member Services 140 Kendrick Street, Building A Suite 300 Needham, MA 02494 USA Tel: 781 444 0404 x 132 fax: 781 444 0320 www.omg.org