TEMA 2: ARQUITECTURA DE SISTEMAS CLIENTE/SERVIDOR Y MULTICAPAS

Guía completa para oposiciones — Teoría + Práctica

ÍNDICE

1. Arquitectura Cliente/Servidor
2. Arquitecturas Multicapas (N-Tier)
3. Arquitecturas de Servicios Web y Protocolos
4. Control de Versiones: Git
5. Metodologías de Desarrollo
6. Pruebas de Software
7. Construcción de Software (Build)
8. Resumen para Examen

1. ARQUITECTURA CLIENTE/SERVIDOR

1.1 Concepto y Definición

La arquitectura cliente/servidor es un modelo de computación distribuida en el que las tareas o cargas de trabajo se reparten entre los proveedores de recursos o servicios, llamados servidores, y los demandantes de dichos servicios, llamados clientes.

Características fundamentales:
- El cliente inicia la comunicación (rol activo).
- El servidor espera peticiones y las atiende (rol pasivo).
- La comunicación se realiza a través de una red.
- El servidor puede atender a múltiples clientes simultáneamente.

1.2 Componentes Principales

Cliente

• Interfaz de usuario.
• Lógica de presentación.
• Envía solicitudes al servidor.
• Puede ser: navegador web, aplicación de escritorio, app móvil.

Servidor

• Procesa las peticiones de los clientes.
• Gestiona recursos (bases de datos, archivos, impresoras).
• Devuelve respuestas.
• Tipos: servidor web, servidor de aplicaciones, servidor de base de datos, servidor de archivos.

Red de Comunicaciones

• Protocolo de comunicación (TCP/IP, HTTP, FTP, etc.).
• Puede ser LAN, WAN o Internet.

1.3 Modelos de Arquitectura Cliente/Servidor

Modelo de 2 capas (2-Tier)

[CLIENTE] <---red---> [SERVIDOR]
  (UI + lógica)       (BD + datos)

Modelo de 3 capas (3-Tier)

[CLIENTE] <---> [SERVIDOR DE APLICACIONES] <---> [SERVIDOR BD]
   (UI)          (lógica de negocio)               (datos)

1.4 Tipos de Servidores

1.5 Ventajas e Inconvenientes

Ventajas:
- Centralización de recursos y datos.
- Facilidad de mantenimiento y actualización.
- Seguridad centralizada.
- Escalabilidad (vertical y horizontal).
- Múltiples clientes comparten recursos.

Inconvenientes:
- Dependencia de la red.
- Cuello de botella en el servidor.
- Mayor coste inicial de infraestructura.
- Punto único de fallo (si no hay redundancia).

1.6 Patrones de Comunicación

Síncrono

• El cliente espera la respuesta del servidor.
• Modelo petición-respuesta (Request-Response).
• Ejemplo: HTTP tradicional.

Asíncrono

• El cliente no espera; recibe notificación cuando la respuesta está lista.
• Ejemplos: WebSockets, colas de mensajes (RabbitMQ, Kafka).

Push vs Pull

• Pull: el cliente solicita datos al servidor (modelo HTTP estándar).
• Push: el servidor envía datos al cliente sin solicitud previa (WebSockets, Server-Sent Events).

2. ARQUITECTURAS MULTICAPAS (N-TIER)

2.1 Concepto

La arquitectura multicapas (N-tier) es una extensión del modelo cliente/servidor donde la aplicación se divide en múltiples capas lógicas y físicas, cada una con responsabilidades bien definidas y que se comunican con las capas adyacentes.

2.2 Arquitectura de 3 Capas (La más Común)

┌─────────────────────────────────┐
│     CAPA DE PRESENTACIÓN        │  ← Frontend / UI
│  (HTML, CSS, JS, React, Angular)│
└────────────────┬────────────────┘
                 │ HTTP/REST
┌────────────────▼────────────────┐
│     CAPA DE LÓGICA DE NEGOCIO   │  ← Backend / Application Server
│  (Java, .NET, Python, Node.js)  │
└────────────────┬────────────────┘
                 │ SQL/ORM
┌────────────────▼────────────────┐
│     CAPA DE DATOS               │  ← Base de Datos
│  (MySQL, PostgreSQL, Oracle)    │
└─────────────────────────────────┘

Capa de Presentación (Tier 1)

• Responsable de la interacción con el usuario.
• Muestra datos y recoge entradas.
• No contiene lógica de negocio.
• Tecnologías: HTML/CSS/JS, React, Angular, Vue.js.

Capa de Lógica de Negocio (Tier 2)

• Contiene las reglas del negocio.
• Procesa datos entre la capa de presentación y la de datos.
• Tecnologías: Java EE, .NET, Spring Boot, Django, Node.js.

Capa de Datos (Tier 3)

• Almacena y gestiona los datos.
• Acceso mediante consultas SQL o APIs.
• Tecnologías: MySQL, PostgreSQL, MongoDB, Oracle.

2.3 Arquitectura de 4 Capas

[PRESENTACIÓN] → [APLICACIÓN] → [LÓGICA DE NEGOCIO] → [DATOS]

2.4 Arquitectura en Capas vs. Arquitectura Hexagonal

Arquitectura en Capas (Layered)

• Dependencias van en una sola dirección (de arriba a abajo).
• Cada capa solo conoce a la inmediatamente inferior.

Arquitectura Hexagonal (Ports and Adapters - Alistair Cockburn)

• El dominio (núcleo) está en el centro.
• Los adaptadores conectan el dominio con el exterior.
• Muy utilizada con DDD (Domain-Driven Design).

        [UI Adapter]
             |
[DB Adapter]─[DOMINIO]─[REST Adapter]
             |
        [Email Adapter]

2.5 Arquitectura Orientada a Microservicios

Evolución natural de las arquitecturas multicapas:

[API Gateway]
     |
  ┌──┴──────────────────────┐
  │                         │
[Servicio Usuario]  [Servicio Pedidos]  [Servicio Catálogo]
       |                   |                    |
    [BD Users]         [BD Orders]          [BD Products]

Principios:
- Cada servicio es independiente y desplegable por separado.
- Cada uno tiene su propia base de datos.
- Comunicación vía API REST o mensajería asíncrona.
- Escalado independiente por servicio.

