Estilos Arquitectónicos

Arquitectura del Software · UDC · Material de estudio — examen final

Arquitecturas No Distribuidas — todos los componentes en una misma máquina física

Capas

No distribuida
FiabilidadMantenibilidadPortabilidad

El sistema se divide en grupos (capas), cada una con una responsabilidad concreta. Las peticiones entran por la capa exterior, recorren todas las capas en orden y vuelven por el mismo camino. Cada capa solo habla con la adyacente.

Lo más importante
Ninguna capa se puede saltar. Aunque una capa no tenga nada que aportar a una petición, la petición pasa igualmente por ella. Una vez llega al fondo, vuelve por el camino inverso.

Ventajas

  • Mantenibilidad: cambiar una capa sin afectar a las demás
  • Reutilización de capas en otros sistemas
  • Fiabilidad: mecanismos de seguridad por capa
  • Portabilidad y soporte multi-plataforma
  • Divide el trabajo entre equipos (uno por capa)

Inconvenientes

  • Rendimiento limitado: la petición recorre todo aunque no necesite todas las capas
  • La seguridad hay que añadirla explícitamente
  • No todos los sistemas encajan bien en capas
¿Cuándo usarla?

Cuando se construyen sistemas sobre sistemas existentes, varios niveles de seguridad, o se quiere separar responsabilidades entre equipos.

Ejemplos reales

Android (buen ejemplo). Sistemas .NET. Sistemas operativos en general.

Diagramas C4

C4: Contexto

«external_system» Cliente Quiere hacer uso del sistema Envía [petición] Devuelve [resp] «system» Sistema en capas

C4: Contenedor

«external_system» Cliente Quiere hacer uso del sistema Envía Devuelve «boundary» Sistema en capas [System] «component» Capa 1 Recibe peticiones y se apoya en la siguiente capa Envía «component» Capa 2 Recibe peticiones y se apoya en la siguiente capa · · · «component» Capa N · Recibe y atiende peticiones

Pipe & Filter

No distribuida
RendimientoModificabilidad

Estructura similar a capas, pero cada etapa se llama filtro. La diferencia clave: la entrada y la salida están en puntos diferentes. El cliente envía la petición, esta recorre los filtros en secuencia y sale por el último — no vuelve al punto de partida.

Lo más importante
No es interactivo. Cada filtro procesa una vez y libera el recurso para la siguiente petición → paralelismo natural. Con N filtros, hasta N peticiones simultáneas. El cliente que envía y el que recibe la salida pueden ser diferentes.

Ventajas

  • Mejor rendimiento que capas (paralelismo)
  • Filtros reutilizables e intercambiables
  • Fácil añadir o quitar filtros sin afectar al resto

Inconvenientes

  • No sirve para sistemas interactivos
  • Encajar el sistema en filtros puede ser difícil
¿Cuándo usarla?

Procesamiento de información en etapas. Cuando quien envía y quien recibe no tienen que ser el mismo.

Ejemplos reales

Compiladores, pipelines de datos, pedidos por email, impresoras, procesamiento de imágenes.

Diagramas C4

C4: Contexto

«external_system» Cliente Quiere hacer uso del sistema Envía [petición] «system» Sistema en pipeline Genera [salida] output

C4: Contenedor

«external_system» Cliente Quiere hacer uso del sistema Envía «boundary» Sistema en pipeline [System] «component» Filtro 1 Recibe petición, procesa, envía Envía «component» Filtro 2 Recibe petición, procesa, envía ··· «component» Filtro N Recibe petición, procesa, produce salida Salida output

Repositorio

No distribuida
ModificabilidadDesacoplamiento

Existe un componente central que centraliza toda la información. Los demás componentes no se conocen entre sí — solo conocen al repositorio. El objetivo principal es el máximo desacoplamiento entre componentes.

Lo más importante
Los componentes solo se comunican con el repositorio, nunca entre ellos directamente. A veces se habla de productores (solo escriben) y consumidores (solo leen). El repositorio es el punto único de fallo.

