Aportes prácticos en el uso de DSLs

En los últimos días, quizá estimulados por la reciente conferencia de Code Generation, se han publicado algunos artículos sobre la experiencia de construcción de DSLs. Dos son muy recomendables: Pedro Molina extendiendo su presentación en la conferencia, y Juha-Pekka Tolvanen, y su lectura comentada del papel elaborado por Steven Kelly y Risto Pohjonen.
Destaca Juha-Pekka:

Among the worst practices identified my top three picks are using the code/library as source for language constructs, failing to consider language's real-life usage during language construction and not updating the language anymore after successful adoption

Pedro, por otra parte, analiza varios enfoques acerca de las vías adoptables para transformar la visión del modelo en código generado:

Doing commercial code generators, I’ve been tested lots of techniques: direct string concatenation, XSLT, direct code generation (or what Kathleen calls brute force code gen), ASP, JSP based approaches, developing custom template engines (two of them), taking a look to Code Smith, T4 and others, using NVelocity and finally arriving till StringTemplate (for the moment).

Dos trabajos para tener a mano.

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.

Plex y el concepto de Model Discovery

Pedro Molina comenta en su blog la intervención de Stuart Kent en CodeGeneration 2009, explicando las características del Visual Studio Team System para la reingeniería de aplicaciones (Model Discovery):

These tools are capable of selecting the source code of a solution and search for all the dependencies in the code. The tools produces an XML graph with the dependences and Visual Studio is able to draw them (a la Graphviz) and do drilldown from assemblies to namespaces, classes & methods.
I had to do this manually once: looking for cross references in more than 2.500 mini-applications of legacy code and finished it finally doing some kind of regex searching for the references, creating a text based graph and display it all with the quoted library GraphViz and some clustering techniques.

Hace pocos días se mencionó aquí otro caso, sumamente interesante, por su capacidad de extensión, Modisco. Este conjunto de herramientas está aún en desarrollo, pero apunta en la dirección de mayor interés, que es no sólo descubrir la arquitectura y la lógica de una aplicación antigua y probablemente no documentada, sino también desplegarla en un contexto nuevo, preparada para ser repensada sobre nuevas bases, las que aquí se proponen siempre. Un salto que implica salir de un conjunto de difícil mantenimiento, de conocimiento incierto, a un modelo capaz de ser mantenido, evolucionado, transportado y articulado entre distintas plataformas.
El problema de la ingeniería reversa de aplicaciones antiguas es complejo, y merece que le dediquemos en algún momento tiempo aparte. Y dadas las complejas posibilidades del entramado de software que cualquier organización encara hoy, atender a sus características y pensar el escenario debiera tener tiempo reservado.

Pero esta nota es para recordar, a propósito de MoDisco, que Plex dispone de una herramienta para facilitar el paso de aplicaciones antiguas a Plex, el Application Generator. Esto es de interés especialmente para quienes lo usan, que no siempre conocen este agregado, para quienes estudian pasar de 2E a Plex, o para quienes buscan una vía de modernización.
¿Cuál es el alcance de esta herramienta? Vale como un auxiliar, básicamente para el reconocimiento del esquema de la base de datos subyacente, y parcialmente para la importación de programas a un modelo Plex. Sólo es aplicable en tres escenarios: un conjunto de tablas posibles de tratar con ODBC, una base de datos DB2 en ISeries, o un subconjunto de este caso, que es un modelo 2E. En el caso de ODBC se pueden importar las definiciones y relaciones entre tablas, y en los otros dos casos se agregan a esta recuperación mínima, la obtención de los programas que manipulan estas tablas. La importación en este caso será como objetos de tipo API, cuyo comportamiento interno se desconoce, pero se exponen al modelo los parámetros que mantiene cada función. La importación no es directa, sino a un estadio intermedio (un repositorio) que es posible modificar, y al que se le puede aplicar herencia, a nivel de cada objeto identificado. La herencia se hace a partir de objetos del modelo al que se importará, con lo que es posible adaptar los objetos antiguos al modelo nuevo.
¿Es esto suficiente? No, evidentemente: un programa importado, al ser una "caja negra", es en realidad un objeto transitorio, que debería reinterpretarse en el nuevo modelo, o permanecer invariable. Este esquema es útil para quien evolucione el antiguo modelo, pasando por una transición manejada.
¿Es posible mejorarlo? Aquí entran las ideas de MoDisco, que parte de una base que es extensible, lo que pudiera abrir posibilides de elaborar herramientas aplicables a modelos Plex. Dado el creciente interés de la comunidad de usuarios de Plex por Eclipse, quizá esto no sea imposible.
¿Qué mejoras esperaría? Ahí caemos a las necesidades usuales en un proceso de ingeniería reversa de un viejo sistema. Y como esto es más general, como se ha dicho, vale la pena verlo aparte, en otro momento. Así será.

MDA + Scrum, un caso de uso

