En el captulo anterior cubierto modelado: cmo capturar las decisiones de diseo que conforman una arquitectura de software de sistemas.

En la prctica, a menudo hay diferentes maneras para visualizar e interactuar con la informacin contenida en esos modelos. Este es el dominio de la visualizacin arquitectnica. Definicin. Una visualizacin arquitectnica define cmo los modelos arquitectnicos son las partes interesadas representadas, y cmo interactan con esas representaciones. Esta es una definicin intencionadamente amplia de visualizacin. Aqu, la visualizacin se compone de dos aspectos clave: la representacin y la interaccin. En pocas palabras, una representacin es una imagen o visual representacin de las decisiones de diseo arquitectnico en un formato particular. visualizacin herramientas pueden proporcionar uno o ms mecanismos de interaccin a travs del cual los usuarios pueden interactuar con esas decisiones en cuanto a la representacin. Estos mecanismos pueden incluir comandos del teclado, las operaciones de apuntar y hacer clic, y as sucesivamente. En este captulo se analiza la relacin entre las notaciones de modelado de arquitectura y visualizaciones, y cmo los diversos lenguajes de modelado se visualizan. A continuacin, cubre diversas estrategias para el diseo y evaluacin de visualizaciones para maximizar su efividad. El captulo termina con una revisin de las tcnicas de visualizacin diferentes y evaluaciones de las fortalezas y debilidades de cada tcnica. Este captulo no pretende ser un tratamiento de tcnicas para el diseo o usabilidad visualizacin de la informacin en general; estos temas son demasiado amplios para el mbito de aplicacin de esta libro. En cambio, el captulo se centra en la identificacin de los tipos de visualizaciones que puedas ser utilizados para los modelos arquitectnicos y discute temas relacionados especficamente con la visualizacin de arquitecturas.

7.1 CONCEPTOS DE VISUALIZACIN Visualizacin juega un papel crtico en la arquitectura de software. El mensaje ms importante de este captulo es que las arquitecturas de forma son visualizados puede ser, en cierta medida, independiente de la forma en que se modelan. Los dos estn estrechamente relacionados, de hecho, cada notacin de modelado es asociada con una o ms visualizaciones cannicas o nativo. (Esto se discutir en ms detalle a continuacin.) Fundamentalmente, sin embargo, un modelo que se acaba de organizar informacin. En la caso de los modelos arquitectnicos, la informacin consiste en las decisiones de diseo. Visualizaciones son los medios por los que se da la informacin en un modelo de la forma: la forma en que se representa y cmo los usuarios interactan con l. Un modelo arquitectnico nico pueden ser visualizados en cualquier nmero de formas, y multi- ples diversos modelos se pueden visualizar de forma similar. Por lo tanto, la visualizacin puede ser utilizado para ocultar (o al menos suavizar) las diferencias en las notaciones de modelado de fondo. En segundo lugar, visualizaciones pueden variar ampliamente, muchos son grficos, pero la mayora de las AVD tienen textual visualnizaciones as. La investigacin se ha hecho en el rea de visualizacin esotricos, tales como tridimensionales realidades virtuales (Feijs y De Jong 1998). El objetivo de esta seccin es distinguir las visualizaciones de su modelo subyacente notaciones, introducir los tipos de visualizaciones que se pueden utilizar para arquitecturas de modelo (Textual, grfica, e hbridos), y luego discutir los problemas que surgen cuando varios visualizaciones (de todos estos tipos) se aplican simultneamente a una arquitectura.

7.1.1 Las visualizaciones cannicas Es difcil separar la informacin de resumen en un modelo a partir de las formas concretas en las que la informacin que se visualiza. Ninguna informacin es completamente divorciada de la visualiza- cin. Sin embargo, mentalmente hacer esta separacin a menudo en nuestra vida diaria. Un signo que representa un peatn palo de la figura con una barra a travs de ella y una muestra cercana que dice "Do Not Cross" son simplemente dos diferentes formas de visualizar la misma informacin: grfica de uno y uno textual. Desde esta perspectiva, las notaciones de modelado de arquitectura son simplemente formas de organizacin informacin. Cada anotacin tiene al menos una visualizacin que es directa y especficamente asociado con l. A esto le llamamos visualizacin visualizacin de la notacin cannica de. Modelos con vistas mltiples se asocian a menudo con mltiples visualizaciones cannica y uno por ver; puntos de vista se trata en la seccin siguiente. ADLs basados en texto (incluyendo basadas en XML AVD) de forma nativa expresada mediante el texto visualizaciones basadas en. No todas las notaciones de modelado son textuales, sin embargo. PowerPoint y OmniGraffle modelos son manipulados en su totalidad en

las visualizaciones grficas, y no hay manera fcil de extraer una representacin basada en texto del modelo. Nativa, diagramas UML son principalmente grfica. Algunas partes de UML, tales como el Lenguaje de Restriccin de Objeto (OCL) restricciones que se utilizan para limitar las relaciones entre los elementos del modelo, son textuales, que tiene una sintaxis bien definida y la semntica que les es propia. Un error comn es que los usuarios asociar una notacin de modelado de arquitectura slo con su visualizacin cannica, o para ver una notacin cannica y su visualizacin como la misma cosa. Ellos no lo son: La notacin es una forma de organizar (resumen) informacin y la visualizacin de la informacin dicta cmo se representa y interactuado. Para ejemplo, la mayora de las herramientas que tienen que ver con los modelos arquitectnicos guardar el modelo en las estructuras de datos en la memoria, asociado con ninguna visualizacin especfica, y no es hasta que un editor que se invoca esta informacin se visualiza. Visualizaciones cannicas presentar la informacin de una manera que est estrechamente relacionado con su organizacin, pero recuerda que esto no es casi siempre el nica manera de presentar la informacin. No todas las visualizaciones son ptimas para todos los usos, as anotaciones para las que existen mltiples visualizaciones son generalmente preferibles a los que slo tienen un nico cannico visualizacin. En proyectos complejos arquitectnicos deseados objetivos pueden alcanzarse ms fcilmente mediante el desarrollo de una nueva visualizacin de una anotacin existente que el perfeccionamiento o la seleccin de un completo nueva notacin.

