Tema 9: Diseño Arquitectónico

📝 Resumen Ejecutivo

Esta sesión marca la transición del Análisis (el Qué) al Diseño (el Cómo), enfocándose en la estructura de alto nivel del software. Se clasifican y explican los principales estilos y patrones arquitectónicos (Centrados en datos, Flujo de datos, Capas, etc.), analizando sus ventajas y desventajas (especialmente el rendimiento vs. mantenibilidad). Finalmente, se introducen los Principios Generales de Sistemas de Bertalanffy para justificar la ingeniería del software como una disciplina ingenieril formal.

🔑 Conceptos Clave

Diseño Arquitectónico: La estructura global del sistema, sus componentes, propiedades visibles y relaciones.

Patrón de Diseño: Una solución probada para un problema recurrente dentro de un contexto específico.
Acoplamiento y Cohesión: Métricas fundamentales (repaso); buscamos alta cohesión (independencia funcional) y bajo acoplamiento (pocas dependencias).
Pipes & Filters (Tuberías y Filtros): Arquitectura de procesamiento secuencial de datos.
Arquitectura en Capas (Layers): Estructura jerárquica donde cada capa ofrece servicios a la superior y abstrae la complejidad de la inferior.
Teoría General de Sistemas: Estudio de las características comunes de los sistemas (especialización, tamaño y estructura).

📚 Desarrollo del Temario

1. Contexto del Proceso de Ingeniería

El diseño arquitectónico no es un paso aislado, sino una evolución.

Evolución de la vista:
Requisitos y Análisis: Entendemos el problema ("¿QUÉ?").

Diseño: Planteamos la solución ("¿CÓMO?").

Implementación: Construcción real (e.g., Java).

Naturaleza del proceso: Aunque se dibuje lineal, en la práctica (y en metodologías ágiles) es iterativo e incremental. Los requisitos evolucionan, por lo que la arquitectura también debe hacerlo.
La Pirámide del Diseño: El diseño arquitectónico se sustenta sobre el diseño de datos (Modelo de Dominio). Antes de organizar los subsistemas, debemos tener claras las clases y datos.

¡OJO AL DATO!: El profesor enfatiza que diseñar es más barato que implementar. Es como hacer el plano de una casa; es mucho más fácil mover una pared en el papel (diseño) que tirarla abajo cuando la casa está construida (código).

2. Definición de Arquitectura de Software

Arquitectura de Software: La estructura o estructuras del sistema, compuestas por componentes, sus propiedades visibles y las relaciones entre ellos.

Objetivos: * Analizar la efectividad para cumplir requisitos. * Considerar alternativas arquitectónicas antes de que sea costoso cambiar (reducción de riesgos).

Nivel de detalle: A nivel arquitectónico NO entramos en detalles algorítmicos. Nos enfocamos en la interacción entre subsistemas (normalmente mediante interfaces).

3. Tipología de Arquitecturas

No hay una "receta única". Debemos identificar el contexto del problema para elegir el estilo adecuado.

A. Arquitecturas Centradas en Datos

El núcleo del sistema es un almacén de datos (repositorio) al que acceden múltiples clientes.

Estructura: Un almacenamiento central (base de datos, archivo) rodeado de software cliente.

Tipos de Almacenamiento: 1. Pasivo: El cliente tiene el control. Accede, lee o escribe cuando quiere.

Activo: El almacenamiento notifica a los clientes cuando hay cambios en los datos de su interés (mayor complejidad).
Ventaja: Facilita enormemente la integración de nuevos clientes (escalabilidad de clientes).

B. Arquitecturas de Flujo de Datos (Pipes & Filters)

Ideal para transformaciones secuenciales de información.

Estructura: Entrada \rightarrow Procesamiento \rightarrow Salida.
Componentes:
Filtros (Filters): Transforman los datos. No necesitan saber quién les envía los datos ni a quién se los pasan.
Tuberías (Pipes): Conectores que llevan el flujo de salida de un filtro a la entrada del siguiente.
Requisito Crítico: Los formatos de datos deben estar estandarizados. Si cada filtro habla un "idioma" distinto, el patrón falla.

Ejemplo del Profesor (Tesis Doctoral - Visión Artificial): Un robot ("Arbibot") procesa imágenes del suelo. 1. Input: Imagen cruda. 2. Filtro 1: Detección de bordes (Canny). 3. Filtro 2: Detección de esquinas (Shi-Tomasi). 4. Output final: Array de puntos.

Ventaja: Si quieres cambiar el algoritmo de detección de esquinas, sacas el filtro viejo y pones el nuevo. Mientras respeten la estructura de datos (Input/Output), el sistema sigue funcionando.
Desventajas: No son apropiadas para aplicaciones interactivas (donde el usuario interviene constantemente) y pueden tener problemas de rendimiento por el trasiego de datos.

C. Arquitecturas de Llamar y Regresar

La estructura clásica jerárquica.

