EMF

De wikiPLII
Saltar a: navegación, buscar

Eclipse Modeling Framework (EMF) & Eclipse Modeling Framework Technology (EMFT)

EMF
Miembros Juan Manuel Otero Albiol
Andrés Quintana López
Francisco Torrejón Colón
Curso Académico 2012/2013
Tipo de Contribución Informe Técnico
Keywords EMF, EMFT, Eclipse
logo EMF‎


Contenido

Resumen

En este Informe técnico queremos profundizar sobre el uso, y las distintas opciones que nos ofrece Ecplipse Modeling Framework (EMF) así como Eclipse Modeling Framework Technology (EMFT), con una importante base teórica además de la realización de algunos casos de estudio que permitan ver con más claridad los conceptos que se tratan.

Eclipse Modeling Framework, EMF, constituye el núcleo de la plataforma Eclipse para el desarrollo dirigido por modelos. Centraremos nuestro estudio teórico en este framework, ya que es muy útil para el desarrollo de metamodelos, mediante una sintaxis abstracta, y también permite generar automáticamente clases de implementación en código para los elementos de nuestros metamodelos.

Describiremos los componentes más importantes de los que se componen EMFT, que es un proyecto que incluye nuevas tecnologías que amplían o complementan a EMF, como pueden ser CDO, Compare, Model Query, Net4j, SDO, Teneo, EEF, Ecore Tools, etc.

Desarrollaremos en profundida toda la concerniente sobre EMF (estructura, arquitectura, características, características comerciales)

Y para finalizar realizmos distintos casos de estudio de los componenetes que nos han parecido más interesantes como: EMF, EMF Compare, para comparar dos modelos diferentes y CDO, repositorio de modelos distribuido para los modelos realizados con EMF, todo ello ilustrado para que el proceso sea más fácil.

Introducción

Eclipse EMF se puede utilizar para modelar nuestro modelo de dominio. EMF tiene una distinción entre el meta-modelo y el modelo real. (El meta-modelo describe la estructura del modelo) Un modelo es entonces la instancia de este meta-modelo. EMF proporciona un marco para almacenar la información del modelo, el formato por defecto que utiliza es XMI (XML Metadata Interchange).

EMF permite crear el meta-modelo a través de diferentes medios, por ejemplo, XMI, anotaciones Java, UML o un esquema XML.

Una vez que el EMF meta-modelo se especifica se pueden generar las implementaciones (de Java) correspondientes de este modelo. EMF ofrece la posibilidad de que el código generado puede ser extendido de forma segura.

Una de las razones para usar EMF es automatizar algunas de las cosas repetitivas que los desarrolladores tienen que hacer, como pueden ser getters, setters y notificación. EMF puede importar modelos desde esquemas, UML, o inclusive código Java con anotaciones (usando el tag @model de Javadoc). FMF puede generar esquemas o código Java con anotaciones, etc.

¿Qué nos aporta modelar con EMF?

En primer lugar, nos aporta un diseño previo, que una vez concretado, genera código completamente funcional y sin errores, basado en nuestro modelo. Además nos aporta listeners sobre las clases y atributos modelados y por tanto contamos con un sistema de comunicación basado en eventos para controlar todo lo que está ocurriendo en nuestro modelo. EMF nos genera, además, los test, que tendremos que ir completando a medida que avanza nuestra aplicación.

Como objetivos nos planteamos ofrecer un informe de lo que nos puede ofrecer Eclipse Modeling Framework y sus herramientas, de todos aquellos conceptos que no se han visto en clases, ofreciendo un estudio profundo con más detalles de EMF Compare y CDO. De manera que un usuario que no tenga muchos conocimientos de todas estas herramientas pueda usarlo partiendo de cero.

Empezaremos esta Wiki describiendo la metodología y planificación que hemos llevado a cabo en la elaboración de nuestro informe, a continuación definiremos en que consisten cada una de las herramientas complementarias de EMF (EMF Core, CDO, Compare, Model Query...).

Continuaremos describiendo en que consiste EMFT y las herramientas de las que se compone (EEF, Ecore Tools, Mint) y su comparativa con EMF.

Luego pasaremos a describir conceptos teóricos sobre EMF, como es su arquitectura, características generales, comerciales) y posteriormente uno de los puntos importantes como son los Casos de estudio de EMF, Compare y CDO.

Para finalizar las referencias que hemos usado para nuestro informe.

Metodología

Modelo De Desarrollo Iterativo e Incremental

La metodología de desarrollo utilizado en este proyecto será una metodología Iterativa e incremental, se ha decidido utlizar esta metodología por ser la que mas se adecúa a nuestro tipo de estudio, ya que nos podemos beneficiar de los aspectos más favorables de los dos modelos de desarrollo, algunos de las razones que nos ha llevado a tomar dicha decisión han sido:


   - Cada iteración está acotada en el tiempo.
   - Reduce riesgo de fallos, ya que un fallo afecta solamente a la iteración presente.
   - Aumenta la facilidad de respuesta ante cambios, ya que estos se pueden añadir o adaptar en la siguiente iteración del producto.
   - A partir de la evaluación se planea el siguiente incremento y así sucesivamente.
   - Es interactivo por naturaleza
   - En lugar de entrega del sistema en una sola entrega, el desarrollo y la entrega están fracturados bajo incrementos, con cada incremento 
     que entrega parte del total requerido.
   - El tiempo de espera para tener algo que evaluar del proyecto es mucho menor que en otras metodologías.   
   - Se evitan proyectos largos y se entrega “Algo de valor” a los usuarios con cierta frecuencia

Planificación

Mediante los diagramas se detallan las tareas a realizar durante los diferentes puntos de control y la planficación a seguir a lo largo del estudio y las distintas fases del Informe técnico a desarrollar.

Planificacion.png

Planificación temporal

Informe Técnico

