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 DE INFORMACION
Profesora: Autores:
Naydrubys Trejo Perez Elaynne CI: 20.209.733
Rojas Zulay CI: 18.556.085
Guarenas, Julio del 2011

2. INTRODUCCIÓN
Desde los años 90 del siglo XX, la Arquitectura de Información ha tenido, una
creciente popularidad. Popularidad que decreció con la caída de las "punto com" en el
2001, pero que volvió a tomar auge en posteriores años.
En la presente información se dan a conocer breves conceptos como:
Una arquitectura es un diseño estructural integrado de un sistema, sus elementos y
definiciones dependen de los requerimientos proporcionados. El concepto de
“arquitectura” es ampliamente usado en el contexto de la construcción de
computadoras. Cuando se aplica a los sistemas de información asumimos que una
arquitectura es un plano abstracto que incluye los diseños de procesos de un sistema,
basado en principios de diseño y dentro de un marco metodológico.
La Arquitectura de Software, consiste en un conjunto de patrones y
abstracciones coherentes que proporcionan el marco de referencia necesario
para guiar la construcción del software para un sistema de información.
La Arquitectura de Software establece los fundamentos para que analistas,
diseñadores, programadores, etc. trabajen en una línea común que permita
alcanzar los objetivos del sistema de información, cubriendo todas las
necesidades.
Y los diferentes estilos de arquitectura de un sistema de información:
El modelo cliente/servidor: Es una arquitectura de procesamientos cooperativo
donde uno de los componentes pide servicios a otro. Este término
originalmente es aplicado a la arquitectura de software; describe el
procesamiento entre dos o más programas; una aplicación y
un servicio soportante.
De comunicación, de capas, entre otros.

3. Definición de arquitectura
Toda arquitectura es diseño, pero no todo el diseño es arquitectura. La
arquitectura es aquella que representa las decisiones de diseño significativas
que le dan forma a un sistema, donde lo significativo puede ser medido por el
costo del cambio.
Definición de arquitectura de software
La arquitectura del software es una descripción de los subsistemas y
componentes (computacionales) de un sistema software y las relaciones entre
ellos.
La determinación de la arquitectura del software consiste en la toma de
decisiones respecto a:
• La organización del sistema software.
• La selección de los elementos estructurales y sus interfaces.
• comportamiento de estos elementos estructurales.
• La posible composición de los elementos estructurales en subsistemas
más grandes.
• El estilo que guía esta organización.
Teniendo en cuenta las propiedades (requisitos no funcionales) del sistema del
software que se quiere lograr:
• eficiencia, cambiabilidad, usabilidad, fiabilidad…
La arquitectura del software es el resultado de la actividad de diseño
arquitectónico del software.
Propiedades:
• Cambiable:
 Extensible: Nuevas funcionalidades o mejora de los componentes.

4.  Portátil: Cambio de plataforma hardware, sistemas operativos,
lenguajes.
 Mantenible: Detención y reparación de errores.
 Reestructurable: Reorganización de componentes.
• Interoperable:
Capacidad de dos o más entidades software de intercambiar
funcionalidad y datos.
• Eficiente:
Tiempo de respuesta, rendimiento, uso de recursos.
• Fiable:
 Tolerancia a fallos: Pérdida de conexión y recuperación posterior.
 Robustez: Protección contra el uso incorrecto y el tratamiento de
errores inesperados.
• Probable:
Facilitar las pruebas del sistema.
• Reusable:
 Reusar software ya existente.
 Hacer software para ser reusado.
• Integridad conceptual:
Harmonía, simetría y predictibilidad.
Estilos de arquitectura
 Cliente/Servidor: Representa un modelo de organización de la relación
entre los distintos y numerosos ordenadores que existen en una
empresa. Es la conexión en la que el “terminal” es llamado ahora cliente
el cual tiene una capacidad propia de ejecución muy alta, con

