Issue 17226: Message Signature in Interactions and Reception.ownedParameter (uml2-rtf) Source: Fraunhofer FOKUS (Mr. Marc-Florian Wendland, marc-florian.wendland(at)fokus.fraunhofer.de) Nature: Uncategorized Issue Severity: Summary: currently (till 2.5) a message's signature is of type NamedElement that resolves either to an Operation or Signal. Apart from the fact that the nearest common superclass is Namespace, the use of elements of different inheritance hierarchies makes it cumbersome/impractical to work with the signatures easily. You always have to check what concrete signature is associated, cast it into the appropriate subclass (i.e. either Signal or Operation) and use it further. Regarding Message::Signature, I was wondering, whether it wouldn't be simpler and far more consistent to refer to a BehavioralFeature (Operation/Reception which has to have an Signal associated) directly instead of NamedElement (which ought to be Namespace)? This leads to a situation where I was wondering why a Reception, though it is a BehavioralFeature, does not say any word about owned parameters at all? However, if Receptions would be able to capture information about parameter, too, the treatment of Reception and Operation would be pretty much the same with regard to their parameter semantics. So, it might be worth to reconsider the relationship between BehavioralFeature, Reception and Parameter. We could supplement BehavioralFeature::ownedParameter {ordered, subsets Namespace::ownedMember} containment with /Reception::ownedParameter [0..1] {redefines BehavioralFeature::ownedParameter } containment The derivation algorithm of Reception::ownedParameter could be similar to the following: A Reception declares at most one Parameter. Its type and name must exactly the name and type of the Signal, referenced by Reception::signal, if present. The direction kind of a Reception's Parameter must be set to IN exclusively. context Reception inv 'parameter': if not self.signal.oclIsUndefined then not self.ownedParameter.oclIsUndefined and self.ownedParameter.type = self.signal and self.ownedParameter.name = self.signal.name and self.ownedParameter.directionKind == ParameterDirectionKind::IN else endif This would ease the usage of BehavioralFeatures a lot, I'd say. In case of Messages, one would only have to walk over Message::signature::parameter instead of casting it down to either an Operation or Signal.. Resolution: Revised Text: Actions taken: March 12, 2012: received issue Discussion: End of Annotations:===== ubject: Message Signature in Interactions and Reception.ownedParameter From: "Wendland, Marc-Florian" To: Hi all, currently (till 2.5) a message's signature is of type NamedElement that resolves either to an Operation or Signal. Apart from the fact that the nearest common superclass is Namespace, the use of elements of different inheritance hierarchies makes it cumbersome/impractical to work with the signatures easily. You always have to check what concrete signature is associated, cast it into the appropriate subclass (i.e. either Signal or Operation) and use it further. Regarding Message::Signature, I was wondering, whether it wouldn't be simpler and far more consistent to refer to a BehavioralFeature (Operation/Reception which has to have an Signal associated) directly instead of NamedElement (which ought to be Namespace)? This leads to a situation where I was wondering why a Reception, though it is a BehavioralFeature, does not say any word about owned parameters at all? However, if Receptions would be able to capture information about parameter, too, the treatment of Reception and Operation would be pretty much the same with regard to their parameter semantics. So, it might be worth to reconsider the relationship between BehavioralFeature, Reception and Parameter. We could supplement BehavioralFeature::ownedParameter {ordered, subsets Namespace::ownedMember} containment with /Reception::ownedParameter [0..1] {redefines BehavioralFeature::ownedParameter } containment The derivation algorithm of Reception::ownedParameter could be similar to the following: A Reception declares at most one Parameter. Its type and name must exactly the name and type of the Signal, referenced by Reception::signal, if present. The direction kind of a Reception's Parameter must be set to IN exclusively. context Reception inv 'parameter': if not self.signal.oclIsUndefined then not self.ownedParameter.oclIsUndefined and self.ownedParameter.type = self.signal and self.ownedParameter.name = self.signal.name and self.ownedParameter.directionKind == ParameterDirectionKind::IN else endif This would ease the usage of BehavioralFeatures a lot, I'd say. In case of Messages, one would only have to walk over Message::signature::parameter instead of casting it down to either an Operation or Signal.. Curious about your comments. Marc-Florian ################################################ Marc-Florian Wendland Master of Science (M.Sc.) ------------------------------------------------ Fraunhofer Institut FOKUS Modeling und Testing Department Kaiserin-Augusta-Alle 31 D-10589 Berlin ------------------------------------------------ Tel: +49 (30) - 3463 7395 Email: marc-florian.wendland@fokus.fraunhofer.de ################################################ From: Ed Seidewitz To: "Wendland, Marc-Florian" Subject: RE: Message Signature in Interactions and Reception.ownedParameter Marc-Florian -- I agree that having the signature of an operation be either an Operation or a Signal is cumbersome. However, while have the signature be a BehavioralFeature would, indeed, be far more consistent, I unfortunately think that this would be to large a change for us to make at this point. Right now, you can have an Interaction with Messages whose signatures are Signals for which the target lifeline does not represent anything with a Reception for that Signal. This is, in fact, not uncommon, since most people seem to be pretty loose about modeling Receptions explicitly. With your proposed change, all these Interactions would become invalid. On Reception parameters, we agreed during the last UML 2.5 submitters call that the ownedParameters of a Reception should be required to be all in Parameters that correspond one-to-one with the attributes of the Signal referenced by the Reception. This is consistent with how the Reception is invoked as a BehavioralFeature and with how the arguments are matched to Parameters on a Message. -- Ed >From: Wendland, Marc-Florian [mailto:marc-florian.wendland@fokus.fraunhofer.de] >Sent: Monday, March 12, 2012 3:02 AM ...snip... >Tel: +49 (30) - 3463 7395 >Email: marc-florian.wendland@fokus.fraunhofer.de >################################################ Subject: AW: Message Signature in Interactions and Reception.ownedParameter From: "Wendland, Marc-Florian" To: "Ed Seidewitz" Cc: Ed, thanks for the clarification. >However, while have the signature be a > BehavioralFeature would, indeed, be far more consistent, I unfortunately > think that this would be to large a change for us to make at this point. Yeah, I know... but there will be a subsequent FTF hopefully This is, in fact, not uncommon, since most people > seem to be pretty loose about modeling Receptions explicitly. With your > proposed change, all these Interactions would become invalid. Hmm... I see... But if people avoid/neglect Receptions, doesn't they produce invalid UML models? I mean, the Reception was introduced to indicate that a classifier is able to receive a particular signal. A message, however, neglects those receptions completely instead of taking it into account. So messages allow people to construct invalid UML models by simply pointing to Signals without the need to model a Reception on the receiving lifeline's classifier/type. This shouldn't be possible. I would expect Interactions to rather cope with the rest of the UML concepts and not to annul the integrity/consistency of a UML model. > On Reception parameters, we agreed during the last UML 2.5 submitters call > that the ownedParameters of a Reception should be ... ...snip... >... with how the Reception is > invoked as a BehavioralFeature and with how the arguments are matched to > Parameters on a Message. Good, this is one step into the right direction. However, I still think that this is not a the best solution for sending Signals. There is a fundamental difference between Signals and Operations, since Signals are types and Operations not. It is simply not possible to create a type corresponding to an Operation call (btw, this is possible for example with TTCN-3), whereas it is possible to instantiate a Signal, because it is a classifier. With 'instantiate' I mean, there is an InstanceSpecification for it, which contains all the relevant information for the Signal (of course, this depends on the purpose). This InstanceSpecification can be used as a Message's argument by using InstanceValue pointing to the InstanceSpecification. By doing so, a lot of redundancies can be avoided within Interactions. Let's say there is a Signal with several attributes (I'm from the testing domain and it is quite often the case that the data that is being exchanged is very complex - with more than 15 fields/attributes for a Signal), which is going to be used in a hundred Messages with the very same values. Do we really want the user to specify all of these attributes a hundred times over and over again? Our way of dealing with such situations makes simply use of the InstanceSpecification which is referenced a hundred times. This results in significant less redundancy and work. So, finally, I think this is something that should be definitely reconsidered in the subsequent FTF. Marc-Florian ################################################ Marc-Florian Wendland Master of Science (M.Sc.) ------------------------------------------------ Fraunhofer Institut FOKUS Modeling und Testing Department Kaiserin-Augusta-Alle 31 D-10589 Berlin ------------------------------------------------ Tel: +49 (30) - 3463 7395 Email: marc-florian.wendland@fokus.fraunhofer.de ################################################ > -----Ursprühe Nachricht----- > Von: Ed Seidewitz [mailto:ed-s@modeldriven.com] > Gesendet: Montag, 12. Mä 2012 17:20 ...snip... > Tel: +49 (30) - 3463 7395 > Email: marc-florian.wendland@fokus.fraunhofer.de > ################################################ From: Bran Selic Subject: Re: Message Signature in Interactions and Reception.ownedParameter To: "Wendland, Marc-Florian" Cc: Ed Seidewitz , uml2-rtf@omg.org Just a footnote on one part of Marc-Florian's response: On Tue, Mar 13, 2012 at 2:31 AM, Wendland, Marc-Florian wrote: Hmm... I see... But if people avoid/neglect Receptions, doesn't they produce invalid UML models? I mean, the Reception was introduced to indicate that a classifier is able to receive a particular signal. A message, however, neglects those receptions completely instead of taking it into account. So messages allow people to construct invalid UML models by simply pointing to Signals without the need to model a Reception on the receiving lifeline's classifier/type. This shouldn't be possible. I would expect Interactions to rather cope with the rest of the UML concepts and not to annul the integrity/consistency of a UML model. [bvs] There are many if not most situations in modeling where we want/need to do what Martin Fowler calls "sketching"; that is, relatively informal modeling where all we are doing is drafting some ideas, trying to firm them up. It is absolutely critical for a modeling language to support this mode, just as it is critical to enable it to support fully formal semantically and syntactically consistent modeling. [bvs] The ability to support incomplete models (but NOT inconsistent ones) and treat them as valid is one of the main characteristics that distinguishes a modeling language from a programming language. There are a number of places in the UML metamodel that support this (e.g., allowing a TypedElement to have no type defined). Whatever we do, we must retain this characteristic. Cheers...Bran Subject: AW: Message Signature in Interactions and Reception.ownedParameter From: "Wendland, Marc-Florian" To: "Bran Selic" Cc: "Ed Seidewitz" , Bran, You.re right, I agree with your comments regarding completeness and consistency. In your TypedElement example, it is quite simple to be more precise, since one would only have to set the type of the TypedElement. It.is not that easy with Messages . well, defining constraints and performing semantics checks works always, of course (to ensure that only Signals are being send to a lifeline, if the represented type provides a reception for the Signal). But, actually, this could also be enabled by the UML superstructure directly (I know, not for UML 2.5 submission). Maybe the signature should be able to capture all situations, i.e. BehavioralFeature or Signal. Marc-Florian ################################################ Marc-Florian Wendland Master of Science (M.Sc.) ------------------------------------------------ Fraunhofer Institut FOKUS Modeling und Testing Department Kaiserin-Augusta-Alle 31 D-10589 Berlin ------------------------------------------------ Tel: +49 (30) - 3463 7395 Email: marc-florian.wendland@fokus.fraunhofer.de ################################################ Von: bran.selic@gmail.com [mailto:bran.selic@gmail.com] Im Auftrag von Bran Selic Gesendet: Dienstag, 13. Mä 2012 08:09 An: Wendland, Marc-Florian Cc: Ed Seidewitz; uml2-rtf@omg.org Betreff: Re: Message Signature in Interactions and Reception.ownedParameter Just a footnote on one part of Marc-Florian's response: On Tue, Mar 13, 2012 at 2:31 AM, Wendland, Marc-Florian wrote: Hmm... I see... But if people avoid/neglect Receptions, doesn't they produce invalid UML models? I mean, the Reception was introduced to indicate that a classifier is able to receive a particular signal. A message, however, neglects those receptions completely instead of taking it into account. So messages allow people to construct invalid UML models by simply pointing to Signals without the need to model a Reception on the receiving lifeline's classifier/type. This shouldn't be possible. I would expect Interactions to rather cope with the rest of the UML concepts and not to annul the integrity/consistency of a UML model. [bvs] There are many if not most situations in modeling where we want/need to do what Martin Fowler calls "sketching"; that is, relatively informal modeling where all we are doing is drafting some ideas, trying to firm them up. It is absolutely critical for a modeling language to support this mode, just as it is critical to enable it to support fully formal semantically and syntactically consistent modeling. [bvs] The ability to support incomplete models (but NOT inconsistent ones) and treat them as valid is one of the main characteristics that distinguishes a modeling language from a programming language. There are a number of places in the UML metamodel that support this (e.g., allowing a TypedElement to have no type defined). Whatever we do, we must retain this characteristic. Cheers...Bran From: "Wendland, Marc-Florian" To: Ed Seidewitz CC: "uml25-ftf@omg.org" Subject: Issue 17226: Message Signature in Interactions and Reception.ownedParameter Thread-Topic: Issue 17226: Message Signature in Interactions and Reception.ownedParameter Thread-Index: Ac4J57hldleO2owsS5e9EfxV12nP0A== Date: Wed, 13 Feb 2013 19:06:08 +0000 Accept-Language: de-DE, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.147.78.16] 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-gate11-haj2 with D997D794001 X-cloud-security: scantime:.3421 X-Virus-Scanned: amavisd-new at omg.org X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id r1DJ6Ia5026361 Hi Ed, Hi all, I started a discussion (see mail below) about how Reception relates to BehavioralFeature.ownedParameters (currently, there is no relation at all, neither a formal nor and editorial one) about a year ago or so. This is related to issue 17226 (http://www.omg.org/issues/uml2-rtf.open.html#Issue17226) and would help to significantly simplify processing message signatures without adding any further restrictions to the user with respect of maturity or degree of completion of the model (to reassure Bran, it would still be possible to just draw a signal message without having a Reception on the receiving Lifeline). Ed, your comment during the RFP those days was: "On Reception parameters, we agreed during the last UML 2.5 submitters call that the ownedParameters of a Reception should be required to be all in Parameters that correspond one-to-one with the attributes of the Signal referenced by the Reception. This is consistent with how the Reception is invoked as a BehavioralFeature and with how the arguments are matched to Parameters on a Message." Is this still desired (I hope so). Because this would allow to change the allowed NamedElement for Message.signature from Operation or Signal to BehavioralFeature or Signal. Not sure, whether this would be possible in the FTF, but it would not require metamodel, but OCL constraint changes in the spec. Regards, Marc-Florian -----Ursprühe Nachricht----- Von: Ed Seidewitz [mailto:ed-s@modeldriven.com] Gesendet: Montag, 12. Mä 2012 17:20 An: Wendland, Marc-Florian Cc: uml2-rtf@omg.org Betreff: RE: Message Signature in Interactions and Reception.ownedParameter Marc-Florian -- I agree that having the signature of an operation be either an Operation or a Signal is cumbersome. However, while have the signature be a BehavioralFeature would, indeed, be far more consistent, I unfortunately think that this would be to large a change for us to make at this point. Right now, you can have an Interaction with Messages whose signatures are Signals for which the target lifeline does not represent anything with a Reception for that Signal. This is, in fact, not uncommon, since most people seem to be pretty loose about modeling Receptions explicitly. With your proposed change, all these Interactions would become invalid. On Reception parameters, we agreed during the last UML 2.5 submitters call that the ownedParameters of a Reception should be required to be all in Parameters that correspond one-to-one with the attributes of the Signal referenced by the Reception. This is consistent with how the Reception is invoked as a BehavioralFeature and with how the arguments are matched to Parameters on a Message. -- Ed -----Original Message----- From: Wendland, Marc-Florian [mailto:marc-florian.wendland@fokus.fraunhofer.de] Sent: Monday, March 12, 2012 3:02 AM To: uml2-rtf@omg.org Subject: Message Signature in Interactions and Reception.ownedParameter Hi all, currently (till 2.5) a message's signature is of type NamedElement that resolves either to an Operation or Signal. Apart from the fact that the nearest common superclass is Namespace, the use of elements of different inheritance hierarchies makes it cumbersome/impractical to work with the signatures easily. You always have to check what concrete signature is associated, cast it into the appropriate subclass (i.e. either Signal or Operation) and use it further. Regarding Message::Signature, I was wondering, whether it wouldn't be simpler and far more consistent to refer to a BehavioralFeature (Operation/Reception which has to have an Signal associated) directly instead of NamedElement (which ought to be Namespace)? This leads to a situation where I was wondering why a Reception, though it is a BehavioralFeature, does not say any word about owned parameters at all? However, if Receptions would be able to capture information about parameter, too, the treatment of Reception and Operation would be pretty much the same with regard to their parameter semantics. So, it might be worth to reconsider the relationship between BehavioralFeature, Reception and Parameter. We could supplement BehavioralFeature::ownedParameter {ordered, subsets Namespace::ownedMember} containment with /Reception::ownedParameter [0..1] {redefines BehavioralFeature::ownedParameter } containment The derivation algorithm of Reception::ownedParameter could be similar to the following: A Reception declares at most one Parameter. Its type and name must exactly the name and type of the Signal, referenced by Reception::signal, if present. The direction kind of a Reception's Parameter must be set to IN exclusively. context Reception inv 'parameter': if not self.signal.oclIsUndefined then not self.ownedParameter.oclIsUndefined and self.ownedParameter.type = self.signal and self.ownedParameter.name = self.signal.name and self.ownedParameter.directionKind == ParameterDirectionKind::IN else endif This would ease the usage of BehavioralFeatures a lot, I'd say. In case of Messages, one would only have to walk over Message::signature::parameter instead of casting it down to either an Operation or Signal.. Curious about your comments. Marc-Florian ################################################ Marc-Florian Wendland Master of Science (M.Sc.) ------------------------------------------------ Fraunhofer Institut FOKUS Modeling und Testing Department Kaiserin-Augusta-Alle 31 D-10589 Berlin ------------------------------------------------ Tel: +49 (30) - 3463 7395 Email: marc-florian.wendland@fokus.fraunhofer.de ################################################ From: Ed Seidewitz To: "Wendland, Marc-Florian" CC: "uml25-ftf@omg.org" Date: Wed, 13 Feb 2013 14:16:34 -0500 Subject: RE: Issue 17226: Message Signature in Interactions and Reception.ownedParameter Thread-Topic: Issue 17226: Message Signature in Interactions and Reception.ownedParameter Thread-Index: Ac4J57hldleO2owsS5e9EfxV12nP0AANkKeQ 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.226]|10.1.50.226|outbound.mailprotector.net|0.0|0.0|0|||0|0|0|0 X-Mailprotector-Results: null_ptr subject_50_chars clean X-Mailprotector-Score: 60 X-Mailprotector-IP-Analysis: 0, 10.1.50.226, Ugly c=0.791824 p=-0.989876 Source White X-Mailprotector-Scan-Diagnostics: 0-0-0-14296-c X-Mailprotector-ID: e1bf91c3-c8bd-4b98-ab84-d70820ca7509 X-Virus-Scanned: amavisd-new at omg.org X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id r1DJGeW8027286 Marc-Florian -- Not only is this still desired, but UML 2.5 actually has the following constraint on Reception: same_structure_as_signal A Reception's parameters match the ownedAttributes of its signal by name, type, and multiplicity [I won't both to copy the OCL.] Allowing a Message signature to be a BehavioralFeature, in general, does make sense to me. It would have to be considered an "enhancement", though, in that it would have some interoperability considerations. Namely, it would mean UML 2.5 models that used Receptions as Message signatures would technically be valid as UML 2.4.1 models. But perhaps that is not too big a problem. -- Ed -----Original Message----- From: Wendland, Marc-Florian [mailto:marc-florian.wendland@fokus.fraunhofer.de] Sent: Wednesday, February 13, 2013 2:06 PM To: Ed Seidewitz Cc: uml25-ftf@omg.org Subject: Issue 17226: Message Signature in Interactions and Reception.ownedParameter Hi Ed, Hi all, I started a discussion (see mail below) about how Reception relates to BehavioralFeature.ownedParameters (currently, there is no relation at all, neither a formal nor and editorial one) about a year ago or so. This is related to issue 17226 (http://www.omg.org/issues/uml2-rtf.open.html#Issue17226) and would help to significantly simplify processing message signatures without adding any further restrictions to the user with respect of maturity or degree of completion of the model (to reassure Bran, it would still be possible to just draw a signal message without having a Reception on the receiving Lifeline). Ed, your comment during the RFP those days was: "On Reception parameters, we agreed during the last UML 2.5 submitters call that the ownedParameters of a Reception should be required to be all in Parameters that correspond one-to-one with the attributes of the Signal referenced by the Reception. This is consistent with how the Reception is invoked as a BehavioralFeature and with how the arguments are matched to Parameters on a Message." Is this still desired (I hope so). Because this would allow to change the allowed NamedElement for Message.signature from Operation or Signal to BehavioralFeature or Signal. Not sure, whether this would be possible in the FTF, but it would not require metamodel, but OCL constraint changes in the spec. Regards, Marc-Florian -----Ursprühe Nachricht----- Von: Ed Seidewitz [mailto:ed-s@modeldriven.com] Gesendet: Montag, 12. Mä 2012 17:20 An: Wendland, Marc-Florian Cc: uml2-rtf@omg.org Betreff: RE: Message Signature in Interactions and Reception.ownedParameter Marc-Florian -- I agree that having the signature of an operation be either an Operation or a Signal is cumbersome. However, while have the signature be a BehavioralFeature would, indeed, be far more consistent, I unfortunately think that this would be to large a change for us to make at this point. Right now, you can have an Interaction with Messages whose signatures are Signals for which the target lifeline does not represent anything with a Reception for that Signal. This is, in fact, not uncommon, since most people seem to be pretty loose about modeling Receptions explicitly. With your proposed change, all these Interactions would become invalid. On Reception parameters, we agreed during the last UML 2.5 submitters call that the ownedParameters of a Reception should be required to be all in Parameters that correspond one-to-one with the attributes of the Signal referenced by the Reception. This is consistent with how the Reception is invoked as a BehavioralFeature and with how the arguments are matched to Parameters on a Message. -- Ed -----Original Message----- From: Wendland, Marc-Florian [mailto:marc-florian.wendland@fokus.fraunhofer.de] Sent: Monday, March 12, 2012 3:02 AM To: uml2-rtf@omg.org Subject: Message Signature in Interactions and Reception.ownedParameter Hi all, currently (till 2.5) a message's signature is of type NamedElement that resolves either to an Operation or Signal. Apart from the fact that the nearest common superclass is Namespace, the use of elements of different inheritance hierarchies makes it cumbersome/impractical to work with the signatures easily. You always have to check what concrete signature is associated, cast it into the appropriate subclass (i.e. either Signal or Operation) and use it further. Regarding Message::Signature, I was wondering, whether it wouldn't be simpler and far more consistent to refer to a BehavioralFeature (Operation/Reception which has to have an Signal associated) directly instead of NamedElement (which ought to be Namespace)? This leads to a situation where I was wondering why a Reception, though it is a BehavioralFeature, does not say any word about owned parameters at all? However, if Receptions would be able to capture information about parameter, too, the treatment of Reception and Operation would be pretty much the same with regard to their parameter semantics. So, it might be worth to reconsider the relationship between BehavioralFeature, Reception and Parameter. We could supplement BehavioralFeature::ownedParameter {ordered, subsets Namespace::ownedMember} containment with /Reception::ownedParameter [0..1] {redefines BehavioralFeature::ownedParameter } containment The derivation algorithm of Reception::ownedParameter could be similar to the following: A Reception declares at most one Parameter. Its type and name must exactly the name and type of the Signal, referenced by Reception::signal, if present. The direction kind of a Reception's Parameter must be set to IN exclusively. context Reception inv 'parameter': if not self.signal.oclIsUndefined then not self.ownedParameter.oclIsUndefined and self.ownedParameter.type = self.signal and self.ownedParameter.name = self.signal.name and self.ownedParameter.directionKind == ParameterDirectionKind::IN else endif This would ease the usage of BehavioralFeatures a lot, I'd say. In case of Messages, one would only have to walk over Message::signature::parameter instead of casting it down to either an Operation or Signal.. Curious about your comments. Marc-Florian ################################################ Marc-Florian Wendland Master of Science (M.Sc.) ------------------------------------------------ Fraunhofer Institut FOKUS Modeling und Testing Department Kaiserin-Augusta-Alle 31 D-10589 Berlin ------------------------------------------------ Tel: +49 (30) - 3463 7395 Email: marc-florian.wendland@fokus.fraunhofer.de ################################################ From: "Wendland, Marc-Florian" To: Ed Seidewitz CC: "uml25-ftf@omg.org" Subject: AW: Issue 17226: Message Signature in Interactions and Reception.ownedParameter Thread-Topic: Issue 17226: Message Signature in Interactions and Reception.ownedParameter Thread-Index: Ac4J57hldleO2owsS5e9EfxV12nP0AANkKeQAABv8oA= Date: Wed, 13 Feb 2013 19:42:38 +0000 Accept-Language: de-DE, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.147.78.16] 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-gate04-haj2 with C492B794001 X-cloud-security: scantime:.3349 X-Virus-Scanned: amavisd-new at omg.org X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id r1DJgn5W029531 Ed, dagnabit, I did not check the OCL, but only the Abstract Syntax of Receptions and the BehavioralFeature Semantics. Thanks for pointing me into the right direction. > But perhaps that is not too big a problem. I think so, too. Since I raised this issue initially, I would, of course, be happy if the group agrees on that change, but maybe we would need some statements from the vendors as well?! Regards, Marc-Florian -----Ursprühe Nachricht----- Von: Ed Seidewitz [mailto:ed-s@modeldriven.com] Gesendet: Mittwoch, 13. Februar 2013 20:17 An: Wendland, Marc-Florian Cc: uml25-ftf@omg.org Betreff: RE: Issue 17226: Message Signature in Interactions and Reception.ownedParameter Marc-Florian -- Not only is this still desired, but UML 2.5 actually has the following constraint on Reception: same_structure_as_signal A Reception's parameters match the ownedAttributes of its signal by name, type, and multiplicity [I won't both to copy the OCL.] Allowing a Message signature to be a BehavioralFeature, in general, does make sense to me. It would have to be considered an "enhancement", though, in that it would have some interoperability considerations. Namely, it would mean UML 2.5 models that used Receptions as Message signatures would technically be valid as UML 2.4.1 models. But perhaps that is not too big a problem. -- Ed -----Original Message----- From: Wendland, Marc-Florian [mailto:marc-florian.wendland@fokus.fraunhofer.de] Sent: Wednesday, February 13, 2013 2:06 PM To: Ed Seidewitz Cc: uml25-ftf@omg.org Subject: Issue 17226: Message Signature in Interactions and Reception.ownedParameter Hi Ed, Hi all, I started a discussion (see mail below) about how Reception relates to BehavioralFeature.ownedParameters (currently, there is no relation at all, neither a formal nor and editorial one) about a year ago or so. This is related to issue 17226 (http://www.omg.org/issues/uml2-rtf.open.html#Issue17226) and would help to significantly simplify processing message signatures without adding any further restrictions to the user with respect of maturity or degree of completion of the model (to reassure Bran, it would still be possible to just draw a signal message without having a Reception on the receiving Lifeline). Ed, your comment during the RFP those days was: "On Reception parameters, we agreed during the last UML 2.5 submitters call that the ownedParameters of a Reception should be required to be all in Parameters that correspond one-to-one with the attributes of the Signal referenced by the Reception. This is consistent with how the Reception is invoked as a BehavioralFeature and with how the arguments are matched to Parameters on a Message." Is this still desired (I hope so). Because this would allow to change the allowed NamedElement for Message.signature from Operation or Signal to BehavioralFeature or Signal. Not sure, whether this would be possible in the FTF, but it would not require metamodel, but OCL constraint changes in the spec. Regards, Marc-Florian -----Ursprühe Nachricht----- Von: Ed Seidewitz [mailto:ed-s@modeldriven.com] Gesendet: Montag, 12. Mä 2012 17:20 An: Wendland, Marc-Florian Cc: uml2-rtf@omg.org Betreff: RE: Message Signature in Interactions and Reception.ownedParameter Marc-Florian -- I agree that having the signature of an operation be either an Operation or a Signal is cumbersome. However, while have the signature be a BehavioralFeature would, indeed, be far more consistent, I unfortunately think that this would be to large a change for us to make at this point. Right now, you can have an Interaction with Messages whose signatures are Signals for which the target lifeline does not represent anything with a Reception for that Signal. This is, in fact, not uncommon, since most people seem to be pretty loose about modeling Receptions explicitly. With your proposed change, all these Interactions would become invalid. On Reception parameters, we agreed during the last UML 2.5 submitters call that the ownedParameters of a Reception should be required to be all in Parameters that correspond one-to-one with the attributes of the Signal referenced by the Reception. This is consistent with how the Reception is invoked as a BehavioralFeature and with how the arguments are matched to Parameters on a Message. -- Ed -----Original Message----- From: Wendland, Marc-Florian [mailto:marc-florian.wendland@fokus.fraunhofer.de] Sent: Monday, March 12, 2012 3:02 AM To: uml2-rtf@omg.org Subject: Message Signature in Interactions and Reception.ownedParameter Hi all, currently (till 2.5) a message's signature is of type NamedElement that resolves either to an Operation or Signal. Apart from the fact that the nearest common superclass is Namespace, the use of elements of different inheritance hierarchies makes it cumbersome/impractical to work with the signatures easily. You always have to check what concrete signature is associated, cast it into the appropriate subclass (i.e. either Signal or Operation) and use it further. Regarding Message::Signature, I was wondering, whether it wouldn't be simpler and far more consistent to refer to a BehavioralFeature (Operation/Reception which has to have an Signal associated) directly instead of NamedElement (which ought to be Namespace)? This leads to a situation where I was wondering why a Reception, though it is a BehavioralFeature, does not say any word about owned parameters at all? However, if Receptions would be able to capture information about parameter, too, the treatment of Reception and Operation would be pretty much the same with regard to their parameter semantics. So, it might be worth to reconsider the relationship between BehavioralFeature, Reception and Parameter. We could supplement BehavioralFeature::ownedParameter {ordered, subsets Namespace::ownedMember} containment with /Reception::ownedParameter [0..1] {redefines BehavioralFeature::ownedParameter } containment The derivation algorithm of Reception::ownedParameter could be similar to the following: A Reception declares at most one Parameter. Its type and name must exactly the name and type of the Signal, referenced by Reception::signal, if present. The direction kind of a Reception's Parameter must be set to IN exclusively. context Reception inv 'parameter': if not self.signal.oclIsUndefined then not self.ownedParameter.oclIsUndefined and self.ownedParameter.type = self.signal and self.ownedParameter.name = self.signal.name and self.ownedParameter.directionKind == ParameterDirectionKind::IN else endif This would ease the usage of BehavioralFeatures a lot, I'd say. In case of Messages, one would only have to walk over Message::signature::parameter instead of casting it down to either an Operation or Signal.. Curious about your comments. Marc-Florian ################################################ Marc-Florian Wendland Master of Science (M.Sc.) ------------------------------------------------ Fraunhofer Institut FOKUS Modeling und Testing Department Kaiserin-Augusta-Alle 31 D-10589 Berlin ------------------------------------------------ Tel: +49 (30) - 3463 7395 Email: marc-florian.wendland@fokus.fraunhofer.de ################################################