Esta sección seguirá el esquema del desarrollo del estudio de nuestro framework, que son los puntos que a continuación detallamos, definición, arquitectura, componentes y características.

  • EMF constitute el núcleo de la plataforma Eclipse para el desarrollo dirigido por modelos.
  • Mediante una sintaxis abstracta, permite generar automáticamente clases de implementación en código para los elementos de nuestros metamodelos.
  • Uno de sus objetivos es la generación de código para crear aplicaciones Java basadas en simples definiciones del modelo.
  • Diseñado para hacer el modelado práctico y útil para la corriente principal programador Java, EMF unifica tres tecnologías importantes como Java, XML y UML.


Arquitectura

En este punto trataremos de profundizar en la arquitectura del framework de Eclipse EMF. Pero antes de hablar de ello, sería adecuado hacer una introducción al proyecto de Eclipse que se encarga del desarrollo de plug-in, para luego tratar especificamente el de nuestro framework.

La arquitectura de ejecución de Eclipse se basa en el concepto de Micro-Kernel, en donde toda la funcionalidad es suplida por plug-ins. Los puntos de extensión de Eclipse definen los colectores para las nuevas contribuciones.

El siguiente dibujo nos muestra la forma como se pueden integrar los diferentes plug-ins en Eclipse.

DIBUJO1.png

Al iniciar la plataforma de ejecución de Eclipse, descubre los nuevos plug-ins instalados en el disco, hace parejas entre las extensiones y los puntos de extensión, construyen un registro global de plug-ins y registra todo en el disco para la próxima vez.

PDE (Plug-in Development Environment) se enmarca dentro de Eclipse Top-Level Project. Provee vistas y editores que hacen fácil y distraida la construcción de plug-ins para Eclipse. Con PDE se puede crear el archivo de manifiesto de plug-ins llamado plugin.xml. En este archivo se especifican la identificación del plug-in, la localización del código, otros plug-in necesitados, los puntos de extensión marcados y las extensiones para ser validadas. En resumen, PDE hace que la integración de plug-ins sea fácil y divertida.

Dos sub-proyectos componen PDE:

  • PDE Build: se encarga de facilitar la automatización de los procesos de construcción de aplicaciones
  • PDE User: inteface que trabaja las contribuciones sobre el Workbench para el desarrollo de plug-in

En la siguiente imagen se aprecia como PDE esta en ejecución, invocando y depurando otro Workbench de Eclipse

  DIBUJO2.png

Ahora pasararemos a ver de manera mas detallada la arquitectura de nuestro framework EMF, el cual es formado por tres componentes. Podemos decir que son tres niveles en forma de pirámide de la arquitectura, como vemos en el siguiente gráfico.

DIBUJO3.png
  • EMF: El núcleo de EMF, que contiene un meta-modelo de UML llamado Ecore para describir y soportar la ejecución de modelos incluyendo notificación de cambios, servicios de persistencia con serialización en XMI y una muy eficiente API reflexiva para la manipulación de objetos EMF.
  • EMF.Edit: framework de Eclipse que incluye clases genéricas reutilizables para la construcción de editores para los modelos de nuestro framework EMF. Ahora entraremos un poco mas a fondo en sus características:
  - Clases de contenidos y etiquetas, el apoyo de propiedad de origen y otras clases de conveniencia que permitan que los modelos EMF se   
    muestren usando estándar de escritorio (JFace) hojas de propiedades.
   
  - Cuadro de mando, incluyendo un conjunto de clases genéricas de comandos de ejecución para la construcción de editores que soportan de 
    manera completamente automática el "deshacer" y "rehacer".
   
  - Un generador de código capaz de generar todo lo necesario para construir un completo editor de plug-in para su modelo EMF. Está 
    adeuadamente estructurado para que se ajuste al estilo recomendado para los editores de Eclipse. Además, puede personalizarse el código 
    a gusto del programador, sin perder la conexión con el modelo.
  • EMF.Codegen: es capaz de generar todo lo necesario para construir un completo editor de un modelo de EMF. Incluye una interfaz gráfica de usuario desde en el que las opciones de generación de código puede ser especificadas, y los generadores pueden ser invocados. La instalación de generación aprovecha el JDT (herramientas de desarrollo de Java), componente de Eclipse.

Características generales de EMF

  • Facilidad de uso: funciona perfecta y sencillamente en Eclipse. Uso intuitivo, aunque necesita conocimientos en Java y desarrollo de herramientas CASE. El editor y sus funcionalidades son bastante amenas.
  • Despliegue e internacionalización: la herramienta funciona en cualquier plataforma y su lenguaje es el mas común y frecuente, el inglés.

Características en Tiempo de ejecución:

  • Metadata enriquecida.
  • Serialización y deserialización XMI.
  • Monitoreo de cambios de modelo.
  • Framework de validación.

Características de Generación:

  • Plantillas JSP personalizables con JET (Java Emitter Templates).
  • Se puede ejecutar desde línea de comandos, con ANT o integrada con Eclipse.

Características comerciales

  • Difusión y madurez: tiene varias versiones y en la actualidad constituye la base de un amplio conjunto de proyectos desarrollados alrededor de UML. Su documentación es bastante amplia e interesante.
  • Costo: herramienta de código abierto, que tiene una licencia de tipo LGPL, al igual que su documentación, se puede descargar sin ningún costo y utilizar para integrar en entornos de desarrollo de modelos y otros proyectos.
  • Soporte: la comunidad de Eclipse tiene una robusta estructura para el desarrollo de sus proyectos, aunque no tiene una estrategia de soporte directa, se pueden enviar bug, problemas y sugerencias al equipo de desarrolladores del proyecto, que serán revisados por una concurrida comunidad muy bien organizada.




Eclipse Modeling Framework Technology (EMFT)

Proyecto que reúne nuevas tecnologías que amplían o implementan a EMF, luego EMFT complementa a EMF. Con el tiempo, los proyectos se graduarán de EMFT en proyectos de modelado, tales como EMF , MDT o M2T.

De muchas de las tecnologías de EMFT hemos hablado ya en los puntos anteriores, a continuación destacamos otras que también son importantes.

