Issue 18528: Interactions needs to fix Gate name Distinguishability rules (uml25-ftf) Source: Fujitsu (Mr. Tom Rutt, tom(at)coastin.com) Nature: Revision Severity: Summary: The isDistingishableFrom() operation of NamedElement needs to be overridden for Gate class to cover the case of when the gate is used as a formalGate of an Interaction. The association end formalGate subsets ownedElement, and since the Gate name attribute is optional, it is allowed to have two formal gates without an explicit name, but having derived names which are distinct. Even though the gate matching rules do not use this operation, we need to override it to avoid problems. In addition to this fix, there is a also need to add constraints to the gate names used for Gates for the gate matching rules to work properly. In particular, there are cases in use of gates which require distinction for the gate matching rules to work. Thus there is still a need to add new constraints on gate Names (explicit or derived). Because Gates which do not have an explicity name attribute have derived names, any constraint must include the possibility of these derived names. There is an explicit operation getGateName() on Gate class which returns the name of the gate which is to be used in the gate matching rules. If a gate does not have an explicit name attribute, a gate name is derived from the name of the message the gate is attached to , and the direction of the message with respect to the gate (e.g, foo_in, foo_out). The direction "in" or "out" is considered with respect to the outer perimeter of the interaction fragment that the gate is attached to. UML 2.5 added Gate matching rules in OCL, using this getGateName() operation, however there are currently no gate name distinguishably constraints in the spec. Two gates in the same container may have duplicate derived names, just because they are attached to two different messages, with the same direction, which happen to have the same name. There are cases when the gate matching rules will not work unless at least one of these gates needs includes an explicit name attribute value contrived to avoid the collision of the getGateNames() operation. The association end formalGates of Interaction subset ownedMember, and, as already stated above, we have to override the isDistinguisableFrom() operator for gate class. However, If there were two formal Gates with the same gate name in an interaction, the gate matching rules would become invalid. The association ends actualGates of InteractionUse, and cFragmentGates of CombinedFragment, both subset ownedElement, not ownedMember. So they no not need to obey the isDistinguisableFrom test. However, even though not required for the UML namespace Rules, actual Gates for an InteractionUse should have distinguishable gate names, in order for the gate matching rules to work. For the same reason, If a cFragmentGate is outside the CombinedFragment, then it must be distinguishable from other outer cFragmentGates of that same CombinedFragment. For the same reason, any two inner cFragmentGates associated with the same InteractionOperator of a CombinedFragment must have distinguished gate names. Thus we need to add a set of four constraints (one for each kind of gate) to the Gate class. Adding these four constraints will ensure that the gate matching rules work correctly. Proposed Change: Override the isDistinguishableFrom() operation of Gate to always return true. Add the following four new constraints to the Gate class. These rely on the four existing boolean operators of the Gate class which are used to determine in which of the four contexts of association that the gate is an instance of. formal_gate_distinguishable isFormal() implies <test that no other formal gate of the parent Interaction returns the same getGateName() as returned for self> actual_gate_distinguishable isActual() implies <test that no other actual gate of the parent InteractionUse returns the same getGateName() as returned for self> outside_cf_gate_distinguishable isOutsideCF() implies <test that no other outside cf gate of the parent CombinedFragment returns the same getGateName() as returned for self> inside_cf_gate_distinguishable isInsideCF() implies <test that no other inside cf gate attached to a message with its other end in the same InteractionOperator as self returns the same getGateName() as returned for self> I leave the detailed OCL for the actual OCL to include within the < > for the actual resolution of this issue. Resolution: Revised Text: Actions taken: March 5, 2013: received issue Discussion: End of Annotations:===== te: Tue, 05 Mar 2013 14:10:44 -0500 From: Tom Rutt User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 To: "issues@omg.org" , Juergen Boldt , Tom Rutt Subject: Please add this as a new UML 2.5 FTF issue for Chapter 17. X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - neptune.host4u.net X-AntiAbuse: Original Domain - omg.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - coastin.com X-Get-Message-Sender-Via: neptune.host4u.net: authenticated_id: tom@coastin.com X-Virus-Scanned: amavisd-new at omg.org X-Brightmail-Tracker: AAAAAA== X-Brightmail-Tracker: AAAAAA== OMG Issue: nnnnn Title: Interactions needs to fix Gate name Distinction rules UML 2.5 FTF. Source: Tom Rutt (Fujitsu) Summary: The isDistinguishableFrom() operation of NamedElement needs to be overridden for Gate class to cover the case of when the gate is used as a formalGate of an Interaction. The association end formalGate subsets ownedElement, and since the Gate name attribute is optional, it is allowed to have two formal gates without an explicit name, but having derived names which are distinct. Even though the gate matching rules do not use this operation, we need to override it to avoid problems. In addition to this fix, there is a also need to add constraints to the gate names used for Gates for the gate matching rules to work properly. In particular, there are cases in use of gates which require distinction for the gate matching rules to work. Thus there is still a need to add new constraints on gate Names (explicit or derived). Because Gates which do not have an explicity name attribute have derived names, any constraint must include the possibility of these derived names. There is an explicit operation getGateName() on Gate class which returns the name of the gate which is to be used in the gate matching rules. If a gate does not have an explicit name attribute, a gate name is derived from the name of the message the gate is attached to , and the direction of the message with respect to the gate (e.g, foo_in, foo_out). The direction "in" or "out" is considered with respect to the outer perimeter of the interaction fragment that the gate is attached to. UML 2.5 added Gate matching rules in OCL, using this getGateName() operation, however there are currently no gate name distinguishably constraints in the spec. Two gates in the same container may have duplicate derived names, just because they are attached to two different messages, with the same direction, which happen to have the same name. There are cases when the gate matching rules will not work unless at least one of these gates needs includes an explicit name attribute value contrived to avoid the collision of the getGateNames() operation. The association end formalGates of Interaction subset ownedMember, and, as already stated above, we have to override the isDistinguisableFrom() operator for gate class. However, If there were two formal Gates with the same gate name in an interaction, the gate matching rules would become invalid. The association ends actualGates of InteractionUse, and cFragmentGates of CombinedFragment, both subset ownedElement, not ownedMember. So they no not need to obey the isDistinguisableFrom test. However, even though not required for the UML namespace Rules, actual Gates for an InteractionUse should have distinguishable gate names, in order for the gate matching rules to work. For the same reason, If a cFragmentGate is outside the CombinedFragment, then it must be distinguishable from other outer cFragmentGates of that same CombinedFragment. For the same reason, any two inner cFragmentGates associated with the same InteractionOperator of a CombinedFragment must have distinguished gate names. Thus we need to add a set of four constraints (one for each kind of gate) to the Gate class. Adding these four constraints will ensure that the gate matching rules work correctly. Proposed Change: Override the isDistinguishableFrom() operation of Gate to always return true. Add the following four new constraints to the Gate class. These rely on the four existing boolean operators of the Gate class which are used to determine in which of the four contexts of association that the gate is an instance of. formal_gate_distinguishableisFormal() implies actual_gate_distinguishableisActual() implies outside_cf_gate_distinguishableisOutsideCF() implies inside_cf_gate_distinguishableisInsideCF() implies I leave the detailed OCL for the actual OCL to include within the < > for the actual resolution of this issue. -- ---------------------------------------------------- Tom Rutt email: tom@coastin.com; trutt@us.fujitsu.com Tel: +1 732 801 5744 Fax: +1 732 774 5133 From: Steve Cook To: "Tom Rutt (tom@coastin.com)" CC: "" Subject: RE: [UML 2.5 FTF] Ballot 6 - Preview 3 --- PLEASE READ Thread-Topic: [UML 2.5 FTF] Ballot 6 - Preview 3 --- PLEASE READ Thread-Index: AQHOZkGtDoMwSRGn8Uuv7tMvoXWwm5kwd4iA Date: Tue, 11 Jun 2013 12:53:39 +0000 Accept-Language: en-GB, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.166.18.103] X-Forefront-Antispam-Report: CIP:131.107.125.37;CTRY:US;IPV:CAL;IPV:NLI;EFV:NLI;SFV:NSPM;SFS:(199002)(71364002)(189002)(56776001)(79102001)(47736001)(74366001)(31966008)(33656001)(53806001)(56816003)(59766001)(74706001)(16601075002)(65816001)(63696002)(54316002)(512954002)(74662001)(47446002)(77982001)(80022001)(54356001)(69226001)(71186001)(81542001)(77096001)(15202345002)(49866001)(81342001)(47976001)(55846006)(16236675002)(51856001)(76796001)(74876001)(46102001)(6806003)(16406001)(50986001)(20776003)(74502001)(4396001)(76786001)(76482001);DIR:OUT;SFP:;SCL:1;SRVR:BN1AFFO11HUB001;H:TK5EX14MLTC102.redmond.corp.microsoft.com;CLIP:131.107.125.37;RD:InfoDomainNonexistent;A:1;MX:1;LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 087474FBFA X-Virus-Scanned: amavisd-new at omg.org Tom Regarding the resolution for issue 18528 in ballot 6 (.Interactions needs to fix Gate name Distinguishability rules)., there are some constraints with no documentation. The vast majority of the constraints in the spec have English documentation that states the constraint, as well as the OCL. I.m not happy that we should break this convention in this resolution. The reasoning is already set out in the Resolution section, so it will not be much effort to add appropriate documentation to the Revised Text. Thanks -- Steve From: Manfred R. Koethe [mailto:koethe@88solutions.com] Sent: 11 June 2013 02:17 To: Subject: [UML 2.5 FTF] Ballot 6 - Preview 3 --- PLEASE READ Dear Colleagues, Here is Preview 3 of the UML 2.5 FTF Ballot 6. I removed the duplicate issue resolution for 18690. The prevailing resolution is the one merged with issue 18415. Also I improved the formatting, made the issue references (for example in Merged/Duplicate) hyperlinks and updated the voter table. No further changes. Kind regards, Manfred --------------------------------------------------------------- Manfred R. Koethe 88solutions Corporation tel: +1 (510) 246 8611 fax: +1 (815) 550 2086 mailto: koethe@88solutions.com web: http://www.88solutions.com --------(Model-Driven Modeling Solutions)--------