Generación automática de código

Conforme va madurando el campo de tecnologí­a de información, se van estableciendo patrones de referencia de cómo deben ser las aplicaciones de negocio y va aumentando la presión para tener ciclos de desarrollo cortos.


Surge entonces la necesidad de mecanizar el proceso de producción de software, y además hacerlo de manera flexible y ágil que permita incorporar la parte variable de manera robusta.

Un enfoque es desarrollo Cut-and-Paste usando programadores experimentados en el desarrollo de aplicaciones similares a la que se esta haciendo. Este modelo tiene sus limitaciones y no es realmente escalable. Por un lado es propenso a errores y consume horas-hombre que serian mejor empleadas en actividades que se beneficien de la capacidad creativa y visión del desarrollador. Por otro lado, realmente no permite de manera natural institucionalizar y transferir experiencias entre desarrolladores y entre grupos de desarrolladores.

En el ciclo de vida y desarrollo de una aplicación se requieren distintas perspectivas y niveles de abstracción. En un proceso mecanizado de desarrollo debe haber herramientas que idealmente nos permita partir de la conceptualización de las necesidades de negocio y de manera automática llegar a la implantación bajo tecnologí­as especí­ficas.

El grupo de patrones y prácticas de Microsoft ha desarrollado el concepto de fábricas de software como paquetes de referencia que incluyen una serie de artefactos que permiten mecanizar el desarrollo de familias de aplicaciones. Estos artefactos incluyen modelos, marcos (frameworks) y herramientas.



UML se utiliza en algunas herramientas que generan código a partir de un diagrama de clases por ejemplo. De manera más general el Object managment Group (OMG) ha desarrollado el concepto de arquitectura dirigida por modelos (model-driven architecture, MDA). Este enfoque pudiera ser a un nivel de abstracción y generalización demasiado alto para ser de uso practico.

MDA enfatiza independencia de plataforma. En la práctica, esto no puede ser un absoluto. Las caracterí­sticas de una tecnología o implementación son restricciones en el modelo.

MDA asume que están disponibles modelos para cualquier artefacto.

MDA utiliza UML como lenguaje de uso general. Algunas tecnologías y aplicaciones no se prestan para ser representados en UML y se pueden describir mejor con herramientas especí­ficas que permitan una mayor fidelidad al pasar de concepto a implementación.

MDA asume que 3 tipos de modelo son suficientes:

computation-independent model,

platform-independent model,

platform-specific model.

MDA se enfoca en transformaciones. Es difí­cil lograr un proceso completamente automático que vaya de concepto a implementación. La metodología debe incluir el manejo de la parte variable que no se puede automatizar y los cambos que se requieran durante el mantenimiento de una aplicación

Un lenguaje de modelación de uso general como UML esta diseñado para soportar el desarrollo de modelos que sirvan principalmente como documentación. Estos lenguajes pueden describir cualquier dominio, pero necesariamente de manera imprecisa por el alto nivel de abstracción que utilizan. En el caso de UML, las abstracciones genéricas se definen utilizando lenguaje natural informal.

Un lenguaje de domino especifico (DSL), esta diseñado para describir con precisión una tarea especifica. En vez de abstracciones genéricas utiliza conceptos tomados directamente de la tarea a modelar.

El concepto de fabricas de software de Microsoft utiliza como componente básicos leguajes de alta fidelidad como XML, C# y SQL, lenguajes de domino especifico (Domain Specific Language, DSL), scripts de flujos de trabajo (workflow), archivos WSDL, archivos DDL, SQL.

Las fábricas de software son especí­ficas a subsistemas como administración de clientes, administración de catálogos, cumplimiento de órdenes.

El machote (template) de una fábrica de software incluye código y metadata que se pueden cargar en un IDE o en una herramienta de desarrollo de aplicaciones empresariales. El concepto de machote es similar al de un machote de un documento de Word o Excel.

El uso de una fábrica de software incluye los siguientes pasos:

• Análisis de problema. Primero determinar si el producto cae dentro del alcance de la fábrica de software.


• Especificación del producto. Definir los requerimientos del producto en términos de sus diferencias con los requerimientos de los componentes de la fábrica de software.


• Arquitecta del producto. Ajustar la fabrica de software a las características particulares del producto.


• Implementación. Las actividades usuales de pruebas unitarias, pruebas de ejecución, ensamblaje de componentes, desarrollo de componentes


• Instalación. Crear o re usar restricciones, configuración de infraestructura, validaciones, instalación de requerimientos y ejecutalbes.


• Pruebas. Crear o re usar recursos de pruebas, datos de prueba, scripts de prueba, uso de herramientas de medición.

Las fábricas de software proporcionan un enfoque robusto a la creación de software usando un paradigma de modelación visual, pero va más allá del uso de modelos como documentación. Usando DSL y XML permiten usar metadata para automatizar la generación de código. Los cuatro pilares de las fábricas de software son: Líneas de software, marcos arquitectónicos (architecture frameworks), desarrollo dirigido por modelos, y guías contextuales

El esquema de fábrica de software es un modelo diseñado para soportar cómputo. El esquema de una fábrica es un árbol. Cada nodo en el árbol se conoce como una perspectiva (viewpoint). La perspectiva raíz corresponde a construir todo el entregable. Las perspectivas subyacentes se derivan por descomposición. Cada perspectiva describe la solución en términos de actividades a realizar y una explicación como realizar cada actividad. Las actividades se describen en términos de los productos que generan. Esto productos son los componentes que se utilizan para construir el entregable. Además cada perspectiva incluye recursos suministrados por la fábrica para resolver los problemas del dominio, generalmente automatizando total o parcialmente la tarea.

Par construir una fabrica se empieza sencillo con recursos simples y se va invirtiendo tiempo en desarrollar recursos más sofisticados conforme se va ganando experiencia en el dominio.

Referencias:

Bare-Naked Languages or What Not to Model

CodeGen'ing a Data Access Layer with CodeSmith

LLBLGen

Microsoft DSL

CodeSmith Community: .netTiers

Sean Mccormack's Codus

Software Factories

Wilson OR Mapper templates for CodeSmith

Codegeneration.net

Can you code gen everything?

CodeSmith Community: Rocky CSLA Templates

Deklarit Kathleen Dollard

CodeSmith Community: Files

Andres Aguiar's Blog

Eric Smith's Blog

.nettiers demo/tutorial DAL in 15 mins

Global Bank Scenario

Visual Studio 2005 SDK Version 4.0

http://blogs.msdn.com/jackgr/

Jack Greenfield's Blog

Code Generation Network

TypeBuilderLib, a Library to Build Dynamic Types Easily