EEF

Proporciona un componente generativo e infraestructura de tiempo de ejecución para el desarrollo de componentes avanzados para facilitar la edición de los modelos basados en EMF. Se compone de tres partes:

Entre alguna de sus características encontramos:

  • Contiene un conjunto de widgets avanzados y una arquitectura genérica y extensible.
  • Metamodelos estándar que permite la definición de modelos para parametrizar los componentes reales de edición que van a ser generados.
  • Un módulo Acceleo que genera una arquitectura estándar para extender el tiempo de ejecución del marco.

Los elementos generados se pueden integrar en cualquier componente de SWT/JFace y de ese modo ayudar en la edición del modelo.

Propiedades EEF

Ecore Tools

El componente Ecore Tools ofrece un entorno completo para crear, editar y mantener modelos de herramientas. Este componente hace mas facil y agradable la manipulación de modelos Ecore con un editor gráfico y puentes con muchas mas herramientas diferentes que existen (validación, búscqueda, comparación, generadores, etc). El editor gráfico Ecore implementa un multi-diagrama de apoyo, una vista personalizada propiedades por fichas, la retroalimentación de validación, las capacidades de refactorización, y muchas propiedades mas. El objetivo a largo plazo es proporcionar el mismo nivel de servicios al igual que JDT para Java. Sus principales características son:

  • Modelo vista de esquema orientado: elementos del modelo en el área del diagrama para mostrar su representación gráfica.
  • Propiedades con pestañas "Ver": proporcionar capacidades avanzadas para editar.
  • Ejemplo de diagrama de modelo Ecore.ecore: mostrar las capacidades del editor a través de este modelo

Ecore Tools

Mint

Componente propuesto de código abierto en EMFT, cuyo objetivo es mejorar la experiencia de los usuarios en el desarrollo de soluciones basadas en EMF. Esto es, en la mayor parte de los casos, gracias a la empresa de herramientas de Java, con determinadas mejoras en EMF.

Está en fase de propuesta de proyecto y pendiente de escrito de intenciones y alcances del mismo. Solicitara la participación adicional y el aporte de la comunidad Eclipse.

El fondo de este componente viene con editores básicos estructurados gracias a SDK EMF, que permiten el desarrollo de modelos Ecore y generación de código relacionado con Java. Además, apoya la creación de modelos EMF Ecore de Javadoc anotado código fuente.

La funcionalidad de este componente destaca por:

  • Decoración modelo de Java
  • Filtros estructurados de visor de código generado por Java
  • Integración mediante Java
  • GenModel a Java
  • Editor Java con mejoras

Mint se basa en la funcionalidad proporcionada por el proyecto EMF sí mismo. Se prevé que Mint podría beneficiarse de las contribuciones realizadas por el componente de búsqueda, especialmente en el área de la integración de búsqueda Java.

La generación de código incremental basado en Java, por otra parte, puede ser posible con un procesador de anotación utilizando la funcionalidad JET2.Es necesario determinar si esto es factible y cómo podría aplicarse.

En general, las características y las mejoras aportadas por Mint deberían ser aplicable a otros proyectos que basan sus modelos en todo Ecore.

EMF Modelo de características

Proyecto de código abierto bajo la Tecnología EMFT.

Durante el año pasado el modelo de características se ha convertido en el "estándar" para la gestión de la variabilidad en el campo de la Línea de Productos de Software. Son fáciles de entender y proveen una manera genérica para representar la información variabilidad, independiente de un dominio de aplicación específico. Varios proyectos independientes que utilizan la plataforma Eclipse han definido cada uno su propio metamodelo para los modelados de función. Aunque estos metamodelos tienen considerables diferencias estructurales, su semántica básica son similares. Definirá un modelo de representación estándar de los modelos de funciones dentro de la plataforma Eclipse. La intención es proporcionar una representación uniforme para obtener información sobre la variabilidad de herramientas basadas en Eclipse Modeling Framework. Esto permitirá un acceso fácil y consistente a la información relacionada con la variabilidad, como puntos de variación y decisiones variante, en DSL, las transformaciones M2M, y otros contextos en que se produce variabilidad información o consumido.

Los objetivos del proyecto EMF modelo de características son las siguientes:

  • Definir el modelo de características
  • Definir un marco de evaluación motor extensible y proporcionar una implementación ejemplar
  • Proporcionar editores extensibles y visualizaciones para los modelos

Herramientas Complementarias y Comparativa

EMF (Core)

EMF core, es el meta-modelo principal de EMF, más concretamente es un framework de modelado así como de generación de código para herramientas de construcción y otras aplicaciones basadas en un modelo de datos estructurado. Proporciona herramientas y soporte de ejecución a partir de una especificación del modelo descrito en XMI o EMF para producir un conjunto de clases Java para dicho modelo, un conjunto de clases de adaptadores que permiten la visualización y comando de edición basada en el modelo, y un editor básico.

Los modelos se pueden especificar mediante anotaciones Java, los documentos XML, o las herramientas de modelado como Rational Rose.

CDO

logo CDO‎

Connected Data Objects, CDO es un repositorio de modelos distribuido para los modelos realizados con EMF modelo y modelos de metadatos, así como un entorno de ejecución de modelo con un enfoque en los aspectos ortogonales como la escalabilidad del modelo, transaccionabilidad, persistencia, distribución, consultas y más. CDO es a la vez un desarrollo en tiempo repositorio de modelos y un marco de persistencia en tiempo de ejecución.

Posee una arquitectura de 3 capas de soporte basados ​​en EMF-aplicaciones cliente, ofreciendo un modelo de servidor de archivo central y el aprovechamiento de los diferentes tipos de almacenamiento de datos como bases de datos relacionales, bases de datos de objetos y sistemas de archivos.

Este almacenamiento con migraciones entre JDBC, Hibernate, MongoDB o DB4O es perfecta para aplicaciones de CDO.

