El metametamodelo EmofUC es una extensión del metametamodelo EMOF 2.4 de OMG, en el que se han introducido ligeras modificaciones para simplificar su implementación en el entorno PyEmofUC:

• Se han eliminado algunas de las clases abstractas incluidas en EMOF. Estas clases se incluyen porque OMG formula EMOF en base a la especificación de UML y de CMOF, pero no aportan nada en EMOF.
• Se ha eliminado EMOF:Classifier cuya responsabilidad se ha pasado a su única clase  especializada EmoUC:Type.
• Se ha considerado que EmofUC::MultiplicityElement hereda de EmofUC::TypedElement, para evitar una herencia múltiple de Property, Operation y Parameter de TypedElement y MultiplicityElement.
• Se ha cambiado el nombre de algunas referencias para hacerlas compatibles con palabras reservadas del lenguaje Python.
• La referencia EMOF::type se ha renombrado como EmofUC::theType.
• La referencia EMOF::class se ha renombrado como EmofUC:theClass.
• Se han adoptado los tipos de datos primitivos propuesto en el anexo de UML, pero se atribuyen los valores propios de los correspondientes tipos primitivos Python.
  Los tipos primitivos definidos han sido:
  
• PyString con los valores de Python::str)
• PyBoolean (con los valores de Python::bool)
• PyReal (con los valores de Python::float)
• PyInteger (con los valores de Python::int)
• PyUnlimitedInteger (con los valores de Python::long)
  
• Se ha incluido nuevos tipo de datos primitivos específicos para reducir laxitud en los metamodelos.
• PyToken
• XMI_Identifier
• URI
• URL
• DefaultValue
• NsPrefix
• LowerCardinality
• UpperCardinality
• GlobalPropertyRef
• GlobalClassRef
• GlobalTypeRef

En el siguiente diagrama de clases se muestran las clases de EmofUC organizadas por contención y herencia.
La descripción detallada de las clases (atributos y asociaciones) puede encontrarse en la especificación EMOF 2.4.

Implementación Python de las clases EMOF

La implementación de las clases Python que se asocian a los elementos del metametamodelo se generan dinámicamente en tiempo de ejecución, con las siguientes características:

• Las propiedades de las clases EMOF se formulan en la clase Python como una propiedad Python con el mismo nombre y con el valor por defecto asignado (en caso que lo tenga definido). Sin embargo, como es propio en Phyton,  las propiedades toman su tipo cuando se le asigna un valor. Por ello, es responsabilidad de la herramienta que carga o la aplicación que crea un modelo, asegurar que el valor que se asigna es del tipo establecido en el modelo EMOF. Esta información está disponible como parte de la información que proporciona la metaclase asociada.

• En cada clase las operaciones definidas en el modelo EMOF se formulan como una función Python de la clase con el nombre, tipo de valor retornado y parámetros iguales a los declarados en el modelo. El metamodelo puede definir la funcionalidad de la operación a través del código que se define mediante una  etiqueta "OPE" (ver la siguiente sección).

• Las operaciones de las clases EMOF pueden tener declarados parámetros,  con nombre, tipo, multiplicidad y valor por defecto. En la implementación Python de las operaciones, se definen los parámetros con las mismas características, salvo el tipo que en el caso de Python se establece en la asignación del valor, esto es, en la invocación. Es de nuevo responsabilidad de la herramienta o aplicación, asignar valores a los parámetros del tipo correcto. Esta información está disponible en la información que proporciona la metaclase asociada.

Extensiones proporcionadas por EmofUC

Al metametamodelo EmofUC se han incorporado un conjunto de extensiones, utilizando para ello el mecanismo basado en asociar etiquetas (instancias de la clase Tag) a los elementos de los metamodelos, previstos en EMOF.
Las extensiones incorporadas a EmofUC son las siguientes:

Declaración de tipos primitivos nativos

EMOF (e igualmente EmofUC) permite declarar tipos primitivos con un nombre asociado. Sin embargo EMOF, no ofrece mecanismos para especificar las características del tipo de dato, ni la dependencia por herencia entre ellos.
En EmofUC, se han declarado 5 tipos de datos básicos en base a los tipos de datos nativos de Python:

• PyString: PrimitiveType => Corresponde a la formulación de texto utilizando  el tipo str de Python.
• PyBoolean: PrimitiveType => Corresponde a la represenación de los valores booleanos utilizando el tipo bool de python, con sus valores lógicos True y False.
• PyReal: PrimitiveType => Corresponde a la representación de datos numricos reales utilizando el tipo float de Python.
• PyInteger: PrimitiveType => Corresponde a la representación de datos numéricos enteros utilizando el tipo int de Python.
• PyUnlimitedInteger: PrimitiveType =>  Corresponde a la representación de datos numéricos con rangos ilimitados de valores utilizando el tipo long de Python.

