1. La Arquitectura De 41 Vistas
Arquitectura de Software
La arquitectura software trata el diseño e implementación de la estructura de alto nivel
del software. Es el resultado de ensamblar un cierto número de elementos
arquitectó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ón
de los requisitos funcionales: lo que el sistema debería proporcionar en términos de
servicios a sus usuarios. El sistema se descompone en un conjunto de abstracciones
clave tomadas mayormente del dominio del problema, en forma de objetos o clases. En
esta 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 y
paquetes. 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 no
funcionales. Ejecución, disponibilidad, tolerancia a fallos, integridad, etc. Esta vista
también especifica que hilo de control ejecuta cada operación identificada en cada clase
identificada en la vista lógica. La vista se centra por tanto en la concurrencia y
distribución de procesos. Notación: La notación más usada es UML, y dentro de esta
diagramas estados, actividad y similares. Estilo: pueden encajar varios estilos. Por
ejemplo, tomando la taxonomía de Garlan y Shaw (1993), pueden usarse tuberías y
filtros (pipes and filtres) o Cliente – Servidor (con variantes de múltiples clientes –
simple servidor y múltiples clientes – múltiples servidores). Para sistemas más
complejos puede usarse un estilo similar a la ISIS system’s process groups, como
describe Kenneth Birman (1994) .
3. Arquitectura de Desarrollo (Development Architecture) La vista de desarrollo o
despliegue se enfoca en la organización de los módulos software en el entorno de
desarrollo. El software es empaquetado en pequeños trozos (librerías de programa,
subsistemas, componentes, etc.), los subsistemas se organizan en capas jerárquicas, y
cada capa proporciona una interfaz bien definida a sus capas superiores La vista de
desarrollo 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 de
programación Esta organización del software se suele apoyar en diagramas de módulos
o de subsistemas que muestran las relaciones de exportación (export) e importación
(import). Y destacar que podrá describirse la vista de desarrollo por completo
solamente después de haber identificado todos los elementos software. Notación: La
notació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 de
desarrollo. Una regla de diseño es que un subsistema puede solamente depender de
subsistemas en la misma capa o en las menores. Esto minimiza las dependencias entre
módulos a favor de una más simple estrategia capa – capa. 4. Arquitectura Física

2. (Physical Architecture) La vista física se centra en los requisitos no funcionales, tales
como la disponibilidad del sistema, la fiabilidad (tolerancia a fallos), ejecución y
escalabilidad. Y también presenta cómo los procesos, objetos, etc., corresponden a
nodos de proceso: Componentes: nodos de proceso. Conectores: LAN, WAN, bus, etc.
Contenedores: subsistemas físico Varias configuraciones físicas pueden usarse. La
correspondencia de el software a los nodos debe ser altamente flexible y tener el
mínimo impacto en el código fuente. 5. Escenarios (Scenarios) La vista de
escenarios 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 del
sis tema software, viendo, por ejemplo, que máquinas, o clases, o componentes, o .jar, o
procesos, 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 no
es una metodología si que “sugiere” un método de trabajo. Parece lógico que la vista de
escenarios 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 por
ejemplo las clases definiremos maneras de agruparlas y modos de ejecución. Para con
todo concluir en la vista física. Todo ello, obviamente, con sus correspondientes y
típicas iteraciones. 7. Arquitectura y UML Se ha ido exponiendo a lo largo de la
explicación de cada una de las vistas su translación a un lenguaje de modelado concreto
como 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 amenudo
produce confusión al diseñador que en la actualidad quiere modelar una arquitectura con
ambas herramientas.
Diagramacion
Introducción
El primer paso en el diseño de objetos o procesos es la representación mediante
diagramas de su estructura, funcionamiento y comportamiento, concretando así las
primeras ideas abstractas. En el caso de productos interactivos con interfaz, como por
ejemplo los sitios web, esta interfaz también es objeto de diagramación, especificando
cuá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 etapas
de investigación de la audiencia, en las que se estudia a los usuarios con el objetivo de
crear un producto que satisfaga sus necesidades.
En qué consiste la diagramación
La diagramación, a la cual nos referimos, consiste en la representación de los
contenidos que tendrá un producto digital, y las relaciones entre dichos contenidos.
Desde sus orígenes los seres humanos representaron escenas de caza, danzas rituales y
otros aspectos de su vida. La representación forma parte de la naturaleza cognitiva
humana, y es lógico que el hombre, en su devenir histórico, haya usado esta capacidad
para plasmar en algún soporte, ideas concebidas mentalmente.

