Skip to content

Tema 8: Introducción al Diseño de Software

📝 Resumen Ejecutivo

Esta sesión marca el punto de inflexión entre el Análisis (el Qué - dominio del problema) y el Diseño (el Cómo - dominio de la solución). Se establece que el objetivo fundamental del diseño es asegurar la mantenibilidad del software a largo plazo, utilizando una estructura piramidal que tiene como base el diseño de datos. Finalmente, se exploran los conceptos críticos de calidad: abstracción, ocultamiento de información, modularidad y la regla de oro del diseño: Alta Cohesión y Bajo Acoplamiento.

🔑 Conceptos Clave

  • Diseño de Software: Proceso creativo y técnico que describe la estructura, datos, interfaces y componentes del sistema para su implementación.
  • Abstracción: Capacidad de manejar la complejidad ignorando detalles técnicos de bajo nivel; evoluciona hacia el refinamiento.
  • Modularidad: División del software en componentes con nombres distintos y abordables por separado.
  • Ocultamiento de Información: Principio donde los módulos ocultan sus decisiones de diseño (datos y procedimientos) al resto.
  • Cohesión: Indicador de la fortaleza funcional interna de un módulo (cuánto sentido tiene que esas funciones estén juntas).
  • Acoplamiento: Indicador de la interdependencia entre distintos módulos (cuánto dependen unos de otros).

📘 Desarrollo del Temario

1. El Salto del Análisis al Diseño

El proceso de ingeniería sufre una transición fundamental. Mientras que el análisis busca entender el problema (flecha hacia arriba, alto nivel de abstracción), el diseño busca crear la solución (flecha hacia abajo, refinamiento técnico).

  • Dominio del Problema (¿QUÉ?): Se centra en entender al cliente. Usamos herramientas como Diagramas de Casos de Uso (funcionalidad a alto nivel) y Modelo de Dominio (estructura de información).
  • Dominio de la Solución (¿CÓMO?): Aplicamos conocimientos técnicos para construir la respuesta. Aquí definimos la estructura real del software, interfaces y algoritmos.

Explicación del Profesor: La línea entre análisis y diseño es difusa ("permeable"), especialmente en metodologías ágiles o iterativas. Sin embargo, el objetivo ideal de una buena documentación de diseño es que el arquitecto pueda "desaparecer" y el desarrollador sea capaz de implementar el sistema sin hacer preguntas, similar a cómo un constructor sigue los planos de un ingeniero de caminos.

2. Importancia del Diseño: Mantenibilidad

No es obligatorio diseñar para programar; se puede implementar directamente ("spaghetti code"). Sin embargo, el diseño es crucial para la vida útil del producto.

  • Sin Diseño: Se codifica rápido al inicio, pero el sistema se vuelve inestable y difícil de cambiar.
  • Con Diseño: Facilita el mantenimiento y la prueba. Un sistema bien diseñado es escalable, extensible y adaptable a cambios futuros.

¡OJO AL DATO! El diseño sirve principalmente para que el mantenimiento futuro sea menos costoso y más sencillo.

3. La Pirámide del Diseño (Modelos de Diseño)

El diseño se visualiza como una pirámide donde cada capa se sustenta en la anterior.

  1. Diseño de Datos (La Base):
    • Es la base de la pirámide. Transforma el modelo de dominio en estructuras de datos y bases de datos.
    • Importancia Crítica: Si cambia el modelo de datos, obliga a cambiar todas las capas superiores (Lógica de negocio, Control y Vista). Por eso debe ser lo más sólido posible al inicio.
  2. Diseño Arquitectónico:
    • Define la relación entre los elementos principales (subsistemas). Proporciona la visión general.
    • Se basa en patrones arquitectónicos y estilos.
  3. Diseño de la Interfaz:
    • Describe cómo se comunica el software:
      • Con el usuario (UI/UX).
      • Con otros sistemas (APIs externas, ej. PayPal).
      • Entre componentes internos (Interfaces de clases).
  4. Diseño a nivel de Componentes:
    • Transforma elementos estructurales en una descripción procedimental (algoritmos, clases reales). Es lo más cercano al código.

4. Dimensiones del Diseño

