Información general sobre el escenario: Cambiar el diseño usando modelado y visualización

Para asegurarse de que el sistema de software satisface las necesidades de los usuarios, utilice las herramientas de visualización y modelado de Visual Studio Ultimate para ayudarle a actualizar o cambiar el diseño del sistema. Entre estas herramientas se incluyen diagramas de Unified Modeling Language (UML), diagramas de capas, gráficos de dependencias basados en códigos, diagramas de secuencia y diagramas de clases. Por ejemplo, puede utilizar estas herramientas para realizar estas tareas:

• Clarificar los requisitos de los usuarios y los procesos de negocios empresariales.

• Visualizar y explorar el código existente.

• Describir los cambios efectuados en un sistema existente.

• Comprobar que el sistema cumple los requisitos.

• Mantener la coherencia entre el código y el diseño.

En este tutorial se utiliza un escenario de ejemplo para lograr los siguientes objetivos:

• Proporcionar información de alto nivel de las herramientas y sus ventajas en un proyecto de software.

• Demostrar cómo dos equipos podrían utilizar estas herramientas en un escenario de ejemplo, con independencia de los enfoques de desarrollo.

Para obtener más información sobre estas herramientas y los escenarios que admiten, vea:

• Modelar la aplicación

• Visualizar el código

• Desarrollar modelos para el diseño de software

En este tema

Sección	Descripción
Información general sobre el escenario	Describe el escenario de ejemplo y sus participantes.
Roles de los diagramas de arquitectura y modelado en el desarrollo de software	Describe los roles que estas herramientas desempeñan durante el ciclo de vida de desarrollo de software.
Comprender y comunicar la información sobre el sistema	Proporciona información general de alto nivel sobre el modo en que los participantes utilizan las herramientas en este escenario.
Actualizar el sistema mediante visualización y modelado	Proporciona detalles en profundidad sobre cada herramienta y su uso en este escenario.

Información general sobre el escenario

Este escenario describe los episodios de los ciclos de vida del desarrollo de software de dos compañías ficticias: Dinner Now y Lucerne Publishing. Dinner Now ofrece un servicio de reparto de comida a domicilio basado en web, en Seattle. Los clientes pueden encargar comida y pagarla en el sitio web de Dinner Now. A continuación, los pedidos se envían al restaurante adecuado para el reparto. Lucerne Publishing, una compañía de Nueva York, dirige varios negocios dentro y fuera de la Web. Por ejemplo, dirigen un sitio web donde los clientes pueden exponer sus opiniones sobre restaurantes.

Lucerne adquirió recientemente Dinner Now y desea llevar a cabo las siguientes modificaciones:

• Integrar los sitios web agregando la capacidad de opinar sobre los restaurantes a Dinner Now.

• Reemplazar el sistema de pago de Dinner Now por el sistema de Lucerne.

• Expandir el servicio que ofrece Dinner Now a toda la región.

Dinner Now utiliza programación SCRUM y eXtreme. Tienen elevada cobertura de prueba y poco código no compatible. Minimizan los riesgos creando versiones pequeñas pero operativas de un sistema y agregando funcionalidad incrementalmente. Desarrollan el código en iteraciones breves y frecuentes. Esto les permite asumir los cambios con seguridad, refactorizar el código con frecuencia y evitar el "diseño a lo grande para empezar".

Lucerne mantiene una colección inmensamente mayor y compleja de sistemas, algunos de los cuales tienen más de 40 años de antigüedad. Son muy cautos a la hora de realizar modificaciones debido a la complejidad y al alcance del código heredado. Siguen un proceso de desarrollo más riguroso y prefieren diseñar soluciones detalladas y documentar el diseño y los cambios que se producen durante desarrollo.

Ambos equipos utilizan diagramas de modelado de Visual Studio Ultimate como ayuda para el desarrollo de sistemas que satisfagan las necesidades de los usuarios. Utilizan Team Foundation Server junto con otras herramientas para planear, organizar y administrar el trabajo.

Para obtener más información sobre cómo trabajar con Team Foundation Server, vea:

• Planeación y seguimiento del trabajo

• Pruebas, validación y protección del código actualizado

Roles de los diagramas de arquitectura y modelado en el desarrollo de software

En la siguiente tabla se describen los roles que estas herramientas desempeñan durante las distintas y abundantes etapas del ciclo de vida de desarrollo de software:

	Modelado de los requisitos de los usuarios	Modelado del proceso comercial	Arquitectura y diseño del sistema	Visualización y exploración del código	Comprobación
Diagrama de casos de uso (UML)	√	√			√
Diagrama de actividades (UML)	√	√	√		√
Diagrama de clases (UML)	√	√	√		√
Diagrama de componentes (UML)	√	√	√		√
Diagrama de secuencia (UML)	√	√	√		√
Diagrama de Lenguaje específico de dominio (DSL)	√	√	√
Diagrama de capas, validación de capas			√	√	√
Gráfico de dependencias (basado en código)			√	√	√
Diagrama de secuencia (basado en código)				√	√
Diseñador de clases (basado en código)				√
Explorador de arquitectura				√

Para dibujar diagramas UML y diagramas de capas, se debe crear un proyecto de modelado como parte de una solución existente o de una nueva. Estos diagramas se deben crear en el proyecto de modelado. Los elementos de los diagramas UML forman parte de un modelo común y los diagramas UML constituyen vistas de ese modelo. Los elementos de los diagramas de capas se encuentran en el proyecto de modelado, pero no se almacenan en el modelo común. Los gráficos de dependencias basados en código, los diagramas de secuencia y los diagramas de clases normalmente existen fuera del proyecto de modelado.

Vea:

• Crear proyectos y diagramas de modelado UML

• Crear diagramas de capas a partir del código

• Asignar dependencias en el código mediante gráficos de dependencias

• Visualizar el código en diagramas de secuencia

• Cómo: Agregar diagramas de clases a proyectos (Diseñador de clases)

• Modelar el SDK de Visual Studio - Lenguajes específicos de dominio

Para mostrar vistas alternativas de la arquitectura, puede reutilizar algunos elementos del mismo modelo en varios diagramas. Por ejemplo, puede arrastrar un componente a otro diagrama de componentes o a un diagrama de secuencia para que funcione como un actor. Vea Editar modelos y diagramas UML.

Ambos equipos también utilizan la validación de capas para asegurarse de que el código en desarrollo sigue siendo coherente con el diseño.

Vea:

• Mantener la coherencia entre el código y el diseño

• Describir la arquitectura lógica: diagramas de capas

• Validar código con diagramas de capas

  Nota
  Visual Studio Premium admite la validación de capas y las versiones de solo lectura de estos gráficos y diagramas para la visualización y el modelado.

Comprender y comunicar la información sobre el sistema

No hay ningún orden prescrito para utilizar los diagramas de modelado de Visual Studio Ultimate, de modo que puede utilizarlos del modo que se ajuste a sus necesidades o enfoque. Normalmente, los equipos vuelven a los modelos de manera iterativa y con frecuencia a lo largo de un proyecto. Cada diagrama ofrece facetas concretas que ayudan a entender, describir y comunicar aspectos diferentes del sistema que se desarrolla.

Dinner Now y Lucerne se comunican entre sí y con los interesados en el proyecto utilizando los diagramas como lenguaje común. Por ejemplo, Dinner Now usa diagramas para realizar estas tareas:

• Visualizar el código existente.

• Comunicarse con Lucerne sobre artículos de usuarios nuevos o actualizados.