7.1.2 Las visualizaciones textuales Visualizaciones textuales representan arquitecturas usando archivos de texto normales. Estos archivos de texto en general ajustarse a un formato particular sintctico, como un c. o. java se ajusta a la sintaxis de la C o lenguaje Java. (Como ya hemos comentado, las decisiones arquitectnicas tambin pueden serdocumentado en lenguaje natural, en cuyo caso la visualizacin textual slo sera limitado por las reglas de la gramtica y la ortografa de esa lengua.) La Figura 7-1 muestra dos representaciones textuales de la arquitectura de un cliente Web que consiste en slo uno de los componentes: un navegador Web. La primera representacin muestra una arquitectura en la xADL formato nativo XML, y el segundo muestra la arquitectura misma en xADLite. Este es un ejemplo de diferentes visualizaciones que se aplica al mismo modelo. El XML visualizacin de la arquitectura es fcil de leer, manipular y sintcticamente validado por XML herramientas. La visualizacin xADLite describe la arquitectura mismo (y es, de hecho, deriva directamente del mismo modelo), pero est mejor optimizado para facilitar la lectura humana. Visualizaciones de texto tienen varias ventajas. Por lo general, representan la

totalidad de los una arquitectura en una notacin particular en un solo archivo. Cientos de editores de texto son fcilmente disponibles que permiten al usuario interactuar con archivos de texto. Aos de investigacin han entrado en tecnologas para el anlisis, procesamiento y edicin de texto estructurado. Cuando una sintaxis textual es tecnologas para el anlisis, procesamiento y edicin de texto estructurado. Cuando una sintaxis textual es 252

7.1.1 Las visualizaciones cannicas Es difcil separar la informacin de resumen en un modelo a partir de las formas concretas en las que la informacin que se visualiza. Ninguna informacin es completamente divorciada de la visualiza- cin. Sin embargo, mentalmente hacer esta separacin a menudo en nuestra vida diaria. Un signo que representa un peatn palo de la figura con una barra a travs de ella y una muestra cercana que dice "Do Not Cross" son simplemente dos diferentes formas de visualizar la misma informacin: grfica de uno y uno textual. Desde esta perspectiva, las notaciones de modelado de arquitectura son simplemente formas de organizacin informacin. Cada notacin tiene al menos una visualizacin que es directa y especficamente asociado con l. A esto le llamamos visualizacin visualizacin de la notacin cannica de. Modelos con vistas mltiples se asocian a menudo con mltiples visualizaciones cannica y uno por ver; puntos de vista se trata en la seccin siguiente.

ADLs basados en texto (incluyendo basadas en XML AVD) de forma nativa expresada mediante el texto visualizaciones basadas en. No todas las notaciones de modelado son textuales, sin embargo. PowerPoint y OmniGraffle modelos son manipulados en su totalidad en las visualizaciones grficas, y no hay manera fcil de extraer una representacin basada en texto del modelo. Nativa, diagramas UML son principalmente grfica. Algunas partes de UML, tales como el Lenguaje de Restriccin de Objeto (OCL) restricciones que se utilizan para limitar las relaciones entre los elementos del modelo, son textuales, que tiene una sintaxis bien definida y la semntica que les es propia.

Un error comn es que los usuarios asociar una notacin de modelado de arquitectura slo con su visualizacin cannica, o para ver una notacin cannica y su visualizacin como la misma cosa. Ellos no lo son: La notacin es una forma de organizar (resumen) informacin y la visualizacin de la informacin dicta cmo se representa y interactuado. Para ejemplo, la mayora de las herramientas que tienen que ver con los modelos arquitectnicos guardar el modelo en las estructuras de datos en la memoria, asociado con ninguna visualizacin especfica, y no es hasta que un editor que se invoca esta informacin se visualiza. Visualizaciones cannicas presentar la informacin de una manera que est estrechamente relacionado con su organizacin, pero recuerda que esto no es casi siempre el nica manera de presentar la informacin.

No todas las visualizaciones son ptimas para todos los usos, as anotaciones para las que existen mltiples visualizaciones son generalmente preferibles a los que slo tienen un nico cannico visualiza cin. En proyectos complejos arquitectnicos deseados objetivos pueden alcanzarse ms fcilmente mediante el desarrollo de una nueva visualizacin de una anotacin existente que el perfeccionamiento o la seleccin de un completo nueva notacin. 7.1.2 Las visualizaciones textuales Visualizaciones textuales representan arquitecturas usando archivos de texto normales. Estos archivos de texto en general ajustarse a un formato particular sintctico, como un c. o. java se ajusta a la sintaxis de la C o lenguaje Java. (Como ya hemos comentado, las decisiones arquitectnicas tambin pueden ser documentado en lenguaje natural, en cuyo caso la visualizacin textual slo sera limitado por las reglas de la gramtica y la ortografa de esa lengua.) La Figura 7-1 muestra dos representaciones textuales de la arquitectura de un cliente Web que consiste en slo uno de los componentes: un navegador Web. La primera representacin muestra una arquitectura en la xADL formato nativo XML, y el segundo muestra la arquitectura misma en xADLite. Este es un ejemplo de diferentes visualizaciones que se aplica al mismo modelo. El XML visualizacin de la arquitectura es fcil de leer, manipular y sintcticamente validado por XML herramientas. La visualizacin xADLite describe la arquitectura mismo (y es, de hecho, deriva directamente del mismo modelo), pero est mejor optimizado para facilitar la lectura humana. Visualizaciones de texto tienen varias ventajas. Por lo general, representan la totalidad de los una arquitectura en una notacin particular en un solo archivo. Cientos de editores de texto son fcilmente disponibles que permiten al usuario interactuar con archivos de texto. Aos de investigacin han entrado en tecnologas para el anlisis, procesamiento y edicin de texto estructurado. Cuando una sintaxis textual es tecnologas para el anlisis, procesamiento y edicin de texto estructurado. Cuando una sintaxis textual es 252

define mediante un meta-lenguaje como Backus-NaurForm (BNF), muchas herramientas disponibles para generar bibliotecas de programas que pueden analizar y comprobar la sintaxis de los documentos de texto escritos en ese idioma. Muchos editores de texto proporcionar apoyo adicional para los desarrolladores especial notaciones con caractersticas como autocompletar y comprobacin de sintaxis a medida que

