Buena presentación sobre MDE

Jordi Cabot publica hoy en Slideshare una muy interesante presentación sobre MDE/MDD, que, si bien hace una introducción general al tema, le dedica lo fundamental a las líneas de investigación y a los puntos problemáticos para lo que define como versión 2.0 de MDE. Dentro de las líneas de trabajo presente y futuro dos aspectos que veo particularmente interesantes son la actividad relacionada con  ingeniería reversa dirigida por modelos (mención especial de MoDisco), y el  manejo de muy grandes modelos, que parece ser un asunto de difícil solución en el marco de las premisas actuales de MDE/MDD.
La presentación es suficientemente detallada y amplia como para que pueda despertar la inquietud de aquellos que todavía dudan del valor de MDD/MDE, y más aún para quienes ya están embarcados en alguna forma de desarrollo basado en modelos. El camino es ancho y abierto...
No lo voy a reproducir: cualquiera puede ver la presentación en Slideshare.

A propósito de la década de Eclipse

Jean Bezivin comparte hoy en Google+ una nota de Ian Skerrett, de la Fundación Eclipse, que puntualiza algunos de sus logros en diez años de existencia. En lo esencial:

As I have written, Eclipse is celebrating 10 years of open source and community during the month of November.   There have been a number of milestones that have shaped the Eclipse community but what have been the major accomplishments?  What has Eclipse done to actually change the software industry?  Here are what I see as some of the key accomplishments for Eclipse.
1.  Dominant Java IDE.  Eclipse started out as being a really great Java IDE and continues today to be the market leader for Java IDEs.  If you think back to the late 1990′s and early 2000′s the Java IDE market was a dog-fight between Borland JBuilder, Visual Cafe, IBM VisualAge for Java.   Eclipse is now the clear leader and has approximately 65% market share in the Java IDE market.
2. De-facto Solution for C/C++ Tools.  If you are building a tooling solution for C/C++ developers there is a very good chance you are using Eclipse CDT as the platform.   In the realtime operating system and embedded development market, Eclipse CDT has become the de-facto standard.  There at least 50 companies that are building their developer tools solution based on CDT.
3. A large and innovative modeling community.  I am not sure how to quantify it but I believe the Eclipse modeling community has grown to become one of the largest and innovative communities at Eclipse.  If you are doing modeling, chances are you are using Eclipse Modeling Framework (EMF).  However, EMF is just the core that has created a really amazing community of innovation and diversity that happens at Eclipse Modeling.   There are over 70 modeling projects at Eclipse and I know a lot more not hosted at Eclipse.   It is a great success.
4. Integrating ALM Tools.  The Mylyn project has grown into becoming the industry hub for integrating tools across the application lifecycle.   There are now over 70 different Mylyn connectors that integrate different projects into the developer desktop.
5. Modular runtimes.  Equinox and the EclipseRT projects demonstrate how modularity can work on a large scale.  Everything at Eclipse is based on Equinox, since it is the OSGi runtime.  However, Equinox and the EclipseRT top-level project has spawned an industry around Eclipse RCP and server-side OSGi.  The range of applications being built on RCP is impressive, including NASA Mars Rover, financial institutions, aircraft design, genome decoding, etc, etc.   On the server side, Equinox is used by most enterprise Java application servers and Virgo is emerging as a new Equinox based platform.
6. Eclipse Release Train.  The Eclipse release trains have demonstrated open source communities can be predictable and scale to large distributed teams.   This is incredibly important as large more conservative companies become involved in open source.  Very few other organizations can claim a track record of predictability and scale that compares to the Eclipse community.
7. Eclipse Ecosystem.  Eclipse has become one of the two major development tools platform in the industry; MS Visual Studio being the other.   No matter what language you are using there is most likely an Eclipse IDE for you.  No matter what developer tool you are using, there is probably an Eclipse plugin.   No other platform has been able to create such a diverse and large ecosystem.  It has actually made building and integrating developer tools a lot easier!

