Tema 4: Ingeniería del Software - Diagrama de Clases (UML)

Resumen Ejecutivo

Esta sesión introduce el Diagrama de Clases de UML como una herramienta estructural fundamental para modelar la vista estática de un sistema, definiendo sus elementos básicos y relaciones. Se detalla exhaustivamente la sintaxis para definir clases (atributos, operaciones, visibilidad) y los distintos tipos de relaciones (asociación, generalización, dependencia, realización, agregación y composición). Finalmente, se distingue entre el modelo de análisis (dominio del problema, sin métodos) y el modelo de diseño, siendo el primero el foco de la actividad práctica del curso.

Conceptos Clave

Clase: Descripción de un conjunto de objetos que comparten características, restricciones y semántica.
Objeto: Instancia concreta y discreta de una clase con estado y comportamiento.
Visibilidad: Nivel de acceso a los atributos/métodos (+ Público, # Protegido, - Privado, ~ Paquete).
Atributo Derivado: Atributo cuyo valor se calcula a partir de otros datos del sistema.
Asociación: Relación estructural entre clases que se necesitan mutuamente.
Clase Asociación: Información que surge de la relación entre dos clases y no pertenece exclusivamente a ninguna de ellas.
Agregación vs. Composición: Relaciones "todo-parte". La agregación es débil (las partes sobreviven al todo); la composición es fuerte (ciclos de vida unidos).
Clase de Análisis (Modelo de Dominio): Representación conceptual enfocada en datos (atributos) sin operaciones/métodos.

Desarrollo del Temario

1. Introducción al Diagrama de Clases

El diagrama de clases es una herramienta estructural que ofrece una vista estática del sistema. Modela la estructura de las clases que conforman el software, sirviendo como el "esqueleto" sobre el cual se construye la funcionalidad.

Definición de Clase: Es una abstracción (caja rectangular) que agrupa objetos con la misma estructura de información (atributos) y comportamiento (métodos).
Definición de Objeto: Es una entidad discreta; una instancia específica de una clase.

2. Estructura y Sintaxis de una Clase

Una clase se representa mediante un rectángulo dividido en compartimentos. Cualquier desviación de esta sintaxis se considera una "falta de ortografía" en el lenguaje UML.

Nombre (Primer compartimento): Identificador de la clase. Debe comenzar con mayúscula.
Atributos (Segundo compartimento): Propiedades de la clase. Comienzan con minúscula.
Operaciones (Tercer compartimento): Métodos o funcionalidades. Comienzan con minúscula.

3. Definición de Atributos

La sintaxis completa para un atributo es: $$visibilidad / nombre : tipo [multiplicidad] = valorPorDefecto \{propiedades\}$$

Visibilidad (Obligatorio): Define quién puede acceder al atributo.
- + Pública: Acceso total.
- # Protegida: Acceso para la clase y sus hijas (herencia).
- - Privada: Solo la propia clase.
- ~ Paquete: Visible dentro del mismo paquete.
Nombre y Tipo (Obligatorios): Identificador y tipo de dato (e.g., String, Integer, Date).
Atributo Derivado (/): Se indica con una barra antes del nombre. Significa que el dato no se almacena directamente, sino que se calcula a partir de otros (ej. la edad se deriva de fechaNacimiento).
Multiplicidad: Si es un array o colección (ej. [0..*]).

4. Definición de Operaciones (Métodos)

La sintaxis para las operaciones es: $$visibilidad \ nombre (listaParametros) : tipoRetorno \{propiedades\}$$

Parámetros: Se definen como dirección nombre : tipo. La dirección puede ser in (entrada), out (salida) o inout.
Tipo de Retorno: Opcional si no devuelve nada (void).

¡OJO AL DATO! - Notación Especial: * Subrayado: Indica un miembro Estático (alcance de clase). Todos los objetos comparten el mismo valor en memoria. * Cursiva: Indica un miembro Abstracto. Debe ser implementado por las subclases.

5. Relaciones entre Clases

UML define cuatro tipos principales de relaciones con distinta carga semántica:

Asociación (Línea continua): Relación estructural donde las clases están conectadas y se necesitan para funcionar. Es la relación más común.
Generalización (Línea con triángulo vacío): Herencia. "Es un tipo de". Define una clase padre (superclase) y una hija (subclase).
Dependencia (Línea punteada con flecha): Relación débil de "uso". Una clase utiliza a otra momentáneamente (ej. recibir un objeto como parámetro en un método), pero no es una relación estructural fuerte.
Realización (Línea punteada con triángulo vacío): Relación entre una interfaz (contrato de comportamiento) y la clase que implementa dicho comportamiento (código real).

6. Detalles de la Asociación

Las asociaciones pueden enriquecerse con varios "adornos" para precisar el modelo: * Multiplicidad: Cuántos objetos participan (1, 0..1, 1..*, *). * Roles: Nombre que recibe la clase en el contexto de la relación (ej. aseguradora). * Navegabilidad (Flecha): Indica la dirección en la que se puede acceder a la información. Si no hay flechas, se asume bidireccional.

Clase Asociación

Ocurre cuando la propia relación entre dos clases contiene información valiosa que no pertenece a ninguna de las dos entidades por separado. Se representa "colgando" una clase de la línea de asociación con una línea punteada.

Limitación Importante: Solo puede existir un objeto de la clase asociación para cada par de objetos relacionados. No permite guardar históricos (ej. si compro acciones hoy y mañana vuelvo a comprar, sobrescribo el dato anterior a menos que modele la relación de otra forma).

7. Agregación y Composición

Son tipos especializados de asociación que denotan jerarquía ("Todo-Parte").

Agregación (Rombo blanco): Relación débil o compartida.
- El objeto "parte" puede vivir sin el "todo".
- Ejemplo: Una Canción en un Disco. Si borras el disco, la canción puede seguir existiendo en una lista de reproducción.
Composición (Rombo negro): Relación fuerte o agregación compuesta.
- El ciclo de vida de la "parte" depende del "todo". Si el "todo" muere, la "parte" muere.
- Ejemplo: Una Ventana y sus Botones. Si cierras la ventana, los botones se destruyen.

8. Análisis vs. Diseño

Es crucial distinguir el nivel de abstracción al modelar:

Diagrama de Clases de Diseño: Nivel técnico, cercano al código, incluye visibilidad, tipos de datos exactos y métodos completos.
Diagrama de Clases del Análisis (Modelo de Dominio):
- Se enfoca en el dominio del problema y los conceptos.
- Contenido: Solo contiene atributos de alto nivel.
- Restricción: NO tiene operaciones (métodos).
- Tipos de clases: Entidad (información), Control (lógica), Interfaz (presentación).

Nota para el examen/práctica: En la fase de análisis de requisitos (ejercicio de la actividad), se pide un modelo de dominio. Esto significa que no debéis incluir métodos en vuestras clases, solo atributos que representen datos a nivel de aplicación.

Preguntas de Autoevaluación

Sintaxis: Si ves un atributo subrayado en un diagrama UML (ej. <u>contador: Integer</u>), ¿qué significa exactamente en términos de memoria y acceso?
Relaciones: ¿Cuál es la diferencia semántica fundamental (ciclo de vida) entre una Agregación (rombo blanco) y una Composición (rombo negro)?
Modelado: Estás diseñando un sistema para un Hotel. Un cliente se aloja en una habitación. Si modelas esto con una "Clase Asociación" llamada Estancia entre Cliente y Habitación, ¿podrías registrar que el mismo cliente se alojó en la misma habitación dos fechas diferentes? ¿Por qué?
Análisis vs Diseño: En un diagrama de clases a nivel de análisis (Modelo de Dominio), ¿es correcto incluir la operación +calcularSalario(): Float en la clase Empleado?
Derivados: ¿Cómo representarías visualmente un atributo precioTotal que se calcula sumando el precio de todas las líneas de un pedido?