Issue 12530: Behavior's parameter list (uml2-rtf) Source: International Business Machines (Mr. James Bruck, nobody) Nature: Uncategorized Issue Severity: Summary: We are concerned with the UML specification forcing an Behavior's parameter list to be in sync with its behavioral feature. >From the UML 2.1.1 07-02-03, page 431 (or 445/732) it states in the 13.3.2 Behaviors section the following constraint: [1] The parameters of the behavior must match the parameters of the implemented behavioral feature We feel that this constraint is unnecessary. The parameter list of a Behavior element can be derived from its behavioral feature. Forcing the Behavior to have its own list of parameters has practical implementation problems such as needlessly increasing the size of the UML model, and worse, forcing one to preform the tedious task (or the tool to preform the extra overhead) of keeping the parameter lists of the Behavior and its behavioral feature in sync. We would like to request that this constraint is removed from the specification. Resolution: Revised Text: Actions taken: June 13, 2008: received issue Discussion: End of Annotations:===== ubject: UML2 issue. X-Mailer: Lotus Notes Release 7.0 August 18, 2005 From: James Bruck Date: Fri, 13 Jun 2008 14:20:07 -0400 X-MIMETrack: Serialize by Router on D25ML03/25/M/IBM(Release 7.0.3FP1|February 24, 2008) at 06/13/2008 14:20:08, Serialize complete at 06/13/2008 14:20:08 Hi Juergen, Could you please raise the following issue with the UML2 spec. and create an issue number. Thanks, - James. ----------------------------------------------------------------------------------------------------------------------------------------------------------- We are concerned with the UML specification forcing an Behavior's parameter list to be in sync with its behavioral feature. >From the UML 2.1.1 07-02-03, page 431 (or 445/732) it states in the 13.3.2 Behaviors section the following constraint: [1] The parameters of the behavior must match the parameters of the implemented behavioral feature We feel that this constraint is unnecessary. The parameter list of a Behavior element can be derived from its behavioral feature. Forcing the Behavior to have its own list of parameters has practical implementation problems such as needlessly increasing the size of the UML model, and worse, forcing one to preform the tedious task (or the tool to preform the extra overhead) of keeping the parameter lists of the Behavior and its behavioral feature in sync. We would like to request that this constraint is removed from the specification. Subject: RE: issue 12530 -- UML 2 RTF issue Date: Fri, 13 Jun 2008 15:35:51 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: issue 12530 -- UML 2 RTF issue thread-index: AcjNhVKjgXFkn+OHRaW4Re5mFNWArQABjgDg From: "Ed Seidewitz" To: A behavior is not required to implement a behavioral feature. It may be stand-alone, callable using a call behavior action, and it can have parameters in order to pass data in and out. This is particularly common in activity modeling. If the behavior is, in fact, the method of a behavioral feature, then it would, indeed, be possible to derive the parameters of the behavior from the parameters of the behavioral feature. However, it would be rather awkward (though not impossible) to set up the abstract syntax metamodel so that the parameters of the behavior are derived from the behavioral feature, if it has one, and are owned by the behavior if it does not. One would have to distinguish between parameters and owned parameters, with the former always being derived, and the latter only allowed if there was no behavioral feature, etc. The current approach is consistent with the idea that the behavioral feature is a specification and the behavior is a structurally independent implementation, with the relationship between the two being one of conformance or .matching.. -- Ed -------------------------------------------------------------------------------- From: Juergen Boldt [mailto:juergen@omg.org] Sent: Friday, June 13, 2008 2:40 PM To: uml2-rtf@omg.org; issues@omg.org Subject: issue 12530 -- UML 2 RTF issue This is issue # 12530 From: James Bruck We are concerned with the UML specification forcing an Behavior's parameter list to be in sync with its behavioral feature. >From the UML 2.1.1 07-02-03, page 431 (or 445/732) it states in the 13.3.2 Behaviors section the following constraint: [1] The parameters of the behavior must match the parameters of the implemented behavioral feature We feel that this constraint is unnecessary. The parameter list of a Behavior element can be derived from its behavioral feature. Forcing the Behavior to have its own list of parameters has practical implementation problems such as needlessly increasing the size of the UML model, and worse, forcing one to preform the tedious task (or the tool to preform the extra overhead) of keeping the parameter lists of the Behavior and its behavioral feature in sync. We would like to request that this constraint is removed from the specification. Juergen Boldt Director, Member Services Object Management Group 140 Kendrick St Building A Suite 300 Needham, MA 02494 USA tel: +1 781 444 0404 x 132 fax: +1 781 444 0320 email: juergen@omg.org www.omg.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type:references; bh=ub72QkSvSOfXTTSiSLcQuj41BfQ0Gm1mWJDyw4RbdT8=; b=oDqOqisPOTfKA7rXh5yYWOwDOqCKRacGH3PPOiqpewa/6UAsTHbb2vKdV0ey96Vglv d/5mEMM5Mw0wJOK9F00P1ePvKvQxYyIysXuXSv3k904rc704GO8vCfewm++bAW2Esp2S sG7ekqa8UQMUR7LWOM93OPb2GvCYsZEEqsK2E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:references; b=IgHn8mMLWHpsMHplk09snDjeeuP7bTBghLEQx5+PJITqG4dITqV2WAlKbutoMB7hSJ Gw6X3WeqVB827UVKEIhd+sfTUQ1DB6mGKq5ga6lUS7+PFaT30/Ifqt9aGFb3X2BsD7Hu ueDoN73y4uVcJpygXtlorjRWZm1unFChwB3iM= Date: Fri, 13 Jun 2008 16:28:58 -0400 From: "Bran Selic" To: "Ed Seidewitz" Subject: Re: issue 12530 -- UML 2 RTF issue Cc: uml2-rtf@omg.org Actually, the "awkward" solution is the one I was thinking of. It's not that difficult to realize. Another alternative is to have a subclass of Behavior for those that are realizations of BehavioralFeatures. Bran On Fri, Jun 13, 2008 at 3:35 PM, Ed Seidewitz wrote: A behavior is not required to implement a behavioral feature. It may be stand-alone, callable using a call behavior action, and it can have parameters in order to pass data in and out. This is particularly common in activity modeling. If the behavior is, in fact, the method of a behavioral feature, then it would, indeed, be possible to derive the parameters of the behavior from the parameters of the behavioral feature. However, it would be rather awkward (though not impossible) to set up the abstract syntax metamodel so that the parameters of the behavior are derived from the behavioral feature, if it has one, and are owned by the behavior if it does not. One would have to distinguish between parameters and owned parameters, with the former always being derived, and the latter only allowed if there was no behavioral feature, etc. The current approach is consistent with the idea that the behavioral feature is a specification and the behavior is a structurally independent implementation, with the relationship between the two being one of conformance or "matching". -- Ed -------------------------------------------------------------------------------- From: Juergen Boldt [mailto:juergen@omg.org] Sent: Friday, June 13, 2008 2:40 PM To: uml2-rtf@omg.org; issues@omg.org Subject: issue 12530 -- UML 2 RTF issue This is issue # 12530 From: James Bruck We are concerned with the UML specification forcing an Behavior's parameter list to be in sync with its behavioral feature. >From the UML 2.1.1 07-02-03, page 431 (or 445/732) it states in the 13.3.2 Behaviors section the following constraint: [1] The parameters of the behavior must match the parameters of the implemented behavioral feature We feel that this constraint is unnecessary. The parameter list of a Behavior element can be derived from its behavioral feature. Forcing the Behavior to have its own list of parameters has practical implementation problems such as needlessly increasing the size of the UML model, and worse, forcing one to preform the tedious task (or the tool to preform the extra overhead) of keeping the parameter lists of the Behavior and its behavioral feature in sync. We would like to request that this constraint is removed from the specification. Juergen Boldt Director, Member Services Object Management Group 140 Kendrick St Building A Suite 300 Needham, MA 02494 USA tel: +1 781 444 0404 x 132 fax: +1 781 444 0320 email: juergen@omg.org www.omg.org -- Bran Selic DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type:references; bh=ub72QkSvSOfXTTSiSLcQuj41BfQ0Gm1mWJDyw4RbdT8=; b=oDqOqisPOTfKA7rXh5yYWOwDOqCKRacGH3PPOiqpewa/6UAsTHbb2vKdV0ey96Vglv d/5mEMM5Mw0wJOK9F00P1ePvKvQxYyIysXuXSv3k904rc704GO8vCfewm++bAW2Esp2S sG7ekqa8UQMUR7LWOM93OPb2GvCYsZEEqsK2E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:references; b=IgHn8mMLWHpsMHplk09snDjeeuP7bTBghLEQx5+PJITqG4dITqV2WAlKbutoMB7hSJ Gw6X3WeqVB827UVKEIhd+sfTUQ1DB6mGKq5ga6lUS7+PFaT30/Ifqt9aGFb3X2BsD7Hu ueDoN73y4uVcJpygXtlorjRWZm1unFChwB3iM= Date: Fri, 13 Jun 2008 16:28:58 -0400 From: "Bran Selic" To: "Ed Seidewitz" Subject: Re: issue 12530 -- UML 2 RTF issue Cc: uml2-rtf@omg.org Actually, the "awkward" solution is the one I was thinking of. It's not that difficult to realize. Another alternative is to have a subclass of Behavior for those that are realizations of BehavioralFeatures. Bran On Fri, Jun 13, 2008 at 3:35 PM, Ed Seidewitz wrote: A behavior is not required to implement a behavioral feature. It may be stand-alone, callable using a call behavior action, and it can have parameters in order to pass data in and out. This is particularly common in activity modeling. If the behavior is, in fact, the method of a behavioral feature, then it would, indeed, be possible to derive the parameters of the behavior from the parameters of the behavioral feature. However, it would be rather awkward (though not impossible) to set up the abstract syntax metamodel so that the parameters of the behavior are derived from the behavioral feature, if it has one, and are owned by the behavior if it does not. One would have to distinguish between parameters and owned parameters, with the former always being derived, and the latter only allowed if there was no behavioral feature, etc. The current approach is consistent with the idea that the behavioral feature is a specification and the behavior is a structurally independent implementation, with the relationship between the two being one of conformance or "matching". -- Ed -------------------------------------------------------------------------------- From: Juergen Boldt [mailto:juergen@omg.org] Sent: Friday, June 13, 2008 2:40 PM To: uml2-rtf@omg.org; issues@omg.org Subject: issue 12530 -- UML 2 RTF issue This is issue # 12530 From: James Bruck We are concerned with the UML specification forcing an Behavior's parameter list to be in sync with its behavioral feature. >From the UML 2.1.1 07-02-03, page 431 (or 445/732) it states in the 13.3.2 Behaviors section the following constraint: [1] The parameters of the behavior must match the parameters of the implemented behavioral feature We feel that this constraint is unnecessary. The parameter list of a Behavior element can be derived from its behavioral feature. Forcing the Behavior to have its own list of parameters has practical implementation problems such as needlessly increasing the size of the UML model, and worse, forcing one to preform the tedious task (or the tool to preform the extra overhead) of keeping the parameter lists of the Behavior and its behavioral feature in sync. We would like to request that this constraint is removed from the specification. Juergen Boldt Director, Member Services Object Management Group 140 Kendrick St Building A Suite 300 Needham, MA 02494 USA tel: +1 781 444 0404 x 132 fax: +1 781 444 0320 email: juergen@omg.org www.omg.org -- Bran Selic Malina Software Corp. Subject: RE: issue 12530 -- UML 2 RTF issue Date: Fri, 13 Jun 2008 17:39:23 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: issue 12530 -- UML 2 RTF issue thread-index: AcjNlDZ7/iw9B42CQOyNpTUigknU3wAADKKg From: "Ed Seidewitz" To: "Bran Selic" Cc: Bran . The subclass approach would be even more awkward, I think, because Behavior already has several concrete subclasses, which would have to be subclassed, too. So, you would have to have method and non-method versions of Activity, StateMachine, etc. I wouldn.t go that way. Whether other folks find the non-subclassing solution awkward or not is for them to say. -- Ed -------------------------------------------------------------------------------- From: Bran Selic [mailto:bran.selic@gmail.com] Sent: Friday, June 13, 2008 4:29 PM To: Ed Seidewitz Cc: uml2-rtf@omg.org Subject: Re: issue 12530 -- UML 2 RTF issue Actually, the "awkward" solution is the one I was thinking of. It's not that difficult to realize. Another alternative is to have a subclass of Behavior for those that are realizations of BehavioralFeatures. Bran On Fri, Jun 13, 2008 at 3:35 PM, Ed Seidewitz wrote: A behavior is not required to implement a behavioral feature. It may be stand-alone, callable using a call behavior action, and it can have parameters in order to pass data in and out. This is particularly common in activity modeling. If the behavior is, in fact, the method of a behavioral feature, then it would, indeed, be possible to derive the parameters of the behavior from the parameters of the behavioral feature. However, it would be rather awkward (though not impossible) to set up the abstract syntax metamodel so that the parameters of the behavior are derived from the behavioral feature, if it has one, and are owned by the behavior if it does not. One would have to distinguish between parameters and owned parameters, with the former always being derived, and the latter only allowed if there was no behavioral feature, etc. The current approach is consistent with the idea that the behavioral feature is a specification and the behavior is a structurally independent implementation, with the relationship between the two being one of conformance or "matching". -- Ed -------------------------------------------------------------------------------- From: Juergen Boldt [mailto:juergen@omg.org] Sent: Friday, June 13, 2008 2:40 PM To: uml2-rtf@omg.org; issues@omg.org Subject: issue 12530 -- UML 2 RTF issue This is issue # 12530 From: James Bruck We are concerned with the UML specification forcing an Behavior's parameter list to be in sync with its behavioral feature. >From the UML 2.1.1 07-02-03, page 431 (or 445/732) it states in the 13.3.2 Behaviors section the following constraint: [1] The parameters of the behavior must match the parameters of the implemented behavioral feature We feel that this constraint is unnecessary. The parameter list of a Behavior element can be derived from its behavioral feature. Forcing the Behavior to have its own list of parameters has practical implementation problems such as needlessly increasing the size of the UML model, and worse, forcing one to preform the tedious task (or the tool to preform the extra overhead) of keeping the parameter lists of the Behavior and its behavioral feature in sync. We would like to request that this constraint is removed from the specification. Juergen Boldt Director, Member Services Object Management Group 140 Kendrick St Building A Suite 300 Needham, MA 02494 USA tel: +1 781 444 0404 x 132 fax: +1 781 444 0320 email: juergen@omg.org www.omg.org -- Bran Selic Malina Software Corp. DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type:references; bh=KrhFC/EShETz4FlLfgEUJjA00lmB5/rRXIGHx7BBut4=; b=qqdTc5OYccMP9yWgWZRymCVmQNMKZ3GqXVAARdqGS0p1LPZwBz7Zw/4CuX/CQULt5q GUfCdPBeuLxhzimUFuJkMl8p4WLjqQ+ZxmqkEjO7xzce3fe5X6vSamznAvDpQa2HKblB ShRm+3v322V8ve9HCkp/Y54Szf1eLr7hTWn+w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:references; b=t8w+4szAUAH57nOiZEBcDfxQyIRbjJNV4PeSZ/Lr7pdODscZvPtFoW+ikL3nJCVbjI 4sofVGB7lV6kVWSzWWuUA/tIdDE0SjZd8/UU8/p3bJ/xJG6uiVxF5YQ7aNnda6P/suBH MCa/LFmAaguo6EfrfOMqSMLfsn15fHccRh79Y= Date: Fri, 13 Jun 2008 17:48:24 -0400 From: "Bran Selic" To: "Thomas Weigert" Subject: Re: issue 12530 -- UML 2 RTF issue Cc: "Ed Seidewitz" , uml2-rtf@omg.org, "James Bruck" My understanding is that the problem is that this duplication of information significantly bulks up models. However, James Bruck, who raised the issue, may have more information. Bran On Fri, Jun 13, 2008 at 5:36 PM, Thomas Weigert wrote: Before we all get excited about this, can we understand the motivation behind this issue? The situation is as Ed says, I believe. The constraint does not cause any problems for stand-alone behaviors, I think. Th. From: Bran Selic [mailto:bran.selic@gmail.com] Sent: Friday, June 13, 2008 3:29 PM To: Ed Seidewitz Cc: uml2-rtf@omg.org Subject: Re: issue 12530 -- UML 2 RTF issue Actually, the "awkward" solution is the one I was thinking of. It's not that difficult to realize. Another alternative is to have a subclass of Behavior for those that are realizations of BehavioralFeatures. Bran On Fri, Jun 13, 2008 at 3:35 PM, Ed Seidewitz wrote: A behavior is not required to implement a behavioral feature. It may be stand-alone, callable using a call behavior action, and it can have parameters in order to pass data in and out. This is particularly common in activity modeling. If the behavior is, in fact, the method of a behavioral feature, then it would, indeed, be possible to derive the parameters of the behavior from the parameters of the behavioral feature. However, it would be rather awkward (though not impossible) to set up the abstract syntax metamodel so that the parameters of the behavior are derived from the behavioral feature, if it has one, and are owned by the behavior if it does not. One would have to distinguish between parameters and owned parameters, with the former always being derived, and the latter only allowed if there was no behavioral feature, etc. The current approach is consistent with the idea that the behavioral feature is a specification and the behavior is a structurally independent implementation, with the relationship between the two being one of conformance or "matching". -- Ed -------------------------------------------------------------------------------- From: Juergen Boldt [mailto:juergen@omg.org] Sent: Friday, June 13, 2008 2:40 PM To: uml2-rtf@omg.org; issues@omg.org Subject: issue 12530 -- UML 2 RTF issue This is issue # 12530 From: James Bruck We are concerned with the UML specification forcing an Behavior's parameter list to be in sync with its behavioral feature. >From the UML 2.1.1 07-02-03, page 431 (or 445/732) it states in the 13.3.2 Behaviors section the following constraint: [1] The parameters of the behavior must match the parameters of the implemented behavioral feature We feel that this constraint is unnecessary. The parameter list of a Behavior element can be derived from its behavioral feature. Forcing the Behavior to have its own list of parameters has practical implementation problems such as needlessly increasing the size of the UML model, and worse, forcing one to preform the tedious task (or the tool to preform the extra overhead) of keeping the parameter lists of the Behavior and its behavioral feature in sync. We would like to request that this constraint is removed from the specification. -- Bran Selic Malina Software Corp. To: "Bran Selic" Cc: "Ed Seidewitz" , uml2-rtf@omg.org, "Thomas Weigert" , Anthony Hunter , Maged Elaasar Subject: Re: issue 12530 -- UML 2 RTF issue X-Mailer: Lotus Notes Release 7.0 August 18, 2005 From: James Bruck Date: Mon, 16 Jun 2008 11:05:08 -0400 X-MIMETrack: Serialize by Router on D25ML03/25/M/IBM(Release 7.0.3FP1|February 24, 2008) at 06/16/2008 11:05:10, Serialize complete at 06/16/2008 11:05:10 Hi, The motiviation behind the issue stems from some practical implementation concerns. As Bran mentioned, one issue has to do with duplication of information in serialized models. Another issue has to do with keeping the parameters of the Behavior matched up with the parameters of the implemented BehavioralFeature (its specification). In order to verify the constraint, we can't for example, simply assume that the parameters will match just because the specification is explicitly set. Having only one copy of the parameter list would also help with ensuring that changes in one spot would keep the entire model in a consistent state. As Ed pointed out, in a case where no specification is set, explicitly setting the parameters would be necessary; however, we were focusing on cases where a specification was explicitly being set. Cheers, - James. "Bran Selic" 13/06/2008 05:48 PM To "Thomas Weigert" cc "Ed Seidewitz" , uml2-rtf@omg.org, James Bruck/Ottawa/IBM@IBMCA Subject Re: issue 12530 -- UML 2 RTF issue My understanding is that the problem is that this duplication of information significantly bulks up models. However, James Bruck, who raised the issue, may have more information. Bran On Fri, Jun 13, 2008 at 5:36 PM, Thomas Weigert wrote: Before we all get excited about this, can we understand the motivation behind this issue? The situation is as Ed says, I believe. The constraint does not cause any problems for stand-alone behaviors, I think. Th. From: Bran Selic [mailto:bran.selic@gmail.com] Sent: Friday, June 13, 2008 3:29 PM To: Ed Seidewitz Cc: uml2-rtf@omg.org Subject: Re: issue 12530 -- UML 2 RTF issue Actually, the "awkward" solution is the one I was thinking of. It's not that difficult to realize. Another alternative is to have a subclass of Behavior for those that are realizations of BehavioralFeatures. Bran On Fri, Jun 13, 2008 at 3:35 PM, Ed Seidewitz wrote: A behavior is not required to implement a behavioral feature. It may be stand-alone, callable using a call behavior action, and it can have parameters in order to pass data in and out. This is particularly common in activity modeling. If the behavior is, in fact, the method of a behavioral feature, then it would, indeed, be possible to derive the parameters of the behavior from the parameters of the behavioral feature. However, it would be rather awkward (though not impossible) to set up the abstract syntax metamodel so that the parameters of the behavior are derived from the behavioral feature, if it has one, and are owned by the behavior if it does not. One would have to distinguish between parameters and owned parameters, with the former always being derived, and the latter only allowed if there was no behavioral feature, etc. The current approach is consistent with the idea that the behavioral feature is a specification and the behavior is a structurally independent implementation, with the relationship between the two being one of conformance or "matching". -- Ed -------------------------------------------------------------------------------- From: Juergen Boldt [mailto:juergen@omg.org] Sent: Friday, June 13, 2008 2:40 PM To: uml2-rtf@omg.org; issues@omg.org Subject: issue 12530 -- UML 2 RTF issue This is issue # 12530 From: James Bruck We are concerned with the UML specification forcing an Behavior's parameter list to be in sync with its behavioral feature. >From the UML 2.1.1 07-02-03, page 431 (or 445/732) it states in the 13.3.2 Behaviors section the following constraint: [1] The parameters of the behavior must match the parameters of the implemented behavioral feature We feel that this constraint is unnecessary. The parameter list of a Behavior element can be derived from its behavioral feature. Forcing the Behavior to have its own list of parameters has practical implementation problems such as needlessly increasing the size of the UML model, and worse, forcing one to preform the tedious task (or the tool to preform the extra overhead) of keeping the parameter lists of the Behavior and its behavioral feature in sync. We would like to request that this constraint is removed from the specification. -- Bran Selic Malina Software Corp. Subject: RE: issue 12530 -- UML 2 RTF issue Date: Wed, 18 Jun 2008 21:54:47 -0500 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: issue 12530 -- UML 2 RTF issue Thread-Index: AcjPxRO5vbTDSnVuT3mIH0QR3OYxjgB8LUhA From: "Weigert, Thomas" To: "James Bruck" , "Bran Selic" Cc: "Ed Seidewitz" , , "Thomas Weigert" , "Anthony Hunter" , "Maged Elaasar" X-OriginalArrivalTime: 19 Jun 2008 02:54:52.0735 (UTC) FILETIME=[D8D88CF0:01C8D1B7] X-SpamInfo: FortiGuard - AntiSpam ip, connection black ip 209.106.228.53 James, Your suggestion proposes to make major changes to the intention of the separation of the behavior specification (the behavioral feature) and the behavior implementation (the behavior). This separation goes back to UML 1. 1. A behavioral feature declares that an object will handle certain requests. 2. A behavior implements how the object handles those requests. 3. Which behavior will be invoked in response to a matching request arriving is determined by the particular semantics of the modeling language/profile (due to the wide variation possible this is a semantic variation point). It is not necessarily the Behavior that is the behavior pointed to by the BehavioralFeature. a. One example might be that one searches the hierarchy up from the pointed to behavior until one finds a behavior with an appropriate signature. b. This may involve multiple dispatch (i.e., matching on more than one parameter type), the type of the first parameter, strict identify on all parameters, name matching, or many more. As you can see, the duplication of the parameter list is inherently built into the UML. Taking this away may be a practical suggestion, but is a major change. These two parameter lists serve totally different purpose: · The parameter list on behavioral feature establishes which behavior invocation requests are accepted by the object. · The parameter list on behavior establishes which behavior will be actually invoked to handle the request. In some languages that there are two such lists appears redundant. But in other languages this is essential. The only simplification that we could do without dramatically changing the language would be to allow the list to be omitted with a reasonable default interpretation. For example, one could say that if a behavioral feature does not have a parameter list, its parameter list is derived from the pointed to behavior, but note that there are many complications: What if there is no behavior in this object, but the behavior is inherited down---the parameters cannot be taken from there. Note further that this scheme would limit the flexibility of the specification of the behavior. Note that your suggestion is just one step away from suggesting that we do not need the concept of a BehavioralFeature, as that concept could be subsumed by Interface. If we were to follow your suggestion, using Interfaces to specify a behavioral feature would be more powerful than just eliminating the parameter list. Either way, this is a big change. Th. From: James Bruck [mailto:jbruck@ca.ibm.com] Sent: Monday, June 16, 2008 10:05 AM To: Bran Selic Cc: Ed Seidewitz; uml2-rtf@omg.org; Thomas Weigert; Anthony Hunter; Maged Elaasar Subject: Re: issue 12530 -- UML 2 RTF issue Hi, The motiviation behind the issue stems from some practical implementation concerns. As Bran mentioned, one issue has to do with duplication of information in serialized models. Another issue has to do with keeping the parameters of the Behavior matched up with the parameters of the implemented BehavioralFeature (its specification). In order to verify the constraint, we can't for example, simply assume that the parameters will match just because the specification is explicitly set. Having only one copy of the parameter list would also help with ensuring that changes in one spot would keep the entire model in a consistent state. As Ed pointed out, in a case where no specification is set, explicitly setting the parameters would be necessary; however, we were focusing on cases where a specification was explicitly being set. Cheers, - James. "Bran Selic" 13/06/2008 05:48 PM To "Thomas Weigert" cc "Ed Seidewitz" , uml2-rtf@omg.org, James Bruck/Ottawa/IBM@IBMCA Subject Re: issue 12530 -- UML 2 RTF issue My understanding is that the problem is that this duplication of information significantly bulks up models. However, James Bruck, who raised the issue, may have more information. Bran On Fri, Jun 13, 2008 at 5:36 PM, Thomas Weigert wrote: Before we all get excited about this, can we understand the motivation behind this issue? The situation is as Ed says, I believe. The constraint does not cause any problems for stand-alone behaviors, I think. Th. From: Bran Selic [mailto:bran.selic@gmail.com] Sent: Friday, June 13, 2008 3:29 PM To: Ed Seidewitz Cc: uml2-rtf@omg.org Subject: Re: issue 12530 -- UML 2 RTF issue Actually, the "awkward" solution is the one I was thinking of. It's not that difficult to realize. Another alternative is to have a subclass of Behavior for those that are realizations of BehavioralFeatures. Bran On Fri, Jun 13, 2008 at 3:35 PM, Ed Seidewitz wrote: A behavior is not required to implement a behavioral feature. It may be stand-alone, callable using a call behavior action, and it can have parameters in order to pass data in and out. This is particularly common in activity modeling. If the behavior is, in fact, the method of a behavioral feature, then it would, indeed, be possible to derive the parameters of the behavior from the parameters of the behavioral feature. However, it would be rather awkward (though not impossible) to set up the abstract syntax metamodel so that the parameters of the behavior are derived from the behavioral feature, if it has one, and are owned by the behavior if it does not. One would have to distinguish between parameters and owned parameters, with the former always being derived, and the latter only allowed if there was no behavioral feature, etc. The current approach is consistent with the idea that the behavioral feature is a specification and the behavior is a structurally independent implementation, with the relationship between the two being one of conformance or "matching". -- Ed -------------------------------------------------------------------------------- From: Juergen Boldt [mailto:juergen@omg.org] Sent: Friday, June 13, 2008 2:40 PM To: uml2-rtf@omg.org; issues@omg.org Subject: issue 12530 -- UML 2 RTF issue This is issue # 12530 From: James Bruck We are concerned with the UML specification forcing an Behavior's parameter list to be in sync with its behavioral feature. >From the UML 2.1.1 07-02-03, page 431 (or 445/732) it states in the 13.3.2 Behaviors section the following constraint: [1] The parameters of the behavior must match the parameters of the implemented behavioral feature We feel that this constraint is unnecessary. The parameter list of a Behavior element can be derived from its behavioral feature. Forcing the Behavior to have its own list of parameters has practical implementation problems such as needlessly increasing the size of the UML model, and worse, forcing one to preform the tedious task (or the tool to preform the extra overhead) of keeping the parameter lists of the Behavior and its behavioral feature in sync. We would like to request that this constraint is removed from the specification. -- Bran Selic Malina Software Corp. Subject: RE: issue 12530 -- UML 2 RTF issue To: "Weigert, Thomas" Cc: Anthony Hunter , "Bran Selic" , "Ed Seidewitz" , James Bruck , uml2-rtf@omg.org, "Thomas Weigert" , Jim Amsden X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Maged Elaasar Date: Thu, 19 Jun 2008 10:08:28 -0400 X-MIMETrack: Serialize by Router on D25ML03/25/M/IBM(Release 7.0.3FP1|February 24, 2008) at 06/19/2008 10:08:29 >>The only simplification that we could do without dramatically changing the language would be to allow the list to be omitted with a reasonable default interpretation. For example, one could say that if a behavioral feature does not have a parameter list, its parameter list is derived from the pointed to behavior, but note that there are many complications: What if there is no behavior in this object, but the behavior is inherited down---the parameters cannot be taken from there. Note further that this scheme would limit the flexibility of the specification of the behavior. Thomas, I think what James is suggesting is the other way around: if a Behavior has a specification set (a behavioral feature), but no owned parameters, then that list gets derived from the parameter list of the specification. Since currently a Behavior's specification has to be owned by the same classifier owning the behavior, you are guraranteed to find it and not search for it up in the hierarchy. So as it stands now in practice, we have 2 sets of parameters to keep in synch: one defined in the behavior feature of the classifier (the specification), and one in the Behavior (the method). In fact, considering the case where that behavioral feature also matces another one declared by an interface realized by the classifier, we have yet another set of parameters to keep in synch (total of 3). Jim Amsden actually touched on this same issue regarding having to duplicate the behavioral feature, hence also the parameters, in implementing classifiers in a separate issue before. As you said, that was designed intentionally in UML to separate concerns, however maybe with good assumptions for default values, we can optimize the common case in practice. ------------------------------------- Maged Elaasar, PhD Candidate Senior Software Developer, Team Lead OMG Representative for UML / DD Rational Modeling Platform/ Tools Rational Software, IBM Software Group, Canada melaasar@ca.ibm.com tel: 613-591-7935 "Weigert, Thomas" "Weigert, Thomas" 06/18/2008 10:54 PM To James Bruck/Ottawa/IBM@IBMCA, "Bran Selic" cc "Ed Seidewitz" , , "Thomas Weigert" , Anthony Hunter/Ottawa/IBM@IBMCA, Maged Elaasar/Ottawa/IBM@IBMCA Subject RE: issue 12530 -- UML 2 RTF issue James, Your suggestion proposes to make major changes to the intention of the separation of the behavior specification (the behavioral feature) and the behavior implementation (the behavior). This separation goes back to UML 1. 1. A behavioral feature declares that an object will handle certain requests. 2. A behavior implements how the object handles those requests. 3. Which behavior will be invoked in response to a matching request arriving is determined by the particular semantics of the modeling language/profile (due to the wide variation possible this is a semantic variation point). It is not necessarily the Behavior that is the behavior pointed to by the BehavioralFeature. a. One example might be that one searches the hierarchy up from the pointed to behavior until one finds a behavior with an appropriate signature. b. This may involve multiple dispatch (i.e., matching on more than one parameter type), the type of the first parameter, strict identify on all parameters, name matching, or many more. As you can see, the duplication of the parameter list is inherently built into the UML. Taking this away may be a practical suggestion, but is a major change. These two parameter lists serve totally different purpose: · The parameter list on behavioral feature establishes which behavior invocation requests are accepted by the object. · The parameter list on behavior establishes which behavior will be actually invoked to handle the request. In some languages that there are two such lists appears redundant. But in other languages this is essential. The only simplification that we could do without dramatically changing the language would be to allow the list to be omitted with a reasonable default interpretation. For example, one could say that if a behavioral feature does not have a parameter list, its parameter list is derived from the pointed to behavior, but note that there are many complications: What if there is no behavior in this object, but the behavior is inherited down---the parameters cannot be taken from there. Note further that this scheme would limit the flexibility of the specification of the behavior. Note that your suggestion is just one step away from suggesting that we do not need the concept of a BehavioralFeature, as that concept could be subsumed by Interface. If we were to follow your suggestion, using Interfaces to specify a behavioral feature would be more powerful than just eliminating the parameter list. Either way, this is a big change. Th. From: James Bruck [mailto:jbruck@ca.ibm.com] Sent: Monday, June 16, 2008 10:05 AM To: Bran Selic Cc: Ed Seidewitz; uml2-rtf@omg.org; Thomas Weigert; Anthony Hunter; Maged Elaasar Subject: Re: issue 12530 -- UML 2 RTF issue Hi, The motiviation behind the issue stems from some practical implementation concerns. As Bran mentioned, one issue has to do with duplication of information in serialized models. Another issue has to do with keeping the parameters of the Behavior matched up with the parameters of the implemented BehavioralFeature (its specification). In order to verify the constraint, we can't for example, simply assume that the parameters will match just because the specification is explicitly set. Having only one copy of the parameter list would also help with ensuring that changes in one spot would keep the entire model in a consistent state. As Ed pointed out, in a case where no specification is set, explicitly setting the parameters would be necessary; however, we were focusing on cases where a specification was explicitly being set. Cheers, - James. "Bran Selic" 13/06/2008 05:48 PM To "Thomas Weigert" cc "Ed Seidewitz" , uml2-rtf@omg.org, James Bruck/Ottawa/IBM@IBMCA Subject Re: issue 12530 -- UML 2 RTF issue My understanding is that the problem is that this duplication of information significantly bulks up models. However, James Bruck, who raised the issue, may have more information. Bran On Fri, Jun 13, 2008 at 5:36 PM, Thomas Weigert wrote: Before we all get excited about this, can we understand the motivation behind this issue? The situation is as Ed says, I believe. The constraint does not cause any problems for stand-alone behaviors, I think. Th. From: Bran Selic [mailto:bran.selic@gmail.com] Sent: Friday, June 13, 2008 3:29 PM To: Ed Seidewitz Cc: uml2-rtf@omg.org Subject: Re: issue 12530 -- UML 2 RTF issue Actually, the "awkward" solution is the one I was thinking of. It's not that difficult to realize. Another alternative is to have a subclass of Behavior for those that are realizations of BehavioralFeatures. Bran On Fri, Jun 13, 2008 at 3:35 PM, Ed Seidewitz wrote: A behavior is not required to implement a behavioral feature. It may be stand-alone, callable using a call behavior action, and it can have parameters in order to pass data in and out. This is particularly common in activity modeling. If the behavior is, in fact, the method of a behavioral feature, then it would, indeed, be possible to derive the parameters of the behavior from the parameters of the behavioral feature. However, it would be rather awkward (though not impossible) to set up the abstract syntax metamodel so that the parameters of the behavior are derived from the behavioral feature, if it has one, and are owned by the behavior if it does not. One would have to distinguish between parameters and owned parameters, with the former always being derived, and the latter only allowed if there was no behavioral feature, etc. The current approach is consistent with the idea that the behavioral feature is a specification and the behavior is a structurally independent implementation, with the relationship between the two being one of conformance or "matching". -- Ed -------------------------------------------------------------------------------- From: Juergen Boldt [mailto:juergen@omg.org] Sent: Friday, June 13, 2008 2:40 PM To: uml2-rtf@omg.org; issues@omg.org Subject: issue 12530 -- UML 2 RTF issue This is issue # 12530 From: James Bruck We are concerned with the UML specification forcing an Behavior's parameter list to be in sync with its behavioral feature. >From the UML 2.1.1 07-02-03, page 431 (or 445/732) it states in the 13.3.2 Behaviors section the following constraint: [1] The parameters of the behavior must match the parameters of the implemented behavioral feature We feel that this constraint is unnecessary. The parameter list of a Behavior element can be derived from its behavioral feature. Forcing the Behavior to have its own list of parameters has practical implementation problems such as needlessly increasing the size of the UML model, and worse, forcing one to preform the tedious task (or the tool to preform the extra overhead) of keeping the parameter lists of the Behavior and its behavioral feature in sync. We would like to request that this constraint is removed from the specification. -- Bran Selic Malina Software Corp. Subject: RE: issue 12530 -- UML 2 RTF issue To: "Thomas Weigert" Cc: Anthony Hunter , "'Bran Selic'" , "'Ed Seidewitz'" , James Bruck , "'Jim Amsden'" , uml2-rtf@omg.org, "Weigert, Thomas" X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Maged Elaasar Date: Thu, 19 Jun 2008 10:49:07 -0400 X-MIMETrack: Serialize by Router on D25ML03/25/M/IBM(Release 7.0.3FP1|February 24, 2008) at 06/19/2008 10:49:10 >>Say you have an inheritance chain where you have classes C1 inherits from C2 inherits from C3. C2 and C3 each have behavior B, without parameter list, but no behavioral feature corresponding to it. Here is already a problem in that we cannot statically analyze B as we do not know the types of its parameters. The case I was referring to "requires" 1) the Behavior to have a BF specified 2) empty ownedParameters in the Behavior, in order to derive its parameters. The example you gave here says " with no behavioral feature corresponding to it", so I think it is not a valid example of my case. In fact in this example, Behavior B's lack of parameters is either OK if B's design does not refer to any parameters, or "wrong" because it refers to parameters that do not exist and cannot be derived. >>Continue the scenario. C1 has a behavior B also, with some parameter list. C1 has a behavioral feature BF pointing to B. Now imagine a case where the behavioral feature BF is invoked with parameters not matching the parameters on B, so another behavior has to be found. But none of the behaviors up the chain have parameters defined, so we cannot infer anything. based on what I said above, there is still no inconsistency since in this case behaviors B from super classes would not be candidates for C1's BF method as they do not refer in any way to a matching BF. Also there would be an inconsistency in C1's BF if the method B it refers to has non compatible parameters. ------------------------------------- Maged Elaasar, PhD Candidate Senior Software Developer, Team Lead OMG Representative for UML / DD Rational Modeling Platform/ Tools Rational Software, IBM Software Group, Canada melaasar@ca.ibm.com tel: 613-591-7935 "Thomas Weigert" "Thomas Weigert" 06/19/2008 10:17 AM To Maged Elaasar/Ottawa/IBM@IBMCA, "Weigert, Thomas" cc Anthony Hunter/Ottawa/IBM@IBMCA, "'Bran Selic'" , "'Ed Seidewitz'" , James Bruck/Ottawa/IBM@IBMCA, , "'Jim Amsden'" Subject RE: issue 12530 -- UML 2 RTF issue You may be right in inferring James. intentions, but they are certainly not clear from his message and the following discussion. First, let.s stop talking about duplicated or replicated parameter lists, as they all serve different purposes and may in fact differ from each other even in the same class. I assume from now on that it is agreed that it must be possible to have separate parameter lists for (i) behavioral feature (ii) behavior and (iii) interfaces. So the discussion is on whether we can elide some of these lists and what the inferred parameters would be. Your proposal of allowing eliding the behavior parameters and inferring from the behavioral feature is the most natural and avoids the problem pointed to below. However, it also has a problem of its own: Say you have an inheritance chain where you have classes C1 inherits from C2 inherits from C3. C2 and C3 each have behavior B, without parameter list, but no behavioral feature corresponding to it. Here is already a problem in that we cannot statically analyze B as we do not know the types of its parameters. Continue the scenario. C1 has a behavior B also, with some parameter list. C1 has a behavioral feature BF pointing to B. Now imagine a case where the behavioral feature BF is invoked with parameters not matching the parameters on B, so another behavior has to be found. But none of the behaviors up the chain have parameters defined, so we cannot infer anything. Th. From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: Thursday, June 19, 2008 9:08 AM To: Weigert, Thomas Cc: Anthony Hunter; Bran Selic; Ed Seidewitz; James Bruck; uml2-rtf@omg.org; Thomas Weigert; Jim Amsden Subject: RE: issue 12530 -- UML 2 RTF issue >>The only simplification that we could do without dramatically changing the language would be to allow the list to be omitted with a reasonable default interpretation. For example, one could say that if a behavioral feature does not have a parameter list, its parameter list is derived from the pointed to behavior, but note that there are many complications: What if there is no behavior in this object, but the behavior is inherited down---the parameters cannot be taken from there. Note further that this scheme would limit the flexibility of the specification of the behavior. Thomas, I think what James is suggesting is the other way around: if a Behavior has a specification set (a behavioral feature), but no owned parameters, then that list gets derived from the parameter list of the specification. Since currently a Behavior's specification has to be owned by the same classifier owning the behavior, you are guraranteed to find it and not search for it up in the hierarchy. So as it stands now in practice, we have 2 sets of parameters to keep in synch: one defined in the behavior feature of the classifier (the specification), and one in the Behavior (the method). In fact, considering the case where that behavioral feature also matces another one declared by an interface realized by the classifier, we have yet another set of parameters to keep in synch (total of 3). Jim Amsden actually touched on this same issue regarding having to duplicate the behavioral feature, hence also the parameters, in implementing classifiers in a separate issue before. As you said, that was designed intentionally in UML to separate concerns, however maybe with good assumptions for default values, we can optimize the common case in practice. ------------------------------------- Maged Elaasar, PhD Candidate Senior Software Developer, Team Lead OMG Representative for UML / DD Rational Modeling Platform/ Tools Rational Software, IBM Software Group, Canada melaasar@ca.ibm.com tel: 613-591-7935 "Weigert, Thomas" "Weigert, Thomas" 06/18/2008 10:54 PM To James Bruck/Ottawa/IBM@IBMCA, "Bran Selic" cc "Ed Seidewitz" , , "Thomas Weigert" , Anthony Hunter/Ottawa/IBM@IBMCA, Maged Elaasar/Ottawa/IBM@IBMCA Subject RE: issue 12530 -- UML 2 RTF issue James, Your suggestion proposes to make major changes to the intention of the separation of the behavior specification (the behavioral feature) and the behavior implementation (the behavior). This separation goes back to UML 1. 1. A behavioral feature declares that an object will handle certain requests. 2. A behavior implements how the object handles those requests. 3. Which behavior will be invoked in response to a matching request arriving is determined by the particular semantics of the modeling language/profile (due to the wide variation possible this is a semantic variation point). It is not necessarily the Behavior that is the behavior pointed to by the BehavioralFeature. a. One example might be that one searches the hierarchy up from the pointed to behavior until one finds a behavior with an appropriate signature. b. This may involve multiple dispatch (i.e., matching on more than one parameter type), the type of the first parameter, strict identify on all parameters, name matching, or many more. As you can see, the duplication of the parameter list is inherently built into the UML. Taking this away may be a practical suggestion, but is a major change. These two parameter lists serve totally different purpose: · The parameter list on behavioral feature establishes which behavior invocation requests are accepted by the object. · The parameter list on behavior establishes which behavior will be actually invoked to handle the request. In some languages that there are two such lists appears redundant. But in other languages this is essential. The only simplification that we could do without dramatically changing the language would be to allow the list to be omitted with a reasonable default interpretation. For example, one could say that if a behavioral feature does not have a parameter list, its parameter list is derived from the pointed to behavior, but note that there are many complications: What if there is no behavior in this object, but the behavior is inherited down---the parameters cannot be taken from there. Note further that this scheme would limit the flexibility of the specification of the behavior. Note that your suggestion is just one step away from suggesting that we do not need the concept of a BehavioralFeature, as that concept could be subsumed by Interface. If we were to follow your suggestion, using Interfaces to specify a behavioral feature would be more powerful than just eliminating the parameter list. Either way, this is a big change. Th. From: James Bruck [mailto:jbruck@ca.ibm.com] Sent: Monday, June 16, 2008 10:05 AM To: Bran Selic Cc: Ed Seidewitz; uml2-rtf@omg.org; Thomas Weigert; Anthony Hunter; Maged Elaasar Subject: Re: issue 12530 -- UML 2 RTF issue Hi, The motiviation behind the issue stems from some practical implementation concerns. As Bran mentioned, one issue has to do with duplication of information in serialized models. Another issue has to do with keeping the parameters of the Behavior matched up with the parameters of the implemented BehavioralFeature (its specification). In order to verify the constraint, we can't for example, simply assume that the parameters will match just because the specification is explicitly set. Having only one copy of the parameter list would also help with ensuring that changes in one spot would keep the entire model in a consistent state. As Ed pointed out, in a case where no specification is set, explicitly setting the parameters would be necessary; however, we were focusing on cases where a specification was explicitly being set. Cheers, - James. "Bran Selic" 13/06/2008 05:48 PM To "Thomas Weigert" cc "Ed Seidewitz" , uml2-rtf@omg.org, James Bruck/Ottawa/IBM@IBMCA Subject Re: issue 12530 -- UML 2 RTF issue My understanding is that the problem is that this duplication of information significantly bulks up models. However, James Bruck, who raised the issue, may have more information. Bran On Fri, Jun 13, 2008 at 5:36 PM, Thomas Weigert wrote: Before we all get excited about this, can we understand the motivation behind this issue? The situation is as Ed says, I believe. The constraint does not cause any problems for stand-alone behaviors, I think. Th. From: Bran Selic [mailto:bran.selic@gmail.com] Sent: Friday, June 13, 2008 3:29 PM To: Ed Seidewitz Cc: uml2-rtf@omg.org Subject: Re: issue 12530 -- UML 2 RTF issue Actually, the "awkward" solution is the one I was thinking of. It's not that difficult to realize. Another alternative is to have a subclass of Behavior for those that are realizations of BehavioralFeatures. Bran On Fri, Jun 13, 2008 at 3:35 PM, Ed Seidewitz wrote: A behavior is not required to implement a behavioral feature. It may be stand-alone, callable using a call behavior action, and it can have parameters in order to pass data in and out. This is particularly common in activity modeling. If the behavior is, in fact, the method of a behavioral feature, then it would, indeed, be possible to derive the parameters of the behavior from the parameters of the behavioral feature. However, it would be rather awkward (though not impossible) to set up the abstract syntax metamodel so that the parameters of the behavior are derived from the behavioral feature, if it has one, and are owned by the behavior if it does not. One would have to distinguish between parameters and owned parameters, with the former always being derived, and the latter only allowed if there was no behavioral feature, etc. The current approach is consistent with the idea that the behavioral feature is a specification and the behavior is a structurally independent implementation, with the relationship between the two being one of conformance or "matching". -- Ed -------------------------------------------------------------------------------- From: Juergen Boldt [mailto:juergen@omg.org] Sent: Friday, June 13, 2008 2:40 PM To: uml2-rtf@omg.org; issues@omg.org Subject: issue 12530 -- UML 2 RTF issue This is issue # 12530 From: James Bruck We are concerned with the UML specification forcing an Behavior's parameter list to be in sync with its behavioral feature. >From the UML 2.1.1 07-02-03, page 431 (or 445/732) it states in the 13.3.2 Behaviors section the following constraint: [1] The parameters of the behavior must match the parameters of the implemented behavioral feature We feel that this constraint is unnecessary. The parameter list of a Behavior element can be derived from its behavioral feature. Forcing the Behavior to have its own list of parameters has practical implementation problems such as needlessly increasing the size of the UML model, and worse, forcing one to preform the tedious task (or the tool to preform the extra overhead) of keeping the parameter lists of the Behavior and its behavioral feature in sync. We would like to request that this constraint is removed from the specification. -- Bran Selic Malina Software Corp. pic08007.gif Subject: RE: issue 12530 -- UML 2 RTF issue To: "Thomas Weigert" Cc: Anthony Hunter , "'Bran Selic'" , "'Ed Seidewitz'" , James Bruck , "'Jim Amsden'" , uml2-rtf@omg.org, "Weigert, Thomas" X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Maged Elaasar Date: Thu, 19 Jun 2008 11:29:52 -0400 X-MIMETrack: Serialize by Router on D25ML03/25/M/IBM(Release 7.0.3FP1|February 24, 2008) at 06/19/2008 11:29:54 >>So you would require a constraint that if a behavior has an empty parameter list, then it must have a behavioral feature as specification. I do not think there is a need for such a constraint. Having a behavior with no parameters and no BF does not conflict with my case. My case states "if" the behavior has no param and a specification specified, then it is ok for that behavior to reference the parameters of the specation in its design. That is not saying "if a behavior does not have parameters, then it has to have specification". "To your second comment below, it is perfectly feasible that a BF is invoked with parameters not satisfied by the behavior, which would require searching up the hierarchy for a matching behavior. This is how one can work around the problem with contravariance using multiple dispatch." what would be the criteria of finding a satisfying behavior up the hierarchy? compatible parameters? compatible specification? in any case, my point below was that the new proposal does not affect those semantics, since it only introduces a way to derive parameters of a Behavior, in that special "common" case I refered to. ------------------------------------- Maged Elaasar, PhD Candidate Senior Software Developer, Team Lead OMG Representative for UML / DD Rational Modeling Platform/ Tools Rational Software, IBM Software Group, Canada melaasar@ca.ibm.com tel: 613-591-7935 "Thomas Weigert" "Thomas Weigert" 06/19/2008 10:56 AM To Maged Elaasar/Ottawa/IBM@IBMCA cc Anthony Hunter/Ottawa/IBM@IBMCA, "'Bran Selic'" , "'Ed Seidewitz'" , James Bruck/Ottawa/IBM@IBMCA, "'Jim Amsden'" , , "Weigert, Thomas" Subject RE: issue 12530 -- UML 2 RTF issue There is no requirement that a behavior has a behavioral feature specified. In fact, that is often not the case. So you would require a constraint that if a behavior has an empty parameter list, then it must have a behavioral feature as specification. To your second comment below, it is perfectly feasible that a BF is invoked with parameters not satisfied by the behavior, which would require searching up the hierarchy for a matching behavior. This is how one can work around the problem with contravariance using multiple dispatch. Th. From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: Thursday, June 19, 2008 9:49 AM To: Thomas Weigert Cc: Anthony Hunter; 'Bran Selic'; 'Ed Seidewitz'; James Bruck; 'Jim Amsden'; uml2-rtf@omg.org; Weigert, Thomas Subject: RE: issue 12530 -- UML 2 RTF issue >>Say you have an inheritance chain where you have classes C1 inherits from C2 inherits from C3. C2 and C3 each have behavior B, without parameter list, but no behavioral feature corresponding to it. Here is already a problem in that we cannot statically analyze B as we do not know the types of its parameters. The case I was referring to "requires" 1) the Behavior to have a BF specified 2) empty ownedParameters in the Behavior, in order to derive its parameters. The example you gave here says " with no behavioral feature corresponding to it", so I think it is not a valid example of my case. In fact in this example, Behavior B's lack of parameters is either OK if B's design does not refer to any parameters, or "wrong" because it refers to parameters that do not exist and cannot be derived. >>Continue the scenario. C1 has a behavior B also, with some parameter list. C1 has a behavioral feature BF pointing to B. Now imagine a case where the behavioral feature BF is invoked with parameters not matching the parameters on B, so another behavior has to be found. But none of the behaviors up the chain have parameters defined, so we cannot infer anything. based on what I said above, there is still no inconsistency since in this case behaviors B from super classes would not be candidates for C1's BF method as they do not refer in any way to a matching BF. Also there would be an inconsistency in C1's BF if the method B it refers to has non compatible parameters. ------------------------------------- Maged Elaasar, PhD Candidate Senior Software Developer, Team Lead OMG Representative for UML / DD Rational Modeling Platform/ Tools Rational Software, IBM Software Group, Canada melaasar@ca.ibm.com tel: 613-591-7935 "Thomas Weigert" "Thomas Weigert" 06/19/2008 10:17 AM To Maged Elaasar/Ottawa/IBM@IBMCA, "Weigert, Thomas" cc Anthony Hunter/Ottawa/IBM@IBMCA, "'Bran Selic'" , "'Ed Seidewitz'" , James Bruck/Ottawa/IBM@IBMCA, , "'Jim Amsden'" Subject RE: issue 12530 -- UML 2 RTF issue You may be right in inferring James. intentions, but they are certainly not clear from his message and the following discussion. First, let.s stop talking about duplicated or replicated parameter lists, as they all serve different purposes and may in fact differ from each other even in the same class. I assume from now on that it is agreed that it must be possible to have separate parameter lists for (i) behavioral feature (ii) behavior and (iii) interfaces. So the discussion is on whether we can elide some of these lists and what the inferred parameters would be. Your proposal of allowing eliding the behavior parameters and inferring from the behavioral feature is the most natural and avoids the problem pointed to below. However, it also has a problem of its own: Say you have an inheritance chain where you have classes C1 inherits from C2 inherits from C3. C2 and C3 each have behavior B, without parameter list, but no behavioral feature corresponding to it. Here is already a problem in that we cannot statically analyze B as we do not know the types of its parameters. Continue the scenario. C1 has a behavior B also, with some parameter list. C1 has a behavioral feature BF pointing to B. Now imagine a case where the behavioral feature BF is invoked with parameters not matching the parameters on B, so another behavior has to be found. But none of the behaviors up the chain have parameters defined, so we cannot infer anything. Th. From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: Thursday, June 19, 2008 9:08 AM To: Weigert, Thomas Cc: Anthony Hunter; Bran Selic; Ed Seidewitz; James Bruck; uml2-rtf@omg.org; Thomas Weigert; Jim Amsden Subject: RE: issue 12530 -- UML 2 RTF issue >>The only simplification that we could do without dramatically changing the language would be to allow the list to be omitted with a reasonable default interpretation. For example, one could say that if a behavioral feature does not have a parameter list, its parameter list is derived from the pointed to behavior, but note that there are many complications: What if there is no behavior in this object, but the behavior is inherited down---the parameters cannot be taken from there. Note further that this scheme would limit the flexibility of the specification of the behavior. Thomas, I think what James is suggesting is the other way around: if a Behavior has a specification set (a behavioral feature), but no owned parameters, then that list gets derived from the parameter list of the specification. Since currently a Behavior's specification has to be owned by the same classifier owning the behavior, you are guraranteed to find it and not search for it up in the hierarchy. So as it stands now in practice, we have 2 sets of parameters to keep in synch: one defined in the behavior feature of the classifier (the specification), and one in the Behavior (the method). In fact, considering the case where that behavioral feature also matces another one declared by an interface realized by the classifier, we have yet another set of parameters to keep in synch (total of 3). Jim Amsden actually touched on this same issue regarding having to duplicate the behavioral feature, hence also the parameters, in implementing classifiers in a separate issue before. As you said, that was designed intentionally in UML to separate concerns, however maybe with good assumptions for default values, we can optimize the common case in practice. ------------------------------------- Maged Elaasar, PhD Candidate Senior Software Developer, Team Lead OMG Representative for UML / DD Rational Modeling Platform/ Tools Rational Software, IBM Software Group, Canada melaasar@ca.ibm.com tel: 613-591-7935 "Weigert, Thomas" "Weigert, Thomas" 06/18/2008 10:54 PM To James Bruck/Ottawa/IBM@IBMCA, "Bran Selic" cc "Ed Seidewitz" , , "Thomas Weigert" , Anthony Hunter/Ottawa/IBM@IBMCA, Maged Elaasar/Ottawa/IBM@IBMCA Subject RE: issue 12530 -- UML 2 RTF issue James, Your suggestion proposes to make major changes to the intention of the separation of the behavior specification (the behavioral feature) and the behavior implementation (the behavior). This separation goes back to UML 1. 1. A behavioral feature declares that an object will handle certain requests. 2. A behavior implements how the object handles those requests. 3. Which behavior will be invoked in response to a matching request arriving is determined by the particular semantics of the modeling language/profile (due to the wide variation possible this is a semantic variation point). It is not necessarily the Behavior that is the behavior pointed to by the BehavioralFeature. a. One example might be that one searches the hierarchy up from the pointed to behavior until one finds a behavior with an appropriate signature. b. This may involve multiple dispatch (i.e., matching on more than one parameter type), the type of the first parameter, strict identify on all parameters, name matching, or many more. As you can see, the duplication of the parameter list is inherently built into the UML. Taking this away may be a practical suggestion, but is a major change. These two parameter lists serve totally different purpose: · The parameter list on behavioral feature establishes which behavior invocation requests are accepted by the object. · The parameter list on behavior establishes which behavior will be actually invoked to handle the request. In some languages that there are two such lists appears redundant. But in other languages this is essential. The only simplification that we could do without dramatically changing the language would be to allow the list to be omitted with a reasonable default interpretation. For example, one could say that if a behavioral feature does not have a parameter list, its parameter list is derived from the pointed to behavior, but note that there are many complications: What if there is no behavior in this object, but the behavior is inherited down---the parameters cannot be taken from there. Note further that this scheme would limit the flexibility of the specification of the behavior. Note that your suggestion is just one step away from suggesting that we do not need the concept of a BehavioralFeature, as that concept could be subsumed by Interface. If we were to follow your suggestion, using Interfaces to specify a behavioral feature would be more powerful than just eliminating the parameter list. Either way, this is a big change. Th. From: James Bruck [mailto:jbruck@ca.ibm.com] Sent: Monday, June 16, 2008 10:05 AM To: Bran Selic Cc: Ed Seidewitz; uml2-rtf@omg.org; Thomas Weigert; Anthony Hunter; Maged Elaasar Subject: Re: issue 12530 -- UML 2 RTF issue Hi, The motiviation behind the issue stems from some practical implementation concerns. As Bran mentioned, one issue has to do with duplication of information in serialized models. Another issue has to do with keeping the parameters of the Behavior matched up with the parameters of the implemented BehavioralFeature (its specification). In order to verify the constraint, we can't for example, simply assume that the parameters will match just because the specification is explicitly set. Having only one copy of the parameter list would also help with ensuring that changes in one spot would keep the entire model in a consistent state. As Ed pointed out, in a case where no specification is set, explicitly setting the parameters would be necessary; however, we were focusing on cases where a specification was explicitly being set. Cheers, - James. "Bran Selic" 13/06/2008 05:48 PM To "Thomas Weigert" cc "Ed Seidewitz" , uml2-rtf@omg.org, James Bruck/Ottawa/IBM@IBMCA Subject Re: issue 12530 -- UML 2 RTF issue My understanding is that the problem is that this duplication of information significantly bulks up models. However, James Bruck, who raised the issue, may have more information. Bran On Fri, Jun 13, 2008 at 5:36 PM, Thomas Weigert wrote: Before we all get excited about this, can we understand the motivation behind this issue? The situation is as Ed says, I believe. The constraint does not cause any problems for stand-alone behaviors, I think. Th. From: Bran Selic [mailto:bran.selic@gmail.com] Sent: Friday, June 13, 2008 3:29 PM To: Ed Seidewitz Cc: uml2-rtf@omg.org Subject: Re: issue 12530 -- UML 2 RTF issue Actually, the "awkward" solution is the one I was thinking of. It's not that difficult to realize. Another alternative is to have a subclass of Behavior for those that are realizations of BehavioralFeatures. Bran On Fri, Jun 13, 2008 at 3:35 PM, Ed Seidewitz wrote: A behavior is not required to implement a behavioral feature. It may be stand-alone, callable using a call behavior action, and it can have parameters in order to pass data in and out. This is particularly common in activity modeling. If the behavior is, in fact, the method of a behavioral feature, then it would, indeed, be possible to derive the parameters of the behavior from the parameters of the behavioral feature. However, it would be rather awkward (though not impossible) to set up the abstract syntax metamodel so that the parameters of the behavior are derived from the behavioral feature, if it has one, and are owned by the behavior if it does not. One would have to distinguish between parameters and owned parameters, with the former always being derived, and the latter only allowed if there was no behavioral feature, etc. The current approach is consistent with the idea that the behavioral feature is a specification and the behavior is a structurally independent implementation, with the relationship between the two being one of conformance or "matching". -- Ed -------------------------------------------------------------------------------- From: Juergen Boldt [mailto:juergen@omg.org] Sent: Friday, June 13, 2008 2:40 PM To: uml2-rtf@omg.org; issues@omg.org Subject: issue 12530 -- UML 2 RTF issue This is issue # 12530 From: James Bruck We are concerned with the UML specification forcing an Behavior's parameter list to be in sync with its behavioral feature. >From the UML 2.1.1 07-02-03, page 431 (or 445/732) it states in the 13.3.2 Behaviors section the following constraint: [1] The parameters of the behavior must match the parameters of the implemented behavioral feature We feel that this constraint is unnecessary. The parameter list of a Behavior element can be derived from its behavioral feature. Forcing the Behavior to have its own list of parameters has practical implementation problems such as needlessly increasing the size of the UML model, and worse, forcing one to preform the tedious task (or the tool to preform the extra overhead) of keeping the parameter lists of the Behavior and its behavioral feature in sync. We would like to request that this constraint is removed from the specification. -- Bran Selic Malina Software Corp. pic13874.gif Subject: RE: issue 12530 -- UML 2 RTF issue To: "Thomas Weigert" Cc: Anthony Hunter , "'Bran Selic'" , "'Ed Seidewitz'" , James Bruck , "'Jim Amsden'" , uml2-rtf@omg.org, "Weigert, Thomas" X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Maged Elaasar Date: Thu, 19 Jun 2008 12:20:57 -0400 X-MIMETrack: Serialize by Router on D25ML03/25/M/IBM(Release 7.0.3FP1|February 24, 2008) at 06/19/2008 12:20:59 I guess it could be derived more or less from Ed's proposal before: "If the behavior is, in fact, the method of a behavioral feature, then it would, indeed, be possible to derive the parameters of the behavior from the parameters of the behavioral feature. However, it would be rather awkward (though not impossible) to set up the abstract syntax metamodel so that the parameters of the behavior are derived from the behavioral feature, if it has one, and are owned by the behavior if it does not. One would have to distinguish between parameters and owned parameters, with the former always being derived, and the latter only allowed if there was no behavioral feature, etc." so a Behavior would have the following: ownedParameter: Parameter References a list of parameters owned by the behavior that describes the order and type of arguments that can be given when the behavior is invoked and of the values that will be returned when the behavior completes its execution. (Specializes Namespace.ownedMember.) parameter: Parameter A derived list of parameters to the behavior that describes the order and type of arguments that can be given when the behavior is invoked and of the values that will be returned when the behavior completes its execution. The derivation of the parameter list defaults to the list of ownedParameters, except when the behavior has no ownedParameters but with a specification specified, in which case the derivation defaults to the list of parameters of that specifiction. the OCL derivation for parameters: if ownedParameter->isEmpty() and specification->notEmpty() then specification.ownedParameter else ownedParameter endif I guess this leaves still the flexibility for Behaviors that have speciaitions but a different set of parameters, but optimizes the common case where they have to match. ------------------------------------- Maged Elaasar, PhD Candidate Senior Software Developer, Team Lead OMG Representative for UML / DD Rational Modeling Platform/ Tools Rational Software, IBM Software Group, Canada melaasar@ca.ibm.com tel: 613-591-7935 "Thomas Weigert" "Thomas Weigert" 06/19/2008 11:32 AM To Maged Elaasar/Ottawa/IBM@IBMCA cc Anthony Hunter/Ottawa/IBM@IBMCA, "'Bran Selic'" , "'Ed Seidewitz'" , James Bruck/Ottawa/IBM@IBMCA, "'Jim Amsden'" , , "Weigert, Thomas" Subject RE: issue 12530 -- UML 2 RTF issue Why don.t you try to formulate the precise rule that allows you to elide the parameters on the behavior and any additional constraints required, so that it does not susceptible to the two problems outlined below. Th. From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: Thursday, June 19, 2008 10:30 AM To: Thomas Weigert Cc: Anthony Hunter; 'Bran Selic'; 'Ed Seidewitz'; James Bruck; 'Jim Amsden'; uml2-rtf@omg.org; Weigert, Thomas Subject: RE: issue 12530 -- UML 2 RTF issue >>So you would require a constraint that if a behavior has an empty parameter list, then it must have a behavioral feature as specification. I do not think there is a need for such a constraint. Having a behavior with no parameters and no BF does not conflict with my case. My case states "if" the behavior has no param and a specification specified, then it is ok for that behavior to reference the parameters of the specation in its design. That is not saying "if a behavior does not have parameters, then it has to have specification". "To your second comment below, it is perfectly feasible that a BF is invoked with parameters not satisfied by the behavior, which would require searching up the hierarchy for a matching behavior. This is how one can work around the problem with contravariance using multiple dispatch." what would be the criteria of finding a satisfying behavior up the hierarchy? compatible parameters? compatible specification? in any case, my point below was that the new proposal does not affect those semantics, since it only introduces a way to derive parameters of a Behavior, in that special "common" case I refered to. ------------------------------------- Maged Elaasar, PhD Candidate Senior Software Developer, Team Lead OMG Representative for UML / DD Rational Modeling Platform/ Tools Rational Software, IBM Software Group, Canada melaasar@ca.ibm.com tel: 613-591-7935 "Thomas Weigert" "Thomas Weigert" 06/19/2008 10:56 AM To Maged Elaasar/Ottawa/IBM@IBMCA cc Anthony Hunter/Ottawa/IBM@IBMCA, "'Bran Selic'" , "'Ed Seidewitz'" , James Bruck/Ottawa/IBM@IBMCA, "'Jim Amsden'" , , "Weigert, Thomas" Subject RE: issue 12530 -- UML 2 RTF issue There is no requirement that a behavior has a behavioral feature specified. In fact, that is often not the case. So you would require a constraint that if a behavior has an empty parameter list, then it must have a behavioral feature as specification. To your second comment below, it is perfectly feasible that a BF is invoked with parameters not satisfied by the behavior, which would require searching up the hierarchy for a matching behavior. This is how one can work around the problem with contravariance using multiple dispatch. Th. From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: Thursday, June 19, 2008 9:49 AM To: Thomas Weigert Cc: Anthony Hunter; 'Bran Selic'; 'Ed Seidewitz'; James Bruck; 'Jim Amsden'; uml2-rtf@omg.org; Weigert, Thomas Subject: RE: issue 12530 -- UML 2 RTF issue >>Say you have an inheritance chain where you have classes C1 inherits from C2 inherits from C3. C2 and C3 each have behavior B, without parameter list, but no behavioral feature corresponding to it. Here is already a problem in that we cannot statically analyze B as we do not know the types of its parameters. The case I was referring to "requires" 1) the Behavior to have a BF specified 2) empty ownedParameters in the Behavior, in order to derive its parameters. The example you gave here says " with no behavioral feature corresponding to it", so I think it is not a valid example of my case. In fact in this example, Behavior B's lack of parameters is either OK if B's design does not refer to any parameters, or "wrong" because it refers to parameters that do not exist and cannot be derived. >>Continue the scenario. C1 has a behavior B also, with some parameter list. C1 has a behavioral feature BF pointing to B. Now imagine a case where the behavioral feature BF is invoked with parameters not matching the parameters on B, so another behavior has to be found. But none of the behaviors up the chain have parameters defined, so we cannot infer anything. based on what I said above, there is still no inconsistency since in this case behaviors B from super classes would not be candidates for C1's BF method as they do not refer in any way to a matching BF. Also there would be an inconsistency in C1's BF if the method B it refers to has non compatible parameters. ------------------------------------- Maged Elaasar, PhD Candidate Senior Software Developer, Team Lead OMG Representative for UML / DD Rational Modeling Platform/ Tools Rational Software, IBM Software Group, Canada melaasar@ca.ibm.com tel: 613-591-7935 "Thomas Weigert" "Thomas Weigert" 06/19/2008 10:17 AM To Maged Elaasar/Ottawa/IBM@IBMCA, "Weigert, Thomas" cc Anthony Hunter/Ottawa/IBM@IBMCA, "'Bran Selic'" , "'Ed Seidewitz'" , James Bruck/Ottawa/IBM@IBMCA, , "'Jim Amsden'" Subject RE: issue 12530 -- UML 2 RTF issue You may be right in inferring James. intentions, but they are certainly not clear from his message and the following discussion. First, let.s stop talking about duplicated or replicated parameter lists, as they all serve different purposes and may in fact differ from each other even in the same class. I assume from now on that it is agreed that it must be possible to have separate parameter lists for (i) behavioral feature (ii) behavior and (iii) interfaces. So the discussion is on whether we can elide some of these lists and what the inferred parameters would be. Your proposal of allowing eliding the behavior parameters and inferring from the behavioral feature is the most natural and avoids the problem pointed to below. However, it also has a problem of its own: Say you have an inheritance chain where you have classes C1 inherits from C2 inherits from C3. C2 and C3 each have behavior B, without parameter list, but no behavioral feature corresponding to it. Here is already a problem in that we cannot statically analyze B as we do not know the types of its parameters. Continue the scenario. C1 has a behavior B also, with some parameter list. C1 has a behavioral feature BF pointing to B. Now imagine a case where the behavioral feature BF is invoked with parameters not matching the parameters on B, so another behavior has to be found. But none of the behaviors up the chain have parameters defined, so we cannot infer anything. Th. From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: Thursday, June 19, 2008 9:08 AM To: Weigert, Thomas Cc: Anthony Hunter; Bran Selic; Ed Seidewitz; James Bruck; uml2-rtf@omg.org; Thomas Weigert; Jim Amsden Subject: RE: issue 12530 -- UML 2 RTF issue >>The only simplification that we could do without dramatically changing the language would be to allow the list to be omitted with a reasonable default interpretation. For example, one could say that if a behavioral feature does not have a parameter list, its parameter list is derived from the pointed to behavior, but note that there are many complications: What if there is no behavior in this object, but the behavior is inherited down---the parameters cannot be taken from there. Note further that this scheme would limit the flexibility of the specification of the behavior. Thomas, I think what James is suggesting is the other way around: if a Behavior has a specification set (a behavioral feature), but no owned parameters, then that list gets derived from the parameter list of the specification. Since currently a Behavior's specification has to be owned by the same classifier owning the behavior, you are guraranteed to find it and not search for it up in the hierarchy. So as it stands now in practice, we have 2 sets of parameters to keep in synch: one defined in the behavior feature of the classifier (the specification), and one in the Behavior (the method). In fact, considering the case where that behavioral feature also matces another one declared by an interface realized by the classifier, we have yet another set of parameters to keep in synch (total of 3). Jim Amsden actually touched on this same issue regarding having to duplicate the behavioral feature, hence also the parameters, in implementing classifiers in a separate issue before. As you said, that was designed intentionally in UML to separate concerns, however maybe with good assumptions for default values, we can optimize the common case in practice. ------------------------------------- Maged Elaasar, PhD Candidate Senior Software Developer, Team Lead OMG Representative for UML / DD Rational Modeling Platform/ Tools Rational Software, IBM Software Group, Canada melaasar@ca.ibm.com tel: 613-591-7935 "Weigert, Thomas" "Weigert, Thomas" 06/18/2008 10:54 PM To James Bruck/Ottawa/IBM@IBMCA, "Bran Selic" cc "Ed Seidewitz" , , "Thomas Weigert" , Anthony Hunter/Ottawa/IBM@IBMCA, Maged Elaasar/Ottawa/IBM@IBMCA Subject RE: issue 12530 -- UML 2 RTF issue James, Your suggestion proposes to make major changes to the intention of the separation of the behavior specification (the behavioral feature) and the behavior implementation (the behavior). This separation goes back to UML 1. 1. A behavioral feature declares that an object will handle certain requests. 2. A behavior implements how the object handles those requests. 3. Which behavior will be invoked in response to a matching request arriving is determined by the particular semantics of the modeling language/profile (due to the wide variation possible this is a semantic variation point). It is not necessarily the Behavior that is the behavior pointed to by the BehavioralFeature. a. One example might be that one searches the hierarchy up from the pointed to behavior until one finds a behavior with an appropriate signature. b. This may involve multiple dispatch (i.e., matching on more than one parameter type), the type of the first parameter, strict identify on all parameters, name matching, or many more. As you can see, the duplication of the parameter list is inherently built into the UML. Taking this away may be a practical suggestion, but is a major change. These two parameter lists serve totally different purpose: · The parameter list on behavioral feature establishes which behavior invocation requests are accepted by the object. · The parameter list on behavior establishes which behavior will be actually invoked to handle the request. In some languages that there are two such lists appears redundant. But in other languages this is essential. The only simplification that we could do without dramatically changing the language would be to allow the list to be omitted with a reasonable default interpretation. For example, one could say that if a behavioral feature does not have a parameter list, its parameter list is derived from the pointed to behavior, but note that there are many complications: What if there is no behavior in this object, but the behavior is inherited down---the parameters cannot be taken from there. Note further that this scheme would limit the flexibility of the specification of the behavior. Note that your suggestion is just one step away from suggesting that we do not need the concept of a BehavioralFeature, as that concept could be subsumed by Interface. If we were to follow your suggestion, using Interfaces to specify a behavioral feature would be more powerful than just eliminating the parameter list. Either way, this is a big change. Th. From: James Bruck [mailto:jbruck@ca.ibm.com] Sent: Monday, June 16, 2008 10:05 AM To: Bran Selic Cc: Ed Seidewitz; uml2-rtf@omg.org; Thomas Weigert; Anthony Hunter; Maged Elaasar Subject: Re: issue 12530 -- UML 2 RTF issue Hi, The motiviation behind the issue stems from some practical implementation concerns. As Bran mentioned, one issue has to do with duplication of information in serialized models. Another issue has to do with keeping the parameters of the Behavior matched up with the parameters of the implemented BehavioralFeature (its specification). In order to verify the constraint, we can't for example, simply assume that the parameters will match just because the specification is explicitly set. Having only one copy of the parameter list would also help with ensuring that changes in one spot would keep the entire model in a consistent state. As Ed pointed out, in a case where no specification is set, explicitly setting the parameters would be necessary; however, we were focusing on cases where a specification was explicitly being set. Cheers, - James. "Bran Selic" 13/06/2008 05:48 PM To "Thomas Weigert" cc "Ed Seidewitz" , uml2-rtf@omg.org, James Bruck/Ottawa/IBM@IBMCA Subject Re: issue 12530 -- UML 2 RTF issue My understanding is that the problem is that this duplication of information significantly bulks up models. However, James Bruck, who raised the issue, may have more information. Bran On Fri, Jun 13, 2008 at 5:36 PM, Thomas Weigert wrote: Before we all get excited about this, can we understand the motivation behind this issue? The situation is as Ed says, I believe. The constraint does not cause any problems for stand-alone behaviors, I think. Th. From: Bran Selic [mailto:bran.selic@gmail.com] Sent: Friday, June 13, 2008 3:29 PM To: Ed Seidewitz Cc: uml2-rtf@omg.org Subject: Re: issue 12530 -- UML 2 RTF issue Actually, the "awkward" solution is the one I was thinking of. It's not that difficult to realize. Another alternative is to have a subclass of Behavior for those that are realizations of BehavioralFeatures. Bran On Fri, Jun 13, 2008 at 3:35 PM, Ed Seidewitz wrote: A behavior is not required to implement a behavioral feature. It may be stand-alone, callable using a call behavior action, and it can have parameters in order to pass data in and out. This is particularly common in activity modeling. If the behavior is, in fact, the method of a behavioral feature, then it would, indeed, be possible to derive the parameters of the behavior from the parameters of the behavioral feature. However, it would be rather awkward (though not impossible) to set up the abstract syntax metamodel so that the parameters of the behavior are derived from the behavioral feature, if it has one, and are owned by the behavior if it does not. One would have to distinguish between parameters and owned parameters, with the former always being derived, and the latter only allowed if there was no behavioral feature, etc. The current approach is consistent with the idea that the behavioral feature is a specification and the behavior is a structurally independent implementation, with the relationship between the two being one of conformance or "matching". -- Ed -------------------------------------------------------------------------------- From: Juergen Boldt [mailto:juergen@omg.org] Sent: Friday, June 13, 2008 2:40 PM To: uml2-rtf@omg.org; issues@omg.org Subject: issue 12530 -- UML 2 RTF issue This is issue # 12530 From: James Bruck We are concerned with the UML specification forcing an Behavior's parameter list to be in sync with its behavioral feature. >From the UML 2.1.1 07-02-03, page 431 (or 445/732) it states in the 13.3.2 Behaviors section the following constraint: [1] The parameters of the behavior must match the parameters of the implemented behavioral feature We feel that this constraint is unnecessary. The parameter list of a Behavior element can be derived from its behavioral feature. Forcing the Behavior to have its own list of parameters has practical implementation problems such as needlessly increasing the size of the UML model, and worse, forcing one to preform the tedious task (or the tool to preform the extra overhead) of keeping the parameter lists of the Behavior and its behavioral feature in sync. We would like to request that this constraint is removed from the specification. -- Bran Selic Malina Software Corp. pic25084.gif Subject: RE: issue 12530 -- UML 2 RTF issue To: Maged Elaasar Cc: Anthony Hunter , "'Bran Selic'" , "'Ed Seidewitz'" , James Bruck , "'Jim Amsden'" , uml2-rtf@omg.org, "Weigert, Thomas" , "Thomas Weigert" X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Maged Elaasar Date: Thu, 19 Jun 2008 12:25:36 -0400 X-MIMETrack: Serialize by Router on D25ML03/25/M/IBM(Release 7.0.3FP1|February 24, 2008) at 06/19/2008 12:25:39 Also the following constraint: [1] The parameters of the behavior must match the parameters of the implemented behavioral feature. would be interpreted to mean the "parameter" vs. "ownedParameter" of a Behavior. ------------------------------------- Maged Elaasar, PhD Candidate Senior Software Developer, Team Lead OMG Representative for UML / DD Rational Modeling Platform/ Tools Rational Software, IBM Software Group, Canada melaasar@ca.ibm.com tel: 613-591-7935 Maged Elaasar/Ottawa/IBM Maged Elaasar/Ottawa/IBM 06/19/2008 12:20 PM To "Thomas Weigert" cc Anthony Hunter/Ottawa/IBM@IBMCA, "'Bran Selic'" , "'Ed Seidewitz'" , James Bruck/Ottawa/IBM@IBMCA, "'Jim Amsden'" , uml2-rtf@omg.org, "Weigert, Thomas" Subject RE: issue 12530 -- UML 2 RTF issue I guess it could be derived more or less from Ed's proposal before: "If the behavior is, in fact, the method of a behavioral feature, then it would, indeed, be possible to derive the parameters of the behavior from the parameters of the behavioral feature. However, it would be rather awkward (though not impossible) to set up the abstract syntax metamodel so that the parameters of the behavior are derived from the behavioral feature, if it has one, and are owned by the behavior if it does not. One would have to distinguish between parameters and owned parameters, with the former always being derived, and the latter only allowed if there was no behavioral feature, etc." so a Behavior would have the following: ownedParameter: Parameter References a list of parameters owned by the behavior that describes the order and type of arguments that can be given when the behavior is invoked and of the values that will be returned when the behavior completes its execution. (Specializes Namespace.ownedMember.) parameter: Parameter A derived list of parameters to the behavior that describes the order and type of arguments that can be given when the behavior is invoked and of the values that will be returned when the behavior completes its execution. The derivation of the parameter list defaults to the list of ownedParameters, except when the behavior has no ownedParameters but with a specification specified, in which case the derivation defaults to the list of parameters of that specifiction. the OCL derivation for parameters: if ownedParameter->isEmpty() and specification->notEmpty() then specification.ownedParameter else ownedParameter endif I guess this leaves still the flexibility for Behaviors that have speciaitions but a different set of parameters, but optimizes the common case where they have to match. ------------------------------------- Maged Elaasar, PhD Candidate Senior Software Developer, Team Lead OMG Representative for UML / DD Rational Modeling Platform/ Tools Rational Software, IBM Software Group, Canada melaasar@ca.ibm.com tel: 613-591-7935 "Thomas Weigert" "Thomas Weigert" 06/19/2008 11:32 AM To Maged Elaasar/Ottawa/IBM@IBMCA cc Anthony Hunter/Ottawa/IBM@IBMCA, "'Bran Selic'" , "'Ed Seidewitz'" , James Bruck/Ottawa/IBM@IBMCA, "'Jim Amsden'" , , "Weigert, Thomas" Subject RE: issue 12530 -- UML 2 RTF issue Why don.t you try to formulate the precise rule that allows you to elide the parameters on the behavior and any additional constraints required, so that it does not susceptible to the two problems outlined below. Th. From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: Thursday, June 19, 2008 10:30 AM To: Thomas Weigert Cc: Anthony Hunter; 'Bran Selic'; 'Ed Seidewitz'; James Bruck; 'Jim Amsden'; uml2-rtf@omg.org; Weigert, Thomas Subject: RE: issue 12530 -- UML 2 RTF issue >>So you would require a constraint that if a behavior has an empty parameter list, then it must have a behavioral feature as specification. I do not think there is a need for such a constraint. Having a behavior with no parameters and no BF does not conflict with my case. My case states "if" the behavior has no param and a specification specified, then it is ok for that behavior to reference the parameters of the specation in its design. That is not saying "if a behavior does not have parameters, then it has to have specification". "To your second comment below, it is perfectly feasible that a BF is invoked with parameters not satisfied by the behavior, which would require searching up the hierarchy for a matching behavior. This is how one can work around the problem with contravariance using multiple dispatch." what would be the criteria of finding a satisfying behavior up the hierarchy? compatible parameters? compatible specification? in any case, my point below was that the new proposal does not affect those semantics, since it only introduces a way to derive parameters of a Behavior, in that special "common" case I refered to. ------------------------------------- Maged Elaasar, PhD Candidate Senior Software Developer, Team Lead OMG Representative for UML / DD Rational Modeling Platform/ Tools Rational Software, IBM Software Group, Canada melaasar@ca.ibm.com tel: 613-591-7935 "Thomas Weigert" "Thomas Weigert" 06/19/2008 10:56 AM To Maged Elaasar/Ottawa/IBM@IBMCA cc Anthony Hunter/Ottawa/IBM@IBMCA, "'Bran Selic'" , "'Ed Seidewitz'" , James Bruck/Ottawa/IBM@IBMCA, "'Jim Amsden'" , , "Weigert, Thomas" Subject RE: issue 12530 -- UML 2 RTF issue There is no requirement that a behavior has a behavioral feature specified. In fact, that is often not the case. So you would require a constraint that if a behavior has an empty parameter list, then it must have a behavioral feature as specification. To your second comment below, it is perfectly feasible that a BF is invoked with parameters not satisfied by the behavior, which would require searching up the hierarchy for a matching behavior. This is how one can work around the problem with contravariance using multiple dispatch. Th. From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: Thursday, June 19, 2008 9:49 AM To: Thomas Weigert Cc: Anthony Hunter; 'Bran Selic'; 'Ed Seidewitz'; James Bruck; 'Jim Amsden'; uml2-rtf@omg.org; Weigert, Thomas Subject: RE: issue 12530 -- UML 2 RTF issue >>Say you have an inheritance chain where you have classes C1 inherits from C2 inherits from C3. C2 and C3 each have behavior B, without parameter list, but no behavioral feature corresponding to it. Here is already a problem in that we cannot statically analyze B as we do not know the types of its parameters. The case I was referring to "requires" 1) the Behavior to have a BF specified 2) empty ownedParameters in the Behavior, in order to derive its parameters. The example you gave here says " with no behavioral feature corresponding to it", so I think it is not a valid example of my case. In fact in this example, Behavior B's lack of parameters is either OK if B's design does not refer to any parameters, or "wrong" because it refers to parameters that do not exist and cannot be derived. >>Continue the scenario. C1 has a behavior B also, with some parameter list. C1 has a behavioral feature BF pointing to B. Now imagine a case where the behavioral feature BF is invoked with parameters not matching the parameters on B, so another behavior has to be found. But none of the behaviors up the chain have parameters defined, so we cannot infer anything. based on what I said above, there is still no inconsistency since in this case behaviors B from super classes would not be candidates for C1's BF method as they do not refer in any way to a matching BF. Also there would be an inconsistency in C1's BF if the method B it refers to has non compatible parameters. ------------------------------------- Maged Elaasar, PhD Candidate Senior Software Developer, Team Lead OMG Representative for UML / DD Rational Modeling Platform/ Tools Rational Software, IBM Software Group, Canada melaasar@ca.ibm.com tel: 613-591-7935 "Thomas Weigert" "Thomas Weigert" 06/19/2008 10:17 AM To Maged Elaasar/Ottawa/IBM@IBMCA, "Weigert, Thomas" cc Anthony Hunter/Ottawa/IBM@IBMCA, "'Bran Selic'" , "'Ed Seidewitz'" , James Bruck/Ottawa/IBM@IBMCA, , "'Jim Amsden'" Subject RE: issue 12530 -- UML 2 RTF issue You may be right in inferring James. intentions, but they are certainly not clear from his message and the following discussion. First, let.s stop talking about duplicated or replicated parameter lists, as they all serve different purposes and may in fact differ from each other even in the same class. I assume from now on that it is agreed that it must be possible to have separate parameter lists for (i) behavioral feature (ii) behavior and (iii) interfaces. So the discussion is on whether we can elide some of these lists and what the inferred parameters would be. Your proposal of allowing eliding the behavior parameters and inferring from the behavioral feature is the most natural and avoids the problem pointed to below. However, it also has a problem of its own: Say you have an inheritance chain where you have classes C1 inherits from C2 inherits from C3. C2 and C3 each have behavior B, without parameter list, but no behavioral feature corresponding to it. Here is already a problem in that we cannot statically analyze B as we do not know the types of its parameters. Continue the scenario. C1 has a behavior B also, with some parameter list. C1 has a behavioral feature BF pointing to B. Now imagine a case where the behavioral feature BF is invoked with parameters not matching the parameters on B, so another behavior has to be found. But none of the behaviors up the chain have parameters defined, so we cannot infer anything. Th. From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: Thursday, June 19, 2008 9:08 AM To: Weigert, Thomas Cc: Anthony Hunter; Bran Selic; Ed Seidewitz; James Bruck; uml2-rtf@omg.org; Thomas Weigert; Jim Amsden Subject: RE: issue 12530 -- UML 2 RTF issue >>The only simplification that we could do without dramatically changing the language would be to allow the list to be omitted with a reasonable default interpretation. For example, one could say that if a behavioral feature does not have a parameter list, its parameter list is derived from the pointed to behavior, but note that there are many complications: What if there is no behavior in this object, but the behavior is inherited down---the parameters cannot be taken from there. Note further that this scheme would limit the flexibility of the specification of the behavior. Thomas, I think what James is suggesting is the other way around: if a Behavior has a specification set (a behavioral feature), but no owned parameters, then that list gets derived from the parameter list of the specification. Since currently a Behavior's specification has to be owned by the same classifier owning the behavior, you are guraranteed to find it and not search for it up in the hierarchy. So as it stands now in practice, we have 2 sets of parameters to keep in synch: one defined in the behavior feature of the classifier (the specification), and one in the Behavior (the method). In fact, considering the case where that behavioral feature also matces another one declared by an interface realized by the classifier, we have yet another set of parameters to keep in synch (total of 3). Jim Amsden actually touched on this same issue regarding having to duplicate the behavioral feature, hence also the parameters, in implementing classifiers in a separate issue before. As you said, that was designed intentionally in UML to separate concerns, however maybe with good assumptions for default values, we can optimize the common case in practice. ------------------------------------- Maged Elaasar, PhD Candidate Senior Software Developer, Team Lead OMG Representative for UML / DD Rational Modeling Platform/ Tools Rational Software, IBM Software Group, Canada melaasar@ca.ibm.com tel: 613-591-7935 "Weigert, Thomas" "Weigert, Thomas" 06/18/2008 10:54 PM To James Bruck/Ottawa/IBM@IBMCA, "Bran Selic" cc "Ed Seidewitz" , , "Thomas Weigert" , Anthony Hunter/Ottawa/IBM@IBMCA, Maged Elaasar/Ottawa/IBM@IBMCA Subject RE: issue 12530 -- UML 2 RTF issue James, Your suggestion proposes to make major changes to the intention of the separation of the behavior specification (the behavioral feature) and the behavior implementation (the behavior). This separation goes back to UML 1. 1. A behavioral feature declares that an object will handle certain requests. 2. A behavior implements how the object handles those requests. 3. Which behavior will be invoked in response to a matching request arriving is determined by the particular semantics of the modeling language/profile (due to the wide variation possible this is a semantic variation point). It is not necessarily the Behavior that is the behavior pointed to by the BehavioralFeature. a. One example might be that one searches the hierarchy up from the pointed to behavior until one finds a behavior with an appropriate signature. b. This may involve multiple dispatch (i.e., matching on more than one parameter type), the type of the first parameter, strict identify on all parameters, name matching, or many more. As you can see, the duplication of the parameter list is inherently built into the UML. Taking this away may be a practical suggestion, but is a major change. These two parameter lists serve totally different purpose: · The parameter list on behavioral feature establishes which behavior invocation requests are accepted by the object. · The parameter list on behavior establishes which behavior will be actually invoked to handle the request. In some languages that there are two such lists appears redundant. But in other languages this is essential. The only simplification that we could do without dramatically changing the language would be to allow the list to be omitted with a reasonable default interpretation. For example, one could say that if a behavioral feature does not have a parameter list, its parameter list is derived from the pointed to behavior, but note that there are many complications: What if there is no behavior in this object, but the behavior is inherited down---the parameters cannot be taken from there. Note further that this scheme would limit the flexibility of the specification of the behavior. Note that your suggestion is just one step away from suggesting that we do not need the concept of a BehavioralFeature, as that concept could be subsumed by Interface. If we were to follow your suggestion, using Interfaces to specify a behavioral feature would be more powerful than just eliminating the parameter list. Either way, this is a big change. Th. From: James Bruck [mailto:jbruck@ca.ibm.com] Sent: Monday, June 16, 2008 10:05 AM To: Bran Selic Cc: Ed Seidewitz; uml2-rtf@omg.org; Thomas Weigert; Anthony Hunter; Maged Elaasar Subject: Re: issue 12530 -- UML 2 RTF issue Hi, The motiviation behind the issue stems from some practical implementation concerns. As Bran mentioned, one issue has to do with duplication of information in serialized models. Another issue has to do with keeping the parameters of the Behavior matched up with the parameters of the implemented BehavioralFeature (its specification). In order to verify the constraint, we can't for example, simply assume that the parameters will match just because the specification is explicitly set. Having only one copy of the parameter list would also help with ensuring that changes in one spot would keep the entire model in a consistent state. As Ed pointed out, in a case where no specification is set, explicitly setting the parameters would be necessary; however, we were focusing on cases where a specification was explicitly being set. Cheers, - James. "Bran Selic" 13/06/2008 05:48 PM To "Thomas Weigert" cc "Ed Seidewitz" , uml2-rtf@omg.org, James Bruck/Ottawa/IBM@IBMCA Subject Re: issue 12530 -- UML 2 RTF issue My understanding is that the problem is that this duplication of information significantly bulks up models. However, James Bruck, who raised the issue, may have more information. Bran On Fri, Jun 13, 2008 at 5:36 PM, Thomas Weigert wrote: Before we all get excited about this, can we understand the motivation behind this issue? The situation is as Ed says, I believe. The constraint does not cause any problems for stand-alone behaviors, I think. Th. From: Bran Selic [mailto:bran.selic@gmail.com] Sent: Friday, June 13, 2008 3:29 PM To: Ed Seidewitz Cc: uml2-rtf@omg.org Subject: Re: issue 12530 -- UML 2 RTF issue Actually, the "awkward" solution is the one I was thinking of. It's not that difficult to realize. Another alternative is to have a subclass of Behavior for those that are realizations of BehavioralFeatures. Bran On Fri, Jun 13, 2008 at 3:35 PM, Ed Seidewitz wrote: A behavior is not required to implement a behavioral feature. It may be stand-alone, callable using a call behavior action, and it can have parameters in order to pass data in and out. This is particularly common in activity modeling. If the behavior is, in fact, the method of a behavioral feature, then it would, indeed, be possible to derive the parameters of the behavior from the parameters of the behavioral feature. However, it would be rather awkward (though not impossible) to set up the abstract syntax metamodel so that the parameters of the behavior are derived from the behavioral feature, if it has one, and are owned by the behavior if it does not. One would have to distinguish between parameters and owned parameters, with the former always being derived, and the latter only allowed if there was no behavioral feature, etc. The current approach is consistent with the idea that the behavioral feature is a specification and the behavior is a structurally independent implementation, with the relationship between the two being one of conformance or "matching". -- Ed -------------------------------------------------------------------------------- From: Juergen Boldt [mailto:juergen@omg.org] Sent: Friday, June 13, 2008 2:40 PM To: uml2-rtf@omg.org; issues@omg.org Subject: issue 12530 -- UML 2 RTF issue This is issue # 12530 From: James Bruck We are concerned with the UML specification forcing an Behavior's parameter list to be in sync with its behavioral feature. >From the UML 2.1.1 07-02-03, page 431 (or 445/732) it states in the 13.3.2 Behaviors section the following constraint: [1] The parameters of the behavior must match the parameters of the implemented behavioral feature We feel that this constraint is unnecessary. The parameter list of a Behavior element can be derived from its behavioral feature. Forcing the Behavior to have its own list of parameters has practical implementation problems such as needlessly increasing the size of the UML model, and worse, forcing one to preform the tedious task (or the tool to preform the extra overhead) of keeping the parameter lists of the Behavior and its behavioral feature in sync. We would like to request that this constraint is removed from the specification. -- Bran Selic Malina Software Corp. pic21814.gif pic20440.gif Subject: RE: issue 12530 -- UML 2 RTF issue To: "Nicolas Rouquette" Cc: Anthony Hunter , "'Bran Selic'" , "'Ed Seidewitz'" , James Bruck , "'Jim Amsden'" , uml2-rtf@omg.org, "'Weigert, Thomas'" , "'Thomas Weigert'" X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Maged Elaasar Date: Thu, 19 Jun 2008 16:29:09 -0400 X-MIMETrack: Serialize by Router on D25ML03/25/M/IBM(Release 7.0.3FP1|February 24, 2008) at 06/19/2008 16:29:11 Thank you for your input Nicolas. Interesting points, let me try to respond to best of my knowledge: Example 1: The behavior is in a different namespace than that of the specification; the types used for the specification may not be visible in the behavior namespace Wouldn't you have the same problem if the Behavior, instead, declared those owned parameters without having visiility to their types as well? I see it as a common modeling error in both cases, rather than a limitation to the new proposal only Example 2: Joe makes baby steps in modeling; the behavior is incompletely described: it has a link to the specification but no parameters; the OCL rule kicks in; produces an error because Joe.s model is precisely the above example. The constraint I refered to requires the parameters to match (variation point), and in this special case since the lists of parameters from the behavior and the BF would be indentical, it would match. Joe would only get an error if he referrs to those parameters in the behavior without having visiblity to their type, as described by point 1. Example 3: It.s MDA. The specification is in the PIM; the behavior in the PSM; the PIM/PSM bridge specifies the mapping between PIM types and PSM types. Betweem PIM and PSM, there is always an abstraction relationship, not a generaliation. And since form the spec, "a specification of a behavior must be owned by the classifier that owns the behavior or be inherited by it", there cannot be a case where a specification (Behavior Feature) is in a PIM and the implementation (Behavior) is in a PSM. As it stands now in the specs, there has to be another specification in the PSM classifier realizaing the PIM specification, before being able to refer to from Behaviors. Example 4: The behavior is a closure of the specification for local variables corresponding to all of the specification.s owned parameters; therefore the behavior does not need to own any parameter at all! As Thomas said, the Behavior parameters do not "have" to be identifcal to the specification one, since matching is a semantic variation. Therefore, the current proposal still leaves it possible for them to vary, by the Behavio optionally owning parameters. However, in the common case identified, it would not have to incur this expense. ------------------------------------- Maged Elaasar, PhD Candidate Senior Software Developer, Team Lead OMG Representative for UML / DD Rational Modeling Platform/ Tools Rational Software, IBM Software Group, Canada melaasar@ca.ibm.com tel: 613-591-7935 "Nicolas Rouquette" "Nicolas Rouquette" 06/19/2008 02:21 PM To Maged Elaasar/Ottawa/IBM@IBMCA, "'Thomas Weigert'" cc Anthony Hunter/Ottawa/IBM@IBMCA, "'Bran Selic'" , "'Ed Seidewitz'" , James Bruck/Ottawa/IBM@IBMCA, "'Jim Amsden'" , , "'Weigert, Thomas'" Subject RE: issue 12530 -- UML 2 RTF issue Maged, This might be an elegant solution to James. problem; however, I.m concerned that the OCL expression is broadly applicable and therefore could interfere in many situations where the premise of the rule is satisfied but the conclusion is inappropriate in the context where the rule is applied. Example 1: The behavior is in a different namespace than that of the specification; the types used for the specification may not be visible in the behavior namespace Example 2: Joe makes baby steps in modeling; the behavior is incompletely described: it has a link to the specification but no parameters; the OCL rule kicks in; produces an error because Joe.s model is precisely the above example. Example 3: It.s MDA. The specification is in the PIM; the behavior in the PSM; the PIM/PSM bridge specifies the mapping between PIM types and PSM types. Example 4: The behavior is a closure of the specification for local variables corresponding to all of the specification.s owned parameters; therefore the behavior does not need to own any parameter at all! Nicolas. From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: Thursday, June 19, 2008 9:21 AM To: Thomas Weigert Cc: Anthony Hunter; 'Bran Selic'; 'Ed Seidewitz'; James Bruck; 'Jim Amsden'; uml2-rtf@omg.org; Weigert, Thomas Subject: RE: issue 12530 -- UML 2 RTF issue I guess it could be derived more or less from Ed's proposal before: "If the behavior is, in fact, the method of a behavioral feature, then it would, indeed, be possible to derive the parameters of the behavior from the parameters of the behavioral feature. However, it would be rather awkward (though not impossible) to set up the abstract syntax metamodel so that the parameters of the behavior are derived from the behavioral feature, if it has one, and are owned by the behavior if it does not. One would have to distinguish between parameters and owned parameters, with the former always being derived, and the latter only allowed if there was no behavioral feature, etc." so a Behavior would have the following: ownedParameter: Parameter References a list of parameters owned by the behavior that describes the order and type of arguments that can be given when the behavior is invoked and of the values that will be returned when the behavior completes its execution. (Specializes Namespace.ownedMember.) parameter: Parameter A derived list of parameters to the behavior that describes the order and type of arguments that can be given when the behavior is invoked and of the values that will be returned when the behavior completes its execution. The derivation of the parameter list defaults to the list of ownedParameters, except when the behavior has no ownedParameters but with a specification specified, in which case the derivation defaults to the list of parameters of that specifiction. the OCL derivation for parameters: if ownedParameter->isEmpty() and specification->notEmpty() then specification.ownedParameter else ownedParameter endif I guess this leaves still the flexibility for Behaviors that have speciaitions but a different set of parameters, but optimizes the common case where they have to match. ------------------------------------- Maged Elaasar, PhD Candidate Senior Software Developer, Team Lead OMG Representative for UML / DD Rational Modeling Platform/ Tools Rational Software, IBM Software Group, Canada melaasar@ca.ibm.com tel: 613-591-7935 "Thomas Weigert" "Thomas Weigert" 06/19/2008 11:32 AM To Maged Elaasar/Ottawa/IBM@IBMCA cc Anthony Hunter/Ottawa/IBM@IBMCA, "'Bran Selic'" , "'Ed Seidewitz'" , James Bruck/Ottawa/IBM@IBMCA, "'Jim Amsden'" , , "Weigert, Thomas" Subject RE: issue 12530 -- UML 2 RTF issue Why don.t you try to formulate the precise rule that allows you to elide the parameters on the behavior and any additional constraints required, so that it does not susceptible to the two problems outlined below. Th. From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: Thursday, June 19, 2008 10:30 AM To: Thomas Weigert Cc: Anthony Hunter; 'Bran Selic'; 'Ed Seidewitz'; James Bruck; 'Jim Amsden'; uml2-rtf@omg.org; Weigert, Thomas Subject: RE: issue 12530 -- UML 2 RTF issue >>So you would require a constraint that if a behavior has an empty parameter list, then it must have a behavioral feature as specification. I do not think there is a need for such a constraint. Having a behavior with no parameters and no BF does not conflict with my case. My case states "if" the behavior has no param and a specification specified, then it is ok for that behavior to reference the parameters of the specation in its design. That is not saying "if a behavior does not have parameters, then it has to have specification". "To your second comment below, it is perfectly feasible that a BF is invoked with parameters not satisfied by the behavior, which would require searching up the hierarchy for a matching behavior. This is how one can work around the problem with contravariance using multiple dispatch." what would be the criteria of finding a satisfying behavior up the hierarchy? compatible parameters? compatible specification? in any case, my point below was that the new proposal does not affect those semantics, since it only introduces a way to derive parameters of a Behavior, in that special "common" case I refered to. ------------------------------------- Maged Elaasar, PhD Candidate Senior Software Developer, Team Lead OMG Representative for UML / DD Rational Modeling Platform/ Tools Rational Software, IBM Software Group, Canada melaasar@ca.ibm.com tel: 613-591-7935 "Thomas Weigert" "Thomas Weigert" 06/19/2008 10:56 AM To Maged Elaasar/Ottawa/IBM@IBMCA cc Anthony Hunter/Ottawa/IBM@IBMCA, "'Bran Selic'" , "'Ed Seidewitz'" , James Bruck/Ottawa/IBM@IBMCA, "'Jim Amsden'" , , "Weigert, Thomas" Subject RE: issue 12530 -- UML 2 RTF issue There is no requirement that a behavior has a behavioral feature specified. In fact, that is often not the case. So you would require a constraint that if a behavior has an empty parameter list, then it must have a behavioral feature as specification. To your second comment below, it is perfectly feasible that a BF is invoked with parameters not satisfied by the behavior, which would require searching up the hierarchy for a matching behavior. This is how one can work around the problem with contravariance using multiple dispatch. Th. From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: Thursday, June 19, 2008 9:49 AM To: Thomas Weigert Cc: Anthony Hunter; 'Bran Selic'; 'Ed Seidewitz'; James Bruck; 'Jim Amsden'; uml2-rtf@omg.org; Weigert, Thomas Subject: RE: issue 12530 -- UML 2 RTF issue >>Say you have an inheritance chain where you have classes C1 inherits from C2 inherits from C3. C2 and C3 each have behavior B, without parameter list, but no behavioral feature corresponding to it. Here is already a problem in that we cannot statically analyze B as we do not know the types of its parameters. The case I was referring to "requires" 1) the Behavior to have a BF specified 2) empty ownedParameters in the Behavior, in order to derive its parameters. The example you gave here says " with no behavioral feature corresponding to it", so I think it is not a valid example of my case. In fact in this example, Behavior B's lack of parameters is either OK if B's design does not refer to any parameters, or "wrong" because it refers to parameters that do not exist and cannot be derived. >>Continue the scenario. C1 has a behavior B also, with some parameter list. C1 has a behavioral feature BF pointing to B. Now imagine a case where the behavioral feature BF is invoked with parameters not matching the parameters on B, so another behavior has to be found. But none of the behaviors up the chain have parameters defined, so we cannot infer anything. based on what I said above, there is still no inconsistency since in this case behaviors B from super classes would not be candidates for C1's BF method as they do not refer in any way to a matching BF. Also there would be an inconsistency in C1's BF if the method B it refers to has non compatible parameters. ------------------------------------- Maged Elaasar, PhD Candidate Senior Software Developer, Team Lead OMG Representative for UML / DD Rational Modeling Platform/ Tools Rational Software, IBM Software Group, Canada melaasar@ca.ibm.com tel: 613-591-7935 "Thomas Weigert" "Thomas Weigert" 06/19/2008 10:17 AM To Maged Elaasar/Ottawa/IBM@IBMCA, "Weigert, Thomas" cc Anthony Hunter/Ottawa/IBM@IBMCA, "'Bran Selic'" , "'Ed Seidewitz'" , James Bruck/Ottawa/IBM@IBMCA, , "'Jim Amsden'" Subject RE: issue 12530 -- UML 2 RTF issue You may be right in inferring James. intentions, but they are certainly not clear from his message and the following discussion. First, let.s stop talking about duplicated or replicated parameter lists, as they all serve different purposes and may in fact differ from each other even in the same class. I assume from now on that it is agreed that it must be possible to have separate parameter lists for (i) behavioral feature (ii) behavior and (iii) interfaces. So the discussion is on whether we can elide some of these lists and what the inferred parameters would be. Your proposal of allowing eliding the behavior parameters and inferring from the behavioral feature is the most natural and avoids the problem pointed to below. However, it also has a problem of its own: Say you have an inheritance chain where you have classes C1 inherits from C2 inherits from C3. C2 and C3 each have behavior B, without parameter list, but no behavioral feature corresponding to it. Here is already a problem in that we cannot statically analyze B as we do not know the types of its parameters. Continue the scenario. C1 has a behavior B also, with some parameter list. C1 has a behavioral feature BF pointing to B. Now imagine a case where the behavioral feature BF is invoked with parameters not matching the parameters on B, so another behavior has to be found. But none of the behaviors up the chain have parameters defined, so we cannot infer anything. Th. From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: Thursday, June 19, 2008 9:08 AM To: Weigert, Thomas Cc: Anthony Hunter; Bran Selic; Ed Seidewitz; James Bruck; uml2-rtf@omg.org; Thomas Weigert; Jim Amsden Subject: RE: issue 12530 -- UML 2 RTF issue >>The only simplification that we could do without dramatically changing the language would be to allow the list to be omitted with a reasonable default interpretation. For example, one could say that if a behavioral feature does not have a parameter list, its parameter list is derived from the pointed to behavior, but note that there are many complications: What if there is no behavior in this object, but the behavior is inherited down---the parameters cannot be taken from there. Note further that this scheme would limit the flexibility of the specification of the behavior. Thomas, I think what James is suggesting is the other way around: if a Behavior has a specification set (a behavioral feature), but no owned parameters, then that list gets derived from the parameter list of the specification. Since currently a Behavior's specification has to be owned by the same classifier owning the behavior, you are guraranteed to find it and not search for it up in the hierarchy. So as it stands now in practice, we have 2 sets of parameters to keep in synch: one defined in the behavior feature of the classifier (the specification), and one in the Behavior (the method). In fact, considering the case where that behavioral feature also matces another one declared by an interface realized by the classifier, we have yet another set of parameters to keep in synch (total of 3). Jim Amsden actually touched on this same issue regarding having to duplicate the behavioral feature, hence also the parameters, in implementing classifiers in a separate issue before. As you said, that was designed intentionally in UML to separate concerns, however maybe with good assumptions for default values, we can optimize the common case in practice. ------------------------------------- Maged Elaasar, PhD Candidate Senior Software Developer, Team Lead OMG Representative for UML / DD Rational Modeling Platform/ Tools Rational Software, IBM Software Group, Canada melaasar@ca.ibm.com tel: 613-591-7935 "Weigert, Thomas" "Weigert, Thomas" 06/18/2008 10:54 PM To James Bruck/Ottawa/IBM@IBMCA, "Bran Selic" cc "Ed Seidewitz" , , "Thomas Weigert" , Anthony Hunter/Ottawa/IBM@IBMCA, Maged Elaasar/Ottawa/IBM@IBMCA Subject RE: issue 12530 -- UML 2 RTF issue James, Your suggestion proposes to make major changes to the intention of the separation of the behavior specification (the behavioral feature) and the behavior implementation (the behavior). This separation goes back to UML 1. 1. A behavioral feature declares that an object will handle certain requests. 2. A behavior implements how the object handles those requests. 3. Which behavior will be invoked in response to a matching request arriving is determined by the particular semantics of the modeling language/profile (due to the wide variation possible this is a semantic variation point). It is not necessarily the Behavior that is the behavior pointed to by the BehavioralFeature. a. One example might be that one searches the hierarchy up from the pointed to behavior until one finds a behavior with an appropriate signature. b. This may involve multiple dispatch (i.e., matching on more than one parameter type), the type of the first parameter, strict identify on all parameters, name matching, or many more. As you can see, the duplication of the parameter list is inherently built into the UML. Taking this away may be a practical suggestion, but is a major change. These two parameter lists serve totally different purpose: · The parameter list on behavioral feature establishes which behavior invocation requests are accepted by the object. · The parameter list on behavior establishes which behavior will be actually invoked to handle the request. In some languages that there are two such lists appears redundant. But in other languages this is essential. The only simplification that we could do without dramatically changing the language would be to allow the list to be omitted with a reasonable default interpretation. For example, one could say that if a behavioral feature does not have a parameter list, its parameter list is derived from the pointed to behavior, but note that there are many complications: What if there is no behavior in this object, but the behavior is inherited down---the parameters cannot be taken from there. Note further that this scheme would limit the flexibility of the specification of the behavior. Note that your suggestion is just one step away from suggesting that we do not need the concept of a BehavioralFeature, as that concept could be subsumed by Interface. If we were to follow your suggestion, using Interfaces to specify a behavioral feature would be more powerful than just eliminating the parameter list. Either way, this is a big change. Th. From: James Bruck [mailto:jbruck@ca.ibm.com] Sent: Monday, June 16, 2008 10:05 AM To: Bran Selic Cc: Ed Seidewitz; uml2-rtf@omg.org; Thomas Weigert; Anthony Hunter; Maged Elaasar Subject: Re: issue 12530 -- UML 2 RTF issue Hi, The motiviation behind the issue stems from some practical implementation concerns. As Bran mentioned, one issue has to do with duplication of information in serialized models. Another issue has to do with keeping the parameters of the Behavior matched up with the parameters of the implemented BehavioralFeature (its specification). In order to verify the constraint, we can't for example, simply assume that the parameters will match just because the specification is explicitly set. Having only one copy of the parameter list would also help with ensuring that changes in one spot would keep the entire model in a consistent state. As Ed pointed out, in a case where no specification is set, explicitly setting the parameters would be necessary; however, we were focusing on cases where a specification was explicitly being set. Cheers, - James. "Bran Selic" 13/06/2008 05:48 PM To "Thomas Weigert" cc "Ed Seidewitz" , uml2-rtf@omg.org, James Bruck/Ottawa/IBM@IBMCA Subject Re: issue 12530 -- UML 2 RTF issue My understanding is that the problem is that this duplication of information significantly bulks up models. However, James Bruck, who raised the issue, may have more information. Bran On Fri, Jun 13, 2008 at 5:36 PM, Thomas Weigert wrote: Before we all get excited about this, can we understand the motivation behind this issue? The situation is as Ed says, I believe. The constraint does not cause any problems for stand-alone behaviors, I think. Th. From: Bran Selic [mailto:bran.selic@gmail.com] Sent: Friday, June 13, 2008 3:29 PM To: Ed Seidewitz Cc: uml2-rtf@omg.org Subject: Re: issue 12530 -- UML 2 RTF issue Actually, the "awkward" solution is the one I was thinking of. It's not that difficult to realize. Another alternative is to have a subclass of Behavior for those that are realizations of BehavioralFeatures. Bran On Fri, Jun 13, 2008 at 3:35 PM, Ed Seidewitz wrote: A behavior is not required to implement a behavioral feature. It may be stand-alone, callable using a call behavior action, and it can have parameters in order to pass data in and out. This is particularly common in activity modeling. If the behavior is, in fact, the method of a behavioral feature, then it would, indeed, be possible to derive the parameters of the behavior from the parameters of the behavioral feature. However, it would be rather awkward (though not impossible) to set up the abstract syntax metamodel so that the parameters of the behavior are derived from the behavioral feature, if it has one, and are owned by the behavior if it does not. One would have to distinguish between parameters and owned parameters, with the former always being derived, and the latter only allowed if there was no behavioral feature, etc. The current approach is consistent with the idea that the behavioral feature is a specification and the behavior is a structurally independent implementation, with the relationship between the two being one of conformance or "matching". -- Ed -------------------------------------------------------------------------------- From: Juergen Boldt [mailto:juergen@omg.org] Sent: Friday, June 13, 2008 2:40 PM To: uml2-rtf@omg.org; issues@omg.org Subject: issue 12530 -- UML 2 RTF issue This is issue # 12530 From: James Bruck We are concerned with the UML specification forcing an Behavior's parameter list to be in sync with its behavioral feature. >From the UML 2.1.1 07-02-03, page 431 (or 445/732) it states in the 13.3.2 Behaviors section the following constraint: [1] The parameters of the behavior must match the parameters of the implemented behavioral feature We feel that this constraint is unnecessary. The parameter list of a Behavior element can be derived from its behavioral feature. Forcing the Behavior to have its own list of parameters has practical implementation problems such as needlessly increasing the size of the UML model, and worse, forcing one to preform the tedious task (or the tool to preform the extra overhead) of keeping the parameter lists of the Behavior and its behavioral feature in sync. We would like to request that this constraint is removed from the specification. -- Bran Selic Malina Software Corp. pic06191.gif -----------------------------------------------------------------------------------------------------------------------------------------------------