Uso de modelos dentro del proceso de desarrollo

Artículo
02/19/2013

En Visual Studio Ultimate, puede usar un modelo para que le ayude a comprender y modificar un sistema, aplicación o componente.Un modelo puede ayudarle a visualizar el mundo en el que trabaja el sistema, a clarificar las necesidades de los usuarios, a definir la arquitectura del sistema, a analizar el código y a garantizar que el código satisface los requisitos.

Vea Vídeo de canal 9: Mejorar la arquitectura con el modelado.

Usar modelos

Los modelos pueden ayudarle de varias maneras:

Dibujar diagramas de modelado puede servirle de ayuda para clarificar los conceptos implicados en los requisitos, la arquitectura y el diseño de alto nivel.Para obtener más información, vea Crear modelos de los requisitos de los usuarios.
Trabajar con modelos puede servirle de ayuda para poner de manifiesto las inconsistencias que pudiera haber en los requisitos.
La comunicación con modelos le permite transmitir conceptos importantes con una ambigüedad menor que la del lenguaje natural.Para obtener más información, vea Modelar la arquitectura de un sistema de Software.
En ocasiones, podrá usar los modelos para generar código u otros artefactos, como documentos o esquemas de base de datos.Por ejemplo, los componentes de modelado de Visual Studio Ultimate se generan a partir de un modelo.Para obtener más información, vea Generar y configurar aplicaciones a partir de modelos.

Puede usar modelos en una gran variedad de procesos, desde procesos extremadamente ágiles hasta procesos muy elaborados.

Usar modelos para reducir la ambigüedad

El lenguaje de modelos es menos ambiguo que el lenguaje natural y está diseñado para expresar las ideas que suelen emplearse durante el desarrollo de software.

Si el proyecto se compone de un equipo pequeño que busca procesos ágiles, puede usar los modelos para que le ayuden a dotar los casos de usuario de mayor claridad.En las conversaciones que mantenga con el cliente sobre sus necesidades, al crear un modelo, pueden surgir con más rapidez preguntas útiles relacionadas con un área mayor del producto que las que surgirían escribiendo una maqueta o prototipo de código.

Si el proyecto es grande y participan equipos que se encuentran en distintas partes del mundo, puede usar modelos que le ayuden a transmitir los requisitos y la arquitectura de forma más eficaz que a través de un documento de texto sin formato.

En estas dos situaciones, siempre que se crea un modelo, se reducen significativamente las inconsistencias y las ambigüedades.Los participantes del proyecto a menudo tienen concepciones distintas del mundo empresarial en el que trabaja el sistema y los desarrolladores suelen tener ideas distintas acerca de cómo funciona el sistema.Cuando se usa un modelo como eje central de una conversación, suelen salir a la luz estas diferencias.Para obtener más información acerca de cómo se puede usar un modelo para reducir las inconsistencias, vea Crear modelos de los requisitos de los usuarios.

Usar modelos con otros artefactos

Un modelo por sí solo no constituye una arquitectura ni una especificación de requisitos.En una herramienta que permite expresar algunos aspectos de estos elementos con mayor claridad, pero no todos los conceptos que serán necesarios durante el diseño de software.Los modelos, por tanto, deben usarse con otros medios de comunicación, como páginas o párrafos de OneNote, documentos de Microsoft Office, elementos de trabajo de Team Foundation o notas rápidas adheridas a la pared del proyecto.A excepción de este último, todos estos tipos de objetos pueden vincularse a elementos del modelo.

A continuación se enumeran otros aspectos de especificación que se usan habitualmente con los modelos.En función de la escala y el estilo del proyecto, podrá usar varios de estos aspectos o no usar ninguno:

