Arquitectura y Modelo en Visual Studio 2010 Ultimate.

Arquitectura y modelado
El Explorador de arquitectura de Visual Studio 2010 Ultimate ayuda a entender los activos de cdigo existentes y otras interdependencias. Los diagramas por capas ayudan a garantizar el cumplimiento de la arquitectura y permiten validar artefactos de cdigo con respecto al diagrama. Adems, Visual Studio 2010 Ultimate admite los cinco diagramas de UML ms comunes que conviven junto con su cdigo.

Para utilizar los modelos en un proyecto de desarrollo eficazmente, los miembros del equipo deben poder trabajar al mismo tiempo en los modelos de las diferentes partes del proyecto. En este tema se propone un esquema para dividir la aplicacin en las diferentes partes que se corresponden con las capas de un diagrama de capas. Para comenzar rpidamente con un proyecto o subproyecto, es til tener una plantilla de proyecto que siga la estructura del proyecto elegido. En este tema se describe cmo crear y utilizar este tipo de plantilla. En este tema se supone que est trabajando en un proyecto lo suficientemente grande como para necesitar la participacin de varios miembros del equipo y quiz incluya varios equipos. El cdigo y los modelos del proyecto estn almacenados en un sistema de control de cdigo fuente como Team Foundation Server. Al menos algunos miembros utilizan Visual Studio 2010 Ultimate para el desarrollo de los modelos y otros miembros pueden ver los modelos utilizando otras versiones de Visual Studio.

Estruct

ura de soluciones

En un proyecto de tamao medio o grande, la estructura del equipo se basa en la estructura de la aplicacin. Cada equipo utiliza una solucin de Visual Studio.

Para dividir las aplicaciones en capas

1. Base la estructura de las soluciones en la estructura de la aplicacin, es decir, aplicacin web, aplicacin de servicio o aplicacin de escritorio. En Application Archetypes in the Microsoft Application Architecture Guide se comentan diversas arquitecturas comunes. Cree una solucin en Visual Studio, que denominaremos solucin Arquitectura. Se utilizar para crear el diseo general del sistema. Contendr modelos pero no incluir cdigo. Agregue un diagrama de capas a dicha solucin. En el diagrama de capas, dibuje la arquitectura que ha elegido para la aplicacin. Por ejemplo, el diagrama podra mostrar los siguientes niveles y dependencias entre ellos: presentacin, lgica empresarial y datos.

2.

Puede crear el diagrama de capas y una nueva solucin en Visual Studio al mismo tiempo mediante el comando Nuevo diagrama del men Arquitectura. 3. Agregue al modelo Arquitectura diagramas UML que representen los conceptos empresariales importantes y casos de uso a los que se haga referencia en el diseo de todas las capas. Por cada capa, cree una solucin de Visual Studio independiente en el diagrama de capas Arquitectura. Estas soluciones se utilizarn para desarrollar el cdigo de las capas. 5. Cree modelos UML que representen los diseos de las capas y los conceptos comunes a todas las capas. Organice los modelos de forma que se vean todos en la solucin Arquitectura y los que sean relevantes se puedan ver desde cada capa. Esto se consigue mediante alguno de los siguientes procedimientos. La primera alternativa crea un proyecto de modelado independiente por capa y la segunda crea un proyecto de modelado nico que se comparte entre las capas.

4.

Para utilizar un proyecto de modelado independiente para cada capa

a. Cree un proyecto de modelado en cada solucin de capas. Este modelo contendr diagramas UML que describen los requisitos y el diseo de esa capa. Tambin puede incluir diagramas de capas que muestran las capas anidadas. Ya tiene un modelo para cada capa, adems de un modelo para la arquitectura de la aplicacin. Cada modelo est contenido en una solucin propia. Esto permite que los miembros del equipo trabajen al mismo tiempo en las capas. b. Agregue a la solucin Arquitectura, el proyecto de modelado de cada solucin de capa. Para ello, abra la solucin Arquitectura. En el Explorador de soluciones, haga clic en el nodo de la solucin con el botn secundario, seleccione Agregar y haga clic en Proyecto existente. Navegue hasta el proyecto de modelado (.modelproj) en la solucin de una capa. Cada modelo est ahora visible en dos soluciones: la solucin del modelo propiamente y la solucin Arquitectura. c. Agregue un diagrama de capas al proyecto de modelado de cada capa. Comience con una copia del diagrama de capas Arquitectura. Puede eliminar las partes que no sean dependencias del diagrama de capas. Tambin puede agregar diagramas de capas que representen la estructura detallada de esta capa.