Ventajas

  • N componentes solo necesitan 1 comunicación, no N×N
  • Componentes independientes e intercambiables
  • Bueno cuando la información es lo central del sistema

Inconvenientes

  • El repositorio es punto único de fallo
  • Si el repositorio cae, toda la comunicación se detiene
  • Puede ser cuello de botella de rendimiento
¿Cuándo usarla?

Sistemas con mucho intercambio de información entre muchos componentes. Data-driven systems. Cuando la información es lo central.

Ejemplos reales

Sistemas de artículos científicos, plataformas de recetas, sensores IoT, IDEs.

Diagramas C4

C4: Contexto

«external_system» Cliente Genera y consume información Envía [datos] Lee [datos] «system» Sistema en repositorio

C4: Contenedor

«external_system» Cliente Quiere hacer uso del sistema Envía Lee «boundary» Sistema en repositorio [System] «component» Cliente (Productor) Genera y envía info «component» Cliente (Consumidor) Lee y consume info Envía Lee «component» Repositorio Recibe, ofrece y mantiene info Usa Almacenamiento

Arquitecturas Distribuidas — componentes en máquinas físicas diferentes

Cliente / Servidor

Distribuida
RobustezEscalabilidadMantenibilidad

Funcionalidades divididas en servicios independientes. Un directorio intermediario sabe qué servicios están levantados y redirige peticiones. En la versión distribuida, cada servicio está en una máquina física diferente.

No distribuida vs Distribuida
En la no distribuida, todo en una máquina (boundary lógico). En la distribuida, cada servicio en una máquina diferente → si una cae, el resto sigue. El directorio intermediario sigue siendo punto único de fallo en ambas.

Ventajas

  • Robustez: si un servicio cae, el resto sigue
  • Escalabilidad: múltiples instancias del mismo servicio
  • Se puede lanzar con un solo servicio operativo

Inconvenientes

  • El directorio intermediario es punto único de fallo
  • Varios servicios pueden necesitar la misma BD
¿Cuándo usarla?

Cuando se quiere robustez, escalabilidad o rendimiento. Servicios heterogéneos. Construcción incremental.

Ejemplos reales

Aplicaciones web, microservicios en la nube.

Diagramas C4

C4: Contexto

«external_system» Cliente Quiere hacer uso del sistema Envía [petición] Devuelve [resp] «system» Sistema C/S distribuido

C4: Contenedor (distribuida)

«external_system» Cliente Quiere hacer uso del sistema Envía Devuelve «boundary» Sistema C/S distribuido [System] «boundary» Servidor [Container] «component» Directorio Publica el API, redirige a los servicios «boundary» Nodo 1 «component» Servicio S1 «component» Servicio S2 «boundary» Nodo 2 «component» Servicio Sn «component» Servicio Sn Redirige peticiones a los servicios correspondientes

Líder / Trabajador

Distribuida
RendimientoEscalabilidad elástica

El Líder no trabaja — solo recibe peticiones y las distribuye entre los Trabajadores. A diferencia del directorio en C/S, el líder tiene gestión activa: puede levantar o apagar trabajadores según la carga.

Diferencia clave con Cliente/Servidor
El directorio de C/S es pasivo. El líder en L/T es activo: gestiona y coordina. Puede crear más trabajadores si hay mucha carga o eliminarlos si hay poca. El líder es punto único de fallo.

Ventajas

  • Gran rendimiento: el líder solo organiza, no trabaja
  • Escalabilidad elástica a cambios de carga
  • Trabajadores intercambiables

Inconvenientes

  • El líder es punto único de fallo
  • Mal reparto si hay desajuste líder/trabajadores
¿Cuándo usarla?

Escalabilidad elástica y tiempos de respuesta eficientes. Tareas homogéneas y paralelizables. Carga que varía mucho en el tiempo.

Ejemplos reales

Sistemas de procesado masivo, colas de trabajo distribuidas, renderizado distribuido.

Diagramas C4

C4: Contexto

«external_system» Cliente Quiere hacer uso del sistema Envía [petición] Devuelve [resp] «system» Sistema líder- trabajador