De esto algo conocemos en la comunidad de Plex: al menos dos emprendimientos vinculan extensiones de Plex con las posibilidades de Eclipse: Webclient, creando una variante web ajax a partir de la generación de código Plex java, y el trabajo de Christopher Smith, mejorando el proceso de implementación de un modelo Plex. Dos sugerencias que abren un panorama más que positivo para el futuro.

El modelo de Eclipse + Plex... ¿+ Xtext?

Varios meses muy atareado. Vuelvo de dos semanas de vacaciones, y llega el momento de rematar el trabajo...Extendiendo dos modelos construídos con Plex, con una presentación basada en C++ y servicios llamados en iSeries-RPG400/RPGIV, para que puedan disponer una presentación Web. La parte Web, hecha con Webclient (ADC Austin), con su extensión Java/Javascript disparada a través del uso de Eclipse. Este es el segundo proyecto organizado fuera de CA usando Eclipse como un mediador para extender Plex (el primero, el open source encarado por Christopher Smith para usar las facilidades de test y depuración de Eclipse/java con Plex).
En fin, el proyecto funciona...A partir de los modelos diseñados para C++/RPG, creamos una variante Java-WebClient que separa el diseño de paneles (y reportes) en la variante, de tal forma que conviven en el mismo modelo dos paneles distintos; con sólo configurar una variante u otra, generamos paneles para cada lenguaje. La lógica la hemos desarrollado en la variante base (C++), usando metaoperaciones para separar las diferencias de implementación entre ambos lenguajes. Luego, el modelo declara en la variante Java-Web dos elementos: nueva herencia que indica qué tipo de paneles Web se construirán, y el lenguaje Java de implementación.Así, se genera distinto código según la variante configurada.
¿Cómo pasa el código de Plex a Eclipse? El código Java generado en Plex es tomado por scripts escritos en Ant y transferido a un proyecto JEE en Eclipse. El área de trabajo en Eclipse se compone de un proyecto Ant , uno Java, un servlet WebClient, y un proyecto Web (JEE). Por cada panel el proyecto java construye una función (servlet) que enlaza la presentación y los eventos interactivos con el código Javascript que ejecutará en tiempo real. El código javascript (Dojo + Json) está enlazado a plantillas tipo que son invocadas al indicarle al modelo que se hereda de determinados patrones Webclient.
Teóricamente, (y lo he puesto en práctica rudimentariamente) cada plantilla es factible de ser creada por el modelador. Mientras nos familiarizamos, nos hemos sujetado a utilizar las que están disponibles, modificando algunos aspectos de éstas, sea en las directivas de las plantillas o en las hojas de estilo asociadas.
El último paso es configurar los ficheros properties y adecuar el fichero de configuración de la aplicación Web (Web.xml), crear un paquete War, e implementarlo en Websphere (este paso resultó sorprendentemente más fácil de hacer de lo que esperaba).

Es decir, Plex es extendido en este caso agregando enteramente el código Ajax en un proyecto Eclipse, y asociándolo con el código Plex java mediante un servlet. Así, no sólo extendemos Plex a aplicaciones Web que se basan en Ajax, sino que podemos usar las facilidades de testeo y depuración de Eclipse: en una sesión normal, testeo el código java directamente en el ambiente Eclipse, y, usando Tomcat o Jetty, el código Web. Si hay diferencias de comportamiento, a revisar...(Consola de Java, Log de actividad del servlet).

