Issue 18545: Message Constraint signature_is_Signal only merely refers to Signal.ownedAttributes as parameters of a Message signature (uml25-ftf) Source: Fraunhofer FOKUS (Mr. Marc-Florian Wendland, marc-florian.wendland(at)fokus.fraunhofer.de) Nature: Uncategorized Issue Severity: Summary: Message Constraint signature_is_Signal only merely refers to Signal.ownedAttributes as parameters of a Message signature. This is not sufficient, since a Signal may specialize other signals and, thus, the Message should also allow to specify arguments for inherited attributes. Of course, redefined attributes need to be sorted out. Resolution: Revised Text: Actions taken: March 13, 2013: received issue Discussion: End of Annotations:===== m: "Wendland, Marc-Florian" To: Juergen Boldt , "uml25-ftf@omg.org" Subject: AW: [Interactions] Constraint for Signal signature inusfficient - and other things Thread-Topic: [Interactions] Constraint for Signal signature inusfficient - and other things Thread-Index: AQHOHpMYWL0goXfTB0q+PEAW5gNBAJijT1BQ Date: Wed, 13 Mar 2013 08:46:17 +0000 Accept-Language: de-DE, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.147.78.246] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean X-cloud-security-sender: marc-florian.wendland@fokus.fraunhofer.de X-cloud-security-recipient: juergen@omg.org X-cloud-security-Virusscan: CLEAN X-cloud-security-disclaimer: This E-Mail was scanned by E-Mailservice on mx-gate12-muc with AD09312B4007 X-cloud-security: scantime:.2020 X-Virus-Scanned: amavisd-new at omg.org X-Brightmail-Tracker: AAAAAh0YqyAdGKrx X-Brightmail-Tracker: AAAAAA== Juergen, Could you please file two issues for that mail: 2. Message Constraint signature_is_Signal only merely refers to Signal.ownedAttributes as parameters of a Message signature. This is not sufficient, since a Signal may specialize other signals and, thus, the Message should also allow to specify arguments for inherited attributes. Of course, redefined attributes need to be sorted out. Regards, Marc-Florian Von: Juergen Boldt [mailto:juergen@omg.org] Gesendet: Montag, 11. März 2013 20:59 An: Wendland, Marc-Florian; uml25-ftf@omg.org Betreff: Re: [Interactions] Constraint for Signal signature inusfficient - and other things will keep this one on my todo list until I hear either way -Juergen At 03:53 PM 3/11/2013, Wendland, Marc-Florian wrote: Hi all, Just found out that the OCL statement for signature_is_signal is not sufficiently specified from my perspective, since it only refers to the owned attributes of an Signal. Shouldn�t it rather fetch all attributes via Classifier.allAttributes() operation? I guess it is not that uncommon to specialize a Signal, is it? However, there needs to be an implementation of the inherit(NamedElement[*]):NamedElement[*] operation in the context of Signal. Just checked some other Classifier subclasses: Why does Class, Signal, Interface, Enumeration do not override the inherit(NamedElement) : NamedElement operation similar to DataType? If I�m not wrong, inherit determines what members are inherited from a general classifier. DataType explicitly overrides this operation to sort out all elements that are redefined. The corresponding OCL does not include anything DataType-specific, so for what reason is this operation not pulled up to Classifier? Sorry, if this issue is already filed � haven�t checked this yet due to time restriction. Regards, Marc-Florian Juergen Boldt Director, Member Services 109 Highland Ave Needham, MA 02494 USA Tel: 781 444 0404 x 132 fax: 781 444 0320 www.omg.org [] Date: Mon, 25 Mar 2013 21:06:27 -0400 From: Tom Rutt User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 To: "uml25-ftf@omg.org" Subject: Question on Issue 18545 - is_signal constraint 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== I am not sure about how to resolve issue 18545. It states Message Constraint signature_is_Signal only merely refers to Signal.ownedAttributes as parameters of a Message signature. This is not sufficient, since a Signal may specialize other signals and, thus, the Message should also allow to specify arguments for inherited attributes. Of course, redefined attributes need to be sorted out. But Signal does not have a superclass association, like that of class. It inherits from classifier, but it does not have an association to Signal, such as the superclass association which is in Class. Thus I am not sure that signals can inherit attributes from an inheritance relationship with another signal. Tom -- ---------------------------------------------------- Tom Rutt email: tom@coastin.com; trutt@us.fujitsu.com Tel: +1 732 801 5744 Fax: +1 732 774 5133 Date: Tue, 26 Mar 2013 09:10:52 +0000 From: Dave Hawkins User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 To: Tom Rutt CC: "uml25-ftf@omg.org" Subject: Re: Question on Issue 18545 - is_signal constraint X-Source-IP: userp1040.oracle.com [156.151.31.81] X-Virus-Scanned: amavisd-new at omg.org All classifiers can have generalizations. Class::superClass is just a redefinition of Classifier::general, which is ultimately generalization.general. However I don't think you need to do anything with that, you just need to select all the properties from the member derived union, which includes the inherited members. Dave On 26/03/13 01:06, Tom Rutt wrote: I am not sure about how to resolve issue 18545. It states Message Constraint signature_is_Signal only merely refers to Signal.ownedAttributes as parameters of a Message signature. This is not sufficient, since a Signal may specialize other signals and, thus, the Message should also allow to specify arguments for inherited attributes. Of course, redefined attributes need to be sorted out. But Signal does not have a superclass association, like that of class. It inherits from classifier, but it does not have an association to Signal, such as the superclass association which is in Class. Thus I am not sure that signals can inherit attributes from an inheritance relationship with another signal. Tom -- Dave Hawkins | Principal Software Engineer | +44 118 924 0022 Oracle JDeveloper Development Oracle Corporation UK Ltd is a company incorporated in England & Wales. Company Reg. No. 1782505. Reg. office: Oracle Parkway, Thames Valley Park, Reading RG6 1RA. From: "Wendland, Marc-Florian" To: Tom Rutt , "uml25-ftf@omg.org" Subject: AW: Question on Issue 18545 - is_signal constraint Thread-Topic: Question on Issue 18545 - is_signal constraint Thread-Index: AQHOKb47NI2e8bU8vEKpZ7Gca0cZV5i3ryCA Date: Tue, 26 Mar 2013 09:33:12 +0000 Accept-Language: de-DE, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.147.67.134] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean X-cloud-security-sender: marc-florian.wendland@fokus.fraunhofer.de X-cloud-security-recipient: uml25-ftf@omg.org X-cloud-security-Virusscan: CLEAN X-cloud-security-disclaimer: This E-Mail was scanned by E-Mailservice on mx-gate03-haj2 with DF3DD1D801F X-cloud-security: scantime:.1993 X-Virus-Scanned: amavisd-new at omg.org X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id r2Q9XKos018861 Tom, > But Signal does not have a superclass association, like that of class. That means that Signal can actually specialize every kind of Classifier, since the /general association end is defined for metaclass Classifier. Don't know yet whether this was done on purpose, but it does not affect issue #18545 at all. > Thus I am not sure that signals can inherit attributes from an inheritance > relationship with another signal. I'd say it can. Have a look at section 9.9, subsection Classifier, subsection Operations: inheritableMembers(c : Classifier) : NamedElement [0..*] The query inheritableMembers() gives all of the members of a Classifier that may be inherited in one of its descendants, subject to whatever visibility restrictions apply. pre: c.allParents()->includes(self) body: member->select(m | c.hasVisibilityOf(m)) So, the elements that can be inherited by Classifiers in general are already determined on Classifier level. For Signal, this means that a specialized Signal inherits all Propertiers of its parent Signals, since Signal.ownedAttributes subsets Namespace.member. But this also means that a Signal, if a Generalization is established between a Signal and a Class, for example (what is not prohibited - as far as I know - in the spec) inherits the Operations of its super Class. Again, I do not know whether this was done on purpose or whether this needs clarification. If so, this is apparently another issue for Signal. Regards, Marc-Florian > -----Ursprühe Nachricht----- > Von: Tom Rutt [mailto:tom@coastin.com] > Gesendet: Dienstag, 26. Mä 2013 02:06 > An: uml25-ftf@omg.org > Betreff: Question on Issue 18545 - is_signal constraint > > I am not sure about how to resolve issue 18545. > > It states > > Message Constraint signature_is_Signal only merely refers to > Signal.ownedAttributes as parameters of a Message signature. This is not > sufficient, since a Signal may specialize other signals and, thus, the Message > should also allow to specify arguments for inherited attributes. Of course, > redefined attributes need to be sorted out. > > > But Signal does not have a superclass association, like that of class. > > It inherits from classifier, but it does not have an association to Signal, such as > the superclass association which is in Class. > > Thus I am not sure that signals can inherit attributes from an inheritance > relationship with another signal. > > Tom > > > -- > ---------------------------------------------------- > Tom Rutt email: tom@coastin.com; trutt@us.fujitsu.com > Tel: +1 732 801 5744 Fax: +1 732 774 5133 Date: Tue, 26 Mar 2013 09:40:58 +0000 From: Dave Hawkins User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 To: "Wendland, Marc-Florian" CC: Tom Rutt , "uml25-ftf@omg.org" Subject: Re: AW: Question on Issue 18545 - is_signal constraint X-Source-IP: acsinet22.oracle.com [141.146.126.238] X-Virus-Scanned: amavisd-new at omg.org On 26/03/13 09:33, Wendland, Marc-Florian wrote: But this also means that a Signal, if a Generalization is established between a Signal and a Class, for example (what is not prohibited - as far as I know - in the spec) inherits the Operations of its super Class. Again, I do not know whether this was done on purpose or whether this needs clarification. If so, this is apparently another issue for Signal. That's prohibited by constraint Classifier::specialize_type. Regards, Marc-Florian -----Ursprühe Nachricht----- Von: Tom Rutt [mailto:tom@coastin.com] Gesendet: Dienstag, 26. Mä 2013 02:06 An: uml25-ftf@omg.org Betreff: Question on Issue 18545 - is_signal constraint I am not sure about how to resolve issue 18545. It states Message Constraint signature_is_Signal only merely refers to Signal.ownedAttributes as parameters of a Message signature. This is not sufficient, since a Signal may specialize other signals and, thus, the Message should also allow to specify arguments for inherited attributes. Of course, redefined attributes need to be sorted out. But Signal does not have a superclass association, like that of class. It inherits from classifier, but it does not have an association to Signal, such as the superclass association which is in Class. Thus I am not sure that signals can inherit attributes from an inheritance relationship with another signal. Tom -- ---------------------------------------------------- Tom Rutt email: tom@coastin.com; trutt@us.fujitsu.com Tel: +1 732 801 5744 Fax: +1 732 774 5133 -- Dave Hawkins | Principal Software Engineer | +44 118 924 0022 Oracle JDeveloper Development Oracle Corporation UK Ltd is a company incorporated in England & Wales. Company Reg. No. 1782505. Reg. office: Oracle Parkway, Thames Valley Park, Reading RG6 1RA. From: "Wendland, Marc-Florian" To: Dave Hawkins CC: Tom Rutt , "uml25-ftf@omg.org" Subject: AW: AW: Question on Issue 18545 - is_signal constraint Thread-Topic: AW: Question on Issue 18545 - is_signal constraint Thread-Index: AQHOKb47NI2e8bU8vEKpZ7Gca0cZV5i3ryCA///4qQCAABJ1YA== Date: Tue, 26 Mar 2013 09:51:17 +0000 Accept-Language: de-DE, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.147.67.134] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean X-cloud-security-sender: marc-florian.wendland@fokus.fraunhofer.de X-cloud-security-recipient: uml25-ftf@omg.org X-cloud-security-Virusscan: CLEAN X-cloud-security-disclaimer: This E-Mail was scanned by E-Mailservice on mx-gate03-haj2 with 5071E1D800E X-cloud-security: scantime:.2106 X-Virus-Scanned: amavisd-new at omg.org X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id r2Q9pQYd019641 Dave, thanks. Good to know. Well, then, we can forget about the last paragrapg, but as Dave and I pointed out, Signals can inherit Properties of super Signals and these Properties need to be included in the signature constraint of Message. I reckon, however, the resolution of this issue needs the resolution of issue #18544 first. Regards, Marc-Florian > -----Ursprühe Nachricht----- > Von: Dave Hawkins [mailto:dave.hawkins@oracle.com] > Gesendet: Dienstag, 26. Mä 2013 10:41 > An: Wendland, Marc-Florian > Cc: Tom Rutt; uml25-ftf@omg.org > Betreff: Re: AW: Question on Issue 18545 - is_signal constraint > > On 26/03/13 09:33, Wendland, Marc-Florian wrote: > > But this also means that a Signal, if a Generalization is established between > a Signal and a Class, for example (what is not prohibited - as far as I know - in > the spec) inherits the Operations of its super Class. Again, I do not know > whether this was done on purpose or whether this needs clarification. If so, > this is apparently another issue for Signal. > > That's prohibited by constraint Classifier::specialize_type. > > > > > Regards, > > Marc-Florian > > > > > >> -----Ursprühe Nachricht----- > >> Von: Tom Rutt [mailto:tom@coastin.com] > >> Gesendet: Dienstag, 26. Mä 2013 02:06 > >> An: uml25-ftf@omg.org > >> Betreff: Question on Issue 18545 - is_signal constraint > >> > >> I am not sure about how to resolve issue 18545. > >> > >> It states > >> > >> Message Constraint signature_is_Signal only merely refers to > >> Signal.ownedAttributes as parameters of a Message signature. This is > >> not sufficient, since a Signal may specialize other signals and, > >> thus, the Message should also allow to specify arguments for > >> inherited attributes. Of course, redefined attributes need to be sorted > out. > >> > >> > >> But Signal does not have a superclass association, like that of class. > >> > >> It inherits from classifier, but it does not have an association to > >> Signal, such as the superclass association which is in Class. > >> > >> Thus I am not sure that signals can inherit attributes from an > >> inheritance relationship with another signal. > >> > >> Tom > >> > >> > >> -- > >> ---------------------------------------------------- > >> Tom Rutt email: tom@coastin.com; trutt@us.fujitsu.com > >> Tel: +1 732 801 5744 Fax: +1 732 774 5133 > > > > -- > Dave Hawkins | Principal Software Engineer | +44 118 924 0022 Oracle > JDeveloper Development Oracle Corporation UK Ltd is a company > incorporated in England & Wales. > Company Reg. No. 1782505. > Reg. office: Oracle Parkway, Thames Valley Park, Reading RG6 1RA. From: Ed Seidewitz To: Dave Hawkins CC: Tom Rutt , "uml25-ftf@omg.org" Date: Tue, 26 Mar 2013 08:49:37 -0400 Subject: Re: Question on Issue 18545 - is_signal constraint Thread-Topic: Question on Issue 18545 - is_signal constraint Thread-Index: Ac4qIGE9DSbs2zhKS5Sh1EJhYHbV6Q== Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-Mailprotector-Decision: deliver X-Mailprotector-Connection: TLSv1|[10.1.50.225]|10.1.50.225|outbound.mailprotector.net|0.0|0.0|0|||0|0|0|0 X-Mailprotector-Results: null_ptr clean X-Mailprotector-Score: 40 X-Mailprotector-IP-Analysis: 0, 10.1.50.225, Ugly c=0.782135 p=-0.9727 Source White X-Mailprotector-Scan-Diagnostics: 0-0-0-5087-c X-Mailprotector-ID: 96a78b2b-2ab7-4c81-a48e-bb8286386fa2 X-Virus-Scanned: amavisd-new at omg.org X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id r2QCnn4J026006 X-Brightmail-Tracker: AAAAAA== X-Brightmail-Tracker: AAAAAA== The problem is that members are not ordered, but the attributes of a signal need to be matched in order if positional arguments are used in a message. We also had this problem matching the pins of a send signal action to the attributes of a signal. We resolved it by introducing the Classifier allAttributes operation that produces an ordered list of owned and inherited attributes (though the order is not fully determined in the face of multiple generalizations, since generalizations are not ordered). Ed Sent from my iPhone On Mar 26, 2013, at 5:12 AM, "Dave Hawkins" wrote: > All classifiers can have generalizations. Class::superClass is > just a redefinition of Classifier::general, which is ultimately > generalization.general. However I don't think you need to do > anything with that, you just need to select all the properties > from the member derived union, which includes the inherited > members. > > Dave > > On 26/03/13 01:06, Tom Rutt wrote: >> I am not sure about how to resolve issue 18545. >> >> It states >> >> Message Constraint signature_is_Signal only merely refers to Signal.ownedAttributes as parameters of a Message >> signature. This is not sufficient, since a Signal may specialize other signals and, thus, the Message should also allow >> to specify arguments for inherited attributes. Of course, redefined attributes need to be sorted out. >> >> >> But Signal does not have a superclass association, like that of class. >> >> It inherits from classifier, but it does not have an association to Signal, such as the superclass >> association which is in Class. >> >> Thus I am not sure that signals can inherit attributes from an inheritance relationship with another signal. >> >> Tom > > -- > Dave Hawkins | Principal Software Engineer | +44 118 924 0022 > Oracle JDeveloper Development > Oracle Corporation UK Ltd is a company incorporated in England & Wales. > Company Reg. No. 1782505. > Reg. office: Oracle Parkway, Thames Valley Park, Reading RG6 1RA.