Tema 2. Fundamentos del DSDM. Metamodelado

Slides:



Advertisements
Presentaciones similares
Lenguaje Unificado de Modelado
Advertisements

TECNICATURA UNIVERSITARIA EN INFORMATICA
Curso de Java Capitulo 7: Conceptos sobre poo Profesor:
Arquitectura de software dirigida por modelos (Model-Driven Architecture) Liliana Favre UNCPBA 2006.
Arquitectura de software dirigida por modelos (Model-Driven Architecture) Liliana Favre UNCPBA 2006.
Servicios Web.
Introducción a la Orientación a Objetos
Aplicación de diseño de clases y generación de código, orientado hacia la arquitectura multicapas y el mapeo objeto/relacional Juan Timoteo Ponce Ortiz.
Transformación de modelos con ATL
Tipo de Dato Abstracto Tipos de datos:
JSP Copyright ISIPE – Instituto de Servicios Informáticos para Empresas – Universidad Siglo 21 – Cualquier copia u otro uso debe ser autorizado expresamente.
Java 2 Platform Enterprise Edition
Aplicación del paradigma orientado a objetos
Introducción XML y WebServices.
INTRODUCCIÓN A UML Oscar Miguel Alonso Moreno.
JAVA Persistence API (JPA)
DIAGRAMA DE COMPONENTES INTEGRANTES Córdova Vásquez Giovanny Escobar Alvares Calixto Gomez Quinteros Adelaida Pinto Flores Yarmila.
DIAGRAMA DE CLASE.
BASES DE DATOS ORIENTADAS A OBJETO
PROGRAMACIÓN EN JAVA Curso-taller inicial de programación en JAVA Facultad de Estadística e Informática TEMA II.
El paradigma de la orientación a objetos La programación orientada a objetos genera códigos eficientes y estandariza la metodología de programación, además.
Unified Modeling Language (Lenguaje de Modelamiento unificado)
Material Original de Microsoft para desarrolladores adaptado por Jorge Miguel PERALTA para clases de Informática Aplicada (Haga clic para adelantar/atrasar.
I Taller sobre Desarrollo de Software Dirigido por Modelos, MDA y Aplicaciones (DSDM'04) MDA Aplicado: Una Gramática de Grafos para la Transformación de.
Modelado Arquitectónico
STARUML.
UNIDAD 2 CLASES Y OBJETOS. CLASE Elementos cabecera y cuerpo de la clase. Cabecera: aporta información fundamental sobre la clase en sí y constituye de.
(c) P. Gomez-Gil, INAOE DISEÑO DE COMPONENTES DE SOFTWARE * NOTAS DEL CURSO Ingeniería de Software I DRA. MARIA DEL PILAR GÓMEZ GIL INAOEP.
Ingeniería de Software
Viviana Poblete López Módulo: Modelo de Datos
Arquitectura de software dirigida por modelos (Model-Driven Architecture) Liliana Favre UNCPBA2006.
Sesión 5 Herramientas de creación de DSL gráficos (GMF)
ESTRUCTURA DE DATOS EN JAVA
Como Desarrollar SW Distribuido de Calidad
Bases de Datos Orientadas a Objetos (BDOO)
Fundamentos de programación
Contenido: 1- Que es el .Net Framework 2- Arquitectura en .Net
Modelos de Bases de Datos
Arquitectura de software dirigida por modelos (Model-Driven Architecture) Liliana Favre UNCPBA 2006.
Introducción al modelado Unificado
UML 2.0 Integrantes: Diana Carolina Valencia M. Jhon Fernando Lopez T. Carlos Alberto Castillo.
Arquitectura de software dirigida por modelos (Model-Driven Architecture) Liliana Favre UNCPBA2006.
Importancia en la efectividad del:
Facultad de Ingeniería
TEMA 9: DIAGRAMA DE CLASE EN UML
Términos y Conceptos Básicos
Métrica v2.1 Técnicas: Modelado de datos (Parte 1)
Juan Timoteo Ponce Ortiz
29/01/031 OCL (Object Constraint Language) Juan Casas Cuevas Mercedes Arenas Fernández Laboratorio de Sistemas de Información Facultad de Informática.
Introducción a UML Departamento de Informática Universidad de Rancagua
Ingeniería de Requisitos
Taller de Sistemas de Programas Clase 6 Dpto. de Computación y T.I.
Integrantes: Dennys Quintero José Ortega Simón Fagundez Caracas 09 de Febrero de 2015.
Unified Modeling Language (Lenguaje de Modelamiento unificado)
Análisis y Diseño de Aplicaciones 3º Educación Media Tecnológica
DISEÑO DE BASES DE DATOS (modelos para el diseño)
Introducción AOO. Contenido - Introducción - Repaso de Orientación a Objetos - UML - Casos de Uso.
GML Geography Markup Language
Integrantes Miguel Betancourt Alexis Tacuri.  Activiti es una plataforma para la formación de flujos de trabajo y procesos empresariales dentro del.
Servicios Web Conjunto de aplicaciones o de tecnologías con capacidad para interoperar en la Web. Estas aplicaciones o tecnologías intercambian datos entre.
Fundamentos de Ingeniería de Software
Arquitectura de software dirigida por modelos (Model-Driven Architecture) Liliana Favre UNCPBA2006.
Presentación De UML Lenguaje estándar para escribir planos de software Se usa para visualizar, especificar, construir y documentar los artefactos de un.
Modelado UML Diagrama de Clases
Entregables del Proyecto
Programación en Java Introducción a Java. Reseña histórica Surge en 1991 por Sun Microsystems Desarrollado para electrodomésticos Se buscaba un código.
Concepto de Tipo y Subtipo Diseño e Implementación Fundamentos de Programación Departamento de Lenguajes y Sistemas Informáticos Unidad Didáctica 10 Versión.
Estructura de Datos Departamento de Programación Universidad Metropolitana Contenido: UML. Envío de mensajes. Relaciones. Asociación. Agregación o composición.
Programación en Java Introducción a Java. Reseña histórica Surge en 1991 por Sun Microsystems Desarrollado para electrodomésticos Se buscaba un código.
Arquitectura de software dirigida por modelos (Model-Driven Architecture) Liliana Favre UNCPBA2006.
Transcripción de la presentación:

Tema 2. Fundamentos del DSDM. Metamodelado Departamento de Informática y Sistemas Tema 2. Fundamentos del DSDM. Metamodelado Hola, buenos días, mi nombre es Javier Cánovas Izquierdo, pertenezco al grupo de investigación de tecnología del software de la Universidad de Murcia y en esta exposición voy a presentar el artículo de las jornadas titulado “Utilidad de las transformaciones modelo-modelo en la generación automática de código” Posgrado Informática y Matemáticas Aplicadas a la Ciencia e Ingeniería Jesús García Molina Departamento de Informática y Sistemas Universidad de Murcia http://dis.um.es/~jmolina

Contenidos Metamodelado Lenguajes de metamodelado Lenguaje OCL MOF Ecore Lenguaje OCL Perfiles UML Cuestiones de metamodelado Estos son los contenidos que voy a desarrollar a los largo de la presentación. En primer lugar veremos una ligera introducción para contextualizar el artículo. A continuación explicaré el problema en el que nos basaremos para analizar las aproximaciones que veremos. Este problema consiste en la creación de wrappers Java para PL/SQL. El núcleo principal de la presentación se centrará en la explicación de la aplicación de MDD que hemos realizado al problema, siguiendo dos aproximaciones. Por una parte, la aproximación modelo-codigo, y por otra, la aproximación modelo-modelo. Finalmente veremos una comparación entre ambas aproximaciones y unas conclusiones. 11/04/2017 DSDM

Metamodelado DSDM requiere lenguajes apropiados para describir todos los aspectos de los sistemas y a diferentes niveles de abstracción. Lenguajes de modelado son lenguajes específicos del dominio (DSL). Dos posibilidades para definir un nuevo lenguaje: Crear un perfil UML Crear un metamodelo con un lenguaje de metamodelado

Metamodelado Un lenguaje de modelado o DSL se define formalmente mediante un metamodelo: Sintaxis abstracta y restricciones Sintaxis concreta Semántica Necesidad de un lenguaje de metamodelado: OMG MOF: EMOF y CMOF Eclipse (EMF, Eclipse Modeling Framework) Ecore Otros: Herramientas de metamodelado existentes disponen de uno propio (XMF, Metaedit+, DSL Tools,...)

Metamodelado Un metamodelo define los elementos de un lenguaje de modelado y las relaciones entre ellos, y las restricciones (semántica abstracta). Un metamodelo define la sintaxis abstracta y la semántica estática, pero no la sintaxis concreta. Un metamodelo define formalmente un lenguaje de modelado o DSL. Crear un metamodelo es una actividad de modelado conceptual OO Necesidad de conocer bien el dominio Herramientas manejan metamodelos y los desarrolladores sintaxis concreta (modelos).

Sintaxis abstracta de una máquina de estados Metamodelado context StateMachine inv: EstadosDistintoNombre states-> forAll (s1 | states->forAll (s2 | s1.name = s2.name implies s1 = s2)) end +states Sintaxis abstracta de una máquina de estados

Sintaxis concreta de una máquina de estados Metamodelado ruido after (2 sec) send c.estaActivo contactar objetivoEn(p) [representaAmenaza] / t.añadirObjetivo(p) Inactivo Buscando Rastreando Acoplamiento Sintaxis concreta de una máquina de estados

Metamodelado MOF y Ecore se basan en elementos de modelado orientado a objetos: Clases y Atributos Asociaciones en MOF y referencias entre objetos en Ecore Agregación en MOF Generalización Paquetes

MOF (MetaObject Facility) MOF es el lenguaje para crear metamodelos propuesto por OMG para MDA. UML está definido como un metamodelo MOF. Aplicable a cualquier dominio. Lenguajes OMG: CWM, EJB, EAI, EDOC “Medio universal para definir lenguajes de modelado” MOF permite expresar metadatos (igual que XML) Independiente de la plataforma

MOF (MetaObject Facility) MOF es descrito con la notación UML, OCL y texto informal. La notación para metamodelos MOF es la sintaxis concreta de UML: ¡Puede generar confusión al principio! Comparte elementos de modelado con UML: clases, atributos, generalización, etc.

MOF Cada elemento del lenguaje de modelado se representa mediante una clase y sus propiedades como atributos Las relaciones entre elementos se representan como asociaciones. La generalización permite expresar que un elemento es una especialización de otro. Se usa OCL para expresar la semántica estática. Uso de paquetes si el metamodelo es muy grande

Arquitectura de cuatro niveles Descripción M3 (Meta-metamodelo) Define un lenguaje para especificar metamodelos M2 (Metamodelo) Define un lenguaje para especificar modelos Cada elemento es una instancia del meta-metamodelo M1 (Modelo) Cada elemento es una instancia de un metamodelo. M0 (Instancia) Instancias de elementos definidos en un modelo

Arquitectura de cuatro niveles en MDA Descripción M3 MOF M2 metamodelos, instancias de los elementos MOF M1 modelos, instancia de un metamodelo MOF M0 el sistema, objetos y datos, instancias de los elementos de un modelo

Arquitectura de cuatro niveles: Ejemplo MOF M2 Metamodelo de UML M1 Modelo de clases UML para un sistema TPV M0 Instancias de elementos en el modelo de clases del TPV

Arquitectura de cuatro niveles: Ejemplo Elementos M3 MOF Clase, Atributo, Asociación,.. M2 Metamodelo de UML Clase, Atributo, Asociación, Estado, Actividad, Caso de uso, … M1 Modelo de clases UML para un sistema TPV Clase “Cliente”, atributo “dni”, asociación “Cliente-Pedido” M0 Instancias de elementos en el modelo de clases del TPV Cliente Pepe Pérez, 87654321, … Cliente Ana Haro, 1234567,…

Arquitectura de cuatro niveles: Ejemplo Elementos M3 MOF Clase, Atributo, Asociación,.. M2 Metamodelo del DSL TaskFlow Actividad, Tarea, Agente,.. M1 Modelo de TaskFlow Actividad “Gestión artículos de un Congreso”, Tarea “Enviar artículo”, Actor “Autor” M0 Instancias de elementos en el modelo de clases del TPV Actividad “Congreso DSDM, Tarea “Envío artículo XXX”, Actor “JJGM”

Arquitectura de cuatro niveles

Arquitectura de cuatro niveles

MOF Tabla y Columna son elementos de un modelo Existe el concepto de jerarquía de tablas context Tabla inv: padre.columna -> forAll (columnaPadre | self.columna ->includes (columnaPadre))

Árbol Sintaxis Abstracta Compiladores construyen árbol de sintaxis a partir de una sintaxis concreta (gramática). Herramientas que manejan metamodelos crean un árbol de sintaxis abstracta (AST) para representar un modelo. Sus nodos son instancias de clases del metamodelo Sus arcos son instancias de asociaciones del metamodelo

Ejemplo AST :Tabla nombre = “Persona” :Tabla nombre = “Empleado” :Columna nombre = “Pepe” :Columna dni = “1234567” :Columna sueldo = “100000”

MOF (MetaObject Facility) UML 2.0 está organizado en dos partes: Infraestructura y SuperEstructura Infraestructura define las construcciones básicas de UML 2.0. SuperEstructura define las construcciones a nivel de usuario de UML 2.0. MOF “merges” ciertos paquetes de Infraestructura Subconjunto de UML Misma notación que UML

Infraestructura: Core Contiene conceptos básicos de metamodelos Profiles Define mecanismos para extender metamodelos

SuperEstructura: Estructura

SuperEstructura: Comportamiento

MOF(MetaObject Facility) Integra facilidades básicas como reflexión o identificadores. Reflexión útil para crear herramientas de metamodelado Se debe manejar elementos de cualquier metamodelo Identificadores Se asigna un identificador único a cada elemento. Útil en actualizaciones de datos, identificación de objetos en comunicación, comparación por identidad, establecer la traza de los elementos, …

EMOF MOF: Essential MOF (EMOF) + Complete MOF (CMOF) EMOF es un subconjunto “mínimo” de MOF que contiene el núcleo con las capacidades básicas. El objetivo de EMOF es facilitar su implementación y que las herramientas conformen a MOF. Proporciona el conjunto mínimo de elementos para hacer modelado OO: clases, atributos, operaciones, herencia, y paquetes. EMOF permite definir metamodelos simples.

EMOF

EMOF

CMOF Elementos principales: Clase, Asociación, Generalización y Paquete Las clases tienen Atributos y Operaciones Una asociación tiene dos extremos que pueden tener una cardinalidad asociada y semántica de orden y agregación, y navegabilidad.

CMOF

MOF

Metamodelo UML Instancia de MOFAttribute Instancia de MOFGeneralizes Instancia de MOFAssociation Instancia de MOFClass

MetamodeloUML Instancia de MOFGeneralizes Instancia de MOFAttribute Instancia de MOFAssociation Instancia de MOFClass

CWM Instancia de MOFAssociation Instancia de MOFClass Instancia de MOFAttribute Instancia de MOFGeneralization

Arquitectura de cuatro niveles Descripción M3 MOF M2 metamodelos, instancias de los elementos MOF M1 modelos, instancia de un metamodelo MOF M0 el sistema, objetos y datos, instancias de los elementos de un modelo

EMF-Eclipse UML Java EMF Model Ecore XML Framework de DSDM para Eclipse. “Modelado y programación pueden ser considerados la misma cosa” Código Java generado a partir de un modelo Ecore Notificación de cambios, reflexión, serialización XMI, persistencia, clases de utilidad. Java (anotaciones) UML (diagramas de clase) EMF Model Ecore XML

Ecore 0..* 0..* 0..*

Ecore EClass EAttribute EDataType EReference Epackage y EFactory Modela clases EAttribute Modela atributos EDataType Modela los tipos de los atributos, que son tipos primitivos y tipos de datos objetos definidos en Java. EReference Modela asociaciones entre clases, incluyendo composición. Epackage y EFactory Clases y tipos relacionados son agrupados en paquetes y una factoría se utiliza para crear objetos.

Ecore: Parte Estructural

Ecore : Parte Comportamiento 0..* 0..* 0..* 0..*

Ecore: Paquetes 0..* 0..*

MOF Metamodelos MOF son independientes de la plataforma. Mappings de MOF a middleware, lenguajes, y formatos de información, permiten a generadores transformar automáticamente una sintaxis abstracta de un metamodelo en representaciones concretas basadas en plataformas concretas. Se han definido mappings para CORBA, XML (XMI) y Java (JMI).

XMI (XML Data Interchange) Formato de intercambio de metadatos común independiente de cualquier plataforma. Nueva forma de transferir metadatos entre repositorios MOF. Serialización de modelos y metamodelos MOF en XML Primero fue aplicado al metamodelo de UML Proporciona interoperabilidad entre herramientas

Metamodelo de clases MOF EMOF

XMI del metamodelo de clases (EMOF) <?xml version="1.0" encoding="UTF-8"?> <emof:Package xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:emof="http://schema.omg.org/spec/mof/2.0/emof.xmi" xmi:id="ClassM" name="ClassM"> <ownedType xmi:type="emof:Class" xmi:id="6E721B079B360F7A00D1E07C4458BAA5" name="Class" superClass="6EEE79489B360F7A007244CA3BE86B5B"> <ownedAttribute xmi:id="73695CDB9B360F7A0033B121713E40BF" name="attrs" upper="*" type="6EF9DA649B360F7A007244CA408DB38E" isComposite="true" opposite="ClassM.Attribute.owner"/> </ownedType> <ownedType xmi:type="emof:Class" xmi:id="6EEE79489B360F7A007244CA3BE86B5B" name="Classifier"> <ownedAttribute xmi:id="ClassM.Classifier.name" name="name“ > <type xmi:type="emof:PrimitiveType" href="http://schema.omg.org/spec/mof/2.0/emof.xmi#String"/> </ownedAttribute> <ownedAttribute xmi:id="73695CDB9B360F7A0033B121AF590F9B" name="typeOf" upper="*" type="6EF9DA649B360F7A007244CA408DB38E" opposite="ClassM.Attribute.type"/> <ownedType xmi:type="emof:Class" xmi:id="6EF9DA649B360F7A007244CA408DB38E" name="Attribute"> <ownedAttribute xmi:id="ClassM.Attribute.owner" name="owner" lower="1" type="6E721B079B360F7A00D1E07C4458BAA5" opposite="73695CDB9B360F7A0033B121713E40BF"/> <ownedAttribute xmi:id="ClassM.Attribute.type" name="type" lower="1" type="6EEE79489B360F7A007244CA3BE86B5B" opposite="73695CDB9B360F7A0033B121AF590F9B"/> <ownedAttribute xmi:id="ClassM.Attribute.name" name="name"> <ownedAttribute xmi:id="ClassM.Attribute.is_primary" name="is_primary"> <type xmi:type="emof:PrimitiveType" href="http://schema.omg.org/spec/mof/2.0/emof.xmi#Boolean"/> <ownedType xmi:type="emof:Class" xmi:id="6EF9E0579B360F7A007244CA0FCB1365" name="PrimitiveType" superClass="6EEE79489B360F7A007244CA3BE86B5B"/> </emof:Package>

XMI del metamodelo de clases (ECore) <?xml version="1.0" encoding="UTF-8"?> <ecore:EPackage xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore" name="ClassM" nsURI="http://gts.inf.um.es/examples/class" nsPrefix="classm"> <eClassifiers xsi:type="ecore:EClass" name="Class" eSuperTypes="#//Classifier"> <eStructuralFeatures xsi:type="ecore:EReference" name="attrs" upperBound="-1" eType="#//Attribute" containment="true" eOpposite="#//Attribute/owner"/> </eClassifiers> <eClassifiers xsi:type="ecore:EClass" name="Attribute"> <eStructuralFeatures xsi:type="ecore:EAttribute" name="name" eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EString"/> <eStructuralFeatures xsi:type="ecore:EReference" name="type" eType="#//Classifier"/> <eStructuralFeatures xsi:type="ecore:EAttribute" name="is_primary" eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EBoolean"/> <eStructuralFeatures xsi:type="ecore:EReference" name="owner" eType="#//Class" eOpposite="#//Class/attrs"/> <eClassifiers xsi:type="ecore:EClass" name="Classifier"> <eClassifiers xsi:type="ecore:EClass" name="PrimitiveType" eSuperTypes="#//Classifier"/> <eClassifiers xsi:type="ecore:EClass" name="Model"> <eStructuralFeatures xsi:type="ecore:EReference" name="classifiers" upperBound="-1" eType="#//Classifier" containment="true"/> </ecore:EPackage>

Metamodelo Relacional Column name : String type : String Table 0..n 1 +cols +owner 1..n +pKeys +pKeyOf Fkey +partOfFkey +fKeys +references +referencedBy MOF EMOF Table name : String cols : set(Column) pKeys : set(Column) referenceBy : set(FKey) fkeys : set(Fkey) Column owner : Table pKeyOf : Table partOfFkey : Fkey type : String Fkey references : Table

Metamodelo relacional (EMOF) <?xml version="1.0" encoding="UTF-8"?> <emof:Package xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:emof="http://schema.omg.org/spec/mof/2.0/emof.xmi" xmi:id="TableM" name="TableM"> <ownedType xmi:type="emof:Class" xmi:id="6F184C409B360F7A007244CA1577F422" name="Table“ > <ownedAttribute xmi:id="TableM.Table.name" name="name"> <type xmi:type="emof:PrimitiveType" href="http://schema.omg.org/spec/mof/2.0/emof.xmi#String"/> </ownedAttribute> <ownedAttribute xmi:id="73A6F82B9B360F7A0033B121EF646314" name="cols" upper="*" type="6F1951099B360F7A007244CA3E24CF40" isComposite="true" opposite="TableM.Column.owner"/> <ownedAttribute xmi:id="73A6F82B9B360F7A0033B1218D1F3EAA" name="pkeys" upper="*" type="6F1951099B360F7A007244CA3E24CF40" opposite="TableM.Column.pkeyOf"/> <ownedAttribute xmi:id="73A6F82B9B360F7A0033B12107163D64" name="referenceBy" upper="*" type="6F197CD29B360F7A007244CA704AD65E" opposite="TableM.FKey.references"/> <ownedAttribute xmi:id="73A6F82B9B360F7A0033B1219677E62B" name="fkeys" upper="*" type="6F197CD29B360F7A007244CA704AD65E" opposite="TableM.FKey.owner"/> </ownedType> <ownedType xmi:type="emof:Class" xmi:id="6F1951099B360F7A007244CA3E24CF40" name="Column"> <ownedAttribute xmi:id="TableM.Column.owner" name="owner" lower="1" type="6F184C409B360F7A007244CA1577F422" opposite="73A6F82B9B360F7A0033B121EF646314"/> <ownedAttribute xmi:id="TableM.Column.pkeyOf" name="pkeyOf" lower="1" type="6F184C409B360F7A007244CA1577F422" opposite="73A6F82B9B360F7A0033B1218D1F3EAA"/> <ownedAttribute xmi:id="TableM.Column.type" name="type"> <ownedAttribute xmi:id="TableM.Column.name" name="name"> <ownedAttribute xmi:id="73A6F82C9B360F7A0033B1218CE3CB87" name="partOfFkey" lower="1" type="6F197CD29B360F7A007244CA704AD65E" opposite="TableM.FKey.cols"/> <ownedType xmi:type="emof:Class" xmi:id="6F197CD29B360F7A007244CA704AD65E" name="FKey"> <ownedAttribute xmi:id="TableM.FKey.references" name="references" type="6F184C409B360F7A007244CA1577F422" opposite="73A6F82B9B360F7A0033B12107163D64"/> <ownedAttribute xmi:id="TableM.FKey.owner" name="owner" lower="1" type="6F184C409B360F7A007244CA1577F422" opposite="73A6F82B9B360F7A0033B1219677E62B"/> <ownedAttribute xmi:id="TableM.FKey.cols" name="cols" upper="*" type="6F1951099B360F7A007244CA3E24CF40" opposite="73A6F82C9B360F7A0033B1218CE3CB87"/> </emof:Package>

Metamodelo Relacional (Ecore) <?xml version="1.0" encoding="UTF-8"?> <ecore:EPackage xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore" name="TableM" nsURI="http://gts.inf.um.es/examples/relational" nsPrefix="relational"> <eClassifiers xsi:type="ecore:EClass" name="Table"> <eStructuralFeatures xsi:type="ecore:EAttribute" name="name" eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EString"/> <eStructuralFeatures xsi:type="ecore:EReference" name="cols" upperBound="-1" eType="#//Column" containment="true" eOpposite="#//Column/owner"/> <eStructuralFeatures xsi:type="ecore:EReference" name="pkeys" upperBound="-1" eType="#//Column"/> <eStructuralFeatures xsi:type="ecore:EReference" name="fkeys" upperBound="-1" eType="#//FKey" containment="true" eOpposite="#//FKey/owner"/> <eStructuralFeatures xsi:type="ecore:EReference" name="referencedBy" upperBound="-1" eType="#//FKey"/> </eClassifiers> <eClassifiers xsi:type="ecore:EClass" name="Column"> <eStructuralFeatures xsi:type="ecore:EReference" name="owner" eType="#//Table" eOpposite="#//Table/cols"/> <eStructuralFeatures xsi:type="ecore:EAttribute" name="type" eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EString"/> <eClassifiers xsi:type="ecore:EClass" name="FKey"> <eStructuralFeatures xsi:type="ecore:EReference" name="references“ eType="#//Table"/> eOpposite="#//Table/fkeys"/> <eStructuralFeatures xsi:type="ecore:EReference" name="cols" upperBound="-1" eType="#//Column"/> </ecore:EPackage>

XMI de un modelo “Relacional” (EMOF) <xmi:XMI xmlns:emof='http://schema.omg.org/spec/mof/2.0/emof.xmi' xmi:version='2.0' xmlns:TableM='file:////home/jesus/usr/eclipse-age-dev/runtime-age.product/class2table-tutorial/metamodels/TableM.emof' xmlns:xmi='http://www.omg.org/XMI'> <TableM:Table name='Person' pkeys='TableM.Column_4' xmi:id='TableM.Table_1' referenceBy='TableM.FKey_3' fkeys='TableM.FKey_2 TableM.FKey_1'> <cols name='Pet_name_id' partOfFkey='TableM.FKey_1' type='String' xmi:id='TableM.Column_1'/> <cols name='Job_name_id' partOfFkey='TableM.FKey_2' type='String' xmi:id='TableM.Column_2'/> <cols name='Job_address_id' partOfFkey='TableM.FKey_2' type='String' xmi:id='TableM.Column_3'/> <cols name='name' type='String' xmi:id='TableM.Column_4' pkeyOf='TableM.Table_1'/> <cols name='age' type='Integer' xmi:id='TableM.Column_5'/> </TableM:Table> <TableM:Table name='Job' pkeys='TableM.Column_6 TableM.Column_7' xmi:id='TableM.Table_2' referenceBy='TableM.FKey_2' fkeys='TableM.FKey_3'> <cols name='name' type='String' xmi:id='TableM.Column_6' pkeyOf='TableM.Table_2'/> <cols name='address' type='String' xmi:id='TableM.Column_7' pkeyOf='TableM.Table_2'/> <cols name='Person_name_id' partOfFkey='TableM.FKey_3' type='String' xmi:id='TableM.Column_8'/> </TableM:Table> <TableM:Table name='Pet' pkeys='TableM.Column_9' xmi:id='TableM.Table_3' referenceBy='TableM.FKey_1'> <cols name='name' type='String' xmi:id='TableM.Column_9' pkeyOf='TableM.Table_3'/> <cols name='age' type='Integer' xmi:id='TableM.Column_10'/> <TableM:FKey references='TableM.Table_1' xmi:id='TableM.FKey_3' cols='TableM.Column_8' owner='TableM.Table_2'/> <TableM:FKey references='TableM.Table_2' xmi:id='TableM.FKey_2' cols='TableM.Column_2 TableM.Column_3' owner='TableM.Table_1'/> <TableM:FKey references='TableM.Table_3' xmi:id='TableM.FKey_1' cols='TableM.Column_1' owner='TableM.Table_1'/> </xmi:XMI>

XMI de un modelo “Relacional” (Ecore) <xmi:XMI xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance' xsi:schemaLocation='http://gts.inf.um.es/examples/relational ../metamodels/TableM.ecore' xmi:version='2.0' xmlns:xmi='http://www.omg.org/XMI'> <relational:Table name='Person' pkeys='#/0/@cols.3' xmlns:relational='http://gts.inf.um.es/examples/relational'> <cols name='Pet_name_id' type='String'/> <cols name='Job_name_id' type='String'/> <cols name='Job_address_id' type='String'/> <cols name='name' type='String'/> <cols name='age' type='Integer'/> <fkeys references='#/1' cols='#/0/@cols.1 #/0/@cols.2'/> <fkeys references='#/2' cols='#/0/@cols.0'/> </relational:Table> <relational:Table name='Job' pkeys='#/1/@cols.0 #/1/@cols.1' xmlns:relational='http://gts.inf.um.es/examples/relational'> <cols name='address' type='String'/> <cols name='Person_name_id' type='String'/> <fkeys references='#/0' cols='#/1/@cols.2'/> <relational:Table name='Pet' pkeys='#/2/@cols.0' xmlns:relational='http://gts.inf.um.es/examples/relational'> </xmi:XMI>

Ejemplo XMI (UML) <XMI xmi.version="1.2" xmlns:UML="org.omg/standards/UML"> <XMI.header> <XMI.metamodel name="UML" version="1.3" href="UML.xml"/> <XMI.model name=“ejemplo" version="1" href="ejemplo.xml"/> </XMI.header> <XMI.content> <UML:Class name="C1"> <UML:Classifier.feature> <UML:Attribute name="at1“ visibility="private"/> </UML:Classifier.feature> </UML:Class> </XMI.content> </XMI>

JMI (Java Metadata Interface) JMI define un mapping Java para MOF JMI especifica cómo generar automáticamente, para un metamodelo MOF cualquiera, un conjunto de API Java para manipular modelos de ese metamodelo. API que proporciona un mapping MOF-Java Interfaz de programación a MOF. Integración con J2EE.

JMI Las aplicaciones Java cliente pueden usar esta API o un API reflectiva genérica, para interactuar con los metadatos: operaciones de consulta, recorrido, ciclo de vida. Se puede construir un mecanismo para facilitar la interoperabilidad con metadatos genéricos.

Ejemplo JMI

Ejemplo JMI: Interfaz instancia public interface Element extends javax.jmi.reflect.RefObject { public String getName(); public void setName(String newValue); public Node getContainer(); public void setContainer(Node newValue); }

Ejemplo JMI: Interfaz proxy clase public interface AttributeClass extends javax.jmi.reflect.RefClass { public Attribute createAttribute(); public Attribute createAttribute(String name, String value); }

Ejemplo JMI: Interfaz proxy asociación public interface Contains extends javax.jmi.reflect.RefAssociation { public boolean exists(Element element, Node container); public java.util.List getElements(Node container); public Node getContainer(Element element); public boolean add(Element element, Node container); public boolean remove(Element element, Node container); }

Ejemplo JMI: Interfaz proxy paquete public interface XMLModelPackage extends javax.jmi.reflect.RefPackage { public NodeClass getNode(); public AttributeClass getAttribute(); public ElementClass getElement(); public RootNodeClass getRootNode(); public Contains getContains(); }

Repositorio MOF A partir de un metamodelo MOF, un generador crea las APIs, junto con sus implementaciones, que permiten manipular modelos de ese tipo. Posibilidad de código genérico para manipular metadatos del repositorio: mismo código para modelos de distintos metamodelos. Editores genéricos en los repositorios MDR/NetBeans (MOF 1.4 y JMI) RMOF (EMOF 2.0 y Ruby)

Repositorio MOF Modelos UML (M1) Modelos datos (M1) Metamodelos (M2) XMI JMI Modelos UML (M1) Modelos datos (M1) Metamodelos (M2) El modelo MOF (M3)

¿MOF o XML? < xml version = “1.0” encoding = “UTF-8”? > <! ELEMENT TABLA (NOMBRE, COLUMNA+)> <!ELEMENT NOMBRE (#PCDATA)> <!ELEMENT COLUMNA (NOMBRE)>

OCL (Object Constraint Language ) Lenguaje declarativo para añadir información a los modelos UML: restricciones, invariantes, queries,.. Estándar del OMG Versión actual OCL 2.0

OCL (Object Constraint Language ) Lenguaje de especificación para escribir expresiones sobre modelos UML, p.e. queries, reglas de derivación de atributos, el cuerpo de operaciones de consulta, pre y postcondiciones o el invariante, guardas. Extiende la potencia expresiva de UML y permite crear modelos más precisos y más completos. Es tipado, cada expresión OCL tiene un tipo. Utilizado para escribir las restricciones

OCL (Object Constraint Language ) ¿Por qué usar OCL? Limitaciones de los lenguajes (diagramas) para crear modelos precisos y completos. context Vuelo inv: pasajeros -> size() <= avion. númeroPlazas

OCL: Características Lenguaje de restricciones y de consulta Lenguaje formal basado en teoría de conjuntos y lógica de predicados pero notación fácil de usar. Fuertemente tipado Tipos de modelos UML Modelos validados antes de la ejecución Lenguaje declarativo

OCL Contexto de una definición Tipo contextual Especifica el elemento de un modelo UML para el que se define una expresión OCL. Normalmente una clase, una interfaz o una operación Tipo contextual Es el tipo del objeto para el que se evaluará una expresión OCL: una clase, interfaz, tipo de dato o componente. Una expresión OCL se evalúa siempre para una única instancia del tipo contextual.

Ejemplo: Modelo “Royal and Loyal”

Navegación Los extremos de las asociaciones pueden ser utilizados para navegar de un objeto a otro: Notación Punto. context CustomerCard inv self.owner.programs -> size() > 0 Customer LoyaltyProgram CustomerCard programs 0..* cards owner 1

Navegación : Tipos Contexto CustomerCard Tipo(self.owner) = Customer Tipo(self.owner.programs) = Set(LoyaltyProgram) Contexto Customer Tipo(self.programs) = Set(LoyaltyProgram) Tipo(self.cards) = Set(CustomerCard) Contexto LoyaltyProgram Tipo(self.Customer.programs) = Bag(CustomerCard)

OCL: Query context CustomerCard::getTransactions (from: Date, until: Date) : Set(Transaction) body: transactions -> select (date.isAfter(from) and date.isBefore(until)) context LoyaltyProgram::getServices():Set(Service) body: partners.deliveredServices->asSet() context LoyaltyProgram::getServices(pp: ProgramPartner) : Set(Service) body: if partners ->includes(pp) then pp.deliveredServices else Set() end

OCL: Invariantes context Customer inv ofAge: age >= 18 context CustomerCard inv checkDates: validFrom.isBefore(goodThru) inv ofAge: owner.age >= 18

OCL: Colecciones (Operaciones Estándar) Operación Descripción count(obj) Número de ocurrencias de un objeto obj en la colección excludes (obj) True si obj no pertenece a la colección excludesAll(c) True si ningún objeto la colección c pertenece a la colección includes(obj) True si obj pertenece a la colección includesAll(c) True si todos los objetos c pertenecen a la colección isEmpty True si la colección está vacía. notEmpty True si no está vacía. size() Número de elementos sum() Suma de todos los elementos

OCL: Colecciones (operaciones con significado diferente) = y <> asBag(), asSet(), asOrderedSet(), asSequence() Conversión de un tipo en otro including(obj) Retorna una nueva colección que incluye a obj excluding(obj) Retorna una nueva colección en la que se ha eliminado obj flatten() Trasforma una colección de colecciones en una única colección union (col), intersection (col)

OCL: OrderedSet y Sequence append(objeto) at(index) first() last() insertAt(objeto) indexOf(objeto)

OCL: Iteradores col -> isUnique (expr) col -> iterate (…) select Retorna true si expr tiene el mismo valor para cada elemento col -> iterate (…) Iterar sobre todos los elementos select reject collect forAll exist sortedBy(expr)

OCL: Colecciones context LoyaltyProgram inv minServices: partners.deliveredServices -> size() >=1 context Customer inv sizesAgree: programs ->size() = card -> select(valid = true)->size() inv: participants -> forAll (age() <= 70) inv: self.participants -> forAll (c1, c2 | c1 <> c2 implies c1.name <> c2.name) inv: points>0 implies transactions->exist(t | t.points > 0)

OCL: Colecciones context LoyaltyAccount inv: transactions -> collect (points)->exist( p : Integer | p = 500) inv: transactions.points -> exist(

OCL: Pre y Postcondiciones context LoyaltyAccount::enroll(c : Customer) pre – not (participants -> includes (c)) post participants = participants@pre ->including(c) context LoyaltyAccount::isEmpty(): Boolean pre -- ninguna post result = (points = 0) context Customer::birthdaysHappens() post: age = age@pre + 1 context Person::birthdaysHappens()

Perfiles UML (Profiles) En vez de definir un nuevo metamodelo MOF se puede extender un metamodelo existente. Extensibilidad de los metamodelos (DSL) Si el metamodelo elegido es UML Extender el metamodelo UML Definir un perfil UML Mecanismo definido en el propio metamodelo de UML

Extensión del metamodelo UML::Class CM::Component transational: bool Necesidad de herramientas que permitan: Manejar el metamodelo Asociar una sintaxis concreta a la extensión

Perfiles UML UML es una familia de lenguajes Lenguaje core + Perfiles Un perfil define una extensión de UML mediante la especialización de un subconjunto del metamodelo de UML. Un perfil define una forma específica de usar UML para un dominio concreto: EJB, aplicaciones web, CORBA, modelado del negocio,.. Agrupación de un conjunto de estereotipos, valores etiquetados y restricciones, con su correspondiente notación. Usados como lenguajes de los PSM en MDA

Perfiles UML Un perfil se define mediante un modelo formal UML. • Estereotipos pueden extender cualquier elemento del metamodelo para definir nuevas meta-clases, meta-asociaciones,.. • Valores etiquetados definen los atributos de un estereotipo. • Restricciones semánticas en OCL completan la definición del perfil. • Se puede asociar una representación gráfica a cada estereotipo.

Perfiles UML Metamodelo de UML 2.0 <<stereotype>> CM::Component transational: bool <<metaclass>> UML::Class Extensión Metamodelo de UML 2.0 Un perfil es una especialización de UML::Package Un estereotipo es una especialización de UML::Class Un perfil contiene estereotipos Una extensión es una especialización de UML::Association cuyos extremos son una clase y un estereotipo. Un perfil se define sobre un metamodelo referencia (UML u otro perfil) y no puede modificar las definiciones existentes. Las herramientas actuales no soportan bien los perfiles.

<<profile>> EJB context Bean inv: realization->realizer -> collect( ili.hasStereotype(“”Remote”)->size ()) == 1 && realization->realizer -> collect( ili.hasStereotype(“”Home”)->size ()) == 1 UML::Component <<stereotype>> Bean <<stereotype>> EntityBean <<stereotype>> SessionBean state: StateKind UML::Artifact <<stereotype>> Bean <<enumeration>> StateKind stateful stateless <<stereotype>> Remote UML::Artifact <<stereotype>> Home

Perfiles del OMG

Perfiles del OMG Perfiles definidos por OMG: CORBA y CCM EDOC (Enterprise Distributed Object Computing) EAI (Enterprise Application Integration) Planificación, Prestaciones, y Tiempo Otros perfiles estándares de-facto: EJB Java C#

Pasos para definir un Perfil UML Definir, si no se dispone, el modelo conceptual de la plataforma o del dominio de aplicación. Definir un estereotipo para cada elemento del modelo conceptual; hay que elegir el elemento del metamodelo UML a extender. Definir como valores etiquetados los atributos de los elementos del modelo conceptual. Definir las restricciones del dominio como restricciones del perfil.

Ejemplo de definición de Perfil UML “Modelar conexiones entre elementos de un sistema de información conectados según la topología estrella” context MyTopology::MainNode inv : self.localnodes ->forAll (n : Node | n.location = self.location) inv: self.target ->forAll (n : MainNode | n.location <> self.location )

Ejemplo de definición de un Perfil UML «profile» TopologyProfile «stereotype» Node MainNode location: String «metaclass» Class Association Egde LocalEdge

Ejemplo de definición de un Perfil UML context UML::InfrastructureLibrary::Core::Constructs::Class inv : self.isStereotyped(“Node”) implies self.connection -> select (isStereotyped(“LocalEdge”)) -> size = 1 and self.connection -> select (isStereotyped(“Edge”)) ->isEmpty context UML::InfrastructureLibrary::Core::Constructs::Association inv : self.isStereotyped(“LocalEdge”) implies self.connection -> exists (participant.isStereotyped(“MainNode”) and multiplicity.min=1 and multiplicity.max=1) self.connection -> select (participant.isStereotyped(“Node”) or participant.isStereotyped(“MainNode”) ) -> forAll (n1, n2 | n1.location = n2.location) inv : self.isStereotyped(“Edge”) implies self.connection -> select(participant.isStereotyped(“Node”))->isEmpty and self.connection->select(participant.isStereotyped(“MainNode”) ) -> forAll (n1, n2 | n1.location <> n2.location)

Cuestiones de metamodelado ¿Cómo expresar que las instancias de cierta metaclase Entidad deben implementar cierta interfaz IA? Entidad context Entidad inv: realization -> exist(realizer oclTypeOf IA) Entidad {subsets realization} IA Entidad IA

Cuestiones de metamodelado Varios elementos del metamodelo deben tener un nombre <<interface>> ElementoConNombre Entidad Nodo Servicio

Cuestiones de metamodelado Varios elementos dependen de una interfaz IA porque invocan sus operaciones Entidad * * IA Entidad IA

Cuestiones de metamodelado Un elemento Entidad tiene un atributo ID de tipo String. context Entidad inv: self.attributes -> select (name =“ID”)->size == 1 && self.attributes -> select (name =“ID”)->forAll( type.name = “String”) Entidad Entidad ID: String

Ejemplo de metamodelo DSL para crear “modelos de características” MOF Attribute type: String value: String attributes MOF::Class MOF FM::Feature groups FM::SubFeatureGroup kind FM::GroupKind 1 1 1 n 1 parent n features Feature Model FM::Concept context FM::GroupKind inv: value ==“optional” || value ==“required” value == “alternative” context FM::Concept inv: parent == null

Herramientas y metamodelado Herramientas UML Mayoría no soportan metamodelado Tendencia a soportar perfiles Herramientas que tiene como entrada modelos creados con herramientas UML Entrada es un modelo XMI Validadores, Transformación de modelos, Generadores de código Herramientas de metamodelado Permiten definir metamodelos y generan editores de modelos Tienen su propio lenguaje de metamodelado Metaedit, GME, DSL Tools, XMF