Ventajas:
- Alta escalabilidad y disponibilidad.
- Despliegue independiente.
- Tecnología heterogénea por servicio.

Inconvenientes:
- Mayor complejidad operacional.
- Gestión de transacciones distribuidas (SAGA pattern).
- Latencia de red entre servicios.

2.6 Patrones de Diseño en Arquitecturas Multicapas

3. ARQUITECTURAS DE SERVICIOS WEB Y PROTOCOLOS

3.1 Servicios Web: Concepto

Un servicio web es un sistema software diseñado para soportar la interoperabilidad entre máquinas a través de una red. Permite la comunicación entre aplicaciones heterogéneas.

Tipos principales:
1. SOAP (Simple Object Access Protocol) — basado en XML.
2. REST (Representational State Transfer) — basado en HTTP.
3. GraphQL — lenguaje de consulta para APIs.
4. gRPC — framework de RPC de alto rendimiento de Google.
5. WebSockets — comunicación bidireccional en tiempo real.

3.2 SOAP (Simple Object Access Protocol)

Definición: Protocolo de intercambio de mensajes basado en XML para comunicación entre aplicaciones a través de HTTP, SMTP, etc.

Estructura de un mensaje SOAP:

<?xml version="1.0"?>
<soap:Envelope
  xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
  <soap:Header>
    <!-- Cabeceras opcionales: autenticación, seguridad -->
  </soap:Header>
  <soap:Body>
    <GetUserRequest>
      <UserId>123</UserId>
    </GetUserRequest>
  </soap:Body>
</soap:Envelope>

Componentes SOAP:
- WSDL (Web Services Description Language): describe el servicio.
- UDDI (Universal Description, Discovery and Integration): registro de servicios.
- XSD (XML Schema Definition): define tipos de datos.

Características:
- Independiente del protocolo de transporte.
- Soporte para seguridad (WS-Security).
- Soporte para transacciones (WS-AtomicTransaction).
- Verboso (mucho XML).
- Más utilizado en entornos empresariales legacy.

3.3 REST (Representational State Transfer)

Definición: Estilo arquitectónico para sistemas distribuidos propuesto por Roy Fielding en su tesis doctoral (2000). No es un protocolo, sino un conjunto de restricciones.

Principios REST (Constraints de Fielding)

1. Arquitectura Cliente/Servidor — separación de responsabilidades.
2. Sin estado (Stateless) — cada petición contiene toda la información necesaria.
3. Caché — las respuestas deben indicar si son cacheables.
4. Interfaz Uniforme — interfaz homogénea entre componentes.
5. Sistema en Capas — el cliente no sabe si está conectado directamente al servidor.
6. Código bajo demanda (opcional) — el servidor puede enviar código ejecutable.

Recursos y URIs REST

Un recurso es cualquier información que puede ser nombrada. Se identifica con una URI.

# Colección
GET /api/usuarios

# Recurso individual
GET /api/usuarios/123

# Sub-recursos
GET /api/usuarios/123/pedidos

# Filtrado
GET /api/usuarios?rol=admin&activo=true

Buenas prácticas URI:
- Usar sustantivos, nunca verbos (/usuarios, NO /getUsuarios).
- Plural para colecciones.
- Minúsculas y guiones.
- Versionar la API: /api/v1/usuarios.

Métodos HTTP en REST

Idempotente: el resultado es el mismo aunque se repita la operación.
Seguro: no modifica el estado del servidor.

Códigos de Estado HTTP

Niveles de Madurez REST (Modelo Richardson)

• Nivel 0: HTTP como transporte (RPC sobre HTTP).
• Nivel 1: Recursos (URIs por recurso).
• Nivel 2: Verbos HTTP (GET, POST, PUT, DELETE correctamente).
• Nivel 3: HATEOAS (Hypermedia As The Engine Of Application State).

HATEOAS

Las respuestas incluyen enlaces para navegar por la API:

{
  "id": 123,
  "nombre": "Juan García",
  "_links": {
    "self": { "href": "/api/usuarios/123" },
    "pedidos": { "href": "/api/usuarios/123/pedidos" },
    "eliminar": { "href": "/api/usuarios/123", "method": "DELETE" }
  }
}

Ejemplo completo de API REST

# Crear usuario
POST /api/v1/usuarios
Content-Type: application/json

{
  "nombre": "Ana López",
  "email": "ana@ejemplo.com"
}

# Respuesta
HTTP/1.1 201 Created
Location: /api/v1/usuarios/456
Content-Type: application/json

{
  "id": 456,
  "nombre": "Ana López",
  "email": "ana@ejemplo.com"
}

# Obtener usuario
GET /api/v1/usuarios/456
Accept: application/json

# Actualizar parcialmente
PATCH /api/v1/usuarios/456
Content-Type: application/json

{ "email": "ana.lopez@ejemplo.com" }

# Eliminar
DELETE /api/v1/usuarios/456
# Respuesta: 204 No Content

3.4 GraphQL

Definición: Lenguaje de consulta para APIs, desarrollado por Facebook (2015). El cliente especifica exactamente qué datos necesita.

Problema que resuelve:
- Over-fetching: REST devuelve más datos de los necesarios.
- Under-fetching: REST requiere múltiples peticiones para obtener datos relacionados.

Ejemplo:

# Consulta (Query)
query {
  usuario(id: "123") {
    nombre
    email
    pedidos {
      id
      total
    }
  }
}

# Mutación (escritura)
mutation {
  crearUsuario(nombre: "Pedro", email: "pedro@ej.com") {
    id
    nombre
  }
}

# Suscripción (tiempo real)
subscription {
  nuevoPedido {
    id
    total
  }
}

Ventajas: Flexibilidad, una sola petición, tipado fuerte, introspección.
Inconvenientes: Mayor complejidad del servidor, caché más difícil.

3.5 gRPC

Definición: Framework de RPC (Remote Procedure Call) de Google, basado en HTTP/2 y Protocol Buffers (protobuf).

Características:
- Alto rendimiento (binario, no JSON).
- Tipado fuerte mediante archivos .proto.
- Streaming bidireccional.
- Ideal para microservicios internos.