Generalizando, la utilización de Eclipse por distintos grupos de desarrollos de Plex, puntualiza la potencia disponible a partir de esta combinación. Existen infinitos recursos disponibles en Eclipse, particularmente el Eclipse Modeling Framework, y las extensiones que lo utilizan (UML2, OCL). Aquí se ha mencionado a MODISCO (Model Discovery), como un elemento de mucho interés que debería ser seguido con atención. Y otro más debería ser seguido con máximo interés: Xtext, que por su versatilidad podría ser usado para extender Plex de muy distintas maneras.
Es mi parecer, y ojalá estuviera en mis posibilidades explorarlo, que es posible extender Plex para muy distintos alcances, entre ellos algunos que en más de una oportunidad fueron desestimados basados en el alcance estricto de sus generadores.
A modo de confirmación, dos discusiones (1,2) de finales de este mes muestran que es posible incluír IPhone o IPad entre las aplicaciones generables a partir de modelos Plex.

Críticas a MDD desde dentro: Rigidez del código, parte II

Tratando de completar las ideas que el primer punto de Johan sugiere, quisiera volver sobre el carácter abstracto de MDD (The goal of MDD is to ‘program' on a higher level of abstraction. This means that you have to specify less and generate more. However, this also means that you can't change every little detail you want).
Muchas de las objeciones atribuidas primero a MDA, pero luego extensibles a MDD (la visión ampliada y variada del diseño basado en modelos), están aquí. El primer acusado es UML, el estándar definido por OMG primero como herramienta de modelado, y luego como soporte para expresar modelos traducibles a código. ¿Es suficiente UML para expresar de manera abstracta toda la lógica de un sistema? ¿Es posible bajar en el nivel de detalle de un sistema recurriendo sólo a las herramientas propias de UML (vistas de diagramas y OCL)? Estas objeciones provienen especialmente de quienes usan o discuten MDA; sin embargo, no escapan a estas preguntas las variadas alternativas de solución ajenas a MDA (Johan describe algunas de estas variantes).
MDD, en sus distintas vertientes, probablemente esté atravesando un período parecido al que atravesara UML en la década de los 90: distintas notaciones se fueron forjando para expresar el diseño orientado a objetos, convergiendo en un esquema consensuado y no propietario, suficientemente potente como para responder a su tarea. El desarrollo de aplicaciones basado en modelos abstractos y generables, capaces de aplicarse a distintas plataformas y a distintas arquitecturas, mejorará sus herramientas y logrará mejores resultados. ¿El esquema de extensiones de Eclipse podría ser una respuesta a la apuntada "falta de flexibilidad"? ¿Alguna variante de DSLs aplicados en el espacio hoy llamado "rígido" podría aumentar la granularidad de los sistemas?
En el caso de Plex (mi herramienta de trabajo, para cualquiera que lo desconozca), este espacio está cubierto por el concepto de "diagramas de acción": llamémoslo un script abstracto, capaz de moverse en un meta nivel materializable en distintas encarnaciones, fuertemente restringido por los objetos a los que sirve (no es posible referirse a ningún objeto que no esté definido en el modelo, ni violar los tipos que manipula), que puede sin embargo ser detallado y minucioso. ¿Es una solución definitiva? No, porque globalmente podría llegar a expresar en un conjunto de diagramas algo contradictorio con el comportamiento esperado del modelo. No es sustituíble el trabajo del diseñador para expresar su modelo; un mal diseño también puede ser plasmado en un modelo escrito con UML.
En fin, digamos que el punto 1 de los ocho enumerados por Johan den Haan, pone el acento en un problema en discusión, que está en el laboratorio. Y que probablemente se refinará y quizá incluso desaparezca. Sin duda, en primer lugar, su objeción a la calidad de la interface gráfica.
En los próximos días seguiremos con otros puntos...

Críticas a MDD desde dentro: 1, rigidez del código

