Issue 6373: Parameters in Features and Common Behavior (uml2-superstructure-ftf) Source: NIST (Dr. Conrad Bock, conrad.bock(at)nist.gov) Nature: Revision Severity: Significant Summary: The Features model (Figure 28) shows BehavioralFeature with the parameter association presumably derived from formalParameter and returnResult, whereas the Common Behavior model (Figure 312) shows Behavior formalParameter and returnResult derived, derived from the parameter association. These parameter models for operations and behavior should be the same. Resolution: see above Revised Text: Actions taken: October 20, 2003: received issue March 8, 2005: closed issue Discussion: As pointed out in the summary, these portions of the specification should be consistent, which can be accomplished either by making the features model consistent with the common behavior model, or vice versa. While the issue does not notice this, there is actually a defect in the features model in that it is missing a consistency constraint between the formal parameter and the return parameters. The proposed resolution to issue 7344 resolves the discrepancy between superstructure and infrastructure on how to interpret parameters. This resolution brings the parameter model in CommonBehavior in synchronicity with the proposed resolution 7344. In Figure 311 “Common Behavior” change parameter to ownedParameter. Delete the derived associations Behavior.formalParameter and Behavior.returnResult. In Section 13.3.3. Behavior, Associations, delete the definitions of formalParameter and returnedResult. Change parameter to ownedParameter. In Section 13.3.3, Semantics, on p. 439 change the first paragraph: When a behavior is invoked, its attributes and parameters (if any) are created and appropriately initialized. Upon invocation, the arguments of the original invocation action are made available to the new behavior execution corresponding to its formal parameters, if any. When a behavior completes its execution, a value or set of values is returned corresponding to each return result parameter, if any. To When a behavior is invoked, its attributes and parameters (if any) are created and appropriately initialized. Upon invocation, the arguments of the original invocation action are made available to the new behavior execution corresponding to its parameters with direction in and inout, if any. When a behavior completes its execution, a value or set of values is returned corresponding to each parameter with direction out, inout, or return, if any. End of Annotations:===== me: Conrad Bock Company: NIST mailFrom: conrad.bock@nist.gov Nature: Revision Severity: Significant Subject: Parameters in Features and Common Behavior The Features model (Figure 28) shows BehavioralFeature with the parameter association presumably derived from formalParameter and returnResult, whereas the Common Behavior model (Figure 312) shows Behavior formalParameter and returnResult derived, derived from the parameter association. These parameter models for operations and behavior should be the same. From: "Thomas Weigert" To: "Thomas Weigert" , "Branislav Selic" , Cc: , Subject: ,cb, Issue 6373 Date: Sun, 18 Apr 2004 21:30:07 -0500 X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal The solution to issue 6373 requires a correction to the infrastructure. Note that this issue does point to a problem in both superstructure and infrastructure. How does one go about suggesting changes to the infrastructure? OMG Issue No: 6373 Title: Parameters in Features and Common Behavior Source: NIST (Mr. Conrad Bock, conrad.bock@nist.gov) Summary: The Features model (Figure 28) shows BehavioralFeature with the parameter association presumably derived from formalParameter and returnResult, whereas the Common Behavior model (Figure 312) shows Behavior formalParameter and returnResult derived, derived from the parameter association. These parameter models for operations and behavior should be the same. Discussion: As pointed out in the summary, these portions of the specification should be consistent, which can be accomplished either by making the features model consistent with the common behavior model, or vice versa. While the issue does not notice this, there is actually a defect in the features model in that it is missing a consistency constraint between the formal parameter and the return parameters. While it may be procedurally simpler, to make the change to the common behavior model (as the infrastructure is not affected), the more sensible change is the correct the feature model: The feature model has inherited from the Infrastructure the following problem: In the manner of representing the relationship between BehavioralFeature and Parameter the infrastructure imposes either a limit on the nature of parameters on modeling languages reusing the infrastructure or forces them to duplicate this mechanism. The infrastructure decided to represent as concrete associations the kinds of parameters, and distinguishes two: returnResult and formalParameter. The parameter association is then derived as a union of these. However, there may be a large number of parameter kinds. For example, the superstructure defines four, and one can easily imagine additional ones. To be more reusable and expandable, parameter should be characterized by its kind (does it return a result, is it a formal parameter). Note that this is, in reality, a property of the parameter, not of the relation between BehavioralFeature and Parameter and thus is modeled better this way anyway. Back to the superstructure.. To deal with the inadequacy of the infrastructure, the superstructure has introduced a mandatory attribute direction kind for Parameter, indicating whether this parameter is passed in or out, or whether it is a result parameter. Consequentially, the infromation whether a parameter is a return result of a behavioral feature is already determined by the direction kind of the parameter, and the association BehavioralFeature.returnResult adds no additional value. The same goes for BehavioralFeature.formalParameter. Thus, these associations would be better viewed as derived by selecting the subset of BehavioralFeature.parameter, where the parameter is a return parameter, or not, respectively. If this is not corrected as described, a constraint is missing in the Kernel package that states that the direction kind of a parameter must be consistent with the association to the parameter (thus either way a change to the Kernel is required). The following changes are propoosed, but similar changes will have to be made to the infrastructure. A corresponding issue has been submitted. In Fig. 28, Features Diagram, remove the diamond from the Parameter.ownerReturnParam end of the corresponding association between BehavioralFeature and Parameter and delete the text .{subsets namespace}.. Mark the BehaviralFeature.returnResult end of the same association as derived. Change the comment text to .{union, subsets member}.. Remove the diamond from the Parameter.ownerFormalParam end of the corresponding association between BehavioralFeature and Parameter and delete the text .{subsets namespace}.. Mark the BehaviralFeature.formalParameter end of the same association as derived. Change the comment text to .{union, subsets member}.. Add a diamond to the association between BehavioralFeature and Parameter on the end attaching to BehavioralFeature and add the text .{subsets namespace}.. Remove the ./. from the parameter end of this association, indicating that this association is not derived. Change the text the .{union, subsets ownedMember, ordered.}. In the association section of BehavioralFeature, on p.72, insert a slash indicateding a derived association before .returnResult:.. Change the explanatory text to: .Specifies the ordered set of return results of this BehavioralFeature. Subsets Namespace::member and BehavioralFeature::parameter. This association is derived from the direction of the parameter such that it includes all parameters that have the direction return. In the association section of BehavioralFeature, on p.72, insert a slash indicateding a derived association before .formalParameter:.. Change the explanatory text to: .Specifies the ordered set of formal parameters of this BehavioralFeature. Subsets Namespace::member and BehavioralFeature::parameter. This association is derived from the direction of the parameter such that it excludes all parameters that have the direction.. In the association section of BehavioralFeature, on p.72, remove the slash before .parameter:.. Change the explanatory text to: .Specifies the ordered set of parameters of this BehavioralFeature. Subsets Namespace::ownedMember.. Disposition: Resolved To: "Thomas Weigert" Cc: mu2i-ftf@omg.org, uml2-superstructure-ftf@omg.org Subject: Re: ,cb cs, Proposed issues for 15 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Branislav Selic Date: Tue, 18 May 2004 06:35:06 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.0.2CF1|June 9, 2003) at 05/18/2004 06:35:11, Serialize complete at 05/18/2004 06:35:11 Thomas, Some feedback on your proposed resolutions: 6356 - please see my comment regarding 6429, which introduces unacceptable constraints (at least unacceptable to IBM because it removes an important capability of the current model). At the very least, the explanation of what a port is tha tis included in the resolution should be modified (we've had this discussion before: a UML-RT port is actually a property that takes up a slot). Perhaps we can deal with this by having a subtype of port which is also a subtype of Property? 6373 - your resolution is, in effect, calling for a change of the infrastructure. Given the dependency structure, this resolution will first have to be approved by the infrastructure FTF. So, you should first submit to that FTF (you may have to raise an issue to deal with only the infrastructure part, though). 6429 - I disagree with this proposed resolution since it opens up major scalability problems and limits the modeling power of ports. It is extremely useful to allow ports to be created dynamically as needed. In our experience, people often configure a maximum number of ports using worst-case numbers (e.g., I have seen designs that had port multiplicities that ranged in the hundreds and even thousands). In practice, it is typically the case that a much smaller number is actually needed. Therefore, I suggest that the resolution should (a) remove the statement that all ports are created when the object is created and (b) allow lower multiplicity bounds to be different from upper bounds. The semantics of these bounds are the same as for parts: the lower bound specifies the number that are created when the containing object is created and the upper is a maximum. This is a more general approach to the problem that leaves open the possibility of both dynamic and statically configured port multiplicities. Bran "Thomas Weigert" 05/16/2004 02:29 PM To Branislav Selic/Ottawa/IBM@IBMCA, cc Subject ,cb cs, Proposed issues for 15 Dear all, attached please find a set of proposed issues for Ballot 15. I would like to draw special attention to 6373. This issue resolution also affects the infrastructure, so a corresponding resolution (with different wording, as the changes would be spread over several packages) has to be floated there. An issue that highlights the problem in the infrastructure has been submitted. Please provide feedback to improve these resolutions. Thanks, Th. To: "Thomas Weigert" Cc: "Branislav Selic" , mu2i-ftf@omg.org, uml2-superstructure-ftf@omg.org Subject: Re: ,cb cs, Proposed issues for 15 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 From: Stephen Brodsky Date: Tue, 18 May 2004 15:26:37 -0700 X-MIMETrack: Serialize by Router on D03NM116/03/M/IBM(Release 6.0.2CF2HF303 | April 20, 2004) at 05/18/2004 16:26:39, Serialize complete at 05/18/2004 16:26:39 Thomas and Conrad, The proposed 6373 resolution where there is a parameter kind with an allowed set of values causes problems for MOF instead of adding the intended extensibility. Parameter kinds with values outside the range known by MOF would be invalid in MOF, so a UML operation containing such parameters would no longer be a valid MOF operation also. Instead, additional information should be added in a way that does not create invalid MOF models, and should be structured as an incremental addition. Two possible ways to structure this is by adding more information to Operation or by making a UML subclass of Parameter. Thanks, -Steve Stephen A. Brodsky, Ph.D. Software Architect, STSM Notes Address: Stephen Brodsky/Santa Teresa/IBM@IBMUS Internet Address: sbrodsky@us.ibm.com Phone: 408.463.5659 "Thomas Weigert" 05/16/2004 11:29 AM To: "Branislav Selic" , cc: Subject: ,cb cs, Proposed issues for 15 Dear all, attached please find a set of proposed issues for Ballot 15. I would like to draw special attention to 6373. This issue resolution also affects the infrastructure, so a corresponding resolution (with different wording, as the changes would be spread over several packages) has to be floated there. An issue that highlights the problem in the infrastructure has been submitted. Please provide feedback to improve these resolutions. Thanks, Th. #### Comp struc + com beh issues 15 done v1.doc has been removed from this note on May 18, 2004 by Stephen Brodsky [attachment "Comp struc + com beh issues 15 done v1.doc" deleted by Branislav Selic/Ottawa/IBM] From: "Thomas Weigert" To: "Stephen Brodsky" , "Thomas Weigert" Cc: "Branislav Selic" , , Subject: RE: ,cb cs, Proposed issues for 15 Date: Tue, 18 May 2004 20:59:45 -0500 X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Thanks for the comments. Let's come up with a solution that works for everybody. 1. Note that the strategy of extending enumerations in subtypes is used in other places of the specification. I understand the issues about that allowing a sequence of assignments that would lead to a type error in the absence of run-time type checks or Eiffel-like assumptions (this is the analogous problem to the skier example from Meyer's text book). However, this is a problem that can be avoided by careful programming, as you know. 2. Another solution to the one pointed out by you is to give a richer set of ParameterDirectionKinds in the infrastructure. Making a subtype to Parameter in superstructure does not strike me as the right solution; in addition, we still have the problem that what information is derived and what is given is opposite. The infrastructure solution is simply not extensible and reusable and needs to be fixed, I believe. 3. Yet another way of dealing with this would be to use integer codes, rather than enumerated types, but allow to name integers for clarity (that would avoid the typing problem). Th. -----Original Message----- From: Stephen Brodsky [mailto:sbrodsky@us.ibm.com] Sent: Tuesday, May 18, 2004 5:27 PM To: Thomas Weigert Cc: Branislav Selic; mu2i-ftf@omg.org; uml2-superstructure-ftf@omg.org Subject: Re: ,cb cs, Proposed issues for 15 Thomas and Conrad, The proposed 6373 resolution where there is a parameter kind with an allowed set of values causes problems for MOF instead of adding the intended extensibility. Parameter kinds with values outside the range known by MOF would be invalid in MOF, so a UML operation containing such parameters would no longer be a valid MOF operation also. Instead, additional information should be added in a way that does not create invalid MOF models, and should be structured as an incremental addition. Two possible ways to structure this is by adding more information to Operation or by making a UML subclass of Parameter. Thanks, "Thomas Weigert" 05/16/2004 11:29 AM To: "Branislav Selic" , cc: Subject: ,cb cs, Proposed issues for 15 Dear all, attached please find a set of proposed issues for Ballot 15. I would like to draw special attention to 6373. This issue resolution also affects the infrastructure, so a corresponding resolution (with different wording, as the changes would be spread over several packages) has to be floated there. An issue that highlights the problem in the infrastructure has been submitted. Please provide feedback to improve these resolutions. Thanks, Th. #### Comp struc + com beh issues 15 done v1.doc has been removed from this note on May 18, 2004 by Stephen Brodsky From: "Thomas Weigert" To: "'Thomas Weigert'" , "'Jim Amsden'" , Subject: RE: Updated Issue 7344 Date: Sun, 26 Sep 2004 13:26:48 -0500 X-Mailer: Microsoft Outlook, Build 10.0.6626 I have written up the change to the common behavior section to match Jim's proposal. If further changes are made, I will track those. This is issue 6373. Th. -----Original Message----- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: Sunday, September 26, 2004 1:13 PM To: 'Thomas Weigert'; 'Jim Amsden'; 'uml2-superstructure-ftf@omg.org' Subject: RE: Updated Issue 7344 I will now create a solution for 6373 to match your proposal. We should decide what to do with the two associations mentioned. Comp struc + com beh issues 26.doc OMG Issue No: 6373 Title: Parameters in Features and Common Behavior Source: NIST (Mr. Conrad Bock, conrad.bock@nist.gov) Summary: The Features model (Figure 28) shows BehavioralFeature with the parameter association presumably derived from formalParameter and returnResult, whereas the Common Behavior model (Figure 312) shows Behavior formalParameter and returnResult derived, derived from the parameter association. These parameter models for operations and behavior should be the same. Discussion: As pointed out in the summary, these portions of the specification should be consistent, which can be accomplished either by making the features model consistent with the common behavior model, or vice versa. While the issue does not notice this, there is actually a defect in the features model in that it is missing a consistency constraint between the formal parameter and the return parameters. The proposed resolution to issue 7344 resolves the discrepancy between superstructure and infrastructure on how to interpret parameters. This resolution brings the parameter model in CommonBehavior in synchronicity with the proposed resolution 7344. In Figure 311 .Common Behavior. delete the derived associations Behavior.formalParameter and Behavior.returnResult. In Section 13.3.3. Behavior, Associations, delete the definitions of formalParameter and returnedResult. In Section 13.3.3, Semantics, on p. 439 change the first paragraph: When a behavior is invoked, its attributes and parameters (if any) are created and appropriately initialized. Upon invocation, the arguments of the original invocation action are made available to the new behavior execution corresponding to its formal parameters, if any. When a behavior completes its execution, a value or set of values is returned corresponding to each return result parameter, if any. To When a behavior is invoked, its attributes and parameters (if any) are created and appropriately initialized. Upon invocation, the arguments of the original invocation action are made available to the new behavior execution corresponding to its parameters with direction in and inout, if any. When a behavior completes its execution, a value or set of values is returned corresponding to each parameter with direction out, inout, or return, if any. Disposition: Resolved From: "Thomas Weigert" To: "'Branislav Selic'" , Cc: , Subject: RE: Second draft of ballot 26 Date: Sat, 25 Sep 2004 20:58:56 -0500 X-Mailer: Microsoft Outlook, Build 10.0.6626 Bran et.al., I am not sure why my resolution for issue 6373 has disappeared. The proposed resolution for issue 7344 may or may not address part of this. The reason why I say "may or may not" is because it is difficult to see the final result without having the metamodel accessible. Can you please provide the new metamodel snippets that are created as a result of resolution proposal 7344. I am concerned because I thought I understood the intent of the proposal, but then some detail in the write-up seems inconsistent with that intent. For example, I believe that the proposal 7344 wants to eliminate the returnResult as a separate association. However, in the text for operation, we are still referencing return parameters. These need to be described, e.g., as the set of parameters that have direction kind out, inout, or return. Actually, if my understanding is correct, the direction kind return seems unneeded now as it cannot be distinguished from out. Anyway, we need to get clarity on what 7344 proposes, which is best done by exhibiting the metamodel.n Then, the associations between Behavior and Parameter have to be made consistent with the definitions introduced in 7344. However, as it stands I think we cannot yet vote on 7344. Note that the relationship between BehavioralFeature and Parameter is a very central one to the UML and needs to be correct. Please provide the metamodel for the affected diagrams as soon as possible, so that we can finish this issue soon. Th. -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Friday, September 24, 2004 4:12 AM To: uml2-superstructure-ftf@omg.org Cc: mu2i-ftf@omg.org; uml2di-ftf@omg.org Subject: Second draft of ballot 26 Attached, please find the second draft of ballot 26. The only thing I am not sure of is whether issue 6373 is resolved by the resolution to issue 7344 (Jim, Thomas?). Also, we may also add a resolution to issue 6630. Finally, on the final version of the ballot, I will include a proposla to defer the remaining 40 or so issues that we have not been able to process. Please review the proposed resolutions carefully -- we want to make sure that we do not accidentally slip in bad resolutions in our haste to close things off. Regards, Bran Please advise, Th.