Diagramas UML: Clases, Secuencias, Actividades y Casos de Uso
Este artículo te ofrece una descripción completa de los diagramas UML, incluidos todos los tipos principales, relaciones y ejemplos prácticos.
En pocas palabras
UML (Unified Modeling Language) es la notación gráfica estandarizada para modelar sistemas software. Proporciona diferentes tipos de diagramas para representar distintos aspectos del desarrollo de software.
Descripción técnica concisa
Unified Modeling Language (UML) es un lenguaje de modelado estandarizado por la Object Management Group (OMG) para el desarrollo de software orientado a objetos.
Tipos principales de diagramas:
- Diagramas estructurales: Aspectos estáticos (clases, componentes, despliegue)
- Diagramas de comportamiento: Aspectos dinámicos (actividades, secuencias, estados)
- Diagramas de interacción: Comunicación entre objetos
Diagramas más importantes:
- Diagrama de clases: Clases, atributos, métodos, relaciones
- Diagrama de secuencia: Secuencia temporal y flujo de mensajes
- Diagrama de actividades: Flujos de procesos y decisiones
- Diagrama de casos de uso: Requisitos e interacciones de actores
UML actúa como medio de comunicación entre desarrolladores, arquitectos y stakeholders, y constituye la base para generación de código y documentación.
Puntos clave para exámenes
- Diagrama de clases: Estructura estática con atributos, métodos, relaciones
- Diagrama de secuencia: Interacciones temporales entre objetos
- Diagrama de actividades: Flujos de procesos con decisiones y paralelismo
- Diagrama de casos de uso: Requisitos funcionales e interacciones de actores
- Relaciones: Asociación, agregación, composición, herencia
- Modificadores de visibilidad: public (+), private (-), protected (#), package (~)
- Multiplicidades: 1, , 0..1, 1.., 0..*
- Relevante para IHK en arquitectura y diseño de software
Componentes principales
Diagrama de clases
- Clases: Rectángulos con nombre, atributos, métodos
- Atributos: Propiedades con tipo y visibilidad
- Métodos: Operaciones con parámetros y tipo de retorno
- Relaciones: Conexiones entre clases
Diagrama de secuencia
- Actores: Participantes de la interacción
- Líneas de vida: Líneas verticales para objetos
- Mensajes: Flechas horizontales entre líneas de vida
- Cajas de activación: Rectángulos en las líneas de vida
Diagrama de actividades
- Acciones: Rectángulos redondeados
- Decisiones: Rombos para bifurcaciones
- Inicio/Fin: Círculos para comienzo y término del proceso
- Barras de sincronización: Para flujos paralelos
Diagrama de casos de uso
- Casos de uso: Óvalos para funcionalidades
- Actores: Figuras de palo para usuarios y roles
- Límites del sistema: Rectángulos alrededor de los casos de uso
- Relaciones: Líneas entre actores y casos de uso
Ejemplos prácticos
1. Diagrama de clases (Sistema de comercio electrónico)
@startuml ECommerceClassDiagram
class Cliente {
-clienteId: Long
-nombre: String
-email: String
-direccion: String
+getClienteId(): Long
+realizar(productoId: Long, cantidad: Int): Pedido
+getPedidos(): List<Pedido>
}
class Pedido {
-pedidoId: Long
-fechaPedido: Date
-totalPedido: Decimal
-estado: String
+calcularTotalPedido(): Decimal
+setEstado(estado: String): void
+getLineas(): List<LineaPedido>
}
class Producto {
-productoId: Long
-nombre: String
-precio: Decimal
-stock: Int
+getPrecio(): Decimal
+verificarDisponibilidad(cantidad: Int): Boolean
+reducirStock(cantidad: Int): void
}
class LineaPedido {
-lineaId: Long
-cantidad: Int
-precioUnitario: Decimal
+calcularPrecioTotal(): Decimal
}
' Relaciones
Cliente "1" -- "0..*" Pedido : realiza >
Pedido "1" -- "1..*" LineaPedido : contiene >
Pedido "1" -- "*" Producto : hace referencia >
Producto "0..*" -- "0..*" LineaPedido : es pedido >
@enduml2. Diagrama de secuencia (Proceso de pedido)
@startuml PedidoSecuenciaDiagrama
actor Cliente
participant "ServicioPedido" as Servicio
participant "ServicioProducto" as Producto
participant "ServicioPago" as Pago
participant "ServicioAlmacen" as Almacen
Cliente -> Servicio: realizarPedido(productos, cantidad)
activate Servicio
Servicio -> Producto: verificarProductos(productos)
activate Producto
Producto --> Servicio: infoDisponibilidad
deactivate Producto
alt todos los productos disponibles
Servicio -> Almacen: reservarAlmacen(productos, cantidad)
activate Almacen
Almacen --> Servicio: confirmacionReserva
deactivate Almacen
Servicio -> Pago: procesarPago(cliente, monto)
activate Pago
Pago --> Servicio: confirmacionPago
deactivate Pago
Servicio -> Almacen: confirmarReserva(idReserva)
activate Almacen
Almacen --> Servicio: confirmacionExitosa
deactivate Almacen
Servicio --> Cliente: confirmacionPedido(idPedido)
else productos no disponibles
Servicio --> Cliente: errorDisponibilidad(productos)
end
deactivate Servicio
@enduml3. Diagrama de actividades (Procesamiento de pedidos)
@startuml PedidoActividadesDiagrama
start
:Pedido recibido;
if (Producto disponible?) then (sí)
:Verificar stock;
fork
:Procesar pago;
fork again
:Verificar dirección de entrega;
end fork
if (Pago exitoso?) then (sí)
:Confirmar pedido;
:Reducir stock;
:Gestionar envío;
stop
else (no)
:Rechazar pedido;
:Cancelar reserva de almacén;
stop
endif
else (no)
:Reportar error de disponibilidad;
:Sugerir productos alternativos;
stop
endif
@enduml4. Diagrama de casos de uso (Sistema de comercio electrónico)
@startuml ECommerceUseCaseDiagram
actor Cliente
actor Administrador
actor Proveedor
rectangle "Sistema de Comercio Electrónico" {
usecase "Buscar producto" as UC1
usecase "Ver producto" as UC2
usecase "Gestionar carrito" as UC3
usecase "Realizar pedido" as UC4
usecase "Rastrear pedido" as UC5
usecase "Dejar reseña" as UC6
usecase "Gestionar productos" as UC7
usecase "Procesar pedidos" as UC8
usecase "Gestionar entregas" as UC9
}
' Relaciones
Cliente --> UC1
Cliente --> UC2
Cliente --> UC3
Cliente --> UC4
Cliente --> UC5
Cliente --> UC6
Administrador --> UC7
Administrador --> UC8
Proveedor --> UC9
' Relaciones de inclusión
UC4 --> UC3 : <<include>>
UC4 --> UC2 : <<include>>
' Relaciones de extensión
UC6 --> UC4 : <<extend>>
@enduml5. Código Java generado desde diagrama de clases
// Cliente.java
public class Cliente {
private Long clienteId;
private String nombre;
private String email;
private String direccion;
private List<Pedido> pedidos = new ArrayList<>();
public Long getClienteId() {
return clienteId;
}
public Pedido realizar(Long productoId, int cantidad) {
Pedido pedido = new Pedido();
pedido.setFechaPedido(new Date());
// Agregar línea de pedido
LineaPedido linea = new LineaPedido();
linea.setCantidad(cantidad);
pedido.addLinea(linea);
pedidos.add(pedido);
return pedido;
}
public List<Pedido> getPedidos() {
return new ArrayList<>(pedidos);
}
}
// Pedido.java
public class Pedido {
private Long pedidoId;
private Date fechaPedido;
private BigDecimal totalPedido;
private String estado;
private List<LineaPedido> lineas = new ArrayList<>();
public BigDecimal calcularTotalPedido() {
return lineas.stream()
.map(LineaPedido::calcularPrecioTotal)
.reduce(BigDecimal.ZERO, BigDecimal::add);
}
public void setEstado(String estado) {
this.estado = estado;
}
public List<LineaPedido> getLineas() {
return new ArrayList<>(lineas);
}
public void addLinea(LineaPedido linea) {
lineas.add(linea);
}
}
// Producto.java
public class Producto {
private Long productoId;
private String nombre;
private BigDecimal precio;
private int stock;
public BigDecimal getPrecio() {
return precio;
}
public boolean verificarDisponibilidad(int cantidad) {
return stock >= cantidad;
}
public void reducirStock(int cantidad) {
if (verificarDisponibilidad(cantidad)) {
stock -= cantidad;
} else {
throw new IllegalArgumentException("Stock insuficiente");
}
}
}
// LineaPedido.java
public class LineaPedido {
private Long lineaId;
private int cantidad;
private BigDecimal precioUnitario;
public BigDecimal calcularPrecioTotal() {
return precioUnitario.multiply(new BigDecimal(cantidad));
}
}
Relaciones UML en detalle
Asociación
Cliente 1..* --* Pedido- Ambas clases son interdependientes
- Ciclo de vida independiente
Agregación
Vehículo 1 --* Rueda- Las ruedas pueden existir sin el vehículo
- Relación “tiene-un”
Composición
Auto 1 --* Motor- El motor existe solo con el auto
- Relación “es-parte-de”
Herencia
Vehículo <|-- Auto- Auto hereda de Vehículo
- Relación “es-un”
Implementación
Interfaz <|.. Clase- Clase implementa interfaz
- Relación de realización
Multiplicidades
| Símbolo | Significado | Ejemplo |
|---|---|---|
| 1 | Exactamente uno | 1 cliente |
| 0..1 | Cero o uno | 0..1 dirección |
| * | Cero o más | * pedidos |
| 1..* | Mínimo uno | 1..* líneas |
| 0..* | Cero a cualquier cantidad | 0..* productos |
| 2..4 | Entre 2 y 4 | 2..4 ruedas |
Modificadores de visibilidad
| Símbolo | Significado | Descripción |
|---|---|---|
| + | public | Accesible desde cualquier lugar |
| - | private | Solo dentro de la clase |
| # | protected | Dentro de la clase y subclases |
| ~ | package | Dentro del paquete |
Ventajas y desventajas
Ventajas de UML
- Estandarización: Notación uniforme para todos
- Visualización: Relaciones complejas comprensibles
- Comunicación: Lenguaje común para el equipo
- Documentación: Generación automática posible
- Generación de código: Implementación directa
Desventajas
- Complejidad: Poco manejable en sistemas muy grandes
- Curva de aprendizaje: Requiere tiempo de capacitación
- Sobre-ingeniería: Modelado demasiado detallado
- Mantenimiento: Los cambios requieren actualizar diagramas
Preguntas frecuentes de examen
-
¿Cuál es la diferencia entre agregación y composición? Agregación: “tiene-un” (las partes pueden existir independientemente), Composición: “es-parte-de” (las partes existen solo con el todo).
-
Explica las multiplicidades 1.. y 0..1.* 1..*: Mínimo uno, cantidad cualquiera. 0..1: Cero o exactamente uno.
-
¿Cuándo se utilizan diagramas de secuencia? Para representar secuencias temporales e interacciones entre objetos.
-
¿Cuál es el propósito de los diagramas de casos de uso? Modelar requisitos desde la perspectiva de usuarios y actores.