Clase 8 — Tema 5: Patrones de arquitectura generales

Resumen Ejecutivo

Inicio del bloque de arquitectura (tema 5) con un repaso a los patrones arquitectónicos generales que muchos ya conocen de otras asignaturas. Refresco intencionado: la próxima sesión (tema 6) entrará en patrones específicos de cloud. Se ven (1) la diferencia patrón de arquitectura vs patrón de diseño, (2) la conexión con los requisitos no funcionales (rendimiento, seguridad, protección, disponibilidad, mantenibilidad), (3) el catálogo de patrones generales — cliente-servidor (clientes ligeros / pesados, dos / tres niveles), pipes & filters, multicapa, repositorio, maestro-esclavo, peer-to-peer, sistemas distribuidos — y (4) los patrones para confiabilidad (sistema de protección con monitor redundante, N-version programming). Se cierra hablando del artículo de la arquitectura de Netflix subido al foro y un debate sobre el uso (y abuso) de IA en las entregas. ⚠️ EXAMEN: distinguir requisito funcional vs no funcional, conocer el catálogo de patrones, ejemplos de cliente ligero / pesado, propósito de N versiones y monitor redundante.

Conceptos Clave

Patrón de arquitectura: representación esquemática de alto nivel del sistema, en bloques o módulos. Los temas 5 y 6 hablan de eso. ⚠️ EXAMEN
Patrón de diseño: patrones a nivel de clases del software (tema 7). MVC es el clásico que solapa ambos mundos.
Requisito funcional: describe qué hace el sistema (acciones, servicios, procesamientos). Se redacta como acción ("cuando el usuario X, el sistema Y").
Requisito no funcional (NFR): describe cómo se comporta el sistema (rendimiento, fiabilidad, etc.) o restricciones. ⚠️ EXAMEN — distinguirlo del funcional es la pregunta más típica.
Confiabilidad (dependability): propiedad agregada que combina protección + fiabilidad + disponibilidad + seguridad. ⚠️ EXAMEN
Protección (safety): evitar que el sistema falle por causas internas (bugs, bucles infinitos, desbordamientos).
Seguridad (security): evitar que el sistema falle por amenazas externas (intrusos, ataques). ⚠️ EXAMEN — diferencia safety/security
Fiabilidad: los resultados que ofrece el sistema son correctos.
Disponibilidad: fracción de tiempo durante el que el sistema da servicio.
Mantenibilidad: facilidad para actualizar el software de un módulo o subsistema.
Cliente ligero (thin client): solo capa de presentación. Ejemplos: Telnet, navegador con páginas ASP/PHP/JSP. ⚠️ EXAMEN
Cliente pesado (rich client): capa de presentación + lógica de negocio o datos. Ejemplos: app de Instagram (filtros locales), gestor de inventario por sucursal.
Cliente-servidor de 2 niveles físicos: servidor único con dos capas lógicas (web + datos en la misma máquina).
Cliente-servidor de 3 niveles físicos: servidor web, servidor de datos, servidor de imágenes/audio en máquinas separadas. Permite escalabilidad independiente. ⚠️ EXAMEN
Pipes & filters: nodos especializados (filtros) conectados por tuberías; cada filtro consume la salida del anterior. Ejemplo canónico: compilador. ⚠️ EXAMEN
Arquitectura multicapa (layered): cada capa actúa como servidor de la inmediatamente superior, que es su cliente. Ejemplo: pila Android, modelo OSI.
Arquitectura de repositorio: repositorio central de datos compartido por varios subsistemas. Ejemplo: HIS hospitalario.
Maestro-esclavo: un nodo coordina, el resto ejecutan. Ni siempre el maestro es servidor; depende de quién pide la información. ⚠️ EXAMEN
Peer-to-peer (P2P): todos los nodos son a la vez cliente y servidor. eMule, BitTorrent, SETI@home.
P2P semicentralizada: existen superpares (centralitas) que aceleran el descubrimiento. Análogo conceptual al DNS.
Monitor / sistema de protección redundante: sistema en paralelo que monitoriza y, ante anomalías, toma el control o aborta. ⚠️ EXAMEN
N-version programming: N implementaciones independientes de la misma especificación, ejecutadas en paralelo; se compara la salida (votación, mayoría). Equipos, lenguajes y máquinas distintos para minimizar errores comunes. ⚠️ EXAMEN

