The EmofUC meta-meta-model is an extension of the OMG EMOF 2.4 meta-meta-model, in which minor modifications have been introduced in order to simplify its Python implementation in the PyEmofUC environment:

• Several EMOF abstract classes have been removed. Those classes were included because OMG defines EMOF as a simplification of UML and CMOF, but contribute nothing to EMOF.
• EMOF::Classifier has been removed. Its responsibility has been passed to the EmofUC::Type class.
• In order to avoid multiple inheritance, EmofUC::MultiplicityElement inherits from EmofUC::TypedElement.
• Several references have been renamed ir order to avoid collision with reserved words in Python.
• The reference EMOF::type has been renamed to EmofUC::theType.
• The reference EMOF::class has been renamed to EmofUC:theClass.
• The primitive data types proposed in the UML annex have been adopted. However, in EmofUC the values of the corresponding Python primitive types can be assigned to them.
  The defined primitive types are:
  
• PyString (with the values of Python::str)
• PyBoolean (with the values of Python::bool)
• PyReal (with the values of Python::float)
• PyInteger (with the values of Python::int)
• PyUnlimitedInteger (with the values of Python::long)
  
• In order to minimize laxity in meta-models, new specific primitive types have been defined:
  
• PyToken
  
• Identifier
• URI
• URL
• DefaultValue
• NsPrefix
• LowerCardinality
• UpperCardinality
• GlobalPropertyRef
• GlobalClassRef
• GlobalTypeRef
  

The class diagram below shows the EmofUC classes organized by containment and inheritance.
Their detailed description (attributes and associations) can be found in the EMOF 2.4 specification.

Python implementation of EMOF classes

The Python classes associated to the meta-meta-model elements are dynamically generated at runtime. The implementation has the following features:

• The properties are formulated through properties in the corresponding Python class, with same name and holding the defined default value (if any).
  However, as established in Python, the properties are not typed until a value is assigned to them.
  Therefore, the application creating a model is responsible for the appropriate assignment (regarding the type, as specified by the meta-model) of values to the variables. This type information is always available to any application because in PyEmofUC each model element has always access to its meta-class through the metaclass reference.

• Every operation defined in the EMOF classes is implemented as a method with same name, same return type and same parameters (name and type) in the corresponding Python class.
  The meta-model can define the functionality of an operation by associating an "OPE" tag to it (see the next section).

• The methods in the EMOF Python implementation may have parameters as defined in EMOF (regarding name, type, cardinality and default value).

Extensions provided by EmofUC

The EmofUC meta-meta-model incorporates a number of extensions which are specified associating a tag (with predefined key names) to the meta-models elements.
The extensions defined are:

Declaration of native primitive types

EMOF (as well as EmofUC) allows to declare new primitive types. However, EMOF does not provide mechanisms for specifying nor characteristics of the newly defined data types neither inheritance relations among them.
EmofUC declares 5 primitive data types based on the Python native data types:

• PyString:PrimitiveType => It corresponds to the formulation of a text using the Python str type.
• PyBoolean:PrimitiveType => It corresponds to the Python bool type, with its logical values True and False.
• PyReal:PrimitiveType => It corresponds to the Python float type.
• PyInteger:PrimitiveType => It corresponds to the Python int type.
• PyUnlimitedInteger:PrimitiveType =>  It corresponds to an integer numerical type with an unlimited range of values, as defined by the Python long type.

Their definition is complete because they correspond to well-defined Python types. The types also match those defined in the UML Annex. The only difference is that UML suggests the UnlimitedNatural unsigned type whereas PyEmofUC proposes the PyUnlimitedInteger type, which corresponds to a signed integer.

Declaration of specific primitive types

EmofUC introduces a number of types derived from native primitive types. They increase the detail level when formalizing meta-models, hence allowing model verification before installing the models in the environment.

The types defined by PyEmofUC are shown in the previous figure:

• PyToken:PrimitiveType =>  It is based on the PyString type by delimiting the possible characters to alphanumeric ones.
  The operating principle of the PyEmofUC environment is the dynamic generation of Python structures from EMOF models.
  This type restricts the EMOF identifiers (names of properties, data types, classes, packages, operations and parameters) to strings suitable for designating elements of the Python language.