// Definición del servicio
service UsuarioService {
  rpc GetUsuario (UsuarioRequest) returns (Usuario);
  rpc ListarUsuarios (ListarRequest) returns (stream Usuario);
}

message UsuarioRequest {
  int32 id = 1;
}

message Usuario {
  int32 id = 1;
  string nombre = 2;
  string email = 3;
}

3.6 WebSockets

Definición: Protocolo que proporciona un canal de comunicación bidireccional y full-duplex sobre una única conexión TCP.

Funcionamiento:
1. El cliente inicia con HTTP (handshake WebSocket).
2. El servidor acepta la actualización del protocolo.
3. Se establece una conexión persistente.
4. Ambos pueden enviar mensajes en cualquier momento.

// Cliente JavaScript
const ws = new WebSocket('wss://servidor.com/chat');

ws.onopen = () => ws.send(JSON.stringify({ tipo: 'saludo', texto: 'Hola' }));
ws.onmessage = (event) => console.log(JSON.parse(event.data));
ws.onclose = () => console.log('Conexión cerrada');

Casos de uso: Chat en tiempo real, juegos online, dashboards en vivo, notificaciones push.

3.7 Comparativa de Arquitecturas de Servicios Web

3.8 Protocolos de Red Asociados

HTTP/HTTPS

HTTP (HyperText Transfer Protocol) — Protocolo de la capa de aplicación (OSI capa 7).

• HTTP/1.0: Una conexión TCP por petición.
• HTTP/1.1: Conexiones persistentes (keep-alive), pipelining.
• HTTP/2: Multiplexación, compresión de cabeceras (HPACK), server push, binario.
• HTTP/3: Basado en QUIC (UDP), menor latencia, mejor en redes con pérdidas.

HTTPS: HTTP sobre TLS/SSL. Proporciona:
- Confidencialidad (cifrado de datos).
- Integridad (los datos no se modifican en tránsito).
- Autenticación (verifica la identidad del servidor).

TCP/IP

• TCP (Transmission Control Protocol): orientado a conexión, fiable, control de flujo.
• UDP (User Datagram Protocol): sin conexión, más rápido, sin garantías.

DNS (Domain Name System)

• Traduce nombres de dominio a direcciones IP.
• Jerárquico y distribuido.

TLS/SSL

• TLS (Transport Layer Security) — cifrado de comunicaciones.
• Handshake: intercambio de certificados y claves.
• Versiones: TLS 1.2, TLS 1.3 (más segura y rápida).

3.9 OpenAPI / Swagger

Especificación estándar para documentar APIs REST.

openapi: 3.0.0
info:
  title: API de Usuarios
  version: 1.0.0
paths:
  /usuarios/{id}:
    get:
      summary: Obtener usuario por ID
      parameters:
        - name: id
          in: path
          required: true
          schema:
            type: integer
      responses:
        '200':
          description: Usuario encontrado
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/Usuario'
        '404':
          description: No encontrado
components:
  schemas:
    Usuario:
      type: object
      properties:
        id:
          type: integer
        nombre:
          type: string
        email:
          type: string

3.10 Seguridad en APIs Web

Autenticación y Autorización

API Key:

GET /api/usuarios
X-API-Key: mi-clave-secreta

Basic Auth:

GET /api/usuarios
Authorization: Basic dXN1YXJpbzpjb250cmFzZcOxYQ==

JWT (JSON Web Token):

Header.Payload.Signature
eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMjMifQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV

OAuth 2.0: Framework de autorización delegada.
- Flujos: Authorization Code, Client Credentials, Implicit, PKCE.
- Se complementa con OpenID Connect para autenticación.

Prácticas de seguridad:
- HTTPS obligatorio.
- Rate limiting y throttling.
- Validación de entrada.
- CORS (Cross-Origin Resource Sharing).
- OWASP API Security Top 10.

4. CONTROL DE VERSIONES: GIT

4.1 Concepto de Control de Versiones

Un sistema de control de versiones (VCS, Version Control System) registra los cambios realizados sobre un conjunto de ficheros a lo largo del tiempo, permitiendo recuperar versiones específicas.

Tipos de VCS:
- Local: solo en el equipo local (ej. RCS).
- Centralizado: un único servidor central (ej. SVN, CVS).
- Distribuido: cada cliente tiene una copia completa del repositorio (ej. Git, Mercurial).

4.2 Git: Introducción

Git es un sistema de control de versiones distribuido, creado por Linus Torvalds en 2005 para el desarrollo del kernel de Linux. Es el VCS más utilizado del mundo.

Características:
- Distribuido: cada clon es un repositorio completo.
- Rápido y eficiente (almacena snapshots, no diferencias).
- Integridad garantizada (SHA-1/SHA-256).
- Ramificación y fusión eficiente.
- Software libre (GPLv2).

4.3 Modelo de Datos de Git

Git almacena datos como instantáneas (snapshots) del sistema de archivos, no como diferencias (a diferencia de SVN).

Objetos de Git:
- Blob: contenido de un archivo.
- Tree: directorio (contiene blobs y otros trees).
- Commit: instantánea con metadatos (autor, fecha, mensaje, referencia al tree padre).
- Tag: etiqueta anotada.

Todos los objetos se identifican por su hash SHA-1 (40 caracteres hexadecimales).

4.4 Áreas de Trabajo en Git

[Directorio de trabajo] → git add → [Índice/Staging Area] → git commit → [Repositorio local] → git push → [Repositorio remoto]

• Working Directory: archivos en disco, modificados o no.
• Staging Area (Índice): archivos preparados para el próximo commit.
• Repositorio local: historial completo de commits.
• Repositorio remoto: copia en servidor (GitHub, GitLab, Bitbucket).

4.5 Estados de un Archivo en Git

Untracked → Staged → Committed
              ↑         ↓
           Modified ←──┘

• Untracked: Git no lo sigue.
• Tracked/Unmodified: en el repositorio, sin cambios.
• Modified: modificado pero no en staging.
• Staged: en el área de preparación.

4.6 Comandos Git Fundamentales

Configuración inicial

git config --global user.name "Nombre Apellido"
git config --global user.email "email@ejemplo.com"
git config --global core.editor "vim"
git config --list  # Ver configuración

