Diseño de software: requisitos verificables, arquitectura y patrones
Diseño de software evalúa la capacidad de traducir necesidades en una solución verificable: especificar requisitos, modelar, elegir arquitectura y patrones, y sostener decisiones con criterios de calidad. El foco no es la sintaxis de un lenguaje, sino el diseño.
Conceptos que se preguntan
- Requisitos funcionales (qué hace el sistema) frente a no funcionales o atributos de calidad (rendimiento, seguridad, disponibilidad, mantenibilidad, usabilidad).
- Ciclo de vida: cascada (requisitos estables), iterativo e incremental, ágil (Scrum: sprints, backlog, roles, ceremonias).
- UML: casos de uso (actores y fronteras), clases (atributos, métodos y relaciones: asociación, herencia, composición), secuencia (mensajes en el tiempo).
- Arquitectura: capas, MVC, cliente-servidor, microservicios, orientada a eventos.
- Patrones: Singleton, Factory, Observer, Strategy, Repository.
- Principios: SOLID; alta cohesión y bajo acoplamiento; separación de responsabilidades.
- Pruebas: unitarias, de integración, de aceptación; TDD; la cobertura no equivale a calidad.
- Deuda técnica y refactorización; control de versiones con ramas.
Ejemplo resuelto
Requisito original: “El sistema debe ser rápido y notificar a varios módulos cuando cambie el precio de un producto”.
Razonamiento: “rápido” no es verificable; se convierte en un requisito no funcional medible: “el 95% de las consultas de precio debe responder en menos de 2 segundos con 500 usuarios concurrentes”. Para las notificaciones, si el emisor llamara directamente a cada módulo quedaría acoplado a todos. El patrón Observer permite que los módulos se suscriban y reciban el cambio sin que el emisor los conozca: baja el acoplamiento y se pueden agregar suscriptores sin modificar el código existente (principio abierto/cerrado).
Errores que cuestan puntos
- Elegir patrones por moda y no por el problema (Singleton aplicado a todo).
- Confundir herencia con composición y forzar jerarquías rígidas.
- Aceptar requisitos ambiguos sin criterios de aceptación.
- Creer que más capas o más pruebas siempre mejoran el diseño.
- Ignorar los atributos de calidad, que son los que realmente deciden la arquitectura.