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