Issue 6531: Omit predefined type OclModelElement. (ocl2-ftf) Source: (, ) Nature: Uncategorized Issue Severity: Summary: Description: OclModelElement is currently defined in the OCL Standard Library. It can simply be omitted, as it is actually never used. OclModelElementType, however, must remain in the metamodel, e.g., for the mapping of OclState. Resolution: Revised Text: Revised Text: 1) In section 8.2 remove the obsolete sentences: "In comparison with UML 1.4 …" and "This means that a Classifier…". 2) In all the document replace OclModelElementType by ElementType. 3) Add the TypeType metaclass and ElementType in the types diagram (Figure 5) +elementType PrimitiveType InvalidType AnyType Operation Signal MessageType 0..1 * +referredOperation 0..1 * +referredSignal TypeType ElementType 4) Add the following description for the TypeType metaclass: """A TypeType is used to represent the type of the formal parameter of specific operations that need to refer to the types at the meta-level, like the oclIsKindOf, oclIsTypeOf and oclAsType pre-defined operations. It has a unique instance named 'OclType' which complies to any type defined in the model (at the meta level). """ 6) In section 8.2, replace the description of the OclModelElementType metaclass (now renamed ElementType) with the following text: A ElementType is used to represent the type of the formal parameter of specific operations that need to refer to elements of the model such as the UML states in the predefined oclInState operation. 7) In all 11.2.4 paragraph, replace all occurrences of 'typename' by 'typespec', "statename" by "statespec" and remove all sentences "Typename may be in the format Package::subPackage::classifier" and "statename may be in the format Class::State::subState". 8) Rename title 11.3 as "Special types". Changes the sentence "This section defines …" by "This section defines several special types that are used to formalize the signature of pre-defined operations that manipulate types and elements defined in the UML model". Rename OclModelElement as OclElement and change its description with "The singleton instance of ElementType". Change the description of OclType with "The singleton instance of TypeType". Remove the OclState description. Actions taken: November 10, 2003: received issue November 1, 2005: closed issue Discussion: This issue has been merged with issue 6610 (Enumeration approach for reflection) which suggest dropping the enumeration approach for reflection because of multiple implementation problems it causes. Usage of enumeration for reflection is now avoided thanks to the introduction of TypeExp and StateExp. The metaclass TypeType is now used to represent the type accepted by the oclIsKindOf, oclIsTypeOf and oclAsType operations. The TypeType has a unique instance named 'OclType' , but it is anymore a enumeration but a type compliant with any type defined in the model (metalevel). In a similar way, the OclModelElementType – renamed ElementType – to better match UML2 terminology (since Element replaces ModelElement as the base element in the class hierarchy) – is retained to allow encoding explicitly the type of the parameter in the oclInState pre-defined operation. This ElementType type has a singleton instance in the standard library called OclElement (which is not an enumeration). Since a usage of oclIsKindOf (resp. oclInState) is encoded as an operations call, the arguments need to be OclExpressions: that's why the meta types are passed using TypeExp (resp. StateExp). End of Annotations:===== mit predefined type OclModelElement. Author: Stephan Flake (flake@c-lab.de) Description: OclModelElement is currently defined in the OCL Standard Library. It can simply be omitted, as it is actually never used. OclModelElementType, however, must remain in the metamodel, e.g., for the mapping of OclState. Subject: OCL FTF: Preparing the 2nd poll Date: Mon, 16 May 2005 19:06:03 +0200 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: OCL FTF: Preparing the 2nd poll Thread-Index: AcVaOYpgaBXNgxcuSoesmCN7i3RLVg== From: "BELAUNDE Mariano RD-MAPS-LAN" To: Cc: "Jos Warmer" X-OriginalArrivalTime: 16 May 2005 17:06:08.0979 (UTC) FILETIME=[8DDF6230:01C55A39] Hi all, For the next 2nd poll, I would like to resolve at least the following set of issues: - Issue 6012 : Alignment of OCL/UML/MOF (merging issues 6545, 6567), - Issues 6531, 6532, 7660, 7661 (problems with the representation of types), If you want other issues be treated in this second poll, do not hesitate to sent your suggestions and resolutions, preferibly by the mid of this week. After the second poll I think we will have the possibility to make an additional third poll by the end of May. Please find below for discussion my initial proposal to resolve the issues listed above. I still need to track the complete impact of the proposed changes in the document. I will send a more elaborated resolution text proposal within a couple of days to prepare the ballot that I hope will run next week. *********** Issue 7661: There should be an OclTypeLiteralExp *********************** *********** Issue: 7660 There should be an OclStateLiteralExp ********************** *********** Issue: 6531 Omit predefined type OclModelElement ********************** *********** Issue 6532: Consider OclType as a powertype. **************************** Note: I propose to merge these 4 issues because of the resolution dependencies. Resolution: The FTF members agree that using enumerations to refer to the available types or states in the UML model brings a lot of problems ("a dead end") to implementors. Introducing a specific expression 'TypeLiteralExp' that refers directly to the referred types solves the problem of type referrencing and avoids building OclType and OclModelElement enumerations . which are not generically defined. The resolution works when dealing with UML user models as well as when dealing with metamodels. TypeLiteralExp is to be used when invoking the operations oclIsKindOf and oclIsTypeOf. Also introducing StateLiteralExp . as suggested by the author of issue 7660 - avoids building a model-dependent enumeration to refer to the available states. The Figure 28, which defines specific inheritance links between M1 level types is removed, since it brings confusion (see description of issue 6532) and is not strictly needed to define the compliance rules (OclVoid and OclAny are special types with their own built-in compliance rules). The OclAny is defined as an instance of the AnyType metatype instead of being an instance of Classifier, since a Classifier, being abstract, cannot be instantiated. Revised Text: 1) In section 8.2, remove OclModelElementType metaclass from the OCL Types package. 2) In section 8.3 (Expressions package) add the metaclass TypeLiteralExp and add an association named 'TypeLiteralExp::referredType : Type'. 3) Remove the definition of OclModelElement and OclType in section 11.3 (Standard library/ModelElementTypes) 4) In section 8.3 (Expressions package) add the metaclass StateLiteralExp and add an association named 'StateLiteralExp::referredState : Vertex'. 5) Remove the definition of OclState in section 11.3 (Standard library/ModelElementTypes) 6) Remove the sub-title 11.3 (since it becomes empty) 7) In section 8.2 (Types Package) add the metaclass AnyType with the following description: "The type AnyType is used to represent features that are available to all objects, in particular the instances of types defined in the model. It has a unique instance named OclAny defined in the standard library". 8) In section 11.2.1 replace the paragraph "The type OclAny is the supertype of all types in the UML model and the primitive types in the OCL Standard Library. The collection types from the OCL Standard Library are not subtypes of OclAny. Properties of OclAny are available on each object in all OCL expressions. OclAny is itself an instance of the metatype Classifier. " By: "All types in the UML model and the primitive types in the OCL standard library comply with the type OclAny. Conceptually, OclAny behaves as a supertype for all the types except for the OCL pre-defined collection types. Features of OclAny are available on each object in all OCL expressions. OclAny is itself an instance of the metatype AnyType." 9) Remove figure 28 . *** Issue 6012: Alignment of OCL2/UML2/MOF2 .***************************** General approach: We make all the changes needed to align the OCL2 metamodel with the UML2 superstructure metamodel (last revised spec : ptc/04-10-2). We add an additional chapter, named "Essential OCL", to define the adaptation of the OCL2 metamodel to EMOF. Since no new concept in introduced here, this chapter will simply contain an introductory text and the list of diagrams defining the "Essential OCL" package (in essence a subset of the complete OCL metamodel). To align OCL2 metamodel with the UML2 superstructure metamodel, I have identified the following changes: - Rename 'ModelPropertyCallExp' as 'ModelFeaturePropertyCallExp' (since in UML2 a 'feature' designates both attributes and operations). - Merges AttributeCallExp and AssociationEndCallExp as a unique metaclass, named PropertyCallExp inheriting from the existing metaclass NavigationCallExp. The links 'AttributeCallExp::referredAttribute' and 'AssociationEndCallExp:referredAssociationEnd' are merged into the link 'PropertyCallExp:referredProperty'. - OclExpression inherits from "OpaqueExpression", instead of "ModelElement" (Since this is the way how the UML2 assumes that the integration of OCL has to be done). - In all parts of the spec, align names when referencing the packages and the metaclasses of the UML2 superstructure metamodel. 'Core' package becomes 'Kernel' package 'Common Behavior' package becomes 'CommonBehaviors' package 'EnumLiteral' class becomes 'EnumerationLiteral' class 'AssociationClass' taken from package 'AssociationClasses' (instead of package 'Core') 'CallAction' taken from package 'Actions' (instead of 'Common Behavior') 'SendAction' becomes 'SendSignalAction' and is taken from 'Actions' (instead of 'Common Behavior') For the alignment between OCL and EMOF, the existing temporary chapter 13 "Alignment of .", will be replaced by the "Essential OCL" chapter. The idea is to build the "Essential OCL" metamodel in a similar way as EMOF is build from UML infrastructure (using merge/combine semantics). At the end, the "Essential OCL" package will depend on the "EMOF" package (instead of depending on the UML superstructure metamodel as for the complete OCL). - All the classes that are specific to UML are skipped: OclMessageType, OclMessageType, OclMessageArg, UnspecifiedValueExp, AssociationClassCallExp - the same class hierarchy refactoring that was done for EMOF applies to Essential Ocl: For instance, Classifier is replaced by Type (since Classifier is not an EMOF metaclass). I will provide a draft of the diagrams defining this package within one or two days. Regards, Mariano From: "Bast, Wim" To: "'BELAUNDE Mariano RD-MAPS-LAN'" , ocl2-ftf@omg.org Cc: Jos Warmer Subject: RE: OCL FTF: Preparing the 2nd poll Date: Tue, 17 May 2005 13:41:00 +0200 X-Mailer: Internet Mail Service (5.5.2657.72) Hi Mariano, Shouldn't Essential OCL depend on Base in UML infra instead of depending on EMOF as you propose? We need to support essential OCL for UML to. Perhaps we have to name is Base OCL thenJ. Essential OCL can be constructed form Base OCL as EMOF is constructed from Base in UML infra. Kind regards, Wim -------------------------------------------------------------------------------- From: BELAUNDE Mariano RD-MAPS-LAN [mailto:mariano.belaunde@francetelecom.com] Sent: Monday, May 16, 2005 7:06 PM To: ocl2-ftf@omg.org Cc: Jos Warmer Subject: OCL FTF: Preparing the 2nd poll Hi all, For the next 2nd poll, I would like to resolve at least the following set of issues: - Issue 6012 : Alignment of OCL/UML/MOF (merging issues 6545, 6567), - Issues 6531, 6532, 7660, 7661 (problems with the representation of types), If you want other issues be treated in this second poll, do not hesitate to sent your suggestions and resolutions, preferibly by the mid of this week. After the second poll I think we will have the possibility to make an additional third poll by the end of May. Please find below for discussion my initial proposal to resolve the issues listed above. I still need to track the complete impact of the proposed changes in the document. I will send a more elaborated resolution text proposal within a couple of days to prepare the ballot that I hope will run next week. *********** Issue 7661: There should be an OclTypeLiteralExp *********************** *********** Issue: 7660 There should be an OclStateLiteralExp ********************** *********** Issue: 6531 Omit predefined type OclModelElement ********************** *********** Issue 6532: Consider OclType as a powertype. **************************** Note: I propose to merge these 4 issues because of the resolution dependencies. Resolution: The FTF members agree that using enumerations to refer to the available types or states in the UML model brings a lot of problems ("a dead end") to implementors. Introducing a specific expression 'TypeLiteralExp' that refers directly to the referred types solves the problem of type referrencing and avoids building OclType and OclModelElement enumerations - which are not generically defined. The resolution works when dealing with UML user models as well as when dealing with metamodels. TypeLiteralExp is to be used when invoking the operations oclIsKindOf and oclIsTypeOf. Also introducing StateLiteralExp - as suggested by the author of issue 7660 - avoids building a model-dependent enumeration to refer to the available states. The Figure 28, which defines specific inheritance links between M1 level types is removed, since it brings confusion (see description of issue 6532) and is not strictly needed to define the compliance rules (OclVoid and OclAny are special types with their own built-in compliance rules). The OclAny is defined as an instance of the AnyType metatype instead of being an instance of Classifier, since a Classifier, being abstract, cannot be instantiated. Revised Text: 1) In section 8.2, remove OclModelElementType metaclass from the OCL Types package. 2) In section 8.3 (Expressions package) add the metaclass TypeLiteralExp and add an association named 'TypeLiteralExp::referredType : Type'. 3) Remove the definition of OclModelElement and OclType in section 11.3 (Standard library/ModelElementTypes) 4) In section 8.3 (Expressions package) add the metaclass StateLiteralExp and add an association named 'StateLiteralExp::referredState : Vertex'. 5) Remove the definition of OclState in section 11.3 (Standard library/ModelElementTypes) 6) Remove the sub-title 11.3 (since it becomes empty) 7) In section 8.2 (Types Package) add the metaclass AnyType with the following description: "The type AnyType is used to represent features that are available to all objects, in particular the instances of types defined in the model. It has a unique instance named OclAny defined in the standard library". 8) In section 11.2.1 replace the paragraph "The type OclAny is the supertype of all types in the UML model and the primitive types in the OCL Standard Library. The collection types from the OCL Standard Library are not subtypes of OclAny. Properties of OclAny are available on each object in all OCL expressions. OclAny is itself an instance of the metatype Classifier. " By: "All types in the UML model and the primitive types in the OCL standard library comply with the type OclAny. Conceptually, OclAny behaves as a supertype for all the types except for the OCL pre-defined collection types. Features of OclAny are available on each object in all OCL expressions. OclAny is itself an instance of the metatype AnyType." 9) Remove figure 28 . *** Issue 6012: Alignment of OCL2/UML2/MOF2 .***************************** General approach: We make all the changes needed to align the OCL2 metamodel with the UML2 superstructure metamodel (last revised spec : ptc/04-10-2). We add an additional chapter, named "Essential OCL", to define the adaptation of the OCL2 metamodel to EMOF. Since no new concept in introduced here, this chapter will simply contain an introductory text and the list of diagrams defining the "Essential OCL" package (in essence a subset of the complete OCL metamodel). To align OCL2 metamodel with the UML2 superstructure metamodel, I have identified the following changes: - Rename 'ModelPropertyCallExp' as 'ModelFeaturePropertyCallExp' (since in UML2 a 'feature' designates both attributes and operations). - Merges AttributeCallExp and AssociationEndCallExp as a unique metaclass, named PropertyCallExp inheriting from the existing metaclass NavigationCallExp. The links 'AttributeCallExp::referredAttribute' and 'AssociationEndCallExp:referredAssociationEnd' are merged into the link 'PropertyCallExp:referredProperty'. - OclExpression inherits from "OpaqueExpression", instead of "ModelElement" (Since this is the way how the UML2 assumes that the integration of OCL has to be done). - In all parts of the spec, align names when referencing the packages and the metaclasses of the UML2 superstructure metamodel. 'Core' package becomes 'Kernel' package 'Common Behavior' package becomes 'CommonBehaviors' package 'EnumLiteral' class becomes 'EnumerationLiteral' class 'AssociationClass' taken from package 'AssociationClasses' (instead of package 'Core') 'CallAction' taken from package 'Actions' (instead of 'Common Behavior') 'SendAction' becomes 'SendSignalAction' and is taken from 'Actions' (instead of 'Common Behavior') For the alignment between OCL and EMOF, the existing temporary chapter 13 "Alignment of ...", will be replaced by the "Essential OCL" chapter. The idea is to build the "Essential OCL" metamodel in a similar way as EMOF is build from UML infrastructure (using merge/combine semantics). At the end, the "Essential OCL" package will depend on the "EMOF" package (instead of depending on the UML superstructure metamodel as for the complete OCL). - All the classes that are specific to UML are skipped: OclMessageType, OclMessageType, OclMessageArg, UnspecifiedValueExp, AssociationClassCallExp - the same class hierarchy refactoring that was done for EMOF applies to Essential Ocl: For instance, Classifier is replaced by Type (since Classifier is not an EMOF metaclass). I will provide a draft of the diagrams defining this package within one or two days. Regards, Mariano -- The contents of this e-mail are intended for the named addressee only. It contains information that may be confidential. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it.