1. L A A R Q U I T E C T U R A S O F T W A R E . E L M O D E L O 4 + 1
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. Perry y Wolf (1992) describen una arquitectura
software como:
Arquitectura Software = {Elementos, Formas, Fundamento/Restricciones}
Es muy complejo capturar la arquitectura software en un sólo modelo (o
diagrama). Para manejar esta complejidad se representan diferentes aspectos y
características de la arquitectura en múltiples vistas. Una vista es “una presentación
de un modelo, la cual es una descripción completa de un sistema desde una particular
perspectiva” (Kruchten, 1995). El modelo más aceptado a la hora de establecer las
vistas necesarias para describir una arquitectura software es el modelo 4+1
(Kruchten, 1995).
Este modelo define 4 vistas principlaes:
Vista Lógica (Logical View), modelo de objetos, clases, entidad – relación, etc.
Vista de Proceso (Process View), modelo de concurrencia y sincronización.
Vista de Desarrollo (Development View), organización estática del software en su
entorno de desarrollo (librerías, componentes, .ear, .jar, etc.).
Vista Física (Physical View), modelo de correspondencia software - hardware
(aspectos de distribución en máquinas, por ejemplo)

2. Figura 1. Modelo de vistas 4+1
Y una vista más, la "+1", que se muestra y traza en cada una de las anteriores y que
está formada por las necesidades funcionales que cubre el sistema, y que en ocasiones
identificamos como vista de "casos de uso". De donde deducimos que según este
modelo, la arquitectura es en realidad evolucionada desde escenarios
El modleo 4+1 aplica la ecuación de Perry y Wolf (1992) de forma independiente para
cada vista, por ejemplo, cada vista puede definir un conjunto de elementos para su uso
(componentes, contenedores y conectores).
Cada vista es descrita usando su particular y más adecuada notación (por ejemplo,
existen diagramas UML que se adaptan más a una vista que otra). Para cada vista los
arquitectos pueden escoger cierto esquilo arquitectónico (patrón arquitectónico),
permitiendo la coexistencia de múltiples estilos en un sistema.

3. Y por último, también comentar que el modelo de vistas “4+1” es “genérico”: otras
notaciones y herramientas a parte de UML pueden usarse, y cualquier método de
diseño, especialmente para las descomposiciones lógicas y de proceso.
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).

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

