La Arquitectura De 41 VistasArquitectura de SoftwareLa arquitectura software trata el diseño e implementación de la estruc...
(Physical Architecture) La vista física se centra en los requisitos no funcionales, talescomo la disponibilidad del sistem...
La representación se ha usado desde los comienzos del diseño de software, en forma deorganigramas, diagramas de flujo de d...
El segundo grupo de diagramas (wireframe, mockup o prototype) tienen el objetivo de“mostrar el contenido de las páginas” (...
Aplicaciones software que no fueron ideadas específicamente para hacer diagramas:Corel Draw (http://www.corel.com)Adobe [a...
Garrett Dimon creó basándose en la propuesta de Dan Brown una serie de iconos para elproceso de diagramación: http://v1.ga...
Para hacer los diagramas de funcionamiento y los diagramas de presentación seproponen otros iconos más trabajados visualme...
Brown, Dan. The Visual Vocabulary Three Years Later: An Interview with Jesse JamesGarrett. Disponible en: http://www.boxes...
Upcoming SlideShare
Loading in …5
×

La arquitectura de 41 vistas

426 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
426
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
7
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

La arquitectura de 41 vistas

  1. 1. La Arquitectura De 41 VistasArquitectura de SoftwareLa arquitectura software trata el diseño e implementación de la estructura de alto niveldel software. Es el resultado de ensamblar un cierto número de elementosarquitectónicos para satisfacer la funcionalidad y ejecución de los requisitos del sistema;así como los requisitos no funcionales del mismo: fiabilidad, escalabilidad, portabilidad,disponibilidad, etc.1. Arquitectura Lógica (Logical Architecture) Soporta el análisis y la especificaciónde los requisitos funcionales: lo que el sistema debería proporcionar en términos deservicios a sus usuarios. El sistema se descompone en un conjunto de abstraccionesclave tomadas mayormente del dominio del problema, en forma de objetos o clases. Enesta vista se usan comúnmente los diagramas de clases, los de interacción y objetos.Notación: La notación más usada es UML, y dentro de esta diagramas de clases ypaquetes. Estilo: El estilo más usado para la vista lógica es el Orientado a Objetos. 2.Arquitectura de Procesos (Process Architecture) Se tratan algunos requisitos nofuncionales. Ejecución, disponibilidad, tolerancia a fallos, integridad, etc. Esta vistatambién especifica que hilo de control ejecuta cada operación identificada en cada claseidentificada en la vista lógica. La vista se centra por tanto en la concurrencia ydistribución de procesos. Notación: La notación más usada es UML, y dentro de estadiagramas estados, actividad y similares. Estilo: pueden encajar varios estilos. Porejemplo, tomando la taxonomía de Garlan y Shaw (1993), pueden usarse tuberías yfiltros (pipes and filtres) o Cliente – Servidor (con variantes de múltiples clientes –simple servidor y múltiples clientes – múltiples servidores). Para sistemas máscomplejos puede usarse un estilo similar a la ISIS system’s process groups, comodescribe Kenneth Birman (1994) . 3. Arquitectura de Desarrollo (Development Architecture) La vista de desarrollo odespliegue se enfoca en la organización de los módulos software en el entorno dedesarrollo. El software es empaquetado en pequeños trozos (librerías de programa,subsistemas, componentes, etc.), los subsistemas se organizan en capas jerárquicas, ycada capa proporciona una interfaz bien definida a sus capas superiores La vista dedesarrollo toma por tanto requisitos internos relacionados con facilidad de desarrollo,gestión del software (reparto de requisitos, trabajo del equipo), evaluación de costes,planificación, monitorización del progreso del proyecto, reutilización, portabilidad,seguridad y restricciones impuestas por las herramientas o por el lenguaje deprogramación Esta organización del software se suele apoyar en diagramas de móduloso de subsistemas que muestran las relaciones de exportación (export) e importación(import). Y destacar que podrá describirse la vista de desarrollo por completosolamente después de haber identificado todos los elementos software. Notación: Lanotación más usada es UML, y dentro de esta diagramas de componentes y paquetes.Estilo: se recomienda definir de cuatro a seis capas de subsistemas en la vista dedesarrollo. Una regla de diseño es que un subsistema puede solamente depender desubsistemas en la misma capa o en las menores. Esto minimiza las dependencias entremódulos a favor de una más simple estrategia capa – capa. 4. Arquitectura Física
  2. 2. (Physical Architecture) La vista física se centra en los requisitos no funcionales, talescomo la disponibilidad del sistema, la fiabilidad (tolerancia a fallos), ejecución yescalabilidad. Y también presenta cómo los procesos, objetos, etc., corresponden anodos de proceso: Componentes: nodos de proceso. Conectores: LAN, WAN, bus, etc.Contenedores: subsistemas físico Varias configuraciones físicas pueden usarse. Lacorrespondencia de el software a los nodos debe ser altamente flexible y tener elmínimo impacto en el código fuente. 5. Escenarios (Scenarios) La vista deescenarios corresponde con instancias de casos de uso que unifican todas las vistas. Así,desde casos de uso se debiera poder hacer una trazabilidad a todos los componentes delsis tema software, viendo, por ejemplo, que máquinas, o clases, o componentes, o .jar, oprocesos, son los responsables de que el sistema cubra una cierta funcionalidad. 6.Relación entre las vistas Como sucede en otras muchas ocasiones, si bien el modelo noes una metodología si que “sugiere” un método de trabajo. Parece lógico que la vista deescenarios o casos de uso sea la de arranque, y que de ahí se pase a la vista lógica.Desde la vista lógica afrontaremos la de desarrollo y procesos, una vez que tenemos porejemplo las clases definiremos maneras de agruparlas y modos de ejecución. Para contodo concluir en la vista física. Todo ello, obviamente, con sus correspondientes ytípicas iteraciones. 7. Arquitectura y UML Se ha ido exponiendo a lo largo de laexplicación de cada una de las vistas su translación a un lenguaje de modelado concretocomo UML. Hya que tener en cuenta que UML nace casi a la vez que el modelo 4+1,por lo que en un origen no existía una clara relación entre ambos, lo que amenudoproduce confusión al diseñador que en la actualidad quiere modelar una arquitectura conambas herramientas.DiagramacionIntroducciónEl primer paso en el diseño de objetos o procesos es la representación mediantediagramas de su estructura, funcionamiento y comportamiento, concretando así lasprimeras ideas abstractas. En el caso de productos interactivos con interfaz, como porejemplo los sitios web, esta interfaz también es objeto de diagramación, especificandocuál será la organización y estructuración visual de los diferentes elementos.Los diagramas se deben realizar a partir de la información recogida durante las etapasde investigación de la audiencia, en las que se estudia a los usuarios con el objetivo decrear un producto que satisfaga sus necesidades.En qué consiste la diagramaciónLa diagramación, a la cual nos referimos, consiste en la representación de loscontenidos que tendrá un producto digital, y las relaciones entre dichos contenidos.Desde sus orígenes los seres humanos representaron escenas de caza, danzas rituales yotros aspectos de su vida. La representación forma parte de la naturaleza cognitivahumana, y es lógico que el hombre, en su devenir histórico, haya usado esta capacidadpara plasmar en algún soporte, ideas concebidas mentalmente.
  3. 3. La representación se ha usado desde los comienzos del diseño de software, en forma deorganigramas, diagramas de flujo de datos, árboles de decisión, etc. Al evolucionar lasinterfaces gráficas de usuario, las labores de representación se ampliaron con losllamados guiones de navegación y guiones de interacción, los cuales consistían endiagramas que representaban el funcionamiento de los productos electrónicos que segeneraban en ese momento.La evolución de los productos digitales, unida al crecimiento geométrico de lainformación que soportan, ha originado la necesidad de ampliar estas formas derepresentación con otras nuevas, o de enriquecer las existentes. Es por esto que se hageneralizado el uso de los esquemas de representación entre arquitectos de información,enfocados a los aspectos organizativos y representativos de la información.Hay que señalar que durante el proceso de Arquitectura de Información se usan otrasformas de representación, con diferentes objetivos. Por ejemplo, en la aplicación de latécnica de Card Sorting se pueden generar dendogramas y gráficos de escalamientomultidimensional; otro ejemplo serían las representaciones de las estructuras mentalesde los usuarios tras una tormenta de ideas (brainstorming); o los organigramas de laempresa por la cual se crea el producto digital.Los diagramas a los que se refiere este artículo son los que se usan en arquitectura deinformación para proponer cómo será el producto final. Esencialmente se refieren a laorganización de los contenidos del producto, al funcionamiento básico del mismo, y laubicación que tendrán estos contenidos en la interfaz.Los autores angloparlantes, pioneros en los temas del diseño y representación delsoftware, dividen estos diagramas en 2 tipos:BlueprintsWireframesComo sustituto del término Blueprint a veces se usa el de Architecture Map, quesignifica Mapa de Arquitectura.También como término similar a wireframe se usan otros términos como mockup yprototype (maqueta y prototipo). (Rosenfeld & Morville, Wodtke, Snyder)El primer grupo de diagramas (blueprints), tiene como objetivo representar “lasprincipales áreas de organización y rotulado” (Rosenfeld & Morville), y están enfocadosa los aspectos estructurales y de funcionamiento del producto. Generalmente serepresentan con textos, cajas y flechas.Estos planos o blueprints parten de lo general a lo particular, de lo abstracto a loconcreto. Su función es explicitar iterativamente las decisiones de diseño, con elobjetivo de comunicar dichas decisiones al resto de miembros del equipo de desarrollo,o al cliente final.Christina Wodtke conceptualiza los Blueprint como: “Un plano de diseño es justamenteuna buena idea llevada a la realidad a través de la escritura”.
  4. 4. El segundo grupo de diagramas (wireframe, mockup o prototype) tienen el objetivo de“mostrar el contenido de las páginas” (Rosenfeld & Morville), concretando loselementos que se plantearon en los primeros planos (blueprints) y ubicándolos en laspáginas o pantallas del producto final.Este segundo grupo de diagramas están comprendidos como prototipos de bajafidelidad, ya que se realizan en “blanco y negro” y no muestran el diseño gráfico delproducto ni la funcionalidad de sus códigos de programación.Los niveles de prototipos son:Prototipos de baja fidelidad o estáticos (wireframes, mockup)Prototipos de fidelidad intermedia (diseño gráfico)Prototipos de alta fidelidad o dinámicos (Web, HTML)Figura 1: Representación de la diagramaciónEstos tipos de diagramas se realizan también de forma iterativa con el usuario y demásmiembros del equipo de desarrollo.Aunque para la realización de estos diagramas existen aplicaciones softwareespecializadas, también es posible realizarlos en papel (paper prototype).Figura 2: Fotografía de realización de diagramas manuscritos.Software para hacer diagramasExisten diferentes aplicaciones software que se utilizan para la confección dediagramas. Para una mejor comprensión de los mismos se han clasificado en 2 grupos:los que originalmente fueron ideados para hacer diagramas, y los que originalmente nofueron pensados para diagramación, pero que también pueden usarse con este objetivoya que son poderosas herramientas de diseño gráfico.Algunas aplicaciones software que fueron ideadas para hacer diagramas:Smart Draw? (http://www.smartdraw.com)Microsoft Visio (http://www.microsoft.com)iGrafx Flowcharter (http://www.igrafx.de)DENIM & Silk. (http://guir.berkeley.edu/projects/denim/)Mindmanager (http://www.mindjet.com)Freemind (http://freemind.sourceforge.net/)Omni Graffle? (OSX) (http://www.omnigroup.com)
  5. 5. Aplicaciones software que no fueron ideadas específicamente para hacer diagramas:Corel Draw (http://www.corel.com)Adobe [antes Macromedia] Freehand (http://www.adobe.com)Adobe Illustrator (http://www.adobe.com)Sistemas de diagramación en la AIUna notación muy usada por arquitectos de información y diseñadores de interacciónpara hacer la diagramación de sitios web es la propuesta por Jesse James Garret(http://www.jjg.net), y que consiste, según el propio autor, en un “vocabulario visualpara describir arquitectura de información y diseño de interacción” (Garret, trad.Velasco. 2002). El sistema de diagramación está compuesto de símbolos geométricos,flechas y líneas.El vocabulario visual de Garret es muy útil para representar tanto el diseño deinteracción, como la estructura conceptual y organizativa del contenido. (Garret, trad.Velasco. 2002).Esta notación gráfica está concebida para realizar un diseño de lo general a lo concreto,ya que sigue el principio de la simplificación de representación a partir de cajas (boxes)y flechas (arrows). Este principio es el que le facilita a cualquier diseñador comunicararquitecturas de información de forma fácilmente comprensible.A visual vocabulary for describing information architecture and interaction design.http://www.jjg.net/ia/visvocab/Otra propuesta es la de Bill Scout, especialista de diseño de interacción de la empresaYahoo!. Este vocabulario es muy completo, por la variedad de símbolos que ofrece.Storyboarding rich internet applications with Visio.http://www.boxesandarrows.com/view/storyboarding_rich_internet_applications_with_visioYAHOO! http://billsportfolio.comLooks Good Works Well: Visio Wireframe Toolkit for Downloadhttp://looksgoodworkswell.blogspot.com/2005/11/visio-wireframe-toolkit-for-download.htmlPor otro lado Dan Brown propone otro vocabulario muy útil para la distribución de loselementos dentro de las pantallas. http://www.greenonions.comWhere the Wireframes Are: Special Deliverable #3.http://www.boxesandarrows.com/view/where_the_wireframes_are_special_deliverable_3
  6. 6. Garrett Dimon creó basándose en la propuesta de Dan Brown una serie de iconos para elproceso de diagramación: http://v1.garrettdimon.com/resources/templates-stencils-for-visio-omnigraffleLa propuesta de Nick Finck también es diversa y útil en la confección de diagramaspara sitios web. http://www.nickfinck.com/stencils.htmlPeter Van Dijk’s es autor de otra propuesta que se puede encontrar en:http://iabook.com/template.htmJoaquín Márquez Correa propone una serie de gráficos en Visio para la realización dediagramas:http://www.jmarquez.com/documentos/jmarquez%20wireframe%20shapes.zipEl Instituto de AI agrupa varias herramientas para diagramar y hacer arquitectura deinformación en general. Contiene propuestas para el software Omnigraffle, Ilustrador yVisio. http://iainstitute.org/en/learn/tools.phpUn propuesta propiaA partir de la experiencia del autor, se propone un sistema de diagramación con unanotación que va de lo general a lo concreto, conformada por figuras ampliamenteutilizadas por los creadores de productos digitales desde tiempos pasados.Se proponen tres tipos de diagramas de acuerdo a las funciones principales que cumpleun arquitecto de información en el diseño de un producto digital:Diagramas de organización. (planos - blueprints)Diagramas de funcionamiento. (planos avanzados - blueprints)Diagramas de presentación. (maquetas - wireframes)Esta clasificación no significa que estos diagramas sean excluyentes. Debe existir unainterrelación entre los mismos, de manera que cada diagrama creado complemente alanterior, y se convierta en apoyo de los siguientes. Igualmente la división por grupos deestos diagramas no significa que haya que hacer rígidamente tres.Además, esta propuesta no excluye a ningún otro modelo de diagramación.Perfectamente podría complementarse con el vocabulario visual de Garret, con lapropuesta de Dan Brown, o cualquier otro modelo de los anteriormente mostrados.Propuesta de iconosPara hacer los diagramas de organización se proponen una serie de iconos simples,iguales que los que propone Garret. Se basan en cajas y flechas o conectores.Figura 3: Iconos para realizar diagramas de organización
  7. 7. Para hacer los diagramas de funcionamiento y los diagramas de presentación seproponen otros iconos más trabajados visualmente, con el objetivo de representar elcomportamiento interactivo del producto.Figura 4: Iconos para realizar diagramas de funcionamiento y diagramas depresentaciónPropuesta de diagramas Los diagramas de organización consisten en la representaciónde los grupos organizados, y de los elementos básicos que contienen, siendo el diagramabásico para entender la estructura general del producto.Figura 5: Diagrama de organizaciónEl diagrama de funcionamiento es la representación de las estructuras con los flujos denavegación. Este diagrama tiene un nivel de acabado superior al anterior y complementaal mismo. Debe ser el que muestre los niveles de navegación así como los tipos denavegación en el producto.Figura 6: Diagrama de funcionamientoEl diagrama de presentación es el que debe mostrar las formas de organización visual delos contenidos en las páginas principales, por ejemplo: la página inicial, las páginasinteriores, páginas de productos, etc. Este diagrama no pretende representar el diseñográfico o diseño visual en detalle, sino especificar el esqueleto organizativo de lainterfaz.Figura 7: Diagrama de presentaciónConclusiones Los diagramas son mecanismos esenciales en la arquitectura deinformación de sitios web, libros electrónicos, sistema de información, etc.Esta técnica alivia el coste de producción, al ser más fácil y económico rectificar undiseño sobre el “papel” que sobre el producto implementado.Aunque existen formas de diagramación desarrolladas por diversos autores, la propuestade nuevas formas complementa las anteriores y contribuye a la creación de formasfuturas.Dos versiones de la propuesta de iconos:Microsoft Visio: elrodri.vss [115 kb]Adobe Ilustrator: elrodri.ai [34 Kb]BibliografíaBrown, Dan. Representing data in Wireframes. Disponible en:http://www.greenonions.com/portfolio/dbrown_ia2005_wireframes.pdf (consultado:mayo 2006)
  8. 8. Brown, Dan. The Visual Vocabulary Three Years Later: An Interview with Jesse JamesGarrett. Disponible en: http://www.boxesandarrows.com/view/… (consultado:diciembre 2005)Brown, Dan. Where the Wireframes Are: Special Deliverable #3. Disponible en:http://www.boxesandarrows.com/view/where_the_wireframes_are_special_deliverable_3 (consultado: enero 2006)Garret, Jesse James. A visual vocabulary for describing information architecture andinteraction design. (enero 2001). Disponible en: http://www.jjg.net/ia/visvocab/(consultado: febrero 2005)Garret, Jesse James. Un vocabulario visual para describir arquitectura de información ydiseño de interacción. Traducción: Javier Velasco (marzo 2002). Disponible en:http://www.jjg.net/ia/visvocab/spanish.html (consultado: abril 2005)Océano Grupo Editorial. Enciclopedia didáctica de computación. Madrid: OcéanoGrupo Editorial, 1998Olsen, Henrik. Visio - the interaction designer’s nail gun. How to use Visio for rapidprototyping. Disponible en: http://www.guuui.com/issues/02_03_02.php (consultado:junio 2007)Ronda León, Rodrigo. Productos electrónicos: principios y pautas. Editorial FélixVarela, La Habana, 2005Rosenfeld, Louis & Morville, Peter. Information architecture for the World Wide Web.O’Reilly & Associates. 1998.Scott, Bill. Storyboarding Rich Internet Applications with Visio. Disponible en:http://www.boxesandarrows.com/view/storyboarding_rich_internet_applications_with_visio. (consultado: enero 2007)Zinder, Carolyn. Paper prototyping. The fast end easy way to design and refine userinterfaces. Morgan Kaufman, 1ra edición, abril 2003.Wodtke, Christina. Information architecture, blueprints for the web. New Riders,octubre 2002.

×