1. INSTITUTO UNIVERSITARIO DE TECNOLOGIA
DE ADMINISTRACION INDUSTRIAL
ESPECIALIDAD: INFORMATICA
SECCION: 204-A-3
UNIDAD CURRICULAR: DISEÑO DE SISTEMA
DISEÑO DE LA ARQUITECTURA DE UN SISTEMA
Profesora: Autores:
Naydrubys Trejo Navarro José 17.603.195
Vásquez Jhonderson 20.595.241
Luis Sánchez 20.208.521
Guarenas, Julio del 2011

2. Introducción
A continuación se presenta todo lo referente a lo que es el diseño de la
arquitectura de un sistema de información, la cual es importante saber para
un diseñador de sistema para mayor conocimientos tomaremos este
concepto en cuenta.
La etapa del diseño de la arquitectura se refiere a la planificación del
hardware, software, y a la infraestructura de comunicaciones para el nuevo
sistema, así como a la seguridad y al apoyo global.
También se toma en cuenta que los programadores, diseñadores, ingenieros
y analistas pueden trabajar bajo una línea común que les posibilite la
compatibilidad necesaria para lograr el objetivo deseado.
Algunos objetivos dentro de un esquema de Arquitectura de Software pueden
ser: el software se debe mantener, esto es, fácilmente analizable,
modificable, corregible; también puede ser un objetivo el nivel de interacción
con otros sistemas informáticos, o su escalabilidad.

3. Desarrollo
Diseño de la arquitectura del sistema
La etapa del diseño de la arquitectura se refiere a la planificación del
hardware, software, y a la infraestructura de comunicaciones para el nuevo
sistema, así como a la seguridad y al apoyo global. La primera etapa de
diseño de la arquitectura consiste en determinar el tipo de arquitectura del
sistema: basada-en-el-servidor (served-based), basada-en-el-cliente (client-
based) o cliente-servidor (client-server).
Arquitectura de sistema de información
Es la disciplina y arte encargada del estudio, análisis, organización,
disposición y estructuración de la información en espacios de información, y
de la selección y presentación de los datos en los sistemas de información
interactivos y no interactivos.
La Arquitectura de la Información trata indistintamente del diseño de: sitios
web, interfaces de dispositivos móviles o gadgets (como los lectores de
mp3), CDs interactivos, videoclips digitales, relojes, tableros de instrumentos
de aviones de combate o civiles, interfaces de máquinas dispensadoras,
interfaces de juegos electrónicos, etc. (Laverde, A. 2005)
Su principal objetivo es facilitar al máximo los procesos de comprensión y
asimilación de la información, así como las tareas que ejecutan los usuarios
en un espacio de información definido.
Arquitectura de software
Las técnicas metodológicas desarrolladas con el fin de facilitar la
programación se engloban dentro de la llamada Arquitectura de Software o
Arquitectura lógica. Se refiere a un grupo de abstracciones y patrones que
nos brindan un esquema de referencia útil para guiarnos en el desarrollo de
software dentro de un sistema informático.
Así, los programadores, diseñadores, ingenieros y analistas pueden
trabajar bajo una línea común que les posibilite la compatibilidad necesaria
para lograr el objetivo deseado.

4. Algunos objetivos dentro de un esquema de Arquitectura de Software pueden
ser: el software debe ser mantenible, esto es, fácilmente analizable,
modificable, corregible; también puede ser un objetivo el nivel de interacción
con otros sistemas informáticos, o su escalabilidad.
Estas Arquitecturas están definidas muchas veces por el tipo de tecnología a
la cual se enfrenta un programador o grupo de programadores, por lo cual
algunos tipos de arquitectura son más recomendables que otras para ciertas
tecnologías.
Cada tarea de computación es asignada a una computadora, por lo cual una
Arquitectura determinada debe ser implementada físicamente y definir de
forma abstracta los componentes que tomarán arte en las tareas y sus
interfaces comunicativas.
Todo esto se desarrolla a "alto nivel", ensamblando elementos para lograr la
mayor funcionalidad posible siendo a la vez portable, logrando disponibilidad,
escalabilidad y confiabilidad.
Como ejemplos de Arquitecturas podemos citar las monolíticas (los grupos
funcionales del software están altamente acoplados entre sí), cliente-servidor
(se reparte la carga de cómputo en dos partes independientes), y la
arquitectura de tres niveles (la carga se divide entre tres partes:
presentación, cálculo y almacenamiento).
Estilos de arquitectura sistema de información
Cliente/Servidor
La arquitectura cliente-servidor consiste básicamente en un cliente que
realiza peticiones a otro programa (el servidor) que le da respuesta. Aunque
esta idea se puede aplicar a programas que se ejecutan sobre una sola
computadora es más ventajosa en un sistema
operativo multiusuario distribuido a través de una red de computadoras.
En esta arquitectura la capacidad de proceso está repartida entre los clientes
y los servidores, aunque son más importantes las ventajas de tipo
organizativo debidas a la centralización de la gestión de la información y la
separación de responsabilidades, lo que facilita y clarifica el diseño del
sistema.
La separación entre cliente y servidor es una separación de tipo lógico,
donde el servidor no se ejecuta necesariamente sobre una sola máquina ni
es necesariamente un sólo programa. Los tipos específicos
de servidores incluyen los servidores web, los servidores de archivo, los

