Los sistemas de TI no se desarrollan en aislamiento. Su propósito es facilitar las operaciones de un negocio, lo cual implica que las necesidades del ambiente de negocio determinan la manera como se desarrollan los sistemas de TI que lo soportan. La siguiente lista describe los principales motivadores del ambiente actual:
•Así como se espera que los negocios sean más flexibles y adaptables, de la misma manera ocurre para los sistemas de TI.
•Los días de invertir en TI simplemente porque sí, son cosa del pasado. Los departamentos de TI ahora operan bajo fuertes restricciones de presupuesto y se espera que demuestren un claro valor al negocio.
•Los sistemas de software continúan creciendo en escala y complejidad para satisfacer las necesidades del negocio. Las técnicas que funcionan bien para desarrollos de pequeña escala, no necesariamente escalan para iniciativas de nivel empresarial.
•La sofisticación de las plataformas de TI actuales requieren de gente altamente especializada, y las organizaciones sufren para encontrarlos. Además, los proyectos con frecuencia dependen de personas clave y sufren significativamente cuando éstos dejan la compañía.
•Existe una gran variedad de plataformas de Middleware, y el ritmo con el que evolucionan no parece detenerse. Las organizaciones quieren aprovechar los avances en Middleware, pero no quieren reescribir constantemente sus aplicaciones.
Entendiendo la estrategia dirigida por modelos
MDD es un estilo de desarrollo donde los principales artefactos de software son modelos, a partir de los cuales se puede generar código y otros artefactos. Un modelo es una descripción de un sistema desde una perspectiva particular, omitiendo detalles irrelevantes, así las características de interés se vuelven más evidentes. Por ejemplo, un ingeniero civil crea un modelo de un edificio que le sirve para determinar las posiciones de las cargas.
En MDD se introduce el criterio adicional de que un modelo debe ser interpretado por una máquina. Por ejemplo: debemos ser capaces de acceder al contenido del modelo de manera automática. Esta capacidad de interpretación de los modelos es un prerrequisito para ser capaces de generar artefactos. Un diagrama en un pizarrón podría reunir otros criterios para ser considerado un modelo, pero mientras no pueda ser interpretado por una máquina, no podrá ser usado dentro de una cadena de MDD.
Los modelos de software se expresan típicamente en el lenguaje UML, que como sabemos, es un lenguaje para especificar, visualizar y documentar sistemas de software. Provee una notación visual y una semántica subyacente para modelos de software. UML también tiene un formato de serialización estándar, legible para una computadora, que le permite su automatización.
Los modelos de software esconden detalles de implantación técnica, para que un sistema pueda diseñarse utilizando conceptos de un dominio de aplicación. El diseño de la aplicación, típicamente se lleva acabo utilizando una herramienta de modelado de UML (como por ejemplo IBM Rational Software Architect), para modelar conceptos relevantes al dominio de la aplicación. Por ejemplo: cuando se trabaja en un dominio de integración empresarial, arrancaríamos modelando el diseño de la aplicación utilizando conceptos tales como mensaje, proxy y adaptador. Posteriormente se puede refinar el modelo de software y diseñar los detalles de sus componentes.
Los modelos como borradores y planos
La utilización de modelos para diseñar software, ya es una práctica bien establecida. Sin embargo, en la mayoría de los casos los modelos se utilizan sólo como borradores que comunican de manera informal algún aspecto del sistema, o como planos arquitectónicos que describen un diseño que posteriormente se implementa a mano. Esta práctica de utilizar modelos como documentación y especificación es valiosa, pero requiere una disciplina estricta para mantenerlos actualizados conforme la aplicación progresa y cambia con el tiempo. Conforme avanza un proyecto y hay cambios y presiones por los tiempos de entrega, es muy común que se actualice la implementación (código), sin actualizar los modelos. Ciertamente, un modelo impreciso puede ser incluso más peligroso que la ausencia de uno.
Los modelos como habilitadores de la
automatización
En MDD, los modelos no son solamente borradores, diagramas o planos, sino artefactos primarios, de los cuales se genera automáticamente una implementación. En MDD, los modelos orientados al dominio de la aplicación son el foco principal cuando se desarrollan nuevos componentes de software. El código y otros artefactos se generan utilizando transformaciones diseñadas con entradas provistas tanto por expertos en modelado, como por expertos del dominio.
No sólo código
La generación de código y otros artefactos de la plataforma son parte importante de MDD, pero la automatización mediante MDD puede ir mucho más allá. Un proyecto de desarrollo de software necesita producir muchos artefactos, además del código, algunos de los cuales, pueden ser completa o parcialmente derivados a partir de los modelos. La siguiente lista muestra algunos de ellos, sin embargo, pueden existir más, tales como documentación, artefactos de pruebas, scripts de construcción y liberación, otros modelos y uso de patrones.
¿Cómo desarrollar un proyecto con MDD?
MDD tiene un gran impacto en la forma en la que desarrollamos software. Captura las decisiones de la gente técnica más apta, haciéndolas disponibles al resto del equipo mediante las herramientas personalizadas para las necesidades del proyecto. Esto genera ahorros significativos en el costo del desarrollo y pruebas del software, ya que gran parte de la codificación de bajo nivel se automatiza. Adicionalmente, el número de errores se reduce, y se incrementa la consistencia en la forma como se realiza el trabajo.
No obstante, con MDD también cambia la manera en que se lleva a cabo el proyecto, dado que se deben llevar a cabo dos proyectos, uno dentro de otro: el proyecto externo que consiste en desarrollar la aplicación de negocio; y otro interno que consiste en desarrollar el ambiente y herramientas MDD que sustentarán el desarrollo del proyecto externo. Típicamente, una aplicación de negocio será identificada como el primer proyecto a ser construido con el ambiente MDD, y después, este ambiente y herramientas, se pueden aprovechar para construir otras aplicaciones de negocio.
El diagrama mostrado en la figura 1 muestra el flujo de tareas que se realiza en un proyecto MDD. Las tareas sombreadas serían realizadas en un proyecto tradicional. Las tareas en blanco son las adicionales que construyen las herramientas MDD para un proyecto específico.
Figura 1. Pasos para desarrollar un ambiente MDD
Se puede construir el ambiente y herramientas MDD, previo al desarrollo de la aplicación de negocio, o se puede tomar un método más iterativo, o “justo-a-tiempo”, donde se desarrolla el ambiente MDD en paralelo a la aplicación. De cualquier manera, es importante asignar tiempo adicional al proyecto de la aplicación de negocio, tomando en cuenta las mejoras. Desarrollar mejoras que pudieran identificarse dado el primer uso de las herramientas.
Tareas
Los pasos iniciales para desarrollar herramientas MDD son los mismos que en cualquier método de desarrollo tradicional. El arquitecto de la solución, los realiza, y define la estructura de alto nivel de la aplicación de negocio.
•Crear la arquitectura de la solución. Definir la estructura conceptual de la aplicación de negocio. Esta se expresa a través de estilos arquitectónicos que los desarrolladores adoptarán al construir la aplicación.
•Definir ambientes de ejecución. Se define el ambiente de ejecución en el que correrá la aplicación de negocio. Esto incluye los ambientes de desarrollo, pruebas y preproducción.
Una vez que esos dos pasos se completaron, el arquitecto tiene un buen entendimiento de lo que debe desarrollarse para la aplicación del negocio. Aquí ya puede arrancar las tareas específicas de MDD:
•Identificar los estándares y patrones comunes. Se identifican los patrones que se repiten durante la solución.
•Identificar activos existentes MDD reutilizables. Se comparan los patrones encontrados, con los activos MDD existentes para ver cuáles se pueden reutilizar, o hacer los ajustes necesarios.
•Definir el modelo de diseño. Se define qué diagramas, y con qué lineamientos se utilizarán para el modelado.
•Identificar un modelo independiente de la ejecución para los componentes. Este modelo especifica los componentes de la aplicación, sin atarse a una forma de desarrollo, o ambiente de ejecución particular.
•Producir artefactos muestra. Se codifican manualmente los artefactos para realizar un escenario típico de la aplicación. Esta tarea debe ser realizada por el mejor programador, ya que los programas que genere son los que se utilizarán como base para las plantillas y transformaciones MDD.
•Definir la cadena de herramientas. Se identifican las herramientas y configuraciones MDD que se requieren para el proyecto.
Una vez que se definen las herramientas MDD necesarias, podemos enfocarnos en construirlas y configurarlas:
•Extraer plantillas de artefactos muestra. Se desarrolla una plantilla para cada tipo de artefacto diferente, basándose en los artefactos muestra desarrollados previamente.
•Diseñar, codificar y probar transformaciones y patrones. Para cada patrón o transformación, se escribe el código que lea los modelos y genere o actualice los artefactos correspondientes, utilizando las plantillas.
•Empacar las herramientas MDD. Las herramientas se empaquetan de forma que sean fácilmente instalables por el equipo de desarrollo. En algunos casos, incluso sería justificable empaquetar las herramientas como un plug-in para el IDE que utilice el equipo, como por ejemplo: Eclipse.
•Producir documentación y educación para los desarrolladores de la aplicación.
•Validar la cadena de herramientas utilizando escenarios clave.
Ahora las herramientas MDD están listas para que los desarrolladores de la aplicación las utilicen. Lo que sigue es entrenar a los desarrolladores de la aplicación para utilizar las herramientas, y entonces desarrollar las aplicaciones de negocio.
La cadena de herramientas MDD
La figura 2 muestra el flujo de cómo un desarrollador puede utilizar las herramientas MDD para desarrollar parte de una aplicación de negocio. En este ejemplo, el desarrollador revisa el problema de negocio y selecciona un patrón de diseño. Esto aloja un modelo de diseño, y el desarrollador llena en detalle las funciones específicas del negocio que está construyendo. Posteriormente, el proceso de desarrollo es completamente automatizado. El desarrollador selecciona una opción para generar los artefactos, los cuales son empaquetados y colocados en el área de construcción. Entonces, el desarrollador puede seleccionar opciones, posteriormente para generar los artefactos adicionales para una plataforma de ejecución particular.
Figura 2. La Cadena de Herramientas MDD
Conclusión
En este artículo se explicó cómo se puede utilizar MDD para entregar valor de negocio mejorado de las soluciones de TI. Como cualquier otra técnica o herramienta, MDD se puede usar correcta o incorrectamente. MDD tiene el potencial para producir grandes beneficios como incremento en la productividad, repetibilidad, sistemas más adaptables, mejor comunicación, y captura del conocimiento. Sin embargo, la estrategia debe aplicarse correctamente para asegurar los resultados positivos.
Este artículo es una traducción resumida de un artículo escrito por Larry Yusuf, Mandy Chessell, y Tracy Gardner, y publicado en IBM Developerworks. La versión original se encuentra disponible en:
http://www-128.ibm.com/developerworks/library/ar-mdd1
Acerca del autor
Sergio Cedillo es Especialista Rational en IBM de México, y cuenta con más de siete años de experiencia en productos y soluciones de Rational. Previamente trabajó como consultor en soluciones de middleware para mercados financieros. En los últimos años se ha especializado en soluciones de pruebas automatizadas, y en implantaciones del Proceso Unificado Rational. Sergio es Ingeniero en Electrónica con Especialidad en Computación por la Universidad Autónoma Metropolitana.
- Log in to post comments