No me gustan las presentaciones en slides. Fundamentalmente cuando son off-line, porque entonces les falta el soporte de la explicación del presentador, que normalmente va mucho más allá, no sólo desarrollando los conceptos de cada página, sino muchas veces acompañándolas con acciones que ilustran claramente las cuatro líneas de cada hoja. Y sin hablar de la última página de la presentación, que termina con un "¿Preguntas?", que nos perdemos invariablemente. Si acaso se distribuyeran con notas ampliatorias, las que el presentador debe disponer y que nunca se escriben donde se debiera...
Pues bien, dejando a salvo esta objeción, quiero apuntar a la que prepararan los colegas de I2E para el curso de especialista universitario Java Enterprise de la Universidad de Alicante. Tengo dos razones: una, es la segunda vez que I2E presenta en este curso casos prácticos de uso de una herramienta y del estándar MDA. Sé por el modo en que muchas personas llegan a este sitio, que estos casos son buscados para ver en la vida real la construcción de software guiado por modelos.
La segunda razón es que en este caso acompañan el desarrollo de la aplicación con la explicación del modo en que manejan el proceso usando Scrum. En el último tiempo, curiosamente encuentro que muchos equipos y personas que usan algún sistema guiado por modelos (MDD/MDE), dudan al momento de estimar posible usar MDD con métodos ágiles. Particularmente, de la posibilidad de efectuar iteraciones frecuentes. Volveremos sobre ésto, que creo que más bien revela fallos puntuales de algunos esquemas de trabajo.
En fin, retomando la presentación, se la puede seguir en Slideshare: la actual, y la anterior, que alguna vez se mencionó antes aquí. Probablemente, si su lectura despierta preguntas, Emilio o José Luis podrán ampliar su contenido.

Rápida y breve historia del desarrollo en la Web

Un gráfico suele ayudar a entender un problema, particularmente las líneas de tiempo. Publicadas en Wikipedia, dos "timelines" sobre evolución de lenguajes y de browsers tienen la virtud de hacer visible el fulminante crecimiento de Internet como carril del desarrollo del software. Con trabajos precursores a finales de los ochenta, a partir de la década del 90 su crecimiento convirtió cualquier predicción sobre su evolución en hechos consumados en pocos años, retroalimentando una espiral de crecimiento que abre posibilidades apenas imaginadas quince años antes. Un impacto que promete cambiar profundamente las posibilidades de conocimiento del conjunto de la sociedad urbana.
Aquí se publica uno de ellos. El otro, se lo puede encontrar en Wikimedia.
Los artículos de Wikipedia que los sustentan son History of the web browser, y Web development.

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.

"En cinco años, Internet será de pago"

El 10 de junio, Barry Diller, CEO de IAC, conversa con el columnista Jon Fine, de BusinessWeek, acerca del futuro de Internet, afirmando que "absolutamente" se convertirá en un sistema de pago. La conversación fue ampliamente difundida y comentada, como una búsqueda simple en Google lo puede comprobar. Algunas opiniones favorables, y nubes de argumentaciones en contra. Evidentemente, el modelo de negocios está puesto sobre la mesa, y cada uno deberá (o deberemos) defender un punto de vista.
Caroline McCarthy en Cnet resume las palabras de Diller:

While much of the "new IAC" relies on advertising revenue, Diller declared at the conference that strictly relying on advertising as a business model is not sustainable. "I absolutely believe that the Internet is passing from its free phase into a paid system," he predicted (though, keep in mind, Diller did say he doesn't like to predict). "Inevitably, I promise you, it will be paid. Not every single thing, but everything of any value. Again, take commodity away from it."

The wealth of free content on the Internet was a matter of short-sightedness, Diller explained. In his opinion, it came out of the fear of piracy.

"People were so frightened of not being dinosaurs, and baring their heads, and not having what happened to the music industry happen to them, they just slapped everything up on the Internet for free," he said. "That's an accidental historical moment that will absolutely be corrected."

Diller doesn't believe that the poor economy will make it more difficult to get people to pay for things online. One of his subscription-based businesses, dating site Match.com, is doing very well right now: "It would not shock any of you that I think that of the things that, actually, people will do when enduring a storm, financial disaster, or otherwise, is want to hook up in one way or another with other people," Diller said.

Why is he such a believer in the triumph of paid content? Look at the iPhone, Diller told the audience, and the wild success of its App Store.

"The iPhone is a great example of what's going to happen," he pointed out. ""One of the greatest barriers to buying things is the steps that it takes, and we all know the difference when you go to Amazon and you just push your little thing and it's bought, paid for, delivered, billed, et cetera., instantly, and how much that has enabled or how much that has made the difference between just browsing and buying...that little thing, that in fact you scroll it, you do it, it comes, everything else is taken care of, is the answer to what's going to happen on the Internet when, in fact, we get the applicability of that broadly."

He acknowledged that media outlets' readership rates may drop, but that their profits will stabilize once again.

En ZDNet, Tom Steinert-Threlkeld comenta también las palabras de Diller, puntualizando cómo éste ve los mecanismos de pago:

So far, news, content and service suppliers were “afraid of not being dinosaurs and slapped everything up on the Internet for free,’’ he said, in an interchange with BusinessWeek media columnist Jon Fine.

But, that will be change. The New York Times, for instance, likely will have to go beyond the “pay wall” in order to cover the cost of its worldwide reporting corps, even if it means having 1, 2 or 3 million paid subscribers, instead of 20 million unique visitors a month. And people will pay – if it is quality they’re buying.

“People have paid for content,’’ he said. “They always have.”

IAC’s Match.com, a dating service, already charges subscription fees. IAC also operates Ask.com, the search service, UrbanSpoon, one of those iPhone apps, Citysearch, a local information service, and The Daily Beast, a content site headed by former New Yorker editor Tina Brown.

Inevitably, Diller said, the “base model” of the Internet will be paid, at the end of the chaos. The forms will include not just subscriptions and individual one-time purchases, but rapid-fire micropayments and other mechanisms.

The early examples: Amazon’s “one-click” system, where a customer enters billing address and credit card information in advance. Then, a button on the screen for a shopping cart is pressed once and the purchase or purchases associated with that cart are confirmed, billed, paid for and delivered.

Similarly, with the App Store for Apple’s iPhone handheld computing and communication devices, “the real trick and key is the billing system and the way of doing it is absolutely a blink,’’ he said.

The right billing system, broadly applied, would remove “one of the greatest bars of buying anything” which “is the steps it takes” to complete a purchase.

The entire Internet, in effect, would become an app – or content – store.

“That little thing – that in fact that you scroll it, you do it, it comes, everything else is taken care of, is the answer to what’s going to happen on the Internet, when in fact, you get the applicability of that broadly across the Internet,” Diller said. “It’s absolutely going to happen.”

And given the movement of ad and subscription revenue to the Internet, “people who manufacture that content will have no alternative,” he said.

The biggest disruptor? When broadband pipes to the Internet are connected to large screens in living rooms around the world and users are interacting with its increasingly video-based content with a remote control.

At that point, television, radio and prior media founded on scarcity, like limited spectrum whose use is overseen by governments, “will be run over by this much more open, much much less controlled (medium) that is not based on scarcity, but based on unbelievable plenty,” Diller said

Tom lleva más de trescientas respuestas; esta es una de ellas:

Saying it will become a paid system in 5 years is basically living in a delusional bubble. It has been a paid system from the start.

Everyone pays for the Internet already. We pay for the speed of the connection. Some pay email providers. Some pay for online storage. Some pay by buying products online. Some pay for rare and valuable information or to receive specific publications. We also pay with the attention we give to advertisements on our favorite sites. We pay with the time we waste sorting through all the spam we get from advertisers.

Why doesn't it surprise me that it's an old fart saying how people have always paid for content and will continue? People have always been able to listen to the radio and watch television for FREE, too. That swings both ways and means nothing.

That sort of ancient-mindset is why the recording industry is having so much trouble these days. It reeks of the mindset of control freaks from a 50's industry like the RIAA or MPAA. Start charging for or somehow limiting the content people already get for free and you will go bankrupt unless you can add enough value to justify the charges.

These days people want more from content. These days the REAL product you need to sell is improved quality of life. How will your content make my life better? How will it save me time? How will it smooth out my daily routine? Focus on that instead of how much you can squeeze out of somebody because of X bytes of your bandwidth they used.

What people might pay for is value-added and highly-targeted content available on their own schedule. If you want an example of the RIGHT way to get people to pay for a content service, look at what TIVO did for TV or NetFlix with instant Internet streaming. Even digital music purchased through iTunes is an example of how to sell content to a busy, overstressed public. Charging by the megabyte will only piss them off by giving them one more thing to count and worry about. Make it simple. Make it transparent. Make it worry free. Make our lives better. Then we'll talk.

Para tener una guía: Historia del diseño de interface gráfica

Con poco tiempo disponible, de entre todo el material que leo y clasifico, quisiera destacar la recopilación de Gyorgy Fekete publicada en WebDesignerDepot en marzo de este año, historiando las distintas tentativas de crear una interface gráfica al sistema operativo, desde 1981 hasta hoy. A la recopilación le hubiera venido bien una fundamentación de las distintas líneas de análisis del problema, y de las corrientes principales históricas (particularmente una línea abierta para POSIX hubiera ayudado a visualizar las líneas existentes en la industria). También hubiera sido interesante presentar este recorrido gráficamente, a modo de un árbol darwiniano. Como en zoología, no todas las buenas ramas tuvieron éxito...
En mi caso, mis primeras actividades fueron sobre el Mac Os 1.0, Windows 2.0 y AIX ¿y en su caso?
El crédito del encuentro de este artículo es de André Furtado, a quien sigo en del.icio.us desde la época de su graduación en Brasil, debido a su interesante trabajo sobre software factories. No viene al caso, pero debiéramos seguir un poco más el trabajo de las universidades brasileras.