5. 4. Arquitectura Física (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.

6. 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. A modo de
resumen la translación se presenta en la siguiente tabla:
Vista UML
Escenarios Casos de Uso
Lógica Clases, de Estados y Colaboración
Desarrollo Componentes
Física Despliegue
Procesos Actividad, Estados, Secuencia
Programación Orientada a Objetos
Actualmente una de las áreas más candentes en la industria y en el ámbito académico
es la orientación a objetos. La orientación a objetos promete mejoras de amplio
alcance en la forma de diseño, desarrollo y mantenimiento del software ofreciendo
una solución a largo plazo a los problemas y preocupaciones que han existido desde el
comienzo en el desarrollo de software: la falta de portabilidad del código y
reusabilidad, código que es difícil de modificar, ciclos de desarrollo largos y técnicas
de codificación no intuitivas.
Un lenguaje orientado a objetos ataca estos problemas. Tiene tres características
básicas: debe estar basado en objetos, basado en clases y capaz de tener herencia de
clases. Muchos lenguajes cumplen uno o dos de estos puntos; muchos menos cumplen
los tres. La barrera más difícil de sortear es usualmente la herencia.
El concepto de programación orientada a objetos (OOP) no es nuevo, lenguajes
clásicos como SmallTalk se basan en ella. Dado que la OOP. Se basa en la idea natural

7. de la existencia de un mundo lleno de objetos y que la resolución del problema se
realiza en términos de objetos, un lenguaje se dice que está basado en objetos si
soporta objetos como una característica fundamental del mismo.
El elemento fundamental de la OOP es, como su nombre lo indica, el objeto. Podemos
definir un objeto como un conjunto complejo de datos y programas que poseen
estructura y forman parte de una organización.
Esta definición especifica varias propiedades importantes de los objetos. En primer
lugar, un objeto no es un dato simple, sino que contiene en su interior cierto número
de componentes bién estructurados. En segundo lugar, cada objeto no es un ente
aislado, sino que forma parte de una organización jerárquica o de otro tipo.
ESTRUCTURA DE UN OBJETO
Un objeto puede considerarse como una especie de cápsula dividida en tres partes:
1 - RELACIONES
2 - PROPIEDADES
3 - METODOS
Cada uno de estos componentes desempeña un papel totalmente independiente:
Las relaciones permiten que el objeto se inserte en la organización y están formadas
esencialmente por punteros a otros objetos.
Las propiedades distinguen un objeto determinado de los restantes que forman parte
de la misma organización y tiene valores que dependen de la propiedad de que se
trate. Las propiedades de un objeto pueden ser heredadas a sus descendientes en la
organización.
Los métodos son las operaciones que pueden realizarse sobre el objeto, que
normalmente estarán incorporados en forma de programas (código) que el objeto es
capaz de ejecutar y que también pone a disposición de sus descendientes a través de
la herencia.
Encapsulamiento y ocultación
Como hemos visto, cada objeto es una estructura compleja en cuyo interior hay datos
y programas, todos ellos relacionados entre sí, como si estuvieran encerrados

8. conjuntamente en una cápsula. Esta propiedad (encapsulamiento), es una de las
características fundamentales en la OOP.
Los objetos son inaccesibles, e impiden que otros objetos, los usuarios, o incluso los
programadores conozcan cómo está distribuída la información o qué información hay
disponible. Esta propiedad de los objetos se denomina ocultación de la información.
Esto no quiere decir, sin embargo, que sea imposible conocer lo necesario respecto a
un objeto y a lo que contiene. Si así fuera no se podría hacer gran cosa con él. Lo que
sucede es que las peticiones de información a un objeto. deben realizarse a través de
mensajes dirigidos a él, con la orden de realizar la operación pertinente. La respuesta
a estas ordenes será la información requerida, siempre que el objeto considere que
quien envía el mensaje está autorizado para obtenerla.
El hecho de que cada objeto sea una cápsula facilita enormemente que un objeto
determinado pueda ser transportado a otro punto de la organización, o incluso a otra
organización totalmente diferente que precise de él. Si el objeto ha sido bien
construído, sus métodos seguirán funcionando en el nuevo entorno sin problemas. Esta
cualidad hace que la OOP sea muy apta para la reutilización de programas.
Organización de los objetos
En principio, los objetos forman siempre una organización jerárquica, en el sentido de
que ciertos objetos son superiores a otros de cierto modo.
Existen varios tipos tipos de jerarquías: serán simples cuando su estructura pueda ser
representada por medio de un "arbol". En otros casos puede ser más compleja.
En cualquier caso, sea la estructura simple o compleja, podrán distinguirse en ella tres
niveles de objetos.
-La raíz de la jerarquía. Se trata de un objeto único y especial. Este se caracteríza
por estar en el nivel más alto de la estructura y suele recibir un nombre muy genérico,
que indica su categoría especial, como por ejemplo objeto madre, Raíz o Entidad.
-Los objetos intermedios. Son aquellos que descienden directamente de la raíz y que a
su vez tienen descendientes. Representan conjuntos o clases de objetos, que pueden
ser muy generales o muy especializados, según la aplicación. Normalmente reciben
nombres genéricos que denotan al conjunto de objetos que representan, por ejemplo,

9. VENTANA, CUENTA, FICHERO. En un conjunto reciben el nombre de clases o tipos si
descienden de otra clase o subclase.
-Los objetos terminales. Son todos aquellos que descienden de una clase o subclase y
no tienen descendientes. Suelen llamarse casos particulares, instancias o ítems porque
representan los elementos del conjunto representado por la clase o subclase a la que
pertenecen.
Veamos ahora en detalle los tres elementos mencionados en "Estructura de un
Objeto".
1. RELACIONES
Las relaciones entre objetos son, precisamente, los enlaces que permiten a un objeto
relacionarse con aquellos que forman parte de la misma organización.
Las hay de dos tipos fundamentales:
-Relaciones jerárquicas. Son esenciales para la existencia misma de la aplicación
porque la construyen. Son bidireccionales, es decir, un objeto es padre de otro cuando
el primer objeto se encuentra situado inmediatamente encima del segundo en la
organización en la que ambos forman parte; asimismo, si un objeto es padre de otro, el
segundo es hijo del primero (en la fig. 2, B es padre de D,E y F, es decir, D,E y F son
hijos de B; en la fig. 3, los objetos B y C son padres de F, que a su vez es hijo de
ambos).
Una organización jerárquica simple puede definirse como aquella en la que un objeto
puede tener un solo padre, mientras que en una organizacion jerárquica compleja un
hijo puede tener varios padres).
-Relaciones semánticas. Se refieren a las relaciones que no tienen nada que ver con la
organización de la que forman parte los objetos que las establecen. Sus propiedades y
consecuencia solo dependen de los objetos en sí mismos (de su significado) y no de su
posición en la organización.
Se puede ver mejor con un ejemplo: supongamos que vamos a construir un diccionario
informatizado que permita al usuario obtener la definición de una palabra cualquiera.
Supongamos que, en dicho diccionario, las palabras son objetos y que la organización
jerárquica es la que proviene de forma natural de la estructura de nuestros
conocimientos sobre el mundo.

