Comparativa de Arquitecturas de Software: Flujo, Datos, Capas, C/S, Objetos Distribuidos, P2P y SOA

Análisis Comparativo de Arquitecturas de Software

Este documento presenta una evaluación comparativa de diversas arquitecturas de software, considerando criterios clave como mantenibilidad, escalabilidad, fiabilidad, rendimiento, seguridad, interoperabilidad, flexibilidad, facilidad de prueba, portabilidad y reusabilidad. Se analizan las siguientes arquitecturas:

• Flujo de Datos (Pipe and Filter)
• Datos Centralizados (Repositorio)
• Capas
• Cliente/Servidor (C/S)
• Objetos Distribuidos
• Peer-to-Peer (P2P)
• Arquitectura Orientada a Servicios (SOA)

Evaluación de las Arquitecturas

A continuación, se presenta la evaluación de cada arquitectura según los criterios mencionados (valoración del 1 al 5, siendo 5 el valor más alto):

Flujo de Datos (Pipe and Filter)

• Mantenibilidad (Mant): 4 (filtros independientes)
• Escalabilidad (Esca): 4 (facilita la modularidad)
• Fiabilidad (Fiab): 2 (depende del formato de los datos)
• Rendimiento (Rend): 2 (proceso lineal)
• Seguridad (Seg): 3 (procesos independientes)
• Interoperabilidad (Intero): 1 (necesita un formato reconocido para las transformaciones)
• Flexibilidad (Flex): 1 (proceso lineal)
• Prueba (Prueba): 1 (requiere una entrada para probar)
• Portabilidad (Porta): 3 (filtros independientes)
• Reusabilidad (Reu): 4 (filtros reutilizables)

Datos Centralizados (Repositorio)

• Mant: 4 (repositorio centralizado)
• Esca: 1 (difícil de evolucionar)
• Fiab: 2 (si falla el almacén, deja de funcionar)
• Rend: 2 (carga acumulativa)
• Segu: 1 (impone la misma política a todos los subsistemas)
• Intero: 4 (compartición eficiente)
• Flex: 1 (subsistemas coherentes al modelo del repositorio)
• Prueba: 1 (necesidad de un almacén de datos)
• Port: 1 (difícil de distribuir)
• Reut: 4 (independencia entre subsistemas)

Capas

• Mant: 4 (fácil de mantener, solo afecta a la capa adyacente)
• Esca: 4 (si se mantiene la interfaz, la capa es reemplazable)
• Fiab: 3 (control correcto de errores)
• Rend: 1 (afectado por tener tantas capas)
• Segu: 4 (se proporciona seguridad a la capa inferior)
• Intero: 1 (difícil de estructurar en otros sistemas)
• Flex: 4 (es portable)
• Prueba: 1 (se desconoce si las capas están bien)
• Port: 4 (se recodifican las capas internas)
• Reut: 4 (las capas son reemplazables)

Cliente/Servidor (C/S)

• Mant: 4 (fácil de mantener cliente y servidor)
• Esca: 5 (se integran clientes inmediatamente)
• Fiab: 1 (complejo control de errores)
• Rend: 2 (depende de la capacidad del servidor)
• Segu: 3 (afecta a los datos de cliente y servidor)
• Intero: 4 (los clientes acceden a recursos del servidor)
• Flex: 3 (se adapta a diferentes entornos)
• Prueba: 4 (fácil de probar si un cliente accede)
• Port: 4 (adaptable a diferentes plataformas)
• Reut: 2 (integrar servidores es complejo)

Objetos Distribuidos

• Mant: 1 (necesita un experto)
• Esca: 4 (arquitectura abierta y flexible)
• Fiab: 4 (tolerante a fallos)
• Rend: 4 (permite configuración dinámica)
• Segu: 3 (difícil de controlar)
• Intero: 4 (fácil compartición)
• Flex: 4 (adaptable ante exigencias mayores)
• Prueba: 1 (difícil de probar)
• Port: 4 (permite desplazar servicios a otras máquinas)
• Reut: 4 (los objetos proveedores pueden ejecutarse en cualquier nodo)

P2P

• Mant: 1 (difícil de controlar la responsabilidad)
• Esca: 2 (difícil controlar muchos nodos)
• Fiab: 4 (pasa de un nodo a otro)
• Rend: 4 (ventaja computacional)
• Segu: 1 (difícil de controlar la seguridad)
• Intero: 4 (buena capacidad para compartir)
• Flex: 4 (adaptable a diferentes entornos)
• Prueba: 5 (cada nodo ejecuta una parte de la aplicación)
• Port: 4 (nodos repartidos)
• Reut: 1 (difícil de reutilizar)

SOA

• Mant: 4 (aplicación final sencilla de mantener)
• Esca: 5 (permite enlazar en ejecución)
• Fiab: 4 (permite reemplazar los servicios en ejecución)
• Rend: 1 (gran tiempo de respuesta)
• Segu: 2 (puede ser una desventaja)
• Intero: 4 (proporciona servicios de forma eficiente)
• Flex: 4 (adaptable a diferentes entornos)
• Prueba: No especificado
• Port: 2 (mucha dependencia del proveedor)
• Reut: 4 (un proveedor puede dar servicios a otro)

Ventajas y Desventajas

Flujo de Datos (Pipe and Filter)

• Ventajas (V): Filtros reutilizables e independientes, procesamiento en paralelo, modularidad, implementación sencilla.
• Desventajas (D): Proceso lineal forzado, no interactivo, requiere un formato de datos reconocido para todas las transformaciones.

Datos Centralizados (Repositorio)

• V: Compartición eficiente de grandes cantidades de datos, subsistemas independientes, administración centralizada, integración directa de herramientas, escalabilidad.
• D: Subsistemas coherentes con el modelo del repositorio, difícil de evolucionar, el modelo impone la misma política a todos los subsistemas, redundancia, carga de trabajo acumulativa.

Capas

• V: Arquitectura cambiable y portable, reemplazo de capas manteniendo la interfaz, cambios en la interfaz solo afectan a la capa adyacente, recodificación de capas internas para implementación en otros ordenadores.
• D: Rendimiento afectado por el número de capas, dificultad de estructuración.

Proceso de Desarrollo de Software

Se describe un proceso de desarrollo de software genérico, que consta de las siguientes fases:

1. Requisitos (Req): Definición de lo que el sistema debe hacer, incluyendo casos de uso (CU) y diagramas de clases.
2. Especificación (Especif): Identificación de componentes, interacción entre componentes y especificación de cada componente.
3. Abastecimiento: Desarrollo del código y reutilización de componentes existentes.
4. Ensamblado: Integración de los componentes.
5. Prueba: Comprobación de errores.
6. Despliegue: Empaquetado y distribución del software.