23 febrero 2009

Eclipse Model Framework: cosa fina oiga

Eclipse, además de un IDE para Java fantástico, es también una plataforma para el desarrollo de aplicaciones. Estas o bien pueden ser plugins (como el que estoy haciendo yo), o aplicaciones RCP como pueden ser Cool Imaging Project, de unos compañeros que también están compitiendo en el CUSL (saludos!!). El caso es que al ser Eclipse al 99% modular, se presta a ser extendido. La Wikipedia tiene un artículo muy interesante sobre Eclipse, en developer.com hablan de su arquitectura, y en el libro The Java Developer's Guide To Eclipse (muy muy recomendable) hay muchísima más información. Como a veces lo más sencillo es una imagen, he tomado prestada una imagen de ese libro que es representativa de la arquitectura de Eclipse

Quizá el componente más usado de Eclipse es JDT, porque de un modo u otro todos los que desarrollamos sobre Eclipse lo utilizamos. Pero con la tendencia actual de ver a Eclipse como un framework de desarrollo de aplicaciones han aparecido proyectos alrededor que son muy interesantes, como por ejemplo BIRT, Mylyn, DTP... si, todo son siglas ;-)

Uno de estos componentes que me está siendo especialmente útil es EMF, que responde a Eclipse Modeling Framework Project. En plan rápido, EMF es un framework para el modelado y gemeración de código para construir herramientas y otras aplicaciones basadas en un modelo de datos estructurado. Desde la especificación de un modelo descrita en XMI, EMF proporciona herramientas y soporte para generar un conjunto de clases Java para el modelo, además de clases adapter para soportar la visualización y la edición del modelo. Como imagino que esta descripción tampoco es muy útil, y hay sitios donde pueden explicar con más criterio que yo en qué consiste EMF, voy a intentar explicar porqué es útil para mi proyecto.

Imaginemos que estamos desarrollando una aplicación en la que hemos identificado un modelo de datos relativamente complejo, y que debemos ser capaces de serializar y deserializar desde XML. Por ejemplo este, descrito en UML, y que modela parte del soporte para Casos de Uso que tiene eOPSOA:

Este modelo se podría implementar sin problemas en Java, pero sería una tarea cuanto menos dolorosa. Y si a esto añadimos el asunto de la serialización/deserialización en XML, listeners, adapters... etc., nos podemos dar cuenta que no es un asunto trivial.

Si desarrollamos un plugin para Eclipse, una aplicación RCP, o simplemente una programa Java, nos puede resolver la vida. Entre otras muchas cosas, con EMF podemos hacer:

  • Describir el modelo de datos a alto nivel. P.e. podemos usar un diagrama de Rational Rose, un diagrama UML, XSD, interfaces Java anotadas... etc. para construir un fichero ecore con el modelo de datos de nuestro sistema.
  • Con el fichero ecore, podemos generar un fichero genmodel que a su vez puede ser usado para generar el código Java que describe nuestro modelo. Crea además un editor en línea de comandos y otro gráfico como plugins de Eclipse. Todo eso sin tener que escribir una línea de código ;-)
  • Con el código que hemos generado, podemos serializar/deserializar nuestro modelo a XMI y XML, tenemos relaciones entre objetos, notificaciones, notificaciones inversas, adaptadores... etc. Todo ello como he comentado out-of-the-box, solo con la descripción a alto nivel de nuestro modelo y sin escribir (casi) una sola línea de código.
  • Podemos manipular el código generado, y si en un futuro hay cambios en el modelo, se puede recargar y regenerar el código, respetándose nuestros cambios.
  • Podemos usar los ficheros ecore y genmodel anteriores para crear un editor gráfico (en plan pinchaiconos, copiar y arrastrar) con GMF.
  • Y bueno, muchas cosas más que no sé ni creo que vaya a necesitar en un futuro cercano, pero que parecen cosa fina oiga.
A mí al menos, me ha resuelto la vida. Si le echáis un ojo a mi SVN, el plugin org.uclm.eopsoa.core es prácticamente un modelo EMF un poquito grande, y todo el código Java que me genera automáticamente. Si queréis comenzar con esto hay bastante información disponible en Internet, pero lo suyo es comenzar mirando la documentación de EMF, leer la guía para programadores, e intentar hacer los tutoriales. Hay una chuleta de referencia que viene muy bien, y si sabes que te vas a pegar mucho han sacado hace poco la segunda versión del libro EMF: Eclipse Modeling Framework. No es barato pero cubre mucho mucho mucho más de lo que puedas encontrar en Internet, y es extremadamente útil.