Programa Principal / Subprograma: Un programa principal invoca a otros componentes, que a su vez invocan a otros. Control jerárquico.
Llamada a Procedimiento Remoto (RPC): Lo mismo, pero los subprogramas pueden estar distribuidos en diferentes máquinas/sistemas.
Ventaja: Fácil de modificar y escalar la lógica de control.

D. Arquitecturas Orientadas a Objetos

Es el estándar actual para sistemas generalistas.

Los componentes son Clases (encapsulan datos + operaciones).
La comunicación se realiza mediante mensajes (métodos).
Clave: La estructura arquitectónica nace directamente del Modelo de Dominio y el Diagrama de Clases.

E. Arquitecturas en Capas (Layered Architecture)

Organiza el sistema en niveles de abstracción.

Regla de Oro: Las capas superiores usan servicios de las inferiores (caja negra). Las capas inferiores no dependen de las superiores.

Ejemplo Canónico: Modelo OSI / TCP-IP. * Cuando pides una web, la capa de Aplicación solo dice "dame index.html". * Delega la complejidad a Transporte (gestión de procesos). * Este delega a Red (enrutamiento de paquetes). * Este delega a Física (mandar pulsos de luz o eléctricos). * Cada capa resuelve un problema y se olvida de cómo lo hace la de abajo.

Ventajas: Reutilización (puedes cambiar una capa entera si mantienes la interfaz), estandarización, facilidad de desarrollo distribuido.

Desventajas (¡Importante para examen!):

Afecta al rendimiento: Atravesar muchas capas añade sobrecarga (overhead).
Seguridad vs. Rendimiento: El profesor destaca que añadir seguridad (capas de cifrado, comprobación) siempre se paga con rendimiento.

4. Patrones POSA (Pattern-Oriented Software Architecture)

El profesor menciona varios patrones arquitectónicos clave del libro "Pattern-Oriented Software Architecture" (POSA): * Sistemas Interactivos: MVC (Modelo-Vista-Controlador). * Sistemas Distribuidos: Broker, Pipes & Filters. * Estructuración: Layers.

5. Principios Generales de Sistemas (Bertalanffy)

El profesor utiliza esto para reivindicar la Informática como Ingeniería. Si un sistema de software cumple con la Teoría General de Sistemas, puede tratarse con procesos ingenieriles.

Los 3 Principios Clave:

A mayor especialización, menor capacidad de adaptación:
Ejemplo: Un software hecho solo para gestionar una "fresería" específica es difícil de adaptar para gestionar un restaurante genérico. Un sistema genérico es más adaptable pero menos especializado.
A mayor tamaño del sistema, mayor número de recursos para mantenimiento:
El coste de mantenimiento crece con la complejidad y el tamaño. Gestionar mis finanzas personales (Excel) es gratis; gestionar las del Banco Santander requiere miles de ingenieros.
Jerarquía (Sistemas y Subsistemas):
Todo sistema está formado por subsistemas y, a su vez, forma parte de un suprasistema.
Esto permite la descomposición (Divide y Vencerás) y el análisis de Caja Negra (conocer solo entradas/salidas I/O).

6. Contexto del Sistema

Para entender un sistema, debemos mirar sus interacciones externas:

Sistemas Superiores: Usan nuestro sistema.
Sistemas Subordinados: Nosotros los usamos (dependemos de ellos).
Pares (Peers): Interacción en igualdad (intercambio de info). Actores: Entidades (personas o sistemas) que interactúan/ejecutan acciones en el sistema.

🧠 Preguntas de Autoevaluación

Diferencia clave entre almacenamiento pasivo y activo en una arquitectura centrada en datos:
Respuesta: En el pasivo, el cliente tiene el control total y solicita datos. En el activo, el almacenamiento tiene lógica para notificar a los clientes automáticamente cuando ocurren cambios relevantes.
¿Cuál es el principal requisito para que funcione una arquitectura de "Pipes & Filters" y por qué no se recomienda para apps interactivas?
Respuesta: Requiere formatos de datos estandarizados entre filtros. No se recomienda para apps interactivas porque está pensada para procesamiento secuencial por lotes (batch) o flujos continuos, no para respuestas inmediatas a acciones aleatorias del usuario, y es difícil gestionar filtros incrementales.
Explica la relación entre la Arquitectura en Capas (Layers) y el rendimiento.
Respuesta: Aunque las capas mejoran la organización y reutilización, afectan negativamente al rendimiento debido a la sobrecarga (overhead) de pasar los datos y el control a través de múltiples niveles de abstracción.
Según la Teoría General de Sistemas explicada en clase, ¿qué ocurre si diseñamos un software extremadamente especializado?
Respuesta: Según el primer principio, tendrá una menor capacidad de adaptación. Será muy bueno para su tarea específica, pero costoso o imposible de reutilizar en otro contexto similar.
¿Qué aporta el diagrama de subsistemas (Vista Arquitectónica) que no aporte el diagrama de clases?
Respuesta: Proporciona una visión general ("Big Picture") agrupando clases en unidades funcionales (paquetes/subsistemas). Reduce la complejidad visual y permite entender las dependencias y el acoplamiento a alto nivel sin perderse en el detalle de miles de clases individuales.