El valor predeterminado de cliente / servidor de protocolo de comunicación se lleva a cabo con la Plataforma Net4j que veremos a continuación.

EMF Compare

Esta herramienta proporciona soporte genérico para cualquier tipo de metamodelo para comparar y combinar modelos. Los objetivos de este componente son proporcionar una implementación genérica estable y eficiente de comparación de modelos, para proporcionar un marco extensible para necesidades específicas.

En pocas palabras, este proyecto ofrece: un marco que se puede reutilizar y extender fácilmente, para comparar instancias de nuestros modelos y una herramienta integrada en el IDE de Eclipse para ver las diferencias y así poder combinarlos.

Model Query

Es un modelo de consulta y recuperación elementos en nuestro modelo de manera rápida y eficiente a la vez que bien estructurado.

Alguna de las siguientes interfaces o clases más relevantes que admiten las consultas son:

  • Para el ámbito de las búsquedas en una consulta utiliza la interfaz IEObjectSource.
  • La clase SELECT implementa una plantilla que hace la iteración sobre los elementos del modelo, recogiendo los elementos resultantes en un objeto QueryResultSet y lo devuelve a la persona que llama. La clase FROM representa los elementos a buscar.
  • Where aplica las condiciones de búsquedas a realizar.
  • A traves de QueryResultSet obtenemos el conjunto de elementos devueltos por una consulta realizada anteriormente.

También existe Model Query 2 que proporciona una búsqueda y recuperación de elementos del modelo EMF, pero con un consumo mínimo de recursos durante la misma, ya que utiliza un mecanismo de índice incorporado para acelerar las consultas.

Net4j

logo Net4j‎

Net4j es un sistema cliente-servidor extensible. Está basado en el tiempo de ejecución de Eclipse y Spring Framework. Se puede extender la pila de protocolos con los plugins de Eclipse que proporcionan protocolos de aplicación. Net4j realiza un enfoque en el rendimiento y la escalabilidad y se caracteriza por tener un núcleo rápido y asincrónico y no bloquear el búfer del núcleo de multiplexación.

Net4j fue desarrollado originalmente para apoyar la tecnología de CDO para los modelos distribuidos EMF comunes y persistentes, pero también puede multiplexar sus propios modelos suministrados por el usuario a través de protocolos de aplicación de la conexión de socket.

SDO

Service Data Objects no se detienen en la abstracción de datos, a diferencia de otros modelos de integración de datos. El servicio de datos de objetos de marcos también incorpora un buen número de patrones J2EE y prácticas mucho mejores. SDO apoya un modelo de programación desconectado. El modelo de programación establece patrones de uso que permiten la separación limpia de cada una de estas características.

En resumen, podemos definir SDO como un marco para el desarrollo de aplicaciones de datos, que incluye una arquitectura y una API. Service Data Objects simplifica el modelo de programación de datos J2EE y datos abstractos en una arquitectura orientada a servicios (SOA), y unifica los datos de desarrollo de aplicaciones, soporte, e integra XML.

Teneo

Teneo es una solución de EMF para la persistencia de base de datos usando Hibernate o EclipseLink. Apoya la creación automática de los EMF a asignaciones relacionales. Objetos EMF se puede almacenar y recuperar mediante consultas avanzadas (HQL o EJB-QL).

Características

  • Herramienta poderosa de combinación: Teneo integra EMF con las soluciones de persistencia existentes, combinando la funcionalidad de generación de código basado en modelos con el poder de almacenamiento.
  • Enfoque Flexible: Teneo automáticamente asigna modelos de esquema de base de datos relacionales. El mapeado puede ser totalmente controlado, se invalida y se extienden con anotaciones JPA en el modelo en sí o en un archivo XML independiente.
  • Extensa Cobertura : Teneo soporta persistencia de prácticamente todos los modelos Ecore out-of-the-box, sin trabajo manual adicional en el mapeo.
  • Soluciones de servidores secundarios: Teneo es principalmente orientado para entornos orientados a servidores con lógica empresarial. Especialmente servicios web que se pueden beneficiar de la serialización XML, combinado con un modelo-relacional automático de mapeado y la persistencia de base de datos en tiempo de ejecución.


Casos de Estudios

En nuestro caso estudio se entrará a comparar entre las diversas herramientas que utilizan EMF, las mas representativas serían:

  • EMF
  • EMF Compare
  • CDO

Caso de estudio EMF: Creación nuevo proyecto

En este apartado describiremos con todo tipo de detalles los distintos pasos a realizar para crear un proyecto EMF desde cero.

  • New --> Other --> Empty EMF Project
  • Le introducimos el nombre para nuestro proyecto, por ejemplo CasoDeEstudio
  • Se nos crea el proyecto con los siguientes directorio
    • src: Contiene todo nuestro código
    • model: Contiene el metamodelo y modelos
    • Click derecha en la carpeta model y --> New --> Other --> Ecore Modeling Framework --> Ecore Model y le asignamos un nuevo nombre.
    • Creamos nuestro modelo nuevo
    • Podemos modificar nuestro metamodelo usando directamente la sintaxis XML que nos proporciona el fichero .ecore. Podemos abrirlo pulsando en el fichero .ecore: open with -> text editor
XML metamodelo
  • Damos a Validate para validar el modelo y comprobar que no tiene errores.
  • Luego crearemos un modelo de generación de código con File → New → EMF Generator Model (le ponemos el mismo nombre que al anterior pero con extensión .genmodel)
  • Hacemos doble click sobre el nuevo fichero y le damos a Generate All
  • Generamos el código fuente para la creación de nuestro editor de modelos.
  • Se crean lo siguiente:
    • Interfaces, factorías y otras clases para la edición del editor.
    • Implementación del código en lenguaje java de los elementos del metamodelo creado.
    • En definitiva se crean:
      • Código del Modelo
      • Código edición edit
      • Código editor
      • Código test.