escribe. Notaciones textuales tienen ventajas Dis, tambin. Notaciones textuales son buenos para representar Datos lineal y jerrquica. (Piense en una programacin de un lenguaje como Java Cor: Lineal Pedidos se realiza mediante lneas de arriba a abajo, y la estructura jerrquica capturada se el uso de llaves y el sangrado.) Sin embargo, el grfico como estructuras no estn tood lava fcilmente (por La gente) a travs de la visualizacin de texto. Adems, los editores de texto se limitan generalmente a Mostrando un ful pantalla contigua de texto, con pocas opciones para organizar el texto de manera diferente (Aunque algunos entornos avanzados principales caractersticas clued como el plegado de cdigo que Permitir a los usuarios a derrumbarse un bloque de texto en una sola lnea).

7.1.3 Las visualizaciones grficas Visualizaciones grficas representan arquitecturas (principalmente) mediante smbolos grficos en lugar de texto. Al igual que las visualizaciones textuales, las visualizaciones grficas en general se ajustan a una sintaxis (Esta vez de smbolos en lugar de los elementos de texto), pero tambin pueden ser de forma libre (de alto nivel o diagramas de descripcin de arquitecturas son a menudo) de forma libre y estilstica.

La Figura 7-2 muestra dos representaciones grficas de la arquitectura Lunar Lander. La parte superior descripcin es una descripcin de alto nivel de la sonda y su misin. Si bien esta descripcin carece rigor y formalidad, s transmitir informacin til a los interesados que tropiezan con la aplicacin por primera vez. Tales pinturas se utilizan a menudo como general sobre los conceptos de aplicaciones complejas, especialmente aquellas que consiste en muchos de los sistemas interconectados. Stan- dards tales como el Departamento de Defensa Architecture Framework (DoDAF, discutido ms extensamente en el captulo 16) son representaciones-esta representacin tan satisfara el DoDAF "OV-1" vista de la arquitectura Lunar Lander (DoD Architecture Framework Grupo de Trabajo de 2004). Tenga en cuenta, sin embargo, que es ambigua o engaosa en varios importantes maneras. Por ejemplo, el mdulo de aterrizaje se inclina un poco con respecto a la superficie de la luna, lo que puede implicar un aspecto de dos o tres dimensiones para el juego que no existe en la aplicacin final. Tambin representa la Tierra en el fondo, lo que puede llevar a pensar que las comunicaciones de la Tierra juegan un papel en la simulacin aterrizador.

La representacin inferior es una vista lgica de la arquitectura Lunar Lander, representando su estructura en trminos de un componente y el grfico de conector. Este punto de vista es ms rigurosa,

menos ambigua, y muestra ms informacin en el coste de ser menos accesibles a fuera los interesados. La misin y de la finalidad del sistema se pierde en el detalle de la Los componentes y sus interconexiones. Visualizaciones grficas da tener acceso los titulares de formacin Toin de una arquiTure en muchos aspectos que las visualizaciones textuales no pueden. Smbolos, colores y visual otras Decoraciones en general, se pueden distinguir hed ms fcilmente que los elementos de texto estructurado. 7.1 CONCEPTOS DE VISUALIZACIN 255 Relaciones no jerrquicas entre los elementos se puede ver con mayor facilidad en un grfico de un archivo de texto. Visualizaciones grficas pueden usar para expresar las relaciones espaciales relaciones entre los elementos. Advanced visualizaciones grficas tambin pueden emplear animacin u otros efectos visuales para destacar o mostrar diferentes aspectos de la arquitectura. Opciones para interactuar con visualizaciones grficas son generalmente superiores a texto visualnizaciones, as: desplazamiento, zoom, la perforacin hacia abajo, mostrar y ocultar los diferentes niveles de detalle y la manipulacin directa de los objetos con el ratn son comunes en herramientas grficas de visualizacin. Por ejemplo, un entorno grfico podra permitir a un usuario para conectar componentes simplemente dibujando una lnea entre sus interfaces con el ratn. Una desventaja importante de visualizaciones grficas es el coste de las herramientas de construccin para apoyar ellos. Existen muchas herramientas para la creacin de diagramas grficos, PowerPoint, Visio OmniGraffle, Photoshop e Illustrator son algunos de los ms populares. Sin embargo, estas herramientas carecen comprensin de la semntica de arquitectura, y es difcil o imposible para aadir aprosemntica adecuadas y operaciones de interaccin a estas herramientas para que puedan ser integrados en un programa ms amplio entorno de ingeniera. Adems, dichas herramientas tienen generalmente sus propios (generalmente de propiedad) formatos de archivo y modelos de memoria en la que son difciles de conectar a una arquitectura ms centrada en la representacin [(Goldman y Balzer 1999) (Ren y Taylor 2003)].

7.1.4 Las visualizaciones hbridas Grfica y textual son caminos speros de visualizaciones categorizacin. Muchas visualizaciones difuminar la lnea entre estas categoras. Pocos visualizaciones grficas utilizan smbolos de slo en general, el texto se utiliza para decorar, etiquetas, o explicar el significado de los distintos elementos. Algunos visualizaciones de ir an ms lejos, expresando algunos tipos de decisiones de diseo utilizando grficos y otros el uso de texto. Por ejemplo, un diagrama de clases UML se compone sobre todo de la inter- smbolos conectados, mas las limitaciones sobre las relaciones entre los smbolos se representan en la Objeto Constraint Language (OCL) con una visualizacin exclusivamente textual.

La figura 7-3 muestra UML como una visualizacin hbrida. El diagrama de clases es principalmente grficoical, la captura de los tres elementos primarios Lunar Lander-interfaz de usuario, clculo y almacn de datos. Junto con el diagrama de clases, OCL textual se emplea para describir la restriccin que la velocidad de combustin nuevo debe ser no negativo. Algunas visualizaciones pueden estar compuestos de muchos diferentes visualizaciones, tanto grfica y textual. Por ejemplo, el diagrama de UML estructura compuesta es un principalmente grficamente visualizacin cal utilizada para contener otros diagramas UML. Tales compuestos pueden visualizaciones ser bueno para la visualizacin de las relaciones entre los diferentes aspectos de la misma arquitectura. Visualizaciones compuestos pueden llegar a ser complejos y confusos rpidamente como diferentes depiccin y los mecanismos de interaccin se combinan. Estrategias como la interaccin drilldown mecanismos, donde los usuarios pueden navegar a visualizaciones sub de un compuesto de alto nivel visualizacin, puede mitigar esta complejidad.

