La propuesta de Eclipse

Eclipse es principalmente una comunidad que fomenta el código abier- to. Los proyectos en los que trabaja se enfocan principalmente en cons- truir una plataforma de desarrollo abierta. Esta plataforma puede ejecu- tarse en múltiples sistemas operativos, lo que convierte a Eclipse en una multi-plataforma. Está compuesta por frameworks extensibles, y otras herramientas que permiten construir y administrar software. Permite que los usuarios colaboren para mejorar la plataforma existente y extiendan su funcionalidad a través de la creación de plugins.

Eclipse fue desarrollado originalmente por IBM como el sucesor de su familia de herramientas VisualAge. Inicialmente fue un entorno de desa- rrollo para Java, escrito en Java. Pero luego fue extendiendo el soporte a otros lenguajes de programación. Eclipse ganó popularidad debido a que la plataforma Eclipse proporciona el código fuente de la plataforma y esta transparencia generó confianza en los usuarios.

Hace algunos años se creó la Fundación Eclipse, una organización in- dependiente sin fines de lucro que fomenta una comunidad de código abierto. La misma trabaja sobre un conjunto de productos complemen-

tarios, capacidades y servicios que respalda y se encarga del desarrollo continuo de la plataforma. La comunidad Eclipse trabaja actualmente en 60 proyectos. En este capítulo solamente pondremos foco en el proyec- to dedicado a promover tecnologías de desarrollo basadas en modelos llamado Eclipse Modeling Project (http://www.eclipse.org/modeling/). Este proyecto está compuesto por otros subproyectos relacionados. En la figura 4-2 se listan los subproyectos que forman Eclipse Modeling Project.

Abstract Syntax development (EMF) Concrete Syntax development (GMF, TMF) Model Transformation (QVT, JET, MOF2Text)

Standards Implementations (UML2, OCL, OMD, XSD)

Technology & Research (GMT, MDDi, Query, Transaction, etc.)

Figura 4-2. Subproyectos de Eclipse Modeling Project

En este capítulo presentamos los plugins para crear la sintaxis abstracta y concreta de un lenguaje. Para la sintaxis abstracta se presentarán los plugins EMF y OCL, mientras que para la sintaxis concreta se presenta- rán GMF y TMF. Tanto EMF como GMF son proyectos maduros y sus implementaciones han ido evolucionando los últimos años. La primera versión de EMF se lanzó en el año 2003 y la primera versión de GMF en el año 2006. En contraste, TMF es un proyecto nuevo, que aún se en- cuentra en las primeras etapas.

En las secciones siguientes se presentan estos proyectos con más de- talle.

4.3.1 Eclipse Modeling Framework (EMF)

El proyecto EMF es un framework para modelado, que permite la gene- ración automática de código para construir herramientas y otras aplica- ciones a partir de modelos de datos estructurados. La información refe- rida a este proyecto, así como también la descarga del plugin pueden encontrarse en [EMF].

EMF comenzó como una implementación del metalenguaje MOF. En los últimos años se usó para implementar una gran cantidad de herramien- tas lo que permitió mejorar la eficiencia del código generado. Actual- mente el uso de EMF para desarrollar herramientas está muy extendido.

Se usa, por ejemplo, para implementar XML Schema Infoset Modelo (XSD), Servicio de Data Objects (SDO), UML2, y Web Tools Platform (WTP) para los proyectos Eclipse. Además EMF se utiliza en produc- tos comerciales, como Omondo, EclipseUML, IBM Rational y produc- tos WebSphere.

EMF permite usar un modelo como el punto de partida para la genera- ción de código, e iterativamente refinar el modelo y regenerar el códi- go, hasta obtener el código requerido. Aunque también prevé la posibi- lidad de que el programador necesite modificar ese código, es decir, se contempla la posibilidad de que el usuario edite las clases genera- das, para agregar o editar métodos y variables de instancia. Siempre se puede regenerar desde el modelo cuando se necesite, y las partes agregadas serán preservadas durante la regeneración.

Descripción

Como se dijo anteriormente, la generación de código es posible a par- tir de la especificación de un modelo. De esta manera, permite que el desarrollador se concentre en el modelo y delegue en el framework los detalles de la implementación.

El código generado incluye clases Java para manipular instancias de ese modelo como así también clases adaptadoras para visualizar y editar las propiedades de las instancias desde la vista “propiedades” de Eclipse. Además se provee un editor básico en forma de árbol para crear instancias del modelo. Y por último, incluye un conjunto de casos de prueba para permitir verificar propiedades. En la figura 4-3 pueden verse dos pantallas. La de la izquierda muestra los cuatro plugins ge- nerados con EMF. Dentro de los plugins pueden verse los paquetes y las clases correspondientes. La pantalla de la derecha, muestra el edi- tor en forma de árbol.

El código generado por EMF es eficiente, correcto y fácilmente modifi- cable. El mismo provee un mecanismo de notificación de cambios de los elementos, una implementación propia de operaciones reflexivas y persistencia de instancias del modelo. Además provee un soporte bá- sico para rehacer y deshacer las acciones realizadas. Por último, esta- blece un soporte para interoperabilidad con otras herramientas en el framework de Eclipse, incluyendo facilidades para generar editores ba- sados en Eclipse y RCP.

Figura 4-3. Plugins generados con EMF Meta- metamodelo

En EMF los modelos se especifican usando un meta metamodelo lla- mado Ecore. Ecore es una implementación de eMOF (Essential MOF). Ecore en sí, es un modelo EMF y su propio metamodelo. Existen algu- nas diferencias entre Ecore y EMOF, pero aún así, EMF puede leer y escribir serializaciones de EMOF haciendo posible un intercambio de datos entre herramientas. La figura 4-4 muestra las clases más impor- tantes del meta metamodelo Ecore.

Ecore respeta las metaclases definidas por EMOF: todas las metaclases mantienen el nombre del elemento que implementan y agregan como prefijo la letra “E”, indicando que pertenecen al metamodelo Ecore. Por ejemplo, la metaclase EClass implementa la metaclase Class de EMOF. La principal diferencia está en el tratamiento de las relaciones entre las clases. MOF tiene a la asociación como concepto primario, definiéndola como una relación binaria entre clases. Tiene finales de asociaciones, con la propiedad de navegabilidad. En cambio, Ecore define solamente EReferences, como un rol de una asociación, sin finales de asociación ni Association como metaclases. Dos EReferences pueden definirse como opuestas para establecer una relación navegable para ambos sentidos. Existen ventajas y desventajas para esta implementación. Como ventaja puede verse que las relaciones simétricas, como por ejemplo “esposoDe”, implementadas con Association, son difíciles de mantener ya que debe hacerse consistentemente. En cambio con Ecore, al ser sólo una referencia, ella misma es su opuesto, es decir, se captura me- jor la semántica de las asociaciones simétricas, y no es necesario man- tener la consistencia en el otro sentido. Los modelos son entonces, ins- tancias del metamodelo Ecore. Estos modelos son guardados en for- mato XMI (XML Metadata Interchange), que es la forma canónica para especificar un modelo.

Pasos para generar código a partir de un modelo

Para generar el código a partir de la definición de un modelo deben seguirse los siguientes pasos: