Issue 19194: Rg. Reception.ownedParameter (uml2-rtf) Source: Fraunhofer FOKUS (Mr. Marc-Florian Wendland, marc-florian.wendland(at)fokus.fraunhofer.de) Nature: Uncategorized Issue Severity: Summary: in conjunction with the Message signature issue, I was wondering whether Reception should redefine BehavioralFeature.ownedParameter. In contrast to Operation.ownedParameter (that already redefines BehavioralFeature.ownedParameter), Reception.ownedParameter would have to be derived an read-only, since the number and characteristics of the parameters are completely derived from the Properties of the Signal referenced by the Reception. As a matter of fact, with the invariant ‘same_structure_as_signal’ there is already an explicit derivation algorithm given. This one could be the basis for developing the body expression of the derived, read-only Reception.ownedParameter. In my opinion, everything that can be expressed by means of the metamodel, should be expressed in the metamodel and not with additional Constraints. Resolution: Revised Text: Actions taken: January 16, 2014: received issue Discussion: End of Annotations:===== m: "Wendland, Marc-Florian" To: "uml2-rtf@omg.org" Subject: Rg. Reception.ownedParameter Thread-Topic: Rg. Reception.ownedParameter Thread-Index: Ac8Si8G08Wuh5RptSDedYuDO5ANC/g== Date: Thu, 16 Jan 2014 07:23:01 +0000 Accept-Language: de-DE, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.147.67.177] x-kse-antivirus-interceptor-info: protection disabled X-cloud-security-sender: marc-florian.wendland@fokus.fraunhofer.de X-cloud-security-recipient: uml2-rtf@omg.org X-cloud-security-Virusscan: CLEAN X-cloud-security-disclaimer: This E-Mail was scanned by E-Mailservice on mx-gate13-dus with 3CF372118001 X-cloud-security-connect: pluto.fokus.fraunhofer.de[195.37.77.164], TLS=, IP=195.37.77.164 X-cloud-security: scantime:.2448 X-Virus-Scanned: amavisd-new at omg.org Hi all, in conjunction with the Message signature issue, I was wondering whether Reception should redefine BehavioralFeature.ownedParameter. In contrast to Operation.ownedParameter (that already redefines BehavioralFeature.ownedParameter), Reception.ownedParameter would have to be derived an read-only, since the number and characteristics of the parameters are completely derived from the Properties of the Signal referenced by the Reception. As a matter of fact, with the invariant .same_structure_as_signal. there is already an explicit derivation algorithm given. This one could be the basis for developing the body expression of the derived, read-only Reception.ownedParameter. In my opinion, everything that can be expressed by means of the metamodel, should be expressed in the metamodel and not with additional Constraints. Any further comments/opinions on that?! Best regards, Marc-Florian X-Trusted-NM: yes Subject: Re: Rg. Reception.ownedParameter From: Nerijus Jankevicius Date: Thu, 16 Jan 2014 09:54:12 +0200 Cc: "uml2-rtf@omg.org" To: "Wendland, Marc-Florian" X-Mailer: Apple Mail (2.1827) X-Virus-Scanned: amavisd-new at omg.org Marc-Florian, Reception parameter types can be more general than Signal property types. Names could be different too, isn.t it? Nerijus On Jan 16, 2014, at 9:23 AM, Wendland, Marc-Florian wrote: Hi all, in conjunction with the Message signature issue, I was wondering whether Reception should redefine BehavioralFeature.ownedParameter. In contrast to Operation.ownedParameter (that already redefines BehavioralFeature.ownedParameter), Reception.ownedParameter would have to be derived an read-only, since the number and characteristics of the parameters are completely derived from the Properties of the Signal referenced by the Reception. As a matter of fact, with the invariant .same_structure_as_signal. there is already an explicit derivation algorithm given. This one could be the basis for developing the body expression of the derived, read-only Reception.ownedParameter. In my opinion, everything that can be expressed by means of the metamodel, should be expressed in the metamodel and not with additional Constraints. Any further comments/opinions on that?! Best regards, Marc-Florian From: "Wendland, Marc-Florian" To: Nerijus Jankevicius CC: "uml2-rtf@omg.org" Subject: AW: Rg. Reception.ownedParameter Thread-Topic: Rg. Reception.ownedParameter Thread-Index: Ac8Si8G08Wuh5RptSDedYuDO5ANC/v//+AIA///vHmA= Date: Thu, 16 Jan 2014 07:56:20 +0000 Accept-Language: de-DE, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.147.67.177] x-kse-antivirus-interceptor-info: protection disabled X-cloud-security-sender: marc-florian.wendland@fokus.fraunhofer.de X-cloud-security-recipient: uml2-rtf@omg.org X-cloud-security-Virusscan: CLEAN X-cloud-security-disclaimer: This E-Mail was scanned by E-Mailservice on mx-gate09-dus with 6B5762118004 X-cloud-security-connect: pluto.fokus.fraunhofer.de[195.37.77.164], TLS=, IP=195.37.77.164 X-cloud-security: scantime:.2862 X-Virus-Scanned: amavisd-new at omg.org Hi Nerijus, not according to .same_structure_as_signal.. They are completely derived from the corresponding Property of the Signal. (see UML v2.5 p. 185) inv: signal.ownedAttribute->size() = ownedParameter->size() and Sequence{1..signal.ownedAttribute->size()}->forAll( i | ownedParameter->at(i).direction = ParameterDirectionKind::_'in' and ownedParameter->at(i).name = signal.ownedAttribute->at(i).name and ownedParameter->at(i).type = signal.ownedAttribute->at(i).type and ownedParameter->at(i).lowerBound() = signal.ownedAttribute->at(i).lowerBound() and ownedParameter->at(i).upperBound() = signal.ownedAttribute->at(i).upperBound() ) Regards, Marc-Florian Von: Nerijus Jankevicius [mailto:nerijus@nomagic.com] Gesendet: Donnerstag, 16. Januar 2014 08:54 An: Wendland, Marc-Florian Cc: uml2-rtf@omg.org Betreff: Re: Rg. Reception.ownedParameter Marc-Florian, Reception parameter types can be more general than Signal property types. Names could be different too, isn.t it? Nerijus On Jan 16, 2014, at 9:23 AM, Wendland, Marc-Florian wrote: Hi all, in conjunction with the Message signature issue, I was wondering whether Reception should redefine BehavioralFeature.ownedParameter. In contrast to Operation.ownedParameter (that already redefines BehavioralFeature.ownedParameter), Reception.ownedParameter would have to be derived an read-only, since the number and characteristics of the parameters are completely derived from the Properties of the Signal referenced by the Reception. As a matter of fact, with the invariant .same_structure_as_signal. there is already an explicit derivation algorithm given. This one could be the basis for developing the body expression of the derived, read-only Reception.ownedParameter. In my opinion, everything that can be expressed by means of the metamodel, should be expressed in the metamodel and not with additional Constraints. Any further comments/opinions on that?! Best regards, Marc-Florian From: "BERNARD, Yves" To: "Wendland, Marc-Florian" , "uml2-rtf@omg.org" Date: Thu, 23 Jan 2014 08:40:43 +0100 Subject: RE: Rg. Reception.ownedParameter Thread-Topic: Rg. Reception.ownedParameter Thread-Index: Ac8Si8G08Wuh5RptSDedYuDO5ANC/gFgp58g Accept-Language: fr-FR, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR, en-US X-Virus-Scanned: amavisd-new at omg.org I fully agree. Yves De : Wendland, Marc-Florian [mailto:marc-florian.wendland@fokus.fraunhofer.de] Envoyé jeudi 16 janvier 2014 08:23 À: uml2-rtf@omg.org Objet : Rg. Reception.ownedParameter Hi all, in conjunction with the Message signature issue, I was wondering whether Reception should redefine BehavioralFeature.ownedParameter. In contrast to Operation.ownedParameter (that already redefines BehavioralFeature.ownedParameter), Reception.ownedParameter would have to be derived an read-only, since the number and characteristics of the parameters are completely derived from the Properties of the Signal referenced by the Reception. As a matter of fact, with the invariant .same_structure_as_signal. there is already an explicit derivation algorithm given. This one could be the basis for developing the body expression of the derived, read-only Reception.ownedParameter. In my opinion, everything that can be expressed by means of the metamodel, should be expressed in the metamodel and not with additional Constraints. Any further comments/opinions on that?! Best regards, Marc-Florian The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free.