7.1.5 La relacin entre Visualizaciones y Vistas Algunas visualizaciones pueden representar el modelo arquitectnico completo de una vez, pero a menudo ms visualizaciones diferentes se utilizan para representar vistas diferentes de la arquitectura. Captulo 6 present el concepto de puntos de vista: subconjuntos de la arquitectura, por lo general organizada en torno a un preocupacin o conjunto de preocupaciones. Recordemos las definiciones presentadas: Definicin. Una vista es un conjunto de decisiones de diseo relacionadas por una preocupacin comn (o conjunto De las preocupaciones).

Definicin. Un punto de vista define la perspectiva desde la cual se tiene una vista. Efectivamente, las opiniones y puntos de vista vamos a considerar diferentes subconjuntos de thedesign Las decisiones en una arquitectura. Podemos aplicar el mismo concepto a sub fa establecidos para las visualizaciones: Una visualizacin de un punto de vista define los mecanismos de representacin y la interaccin slo para Los tipos de decisiones de diseo incluido en ese punto de vista. Nos asociamos con visualizaciones Puntos de vista en lugar de puntos de vista, porque la misma visualizacin pueden utilizarse para visualizar a muchos arquitecturas diferentes, no creamos una nueva visualizacin para cada arquitectura. Para ejemplo, theUMLclassdiagramisavisualizationthatcanbeusedtovisualizetheclass structureofmanydifferentapplications.Twodifferentclassdiagramsarenottwoseparate Las visualizaciones, sino que son simplemente dos ejemplos de la visualizacin diagrama UML de clases. Cuando una notacin est asociado con un conjunto de puntos de vista, es de diez el caso de que Cada punto de vista tiene su propia visualizacin cannica. UML es un buen ejemplo de esto: Cada Tipo de diagrama UML puede ser visto como una visualizacin separada. Al aunque UML'scanonical visualizacin grfica son, difieren ampliamente. El diagrama de caja y flecha al estilo utilizado para describir los componentes y sus relaciones tiene apariencia ms escasos para los autmatas de tipo estado grfico o lnea de tiempo le gustan los diagramas equence, como seeninFigure7-4. Este es un producto natural consecuencia del hecho de que los modelos de arquitectura capturar una amplia variedad de informacin

acerca de un sistema. Lo que constituye una visualizacin til para una preocupacin tal vez intil por otra preocupacin. As como los actores del sistema deben identificar los puntos de vista que va a utilizar para examinar y trabajar con una arquitectura, sino que tambin debe identificar apropiada visualizaciones para cada punto de vista. Todos nuestros comentarios anteriores sobre la relacin entre las visualizaciones y los modelos se aplican igualmente a los modelos parciales, es decir, puntos de vista. Si el mismo conjunto de diseo arquitectnico decisiones est simplemente representada en dos formas diferentes, no son dos vistas diferentes de la arquitectura, pero son dos visualizaciones diferentes que se aplican a la misma vista. En el captulo 6, mostramos una representacin de Lunar Lander en xADLite, seguido por la representacin equivalente en el Archipilago. Figura 7-5 repite las dos representaciones de Captulo 6 (aunque la visualizacin xADLite extensa se ha abreviado). es un ejemplo de dos diferentes visualizaciones para el punto de vista estructural que se aplica a el mismo subconjunto de las decisiones de diseo (es decir, ver) de la arquitectura Lunar Lander. Por lo tanto, no diramos que se trata de la vista y la vista xADLite Archipilago Lunar de la Lander arquitectura, que son la xADLite y representaciones del Archipilago estructural vista del sistema Lunar Lander.

7.2 EVALUACIN DE visualizaciones Las secciones anteriores describen lo visualizaciones son, qu tipos de visualizaciones de existir, y las relaciones entre las visualizaciones, modelos, vistas y puntos de vista. Sin embargo, una pregunta clave que surge ahora: Qu hace una visualizacin "bueno" Cmo puede uno distinguir visualizaciones de uno a otro y elegir el mejor? En ltima instancia, el valor de un visualizacin depende de lo bien que se adapta a las necesidades de los interesados de un proyecto. Como tenemos visto, las necesidades de las partes interesadas y las prioridades varan de un proyecto a otro, por lo que una visualizacin que Es perfecto para un proyecto puede ser intil en otro. No obstante, es posible identificar algunas cualidades deseables para las visualizaciones, los cuales pueden ser priorizados por los actores para adaptarse sus situaciones especficas. Estas cualidades incluyen: Fidelidad La fidelidad es una medida de cun fielmente visualizacin representa el modelo subyacente. En

general, la fidelidad mnimo aceptable para una visualizacin requiere que la informacin pretantes en la visualizacin ser coherente con el modelo subyacente. Sera extremadamente confuso, por ejemplo, si una visualizacin estructural mostr componentes que no se actualiado en la arquitectura, y as sucesivamente. Sin embargo, las visualizaciones no tienen que tratar todos los informacin en un modelo subyacente. Dejando un poco el detalle menudo puede hacer que visualizaciones ms eficaz centrando la atencin en las partes del modelo que importan en un dado situacin. Tal es el caso para las visualizaciones que estn asociados con puntos de vista particulares,por ejemplo.

Fidelity afecta tanto a la descripcin y la interaccin. Un mecanismo de interaccin es fiel si respeta la sintaxis y la semntica subyacente de la notacin visualizada. Por ejemplo, una interfaz que permite a los interesados para cambiar el modelo de manera no vlidos pueden ser confusos. Un equilibrio debe lograrse entre la fidelidad y la facilidad de uso, la prevencin de que los usuarios realicen errores enteramente limita exploratorio de diseo.