Desde hace pocos meses existe el foro The Model Driven Software Network (como aquí se comentó). En breve tiempo ha desarrollado un buen cruce de ideas, atrayendo a muchos de los teóricos, constructores, y poseedores de los distintos "sabores" en que se trabaja hoy en desarrollo basado en modelos. Curiosamente, en varias ocasiones se ha discutido allí en tono pesimista, poniendo acento en las dificultades que este tipo de desarrollo implica, pero dejando aparte lo que de positivo y productivo tiene. Probablemente, porque esto se da por sobreentendido, y a quienes construyen les interesa resolver los problemas en primer lugar.
En este contexto, en los últimos días dos miembros del foro han aportado algunas razones de las dificultades propias de MDD: Johan den Haan, que resume ocho razones por las que MDD es peligroso, y Peter Bell, puntualizando la importancia de la selección de un meta-metamodelo.
Particularmente las observaciones de Johan se han discutido más de una vez en TMDSN, y pueden servir de base para conversar sobre estos puntos críticos. Dado que el tiempo es escaso, conversaremos un punto por vez. Y el primero será la referencia a la "rigidez del código":

"If you're used to programming everything by hand, MDD can be quite rigid. The goal of MDD is to ‘program' on a higher level of abstraction. This means that you have to specify less and generate more. However, this also means that you can't change every little detail you want. It is, for example, often the case that generated graphical user interface are inflexible and they all look like each other."

Johan menciona aquí por lo menos dos aspectos: las características del código, y las de la interfaz gráfica. Particularmente el aspecto de la rigidez del código, de una u otra forma, es uno de los más discutidos en TMDSN, y donde se proponen soluciones más abiertas. En varios casos se cuestiona la limitación del código generable, por su incapacidad de alcanzar más allá del marco estático de un sistema. Al llegar al comportamiento (behavioural model) parece entrarse en un terreno abierto e inconcluso. Distintos caminos, algunos más "rígidos" que otros.
En cuanto a la interface grafica de usuario, que básicamente podría pertenecer al modelo estático, dificultades para definirla con el grado de detalle que se desee deberían considerarse limitaciones de la herramienta particular con la que se trabaje.
Pero volviendo a la posible "dureza" del código, esto tiene dos aspectos: la capacidad del modelo de expresar un problema, tan flexible y detallado como se requiera, y la calidad del código generado al transformar el modelo en código ejecutable. Es mi parecer que la herramienta que se use debe ser capaz de modelar el problema, y que si no lo logra, es incompleta. Estoy seguro de que casi todas las existentes son capaces de expresar una solución tan completa y articulada como se requiera. Y que esta capacidad puede refinarse progresivamente para ser todo lo dúctil que haga falta. Por otra parte, sin duda será rígido el código final ejecutable que se genere: Dado que el código proviene de las transformaciones preestablecidas entre el modelo y el código fuente resultante, éste siempre será escrito de la misma forma para los mismos elementos de modelo que "traduzca". Si bien eso es cierto, también es cierto que se trata de código probado, y que siempre será igual de confiable. Por supuesto, el todo generado no necesariamente será optimizado o seguro, pero esto es solucionable en un nivel más general: siempre es posible (y necesario) optimizar las transformaciones. Usualmente estas transformaciones son modificables, y, aún más, en muchos casos se trata de contrucciones "ad hoc". De paso, a mi entender, esta es la única vía de refactorizar en el desarrollo basado en modelos.
Donde se puede hablar de problemas con el código, es en el modelo dinámico (behavioural model). Muchas herramientas generan sin dificultad el modelo de clases, pero allí se detienen, requiriendo completar el comportamiento mediante extensiones construídas con programación estándar. Eclipse es preferido por muchos por su modelo basado en extensiones, y la posibilidad de integrar estas (construídas en código java en general) con el modelo al que soporte. Sin embargo este no es estrictamente el punto cuestionado por Johan. Lo tomaremos en otro momento...
Queda más por conversar. Recapitularemos en la semana.

MoDisco: Ingeniería reversa guiada por modelos