Casos de usuario.Un caso de usuario es una descripción corta, que se analiza con los usuarios y demás participantes, de un aspecto del comportamiento del sistema que se proporcionará en una de las iteraciones del proyecto.Un caso de usuario típico comienza por "El cliente podrá...". Un caso de usuario puede presentar un grupo de casos de uso o puede definir extensiones de casos de uso que se desarrollaron previamente.Si se definen o amplían casos de uso, el caso de usuario resulta más claro.
Solicitudes de cambio.Una solicitud de cambio de un proyecto más formal es muy similar a un caso de usuario en de proyecto más ágil.En el enfoque ágil, todos los requisitos se tratan como modificaciones del trabajo desarrollado en iteraciones anteriores.
Descripción de casos de uso.Un caso de uso representa un mecanismo mediante el que un usuario interactúa con el sistema para lograr un objetivo determinado.Una descripción completa incluiría el objetivo, la secuencia de eventos principal y alternativa y los resultados excepcionales.Con los diagramas de casos de uso, resulta más fácil resumir y proporcionar información general sobre los casos de uso.
Escenarios.Un escenario es una descripción bastante detallada de una secuencia de eventos que muestran cómo el sistema, los usuarios y otros sistemas trabajan juntos para ofrecer un valor a las partes interesadas.Puede tener la forma de una presentación con diapositivas de la interfaz de usuario o un prototipo de la interfaz de usuario.En un escenario se puede describir un caso de uso o una secuencia de casos de uso.
Glosario.En el glosario de requisitos del proyecto se describen las palabras con las que los clientes explican su mundo.La interfaz de usuario y los modelos de requisitos también deben usar estos términos.Un diagrama de clases puede ayudar a clarificar las relaciones entre la mayoría de estos términos.Con la creación de los diagramas y el glosario, no solo se reducen los malentendidos entre los usuarios y los desarrolladores, sino que casi siempre se ponen de manifiesto también los malentendidos entre los distintos participantes del negocio.
Reglas de negocios.Muchas reglas de negocios se pueden expresar como restricciones invariables de las asociaciones y atributos del modelo de clases de requisitos y como restricciones de los diagramas de secuencia.
Diseño de alto nivel.Describe los elementos principales y cómo encajan unos con otros.Los diagramas de componentes, secuencia e interfaces constituyen una parte fundamental de un diseño de alto nivel.
Modelos de diseño.Describen las reglas de diseño que comparten diferentes elementos del sistema.
Especificaciones de prueba.Los diagramas de secuencia y los diagramas de actividades pueden resultar muy útiles en los scripts de prueba y los diseños del código de prueba para describir secuencias de pasos de prueba.Las pruebas del sistema deben expresarse en términos del modelo de requisitos para que se puedan modificar fácilmente cuando varíen los requisitos.
Plan del proyecto.El plan del proyecto o el trabajo pendiente establece cuando se entregará cada característica.Puede definir cada característica estableciendo qué casos de uso y reglas de negocio implementa o amplía.Puede hacer referencia a los casos de uso y las reglas de negocios directamente en el plan o puede definir un conjunto de características en un documento diferente y usar los títulos de estas características en el plan.

Usar modelos en los planes de iteraciones

Aunque todos los proyectos difieren en su escala y organización, un proyecto normal se planea como una serie de iteraciones de entre dos y seis semanas.Es importante planear iteraciones suficientes, de modo que los comentarios de las iteraciones iniciales puedan usarse para ajustar el ámbito y los planes en iteraciones posteriores.

Es posible que las sugerencias siguientes le resulten útiles para reconocer las ventajas del uso de modelos en un proyecto iterativo.

Ajustar el área de interés a medida que se acerca cada iteración

A medida que se acerca cada iteración, use modelos que le ayuden a definir los resultados que va a entregar al final de la iteración.

En las iteraciones iniciales, no debe modelar todo en detalle.En la primera iteración, cree un diagrama de clases para los elementos primarios del glosario del usuario, dibuje un diagrama de los casos de uso principales y dibuje un diagrama de los componentes principales.No describa estos elementos con un alto nivel de detalle porque los detalles cambiarán posteriormente en el proyecto.Use los términos definidos en este modelo para crear una lista de características o casos de usuario principales.Asigne las características a las iteraciones para equilibrar en la medida de lo posible la carga de trabajo calculada a lo largo del proyecto.Estas asignaciones variarán a medida que avance el proyecto.
Intente implementar versiones simplificadas de todos los casos de uso más importantes en una iteración inicial.Amplíe estos casos de uso en iteraciones posteriores.Con este enfoque, el riesgo de detectar un error en los requisitos o la arquitectura del proyecto demasiado tarde para poder hacer algo se reduce.
Cuando se acerque el final de cada iteración, celebre un taller de requisitos para definir en detalle los requisitos o casos de usuario que se desarrollarán en la iteración siguiente.Invite a los usuarios y a las partes interesadas del negocio que pueden establecer las prioridades, además de a los desarrolladores y a los evaluadores del sistema.Deje tres horas en cada iteración de dos semanas para definir los requisitos.
El objetivo del taller es que todos acuerden qué objetivos deben conseguirse al final de la iteración siguiente.Use los modelos como una herramientas más para aclarar los requisitos.La salida del taller es el trabajo pendiente de una iteración, es decir, una lista de tareas de desarrollo en Team Foundation y conjuntos de pruebas en Microsoft Test Manager.
En el taller de requisitos, analice el diseño solo en la medida en que necesite determinar las estimaciones de las tareas de desarrollo.De lo contrario, restrinja la conversación al comportamiento del sistema que los usuarios pueden experimentar directamente.Mantenga el modelo de requisitos separado del modelo arquitectónico.
El personal no técnico que participa en el proyecto no tendrá problemas para comprender los diagramas UML, con cierta ayuda por su parte.

Vincular el modelo a elementos de trabajo

Después del taller de requisitos, elabore los detalles del modelo de requisitos y vincule el modelo a las tareas de desarrollo.Puede hacerlo vinculando los elementos de trabajo de Team Foundation a los elementos del modelo.Para obtener información acerca de cómo hacerlo, vea Vincular elementos de modelo con elementos de trabajo.