5. independencia del ordenador principal, llamado ahora servidor, que se
especializa en ciertas funciones especificas. La arquitectura
cliente/servidor es una distribución lógica de funciones donde la
capacidad de proceso de los ordenadores personales se emplea
extensamente.
Esta arquitectura consiste básicamente en que un programa cliente realiza
peticiones a otro programa, servidor, que le da respuesta. Por lo tanto, en esta
arquitectura se divide la capacidad de proceso de información entre
ordenadores cliente y servidor. En realidad la separación entre cliente y
servidor es una separación de tipo lógico, donde el servidor no es
necesariamente una sola maquina, ni posee necesariamente un solo programa.
En general, este modelo utiliza el procesamiento distribuido entre clientes y
servidores conectados todos ellos por una red de comunicación.
Características significativas:
o Las funciones del cliente y del servidor pueden estar en
plataformas separadas, o en la misma plataforma.
o Un servidor puede dar servicios a múltiples clientes de forma
concurrente.
o Cada plataforma puede ser escalable de manera independiente.
o El esquema cliente/servidor construye además, a proporcionar, a
los diferentes departamentos de una organización, soluciones
locales, pero permitiendo la integración de la información
relevante a nivel global.
 Peer to peer: Esta arquitectura convierte a los usuarios en servidores de
contenido, de forma transparente, proporcionándoles un papel que va
mas allá del que hasta este momento habían tenido, como simples
consumidores de datos. En termino de funcionalidad, esta arquitectura
consiste en que los nodos de una red pueden adoptar tanto el rol del
cliente, como el del servidor con los demás nodos de la red. Basa su
funcionamiento, dirigido a optimizar los recursos de la red (capacidad de

6. proceso, velocidad de proceso, disponibilidad de ancho de banda
conexión de red, capacidad de almacenamiento,…), en que todos los
usuarios pueden compartir. Existen variantes de esta arquitectura, ya
que la red puede llamarse P2P, aunque utilice una filosofía C/S para
ciertas tareas:
Redes P2P centralizadas: En esta modalidad todas las transacciones se
hacen a través de un único servidor que sirve de punto de enlace entre todos
los nodos, y como servidor de acceso al contenido. Esta arquitectura tiene
problemas de escalabilidad del servidor, de tolerancia a fallos, etc.
Redes P2P “puras” o totalmente descentralizada: No requieren de un nodo
central. Son más comunes, y las más versátiles.
Redes P2P hibridas: En esta topología, se puede observar la interacción
entre un nodo o más nodos que actúan de servidores centrales para
administrar los recursos de ancho de banda de conexión de la red, y gestionar
los enrutamientos y comunicaciones entre nodos; aunque lo hacen de manera
transparente, es decir, sin conocer la identidad de cada nodo, y sin almacenar
contenidos, o proporcionar otros recursos que pueden ser alcanzados por otros
nodos.
Las redes P2P se usan muy a menudo para compartir toda clase de archivos
que contienen: audio, video, texto, software y datos, en cualquier formato
digital. Esta arquitectura se liga a menudo a distribución de contenidos, sin
embargo, su aplicación en la empresa a puesto de manifiesto su potencialidad
para otro tipo de soluciones, tales como, el soporte a servicios de comunicación
y colaboración, la implantación de sistemas descentralizados de computación
masiva, el desarrollo de plataformas C2C (client to client) de soporte a
complejas relaciones comerciales, etc.
 De comunicación: Es una estructura organizada jerárquicamente con
el fin de permitir el intercambio de datos entre niveles lógicos
semejantes en distintas máquinas o terminales de la misma o distinta
red.

7. 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.
Debido a la complejidad que requiere la comunicación entre 2 entidades de diferentes
sistemas, encontramos implementadas las funciones de comunicación mediante un
conjunto de protocolos estructurados. Esta organización de los protocolos se realiza
mediante capas o niveles con objeto de simplificar su diseño. El propósito de cada
capa es ofrecer ciertos servicios a las capas superiores.
La capa n en una máquina conversa con la capa n de la otra máquina. Las reglas y
convecciones utilizadas en la conversación se conocen como protocolo de la capa n.
A las entidades de una misma capa correspondiente a máquinas diferentes se le
denomina procesos pares.
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.
 De capas: 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:

8. • 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).
RPM toca muy superficialmente los problemas asociados al desarrollo de una
capa de Presentación. Menciona que es conveniente usar un enfoque de
prototipaje y que pueden ser útiles los casos reales de uso; sin embargo no
proporciona métodos, principios o lineamientos metodológicos que apoyen el
desarrollo de una metáfora de diseño para la interfaz, el diseño lógico de la
presentación o su diseño físico.
RPM tampoco proporciona muchas luces sobre el desarrollo de la capa del Repositorio
y tiende a subestimar su complejidad.
Una vez elaborado el Modelo de Uso, RPM recomiendo seguir con actividades de
análisis de requerimientos. Para ello se elabora un Modelo Conceptual, en el cual se
busca identificar los conceptos importantes del dominio de la aplicación, abstrayendo
todo lo que puedan ser mecanismos o conceptos propios de un diseño o de una
implementación. Así, en el ejemplo de un Sistema de Punto de Venta, nos interesan
los conceptos como Venta, Recibo, Efectivo, Cheque, Impuesto que tienen que ver con
los procesos de negocio que se están apoyando y no nos interesan conceptos como
Menú, Ventana, Tabla relacional, Consulta a Base de Datos que tienen que ver con
cómo mejor implementar los conceptos del negocio. La mayoría de estos elementos
de un Modelo Conceptual terminan agrupándose naturalmente en la capa del Dominio
de La Aplicación.

