Un afilado comentario sobre el estado del uso de modelos

Scott Finnie publica a finales de Septiembre un acertado comentario (a mi juicio por lo menos) crítico sobre el estado y evolución del uso de modelado en la vida real, en sus distintas vertientes actuales. Finnie encuentra que algunas de las tendencias en modelado han evolucionado mal, y prácticamente no encuentra alguna via conceptual o herramienta aplicada que sea totalmente satisfactoria.
Finnie comienza dedicando un párrafo breve a los métodos más formales, que considera en general inaplicables por sus exigencias:

Formal methods can definitely contribute to the “better software” imperative. Any impact on “faster” is a second order effect however: the models have to be translated into working software by hand. And the learning curve can be steep, requiring a solid foundation in the theory and notation of one or more mathematical disciplines (predicate logic, sets, graphs).

En segundo lugar, Finnie se ocupa de los lenguajes específicos de dominio (DSLs) sobre los que señala sus límites de adopción en la dificultad que representa sumir la creación de lenguajes adecuados a una diversidad de problemas por parte de equipos de empresa. Sólo los ve aceptables en nichos de empresas cuyo producto es el software, en general:

Domain-specific approaches can directly address both “better” and “faster”. But they are not without hurdles, both technical and organisational. On the technical front it’s the challenges of language design. Textual approaches (e.g. Spoofax, Xtext, MPS, Rascal) require the designer to understand compiler construction: parsing, linking, semantic analysis, type systems and so on. Graphical approaches such as MetaEdit+ perhaps simplify that. But there’s still the question of designing a language.
The organisational barriers are at least as significant – and independent of the textual/graphical debate. Getting traction for a DSL depends heavily on the organisation’s approach to software. It’s possible in companies building software products, especially those offering related product families. The cost of investing in language design and tooling is justified through repeatability and hence efficiency. But not all software falls into the “product family” bucket. Even when it does, some organisations – and many developers – are nervous about building a proprietary language. Maintainability, recruitment and CV curation can be powerful adversarial forces.

Finalmente, se enfoca en los lenguajes de modelado de propósito general, de los que espera más, pero encuentra grandes dificultades. La principal objeción a este tipo de modelado, enfocándose fundamentalmente en UML, es la incapacidad de casi todas las variantes desarrolladas de pasar de un esquema más o menos definido, a código ejecutable, o como suele decirse, a modelos ejecutables:

The vast majority of UML models are mere sketches. Sketches aren’t working software.
Sketches need lots of human endeavour to translate them into working software. Which isn’t to say they’re bad: a quick diagram on the whiteboard can be invaluable. But it’s a long way from working software. At the height of its hype curve, the UML wasn’t capable of describing precise, executable models(²). Without those, it’s impossible to automate software generation. Without automation, we don’t get better software quicker.
This is the fundamental mistake with MDA:

1. An incomplete language intended for sketches is not a viable basis for precise, executable models.
2. Without precise models,
   1. no formal checking can take place. So the impact on “better” is marginal;
   2. no process automation can take place. So the impact on “faster” is at best nil.

Summing up: MDA didn’t deliver better software quicker. It had the hype and the backing of large organisations. It didn’t stick because, brutally, it didn’t work.
So – in the context of general purpose modelling – let’s be clear about this: as long as a manually intensive process sits between a model and working software, the model is no more valuable than a sketch.

Finnie sostiene que hoy están dadas las condiciones para reparar estas faltas. Enumera una lista de asuntos por ajustar y resolver, con final abierto:

• whilst there are a plethora of tools for building models, few of them support executable models. Of that few, far fewer still are actually rewarding to use.
• we’re missing the pre-existing models that serve as exemplars. Models that are demonstrably translated into real, working software. Models that can be adapted or reused to meet different requirements.
• we’re missing the translators that turn those models into working software. Automatically, quickly and repeatably. We have the tools to write those translators: we don’t have the translators themselves. At least not robust, industrial quality translators that produce robust, industrial quality software. That can be used by real users or sold to real customers. Results that looks as good as, and function as well as, ‘hand written’ alternatives. Crucially, those translators need to be open for adaptation.
• we’re missing the cohesive environments that make it easy. Environments that don’t need weird hacks or obtuse incantations to make them work. Tools that “just work”. Tools that combine the constituent parts for modelling and translation into a consistent, seamless, industrial-quality experience.
• we’re missing eco-systems that pull these things together to forge communities. Communities that generate interest because they’re doing cool stuff.

Ante esta discusión, que creo que sigue siendo de interés fundamental, desde nuestra comunidad de usuarios de Plex...¿cuántas oportunidades se han perdido  en este camino para lograr una mayor abstracción y alcance?
Nota: si lee el artículo de Finnie, no deje de leer también los comentarios posteriores.

Evolución o desajuste: un asunto crítico

De interés para usuarios de Plex; en el último tiempo, varias discusiones importantes se han desarrollado en la comunidad de usuarios en CA. Discusiones que van en dos direcciones: prometedores nuevos desarrollos, y retrasos lamentables en el soporte de nuevas tecnologías. Esta dualidad refleja probablemente la situación del producto: un gran capital en una herramienta robusta que no pierde utilidad, y una respuesta errática a los cambios tecnológicos. Puntualizo algunas de las discusiones, e invito a revisarlas, y en el caso de las ideas propuestas, a votarlas si les parecen adecuadas. Las menciono por su título:
Outlook question: la discusión abierta es acerca del soporte de WinApi, ObMapi, es decir, el sistema de mensajería, para Outlook 2013 (también se menciona Outlook 2010). El problema reside en que el API está soportado para 64 bits, pero no para 32 bits, y Plex es generado para 32 bits. Esta es la respuesta del soporte de Plex:

There is a compatibility issue between the 64-bit versions of Microsoft Outlook and other 32-bit applications. Since Plex generates 32-bit application, you will need to use the 32-bit versions of Outlook.  (remite a la explicación de Microsoft). So, if you are using the OBMAPI or WINAPI Souce Code mail APIs, then you will not be able to use the 64-bit version of Outlook 2013 with these APIs.

La solución ofrecida es usar la versión de Office de 32 bits, o usar otro código, o solicitar al equipo de desarrollo que estas APIs soporten 64 bits. El propio soporte recomienda esta última opción, que conduce a  una solicitud existente desde julio de 2014.
Sobre este asunto del atraso en el soporte de productos u opciones respecto a la evolución tecnológica actual, hay otra discusión que afecta a 2E, no Plex, pero donde valen las opiniones de los participantes, ya que podrían asociarse sin mucha dificultad también a Plex: la complejidad de plataformas y tecnologías que deberían abarcarse hace difícil mantener el paso. En el caso de Office, el problema resulta aún más claro: los cambios de arquitectura ensayados por Microsoft son capaces de hundir a cientos de proveedores de servicios que trabajan para su plataforma (partners), como sucediera con el mercado de Silverlight, y seguramente con los incipientes desarrollos orietados al cuasi difunto Metro.
Otras discusiones de importancia vienen de la sección de Ideas, por ejemplo la postulación de la generación de servicios REST sobre el System i (discusión especialmente interesante), o las dos o tres referencias a la actalización del soporte de SQL en el System i (1, 2). O incluso las postulaciones a mejoras en el soporte de RPG ILE. Todos ellos hablan de un retraso de soporte a la evolución de las distintas plataformas, que resulta prioritario resolver. Hoy la evolución tecnológica es rápida y diversa, y resulta muy difícil abarcar el espectro completo de arquitecturas, tecnologías y paradigmas. Aún para el paradigma de diseño basado en modelos, resulta difícil seguir el paso para elaborar transformaciones adecuadas a cada caso y sus interrelaciones. ¿Qué camino es más aconsejable en éste caso, el de Plex?
Desde hace años, la solución de las transformaciones para atender nuevas áreas en Plex han estado a cargo de terceros; sea socios de negocios, como en el caso de los desarrollos web, telefonía móvil, e incipientemente cloud por parte de SoftDesign (Websydian) y CM First (WebClient), o los desarrollos para XML de Simon Jasperse, o los minipatterns debidos a Peter Fabel y Luwdig Hirth, o Stella Tools de George Jeffcock. Probablemente este sea el mejor modo de poder atender, especialmente sin un elevado presupuesto de investigación, la avasalladora ola de cambios en que nos movemos.
También desde hace años, el equipo de desarrollo de Plex expone crecientemente el API que permite la interrogación y operación del modelo, sus objetos y sus métodos. Es gracias a ésto que herramientas como Stella Tools puede trabajar. Probablemente esta vía sea la mejor para el desarrollo del modelador y sus generadores. Sería muy positivo que el trabajo del laboratorio de desarrollo de Plex se concentrara en éste aspecto: los modos para extender el modelador, para extender la inclusión de nuevos generadores que puedan ser elaborados por terceros. Estos terceros podrían ser empresas interesadas en extender la generación de código final a un nuevo área, o empresas  interesadas en adecuar una extensión a sus propias necesidades. Al modo en que Xtext trabaja hoy como DSL. Creo que ésta es la salida viable de Plex en éste momento, y allí deberían centrarse los esfuerzos.