Jean Bézivin, a quien se ha recordado aquí más de una vez, promueve y participa en un proyecto de especial interés: MoDisco ( abreviando Model Discovery), que se propone la extracción de modelos partiendo del análisis de sistemas antiguos (legacy systems). A mi juicio, este es un movimiento de importancia en el camino de avanzar hacia aplicaciones basadas en modelos: Si se examina la realidad del uso de sistemas informáticos, el panorama deja una gran heterogeneidad, un gran volúmen de sistemas obsoletos, y una débil penetración de estos conceptos, que dominan las actividades de grupos académicos y conferencias, pero que representan un porcentaje bajo del modo en que se construyen las aplicaciones en el mundo real. Si tomamos las búsquedas laborales, los ránkings de uso de lenguajes, lo que se entrevé de la vida diaria, encontramos un extenso uso de lenguajes de tercera generación, comenzando por COBOL (especialmente en España), RPG, Visual Basic, Java, C, C++...Una coexistencia de viejas aplicaciones que no se tocan porque funcionan, con modernos intentos cubriendo aspectos parciales, o viceversa, modernos paquetes preplaneados que integran antiguos desarrollos.
Por tanto, una herramienta que partiendo de lo que existe, permite crear un marco de abstracción adecuado para encauzar la construcción de software, abre posibilidades de facilitar la ampliación del uso de mejores herramientas, acortando el camino entre el desarrollo basado en modelos y las aplicaciones existentes. Como siempre se ha destacado aquí, manejar la construcción de las aplicaciones desde la abstracción de un modelo es la manera de superar esta compleja coexistencia que inevitablemente se dará en la vida real.
En fin, el objetivo de MODISCO es facilitar un puente hacia este terreno.
De la presentación del proyecto:

MoDisco (for Model Discovery) is an Eclipse-GMT project for model-driven reverse engineering. The objective is to allow practical extractions of models from legacy systems. Because of the widely different nature and technological heterogeneity of legacy systems, there are several different ways to extract models from such systems. MoDisco proposes a generic and extensible metamodel-driven approach to model discovery. A basic framework and a set of guidelines are provided to the Eclipse contributors to bring their own solutions to discover models in various kinds of legacy.

Sobre la importancia de su enfoque para hacer ingeniería reversa de antiguos sistemas, dice su presentación:

What are the benefits of the MoDisco approach compared to already existing reverse engineering tools?

First, MoDisco proposes a unified approach to model-driven reverse engineering and a metamodel driven methodology. This way, we are able to work in the modeling world, coming from a heterogeneous world to a homogeneous one. The target model engineering space already proved its adaptability and scalability by several experiments to match requirements for data integration, tools interoperability and platform migration.

Moreover, the well structured modeling world allows easy manipulation of many different concepts in a unified way. For instance, every model can be transformed, weaved, extracted with the same tool set. As those operations are defined upon models’ metamodels, they are reusable for different use cases.

Una característica (propia de Eclipse) es su característica de ser extensible, lo que deja abierta la posibilidad de adecuarlo a diferentes requerimientos a partir de su núcleo.

The MoDisco framework is a generic framework that provides a basis for extension. It offers a minimum tool set to allow model discovery. The first component is a base metamodel. It is based on the Knowledge Discovery Metamodel (KDM) from the OMG. Actually, it is a minimal subset of KDM allowing end users to define (by extension) some KDM compliant metamodels. The framework offers facilities to manipulate models which metamodels are extensions of the base metamodel.

Sobre los soportes en que se basa MODISCO:

Due to the highly diversified nature of the considered legacy, MoDisco is a collaborative project involving several organizations. Each of them will bring its own expertise in a given area. MoDisco will use as often as possible the solutions elaborated by the OMG ADM (Architecture Driven Modernization) Task Force.
(...) As a GMT project, MoDisco will make good use of other GMT projects or solutions available in the Eclipse Modeling Project (EMF, M2M, GMF, TMF, etc), and more generally of any plugin available in the Eclipse environment.

Puede consultarse su documentación en el mismo sitio.

Nota: Este artículo fue adelantado parcialmente ayer. Esta es su versión "definitiva"
Nota 2: La imágen pertenece al sitio, y es reproducida en la hoja de información rápida y en el papel de presentación.