Estos diagramas se utilizan para validar el cdigo que se desarrolla en esta capa. d. En la solucin Arquitectura, modifique los requisitos y los modelos de diseo de todas las capas utilizando Visual Studio Ultimate. En la solucin de cada capa, desarrolle el cdigo de capa haciendo referencia al modelo. Si no tiene inconveniente en hacer el desarrollo sin usar el mismo equipo para actualizar el modelo, puede leer el modelo y desarrollar el cdigo con Visual Studio Premium. Tambin puede generar el cdigo del modelo en Visual Studio Premium. Con este mtodo se garantiza que los desarrolladores no causarn interferencias si modifican los modelos de una capa al mismo tiempo. Sin embargo, como los modelos son independientes, es difcil hacer referencia a los conceptos comunes. Cada modelo debe tener una copia de los elementos de los que depende en otras capas y en la arquitectura. El diagrama de capas de cada capa se debe mantener en sincronizacin con el diagrama de capas Arquitectura. Es difcil mantener la sincronizacin cuando estos elementos cambian, aunque es posible desarrollar herramientas para hacerlo.

Para utilizar un paquete independiente por capa

e. En la solucin de cada capa, agregue el proyecto de modelado Arquitectura. En el Explorador de soluciones, haga clic en el nodo de la solucin con el botn secundario, seleccione Agregar y haga clic en Proyecto existente. Ahora se tiene acceso al proyecto de modelado nico desde cada solucin: el proyecto Arquitectura y el proyecto de desarrollo para cada capa. En el modelo UML compartido, cree un paquete para cada capa: en el Explorador de soluciones, seleccione el proyecto de modelado. En el Explorador de modelos UML, haga clic con el botn secundario en el nodo raz del modelo, seleccione Agregar y, a continuacin, haga clic en Paquete. Cada paquete contendr diagramas UML que describen los requisitos y el diseo de la capa correspondiente. g. Si es necesario, agregue diagramas de capa local para la estructura interna de cada capa. Este mtodo permite que los elementos de diseo de cada capa hagan referencia directamente a los de las capas y arquitectura comn de las que dependen. Aunque el trabajo simultneo en paquetes diferentes puede producir algunos conflictos, se controlan con facilidad porque los paquetes se guardan en archivos independientes. La principal dificultad la causa la eliminacin de un elemento al que se hace referencia en un paquete dependiente. Para obtener ms informacin, veaAdministrar modelos y grficos con control de versiones.

f.

Crear las plantillas de arquitectura

En la prctica, no crear todas las soluciones de Visual Studio al mismo tiempo, sino que las ir agregando a medida que el proyecto progrese. Probablemente utilizar tambin la misma estructura de la solucin en proyectos futuros. Para crear nuevas soluciones rpidamente, puede crear una solucin o una plantilla de proyecto. Puede capturar la plantilla en un proyecto de extensin de integracin (VSIX) de Visual Studio para facilitar la distribucin e instalacin en otros equipos. Por ejemplo, si utiliza con frecuencia soluciones que tienen capas de presentacin, negocio y datos, puede configurar una plantilla que cree nuevas soluciones con esa estructura.

Para crear una plantilla de solucin

1. 2. 3. 4. Descargue e instale el Asistente para exportar plantillas, si an no lo ha hecho. Cree la estructura que desea utilizar como punto inicial de futuros proyectos. En el men Archivo, haga clic en Exportar plantilla como VSIX. Se abrir el Asistente para exportar plantillas como VSIX. Siguiendo las instrucciones del asistente, seleccione los proyectos que desea incluir en la plantilla, proporcione un nombre y una descripcin para la plantilla y especifique la ubicacin donde se guardar.

Modelado

Uso de modelos dentro del proceso de desarrollo

Visual Studio 2010 En Visual Studio Ultimate, puede usar un modelo para que le ayude a comprender y modificar un sistema, aplicacin 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 cdigo y a garantizar que el cdigo satisface los requisitos. Para obtener una introduccin en vdeo, vea Video: UML with Visual Studio 2010

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 diseo de alto nivel. Para obtener ms informacin, 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 comunicacin con modelos le permite transmitir conceptos importantes con una ambigedad menor que la del lenguaje natural. Para obtener ms informacin, veaModelar la arquitectura de un sistema de Software. En ocasiones, podr usar los modelos para generar cdigo 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 ms informacin, 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 ambigedad