5. servidores del correo, etc. Mientras que sus propósitos varían de unos
servicios a otros, la arquitectura básica seguirá siendo la misma.
Una disposición muy común son los sistemas multicapa en los que el
servidor se descompone en diferentes programas que pueden ser ejecutados
por diferentes computadoras aumentando así el grado de distribución del
sistema.
La arquitectura cliente-servidor sustituye a la arquitectura monolítica en la
que no hay distribución, tanto a nivel físico como a nivel lógico.
La red cliente-servidor es aquella red de comunicaciones en la que todos los
clientes están conectados a un servidor, en el que se centralizan los diversos
recursos y aplicaciones con que se cuenta; y que los pone a disposición de
los clientes cada vez que estos son solicitados. Esto significa que todas las
gestiones que se realizan se concentran en el servidor, de manera que en él
se disponen los requerimientos provenientes de los clientes que tienen
prioridad, los archivos que son de uso público y los que son de uso
restringido, los archivos que son de sólo lectura y los que, por el contrario,
pueden ser modificados, etc. Este tipo de red puede utilizarse conjuntamente
en caso de que se esté utilizando en una red mixta.
Peer to peer
Una red Peer-to-Peer o red de pares o red entre iguales o red entre
pares o red punto a punto (P2P, por sus siglas en inglés) es una red de
computadoras en la que todos o algunos aspectos funcionan
sin clientes ni servidores fijos, sino una serie de nodos que se comportan
como iguales entre sí. Es decir, actúan simultáneamente como clientes y
servidores respecto a los demás nodos de la red. Las redes P2P permiten el
intercambio directo de información, en cualquier formato, entre los
ordenadores interconectados.
El hecho de que sirvan para compartir e intercambiar información de forma
directa entre dos o más usuarios ha propiciado que parte de los usuarios lo
utilicen para intercambiar archivos cuyo contenido está sujeto a las leyes
de copyright, lo que ha generado una gran polémica entre defensores y
detractores de estos sistemas.
Las redes peer-to-peer aprovechan, administran y optimizan el uso
del ancho de banda de los demás usuarios de la red por medio de la
conectividad entre los mismos, y obtienen así más rendimiento en las
conexiones y transferencias que con algunos métodos centralizados

6. convencionales, donde una cantidad relativamente pequeña de servidores
provee el total del ancho de banda y recursos compartidos para un servicio o
aplicación.
Dichas redes son útiles para diversos propósitos. A menudo se usan para
compartir ficheros de cualquier tipo (por ejemplo, audio, vídeo o software).
Este tipo de red también suele usarse en telefonía VoIP para hacer más
eficiente la transmisión de datos en tiempo real.
La eficacia de los nodos en el enlace y transmisión de datos puede variar
según su configuración local (cortafuegos, NAT, ruteadores, etc.), velocidad
de proceso, disponibilidad de ancho de banda de su conexión a la red y
capacidad de almacenamiento en disco.
De comunicación
Al hablar de redes y de comunicaciones entre ordenadores resultan
fundamentales 2 conceptos: Protocolos y Arquitectura de comunicación.
Los protocolos se utilizan para la comunicación entre entidades de diferentes
sistemas. Ejemplos de entidades son programas de aplicación de usuario,
paquetes de transferencia de ficheros, sistemas de manejo de BD y
terminales. Ejemplo de sistemas son ordenadores, terminales y sensores
remotos. Podemos decir, que una entidad es algo capaz de enviar o de
recibir información y un sistema es un objeto que contiene una o más
entidades. Para que 2 entidades puedan comunicarse han de hablar el
mismo idioma, mediante una serie de convenciones entre estas, a este
conjunto de convenciones se le denomina protocolo, que puede definirse
como el conjunto de reglas que gobiernan el intercambio de datos entre 2
entidades.
En la realidad, la transferencia de datos desde una capa n de una máquina a
la capa n de otra máquina no se realiza directamente, sino que los datos son
pasados a la capa inmediatamente inferior de la máquina y así
sucesivamente hasta llegar a la capa 1, donde nos encontramos el medio
físico, por donde se realiza la comunicación con la otra máquina.
Entre cada par de capas adyacentes hay una interfaz, la cual define los
servicios y operaciones primitivas que la capa inferior ofrece a la superior. Al
conjunto de capas con las interfaces y protocolos recibe el nombre
de arquitectura de la red.

