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.
En Visual Studio, puede usar un modelo para ayudarle a comprender y cambiar un sistema, una aplicación o un componente. Un modelo puede ayudarle a visualizar el mundo en el que funciona el sistema, aclarar las necesidades de los usuarios, definir la arquitectura del sistema, analizar el código y asegurarse de que el código cumple los requisitos.
Para ver qué versiones de Visual Studio admiten cada tipo de modelo, consulte Compatibilidad de versiones con herramientas de arquitectura y modelado.
Los modelos pueden ayudarle de varias maneras:
Dibujar diagramas de modelado le ayuda a aclarar los conceptos implicados en los requisitos, la arquitectura y el diseño de alto nivel. Para obtener más información, consulte Model user requirements (Requisitos de usuario del modelo).
Trabajar con modelos puede ayudarle a exponer incoherencias en los requisitos.
La comunicación con modelos le ayuda a comunicar conceptos importantes de forma menos ambigua que con lenguaje natural. Para obtener más información, consulta Modelar la arquitectura de la aplicación.
A veces puede usar modelos para generar código u otros artefactos, como esquemas de base de datos o documentos. Por ejemplo, los componentes de modelado de Visual Studio se generan a partir de un modelo. Para obtener más información, consulte Generación y configuración de la aplicación a partir de modelos.
Puede usar modelos en una amplia variedad de procesos, desde el extremo ágil hasta el de alta formalidad.
Uso de modelos para reducir la ambigüedad
El lenguaje de modelado es menos ambiguo que el lenguaje natural y está diseñado para expresar las ideas que normalmente se requieren durante el desarrollo de software.
Si el proyecto tiene un equipo pequeño siguiendo prácticas ágiles, puede usar modelos para ayudarle a aclarar los casos de usuario. En las discusiones con el cliente sobre sus necesidades, la creación de un modelo puede generar preguntas útiles mucho más rápidamente y en un área más amplia del producto que escribir código spike o prototipo.
Si el proyecto es grande e incluye equipos en diferentes partes del mundo, puede usar modelos para ayudar a comunicar los requisitos y la arquitectura de forma mucho más eficaz que en texto sin formato.
En ambos casos, la creación de un modelo casi siempre produce una reducción significativa de incoherencias y ambigüedades. Las distintas partes interesadas suelen tener diferentes conocimientos del mundo empresarial en el que funciona el sistema, y los diferentes desarrolladores suelen tener diferentes conocimientos sobre cómo funciona el sistema. El uso de un modelo como enfoque de una discusión suele exponer estas diferencias. Para obtener más información sobre cómo usar un modelo para reducir las incoherencias, consulte Requisitos de usuario del modelo.
Uso de modelos con otros artefactos
Un modelo no es por sí mismo una especificación de requisitos o una arquitectura. Es una herramienta para expresar algunos aspectos de estas cosas con más claridad, pero no todos los conceptos necesarios durante el diseño de software se pueden expresar. Por lo tanto, los modelos deben usarse junto con otros medios de comunicación, como páginas o párrafos de OneNote, documentos de Microsoft Office, elementos de trabajo en Team Foundation o notas permanentes en la pared de la sala del proyecto. Aparte del último elemento, todos estos tipos de objetos se pueden vincular a elementos del modelo.
Otros aspectos de la especificación que normalmente se usan junto con los modelos incluyen lo siguiente. En función de la escala y el estilo del proyecto, puede usar varios de estos aspectos o no usar ninguno en absoluto:
Casos de usuario. Un artículo de usuario es una breve descripción, que se describe con los usuarios y otras partes interesadas, de un aspecto del comportamiento del sistema que se entregará en una de las iteraciones del proyecto. Un caso de usuario típico comienza "El cliente podrá...". Un caso de usuario podría introducir un grupo de casos de uso o puede definir extensiones de casos de uso que se hayan desarrollado anteriormente. Definir o ampliar los casos de uso ayuda a que el caso del usuario sea más claro.
Solicitudes de cambio. Una solicitud de cambio en un proyecto más formal es muy similar a un caso de usuario en un proyecto ágil. El enfoque ágil trata todos los requisitos como cambios en lo que se desarrolló en iteraciones anteriores.
Descripción del caso de uso. Un caso de uso representa una manera en la que un usuario interactúa con el sistema para lograr un objetivo determinado. Una descripción completa incluye el objetivo, las secuencias principales y alternativas de los eventos y los resultados excepcionales. Un diagrama de casos de uso ayuda a 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 muestra cómo funcionan juntos el sistema, los usuarios y otros sistemas para proporcionar valor a las partes interesadas. Puede adoptar la forma de una presentación con diapositivas de la interfaz de usuario o un prototipo de la interfaz de usuario. Puede describir un caso de uso o una secuencia de casos de uso.
Glosario. El glosario de requisitos del proyecto describe las palabras con las que los clientes describen su mundo. Los modelos de interfaz de usuario y requisitos también deben usar estos términos. Un diagrama de clases puede ayudar a aclarar las relaciones entre la mayoría de estos términos. La creación de diagramas y glosarios no solo reduce los malentendidos entre usuarios y desarrolladores, sino que también casi siempre expone malentendidos entre diferentes partes interesadas de la empresa.
Reglas de negocio. Muchas reglas de negocios se pueden expresar como restricciones invariables en las asociaciones y atributos del modelo de clase de requisitos y como restricciones en diagramas de secuencia.
Diseño de alto nivel. Describe las partes principales y cómo encajan juntas. Los diagramas de componentes, secuencias e interfaces son una parte importante de un diseño de alto nivel.
Patrones de diseño. Describir las reglas de diseño que se comparten entre las distintas partes del sistema.
Especificaciones de prueba. Los scripts de prueba y los diseños de código de prueba pueden hacer un buen uso de los diagramas de actividad y secuencia para describir secuencias de pasos de prueba. Las pruebas del sistema deben expresarse en términos del modelo de requisitos para que se puedan cambiar fácilmente cuando cambian los requisitos.
Plan de proyecto. El plan de proyecto o el trabajo pendiente define cuándo se entregará cada característica. Puede definir cada característica indicando qué casos de uso y reglas de negocio implementa o extiende. Puede hacer referencia a los casos de uso y las reglas de negocio directamente en el plan, o bien puede definir un conjunto de características en un documento independiente y usar los títulos de características del plan.
Uso de modelos en el planeamiento de iteración
Aunque todos los proyectos son diferentes en su escala y organización, se planea un proyecto típico como una serie de iteraciones de entre dos y seis semanas. Es importante planear suficientes iteraciones para permitir que los comentarios de las iteraciones tempranas se usen para ajustar el ámbito y los planes para iteraciones posteriores.
Puede encontrar las siguientes sugerencias útiles para ayudar a obtener las ventajas del modelado en un proyecto iterativo.
Agudizar el enfoque a medida que se acerca cada iteración
A medida que se aproxima cada iteración, use modelos para ayudar a definir lo que se va a entregar al final de la iteración.
No desarrolle cada aspecto en detalle en las primeras iteraciones. En la primera iteración, cree un diagrama de clases para los elementos principales del glosario de usuario, dibuje un diagrama de los casos de uso principales y dibuje un diagrama de los componentes principales. No describa ninguno de estos detalles con detalle, ya que los detalles cambiarán más adelante 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 aproximadamente la carga de trabajo estimada en todo el proyecto. Estas asignaciones cambiarán más adelante en el proyecto.
Intente implementar versiones simplificadas de todos los casos de uso más importantes en una iteración temprana. Amplíe esos casos de uso en iteraciones posteriores. Este enfoque ayuda a reducir el riesgo de detectar un error en los requisitos o la arquitectura demasiado tarde en el proyecto para hacer algo sobre él.
Cerca del final de cada iteración, mantenga un taller de requisitos para definir en detalle los requisitos o casos de usuario que se desarrollarán en la siguiente iteración. Invite a los usuarios y a las partes interesadas empresariales que puedan decidir prioridades, así como a desarrolladores y evaluadores del sistema. Asignar tres horas para definir los requisitos de una iteración de 2 semanas.
El objetivo del taller es que todos acepten lo que se logrará al final de la siguiente iteración. Use modelos como una de las herramientas para ayudar a aclarar los requisitos. La salida del taller es un trabajo pendiente de iteración: es decir, una lista de tareas de desarrollo en Team Foundation y conjuntos de pruebas de 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, mantenga la discusión sobre el comportamiento del sistema que los usuarios pueden experimentar directamente. Mantenga el modelo de requisitos separado del modelo de arquitectura.
Normalmente, las partes interesadas no técnicas no tienen problemas para comprender los diagramas de UML, con algunas instrucciones de usted.
Vinculación del modelo a elementos de trabajo
Después del taller de requisitos, elabora los detalles del modelo de requisitos y vincula el modelo a las tareas de desarrollo. Para ello, puede vincular elementos de trabajo de Team Foundation a elementos del modelo.
Puede vincular cualquier elemento a elementos de trabajo, pero los elementos más útiles son los siguientes:
- Comentarios que describen las reglas de negocios o la calidad de los requisitos de servicio. Para obtener más información, consulte Model user requirements (Requisitos de usuario del modelo).
Vinculación del modelo a las pruebas
Use el modelo de requisitos para guiar el diseño de las pruebas de aceptación. Cree estas pruebas simultáneamente con el trabajo de desarrollo.
Para más información sobre esta técnica, consulte Desarrollo de pruebas a partir de un modelo.
Estimación del trabajo restante
Un modelo de requisitos puede ayudar a calcular el tamaño total del proyecto en relación con el tamaño de cada iteración. Evaluar el número y la complejidad de los casos de uso y las clases puede ayudarle a calcular el trabajo de desarrollo que será necesario. Cuando haya completado las primeras iteraciones, una comparación de los requisitos cubiertos y los requisitos que se siguen abarcando pueden dar una medida aproximada del costo y el ámbito del resto del proyecto.
Cerca del final de cada iteración, revise la asignación de requisitos a futuras iteraciones. Puede ser útil representar el estado del software al final de cada iteración como subsistema en un diagrama de casos de uso. En los debates, puede mover casos de uso y extensiones de casos de uso de uno de estos subsistemas a otro.
Niveles de abstracción
Los modelos tienen una gama de abstracción en relación con el software. Los modelos más concretos representan directamente el código de programa y los modelos más abstractos representan conceptos empresariales que podrían o no representarse en el código.
Un modelo se puede ver a través de varios tipos de diagramas. Para obtener información sobre los modelos y diagramas, consulte Creación de modelos para la aplicación.
Los diferentes tipos de diagramas son útiles para describir el diseño en diferentes niveles de abstracción. Muchos de los tipos de diagrama son útiles en más de un nivel. En esta tabla se muestra cómo se puede usar cada tipo de diagrama.
| Nivel de diseño | Tipos de diagrama |
|---|---|
| Proceso de negocio Comprender el contexto en el que se usará el sistema le ayuda a comprender lo que los usuarios necesitan de él. |
- Los diagramas de clases conceptuales describen los conceptos empresariales que se usan en el proceso de negocio. |
| Requisitos del usuario Definición de lo que necesitan los usuarios del sistema. |
- Las reglas de negocio y los requisitos de calidad de servicio se pueden describir en documentos independientes. |
| Diseño de alto nivel La estructura general del sistema: los componentes principales y cómo se unen. |
- Diagramas de dependencias describen cómo se estructura el sistema en partes interdependientes. Puede validar el código de programa en los diagramas de dependencias para asegurarse de que se adhiere a la arquitectura. |
| Análisis de código Los diagramas se pueden generar a partir del código. |
- Los diagramas de dependencia muestran las dependencias entre clases. El código actualizado se puede validar en un diagrama de dependencias. - Los diagramas de clases muestran las clases en el código. |
Recursos externos
Contenido relacionado
- Uso de modelos en el desarrollo de Agile
- Creación de modelos para la aplicación
- Requisitos del usuario del modelo
- Modelar la arquitectura de la aplicación
- Desarrollo de pruebas a partir de un modelo
- Estructura de la solución de modelado
Nota:
El componente Transformación de Plantillas de Texto se instala automáticamente como parte de la tarea Desarrollo de Extensiones de Visual Studio. También puede instalarlo desde la pestaña Componentes individuales del Instalador de Visual Studio, en la categoría SDK, bibliotecas y marcos . Instale el componente SDK de modelado desde la pestaña Componentes individuales .