• Identificar los cambios necesarios para admitir casos de usuarios nuevos o actualizados.

Lucerne utiliza los diagramas para estas tareas:

• Conocer el proceso de negocio de Dinner Now.

• Comprender el diseño del sistema.

• Comunicar a Dinner Now requisitos de usuario nuevos o actualizados.

• Actualizar documentos en el sistema.

Los diagramas están integrados en Team Foundation Server para que los equipos puedan planear y administrar su trabajo, y hacer un seguimiento del mismo, con mayor facilidad. Por ejemplo, ambos utilizan modelos para identificar casos de prueba y tareas de desarrollo, así como para estimar el trabajo. Lucerne vincula los elementos de trabajo de Team Foundation Server a elementos de patrón para que puedan supervisar el progreso y asegurar que el sistema cumple los requisitos de los usuarios. Por ejemplo, vinculan los casos de uso a los elementos de trabajo de casos de prueba, de modo que pueden ver que se cumplen los casos de uso cuando se superan todas las pruebas.

Antes de que los equipos protejan los cambios, validan el código con las pruebas y el diseño ejecutando compilaciones que incluyen validación de capas y pruebas automatizadas. Esto ayuda a asegurar que el código actualizado no entra en conflicto con el diseño e interrumpe la funcionalidad previamente establecida.

Vea:

• Comprender el rol del sistema en el proceso de negocio

• Describir requisitos de usuario nuevos o actualizados

• Crear pruebas a partir de modelos

• Identificar cambios en el sistema existente

• Mantener la coherencia entre el código y el diseño

• Sugerencias generales para crear y utilizar modelos

• Planeación y seguimiento del trabajo

• Pruebas, validación y protección del código actualizado

Comprender el rol del sistema en el proceso de negocio

Lucerne desea más información sobre el proceso de negocio de Dinner Now. Crean los siguientes diagramas para profundizar en su comprensión de Dinner Now:

Diagrama	Describe
Diagrama de casos de uso (UML) Vea: Diagramas de casos de uso de UML: Referencia Diagramas de casos de uso de UML: Instrucciones	Las actividades que admite el sistema Dinner Now Las personas y sistemas externos que realizan las actividades Los componentes principales del sistema que mantienen cada actividad Las partes del proceso de negocio que están fuera del ámbito del sistema, por ejemplo, el reparto de comida
Diagrama de actividades (UML) Vea: Diagramas de actividades UML: Referencia Diagramas de actividades UML: Instrucciones	El flujo de los pasos que se producen cuando un cliente crea un pedido
Diagrama de clases (UML) Vea: Diagramas de clases de UML: Referencia Diagramas de clases de UML: Instrucciones	Las entidades y condiciones comerciales que utilizaron en el debate y las relaciones entre esas entidades. Por ejemplo, pedido y plato de la carta o del menú forman parte del vocabulario en este caso.

Por ejemplo, Lucerne crea el siguiente diagrama de casos de uso para entender las tareas que se realizan en el sitio web de Dinner Now y quién las realiza:

Diagrama de casos de uso (UML)

El siguiente diagrama de actividades describe el flujo de pasos cuando un cliente crea un pedido en el sitio web de Dinner Now. En esta versión, los elementos de comentario identifican los roles y las líneas crean calles, que organizan los pasos según el rol:

UML Activity Diagram

El siguiente diagrama de clases describe las entidades que participan en el proceso de los pedidos:

Diagrama de clases de UML

Describir requisitos de usuario nuevos o actualizados

Lucerne desea agregar funcionalidad al sistema de Dinner Now para que los clientes puedan leer y contribuir a las opiniones sobre los restaurantes. Actualizan los siguientes diagramas para que puedan describir y discutir este nuevo requisito con Dinner Now:

Diagrama	Describe
Diagrama de casos de uso (UML) Vea: Diagramas de casos de uso de UML: Referencia Diagramas de casos de uso de UML: Instrucciones	Un nuevo caso de uso para "Escribir una crítica sobre el restaurante"
Diagrama de actividades (UML) Vea: Diagramas de actividades UML: Referencia Diagramas de actividades UML: Instrucciones	Pasos que se tienen lugar cuando un cliente desea escribir una crítica de un restaurante
Diagrama de clases (UML) Vea: Diagramas de clases de UML: Referencia Diagramas de clases de UML: Instrucciones	Datos que se exigen para guardar una crítica

Por ejemplo, el siguiente diagrama de casos de uso incluye un nuevo caso de uso "Escribir crítica", que representa el nuevo requisito. Se resalta en naranja en el diagrama para facilitar la identificación:

Diagrama de casos de uso de UML

El siguiente diagrama de actividades incluye en naranja los nuevos elementos que describen el flujo de pasos del nuevo caso de uso:

Diagrama de actividades de UML

El siguiente diagrama de clases incluye una nueva clase Review y sus relaciones con otras clases para que los equipos puedan discutir sus detalles. Observe que un cliente y un restaurante pueden tener varias críticas (reviews):

Diagrama de clases de UML

Crear pruebas a partir de modelos

Ambos equipos están de acuerdo en que necesitan un conjunto completo de pruebas para el sistema y sus componentes antes de llevar a cabo cualquier modificación. Lucerne tiene un equipo especializado que realiza pruebas en el nivel de componentes y del sistema. Reutilizan las pruebas creadas por Dinner Now y las estructuran mediante los diagramas de UML:

• Una o varias pruebas representan uno o varios casos de uso. Los elementos del diagrama de casos de uso se vinculan a los elementos de trabajo de casos de prueba en Team Foundation Server.

• Cada flujo de un diagrama de actividades o de un diagrama de secuencias de nivel del sistema se vincula, como mínimo, a una prueba. El equipo de pruebas se asegura sistemáticamente de que prueban cada ruta de acceso posible a través del diagrama de actividades.

• Las condiciones utilizadas para describir las pruebas están basadas en las condiciones definidas por diagramas de caso de uso, de clases y de actividades.

Cuando los requisitos cambian y los diagramas se actualizan para reflejarlos, las pruebas también se actualizan. Un requisito se considera cumplido solo cuando se superan las pruebas. Cuando es posible o práctico, las pruebas se definen y se basan en diagramas UML antes de que comience la implementación.

Vea:

• Desarrollar pruebas en un modelo

• Validar un modelo UML

Identificar cambios en el sistema existente

Dinner Now debe estimar el costo de cumplir el nuevo requisito. Esto depende en parte de cuánto afectará este cambio a otras partes del sistema. Para ayudar a explicar esto, uno de los desarrolladores de Dinner Now crea los gráficos y diagramas siguientes a partir del código existente:

Gráfico o diagrama	Muestra
Gráfico de dependencias Vea: Asignar dependencias en el código mediante gráficos de dependencias Examinar y reorganizar gráficos de dependencias Editar y personalizar gráficos de dependencias Buscar código con el explorador de arquitectura	Dependencias y otras relaciones en el código. Por ejemplo, Dinner Now podría comenzar revisando los gráficos de dependencias de los ensamblados para dar una información general de los ensamblados y sus dependencias. Pueden detallar los gráficos para explorar los espacios de nombres y las clases de esos ensamblados. Dinner Now también puede crear gráficos para explorar áreas determinadas y otros tipos de relaciones existentes en el código. Usan el Explorador de arquitectura o de soluciones como ayuda para buscar y seleccionar las áreas y las relaciones que les interesan.
Diagrama de secuencia basado en código Vea Visualizar el código en diagramas de secuencia.	La secuencia de interacciones entre las instancias. Los diagramas de secuencia se generan a partir de las definiciones de los métodos y son útiles para entender la forma en que el código implementa el comportamiento de los métodos.
Diagrama de clases basado en código Vea Cómo: Agregar diagramas de clases a proyectos (Diseñador de clases).	Clases existentes en código