Desarrollo del Temario

1. ¿Por qué importan los patrones de arquitectura?

Cuatro motivos (de la diapositiva-resumen del profesor):

Análisis del sistema → identificar bloques con cohesión alta y acoplamiento bajo.
Comunicación → herramienta para dialogar con compañeros, equipos, cliente.
Reutilización → reusamos diseños y conocimiento, no solo código.
Decisiones técnicas → influyen en planificación, asignación de equipos, metodologías por subsistema.

"Una empresa grande como Netflix o Spotify no se gestiona toda con la misma metodología. Los equipos de codificadores, CDN, frontend web, app móvil… cada uno puede llevar su variante."

2. Diferencia patrón de arquitectura vs patrón de diseño ⚠️ EXAMEN

Patrón de arquitectura (T5-T6)	Patrón de diseño (T7)
Alto nivel: subsistemas, bloques	Bajo nivel: clases, objetos
Define la estructura macro	Define la estructura interna
Ejemplos: Cliente-servidor, P2P, capas, repositorio	Ejemplos: Singleton, Factory, Observer
MVC entra aquí cuando se aplica a la macro de la app web	MVC entra también aquí cuando se materializa en clases

MVC es el ejemplo de patrón que pisa los dos mundos.

3. Requisitos no funcionales como motor de la arquitectura ⚠️ EXAMEN

3.1 Distinguir funcional vs no funcional

"Hay gente que tiene empanada con esto." — del profesor.

Si el requisito describe algo que el sistema hace ("cuando el usuario envía sus datos, el sistema los encripta con AES-256") → funcional, aunque hable de seguridad.
Si el requisito describe una restricción global o una propiedad agregada ("toda la información clasificada como secreta debe encriptarse con AES-256") → no funcional.

⚠️ Clave: seguridad en el enunciado no implica que sea NFR. Lo que define la categoría es la forma en que está escrito y el alcance.

3.2 Taxonomía de Sommerville

flowchart TB
    NFR[Requisitos no funcionales]
    NFR --> P[De producto]
    NFR --> O[Organizacionales]
    NFR --> E[Externos]
    P --> P1[Eficiencia<br/>rendimiento + espacio]
    P --> P2[Usabilidad]
    P --> P3[Fiabilidad]
    P --> P4[Portabilidad]
    P --> P5[Protección/Seguridad]
    O --> O1[Plazos de entrega]
    O --> O2[Implementación<br/>p. ej. lenguaje, no usar punteros]
    O --> O3[Estándares]
    E --> E1[Legales]
    E --> E2[Éticos]

3.3 Cómo cada NFR afecta a la arquitectura

NFR	Implicación arquitectónica
Rendimiento	Procesos en máquinas con buena GPU/CPU según carga; minimizar latencias de red; agrupar máquinas geográficamente.
Seguridad (security)	Aislar datos críticos; arquitecturas en capas con cortafuegos; bunkers de datos.
Protección (safety)	Redundancia, sistemas de monitoreo, N versiones.
Disponibilidad	Redundancia activa/pasiva; balanceadores; clústeres.
Mantenibilidad	Microservicios, pipes & filters, separación clara de responsabilidades.

Anécdota del profesor: en un proyecto militar en C estaban prohibidos los punteros (NFR de implementación) porque su mal uso podía provocar desbordamientos en sistemas críticos.

4. Cliente-servidor

4.1 Idea general

Dos roles:

Servidor: ofrece servicios (web, base de datos, impresión, audio, vídeo).
Cliente: los consume.

Hay más clientes que servidores → el servidor suele ser más potente.

Puede estar dentro de la misma máquina: un proceso A actúa como servidor de un proceso B en el mismo host. No es necesario que sea distribuido.

4.2 Cliente ligero vs cliente pesado ⚠️ EXAMEN

