Framework aplicativo y MDA. Detonadores de calidad y productividad.

El ambiente de negocio de empresas exitosas es por definición dinámico y cambiante. Para mantener su ventaja competitiva, una compañía tiene que responder al cambio rápida y adecuadamente. Así, la capacidad de desarrollar sistemas de información cumpliendo los requerimientos del negocio, con la calidad requerida, en el tiempo que permita al negocio lograr sus objetivos, y a un costo competitivo, está directamente ligado con el éxito de la compañía.

En este artículo vamos a presentar el esquema de “Industrialización” de la fábrica de software de IIDEA Solutions basado en tres conceptos que identificamos como claves para la operación interna de la misma: los conceptos de frameworks aplicativos, EOM (Enterprise Object Model) y MDA (Model Driven Architecture).

¿Qué es un Framework Aplicativo?
Un framework aplicativo es una “aplicación semi-terminada” que está montada sobre una tecnología base como .NET o J2EE. Contiene una capa general que provee servicios comunes para todo tipo de aplicaciones tales como seguridad, acceso a datos, manejo de errores, etc., y una capa que provee servicios específicos para un cierto dominio de negocio. Este tipo de frameworks son diseñados por arquitectos experimentados; donde queda plasmado mucho de su conocimiento adquirido a través de los años y que está empaquetado y listo para ser reutilizado.

Los frameworks aplicativos son creados para ser la estructura base en la cual se montan varias aplicaciones de negocio, las cuales compartirán requerimientos similares de infraestructura, mientras otros requerimientos de negocio serán totalmente diferentes. Esta característica hace al desarrollo de un framework aplicativo particular y complejo, por lo que al momento de diseñar, se debe estar consciente de que su estructura de clases sea muy flexible en puntos donde se detecte que pueda haber requerimientos muy variables. Esto se logra siguiendo el principio “open-close” de la programación orientada a objetos (una clase debe soportar extensibilidad o modificación de su comportamiento sin la necesidad de modificar su código, la clase debe estar cerrada para su modificación de código fuente) utilizando patrones de diseño que nos apoyan en establecer “hooks” o ganchos dentro la estructura de una clase para colgar nuevos comportamientos a esta. También se debe tener la previsión para saber cuáles son los requerimientos más comunes en las aplicaciones de cierto nicho y así proveer estos mecanismos.

Un error muy común en la interpretación del concepto del framework aplicativo es confundirlo con una librería de clases o API; el framework va más allá. La diferencia primordial es que un framework controla el ciclo de vida de los componentes montados sobre éste y contiene lógica de orquestación de ciertos flujos.

Figura 1. Librerías vs Framework

En la figura de la izquierda, la aplicación usa los componentes que provee una librería y nada más. En la figura de la derecha la aplicación usa componentes que provee el framework y además éste controla el ciclo de vida de los objetos (IoC) y los flujos dentro de ciertos procesos para orquestar los componentes que fueron montados sobre éste.

Para explicar cómo está conformado un framework aplicativo en la figura tenemos una disección en capas. Existen frameworks genéricos como .NET o Java los cuales fueron hechos para uso genérico y tienen mil y una formas de realizar una misma funcionalidad. Sobre éste están los frameworks aplicativos, que son la realización de una arquitectura de software específica (componentes de software) para un cierto tipo de aplicaciones. Si hacemos un zoom de un framework aplicativo, podemos ver que existen 2 capas importantes, una dedicada a ofrecer funcionalidades comunes orientadas a servicios de infraestructura, y otra que se refiere a servicios específicos para un tipo de negocio en particular; lo cual da como resultado la capa que se llama “Domain Specific Language” (DSL). Entre más especializado sea un framework, su valor se incrementa debido a que se ve afectada positivamente la productividad del desarrollo de software y como veremos más adelante se puede generar mayor porcentaje de código automáticamente usando una herramienta de MDA.

Figura 2. Disección en capas

Enterprise Object Model
Para desarrollar la capa de DSL se debe realizar previamente un proyecto de EOM (Enterprise Object Model). El concepto de EOM está basado en la idea de crear un modelo de dominio representando los objetos de negocio para toda una organización empresarial. Para obtener este modelo se requiere realizar un análisis de procesos de la organización e identificar los objetos de negocio, así como su objetivo, propiedades, responsabilidades y variaciones que pueden tener dentro de los diferentes procesos o contextos de negocio en que son usados. Después se deben encontrar agrupaciones funcionales de objetos y englobarlos en subsistemas funcionales. En base a este modelo se pueden identificar, diseñar y construir subsistemas funcionales parametrizables según los hallazgos de variabilidad de los objetos encontrados por el EOM. Estos componentes funcionales parametrizables de negocio se integran al framework aplicativo formando la capa de DSL.