C4: Contenedor

«external_system» Cliente Quiere hacer uso del sistema Envía Devuelve «boundary» Sistema líder-trabajador [System] «boundary» Servidor [Container] «component» Líder Publica API, redirige y gestiona workers «boundary» Nodo 1 T1 Worker T2 Worker Tn Worker «boundary» Nodo N T1 Worker Tn Worker El líder redirige las peticiones a los trabajadores disponibles Cada nodo no tiene por qué tener el mismo número de trabajadores

Peer-to-Peer (P2P)

Distribuida
DisponibilidadEscalabilidad

No hay directorio ni líder. Todos los nodos son iguales (peers) y tienen la misma funcionalidad completa. Una petición llega a un peer; si está disponible la atiende, si no la reenvía al peer más disponible que conozca.

Lo más importante
El cliente debe conocer al menos un peer de antemano. Se añade un máximo de saltos para evitar que una petición circule eternamente. No hay control central → la seguridad es el gran problema.

Ventajas

  • Escalabilidad y disponibilidad casi infinitas
  • No hay punto único de fallo
  • Reparto de carga distribuido y uniforme

Inconvenientes

  • Seguridad muy difícil: cualquiera puede levantar un peer malicioso
  • No se puede verificar la autoría/veracidad de los datos
  • Ausencia total de control y sincronización central
¿Cuándo usarla?

Disponibilidad y escalabilidad máximas. Seguridad no crítica. Datos no sensibles.

Ejemplos reales

BitTorrent, compartición de ficheros. NO para sistemas médicos o bancarios.

Diagramas C4

C4: Contexto

«external_system» Cliente Quiere hacer uso del sistema Envía [petición] Devuelve [resp] «system» Sistema peer-to-peer

C4: Contenedor

«external_system» Cliente Conoce al menos un peer Envía Devuelve «boundary» Sistema peer-to-peer [System] «boundary» Nodo N «component» Peer Pn Recibe peticiones, procesa o redirige «boundary» Nodo 2 «component» Peer P2 Recibe peticiones, procesa o redirige «boundary» Nodo 1 «component» Peer P1 Recibe peticiones, procesa o redirige Todos los peers son iguales · No hay directorio central Si un peer no puede atender, redirige al siguiente peer disponible

Tácticas Arquitectónicas — estrategias complementarias para atender RNFs

¿Qué es una táctica?
Una decisión de diseño que influye en una respuesta de un atributo de calidad (RNF). No son estilos, son mecanismos concretos que se añaden a un estilo para mejorar disponibilidad, rendimiento o seguridad. En el examen siempre aparecen en la parte (b) de la pregunta grande.

Tácticas de Rendimiento

Performance

Objetivo: reducir la latencia de las respuestas. Actúan sobre tres ejes: la demanda de recursos que llega al sistema, cómo se gestionan los recursos disponibles, y cómo se arbitra entre peticiones que compiten.

1. Demanda de recursos — reducir el trabajo que entra

  • →Eficiencia computacional: mejorar los algoritmos (O(n) en vez de O(n²)), usar estructuras de datos mejores.
  • →Reducir sobrecarga de comunicaciones: agrupar mensajes, comprimir datos, evitar llamadas innecesarias entre componentes.
  • →Gestionar la tasa de eventos (tasa de muestreo): limitar cuántos eventos por segundo procesa el sistema; descartar o encolar el exceso.
  • →Limitar la respuesta: poner topes a la cantidad de recursos que consume cada petición (timeouts, máx. registros devueltos…).

2. Gestión de recursos — optimizar lo que ya tenemos

  • →Concurrencia: procesar peticiones en paralelo usando hilos, procesos o workers. Evita que una petición lenta bloquee al resto.
  • →Mantener múltiples copias de datos (cache/replicación): evitar recalcular o refetchar lo mismo repetidamente.
  • →Aumentar recursos: añadir más CPU, RAM, nodos. Es la solución más directa pero la menos sostenible sin las otras.
  • →Planificador (scheduler): asignar recursos según política: Round-Robin, prioridad, basado en deadlines…