flowchart LR
    subgraph Ligero
        T[Telnet / navegador puro]
    end
    subgraph Pesado
        I[App Instagram con filtros locales]
        E[Gestor inventario sucursal]
    end
    T -- todo el procesamiento --> S1[Servidor]
    I -- consultas finales --> S2[Servidor]
    E -- sync periódica --> S3[Servidor central]

	Ligero	Pesado
Capas en cliente	Solo presentación	Presentación + parte de lógica/datos
Ejemplo	Telnet, ASP/PHP/JSP renderizado en server	Instagram móvil, Word de escritorio, gestor sucursales
Recursos en cliente	Pocos	Muchos
Ventajas	Menor exposición de datos sensibles, infra centralizada	Menor coste de cómputo en servidor (lo paga el proveedor)
Inconvenientes	Necesita servidor potente y red rápida	Más coste en hardware del cliente, sincronización compleja

Reflexión en clase: estamos volviendo a terminales ligeros (todo en cloud) pero con matiz: hay mucho JavaScript en el navegador, así que el cliente no es tan ligero. Cada ciclo de servidor cuesta dinero al proveedor → siempre interesa empujar cómputo al cliente cuando sea seguro.

4.3 Cliente-servidor de 2 vs 3 niveles físicos ⚠️ EXAMEN

2 niveles físicos:
[Cliente] ── red ── [Servidor con web + BD en la misma máquina]
                     ej: blog en una droplet de DigitalOcean

3 niveles físicos:
[Cliente] ── red ── [Servidor web]
                          ├── [Servidor de BD]
                          └── [Servidor de imágenes/audio]

Ventaja del 3 niveles: escalabilidad independiente. Si crece el almacenamiento pero no las peticiones, escalas solo el almacén.

5. Pipes & filters

5.1 Idea

Cada filtro es un nodo de procesamiento especializado. Los filtros se comunican por tuberías (la salida de uno es la entrada del siguiente). Bloques independientes y sustituibles mientras respeten el formato del flujo.

flowchart LR
    A[Código fuente] --> B[Análisis léxico]
    B --> C[Análisis sintáctico]
    C --> D[Análisis semántico]
    D --> E[Generación de código]

Ejemplo canónico: compilador. Cada fase es un filtro; los tokens, árboles y representaciones intermedias son las tuberías. ⚠️ EXAMEN

Otros ejemplos: Apache Cocoon (XML transforms), pipelines de Unix (grep | sort | uniq).

5.2 ¿Es lo mismo que un pipeline DevOps?

Pregunta de Marco Antonio: "¿no es lo mismo un pipeline de DevOps?"

Conceptualmente similar (grafo dirigido), pero no idéntico: un pipeline DevOps no transforma datos sino que ejecuta etapas (build, test, deploy). En pipes & filters cada filtro produce un dato de salida consumido por el siguiente.

6. Arquitectura multicapa

Cada capa actúa como servidor de la capa superior y cliente de la capa inferior.

6.1 Ejemplo: pila Android

+----------------------------------------+
|        Aplicaciones (usuario, OEM)     |
+----------------------------------------+
|     Framework Java (Android SDK)       |
+----------------------------------------+
|  Runtime (Dalvik/ART) + libs nativas   |
+----------------------------------------+
|        HAL (Hardware Abstraction)      |
+----------------------------------------+
|              Kernel Linux              |
+----------------------------------------+
|                Hardware                |
+----------------------------------------+

Apunte: en Android se puede programar también en C vía NDK para librerías de procesamiento de imagen/audio.

Ejemplo análogo: modelo OSI / TCP-IP.

7. Arquitectura de repositorio

Un repositorio central de datos al que acceden múltiples subsistemas.

flowchart LR
    A[Admisión urgencias]
    B[Gestión de planta]
    C[Consulta médico]
    D[Farmacia]
    R[(Repositorio HIS)]
    A --> R
    B --> R
    C --> R
    D --> R

Indicado cuando hay gran volumen de información compartida o cuando la información es sensible y conviene tenerla protegida en un único punto.

8. Patrones para confiabilidad ⚠️ EXAMEN