Código generado:

  • Existe tres niveles de generación de código que son compatibles:
    • Nivel de Modelo: Provee interfaces Java y clases de implementación para todas las clases de un modelo, adicionalmente una factoría y un paquete de manejo de meta-datos
    • Nivel de Adaptadores: Genera clases de implementación que adaptan las clases del modelo para editar y mostrar
    • Nivel de Editor: Produce un editor de propiedades estructurado que se ajusta e los estilos recomendados por Eclipse EMF y sirve de punto de partida para empezar a personalizarlos

Código generado del Modelo:

Se crean los siguientes apartados:

thum

  • (estudioemf) -> Se crea automáticamente en nuestro proyecto los siguientes ficheros java, uno por cada clase de nuestro modelo, como podemos ver a continuación:
Codigo generado2.png

Para cada atributo de nuestro modelo se crean los métos get y set. Cada clase tiene también una notificación generada a los observadores del modelo. Esto significa que otro objeto puede adjuntar al modelo y reaccionar a los cambios en el modelo.

  • (estidoemf.impl) -> model.impl: Aplicación concreta de las interfaces definidas en el modelo.
    • EObjectImpl proporcionar una clase que permite a las interfaces y a las clases generadas participar en la notificación de los EMF y frameworks.
  • (estudioemf.util) -> model.util - El AdapterFactory

Ambas contienen implementaciones de las interfaces y las clases adicionales de utilidad.

Cada interfaz generado extiende la interfaz EObject, ésta es la base de todas las clases y en EMF es el equivalente de java.lang.Object.

Cada método generado se etiqueta con @generado. Se puede ajustar manualmente el método que desee para evitar que los EMF sobrescriba el método durante la próxima ejecución, para ello tiene que quitar esta etiqueta.


Código edición/editor de modelo EMF.Edit /Editor

"edit" plug-in contiene adaptadores que proporcionan una visión estructurada basado en comandos de edición de los objetos de nuestro modelo, y el "editor" plug-in proporciona la interfaz de usuario para el editor y el asistente.

Genera proveedores de elementos (item providers) y otras clases necesarias para editar las instancias del modelo, añadiendo soporte para la generación de clases de adaptadores que permiten la visualización y edición de un modelo, e incluso un editor de trabajo. Dicho generador de código (EMF.Edit) no es una herramienta independiente, es sólo otra de las características del generador de modelo.

El código generado es de edición en un solo paquete llamado ". provider", por ejemplo (EstudioEMF.provider) contiene varias ItemProvider y ItemProviderAdapterFactory.

EMF.edit.png

Los ItemProviders son los objetos individuales más importantes en EMF.Edit, sirven para adaptar los objetos del modelo de modo que el objeto modelo puede proporcionar todas las interfaces que necesita para ser visto o editado.

Describimos sus cuatro funciones principales:

  • Implementa el contenido de las funciones provider.
  • Proporciona código fuente de los objetos EMF.
  • Sirve para interactuar con los objetos del modelo asociado.
  • Notificaciones de cambios en el modelo.


Esto también creará unas pruebas de plug-in, que contienen esqueletos de prueba JUnit para el ejercicio de las funciones volátiles y operaciones definidas en el modelo. Este modelo no incluye ninguna, pero en general, habrá que llenar los cuerpos de estas pruebas. Las pruebas de plug-in también incluye una clase simple ejemplo que muestra cómo cargar y validar un modelo en una aplicación independiente.

Para finalizar podemos observar en la siguiente tabla un resumen con todos los ficheros generados mencionados anteriormente (Model Code, Edit Code, Editor Code y Test Code):

Tabla Todo Codigo.png




Caso de Estudio de EMF Compare

En este apartado describiremos el segundo caso de estudio, en dicho caso de estudio se utiliza la extensión EMF Compare. Esta herramienta nos ayuda a comparar distintos modelos para poder identificar sus diferencias, una vez visto las diferencias nos facilita la posibilidad de reutilizar código y poder combinar modelos consiguiendo un ahorro de esfuerzo considerable.

  • 1.En primer lugar instalamos la herramienta EMF Compare en nuestro eclipse desde juno.
Instalación EMF Compare
  • 2.Creamos un proyecto EMF de la misma forma descrita en el anterior caso de uso, hasta generar nuestro modelo:
    • New -> Other --> Ecore Modeling Framework --> Ecore Model
    • Luego crearemos un modelo de generación de código con File → New → EMF Generator Model
    • De esta forma, ya tendremos en nuestro caso de uso los archivos Nombre_asignado.ecorediag, Nombre_asignado.ecore y Nombre_asignado.genmodel
    • Como se puede ver en la segunda captura, hemos creado nuestro modelo, para poder compararlo con otro modelo, en este caso lo compararemos tanto con el modelo generado en el primer caso de estudio, como con anteriores versiones de nuestro mismo modelo. En la tercera captura está la estructura detallada generada en el archivo .genmodel
Diagrama del modelo
Estructura

Una vez generado nuestro modelo pasaremos a la comparación en sí.

Comparación con una versión anterior de nuestro modelo

  • 3a.Para poder comparar nuestro modelo con una versión anterior, seleccionamos el modelo, desplegamos el menú con el boton derecho y seleccionamos Compare With y después Local History. Una vez hecho esto seleccionamos la versión anterior con la cual queremos compararla y escogemos entre recurso seleccionado (Selected resource(s) only) o conjunto de recursos (complete resource set(s)). Una vez completado el paso 3a, pasamos al paso 6.
Comparación versión anterior
Selección de versión


Comparación con otro modelo distinto

  • 3b.Importamos el proyecto del cual vamos a comparar su modelo con el generado en nuestro caso de estudio, que será el modelo generado en el primer caso de estudio.
  • 4.En la cuarta captura vemos el modelo a comparar.
Diagrama del modelo a comparar
  • 5.En la quinta captura podemos ver los pasos a seguir para ejecutar la herramienta EMF Compare y seleccionamos los dos modelos que compararemos.
    • Botón derecho en uno de los dos ficheros .ecore --> Compare With --> Each other