MDA
MDA son las siglas de “Model Driven Architecture”, un concepto promovido por la OMG, que propone basar el desarrollo de software en modelos de análisis y/o diseño especificados en UML, y que a partir de estos se realicen transformaciones que generen código fuente u otro modelo con características específicas para una tecnología.

Este concepto permite dos tipos de modelos de UML: Modelo PIM (independiente a la tecnología) y Modelo PSM (específico a una tecnología). Esto sucede debido a que MDA intenta separar en el desarrollo de software las preocupaciones de requerimientos del negocio y las preocupaciones tecnológicas. La ventaja que nos da este desacoplamiento es que ambos aspectos pueden evolucionar en su propio tiempo y espacio sin estar atados entre sí; la lógica de negocio responde a las necesidades del negocio —y no a las restricciones tecnológicas—, y los aspectos tecnológicos pueden tomar ventaja de los nuevos desarrollos tecnológicos.

La propuesta se basa en tener un modelo de UML que contenga el comportamiento y lógica del negocio de una aplicación neutral a la tecnología (PIM), esto quiere decir que el modelo PIM no es consciente de lenguajes de programación, restricciones tecnológicas, estilos arquitectónicos o protocolos. Ahora mediante transformaciones (punto clave del concepto MDA) del modelo PIM se generarán modelos para plataformas tecnológicas especificas (PSM ) como .NET o J2EE. Para llevar a la práctica el concepto de MDA necesitamos lo siguiente:

1) Una arquitectura de software que define los componentes claves del sistema y sus responsabilidades, la organización de los componentes del sistema y cómo se intercomunican entre sí. Esta puede estar definida en dos niveles, una arquitectura de software base que define los componentes claves y la organización de los componentes sin tener detalles de implementación; y como segundo nivel una arquitectura de software que se basa en la definición de la arquitectura base mas los detalles de implementación referentes a una plataforma o tecnología.

2) Documentar los mecanismos de diseño que son la especificación de las reglas de mapeo y transformación entre un modelo PIM y un modelo PSM.

3) Definir un perfil de UML (UML Profile) el cual es la definición de “estereotipos” y “tagged values” que es el mapeo de los tipos de componentes y roles que se definen en la arquitectura de software y los cuales serán usados para “marcar” el modelo PIM. (Cuando se tiene un Framework Aplicativo con DSL éste agrega más definiciones al perfil).

4) El Transformador es el componente que implementa las reglas de mapeo y transformación definidas en las mecánicas de diseño. En caso de existir un framework aplicativo, el Transformador será consciente de éste y generará código para ser montado sobre el framework.

Existe un quinto componente que es opcional (éste es el sello diferencial de un MDA), el cual es tener un Framework Aplicativo sobre el cual se basará el componente Transformador para la generación de código fuente y así lograr generar una mayor cantidad de código automáticamente por medio del DSL.

Ya teniendo estos componentes, el flujo del proceso sería realizar un modelo de UML PIM que especifique la lógica del negocio de manera precisa y de manera agnóstica a la tecnología de una aplicación, luego este modelo PIM se “marca” con el Perfil de UML que se tiene y que fue definido por la arquitectura de software, en este momento del proceso es cuando se le agrega al modelo el conocimiento de la arquitectura de software de manera conceptual. Después este modelo PIM “marcado” sirve como entrada para el Transformador que en base a las “marcas” que se agregaron al modelo PIM determina la transformación a realizar y genera el modelo PSM, que puede ser el código fuente de la aplicación u otro modelo UML (no necesariamente tiene que ser un modelo UML ).

Es fácil darse cuenta que el modelo PIM que sirve como entrada al proceso es el artefacto más preciado ya que detalla de manera precisa la lógica y comportamiento del negocio y el cual puede ser transformado a diferentes plataformas tecnológicas (ver figura anterior).

“El concepto de MDA es otro pequeño paso en el largo camino de transformar el actual proceso de desarrollo de software artesanal a un proceso de software que sea una disciplina de ingeniería”.