Consistencia La consistencia es una medida de qu tan bien una visualizacin utiliza representaciones similares y la interaccin mecanismos para conceptos similares. Este sentido es uno de coherencia interna (ya sea un visualizacin es consistente con s mismo) en lugar de la coherencia con el modelo subyacente (Que llamamos fidelidad). En trminos de representacin, las visualizaciones consistentes pantalla similar conceptos de maneras similares. Por ejemplo, en UML, un objeto se representa siempre como un rectngulo con un nombre subrayado independientemente del contexto en el que aparece. UML no es perfectamente visualmente consistente, sin embargo: En la mayora de los diagramas, una lnea discontinua con cabeza de flecha abierta representa una dependencia, pero en un diagrama de secuencia, que representa una llamada asincrnica o mensaje. En trminos de interaccin, las visualizaciones compatibles permiten al usuario hacer semejante las cosas de maneras similares. Si al hacer doble clic en un elemento permite al usuario asignar un nombre 260 CAPTULO 7 VISUALIZACIN a ese elemento, lo que requiere que el usuario haga clic derecho y seleccionar una opcin de men para asignar un nombre a otro tipo de elemento sera incompatible.

En general, las visualizaciones ms consistentes son preferibles a las menos consistentes. La excepcin, una vez ms se produce en los extremos: Ser demasiado coherente podra causar una visualizacin de tener una variedad enorme y confusa de smbolos (para asegurarse de que no comparten dos conceptos un smbolo) o limitar la concisin de una visualizacin. Comprensibilidad Comprensin es una medida de qu tan fcil es para las partes interesadas para comprender y utilizar una visualizacin. Esto hace que la comprensibilidad una funcin tanto de la visualizacin y los interesados que lo utilizan. Muchos factores contribuyen a la inteligibilidad, incluyendo el informacin complejidad de la visualizacin y cmo se presenta, la complejidad de la interfaz de interaccin, y el conjunto de destrezas y experiencias previas de los grupos de inters. Una forma de mejorar la comprensibilidad es reducir el alcance de una visualizacin, limitING el nmero de conceptos que pretende dar a conocer y optimizar la visualizacin de slo estos conceptos. Tratando de mostrar demasiada informacin en conceptos relacionados vez o muchas Al mismo tiempo, dificulta la visualizacin y aumenta su complejidad. Alternativamente, la inteligibilidad de una visualizacin se puede mejorar mediante el aprovechamiento de los interesados conocimiento borde. Por ejemplo, utilizando un smbolo de componente UML para representar componentes en no-UML diagramas pueden hacer una visualizacin ms comprensible para las partes interesadas que ya tienen experiencia con UML. (Por supuesto, esto puede disparar de nuevo si los interesados traer supuestos sobre los componentes de UML que no se estn implcitos en el uso del smbolo.) Dinamismo Dinamismo es una medida de qu tan bien una visualizacin compatible con los modelos que cambian con el tiempo; en el captulo 6, estos se conocen como modelos dinmicos. La informacin sobre los flujos de dos cambios formas: cambios en el modelo (de cualquier fuente) se puede reflejar en la visualizacin y cambios en la visualizacin (a travs de uno de los mecanismos de interaccin) pueden ser reflejadas en el modelo. Una gama de posibilidades existe aqu. Una visualizacin dinmica ideal ser inmediatamente actualiza cuando cambia el modelo subyacente de cualquier fuente. Adicionalmente, los cambios en la visualizacin a travs de los mecanismos de interaccin debera provocar que el modelo que se actualizar en consecuencia.

En general, la representacin de un modelo dinmico implicar algn tipo de asncrona animacin, de lo contrario, la visualizacin sea incoherente con los cambios del modelo. La alternativa menos deseable es permitir al usuario actualizar manualmente la visualizacin, opcionalmente notificar al usuario cuando el modelo subyacente ha cambiado de modo que puedan realizar una renovacin operacin. Con respecto a la interaccin, cualquier visualizacin que permite la edicin debe ser, a En cierta medida, dinmico. Las visualizaciones que actualizan el modelo subyacente en tiempo real, como la trabaja el usuario, son preferidas a las que slo sincronizar los cambios de forma peridica o en la solicitud del usuario a travs de, por ejemplo, una operacin de almacenamiento.

Ver Coordinacin Coordinacin View es qu tan bien una visualizacin es (o puede ser) coordin con otros. En general, los entornos que permite visualizaciones mltiples para ser presentado y utilizado al mismo tiempo ofrecer a los usuarios una visin ms clara y la capacidad para disear o revisar una arquitectura. Sin embargo, la coordinacin de las visualizaciones mltiples no siempre es sencillo o fcil. Estrategias para la visualizacin de coordinacin se explican en su propia seccin de abajo. esttica La esttica es una medida de cun agradable es una visualizacin de sus usuarios. La esttica no se limita a la representacin, interfaces de usuario tienen cualidades estticas tambin. Aqu, la representacin es el aspecto y interaccin es la sensacin de la visualizacin. En comparacin con otras cualidades, cualidades estticas son extremadamente subjetiva. Sin embargo, existe una enorme cantidad de literatura disponible en la evaluacin y el diseo de pantallas estticamente agradables de informacin. esto viene tanto de la comunidad informtica (por ejemplo, el diseo de la interfaz de usuario) y de otras comunidades (arte, publicidad, marketing, etc.) Por ejemplo, la teora del color es instructivo en la eleccin de colores atractivos y complementarios para las visualizaciones grficas. La determinacin de qu colores son complementarios es fcil con una rueda de color bsico y algunos conocimiento de cmo se construyen los esquemas de color, pero es difcil utilizar la intuicin sola. Los tecnlogos tienen una tendencia a ignorar o suprimir las prioridades aspectos estticos de