El diseño se mueve en dos dimensiones simultáneas: * Dimensión del Proceso: La evolución temporal de las tareas (de la arquitectura a los componentes). * Dimensión de la Abstracción: El nivel de detalle. A medida que avanzamos, descendemos en abstracción y aumentamos el detalle técnico (Refinamiento).

5. Conceptos y Principios Fundamentales

A. División de Problemas (Divide y Vencerás)

Estrategia de dividir un problema complejo en elementos manejables. Esto genera Modularidad. * Curva de Coste: Existe un punto óptimo en la cantidad de módulos. * Pocos módulos = Coste alto por complejidad interna. * Demasiados módulos = Coste alto de integración (hacer que todos hablen entre sí).

B. Ocultamiento de la Información

Los módulos deben ser "cajas negras". Un módulo no debe saber cómo funciona otro por dentro, solo qué interfaz ofrece.

Ejemplo del Profesor: Una calculadora. Tú pulsas el botón de "raíz cuadrada" (interfaz) y te da el resultado. No necesitas saber el algoritmo matemático interno para usarla. Si el código interno cambia, no te afecta mientras el botón siga ahí.

C. Independencia Funcional (CRÍTICO PARA EXAMEN)

Se logra cuando cada módulo resuelve un subconjunto específico de requisitos con la mínima interacción con otros. Se evalúa con dos criterios cualitativos:

  1. Cohesión (Fortaleza Interna):

    • Queremos Alta Cohesión.
    • Significa que todo lo que está dentro de una clase/módulo está ahí porque tiene sentido funcional (ej. GestiónProveedores maneja solo datos de proveedores).
    • Tipos: La mejor es la Funcional. La peor es la Coincidental (agrupado por casualidad).

  2. Acoplamiento (Dependencia Externa):

    • Queremos Bajo Acoplamiento.
    • Significa que los módulos dependen poco unos de otros. Si cambio el Módulo A, el Módulo B no debería enterarse.
    • El peor tipo: Acoplamiento de Contenido. Ocurre cuando un atributo es public. Cualquiera puede modificar el estado interno de un objeto sin control. Por eso los atributos siempre deben ser private.

Regla de Oro: Un buen diseño siempre busca Alta Cohesión y Bajo Acoplamiento.

D. Patrones de Diseño

Soluciones probadas a problemas recurrentes en un contexto específico. * Ejemplo: ¿Necesito que la interfaz gráfica cambie sin romper la lógica? -> Uso patrón MVC (Modelo-Vista-Controlador). * Ejemplo: ¿Necesito una única instancia de conexión a base de datos? -> Uso patrón Singleton.

🧠 Preguntas de Autoevaluación

  1. ¿Por qué se dice que el Diseño de Datos es la base de la pirámide de diseño y qué implica esto para el mantenimiento?

    • Respuesta: Es la base porque todos los demás elementos (arquitectura, interfaz, componentes) dependen de los datos. Si el modelo de datos cambia (ej. añadir un segundo apellido), obliga a cambiar la lógica de control y la interfaz de usuario, afectando a todo el sistema.

  2. Explique la relación entre Modularidad y Coste de Integración basándose en el gráfico de la diapositiva 16.

    • Respuesta: Al dividir el software en más módulos, el coste de desarrollo de cada módulo individual baja (son más simples), pero el coste de integrarlos (hacerlos funcionar juntos) sube. El diseño óptimo busca el punto medio de coste mínimo total.

  3. Para obtener una alta calidad de diseño, ¿cómo deben ser la Cohesión y el Acoplamiento?

    • Respuesta: La Cohesión debe ser Alta (el módulo se enfoca en una sola tarea) y el Acoplamiento debe ser Bajo (mínima interdependencia entre módulos).

  4. Según el profesor, ¿por qué los atributos de una clase nunca deben ser públicos (Acoplamiento de Contenido)?

    • Respuesta: Porque genera el peor tipo de acoplamiento (de contenido). Si un atributo es público, cualquier componente externo puede modificarlo sin que la clase propietaria se entere o pueda validarlo, rompiendo el encapsulamiento y dificultando el mantenimiento.

  5. ¿Cuál es la diferencia principal entre el objetivo del Análisis y el objetivo del Diseño?

    • Respuesta: El Análisis se centra en el "QUÉ" (entender el problema del cliente, alto nivel de abstracción), mientras que el Diseño se centra en el "CÓMO" (definir la solución técnica, bajo nivel de abstracción/refinamiento).