Al estar asociadas las características de estos tipos de datos a los correspondientes del lenguaje Python, su características quedan perfectamente especificadas. Es interesante notar que estos tipos coinciden con los propuestos en la extensión base que propone OMG para UML. La única diferencia cualitativa es que OMG propone UnlimitedNatural de enteros sin signo en vez de PyUnlimitedInteger como se propone en PyEmofUC que son enteros con signo.

Declaración de tipos primitivos específicos

Se ha considerado de interés introducir en EmofUC un conjunto de tipos específicos que son derivados de los tipos primitivos nativos, que permiten incrementar el detalle en la formalización de la información, y sobre todo, poder verificar la consistencia de los modelos de forma previa a su instanciación en el entorno.

Los tipos que se han definido en PyEmofUC, son los que se muestran en la figura previa:

• PyToken: PrimitiveType =>  Es un tipo PyString en el que se restringe a palabras alfanuméricas que pueden ser utilizadas en Python para representar los tokens del lenguaje. La base operativa  del entorno PyEmofUC es la generación dinámica de las estructuras Python en base de los modelos EMOF, por lo que para facilitar y hacer mas legible el entorno se restringen los identificadores de los elementos de los modelos EMOF (Properties, DataTypes, Classes, Packages, Operations y Parameters) a palabras que pueden ser utilizados para designar elementos del lenguaje Python.
• XMI_Identifier: PrimitiveType => Es un tipo PyString en el que se restringe a palabra alfanuméricas al formato que puede ser utilizado como identificador en los documentos XMI. Se ha utilizado el mismo valor como identificador del elemento en tres casos: en los atributos xmi_id de los elementos en EmofUC, en los correspondientesatributos de sus implementaciones Python y en los atributos xmi:id en los documentos XMI. La elección del mismo tipo de dato   simplifica las transformaciones, hace mas legibles la información y ayuda a  la trazabilidad en los procesos de verificación.
• URI: PrimitiveType => Es un tipo PyString en el que se restringe a los formatos de los  identificadores universales (URI), tal como se definen en la especificación Uniform Resource Identifier (URI): Generic Syntax. De hecho, no se toma esta especificación en toda su generalidad, y se reduce al subconjunto de formatos que son soportados por PyEmofUC  (Formatos http:, file: y platform:). Se utiliza para delimitar los identificadores de los modelos que se gestionan en el entorno.
• URL: PrimitiveType => Es un tipo PyString en el que se restringe la palabra a localizadores de documentos bajo diferentes escenario, como hipertexto (http:), direcciones absolutas en sistemas de ficheros (file:) y direcciones relativas en base a workspaces(platform:). Se utiliza para delimitar los localizadores de los documentos en el entorno.
• DefaultValue: PrimitiveType => Es un tipo comodín. Unas de las características claves del lenguaje Python es la asignación dinámica del tipo a las variables en en momento de la asignación, y no en el momento de la declaración (que no se requiere). Con el tipo DefaultValue se propone un tipo comodín similar, que asigna el tipo al dato en base del contexto. Por ejemplo, las propiedades EMOF tienen declarado  un atributo default, cuyo tipo de dato se establece cuando se define el tipo de la propiedad (no del atributo).
• NsPrefix: PrimitiveType => Es un tipo PyString en el que se restringe la palabra a aquellas que van a utilizarse para de forma abreviada designar los espacios de nombre que introducen los modelos y paquetes, sustituyendo localmente a los URI dentro de ciertos entornos temporales.
• LowerCardinality: PrimitiveType => Es un tipo PyString  que define los dos términos ‘0’ y ‘1’ utilizados en el valor inferior del rango de multiplicidad para indicar el carácter opcional u obligatoriedad de las propiedades.
• UpperCardinality: PrimitiveType => Es un tipo PyString  que define los dos términos ‘1’ y ‘*’ utilizados en el valor superior del rango de multiplicidad para indicar la naturaleza única o múltiple de los valores de los MultiplicityElement.
• GlobalPropertyRef: PrimitiveType => Es un tipo comodín que se utiliza para indicar que una referencia a una propiedad puede ser definida como interna o externa. Lo característico de las referencias externas es que dentro del entorno las referencias externas  pueden tener dos implementaciones diferentes. Cuando es interna, o externa y el modelo al que pertenece está registrado en el entorno, la referencia se implementa como una referencia Python a un objeto Property en memoria. Por el contrario, la misma referencia si es externa y el modelo no está registrado la implementación que se utiliza en el entorno es un texto de tipo URI que los designa la propiedad.
• GlobalClassRef: PrimitiveType  => Es un tipo comodín que se utiliza para indicar que una referencia a una emof.Class puede ser definida como interna o externa. Su naturaleza es similar a GlobaPropertyRef, salvo que  es una referencia a una clase EMOF.
• GlobalTypeRef: PrimitiveType =>  Es un tipo comodín que se utiliza para indicar que una referencia a un elemento emof.Type  que puede ser definida como interna u externa. Su naturaleza es similar a GlobaPropertyRef, salvo que  es una referencia a un tipo EMOF.