3. Arbitraje de recursos — decidir quién pasa primero

  • →FIFO: las peticiones se atienden en orden de llegada. Simple y justo, pero no distingue urgencia.
  • →Prioridad fija: cada tipo de petición tiene una prioridad asignada. Las de mayor prioridad siempre se procesan antes.
  • →Plazo límite (deadline scheduling): las peticiones con fecha límite más cercana tienen más prioridad.
Para el examen
Cuando el enunciado mencione lentitud, cuellos de botella, muchos usuarios concurrentes: propón concurrencia + cache + limitar tasa de eventos. Si hay picos de carga: añadir recursos dinámicamente (Líder/Trabajador se presta a esto de forma natural).

Tácticas de Disponibilidad

Availability

Objetivo: minimizar el tiempo fuera de servicio. Actúan en tres momentos distintos: detectar el fallo antes de que el sistema caiga, recuperarse cuando ya ha caído, y prevenir que ocurra en primer lugar.

1. Detección de errores — saber que algo ha fallado

  • →Ping / Echo: un componente envía un ping periódico a otro; si no responde en un tiempo, se marca como caído. Simple y muy común.
  • →Heartbeat (latido): el componente vigilado envía señales de vida periódicas. Si deja de enviar, el monitor actúa. Diferencia con Ping: aquí es el propio componente quien avisa.
  • →Excepciones del sistema: capturar excepciones no controladas para detectar estados inesperados del sistema antes de que colapsen.

2. Recuperación de errores — volver a funcionar

  • →Votación (voting): tres o más componentes hacen el mismo cálculo; el resultado mayoritario es el válido. Si uno discrepa, se descarta. Caro pero muy fiable (usado en aviación, medicina).
  • →Redundancia activa (hot standby): el componente de respaldo procesa las mismas peticiones que el principal en paralelo. Si el principal falla, el paso a respaldo es inmediato (0 downtime).
  • →Redundancia pasiva (warm/cold standby): el respaldo existe pero solo se activa cuando el principal falla. Hay pequeña ventana de downtime mientras se activa.
  • →Repuesto (spare): componente de reserva que se activa manualmente o automáticamente. Similar a pasivo pero la activación puede ser más lenta.
  • →Operación en sombra (shadow operation): ejecutar en paralelo el sistema nuevo y el viejo; comparar resultados antes de hacer la transición completa.

3. Prevención de errores — evitar que ocurran

  • →Retirada de servicio (service removal): sacar temporalmente del sistema un componente para mantenimiento sin afectar a los demás. Requiere que el sistema siga funcionando sin él.
  • →Transacciones: agrupar operaciones en unidades atómicas (todo o nada). Si algo falla a mitad, se hace rollback y el sistema queda en estado consistente.
  • →Monitor de procesos: un proceso guardian que supervisa el sistema y lo reinicia automáticamente si detecta que un proceso ha muerto o está bloqueado.
Para el examen
Cuando el enunciado mencione punto único de fallo, alta criticidad, 24/7: propón redundancia activa + heartbeat. Para sistemas con presupuesto limitado: redundancia pasiva + ping/echo. Si el sistema maneja datos críticos: transacciones.

Tácticas de Seguridad

Security

Objetivo: proteger el sistema de accesos y modificaciones no autorizadas. El enfoque es en tres capas: resistir el ataque, detectarlo mientras ocurre, y recuperar el sistema después.

1. Resistir ataques — hacer difícil el ataque

  • →Autenticación de usuarios: verificar que quien dice ser X es realmente X. Contraseñas, tokens, certificados, biometría.
  • →Autorización de usuarios: verificar que X tiene permiso para hacer la operación Y. RBAC, ACLs, políticas.
  • →Confidencialidad de datos: cifrar los datos en tránsito (TLS) y en reposo (AES). Nadie sin la clave puede leerlos.
  • →Integridad de datos: checksums, firmas digitales, hashes. Detectar si los datos han sido modificados en tránsito.
  • →Exposición limitada: minimizar la superficie de ataque. Exponer solo los puertos/servicios/endpoints estrictamente necesarios.
  • →Limitación de acceso: firewalls, DMZs, redes privadas. Controlar de dónde puede llegar tráfico al sistema.

