Una evaluación integradora de MDA/SF

En septiembre de 2005, Vicente Pelechano y Javier Muñoz, de la Universidad Politécnica de Valencia, publicaron un trabajo que compara, evalúa, y trata de sacar elementos positivos e integradores, de las estrategias de diseño dirigido por modelos y las factorías de software. El trabajo fue presentado en el II Taller sobre Desarrollo de Software Dirigido por Modelos, MDA y Aplicaciones (DSDM), en Granada (España).
En resumen, lo principal de la comparación:

Las Factorías de Software proporcionan una mayor guía para llevar a cabo el desarrollo de software, ya que recomiendan explícitamente el uso de líneas de producto, frameworks de implementación, patrones de diseño, etc.; mientras que MDA se centra en diferenciar entre la descripción del sistema de manera independiente de plataforma y las posibles realizaciones de esa especificación. MDA no proporciona indicaciones sobre cómo se deben diseñar los sistemas, se limita a recomendar que la generación del código se realice a partir de modelos.
Las Factorías Software promueven el uso de Lenguajes de Dominio Especifíco, mientras que MDA promueve el uso de UML, que es de propósito general. Esta es una de las diferencias más importantes entre los dos enfoques y la que, sin duda, es más polémica. Las Factorías de Software recomiendan la creación de lenguajes (de modelado) que permitan a los desarrolladores utilizar las primitivas más adecuadas para cada tipo de sistema. La OMG defiende que debe usarse UML, utilizando sus capacidades de extensión (profiles), cuando sea necesario, para expresar conceptos que no pueden representarse de forma directa en UML.
MDA proporciona lenguajes para la gestión de los modelos (UML, CWM, MOF, QVT), mientras que las Factorías de Software se limitan a describir técnicas que pueden utilizarse para este fin. Por ejemplo, en [6, cap. 8] se describe la posibilidad de especificar la sintaxis abstracta de los lenguajes específicos de dominio utilizando BNF o metamodelos, para estos últimos utiliza una notación similar a la propuesta por MOF. Sin embargo en el apéndice B de [6] se critica MOF desaconsejando su uso sin proponer ninguna alternativa.
MDA promueve explícitamente elevar el nivel de abstracción a la hora de especificar los sistemas, las Factorías Software permiten la creación de DSLs que representen directamente elementos de plataformas de implementación. En varios ejemplos, por ejemplo algunas figuras de [6, cap. 7], se muestran modelos que utilizan primitivas como ASP.NET Service o Windows Application. Siguiendo la estrategia MDA, un sistema debe especificarse utilizando modelos independiente de plataforma (PIM) que, posteriormente, podrán ser transformados o anotados para convertirse en modelos específicos de una plataforma (PSM).

Ventajas de MDA:

Define de manera clara la tecnología que recomienda utilizar para aplicar su enfoque: UML, MOF, QVT, etc. Esto facilita la tarea de construcción de un método a los desarrolladores que quieren aplicar este enfoque. Podemos contar con lenguajes ampliamente conocidos que, en gran parte, no necesitan de descripción y disponen de abundante documentación.
Está más tiempo en el mercado, ya que fue presentado con anterioridad a las Factorías de Software. Debido a esto, MDA ha sido más estudiado, discutido y
aplicado. Este aspecto facilita la aceptación de un método por parte de la comunidad de la Ingeniería del Software.
Ofrece un mayor soporte de herramientas que están empezando a madurar. Esto ocurre debido a dos causas: (1) OMG está compuesto por muchas empresas que desean ofrecer productos que sigan las especificaciones de OMG, y tal y como se ha dicho en el punto anterior, (2) MDA es conocido desde hace más tiempo. Por ejemplo, Eclipse es un entorno de desarrollo extensible, libre y promovido principalmente por IBM. Este entorno tiene una amplia comunidad que desarrolla extensiones para proporcionar funcionalidad muy diversa. Entre estas extensiones destaca EMF, una extensión para el metamodelado basado en el estándar MOF de OMG capaz de almacenar los modelos en formato XMI 2. También existe una extensión que proporciona una implementación del metamodelo de UML utilizando EMF, disponiendo en estos casos de implementaciones libres de los estándares de OMG. Por otra parte, las Domain-Specific Language Tools que Microsoft propone para construir Factorías de Software todavía se encuentran en fase de desarrollo, por lo que no son muy robustas y no pueden aplicarse en entornos de producción industrial.

