Issue 6442: Specification of parametric models (uml2-superstructure-ftf) Source: Pivot Point (Mr. Cris Kobryn, ) Nature: Uncategorized Issue Severity: Summary: Description: It is unclear how to specify parametric models as they are used in systems engineering. In particular, it is unclear how to specify mathematical or logical equations (e.g., Force = mass * acceleration) that constrain the values of classifier attributes/properties. Systems engineers must be able to: a) Specify the dependencies between parameters and expressions or constraints. This must support arbitrarily complex and continuous time equations. b) Allow parameters to be passed into expressions. Resolution: Revised Text: Actions taken: November 6, 2003: received issue March 9, 2005: closed issue Discussion: To enable writing mathematical formulas for constraints, UML 2 provides the option to write constraints in languages othe r than UML and OCL and include the result in a UML 2 model as an Expression and/or OpaqueExpression, which are then referenced as the body of a UML 2 Constraint. Expressions and OpaqueExpression are the model elements provided for such purposes. For this reason, they are provided with an attribute to indicate their language. The Issue is correct in noting that UML 2 itself does not include the language of applied mathematics. UML 2 does permit reuse of the same mathematical expression in more than one constraint, and allows the choice of a language other than UML. Users of UML 2 are advised to choose whatever constraint langugage best meets their special requirements. A detailed review of the relevant parts of UML 2 are as follows: 7.6.1 Constraint states A user-defined Constraint is described using a specified language, whose syntax and interpretation is a tool responsibility. The Associations of Constraint include its specification, which is a ValueSpecification[0..1] ValueSpecification is an abstract named and typed model element, with concrete subclasses Expression and OpaqueExpression. OpaqueExpression (7.5.2) has attributes body (a mandatory string) and an optional attribute to indicate the language of the string. The same expression or opaqueExpression instance can be used as the ValueSpecification for any number of constraints. These are the means provided by UML 2 to specify parametric mathematical models as a constraint, and to re-use the same mathematical expressions in as many constraints as one wishes. It is not appropriate to defer this issue to another revision of UML, because it is not within the intended scope of UML to reproduce or replace the familiar notations of mathematical physics and various mechanical and electronic engineering disciplines. sysML can identify a branch of mathematics as the default language for constraints, and can extend the metamodel such that a new subtype of constraint is recognized which uses such language by default. A suitable choice of a mathematical constraint language, other than OCL, is recommended to submitters responding to the sysML RFP Disposition: Closed, no change End of Annotations:===== eference: UML 2 Superstructure, OMG doc# ptc/03-08-02 Issue: Specification of parametric models Description: It is unclear how to specify parametric models as they are used in systems engineering. In particular, it is unclear how to specify mathematical or logical equations (e.g., Force = mass * acceleration) that constrain the values of classifier attributes/properties. Systems engineers must be able to: a) Specify the dependencies between parameters and expressions or constraints. This must support arbitrarily complex and continuous time equations. Issue 6442: Specification of parametric models (uml2-superstructure-ftf Source: Telelogic AB (Mr. Cris Kobryn, cris.kobryn@telelogic.com) Nature: Uncategorized Issue Severity: Summary: Description: It is unclear how to specify parametric models as they are used in systems engineering. In particular, it is unclear how to specify mathematical or logical equations (e.g., Force = mass * acceleration) that constrain the values of classifier attributes/properties. Systems engineers must be able to: a) Specify the dependencies between parameters and expressions or constraints. This must support arbitrarily complex and continuous time equations. b) Allow parameters to be passed into expressions. Discussion: 7.6.1 Constraint states A user-defined Constraint is described using a specified language, whose syntax and interpretation is a tool responsibility. The Associations of Constraint include its specification, which is a ValueSpecification[0..1] ValueSpecification has subclasses Expression and OpaqueExpression. OpaqueExpression (7.5.2) has attributes body (a mandatory string) and an optional attribute to indicate the language of the string. These are the means provided by UML 2 to specify parametric mathematical models. Resolution: Closed, no change. Revised Text: N/A Actions taken: November 6, 2003: received issue \ Reply-To: From: "Conrad Bock" To: Subject: RE: Draft of ballot 13 Date: Thu, 29 Apr 2004 13:18:18 -0400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Hi Karl, Just checking, have these been posted before? Ballot 13 starts tomorrow, I think. Other comments below. Conrad - Issue 6437: targetScope on StructuralFeature and AssociationEnd isStatic is the UML 2 version of ownerScope, rather than targetScope. - Issue 6442: Specification of parametric models This issue is mainly in item "b". Constraints and OCL in particular cannot be reused in the way behavior's can, ie, they aren't parameterized. If there is a way to have a generic constraint that is reused in multiple places (including other Issue 6442:Specification of Parametric Models Source: Telelogic AB (Mr. Cris Kobryn, cris.kobryn@telelogic.com) Nature: Uncategorized Issue Severity: Summary: Description: It is unclear how to specify parametric models as they are used in systems engineering. In particular, it is unclear how to specify mathematical or logical equations (e.g., Force = mass acceleration) that constrain the values of classifier attributes/properties. Systems engineers must be able to: a) Specify the dependencies between parameters and expressions or constraints. This must support arbitrarily complex and continuous time equations. b) Allow parameters to be passed into expressions. Discussion: To enable writing mathematical formulas for constraints, UML 2 provides the option to write constraints in languages other than UML and OCL and include the result in a UML 2 model as an Expression and/or OpaqueExpression, which are then referenced as the body of a UML 2 Constraint. Expressions and OpaqueExpression are the model elements provided for such purposes. For this reason, they are provided with an attribute to indicate their language. The Issue is correct in noting that UML 2 itself does not include the language of applied mathematics. UML 2 does permit reuse of the same mathematical expression in more than one constraint, and allows the choice of a language other than UML. Users of UML 2 are advised to choose whatever constraint langugage best meets their special requirements. A detailed review of the relevant parts of UML 2 are as follows: 7.6.1 Constraint states A user-defined Constraint is described using a specified language, whose syntax and interpretation is a tool responsibility. The Associations of Constraint include its specification, which is a ValueSpecification[0..1] ValueSpecification is an abstract named and typed model element, with concrete subclasses Expression and OpaqueExpression. OpaqueExpression (7.5.2) has attributes body (a mandatory string) and an optional attribute to indicate the language of the string. The same expression or opaqueExpression instance can be used as the ValueSpecification for any number of constraints. These are the means provided by UML 2 to specify parametric mathematical models as a constraint, and to re-use the same mathematical expressions in as many constraints as one wishes. It is not appropriate to defer this issue to another revision of UML, because it is not within the intended scope of UML to reproduce or replace the familiar notations of mathematical physics and various mechanical and electronic engineering disciplines. sysML can identify a branch of mathematics as the default language for constraints, and can extend the metamodel such that a new subtype of constraint is recognized which uses such language by default. Resolution: Closed, no change. A suitable choice of a mathematical constraint language, other than OCL, is recommended to submitters responding to the sysML RFP Revised Text: N/A Actions taken: November 6, 2003: received issue constraints), I'd be interested to hear. Deferral seems From: "Moore, Alan" To: "'Branislav Selic'" , Karl Frank Cc: Joaquin Miller , Thomas Weigert , uml2-superstructure-ftf@omg.org Subject: RE: One more proposed resolution for ballot 14 from Karl Date: Mon, 17 May 2004 13:48:36 +0100 X-Mailer: Internet Mail Service (5.5.2653.19) It seems that Karl's solution is to leave any major work in the area of parametric models to SysML, which seems eminently reasonable. In terms of what is available in UML for handling parametric constraints, I concur with Karl, although my reading of Fig 14 is that a ValueSpecification may be part of only one Constraint, rather than being reusable. Regards, Alan. -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: 11 May 2004 23:03 To: Karl Frank; Moore, Alan Cc: Joaquin Miller; Thomas Weigert; uml2-superstructure-ftf@omg.org Subject: RE: One more proposed resolution for ballot 14 from Karl Hi Karl (and Alan), I have a few comments (nothing serious): Issue 3783: (I see nothing wrong with using the term "in a sense" in the description part of the spec -- but let's leave it as is. I am not sure that using the term "contract" to define an interface is really helpful. I can think of several ways in which that term can be interpreted -- it's not a formally defined term in UML. Again, this is a nitpick and I am not asking that something be done about it. Lastly, I suggest replacing the word "coherent" by the word "related". The former is actually a good word, but most people I think will not know what it means (the opposite of "incoherent"?) since the intended meaning is not common usage in American English. Issue 5978: I think there should be at least 1 example figure showing the "unfilled" diamond. BTW, I prefer "unfilled" to "open" and suggest it be used instead. "Open" to me sounds like one of the sides of the diamond is missing. Issue 6160: The first sentence refers to issue 6160 -- it should be 6170. Issue 6218: Please specify more precisely which text is being removed (i.e., which pages, paragraphs, figure numbers, etc.). As it stands, it is not clear and it can easily be misinterpreted. (As an editor, I would really appreciate it.) Issue 6437: I recall that Conrad had some comment about there being a difference between "ownerScope" and "targetScope" -- is that not an issue? Issue 6442: Please draw the attention of Alan Moore to this particular solution -- I believe that he is working on the SysML model of what they call "parametrization" and he may have some feedback on your resolution. I have copied Alan on this e-mail just in case. Also, I am not sure what I am supposed to do with the sentence following the "closed, no change" resolution -- this field of a resolution should not contain any other text. Please either remove it or put it somewhere in the resolution or discussion. Issue 6509: this looks like a Duplicate of 6507 to me. Your choice whether you want to deal with it as a duplicate or as a closed no change. The usual convention is to deal with it as a duplicate (it gives us a bit more precise statistics at the end). Cheers, Bran "Karl Frank" 05/09/2004 09:49 PM To "Thomas Weigert" , Branislav Selic/Ottawa/IBM@IBMCA, "Joaquin Miller" cc Subject RE: One more proposed resolution for ballot 14 from Karl Yet another rewrite. The last one I sent had the new language in one place, but not in all places where it was needed. The attached file is complete in itself, including the 8 prior proposals, plus this newly reworked one, and hence is labeled 9_Ballot14 etc. From: Karl Frank [mailto:Karl.Frank@borland.com] Sent: Sunday, 09 May, 2004 9:56 AM To: Thomas Weigert; Branislav Selic Cc: uml2-superstructure-ftf@omg.org Subject: RE: One more proposed resolution for ballot 14 from Karl Thoma, I agree with your proposal, which you formulated as follows, because it removes the ambiguous scope of the "must", making it clear that the "must" does not say that an interface must have instances of classifiers, etc. So I will rewrite my proposal with your language at that point. Thomas wrote: "An interface specifies a contract; any instance of a classifier that realizes the interface must fulfill that contract " is pretty much what we had in the original text? It is better than the original because it removes the ambiguity. - Karl -------------------------------------------------------------------------------- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: Saturday, 08 May, 2004 6:25 PM To: Branislav Selic; Thomas Weigert Cc: Karl Frank; uml2-superstructure-ftf@omg.org Subject: RE: One more proposed resolution for ballot 14 from Karl Just to clarify... I am opposed to the change indicated by (1) in Karl's proposal as it makes unclear what was clear in the original text. Regarding the "realizes" I think we should look for other occurrences and replace them by implement where appropriate, consistently with Bran's other issue resolution. Th. -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Saturday, May 08, 2004 4:47 PM To: Thomas Weigert Cc: Karl Frank; uml2-superstructure-ftf@omg.org Subject: RE: One more proposed resolution for ballot 14 from Karl Please note that I have submitted a resolution that deals with the "implements" versus "realizes" difference. I believe it is compatible with karl's resolution, but I think it is useful to draw people's attention to this. I like Karl's fixes, but prefer the term "must" to "can only" because I think the latter is too restrictive. I have no idea what else can "fulfill" an interface, but I don't want to prejudge that. I agree with Thomas' suggestion that the word "specification" should be omitted -- it adds nothing since an Interface is already a specification. The phrase "realizes an interface" may indeed be around in other places, but I think that Karl's refinement is a good one. regards, Bran "Thomas Weigert" 05/08/2004 03:42 PM To "Karl Frank" , Branislav Selic/Ottawa/IBM@IBMCA cc Subject RE: One more proposed resolution for ballot 14 from Karl Karl, regarding your proposed clarifications: 1. The original text was clear and unambiguous. Your proposed change makes it more fuzzy. I suggest you do not make this change. If you have an interface on a classifier, the contract MUST be fulfilled by all instances of that classifier. 2. Good. But as long as we are word-smithing, you should drop "specification" from the sentence. It is not the interface specification that is realized, but the interface. 3. The term "realizes an interface" might occur at other places in the specification. We should scour the text for this. Th. -----Original Message----- From: Karl Frank [mailto:Karl.Frank@borland.com] Sent: Saturday, May 08, 2004 2:08 PM To: Branislav Selic Cc: uml2-superstructure-ftf@omg.org Subject: One more proposed resolution for ballot 14 from Karl This one is in a file by itself, consider it as one to add to the 8 others for Classes. Joaquin, this is an issue you submitted, so pay special attention. Sorry the filename does not mean I have 3783 resolutions proposed. - Karl [attachment "9_Ballot14ClassesResolutions.doc" deleted by Branislav Selic/Ottawa/IBM] b) Allow parameters to be passed into expressions