Issue 16936: need clear specification for how to write OCL that refers to the stereotypes applied to a model within a UML profile (ocl2-rtf) Source: Model Driven Solutions (Dr. Edward Willink, ed(at)willink.me.uk) Nature: Uncategorized Issue Severity: Summary: Yet another query on an Eclipse newsgroup has asked how stereotypes/profiles work in a transformation language, so I've taken a brief look and it appears that UML 2.5 Section 12 appears gives the only clue as to how an OCL expression might navigate a Stereotype: self.base_Interface.ownedAttributes->size() = 0 This is a particularly unfortunate example since it uses reflection, or at least multiple meta-levels, which are not currently supported in OCL 2.x. Once OCL supports reflection and type literals, I would expect to see something more like Interface.ownedAttribute->size() = 0 The constraint presumably is that the stereotype has no attributes, regardless of the class to which it is applied. Reflective operation might do something like self.oclType().selectFragment(Interface).ownedAttribute->size() = 0 (if selectFragment is an OCL library operation that selects a type merge contribution). The utility of the meta-level traversing 'base_xxxx' and 'extension_xxxx' seems very suspect. Does any tool support them? I know Eclipse UML2 has at least a 'base_xxxx' name, but I doubt that it is reflective. It's sole purpose seems to be to give me trouble with validation errors. ----------------- It seems to me that in the same way that (for base classes): A class C (with property c) may have base classes B1 (with properties b, b1) and B2 (with property b, b2) allowing implicit access such as aC.c, aC.b1, aC.b2, but requiring qualification for aC.B1::b and allowing redundant qualification for aC.B1::b1. then (for stereotypes): A Class C may have stereotypes S1 (with properties s, s1) and S2 (with properties s, s2) allowing implicit access such as aC.s1, aC.s2, but requiring qualification for aC.S1::s and allowing redundant qualification for aC.S1::s1. The implicit access is only permissible when it is statically known that the Stereotype has been applied, i.e for an expression whose context is the Stereotype. In more general contexts the Stereotype qualification may need a run-time check and an invalid result if the Stereotype has not been applied. Thus: not aC.S1::s1.oclIsInvalid() implies some-expression-when-S1::s-exists If property overloading is forbidden, but operation overloading permitted, in the above adding a property C::b, or S1::c or S2::b2 would be a static error since the added property overloads a property name already present in the extended class. Note that this is not in accord with the current OCL specification that motivates the introduction of qualification to support access to hidden property names, which UML prohibits. adding any operation in a stereotype is valid; it is either a new or overloaded operation. However two stereotypes contributing the same operation signature is a static error to be detected by the attempt to apply both stereotypes. Since the WFRs for the above belong in UML, presumably the above should be in the UML specification, and the OCL specification should just map the alternate navigation syntaxes appearing in the UML specification to appropriate Concrete and Abstract Syntax Expression elements. Resolution: There is a gaping chasm between UML and OCL with regard to how stereotype names are used. There is no example of any kind in the OCL specification that uses a stereotype. My current thinking is that most of the complexity vanishes if stereotypes are resolved by the metamodel loader so that for the purposes of OCL evaluation, the M2 properties of the stereotype become regular, although static, M1 properties. Prototyping in Eclipse OCL demonstrates that this works and avoids loss of static type information. The semantics of static properties is currently limited to intuitive extrapolation from the existence of the keyword in the concrete syntax. There is a lot of work to do here. Disposition: Deferred Revised Text: Actions taken: December 30, 2011: received issue Discussion: End of Annotations:===== M-Score: 0.00 X-CNFS-Analysis: v=2.0 cv=JPG5Qr2b c=1 sm=1 a=eW53zEZrsyElcQ0NK1QpqA==:17 a=M51pKum5684A:10 a=td8BlWK1vRMA:10 a=8nJEP1OIZ-IA:10 a=ML_o0QeUGd9o004jtyEA:9 a=wPNLvfGTeEIA:10 a=eW53zEZrsyElcQ0NK1QpqA==:117 Date: Fri, 30 Dec 2011 10:52:12 +0000 From: Ed Willink User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 To: "uml2-rtf@omg.org" Subject: UML 2.5 12.3 How is OCL used for Stereotypes? Hi Yet another query on an Eclipse newsgroup has asked how stereotypes/profiles work in a transformation language, so I've taken a brief look and it appears that UML 2.5 Section 12 appears gives the only clue as to how an OCL expression might navigate a Stereotype: self.base_Interface.ownedAttributes->size() = 0 This is a particularly unfortunate example since it uses reflection, or at least multiple meta-levels, which are not currently supported in OCL 2.x. Once OCL supports reflection and type literals, I would expect to see something more like Interface.ownedAttribute->size() = 0 The constraint presumably is that the stereotype has no attributes, regardless of the class to which it is applied. Reflective operation might do something like self.oclType().selectFragment(Interface).ownedAttribute->size() = 0 (if selectFragment is an OCL library operation that selects a type merge contribution). The utility of the meta-level traversing 'base_xxxx' and 'extension_xxxx' seems very suspect. Does any tool support them? I know Eclipse UML2 has at least a 'base_xxxx' name, but I doubt that it is reflective. It's sole purpose seems to be to give me trouble with validation errors. ----------------- It seems to me that in the same way that (for base classes): A class C (with property c) may have base classes B1 (with properties b, b1) and B2 (with property b, b2) allowing implicit access such as aC.c, aC.b1, aC.b2, but requiring qualification for aC.B1::b and allowing redundant qualification for aC.B1::b1. then (for stereotypes): A Class C may have stereotypes S1 (with properties s, s1) and S2 (with properties s, s2) allowing implicit access such as aC.s1, aC.s2, but requiring qualification for aC.S1::s and allowing redundant qualification for aC.S1::s1. The implicit access is only permissible when it is statically known that the Stereotype has been applied, i.e for an expression whose context is the Stereotype. In more general contexts the Stereotype qualification may need a run-time check and an invalid result if the Stereotype has not been applied. Thus: not aC.S1::s1.oclIsInvalid() implies some-expression-when-S1::s-exists If property overloading is forbidden, but operation overloading permitted, in the above adding a property C::b, or S1::c or S2::b2 would be a static error since the added property overloads a property name already present in the extended class. Note that this is not in accord with the current OCL specification that motivates the introduction of qualification to support access to hidden property names, which UML prohibits. adding any operation in a stereotype is valid; it is either a new or overloaded operation. However two stereotypes contributing the same operation signature is a static error to be detected by the attempt to apply both stereotypes. Since the WFRs for the above belong in UML, presumably the above should be in the UML specification, and the OCL specification should just map the alternate navigation syntaxes appearing in the UML specification to appropriate Concrete and Abstract Syntax Expression elements. Regards DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=0rMUR8FRU3sWRkz4X+d4JRmwb9oKjU1xzXlI7RjNK9U=; b=juShUJvSqFKLQ2t8YiAmsmDx/mStXjzEKADZK3zVp4iMge86h5UjkcRNeOrZygiFi0 sa5otaoU3Ej04Wk83VQGNFQP7pGiSD7ZQWcUHCmqsWpWEwQF27j/JDENz7K0MYT+lsSI TaHMUpm7yUOrDo5brjytlBLFaPmwPaBvdVpb8= Sender: bran.selic@gmail.com From: Bran Selic Date: Fri, 30 Dec 2011 12:09:37 -0500 X-Google-Sender-Auth: -ezuyE3HiraApi-aSWo2su0PGJM Subject: Re: UML 2.5 12.3 How is OCL used for Stereotypes? To: Ed Willink Cc: "uml2-rtf@omg.org" Thanks, Ed. A few comments/questions below: On Fri, Dec 30, 2011 at 5:52 AM, Ed Willink wrote: Hi Yet another query on an Eclipse newsgroup has asked how stereotypes/profiles work in a transformation language, so I've taken a brief look and it appears that UML 2.5 Section 12 appears gives the only clue as to how an OCL expression might navigate a Stereotype: self.base_Interface.ownedAttributes->size() = 0 This is a particularly unfortunate example since it uses reflection, or at least multiple meta-levels, which are not currently supported in OCL 2.x. [bvs] Can you please elaborate why this is an issue? Meta-levels are merely an orientation device to help us be more precise in discussions when necessary. That is, there is no formal meta-level concept of a meta-level in either MOF or UML. Stereotypes are model elements that are syntactically no different than any other M1 elements, except that they are intended to be treated as being "stand ins" for corresponding virtual MOF entities. However, this does not change the fact that they are M1. Therefore, I don't understand why the expression above is problematic. [bvs] I believe that at least RSA tools support the above usage form. Cheers...Bran X-CM-Score: 0.00 X-CNFS-Analysis: v=2.0 cv=JPG5Qr2b c=1 sm=1 a=eW53zEZrsyElcQ0NK1QpqA==:17 a=M51pKum5684A:10 a=b3taTnZFt7oA:10 a=8nJEP1OIZ-IA:10 a=pGLkceISAAAA:8 a=YYzpnO7rAAAA:8 a=oCcaPWc0AAAA:8 a=jc_qI33gpL1yfeIXeUEA:9 a=_kvHa3yWtdy2TdHwLdQA:7 a=wPNLvfGTeEIA:10 a=eW53zEZrsyElcQ0NK1QpqA==:117 Date: Fri, 30 Dec 2011 18:09:46 +0000 From: Ed Willink User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 To: Bran Selic CC: "uml2-rtf@omg.org" Subject: Re: UML 2.5 12.3 How is OCL used for Stereotypes? Hi Bran Perhaps one of us misunderstands self.base_Interface.ownedAttributes->size() = 0 I consider 'self' to be an instance of Home, and ownedAttributes() to be a typo for the Class::ownedAttribute() operation which is a class rather than instance operation and so base_Interface is a meta-level traversal from the instance of Home to the Home/Interface type. (In the context of RSA, ownedAttributes might be correct since the default settings for UML to Ecore conversion are to pluralize collection properties.) Simple OCL operates at a single meta-level; using instances of user-defined types and OCL values. As currently specified, OCL does not support more than this. For instance the type argument for oclIsKindOf() is obviously a Type or Element literal but the OCL grammar and AST has no type or element literal. The signature of oclType() has changed in every version of the OCL specification as the seemingly misguided attempts to use an 'open' enumeration rather than reflection have unravelled. My attempts to model the OCL Standard Library for OCL 2.4/2.5 do not tolerate convenient vagueness. Defining oclType() as a fully reflective operation as a templated type-safe form of Java's getClass() looks to provide a sound powerful solution. I am keen to avoid additional primary mechanisms for traversing between the instance level and the type level. RSA 8, which I think is Eclipse OCL 3.0, may support base_xxx, but the old Eclipse OCL implementation is Ecore based and so as soon as you change meta-levels you find EClass rather than Class. The UML support has some wierd M1/M2 option that I really do not understand; perhaps this creates the illusion that something works, but I would be really surprised if it stands up to pedantic examination. The new Eclipse OCL protoyping OCL 2.4/2.5 currently has a UML 2.2 Basic-inspired self-defining pivot model so that the type of an element is generally an OCL::Type and the type of an OCL::Type is also an OCL::Type. I'm currently preparing the UML 2.5 to OCL Pivot QVTo transformation to replace inspired by aligned. NB OCL has to restructure since once you start adding operations to primitive types, it is impossible to tell the different between a Type, Classifier or Class, so the three UML types merge into the one OCL::Type. Regards Ed Willink On 30/12/2011 17:09, Bran Selic wrote: Thanks, Ed. A few comments/questions below: On Fri, Dec 30, 2011 at 5:52 AM, Ed Willink wrote: Hi Yet another query on an Eclipse newsgroup has asked how stereotypes/profiles work in a transformation language, so I've taken a brief look and it appears that UML 2.5 Section 12 appears gives the only clue as to how an OCL expression might navigate a Stereotype: self.base_Interface.ownedAttributes->size() = 0 This is a particularly unfortunate example since it uses reflection, or at least multiple meta-levels, which are not currently supported in OCL 2.x. [bvs] Can you please elaborate why this is an issue? Meta-levels are merely an orientation device to help us be more precise in discussions when necessary. That is, there is no formal meta-level concept of a meta-level in either MOF or UML. Stereotypes are model elements that are syntactically no different than any other M1 elements, except that they are intended to be treated as being "stand ins" for corresponding virtual MOF entities. However, this does not change the fact that they are M1. Therefore, I don't understand why the expression above is problematic. [bvs] I believe that at least RSA tools support the above usage form. Cheers...Bran No virus found in this message. Checked by AVG - www.avg.com Version: 2012.0.1901 / Virus Database: 2109/4711 - Release Date: 12/29/11 Date: Fri, 30 Dec 2011 10:12:11 -0800 Subject: Re: UML 2.5 12.3 How is OCL used for Stereotypes? Thread-Topic: UML 2.5 12.3 How is OCL used for Stereotypes? Thread-Index: AczHHo7U5gGXsMLtRQSzfb5uQ9QsrQ== From: "Pete Rivett" To: "Ed Willink" Cc: X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id pBUICPM3014108 Hi Ed, your reinterpretation of the constraint is wrong since the stereotype instance is a distinct object from the Interface instance. And the constraint is that the Interface to which this stereotype is applied should have no attributes. base_Interface is the property on the stereotype to navigate to the Interface instance and so is correctly used here. I agree with Bran that no meta-levels are involved: this is all M1 since we're constraining instances of the metaclass Interface (and instances of the stereotype). Pete Ed Willink wrote: Hi Yet another query on an Eclipse newsgroup has asked how stereotypes/profiles work in a transformation language, so I've taken a brief look and it appears that UML 2.5 Section 12 appears gives the only clue as to how an OCL expression might navigate a Stereotype: self.base_Interface.ownedAttributes->size() = 0 This is a particularly unfortunate example since it uses reflection, or at least multiple meta-levels, which are not currently supported in OCL 2.x. Once OCL supports reflection and type literals, I would expect to see something more like Interface.ownedAttribute->size() = 0 The constraint presumably is that the stereotype has no attributes, regardless of the class to which it is applied. Reflective operation might do something like self.oclType().selectFragment(Interface).ownedAttribute->size() = 0 (if selectFragment is an OCL library operation that selects a type merge contribution). The utility of the meta-level traversing 'base_xxxx' and 'extension_xxxx' seems very suspect. Does any tool support them? I know Eclipse UML2 has at least a 'base_xxxx' name, but I doubt that it is reflective. It's sole purpose seems to be to give me trouble with validation errors. ----------------- It seems to me that in the same way that (for base classes): A class C (with property c) may have base classes B1 (with properties b, b1) and B2 (with property b, b2) allowing implicit access such as aC.c, aC.b1, aC.b2, but requiring qualification for aC.B1::b and allowing redundant qualification for aC.B1::b1. then (for stereotypes): A Class C may have stereotypes S1 (with properties s, s1) and S2 (with properties s, s2) allowing implicit access such as aC.s1, aC.s2, but requiring qualification for aC.S1::s and allowing redundant qualification for aC.S1::s1. The implicit access is only permissible when it is statically known that the Stereotype has been applied, i.e for an expression whose context is the Stereotype. In more general contexts the Stereotype qualification may need a run-time check and an invalid result if the Stereotype has not been applied. Thus: not aC.S1::s1.oclIsInvalid() implies some-expression-when-S1::s-exists If property overloading is forbidden, but operation overloading permitted, in the above adding a property C::b, or S1::c or S2::b2 would be a static error since the added property overloads a property name already present in the extended class. Note that this is not in accord with the current OCL specification that motivates the introduction of qualification to support access to hidden property names, which UML prohibits. adding any operation in a stereotype is valid; it is either a new or overloaded operation. However two stereotypes contributing the same operation signature is a static error to be detected by the attempt to apply both stereotypes. Since the WFRs for the above belong in UML, presumably the above should be in the UML specification, and the OCL specification should just map the alternate navigation syntaxes appearing in the UML specification to appropriate Concrete and Abstract Syntax Expression elements. Regards Ed Willink DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=IqWiHfTVrD6MKlgKWhKh5yL1VsYpNIktF/rNH0va8/E=; b=qafRHKStTr6AGmMmpWuMiuzoCuOEgap2wXp0pMwc7RRR/WfizNqY9N/0mgH8vBULTK KAOjpwFyAaJ0R7IVjDLaWser1rcMGZwWxUD9klKTjxLTF9evX3ODlZjfG+GM0KX5JoRq /wkh1MvV6+rkYvkpL+g5SBxQEWObDU2hIakGM= Sender: bran.selic@gmail.com From: Bran Selic Date: Fri, 30 Dec 2011 14:01:14 -0500 X-Google-Sender-Auth: Ep4Mt8x0JvvWYaPd5NWtbF1cWJo Subject: Re: UML 2.5 12.3 How is OCL used for Stereotypes? To: Ed Willink Cc: "uml2-rtf@omg.org" Hi Ed, Feedback below prefixed by "[bvs]": On Fri, Dec 30, 2011 at 1:09 PM, Ed Willink wrote: Hi Bran Perhaps one of us misunderstands self.base_Interface.ownedAttributes->size() = 0 I consider 'self' to be an instance of Home, [bvs] Not exactly. There is no instance of Home. Instead, there is an instance of Stereotype with a link to the (meta)class that it extends. In this case, it points to Interface (since Home is a stereotype of Interface). Therefore, the expression "self.base_Interface" gets us to the Interface (meta)class. (NB: This assumes that the M2 model of UML is accessible -- whether it is physically present or merely implied, is a tool implementation issue.). So, the expression "self.base_Interface.ownedAttribute" will indeed be an operation on the Interface (meta)class, and the expression will indeed return the collection of attributes owned by the Interface class (modulo the incorrect spelling of the operation name that you pointed out -- please raise an issue on this with Juergen). Simple OCL operates at a single meta-level; [bvs] As I noted above, the assumption behind the expression is that the UML metamodel is "present"; that is, the M1 model and the M2 metamodel are simply combined into a single composite model, with all its nodes being instances of MOF::Class. Since there is no formal notion of meta-levels, the fact that some elements of this composite are M1 elements and others M2 is transparent. Cheers...Bran Date: Fri, 30 Dec 2011 11:23:50 -0800 Subject: Re: UML 2.5 12.3 How is OCL used for Stereotypes? Thread-Topic: UML 2.5 12.3 How is OCL used for Stereotypes? Thread-Index: AczHKrT5/cbt+kZxQ+OwousXV1xPIw== From: "Pete Rivett" To: "Bran Selic" Cc: "Ed Willink" , X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id pBUJdSFN028739 To clarify, this is all defined at the M2 level but only ever applied or executed at the M1 or model level. For example it is not testing whether the UML metaclass Interface has any attributes (which would be a bit pointless) but a specific instance of Interface which is linked to an instance of the Home stereotype. So I disagree with Bran that it needs access to the UML metamodel at all. Pete Bran Selic wrote: Hi Ed, Feedback below prefixed by "[bvs]": On Fri, Dec 30, 2011 at 1:09 PM, Ed Willink wrote: > Hi Bran > > Perhaps one of us misunderstands > > self.base_Interface.ownedAttributes->size() = 0 > > I consider 'self' to be an instance of Home, > [bvs] Not exactly. There is no instance of Home. Instead, there is an instance of Stereotype with a link to the (meta)class that it extends. In this case, it points to Interface (since Home is a stereotype of Interface). Therefore, the expression "self.base_Interface" gets us to the Interface (meta)class. (NB: This assumes that the M2 model of UML is accessible -- whether it is physically present or merely implied, is a tool implementation issue.). So, the expression "self.base_Interface.ownedAttribute" will indeed be an operation on the Interface (meta)class, and the expression will indeed return the collection of attributes owned by the Interface class (modulo the incorrect spelling of the operation name that you pointed out -- please raise an issue on this with Juergen). > > Simple OCL operates at a single meta-level; > [bvs] As I noted above, the assumption behind the expression is that the UML metamodel is "present"; that is, the M1 model and the M2 metamodel are simply combined into a single composite model, with all its nodes being instances of MOF::Class. Since there is no formal notion of meta-levels, the fact that some elements of this composite are M1 elements and others M2 is transparent. Cheers...Bran X-CM-Score: 0.00 X-CNFS-Analysis: v=2.0 cv=JPG5Qr2b c=1 sm=1 a=eW53zEZrsyElcQ0NK1QpqA==:17 a=M51pKum5684A:10 a=b3taTnZFt7oA:10 a=IkcTkHD0fZMA:10 a=N54-gffFAAAA:8 a=YYzpnO7rAAAA:8 a=oCcaPWc0AAAA:8 a=yn2L5TA1rWe-MIICbFsA:9 a=XfWyC_wCQ6_mCE55VPIA:7 a=QEXdDO2ut3YA:10 a=nAPXUAfsBmEA:10 a=eW53zEZrsyElcQ0NK1QpqA==:117 Date: Fri, 30 Dec 2011 21:04:40 +0000 From: Ed Willink User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 To: Pete Rivett CC: Bran Selic , uml2-rtf@omg.org Subject: Re: UML 2.5 12.3 How is OCL used for Stereotypes? Hi Pete, Bran I think I was right for the wrong reason when I wrote that self is an instance of Home (I was thinking of Home at M1 not M2). Writing the full Complete OCL package example context Home inv NoHomeInterfaceAttributes: self.base_Interface.ownedAttribute->size() = 0 endpackage self@M1 is an instance of Home@M2 which is an instance of Stereotype@M3. self.base_Interface@M1 is an instance of Interface@M2 which is an instance of Class@M3. So @M1 self.base_Interface.ownedAttribute uses Interface::ownedAttribute to enforce no attribute definition in the user-defined HomeInterface@M1 and no attribute slots in the user object @M0. OCL requires a type for self and Home seems correct. OCL requires access to the UML meta-model in order to validate and use Interface::ownedAttribute. "base_..." and "extension..." are just auto-generated names for artefacts not normally drawn with a relationship. This convention seems a little clumsy in comparison to OCL qualified names that could allow self.Interface::ownedAttribute which more clearly indicates a feature selection within a compound object rather than a cluster of objects. Neither form of navigation is actually correct since if Home is applied to any non-Interface type the consequent 0-multiplicity for self.base_Interface leads to invalid (OCL's NPE) for the the subsequent ownedAttribute navigation. So perhaps the correct OCL is context Home inv NoHomeInterfaceAttributes: let interface : Interface = self.base_Interface -- or just self.Interface in interface->notEmpty() implies interface.ownedAttribute->isEmpty() Regards Ed Willink On 30/12/2011 19:23, Pete Rivett wrote: To clarify, this is all defined at the M2 level but only ever applied or executed at the M1 or model level. For example it is not testing whether the UML metaclass Interface has any attributes (which would be a bit pointless) but a specific instance of Interface which is linked to an instance of the Home stereotype. So I disagree with Bran that it needs access to the UML metamodel at all. Pete Bran Selic wrote: Hi Ed, Feedback below prefixed by "[bvs]": On Fri, Dec 30, 2011 at 1:09 PM, Ed Willink wrote: Hi Bran Perhaps one of us misunderstands self.base_Interface.ownedAttributes->size() = 0 I consider 'self' to be an instance of Home, [bvs] Not exactly. There is no instance of Home. Instead, there is an instance of Stereotype with a link to the (meta)class that it extends. In this case, it points to Interface (since Home is a stereotype of Interface). Therefore, the expression "self.base_Interface" gets us to the Interface (meta)class. (NB: This assumes that the M2 model of UML is accessible -- whether it is physically present or merely implied, is a tool implementation issue.). So, the expression "self.base_Interface.ownedAttribute" will indeed be an operation on the Interface (meta)class, and the expression will indeed return the collection of attributes owned by the Interface class (modulo the incorrect spelling of the operation name that you pointed out -- please raise an issue on this with Juergen). Simple OCL operates at a single meta-level; [bvs] As I noted above, the assumption behind the expression is that the UML metamodel is "present"; that is, the M1 model and the M2 metamodel are simply combined into a single composite model, with all its nodes being instances of MOF::Class. Since there is no formal notion of meta-levels, the fact that some elements of this composite are M1 elements and others M2 is transparent. Cheers...Bran ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2012.0.1901 / Virus Database: 2109/4712 - Release Date: 12/30/11 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=V3ltvcrMvNvgqHXxInmU8vIX8gYx6CTzvNCxF+erAY4=; b=TlA6vcF3vGuPJUDcYiSz+cGKa5gJ2zw7YTEH3L8CcHswRgi137bsRGQzsVSidXeL0e Siu+CGO4bnStf6QGYAxMTTtV1QJvY+CT0o1bix1S8wbkmrt2BL8/LWyV+zq/OdzQB2wJ fu/VglYRNB8o3XrSlQTKPmhTjDAV3OlckImjw= Sender: bran.selic@gmail.com From: Bran Selic Date: Fri, 30 Dec 2011 17:16:54 -0500 X-Google-Sender-Auth: DYxnBMzxed6SwiZRsGAG8jW4oZA Subject: Re: UML 2.5 12.3 How is OCL used for Stereotypes? To: Pete Rivett Cc: Ed Willink , uml2-rtf@omg.org Pete is right. I mixed my M2s and M1s when I explained how the navigation works. The Stereotype instance in M1 is actually connected to an Interface instance (M1). However, the constraint is defined at M2 and, as usual, applies to corresponding M1 instances. Apologies for any confusion....Bran On Fri, Dec 30, 2011 at 2:23 PM, Pete Rivett wrote: To clarify, this is all defined at the M2 level but only ever applied or executed at the M1 or model level. For example it is not testing whether the UML metaclass Interface has any attributes (which would be a bit pointless) but a specific instance of Interface which is linked to an instance of the Home stereotype. So I disagree with Bran that it needs access to the UML metamodel at all. Pete Bran Selic wrote: Hi Ed, Feedback below prefixed by "[bvs]": On Fri, Dec 30, 2011 at 1:09 PM, Ed Willink wrote: > Hi Bran > > Perhaps one of us misunderstands > > self.base_Interface.ownedAttributes->size() = 0 > > I consider 'self' to be an instance of Home, > [bvs] Not exactly. There is no instance of Home. Instead, there is an instance of Stereotype with a link to the (meta)class that it extends. In this case, it points to Interface (since Home is a stereotype of Interface). Therefore, the expression "self.base_Interface" gets us to the Interface (meta)class. (NB: This assumes that the M2 model of UML is accessible -- whether it is physically present or merely implied, is a tool implementation issue.). So, the expression "self.base_Interface.ownedAttribute" will indeed be an operation on the Interface (meta)class, and the expression will indeed return the collection of attributes owned by the Interface class (modulo the incorrect spelling of the operation name that you pointed out -- please raise an issue on this with Juergen). > > Simple OCL operates at a single meta-level; > [bvs] As I noted above, the assumption behind the expression is that the UML metamodel is "present"; that is, the M1 model and the M2 metamodel are simply combined into a single composite model, with all its nodes being instances of MOF::Class. Since there is no formal notion of meta-levels, the fact that some elements of this composite are M1 elements and others M2 is transparent. Cheers...Bran From: "Bock, Conrad" To: Ed Willink , "uml2-rtf@omg.org" Date: Wed, 4 Jan 2012 10:12:28 -0500 Subject: RE: UML 2.5 12.3 How is OCL used for Stereotypes? Thread-Topic: UML 2.5 12.3 How is OCL used for Stereotypes? Thread-Index: AczHiaaWXAn3pYf8TKWQUq/KYbz/rADaYCDA Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Ed, > self@M1 is an instance of Home@M2 which is an instance of > Stereotype@M3. Stereotype is in the UML metamodel (M2). It's not in MOF, as I understand it. Conrad From: "Bock, Conrad" To: Ed Willink , "uml2-rtf@omg.org" Date: Wed, 4 Jan 2012 10:18:11 -0500 Subject: RE: UML 2.5 12.3 How is OCL used for Stereotypes? Thread-Topic: UML 2.5 12.3 How is OCL used for Stereotypes? Thread-Index: AczHiaaWXAn3pYf8TKWQUq/KYbz/rADaYCDA Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US P.S. Also, Home I assume is user-defined, so is at M1, even though conceptually they are extensions to metaclasses. (Thisslight of hand causes alot of problems, and was introduced for tools with fixed metaclasses (eg, implementations of metaclasses as database tables). My understanding it affects the interchange files, which need to treat them specially). Conrad Ed, > self@M1 is an instance of Home@M2 which is an instance of > Stereotype@M3. Stereotype is in the UML metamodel (M2). It's not in MOF, as I understand it. Conrad X-SpamScore: -10 X-BigFish: VS-10(zz9371Ic85fh1432N98dKzz1202hzz8275bh8275dh84d07hz2fh2a8h668h839h) X-Forefront-Antispam-Report: CIP:131.107.125.8;KIP:(null);UIP:(null);IPV:NLI;H:TK5EX14HUBC104.redmond.corp.microsoft.com;RD:none;EFVD:NLI X-FB-SS: 13, From: Steve Cook To: Bran Selic , Pete Rivett CC: Ed Willink , "uml2-rtf@omg.org" Subject: RE: UML 2.5 12.3 How is OCL used for Stereotypes? Thread-Topic: UML 2.5 12.3 How is OCL used for Stereotypes? Thread-Index: AczHKrT5xofwC5PkxU+0FiqI4bquUwAFgd0AAO0f7uA= Date: Wed, 4 Jan 2012 15:39:18 +0000 Accept-Language: en-GB, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.166.18.105] X-OriginatorOrg: microsoft.com For a material example: there is a constraint .initial_transition. on Transition that wants to specify that a particular stereotype applies under particular circumstances. The current constraint is wrong on numerous grounds, but contains the following subexpression: self.trigger.stereotype.name = 'create' I'm thinking the correct OCL for this ought to be the following: Stereotype.allInstances()->select( si | si.base_Trigger = self.trigger)->exists( si | si.name = .Create.) This would assume that the Create stereotype can validly apply to a Trigger, which it currently cannot, according to the standard profile. However I believe that any OCL typechecker will complain when it gets to si.base_Trigger, because the property base_Trigger is not defined on Stereotype (despite what it says in the Profiles chapter of UML, with the example self.base_Interface.ownedAttributes->size() = 0). The OCL evaluator would have to turn off typechecking on properties starting with base_ and treat the second part of the name as a type for further typechecking. This, I guess, is what Ed might call .reflection.. -- Steve From: bran.selic@gmail.com [mailto:bran.selic@gmail.com] On Behalf Of Bran Selic Sent: 30 December 2011 22:17 To: Pete Rivett Cc: Ed Willink; uml2-rtf@omg.org Subject: Re: UML 2.5 12.3 How is OCL used for Stereotypes? Pete is right. I mixed my M2s and M1s when I explained how the navigation works. The Stereotype instance in M1 is actually connected to an Interface instance (M1). However, the constraint is defined at M2 and, as usual, applies to corresponding M1 instances. Apologies for any confusion....Bran On Fri, Dec 30, 2011 at 2:23 PM, Pete Rivett wrote: To clarify, this is all defined at the M2 level but only ever applied or executed at the M1 or model level. For example it is not testing whether the UML metaclass Interface has any attributes (which would be a bit pointless) but a specific instance of Interface which is linked to an instance of the Home stereotype. So I disagree with Bran that it needs access to the UML metamodel at all. Pete Bran Selic wrote: Hi Ed, Feedback below prefixed by "[bvs]": On Fri, Dec 30, 2011 at 1:09 PM, Ed Willink wrote: > Hi Bran > > Perhaps one of us misunderstands > > self.base_Interface.ownedAttributes->size() = 0 > > I consider 'self' to be an instance of Home, > [bvs] Not exactly. There is no instance of Home. Instead, there is an instance of Stereotype with a link to the (meta)class that it extends. In this case, it points to Interface (since Home is a stereotype of Interface). Therefore, the expression "self.base_Interface" gets us to the Interface (meta)class. (NB: This assumes that the M2 model of UML is accessible -- whether it is physically present or merely implied, is a tool implementation issue.). So, the expression "self.base_Interface.ownedAttribute" will indeed be an operation on the Interface (meta)class, and the expression will indeed return the collection of attributes owned by the Interface class (modulo the incorrect spelling of the operation name that you pointed out -- please raise an issue on this with Juergen). > > Simple OCL operates at a single meta-level; > [bvs] As I noted above, the assumption behind the expression is that the UML metamodel is "present"; that is, the M1 model and the M2 metamodel are simply combined into a single composite model, with all its nodes being instances of MOF::Class. Since there is no formal notion of meta-levels, the fact that some elements of this composite are M1 elements and others M2 is transparent. Cheers...Bran Subject: AW: UML 2.5 12.3 How is OCL used for Stereotypes? Date: Wed, 4 Jan 2012 16:39:20 +0100 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: UML 2.5 12.3 How is OCL used for Stereotypes? Thread-Index: AczHiaaWXAn3pYf8TKWQUq/KYbz/rADaYCDAAAC2ucA= From: "Wendland, Marc-Florian" To: "Bock, Conrad" , "Ed Willink" , X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id q04FdIxZ030879 Conrad, As far as I know, the profile mechanism was defined on M3 (UML Infrastructure) until UML 2.5. Therefore, I'd agree with Ed that self@M1 is an instance of Home, which is defined at M2 level and is an instance of M3 stereotype. I do not know how this is realized in UML 2.5, since the Infrastructure has been removed from the overall architecture. Logically, Home still should be on M2 level but as an instance of M2 stereotype (since MOF does not know anything about stereotypes) - maybe similar as how InstanceSpecifications are treated at M1. Nevertheless, it must be located on M2 level, since a stereotype instance (which is Home, not the instance of Home in M1) is related to a metaclass on M2 (e.g. adds new attributes/constraints at metaclass level, not on model level). Hope, this was not too confusing. Marc-Florian ################################################ Marc-Florian Wendland Master of Science (M.Sc.) ------------------------------------------------ Fraunhofer Institut FOKUS Modeling und Testing Department Kaiserin-Augusta-Alle 31 D-10589 Berlin ------------------------------------------------ Tel: +49 (30) - 3463 7395 Email: marc-florian.wendland@fokus.fraunhofer.de ################################################ > -----Ursprühe Nachricht----- > Von: Bock, Conrad [mailto:conrad.bock@nist.gov] > Gesendet: Mittwoch, 4. Januar 2012 16:12 > An: Ed Willink; uml2-rtf@omg.org > Betreff: RE: UML 2.5 12.3 How is OCL used for Stereotypes? > > > Ed, > > > self@M1 is an instance of Home@M2 which is an instance of > > Stereotype@M3. > > Stereotype is in the UML metamodel (M2). It's not in MOF, as I understand > it. > > Conrad X-CM-Score: 0.00 X-CNFS-Analysis: v=2.0 cv=EZtKsYaC c=1 sm=1 a=eW53zEZrsyElcQ0NK1QpqA==:17 a=M51pKum5684A:10 a=b3taTnZFt7oA:10 a=8nJEP1OIZ-IA:10 a=oCcaPWc0AAAA:8 a=yILxcaVEdg37zQbNwCkA:9 a=XryG6PcG8C6ehCs5BQQA:7 a=wPNLvfGTeEIA:10 a=eW53zEZrsyElcQ0NK1QpqA==:117 Date: Wed, 04 Jan 2012 15:45:15 +0000 From: Ed Willink User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 To: "Bock, Conrad" CC: "uml2-rtf@omg.org" Subject: Re: UML 2.5 12.3 How is OCL used for Stereotypes? Hi Conrad Yes, Home is user-defined, and is no doubt 'drawn' on diagrams showing M1 elements. It may therefore be convenient for UML to use a slight of hand to treat Home as an M1 UML element. Unfortunately I suspect that this slight of hand is untenable for OCL navigation which must treat Home as the M2 element that it is and consequently the OCL metamodels must have Stereotype at M3 so that it is not until, M4 that you get self definition. Regards Ed Willink On 04/01/2012 15:18, Bock, Conrad wrote: P.S. Also, Home I assume is user-defined, so is at M1, even though conceptually they are extensions to metaclasses. (Thisslight of hand causes alot of problems, and was introduced for tools with fixed metaclasses (eg, implementations of metaclasses as database tables). My understanding it affects the interchange files, which need to treat them specially). Conrad Ed, > self@M1 is an instance of Home@M2 which is an instance of > Stereotype@M3. Stereotype is in the UML metamodel (M2). It's not in MOF, as I understand it. Conrad ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2012.0.1901 / Virus Database: 2109/4721 - Release Date: 01/03/12 From: "Bock, Conrad" To: Ed Willink , "uml2-rtf@omg.org" Date: Wed, 4 Jan 2012 10:51:09 -0500 Subject: RE: UML 2.5 12.3 How is OCL used for Stereotypes? Thread-Topic: UML 2.5 12.3 How is OCL used for Stereotypes? Thread-Index: AczHiaaWXAn3pYf8TKWQUq/KYbz/rADaYCDAAAC2ucAAAIq4sA== Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Marc-Florian, > As far as I know, the profile mechanism was defined on M3 > (UML Infrastructure) until UML 2.5. Infrastrucure isn't M3, it's mostly the overlap between UML and MOF, except for profiles, which is only for extending UML, as I understand it. > Logically, Home still should be on M2 level > but as an instance of M2 stereotype (since MOF does not know > anything about stereotypes) - maybe similar as how > InstanceSpecifications are treated at M1. Nerijus showed by an interchange example where the stereotype instances and their links to the UML metaclass instances are in a completely separate part of the file, to get around the meta-sleight of hand stereotypes are doing. It doesn't use InstanceSpecs, I don't think, InstanceSpecs aren't instances, they can specify any number of instances. Conrad From: "Bock, Conrad" To: Ed Willink , "uml2-rtf@omg.org" Date: Wed, 4 Jan 2012 10:58:24 -0500 Subject: RE: UML 2.5 12.3 How is OCL used for Stereotypes? Thread-Topic: UML 2.5 12.3 How is OCL used for Stereotypes? Thread-Index: AczHKrT5xofwC5PkxU+0FiqI4bquUwAFgd0AAO0f7uAAAOxbgA== Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Steve, > Stereotype.allInstances()->select( si | si.base_Trigger = > self.trigger)->exists( si | si.name = 'Create') > > However I believe that any OCL typechecker will complain > when it gets to si.base_Trigger, because the property > base_Trigger is not defined on Stereotype It should be, search on "base_" in the Profiles chapter. Conrad X-SpamScore: -11 X-BigFish: VS-11(zz542M1432Nzz1202hzz8275dh84d07hz2fh2a8h668h839h944h) X-Forefront-Antispam-Report: CIP:131.107.125.8;KIP:(null);UIP:(null);IPV:NLI;H:TK5EX14MLTC104.redmond.corp.microsoft.com;RD:none;EFVD:NLI X-FB-SS: 13, From: Steve Cook To: "Bock, Conrad" , Ed Willink , "uml2-rtf@omg.org" Subject: RE: UML 2.5 12.3 How is OCL used for Stereotypes? Thread-Topic: UML 2.5 12.3 How is OCL used for Stereotypes? Thread-Index: AczHKrT5xofwC5PkxU+0FiqI4bquUwAFgd0AAO0f7uAAAOxbgAAAWX3g Date: Wed, 4 Jan 2012 16:14:31 +0000 Accept-Language: en-GB, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.166.18.105] X-OriginatorOrg: microsoft.com X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id q04GExW0001960 Conrad The class Stereotype has no properties base_XXX defined on it. It is only the "MOF-equivalent model" that has such properties defined. >From the OCL point of view, the example I gave will not compile. It could compile either (a) by special-casing the base_XXX properties in the way I indicated in my email, or (b) by actually instantiating the MOF-equivalent model. -- Steve -----Original Message----- From: Bock, Conrad [mailto:conrad.bock@nist.gov] Sent: 04 January 2012 15:58 To: Ed Willink; uml2-rtf@omg.org Subject: RE: UML 2.5 12.3 How is OCL used for Stereotypes? Steve, > Stereotype.allInstances()->select( si | si.base_Trigger = > self.trigger)->exists( si | si.name = 'Create') > > However I believe that any OCL typechecker will complain > when it gets to si.base_Trigger, because the property > base_Trigger is not defined on Stereotype It should be, search on "base_" in the Profiles chapter. Conrad From: "Bock, Conrad" To: Ed Willink , "uml2-rtf@omg.org" Date: Wed, 4 Jan 2012 11:33:23 -0500 Subject: RE: UML 2.5 12.3 How is OCL used for Stereotypes? Thread-Topic: UML 2.5 12.3 How is OCL used for Stereotypes? Thread-Index: AczHKrT5xofwC5PkxU+0FiqI4bquUwAFgd0AAO0f7uAAAOxbgAAAWX3gAAByvgA= Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Steve, > The class Stereotype has no properties base_XXX defined on > it. You're right the constraint on Transition is assuming a general M1 stereotype that's a superclass of all M1 stereotypes, with a general property for navigating to the base instance. This is how it should have been, but isn't. The OCL you wrote can be adapted to work: Create.allInstances()->select( si | si.base_Trigger = self)->notEmpty() It uses the base_Trigger property on instances of the Create stereotype, which is what the spec currently requires (search on "base_" in the profiles chapter), assuming Trigger is the base for Create as you said. Or self.extension_Create->notEmpty() because the extension associations are navigable in both directions (the above being a navigable association-owned property, if OCL supports those). Conrad X-SpamScore: -5 X-BigFish: VS-5(zz542Mzz1202hzz8275dhz2fh2a8h668h839h944h) X-Forefront-Antispam-Report: CIP:131.107.125.8;KIP:(null);UIP:(null);IPV:NLI;H:TK5EX14HUBC107.redmond.corp.microsoft.com;RD:none;EFVD:NLI X-FB-SS: 13, From: Steve Cook To: "Bock, Conrad" , Ed Willink , "uml2-rtf@omg.org" Subject: RE: UML 2.5 12.3 How is OCL used for Stereotypes? Thread-Topic: UML 2.5 12.3 How is OCL used for Stereotypes? Thread-Index: AczHKrT5xofwC5PkxU+0FiqI4bquUwAFgd0AAO0f7uAAAOxbgAAAWX3gAAByvgAAANrl4A== Date: Wed, 4 Jan 2012 16:48:27 +0000 Accept-Language: en-GB, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.166.18.105] X-OriginatorOrg: microsoft.com X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id q04Gn3Hi004836 Conrad >The OCL you wrote can be adapted to work: > Create.allInstances()->select( si | si.base_Trigger = self)->notEmpty() Yes, as I said "by actually instantiating the MOF-equivalent model". >self.extension_Create->notEmpty() It may be interesting to postulate an OCL checker that would be able to typecheck that. It would need to be able to dynamically extend the type Trigger whenever anybody defined a stereotype of it. I can't readily imagine anybody implementing such a checker though. -- Steve -----Original Message----- From: Bock, Conrad [mailto:conrad.bock@nist.gov] Sent: 04 January 2012 16:33 To: Ed Willink; uml2-rtf@omg.org Subject: RE: UML 2.5 12.3 How is OCL used for Stereotypes? Steve, > The class Stereotype has no properties base_XXX defined on > it. You're right the constraint on Transition is assuming a general M1 stereotype that's a superclass of all M1 stereotypes, with a general property for navigating to the base instance. This is how it should have been, but isn't. The OCL you wrote can be adapted to work: Create.allInstances()->select( si | si.base_Trigger = self)->notEmpty() It uses the base_Trigger property on instances of the Create stereotype, which is what the spec currently requires (search on "base_" in the profiles chapter), assuming Trigger is the base for Create as you said. Or self.extension_Create->notEmpty() because the extension associations are navigable in both directions (the above being a navigable association-owned property, if OCL supports those). Conrad From: "Bock, Conrad" To: Ed Willink , "uml2-rtf@omg.org" Date: Wed, 4 Jan 2012 12:08:56 -0500 Subject: RE: UML 2.5 12.3 How is OCL used for Stereotypes? Thread-Topic: UML 2.5 12.3 How is OCL used for Stereotypes? Thread-Index: AczHKrT5xofwC5PkxU+0FiqI4bquUwAFgd0AAO0f7uAAAOxbgAAAWX3gAAByvgAAANrl4AAA1g5Q Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Steve, > >self.extension_Create->notEmpty() > > It may be interesting to postulate an OCL checker that would > be able to typecheck that. It would need to be able to > dynamically extend the type Trigger whenever anybody defined > a stereotype of it. I can't readily imagine anybody > implementing such a checker though. Could avoid extending Trigger (which is the purpose of navigable association-owned ends) using intersection tables or hash tables. Query the table with the instance of Trigger and get the instances of Create extending it. Conrad X-CM-Score: 0.00 X-CNFS-Analysis: v=2.0 cv=EZtKsYaC c=1 sm=1 a=eW53zEZrsyElcQ0NK1QpqA==:17 a=M51pKum5684A:10 a=b3taTnZFt7oA:10 a=8nJEP1OIZ-IA:10 a=KHpXyVWLAAAA:8 a=oCcaPWc0AAAA:8 a=puLK-9pEqXw4kHNSBmEA:9 a=o-cOXrZtvUtRRmXtR7oA:7 a=wPNLvfGTeEIA:10 a=WP4_USCxRkkA:10 a=eW53zEZrsyElcQ0NK1QpqA==:117 Date: Wed, 04 Jan 2012 17:10:10 +0000 From: Ed Willink User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 To: "uml2-rtf@omg.org" Subject: Re: UML 2.5 12.3 How is OCL used for Stereotypes? Hi I don't regard any constraint written using allInstances as desirable. There should be a better way. If there is a MOF-equivalent model we need the construction rules for this model. I suspect that qualified navigation may offer a solution since typenames exist whereas synthetic association/extension names have to be synthesized in a bespoke model. If there is a rule that can be executed, then the type analysis must be tractable whichj means that an OCL type checker is easily produced. Once UML has realizable OCL constraints, I would expect to implement 100% of them in Eclipse OCL by direct loading and direct code generation to well-defined models. Regards Ed Willink On 04/01/2012 16:48, Steve Cook wrote: Conrad The OCL you wrote can be adapted to work: Create.allInstances()->select( si | si.base_Trigger = self)->notEmpty() Yes, as I said "by actually instantiating the MOF-equivalent model". self.extension_Create->notEmpty() It may be interesting to postulate an OCL checker that would be able to typecheck that. It would need to be able to dynamically extend the type Trigger whenever anybody defined a stereotype of it. I can't readily imagine anybody implementing such a checker though. -- Steve -----Original Message----- From: Bock, Conrad [mailto:conrad.bock@nist.gov] Sent: 04 January 2012 16:33 To: Ed Willink; uml2-rtf@omg.org Subject: RE: UML 2.5 12.3 How is OCL used for Stereotypes? Steve, > The class Stereotype has no properties base_XXX defined on> it. You're right the constraint on Transition is assuming a general M1 stereotype that's a superclass of all M1 stereotypes, with a general property for navigating to the base instance. This is how it should have been, but isn't. The OCL you wrote can be adapted to work: Create.allInstances()->select( si | si.base_Trigger = self)->notEmpty() It uses the base_Trigger property on instances of the Create stereotype, which is what the spec currently requires (search on "base_" in the profiles chapter), assuming Trigger is the base for Create as you said. Or self.extension_Create->notEmpty() because the extension associations are navigable in both directions (the above being a navigable association-owned property, if OCL supports those). Conrad ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2012.0.1901 / Virus Database: 2109/4721 - Release Date: 01/03/12 From: "Bock, Conrad" To: Ed Willink , "uml2-rtf@omg.org" Date: Wed, 4 Jan 2012 12:24:04 -0500 Subject: RE: UML 2.5 12.3 How is OCL used for Stereotypes? Thread-Topic: UML 2.5 12.3 How is OCL used for Stereotypes? Thread-Index: AczLBAGahCvXTZEPTeGDjRLFKiU+qgAAInEA Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Ed, > I don't regard any constraint written using allInstances as > desirable. There should be a better way. Does OCL support navigation across navigable association-owned association ends? (I see there's a compliance point for navigating across non-navigable associations, would be the same sort of implementation). If so, you could do this: self.extension_XXX to identify the instances of stereotype XXX applied to an instance of a UML metaclass (self). Conrad From: "Bock, Conrad" To: Ed Willink , "uml2-rtf@omg.org" Date: Wed, 4 Jan 2012 12:26:03 -0500 Subject: RE: UML 2.5 12.3 How is OCL used for Stereotypes? Thread-Topic: UML 2.5 12.3 How is OCL used for Stereotypes? Thread-Index: AczLBAGahCvXTZEPTeGDjRLFKiU+qgAAInEA Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US P.S. Never mind, found it in the OCL spec: In a UML association, an end may be owned by the Classifier at that end, or by the association, itself. The ownership of the end is not significant to OCL. In either case, the association end is considered as a property of the Classifier and can be navigated from that end to the other. so the OCL below should work, and be used in the Transition constraint Steve mentioned. Conrad Ed, > I don't regard any constraint written using allInstances as > desirable. There should be a better way. Does OCL support navigation across navigable association-owned association ends? (I see there's a compliance point for navigating across non-navigable associations, would be the same sort of implementation). If so, you could do this: self.extension_XXX to identify the instances of stereotype XXX applied to an instance of a UML metaclass (self). Conrad X-CM-Score: 0.00 X-CNFS-Analysis: v=2.0 cv=EZtKsYaC c=1 sm=1 a=eW53zEZrsyElcQ0NK1QpqA==:17 a=M51pKum5684A:10 a=b3taTnZFt7oA:10 a=8nJEP1OIZ-IA:10 a=oCcaPWc0AAAA:8 a=STPszkrDly06D7yVfnAA:9 a=4fgvry9JmCjIis43TFYA:7 a=wPNLvfGTeEIA:10 a=eW53zEZrsyElcQ0NK1QpqA==:117 Date: Wed, 04 Jan 2012 17:33:28 +0000 From: Ed Willink User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 To: "uml2-rtf@omg.org" Subject: Re: UML 2.5 12.3 How is OCL used for Stereotypes? Hi Conrad Yes. OCL supports arbitrary association navigation. If a tool or a serialization (e.g EMOF without oppositeRoleName tags) doesn't support them that is not OCL's problem. Yes self.extension_XXX might work, but I think this requires that "extension_XXX" is either reified in a bespoke equivalent MOF model or that OCL recognise base_XXX as a special purpose navigation operator. I dislike the former and hate the latter. My suggestion of something like self.XXX overloads navigation but hopefully with obviously distinct names and so avoids the need for custom operators or bespoke equivalent MOF models. Regards Ed Willink On 04/01/2012 17:24, Bock, Conrad wrote: Ed, > I don't regard any constraint written using allInstances as > desirable. There should be a better way. Does OCL support navigation across navigable association-owned association ends? (I see there's a compliance point for navigating across non-navigable associations, would be the same sort of implementation). If so, you could do this: self.extension_XXX to identify the instances of stereotype XXX applied to an instance of a UML metaclass (self). Conrad ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2012.0.1901 / Virus Database: 2109/4721 - Release Date: 01/03/12 From: "Bock, Conrad" To: Ed Willink , "uml2-rtf@omg.org" Date: Wed, 4 Jan 2012 12:42:19 -0500 Subject: RE: UML 2.5 12.3 How is OCL used for Stereotypes? Thread-Topic: UML 2.5 12.3 How is OCL used for Stereotypes? Thread-Index: AczLB1TbUEkaQ7Y+QDe+3Z1A1YchIQAAF50w Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Ed, > Yes self.extension_XXX might work, but I think this requires > that "extension_XXX" is either reified in a bespoke > equivalent MOF model or that OCL recognise base_XXX as a > special purpose navigation operator. I dislike the former > and hate the latter. > > My suggestion of something like self.XXX overloads > navigation but hopefully with obviously distinct names and > so avoids the need for custom operators or bespoke > equivalent MOF models. Or could require all M1 stereotypes to be specializations of a UML-provided stereotype based on Element, with a property "base" (or some other name) of type Element. This property could be redefined in user-defined stereotypes to restrict the type to the base of those stereotypes. Conrad X-CM-Score: 0.00 X-CNFS-Analysis: v=2.0 cv=EZtKsYaC c=1 sm=1 a=eW53zEZrsyElcQ0NK1QpqA==:17 a=M51pKum5684A:10 a=b3taTnZFt7oA:10 a=8nJEP1OIZ-IA:10 a=oCcaPWc0AAAA:8 a=pzOP6sb4uk7MFAJomngA:9 a=xmmulvwK-QdwRDg-UU8A:7 a=wPNLvfGTeEIA:10 a=eW53zEZrsyElcQ0NK1QpqA==:117 Date: Wed, 04 Jan 2012 18:32:07 +0000 From: Ed Willink User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 To: "uml2-rtf@omg.org" Subject: Re: UML 2.5 12.3 How is OCL used for Stereotypes? Hi A standard "base" property is much better, but it makes type checking harder since the known type is encoded in a constraint, which an OCL tool would need to recognize as an idiomatic declaration. Direct use of the typename avoids the need for constraints, but of course also needs an OCL tool to recognize yet another source of navigation name candidates. These can be expressed relatively clearly in the OCL expressions that define the name candidates in an environment. Regards Ed Willink On 04/01/2012 17:42, Bock, Conrad wrote: Ed, > Yes self.extension_XXX might work, but I think this requires > that "extension_XXX" is either reified in a bespoke > equivalent MOF model or that OCL recognise base_XXX as a > special purpose navigation operator. I dislike the former > and hate the latter. > > My suggestion of something like self.XXX overloads > navigation but hopefully with obviously distinct names and > so avoids the need for custom operators or bespoke > equivalent MOF models. Or could require all M1 stereotypes to be specializations of a UML-provided stereotype based on Element, with a property "base" (or some other name) of type Element. This property could be redefined in user-defined stereotypes to restrict the type to the base of those stereotypes. Conrad ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2012.0.1901 / Virus Database: 2109/4721 - Release Date: 01/03/12 From: "Bock, Conrad" To: Ed Willink , "uml2-rtf@omg.org" Date: Thu, 5 Jan 2012 09:52:47 -0500 Subject: RE: UML 2.5 12.3 How is OCL used for Stereotypes? Thread-Topic: UML 2.5 12.3 How is OCL used for Stereotypes? Thread-Index: AczLEhPuFutzDf8+Qu6Ruk5JsejsaQAp2KXw Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Ed, > A standard "base" property is much better, but it makes type > checking harder since the known type is encoded in a > constraint, which an OCL tool would need to recognize as an > idiomatic declaration. Not sure what the "known type" is, but the type of the base property would be redefined without using OCL in user-defined stereotypes. In any case, this assumes changes to UML that might not be in scope of UML 2.5. Conrad From: Ed Seidewitz To: Steve Cook , "Bock, Conrad" , Ed Willink CC: "uml2-rtf@omg.org" Date: Thu, 5 Jan 2012 11:11:49 -0500 Subject: RE: UML 2.5 12.3 How is OCL used for Stereotypes? Thread-Topic: UML 2.5 12.3 How is OCL used for Stereotypes? Thread-Index: AczHKrT5xofwC5PkxU+0FiqI4bquUwAFgd0AAO0f7uAAAOxbgAAAWX3gAAByvgAAANrl4AAwPUUg Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-Mailprotector-Decision: deliver X-Mailprotector-Connection: TLSv1|[10.1.50.226]|10.1.50.226|outbound.mailprotector.net|0|0|0|new|ugly|0|0|0|0 X-Mailprotector-Results: null_ptr clean X-Mailprotector-Score: 40 X-Mailprotector-IP-Analysis: 0, 10.1.50.226, Ugly c=0 p=0 Source New X-Mailprotector-Scan-Diagnostics: 0-0-0-10117-c X-Mailprotector-ID: b1f2429a-3910-4f9d-a818-9397a04993eb X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id q05GBtgj023214 Actually, the OCL Conrad gave does not really require "instantiating the MOF-equivalent model" as such, at least not for syntactic and static semantic correctness. A stereotype is a kind of class and the extension relationship between the stereotype and the metaclass it extends is just a special kind of association. If you simply treat the Create stereotype as a class with an association to the Trigger class, then the OCL given by Conrad is perfectly correct. The only issue is the naming of ends of the extension association itself. The UML 2.4 and previous specs are not actually clear that it is normative that the extension association ends should have the "base_X" and "extension_Y" (these names only come up in the discussion of the MOF-equivalent semantic model). However, I believe we decided to clarify this in UML 2.5, so it is perfectly consistent to assume these end names in OCL expressions. This should be sufficient, I think, for the "Create.allInstances()" expression. As I think Ed Willink noted, for "self.extension_Create" to work correctly you need to be able to identify "extension_Create" as an owned end of the extension association from Create to Trigger. If it is sufficient that the extension itself is imported, then things should be OK, since, presumably, the standard profile package is already imported in order to make the Create stereotype visible without qualification. On the other hand, if qualification is required on "extension_Create", then we would need to define some sort of normative names for extension associations so the association name can be used as a qualifier. In any case, note that the fact that Trigger is a metaclass doesn't really matter. This is an example of the kind of "cross meta-level" relationship that Bran was talking about when making the point that trying to pin everything at some specific "M-level" really just confuses things. Actually, things were a little dicey with MOF 2.0 before UML 2.4, because MOF classes were not actually UML classes, resulting from a separate merge of the (UML 2.0!) infrastructure. However, this isn't an issue in UML 2.4, since MOF 2.4 classes are UML 2.4 classes and there is a normative merged UML 2.4 metamodel to refer to. Indeed, in UML 2.4/2.5 the "MOF equivalent model" is really just a regular UML model of the relationship of the stereotype to the metaclass it extends. The only reasons to keep the idea of "MOF equivalence" are because stereotypes don't actually extend the normative UML abstract syntax so tools don't have to instantiate them that way to maintain abstract syntax conformance and in order to define the semantics and interchange of stereotypes in terms of MOF. -- Ed -----Original Message----- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Wednesday, January 04, 2012 11:48 AM To: Bock, Conrad; Ed Willink; uml2-rtf@omg.org Subject: RE: UML 2.5 12.3 How is OCL used for Stereotypes? Conrad >The OCL you wrote can be adapted to work: > Create.allInstances()->select( si | si.base_Trigger = self)->notEmpty() Yes, as I said "by actually instantiating the MOF-equivalent model". >self.extension_Create->notEmpty() It may be interesting to postulate an OCL checker that would be able to typecheck that. It would need to be able to dynamically extend the type Trigger whenever anybody defined a stereotype of it. I can't readily imagine anybody implementing such a checker though. -- Steve -----Original Message----- From: Bock, Conrad [mailto:conrad.bock@nist.gov] Sent: 04 January 2012 16:33 To: Ed Willink; uml2-rtf@omg.org Subject: RE: UML 2.5 12.3 How is OCL used for Stereotypes? Steve, > The class Stereotype has no properties base_XXX defined on > it. You're right the constraint on Transition is assuming a general M1 stereotype that's a superclass of all M1 stereotypes, with a general property for navigating to the base instance. This is how it should have been, but isn't. The OCL you wrote can be adapted to work: Create.allInstances()->select( si | si.base_Trigger = self)->notEmpty() It uses the base_Trigger property on instances of the Create stereotype, which is what the spec currently requires (search on "base_" in the profiles chapter), assuming Trigger is the base for Create as you said. Or self.extension_Create->notEmpty() because the extension associations are navigable in both directions (the above being a navigable association-owned property, if OCL supports those). Conrad X-CM-Score: 0.00 X-CNFS-Analysis: v=2.0 cv=EZtKsYaC c=1 sm=1 a=eW53zEZrsyElcQ0NK1QpqA==:17 a=M51pKum5684A:10 a=b3taTnZFt7oA:10 a=8nJEP1OIZ-IA:10 a=OmcBXmSQaHAHcTtKx3sA:9 a=wPNLvfGTeEIA:10 a=eW53zEZrsyElcQ0NK1QpqA==:117 Date: Thu, 05 Jan 2012 17:34:14 +0000 From: Ed Willink User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 To: "uml2-rtf@omg.org" Subject: Re: UML 2.5 12.3 How is OCL used for Stereotypes? Hi Conrad > A standard "base" property is much better, but it makes type > checking harder since the known type is encoded in a > constraint, which an OCL tool would need to recognize as an > idiomatic declaration. Not sure what the "known type" is, but the type of the base property would be redefined without using OCL in user-defined stereotypes. My understanding of stereotypes is very limited, so I'm trying to learn. Unforunately I can't find the Trigger example so I can only go on Interface/Home. I assume that given base_XXX, XXX identifies a group (?type) of navigable elements (?properties), so that an OCL checker/evaluator should perform static/dynamic analysis of the usage of XXX::yyy. I see XXX as a type syntactically and so a.XXX or a.XXX::yyy in OCL. In the event of ambiguity a.uml::Interfaced selects the M2 stereotype and a.my::Interface the M1 user type. In any case, this assumes changes to UML that might not be in scope of UML 2.5. Yes, but since OCL makes no mention of stereotypes and has not yet achieved UML 2.x alignment, the scope of OCL 2.5 is much more accommodating. Regards Ed Willink From: Ed Seidewitz To: Ed Willink CC: "uml2-rtf@omg.org" Date: Thu, 5 Jan 2012 13:47:27 -0500 Subject: RE: UML 2.5 12.3 How is OCL used for Stereotypes? Thread-Topic: UML 2.5 12.3 How is OCL used for Stereotypes? Thread-Index: AczL0I/+/ki2bFgrSA2r8BSYTMyPOAACPZeA Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-Mailprotector-Decision: deliver X-Mailprotector-Connection: TLSv1|[10.1.50.225]|10.1.50.225|outbound.mailprotector.net|0|0|0|new|ugly|0|0|0|0 X-Mailprotector-Results: null_ptr clean X-Mailprotector-Score: 40 X-Mailprotector-IP-Analysis: 0, 10.1.50.225, Ugly c=0 p=0 Source New X-Mailprotector-Scan-Diagnostics: 0-0-0-6485-c X-Mailprotector-ID: 4c50001d-5dce-4b9b-a365-9a3d293a4d6c X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id q05IlRj1003090 Ed -- See my previous long-ish email in this thread. But here is a short summary. In UML, a stereotype is modeled as an extension of a metaclass. In the UML abstract syntax, Stereotype is a kind of Class and Extension is a kind of Association. The stereotype owns one end of the association and the other end is owned by the association itself (so the metaclass does not have to be modified to be extended). The names in question are simply the names that the ends of the extension association are required to have. For example, the Home stereotype extends the Interface metaclass. This means that Home has an extension association with Interface. The Home end of this association is named "extension_Home" and the base end is named "base_Interface". Navigation across the extension is thus, conceptually and formally, exactly like navigation across any association. Again, I don't think the fact that Interface happens to be a metaclass makes any difference here. -- Ed -----Original Message----- From: Ed Willink [mailto:ed@willink.me.uk] Sent: Thursday, January 05, 2012 12:34 PM To: uml2-rtf@omg.org Subject: Re: UML 2.5 12.3 How is OCL used for Stereotypes? Hi Conrad > > A standard "base" property is much better, but it makes type > > checking harder since the known type is encoded in a > > constraint, which an OCL tool would need to recognize as an > > idiomatic declaration. > > Not sure what the "known type" is, but the type of the base > property would be redefined without using OCL in user-defined > stereotypes. My understanding of stereotypes is very limited, so I'm trying to learn. Unforunately I can't find the Trigger example so I can only go on Interface/Home. I assume that given base_XXX, XXX identifies a group (?type) of navigable elements (?properties), so that an OCL checker/evaluator should perform static/dynamic analysis of the usage of XXX::yyy. I see XXX as a type syntactically and so a.XXX or a.XXX::yyy in OCL. In the event of ambiguity a.uml::Interfaced selects the M2 stereotype and a.my::Interface the M1 user type. > In any case, this assumes changes to UML that might not be in > scope of UML 2.5. Yes, but since OCL makes no mention of stereotypes and has not yet achieved UML 2.x alignment, the scope of OCL 2.5 is much more accommodating. Regards Ed Willink X-SpamScore: -15 X-BigFish: VS-15(zzbb2dI9371Ic85fh542M12d5M98dKzz1202hzz8275bh8275dhz2fhc1ahc1bhc1ahc1bh2a8h668h839h) X-Forefront-Antispam-Report: CIP:131.107.125.8;KIP:(null);UIP:(null);IPV:NLI;H:TK5EX14HUBC104.redmond.corp.microsoft.com;RD:none;EFVD:NLI X-FB-SS: 13, From: Steve Cook To: Juergen Boldt Subject: RE: UML 2.5 12.3 How is OCL used for Stereotypes? Thread-Topic: UML 2.5 12.3 How is OCL used for Stereotypes? Thread-Index: AczHKrT5xofwC5PkxU+0FiqI4bquUwAFgd0AAO0f7uAAAOxbgAAAWX3gAAByvgAAANrl4AD6xeupACR8hWA= Date: Tue, 10 Jan 2012 09:47:19 +0000 Accept-Language: en-GB, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.166.18.101] X-OriginatorOrg: microsoft.com I guess it could be turned into an OCL issue . .need clear specification for how to write OCL that refers to the stereotypes applied to a model within a UML profile.. -- Steve From: Juergen Boldt [mailto:juergen@omg.org] Sent: 09 January 2012 16:20 To: Steve Cook Subject: RE: UML 2.5 12.3 How is OCL used for Stereotypes? Steve, how should I handle this extensive thread...as an issue or mere discussion? -Juergen At 11:48 AM 1/4/2012, you wrote: Conrad >The OCL you wrote can be adapted to work: > Create.allInstances()->select( si | si.base_Trigger = self)->notEmpty() Yes, as I said "by actually instantiating the MOF-equivalent model". >self.extension_Create->notEmpty() It may be interesting to postulate an OCL checker that would be able to typecheck that. It would need to be able to dynamically extend the type Trigger whenever anybody defined a stereotype of it. I can't readily imagine anybody implementing such a checker though. -- Steve -----Original Message----- From: Bock, Conrad [ mailto:conrad.bock@nist.gov] Sent: 04 January 2012 16:33 To: Ed Willink; uml2-rtf@omg.org Subject: RE: UML 2.5 12.3 How is OCL used for Stereotypes? Steve, > The class Stereotype has no properties base_XXX defined on > it. You're right the constraint on Transition is assuming a general M1 stereotype that's a superclass of all M1 stereotypes, with a general property for navigating to the base instance. This is how it should have been, but isn't. The OCL you wrote can be adapted to work: Create.allInstances()->select( si | si.base_Trigger = self)->notEmpty() It uses the base_Trigger property on instances of the Create stereotype, which is what the spec currently requires (search on "base_" in the profiles chapter), assuming Trigger is the base for Create as you said. Or self.extension_Create->notEmpty() because the extension associations are navigable in both directions (the above being a navigable association-owned property, if OCL supports those). Conrad Best regards, -Juergen Juergen Boldt Director, Member Services 140 Kendrick Street, Building A Suite 300 Needham, MA 02494 USA Tel: 781 444 0404 x 132 fax: 781 444 0320 www.omg.org Ed Willink