2. Detección de ataques — saber que te están atacando

  • →Detección de intrusos (IDS): monitorizar patrones de acceso anómalos (muchos intentos fallidos, accesos en horarios inusuales, peticiones a recursos no existentes). Genera alertas.

3. Recuperación de ataques — volver al estado seguro

  • →Restauración de estado: backups, snapshots, puntos de restauración. Permiten volver a un estado previo al ataque cuando se detecta que el sistema ha sido comprometido.
  • →Identificación de atacantes: logs de auditoría detallados, trazabilidad completa. No previene el ataque, pero permite analizar qué pasó y perseguir responsabilidades.
Para el examen — P2P y seguridad
P2P tiene seguridad muy baja por diseño (no hay nodo central que controle). Si eliges P2P pero el enunciado requiere seguridad, justifica que lo compensas con tácticas: autenticación en cada peer, cifrado extremo a extremo, IDS en la red, limitar exposición. Esto es aceptable como respuesta.

Tabla comparativa

EstiloPunto único falloEscalabilidadRendimientoSeguridadDisponibilidad
CapasNoBajaLimitadoMediaMedia
Pipe & FilterNoMediaAlta (paralelo)MediaMedia
RepositorioSí (repositorio)MediaMediaMediaBaja si cae
C/S DistribuidaSí (directorio)AltaAltaMediaAlta
Líder / TrabajadorSí (líder)Muy altaMuy altaMediaAlta
P2PNoMuy altaVariableMuy bajaMuy alta

Guía para el examen

Repositorio vs P2P (sale en casi todos los exámenes)
— Si el enunciado menciona seguridad, autoría, control de quién publica: elige Repositorio.
— Si el enunciado prioriza disponibilidad, millones de usuarios, sin datos sensibles: elige P2P.
— P2P + necesidad de seguridad = menciona tácticas de seguridad como compensación.
Capas vs Pipe & Filter
— Si la petición necesita respuesta directa al mismo cliente: Capas.
— Si el procesamiento es en etapas y la salida va a otro lugar: Pipe & Filter.
Cliente/Servidor vs Líder/Trabajador
— C/S: cuando los servicios son heterogéneos (cada uno hace cosas distintas).
— L/T: cuando las tareas son homogéneas y paralelizables y la carga varía mucho.
Estructura de la respuesta de la pregunta grande
(a) Ventajas e inconvenientes de la opción elegida, argumentando cómo responde a los RNF del enunciado.
(b) Tácticas complementarias: qué tácticas de disponibilidad / rendimiento / seguridad aplicarías y cómo. Siempre nombrar la táctica y explicar cómo se aplica al sistema concreto del enunciado.
(c) Dibujar los 3 primeros niveles C4: Contexto → Contenedor → Componentes.
Tácticas más frecuentes en exámenes pasados
— Disponibilidad: Ping/Echo o Heartbeat para detectar fallos + Redundancia activa/pasiva para recuperarse + Monitor de procesos.
— Rendimiento: Concurrencia + Cache (múltiples copias de datos) + Limitar tasa de eventos.
— Seguridad: Autenticación + Autorización + Confidencialidad (cifrado) + IDS para detección.
RNFs más comunes en enunciados y qué tácticas aplicar
— "El sistema debe estar disponible 24/7" → Redundancia activa + Heartbeat + Monitor de procesos.
— "Miles de usuarios concurrentes" → Concurrencia + Cache + Aumentar recursos + Limitar tasa.
— "Datos sensibles / privacidad" → Autenticación + Autorización + Confidencialidad + Exposición limitada.
— "Si un nodo falla, el sistema sigue" → Redundancia pasiva / Repuesto + Ping/Echo.
— "Auditoría / trazabilidad" → Identificación de atacantes (logs) + Integridad de datos.