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