10. La raíz del diccionario podría llamarse TEMAS. De éste término genérico descenderán
tres grandes ramas de objetos llamadas VIDA, MUNDO y HOMBRE. El primero (vida)
comprenderá las ciencias biológicas: Biología y Medicina. El segundo (mundo), las
ciencias de la naturaleza inerte: las Matemáticas, la Física, la Química y la Geología. El
tercero (hombre) comprenderá las ciencias humanas: la Geografía, la Historia, etc.
La relación es, evidentemente, semántica, pués no establece ninguna connotación
jerárquica entre NEWTON y OPTICA y su interpretación depende exclusivamente del
significado de ambos objetos.
La existencia de esta relación nos permitirá responder a preguntas como:
¿Quién trabajó en óptica?
¿En qué trabajó Newton?
¿Quien trabajó en Física?
Las dos primeras se deducen inmediatamente de la existencia de la relación trabajo.
Para la tercera observamos que si Newton trabajó en óptica automáticamente
sabemos que trabajó en Física, por ser óptica una rama de la Física (en nuestro
diccionario, el objeto OPTICA es hijo del objeto FISICA). Entonces gracias a la OOP
podemos responder a la tercera pregunta sin necesidad de establecer una relación
entre NEWTON y FISICA, apoyandonos sólo en la relación definida entre NEWTON
y OPTICA y en que OPTICA es hijo de FISICA. De este modo se elimina toda
redundancia innecesaria y la cantidad de información que tendremos que definir para
todo el diccionario será mínima.
2. PROPIEDADES
Todo objeto puede tener cierto número de propiedades, cada una de las cuales tendrá,
a su vez, uno o varios valores. En OOP, las propiedades corresponden a las clásicas
"variables" de la programación estructurada. Son, por lo tanto, datos encapsulados
dentro del objeto, junto con los métodos (programas) y las relaciones (punteros a
otros objetos). Las propiedades de un objeto pueden tener un valor único o pueden
contener un conjunto de valores más o menos estructurados (matrices, vectores,
listas, etc.). Además, los valores pueden ser de cualquier tipo (numérico, alfabético,
etc.) si el sistema de programación lo permite.

