Generar y configurar aplicaciones a partir de modelos

Artículo
06/10/2015

Puede generar o configurar partes de una aplicación a partir de un modelo. El modelo puede estar en UML o DSL.

El modelo representa los requisitos más directamente que el código. Derivando el comportamiento de la aplicación directamente del modelo, es posible responder a los requisitos que hayan cambiado con mayor rapidez y confiabilidad que actualizando el código. Aunque sea necesario algún trabajo previo para configurar la derivación, la inversión se recupera si se esperan cambios en los requisitos o si piensa llevar a cabo varias variantes del producto.

Generar el código de la aplicación a partir de un modelo

La manera más fácil de generar el código es utilizando plantillas de texto. Se puede generar el código en la misma solución de Visual Studio en la que se mantiene el modelo. Para obtener más información, vea:

Este método se aplica incrementalmente con facilidad. Comience con una aplicación que solo funcione para un caso concreto y elija algunas partes que desee variar del modelo. Cambie el nombre de los archivos de código fuente de estas partes para convertirlos en archivos de plantilla de texto (.tt). En este punto, los archivos .cs de código fuente se generarán automáticamente a partir de los archivos de plantilla, de modo que la aplicación funcionará como antes.

A continuación puede tomar una parte del código y reemplazarlo con una expresión de plantilla de texto, que lee el modelo y genera esa parte del archivo de código fuente. Por lo menos un valor del modelo debe generar el código fuente original de forma que se pueda ejecutar la aplicación de nuevo y funcione como antes. Después de probar distintos valores del modelo, puede continuar insertando las expresiones de la plantilla en otra parte del código.

Este método incremental significa que la generación de código es, normalmente, un enfoque de bajo riesgo. El rendimiento de las aplicaciones resultantes es prácticamente igual al de una versión escrita a mano.

Sin embargo, si comienza con una aplicación existente, verá que es necesaria mucha refactorización para separar los distintos comportamientos que rige el modelo de forma que se puedan variar independientemente. Recomendamos evaluar este aspecto de la aplicación cuando calcule el costo del proyecto.

Configurar aplicaciones a partir de un modelo

Si desea variar el comportamiento de una aplicación en tiempo de ejecución, no puede utilizar la generación de código, que genera el código fuente antes de que se compile la aplicación. En cambio, puede diseñar la aplicación para que lea el modelo UML o DSL y varíe su comportamiento en consecuencia. Para obtener más información, vea:

También se puede aplicar este método incrementalmente, pero hay que hacer más trabajo al principio. Necesita escribir el código que leerá el modelo y configurar un marco que permita que los valores estén accesibles a las partes variables. Hacer genéricas las partes variables es más caro que la generación de código.

El rendimiento de una aplicación genérica es, normalmente, inferior al de sus homólogas concretas. Si el rendimiento es crucial, el plan del proyecto debe incluir una evaluación de este riesgo.

Desarrollar una aplicación derivada

Las siguientes directrices generales pueden resultar útiles.

Comience por lo concreto; después, generalice. Primero escriba una versión concreta de la aplicación. Esta versión debe funcionar en un conjunto de condiciones. Cuando esté funcionando correctamente, puede hacer que parte de ella derive de un modelo. Amplíe gradualmente las partes derivadas.

Por ejemplo, diseñe un sitio web que tenga un conjunto concreto de páginas antes de diseñar una aplicación web que presente las páginas que se definen en un modelo.
Modele los aspectos que varían. Identifique los aspectos que variarán entre una implementación y otra, o con el tiempo a medida que los requisitos cambien. Estos son los aspectos que se deben derivar de un modelo.

Por ejemplo, si el conjunto de páginas web y los vínculos entre ellas cambian, pero el estilo y el formato de las páginas son siempre los mismos, el modelo debe describir los vínculos, pero no el formato de las páginas.
Separe los problemas. Si los aspectos variables se pueden dividir en áreas independientes, utilice modelos independientes para cada área. Con ModelBus, puede definir las operaciones que afectan a ambos modelos y las restricciones entre ellos.

Por ejemplo, use un modelo para definir la navegación entre las páginas web y otro distinto para definir el diseño de las páginas. Para obtener más información, vea Cómo: Integrar modelos UML con otros modelos y herramientas.
Modele el requisito, no la solución. Diseñe el DSL o adapte el UML para que describa los requisitos de los usuarios. Pero no diseñe la notación según los aspectos variables de la implementación.

Por ejemplo, el modelo de navegación web debe representar las páginas web y los hipervínculos entre ellas. El modelo de navegación web no debe representar fragmentos de HTML o clases en la aplicación.
¿Generar o interpretar? Si los requisitos de una implementación determinada no van a cambiar a menudo, genere el código del programa a partir del modelo. Si los requisitos van a cambiar con frecuencia o van a coexistir en más de una variante de la misma implementación, escriba la aplicación de manera que pueda leer e interpretar un modelo.

Por ejemplo, si utiliza un modelo de sitio web para desarrollar una serie de sitios web diferentes e instalados independientemente, genere el código del sitio a partir del modelo. Pero si usa el modelo para controlar un sitio que cambia todos los días, es mejor escribir un servidor web que lea el modelo y presente el sitio de la forma adecuada.
¿UML o DSL? Considere crear la notación de modelado utilizando estereotipos para ampliar el UML. Defina un DSL si no hay ningún diagrama en UML que se ajuste a este objetivo. Pero evite interrumpir la semántica estándar del UML.

Por ejemplo, un diagrama de clases en UML es una colección de cuadros y flechas; con esta notación puede, en teoría, definir cualquier cosa. Pero no se recomienda utilizar el diagrama de clases excepto donde se describa de hecho un conjunto de tipos. Por ejemplo, podría adaptar los diagramas de clases para describir distintos tipos de páginas web.