Ventajas de Software Factory:

Proporcionan una completa guía metodológica a los desarrolladores. Con las Factorías de Software se definen de forma más clara y precisa los pasos que deben llevarse a cabo para construir un método que siga esa aproximación. Esto ha quedado patente en la sección 4.2, donde se ha descrito cómo se deberían aplicar cada una de las estrategias para crear un método para el desarrollo de sistemas pervasivos. La cantidad de información para la construcción de métodos que proporciona el enfoque de las Factorías de Software es mayor que la proporcionada por MDA, ya que éste último no da ninguna pauta sobre cómo se deberían implementar los sistemas.
Integra muchas áreas de la Ingeniería del Software que ya han sido investigadas y puestas en práctica (líneas de productos, patrones de diseño, construcción de frameworks, etc.). De este modo, este enfoque no parte desde cero, sino que integra el conocimiento de estos temas.
El principal promotor es Microsoft, por lo que su posición dominante en el mercado puede conseguir que el enfoque de las Factorías de Software acabe implantándose en la industria. Pese a ello, se debe tener en cuenta que OMG también auna un número importante de multinacionales del desarrollo de software, por lo que esta ventaja puede ser relativa.

MDA + Factorías de Software?
Cada uno de los enfoques discutidos hace énfasis en ciertos aspectos del proceso de desarrollo de software. Esto les confiere ciertas ventajas respecto al otro en aspectos específicos y claramente diferenciados. Una cuestión que surge rápidamente es ¿sería posible integrar los dos enfoques? Para ello deberíamos seguir las recomendaciones de ambos e integrar de algún modo líneas de productos, modelos de alto nivel de abstracción, frameworks de implementación, lenguajes de dominio especifico, los lenguajes de OMG, etc.
Seguir este enfoque integrador tiene una serie de ventajas:
1. La estrategia general del método está definida: línea de producto + framework de implementación + lenguaje de dominio específico.
2. Las técnicas a utilizar están definidas:
MOF + QVT.
3. Existen herramientas de soporte: EMF de Eclipse o MDR de NetBeans, por ejemplo.
4. Se pueden aplicar técnicas conocidas propuestas por las factorías de software, como los "feature models"para la construcción de la línea de producto o los patrones de diseño para el desarrollo de framework de implementación.

Por lo tanto, para desarrollar una método que integre MDA y Factorías de software habría que:
• Hacer uso de la estrategia metodológica que proponen las Factorías de Software; es decir, seguir un enfoque basado en:
1. el desarrollo de una línea de producto,
2. la construcción de un framework de implementación para los sistemas
que serán desarrollados siguiendo la línea de producto, y
3. la definición de un lenguaje de dominio especifíco (DSL) que permita capturar los requisitos específicos de cada uno de los sistemas utilizando las primitivas conceptuales más adecuadas para ese tipo de sistemas.
Construir el DSL de manera que:
1. proporcione primitivas conceptuales independientes de plataforma.
2. se especifique siguiendo las técnicas que propone OMG (creación de un
profile UML o definición de un metamodelo con MOF).

Cuando Software Factory no es una marca comercial

En algún momento, en otro sitio, se ha discutido sobre Software Factories, discriminando los dos conceptos involucrados en este nombre, devenido marca en manos de Jack Greenfield y otros. Pero la primera definición de SF fue la de la construcción de software siguiendo procedimientos "industriales". Repitiendo la definición comentada en otro lugar:

la Fábrica de Software refiere el sentido de producir con rapidez y calidad a través de procesos conocidos, repetibles y gerenciables, y principalmente, mejorables continuamente, no sólo por la incorporación de técnicas y herramientas en el desarrollo del software, sino porque se mantiene constantemente el foco sobre el mejoramiento del proceso de producción y cada uno de los pasos que esto acarrea. Aaen, Bøttcher y Mathiassen indican que el "término fábrica indica un compromiso a largo plazo, esfuerzos integrados - por encima de proyectos individuales- para mejorar las operaciones relativas al software".
Entre los significados de la fábrica de software, mencionan Aaen, Bøttcher y Mathiassen, "mejorar la efectividad del proceso, reducir la cantidad de retrabajo y reusar el ciclo de vida de los productos". De forma tal que se puedan obtener mejores resultados en menor tiempo y con menos costos, pero agregan que además sea una industria en la cual las actividades del desarrollo de software sean "predecibles lo que significa que los costos estimados y compromisos de cronograma pueden ser satisfechos, confiables lo que significa que la capacidad del proceso es conocida, mejora continua significa que la atención constantemente se concentra en mejorar el proceso y que el conocimiento y las habilidades para mejorar están establecidas. Todo esto debería ser logrado a través de la atención al proceso (mejoramiento) y no a los métodos o herramientas", lo que supone la utilización de métricas y técnicas aplicadas al proceso del software y apuntaría a la satisfacción de las dimensiones de la calidad enunciadas por Falconi Campos.(calidad intrínseca, entrega del producto, costo, motivacion de sus productores, seguridad). Falconi Campos, Vicente. TQC: Control de la Calidad Total (al estilo japonés). Bloch Editores S.A., Rio de Janeiro, 1994.)

Así, la utilización de métodos repetibles, mejorables, seguros y confiables, están entre los objetivos básicos de la construcción de software "industrial". El concepto de desarrollo basado en modelos de OMG (y otros) procura justamente la construcción de software confiable, no dependiente de la pericia de cada desarrollador integrante del proyecto, y que sea capaz de ser sostenible en el tiempo. A pesar de lo que Greenfield y otros sostenedores de la versión MS de Software Factories afirman, MDA (y otros proyectos relacionados) son excelentes conductores de estas ideas. Thales Research & Technologies de Francia muestra que es posible encarar un proceso SF basado en conceptos MDA. Participante activo en OMG, sostiene varios proyectos conducentes al desarrollo de aplicaciones basados en modelos convertidos luego en código, y uno de estos proyectos en curso trata de sostener una Fábrica de Software por medio de un constructor MDA. Un papel expuesto por Benoît Langlois y Daniel Exertier en OOPSLA 2004 detalla el proyecto a esa fecha. Su análisis puede servir para estudiar cómo usar el desarrollo basado en modelos para la construcción de sofware a gran escala:

A major issue in software engineering is software production improvement. This paper studies the objectives and the features of a model-driven software factory contributing to automate the production of software systems in evolving environments (specifications, standards, technology, and tools). Through these considerations, this paper introduces MDSoFa, a Model-Driven SOftware FActory tool developed at THALES meeting this need, and a set of technical and methodological lessons learned from this tool implementation and usage.(...)

In this paper, we analyze the combination of two approaches, model-driven engineering and software factory, to rationalize software production. The main interest of model-driven engineering is that model is the primary type for developing systems, e.g. from requirements down to code, and this in different perspectives, as domain, technical, or process. The main interest of software factory is software production automation, for going from a handcrafted to an industrialized software production and for allowing development time reduction and software quality improvement. In this vision, a model-driven software factory is a software factory where models are central with the main objective to ease and industrialize software production.(...)