• Identifier: PrimitiveType => It is based on the PyString type by delimiting the possible characters to alphanumeric ones that can be part of identifiers in XMI documents.
  This type is used in three different contexts, hence facilitating the traceability of the verification processes.
• For assigning a value to the xmi_id attribute of any EmofUC element.
• For assigning values to the properties represented in the Python implementations.
• in "xmi:id" attributes of the XMI documents. 
• URI: PrimitiveType => It is based on the PyString type by enforcing the URI format, as defined in the Uniform Resource Identifier (URI): Generic Syntax specification.
• URL: PrimitiveType =>  It is based on the PyString type by enforcing the valid values for resource locators.
  In PyEmofUc three types of locators are supported:
  
• hypertext format (http://)
• absolute paths in file systems (file:///)
• relative paths within workspaces (platform:).
  
• DefaultValue: PrimitiveType => It is a wildcard type.
  One of the key characteristics of the Python language is the dynamically allocation of type to variables during assigning time (and not at declaration time, which is not required in Python).
  With this type, the data type is assigned based on the context. For instance, the default value of an EMOF property will have the type of the element property in which it is defined.
• NsPrefix:PrimitiveType => It is based on the PyString type. It is used as an abbreviation for representing URIs with reference-like format.
  
• LowerCardinality:PrimitiveType => It is based on the PyString type, only allowing the values "0" and "1". It is used to specify cardinalities lower range.
• UpperCardinality:PrimitiveType =>  It is based on the pyString type, only allowing the values "1" and "*". It is used to specify cardinalities upper range.
• GlobalPropertyRef:PrimitiveType => It is a wildcard type used when a reference can optionally point to an emof.Property element in other model.
  When the model which the pointed element belongs to is stored in the PyEmofUC environment, the variable references the element directly but if the target model is not stored, the value assigned to the reference variable is a textual URI.
• GlobalClassRef:PrimitiveType => It is a wildcard type used when a reference can optionally point to a class in other model. Their characteristics and requirements are the same as the ones for the GlobalPropertyRef type
  
• GlobalTypeRef:PrimitiveType =>  It is a wildcard type used when a reference can optionally point to an emof.Type element in other model. Their characteristics and requirements are the same as the ones for the GlobalPropertyRef type.
  

Qualification of primitive types

  Four tags with predefined and reserved names have been specified in order to declare features of the primitive types defined in a meta-model:

• “PT” => It is used for defining inheritance between data types. Its value attribute specifies the extended (by inheritance) primitive data type.
  For example, the table below shows the declaration of the URI primitive type. The associated tag "PT" indicates that it specializes the emof.PyString type.
• “RE” => It is used for restricting the textual values supported by a specific type based on PyString. Its value attribute defines a regular expression which specifies which strings are compatible with the type.
  For instance, the table below shows the declaration of the URI primitive type. The associated tag "RE" indicates that its value must have a format like, for instance, http://unican.es/istr/PyEmofUC/EMOF.

<ownedType  name="URI" xmi:id="emof.URI" xsi:type="emof:PrimitiveType">       <tag name="PT" xmi:id="emof.URI.PT" xsi:type="emof:Tag"              value="emof#emof.PyString"/>       <tag name="RE" xmi:id="emof.URI.RE" xsi:type="emof:Tag"              value="((http://)|(file:///)|(platform:))([a-z]|[A-Z])([a-z]|[A-Z]|[0-9]|/|[.]|_)*"/> </ownedType>

• “MAX” => It is used for setting the maximum value allowed in numeric data types, i.e. specialization of emof.PyReal, emof.PyInteger and emof.PyUnlimitedInteger. Its value attribute must hold a real or integer number according to the type it qualifies.
• “MIN” => It is used for setting the minimum value allowed in numeric data types,  i.e. specialization of emof.PyReal, emof.PyInteger and emof.PyUnlimitedInteger. Its value attribute must have a real or integer number according to the type it qualifies.

  The table below shows the definition of the primitive data type Percentage as a PyReal type within the range [0.0, 100.0].

<ownedType  name="Percentage" xmi:id="mast2.Percentage" xsi:type="emof:PrimitiveType">       <tag name="PT" xmi:id="mast2.Percentage.PT" xsi:type="emof:Tag" value="emof#emof.PyReal"/>       <tag name="MAX" xmi:id="mast2.URI.MAX" xsi:type="emof:Tag" value="100.0"/>       <tag name="MIN" xmi:id="mast2.URI.MIN" xsi:type="emof:Tag" value="0.0"/> </ownedType>

Declaration of derived attributes

A derived property has a value that is evaluated based on other attributes in the same class. A derived property is not implemented by means of a Python attribute, but through a Python property in which the getter method calls another specific method.
PyEmofUC uses the "DE" tag for declaring the Python code implementing the method that evaluates the value of a derived property.
The table below shows a chunk of code declaring a derived property named isRoot in the emof.Package class.

<ownedType name="Package" xsi:type="emof:Class" xmi:id="emof.Package" superclass="#emof.NamedElement">       <ownedAttribute name="nestingPackage" xmi:id="emof.Package.nestingPackage" xsi:type="emof:Property"               theType="#emof.Package" opposite="#emof.Package.nestedPackage"/> ……..       <ownedAttribute name="isRoot" xmi:id="emof.Package.isRoot" xsi:type="emof:Property"                           theType="#emof.PyBoolean" isDerived="True" >              <tag name="DPE" xmi:id="emof.Package.isRoot.DPE" xsi:type="emof:Tag"                                value="return self.nestingPackage==None"/>       </ownedAttribute> </ownedType>

The code below shows the Python code for the class implemented by the PyEmofUC environment, based on the information provided by the "DPE" tag.

     def getisRoot(self):
           return self.nestingPackage==None
      isRoot=property(getisRoot)

Please, note that the tag value attribute must strictly respect the indentation required by the Python syntax.

Operations implementation

The EMOF specification allows to associate operations to meta-model classes in order to describe the instances behaviour, but it only describes the methods signature, i. e., the operation name, the parameters name and type, and the return type. Its only goal is to describe the public interface of model elements.

PyEmofUC allows to associate the Python code implementing operations by means of "OPE" tags. This mechanism is only useful if the operation code is simple, because it presents dificulties if trying to verify its correctness.
For operations with more complex code, it should be associated using inheritance and extension strategies. (TODO).

The "OPE" tags may be aggregated to emof.Operation elements and the value attribute contains the Python code implementing the operation behaviour. The environment introduces the basic syntax indentation required by the invocation code, but in the code included in the tag, it must be included in the indentation between the code sentences.

The table below shows an example of code operation assignment.

<ownedType name="Familia" xmi:id="fam.Familia" xsi:type="emof:Class" superclass="#fam.Elemento">                                                                                       <ownedAttribute name="miembro" xmi:id="fam.Familia.miembro" xsi:type="emof:Property"                 theType="#fam.Persona" isComposite="True" upper="*" opposite="#fam.Persona.familia"/>       <ownedAttribute name="padre" xmi:id="fam.Familia.padre" xsi:type="emof:Property"                 theType="#fam.Adulto" lower="0"/>       <ownedAttribute name="madre" xmi:id="fam.Familia.madre" xsi:type="emof:Property"                 theType="#fam.Adulto" lower="0"/>       <ownedOperation name="hijo" xmi:id="fam.Familia.hijo" xsi:type="emof:Operation"                 theType="#fam.Persona" lower="0" upper="*">               <tag name="OPE" xmi:id="fam.Familia.hijo.OPE" xsi:type="emof:Tag"                     value="hijos=list(self.miembros);hijos.remove(self.padre)if self.padre else None;hijos.remove(self.madre) if self.madre else None; return hijos"/>       </ownedOperation> </ownedType>

The following chunk of code is incorporated by the environment to the class where the operation is defined.

     def hijo(self):
          hijos=list(self.miembros);hijos.remove(self.padre) if self.padre else None; hijos.remove(self.madre) if self.madre else None; return hijos

Documentation introduction

"DOC" tags are used in order to add documentation into models:

<ownedType name="Elemento" xmi:id="fam.Elemento" xsi:type="emof:Class"             superclass="emof#emof.Object" isAbstract="True">       <tag name="DOC" xmi:id="fam.Elemento.DOC" xsi:type="emof:Tag"                 value="Elemento abstracto raiz de otros tipos de elemento de la familia"/> </ownedType>