Inicializar y Clonar

git init                          # Inicializar repositorio
git clone https://repo.git        # Clonar repositorio
git clone https://repo.git nombre # Clonar con nombre personalizado

Estado e Información

git status                # Estado del directorio de trabajo
git log                   # Historial de commits
git log --oneline         # Historial resumido
git log --oneline --graph --all  # Árbol de ramas visual
git diff                  # Diferencias no añadidas al staging
git diff --staged         # Diferencias en staging
git show abc1234          # Ver detalles de un commit

Operaciones Básicas

git add archivo.txt       # Añadir archivo al staging
git add .                 # Añadir todos los cambios
git add -p                # Añadir cambios interactivamente (por hunks)
git commit -m "mensaje"   # Hacer commit
git commit -am "mensaje"  # add + commit (solo archivos tracked)
git commit --amend        # Modificar el último commit

Deshacer Cambios

git restore archivo.txt        # Descartar cambios en working dir (nuevo)
git restore --staged archivo   # Quitar del staging
git revert abc1234             # Crear commit que deshace otro
git reset --soft HEAD~1        # Deshacer último commit (mantiene staging)
git reset --mixed HEAD~1       # Deshacer último commit (mantiene working dir)
git reset --hard HEAD~1        # Deshacer último commit (PELIGROSO, borra cambios)
git clean -fd                  # Eliminar archivos no rastreados

Ramas (Branches)

git branch                     # Listar ramas locales
git branch -a                  # Listar todas las ramas
git branch nueva-rama           # Crear rama
git checkout -b nueva-rama      # Crear y cambiar a rama
git switch -c nueva-rama        # Crear y cambiar a rama (moderno)
git switch rama                 # Cambiar de rama (moderno)
git branch -d rama              # Eliminar rama (segura)
git branch -D rama              # Eliminar rama (forzado)

Fusión (Merge y Rebase)

# Merge: crea un commit de merge
git checkout main
git merge feature/login

# Merge fast-forward (sin commit de merge)
git merge --ff-only feature/login

# Merge sin fast-forward (fuerza commit de merge)
git merge --no-ff feature/login

# Rebase: reaplica commits sobre otra base
git checkout feature/login
git rebase main

# Rebase interactivo (para limpiar historial)
git rebase -i HEAD~3

Diferencia Merge vs Rebase:
- merge: preserva el historial completo, crea commit de fusión.
- rebase: historial lineal, NO usar en ramas compartidas.

Repositorios Remotos

git remote -v                          # Ver remotos
git remote add origin https://repo.git # Añadir remoto
git fetch origin                       # Descargar cambios sin fusionar
git pull origin main                   # Fetch + merge
git pull --rebase origin main          # Fetch + rebase
git push origin main                   # Subir cambios
git push -u origin feature/login       # Subir rama y establecer upstream
git push origin --delete rama          # Eliminar rama remota

Etiquetas (Tags)

git tag                          # Listar tags
git tag v1.0.0                   # Tag ligero
git tag -a v1.0.0 -m "Release"  # Tag anotado
git push origin v1.0.0           # Subir tag
git push origin --tags           # Subir todos los tags

Stash (Almacén temporal)

git stash                        # Guardar cambios temporalmente
git stash push -m "descripción" # Guardar con descripción
git stash list                   # Listar stashes
git stash pop                    # Recuperar último stash
git stash apply stash@{2}        # Aplicar stash específico
git stash drop stash@{0}         # Eliminar stash

Operaciones Avanzadas

git cherry-pick abc1234          # Aplicar un commit específico en la rama actual
git bisect start                 # Búsqueda binaria de bugs
git bisect bad                   # Marcar commit actual como malo
git bisect good v1.0             # Marcar versión buena
git blame archivo.txt            # Ver quién modificó cada línea
git reflog                       # Log de referencias (recuperación)
git submodule add https://...    # Añadir submódulo

4.7 Resolución de Conflictos

Un conflicto ocurre cuando dos ramas modifican la misma línea de un archivo.

<<<<<<< HEAD
línea en la rama actual
=======
línea en la rama que se fusiona
>>>>>>> feature/login

Resolución:
1. Editar el archivo y elegir/combinar los cambios.
2. Eliminar los marcadores <<<<<<<, =======, >>>>>>>.
3. git add archivo_resuelto.txt
4. git commit

4.8 Flujos de Trabajo con Git (Workflows)

Git Flow (Vincent Driessen, 2010)

Ramas principales:
- main (o master): código en producción.
- develop: integración de características.

Ramas de soporte:
- feature/xxx: nuevas funcionalidades (sale de develop).
- release/x.x.x: preparación de releases (sale de develop, va a main y develop).
- hotfix/xxx: correcciones urgentes en producción (sale de main, va a main y develop).

main:     ●───────────────────●───●
          │                   │   │
develop:  ●──●──────────────●─┤   │
              │              │     │
feature:      ●──●──●────●──┘     │
                                  │
hotfix:                     ●──●──┘

GitHub Flow

Más sencillo, para despliegue continuo:
1. Crear rama desde main.
2. Añadir commits.
3. Abrir Pull Request.
4. Revisar y discutir.
5. Merge a main.
6. Desplegar inmediatamente.

GitLab Flow

Combina características de Git Flow y GitHub Flow. Añade ramas de entorno:
- main → pre-production → production.

Trunk Based Development

• Solo existe una rama principal (trunk/main).
• Los desarrolladores hacen commits directamente o usan feature branches muy cortas (menos de un día).
• Requiere feature flags para código en desarrollo.
• Muy adecuado para CI/CD.

4.9 .gitignore

Archivo que especifica qué archivos/directorios deben ser ignorados por Git.

# Archivos de compilación
*.class
*.pyc
build/
dist/
target/

# Dependencias
node_modules/
vendor/

# Variables de entorno y secretos
.env
*.key
*.pem

# IDEs
.idea/
.vscode/
*.swp

# Sistema operativo
.DS_Store
Thumbs.db

# Logs
*.log
logs/

4.10 Buenas Prácticas con Git

Mensajes de commit (Conventional Commits):