Ejecutando EMF Compare
  • 6.En la sexta captura podemos ver, una vez hecho los pasos anteriores, la estructura detalla de los modelos que hemos seleccionado para comparar.
Estructura de modelos a comparar
  • 7.En la séptima captura obtenemos las diferencias encontradas y de forma mas detallada en la captura octava todas estas diferencias desglosadas.
Diferencias encontradas
Diferencias al detalle

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

  • 8.Una vez visto de forma general la herramienta, procederemos a explicarla de forma detallada, analizando su interfaz, funcionamiento, ventajas y uso.
    • ¿Cómo es la interfaz de EMF Compare?

EMF Compare nos proporciona una interfaz clara para poder ver las diferencias encontradas sin necesidad de verlas de forma detallada, aunque siempre es recomendable verlas en detalle, si se quiere hacer un estudio exhaustivo de los cambios. Para realizar la explicación nos basaremos en versiones anteriores de un mismo modelo y así podremos ver mejor como se muestran los tipos de diferencias una a una.

Elementos añadidos

Empezaremos a describir como se muestran los elementos añadidos, como podemos ver en la siguiente captura, se muestra mediante una linea verde que identifican a los elementos añadidos, respecto a la versión anterior del programa. Dicha línea va desde el propio atributo que se encuentra encasillado con un cuadro verde (para poder ser identificado mejor visualmente) hasta el nombre de la clase en la cual se ha añadido el atributo, ya que el atributo antes no existía.

Interfaz Elementos añadidos

Elementos eliminados

Para mostrar los elementos elementos eliminados, EMF Compare lo hace de forma similar a la descrita anteriormente, pero esta vez es una línea roja que va desde la clase donde exístia antes dicho elemento, hasta el elemento eliminado que se rodea de un cuadro de color rojo, justo arriba de la forma visual, se encuentra las diferencias descritas en forma de árbol para poder observarlas con mas detalle.

Interfaz Elementos eliminados

Elementos modificados

En el caso de los elementos modificados los dos elementos quedan encuadrados con una línea de color azul de manera que hace fácilmente visible los elementos implicados.

Interfaz Elementos modificados

Esta interfaz como hemos podido ver es muy intuitiva, permite de una forma rápida poder identificar las diferencias o cambios que existen los modelos y poder decidir de que manera actuar posteriormente.

    • ¿De que fórma nos muestras los diferencias entre un modelo y otro EMF Compare?

En primer lugar mostraremos si al comparar dos modelos la herramienta es capaz de identificar una modificación en una estructura, como puede ser la modificación en el nombre de la clase y de que manera es capaz de interpretarlo.

Interpretación cambios

Como se puede ver en la anterior captura la herramienta gestiona de manera correcta el cambio de nombre y lo interpreta como una modificación de nombre y no como una modificacion de estructura interpretandola como una clase nueva creada.Este hecho es de importancia ya que nos permite poder comparar modelos con estructuras similares pero con diferentes nombres en sus clases y atributos.

Ahora vamos a poder comparar en el modelo varias modificaciones, elementos eliminados y elementos creados, veremos en primera instancia su interfaz visual y despues podremos estas diferencias en código, donde también podremos indentificar fácilmente las diferencias.

Interfaz Visual
Interfaz Visual

Vemos que identifica como modificaciones (línea azul) el cambio tanto de nombre de clase, como de nombre de atributo, los dos atributos eliminados identificados con la linea roja tanto apellidos del autor como direccion de la editorial, y el atributo añadido descripción con linea verde, todos ellos indicados en sus correspondientes clases.

A la derecha vemos todas estas diferencias de forma detallada en forma de árbol donde podemos observar y clickear en las modificaciones para identificarlas de manera rapida.

Otra de las características interesantes que ofrece EMF Compare es la posibilidad mediante su interfaz visual de poder sobreescribir el código tanto de izquierda a derecha como de derecha a izquierda, es decir tanto de una versión del modelo como de la otra pudiendo (con esto al comparar los dos modelos quedarnos con el que nos ofrezca mejor solución y sobreescribir el otro).Lo explicaremos con mas detalle a continuación:

Sobreescribir código
1. Mover a la anterior diferencia.                                       2. Mover a la siguiente diferencia. 
3. Combinar la diferencia actual de derecha a izquierda                  4. Combinar la diferencia actual de izquierda a derecha
5. Combinar todas las diferencias no conflictivas de dcha a izq          6. Combinar todas las diferencias no conflictivas de izq a dcha

Esto nos permite poder sobreescribir el código que queramos y en la dirección que queramos de una forma fácil ya que con la opción de "combinar la diferencia actual", la diferencia que estemos marcando en ese momento se puede trasladar al código contrario. Y si escogemos "Combinar todas las diferencias no conflictivas" podemos trasladar el código entero de una versión a otra con facilidad.

Una vez que hemos explicado todo lo conciernente a su interfaz visual ahora pasaremos a ver como gestiona las diferencias EMF Compare en código, vamos a ver que lo gestiona de manera muy similar a la visual, identificando las diferencias y resaltándolas para su poder comparar los códigos y actuar en consecuencia.Ahora veremos ejemplos tanto de modificación, eliminación y de elementos añadidos.

Empezamos mostrando los cambios que hemos hecho en autor estos cambios son dos modificaciones en el nombre de la clase y en uno de los atributos y la eliminación de otro atributo como son los apellidos del autor.

Cambios Autor

Ahora vemos otro ejemplo de eliminación en este caso en la clase editorial se elimina el atributo Dirección, y vemos como ahora no existe en nuestro código y en el otro código podemos ver donde esta situado este atributo y su implementación.

Eliminar Dirección

En este último ejemplo mostramos el añadir un atributo en la clase categoría como es Descripción, que al contrario que el caso anterior si aparece en nuestro código y no en el comparado como es normal en una operación de inserción.

Añadir Descripción