Por ejemplo, el desarrollador utiliza el Explorador de arquitectura para seleccionar los espacios de nombres en los que desea centrarse y crea un gráfico de dependencias a partir del código. Ajusta el ámbito para centrarse en las áreas que se verán afectadas por el nuevo escenario. Estas áreas están seleccionadas y resaltadas en el gráfico:

Gráfico de dependencias de espacios de nombres

La desarrolladora de software expande los espacios de nombres seleccionados para ver sus clases, métodos y relaciones:

Gráfico de dependencias de espacios de nombres expandido con vínculos entre grupos visibles

La desarrolladora de software examina el código para buscar las clases y métodos afectados. Genera diagramas de la secuencia y diagramas de clases a partir del código para describir y comentar los cambios. Vea Visualizar el código.

Sugerencia
Para ver los efectos de los cambios a medida que se realizan, regenere el gráfico y los diagramas de secuencia desde el código después de cada cambio.

Para describir cambios efectuados en otras partes del sistema, como componentes o interacciones, el equipo puede dibujar estos elementos en pizarras. También podrían dibujar los siguientes diagramas en Visual Studio para capturar los detalles, administrarlos y comprenderlos:

Diagramas	Describe
Diagrama de actividades (UML) Vea: Diagramas de actividades UML: Referencia Diagramas de actividades UML: Instrucciones	El flujo de pasos que se producen cuando el sistema observa que un cliente hace de nuevo un pedido desde un restaurante, y le solicita que escriba una crítica.
Diagrama de clases (UML) Vea: Diagramas de clases de UML: Referencia Diagramas de clases de UML: Instrucciones	Clases lógicas y sus relaciones. Por ejemplo, se agrega una nueva clase para describir una Crítica y sus relaciones con otras entidades, como Restaurante, Menú y Cliente. Para asociar críticas con un cliente, el sistema debe almacenar los datos del cliente. Un diagrama de clases de UML puede ayudar a clarificar esos detalles.
Diagrama de clases basado en código Vea Cómo: Agregar diagramas de clases a proyectos (Diseñador de clases).	Clases existentes en código.
Diagrama de componentes (UML) Vea: Diagramas de componentes de UML: Referencia Diagramas de componentes de UML: Instrucciones	Las partes de alto nivel del sistema, como el sitio web Dinner Now y sus interfaces. Estas interfaces definen cómo los componentes interactúan entre sí a través de los métodos o servicios que ofrecen y consumen.
Diagrama de secuencia (UML) Vea: Diagramas de secuencia UML: Referencia Diagramas de secuencia de UML: Instrucciones	La secuencia de interacciones entre las instancias.

Por ejemplo, el siguiente diagrama de componentes muestra el nuevo componente, que es parte del componente sitio web Dinner Now. El componente ReviewProcessing controla la funcionalidad de crear las críticas (reviews) y aparece resaltado en naranja:

Diagrama de componentes de UML

El siguiente diagrama de secuencia muestra la secuencia de interacciones que se producen cuando el sitio web Dinner Now comprueba si el cliente ha hecho algún pedido anteriormente. Si es así, se pide al cliente que cree una crítica, que se envía al restaurante y se publica en el sitio web:

Diagrama de secuencia de UML

Mantener la coherencia entre el código y el diseño

Dinner Now debe asegurar que el código actualizado mantenga la coherencia con el diseño. Crean diagramas de capas que describen las capas de funcionalidad del sistema, especifican las dependencias permitidas y asocian los artefactos de la solución a estas capas.

Diagrama

Describe

Diagrama de capas Vea: Crear diagramas de capas a partir del código Diagramas de capas: Referencia Diagrama de capas: Instrucciones Validar código con diagramas de capas

La arquitectura lógica del código. Un diagrama de capas organiza y asigna los artefactos de una solución de Visual Studio a grupos abstractos denominados capas. Estos niveles identifican los roles, las tareas o las funciones que realizan estos artefactos en el sistema. Los diagramas de capas son útiles para describir el diseño intencional del sistema y validar el código que evoluciona en función del diseño. Para crear las capas, arrastre los elementos del Explorador de soluciones, los gráficos de dependencia o el Explorador de arquitectura. Para dibujar nuevas capas, use el cuadro de herramientas o haga clic con el botón secundario en la superficie de diagrama. Para ver las dependencias existentes, haga clic con el botón secundario en la superficie del diagrama de capas y, a continuación, haga clic en Generar dependencias. Para especificar dependencias concretas, dibuje nuevas dependencias.

Por ejemplo, el siguiente diagrama de capas describe las dependencias entre las capas y el número de artefactos asociadas a cada capa:

Diagrama de capas

Para asegurar que no se produzcan conflictos con el diseño durante el desarrollo del código, los equipos utilizan capas de validación en las compilaciones que se ejecutan en Team Foundation Build. También crean una tarea MSBuild personalizada para exigir la validación de capas en las operaciones de protección del código. Utilizan informes de compilación para recopilar errores de validación.

Vea:

• Definir el proceso de compilación

• Utilizar un proceso de compilación de protección controlada para validar cambios

• Personalizar la plantilla de proceso de compilación

Sugerencias generales para crear y utilizar modelos

• La mayoría de los diagramas se componen de nodos conectados por líneas. Para cada tipo de diagrama, el cuadro de herramientas proporciona tipos diferentes de nodos y líneas.

  Para abrir el cuadro de herramientas, en el menú Vista, haga clic en Cuadro de herramientas.

• Para crear un nodo, arrástrelo al cuadro de herramientas hacia el diagrama. Algunos tipos de nodos se deben arrastrar a los nodos existentes. Por ejemplo, en un diagrama de componentes, se debe agregar un nuevo puerto a un componente existente.

• Para crear una línea o una conexión, haga clic en la herramienta adecuada en el cuadro de herramientas, haga clic en el nodo de origen y, a continuación, en el de destino. Algunas líneas solo se pueden crear entre ciertos tipos de nodos. Cuando se mueve sobre un posible origen o destino, el puntero indica si es posible crear una conexión.

• Cuando se crean elementos en diagramas de UML, también se agregan a un modelo común. Los diagramas de UML de un proyecto de modelado son vistas de dicho modelo. Los elementos de un diagrama de capas forman parte del proyecto de modelado, aunque no están almacenados en el modelo común.

  Para ver el patrón, en el menú Arquitectura, elija Windows y, a continuación, haga clic en Explorador de modelos UML.

• En algunos casos, puede arrastrar algunos elementos del Explorador de modelos UML a un diagrama de UML. Algunos elementos del mismo modelo se pueden utilizar en diagramas diferentes para mostrar vistas diferentes de la arquitectura. Por ejemplo, puede arrastrar un componente a otro diagrama de componentes o a un diagrama de secuencia para usarlo como un actor.

• Visual Studio Ultimate es compatible con UML 2.1.2. Esta información únicamente describe las características principales de los diagramas de UML de esta versión, pero hay muchos libros que abordan su naturaleza y su uso en detalle.

Vea Desarrollar modelos para el diseño de software.

Planeación y seguimiento del trabajo