7. De capas y partición
La metodología RPM presentada por C. Larman presupone una estructura de
tres capas que es típica de los Sistemas de Información. Estas tres capas
son:
• La capa de la Presentación
Esta capa reúne todos los aspectos del software que tiene que ver con
las interfaces y la interacción con los diferentes tipos de usuarios
humanos Estos aspectos típicamente incluyen el manejo y aspecto de
las ventanas, el formato de los reportes, menúes, gráficos y
elementos multimedia en general.
• La capa del Dominio de la Aplicación
Esta capa reúne todos los aspectos del software que tienen que
automatizan o apoyan los procesos de negocio que llevan a cabo los
usuarios. Estos aspectos típicamente incluyen las tareas que forman
parte de los procesos, las reglas y restricciones que aplican.
• La capa del Repositorio
Esta capa reúne todos los aspectos del software que tienen que ver
con el manejo de los datos persistentes, por lo que también se le
denomina la capa de las Bases de Datos).
En toda arquitectura de capa los elementos agrupados en una misma capa
pueden comunicarse entre sí; pero existen variantes en cuanto a las
comunicaciones permitidas entre elementos de capas diferentes:

8. 1. Arquitectura top-down de capas:
Los elementos de una capa i+1 pueden enviar solicitudes de servicio a
elementos de la capa inferior i. Típicamente se produce
una cascada de solicitudes, es decir para satisfacer una solicitud a
una capa i+2, ésta requiere enviar varias solicitudes a la capa i+1;
cada una de estas solicitudes a la capa i+1 genera a su vez un
conjunto de solicitudes a la capa i y así sucesivamente. Una
arquitectura top-down es laxa (o no estricta) si los elementos de una
capa i+1 pueden enviar solicitudes de servicio directamente a un
elemento de cualquiera de las i capas inferiores.
2. Arquitectura bottom-up de capas:
Cada elemento de una capa i puede notificar a elementos de la capa
superior i+1 de que ha ocurrido algún evento de interés (ej.
manejadores de dispositivos). La capa i+1 puede juntar varios eventos
antes de notificar a su vez an elemento de la capa i+2. Una
arquitectura bottom-up tambien puede ser no estricta si el elemento de
la capa i puede notificar a cualquier elemento de cualquier capa
superior a la capa i.
3. Arquitectura bidireccional de capas
En su forma más común involucra dos pilas de N capas que se
comunican entre si. El ejemplo más conocido es el de los protocolos
en Redes de Computadores.
Al implementar una arquitectura top-down de capas, se deben tomar en
cuenta los siguientes factores:
1. ¿Cuál es el criterio de abstracción para agrupar servicios/clases en
una capa?

9. Mencionar el criterio Presentación-Dominio de Aplicación-Repositorio
de Sistemas de Información.
2. Determinar el número de capas
En términos simplistas, a más capas más flexibilidad pero menor
desempeño.
3. Típicamente las capas más internas ofrecen menos servicios.
Esto ayuda la reutilización de capas ("pirámide invertida de reuso").
4. El grado de encapsulamiento de las capas.
A mayor encapsulamiento, menor dependencia externa sobre la
estructura de una capa.
5. Estructura interna de cada capa.
6. ¿Cuánta información pasar de una capa a otra?
Tomemos el caso de la arquitectura top-down. Es muy posible que, de
acuerdo con el tipo de servicio solicitado, la capa inferior requiera una
cantidad de información variable. En un modelo puro "empujado"
(push), la capa superior está obligada a enviarle toda la información
que pueda llegar a hacerle falta a la capa inferior en la solicitud.

10. Esto no siempre es posible (piense por ejemplo en una solicitud de
servicio a una base de datos que no logra completarse por estar fuera
de línea. ¿Qué se hace: reintentar, abandonar, usar una fuente
alterna?).
En el modelo contrario, "halado" (pull o por demanda), la capa inferior
solicita mayor información sólo si le hace falta --¿pero de quién la
pida? El modelo desolicitudes top-down presupone un invocador
anónimo y un invocado conocido.
La solución la proporciona el patrón Editorial-Suscriptor (Publish-
Subscribe) que encapsula la idea del callback. Este patrón de diseño
lo estudiaremos más adelante.
7. Diseñe la estrategia de manejo de errores.
Este es un aspecto que es frecuentemente obviado, aunque tiene
impacto fuerte tanto en el tiempo de procesamiento como en el
esfuerzo de programación. Típicamente se recomienda manejar el
error en el nivel que lo descubrió, si esto no es posible, dejar que lo
resuelva la capa más arriba, pero generalmente abstrayendo el tipo de
error para que sea comprensible en término de los servicios de la
capa superior.
Aplicaciones en capas 3 y 4
La estrategia tradicional de utilizar aplicaciones compactas causa gran
cantidad de problemas de integración en sistemas software complejos como
pueden ser los sistemas de gestión de una empresa o los sistemas de
información integrados consistentes en más de una aplicación. Estas
aplicaciones suelen encontrarse con importantes problemas de escalabilidad,
disponibilidad, seguridad, integración...
Para solventar estos problemas se ha generalizado la división de las
aplicaciones en capas que normalmente serán tres: una capa que servirá
para guardar los datos (base de datos), una capa para centralizar la lógica de