Como vemos la manera de mostrar las diferencias es de forma similar que la visual siendo también una buena alternativa para poder utilizar. Para la vista del código también se conservan las funcionalidades para sobreescribir los cambios utilizando las combinaciones de flechas explicadas anteriormente.

Ventajas que proporciona y posibles usos de EMF Compare

  • Puedes combinar dos modelos distintos, que describan un entorno similar observando sus diferencias e identificando más fácilmente cual es la solución óptima para el problema.
  • Puedes comparar dos versiones de un mismo modelo, para en caso de error, modificación o cualquier causa, se quiera saber que estructuras se ha modificado en la versión posterior y así poder detectar más fácilmente el motivo del error.



Caso de Estudio CDO

Con esta herramienta hacemos que cada cliente pueda acceder a un servidor que comparte el mismo modelo.

Empezaremos con la instalación de CDO:


El siguiente paso será la creación de un servidor CDO:

  • Crearemos un servidor CDO basado en un archivo de configuración XML.
  • Creamos un proyecto Feature (conjunto de plug-ins que colaboran a fin de proporcionar una funcionalidad del software)de la siguiente manera:
    • File -> New -> Project… -> Plug-in Development -> Feature Project
    • A continuación en la pestaña Plug-ins y agregamos los siguientes plug-ins:
Añadir plugins para el servidor
  • Lo siguiente será crear un producto basado en este Feature, de la siguiente forma:
    • Botón derecho en el proyecto y seleccione New -> Other… -> Plug-in Development -> Product Configuration y le damos un nombre a nuestro nuevo servidor.
    • Seleccionamos la opción Use an existing product y features
Crear producto servidor
  • Luego agregamos las siguientes dependencias:
Añadir dependencia para el producto servidor

Ahora es el momento de definir el XML del archivo de configuración de CDO. Vamos a seleccionar el proyecto y crear una carpeta llamada RootFiles, y otra carpeta en ella llamada configuration, y ahora creamos un fichero xml llamado server-cdo. A continuación configuramos el fichero XML:

  • Seleccionamos nuestro proyecto y creamos un nueva carpeta con el nombre que deseemos, dentro de ella nuestro archivo XML y copiamos el siguiente código:
   <?xml version="1.0" encoding="UTF-8"?>
   <cdoServer>
   <acceptor type="tcp" listenAddr="0.0.0.0" port="2036">
   </acceptor>

   <repository name="demo">

       <store type="db">
           <mappingStrategy type="horizontal"/>
           <dbAdapter name="mysql"/>
           <dataSource
               class="com.mysql.jdbc.jdbc2.optional.MysqlDataSource"
               url="jdbc:mysql://localhost/cdotest?createDatabaseIfNotExist=true"
               user="root"
               password="nuestra_contraseña"
               />
        </store>
      </repository> 
    </cdoServer>

Este fichero nos muestra datos interesantes sobre la configuración de nuestro servidor, como por ejemplo el puerto en el que está localizado TCP 2036, nombre del repositorio, url de la base de datos, usuario, contraseña, etc.

  • En el fichero server.producto damos a Launch An Eclipse Application y obtenemos el siguiente mensaje si todo ha salido correctamente: !MESSAGE CDO server started
servidor lanzado
  • Por último creamos un fichero de configuración, abrimos el fichero build.properties en la pestaña build y Binary Build” seleccionamos “rootfiles“.
fichero de configuración

El siguiente paso importante será la creación de un cliente CDO.

Usando un modelo anterior, seleccionando nuestro fichero .genmodel hacemos lo siguiente:

  • CDO -> Migrate EMF Generator Model (dynamic feature delegation), esto incluye el código CDO necesario en el código original del modelo.
incluir codigo CDO
  • Además, agregamos una dependencia CDO a nuestro modelo
dependencia CDO modelo

Por fin, estamos listos para crear nuestro cliente. Para ello crearemos una aplicación de la siguiente manera:

File -> New -> Other -> Plug-in Project. Le damos un nombre y sin realizar mas cambios pulsamos siguiente. En el próximo paso nos preguntará si deseamos crear una aplicación de cliente. Nos aseguramos que la opción si este marcado.

crear aplicación cliente

Ahora vamos a seleccionar una plantila Hello RCP, en siguiente le damos un nombre a nuestra aplicación y finalizamos.

Ya tenemos nuestra aplicación lista, vacía, evidentemente. Si lanzamos la aplicación desde el pryecto, la podemos visualizar. Le añadimos las siguientes dependencias:

  • it.rcpvision.rcptutorial.model
  • org.eclipse.emf.cdo
  • org.eclipse.emf.cdo.net4j
  • org.eclipse.net4j.tcp
  • org.eclipse.emf.ecore.change
  • org.junit4

Ahora vamos a crear una nueva clase java en nuestra aplicaión para insertar los datos en nuestra base de datos MySql. La creamos en el paquete principal. El código de esta clase tiene la labor de abrir una sesion en CDO, crear las instancias e insertar datos en ellas. La creamos como test para poder ejecutarla y ver su resultado.

nueva clase de aplicación

Una vez terminada la clase, ejecutamos el test en run, y una vez se ejecute con éxito, las instancias estarán creadas en nuestra base de datos.

instancias creadas

Ahora vamos a hacer que nuestra aplicación lance una view (vista) para poder jugar un poco con los datos de nuestro modelo. Por ejemplo una vista de los autores que hemos insertado en pasos anteriores. Para ello nos vamos a nuestro proyecto aplicación y en el fichero plugin.xml abrimos la pestaña extension. Pulsamos el boton add y añadimos una nueva extension utilizando el filtro view.

añadir extensión view

Seleccionamos org.eclipse.ui.views y pulsamos finalizar. Ahora pinchamos con el botón derecho en la extensión que acabamos de crear y seleccionamos: new -> view. Le damos un identificador, un nombre, y un nombre para la clase a crear. Por último hacemos click en el hipervínculo de class.

hipervínculo class