Los diagramas de modelado de Visual Studio Ultimate se integran con Team Foundation Server de manera que puede planear, administrar y realizar un seguimiento del trabajo con mayor facilidad. Ambos equipos utilizan modelos para identificar casos de prueba y tareas de desarrollo, así como para estimar el trabajo. Lucerne crea y vincula los elementos de trabajo de Team Foundation Server a elementos de modelos, como casos de uso o componentes. Esto les sirve para supervisar el progreso y hacer seguimiento del trabajo hasta llegar a los requisitos de los usuarios. Así se aseguran de que los cambios que efectúan continúan cumpliendo esos requisitos.

A medida que su trabajo progresa, los equipos actualizan los elementos de trabajo para reflejar el tiempo que dedicaron a las tareas. También supervisan e informan sobre su avance en el trabajo utilizando las siguientes características Team Foundation Server:

• informes de evolución diarios que muestran si se completará el trabajo planeado en el tiempo esperado. Generan otros informes similares con Team Foundation Server para llevar el seguimiento del progreso de los errores.

• Una hoja de cálculo de iteración que utiliza Microsoft Excel como ayuda para que el equipo supervise y equilibre la carga de trabajo entre los integrantes. Esta hoja de cálculo se vincula a Team Foundation Server y constituye el foco del debate durante las reuniones de progreso rutinarias.

• Un panel de desarrollo que utiliza Office Project para mantener el equipo al tanto de la información importante del proyecto.

Vea:

• Realizar un seguimiento del trabajo con Visual Studio ALM y TFS

• Realizar un seguimiento del trabajo y administrar el flujo de trabajo [redirigido]

• Vincular elementos de modelo con elementos de trabajo

• Crear, personalizar y administrar informes de Visual Studio ALM

• Crear un registro de trabajo pendiente y tareas mediante Project

Probar, validar y proteger código

A medida que los equipos completan cada tarea, protegen el código del control de versiones de Team Foundation y reciben avisos de Team Foundation Server si se olvidan. Antes de que Team Foundation Server acepte los archivos para su protección, los equipos de desarrollo ejecutan pruebas unitarias y validación de capas para comprobar el código con relación a los casos de prueba y el diseño. Utilizan Team Foundation Server para ejecutar compilaciones, pruebas unitarias automatizadas y validación de capas con regularidad. Así se aseguran de que el código cumple los siguientes criterios:

• Funciona.

• No interrumpe código ya en funcionamiento.

• No entra en conflicto con el diseño.

Dinner Now cuenta con una gran colección de pruebas automatizadas que Lucerne puede reutilizar porque prácticamente todas siguen estando en vigor. Lucerne también puede compilar en estas pruebas y agregar nuevas que cubran nueva funcionalidad. Ambos también utilizan Visual Studio Ultimate para ejecutar pruebas manuales.

Para asegurarse de que el código es conforme al diseño, los equipos configuran las compilaciones en Team Foundation Build para incluir la validación de capas. Si se produce algún conflicto, se generará un informe con los detalles.

Vea:

• Probar la aplicación

• Validar el sistema durante el desarrollo

• Usar el control de versiones

• Compilar la aplicación

Actualizar el sistema mediante visualización y modelado

Lucerne y Dinner Now deben integrar los sistemas de pago. En las siguientes secciones se muestran los diagramas de modelado de Visual Studio Ultimate que les ayudan a realizar esta tarea:

• Comprender los requisitos de los usuarios: diagramas de casos de uso

• Comprender el proceso comercial: diagramas de actividades

• Describir la estructura del sistema: diagramas de componentes

• Describir las interacciones: diagramas de secuencia

• Visualizar el código existente: gráficos de dependencias

• Definir un glosario de tipos: diagramas de clases

• Describir la arquitectura lógica: diagramas de capas

Vea:

• Desarrollar modelos para el diseño de software

• Visualizar el código

• Uso de modelos dentro del proceso de desarrollo

• Crear modelos de los requisitos de los usuarios

• Modelar la arquitectura de un sistema de Software

Comprender los requisitos de los usuarios: diagramas de casos de uso

Los diagramas de casos de uso resumen las actividades que admite un sistema y quién las realiza. Lucerne utiliza estos diagramas de casos de uso para obtener la siguiente información sobre Dinner Now:

• Los clientes crean los pedidos.

• Los restaurantes los reciben.

• La puerta de enlace del procesador de pagos externo, que utiliza el sistema de pago de Dinner Now para validar los pagos, está fuera del ámbito del sitio web.

El diagrama también muestra la forma en que algunos de los casos de uso mayores se dividen en casos de uso menores. Lucerne desea utilizar su sistema de pago propio. Resaltan el caso de uso del proceso de pago en un color diferente para indicar que requiere cambios:

Resaltar el proceso de pago en el diagrama de casos de uso

Si el tiempo de desarrollo fuera corto, el equipo podría debatir si permitir que los clientes paguen directamente a los restaurantes. Para mostrarlo, reemplazarían el caso de uso Proceso de pago por otro que está fuera de los límites del sistema de Dinner Now. A continuación, vincularían directamente el cliente con el restaurante, lo que sería indicación de que solo Dinner Now procesaría los pedidos:

Reajuste del pago al restaurante en el diagrama de casos de uso

Vea:

• Diagramas de casos de uso de UML: Referencia

• Diagramas de casos de uso de UML: Instrucciones

Dibujar diagramas de casos de uso

Un diagrama de casos de uso tiene las siguientes características principales:

• Actores representan roles que representan personas, organizaciones, equipos o sistemas de software. Por ejemplo, el cliente, el restaurante, el sistema de pago de Dinner Now son actores.

• Los casos de uso representan las interacciones entre los actores y el sistema en desarrollo. Pueden representar cualquier escala de interacción, desde un clic del mouse único o un mensaje hasta una transacción que abarca muchos días.

• Las asociaciones vinculan los actores con los casos de uso.

• Un caso de uso mayor puede incluir otros menores, por ejemplo, Crear pedidos incluye Seleccionar restaurante. Puede extender un caso de uso, que agrega objetivos y pasos al caso de uso extendido, para indicar que el caso de uso solo se produce en ciertas condiciones. Los casos de uso también pueden heredar unos de otros.

• Un subsistema representa el sistema de software que está en desarrollo o alguno de sus componentes. Es un cuadro grande que contiene los casos de uso. Un diagrama de casos de uso clarifica lo que entra dentro o sale del límite del subsistema. Para indicar que el usuario debe lograr algunos objetivos de otras maneras, dibuje esos casos de uso fuera del límite del subsistema.

• Los artefactos vinculan los elementos del diagrama con otros diagramas o documentos.

Vea:

• Diagramas de casos de uso de UML: Referencia

• Diagramas de casos de uso de UML: Instrucciones

Resumen: Ventajas de los diagramas de casos de uso

Los diagramas de casos de uso ayudan a visualizar:

• Las actividades que un sistema admite o no admite

• Las personas y los sistemas externos que realizan dichas actividades

• Los principales componentes del sistema que admiten cada actividad, que se pueden representar como subsistemas anidados dentro del sistema primario

• Cómo dividir un caso de uso en otros menores o en variaciones

Relación con otros diagramas