A clear and predictive method of work needs standard domain, technical or process assets. Standardization can be international, enterprise, or project wide. Besides, a rationalized process implies not only rationalized activities but also engineering tools adapted to the defined engineering processes. The common denominator is to develop a systematic method of work, the way for automation. The interest is to create a synergy between standards, processes and tools, raising together the software production maturity level.(...)

A model-driven software factory is a combination of metamodels, expertise, tools and frameworks for producing output assets in an industrial way, that can be also metamodels, expertise, tools and frameworks, i.e. recursively, a model driven software factory can produce a model-driven factory. Depending on the focus of the produced assets, a software factory has the following functions:

• Model factory. In this case, models are produced automatically from models. For instance, a model transformation can be deduced from the application of a model transformation pattern on a domain metamodel.

• Expertise factory. In this case, the software factory produces specific or generic expertise from specific or generic expertise. For instance, model checks and wizards can be produced from a methodological metamodel and a generic expertise for model checking and assistance.

• Tool factory. In this case, the software factory produces tools or executable environments in a tool, as a tool-specific modeling chain.

• Framework factory. In this case, the produced asset is a framework.

• Software factory factory. As mentioned above, this specific case covers the reflective approach when all types of asset are involved in input and output of the software factory for producing a software factory.(...)

We focus now our interest on software factories producing modeling software factories, involving cooperation of heterogeneous domains and pieces of expertise, with development qualities to be respected. In the model-driven perspective, a software factory production can be seen as a mapping execution: the modeling environment is modeled at the metamodel level and the result of the software factory is the modeling environment that will be used by modeling users. (...)This software factory mapping is comparable to an abstract to concrete syntax mapping, or, in MDA terms, to a PIM (Platform Independent Model) to PSM (Platform Specific Model) mapping. A further step consists in instantiating the same software factory for different modeling tool platforms, each having its own specificities (tool-vendor UML metamodel, language, packaging, deployment protocol…) where target platform becomes a parameter to be considered during the software production. This is key for large companies where methodologies and practices are similar with different modeling tools.

Este es un proyecto en curso. No necesariamente es la única solución, pero sin duda sugiere mejores vías de construcción del software.

Más sobre MDA vs SF

Continuando una discusión abierta hace algún tiempo en The Server Side, Jack Vaughan expone sobre Software Factories brevemente, sólo para recordar que parecería que el principal objetivo de hablar sobre SF es desacreditar la iniciativa Model Driven Architecture. Sin embargo, en el marco de usuarios esperanzados en Visual Studio 2005 Team System, un puñado de observaciones críticas apuntan a la inconsistencia de este concepto en su desarrollo actual: en primer lugar, simplemente el remate del comentario de Vaughan.

Not discussed here, of course, is the idea that a key goal behind MDA is to create models that are high-level enough to be platform independent. Frankly, and for obvious reasons, this is not too often a driver in the MS camp

...es decir, evidentemente un punto fundamental en la discusión es la posibilidad de modelar con independencia de la plataforma, bajando el diseño a código, sea en Windows, Linux, Unix o AS400.
Pero es en la pequeña lista de respuestas, casi todas ellas desde el propio campo, donde se puede sacar más sustancia:
Dice Tad Anderson:

My frustration is with today, and the tools we are being handed today. With VSTS 2005 I lose XDE, I gain a DSL roundtrip class diagram modeling tool, and a bunch of Data Center modeling tools. So now I am stuck with the choice between Sparx, Borland, and some other tools to be able to do my job today. I don't have time to write a DSL UML tool so I can architect this project, and I wouldn't even if I had the time.

My frustration is not with your Software Factory movement, my frustration is with the gap that has been put in place by MS making us wait for your Software Factories movement to produce the tools and process frameworks we need to do our job. So I am not against your movement of Software Factories, I am against Microsoft's position of promoting it as what will be available, while providing nothing to us today

Otras intervenciones incluyen una defensa de SF de Aidas Ozelis, respondida detalladamente por Jon Kern, de OptimalJ.