<tipo>[ámbito opcional]: <descripción>

[cuerpo opcional]

[notas al pie opcionales]

Tipos:
- feat: nueva funcionalidad.
- fix: corrección de bug.
- docs: documentación.
- style: formato, sin cambios lógicos.
- refactor: refactorización.
- test: añadir/corregir tests.
- chore: tareas de mantenimiento.
- perf: mejora de rendimiento.
- ci: cambios en CI/CD.

Ejemplos:

feat(auth): añadir autenticación con JWT
fix(usuarios): corregir validación de email duplicado
docs: actualizar README con instrucciones de instalación

Otras buenas prácticas:
- Commits pequeños y atómicos (un cambio por commit).
- Siempre escribir mensajes descriptivos.
- No hacer commit de archivos generados o secretos.
- Usar Pull Requests para revisión de código.
- Proteger la rama main (branch protection rules).
- Usar tags para versiones de release.

4.11 Git vs SVN: Comparativa

5. METODOLOGÍAS DE DESARROLLO

5.1 Concepto y Clasificación

Una metodología de desarrollo de software es un marco de trabajo que define el proceso, las prácticas, las herramientas y las técnicas a seguir para desarrollar software de manera sistemática.

Clasificación principal:
- Predictivas (clásicas o en cascada): el plan se define al inicio.
- Ágiles (iterativas e incrementales): flexibles, orientadas al cambio.

5.2 Modelo en Cascada (Waterfall)

Propuesto por Winston Royce (1970). Proceso secuencial y lineal.

[Requisitos] → [Diseño] → [Implementación] → [Verificación] → [Mantenimiento]

Fases:
1. Análisis de requisitos: qué debe hacer el sistema.
2. Diseño del sistema: arquitectura, módulos, interfaces.
3. Implementación: codificación.
4. Pruebas (verificación): detección de errores.
5. Despliegue: puesta en producción.
6. Mantenimiento: correcciones y mejoras.

Ventajas:
- Simple y fácil de gestionar.
- Documentación exhaustiva.
- Adecuado para proyectos con requisitos estables.

Inconvenientes:
- No apto para requisitos cambiantes.
- El cliente no ve resultados hasta el final.
- Los errores detectados tardíamente son muy costosos.

5.3 Modelo en V

Extensión del modelo en cascada que enfatiza la verificación y validación.

Análisis ────────────────── Aceptación
  Diseño sistema ──────── Integración
    Diseño detallado ── Pruebas unitarias
          Implementación

• Cada fase de desarrollo tiene una fase de prueba correspondiente.
• Verificación (hacemos el producto correctamente) vs Validación (hacemos el producto correcto).

5.4 Modelo Espiral (Barry Boehm, 1986)

Modelo iterativo que combina elementos del cascada con prototipos. Se centra en la gestión del riesgo.

Cuatro cuadrantes por iteración:
1. Determinación de objetivos: objetivos, alternativas, restricciones.
2. Evaluación de alternativas: análisis y reducción de riesgos.
3. Desarrollo y prueba: prototipo, implementación.
4. Planificación: revisión y plan siguiente iteración.

5.5 RUP (Rational Unified Process)

Proceso de desarrollo iterativo e incremental, basado en UML. Desarrollado por IBM Rational.

Fases:
1. Inicio (Inception): alcance, viabilidad, casos de negocio.
2. Elaboración: arquitectura base, reducción de riesgos.
3. Construcción: desarrollo iterativo del producto.
4. Transición: entrega al usuario final, formación.

Disciplinas:
- Modelado del negocio.
- Requisitos.
- Análisis y diseño.
- Implementación.
- Pruebas.
- Despliegue.
- Gestión del proyecto.
- Gestión de la configuración.
- Entorno.

5.6 Metodologías Ágiles

El Manifiesto Ágil (2001) establece 4 valores:
1. Individuos e interacciones sobre procesos y herramientas.
2. Software funcionando sobre documentación exhaustiva.
3. Colaboración con el cliente sobre negociación de contratos.
4. Respuesta ante el cambio sobre seguir un plan.

12 Principios Ágiles (resumidos):
- Satisfacción del cliente mediante entrega continua.
- Bienvenida a cambios, incluso tardíos.
- Entregas frecuentes de software funcional.
- Colaboración diaria entre negocio y desarrolladores.
- Proyectos con personas motivadas y entorno de apoyo.
- Conversación cara a cara como método más eficiente.
- Software funcionando como medida principal de progreso.
- Ritmo de desarrollo sostenible.
- Atención continua a la excelencia técnica.
- Simplicidad (maximizar trabajo no realizado).
- Equipos autoorganizados generan mejores resultados.
- Reflexión periódica y ajuste del comportamiento.

5.7 Scrum

Framework ágil más popular. Desarrollado por Ken Schwaber y Jeff Sutherland (1995).

Roles en Scrum

Artefactos de Scrum

• Product Backlog: lista ordenada de todo lo que podría necesitar el producto (User Stories, épicas, bugs).
• Sprint Backlog: elementos del Product Backlog seleccionados para el Sprint + plan para conseguirlos.
• Incremento: versión funcional y potencialmente entregable del producto al final de cada Sprint.
• Definition of Done (DoD): lista de criterios que debe cumplir el incremento.

Eventos de Scrum (Ceremonias)

Daily Scrum (3 preguntas):
- ¿Qué hice ayer que ayudó al objetivo del Sprint?
- ¿Qué haré hoy para ayudar al objetivo del Sprint?
- ¿Hay algún impedimento que me bloquea?

User Stories

Formato estándar:

Como [tipo de usuario],
quiero [funcionalidad],
para [beneficio/valor].

Criterios de aceptación (INVEST):
- Independiente
- Negociable
- Valiosa
- Estimable
- Small (pequeña)
- Testeable

Estimación con Story Points (Fibonacci: 1, 2, 3, 5, 8, 13, 21, ∞).
Planning Poker: técnica de estimación colaborativa.

Métricas Scrum

• Velocidad: story points completados por Sprint.
• Burndown Chart: trabajo restante en el Sprint.
• Burnup Chart: trabajo completado acumulado.
• Cumulative Flow Diagram (CFD): flujo de trabajo acumulado.