Figura 3. Flujo para aplicar MDA

Logrando los Objetivos de una Fábrica de Software
La Productividad y Calidad de Software son los objetivos primarios en una Fábrica de Software y como detonadores de estos atributos está el uso de un framework aplicativo y una herramienta de MDA.

Las características que impactan directamente a la calidad del software y que se obtienen por usar un framework aplicativo son:

Modularidad. Esta característica se refiere a la composición de una aplicación en componentes o módulos desacoplados. Como las aplicaciones están montadas sobre el framework que promueve la división de la aplicación en componentes desacoplados mejorando la modularidad de las aplicaciones y por consecuencia se incrementa la velocidad en el desarrollo en cambios de funcionalidad o extensión.

Reusabilidad. Lo más valioso de un framework aplicativo es la reutilización de la experiencia de la gente que diseñó el framework y tuvo el cuidado de tener en cuenta aspectos arquitectónicos fundamentales de una aplicación y lo cual se está reutilizando en cada aplicación que lo esté usando. En segundo término la reutilización de funcionalidad común que se encuentra encapsulada en componentes del framework.

Estandarización. El framework aplicativo forza al desarrollador a programar en un modelo determinístico lo cual estandariza la manera de desarrollar aplicaciones.

Extensibilidad. Extensibilidad es la habilidad para agregar nuevas funcionalidades a una aplicación existente. Este criterio de servicio es fundamental en un framework aplicativo debido a que éste debe ser flexible para poder cubrir las diferentes variaciones de funcionalidad que existirán en las aplicaciones que serán montadas sobre este y por ende las aplicaciones de negocio montadas sobre éste también heredarán esta característica casi “out of box”.

Simplicidad. Esta característica se refiere a que el framework aplicativo oculta muchos detalles para el programador referente a complejidad técnica y parte de la orquestación de procesos que se realizan entre componentes del framework por lo que la productividad del programador se ve incrementada.

Facilidad de Mantenimiento. Esta característica se refiere a la habilidad de realizar un cambio de una funcionalidad existente en una aplicación de manera rápida y eficiente sin afectar otra funcionalidad existente. Esta característica es uno de los criterios de servicio más complejos por cubrir y se requieren muchos años de experiencia para lograr un nivel aceptable en las aplicaciones de este criterio de servicio; el framework promueve la arquitectura en capas, composición de una aplicación en componentes desacoplados y parametrizables, manejo de errores y rastreo de errores, lo cual es un punch directo en la facilidad de mantenimiento de la aplicación. Cuando se tiene un conjunto de aplicaciones empresariales con una misma organización de componentes debido a que se montaron sobre un framework aplicativo, está comprobado por la industria de software que esto incrementa la productividad en el mantenimiento de las aplicaciones. Como siguiente paso natural de maduración en el proceso de “industrialización” está la herramienta de MDA que genera automáticamente un porcentaje de código fuente de una aplicación por lo que impacta drásticamente la productividad del desarrollo de software.

Caso Real
En la fábrica de software de IIDEA Solutions empezamos a trabajar en la visión de la “industrialización” del desarrollo de software en el año 2003.

Los primeros dos años nos dedicamos a formar una organización estable y acumular conocimiento en las plataformas estratégicas .NET y J2EE desarrollando varios proyectos para un cliente principal. Sobre todo para la parte de .NET estuvimos en una fase exploratoria durante estos años. Al principio de 2005 estuvimos en la posición de poder integrar el conocimiento tecnológico a un framework aplicativo que se estaba desarrollando durante la primer mitad del 2005. En la segunda mitad tuvimos oportunidad de usar el framework en varios proyectos dentro de la fábrica de software para optimizarlo y madurarlo lo suficiente para usarlo como base para la generación de código bajo el esquema MDA.

Todas las aplicaciones que actualmente se están desarrollando están basadas en este framework. Además estamos trabajando con nuestro cliente principal en el desarrollo de un EOM y servicios reutilizables para enriquecer al framework en la parte del DSL. En el área de MDA empezamos a finales del 2005 a desarrollar un generador de código basado en el kernel de AndroMDA que está disponible sin costo bajo licenciamiento GNU. Actualmente se está usando en un proyecto piloto para cuantificar el potencial de aumentar la productividad en el desarrollo sin disminuir la calidad.