Puede vincular cualquier elemento a los elementos de trabajo, pero los elementos más útiles son los siguientes:

Caso de uso.Puede vincular un caso de uso a las tareas de desarrollo que lo van a implementar.
Extensiones de casos de uso.Si solo se va a implementar un aspecto de un caso de uso en una iteración, puede separarlo en un caso de uso base junto con una o varias extensiones.Las extensiones son casos de uso vinculados al caso base con la relación «extender».Para obtener más información sobre la extensión de casos de uso, vea Diagramas de casos de uso de UML: Referencia.
Comentarios en los que se describan reglas de negocios o requisitos de calidad del servicio.Para obtener más información, vea Crear modelos de los requisitos de los usuarios.

Vincular el modelo a las pruebas

Use el modelo de requisitos para dirigir el diseño de las pruebas de aceptación.Cree estas pruebas simultáneamente con el trabajo de desarrollo.

Para obtener más información sobre esta técnica, vea Desarrollar pruebas en un modelo.

Calcular el trabajo restante

Un modelo de requisitos puede ayudar a calcular el tamaño total del proyecto frente al tamaño de cada iteración.Calcular el número y la complejidad de los casos de uso y las clases puede ayudar a estimar el trabajo de desarrollo que será necesario.Cuando haya completado las primeras iteraciones, una comparación de los requisitos cubiertos y de los requisitos que quedan por cubrir puede proporcionarle una idea aproximada del costo y el ámbito del resto del proyecto.

Cuando se acerque el final de cada iteración, revise la asignación de requisitos a futuras iteraciones.Quizás le resulte útil representar el estado del software al final de cada iteración como un subsistema en un diagrama de casos de uso.En las conversaciones, puede mover los casos de uso y las extensiones de casos de uso de estos subsistemas a otros.

Niveles de abstracción

El nivel de abstracción de los modelos varía en función del software.Los modelos más concretos representan directamente el código del programa y los modelos más abstractos representan conceptos del negocio que pueden o no representarse en el código.

Un modelo puede verse a través de distintos tipos de diagramas.Para obtener información sobre los modelos y diagramas, vea Desarrollar modelos para el diseño de software.

Los distintos tipos de diagramas resultan útiles para describir el diseño con diferentes niveles de abstracción.Muchos de los tipos de diagramas resultan útiles para varios niveles.En esta tabla se muestra cómo se puede usar cada tipo de diagrama.

Nivel de diseño	Tipos de diagramas
Proceso del negocio Conocer el contexto en el que se va a usar el sistema le ayuda a comprender qué es lo que el usuario necesita de este sistema.	En los diagramas de actividades se describe el flujo de trabajo entre las personas y los sistemas para lograr los objetivos del negocio. En los diagramas de clases conceptuales se describen los conceptos del negocio que se usan en los procesos del negocio.
Requisitos del usuario Definición de lo que los usuarios necesitan del sistema.	En los diagramas de casos de uso se resumen las interacciones que los usuarios y otros sistemas externos tienen con el sistema que está desarrollando.Puede adjuntar otros documentos a cada caso de uso para describirlo en detalle. En los diagramas de clases UML se describen los tipos de información sobre los que se comunican los usuarios y el sistema. Las reglas de negocios y los requisitos de calidad del servicio se pueden describir en documentos independientes.
Diseño de alto nivel Estructura global del sistema: sus componentes primarios y cómo se acoplan.	Los diagramas de capas describen cómo el sistema se estructura en partes interdependientes.Puede validar el código del programa con los diagramas de capas para asegurar que se adhieren a la arquitectura. Los diagramas de componentes muestran las interfaces de las partes, y especifican los mensajes y servicios que se proporcionan y que requiere cada componente. En los diagramas de secuencia se muestra cómo se comunican los componentes para implementar cada caso de uso. En los diagramas de clases UML se describen las interfaces de los componentes y los tipos de datos que se pasan entre los componentes.
Modelos de diseño Convenciones y métodos para problemas de diseño que se usan en todos los elementos del diseño.	En los diagramas de clases UML se describen las estructuras de un modelo. En los diagramas de secuencia o actividades se muestran las interacciones y los algoritmos.
Análisis de código Se pueden generar distintos tipos de diagramas a partir del código.	En los diagramas de secuencia se muestra las interacciones entre los objetos del código. En los diagramas de capas se muestran las dependencias entre las clases.El código actualizado se puede validar con un diagrama de capas. En los diagramas de clases se muestran las clases del código.

Recursos externos

Categoría	Vínculos
Videos
Foros	Visual Studio Visualization & Modeling Tools Visual Studio Visualization & Modeling SDK (DSL Tools)
Blogs	Visual Studio ALM + Team Foundation Server Blog
Artículos y diarios técnicos	The Architecture Journal - Issue 23: Architecture Modeling and Processes
Otros sitios	Centro de Arquitectura - MSDN Visual Studio Architecture Tooling Guidance