7. Diagramas de clases: clases, atributos, operaciones y responsabilidades
7.1 Introducción
El diagrama de clases es uno de los diagramas UML más importantes para representar la estructura de un sistema. Permite mostrar clases, atributos, operaciones, responsabilidades y relaciones entre elementos. Es especialmente útil cuando se trabaja con sistemas orientados a objetos, aunque también puede servir para razonar sobre conceptos del dominio antes de pensar en código.
Una clase describe un tipo de objeto. Indica qué información puede tener y qué comportamiento puede ofrecer. Por ejemplo, en un sistema de turnos médicos podrían existir clases como Paciente, Profesional, Turno, Especialidad y Agenda.
7.2 Qué representa una clase
Una clase representa una abstracción. No describe un objeto concreto, sino un conjunto de objetos que comparten características y responsabilidades. La clase Paciente no es una persona específica; es la descripción general de los datos y comportamientos que tendrán los pacientes dentro del sistema.
En UML, una clase se dibuja normalmente como un rectángulo dividido en compartimentos. El primer compartimento contiene el nombre de la clase. El segundo puede contener atributos. El tercero puede contener operaciones.
7.3 Estructura básica de una clase UML
Una clase UML suele organizarse en tres partes: nombre, atributos y operaciones. El nombre identifica el concepto o elemento de diseño. Los atributos describen datos que los objetos de esa clase pueden conservar. Las operaciones representan comportamientos que la clase puede realizar o servicios que puede ofrecer a otros elementos del sistema.
7.4 Nombre de la clase
El nombre de una clase debe ser claro y representar un concepto significativo. Normalmente se usa un sustantivo en singular, como Cliente, Pedido, Producto, Factura o Turno. También pueden usarse nombres compuestos cuando ayudan a precisar la responsabilidad, como DetalleDePedido o ServicioDeAutenticación.
Conviene evitar nombres demasiado genéricos, como Datos, Gestor, Proceso o Información. Esos nombres no explican qué representa la clase ni qué responsabilidad tiene dentro del sistema.
7.5 Atributos
Los atributos representan información que una instancia de la clase puede almacenar. Por ejemplo, una clase Paciente podría tener atributos como nombre, documento, fechaDeNacimiento y teléfono. Una clase Turno podría tener fecha, hora, estado y motivoConsulta.
En UML, un atributo puede escribirse con distintos niveles de detalle. Una forma simple es colocar solo el nombre. Una forma más completa incluye visibilidad, tipo de dato y valor inicial.
Por ejemplo: fecha: Date, estado: EstadoTurno o importeTotal: Decimal.
7.6 Operaciones
Las operaciones representan comportamientos que una clase puede realizar. En muchos casos se corresponden con métodos en un lenguaje de programación, aunque en un modelo de análisis pueden expresarse de manera más conceptual.
Una operación puede escribirse con nombre, parámetros y tipo de retorno:
Por ejemplo: calcularTotal(): Decimal, cancelar(motivo: String): void o estaDisponible(): Boolean.
7.7 Responsabilidades
La responsabilidad de una clase indica qué debe conocer y qué debe hacer. Una clase bien definida tiene una responsabilidad clara. Si una clase concentra demasiadas tareas, el diseño se vuelve difícil de comprender, probar y modificar.
Por ejemplo, una clase Turno puede ser responsable de conocer su fecha, hora, paciente, profesional y estado. También puede validar si puede cancelarse según ciertas reglas. Pero no debería ser responsable de enviar correos, dibujar pantallas o conectarse directamente con servicios externos si esas tareas pertenecen a otros elementos del sistema.
7.8 Clase conceptual y clase de diseño
No todos los diagramas de clases tienen el mismo propósito. Un diagrama conceptual se concentra en conceptos del problema. Un diagrama de diseño se acerca más a la solución técnica y puede incluir clases de servicio, controladores, repositorios, interfaces y detalles más próximos al código.
Por ejemplo, en análisis puede aparecer Turno como concepto del dominio. En diseño pueden aparecer además TurnoService, TurnoRepository, ControladorTurnos o NotificadorDeTurnos. Mezclar estos niveles sin aclaración puede producir confusión.
7.9 Visibilidad
UML permite indicar la visibilidad de atributos y operaciones. Los símbolos más comunes son:
+público: accesible desde otros elementos.-privado: accesible solo dentro de la clase.#protegido: accesible desde la clase y sus especializaciones.~paquete: accesible dentro del mismo paquete.
En diagramas conceptuales puede omitirse la visibilidad. En diagramas de diseño puede ser útil para expresar encapsulamiento y decisiones cercanas a la implementación.
7.10 Tipos de datos
Los atributos y parámetros pueden indicar tipos de datos. Algunos tipos son simples, como String, Integer, Boolean, Date o Decimal. Otros pueden ser clases o enumeraciones del propio modelo, como EstadoTurno, MedioDePago o Dirección.
El nivel de precisión depende del objetivo del diagrama. Si se está explorando el dominio, puede alcanzar con nombres de atributos. Si se está preparando un diseño más concreto, los tipos ayudan a reducir ambigüedad.
7.11 Atributos derivados
Un atributo derivado es un valor que puede calcularse a partir de otros datos. En UML puede indicarse con una barra inclinada antes del nombre. Por ejemplo, /edad puede derivarse de fechaDeNacimiento.
Usar atributos derivados ayuda a distinguir datos almacenados de datos calculados. Esto evita suposiciones incorrectas sobre qué información debe guardarse realmente.
7.12 Operaciones y comandos del dominio
Una operación no debería agregarse solo porque puede programarse. Debe tener sentido dentro de la responsabilidad de la clase. En modelos de dominio, algunas operaciones representan cambios importantes, como confirmar(), cancelar(), pagar() o cerrar().
Estas operaciones pueden expresar reglas del negocio. Por ejemplo, un Turno puede cancelarse solo si todavía no fue atendido. Una Factura puede anularse solo si cumple ciertas condiciones. El diagrama de clases puede sugerir estas responsabilidades, aunque el detalle completo de la regla se documente aparte.
7.13 Clases, objetos e instancias
Una clase es una descripción general; un objeto es una instancia concreta de esa clase. Por ejemplo, Paciente es una clase, mientras que pacienteJuanPerez puede ser un objeto concreto con nombre, documento y fecha de nacimiento específicos.
El diagrama de clases muestra tipos y relaciones generales. Si se necesita mostrar ejemplos concretos con valores reales, corresponde usar un diagrama de objetos.
7.14 Clases con responsabilidades equilibradas
Una clase con pocas responsabilidades puede quedar demasiado pobre y obligar a distribuir lógica en lugares incorrectos. Una clase con demasiadas responsabilidades se vuelve difícil de mantener. El diseño busca un equilibrio: cada clase debe tener una razón clara para existir y colaborar con otras de manera comprensible.
Una señal de alerta aparece cuando una clase acumula muchos atributos y operaciones no relacionadas. Otra señal aparece cuando su nombre es tan genérico que podría significar cualquier cosa.
7.15 Ejemplo: sistema de turnos médicos
En un sistema de turnos médicos, una clase Turno podría tener atributos como fecha, hora, estado y motivoConsulta. También podría tener operaciones como confirmar(), cancelar() y reprogramar(). Su responsabilidad principal sería representar una reserva de atención con un profesional en una fecha y horario determinados.
La clase Paciente podría conservar datos de identificación y contacto. La clase Profesional podría conocer su matrícula, especialidad y disponibilidad. Cada clase debe aportar una parte clara del modelo.
7.16 Cuándo omitir atributos u operaciones
No siempre es necesario mostrar todos los atributos u operaciones. En una vista conceptual, puede interesar solamente la existencia de las clases y sus relaciones. En una vista de diseño, puede ser necesario mostrar más detalle.
También se puede usar un diagrama parcial centrado en una funcionalidad. Por ejemplo, para explicar cancelación de turnos, tal vez solo se muestren clases y operaciones relacionadas con ese escenario.
7.17 Criterios de revisión
- ¿Cada clase representa un concepto o responsabilidad clara?
- ¿Los nombres están en singular y son comprensibles?
- ¿Los atributos pertenecen realmente a la clase?
- ¿Las operaciones corresponden a responsabilidades de la clase?
- ¿El nivel de detalle coincide con el objetivo del diagrama?
- ¿Se evita mezclar conceptos del dominio con detalles técnicos sin criterio?
- ¿El diagrama puede leerse sin depender de explicaciones extensas?
7.18 Errores frecuentes
- Nombrar clases con verbos en lugar de sustantivos.
- Crear clases demasiado genéricas, como Gestor, Datos o Sistema.
- Agregar atributos que pertenecen a otra clase.
- Convertir cada tabla de base de datos en una clase sin analizar responsabilidades.
- Agregar operaciones que no corresponden a la clase.
- Mezclar un modelo conceptual con un diseño técnico sin aclarar el nivel.
- Mostrar demasiados detalles cuando el objetivo es explicar la estructura general.
7.19 Qué debes recordar de este tema
- El diagrama de clases representa estructura mediante clases, atributos, operaciones y relaciones.
- Una clase describe un conjunto de objetos con características y responsabilidades comunes.
- Los atributos representan información; las operaciones representan comportamiento.
- Una clase debe tener una responsabilidad clara.
- El nivel de detalle depende de si el diagrama es conceptual, de análisis o de diseño.
- No siempre es necesario mostrar todos los atributos y operaciones.
7.20 Conclusión
El diagrama de clases es una herramienta central para representar la estructura de un sistema. Permite identificar conceptos, distribuir responsabilidades y preparar decisiones de diseño. Su utilidad depende de nombrar bien las clases, ubicar correctamente atributos y operaciones, y mantener un nivel de detalle coherente con el propósito del modelo.
En el próximo tema veremos las relaciones en diagramas de clases: asociación, agregación, composición, dependencia y herencia.