Guía de Estudio Maestra: Diseño a nivel de Componentes

Esta guía integra la estructura técnica de las diapositivas con las explicaciones detalladas y ejemplos prácticos proporcionados por el profesor en la sesión.

Resumen Ejecutivo

La sesión se centra en la transición del Dominio del Problema (Análisis: ¿Qué?) al Dominio de la la Solución (Diseño: ¿Cómo?) dentro del ciclo de vida de la ingeniería de software. Se analiza el diseño de software como un proceso creativo y técnico que se asienta sobre una pirámide de modelos (datos, arquitectura, interfaces y componentes). El objetivo final es alcanzar la independencia funcional mediante la aplicación de principios de diseño como SOLID y métricas de cohesión (REP, CRP, CCP).

Conceptos Clave

Abstracción y Refinamiento: Proceso descendente para pasar de una visión global a una solución técnica detallada.
Modularidad: División del sistema en componentes con responsabilidades y servicios claros.
Ocultamiento de Información: Los detalles internos de un componente deben ser invisibles para otros; solo se accede a través de interfaces públicas.
Independencia Funcional: Se busca obtener sistemas con Alta Cohesión (cada parte hace una sola cosa bien) y Bajo Acoplamiento (mínima dependencia entre partes).
Release (Liberación): Gránulo de funcionalidad que se entrega al usuario o se pone a disposición para reutilización.

Desarrollo del Temario

1. El Proceso de Diseño: Del "Qué" al "Cómo"

El diseño consiste en proponer alternativas tecnológicas para resolver el problema del cliente y elegir la más óptima para su futura implementación.

Dominio del Problema (Análisis): Se centra en entender los requisitos y el "Qué" debe hacer el sistema.
Dominio de la Solución (Diseño): Se centra en el "Cómo" informático, trabajando con elementos tangibles como modelos de datos reales y diagramas de subsistemas.

Explicación del Profesor: El diseño no es un proceso rígido de "paso a paso" como la toma de requisitos, sino que se basa en la aplicación de buenas prácticas y la adquisición de experiencia. Es un proceso creativo similar al de un arquitecto que dibuja los planos de una casa antes de poner el primer ladrillo.

2. La Pirámide del Diseño de Software

El diseño se estructura en cuatro niveles jerárquicos:

Diseño de Componentes (Cúspide): Transforma los elementos estructurales en descripciones procedimentales.
Diseño de la Interfaz: Define cómo se comunica el software con personas y otros sistemas.
Diseño de la Arquitectura: Describe las relaciones entre los elementos principales, estilos y patrones.
Diseño de Datos o Clases (Base): Transforma los modelos de dominio en estructuras de datos y clases de diseño necesarias para la implementación.

¡OJO AL DATO!: El modelo de datos es la base de toda la pirámide. Si no está bien asentado desde la fase de análisis (modelo de dominio), el resto del diseño será inestable.

3. Principios de Diseño de Componentes (SOLID)

A. Principio Abierto-Cerrado (OCP)

Un componente debe estar abierto para su extensión pero cerrado para su modificación.

Cita/Ejemplo: Imaginemos un sistema de detectores. Si usamos una interfaz genérica de Sensor (con métodos como leer(), activar()), podemos añadir un nuevo Sensor de CO2 sin tener que tocar ni una línea de código del componente Detector original.

B. Principio de Sustitución de Liskov (LSP)

Toda subclase debe poder sustituir a su clase base sin alterar el funcionamiento del sistema.

Cita/Ejemplo: Si tenemos una clase madre Empleado y clases hijas Gerente y Dependiente, el sistema de Pagos debe poder procesar cualquier objeto que sea de tipo Empleado de forma genérica mediante el método calcularSueldo(empleado).

C. Principio de Inversión de Dependencia (DIP)

Se debe depender de las abstracciones (interfaces) y no de las concreciones (clases específicas).

Cita/Ejemplo: Un Boton no debería depender directamente de una Lampara. Es mejor que el Boton dependa de una interfaz Conmutable. Así, el mismo botón podría encender una lámpara, un televisor o un motor sin cambiar su diseño interno.

D. Principio de Segregación de la Interfaz (ISP)

Es mejor tener muchas interfaces específicas que una sola de propósito general.

Cita/Ejemplo (Profesor): Como en Microsoft Word. No tenemos un único menú con las 3 millones de funciones mezcladas. Tenemos interfaces segregadas: una para "Texto", otra para "Insertar Imágenes", otra para "Disposición". Esto favorece la independencia funcional.

4. Principios de Cohesión (REP, CRP, CCP)

Estos principios guían cómo agrupar clases en paquetes o componentes:

REP (Equivalencia de Liberación/Reutilización): El gránulo de lo que se reutiliza debe ser el mismo que el de la versión (release) que se libera. Si haces una biblioteca, la release debe ser funcional y estable para quien la use.
CCP (Cierre Común): Las clases que cambian juntas, deben ir juntas. Si un cambio en una clase obliga a cambiar otra, ambas pertenecen al mismo paquete para minimizar el impacto en otros componentes.
CRP (Reutilización Común): Las clases que no se reutilizan juntas, no deben agruparse juntas.

Ejemplo del Profesor: Si una biblioteca ocupa 3 GB porque hace de todo, pero tú solo necesitas una función pequeña, el diseño es malo porque te obliga a descargar e integrar todo lo innecesario.

Preguntas de Autoevaluación

¿Cuál es la diferencia fundamental entre el dominio del problema y el dominio de la solución?
¿Por qué se representa el diseño de software como una pirámide y qué nivel constituye su base?
Explica con un ejemplo el concepto de "Alta Cohesión" y "Bajo Acoplamiento" en el diseño de componentes.
¿Qué principio SOLID se está violando si, al añadir una nueva funcionalidad, te ves obligado a modificar código en múltiples clases ya existentes?
¿En qué consiste el Principio de Cierre Común (CCP) y qué beneficio aporta al mantenimiento del software?