El lenguaje de modelos es menos ambiguo que el lenguaje natural y est diseado para expresar las ideas que suelen emplearse durante el desarrollo de software. Si el proyecto se compone de un equipo pequeo 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 ms rapidez preguntas tiles relacionadas con un rea mayor del producto que las que surgiran escribiendo una maqueta o prototipo de cdigo.

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 ms eficaz que a travs de un documento de texto sin formato. En estas dos situaciones, siempre que se crea un modelo, se reducen significativamente las inconsistencias y las ambigedades. 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 cmo funciona el sistema.Cuando se usa un modelo como eje central de una conversacin, suelen salir a la luz estas diferencias. Para obtener ms informacin acerca de cmo 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 especificacin de requisitos. En una herramienta que permite expresar algunos aspectos de estos elementos con mayor claridad, pero no todos los conceptos que sern necesarios durante el diseo de software. Los modelos, por tanto, deben usarse con otros medios de comunicacin, como pginas o prrafos de OneNote, documentos de Microsoft Office, elementos de trabajo de Team Foundation o notas rpidas adheridas a la pared del proyecto. A excepcin de este ltimo, todos estos tipos de objetos pueden vincularse a elementos del modelo. A continuacin se enumeran otros aspectos de especificacin que se usan habitualmente con los modelos. En funcin 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 descripcin corta, que se analiza con los usuarios y dems participantes, de un aspecto del comportamiento del sistema que se proporcionar en una de las iteraciones del proyecto. Un caso de usuario tpico 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 amplan casos de uso, el caso de usuario resulta ms claro. Solicitudes de cambio. Una solicitud de cambio de un proyecto ms formal es muy similar a un caso de usuario en de proyecto ms gil. En el enfoque gil, todos los requisitos se tratan como modificaciones del trabajo desarrollado en iteraciones anteriores. Descripcin de casos de uso. Un caso de uso representa un mecanismo mediante el que un usuario interacta con el sistema para lograr un objetivo determinado. Una descripcin completa incluira el objetivo, la secuencia de eventos principal y alternativa y los resultados excepcionales. Con los diagramas de casos de uso, resulta ms fcil resumir y proporcionar informacin general sobre los casos de uso. Escenarios. Un escenario es una descripcin bastante detallada de una secuencia de eventos que muestran cmo el sistema, los usuarios y otros sistemas trabajan juntos para ofrecer un valor a las partes interesadas. Puede tener la forma de una presentacin 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 tambin deben usar estos trminos. Un diagrama de clases puede ayudar a clarificar las relaciones entre la

mayora de estos trminos. Con la creacin 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 tambin 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. Diseo de alto nivel. Describe los elementos principales y cmo encajan unos con otros. Los diagramas de componentes, secuencia e interfaces constituyen una parte fundamental de un diseo de alto nivel. Modelos de diseo. Describen las reglas de diseo 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 diseos del cdigo de prueba para describir secuencias de pasos de prueba. Las pruebas del sistema deben expresarse en trminos del modelo de requisitos para que se puedan modificar fcilmente cuando varen los requisitos. Plan del proyecto. El plan del proyecto o el trabajo pendiente establece cuando se entregar cada caracterstica. Puede definir cada caracterstica estableciendo qu casos de uso y reglas de negocio implementa o ampla. Puede hacer referencia a los casos de uso y las reglas de negocios directamente en el plan o puede definir un conjunto de caractersticas en un documento diferente y usar los ttulos de estas caractersticas en el plan.

Usar modelos en los planes de iteraciones

Aunque todos los proyectos difieren en su escala y organizacin, 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 inters a medida que se acerca cada iteracin A medida que se acerca cada iteracin, use modelos que le ayuden a definir los resultados que va a entregar al final de la iteracin. En las iteraciones iniciales, no debe modelar todo en detalle. En la primera iteracin, 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 cambiarn posteriormente en el proyecto. Use los trminos definidos en este modelo para crear una lista de caractersticas o casos de usuario principales. Asigne las caractersticas a las iteraciones para equilibrar en la medida de lo posible la carga de trabajo calculada a lo largo del proyecto. Estas asignaciones variarn a medida que avance el proyecto. Intente implementar versiones simplificadas de todos los casos de uso ms importantes en una iteracin inicial. Ample 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 iteracin, celebre un taller de requisitos para definir en detalle los requisitos o casos de usuario que se desarrollarn en la iteracin siguiente. Invite a los usuarios y a las partes interesadas del negocio que pueden establecer las prioridades, adems de a los desarrolladores y a los evaluadores del sistema. Deje tres horas en cada iteracin de dos semanas para definir los requisitos. El objetivo del taller es que todos acuerden qu objetivos deben conseguirse al final de la iteracin siguiente. Use los modelos como una herramientas ms para aclarar los requisitos. La salida del taller es el trabajo pendiente de una iteracin, 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 diseo solo en la medida en que necesite determinar las estimaciones de las tareas de desarrollo. De lo contrario, restrinja la conversacin al comportamiento del sistema que los usuarios pueden experimentar directamente. Mantenga el modelo de requisitos separado del modelo arquitectnico. El personal no tcnico 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 Despus 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 informacin acerca de cmo hacerlo, vea Cmo: Vincular elementos de trabajo con elementos de modelo. Puede vincular cualquier elemento a los elementos de trabajo, pero los elementos ms 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 iteracin, 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 relacin extender. Para obtener ms informacin sobre la extensin 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 ms informacin, vea Crear modelos de los requisitos de los usuarios.