3. La representación se ha usado desde los comienzos del diseño de software, en forma de
organigramas, diagramas de flujo de datos, árboles de decisión, etc. Al evolucionar las
interfaces gráficas de usuario, las labores de representación se ampliaron con los
llamados guiones de navegación y guiones de interacción, los cuales consistían en
diagramas que representaban el funcionamiento de los productos electrónicos que se
generaban en ese momento.
La evolución de los productos digitales, unida al crecimiento geométrico de la
información que soportan, ha originado la necesidad de ampliar estas formas de
representación con otras nuevas, o de enriquecer las existentes. Es por esto que se ha
generalizado 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 otras
formas de representación, con diferentes objetivos. Por ejemplo, en la aplicación de la
técnica de Card Sorting se pueden generar dendogramas y gráficos de escalamiento
multidimensional; otro ejemplo serían las representaciones de las estructuras mentales
de los usuarios tras una tormenta de ideas (brainstorming); o los organigramas de la
empresa 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 de
información para proponer cómo será el producto final. Esencialmente se refieren a la
organización de los contenidos del producto, al funcionamiento básico del mismo, y la
ubicación que tendrán estos contenidos en la interfaz.
Los autores angloparlantes, pioneros en los temas del diseño y representación del
software, dividen estos diagramas en 2 tipos:
Blueprints
Wireframes
Como sustituto del término Blueprint a veces se usa el de Architecture Map, que
significa Mapa de Arquitectura.
También como término similar a wireframe se usan otros términos como mockup y
prototype (maqueta y prototipo). (Rosenfeld & Morville, Wodtke, Snyder)
El primer grupo de diagramas (blueprints), tiene como objetivo representar “las
principales áreas de organización y rotulado” (Rosenfeld & Morville), y están enfocados
a los aspectos estructurales y de funcionamiento del producto. Generalmente se
representan con textos, cajas y flechas.
Estos planos o blueprints parten de lo general a lo particular, de lo abstracto a lo
concreto. Su función es explicitar iterativamente las decisiones de diseño, con el
objetivo 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 justamente
una buena idea llevada a la realidad a través de la escritura”.

4. El segundo grupo de diagramas (wireframe, mockup o prototype) tienen el objetivo de
“mostrar el contenido de las páginas” (Rosenfeld & Morville), concretando los
elementos que se plantearon en los primeros planos (blueprints) y ubicándolos en las
páginas o pantallas del producto final.
Este segundo grupo de diagramas están comprendidos como prototipos de baja
fidelidad, ya que se realizan en “blanco y negro” y no muestran el diseño gráfico del
producto 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ón
Estos tipos de diagramas se realizan también de forma iterativa con el usuario y demás
miembros del equipo de desarrollo.
Aunque para la realización de estos diagramas existen aplicaciones software
especializadas, también es posible realizarlos en papel (paper prototype).
Figura 2: Fotografía de realización de diagramas manuscritos.
Software para hacer diagramas
Existen diferentes aplicaciones software que se utilizan para la confección de
diagramas. 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 no
fueron pensados para diagramación, pero que también pueden usarse con este objetivo
ya 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. 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 AI
Una notación muy usada por arquitectos de información y diseñadores de interacción
para 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 visual
para 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 de
interacció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 comunicar
arquitecturas 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 empresa
Yahoo!. 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_
visio
YAHOO! http://billsportfolio.com
Looks Good Works Well: Visio Wireframe Toolkit for Download
http://looksgoodworkswell.blogspot.com/2005/11/visio-wireframe-toolkit-for-
download.html
Por otro lado Dan Brown propone otro vocabulario muy útil para la distribución de los
elementos dentro de las pantallas. http://www.greenonions.com
Where the Wireframes Are: Special Deliverable #3.
http://www.boxesandarrows.com/view/where_the_wireframes_are_special_deliverable_
3