Pulsamos en finalizar, y ahora tenemos una vista vacía lista para ser modificada.

clase vista vacía

Ahora añadiremos el menú. Como hicimos antes con la vista, añadimos una nueva extensión menú con el filtro menú, y añadimos org.eclipse.ui.menus. Pinchamos con el botón derecho en nuestra nueva extensión y vamos a new -> menuContribution.

añadir menú

Le damos a LocationURI el valor org.eclipse.ui.main.menu, por ejemplo. Ahora, dentro del articulo menuContribution creamos un comando: botón derecho new -> command.

añadir command

Ahora, cerca del campo CommandId, pulsar en Browse y añadir el filtro *ShowView, seleccionar org.eclipse.ui.views.showView y añadir el nombre que deseamos aparezca de cabecera en nuestra vista en el campo label

Show View

Ahora añadimos un parámetro a nuestro comando pulsando botón derecho sobre él: new -> parameter. Informará sobre el comando que la vista debe abrir. Debe ser de tipo org.eclipse.ui.views.showView.viewId en el campo de nombre y poner el ID de la vista en el campo valor.

Propiedades parámetro

Antes de lanzar la aplicación, debemos hacer un pequeño cambio en la clase Perspective, agregando:

  public class Perspective implements IPerspectiveFactory { 
  public void createInitialLayout(IPageLayout layout) {
  layout.setEditorAreaVisible(true);
  }

Ahora podemos empezar a trabajar con WindowsBuilder. Para ello debemos instalar nuevo software en Eclipse de la siguiente dirección: http://download.eclipse.org/releases/juno y descargamos los siguientes complementos:

  • SWT Designer
  • SWT Designer Core
  • SWT Designer SWT_AWT Support
  • SWT Designer XWT Support
  • WindowBuilder Core
  • WindowBuilder Core Documentation
  • WindowBuilder Core UI
  • WindowBuilder GroupLayout Support
  • WindowBuilder XML Core

Ahora estamos listos. Abrimos nuestra clase ListAuthorViewPart con botón derecho: open with -> WindowsBuilder Editor, y pinchamos en la pestaña Design.

Una vez en nuestra ventana de editor, vamos a agregar un TableViewer mediante la Paleta, en la sección JFace, hacemos click en él y lo soltamos en nuestra vista.

Editor WindowsBuilder

Del mismo modo, añadimos una columna a la tabla con el componente TableViewerColumn. Esta columna será la del nombre del autor.

Ahora debemos cargar los datos almacenados en la prueba de test que realizamos antes, para poder trabajar con los enlaces de datos. Para ello nos vamos a la pestaña Source. Aquí debemos implementar la clase para que abra nuestra sesion CDO y conecte la vista con la base de datos de nuestro modelo.

Una vez hecho esto, volvemos a la pestaña Design y en el objeto TableView botón derecho -> Bindings -> input.

Ahora seleccionamos el pequeño botón de la derecha, Eclipse Modeling Framework, elegimos el objeto librería, y luego la lista autor, es decir, la colección de autores de nuestro modelo. Ahora en element bean class, buscamos Author - library y elegimos nombre, que es el atributo que queremos enlazar.

Data Binding


Data Binding Autor

Seguimos trabajando en la pestaña Design, y añadimos un GridLayout en la vista desde la paleta, y después añadimos un compuesto a la vista. Ahora añadimos otro GridLayout en el compuesto, y añadimos un label, un text y un button. A la label le damos el valor nombre, dejamos el cuadro de texto vacío a su lado, y al botón le damos el valor save.

Editando vista

Ahora queremos vincular estos controles con los datos de nuestro modelo. Para ello necesitamos definir una variable de tipo WritableValue en nuestro código. Nos vamos de nuevo a nuestro diseño y en el cuadro de texto vacío de nuestra vista botón derecho: bindings -> text.

Enlace cuadro de texto

Seleccionamos author WritableValue y Detail for IObservableValue, y pulsamos siguiente. Ahora seleccionamos el nombre, que es el atributo que deseamos enlazar, y finalizamos.

Ahora pinchamos con el botón derecho en tableViewer para crear un método de cambio: add event handler -> selectionChanged -> selectionChanged.

Método SelectionChanged

Nos llevará a un método en nuestra clase java que debemos implementar para que vaya actualizando el cuadro de texto respecto a los autores de nuestra lista.

Ahora vamos a hacer lo mismo con el botón save. Pulsamos botón derecho y vamos a: add event handler -> selection -> widgetSelected. Ahora, al igual que antes, debemos implementar el nuevo método.

Una vez realizado, podemos lanzar la aplicación y ver el resultado final.

Pequeño ejemplo de aplicación

Podemos verificar que el campo nombre se sincroniza automáticamente con el nombre de autor seleccionado en el visor mediante un clic en la lista. Podemos modificar dicho nombre y mediante el botón save, guardar los cambios. Es un pequeño ejemplo de aplicación enlazada a datos de un repositorio CDO.

Conclusiones

  • Con este informe técnico hemos obtenido unos conocimientos más profundo sobre la herramienta EMF, tanto sus conceptos teóricos como prácticos, así como la variedad de usos y posibilidades que nos ofrece sus múltiples herramientas complementarias, profundizando más en los casos de estudios realizados como son EMF Compare y CDO.
  • Nos hemos encontrado con algunas dificultades al ser herramientas algo recientes, por lo que el proceso de investigación ha sido bastante duro.
  • Se trata de una experiencia nueva, ya que es la primera vez que realizamos un informe técnico sobre una herramienta y en grupo, en el cual tenemos que investigar y realizar nuestros propios casos de estudio.
  • Esperamos que este informe sea de utilidad para otras personas que se inicien en EMF.

Referencias

  1. Wikipedia
  2. Artículo EMF
  3. EMF compare
  4. Manual EMF
  5. EMF_Compare
  6. Teneo Teneo
  7. EMFT eclipse
Herramientas personales
Espacios de nombres

Variantes
Acciones
Navegación
Herramientas