11. Pero existe una diferencia con las "variables", y es que las propiedades se pueden
heredar de unos objetos a otros. En consecuencia, un objeto puede tener una
propiedad de maneras diferentes:
-Propiedades propias. Están formadas dentro de la cápsula del objeto.
-Propiedades heredadas. Estan definidas en un objeto diferente, antepasado de éste
(padre,"abuelo", etc.). A veces estas propiedades se llaman propiedad miembro porque
el objeto las posee por el mero hecho de ser miembro de una clase.
3. METODOS
Una operación que realiza acceso a los datos. Podemos definir método como un
programa procedimental o procedural escrito en cualquier lenguaje, que está asociado
a un objeto determinado y cuya ejecución sólo puede desencadenarse a través de un
mensaje recibido por éste o por sus descendientes.
Son sinónimos de 'método' todos aquellos términos que se han aplicado
tradicionalmente a los programas, como procedimiento, función, rutina, etc. Sin
embargo, es conveniente utilizar el término 'método' para que se distingan claramente
las propiedades especiales que adquiere un programa en el entorno OOP, que afectan
fundamentalmente a la forma de invocarlo (únicamente a través de un mensaje) y a su
campo de acción, limitado a un objeto y a sus descendientes, aunque posiblemente no a
todos.
Si los métodos son programas, se deduce que podrían tener argumentos, o parámetros.
Puesto que los métodos pueden heredarse de unos objetos a otros, un objeto puede
disponer de un método de dos maneras diferentes:
-Métodos propios. Están incluidos dentro de la cápsula del objeto.
-Métodos heredados. Están definidos en un objeto diferente, antepasado de éste
(padre, “abuelo", etc.). A veces estos métodos se llaman método miembro porque el
objeto los posee por el mero hecho de ser miembro de una clase.
Polimorfismo
Una de las características fundamentales de la OOP es el polimorfismo, que no es otra
cosa que la posibilidad de construir varios métodos con el mismo nombre, pero con
relación a la clase a la que pertenece cada uno, con comportamientos diferentes. Esto
conlleva la habilidad de enviar un mismo mensaje a objetos de clases diferentes. Estos

12. objetos recibirían el mismo mensaje global pero responderían a él de formas
diferentes; por ejemplo, un mensaje "+" a un objeto ENTERO significaría suma,
mientras que para un objeto STRING significaría concatenación ("pegar" strings uno
seguido al otro)
Demonios
Es un tipo especial de métodos, relativamente poco frecuente en los sistemas de OOP,
que se activa automáticamente cuando sucede algo especial. Es decir, es un programa,
como los métodos ordinarios, pero se diferencia de estos porque su ejecución no se
activa con un mensaje, sino que se desencadena automáticamente cuando ocurre un
suceso determinado: la asignación de un valor a una propiedad de un objeto, la lectura
de un valor determinado, etc.
Los demonios, cuando existen, se diferencian de otros métodos por que no son
heredables y porque a veces están ligados a una de las propiedades de un objeto, mas
que al objeto entero.
CONSIDERACIONES FINALES
Beneficios que se obtienen del desarrollo con OOP
Día a día los costos del Hardware decrecen. Así surgen nuevas áreas de aplicación
cotidianamente: procesamiento de imágenes y sonido, bases de datos multimedia les,
automatización de oficinas, ambientes de ingeniería de software, etc. Aún en las
aplicaciones tradicionales encontramos que definir interfaces hombre-máquina "a-la-
Windows" suele ser bastante conveniente.
Lamentablemente, los costos de producción de software siguen aumentando; el
mantenimiento y la modificación de sistemas complejos suele ser una tarea trabajosa;
cada aplicación, (aunque tenga aspectos similares a otra) suele encararse como un
proyecto nuevo, etc.
Todos estos problemas aún no han sido solucionados en forma completa. Pero como los
objetos son portables (teóricamente) mientras que la herencia permite la reusabilidad
del código orientado a objetos, es más sencillo modificar código existente porque los
objetos no interaccionan excepto a través de mensajes; en consecuencia un cambio en
la codificación de un objeto no afectará la operación con otro objeto siempre que los
métodos respectivos permanezcan intactos. La introducción de tecnología de objetos
como una herramienta concepual para analizar, diseñar e implementar aplicaciones

13. permite obtener aplicaciones más modificables, fácilmente entendibles y a partir de
componentes reusables. Esta reusabilidad del código disminuye el tiempo que se utiliza
en el desarrollo y hace que el desarrollo del software sea más intuitivo porque la gente
piensa naturalmente en términos de objetos más que en términos de algoritmos de
software.
Problemas derivados de la utilización de OOP en la actualidad
Un sistema orientado a objetos, por lo visto, puede parecer un paraíso virtual. El
problema sin embargo surge en la implementación de tal sistema. Muchas compañías
oyen acerca de los beneficios de un sistema orientado a objetos e invierten gran
cantidad de recursos luego comienzan a darse cuenta que han impuesto una nueva
cultura que es ajena a los programadores actuales. Específicamente los siguientes
temas suelen aparecer repetidamente:
Curvas de aprendizaje largas. Un sistema orientado a objetos ve al mundo en una
forma única. Involucra la conceptualización de todos los elementos de un programa,
desde subsistemas a los datos, en la forma de objetos. Toda la comunicación entre los
objetos debe realizarse en la forma de mensajes. Esta no es la forma en que están
escritos los programas orientados a objetos actualmente; al hacer la transición a un
sistema orientado a objetos la mayoría de los programadores deben capacitarse
nuevamente antes de poder usarlo.
Dependencia del lenguaje. A pesar de la portabilidad conceptual de los objetos en un
sistema orientado a objetos, en la práctica existen muchas dependencias. Muchos
lenguajes orientados a objetos están compitiendo actualmente para dominar el
mercado. Cambiar el lenguaje de implementación de un sistema orientado a objetos no
es una tarea sencilla; por ejemplo C++ soporta el concepto de herencia multiple
mientras que SmallTalk no lo soporta; en consecuencia la elección de un lenguaje tiene
ramificaciones de diseño muy importamtes.
Determinacion de las clases. Una clase es un molde que se utiliza para crear nuevos
objetos. En consecuencia es importante crear el conjunto de clases adecuado para un
proyecto. Desafortunadamente la definición de las clases es más un arte que una
ciencia. Si bien hay muchas jerarquías de clase predefinidas usualmente se deben
crear clases específicas para la aplicación que se este desarrollando. Luego, en 6
meses ó 1 año se da cuenta que las clases que se establecieron no son posibles; en ese
caso será necesario reestructurar la jerarquía de clases devastando totalmente la
planificación original.

14. Performance. En un sistema donde todo es un objeto y toda interaccion es a través de
mensajes, el tráfico de mensajes afecta la performance. A medida que la tecnología
avanza y la velocidad de microprocesamiento, potencia y tamaño de la memoria
aumentan, la situacion mejorará; pero en la situación actual, un diseño de una
aplicación orientada a objetos que no tiene en cuenta la performance no será viable
comercialmente.
Idealmente, habría una forma de atacar estos problemas eficientemente al mismo
tiempo que se obtienen los beneficios del desarrollo de una estrategia orientada a
objetos. Deberia existir una metodología fácil de aprender e independiente del
lenguaje, y facil de reestructurar que no drene la performance del sistema.
Diagramació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.
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

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

16. 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”.
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)
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).
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.

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