9. Este enfoque de RPM termina por sesgar la metodología hacia el desarrollo de la capa
del Dominio de la Aplicación, y en la práctica, tiende a hacer presuponer que el
desarrollo de las otras capas se puede ajustar al diseño de la capa del Dominio de
Aplicación, lo cual no es siempre el caso, incluso dentro del ámbito de los Sistemas de
Información.
Antes de estudiar el Modelo Conceptual, nos conviene aclarar qué es una arquitectura
de capas, su importancia e implicaciones, para tener mayor claridad en los riesgos que
corremos al adoptar una metodología como RPM.
Arquitectura de Capas
 Preguntar qué conocen por arquitectura de capas (en Sistemas de
Operación, Redes de Computadores...).
 Nos limitaremos a manejar la noción de arquitectura como una forma de
estructurar los elementos de un software.
 En toda arquitectura de capa los elementos agrupados en una misma capa
pueden comunicarse entre si; pero existen variantes en cuanto a las
comunicaciones permitidas entre elementos de capas diferentes:
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

10. 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 sí. 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?
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.

11. 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 de
solicitudes 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.
Todo patrón tiene ventajas y desventajas: en el caso de la arquitectura de
capas ya las hemos mencionado [dejar que los estudiantes las resuman]:
• Ventajas
o Reutilización de capas;
o Facilita la estandarización
o Dependencias se limitan a intra-capa
o Contención de cambios a una o pocas capas
• Desventajas
o A veces no se logra la contención del cambio y se requiere una
cascada de cambios en varias capas;
o Pérdida de eficiencia;
o Trabajo innecesario por parte de capas más internas o
redundante entre varias capas;
o Dificultad de diseñar correctamente la granularidad de las capas.

12. Existen tres propuestas de arquitecturas de capas para Sistemas de
Información, donde las capas a veces reciben el nombre de niveles (en Inglés
tiers):
• Arquitectura de dos capas;
• Arquitectura de tres capas;
• Arquitectura de cuatro capas.
Dos capas
En la actualidad muchos sistemas de información están basados en
arquitecturas de dos capas, denominadas:
• Nivel de aplicación;
• Nivel de la base de datos.
Existen herramientas de amplio uso que presuponen esta estructura (p. ej.
Visual Basic + Access/SQL server). Estas arquitecturas fueron las primeras en
aprovecharse de la estructura cliente-servidor (aplicación en los clientes, base
de datos como servidor). Las desventajas de dos niveles son bien conocidas:
• El nivel de las aplicaciones se recargan, entremezclando aspectos
típicos del manejo de la interfaz con las reglas del negocio;
• Las reglas del negocio quedan dispersas entre el nivel de aplicación y
los "stored procedures" de la base de datos;
• La aplicación queda sobrecargada de información de bajo nivel si hay
que extraer los datos de varias bases de datos, posiblemente con
estructuras diferentes.
• El nivel de aplicación puede ser demasiado pesado para el cliente.
Tres capas
Por estas razones, existe una fuerte y bien avanzada tendencia a adoptar una
arquitectura de tres capas:
• Aplicación
• Dominio de la aplicación;
• Repositorio.

13. La mayoría de estos sistemas buscan conservar la tecnología de BD relacional
para la capa del repositorio e introducir la tecnología OO para el dominio de la
aplicación. Para la capa de presentación existe una pelea entre tecnología
HTML (Java-enabled) vs. Generadores GUI.
¿Qué contiene el dominio de la aplicación? En terminología más clásica de BD los tres
niveles pueden equipararse, a grosso modo, con:
• Esquema externo;
• Esquema conceptual;
• Esquema interno o de almacenamiento.
La ventaja es que ahora la aplicación puede describirse únicamente en
relación a la semántica de la aplicación, sin tener que preocuparse sobre cómo
está implementado ese dominio (ubicación y estructura física de la data).
Cuatro capas
Los desarrollos más recientes empiezan a experimentar con una capa adicional
(para 2000 no había visto evidencia de esto en Venezuela):
• Presentación;
• Aplicación;
• Dominio de la aplicación;
• Repositorio
La idea básica es separar todo lo que es programación GUI de la aplicación per
se (y por ende tiende a usar frameworks para GUI como MFC). El nivel de la
presentación no hace cálculos, consultas o actualizaciones sobre el dominio
--de hecho nisiquiera tiene visibilidad sobre la capa del dominio. La capa de la
aplicación es la encargada de accesar la capa del dominio, simplificar la
información del dominio convirtiéndolo a los tipos de datos que entiende la
interfaz: enteros, reales, cadenas de caracteres, fecha y clases contenedoras
(container, collection).
 Modelo vista controlador (MVC): Separa los datos de aplicación