5.8 Kanban

Framework ágil orientado al flujo de trabajo continuo. Origen en Toyota (sistema de producción JIT).

Principios:
1. Empezar con lo que hay ahora.
2. Aceptar el cambio evolutivo e incremental.
3. Respetar los roles, responsabilidades y títulos actuales.

Prácticas:
1. Visualizar el flujo de trabajo (tablero Kanban).
2. Limitar el WIP (Work In Progress).
3. Gestionar el flujo.
4. Hacer las políticas explícitas.
5. Implementar bucles de retroalimentación.
6. Mejorar de forma colaborativa.

Tablero Kanban:

| Por hacer | En progreso | Revisión | Hecho |
|-----------|-------------|----------|-------|
| Tarea A   | Tarea B     | Tarea C  | Tarea D |
| Tarea E   |             |          |       |

Métricas Kanban:
- Lead Time: tiempo desde que se solicita hasta que se entrega.
- Cycle Time: tiempo desde que se empieza hasta que se termina.
- Throughput: elementos completados por unidad de tiempo.

5.9 Extreme Programming (XP)

Metodología ágil de alta ingeniería, propuesta por Kent Beck (1999).

Valores XP: Simplicidad, Comunicación, Retroalimentación, Valentía, Respeto.

Prácticas XP principales:

5.10 SAFe (Scaled Agile Framework)

Framework para escalar ágil en organizaciones grandes. Niveles:
- Team: Scrum/Kanban.
- Program: Agile Release Train (ART).
- Large Solution: coordinación de múltiples ARTs.
- Portfolio: gestión estratégica.

5.11 Comparativa de Metodologías

6. PRUEBAS DE SOFTWARE

6.1 Concepto y Objetivos

Las pruebas de software (testing) son el proceso de evaluación de un sistema para verificar que satisface los requisitos especificados e identificar defectos.

Objetivos:
- Detectar defectos (bugs).
- Verificar que el software cumple los requisitos.
- Aumentar la confianza en la calidad.
- Prevenir defectos (en etapas tempranas).

Principios del testing (ISTQB):
1. El testing muestra la presencia de defectos, no su ausencia.
2. El testing exhaustivo es imposible.
3. El testing temprano ahorra tiempo y dinero.
4. Los defectos se agrupan (regla 80/20 — Principio de Pareto).
5. La paradoja del pesticida (los tests se vuelven menos efectivos con el tiempo).
6. El testing depende del contexto.
7. La falacia de la ausencia de errores.

6.2 Pirámide de Pruebas (Mike Cohn)

           /\
          /UI\          ← Pruebas de extremo a extremo (E2E)
         /────\
        /Integr\        ← Pruebas de integración
       /─────────\
      / Unitarias  \    ← Pruebas unitarias (base, más abundantes)
     /───────────────\

• Más pruebas unitarias (rápidas, baratas).
• Menos pruebas de integración.
• Muy pocas pruebas E2E (lentas, costosas).

6.3 Clasificación de Pruebas por Nivel

Pruebas Unitarias (Unit Testing)

• Prueban unidades individuales de código (función, clase, método).
• Aisladas: no dependen de BD, red o servicios externos (se usan mocks/stubs).
• Rápidas de ejecutar.

// Ejemplo en Java con JUnit 5
@Test
void testSumar() {
    Calculadora calc = new Calculadora();
    assertEquals(5, calc.sumar(2, 3));
    assertEquals(-1, calc.sumar(2, -3));
}

# Ejemplo en Python con pytest
def test_suma():
    assert suma(2, 3) == 5
    assert suma(-1, 1) == 0

Pruebas de Integración

• Verifican la interacción entre componentes o módulos.
• Estrategias de integración:
• Big Bang: integrar todo de una vez.
• Top-Down: de los módulos superiores a los inferiores (stubs para simular módulos inferiores).
• Bottom-Up: de módulos inferiores a superiores (drivers para módulos superiores).
• Incremental: integración gradual.

Pruebas de Sistema

• Prueban el sistema completo.
• Verifican requisitos funcionales y no funcionales.

Pruebas de Aceptación (UAT - User Acceptance Testing)

• El cliente/usuario final valida que el sistema cumple sus necesidades.
• Alpha testing: pruebas internas antes de la release.
• Beta testing: pruebas con usuarios reales en entorno real.

6.4 Clasificación por Técnica

Pruebas de Caja Negra (Black-Box)

• No se conoce el código interno.
• Se prueba la funcionalidad: entrada → salida esperada.
• Técnicas:
• Partición de equivalencia: dividir entradas en clases equivalentes.
• Análisis de valores límite: probar los límites de las clases.
• Tablas de decisión: combinaciones de condiciones.
• Pruebas de transición de estados: máquinas de estado.

Ejemplo partición equivalencia:
Campo edad (1-120):
- Clase válida: 1-120
- Clase inválida: <1, >120, no numérico

Pruebas de Caja Blanca (White-Box / Glass-Box)

• Se conoce el código interno.
• Se prueba la lógica interna.
• Técnicas:
• Cobertura de sentencias: cada sentencia ejecutada al menos una vez.
• Cobertura de ramas: cada rama (if/else) ejecutada.
• Cobertura de condiciones: cada condición evaluada a true y false.
• Cobertura de caminos: todos los caminos posibles (no siempre factible).

Pruebas de Caja Gris (Grey-Box)

• Combinación de ambas técnicas.

6.5 Tipos de Pruebas Especializadas

Pruebas Funcionales

• Verifican que el software hace lo que se supone que debe hacer.
• Basadas en requisitos funcionales.

Pruebas No Funcionales

Pruebas de Regresión

• Verifican que los cambios no han roto funcionalidad existente.
• Se automatizan para ejecutarlas tras cada cambio.

Pruebas de Humo (Smoke Testing)

• Conjunto mínimo de pruebas para verificar que el build básico funciona.
• Se ejecutan antes de pruebas más exhaustivas.

Pruebas de Sanidad (Sanity Testing)

• Verifican que una funcionalidad específica funciona correctamente tras un cambio.
• Subset de pruebas de regresión.

Pruebas Exploratorias

