Issue 4569: Modeling OCL Helper Functions (mof-rtf) Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com) Nature: Enhancement Severity: Minor Summary: Many metamodels including the MOF Model (see 3.9.6) have 'OCL Helper' operations which are purely for the purpose of factoring the OCL constraints, and are not intended to be part of the 'external' model (e.g. to be represented in IDL). There seems to be no way of representing these in the MOF Model: and indeed the OCL Helper functions in MOF Specification do not appear in the XMI file, making it somewhat incomplete as a normative definition and meaning that many of the OCL constraints could not be executed by an OCL engine. This applies not only to MOF but to other metamodels. Resolution: Revised Text: Actions taken: September 16, 2001: received issue Discussion: End of Annotations:===== From: webmaster@omg.org Message-Id: <200109162316.f8GNGS323665@emerald.omg.org> Date: 16 Sep 2001 19:20:29 -0400 To: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Subject: Issue/Bug Report Content-Type: Text/html; charset=windows-1252 X-UIDL: ~;id9_)fd9B~F!!DLNe9 Name: Pete Rivett Company: Adaptive mailFrom: pete.rovett@adaptive.com Notification: Yes Specification: MOF Section: 3.9.6 FormalNumber: ptc/01-08-22 Version: 1.4 RevisionDate: 08/10/01 Page: various Nature: Enhancement Severity: Minor HTTP User Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0) Description Modeling OCL Helper Functions Many metamodels including the MOF Model (see 3.9.6) have 'OCL Helper' operations which are purely for the purpose of factoring the OCL constraints, and are not intended to be part of the 'external' model (e.g. to be represented in IDL). There seems to be no way of representing these in the MOF Model: and indeed the OCL Helper functions in MOF Specification do not appear in the XMI file, making it somewhat incomplete as a normative definition and meaning that many of the OCL constraints could not be executed by an OCL engine. This applies not only to MOF but to other metamodels. From: "Bast, Wim" To: "'mof-rtf@omg.org'" Subject: issue 4569 -- MOF RTF issue Date: Tue, 19 Feb 2002 17:01:06 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: \g6e9/fHe9ih2!!bGid9 This is a proposal for a solution for Issue 4569. ---------------------------------------------------------------------------- ------------ Issue 4569: Modeling OCL Helper Functions Problem: Many metamodels including the MOF model have 'Helper' operations which are purely for the purpose of factoring the OCL constraints, and are not intended to be part of the 'external' visible model (e.g. to be represented in IDL). The only place for adding expressions is in the Constraints class, and a Constraint is currently used for defining an 'invariant'. This seems to be the reason why for example the helper functions of the MOF-model constraints are not represented in the metamodel of MOF itself. This is an unwanted situation because the normative specification is incomplete without a formalized notion (e.g. in XMI) of all the constraints. Furthermore it can be useful for MOF implementations to implement the constraints based on the formal definition Solution: * Add helper functions with protected visibility Helper functions are added to the (mof.dtd compliant) XMI specifications in the same way as any other (visible) operation, with the 'visibility' attribute set to 'protected'. This implies that they will not be visible in IDL (according to the MOF1.4 IDL mapping). TODO: Have to check visibility management in JMI! * Use the Constraint class for defining semantic specifications This is actually a natural choice which is also made in UML. The semantic specifications (for example in OCL) of the operations, helper functions, derived attributes and derived associations can be added to the (mof.dtd compliant) XMI specifications in the same way as the (invariant) model constraints. Changes to MOF 1.4 specification: * Model definition Describe that it is possible to use the Constraint class for adding pre and post conditions to metamodel specifications. State that the evaluationPolicy should always be set to 'immediate' for those kind of Constraints. When using OCL for defining the constraint, start the expression with the prefix "post:" and/or "pre:" instead of "inv:". * XMI, IDL and JMI Mappings No changes * The XMI rendering of the MOF model Add the following to the XMI that defines the MOF model: - All the OCL helper functions as operations with visibility set to "protected". - All semantic specifications in OCL ait; see Section 3.6.3, functions which one might want to invoke from constraints on metaclasses which are not direct subclasses of that on which the operation is defined. e.g. one might want a helper function Class.allFeatures() which one might want to use in a constraint applied to Feature. This would not be allowed since Feature does not inherit from Class. f) While we're at it we should get our act together on the 'language' attribute for OCL, which is Issue 4568 the text for which is as follows. I suggest we just replace "MOF-OCL" with "OCL" in the spec and postpone the more extensive changes. 4568: The MOF XMI file uses 'OCL' for the language of the constraints, whereas the last paragraph of section 3.9.2.1 says that 'MOF-OCL' should be used [due to the minor variations from UML's OCL which are enumerated in 3.9.3]. The description of the Constraint class in 3.4.27 should refer to how constraints are expressed for the MOF Model itself in 3.9.3 (using MOF-OCL). Though it should not be mandatory to use MOF-OCL, user-defined metamodels have the same requirements for constraint expression as the MOF Model and so the variant and usage of OCL is just as appropriate and necessary. Indeed it would be a lot more sensible to pull 3.9.3 out into a separate section since it applies to constraints in any MOF metamodel not just the MOF Model. NB This also needs to be reflected in the UML Profile for MOF. g) We should consider how people might populate the semantics information. The following is from the UML Profile for MOF (3.7.4), which seems wrong to me: "Unlike a MOF Operation, a UML Operation cannot contain a Constraint. Therefore the profile does not support an Operation containing a Constraint." UML allows pre- and post-conditions (via stereotypes) so why not use that? Pete Pete Rivett (pete.rivett@adaptive.com) Chief Technology Officer, Adaptive Ltd 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 > -----Original Message----- > From: Bast, Wim [mailto:Wim.Bast@nl.compuware.com] > Sent: 19 February 2002 16:01 > To: 'mof-rtf@omg.org' > Subject: issue 4569 -- MOF RTF issue > > > This is a proposal for a solution for Issue 4569. > > -------------------------------------------------------------- > -------------- > ------------ > > Issue 4569: Modeling OCL Helper Functions > > Problem: > > Many metamodels including the MOF model have 'Helper' > operations which are > purely for the purpose of factoring the OCL constraints, and are not > intended to be part of the 'external' visible model (e.g. to > be represented > in IDL). > > The only place for adding expressions is in the Constraints > class, and a > Constraint is currently used for defining an 'invariant'. > This seems to be > the reason why for example the helper functions of the > MOF-model constraints > are not represented in the metamodel of MOF itself. > > This is an unwanted situation because the normative specification is > incomplete without a formalized notion (e.g. in XMI) of all > the constraints. > Furthermore it can be useful for MOF implementations to implement the > constraints based on the formal definition > > Solution: > > * Add helper functions with protected visibility > Helper functions are added to the (mof.dtd compliant) XMI > specifications in > the same way as any other (visible) operation, with the 'visibility' > attribute set to 'protected'. This implies that they will not > be visible in > IDL (according to the MOF1.4 IDL mapping). TODO: Have to > check visibility > management in JMI! > > * Use the Constraint class for defining semantic specifications > This is actually a natural choice which is also made in UML. > The semantic > specifications (for example in OCL) of the operations, helper > functions, > derived attributes and derived associations can be added to > the (mof.dtd > compliant) XMI specifications in the same way as the (invariant) model > constraints. > > Changes to MOF 1.4 specification: > * Model definition > Describe that it is possible to use the Constraint class for > adding pre and > post conditions to metamodel specifications. > State that the evaluationPolicy should always be set to > 'immediate' for > those kind of Constraints. > When using OCL for defining the constraint, start the > expression with the > prefix "post:" and/or "pre:" instead of "inv:". > > * XMI, IDL and JMI Mappings > No changes > > * The XMI rendering of the MOF model > Add the following to the XMI that defines the MOF model: > - All the OCL helper functions as operations with visibility set to > "protected". > - All semantic specifications in OCL as Constraints with the > prefix "post:". > > -------------------------------------------------------------- > -------------- > ---------- > > Wim Bast > Compuware Corporation > > The information contained in this email and any attached files are confidential and intended solely for the addressee(s). The e-mail may be legally privileged or prohibited from disclosure and unauthorised use. If you are not the named addressee you may not use, copy or disclose this information to any other person. If you received this message in error please notify the sender immediately. Any views or opinions presented here may be solely those of the originator and do not necessarily reflect those of the Company. s Constraints with the prefix "post:". ---------------------------------------------------------------------------- ---------- Wim Bast Compuware Corporation From: "Pete Rivett" To: "'Bast, Wim'" Cc: Subject: RE: issue 4569 -- MOF RTF issue Date: Tue, 19 Feb 2002 21:07:15 -0000 Message-ID: <005c01c1b989$68bc6600$114c04c8@CHIMAY> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Content-Type: text/plain; charset="iso-8859-1" X-UIDL: DbBe9;Ri!!FZ+!!ae+e9 Hi Wim, This is a good start but there's a way to go yet... a) I think we need a better way of modeling the difference between pre- and post- conditions than the language-specific mechanism of inspecting the OCL body looking for 'post:' or 'pre:'. For example there could be a separate reference for each or a pre-defined tag applied to the Constraint (UML uses stereotypes <> and <>). b) We should be clear that a Constraint is attached to an Operation via the 'constrainedElement' reference and it does not matter whether the Constraint is owned by the Operation, the Class or something else. c) We need to consider the semantics of more than one pre- or post- condition Constraint being attached to the same Operation (we could either disallow this or specify that they're to be considered 'ANDed' together). And, for good measure, we should specifically say whether any invariants (or just immediate ones?) are implicitly ANDed into the pre- and post- conditions. d) The use of 'protected', or any visibility, requires further changes to the MOF spec, for example: - 3.2.1.6 para 2 "All operations for Classes in the MOF Model have visibility of public_vis" - 3.4.1 definition of which, isVisible on page 3-102. The rules of visibility of MOF ModelElements are not currently specified." - 3.4.14 ditto (for Feature - most relevant for Operations) - 3.4.24 ditto (for Import) - 3.6.3 States "Note The rules governing visibility of ModelElements in the MOF are yet to be specified. As an interim measure, all ModelElements are deemed to be visible, irrespective of the currently states: "Returns true. This operation is reserved for future use when the MOF rules visibility attribute settings." e) Protected visibility is defined as "allows use of the ModelElement within containers that inherit from this one have stabilized. Then it will determine whether the supplied otherElement is visible to this ModelElement." - 3.4.3 definition of visibility (for GeneralizableElement), which states: "In the future, this Attribute will be used to limit the ability of ModelElements outside of this GeneralizableElement From: "Wim Bast" To: References: Subject: Follow-up: issue 4569 -- MOF RTF issue Date: Thu, 21 Feb 2002 11:14:06 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Content-Type: text/plain; charset="iso-8859-1" X-UIDL: /~Q!!_VU!!