Vincular el modelo a las pruebas Use el modelo de requisitos para dirigir el diseo de las pruebas de aceptacin. Cree estas pruebas simultneamente con el trabajo de desarrollo. Para obtener ms informacin sobre esta tcnica, vea Desarrollar pruebas en un modelo. Calcular el trabajo restante

Un modelo de requisitos puede ayudar a calcular el tamao total del proyecto frente al tamao de cada iteracin. Calcular el nmero 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 comparacin 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 iteracin, revise la asignacin de requisitos a futuras iteraciones. Quizs le resulte til representar el estado del software al final de cada iteracin 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 abstraccin
El nivel de abstraccin de los modelos vara en funcin del software. Los modelos ms concretos representan directamente el cdigo del programa y los modelos ms abstractos representan conceptos del negocio que pueden o no representarse en el cdigo. Un modelo puede verse a travs de distintos tipos de diagramas. Para obtener informacin sobre los modelos y diagramas, vea Desarrollar modelos para el diseo de software. Los distintos tipos de diagramas resultan tiles para describir el diseo con diferentes niveles de abstraccin. Muchos de los tipos de diagramas resultan tiles para varios niveles. En esta tabla se muestra cmo se puede usar cada tipo de diagrama.

Nivel de diseo 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. Requisitos del usuario Definicin de lo que los usuarios necesitan del sistema.

Tipos de diagramas

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. 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 informacin 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.

Diseo de alto nivel Estructura global del sistema: sus componentes primarios y cmo se acoplan.

Los diagramas de capas describen cmo el sistema se estructura en partes interdependientes. Puede validar el cdigo 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 cmo 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. 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. En los diagramas de secuencia se muestra las interacciones entre los objetos del cdigo. En los diagramas de capas se muestran las dependencias entre las clases. El cdigo actualizado se puede validar con un diagrama de capas. En los diagramas de clases se muestran las clases del cdigo.

Modelos de diseo Convenciones y mtodos para problemas de diseo que se usan en todos los elementos del diseo. Anlisis de cdigo Se pueden generar distintos tipos de diagramas a partir del cdigo.

Unas de las novedades que trae consigo el nuevo Visual Studio 2010 en un men Arquitectura que nos permite realizar algunos de los principales diagramas UML de los que dispone o debera disponer cualquier aplicacin. Entre los diagramas que podemos crear tenemos: -Diagrama de Clases -Diagrama de Secuencias -Diagrama de casos de uso -Diagramas de actividad -Diagrama de Componentes -Diagrama de capaz

No tenemos a la disposicin todos los diagramas UML pero si son mas de los que el 90% (por no decir el 99%) de la aplicaciones que he visto utilizan, y seguramente en un futuro se irn aadiendo nuevos diagramas a galera. Para esto solo tenemos que crear un nuevo proyecto de modelado, en el men ArchivoNuevo Proyecto- Proyecto de Modelado, donde aparecer una lista para escoger el tipo de diagrama que deseamos realizar.

Tambin existe la posibilidad de crear diagramas de dependencia basados en las clases, assemblys o namespace de un proyecto con el que ya estemos trabajando, para esto solo tenemos que ir al men Arquitectura-Generar Grafico de Dependencia y escoger el nivel de dependencia que queremos

Herramientas de arquitectura Este es el ultimo post de una serie de tres donde la tematica central son las mejoras que traera consigo el nuevo IDE Visual Studio 2010, inspirandome en el evento Run Reloaded 2009 que microsoft realizo el mes de novimenbre pasado en Buenos Aires, Argentina y en cual expertos oradores nos mostraron y debatieron con nosotros (la comunidad) el uso de estas nuevas herramientas; para el final de esta serie de posts he dejado una mejora muy interesante y son las nuevas herramientas de arquitectura que trae incoporado VS 2010. Para poder probar es