No sé si os habré convencido, pero para terminar voy a comentar algunas cosas que he aprendido durante estos meses usando EMF:

  • En los tutoriales apenas se comenta, pero la forma más cómoda para crear un modelo EMF es editando el fichero ecore con el editor. Muestra un árbol con los elementos, se pueden añadir/eliminar nuevos hijos, y manipular las propiedades en el properties view. Las interfaces Java anotadas son útiles porque proveen de una perspectiva más cercana a la que podemos tener los programadores, pero es mucho más fácil meter la pata y se pierde flexibilidad. Además, que si tu modelo EMF es un poco complejo es un rollo recordar las 80 anotaciones que quizá te hagan falta.
  • Procura tener tu modelo EMF lo más limpio, expresivo y rico posible. Si te ves modificando mucho código autogenerado, suele ser señal de que necesitas trabajar más tu modelo.
  • El nombre de los atributos va a tener mucho que ver en cómo se va a generar el fichero XMI/XML de persistencia del modelo. No te agobies demasiado si alguna etiqueta queda algo rara; mejor tener una API cómoda para trabajar. Y si alguien tiene que usar tu XML, siempre podrá usar a su vez EMF y entonces te agradecerá las decisiones que hayas tomado.
  • NUNCA, NUNCA pienses que no vas a tener que regenerar el modelo (y el código) y muevas paquetes, cambies nombres a clases sin que se entere EMF. Suele pasar cuando en tu proyecto usas una convención de nombres de interfaces/clases distinta a la que genera EMF, y con las facilidades de refactorización que provee Eclipse puede ser goloso liarse la manta a la cabeza, y moverlo y cambiarlo todo de sitio. Pero aunque no quieras, tarde o temprano vas a tener que modificar tu modelo, y al final tendrás un pisto y perderás tiempo.
Espero que este post haya sido útil, si alguien quiere comentar lo que fuera es bienvenido :-)
16 febrero 2009

Update Site para eOPSOA

No sé si alguno se acordará de algunos años como estaba el panorama en GNU/Linux. Yo comencé cuando la cosa iba más o menos bien, allá por el año 2002, y mi primera distribución fue una RedHat 7.3. Por aquel entonces estaba comenzando el tema de las conexiones de banda ancha (aunque realmente no eran tan anchas... ONO ofrecía por aquel entonces 64 kbps) y aunque poco a poco se iba haciendo hueco Internet en casa, no éramos tantos los afortunados internautas. Decía que mi primera distro fue una RedHat 7.3, y aún recuerdo cómo descubrí lo que por aquel entonces se llamaba dependency hell cuando intenté instalar algún que otro RPM suelto que encontré por ahí: el Compu's Messenger (el abuelo del AMSN actual), los infames drivers binarios de la NVIDIA, el JRE 1.4 de Sun, algún que otro juego... etc. Era una gracia eso de tener el modem de 56 kbps y ver como un paquete depende de otro, otro de otro, otro de otro... y después de descargar 60 megas de paquetes descubrir que has liado tal pisto, que no hay otra solución casi que reinstalar de 0 el sistema. Qué tiempos aquellos, luego descubrí Debian y su bendito apt-get; fue entonces cuando descubrí el cielo. Pero eso es otra historia.

Todo lo anterior venía a cuento porque parece mentira, y en pleno año 2009 algunas cosas no han cambiado tanto, y si no andas con tiento te puedes encontrar con el mismo problema. No sé si lo habré comentado antes, pero Eclipse es modular 100%... en realidad todo está descompuesto en n-mil plugins. Eso tiene sus ventajas, y a la vez sus desventajas. Quizá su mayor desventaja es la instalación de plugins nuevos, que como no tengas cuidado te puedes encontrar con el problema que he comentado antes: un infierno de dependencias. A partir de la versión 3.2 (creo) Eclipse introdujo un componente muy interesante llamado Update Manager, donde se añadían Update Sites desde los cuales te puedes bajar plugins y features, y con un poco de buena suerte se calculaban las dependencias de tal forma que no tuvieras que sufrir la tortura de resolverlas a mano. Versión a versión ha ido mejorando la cosa y en la versión 3.4, aunque es lento como el infierno, es prácticamente usable.

Aprovechando que el proyecto está avanzando poco a poco, y que ya hay algunas cosas que se pueden ver, pensé que quizá sería buena idea montar un Update Site para distribuir de forma rápida el proyecto, y que quien estuviera interesado probara el software no sufriera tortura. Quién sabe, a lo mejor así alguien se anima a rellenar algún que otro bug report... no sé. Hablé con la gente del Centro de Datos de la ESII (gracias Juan Carlos!!! :-)) y han sido tan majos de proporciarme un sitio donde poder ir colgando el Update Site. La URL es http://eopsoa.albacete.org, a que mola ¿verdad? ;-)

Bueno, para ser sincero no he colgado todavía nada, pero por ahora he escrito un HTML guarro donde describo de forma somera el proyecto, y las instrucciones para descargar las fuentes y los binarios. Cuando termine un par de cosas que estoy implementando lo subo, palabra O:-)

He estado pensando en el estado del blog y del proyecto, y creo que no he sido capaz de describir muy bien de qué va mi proyecto. En parte ha sido por desidia mía, pero por otra parte también es verdad que estoy que no me cojo el culo... por eso he pensado que lo mejor sería colgar la prememoria del proyecto que envié cuando inscribí el proyecto en el CUSL, y que aquel que esté interesado que le eche un ojo.

Y nada más por ahora, dentro de poco escribiré otra entrada donde intentaré comentar el estado del proyecto, y de las ideas que tengo para el futuro, que creo que pueden ser interesantes.

Happy hacking!!