Nota:
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
Puede generar o configurar partes de la aplicación a partir de un modelo.
El modelo representa los requisitos más directamente que el código. Al derivar el comportamiento de la aplicación directamente desde el modelo, puede responder a los requisitos modificados de forma mucho más rápida y confiable que mediante la actualización del código. Aunque se requiere algún trabajo inicial para configurar la derivación, esta inversión se devuelve si espera cambios en los requisitos, o si tiene previsto realizar varias variantes del producto.
Generación del código de la aplicación a partir de un modelo
La manera más fácil de generar código es mediante plantillas de texto. Puede generar código en la misma solución de Visual Studio en la que se mantiene el modelo. Para obtener más información, consulte:
Generación de código en tiempo de diseño mediante plantillas de texto T4
Generación de código a partir de un lenguaje Domain-Specific
Este método es fácil de aplicar de forma incremental. Comience con una aplicación que funcione solo para un caso específico y elija algunas partes de ella que quiera variar del modelo. Cambie el nombre de los archivos de origen de estas partes para que se conviertan en archivos de plantilla de texto (.tt). En este momento, los archivos de .cs de origen se generarán automáticamente a partir de los archivos de plantilla, por lo que la aplicación funcionará como hizo antes.
A continuación, puede tomar una parte del código y reemplazarlo por una expresión de plantilla de texto, que lee el modelo y genera esa parte del archivo de origen. Al menos un valor del modelo debe generar el origen original para que pueda ejecutar de nuevo la aplicación y funcionará como antes. Después de probar valores de modelo diferentes, puede pasar a insertar expresiones de plantilla en otra parte del código.
Este método incremental significa que la generación de código suele ser un enfoque de bajo riesgo. Las aplicaciones resultantes suelen funcionar casi así como una versión escrita a mano.
Sin embargo, si empieza con una aplicación existente, es posible que se requiera una gran cantidad de refactorización para separar los distintos comportamientos que se rigen por el modelo para que puedan variar de forma independiente. Se recomienda evaluar este aspecto de la aplicación al calcular el costo del proyecto.
Configuración de la aplicación desde un modelo
Si desea variar el comportamiento de la aplicación en tiempo de ejecución, no puede usar la generación de código, que genera código fuente antes de compilar la aplicación. En su lugar, puede diseñar la aplicación para leer el modelo y variar su comportamiento en consecuencia. Para obtener más información, consulte:
Cómo: Abrir un modelo desde un archivo en código de programa
Este método también se puede aplicar de forma incremental, pero hay más trabajo al principio. Debe escribir el código que leerá el modelo y configurar un marco que permita que sus valores sean accesibles para las partes de la variable. Hacer que las partes de variable sean genéricas es más costosa que la generación de código.
Normalmente, una aplicación genérica funciona menos que sus homólogos específicos. Si el rendimiento es fundamental, el plan de proyecto debe incluir una evaluación de este riesgo.
Desarrollo de una aplicación derivada
Es posible que le resulte útil las siguientes directrices generales.
Comience específico y, a continuación, generalice. Escriba primero una versión específica de la aplicación. Esta versión debe funcionar en un conjunto de condiciones. Cuando esté satisfecho de que funciona correctamente, puede hacer que algunos de estos deriven de un modelo. Amplíe las partes derivadas gradualmente.
Por ejemplo, diseñe un sitio web que tenga un conjunto específico de páginas web antes de diseñar una aplicación web que presente páginas definidas en un modelo.
Modele los aspectos variantes. Identifique los aspectos que variarán, ya sea entre una implementación y otra, o a lo largo del tiempo a medida que cambian los requisitos. 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 siempre son los mismos, el modelo debe describir los vínculos, pero no tiene que describir el formato de las páginas.
Separe las preocupaciones. Si los aspectos de la variable se pueden dividir en áreas independientes, use modelos independientes para cada área. Con ModelBus, puede definir operaciones que afecten a ambos modelos y restricciones entre ellos.
Por ejemplo, use un modelo para definir la navegación entre las páginas web y otro modelo para definir el diseño de las páginas.
Modele el requisito, no la solución. Diseñe el modelo para que describa los requisitos del usuario. Por el contrario, 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 páginas web e hipervínculos entre ellas. El modelo de navegación web no debe representar fragmentos de HTML o clases en la aplicación.
¿Genera o interpreta? Si los requisitos de una implementación determinada rara vez cambiarán, genere código de programa a partir del modelo. Si los requisitos pueden cambiar con frecuencia o pueden coexistir en más de una variante de la misma implementación, escriba la aplicación para que pueda leer e interpretar un modelo.
Por ejemplo, si usa el modelo de sitio web para desarrollar una serie de sitios web diferentes e instalados por separado, debe generar el código del sitio a partir del modelo. Pero se usa el modelo para controlar un sitio que cambia todos los días, entonces es mejor escribir un servidor web que lea el modelo y presente el sitio en consecuencia.
UML o DSL? Considere crear su notación de modelado usando estereotipos para extender UML. Defina un DSL si no hay ningún diagrama UML que se ajuste al propósito. Pero evite interrumpir la semántica estándar de UML.
Por ejemplo, un diagrama de clases UML es una colección de cuadros y flechas; con esta notación se puede definir en teoría cualquier cosa. Pero no se recomienda usar el diagrama de clases, excepto donde se describe de hecho un conjunto de tipos. Por ejemplo, podría adaptar diagramas de clases para describir diferentes tipos de páginas web.