Estilo Arquitectónicos
a.- Arquitecturas de flujo de datos
Se basa en un patrón
tuberías y filtros. Este consta de un conjunto de componentes denominados
“filtros” conectados entre sí por “tuberías” que transmiten los datos desde un
componente al siguiente. Cada filtro trabaja de manera independiente de los
componentes que se encuentren situados antes o después de ella. Se diseñan de
tal modo que esperan que un conjunto de datos en un determinado formato. Y
obtiene como resultado datos de salida en un formato especifico.
El sistema es visto
como una serie de transformaciones sobre piezas sucesivas de datos de entrada.
El dato ingresa en el sistema, y fluye entre los componentes, de uno en uno,
hasta que se le asigne un destino final (salida o repositorio).
La aplicación típica
del estilo es un procesamiento clásico de datos: el cliente hace un
requerimiento; el requerimiento se valida; un Web Service toma el objeto de la
base de datos; se lo convierte a HTML; se efectúa la representación en
pantalla. El estilo tubería-filtros propiamente dicho enfatiza la
transformación incremental de los datos por sucesivos componentes.
b.- Sistemas basados en Llamado y Retorno (capas)
Están organizados
jerárquicamente; cada capa le presta servicios a la capa superior y es cliente
de la capa inferior. El sistema se constituye de un programa principal que
tiene el control del sistema y varios subprogramas que se comunican con éste
mediante el uso de llamadas
La programación por capas es una
arquitectura cliente-servidor en el que el objetivo primordial es la separación
de la lógica de negocios de la lógica de diseño; un ejemplo básico de esto
consiste en separar la capa de datos de la capa de presentación al usuario.
La ventaja principal de
este estilo es que el desarrollo se puede llevar a cabo en varios niveles y, en
caso de que sobrevenga algún cambio, solo se ataca al nivel requerido sin tener
que revisar entre código mezclado. Un buen ejemplo de este método de
programación sería el modelo de interconexión de sistemas abiertos.
Además, permite
distribuir el trabajo de creación de una aplicación por niveles; de este modo,
cada grupo de trabajo está totalmente abstraído del resto de niveles, de forma
que basta con conocer la API que existe entre niveles.
En el diseño de
sistemas informáticos actual se suelen usar las arquitecturas multinivel o
Programación por capas. En dichas arquitecturas a cada nivel se le confía una
misión simple, lo que permite el diseño de arquitecturas escalables (que pueden
ampliarse con facilidad en caso de que las necesidades aumenten).
c.- Sistemas de Componentes Independientes
Un componente de software individual
es un paquete de software, un servicio web, o un módulo que encapsula un
conjunto de funciones relacionadas (o de datos).
Todos los procesos del
sistema son colocados en componentes separados de tal manera que todos los
datos y funciones dentro de cada componente están semánticamente relacionados.
Debido a este principio, con frecuencia se dice que los componentes son
modulares y cohesivos.
Con respecto a la
coordinación a lo largo del sistema, los componentes se comunican uno con el
otro por medio de interfaces. Cuando un componente ofrece servicios al resto
del sistema, éste adopta una interface proporcionada que especifica los
servicios que otros componentes pueden utilizar, y cómo pueden hacerlo. Esta
interface puede ser vista como una firma del componente – el cliente no necesita
saber sobre los funcionamientos internos del componente (su implementación)
para hacer uso de ella. Este principio resulta en componentes referidos como
encapsulados.
Sin embargo, cuando un
componente necesita usar otro componente para poder funcionar, adopta una
interface usada que especifica los servicios que necesita. En las ilustraciones
de UML en este artículo, las interfaces usadas son representadas por un símbolo
de zócalo abierto unido al borde externo del componente.
Permite la
reutilización de software como proceso de crear sistemas de software a partir
de software existente, en lugar de desarrollarlo desde el comienzo.
d.- Sistemas Basados en transacciones
Un sistema de procesamiento de transacciones es
un tipo de sistema de información que recolecta, almacena, modifica y recupera
toda la información generada por las transacciones producidas en una
organización. Una transacción es un evento que genera o modifica los datos que
se encuentran eventualmente almacenados en un sistema de información.
Desde un punto de vista
técnico, un TPS monitoriza los programas transaccionales (un tipo especial de
programas). La base de un programa transaccional está en que gestiona los datos
de forma que estos deben ser siempre consistentes (por ejemplo, si se realiza
un pago con una tarjeta electrónica, la cantidad de dinero de la cuenta sobre
la que realiza el cargo debe disminuir en la misma cantidad que la cuenta que
recibe el pago, de no ser así, ninguna de las dos cuentas se modificará), si
durante el transcurso de una transacción ocurriese algún error, el TPS debe
poder deshacer las operaciones realizadas hasta ese instante.
Si bien este tipo de
integridad es que debe presentar cualquier operación de procesamiento de
transacciones por lotes, es particularmente importante para el procesamiento de
transacciones on-line: si, por ejemplo, un sistema de reserva de billetes de
una línea aérea es utilizado simultáneamente por varios operadores, tras
encontrar un asiento vacío, los datos sobre la reserva de dicho asiento deben
ser bloqueados hasta que la reserva se realice, de no ser así, otro operador
podría tener la impresión de que dicho asiento está libre cuando en realidad
está siendo reservado en ese mismo instante.
Sin las debidas
precauciones, en una transacción podría ocurrir una reserva doble. Otra función
de los monitores de transacciones es la detección y resolución de interbloqueos
(deadlock), y cortar transacciones para recuperar el sistema en caso de
fallos masivos
e.- Sistemas Basados en eventos
Una arquitectura basada
en eventos responde a las acciones o acontecimientos generados por un
directorio y sus usuarios. Los eventos del directorio conectado actúan como un
disparador para iniciar la replicación o sincronización de los datos de ese
directorio. El cambio del repositorio genera un evento resultante, y dicho
evento acciona los cambios en los demás directorios conectados. Como
consecuencia de los eventos y de los cambios correspondientes, se sincronizan
los datos de identidad de todos los directorios conectados
Por ejemplo, cuando un
consumidor compra un coche, el estado del coche pasa de “se vende” a “vendido”.
La arquitectura del sistema del vendedor de coches debe tratar este cambio de
estado como un evento, cuyo suceso puede ser conocido en otras aplicaciones en
la arquitectura. Desde una perspectiva formal, lo que es producido, publicado,
propagado, detectado o consumido es un mensaje (típicamente asíncrono) llamado
notificación del evento, y no el evento en sí mismo, el cuál es el cambio de
estado que disparó la emisión del evento. Los eventos no viajan, solamente
ocurren. Por otro lado, el término evento es frecuentemente usado para denotar
el mensaje de notificación en sí mismo, lo cual puede llevar a algún tipo de
confusión.
f. - PEER TO PEER O P2P
g.- Cliente-Servidor.
La arquitectura cliente-servidor es un modelo de aplicación distribuida en el que las tareas se reparten entre los proveedores de recursos o servicios, llamados servidores, y los demandantes, llamados clientes. Un cliente realiza peticiones a otro programa, el servidor, quien le da respuesta. Esta idea también se puede aplicar a programas que se ejecutan sobre una sola computadora, aunque es más ventajosa en un sistema operativo multiusuario distribuido a través de una red de computadoras. Algunos ejemplos de aplicaciones computacionales que usen el modelo cliente-servidor son el Correo electrónico, un Servidor de impresión y la World Wide Web.
No hay comentarios:
Publicar un comentario