• Sin guión previo, el tester explora la aplicación libremente.
• Efectivas para encontrar bugs inesperados.
• Basadas en la experiencia del tester.

Pruebas de Mutación (Mutation Testing)

• Se introducen pequeñas modificaciones (mutantes) en el código.
• Si los tests detectan el cambio (el mutante muere), el test es efectivo.
• Herramientas: PIT (Java), Mutmut (Python), Stryker (JS).

6.6 TDD (Test-Driven Development)

Desarrollo guiado por tests. El ciclo TDD es:

Red → Green → Refactor

1. Red: Escribir un test que falla (el código aún no existe).
2. Green: Escribir el mínimo código necesario para que el test pase.
3. Refactor: Mejorar el código manteniendo los tests en verde.

Ventajas:
- Diseño orientado a la testabilidad.
- Cobertura de tests alta desde el inicio.
- Documentación viva del comportamiento.
- Detecta errores de diseño temprano.

BDD (Behaviour-Driven Development): extensión de TDD que utiliza lenguaje natural (Gherkin) para escribir tests comprensibles por negocio.

# Gherkin (BDD)
Feature: Inicio de sesión
  Scenario: Usuario válido
    Given que estoy en la página de login
    When introduzco usuario "admin" y contraseña "1234"
    Then debería redirigirme al dashboard
    And debería ver el mensaje "Bienvenido, admin"

Herramientas BDD: Cucumber, SpecFlow, Behave (Python).

6.7 Herramientas de Testing

Cobertura de código:
- Java: JaCoCo.
- Python: coverage.py.
- JavaScript: Istanbul (nyc).
- .NET: Coverlet.

6.8 Gestión de Defectos

Ciclo de vida de un defecto:

Nuevo → Asignado → En progreso → Resuelto → Verificado → Cerrado
                                         ↓
                                      Reabierto

Severidad vs Prioridad:
- Severidad: impacto técnico del defecto (Crítico, Mayor, Menor, Trivial).
- Prioridad: urgencia de resolución (Alta, Media, Baja).

Un defecto puede ser de alta severidad y baja prioridad (o viceversa).

Información en un informe de defecto:
- ID único.
- Título descriptivo.
- Descripción detallada.
- Pasos para reproducir.
- Resultado esperado vs. resultado obtenido.
- Severidad y prioridad.
- Versión del software.
- Entorno (SO, navegador, etc.).
- Capturas de pantalla/logs.

7. CONSTRUCCIÓN DE SOFTWARE (BUILD)

7.1 Concepto de Build

El proceso de construcción (build) es el proceso automatizado de transformar el código fuente en un artefacto ejecutable o desplegable. Incluye compilación, enlazado, empaquetado y otras tareas.

7.2 Integración Continua (CI - Continuous Integration)

Definición: Práctica de desarrollo donde los miembros del equipo integran su trabajo frecuentemente (al menos una vez al día), y cada integración se verifica mediante builds y tests automatizados.

Objetivos:
- Detectar problemas de integración tempranamente.
- Reducir el riesgo de integración ("integration hell").
- Mantener el software siempre en estado funcional.

Flujo CI típico:

Commit → Push → Build → Test → Análisis de código → Notificación

Prácticas CI:
- Repositorio de código único.
- Build automatizado.
- Tests automatizados.
- Builds rápidos (< 10 minutos idealmente).
- Arreglar builds rotos inmediatamente.
- Visibilidad del estado del build para todo el equipo.

7.3 Entrega Continua (CD - Continuous Delivery)

Definición: El software está siempre en un estado que puede ser desplegado a producción en cualquier momento. El despliegue a producción es una decisión humana.

CI → Build → Test → Deploy a Staging → Aprobación manual → Deploy a Producción

7.4 Despliegue Continuo (CD - Continuous Deployment)

Definición: Cada cambio que supera todos los tests se despliega automáticamente a producción, sin intervención humana.

CI → Build → Test → Deploy a Staging → Test → Deploy a Producción (automático)

               Continuous Integration
               ←──────────────────→
Commit → Build → Test → Staging → [Aprobación] → Producción
         ←──────────────────────────────────────→
                  Continuous Delivery
         ←──────────────────────────────────────────────→
                  Continuous Deployment (sin aprobación)

7.5 Herramientas de CI/CD

7.6 Pipelines de CI/CD

Ejemplo de pipeline con GitHub Actions:

# .github/workflows/ci.yml
name: CI/CD Pipeline

on:
  push:
    branches: [ main, develop ]
  pull_request:
    branches: [ main ]

jobs:
  build-and-test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3

      - name: Configurar Java 17
        uses: actions/setup-java@v3
        with:
          java-version: '17'
          distribution: 'temurin'

      - name: Compilar
        run: mvn compile

      - name: Ejecutar tests
        run: mvn test

      - name: Análisis SonarCloud
        run: mvn sonar:sonar

      - name: Construir artefacto
        run: mvn package -DskipTests

      - name: Publicar cobertura
        uses: codecov/codecov-action@v3

  deploy-staging:
    needs: build-and-test
    if: github.ref == 'refs/heads/develop'
    runs-on: ubuntu-latest
    steps:
      - name: Desplegar en Staging
        run: |
          echo "Desplegando en entorno de staging..."
          # Comandos de despliegue aquí

  deploy-production:
    needs: build-and-test
    if: github.ref == 'refs/heads/main'
    runs-on: ubuntu-latest
    environment: production  # Requiere aprobación manual
    steps:
      - name: Desplegar en Producción
        run: |
          echo "Desplegando en producción..."

7.7 Gestores de Dependencias y Build Tools

Java

• Maven: basado en XML (pom.xml), convención sobre configuración.
• Gradle: basado en Groovy/Kotlin DSL, más flexible y rápido.

<!-- Maven pom.xml (fragmento) -->
<dependencies>
  <dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-web</artifactId>
    <version>3.1.0</version>
  </dependency>
</dependencies>

// Gradle build.gradle (fragmento)
dependencies {
    implementation 'org.springframework.boot:spring-boot-starter-web:3.1.0'
    testImplementation 'org.junit.jupiter:junit-jupiter:5.9.0'
}

JavaScript/Node.js