la visualizanes, ya que generalmente agregan valor funcional poco. Sin embargo, las cualidades estticas pueden a menudo hacen la diferencia entre una visualizacin de ser aceptados o rechazados por la pousuarios potenciales. Extensibilidad La extensibilidad es una medida de lo fcil que es modificar una visualizacin para asumir nuevas capacidades, ya sea para representacin o interaccin. Al igual que los modelos subyacentes y notaciones son a menudo ampliado para dar soporte a dominios especficos del proyecto y los objetivos, las visualizaciones de esos modelos deben extenderse tambin. Una visualizacin que es difcil o imposible extender ser cada vez menos tiles como modelos subyacentes se expanden para asumir nuevos conceptos. Mecanismos de apoyo extensibles visualizaciones incluir plug-in API, scripting apoyo puerto, e incluso simplemente abra la subcontratacin el cdigo que implementa la visualizacin para que otros puede modificarlo. 7.2.2 Construccin de un Visualization Por ahora, debe quedar claro que los tipos de conceptos que puede ser capturado en una arquitectura tura son diversas y complejas. Se extienden a partir de componentes estructurales y conectores a sus interfaces a los horarios de acuerdo a la que se desarrollarn. Las partes interesadas optando por incluir estos elementos en sus arquitecturas tambin tendr que elegir la forma en que se representan y manipulada en varias visualizaciones. Si un preexistente o fuera de la plataforma de notacin se utiliza para capturar la arquitectura, su cannica visualizaciones estar disponible. Por ejemplo, UML capta la nocin de una clase y tiene un smbolo especfico utilizado para describir esa clase. Cuando las decisiones son capturados que no tienen una visualizacin cannica, o el canon visualizacin mdica es insuficiente o inadecuada, los interesados tienen la opcin de construir nuevas visualizaciones. La creacin de buenas visualizaciones es algo as como una forma de arte, pero hay algunas cosas que pueden ayudar. Toman prestados elementos de visualizaciones similares. Incluso si usted decide no utilizar UML para capturar su arquitectura, puede ser valiosa para prestar ciertos smbolos o convenciones de UML, tal como la forma de un paquete de smbolo para representar uno de los paquetes o la cerrado de cabeza blanca flecha para representar una relacin de generalizacin. Esto tiene la ventaja que muchos usuarios ya estn familiarizados con la descripcin y su significado. Sin embargo, hay

tambin desventajas: Los usuarios pueden asumir que sus diagramas son UML (cuando no lo son) o pueden asumir semntica especfica que no tena intencin de importar cuando se utiliza la smbolo. Una buena visualizacin ser lograr un equilibrio. Una buena fuente para los smbolos genricos que no cuenten con amplias implicaciones semnticas se diagramas de flujo. Aunque los diagramas de flujo han cado cada vez ms en desuso a medida que los programas se han vuelto ms complejas, Todava se entiende bien por una amplia variedad de usuarios. Smbolos comunes tiles diagramas de flujo fuera del contexto de diagramas de flujo incluyen el diamante (punto de decisin), el tambor vertical (Almacenamiento en disco), el tambor hacia un lado (almacenamiento de memoria), y as sucesivamente.

Sea consistente entre Visualizaciones. Si usted est representando el mismo concepto en muchos visualizaciones, uso similar simbologa. Del mismo modo, tratar de evitar el uso de la misma simbologa para representan conceptos diferentes en diferentes visualizaciones.

Dar significado a cada aspecto visual de los elementos. En un diagrama que representa muchos componentes, es tentador para asignar colores diferentes a los componentes slo por lo que el diagrama no se parece demasiado monocromtico. Si bien esto puede ser estticamente agradable, que es confuso de un perspectiva semntica ya que el aspecto visual del color no tiene ninguna relacin con el submentira modelo arquitectnico. Es una buena idea usar adornos visuales, pero cada decoracin debe tener un significado preciso. En una nota relacionada, los usuarios tienen una tendencia a (a menudo inconscientemente) incrustar verdadero semantic informacin en decoraciones visuales sin hacer que la informacin explcita en el modelo arquitectnico. Por ejemplo, en una representacin grfica de caja y flecha, un usuario podra coloque los componentes cerca uno del otro para indicar que compartan las mismas funciones o los arreglos los componentes en una forma de capas para reflejar una comprensin implcita de que hay capa similar a las dependencias de la arquitectura. Cuando esto ocurre (y las relaciones no son formalmente documentada), la informacin valiosa se incrusta y se pierde en la visualizacin. En este caso, las partes interesadas deberan considerar si estas relaciones visuales tienen semntica importancia y, en caso afirmativo, encontrar una manera de incluirlos explcitamente en los modelos del sistema. Documentar el significado de visualizaciones. Aunque a todos nos gusta pensar que nuestra

diagramas y otras visualizaciones se explican por s, este no suele ser el caso. Documenting lo que cada aspecto del diagrama significa, utilizando una leyenda, documento de diseo, o estndar de la organizacin es la clave para reducir la confusin entre los interesados. En el mejor de cada aspecto de la visualizacin debe corresponder a una pieza de informacin en el modelo. Saldo Interfaces tradicionales e innovadores. Es razonable suponer que la mayora de las partes interesadas involucrado en el diseo de software se han utilizado una cantidad significativa de software s mismos. Como hemos sealado, el endeudamiento conocida representacin y tcnicas de interaccin permite los usuarios aprovechar su experiencia previa. Sin embargo, demasiado con esta directriz resultar en el diseo de visualizacin estancada. De vez en cuando, considere til endeudamiento caractersticas de visualizacin no tradicionales e innovadores, as, o incluso el desarrollo de la propia. Por ejemplo, la mayora de los usuarios tendrn que asumir una caja y flecha grfico de visualizacin para una estructura de la arquitectura se ven y funcionan como el de PowerPoint o Visio. Sin embargo, se es casi seguro que no el caso en que PowerPoint y Visio han perfeccionado caja y flecha edicin grfica. En este caso, se podra considerar paradigmas de diseo avanzado, tales como diseos de ojo de pez, donde la informacin se muestra en tamaos grandes en el centro de la pantalla y en tamaos ms pequeos en los bordes o acceda-paradigmas, donde zoom in se utiliza como una metfora visual para

7.2 EVALUACIN DE 263 visualizaciones mirando a la informacin ms detallada. Una buena fuente de inspiracin en el diseo de visualizacin es otro paquete de software que estn fuera del mbito del diseo de software, tales como CAD aplicaciones, videojuegos, etc. Los aspirantes a diseadores de visualizacin debe tomar nota de inusuales, pero til interfaces de usuario que se enfrentan y determinar cmo aplicar los ideas para disear la arquitectura de visualizacin Edward Tufte, profesor emrito de la estadstica, diseo de informacin, diseo de interfaces, y poltica economa en la Universidad de Yale, es mejor conocido por una serie de libros influyentes, incluyendo el Visual Visualizacin de Informacin Cuantitativa (Tufte 2001) y de la Informacin de previsin (Tufte, 1990), que ofrecen consejos prcticos sobre cmo visualizar conjuntos de datos complejos para maximizar el impacto y la eficacia de ness. Mientras que el trabajo de Tufte se centra principalmente en las representaciones estticas de estadstica y cuantitativa datos, muchos de sus lecciones pueden ser tiles en el diseo y la evaluacin de la arquitectura de software visualizaciones as. Tufte enfoque se puede resumir como uno de parsimonia. Un concepto central en el trabajo de Tufte es maximizar la relacin de los datos-tinta-diseo de las representaciones que se centran en