6. Garrett Dimon creó basándose en la propuesta de Dan Brown una serie de iconos para el
proceso de diagramación: http://v1.garrettdimon.com/resources/templates-stencils-for-
visio-omnigraffle
La propuesta de Nick Finck también es diversa y útil en la confección de diagramas
para sitios web. http://www.nickfinck.com/stencils.html
Peter Van Dijk’s es autor de otra propuesta que se puede encontrar en:
http://iabook.com/template.htm
Joaquín Márquez Correa propone una serie de gráficos en Visio para la realización de
diagramas:
http://www.jmarquez.com/documentos/jmarquez%20wireframe%20shapes.zip
El Instituto de AI agrupa varias herramientas para diagramar y hacer arquitectura de
información en general. Contiene propuestas para el software Omnigraffle, Ilustrador y
Visio. http://iainstitute.org/en/learn/tools.php
Un propuesta propia
A partir de la experiencia del autor, se propone un sistema de diagramación con una
notación que va de lo general a lo concreto, conformada por figuras ampliamente
utilizadas por los creadores de productos digitales desde tiempos pasados.
Se proponen tres tipos de diagramas de acuerdo a las funciones principales que cumple
un 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 una
interrelación entre los mismos, de manera que cada diagrama creado complemente al
anterior, y se convierta en apoyo de los siguientes. Igualmente la división por grupos de
estos 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 la
propuesta de Dan Brown, o cualquier otro modelo de los anteriormente mostrados.
Propuesta de iconos
Para 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. Para hacer los diagramas de funcionamiento y los diagramas de presentación se
proponen otros iconos más trabajados visualmente, con el objetivo de representar el
comportamiento interactivo del producto.
Figura 4: Iconos para realizar diagramas de funcionamiento y diagramas de
presentación
Propuesta de diagramas Los diagramas de organización consisten en la representación
de los grupos organizados, y de los elementos básicos que contienen, siendo el diagrama
básico para entender la estructura general del producto.
Figura 5: Diagrama de organización
El diagrama de funcionamiento es la representación de las estructuras con los flujos de
navegación. Este diagrama tiene un nivel de acabado superior al anterior y complementa
al mismo. Debe ser el que muestre los niveles de navegación así como los tipos de
navegación en el producto.
Figura 6: Diagrama de funcionamiento
El diagrama de presentación es el que debe mostrar las formas de organización visual de
los contenidos en las páginas principales, por ejemplo: la página inicial, las páginas
interiores, páginas de productos, etc. Este diagrama no pretende representar el diseño
gráfico o diseño visual en detalle, sino especificar el esqueleto organizativo de la
interfaz.
Figura 7: Diagrama de presentación
Conclusiones Los diagramas son mecanismos esenciales en la arquitectura de
informació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 un
diseño sobre el “papel” que sobre el producto implementado.
Aunque existen formas de diagramación desarrolladas por diversos autores, la propuesta
de nuevas formas complementa las anteriores y contribuye a la creación de formas
futuras.
Dos versiones de la propuesta de iconos:
Microsoft Visio: elrodri.vss [115 kb]
Adobe Ilustrator: elrodri.ai [34 Kb]
Bibliografía
Brown, Dan. Representing data in Wireframes. Disponible en:
http://www.greenonions.com/portfolio/dbrown_ia2005_wireframes.pdf (consultado:
mayo 2006)

8. Brown, Dan. The Visual Vocabulary Three Years Later: An Interview with Jesse James
Garrett. 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 and
interaction 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 y
diseñ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éano
Grupo Editorial, 1998
Olsen, Henrik. Visio - the interaction designer’s nail gun. How to use Visio for rapid
prototyping. 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élix
Varela, La Habana, 2005
Rosenfeld, 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 user
interfaces. Morgan Kaufman, 1ra edición, abril 2003.
Wodtke, Christina. Information architecture, blueprints for the web. New Riders,
octubre 2002.