(contenidos en el modelo) de los componentes de presentación grafica
(la vista) y lógica de procesamiento de la entrada (el controlador).
El MVC no restringe una aplicación a una sola vista o un solo controlador. En
un programa más sofisticado (como un procesador de palabras), podría haber

14. dos vistas de un modelo de documento. Una vista podría mostrar un bosquejo
del documento y el otro podría mostrar el documento completo. El procesador
de palabras podría también implementar varios controladores: uno para
manejar la entrada del teclado y otro para manejar las selecciones del ratón. Si
cualquiera de los dos controladores realiza un cambio en el modelo, tanto la
vista del bosquejo como la ventana de vista previa de impresión mostrarán el
cambio inmediatamente, cuando el modelo notifique los cambios a todas las
vistas.
Otro beneficio clave para el patrón de arquitectura MVC es que los
desarrolladores pueden modificar cada componente de manera individual, sin
tener que modificar los demás componentes. Por ejemplo, los desarrolladores
podrían modificar la vista que muestra el documento en línea, y no tendrían que
modificar ni el modelo ni las demás vistas o controladores.

15. CONCLUSIÓN
Un proyecto de desarrollo de un Sistema de Información comprende varios
componentes o pasos llevados a cabo durante la etapa del análisis, el cual ayuda a
traducir las necesidades del cliente en un modelo de Sistema que utiliza uno más de
los componentes: Software, hardware, personas, base de datos, documentación y
procedimientos.
En una organización o Empresa, el análisis y Diseño de Sistemas, es el proceso de
estudiar su Situación con la finalidad de observar cómo trabaja y decidir si es
necesario realizar una mejora; el encargado de llevar a cabo estas tareas es el
analista de sistemas.
Lo más importante de los estilos de arquitectura de un sistema de información:
Cliente/Servidor puede incluir múltiples plataformas, bases de datos, redes y
sistemas operativos. Estos pueden ser de distintos proveedores, en
arquitecturas propietarias y no propietarias y funcionando todos al mismo
tiempo. Por lo tanto, su implantación involucra diferentes tipos de estándares:
APPC, TCP/IP, OSI, NFS, DRDA corriendo sobre DOS, OS/2, Windows o
PC UNIX, en Token Ring, Ethernet, FDDI o medio coaxial, sólo por mencionar
algunas de las posibilidades.

16. Referencias
E. Teniente López - A Olive Ramón. E. Mayol Sarroca – Gómez Seoane.
Diseño de Sistema del software en UML
http://books.google.co.ve/books?id=p7nD8_g77_MC&printsec=frontcover&dq=dise
%C3%B1o+de+sistemas&hl=es&ei=eTAiTsXRBsrs0gGR-
dSsAw&sa=X&oi=book_result&ct=result&resnum=2&ved=0CC8Q6AEwAQ#v=onepage&q&f=fa
lse
Juan José Goñi Zabala. El cambio son personas: la dirección de los procesos
de cambio
http://books.google.co.ve/books?id=E-
PgDbPnSKsC&pg=PA85&dq=definicion+arquitectura+cliente/servidor+del+sistema+de+inform
acion&hl=es&ei=8FIiTuzuIYj40gGrusnZAw&sa=X&oi=book_result&ct=result&resnum=1&ved=0
CCgQ6AEwAA#v=onepage&q&f=false
Harvey M. Deitel,Paul J. Deitel. Cómo programar en Java
http://books.google.co.ve/books?
id=is2J44U4DpsC&pg=PA910&dq=arquitectura+modelo+vista+controlador+del+sistema+de+in
formacion&hl=es&ei=ckYkTuriNM6ftgev0Z23Aw&sa=X&oi=book_result&ct=result&resnum=2
&ved=0CDUQ6AEwAQ#v=onepage&q&f=false