Se aplican cuando el sistema es crítico: si falla puede haber muertes, daños ambientales, pérdidas reputacionales o económicas grandes.

8.1 Sistema con monitor / protector

flowchart LR
    subgraph Sistema_Principal
        S1[Sensores]
        C1[Control]
        A1[Actuadores]
        S1 --> C1 --> A1
    end
    subgraph Monitor
        S2[Sensores propios]
        C2[Algoritmos<br/>de seguridad]
        S2 --> C2
    end
    C2 -. supervisa .-> A1
    C2 -- toma control si detecta anomalía --> A1

El monitor tiene sus propios sensores y algoritmos.
Si detecta una desviación, toma prioridad sobre los actuadores.
Aplicaciones: control de aviones, misiles, vehículos autónomos, frenado de emergencia ferroviario.

8.2 N-version programming

flowchart LR
    I[Entradas comunes] --> A[Versión A<br/>equipo 1, lenguaje 1]
    I --> B[Versión B<br/>equipo 2, lenguaje 2]
    I --> C[Versión C<br/>equipo 3, lenguaje 3]
    A --> V[Comparador / votación]
    B --> V
    C --> V
    V --> O[Salida final]

Las N versiones parten de la misma especificación pero las desarrollan equipos independientes con tecnologías y máquinas diferentes.
Se comparan las N salidas: si todas coinciden, todo bien; si una discrepa de las demás, esa versión está fallando.
Equipos distintos minimizan errores correlacionados.

Diferencia con el monitor: aquí todas las versiones funcionan, no hay un "principal" y un "secundario" — el resultado se decide por votación. En el monitor hay un sistema canónico y otro que lo vigila.

⚠️ EXAMEN: las dos arquitecturas son complementarias, no excluyentes. Cada versión podría a su vez tener su propio monitor.

9. Maestro-esclavo

9.1 Idea

Un maestro coordina; los esclavos ejecutan tareas o reportan información.

9.2 No es lo mismo que cliente-servidor

⚠️ EXAMEN — distinción sutil:

En cliente-servidor el rol es estable: el cliente pide, el servidor responde.
En maestro-esclavo cualquiera puede ser cliente o servidor según el flujo:
El esclavo notifica al maestro → el esclavo es cliente, el maestro es servidor.
El maestro consulta al esclavo → el maestro es cliente, el esclavo es servidor.

9.3 Ejemplos

Sistemas SCADA (Homer Simpson en la central nuclear).
Control de tráfico.
Robótica industrial.
Domótica.

Nota terminológica: en GitHub/Git ya cambió master por main. En arquitectura sigue usándose por inercia, pero la dirección es similar.

10. Peer-to-peer

10.1 P2P puro

Todos los nodos son iguales: clientes y servidores simultáneos. No hay coordinación central.

Ejemplos: eMule, BitTorrent, SETI@home.
Problema: encontrar información lleva muchos saltos. Cada nodo solo conoce a algunos vecinos.

10.2 P2P semicentralizada (con superpares)

flowchart LR
    SP1[Superpar 1]
    SP2[Superpar 2]
    SP1 --- SP2
    P1[Peer A] --- SP1
    P2[Peer B] --- SP1
    P3[Peer C] --- SP2
    P4[Peer D] --- SP2

Los superpares actúan como centralitas que aceleran el descubrimiento.

Análogo conceptual al DNS, pero orientado a archivos / procesamiento.

11. Sistemas distribuidos en general

Procesos o máquinas independientes que se ven como un único sistema desde fuera.

Beneficios	Inconvenientes
Escalabilidad independiente	Mayor complejidad de diseño
Componentes especializados (cohesión alta, acoplamiento bajo)	Necesidad de middleware estándar
Más fácil sustituir / actualizar piezas	Latencias de red
Redundancia natural	Problemas de consistencia

Apunte histórico del profesor: en informática industrial los buses de campo propietarios (Profibus, Profinet, etc.) creaban "jardines vallados" entre fabricantes. Hoy es menos problema gracias a estándares e Internet.

12. Avance al tema 6