representar los datos de destino y ayudas de interpretacin con tan pocas distracciones, decoraciones o adornos como sea posible. l acu el trmino "basura grfica" para referirse a estos elementos que desvirten la visualizacin de datos. Char tjunk puede ser obvio, el uso de colores sin sentido, sombras, fotografa o con textura se llena, y as sucesivamente. Grfico de basura tambin puede ser sutil-excesivamente audaces lneas de cuadrcula en un segundo plano, borde grueso alrededor de los elementos de datos que disminuyen la importancia percibida de los datos, y as sucesivamente. Para Tufte, representaciones grficas no son siempre ideales: Simple organizaciones textuales de datos (sobre todo las tablas) a menudo puede transmitir la misma informacin con menos "tinta" y mucho menos distracciones. Tufte defensa de parsimonia no equivale necesariamente al minimalismo, sin embargo. Muchos de los Ejemplos de Tufte, en particular cuando los conjuntos de datos complejos se utilizan, son extraordinariamente densa y mostrar mltiples propiedades de los datos simultneamente. Sin embargo, estas representaciones se siguen enfocando en gran medida de los propios datos. Informacin de previsin, en particular, profundiza en las cuestiones relacionadas con la mostrar de esos conjuntos de datos. En previsin de la Informacin, Tufte generalmente defiende el aumento de la dimensionalidad de repreresentations como una manera de tratar con datos complejos. Tufte abre lamentando las limitaciones de "Llanura", el espacio bidimensional proporcionado por pedazos de papel y las pantallas de ordenador. l presenta diferentes tipos de estrategias para salir de flatland, principalmente a travs de la integracin de adicionales de dimensiones espaciales o temporales en las representaciones. En un medio de dos dimensiones, porperspectiva se puede usar para crear imgenes tridimensionales espaciales. En el momento de la del libro publicacin en 1990, en tres dimensiones las tecnologas de renderizado an estaban algo inaccesibilidadbles ejemplos, y muchos en el libro muestran representaciones tridimensionales a mano por los artistas, aunque unos simples generadas por ordenador ejemplos aparecer tambin. Otra forma de aadir espacial dimensiones de flatland es a travs de capas: la ruptura de los datos en representaciones mltiples que son

combinadas o superpuestas una sobre otra. Las dimensiones temporales tambin pueden ser tenidos en cuenta por que muestra los mismos datos varias veces en diferentes estados, que representan diferentes instantneas en el tiempo. Dimensiones espaciales y temporales se pueden agregar a travs de un concepto Tufte llama "mltiples pequeos" mostrando muchas representaciones pequeas y simples de los datos relacionados con el (o los mismos datos en diferentes momentos) junto el uno al otro en sucesin, lo que facilita a los lectores comparar de un vistazo. Estas tcnicas (tridimensionales pinturas, capas, variacin del tiempo, y los pequeos multiples) pueden todos ser aplicado a la construccin de visualizaciones de arquitectura de software, aunque es cierto que algunas visualizaciones de aprovecharse de ellos hoy. Esto tambin representa un rea de investigacin en curso, por ejemplo, el proyecto de caballete (Hendrickson y van der Hoek 2007) se centra en traer conceptos interactivos capas de una arquitectura basada en xADL entorno de desarrollo. 264 CAPTULO 7 VISUALIZACIN Tufte trabajo se centra principalmente en las representaciones estticas de informacin, sino un conjunto de posibilidades se abre cuando la interactividad de una computadora es ejercida. Ordenadores, particularmente modernos PCs con procesadores rpidos, pantallas de alta resolucin en color, grficos y hardware especializado, puede ser usado para crear visualizaciones interactivas que proporcionan una an ms envolvente escapar de flatland. Aunque todava se limita a un fundamentalmente de dos dimensiones pantalla, tridimensional tecnologa de renderizacin ya est disponible para todos, y representaciones tridimensionales ya no han de permanecer fija en una pgina. Un usuario puede fcilmente tomar un modelo tridimensional y giran examinar y manipular en el espacio virtual desde cualquier ngulo utilizando una computadora. Tridimensional puntos de vista de arquitecturas de software an no han tenido un impacto general. Esto puede ser porque no son lo suficientemente maduro, o puede ser que simplemente no son tiles para describir la especie de datos que comprende un modelo arquitectnico. Proyectos como el caballete, antes citada, no slo romper arquitecturas hacia abajo en las capas, pero permiten la interaccin en vivo con esas capas, convirtindolos en y apagado, su utilizacin para expresar alternativas, y as sucesivamente. Animacin se ha utilizado de forma limitada a