Diagrama	Describe
Diagrama de actividades	El flujo de pasos de un caso de uso y las personas que los ejecutan en ese caso de uso. Es frecuente que los nombres de los casos de uso sean el reflejo de los pasos de un diagrama de actividades. Los diagramas de actividades admiten elementos como decisiones, combinaciones, entradas y salidas, flujos simultáneos, etc. Vea: Diagramas de actividades UML: Referencia Diagramas de actividades UML: Instrucciones
Diagrama de secuencia	La secuencia de interacciones entre los participantes en un caso de uso. Vea: Diagramas de secuencia UML: Referencia Diagramas de secuencia de UML: Instrucciones
Diagrama de clases (UML)	Las entidades o tipos que participan en el caso de uso. Vea: Diagramas de clases de UML: Referencia Diagramas de clases de UML: Instrucciones

Comprender el proceso comercial: diagramas de actividades

Los diagramas de actividades describen el flujo de pasos en un proceso de negocio y constituyen una manera sencilla de comunicar el flujo de trabajo. Un proyecto de desarrollo puede tener varios diagramas de actividades. Normalmente, una actividad abarca todas las acciones que son el resultado de una acción externa, como encargar una comida, actualizar un menú o agregar un nuevo restaurante al negocio. Una actividad también podría describir los detalles de una acción compleja.

Lucerne actualiza el siguiente diagrama de actividades para mostrar que procesa el pago y que paga al restaurante. Reemplazan el Sistema de pago de Dinner Now por el Sistema de pago de Lucerne, como se resalta:

Reemplazo del sistema de pago de Dinner Now en el diagrama de actividades

El diagrama actualizado ayuda a Lucerne y a Dinner Now a visualizar dónde encaja el sistema de pago de Lucerne en el proceso de negocio. En esta versión, los comentarios se utilizan para identificar los roles que ejecutan los pasos. Las líneas se utilizan para crear calles, que organizan los pasos que da el rol.

Los equipos también podrían considerar una situación alternativa en la que el cliente paga al restaurante una vez recibido el pedido. Esto plantearía requisitos diferentes para el sistema de software.

Previamente, Dinner Now dibuja los diagramas en una pizarra o en PowerPoint. Ahora también utilizan Visual Studio Ultimate para dibujar los diagramas de forma que ambos equipos puedan capturar, entender y controlar los detalles.

Vea:

• Diagramas de actividades UML: Referencia

• Diagramas de actividades UML: Instrucciones

Dibujar un diagrama de actividades

Los diagramas de actividades tiene las siguientes características principales:

• Un nodo inicial que indica la primera acción de la actividad.

  El diagrama siempre debe tener uno de estos nodos.

• Acciones que describen los pasos donde el usuario o el software realiza una tarea.

• Flujos de control que muestran el flujo entre las acciones.

• Nodos de decisión que representan las bifurcaciones condicionales en el flujo.

• Nodos de bifurcación (Fork node) que dividen flujos únicos en flujos simultáneos.

• Nodos finales de la actividad que muestran los fines de la actividad.

  Aunque estos nodos son opcionales, es útil incluirlos en el diagrama para mostrar el punto en que la actividad finaliza.

Vea:

• Diagramas de actividades UML: Referencia

• Diagramas de actividades UML: Instrucciones

Resumen: Ventajas de los diagramas de actividades

Los diagramas de actividades ayudan a visualizar y describir el flujo de control e información entre las acciones de una actividad comercial, sistema o programa. Esta es una manera simple y útil de describir el flujo de trabajo al comunicarse con otras personas.

Relación con otros diagramas

Diagrama	Descripción
Diagrama de casos de uso	Resume las actividades que realiza cada actor. Vea: Diagramas de casos de uso de UML: Referencia Diagramas de casos de uso de UML: Instrucciones
Diagrama de componentes	Visualice el sistema como una colección de partes reutilizables que proporcionan o consumen comportamiento a través de un conjunto de interfaces bien definidas. Vea: Diagramas de componentes de UML: Referencia Diagramas de componentes de UML: Instrucciones

Describir la estructura del sistema: diagramas de componentes

Los diagramas de componentes describen un sistema como una colección de partes separables, que proporcionan o consumen el comportamiento a través de un conjunto bien determinado de interfaces. Las partes pueden tener cualquier tamaño y pueden conectarse de cualquier manera.

Para ayudar a Lucerne y a Dinner Now a visualizar los componentes del sistema y las interfaces, crean los siguientes diagramas de componentes:

Componentes del sistema de pago de Dinner Now

Este diagrama muestra diferentes tipos de componentes y sus dependencias. Por ejemplo, tanto el sitio web de Dinner Now como el sistema de pago de Lucerne exigen puerta de enlace de proceso de pago externo para validar los pagos. Las flechas entre los componentes representan las dependencias que indican qué componentes requieren la funcionalidad de otros componentes.

Para utilizar el Sistema de pago de Lucerne, el sitio web Dinner Now debe actualizarse para el uso de las interfaces PaymentApproval Payable Insertion y PaymentApproval en el Sistema de pago de Lucerne.

En el siguiente diagrama se muestra una configuración concreta de componentes para el sitio web de Dinner Now. Esta configuración indica que cualquier instancia del sitio web se compone de cuatro partes:

• CustomerProcessing

• OrderProcessing

• ReviewProcessing

• PaymentProcessing

Estas partes son instancias de los tipos de componente especificados y están conectadas como sigue:

Componentes dentro del sitio web de Dinner Now

El sitio web Dinner Now delega su comportamiento a estas partes, que controlan las funciones del sitio web. Las flechas entre el componente principal y sus componentes miembros muestran delegaciones que indican qué partes controlan los mensajes que el elemento principal recibe o envía a través de sus interfaces.

En esta configuración, el componente PaymentProcessing procesa los pagos de los clientes. Por consiguiente, debe estar actualizado para integrarse con el sistema del pago de Lucerne. En otros escenarios, varias instancias de un tipo de componente pueden existir en el mismo componente principal.

Vea:

• Diagramas de componentes de UML: Referencia

• Diagramas de componentes de UML: Instrucciones

Dibujar un diagrama de componentes

Un diagrama de componentes tiene las siguientes características principales:

• Componentes, que representan partes separables de la funcionalidad del sistema.

• Puertos de interfaz, que representan grupos de mensajes o de llamadas que los componentes implementan y que otros componentes o sistemas externos utilizan.

• Puertos de interfaz requeridos, que representan grupos de mensajes o llamadas que los componentes envían a otros componentes o sistemas externos. Este tipo de puerto describe las operaciones que un componente espera por lo menos de otros componentes o sistemas externos.

• Las partes son miembros de componentes y son, por lo general, instancias de otros componentes. Una parte es una pieza del diseño interno de su componente primario.

• Dependencias, que indican que los componentes requieren la funcionalidad de otros componentes.

• Delegaciones, que indican partes de un controlador de componentes los mensajes enviados o recibidos por el componente primario.

Vea:

• Diagramas de componentes de UML: Referencia

• Diagramas de componentes de UML: Instrucciones

Resumen: Ventajas de los diagramas de componentes

Los diagramas de componentes ayudan a visualizar:

• El sistema como una colección de partes separables sin tener en cuenta el lenguaje de implementación o el estilo.

• Componentes con interfaces bien determinadas, que facilitan el diseño para entender y actualizar cuando los requisitos cambian.

Relación con otros diagramas