Diez reglas para recordar (y seguir...)

Firmado por Javin Paul, un artículo que recuerda diez reglas importantes de orientación a objetos en el diseño con Java (10 Object Oriented Design Principles Java Programmer should know), que podríamos extender fácilmente a otros campos (y estoy pensando en Plex). Un pequeño decálogo, tan escueto que podríamos pegarlo en una pizarra frente a nuestros ojos, y que deberíamos repasar todos los días.

 DRY (Don't repeat yourself)
Our first object oriented design principle is DRY, as name suggest DRY (don't repeat yourself) means don't write duplicate code, instead use Abstraction to abstract common things in one place. If you have block of code in more than two place consider making it a separate method, or if you use a hard-coded value more than one time make them public final constant. Benefit of this Object oriented design principle is in maintenance. It's important  not to abuse it, duplication is not for code, but for functionality . It means, if you used common code to validate OrderID and SSN it doesn’t mean they are same or they will remain same in future. By using common code for two different functionality or thing you closely couple them forever and when your OrderID changes its format , your SSN validation code will break. So beware of such coupling and just don’t combine anything which uses similar code but are not related.

Encapsulate What Changes
Only one thing is constant in software field and that is "Change", So encapsulate the code you expect or suspect to be changed in future. Benefit of this OOPS Design principle is that Its easy to test and maintain proper encapsulated code. If you are coding in Java then follow principle of making variable and methods private by default and increasing access step by step e.g. from private to protected and not public. Several of design pattern in Java uses Encapsulation, Factory design pattern is one example of Encapsulation which encapsulate object creation code and provides flexibility to introduce new product later with no impact on existing code.

Open Closed Design Principle
Classes, methods or functions should be Open for extension (new functionality) and Closed for modification. This is another beautiful SOLID design principle, which prevents some-one from changing already tried and tested code. Ideally if you are adding new functionality only than your code should be tested and that's the goal of Open Closed Design principle. By the way, Open Closed principle is "O" from SOLID acronym.

Single Responsibility Principle (SRP)
Single Responsibility Principle is another SOLID design principle, and represent  "S" on SOLID acronym. As per SRP, there should not be more than one reason for a class to change, or a class should always handle single functionality. If you put more than one functionality in one Class in Java  it introduce coupling between two functionality and even if you change one functionality there is chance you broke coupled functionality,  which require another round of testing to avoid any surprise on production environment.

Dependency Injection or Inversion principle
Don't ask for dependency it will be provided to you by framework. This has been very well implemented in Spring framework, beauty of this design principle is that any class which is injected by DI framework is easy to test with mock object and easier to maintain because object creation code is centralized in framework and client code is not littered with that.There are multiple ways to  implemented Dependency injection like using  byte code instrumentation which some AOP (Aspect Oriented programming) framework like AspectJ does or by using proxies just like used in Spring. See this example of IOC and DI design pattern to learn more about this SOLID design principle. It represent "D" on SOLID acronym.

Favor Composition over Inheritance
Always favor composition over inheritance ,if possible. Some of you may argue this, but I found that Composition is lot more flexible than Inheritance. Composition allows to change behavior of a class at runtime by setting property during runtime and by using Interfaces to compose a class we use polymorphism which provides flexibility of to replace with better implementation any time. Even Effective Java advise to favor composition over inheritance.

Liskov Substitution Principle (LSP)
According to Liskov Substitution Principle, Subtypes must be substitutable for super type i.e. methods or functions which uses super class type must be able to work with object of sub class without any issue". LSP is closely related to Single responsibility principle and Interface Segregation Principle. If a class has more functionality than subclass might not support some of the functionality ,and does violated LSP. In order to follow LSP SOLID design principle, derived class or sub class must enhance functionality, but not reduce them. LSP represent  "L" on SOLID acronym.

Interface Segregation principle (ISP)
Interface Segregation Principle stats that, a client should not implement an interface, if it doesn't use that. This happens mostly when one interface contains more than one functionality, and client only need one functionality and not other.Interface design is tricky job because once you release your interface you can not change it without breaking all implementation. Another benefit of this design principle in Java is, interface has disadvantage to implement all method before any class can use it so having single functionality means less method to implement.

Programming for Interface not implementation
Always program for interface and not for implementation this will lead to flexible code which can work with any new implementation of interface. So use interface type on variables, return types of method or argument type of methods in Java. This has been advised by many Java programmer including in Effective Java and head first design pattern book.

Delegation principle
Don't do all stuff  by yourself,  delegate it to respective class. Classical example of delegation design principle is equals() and hashCode() method in Java. In order to compare two object for equality we ask class itself to do comparison instead of Client class doing that check. Benefit of this design principle is no duplication of code and pretty easy to modify behavior.

Y volviendo sobre la idea de su aplicabilidad en Plex, sin duda lo es. En algunos casos fácilmente entendible, (Favor Composition over Inheritance, Encapsulate What Changes, DRY,  Favor Composition over Inheritance) y en otros casos, después de luchar contra la vía fácil de hacer las cosas (Programming for Interface not implementation). Solo veo difícil implementar Dependency Injection. Y cuando me refiero a aplicabilidad, lo hago a nivel del modelo, no a nivel del código generado, donde su aplicabilidad está asegurada.
Plex, como otros productos, admite distintas interpretaciones, distintas formas de desarrollar. Aplicar principios de OOD permite explotarlo en forma más productiva, potenciando sus características. Luchar por no usar una hoja de ruta rutinaria favorece resultados consistentes y duraderos.

UML en la ICSE 2013

Anteúltimo día de ICSE 2013 (International Conference on Software Engineering) , que muestra un gran número de trabajos de interés y participantes. A esta hora, destaco el que Timothy Lethbridge comenta, aunque por razones diversas: la presentación de Marian Petre "UML in practice", que resume su investigación sobre una muestra de desarrolladores de software, respecto a su uso o no de UML. En el resúmen de Timothy

She conducted an excellent interview-based study of 50 software developers in a wide variety of industries and geographical locations. Her key question was, "Do you use UML".

She found that only 15 out of 50 use it in some way, and none use it wholeheartedly.

A total of 11 use it selectively, adapting it as necessary depending on the audience. Of this group use of diagram types was: Class diagrams: 7, sequence diagrams: 6, activity diagrams: 6, state diagrams: 2 and use case diagrams: 1.

Only 3 used it for code generation; these were generally in the context of product lines and embedded software. Such users, however, tended not to use it for early phases of design, only for generation.

One used it in what she called 'retrofit' mode, i.e. "Not unless the client demands it for some reason".

That leaves the 35 software developers who do not use it (70%). Some reported historical use, and some of these did in fact model using their own notation.

The main complaints were that it is unnecessarily complex, lacks and ability to represent the whole system, and has difficulties when it comes to synchronization of artifacts. There were also comments about certain diagram types, such as state machines being only used as an aid to thinking. In general, diagram types were seen as not working well together.

She did comment on the fact that UML is widely taught in educational programs.

Como Tijs van der Storm comenta, quizá Marian esté martillando los últimos clavos en el ataúd de UML...

También coinciden en sus comentarios James Noble,  Alex Nederlof, y Leif Singer, entre otros. Éste último apunta al uso de UML en educación registrado por Marian, como muchas veces, y en muchos aspectos, corriendo detrás de la situación real.

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.

MDD: Una polémica en castellano

Javier Garzas ha tenido la muy buena idea de transcribir en su blog una discusión que sostuviera poco antes en Twitter con otros colegas españoles, acerca del alcance y validez del desarrollo basado en modelos, y de su confrontación y validez frente al concepto "el diseño es el código". La discusión refleja entre sus lectores un gran interés en el tema, pero también un persistente desconocimiento, y además algo de desconfianza y rechazo acerca de la idea del desarrollo guiado por modelos. No tengo tiempo hoy para otra cosa que no sea recomendar su lectura y, para quienes lo crean necesario, participar en la discusión. Espero tener tiempo el fin de semana para hacer algo más que recomendar su artículo, y la lectura de los comentarios de sus lectores. Entretanto, gracias especialmente a Javier y Pedro por su gran discusión.

Esperando noticias de la conferencia...

Entre el 1 y el 3 de junio se desarrolló la conferencia anual de Plex. No habiendo participado, espero las noticias...En unos días, más detalles de lo que el programa anticipaba.
No es la única conferencia de la que espero noticias: también una semana antes se completó la conferencia de Code Generation Network. En este caso, algunos adelantos han dado Pedro Molina, Marco Brambilla, Angelo Hulshout y  Johan den Haan, entre otros. Lamentablemente, estas semanas, poco tiempo para dedicar por anticipado...

Dos interesantes discusiones

En The Model Driven Software Network, están en desarrollo dos discusiones muy interesantes de seguir: dos preguntas que hacen a la vigencia y alcance del desarrollo guiado por modelos:
The new Golden-Egg : Model-Driven Business Platforms – Why big players aren’t there yet?
Can you really use UML to generate majority of your source code?
En principio, lea la discusión. En los próximos días, algo conversaremos.

Jean Bezivin y MDE, segunda entrada

Jean Bezivin acaba de publicar una nueva entrada sobre el orígen de MDA/MDE.
Dice Jean:

Why this change, between 1995 and 1996 from “Unified Method” to “Unified Language“? The reason is that, at this period people realized that there was no possibility to propose a unique software development method. The goal of the OOAD at OMG was not only too ambitious, but is was an impossible mission.
There is an infinity of possible software processes answering the question of who is doing what, when, how and why in the software development and maintenance world.
The decision of OMG to reduce the ambition of this initiative was most clever.

Recuerdo haber visto antes su esquema del orígen de UML. ¿Cómo seguirá ahora el grafo? ¿Otras variantes colaterales de entonces, o posteriores, no estarán en su futura derivación?

Jean Bezivin recuerda el orígen de MDE...

Jean Bezivin recuerda en su nuevo blog el orígen del desarrollo basado en modelos a partir de discusiones durante la reunión de OMG en noviembre del 96. El relato es particularmente interesante por estimar que las concesiones acordadas para lograr la aceptación de todos los participantes (particularmente IBM), determinaron seguir la peor bifurcación posible del camino: el soporte de OCL (This is the place where history was made. Probably not in a full OMG meeting at the main hotel, but in some café of the”Promenade des anglais”. I suspect that the discussion went somehow as follows: “It is impossible to ignore IBM proposal, but on the other side we don’t want to take their full proposal. Which one shall we chose? OCL or Modeling Schemas?“ I dont claim that they used coin tossing, but the result was clear: OCL was choosen for the best and the worst and the second proposal of Modeling Schemes was simply ignored.)

Historia viva de un modelo de desarrollo todavía en construcción...¿Alguien más se motivará para abrir su visión de entonces? ¿Steve Cook? ¿Bran Selic?

Diseño dirigido por modelos, en tránsito

Jean-Jacques Dubray publica en InfoQ hace ya algunos días, algunas reflexiones sobre el desarrollo basado en modelos, indagando sobre su estado actual, y sus posibilidades de ganar terreno, o de sus dificultades para hacerlo. Su nota fue seguida por un buen número de comentarios, que dan también una idea aproximada del estado de su uso:

Ulrik Eklund published a summary of the keynote speech from Jon Whittle at the SPLC 2010 conference. In his talk, he presented some findings on experiences from using model-based development in industry from the EA-MDE project. The project is interested in understanding the factors that lead to success or failure with model-driven engineering (MDE) to help design the next generation of MDE tools. This question is not new, two years ago, Sven Efftinge, Peter Friese and Jan Köhnlein published an article "MDD best practices and Johan Den Haan, CTO of Mendix, published an article on the how an MDD initiative could fail. Adopting an MDE approach can be quite daunting. Then, Johan concluded his article by:

It’s not my goal to discourage you from starting with model-driven software development. I just wanted to show you the complexity of it and wanted to share some thoughts hopefully pointing you at directions helping you to overcome the complexity of MDE.

Two weeks ago he also published an article on his blog detailing the lessons he learned while building a Model Driven Software Factory and he reiterated the same skepticism:

I see Model Driven Software Development as an important part of the future of software development. However, I also see a lot of people struggle with actually using Model-Driven techniques and applying them in their daily business. It isn't trivial to build a successful Model-Driven Software factory (MDSF).

The question is actually quite popular. Last week, Marco Bramballi and Stefano Butti also published a presentation on the same topic while applying BPM and MDD to a Large Scale banking scenario with BPMN, WebML and WebRation.
In his talk, Jon provided some key success factors of a successful MDE approach, as he identified as part of his research:

1. Keep the domains (modelled, I assume) tight and narrow.
2. Target well known domains.
3. Put MDD on the critical path (he means that pilot projects never get sufficient attention and resources).
4. MDD works best form the ground up.
5. Be careful of gains that are offset elsewhere.
6. Don't obsess about code generation.
7. Not everyone can think abstractly.
8. Most projects fail at scale-up
9. Match tolls and processes to the way people think, not the other way around

In their articles, Swen, Peter and Jan also warned:

Our most important recommendation for the reader is: be pragmatic. DSLs and code generators can, when used appropriately, be an immensely useful tool. But the focus should always be the problem to be solved. In many cases, it makes sense to describe certain, but not all, aspects using DSLs.

Even though MDE is still evolving quite rapidly, Jon reports that 83% of the EA-MDE survey respondents "consider MDE a good thing".
After over a decade of Model Driven Architecture, Development and Engineering and which itself followed some rich Model Driven Development environments like NeXTStep that emerged in the early late 80s, models are everywhere, yet, in such a small quantity that our industry seems to still be looking for the path that will make Model-Driven approaches mainstream. Are we really in the position of defining "lessons learned" or "best practices" with so few successes reported? What is hampering us? Is it the focus and precisions of the model? Is it lack of tools? standards? Is is the level of abstraction that make it difficult for most people to create a viable software factory? What's your take on it?

A esta invitación final de Jean-Jacques a discutir le siguieron muchas e interesantes respuestas. Siguen algunas de ellas:
Rui Curado, autor de su propia herramienta, destaca algo que comparto:

Existing model-driven approaches were conceived by "top-notch" developers/mathematicians. This lead to the assumption that those who would use such approaches are "top-notch" developers too. And this is precisely what is happening: Current MDD practitioners belong to the "top 1%".
Most of the world's developer population (myself included) are what I call the "average developer mortal": developers who are good at their job without actually being "geniuses". People who do things the right way, but pragmatically. We are the "everyday programmer". MDD approaches and tools fail to address us

Sobre el enfoque orientado a objetos de las actuales herramientas orientadas a MDD, dice Dean Wampler:

[...] all the MDD approaches that I know of are based on objects. Unfortunately, objects have proven to be poor at defining reusable component standards. That's a controversial statement, but to prove it, ask yourself why the world's most successful "component" standards, like TCP/IP, HTTP, busses in digital electronics, etc. are not object oriented, while OO-based component standards, like CORBA, proved to be too complex to survive the test of time and to achieve ubiquitous, permanent adoption. (Still not convinced? "Design Rules, Vol. 1: The Power of Modularity" discusses the characteristics of successful modularity standards. Very few OO APIs meet those criteria.)

Dice Steven Kelly, sobre las condiciones para elaborar un modelo satisfactorio:

The key issues are:
1) use a language that is highly targeted, efficient and precise at describing the systems you want to build (and thus useless for most other systems)
2) generate production quality code that you don't need to look at or touch
3) use a toolset that makes creating the language, generators and models efficient, scalable and maintainable.

