Estilos Arquitectónicos Sommerville (Lectura T3) ISW

Arquitectura de tubería y filtro (Sommerville, pág.
163)
Nombre Tubería y filtro ( pipe and filter)

Descripción El procesamiento de datos en un sistema se organiza de forma que cada
componente de procesamiento (filtro) sea discreto y realice un tipo de
transformación de datos. Los datos fluyen (como en una tubería) de un
componente a otro para su procesamiento.
Ejemplo La figura es un ejemplo de un sistema de tubería y filtro usado para el
procesamiento de facturas.
Cuándo se usa Se suele utilizar en aplicaciones de procesamiento de datos (tanto basadas
en lotes [batch] como en transacciones), donde las entradas se procesan
en etapas separadas para generar salidas relacionadas.
Ventajas Fácil de entender y soporta reutilización de transformación. El estilo del

flujo de trabajo coincide con la estructura de muchos procesos
empresariales. La evolución al agregar transformaciones es directa. Puede
implementarse como un sistema secuencial o como uno concurrente.
Desventajas El formato para la transferencia de datos debe acordarse entre las
transformaciones que se comunican. Cada transformación debe analizar
sus entradas y sintetizar sus salidas al formato acordado. Esto aumenta la
carga del sistema, y puede significar que sea imposible reutilizar
transformaciones funcionales que usen estructuras de datos
incompatibles.
Arquitectura en capas (Sommerville, pág. 157)
Nombre Arquitectura en capas

Descripción Organiza el sistema en capas con funcionalidad relacionada con cada capa.
Una capa da servicios a la capa de encima, de modo que las capas de nivel
inferior representan servicios núcleo que es probable se utilicen a lo largo
de todo el sistema.
Ejemplo Un modelo en capas de un sistema para compartir documentos con
derechos de autor se tiene en diferentes bibliotecas (LIBSYS).
Cuándo se usa Se usa al construirse nuevas facilidades encima de los sistemas existentes;
cuando el desarrollo se dispersa a través de varios equipos de trabajo, y
cada uno es responsable de una capa de funcionalidad; cuando exista un
requerimiento para seguridad multinivel.
Ventajas Permite la sustitución de capas completas en tanto se conserve la interfaz.
Para aumentar la confiabilidad del sistema, en cada capa pueden incluirse
facilidades redundantes (por ejemplo, autenticación).
Desventajas En la práctica, suele ser difícil ofrecer una separación limpia entre capas, y
es posible que una capa de nivel superior deba interactuar directamente con
capas de nivel inferior, en vez de que sea a través de la capa
inmediatamente abajo de ella. El rendimiento suele ser un problema,
debido a múltiples niveles de interpretación de una solicitud de servicio
mientras se procesa en cada capa.
Arquitectura cliente-servidor (Sommerville, pág. 160)
Nombre Cliente-servidor
Descripción En una arquitectura cliente-servidor, la funcionalidad del sistema se
organiza en servicios, y cada servicio lo entrega un servidor independiente.
Los clientes son usuarios de dichos servicios y para utilizarlos ingresan a los
servidores.
Ejemplo La figura es un ejemplo de una filmoteca y videoteca (videos/DVD)
organizada como un sistema cliente-servidor.
Cuándo se usa Se usa cuando, desde varias ubicaciones, se tiene que ingresar a los datos
en una base de datos compartida. Como los servidores se pueden replicar,
también se usan cuando la carga de un sistema es variable.
Ventajas La principal ventaja de este modelo es que los servidores se pueden
distribuir a través de una red. La funcionalidad general (por ejemplo, un
servicio de impresión) estaría disponible a todos los clientes, así que no
necesita implementarse en todos los servicios.
Desventajas Cada servicio es un solo punto de falla, de modo que es susceptible a
ataques de rechazo de servicio o a fallas del servidor. El rendimiento
resultará impredecible porque depende de la red, así como del sistema.
Quizás haya problemas administrativos cuando los servidores sean
propiedad de diferentes organizaciones.
Arquitectura de repositorio (Sommerville, pág. 159)
Nombre Repositorio
Descripción Todos los datos en un sistema se gestionan en un repositorio central,
accesible a todos los componentes del sistema. Los componentes no
interactúan directamente, sino tan sólo a través del repositorio.
Ejemplo La figura es un ejemplo de un IDE donde los componentes usan un
repositorio de información de diseño de sistema. Cada herramienta de
software genera información que, en ese momento, está disponible para
uso de otras herramientas.
Cuándo se usa Este patrón se usa cuando se tiene un sistema donde los grandes
volúmenes de información generados deban almacenarse durante mucho
tiempo. También puede usarse en sistemas dirigidos por datos, en los que
la inclusión de datos en el repositorio active una acción o herramienta.
Ventajas Los componentes pueden ser independientes, no necesitan conocer la
existencia de otros componentes. Los cambios hechos por un componente
se pueden propagar hacia todos los componentes. La totalidad de datos se
puede gestionar de manera consistente (por ejemplo, respaldos realizados
al mismo tiempo), pues todos están en un lugar.
Desventajas El repositorio es un punto de falla único, de modo que los problemas en el
repositorio afectan a todo el sistema. Es posible que haya ineficiencias al
organizar toda la comunicación a través del repositorio. Quizá sea difícil
distribuir el repositorio por medio de varias computadoras.
Arquitecturas de aplicación (Sommerville, págs. 164 – 169)
Los sistemas de aplicación tienen la intención de cubrir las necesidades de una empresa u
organización. Todas las empresas tienen mucho en común: necesitan contratar personal, emitir
facturas, llevar la contabilidad, etcétera. Las empresas que operan en el mismo sector usan
aplicaciones comunes específicas para el sector. De esta forma, además de las funciones
empresariales generales, todas las compañías telefónicas necesitan sistemas para conectar
llamadas, administrar sus redes y emitir facturas a los clientes, entre otros. En consecuencia,
también los sistemas de aplicación que utilizan dichas empresas tienen mucho en común.
Estos factores en común condujeron al desarrollo de arquitecturas de software que describen