18. 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.
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.
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.
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.
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.
Actividades Y Casos De Uso
1 La experiencia y práctica de quien hace los diagramas y su respectiva descripción
marca el punto de vista o tendencia, que genera una manera particular de poner
énfasis en determinados elementos. Por ejemplo si soy un desarrollador, veo en todas
partes menús, tablas, opciones, clics y demás elementos es decir no analizo un
problema y doy su solución sino que de una vez pienso en como debería correr la
apliación.

19. 2. El modelo de casos de uso, permite hacer una mejor toma de requerimientos y
clarificar la funcionalidad del sistema, es decir que espera el usuario que haga el
sistema, no tanto como lo haga o con que.
3. Por lo tanto una descripción de un caso de uso específico se debe orientar hacia que
es lo que ese usuario haría allí en interacción con un sistema.
Por lo tanto si tiene un caso de uso llamado “Registrar inventario”, en la descripción no
puede tener un paso que diga “el usuario registra el inventario” y listo, puesto que eso
es precisamente lo que le preguntan, como se registra, (los pasos), los datos que se
manipulan y que operaciones se hacen con ellos.
Para que posteriormente un desarrollador pueda crear las pantallas y menús…
Recuerde que usted como tecnologo o ingeniero, entra a ser parte de un equipo, no lo
hace todo usted y los demás necesitan especifaciones claras para poder hacer su
trabajo.
Una buena descripción de casos de uso, en relación con un buen modelo de clases
facilita inmediatamente los diagras de secuencias y actividades y por lo tanto
favorecen un óptimo desarrollo de la aplicación.
Interfaces De Usuario
En el contexto del proceso de interacción persona-ordenador, la interfaz gráfica de
usuario, es el artefacto tecnológico de un sistema interactivo que posibilita, a través
del uso y la representación del lenguaje visual, una interacción amigable con un sistema
informático.
La interfaz gráfica de usuario (en inglés Graphical User Interface, GUI) es un tipo de
interfaz de usuario que utiliza un conjunto de imágenes y objetos gráficos para
representar la información y acciones disponibles en la interfaz. Habitualmente las
acciones se realizan mediante manipulación directa para facilitar la interacción del
usuario con la computadora.
Surge como evolución de la línea de comandos de los primeros sistemas operativos y es
pieza fundamental en un entorno gráfico.