Diagrama	Descripción
Gráfico de dependencias	Visualice la organización y las relaciones del código. Para identificar candidatos para los componentes, cree un gráfico de dependencias y agrupe los elementos según su función en el sistema. Vea: Asignar dependencias en el código mediante gráficos de dependencias Editar y personalizar gráficos de dependencias
Diagrama de secuencia	Visualice la secuencia de interacciones entre los componentes o las partes en el interior de un componente. Para crear una línea de la vida en un diagrama de secuencia a partir de un componente, haga clic con el botón secundario en el componente y, a continuación, haga clic en Crear línea de vida. Vea: Diagramas de secuencia UML: Referencia Diagramas de secuencia de UML: Instrucciones
Diagrama de clases (UML)	Defina las interfaces en los puertos proporcionados o requeridos y las clases que implementan la funcionalidad de los componentes. Vea: Diagramas de clases de UML: Referencia Diagramas de clases de UML: Instrucciones
Diagrama de capas	Describa la arquitectura lógica del sistema en lo referente a los componentes. Use la validación de capas para asegurarse de que el código sigue siendo coherente con el diseño. Vea: Crear diagramas de capas a partir del código Diagramas de capas: Referencia Diagrama de capas: Instrucciones Validar código con diagramas de capas
Diagrama de actividades	Visualice el procesamiento interno que ejecutan los componentes en respuesta a los mensajes entrantes. Vea: Diagramas de actividades UML: Referencia Diagramas de actividades UML: Instrucciones

Visualizar el código existente: gráficos de dependencias

Los gráficos de dependencias muestran la organización y relaciones existentes en el código. Los elementos se representan como nodos en el gráfico y las relaciones como vínculos. Los gráficos de dependencias pueden ayudar con los siguientes tipos de tareas:

• Explorar código poco conocido.

• Comprender dónde y cómo un cambio propuesto puede afectar al código existente.

• Encontrar áreas de complejidad, capas o modelos naturales u otras áreas que se beneficiarían con la mejora.

Por ejemplo, Dinner Now debe calcular el costo de actualizar el componente PaymentProcessing. Esto depende en parte de cuánto afectará este cambio a otras partes del sistema. Para favorecer la comprensión de esto, uno de los desarrolladores de Dinner Now genera gráficos de la dependencia del código y ajusta el foco del ámbito a las áreas que se podrían ver afectadas por el cambio.

El siguiente gráfico muestra las dependencias entre la clase PaymentProcessing y otras partes del sistema de Dinner Now que aparecen seleccionadas:

Gráfico de dependencias del sistema de pago de Dinner Now

El desarrollador explora el gráfico expandiendo la clase PaymentProcessing y seleccionando sus miembros para ver las áreas potencialmente afectadas:

Métodos de la clase PaymentProcessing y sus dependencias

Generan el siguiente gráfico para que el sistema de pago de Lucerne inspeccione las clases, métodos y dependencias. El equipo comprende que también será necesario algún trabajo para hacer que el sistema de Lucerne interactúe con otras partes de Dinner Now:

Gráfico de dependencias del sistema de pago de Lucerne

Ambos equipos colaboran para determinar los cambios necesarios para integrar los dos sistemas. Deciden refactorizar parte del código para que sea más fácil la actualización. La clase PaymentApprover pasará al espacio de nombres DinnerNow.Business y requerirá algunos métodos nuevos. Las clases Dinner Now que controlan las transacciones tendrán su propio espacio de nombres. Los equipos crean y utilizan los elementos de trabajo para planear, organizan y hacer seguimiento del trabajo. Vinculan elementos de trabajo a elementos del modelo donde es útil.

Después de reorganizar el código, los equipos generan un nuevo gráfico de dependencias para ver la estructura y las relaciones actualizadas:

Gráfico de dependencias con código reorganizado

Este gráfico muestra que la clase PaymentApprover está ahora en el espacio de nombres DinnerNow.Business y tiene nuevos métodos. Las clases de transacción de Dinner Now tienen su propio espacio de nombres PaymentSystem, lo que facilita controlar ese código más adelante.

Crear un gráfico de dependencias

• Para obtener información general rápida del código fuente, siga estos pasos y genere un gráfico de dependencias:

  En el menú Arquitectura, elija Generate Dependency Graph (Generar gráfico de dependencias) y, a continuación, haga clic en Para la solución.

  Para obtener información general rápida del código compilado, cree un gráfico de dependencias en blanco y, a continuación, arrastre archivos de ensamblado o archivos binarios hasta la superficie del gráfico.

  Vea Asignar dependencias en el código mediante gráficos de dependencias.

• Para explorar código o elementos de solución concretos, use el Explorador de soluciones o de arquitecturas para seleccionar los elementos y las relaciones que desea visualizar. Puede generar un nuevo gráfico o agregar los elementos seleccionados a un gráfico existente.

  Vea Asignar dependencias en el código mediante gráficos de dependencias y Buscar código con el explorador de arquitectura.

• Como ayuda para explorar el gráfico, reorganice el diseño de forma que satisfaga los tipos de tareas que desea realizar.

  Por ejemplo, para visualizar las capas de código, seleccione un diseño de árbol. Vea Examinar y reorganizar gráficos de dependencias.

• Si desea centrarse en áreas concretas del gráfico, ajuste el ámbito dejando fuera elementos o personalizando su aspecto. Vea Editar y personalizar gráficos de dependencias.

Resumen: Ventajas de los gráficos de dependencias

Los gráficos de dependencias sirven para:

• Obtener información sobre la organización y las relaciones del código existente.

• Identificar áreas a las que podrían afectar un cambio propuesto.

• Encontrar áreas de complejidad, modelos, niveles u otras que se podrían mejorar para que sea más fácil mantener, cambiar y reutilizar el código.

Relación con otros diagramas

Diagrama	Describe
Diagrama de capas	La arquitectura lógica del sistema. Use la validación de capas para asegurarse de que el código sigue siendo coherente con el diseño. Para ayudar a identificar capas existentes o intencionales, cree un gráfico de dependencias y agrupe los elementos relacionados. Para crear un diagrama de capas, arrastre los elementos desde el gráfico o desde el Explorador de arquitectura. Vea: Crear diagramas de capas a partir del código Diagramas de capas: Referencia Diagrama de capas: Instrucciones Validar código con diagramas de capas
Diagrama de componentes	Los componentes, sus interfaces y sus relaciones. Para identificar los componentes, cree un gráfico de dependencias y agrupe los elementos según su función en el sistema. Vea: Diagramas de componentes de UML: Referencia Diagramas de componentes de UML: Instrucciones
Diagrama de clases (UML)	Las clases, sus atributos y operaciones, y sus relaciones. Para ayudarle a identificar estos elementos, cree un documento de gráfico para mostrarlos. Vea: Diagramas de clases de UML: Referencia Diagramas de clases de UML: Instrucciones
Diagrama de clases (basado en código)	Clases existentes en código. Para visualizar y modificar una clase existente en código, utilice el Diseñador de clases. Vea Cómo: Agregar diagramas de clases a proyectos (Diseñador de clases).

Describir las interacciones: diagramas de secuencia

Los diagramas de secuencia describen una serie de interacciones entre las partes de un sistema. Las partes pueden ser de cualquier escala. Por ejemplo, pueden abarcar desde objetos individuales en un programa hasta subsistemas grandes o actores externos. Las interacciones pueden ser de cualquier escala y tipo. Por ejemplo, pueden ir desde mensajes individuales hasta transacciones extendidas, y pueden ser llamadas a funciones o mensajes de servicios Web.

Para ayudar a Lucerne y a Dinner Now a describir y debatir los pasos en el caso de uso Proceso de pago, crean el siguiente diagrama de secuencia a partir del diagrama de componentes. Las líneas de vida reflejan el componente Sitio web de Dinner Now y sus partes. Los mensajes que aparecen entre las líneas de vida siguen las conexiones en los diagramas de componentes:

Diagrama de secuencia para el caso de uso Proceso Pago

El diagrama de secuencia muestra que cuando el cliente hace un pedido, el sitio web Dinner Now llama a ProcessOrder en una instancia de OrderProcessing. Luego, OrderProcessing llama a ProcessPayment en PaymentProcessing. Esto continúa hasta que la puerta de enlace del procesador de pagos externo valide el pago. Solo después el control vuelve al sitio web de Dinner Now.

Lucerne debe estimar el costo de actualizar el sistema de pago para integrarse con el sistema de Dinner Now. Para ayudarles a comprenderlo, uno de los desarrolladores genera los diagramas de secuencia del código para visualizar las interacciones existentes.

Vea:

• Diagramas de secuencia UML: Referencia

• Diagramas de secuencia de UML: Instrucciones

• Visualizar el código en diagramas de secuencia

Dibujar un diagrama de secuencia

Un diagrama de secuencia tiene las siguientes características principales:

• Las líneas de vida verticales representan actores o instancias de objetos de software.

  Para agregar un símbolo de actor, que indica que un participante está fuera del sistema que se está desarrollando, haga clic en la línea de la vida. En la ventana Propiedades, establezca el campo Actor en True. Si no se muestra la ventana Propiedades, presione F4.

• Los mensajes horizontales representan llamadas a métodos, mensajes del servicio Web o alguna otra comunicación. Las apariciones de ejecución son rectángulos sombreados verticales que aparecen en las líneas de la vida y representan los períodos en que llama el proceso de recepción de llamadas.

• Durante un mensaje sincrónico, el objeto de remitente espera a que el control vuelva (<<volver>>) como en una llamada a función normal. Durante un mensaje asincrónico, el remitente puede continuar inmediatamente.

• Utilice <<crear>> mensajes para indicar la construcción de objetos a través de otros objetos. Debería ser el primer mensaje enviado al objeto.

Vea:

• Diagramas de secuencia UML: Referencia

• Diagramas de secuencia de UML: Instrucciones

Resumen: Ventajas de los diagramas de secuencia

Los diagramas de secuencia ayudan a visualizar:

• El flujo del control que se transfiere entre actores u objetos durante la ejecución de un caso de uso.

• La implementación de un mensaje o una llamada a método.

Relación con otros diagramas

Diagrama	Descripción
Diagrama de clases (UML)	Defina las clases que las líneas de vida representan y los parámetros y valores devueltos que se utilizan en mensajes enviados entre las líneas de vida. Para crear una clase a partir de una línea de vida, haga clic con el botón secundario en la línea de vida y, a continuación, haga clic en Crear clase o Crear interfaz. Para crear una línea de vida a partir de un tipo en un diagrama de clases, haga clic con el botón secundario en la línea de vida y, a continuación, haga clic en Crear línea de vida. Vea: Diagramas de clases de UML: Referencia Diagramas de clases de UML: Instrucciones
Diagrama de componentes	Describa los componentes que representan las líneas de vida y las interfaces que proporcionan y consumen el comportamiento representado por los mensajes. Para crear una línea de vida de un diagrama de componentes, haga clic con el botón secundario en el componente y, a continuación, haga clic en Crear línea de vida. Vea: Diagramas de componentes de UML: Referencia Diagramas de componentes de UML: Instrucciones
Diagrama de casos de uso	Resuma las interacciones entre los usuarios y los componentes en un diagrama de secuencia como un caso de uso que representa el objetivo de un usuario. Vea: Diagramas de casos de uso de UML: Referencia Diagramas de casos de uso de UML: Instrucciones

Definir un glosario de tipos: diagramas de clases

Los diagramas de clases definen las entidades, las condiciones o los conceptos que participan en el sistema y las relaciones entre ellos. Por ejemplo, puede utilizar estos diagramas durante la fase de desarrollo para describir los atributos y las operaciones para cada clase, sin tener en cuenta el lenguaje de implementación o el estilo.

Para ayudar a Lucerne a describir y discutir las entidades que participan en el caso de uso Proceso de pago, dibujan el siguiente diagrama de clases:

Entidades del proceso de pago en un diagrama de clases

Este diagrama muestra que un Cliente puede tener muchos pedidos y diferentes maneras de pagarlos. Tanto BankAccount como CreditCard heredan de Payment.

Durante el desarrollo, Lucerne utiliza el siguiente diagrama de clases para describir y debatir los detalles de cada clase:

Detalles del proceso de pago en el diagrama de clases

Vea:

• Diagramas de clases de UML: Referencia

• Diagramas de clases de UML: Instrucciones

Dibujar un diagrama de clases de UML

Un diagrama de clases tiene las siguientes características principales:

• Tipos como clases, interfaces y enumeraciones:

  • Una clase es la definición de los objetos que comparten características estructurales y de comportamiento concretas.

  • Una interfaz define parte del comportamiento de un objeto que puede observarse desde el exterior.

  • Una enumeración es un clasificador que contiene una lista de valores literales.

• Los atributos son valores de cierto tipo que describen cada instancia de un clasificador. Un clasificador es un nombre general para los tipos, componentes, casos de uso, e incluso actores.

• Las operaciones son métodos o funciones que las instancias de un clasificador pueden efectuar.

• Una asociación indica un tipo de relación entre dos clasificadores.

  • Una agregación es una asociación que indica una propiedad compartida entre los clasificadores.

  • Una composición es una asociación que indica una relación todo-parte entre los clasificadores.

  Para mostrar agregaciones o composiciones, establezca la propiedad Aggregation en una asociación. Shared muestra las agregaciones y Composite muestra las composiciones.

• Una dependencia indica que cambiar la definición de un clasificador, podría cambiar la definición de otro.

• Una generalización indica que un clasificador concreto hereda parte de su definición de un clasificador general. La realización significa que una clase implementa los atributos y operaciones especificados por la interfaz.

  Utilice la herramienta Herencia para crear estas relaciones: Alternativamente, una realización se puede representar como un círculo.

• Los paquetes son grupo de clasificadores, asociaciones, acciones, líneas de vida, componentes y otros. Importar relaciones indica que un paquete incluye todas las definiciones de otro.

Como punto de partida para explorar y discutir las clases existentes, puede utilizar el Diseñador de clases para crear los diagramas de clases a partir del código.

Vea:

• Diagramas de clases de UML: Referencia

• Diagramas de clases de UML: Instrucciones

• Cómo: Agregar diagramas de clases a proyectos (Diseñador de clases)

Resumen: Ventajas de los diagramas de clases

Los diagramas de clases ayudan a definir:

• Un glosario común de condiciones que se utilizan para discutir las necesidades de los usuarios y las entidades que participan en el sistema. Vea Crear modelos de los requisitos de los usuarios.

• Tipos que son utilizados por partes del sistema, como los componentes, sin tener en cuenta su implementación. Vea Modelar la arquitectura de un sistema de Software.

• Relaciones, como las dependencias, entre los tipos. Por ejemplo, puede mostrar que un tipo puede estar asociado a varias instancias de otro.

Relación con otros diagramas

