Encuesta

¿Cuál es tu interés en ejecutar lenguajes distintos de Java en la máquina virtual Java?

01-12-2008 - 193 votos

Eclipse y el Desarrollo de Software Dirigido por Modelos: eclipseDay en Valencia

01/10/2008 18:36 anonymous

 

  El próximo día 2 de Diciembre se celebrará en el Palacio de Congresos de Valencia el eclipseDay. Su programa se centra en el uso de tecnologías de la plataforma Eclipse orientadas al Desarrollo de Software Dirigido por Modelos. En particular se dará a conocer MOSKitt, una herramienta libre fruto de la iniciativa de la unión de la Consellería de Infraestructuras y Transporte de la Comunidad Valenciana y empresas y entidades colaboradoras que da soporte metodológico a una adaptación de Métrica III llamada gvMétrica que utiliza técnicas basadas en el lenguaje de modelado UML. MOSKitt proporciona, además, toda una arquitectura integrada en la plataforma Eclipse que da soporte al desarrollo y construcción de herramientas basadas en MDD.

  Más información y suscripciones al evento en www.moskitt.org 

Volver a actualidad

Etiquetas: otro, eclipse, gmf, emf, dsdm, mda, moskitt, eclipseday, atl, m2m, m2t, xpand2

Comentarios: 10

  • Juanmp 01/10/2008 21:42

    ¿Qué soporte tiene para herramientas pertenecientes al proyecto Eclipse (pienso sobre todo en la integración con EMF y OpenArchiitectureware)? ¿Cómo se relaciona con soluciones comerciales tipo RSA? ¿Alguien lo sabe?

    Son dos preguntas clave:

    1. ¿Han reinventado la rueda o aporta cosas nuevas?

    2. ¿Sirve para algo?

    10 contra 1 a que no la usa ni blas

  • Juanmp 01/10/2008 22:01

    Hmm, es que me acabo de acordar de una conversación con un comercial de IBM al que le pedía si podía decirnos que clientes habían *hecho algo* no sólo *comprado* RSA en España. Después de consultarlo, medio nos dijo-medio se echó atrás que en dos conocidas compañías "lo estaban usando" (que se puede interpretar libremente).

    ¿Alguien está usando MDD / MDA en algún proyecto real?

    AndroMDA tiene un commiter español que es quien ha hecho creo que el soporte de Spring así que, de alguna forma, quizá alguien lo tiene que estar usando en algún lugar.... Me da que sólo a ese nivel teórico.

  • emiliobg 02/10/2008 10:54

    Hola Juanmp, nosotros usamos AndroMDA para desarrollar los proyectos, tiene sus pros y sus contras, pero en general ha sido positivo su uso. Por si le interesa a alguien, tenemos una presentación en slideshare explicando el proceso que seguimos.

    MOSKitt no lo conozco asi que no puedo opinar. Respecto a MDD / MDA, la idea es que desde el diseño (que todos realizamos) se genere el código (al menos el código base, el de infraestructura) y permita añadir codigo manual en caso de que sea necesario.

    Saludos.

  • tavernes 02/10/2008 13:08

    Saludos,

    ante todo como ya es habitual, doy todo mi apoyo a cualquier iniciativa de software libre. 

    He de agradecer el empeño de la Conselleria de Obras Públicas en los temas de software libre, y por supuesto a Martín, que desde el primer momento ha tenido las ideas muy claras y ha aceptado este reto.

    Por desgracia, como tambien es habitual, no he podido probar estas herramientas en detalle, y poco puedo opinar para poder plantear mejoras.

    Eduard

  • Anónimo 02/10/2008 13:35

    Pues básicamente utiliza EMF y GMF ! ! !

    Sirve para algo ?¿? Pues tu mismo; si se aprueba un proyecto para el desarrollo de una herramienta software será porque se tiene la intención de usar.

    Por el momento, la Consellería de Infraestructuras y Transporte ya está haciendo uso de la misma al igual que la Facultad de Informática de la Universidad Politécnica de Valencia.

    Nada más Blas, si te sirve la usas (q para algo es software libre), sino a apostar al bwin !!!

  • Juanmp 03/10/2008 20:25

    @emiliobg

    Es genial, así que eres el Emilio que está detrás del blog de i2e. Hace ya meses que tengo agregado vuestro blog (que es *sensacional* por cierto, gracias por mantenerlo !). Había visto tu nombre por aquí, pero ni me imaginaba que eras ese Emilio.

    En relación al uso de AndroMDA -y la aproximación MDA en general-, unas preguntas:

    - Entiendo el valor de estas herramientas para poder reaprovechar los artefactos de surgen del análisis/diseño, especialmente en grandes aplicaciones. Pero sinceramente, ¿no es muy pesado llevarlo hasta el extremo de MDA de hacer UML ejecutable? Lo digo por dos cosas, primero tienes que detallar los modelos en UML cuando no son lo más expresivo para hacerlo (hay tagged values hasta en la sopa en AndroMDA) y por otro te obliga a mantener a la vez el modelo y el código cuando lo generas por primera vez.

    - Una de las cosas más interesantes para mí cuando lo estuve mirando era el generar toda la fontanería necesaria por nuestra forma de desarrollo (que incluía muchas de las cosas que ya venían soportadas en como entidades en los cartuchos de AndroMDA). Lo que pasaba es que algo olía mal: si había tantas cosas que debían ser repetidas ¿no se estaba haciendo algo mal? Al final eso propició que se cambiase la arquitectura de base y desde luego me dió la sensación de que íbamos por un camino más limpio y sencillo. La pregunta es: ¿no crees tú también que la necesidad de generar código que es muchas veces repetido es un indicador de que algo va mal con estas aproximaciones MDA?

    - En AndroMDA me encontré con que las plantillas de generación de código estaban embebidas dentro de los jars de los cartuchos y no podían ser cambiadas / ampliadas sin ser destruídas en la siguiente revisión (o hechas incompatibles, que podía pasar -y al final pasó- con la nueva versión de AndroMDA). Por otro lado el generar tu propio cartucho definiendo tus necesidades, haciendo los metamodelos, todas las reglas de generación, etc, era muy tedioso. ¿Cómo habéis afrontado esto?

    - Al final el lenguaje de reglas de transformación de EMF en Eclipse, sus plantillas JET y cómo trabajan en conjunto me han parecido mucho más claras -y más documentadas- que la forma de trabajar de AndroMDA. Creo que las iban a soportar en la siguiente versión -que hace tiempo que ha salido- ¿qué aporta AndroMDA por encima de esto?

    - En general, ¿ves *realmente* útil la aproximación MDA después de haber trabajado con ella? 

    Esto es lo que pasa por escribir un buen blog, la gente luego te hace un montón de preguntas :) ! En fin, si tienes un rato sería genial conocer tu opinión.

    Un saludo.

  • emiliobg 04/10/2008 12:41

    Hola Juanmp,

    Muchas gracias por seguir nuestro Blog (y por la publicidad :D), intentamos contar nuestros intereses, aunque no le podemos dedicar todo el tiempo que nos gustaría.

    Voy a intentar responder a tus preguntas, aunque dan para un buen debate.

    "¿no es muy pesado llevarlo hasta el extremo de MDA de hacer UML ejecutable?"
    Lo del UML ejecutable por el momento no lo veo como algo factible. Lo que quiero a aclarar es que mas que MDA lo que perseguimos es seguir el Model Driven Development (MDD). En adelante voy a referirme a MDD que engloba a MDA y a otras aproximaciones.

    "por otro te obliga a mantener a la vez el modelo y el código cuando lo generas por primera vez."
    Creo que esto es una de las ventajas del MDD, desde el modelo dirijo el desarrollo, cualquier cambio sobre las entidades o los servicios de la aplicación los realizo sobre el modelo y a partir de el obtengo el código.
    En cierto modo esto te limita un poco, pero el beneficio a medio plazo merece la pena.
    Por ejemplo usando el diagrama de clases de UML puedo centrarme en modelar los objetos de negocio sin tener en cuenta que tecnología se va a utilizar. A partir de este modelo puedo ralizar plantillas que genere código para
    Hibernate, para Rails, o para cualquier otra tecnología. El esfuerzo utilizado para el diseño se transfiere casi completamente al desarrollo.

    "¿no crees tú también que la necesidad de generar código que es muchas veces repetido es un indicador de que algo va mal con estas aproximaciones MDA?"
    Si que es posible que el código base no sea el mejor (que se tenga mucha fontanería :D). Para mi no es ese el principal motivo para usar MDD.
    Lo que mas me gusta es que puedo centrarme en el diseño (sea con UML o con un DSL hecho a la mediad), esto tiene varias ventajas:

     

    • Tengo una visión mas clara de la aplicación. La aplicación esta implementada realmente siguiendo el diseño realizado.
    • El código base generado siempre tiene la misma estructura.
    • Modificando los generadores puedes obtener un código base adaptado a tus necesidades, o incluso cambiar de tecnología.

     


    "Al final el lenguaje de reglas de transformación de EMF en Eclipse, sus plantillas JET y cómo trabajan en conjunto me han parecido mucho más claras -y más documentadas- que la forma de trabajar de AndroMDA, ¿qué aporta AndroMDA por encima de esto?"
    Tienes razón, actualmente el entorno de eclipse es mas potente que AndroMDA. Un proyecto interesante seria implementar las plantilla de AndroMDA con JET. Las plantillas de AndroMDA actualmente son las mas completas.

    "En general, ¿ves *realmente* útil la aproximación MDA después de haber trabajado con ella?"
    Desde mi punto de vista si que lo veo muy útil. En nuestro caso los beneficios obtenidos son mayores que las limitaciones que puedes tener por seguir el MDD. Ademas creo que es el camino natural para subir un nivel de abstracción y poder hacer frente a los cada día mas complicados requerimientos que tienen las aplicaciones.

    Saludos.

     

  • Anónimo 21/11/2008 16:13

    Tina :) Probe emf, gef y gmf, y pues es el codigo obtenido es reutil. Lo estoy personalizando y me ahorro mucho el tiempo. MDD es un proyecto prometedor. Saludos.

  • Anónimo 21/11/2008 16:18

    Tina :)

    Probe emf, gef y gmf, y pues es el codigo obtenido es reutil. Lo estoy personalizando y me ahorro mucho el tiempo. MDD es un proyecto prometedor. Saludos.

  • Anónimo 21/11/2008 16:21

    Tina :)

    Probe emf, gef y gmf, y pues es el codigo obtenido es reutil. Lo estoy personalizando y me ahorro mucho el tiempo. MDD es un proyecto prometedor. Saludos.

Escribe tu comentario

Sun Microsystem Logo NHT-Norwick Logo

© 2002-2007 Asociación javaHispano