El próximo tema cubrirá patrones específicos del cloud (microservicios, event-driven, serverless, CQRS…). Lectura recomendada: el artículo sobre arquitectura de Netflix subido al foro de dinamización. La idea: que tras los temas 5 y 6 podáis leer el artículo y entender los conceptos.

Ejemplos / Ejercicios resueltos

Ejemplo 1 — Identificar funcional vs no funcional

Requisito	Tipo	Justificación
"Cuando el usuario hace login, el sistema cifra la contraseña con bcrypt antes de almacenarla."	Funcional	Acción que el sistema hace.
"Toda información clasificada como secreta debe almacenarse cifrada con AES-256."	No funcional	Restricción global sobre la información.
"El sistema debe procesar al menos 20 000 peticiones/segundo."	No funcional (rendimiento)	Métrica medible.
"Cuando el inventario baja de 5 unidades, el sistema envía un email al gerente."	Funcional	Servicio concreto.
"El sistema estará disponible al menos el 99,9% del tiempo."	No funcional (disponibilidad)	Métrica estadística.

Ejemplo 2 — Cliente ligero o pesado

Sistema	Tipo	Razón
Conexión SSH a un servidor para ejecutar comandos	Ligero	El cliente solo muestra texto y envía teclas.
Aplicación de banca móvil con autenticación biométrica local	Pesado	Hace cómputo local (huella, validaciones).
Web de Wikipedia (modo lectura)	Casi ligero	El servidor renderiza HTML; el cliente solo lo muestra.
Spotify de escritorio	Pesado	Cachea audio, mezcla, ecualiza local.

Ejemplo 3 — Detectar el patrón

Sistema	Patrón
Compilador GCC	Pipes & filters
Sistema operativo Linux	Multicapa
Centro de salud con BD compartida	Repositorio
Sistema de control de tráfico aéreo	Maestro-esclavo + redundancia + N-version
BitTorrent	P2P
Tienda online típica con frontend, API y BD en máquinas separadas	Cliente-servidor 3 niveles

Preguntas de Autoevaluación

¿Qué diferencia hay entre un patrón de arquitectura y un patrón de diseño? Pon un ejemplo de cada uno.
¿Cómo distingues un requisito funcional de uno no funcional? Da un ejemplo de un requisito relacionado con seguridad que sea funcional y otro que sea no funcional.
Define confiabilidad y enumera los cuatro NFR que la componen.
Diferencia safety y security y pon un ejemplo concreto de cada uno.
¿Qué es un cliente ligero? Pon dos ejemplos. ¿Y un cliente pesado? Otros dos.
Compara cliente-servidor de 2 niveles físicos con uno de 3 niveles físicos. ¿Cuál es la principal ventaja arquitectónica del segundo?
Explica la arquitectura pipes & filters poniendo como ejemplo el funcionamiento de un compilador. Indica al menos dos beneficios y un inconveniente.
Describe la pila de Android usando el patrón multicapa. ¿Qué capa actúa como cliente y servidor a la vez?
¿Cuándo elegirías una arquitectura de repositorio frente a una distribuida en sucursales? Da un ejemplo concreto del sector salud.
¿Qué hace un monitor / sistema de protección redundante? Explica con un sistema de un avión en qué momento toma el control.
Describe N-version programming y por qué se desarrollan las versiones por equipos distintos con lenguajes distintos. ¿Qué pasa si todas las versiones tienen el mismo bug?
¿En qué se diferencia maestro-esclavo de cliente-servidor? Pon un caso donde el maestro actúe como servidor y otro donde actúe como cliente.
¿Por qué las arquitecturas P2P puras necesitan superpares? ¿Qué problema resuelve el superpar?
Cita dos beneficios y dos inconvenientes de los sistemas distribuidos.
Si un proyecto militar prohíbe el uso de punteros en C, ¿es un requisito funcional o no funcional? ¿Y a qué subcategoría pertenece?
¿Cómo justificarías arquitectónicamente el uso combinado de un monitor redundante y N-version programming en un sistema de guiado autónomo? ¿Son patrones excluyentes?