• npm: Node Package Manager, gestor de paquetes por defecto.
• Yarn: alternativa a npm, más rápido.
• pnpm: eficiente en almacenamiento.
• Webpack, Vite, Rollup: bundlers/build tools.

{
  "scripts": {
    "build": "webpack --mode production",
    "test": "jest",
    "lint": "eslint src/"
  },
  "dependencies": {
    "react": "^18.0.0"
  },
  "devDependencies": {
    "jest": "^29.0.0"
  }
}

Python

• pip: gestor de paquetes.
• Poetry, Pipenv: gestión de entornos virtuales y dependencias.
• setuptools, wheel: empaquetado.

.NET

• NuGet: gestor de paquetes.
• MSBuild: sistema de build.
• dotnet CLI: herramienta de línea de comandos.

7.8 Contenedores y Docker

Docker permite empaquetar aplicaciones en contenedores, garantizando que se ejecuten igual en cualquier entorno.

# Dockerfile de ejemplo para aplicación Java
FROM eclipse-temurin:17-jre-alpine

WORKDIR /app

COPY target/mi-aplicacion.jar app.jar

EXPOSE 8080

HEALTHCHECK --interval=30s --timeout=3s \
  CMD wget -qO- http://localhost:8080/health || exit 1

ENTRYPOINT ["java", "-jar", "app.jar"]

# docker-compose.yml
version: '3.8'
services:
  app:
    build: .
    ports:
      - "8080:8080"
    depends_on:
      - db
    environment:
      - SPRING_DATASOURCE_URL=jdbc:postgresql://db:5432/mydb

  db:
    image: postgres:15
    environment:
      POSTGRES_DB: mydb
      POSTGRES_USER: user
      POSTGRES_PASSWORD: password
    volumes:
      - postgres_data:/var/lib/postgresql/data

volumes:
  postgres_data:

7.9 Calidad de Código

Análisis Estático

• Análisis del código sin ejecutarlo.
• Detecta bugs potenciales, code smells, violaciones de estilo.
• Herramientas: SonarQube/SonarCloud, ESLint, Pylint, Checkstyle, PMD, SpotBugs.

Métricas de Calidad (SonarQube)

Revisión de Código (Code Review)

• Pull Request / Merge Request.
• Checklist de revisión:
• ¿El código es legible y mantenible?
• ¿Hay suficientes tests?
• ¿Se siguen los estándares del equipo?
• ¿Hay problemas de seguridad?
• ¿Se podría simplificar?

7.10 Gestión de Artefactos

Repositorios de artefactos para almacenar los productos del build:
- Nexus Repository: JARs, Maven, Docker images.
- JFrog Artifactory: universal, múltiples formatos.
- GitHub Packages: integrado con GitHub.
- Docker Hub / Registry: imágenes Docker.

7.11 Infraestructura como Código (IaC)

Definición: Gestión y aprovisionamiento de infraestructura mediante código, en lugar de procesos manuales.

Herramientas:
- Terraform: declarativo, multi-cloud.
- Ansible: automatización de configuración.
- Helm: gestión de aplicaciones en Kubernetes.
- Pulumi: IaC con lenguajes de programación convencionales.

# Terraform ejemplo
resource "aws_instance" "servidor_web" {
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = "t3.micro"

  tags = {
    Name = "ServidorWeb"
    Env  = "produccion"
  }
}

7.12 GitOps

Práctica donde los cambios en infraestructura y aplicaciones se gestionan mediante Pull Requests en Git, y herramientas como ArgoCD o Flux sincronizan el estado del repositorio con el clúster de Kubernetes.

8. RESUMEN PARA EXAMEN

Conceptos Clave a Recordar

Arquitecturas

• Cliente/Servidor 2 capas: cliente fat, servidor BD.
• 3 capas: Presentación + Lógica de Negocio + Datos.
• Microservicios: servicios independientes, DB por servicio, API entre servicios.
• MVC: separación Modelo-Vista-Controlador.

Servicios Web

• SOAP: XML, WSDL, WS-*, empresarial.
• REST: HTTP, stateless, JSON, 6 principios de Fielding, métodos HTTP, códigos de estado.
• GraphQL: Facebook 2015, query flexible, over/under-fetching.
• gRPC: Google, Protobuf, HTTP/2, alto rendimiento.
• Modelo Richardson: 4 niveles (0-3), HATEOAS en nivel 3.

Git

• Distribuido creado por Linus Torvalds (2005).
• 3 áreas: Working Directory → Staging Area → Repositorio.
• Comandos esenciales: init, clone, add, commit, push, pull, branch, merge, rebase, stash.
• Git Flow: main + develop + feature + release + hotfix.
• Conventional Commits: feat, fix, docs, style, refactor, test, chore.

Metodologías

• Cascada: lineal, documentación, requisitos estables.
• Scrum: Sprint, Product Owner, Scrum Master, Developers. Ceremonias: Planning, Daily, Review, Retro.
• Kanban: flujo continuo, WIP limits, Lead Time, Cycle Time.
• XP: TDD, Pair Programming, Refactoring, CI.
• Manifiesto Ágil (2001): 4 valores, 12 principios.

Pruebas

• Pirámide: Unitarias (base) → Integración → E2E (cima).
• Caja negra: funcionalidad, sin ver el código. Técnicas: partición equivalencia, valores límite.
• Caja blanca: lógica interna, cobertura de ramas/sentencias/caminos.
• TDD: Red → Green → Refactor.
• BDD: Gherkin, Given/When/Then.
• Tipos: funcionales, regresión, humo, carga, estrés, seguridad, usabilidad.

Build y CI/CD

• CI: integración frecuente, build + tests automáticos.
• Continuous Delivery: siempre desplegable, despliegue manual.
• Continuous Deployment: despliegue automático sin aprobación.
• Herramientas: Jenkins, GitHub Actions, GitLab CI.
• Docker: contenedores, Dockerfile, docker-compose.
• Calidad: SonarQube, cobertura, deuda técnica, complejidad ciclomática.

Tabla de Siglas y Acrónimos

Documento generado para preparación de oposiciones — Tema 2: Arquitectura de sistemas cliente/servidor y multicapas. Versión completa con contenido teórico y práctico.