proporcionar una dimensin temporal para visualizaciones arquitectnicas (por lo general visualizaciones efecto que resultado de algn tipo de simulacin), pero mucho ms trabajo que hay que hacer aqu tambin. Tufte y los diseadores de visualizaciones de arquitectura tienen mucho que aprender unos de otros. Trabajo de Tufte proporciona informacin valiosa sobre la informacin que representa mucho ms compleja que la media modelo arquitectnico en un medio muy limitado (esttica bidimensional del papel). Incluso con estas restricciones-y quiz a causa de ellas-que aboga por la explotacin de dimensiones que son an no es bien utilizado por las visualizaciones de arquitectura moderna. Por otra parte, la arquitectura visualizaciones, especialmente los ejecutados en un editor u otra herramienta, pueden explotar los recursos de los ordenadores rpidos con pantallas de alta resolucin para crear visualizaciones dinmicas mucho ms las que son posibles en el papel. Las personas que deseen disear nuevas visualizaciones (o evaluar existente onas) haran bien en absorber las lecciones Tufte y contextualizarlos en trminos de un sistema interactivo basado en ordenador medio 7.2.3 Coordinacin Visualizaciones Cuando visualizaciones mltiples de la misma informacin estn disponibles, es clave para coordinar estas visualizaciones unos con otros, por lo que los cambios a la informacin a travs de una visualizacin se reflejan con precisin en otras visualizaciones. Si las visualizaciones no estn coordinados, pueden llegar a ser fuera de sincrona y causar confusin. Es importante distinguir la coordinacin de las visualizaciones mltiples de mantenimiento consistencia arquitectnica. En este sentido, slo se trata de garantizar que las visualizaciones mltiples de la misma (partes de) el modelo arquitectnico estn al da con respecto al modelo. Las incoherencias y conflictos entre las decisiones de diseo almacenados en el modelo son un aparte cuestin. Las partes interesadas deben decidir cmo y cunto debe permitir que las visualizaciones mltiples para mostrar la misma informacin arquitectnico al mismo tiempo. Si los usuarios slo pueden ver informacin a travs de una visualizacin en un momento, las visualizaciones pueden ser sincronizados con el modelo arquitectnico cuando son llamados a filas. Tambin se puede asumir que el modelo no va a cambiar debido a alguna influencia externa mientras estn activos-los cambios en la modelo se realiza a travs de esta visualizacin nica. Sin embargo, si la misma informacin se puede visualizar en muchos aspectos al mismo tiempo, es generalmente una buena idea para sincronizar las visualizaciones en tiempo real para que se precisa representan el modelo subyacente. Esta situacin es mucho ms complicada, ya que todavisual

cin puede cambiar el modelo, y las otras visualizaciones debe responder adecuadamente a las que el cambio. Si las visualizaciones incluir tanto la representacin y la interaccin, entonces tanto el representacin y el estado de interaccin de las visualizaciones debe ser actualizada. Esto podra significar cambiar el modo de edicin, la actualizacin de las opciones del men, y as sucesivamente. Coordinacin de las visualizaciones mltiples se puede lograr a travs de muchos conocidos mtodos, dependiendo de la situacin. Para situaciones en las que la informacin puede ser visualizada a travs de slo una visualizacin en un momento, un simple mtodo de importacin y exportacin generalmente funciona mejor: Representaciones iniciales se crean cuando la visualizacin es llamado y almacenado (si es necesario) cuando la visualizacin es despedido. Situaciones en las mltiples visualizaciones simultneas permitidas son ms difciles de tratar con. En estos casos, cuatro estrategias de sincronizacin general estn disponibles (vase la figura 7-6): Peer-to-Peer. Las visualizaciones mantener sus propias copias de la informacin del modelo, saber el uno del otro y explcitamente notificarn mutuamente sobre los cambios. Estas estrategias puede ser quebradizo debido a que tienden a visualizaciones hermticamente par. Requieren punto-muchos a-punto dependencias. El nmero de dependencias es v (v-1) 2 en donde v es el nmero de visualizaciones. Esta crece exponencialmente a medida que aumenta el nmero de visualizaciones. Porque de esto, la estrategia peer-to-peer es ms adecuado para un pequeo nmero fijo de visualizaciones elegido de antemano. Master-Slave. Una visualizacin es principalmente responsable de la interaccin con el modelo repositorio, y sirve como el "maestro" visualizacin. Otras visualizaciones esclavos coordinar a travs de este maestro, ya sea a travs de una estrategia de empuje o de traccin basado(ver ms abajo). Esto funciona bien cuando la visualizacin es un auxiliar a otro, por ejemplo, imaginar un editor grfico donde la ventana principal muestra una versin de zoom en la de una parte de la arquitectura, pero la esquina de la ventana se reparti apagan para mostrar una miniatura de toda la arquitectura al mismo tiempo (para proporcionar un contexto para el usuario o que sirve como ayuda de navegacin). Pull-Based. Cada visualizacin repetidamente consulta un modelo comn para los cambios y actualizaciones en consecuencia. Esto puede suceder manualmente a peticin del usuario, automticamente a peri- intervalos dica, o en respuesta a determinadas acciones (por ejemplo, cuando el usuario

hace clic sobre un nuevo visualizacin o intentos de hacer un cambio a una visualizacin diferente). Una desventaja de traccin basados en estrategias es que pueden mostrar fuera de la fecha de la informacin hasta que ellos realizan un accionamiento por traccin. Basadas en extraccin estrategias se pueden utilizar cuando el repositorio de modelo es totalmente pasiva (por ejemplo, una estructura de datos que no enva eventos cuando se cambia, o un base de datos del sistema sin triggers). Cuando las actualizaciones de visualizacin son computacionalmente gasSIVE, pull-basados estrategias se pueden utilizar para limitar la frecuencia se actualizan las visualizaciones. Adems, si slo una visualizacin es realmente visible a la vez, puede que no sea conveniente para actualizar una visualizacin hasta que el usuario lo llama. Push-Based. Las visualizaciones son notificados y en consecuencia que se actualicen cada vez que el cambios en el modelo. Las notificaciones son generalmente de multidifusin a travs de visualizaciones asncrono eventos. Esta es la estrategia empleada por el patrn modelo-vista-controlador. Push-basado estrategias mantener todas las visualizaciones al da. Estas estrategias funcionan bien cuando mltiples visualizaciones se presentan al usuario simultneamente. En situaciones en las que se organiza la arquitectura en mltiples (parcial) modelos, es a veces posible coordinar el acceso a estos modelos a travs de una visualizacin nica, lo enmascarar algunas de las diferencias entre notaciones o la combinacin de la fuerza de mltiples visualizaciones. La Figura 7-7 muestra una arquitectura cuyo componente-y-conector estructura se expresa en xADL 2,0, pero el diseo detallado de cada componente se expresa en UML.

7.2.4 Ms all del diseo: uso de la visualizacin dinmica Como se mencion anteriormente, las visualizaciones de arquitectura se utilizan principalmente para representar y permitir inter-accin con las decisiones de diseo que componen una arquitectura. Sin embargo, ms avanzadosy visualizaciones dinmicas se puede utilizar para obtener una comprensin ms profunda de la arquitectura. Ahora introducimos el concepto de visualizacin de efectos. Definicin. Una visualizacin efecto es una visualizacin que no representa archi-decisiones arquitectnica de diseo directamente, sino que representa los efectos de edificios y estructuras decisiones de diseo.