necesario descargar (es gratuito) la version Ultimate de Visual Studio 2010 beta 2. Visual Studio 2010 Ultimate Beta 2 Microsoft nos ofrece un nuevo esquema de versiones para Visual Studio 2010 y es el siguiente: Visual Studio 2010 Professional Visual Studio 2010 Premium Visual Studio 2010 Ultimate En la version Ultimate es en la cual tenemos completas las herramientas para arquitectura. Las herramientas principales son las siguientes: Architecture Explorer (Explorador de arquitectura) UML Support (Soporte UML) Layer Diagram (Diagrama de capas) Para probar estas nuevas herramientas he tomado un proyecto de la pagina Code Porject, un sitio que recomiendo a todos los interesados en el desarrollo de software, como una fuente muy rica de recursos de los mas variados. El proyecto pertenece a Marcelo Ricardo de Oliveira y consiste en un juego de Pool llamado Snooker.

Architecture Explorer
Con esta herramienta podemos obtener diferentes vistas de nuestra solucion y nuestros proyectos, esta herramienta la encontramos en el nuevo menu de Arquitectura

En la imagen podemos ver como se despliega el menu Generate Dependency Graph, este grafico lo puedo generar por Assemblie, por Namespace, por Clase o de forma personalizada. En este caso voy a generar por Namespace y obtengo lo siguiente:

n la imagen podemos ver como genero el grafico con las dependencias entre cada namespace. Ahora expandimos el nodo CSharpSnookerCore.Model y vemos los elementos en su interior:

Podemos lograr aun mas profundidad si expandimos por ejemplo alguna clase dentro del nodo anterior y vemos los metodos de las clases por ejemplo de la clase Pocket:

En el menu View podemos ver el Architecture Explorer, nos permite navegar nuestra arquitectura de manera facil, intuitiva, y establecer filtros para los elementos

Podemos establecer filtros para facilitar la navegacion dentro de los elementos de la siquiente forma:

Como podemos apreciar, el Explorador de Arquitectura tiene muchas opciones y es una herramienta poderosa que nos permitira ampliar nuestra vision del poryecto en su conjunto.

UML Support
El soporte para UML (Unified Modeling Language), es una herramienta totalmente nueva en Visual Studio, la creacion de modelos es a traves de un template y veremos a continuacion como realizarla Un proyecto de modelado UML se crea como cualquier proyecto nuevo en el menu File, New Proyect, en la categoria Modeling Projects existe un solo template que se llama Modeling Project

Una vez creado el proyecto podemos ver la ventana del UML Explorer, a la cual podemos acceder a traves del menu View, alli podemos agregar algunos elementos a nuestro modelo, haciendo click derecho sobre el modelo vemos el menu Add

Agregar un nuevo diagrama al modelo es tan sencillo como agregar cualquier item a un proyecto, en el menu Project, Add new Item, vemos el cuadro de dialogo para agregar un nuevo diagrama.

Podemos usar la ventana toolbox para agregar nuevos elementos al diagrama o podemos utilizar los elementos que ya existen en nuestro modelo arrastrandalos al diagrama.

De la misma forma podemos crear diferentes tipos de Diagramas UML, utilizando los items de la toolbox dependiendo del diagrama que estemos creando

Layered Diagram (Diagrama de Capas)

En el proyecto de modelado si agregamos un Diagrama de Capas (Layer Diagram) podemos ver lo siguiente

Para agregar un diagrama de capas, lo podemos hacer desde el menu Architecture, Add New Diagram, alli veremos el siguiente dialogo

Este tipo de diagramas es de gran utilidad ya que nos permite agrupar en capas la estructura de nuestro proyecto y verificar la comunincacion entre las diferentes capas. Realizando la validacion de la arquitectura.

He tomado la siguiente imagen de Skinner's Blog. Y se puede ver claramente el funcionamiento de los diagramas de capas

Conclucion

Hasta aqui he presentado las nuevas herramientas de arquitectura que incluye Microsoft Visual Studio 2010 (recordemos que esta version es la Ultimate y se encuentra en Beta 2). Las cuales a mi parecer son muy utiles y le agregan mucho valor al IDE. Una cosa a mejorar es la ausencia de una herramienta que me permita generar codigo a partir del modelo UML (seria ideal la utilizacion de templates T4? para ello) talvez veamos estas features en la version final de VS 2010. La primera experienca utilizando esta herramienta fue muy placentera y sumamente util, aun sigo probando el nuevo VS 2010. Saludos a todos y feliz programacion!