11. negocio (modelo) y por último una interfaz gráfica que facilite al usuario el
uso del sistema.
Si establecemos una separación entre la capa de interfaz gráfica (cliente),
replicada en cada uno de los entornos de usuario, y la capa modelo, que
quedaría centralizada en un servidor de aplicaciones, obtenemos una
potente arquitectura que nos otorga algunas ventajas:
• Centralización de los aspectos de seguridad y transaccionalidad, que
serían responsabilidad del modelo.
• No replicación de lógica de negocio en los clientes: esto permite que
las modificaciones y mejoras sean automáticamente aprovechadas
por el conjunto de los usuarios, reduciendo los costes de
mantenimiento.
• Mayor sencillez de los clientes.
Si intentamos aplicar esto a las aplicaciones web, debido a la obligatoria
sencillez del software cliente que será un navegador web, nos encontramos
con una doble posibilidad:
• Crear un modelo de 4 capas, separando cliente, servidor web, modelo
y almacén de datos. Esto nos permite una mayor extensibilidad en
caso de que existan también clientes no web en el sistema, que
trabajarían directamente contra el servidor del modelo.
Modelo vista controlador
Modelo-Vista-Controlador (Model-View-Controller) es un patrón de
desarrollo que separa la parte lógica de una aplicación de su presentación.
Básicamente sirve para separar el lenguaje de programación del HTML lo
máximo posible y para poder reutilizar componentes fácilmente.
El Modelo es el objeto que representa los datos del programa. Maneja los
datos y controla todas sus transformaciones. El Modelo no tiene
conocimiento específico de los Controladores o de las Vistas, ni siquiera
contiene referencias a ellos. Es el propio sistema el que tiene encomendada
la responsabilidad de mantener enlaces entre el Modelo y sus Vistas, y
notificar a las Vistas cuando cambia el Modelo.

12. La Vista es el objeto que maneja la presentación visual de los datos
representados por el Modelo. Genera una representación visual del Modelo y
muestra los datos al usuario. Interactúa con el Modelo a través de una
referencia al propio Modelo.
El Controlador es el objeto que proporciona significado a las órdenes del
usuario, actuando sobre los datos representados por el Modelo. Cuando se
realiza algún cambio, entra en acción, bien sea por cambios en la
información del Modelo o por alteraciones de la Vista. Interactúa con el
Modelo a través de una referencia al propio Modelo.
Se trata de realizar un diseño que desacople la vista del modelo, con la
finalidad de mejorar la reusabilidad. De esta forma las modificaciones en las
vistas impactan en menor medida en la lógica de negocio o de datos.

13. Conclusión
Al concluir Podemos decir que el diseño está determinado como el fin a
que se dirige o encamina una acción u operación, que a su vez está formada
por requisitos y diversas técnicas de trabajo.
Cuando nos referimos a un “objeto de diseño” estamos hablando de algo
especial, de algo con ciertas características, dándole un significado más
intenso al objeto en cuestión. Debemos tener en cuenta que también el
objeto de diseño no depende tanto de su apariencia en sí, sino busca que su
forma y su función formen un todo coherente, armónico e impactante. Esto
se debe a que cotidianamente estamos rodeados de muchos objetos, y
obviamente que un consumidor o espectador se inclinará por el objeto que
llame un poco más la atención y que sobresalga del resto.
Para concluir, podemos señalar que continuamente estamos rodeados de
objetos de diseño y del diseño en sí, desde las cosas más mínimas e
insignificantes hasta los edificios y construcciones más grandes que día a día
vemos en la ciudad. Por eso, el diseño forma parte de nuestras vidas desde
que nacemos hasta el fin de la misma, por lo tanto es importante tener en
cuenta al objeto de diseño, como una parte más de lo que nosotros somos.

14. Referencias Bibliográficas
Diseño de la arquitectura del sistema
http://ntaula0.tripod.com/ads/disarquit.htm
Arquitectura de la Información
http://es.wikipedia.org/wiki/Arquitectura_de_la_informaci%C3%B3n
Arquitectura de capas
http://ldc.usb.ve/~teruel/ci3715/clases/arqCapas.html