[...] Failing to reach (or even aim for) those 3 targets is what consigns most MDD attempts to mediocrity or failure. Using a tool or language because it's a "standard" or already in use is hardly likely to result in major productivity increases compared to normal. As Einstein said, insanity is doing the same things as before and expecting different results.

Steven, respondiendo a una pregunta de Dubray, dice, respecto a su afirmación de generación completa de código:

100% code generation is definitely the goal, and the norm is to achieve it. Here, 100% means 100% of the code that is specific to this model. There is of course hand-written code below the generated code: what we call the domain framework, i.e. code specifically written to complement this modeling language and generators, and which doesn't change per model.

In some cases a particular model may need an addition to the domain framework; in others models may contain snippets of code or refer to per-model functions that are hand-coded separately.

If by "custom models" you mean "custom modeling languages", then yes, at least that has been my experience. I'm not sure it's "inherently" true, but I think there are good reasons for it. Have you ever seen a tricky or laborious problem can be turned into something an order of magnitude faster and easier by applying the correct language? If so, you probably understand what I'm talking about. Obviously, in general development those situations were rare, because the right language didn't yet exist. DSM lets you create that "right language" for your needs.

Una vez más, un punto cuestionado es el uso de UML, que es confrontado con DSL (Domain Specific Languages). Por supuesto, Steven Kelly, uno de los gestores de Metaedit, es quien especialmente pone el acento en DSM (Domain Specific Modelling). Dice Kelly:

As Dean Wampler said, "Give me a language and APIs that let me express what I need to do very succinctly!" That of course is the whole idea of DSM, and why it is so different from (say) UML-based MDA. It's just a shame that working "code generation" often gets tarred with the same brush as approaches that have failed.

Of course, we're all constrained by what we have experienced personally, e.g. Dean saying that all MDD he has seen has been based on object-oriented languages (I guess referring to UML?). It's just a fact that by nature humans trust personal experience far more than even statistically significant research.

Dean said "Nothing beats a Turing-complete, textual programming language for expressivity and productivity." That may be true if you have to pick one language to use for every single task for your whole life. But for any given problem space, it's simply not true. Expressivity is the ability to say everything you want, precisely and concisely - which is as good a definition of a Domain-Specific Modeling language as you're likely to get. The consistent measured increase in productivity by a factor of 5-10 with DSM is a proven fact. And when you've actually seen DSM in practice, as opposed to code generation with UML or IDE wizards, it's obvious why it is so much faster throughout.

Jean-Jacques complementa la valoración de UML:

With respect to UML, I think the problem the industry doesn't see is that the OO metamodel is all but arbitrary. The structure of a class has nothing absolute. As such is has become a hindrance as more and more complex solutions cannot be efficiently described/implemented with a one size fits all concept. Of course all the ingredients I think are there in OO (object, property, method), but it is how they are combined that is inflexible. The tragedy with UML is to think that (abstracted) OO concepts are the foundation of modeling. They built the whole thing on the wrong foundation (MOF). As a result, people are using UML as an M3 layer, because MOF (or Ecore) is simply impractical to use.

Mi impresión: Sigue siendo un hecho que MDD es un concepto en construcción y evolución. Tras años de acento en UML como herramienta básica de elaboración de modelos, la no obtención de resultados robustos ha llevado a un punto en que se exploran otras alternativas. Probablemente, esa robustez llegará, y las variantes actuales serán sólo una parte de las herramientas que sobrevivan. Lo que no sucederá, es que el desarrollo vuelva atrás a herramientas que no impliquen generación de código y un grado alto de abstracción.

Refinando la discusión sobre modelos

Dos interesantes discusiones en LinkedIn en los últimos meses, en el grupo Model Driven Architecture, demuestran largamente que este es un sitio mucho más amplio que uno dedicado a la búsqueda de trabajo. Aunque ha pasado ya algún tiempo, creo que todavía es válido resaltarlas.

La más antigua es una discusión que tiene hoy ocho meses en LinkedIn, pero sigue manteniendo todo el interés que en ese momento despertó en el grupo.
La discusión se inició con una pregunta retórica ("What is Platform Independent Model (PIM) & Platform Specific Model (PSM) in MDA?") , más en tono de venta de servicios que de interés en atender el problema. Sin embargo, la discusión derivó a una exposición de los puntos débiles del estándar MDA, a través de opiniones favorables pero concientes de la existencia de puntos débiles, y de otras contrarias o favorables a lenguajes y herramientas DSL. Una muestra de estrategias que ayuda a pulsar el estado de las distintas variantes de desarrollo basado en modelos.
La discusión más reciente tiene cinco meses, aún continúa, y derivó de una consulta acerca de la viabilidad de UML para el desarrollo de software (Do you think that code generated from UML diagrams is a good way to develop software? How useful do you think the code will be?). También generó un amplio intercambio de ideas sobre el mismo asunto, acompañado de la entrada en discusión de herramientas DSL complementarias o reemplazantes del uso de UML.
Invito a seguir los argumentos. La discusión está abierta...
Otra discusion de mucho interés: "Modelling Tools- Silver Bullets?"

Code Generation 2010 completado

La conferencia 2010 de Code Generation se ha completado, con un buen número de participaciones y soporte de empresas e instituciones. Una vez más, la conferencia expone las tendencias dominantes y el estado del trabajo en el desarrollo de software basado en modelado. Nuevamente, ha sido importante la presentación de herramientas DSL. Algunas de las presentaciones informalmente ya están disponibles, tales como las de Pedro Molina sobre modelado y generacion de código (excelente introducción), Johan den Haan acerca de la construcción de una factoría para desarrollo basado en modelos, y la de Eelco Visser, sobre Spoofax. Así como el año pasado estuvieron disponibles todas, espero que pronto todo su contenido esté disponible.

Un caso de uso de desarrollo basado en modelos

Fred Madiot publicó hace pocos días una breve reseña del paso a diseño basado por modelos en un caso práctico: un banco tunecino que decide reelaborar sus aplicaciones cambiando tecnología y método de construcción. Nada mejor que casos prácticos para que quienes se aproximan a conocer el desarrollo basado en modelos, tengan una idea del estilo y posibilidades de MDD.
Para mi experiencia y preferencias, de todas formas esperaría que cada caso (aquí, el proyecto del banco) requiriera menos elaboración (me refiero a que el modelado se centrara más en la aplicación, y no inicialmente en la herramienta de transformaciones), y que el código se derivara sin fase final manual, desde un generador bajo Eclipse:

From the EMF model of the reference application, the templates have regenerated 6 MXML files and 19 ActionScript files (Commands, Events, Service Delegates, Front Controller, and Value Objects). The MXML files contain the graphical definition of the GUI: they will be generated only once, just to provide a first application which can be executed. Then they will be edited and maintained with a WYSIWYG designer.

Este aspecto revela en mi criterio la todavía relativa inmadurez de las herramientas disponibles. Digo esto desde mi punto de vista, con una herramienta, Plex, que considero más consistente en este terreno, y a la vez menos flexible en el mismo aspecto que estoy observando.
En común: en la comunidad de Plex, la importancia de Eclipse como puente entre las reglas de Plex y el ancho mundo de los metamodelos para resolver lo que no esté contemplado.

Fred Madiot también participa del proyecto MoDisco, que intenta desarrollar herramientas capaces de extraer el modelo implícito en una aplicación antigua (Legacy Reverse Engineering), de lo que hemos hablado en alguna oportunidad.

Modelos y libertad de acción

Jean-Jacques Dubray escribió, el once de este mes, una "carta abierta a Steve Jobs", en la que, a propósito de la declaración de Apple de que cerrará la programación para el iPhone, recuerda su catastrófica experiencia con NeXTStep, el revolucionario sistema operativo que Jobs desarrolló en su transitoria etapa fuera de Apple. Dubray recuerda su decidido compromiso por el sistema operativo y sus herramientas, y cómo la absorción posterior de NeXT por Apple destruyó su inversión, y afectó a sus clientes:

I discovered NeXT and NeXTStep in 1990 at Penn State and it was love at first sight. I was inspired, from the very first second after years of programming in Turbo Pascal. It is hard to believe for most people that something like Xcode was available as early as 1989. I had built two solutions with NeXTStep: a Laboratory Information Management System (LIMS) and an Industrial Process Control System. It was not easy but the results were incredible.

NeXTStep was so productive that a very small team of 2 or 3 people could write software that was vastly superior to the one written by much larger teams (10-50). I still remember a professor from Stanford visiting us at Hughes Research Lab and looking at these two products (at the time I had also added a Natural Language Interface to the Process Control Software to log process data in the LIMS and define control rules), his jaw dropped on the floor.

Yet, around 1994, NeXT started to fail. You had already moved to create OpenStep (a port of their APIs to Sun -yet incompatible with NeXTStep) and all together in 1997, NeXTStep was packed in boxes and moved to Apple. It resurfaced nearly a decade later. You can easily imagine how these two "strategic" moves impacted my business and my customers. Yes, devastating doesn't really qualifies.

La enseñanza que sacó Dubray de su experiencia tiene dos aspectos: uno, respecto a la evolución de la industria del software, que no necesariamente coincide con los intereses del usuario de la tecnología:

Software vendors are always looking for new customers, they compete against each other and ultimately they have no commitment to their past customers. I actually don't know a single Platform Software Vendor which understands and focuses on helping their existing customers migrate to new versions of their platform. They simply don't care, older customers are just collateral damage.