la estructura y la organización de tipos particulares de sistemas de software. Las arquitecturas
de aplicación encapsulan las principales características de una clase de sistemas. Por ejemplo,
en los sistemas de tiempo real puede haber modelos arquitectónicos genéricos de diferentes
tipos de sistema, tales como sistemas de recolección de datos o sistemas de monitorización.
Aunque las instancias de dichos sistemas difieren en detalle, la estructura arquitectónica común
puede reutilizarse cuando se desarrollen nuevos sistemas del mismo tipo.
A continuación, se recogen dos tipos de arquitecturas de aplicación típicas.
1. Sistemas de procesamiento de transacciones

Los sistemas de procesamiento de transacciones (TP, por las siglas de Transaction Processing)
están diseñados para procesar peticiones del usuario mediante la información de una base de
datos, o los requerimientos para actualizar una base de datos (Lewis et al., 2003). Técnicamente,
una transacción de base de datos es una secuencia de operaciones que se trata como una sola
unidad (una unidad atómica). Todas las operaciones en una transacción tienen que completarse
antes de que sean permanentes los cambios en la base de datos. Esto garantiza que la falla en
las operaciones dentro de la transacción no conduzca a inconsistencias en la base de datos.
Desde una perspectiva de usuario, una transacción es cualquier secuencia coherente de

operaciones que satisfacen un objetivo, como “encontrar los horarios de vuelos de Londres a
París”. Si la transacción del usuario no requiere el cambio en la base de datos, entonces sería
innecesario empaquetar esto como una transacción técnica de base de datos.
Un ejemplo de una transacción es una petición de cliente para retirar dinero de una cuenta
bancaria mediante un cajero automático. Esto incluye obtener detalles de la cuenta del cliente,
verificar y modificar el saldo por la cantidad retirada y enviar comandos al cajero automático
para entregar el dinero. Hasta que todos estos pasos se completan, la transacción permanece
inconclusa y no cambia la base de datos de la cuenta del cliente.
Por lo general, los sistemas de procesamiento de transacción son sistemas interactivos donde
los usuarios hacen peticiones asíncronas de servicios. La figura 6.14 ilustra la estructura
arquitectónica conceptual de las aplicaciones de TP. Primero, un usuario hace una petición al
sistema a través de un componente de procesamiento I/O. La petición se procesa mediante
alguna lógica específica de la aplicación. Se crea una transacción y pasa hacia un gestor de
transacciones que, por lo general, está embebido en el sistema de manejo de la base de datos.
Después de que el gestor de transacciones asegura que la transacción se ha completado
adecuadamente, señala a la aplicación que terminó el procesamiento.
Los sistemas de procesamiento de transacción pueden organizarse como una arquitectura