Diagrama	Descripción
Diagrama de casos de uso	Defina los tipos que se utilizan para describir los objetivos y los pasos en los casos de uso. Vea: Diagramas de casos de uso de UML: Referencia Diagramas de casos de uso de UML: Instrucciones
Diagrama de actividades	Defina los tipos de datos que atraviesan los nodos de objetos, puntos de conexión de entrada y de salida y nodos de parámetros de actividades. Vea: Diagramas de actividades UML: Referencia Diagramas de actividades UML: Instrucciones
Diagrama de componentes	Describa los componentes, sus interfaces y sus relaciones. Una clase también puede describir un componente completo. Vea: Diagramas de componentes de UML: Referencia Diagramas de componentes de UML: Instrucciones
Diagrama de capas	Defina la arquitectura lógica del sistema en lo relativo a las clases. Use la validación de capas para asegurarse de que el código sigue siendo coherente con el diseño. Vea: Crear diagramas de capas a partir del código Diagramas de capas: Referencia Diagrama de capas: Instrucciones Validar código con diagramas de capas
Diagrama de secuencia	Defina los tipos de líneas de vida y las operaciones, los parámetros y los valores devueltos para todos los mensajes que la línea de vida puede recibir. Para crear una línea de vida a partir de un tipo en un diagrama de clases, haga clic con el botón secundario en la línea de vida y, a continuación, haga clic en Crear línea de vida. Vea: Diagramas de secuencia UML: Referencia Diagramas de secuencia de UML: Instrucciones
Gráfico de dependencias	Visualice la organización y las relaciones del código. Para identificar las clases, sus relaciones y sus métodos, cree un documento de gráfico en el que mostrarlos. Vea: Asignar dependencias en el código mediante gráficos de dependencias Editar y personalizar gráficos de dependencias

Describir la arquitectura lógica: diagramas de capas

Los diagramas de capas describen la arquitectura lógica de un sistema organizando los artefactos de la solución en grupos abstractos o capas. Los artefactos pueden ser muchas cosas, como espacios de nombres, proyectos, clases, métodos, etc. Las capas representan y describen los roles o las tareas que realizan los artefactos en el sistema. También puede incluir la validación de capas en las operaciones de protección y compilación para asegurarse de que el código mantiene la coherencia con el diseño.

Para mantener el código coherente con el diseño, Dinner Now y Lucerne utilizan el siguiente diagrama de capas para validar el código cuando evoluciona:

Diagrama de capas de Dinner Now integrado con Lucerne

Las capas de este diagrama vinculan los artefactos de las soluciones de Dinner Now y Lucerne. Por ejemplo, la capa Business se vincula al espacio de nombres DinnerNow.Business y sus miembros, que ahora incluyen la clase PaymentApprover. La capa Resource Access vincula con el espacio de nombres DinnerNow.Data. Las flechas, o dependencias, especifican que solo el nivel Business puede utilizar la funcionalidad de la capa Resource Access. Cuando los equipos actualizan el código, la validación de capas se realiza regularmente para detectar los conflictos cuando se producen y ayudar a resolverlos rápidamente.

Los equipos colaboran para integrar y probar de manera incremental ambos sistemas. Primero se aseguran de que PaymentApprover y el resto de Dinner Now colaboren satisfactoriamente antes de abordar el PaymentProcessing.

El siguiente gráfico de dependencias muestra las nuevas llamadas entre Dinner Now y PaymentApprover:

Gráfico de dependencias con llamadas a métodos actualizadas

Después de confirmar que el sistema funciona como se espera, Dinner Now comenta el código de PaymentProcessing. Los informes de validación de capas están limpios y los gráficos de dependencias resultantes muestran que no existen más dependencias de PaymentProcessing:

Gráfico de dependencias sin PaymentProcessing

Vea:

• Crear diagramas de capas a partir del código

• Diagramas de capas: Referencia

• Diagrama de capas: Instrucciones

• Validar código con diagramas de capas

Dibujar un diagrama de capas

Un diagrama de capas tiene las siguientes características principales:

• Las capas describen grupos lógicos de artefactos.

• Un vínculo es una asociación entre una capa y un artefacto.

  Para crear capas a partir de los artefactos, arrastre los elementos del Explorador de soluciones, los gráficos de dependencias o el Explorador de arquitectura. Para dibujar nuevos niveles y vincularlos con artefactos, utilice el cuadro de herramientas o haga clic con el botón secundario en la superficie del diagrama para crear las capas y, a continuación, arrastre los elementos hacia esas capas.

  El número de una capa indica el número de artefactos vinculados a ella. Estos artefactos pueden ser espacios de nombres, proyectos, clases, métodos, etc. Al interpretar el número de artefactos de una capa, recuerde lo siguiente:

  • Si una capa se vincula a un artefacto que contiene otros artefactos, pero no se vincula directamente a estos otros artefactos, el número incluye únicamente el artefacto vinculado. Sin embargo, los demás artefactos se incluyen para el análisis durante la validación de capas.

    Por ejemplo, si una capa está vinculada a un solo espacio de nombres, el número de artefactos vinculados es 1, aunque el espacio de nombres contenga clases. Si la capa tiene también vínculos a cada clase del espacio de nombres, el número incluirá las clases vinculadas.

  • Si una capa contiene otras que están vinculadas a artefactos, la capa contenedora también está vinculada a esos artefactos, incluso aunque el número de la capa contenedora no los incluya.

  Para ver los artefactos que están vinculados a una capa, haga clic con el botón secundario en la capa y, a continuación, haga clic en Ver vínculos para abrir el Explorador de capas.

• Una dependencia indica que una capa puede usar la funcionalidad de otra, pero no viceversa. Una dependencia bidireccional indica que una capa puede usar la funcionalidad de otra y viceversa.

  Para mostrar las dependencias existentes en el diagrama de capas, haga clic con el botón secundario en la superficie del diagrama y, a continuación, haga clic en Generar dependencias. Para describir las dependencias intencionales, dibuje unas nuevas.

Vea:

• Crear diagramas de capas a partir del código

• Diagramas de capas: Referencia

• Diagrama de capas: Instrucciones

• Validar código con diagramas de capas

Resumen: Ventajas de los diagramas de capas

Los diagramas de capas ayudan a:

• Describir la arquitectura lógica de un sistema según la funcionalidad de sus artefactos.

• Asegurar que el código en desarrollo cumple el diseño especificado.

Relación con otros diagramas

Diagrama	Descripción
Gráfico de dependencias	Visualice la organización y las relaciones del código. Para crear capas, genere un gráfico de dependencias y, a continuación, agrupe los elementos en el gráfico como capas potenciales. Arrastre los grupos desde el gráfico hasta el diagrama de capas. Vea: Asignar dependencias en el código mediante gráficos de dependencias Examinar y reorganizar gráficos de dependencias Editar y personalizar gráficos de dependencias
Diagrama de componentes	Describa los componentes, sus interfaces y sus relaciones. Para visualizar las capas, cree un diagrama de componentes con la funcionalidad de los distintos componentes del sistema. Vea: Diagramas de componentes de UML: Referencia Diagramas de componentes de UML: Instrucciones

Recursos externos

Categoría	Vínculos
Foros	Visualización de Visual Studio & Herramientas de modelado Presentación de Visual Studio & SDK de modelado (herramientas ADSL)
Blogs	Visual Studio ALM + blog de Team Foundation Server
Artículos y diarios técnicos	The Architecture Journal - Edición 23: Modelado y procesos de arquitectura
Otros sitios	Centro de arquitectura de MSDN

Vea también

Conceptos

Visualizar el código

Desarrollar modelos para el diseño de software

Uso de modelos dentro del proceso de desarrollo

Usar modelos en Agile Development

Validar el sistema durante el desarrollo

Ampliar modelos y diagramas UML