20. Como ejemplo de interfaz gráfica de usuario podemos citar el escritorio o desktop del
sistema operativo Windows y el entorno X-Window de Linux.
Diseño de la Logica
El diseño lógico es el proceso de construir un esquema de la información que utiliza la
empresa, basándose en un modelo de base de datos específico, independiente del
SGBD concreto que se vaya a utilizar y de cualquier otra consideración física.
En esta etapa, se transforma el esquema conceptual en un esquema lógico que utilizará
las estructuras de datos del modelo de base de datos en el que se basa el SGBD que
se vaya a utilizar, como puede ser el modelo relacional, el modelo de red, el modelo
jerárquico o el modelo orientado a objetos. Conforme se va desarrollando el esquema
lógico, éste se va probando y validando con los requisitos de usuario.
La normalización es una técnica que se utiliza para comprobar la validez de los
esquemas lógicos basados en el modelo relacional, ya que asegura que las relaciones
(tablas) obtenidas no tienen datos redundantes. Esta técnica se presenta en el
capítulo dedicado al diseño lógico de bases de datos.
El esquema lógico es una fuente de información para el diseño físico. Además, juega un
papel importante durante la etapa de mantenimiento del sistema, ya que permite que
los futuros cambios que se realicen sobre los programas de aplicación o sobre los
datos, se representen correctamente en la base de datos.
Tanto el diseño conceptual, como el diseño lógico, son procesos iterativos, tienen un
punto de inicio y se van refinando continuamente. Ambos se deben ver como un
proceso de aprendizaje en el que el diseñador va comprendiendo el funcionamiento de
la empresa y el significado de los datos que maneja. El diseño conceptual y el diseño
lógico son etapas clave para conseguir un sistema que funcione correctamente. Si el
esquema no es una representación fiel de la empresa, será difícil, sino imposible,
definir todas las vistas de usuario (esquemas externos), o mantener la integridad de la
base de datos. También puede ser difícil definir la implementación física o el
mantener unas prestaciones aceptables del sistema. Además, hay que tener en cuenta
que la capacidad de ajustarse a futuros cambios es un sello que identifica a los buenos
diseños de bases de datos. Por todo esto, es fundamental dedicar el tiempo y las
energías necesarias para producir el mejor esquema que sea posible.

21. Nombre delos alumnos:
García Fonseca Oscar Francisco.
Nombre de la maestra:
Venancio Ledezma Israel.
Materia:
Desarrollo de proyectos de software.
Grado: Grupo:
8º “A”
Trabajo:
Unidad 1 y 2.