Issue 7343: Section 11.7 (uml2-rtf) Source: Missouri University of Science and Technology (Dr. Thomas Weigert, weigert(at)mst.edu) Nature: Clarification Severity: Critical Summary: 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. Define an attribute "direction" on Parameter of type "ParameterDirectionKind". In infrastructure give it two values: in, and returnResult. This type can be extended in other languages, e.g., the UML uses also out, and inout). Make BehavioralFeature.parameter concrete. Make the formalParameter and returnResult associations derived from the direction attribute of each parameter. The result is the identical model, but much more reusable. Note that the superstructure was forced to introduce both mechanisms, thus running into the risk of inconsistencies, if the two mechanisms do not match up. There is no negative impact on the infrastructure of relying on the more reusable option proposed here. The number of model elements stored in the repository is identical for infrastructure, and lower for superstructure. Resolution: Revised Text: Actions taken: May 16, 2004: received issue February 18, 2005: moved from infrastructure August 23, 2006: closed issue Discussion: This is a fixed by the resolution to issue 7344. BehavioralFeature no longer separates returnResult and formalParameter. It has BehavioralFeature::ownedParameter and Parameter has direction:ParameterDirectionKind. Disposition: Closed, no change End of Annotations:===== m: webmaster@omg.org Date: 16 May 2004 13:46:46 -0400 To: Subject: Issue/Bug Report -------------------------------------------------------------------------------- Name: Thomas Weigert Company: Motorola mailFrom: thomas.weigert@motorola.com Notification: No Specification: UML Section: 11.7 FormalNumber: ptc/03-09-15 Version: 2.0 RevisionDate: xx/09/2003 Page: p.146 Nature: Clarification Severity: Critical HTTP User Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0) Description 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. Define an attribute "direction" on Parameter of type "ParameterDirectionKind". In infrastructure give it two values: in, and returnResult. This type can be extended in other languages, e.g., the UML uses also out, and inout). Make BehavioralFeature.parameter concrete. Make the formalParameter and returnResult associations derived from the direction attribute of each parameter. The result is the identical model, but much more reusable. Note that the superstructure was forced to introduce both mechanisms, thus running into the risk of inconsistencies, if the two mechanisms do not match up. There is no negative impact on the infrastructure of relying on the more reusable option proposed here. The number of model elements stored in the repository is identical for infrastructure, and lower for superstructure. Subject: [mu2i] Issue 7343 Inconsistency between Infra and Super on parameter direction Date: Thu, 29 Jul 2004 19:17:57 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mu2i] Issue 7343 Inconsistency between Infra and Super on parameter direction Thread-Index: AcRwoUfBLnXlOXJaSFm+NNOBA7/BKwFGZitw From: "Pete Rivett" To: "Thomas Weigert" , "Branislav Selic" , "Karl Frank" Cc: , "MOF UML Infrastructure FTF" , X-Virus-Scanned: by amavisd-new at sentraliant.com Thomas, I tried to track down discussion related to 'pushback from the infrastructure team' on the issue but failed, and I don't recall it being discussed on an Infra call. I assume you mean Issue 7343 which you raised on Infra. So though you may have had a response from one or more individuals I do not recall any team view being elaborated. Perhaps Thomas or my fellow Infra members could point me at the thread or summarize their arguments? FWIW here are my thoughts: a) I agree that the inconsistency is undesirable b) A further issue is the relationship between the inherited Operation.type and the set of returnParameters c) It is desirable for Operations to have a type and be included in expressions (e.g. in OCL) and composed. d) DirectionKind for parameters was in MOF 1.4 so for compatibility it does not seem to be a bad idea e) Any restrictions on values for DirectionKind would be imposed by MOF not by Infra: we have precedence for this Pete Pete Rivett (mailto:pete.rivett@adaptive.com) Chief Scientist, Adaptive Inc. Dean Park House, 8-10 Dean Park Crescent, Bournemouth, BH1 1HL, UK Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448 http://www.adaptive.com -------------------------------------------------------------------------------- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: Friday, July 23, 2004 11:30 AM To: Branislav Selic; Karl Frank Cc: uml2-superstructure-ftf@omg.org Subject: RE: Resolution for ballot 20: issue 7135 The infrastructure treats parameters different from the superstructure. I have proposed a resolution that would solve that problem but have received pushback from the infrastructure team on not wanting to make changes. I have not carefully examined the solution discussed below, but I think that our solutions overlap, and thus you will run into the same objections. Due to the need to run the resolution through both teams I was planning to defer my issue, but if you think that you will have more luck, we should combine our resolutions. Th. -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Thursday, July 22, 2004 8:19 PM To: Karl Frank Cc: uml2-superstructure-ftf@omg.org Subject: RE: Resolution for ballot 20: issue 7135 Hi Karl, The fact that Infrastructure omits "direction" for Parameter may be a bug, but I am not sure. I seem to recall some reasoning having to do with the difference of modeling of operations in the MOF versus UML. I would seek Pete Rivett's and Steve Brodsky's advice on this issue before moving on it. At the very least -- assuming it IS a bug -- your fix should also add a "direction:ParameterDirectionKind" attribute to Parameter in the Infrastructure as well as the metaclass ParameterDirectionKind. However, I don't think that this was an omission, but design instead. Cheers, Bran "Karl Frank" 07/22/2004 02:52 PM To Branislav Selic/Ottawa/IBM@IBMCA, cc Subject RE: Resolution for ballot 20: issue 7135 Bran, you got the problem with Operation syntax in the superstructure, but seem to have overlooked the exact same problem in the infrastructure. My attached proposal for the infrastructure proposes a fix to both the super and the infra on both BNF and a related problem of lack of clarity about return result. Please see the attached and consider whether it should be incorporated as a small part of your big fix. -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Thursday, 15 July, 2004 12:23 PM To: uml2-superstructure-ftf@omg.org Subject: Resolution for ballot 20: issue 7135 Issue 7135 asks for a consolidation of the multitude of mutually inconsistent and self-inconsistent BNF forms used in the various chapters to describe textual notations. I have visited all of the ones that appear in both the Superstructure and Infrastructure documents and proposed the appropriate fixes to all of them. The proposed changes are included in the attached document. In my first cut at this, I also tried to expand on the meaning of some of the adornments that appear in such specs (e.g., "ordered", "unique", "bag"...) but I abandoned that, since there are other sections of text that do that (notably, pages 91-92 of the Super and 125-126 in the Infra). These could certainly be improved, but that is outside the scope of this issue. So, the net result is a simple rewrite of the various BNF expressions to conform to a single BNF convention. I've also included an explanation of that convention as part of the text to be added to the spec. I plan to propose resolution this for ballot 20. Thanks, Bran [attachment "Ballot20_Issues_6213-6214-7355.doc" deleted by Branislav Selic/Ottawa/IBM] To: "Pete Rivett" Cc: "Branislav Selic" , "Karl Frank" , "MOF UML Infrastructure FTF" , ocl2-ftf@omg.org, "Thomas Weigert" , uml2-superstructure-ftf@omg.org Subject: Re: [mu2i] Issue 7343 Inconsistency between Infra and Super on parameter direction X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 From: Stephen Brodsky Date: Thu, 29 Jul 2004 16:35:05 -0700 X-MIMETrack: Serialize by Router on D03NM116/03/M/IBM(Release 6.0.2CF2HF342 | June 4, 2004) at 07/29/2004 17:35:08, Serialize complete at 07/29/2004 17:35:08 Pete, I haven't been following the email very closely since Orlando. Some months back there was a proposal to modify Operation in Basic that I had concerns about. I am not sure if this is the same issue or not, if it is I think this is what Thomas is referring to. 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 "Pete Rivett" 07/29/2004 04:17 PM To: "Thomas Weigert" , "Branislav Selic" , "Karl Frank" cc: , "MOF UML Infrastructure FTF" , Subject: [mu2i] Issue 7343 Inconsistency between Infra and Super on parameter direction Thomas, I tried to track down discussion related to 'pushback from the infrastructure team' on the issue but failed, and I don't recall it being discussed on an Infra call. I assume you mean Issue 7343 which you raised on Infra. So though you may have had a response from one or more individuals I do not recall any team view being elaborated. Perhaps Thomas or my fellow Infra members could point me at the thread or summarize their arguments? FWIW here are my thoughts: a) I agree that the inconsistency is undesirable b) A further issue is the relationship between the inherited Operation.type and the set of returnParameters c) It is desirable for Operations to have a type and be included in expressions (e.g. in OCL) and composed. d) DirectionKind for parameters was in MOF 1.4 so for compatibility it does not seem to be a bad idea e) Any restrictions on values for DirectionKind would be imposed by MOF not by Infra: we have precedence for this Pete Pete Rivett (mailto:pete.rivett@adaptive.com) Chief Scientist, Adaptive Inc. Dean Park House, 8-10 Dean Park Crescent, Bournemouth, BH1 1HL, UK Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448 http://www.adaptive.com -------------------------------------------------------------------------------- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: Friday, July 23, 2004 11:30 AM To: Branislav Selic; Karl Frank Cc: uml2-superstructure-ftf@omg.org Subject: RE: Resolution for ballot 20: issue 7135 The infrastructure treats parameters different from the superstructure. I have proposed a resolution that would solve that problem but have received pushback from the infrastructure team on not wanting to make changes. I have not carefully examined the solution discussed below, but I think that our solutions overlap, and thus you will run into the same objections. Due to the need to run the resolution through both teams I was planning to defer my issue, but if you think that you will have more luck, we should combine our resolutions. Th. -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Thursday, July 22, 2004 8:19 PM To: Karl Frank Cc: uml2-superstructure-ftf@omg.org Subject: RE: Resolution for ballot 20: issue 7135 Hi Karl, The fact that Infrastructure omits "direction" for Parameter may be a bug, but I am not sure. I seem to recall some reasoning having to do with the difference of modeling of operations in the MOF versus UML. I would seek Pete Rivett's and Steve Brodsky's advice on this issue before moving on it. At the very least -- assuming it IS a bug -- your fix should also add a "direction:ParameterDirectionKind" attribute to Parameter in the Infrastructure as well as the metaclass ParameterDirectionKind. However, I don't think that this was an omission, but design instead. Cheers, Bran "Karl Frank" 07/22/2004 02:52 PM To Branislav Selic/Ottawa/IBM@IBMCA, cc Subject RE: Resolution for ballot 20: issue 7135 Bran, you got the problem with Operation syntax in the superstructure, but seem to have overlooked the exact same problem in the infrastructure. My attached proposal for the infrastructure proposes a fix to both the super and the infra on both BNF and a related problem of lack of clarity about return result. Please see the attached and consider whether it should be incorporated as a small part of your big fix. -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Thursday, 15 July, 2004 12:23 PM To: uml2-superstructure-ftf@omg.org Subject: Resolution for ballot 20: issue 7135 Issue 7135 asks for a consolidation of the multitude of mutually inconsistent and self-inconsistent BNF forms used in the various chapters to describe textual notations. I have visited all of the ones that appear in both the Superstructure and Infrastructure documents and proposed the appropriate fixes to all of them. The proposed changes are included in the attached document. In my first cut at this, I also tried to expand on the meaning of some of the adornments that appear in such specs (e.g., "ordered", "unique", "bag"...) but I abandoned that, since there are other sections of text that do that (notably, pages 91-92 of the Super and 125-126 in the Infra). These could certainly be improved, but that is outside the scope of this issue. So, the net result is a simple rewrite of the various BNF expressions to conform to a single BNF convention. I've also included an explanation of that convention as part of the text to be added to the spec. I plan to propose resolution this for ballot 20. Thanks, Bran [attachment "Ballot20_Issues_6213-6214-7355.doc" deleted by Branislav Selic/Ottawa/IBM] From: "Thomas Weigert" To: "Stephen Brodsky" , "Pete Rivett" Cc: "Branislav Selic" , "Karl Frank" , "MOF UML Infrastructure FTF" , , "Thomas Weigert" , Subject: RE: [mu2i] Issue 7343 Inconsistency between Infra and Super on parameter direction Date: Thu, 29 Jul 2004 21:14:45 -0500 X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Please find the email trail attached. The problem is the following: 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 by some other means. 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. 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 information whether a parameter is a return result of a behavioral feature is already determined by the direction kind of the parameter, and the association BehavioralFea­ture.returnResult adds no additional value. The same goes for BehavioralFea­ture.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). We should try to find a solution to this problem that satisfies the concerns that are raised by Stephen in his attached email and, at the same time, avoids the duplication that is the case today. All the best, Th. -----Original Message----- From: Stephen Brodsky [mailto:sbrodsky@us.ibm.com] Sent: Thursday, July 29, 2004 6:35 PM To: Pete Rivett Cc: Branislav Selic; Karl Frank; MOF UML Infrastructure FTF; ocl2-ftf@omg.org; Thomas Weigert; uml2-superstructure-ftf@omg.org Subject: Re: [mu2i] Issue 7343 Inconsistency between Infra and Super on parameter direction Pete, I haven't been following the email very closely since Orlando. Some months back there was a proposal to modify Operation in Basic that I had concerns about. I am not sure if this is the same issue or not, if it is I think this is what Thomas is referring to. Thanks, "Pete Rivett" 07/29/2004 04:17 PM To: "Thomas Weigert" , "Branislav Selic" , "Karl Frank" cc: , "MOF UML Infrastructure FTF" , Subject: [mu2i] Issue 7343 Inconsistency between Infra and Super on parameter direction Thomas, I tried to track down discussion related to 'pushback from the infrastructure team' on the issue but failed, and I don't recall it being discussed on an Infra call. I assume you mean Issue 7343 which you raised on Infra. So though you may have had a response from one or more individuals I do not recall any team view being elaborated. Perhaps Thomas or my fellow Infra members could point me at the thread or summarize their arguments? FWIW here are my thoughts: a) I agree that the inconsistency is undesirable b) A further issue is the relationship between the inherited Operation.type and the set of returnParameters c) It is desirable for Operations to have a type and be included in expressions (e.g. in OCL) and composed. d) DirectionKind for parameters was in MOF 1.4 so for compatibility it does not seem to be a bad idea e) Any restrictions on values for DirectionKind would be imposed by MOF not by Infra: we have precedence for this -------------------------------------------------------------------------------- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: Friday, July 23, 2004 11:30 AM To: Branislav Selic; Karl Frank Cc: uml2-superstructure-ftf@omg.org Subject: RE: Resolution for ballot 20: issue 7135 The infrastructure treats parameters different from the superstructure. I have proposed a resolution that would solve that problem but have received pushback from the infrastructure team on not wanting to make changes. I have not carefully examined the solution discussed below, but I think that our solutions overlap, and thus you will run into the same objections. Due to the need to run the resolution through both teams I was planning to defer my issue, but if you think that you will have more luck, we should combine our resolutions. Th. From: "Stephen Brodsky" To: "Thomas Weigert" Cc: "Branislav Selic" , , Subject: Re: ,cb cs, Proposed issues for 15 Date: Tue, 18 May 2004 17:26:37 -0500 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00C8_01C475B1.1271B700" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 X-Originating-IP: [144.189.100.103] X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 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 Importance: Normal 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 :wq vi issue7597