Cualificación de los tipos primitivos

Se han reservado cuatro nombres  de etiquetas para la formulación de aspectos relativos a los tipos que se definen en un metamodelo:

• “PT” => Define herencias entre tipos de datos. Su atributo value es la referencia a otro tipo de datos del que hereda su características. Por ejemplo, en la tabla siguiente que muestra la declaración del tipo especifico URI, indica que es una especialización del tipo emof.PyString.
• “RE” => Se utiliza para restringir los textos que admite un tipo especifico de tipo PyString. Su atributo value define una expresión regular que establece los textos que son compatibles el tipo. Por ejemplo, en la tabla siguiente que muestra la declaración del tipo especifico URI, indica que un datos tipo URI debe tener expresiones tales como 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” => Se utiliza para establecer el valor máximo admitido en tipos de datos numéricos (que son especializaciones de emof.PyReal, emof.PyInteger y emof.PyUnlimitedInteger). Su atributo value debe tener un valor real o entero conforme al tipo base de que se trate.
• “MIN”  => Se utiliza para establecer el valor mínimo admitido en tipos de datos numéricos (que son especializaciones de emof.PyReal, emof.PyInteger y emof.PyUnlimitedInteger). Su atributo value debe tener un valor real o entero conforme al tipo base de que se trate.

En la siguiente tabla se define el tipo de dato Percentage como un tipo de dato real que admite valores entre 0.0 y 100.0 (ambos incluidos).

<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>

Declaración de atributos derivados

Una propiedad derivada es aquella que tiene un valor que se evalua en base a otros atributos disponibles en la clase en que está declarado. Una propiedad derivada no se implementa con un atributo Python en la instancia, sino como una propiedad Python en la que el método de lectura ejecuta un método específico en el ámbito de la instancia.
En PyEmofUC se reserva la etiqueta “DPE” para definir el código Python que implementa el método que evalúa el valor de la propiedad derivada. En la tabla se muestra como ejemplo la propiedad derivada isRoot que EMOF define para los elementos emof.Package. Así mismo, en la siguiente figura se muestra el código que el entorno PyEmofUC incorpora en la clase Python que implementa el entorno PyEmofUC a partir de la información del tag “DPE”.

<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>

Esta descripción da lugar a que el entorno cree el siguiente código Python en tiempo de ejecución de la clase en que está declarada.

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

Obsérvese que el sangrado que requiere la sintaxis Python lo introduce de forma automática el entorno PyEmofUC, pero el sangrado relativo al código que se introduzca debe ser introducido con la etiqueta.

Implementación de operaciones de las clases

EMOF prevee asociar a los elementos del modelo operaciones que describen aspectos de su comportamiento. EMOF sólo describe los aspectos de especificación de las cabeceras de los métodos, esto es, nombre y descripción de los parámetros  y del valor que retorna. Su función es meramente describir la interfaz pública de los objetos del modelo.

Haciendo uso de tag con nombre reservado “OPE”, en PyEmofUC se permite asociar a las operaciones el código Python que las implementa y que el entorno las genera automáticamente. El método es útil para incorporar el código de pequeñas operaciones de gestión de los objetos del modelo. Para operaciones de negocio mas complejas, se prevee mecanismos de herencia y/o composición que permita asociar a los objetos del modelo código elaborado (y probado) externamente (TODO).

Los tags de nombre “OPE” se asocian en el metamodelo a los elementos de tipo emof.Operation, y contienen en su atributo value el código Python que implementa la funcionalidad de la operación. El entorno introduce el sangrado base que requiere la sintaxis de invocación del código, pero en el código que se incluye en el tag debe estar el sangrado relativos entre las sentencia del código introducido.

En la figura se muestra como ejemplo la operación ficha de la clase Familia en el ejemplo FamiliaEmpresa que se describe en este documento.

<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>

El siguiente código es el que el entorno incorpora a la clase en que está definida la operación.

     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

Incorporación de documentación

A fin de que se pueda generar automáticamente documentación de los modelos se ha reservado los tags con nombre “DOC” para introducir etiquetas con documentación en cada elemento de un modelo.

<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>