“tubería y filtro” con componentes de sistema responsables de entradas, procesamiento y
salida. Por ejemplo, considere un sistema bancario que permite a los clientes consultar sus
cuentas y retirar dinero de un cajero automático. El sistema está constituido por dos
componentes de software cooperadores: el software del cajero automático y el software de
procesamiento de cuentas en el servidor de la base de datos del banco. Los componentes de
entrada y salida se implementan como software en el cajero automático y el componente de
procesamiento es parte del servidor de la base de datos del banco. La figura 6.15 muestra la
arquitectura de este sistema e ilustra las funciones de los componentes de entrada, proceso y
salida.
2. Sistemas de Información
Todos los sistemas que incluyen interacción con una base de datos compartida se consideran
sistemas de información basados en transacciones. Un sistema de información permite acceso
controlado a una gran base de información, tales como un catálogo de biblioteca, un horario de
vuelos o los registros de pacientes en un hospital. Cada vez más, los sistemas de información
son sistemas basados en la Web, cuyo acceso es mediante un navegador Web.
La figura 6.16 presenta un modelo muy general de un sistema de información. El sistema se
modela con un enfoque por capas, donde la capa superior soporta la interfaz de usuario, y la
capa inferior es la base de datos del sistema. La capa de comunicaciones con el usuario maneja
todas las entradas y salidas de la interfaz de usuario, y la capa de recuperación de información
incluye la lógica específica de aplicación para acceder y actualizar la base de datos. Como se verá
más adelante, las capas en este modelo pueden trazarse directamente hacia servidores dentro
de un sistema basado en Internet.
Como ejemplo de una instancia de este modelo en capas, la figura 6.17 muestra la arquitectura
del MHC-PMS. Recuerde que este sistema mantiene y administra detalles de los pacientes que
consultan médicos especialistas en problemas de salud mental. En el modelo se agregaron
detalles a cada capa al identificar los componentes que soportan las comunicaciones del usuario,
así como la recuperación y el acceso a la información:
1. La capa superior es responsable de implementar la interfaz de usuario. En este caso, la UI se

implementó con el uso de un navegador Web.
2. La segunda capa proporciona la funcionalidad de interfaz de usuario que se entrega a través
del navegador Web. Incluye componentes que permiten a los usuarios ingresar al sistema,
y componentes de verificación para garantizar que las operaciones utilizadas estén
permitidas de acuerdo con su rol. Esta capa incluye componentes de gestión de formato y
menú que presentan información a los usuarios, así como componentes de validación de
datos que comprueban la consistencia de la información.
3. La tercera capa implementa la funcionalidad del sistema y ofrece componentes que ponen
en operación la seguridad del sistema, la creación y actualización de la información del
paciente, la importación y exportación de datos del paciente desde otras bases de datos, y
los generadores de reporte que elaboran informes administrativos. Finalmente, la capa más
baja, que se construye al usar un sistema comercial de gestión
4. Finalmente, la capa más baja, que se construye al usar un sistema comercial de gestión de
base de datos, ofrece administración de transacciones y almacenamiento constante de
datos.
Los sistemas de gestión de información y recursos, por lo general, son ahora sistemas basados
en la Web donde las interfaces de usuario se implementan con el uso de un navegador Web. Por
ejemplo, los sistemas de comercio electrónico son sistemas de gestión de recursos basados en
Internet, que aceptan pedidos electrónicos por bienes o servicios y, luego, ordenan la entrega
de dichos bienes o servicios al cliente. En un sistema de comercio electrónico, la capa específica
de aplicación incluye funcionalidad adicional que soporta un “carrito de compras”, donde los
usuarios pueden colocar algunos objetos en transacciones separadas y, luego, pagarlos en una
sola transacción.
La organización de servidores en dichos sistemas refleja usualmente el modelo genérico en

cuatro capas presentadas en la figura 6.16. Dichos sistemas se suelen implementar como
arquitecturas cliente-servidor de multinivel, como se estudia en el capítulo 18:
1. El servidor Web es responsable de todas las comunicaciones del usuario, y la interfaz de

usuario se pone en función mediante un navegador Web;
2. El servidor de aplicación es responsable de implementar la lógica específica de la
aplicación, así como del almacenamiento de la información y las peticiones de
recuperación;
3. El servidor de la base de datos mueve la información hacia y desde la base de datos y,
además, manipula la gestión de transacciones.
El uso de múltiples servidores permite un rendimiento elevado, al igual que posibilita la
manipulación de cientos de transacciones por minuto. Conforme aumenta la demanda, pueden
agregarse servidores en cada nivel, para lidiar con el procesamiento adicional implicado.

Estilos Arquitectónicos Sommerville (Lectura T3) ISW

Cargado por

Copyright:

Formatos disponibles

Estilos Arquitectónicos Sommerville (Lectura T3) ISW

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Estilos Arquitectónicos Sommerville (Lectura T3) ISW

Cargado por

Copyright:

Formatos disponibles

Arquitectura de tubería y filtro (Sommerville, pág.

Nombre Tubería y filtro ( pipe and filter)

Ventajas Fácil de entender y soporta reutilización de transformación. El estilo del

Nombre Arquitectura en capas

Estos factores en común condujeron al desarrollo de arquitecturas de software que describen

A continuación, se recogen dos tipos de arquitecturas de aplicación típicas.

1. Sistemas de procesamiento de transacciones

Desde una perspectiva de usuario, una transacción es cualquier secuencia coherente de

Los sistemas de procesamiento de transacción pueden organizarse como una arquitectura

1. La capa superior es responsable de implementar la interfaz de usuario. En este caso, la UI se

La organización de servidores en dichos sistemas refleja usualmente el modelo genérico en

1. El servidor Web es responsable de todas las comunicaciones del usuario, y la interfaz de

También podría gustarte