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.
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.
12 comentarios:
que bien, yo tambien utilizo emf; ya no me siento tan solo
cada vez me enamoro más de la tecnología que va apareciendo sobre eclipse.
gmf es otra joya(basa en emf; para crear editores graficos), y cdo para la persistencia de los modelos en bases relaciones (no solo relacionales), y un montón más
suerte
La verdad es que es una gozada si. Después de superar la curva de aprendizaje de EMF se hacen las cosas rapidísimo, y en un plis puedes tener un modelo muy muy completo que de otra forma te llevaría semanas. También me llama mucho la atención JET, que es un sistema de plantillas que se puede usar con EMF. Imagina que p.e. quieres volcar un modelo EMF en qué se yo... en un CSV, o en lo que se te ocurra. Pues JET te permite hacerlo de forma fácil! Y no solo eso, sino cosas muy complejas. Un compañero del trabajo usa EMF para crear metamodelos que a su vez crean modelos que crean programas, pa fliparlo jeje.
Si después de presentar el proyecto me dan la oportunidad de seguir trabajando con eOPSOA, tengo claro que usaré GMF para crear un editor gráfico para el asunto de la definición de los UC, que con texto se puede hacer pero creo que es más práctico de otra forma, ya os contaré por aquí :-)
Hola, una pregunta David, yo estoy haciendo un trabajo y necesito emplear EMF y MOFScript. Necesito pasar de un modelo a codigo, es decir pasar de un metamodelo OLAP y generar su codigo SQL, no se si estoy en lo correcto pero para esto necesito el metamodelo SQL cierto?, pero no lo consigo completo, no se si me puedes ayudar. Gracias
Buenas Quiti
Si te soy sincero no tengo casi ni idea de lo que comentas, el uso que hago de EMF en mi proyecto es muy básico. En un futuro es posible que trabaje más con modelado y metamodelado, pero por ahora no te puedo ayudar...
Sé que existe un proyecto llamado Teneo, la pequeña descripción que hacen de él en la página de Eclipse dice:
Teneo is a database persistency solution for EMF using Eclipselink or Hibernate. It supports automatic creation of EMF to Relational Mappings and the related database schemas. The solution contains a runtime layer to support specific EMF features. EMF Objects can be stored and retrieved using advanced queries (HQL or EJB-QL). EMF resource implementations are provided for integration with EMF Editors. The persistence logic and mapping can be controlled using EJB3/JPA-like annotations. Most of the EJB3/JPA mapping standard is supported.
Pero nunca lo he tocado, ni sé si tiene algo que ver con tu labor, lo siento :-(
¡Mucha suerte!
Hola necesito su ayuda, como hago una interfaz donde pueda inserta el diagrama de mi modelo, algo tipo UML, donde tenga iconitos, Pero tmb donde pueda inserta un modelo q saque de un metamodelo.
Buenas Janet
Lo que necesitas es el framework GMF de Eclipse. Permite construir editores gráficos que den soporte a metamodelos Ecore.
Lo único que puedo hacer por ayudarte es indicarte el framework correcto, porque tengo muy poca experiencia en GMF. Si quieres comenzar a ver el tema, te aconsejo que comiences con la documentación de GMF, e intentes seguir uno de sus tutoriales. Está en inglés, pero no es para nada complejo, y si tienes los conceptos básicos de EMF asimilados no tendrás problemas para seguirlo.
¡Buena suerte! :-)
Gracias David, lo checaré, creo q te estaré molestando con algunas dudas, es la primera vez q voy a trabajar con GMF, podrias pasarme tu correo, tienes msn.
Para quity nose si resolviste el problema pero lo tuyo tiene que ver con trasnformacion de modelos osea pasar del modelo OLAP(Para especificar un modelo OLAP necesitas su metamodelo) a SQL. eso lo podes ver en el libro Eclipse Modeling project: A DOMAIN SPECIFIC LANGUAGE TOOLKIT, libro mas que aconsejable cubre EMF, GMF, Model to model transformations y muchas cosas mas
es verdad que emf es cosa fina desde que lo descubri todos lo proyecto que haga tendran esa tonica, les comento que para lograr hacer un arbol me pase casi trres mese en mi tesis que desgracia y pa colmo ndadia sabia que era eso buenos cabezaso me di pero despues de eso tiempo me dieron otro proyecto y ni se immagina en que tiempo logre hacer la parte de modelado 2 dias señores no lo podria creer el proyecto lo termine en una semana.
EMF yo lo combino con Teneo, hibernate, RCP. osea les paso el modelo a teneo y teneo se encarga de darle a hibernate lo que le hace falta para la creacion de base de dato, que claro esta se genera sola.
sañores no saben lo que se estan perdiendo con esa herraminetas difrutenlan
Hola, que tal:
Estoy desarrollando uno plug in, pero tengo muchas dudas sobre como se comunican emf y gmf, y quisiera saber si me pudieras ayudar, eh tratado de utilizar las restricciones "links constraints" pero no he encontrado mucha información, tendras un correo a donde pueda enviarte la imagen de mi modelo o marchivo ecore, aunque sería bueno que despues se pudiera compartir para que alguien mas pueda utilizar información, gracias y ojalá me puedas ayudar.
hola:
Estoy trabajando en un plug in, pero tengo dudas sobre como se comunican EMF y GMF, adjunto una imagen del modelo de clases
http://cooi.qumax.org/ecorediag.png
http://cooi.qumax.org/ecore_diagram.png
ahora adjunto una imagen del editor visual que hasta el momento llevo, la parte visual ya casi está terminada, lo que me falta ahora es establecer ciertas restricciones, adjunto cada imagen y explico cual es la restriccion.
http://cooi.qumax.org/diagrama_tfd.png
Ninguna figura puede apuntarse a si misma.
http://cooi.qumax.org/Flow.gif flow: es el encargado de unir los diferentes tipos de componentes.
http://cooi.qumax.org/Start.gif start: ningún flujo puede llegar a él, ya que es el componente principal, Solamente puede tener un flujo de salida.
http://cooi.qumax.org/Task.gif task: Solamente puede tener un único flujo de entrada y un único flujo de salida.
http://cooi.qumax.org/Exception.gif exception: Solamente puede tener un único flujo de entrada, tiene dos flujos de salida.
http://cooi.qumax.org/Choice.gif choice: igual que exception.
http://cooi.qumax.org/End.gif end: solamente puede tener un único flujo de entrada, este componente no puede tener ningún flujo de salida
http://cooi.qumax.org/Failure.gif failure: igual que end.
http://cooi.qumax.org/fork.gif fork: solamente puede tener un único flujo de entrada, este componente puede tener cualquier cantidad de flujos de salida.
http://cooi.qumax.org/Join.gif join: este componente puede tener cualquier cantidad de flujos de entrada, sin embargo, solo puede tener un único flujo de salida.
el primer punto de restringir que un componente apunte a si mismo lo logré con la condición establecida en el archivo *.gmfmap, especificamente en el mapeo del flujo, con "link constraint"->"source end constraint" con la siguiente declaración OCL "self <> opposite End", funciona perfectamente, pero no se como establecer las demás restricciones de los otros componentes, ojalá me puedan ayudar, gracias.
En realidad EMF es una joya...estoy empezando a trabajar con él, lleva un poco de tiempo superar la curva de aprendizaje como dijeron por ahí pero luego todo va bien...desearía que hubiese mas info en español el ingles ya me tiene sofocado. muy buen post
Saludos desde Ecuador
Publicar un comentario