Su segunda conclusión es que ya nunca encarará la construcción de software comprometido técnicamente con un proveedor, sino que se apoyará en el desarrollo basado en modelos:

I have learned my lesson, never, ever will I write code directly tied to a set of APIs.
(...) NeXT shaped my mind to build model-driven software. Somehow, I could never go back to just writing imperative code ever again. Around 2005, my understanding of MDE became a lot more formal with the emergence of DSL Tools and Eclipse Modeling Framework and later XText and Oslo.
Ever since I understood how deadly, and frankly stupid it was to tie your solutions to vendor APIs, I spent lots of time developing strategies to become technology and architecture independent.

Jean-Jacques expresa un punto de vista importante en el estado actual del mercado del software: en un universo de negocios cambiantes, donde la tecnología es infinitamente variada, y donde es difícil contruír soluciones estables porque el ciclo de vida de las aplicaciones es crecientemente corto, comprometerse con una solución basada en una tecnología es peligroso. Y orientarse hacia el desarrollo basado en modelos es preventivo: difícilmente un cambio de tecnología afectará la especificación del software. Existen distintas variantes de desarrollo basado en modelos; cualquiera de ellas ofrecerá mejores perspectivas que un diseño apegado a un lenguaje, o infraestructura, o plataforma específica. En el estado actual de la industria, cada variante de lenguaje o plataforma se acerca a ser un commodity, y es el desarrollo basado en modelos el que permite manipular esta diversidad.

Una discusión en LinkedIn sobre el alcance de MDD/MDA

Algunos días atrás se mencionó aquí una discusión en LinkedIn sobre MDD, que criticaba el valor del concepto. Algunos de los cuestionamientos no parecían estar adecuadamente orientados. Sin embargo, las respuestas generadas sí aportan elementos importantes sobre la relevancia del desarrollo basado en modelos, sea que se hable de modelos genéricos o modelos específicos de dominio. En términos generales, lo que sigue es lo más relevante de la conversación:

Cuestionamiento de la portabilidad de los modelos:

(...) until recently the only choices for these modelling languages were proprietary. So by using MDD not only were you choosing to use an obscure programming language with no published standard, you were locking yourself into the only proprietary tool that implemented it. These days its not so bad; there are open source MDD tools. But as far as I know there is no formal standard for the modelling language, which makes the portability of your model between tools effectively zero. This is ironic, given that portability is supposed to be one of the big advantages of MDD.

Este punto es particularmente observable, ya que MDD (y aún DSM) están lejos de ser cerrados, aún tratándose de lenguajes de modelado propietarios. Si sobre algo se ha trabajado en años recientes, es sobre interoperabilidad y metamodelos. Pensando en su visión enfocada en DSLs, Juha-Pekka Tolvanen contesta:

Based on my experience in hundreds of cases, MDD makes always sense when we can raise the level of abstraction with models above the code. In other words, the use of class diagram to represent a class with a rectangle symbol in order to generate a class in file makes very little sense! People who have tried this - usually with some UML tools - are obviously disappointed.
In order to raise the level of abstraction we usually need domain-specific concepts - often implemented into a language and supported by some tool. Luckily the metamodel-based tools that allow to define own languages are always ‘open’ in that respect that while they allow to define code generators (or have API, XML format etc for interchange) they always allow you to move your models to other similar tools too. So there is no locking as you described and there are even published bridges among metatools. IMHO: (and I work for a tool vendor) you should always choose a tool that allows you to move your data (models and metamodels) to other tools - if you don’t do that you have the lock problem you mentioned.

Cuestionamiento a la productividad:

First, to those who point to practical experience [...]: a "successful" project, at best, just means it it was delivered within the estimated budget and timescale (at worst it means a failure that was declared a success for political reasons). The real question is: does MDD deliver projects that cost less and take less time than any of the alternatives. I can have a successful project using assembler, provided I have the budget and time. So: do you have evidence comparing like-for-like that MDD costs less, and if so by how much?
I have only seen one study for MDD (which I can't locate right now) that found MDD development was 40% cheaper than conventional development. However that only compared two development teams, and so could easily have been due to random variation. Furthermore just using a higher level language can give even bigger savings. A study by Lutz Prechelt http://page.mi.fu-berlin.de/prechelt/Biblio//jccpprtTR.pdf gives a clear view of the range available both in developer ability and programming language. Ulf Wiger found that Erlang quadrupled productivity over C++, and the sparse evidence available suggests that Haskell is even more productive.

A este respecto, Juha-Pekka Tolvanen, con gran experiencia en lenguajes específicos de dominio, responde acudiendo a experiencias bien conocidas:

[Acerca de la observación sobre productividad] (“does MDD projects cost less and take less time”) is obviously difficult to answer in general since there are so many modeling languages and programming languages to compare. Ultimately it depends on how well the languages compared fit to the particular problem to be solved.
Since evaluating even two alternatives takes a lot of resources with a proper research method, companies usually don’t make detailed evaluation or at least do not publish them. Fortunately, some do. For example, Panasonic implemented the same system twice and reported 500% productivity improvement when comparing "MDD" to traditional manual coding in C (see http://www.dsmforum.org/events/DSM07/papers/safa.pdf). Polar arranged a laboratory study and a pilot project measuring at least 750% productivity (see http://www.dsmforum.org/events/DSM09/Papers/Karna.pdf). Similar significantly gains are reported by companies like Nokia, Lucent, EADS and Siemens which have defined their own domain-specific modeling languages along with code generators. You can check cases on using Domain-Specific Modeling from http://www.dsmforum.org/cases.html and if you want to see example languages on various domains, check http://www.metacase.com/cases/dsm_examples.html.
These above mentioned productivity figures are quite different than 40% mentioned. I would guess that they used a modeling language that only slightly raises the level of abstraction. Paul, can you find the reference for that case? We have been trying to collect reported cases over the years and this would be valuable addition.

Y Mark Dalgarno, basándose en las experiencias volcadas en las conferencias de Code Generation, responde:

The Code Generation conference has documented MDD success stories in the following domains:

Financial trading platforms
Administrative enterprise applications
Grid & Cloud applications
JEE enterprise applications
Control & Data acquistion systems
Simulation & Training systems
User interface generation
Mobile device applications
Insurance applications
Telecomms applications
Home automation systems
Business and organisational workflow applications
Technology platform migration
Security policy management
Legacy application modernization
Defence systems
Web applications
Hiding framework complexity, handling multiple frameworks
Middleware applications
Sensor Systems

This is by no means the limit of MDD potential.

HLLs (including the ones you list) only allow you to raise your abstraction level so far and it still seems that where MDD is applicable it can outperform HLL by an order of magnitude in terms of productivity depending on the problem domain.

(Se podría agregar a la contestación de Mark, que, más aún, sería indudablemente posible crear modelos que generasen código con los lenguajes de alto nivel sugeridos como "reemplazo" de los modeladores). Este punto particularmente muestra que el cuestionamiento parte de una base errónea.

Finalmente, dos aspectos defendidos por dos de los participantes merecen destacarse:
Rui Curado afirma:

MDD, with proper tool support, gives you additional benefits like traceability, automation, collective knowledge sharing.

Andrea Rocchini pone en el centro de la discusión lo mejor de MDD:

The real advantage of MDD is defining a problem/application with semantic rather than procedural flow.
A model contain all and only the relevant information about problem; it's totally decoupled from implementing technology.
A model can be transformed/interpreted with many tools and many patterns, now and in the future.
From a model we can produce many kind of entity: applications (for many platform), documentation, simulation processes, ...
A model could be designed by an expert of the domain problem rather than a programmer (an expert of IT technology ...)

A procedural flow in a programming language instead is a monolithic object; it's not much recyclable, is strongly technology dependant, conceptual design and implementation are mixed.
The necessary knowledge to have for developing a modern application is all-changing and every day growing.
All that is very frustrating.

Naturally the MDD approach is less free and result depend on quality of tool/interpreter.

Para quienes sean miembros de LinkedIn, la dirección de la discusión, aquí.

Johan den Haan acerca de las virtudes de desarrollo basado en modelos (MDD)

Quisiera destacar algo que ya otros hicieron antes, pero no en castellano: las quince razones que Johan den Haan destaca en defensa del desarrollo basado en modelos. Lo haré muy brevemente, remitiendo a su artículo en inglés, pero en pocos días hablaremos un poco más de la crítica a MDD que se desarrolló en LinkedIn, que es su visión inversa. Tan pronto haya tiempo...
Las quince razones de Johan, simplemente enumeradas:
1. MDD es más rápido
2. MDD ofrece un mejor costo (cost-effectiveness)
3. MDD conduce a una mayor calidad
4. MDD es menos propenso a errores
5. MDD conduce a validaciones más claras
6. MDD produce softwaqre menos afectado por cambios de personal
7. MDD potencia los expertos de un dominio
8. MDD permite a los programadores avanzados a enfocarse en los problemas más árduos
9. MDD tiende un puente entre el enfoque de negocios y el tecnológico
10. MDD permite que el software sea menos sensible a los cambios de requerimientos
11. MDD permite que el software sea menos sensible a los cambios de tecnología
12. MDD realmente fuerza el cumplimento de una arquitectura
13. MDD captura conocimiento del dominio
14. MDD produce documentación actualizada del modelo
15. MDD permite enfocarse en problemas de negocios en lugar de hacerlo en la tecnología

Adhiero cien por cien a ellas. Remito a su artículo para su explicación ampliada; y en unos días, volveremos y daremos una vuelta de tuerca a partir de las críticas comentadas.

Una atinada crítica a DSL

Hoy ha habido mucho que leer. Dos o tres de los artículos aparecidos trataré de comentarlos en sucesivas notas, y otros están apuntados en mis enlaces de Del.icio.us.
El primero es muy breve, pero sustancioso: Rui Curado, miembro de The Model Driven Software Network, presenta sus objeciones a los lenguajes específicos de dominio (DSLs). Son razones que también suscribo:
En primer lugar, Rui reconoce que su uso de DSLs es limitado. Por lo mismo, recurre a lo que otros dicen:

I really don’t have much experience with DSLs, so I won’t use my own arguments. I’ll let the community speak for myself. Here is a tiny sample of DSL criticism:

http://c2.com/cgi/wiki?DomainSpecificLanguage

… the Tower Of Babel effect that results from having so many languages that a person needs to be familiar with (if not master) in order to get common jobs done.
…
writing a good DSL that is robust and reusable beyond a limited context, is a lot of work. It requires persons with both domain expertise and language design expertise (not necessarily the same person) to pull off. A truly reusable DSL will require reasonable documentation, otherwise it won’t survive the departure of its designers.

http://www.theserverside.com/news/thread.tss?thread_id=42078

The other mistake some folks make is they think that with a DSL that “non-coders” can actually use the DSL.

But since a DSL is designed for automation of an underlying objet model, writing in a DSL is just like writing in any language — whether it’s DOS .BAT files or Java, and it takes a coding mindset and understanding of the underlying domain as represented by the computer in order to make effective use.

There was much more written on this thread. You can go to the original page to read more opinions.

Rui plantea sus objeciones a modo de interrogantes:

As general use of DSLs become mainstream, so become the complaints about their shortcomings. If we take so much time to master a general purpose language, should we invest a comparable amount of time in limited-use languages? How can we get support for a DSL, apart from its own creators? Where’s community support? What happens after the departure of the language’s creator? What’s BNF? Do I need it?

DSL critics say really useful DSLs are hard and expensive to create. DSL supporters answer that DSLs are not designed, they evolve. Well, won’t any of those “evolutionary steps” risk breaking the entire development based on that DSL, much like a broken app build? Will the evolution in the language be severe enough to trash what has been done so far? Can you imagine yourself developing a complex C++ software system while C++ itself was still being designed and developed?

Los lenguajes específicos de dominio son una excelente herramienta, y ciertamente pueden cubrir más adecuadamente dominios específicos, comparados a los modeladores de "propósito general", como suelen denominarlos los sostenedores de DSLs. Pero éste es su límite, precisamente. Un DSL está confinado a un dominio. Es muy útil para un propósito específico, pero no es adecuado para articular un sistema complejo. Una Babel de lenguajes no es la solución para manejar una gran aplicación, y eso deberían reconocerlo quienes promueven uno u otro esquema de DSLs. Inversamente, un modelador de propósito general, en el sabor que se prefiera, es capaz de manejar tal sistema, y probablemente pueda integrar dominios específicos con el auxilio de un DSL. A un DSL le falta horizonte, perspectiva, que es la dimensión que se espera de un MDD. En cierto sentido, la declinación de Oslo (y antes, de las "Software Factories") y la puesta del acento en los rasgos "DSLs" de sus herramientas, mantiene la visión de que el equipo de desarrollo de Microsoft no tiene todavía claro cómo obtener una visión global del proceso de desarrollo.
Sobre el resto de las observaciones, comparto las interrogaciones de Rui. Particularmente, a quiénes está destinada una herramienta creadora de lenguajes específicos de dominio: más allá de las sugerencias de que serían casi de uso generalizado, sólo un equipo robusto, capaz de asignar tiempo al desarrollo de una sintaxis, puede dedicarse a construír un lenguaje particular: una gran corporación con suficiente presupuesto, una empresa dedicada a una línea de productos específica. Por lo demás, valen todas las preguntas.
En cuanto a Rui, es autor de ABSE, una herramienta de modelado cuyo proyecto está en curso.

Criticas a UML

Steven Kelly, a comienzos de octubre, destacó un estudio de W.J. Dzidek, E. Arisholm y L.C. Briand, (publicado en IEEE Transactions on Software Engineering, Vol 34 No 3, de Mayo/Junio de 2008), acerca de la eventual productividad de UML en el mantenimiento de una aplicación. El objetivo del estudio era medir y comparar el rendimiento de UML generando código a partir de un modelo, versus un equipo programando en Java. Un segundo aspecto de mucha importancia era que este proyecto se desarrollara como mantenimiento, no como desarrollo desde inicio. Es decir, cada equipo debía modificar distintos aspectos de una aplicación existente y documentada, en lugar de desarrollar desde cero y sin condicionamientos.
El experimento no deja muy bien parado a UML, que da diferencias a favor no muy grandes, a condición de excluír los tiempos de actualización de los diagramas. El equipo programando en Java logra mantenerse bastante cerca de los tiempos del equipo que trabaja con UML.
Estos son los aspectos que destaca Steven, comprometido con Metaedit, una de las herramientas orientadas a Domain Specific Languages mas consolidadas en el mercado, que considera revalidada su afirmación sobre el uso de UML: "empirical research shows that using UML does not improve software development productivity".
Las observaciones de Steven sobre la validez del experimento son atinadas:

One bad thing about the article is that it tries to obfuscate this clear result by subtracting the time spent on updating the models: the whole times are there, but the abstract, intro and conclusions concentrate on the doctored numbers, trying to show that UML is no slower. Worse, the authors try to give the impression that the results without UML contained more errors -- although they clearly state that they measured the time to a correct submission. They claim a "54% increase in functional correctness", which sounded impressive. However, alarm bells started ringing when I saw the actual data even shows a 100% increase in correctness for one task. That would mean all the UML solutions were totally correct, and all the non-UML solutions were totally wrong, wouldn't it? But not in their world: what it actually meant was that out of 10 non-UML developers, all their submissions were correct apart from one mistake made by one developer in an early submission, but which he later corrected. Since none of the UML developers made a mistake in their initial submissions of that particular task, they calculated a 100% difference, and try to claim that as a 100% improvement in correctness -- ludicrous!

To calculate correctness they should really have had a number of things that had to be correct, e.g. 20 function points. Calculated like that, the value for 1 mistake would drop by a factor of 20, down from 100% to just 5% for that developer, and 0.5% over all non-UML developers. I'm pretty sure that calculated like that there would be no statistically significant difference left. Even if there was, times were measured until all mistakes were corrected, so all it would mean is that the non-UML developers were more likely to submit a code change for testing before it was completely correct. Quite possibly the extra 15% of time spent on updating the models gave the developer time to notice a mistake, perhaps when updating that part of the model, and so he went straight back to making a fix rather than first submitting his code for testing. In any case, to reach the same eventual level of quality took 15% longer with UML than without: if you have a quality standard to meet, using UML won't make you get there any more certainly, it will just slow you down.

Queda por ver cuánto influyó en el resultado la elección de la herramienta usada (Borland Together for Eclipse), y si otro modelador hubiera mejorado los números. Sin embargo resulta notable encontrar tanta proximidad entre uno y otro equipo. Sigue pareciendo que hacer pasar todo el desarrollo del modelo por los tipos de diagramas hoy existentes, es insuficiente. Esta es una discusión reiterada en The Model Driven Software Network, tanto en conversaciones anteriores (1, 2, 3), como en la misma que se abriera sobre este experimento.

Por mi parte, quisiera agregar a las observaciones de Steven una más:
El experimento se propone actuar sobre un modelo "en movimiento", para evitar crear un caso de condiciones ideales, en las que, arrancando de cero, se contruye una solución limpia. Sin embargo, al partir de un desarrollo prolijo, estandarizado, bien documentado, está creando un ambiente de laboratorio. Nunca la comparación entre un desarrollo basado en un modelo y un desarrollo basado en código directo (digamos 3GL) será así: en la medida que un desarrollo basado en modelos y otro equivalente basado en código evolucionen, la oscuridad del diseño crecerá, y probablemente lo hará en forma exponencial, siendo mayor el diferencial cuanto más tiempo y actores hayan pasado. Si trabajamos con un diseño de seis meses de antiguedad, las diferencias en opacidad serán no muy grandes; pero si la aplicación tiene dos, tres, cuatro años, y por ella han pasado dos o tres oleadas de desarrolladores, indudablemente será más productivo trabajar con un modelo que navegando y apostando porque el cambio que hagamos no estalle por otro lado.
En el estudio se omite que un trabajo basado en código fuente directo estará expuesto a distintos estilos de grupos o personas intervinientes, que puede tener callejones sin salida, parches, y aún fraudes o sabotajes. De ninguna manera, sobre una aplicación compleja, los tiempos de trabajar a través de un modelo podrán ser iguales a los tiempos que se tomarán haciéndolo sobre el código mismo. Y mucho menos si las personas acaban de ser contratadas para esa tarea, como pretende hacerlo el experimento.
Esto sin introducir alguna variable independiente, como por ejemplo, un cambio de versión en software de infraestructura o de framework que afecte a la aplicación.
Como siempre, debo aclarar que no uso UML en mi actividad diaria. Sin embargo, prefiero extender el alcance de las críticas al uso de herramientas de modelado en general. Soy conciente que Steven no se pronuncia a favor del código fuente, porque él lo ve desde el campo del desarrollo basado en modelos, pero compara UML contra DSLs. Este es otro asunto, que merece tiempo aparte. Pero creo que es necesario dejar bien claro que el concepto genérico de desarrollo basado en modelos es indudablemente superior al uso de código directo, y mayor cuanto más complejo sea el caso. De lo que se trata es de encontrar una fórmula para expresar de manera flexible y ágil la conducta dinámica de un modelo, algo que UML no parece resolver de manera satisfactoria todavía. ¿Existe solución? Sin duda que la habrá. En mi caso, por lo menos, una solución existe. Pero eso será también aparte.

Oslo: quitando ambiguedad a las expectativas

Duro papel se le ha reservado a Douglas Purdy: anunciar la defunción del proyecto Oslo, y hacerlo con entusiasmo. Considerando la fugacidad de Internet, y la variabilidad de la información ofrecida por Microsoft sobre sus productos, es hora de conservar una visión de lo que fué Oslo, antes de que su memoria sea rediseñada. He intentado buscar páginas específicas de Microsoft en The Internet Machine, pero parece que sus páginas son difíciles de archivar: ninguna de las buscadas tuvo resultados. Sin embargo, queda la Wikipedia: lo que sigue es lo esencial de la versión todavía no modificada del producto, al día 3 de octubre, fecha del último cambio:

History

Originally, in 2007, the "Oslo" name encompassed a much broader set of technologies including "updated messaging and workflow technologies in the next version of BizTalk Server and other products" such as the .NET Framework, Microsoft Visual Studio, and Microsoft System Center (specifically the Operations Manager and Configuration Manager).^[1]

By September 2008, however, Microsoft changed its plans to redesign BizTalk Server^[2] Other pieces of the original "Oslo" group were also broken off and given identities of their own; "Oslo" ceased to be a container for future versions of other products. Instead, it was identified as a set of software development and systems management tools:^[2] around "Oslo".

• A centralized repository for application workflows, message contracts (which describe an application's supported message formats and protocols), and other application components
• A modeling language to describe workflows, contracts, and other elements stored in the repository
• A visual editor and other development tools for the modeling language
• A process server to support deployment and execution of application components from the repository.

When "Oslo" was first presented to the public at the Microsoft Professional Developers Conference in October 2008, this list has been focused even further. The process server was split off as code name "Dublin" that would work with "Oslo", leaving "Oslo" itself composed of the first three components above that are presently described (and rearranged) as follows:^[3]

• A storage runtime (the code name "Oslo" repository, built on Microsoft SQL Server) that is highly optimized to provide your data schemas and instances with system-provided best SQL Server practices for scalability, availability, security, versioning, change tracking, and localization.
• A configurable visual tool (Microsoft code name "Quadrant") that enables you and your customers to interact with the data schemas and instances in exactly the way that is clearest to you and to them. That is, instead of having to look at data in terms of tables and rows, "Quadrant" allows every user to configure its views to naturally reveal the full richness of the higher-level relationships within that data.
• A language (Microsoft code name "M") with features that enable you to model (or describe) your data structures, data instances, and data environment (such as storage, security, and versioning) in an interoperable way. It also offers simple yet powerful services to create new languages or transformations that are even more specific to the critical needs of your domain. This allows .NET Framework runtimes and applications to execute more of the described intent of the developer or architect while removing much of the coding and recoding necessary to enable it.

Relationship to "Dynamic IT"

"Oslo" is also presently positioned as a set of modeling technologies for the .NET platform and part of the effort known as Dynamic IT. Bob Muglia, Senior Vice President for Microsoft's Server & Tools Business, has said this about Dynamic IT:^[4]

It costs customers too much to maintain their existing systems and it's not easy enough for them to build new solutions. [We're focused] on bringing together a cohesive solution set that enables customers to both reduce their ongoing maintenance costs while at the same time simplifying the cost of new application development so they can apply that directly to their business.
…
The secret of this is end-to-end thinking, from the beginning of the development cycle all the way through to the deployment and maintenance, and all the way throughout the entire application lifecycle.

One of the pillars of this initiative is an environment that is "model-driven" wherein every critical aspect of the application lifecycle from architecture, design, and development through to deployment, maintenance, and IT infrastructure in general, is described by metadata artifacts (called "models") that are shared by all the roles at each stage in the lifecycle. This differs from the typical approach in which, as Bob Kelly, General Manager of Microsoft's Infrastructure Server Marketing group put it,^[5]

[a customer's] IT department and their development environment are two different silos, and the resulting effect of that is that anytime you want to deploy an application or a service, the developer builds it, throws it over the wall to IT, they try to deploy it, it breaks a policy or breaks some configuration, they hand that feedback to the developer, and so on. A very costly [way of doing business].

By focusing on "models"—model-based infrastructure and model-based development—we believe it enables IT to capture their policies in models and also allows the developers to capture configuration (the health of that application) in a model, then you can deploy that in a test environment very easily and very quickly (especially using virtualization). Then having a toolset like System Center that can act on that model and ensure that the application or service stays within tolerance of that model. This reduces the total cost of ownership, makes it much faster to deploy new applications and new services which ultimately drive the business, and allows for a dynamic IT environment.

To be more specific, a problem today is that data that describes an application throughout its lifecycle ends up in multiple different stores. For example:

• Planning data such as requirements, service-level agreements, and so forth, generally live in documents created by products such as Microsoft Office.
• Development data such as architecture, source code, and test suites live within a system like Microsoft Visual Studio.
• ISV data such as rules, processes modes, etc. live within custom data stores.
• Operation data such as health, policies, service-level agreements, etc., live within a management environment like Microsoft System Center.

Between these, there is little or no data sharing between the tools and runtimes involved. One of the elements of "Oslo" is to concentrate this metadata into the central "Oslo" repository based on SQL Server, thereby making that repository really the hub of Dynamic IT.

Model-Driven Development

"Oslo," then, is that set of tools that make it easier to build more and more of any application purely out of data. That is, "Oslo" aims to have the entire application throughout its entire lifecycle completely described in data/metadata that it contained within a database. As described on "Oslo" Developer's Center:^[3]

Model-driven development in the context of "Oslo" indicates a development process that revolves around building applications primarily through metadata. This means moving more of the definition of an application out of the world of code and into the world of data, where the developer's original intent is increasingly transparent to both the platform (and other developers). As data, the application definition can be easily viewed and quickly edited in a variety of forms, and even queried, making all the design and implementation details that much more accessible. As discussed in this topic already, Microsoft technologies have been moving in this direction for many years; things like COM type libraries, .NET Framework metadata attributes, and XAML have all moved increasingly toward declaring one's intentions directly as data—in ways that make sense for your problem domain—and away from encoding them into a lower-level form, such as x86 or .NET intermediate language (IL) instructions. This is what the code name "Oslo" modeling technologies are all about.

The "models" in question aren't anything new: they simply define the structure of the data in a SQL server database. These are the structures with which the "Oslo" tools interact.

Characteristics of the "Oslo" Repository and Domains

From the "Oslo" Developer's Center: ^[3]

The "Oslo" Repository provides a robust, enterprise-ready storage location for the data models. It takes advantage of the best features of SQL Server 2008 to deliver on critical areas such as scalability, security, and performance. The "Oslo" repository's Base Domain Library (BDL) provides infrastructure and services, simplifying the task of creating and managing enterprise-scale databases. The repository provides the foundation for productively building models and model-driven applications with code name "Oslo" modeling technologies.

"Oslo" also includes additional pre-built "domains," which are pre-defined models and tools for working with particular kinds of data. At present, such domains are included for:^[6]

1. The Common Language Runtime (CLR), which supports extracting metadata from CLR assemblies and storing them in the "Oslo" repository in such a way that they can be explored and queried. A benefit to this domain is that it can maintain such information about the code assets of an entire enterprise, in contrast to tools such as the "Object Explorer" of Microsoft Visual Studio that only works with code assets on a single machine.
2. Unified Modeling Language (UML), which targets the Object Management Group's Unified Modeling Language™ (UML™) specification version 2.1.2
   . UML 2.1.2 models in the Object Management Group's XML Metadata Interchange (XMI) version 2.1
   file format can be imported into the code name "Oslo" repository with a loader tool included with "Oslo".

Note that while the "Oslo" repository is part of the toolset, models may be deployed into any arbitrary SQL Server database; the "Quadrant" tool is also capable of working with arbitrary SQL Server databases.

Characteristics of the "M" Modeling Language

According to the "Oslo" Developer's Center, the "M" language and its features are used to define "custom language, schema for data (data models), and data values." ^[3] The intention is to allow for very domain-specific expression of data and metadata values, thereby increasing efficiency and productivity. A key to "M" is that while it allows for making statements "about the structure, constraints, and relationships, but says nothing about how the data is stored or accessed, or about what specific values an instance might contain. By default, 'M' models are stored in the 'Oslo' repository, but you are free to modify the output to any storage or access format. If you are familiar with XML, the schema definition feature is like XSD." ^[3] The "M" language and its associated tools also simplify the creation of custom domain-specific languages (DSLs) by providing a generic infrastructure engine (parser, lexer, and compiler) that's configured with a specific "grammar". Developers have found many uses for such easy-to-define customer languages.^[7]

Recognizing the widespread interest in the ongoing development of the language, Microsoft shifted that development in March 2009 to a public group of individuals and organizations called the "M" Specification Community.

Characteristics of the "Quadrant" Model Editor

"Oslo's" model editor, known as "Quadrant," is intended to be a new kind of graphical tool for editing and exploring data in any SQL Server database. As described on the "Oslo" Developer's Center: ^[3]

A user can open multiple windows (called workpads) in "Quadrant". Each workpad can contain a connection to a different database, or a different view of the same database. Each workpad also includes a query box in which users can modify the data to a single record or a set of records that match the query criteria.

"Quadrant" features a different way of visualizing data: along with simple list views and table views, data can be displayed in a tree view, in a properties view, and in variable combinations of these four basic views. An essential part of this is the ability to dynamically switch, at any time, between the simplest and the most complex views of the data. As you explore data with these views, insights and connections between data sets previously unknown may become apparent. And that has benefits for those using the Microsoft "Oslo" modeling technologies to create new models. As part of the "Oslo" modeling technologies toolset, "Quadrant" enables "Oslo" developers to view new models with "Quadrant" viewers. The "Quadrant" data viewing experience enables designers of DSLs to quickly visualize the objects that language users will work with. In this way, "Quadrant" will give developers a quick vision of their models. With this feedback, "Quadrant" can also provide a reality check for the model designer, which may in turn lead to better data structures and models.

In the future, Microsoft intends for "Quadrant" to support greater degrees of domain-specific customization, allowing developers to exactly tailor the interaction with data for specific users and roles within an enterprise.

Si usted sigue el enlace de la Wikipedia (recuadro arriba a la derecha, "Code Name Oslo", dirección del website), encontrará que el proyecto Oslo ya no existe como unidad, sino que es conducido al Data Platform Developer Center. Ninguna referencia por allí, nada que nos comunique lo que Douglas Purdy anuncia en su blog, aunque puede ser pronto. Sin embargo, el link ya es redireccionado. Luego veremos...
Todavía hoy, 14 de noviembre, el enlace http://msdn.microsoft.com/en-us/library/cc709420.aspx remite al apartado sobre Oslo en MSDN Library, en su referencia a .NET. Indudablemente todo el contenido deberá sufrir reingeniería. Recorrer su contenido todavía no excesivamente transformado, da una idea de la magnitud de la renuncia, si luego retornamos a la parca redefinición de Purdy:

The components of the SQL Server Modeling CTP are:

• “M” is a highly productive, developer friendly, textual language for defining schemas, queries, values, functions and DSLs for SQL Server databases
• “Quadrant” is a customizable tool for interacting with large datasets stored in SQL Server databases
• “Repository” is a SQL Server role for the the secure sharing of models between applications and systems

We will announce the official names for these components as we land them, but the key thing is that all of these components are now part of SQL Server and will ship with a future release of that product.

No sólo las páginas de MSDN sobre Oslo, o Douglas, deberán ser "refactorizados". Desde junio de 2008, Steve Cook asumió tareas de integración de UML dentro de Visual Studio y paralelamente colaborando con el proyecto Oslo en la integración de UML ¿qué papel jugaba Oslo en este proyecto? ¿cuál será el papel de Steve ahora? Si recorremos las noticias publicadas a través del último año y medio, la impresión que queda es que dos vías de investigación paralelas coexistieron, y que una de ellas al menos ha pasado a vía muerta. Ahora tiene sentido lo que Stuart Kent comentara en noviembre de 2008:

The Oslo modeling platform was announced at Microsoft's PDC and we've been asked by a number of customers what the relationship is between DSL Tools and Oslo. So I thought it would be worth clearing the air on this. Keith Short from the Oslo team has just posted on this very same question. I haven’t much to add really, except to clarify a couple of things about DSL Tools and VSTS Team Architect.

As Keith pointed out, some commentators have suggested that DSL Tools is dead. This couldn’t be further from the truth. Keith himself points out that "both products have a lifecycle in front of them". In DSL Tools in Visual Studio 2010 I summarize the new features that we're shipping for DSL Tools in VS 2010, and we'll be providing more details in future posts. In short, the platform has expanded to support forms-based designers and interaction between models and designers. There's also the new suite of designers from Team Architect including a set of UML designers and technology specific DSLs coming in VS 2010. These have been built using DSL Tools. Cameron has blogged about this, and there are now some great videos describing the features, including some new technology for visualizing existing code and artifacts. See this entry from Steve for details.

The new features in DSL Tools support integration with the designers from team architect, for example with DSLs of your own, using the new modelbus, and we're exploring other ways in which you can enhance and customize those designers without having to taking the step of creating your own DSL. Our T4 text templating technology will also work with these designers for code generation and will allow access to models across the modelbus. You may also be interested in my post Long Time No Blog, UML and DSLs which talks more about the relationship between DSLs and UML.

Pero volviendo a quienes comprometieron sus opiniones en favor de Oslo, ¿cuál es su sensación ahora? Me refiero a opiniones vertidas como en el caso del artículo "Creating Modern Applications: Workflows, Services, and Models", de David Chapell. En un tiempo tan temprano como octubre de 2008, David adelantó las características del proyecto, vendiendo lo que aún era un lineamiento. Todavía después hemos visto como algunos de los elementos adelantados eran dejados aparte, y, siendo todavía un proyecto inmaduro, volvía a ser presentado como una realidad. Y así, hasta el crudo despertar del 10 de noviembre.
Entre otras conclusiones que pueden extraerse de este proyecto ahora aparentemente en proceso de entierro, dos tienen particular interés:

• No es un buen modelo de negocios el vender como realidades lo que aún son esbozos. El cliente (empresas usuarias finales, comunidad de desarrolladores, consultores independientes, investigadores) saldrá herido, por distintas razones: algunos por postergar decisiones en espera de un producto estrella, otros por comprometer su palabra en favor de algo descartado, y otros por perder tiempo en espera de una herramienta que no fue tomada en serio.
• Es problemático depositar el desarrollo de investigaciones de avanzada en los planes de mercado de una empresa.