Aprende a representar visualmente la estructura de un sistema orientado a objetos mediante el lenguaje estándar de modelado UML.
Unified Modeling Language — Lenguaje estándar visual para modelar sistemas de software. Los diagramas de clases son el más usado en POO.
Permite diseñar antes de codificar: muestra clases, atributos, métodos y cómo se relacionan entre sí en el sistema.
Comenzaremos con la anatomía de una clase, luego multiplicidad, y escalaremos por cada tipo de relación hasta los ejemplos completos.
Estructura de una clase · Notación UML · Visibilidad · Multiplicidad · Dependencia
Simple · Agregación · Composición · Reflexiva — con sus notaciones y diferencias clave
Generalización · Herencia múltiple · Realización de interfaces — el principio "es un"
Estereotipos «call» «create» «use» y más · Ejemplos completos de sistemas reales · Quiz
Una clase en UML se representa con un rectángulo dividido en tres secciones: nombre, atributos y métodos.
Una clase UML tiene tres compartimentos:
+ public · - private · # protected · ~ package
| Símbolo | Nombre | Acceso desde… | Ejemplo |
|---|---|---|---|
+ | public | Cualquier clase | + getNombre(): String |
- | private | Solo la propia clase | - nombre: String |
# | protected | Clase y sus subclases | # id: int |
~ | package | Mismo paquete | ~ config: Map |
Puede instanciarse directamente. Tiene implementación completa de todos sus métodos.
No puede instanciarse directamente. Tiene al menos un método abstracto (sin implementar). Nombre en cursiva.
Solo declara métodos sin implementación. Las clases la realizan mediante la relación de Realización.
La multiplicidad define cuántas instancias de una clase pueden relacionarse con instancias de otra. Se coloca en los extremos de las líneas de relación.
| Escenario | Multiplicidad | Lectura |
|---|---|---|
| Un Autor puede publicar varios Libros | 1 — 0..* | Un autor tiene cero o más libros |
| Un Pedido tiene al menos un Producto | 1 — 1..* | Un pedido tiene uno o más productos |
| Un Empleado puede tener un Jefe (o no) | 1 — 0..1 | Un empleado tiene cero o un jefe |
| Un Equipo de fútbol tiene 11 jugadores | 1 — 11 | Un equipo tiene exactamente 11 jugadores |
| Torneo con 2 a 8 equipos | 1 — 2..8 | Un torneo incluye entre 2 y 8 equipos |
La relación más débil entre clases. Una clase "cliente" usa temporalmente a otra "proveedor", sin mantenerla como atributo permanente.
Una dependencia indica que un cambio en el proveedor puede afectar al cliente, pero la relación es temporal y no implica que el cliente "tenga" al proveedor como atributo.
Se usa cuando una clase:
Relación permanente entre dos clases donde una "conoce" y mantiene una referencia a la otra como atributo. Es la relación más común en diagramas OO.
Una Asociación significa que un objeto de la clase A mantiene una referencia permanente a uno o más objetos de la clase B (o viceversa).
Relación "todo-parte" donde las partes pueden existir independientemente del todo. El diamante vacío aparece en el extremo del "todo".
Es una asociación especial que modela una relación "tiene un" donde el todo agrupa partes, pero las partes pueden existir de forma independiente al todo.
Si el todo se destruye, las partes siguen existiendo y pueden pertenecer a otro todo.
Relación "todo-parte" fuerte: las partes NO pueden existir sin el todo. Ciclo de vida compartido. Diamante relleno en el extremo del "todo".
Es la forma más fuerte de agregación. El todo posee y controla la vida de las partes: si el todo se destruye, las partes también desaparecen.
| Característica | ◇ Agregación | ◆ Composición |
|---|---|---|
| Ciclo de vida | Independiente | Dependiente (compartido) |
| ¿La parte sobrevive sin el todo? | ✅ Sí | ❌ No |
| ¿Una parte puede tener varios todos? | ✅ Sí | ❌ No (solo uno) |
| ¿Quién crea las partes? | Alguien externo | El propio todo |
| Símbolo UML | Diamante vacío ◇ | Diamante relleno ◆ |
| Ejemplo | Universidad — Profesor | Casa — Habitación |
Una clase se relaciona con instancias de SU MISMO tipo. La línea de asociación conecta la clase consigo misma, formando un bucle.
Ocurre cuando objetos de la misma clase se relacionan entre sí. La línea de asociación parte y termina en la misma clase.
Es muy común en estructuras jerárquicas o cuando objetos del mismo tipo se supervisan, contienen o referencian entre sí.
La relación "ES UN TIPO DE". Una subclase hereda atributos y métodos de su superclase, pudiendo extenderlos o sobreescribirlos. Triangulo vacío hacia el padre.
La generalización representa la relación "es un tipo de". La subclase hereda todos los atributos y métodos de la superclase, y puede agregar los suyos propios.
En algunos lenguajes (C++, Python) y en UML, una clase puede heredar de dos o más superclases. En Java/C# no se permite directamente (se usa interfaces).
Pato hereda de Volador y Nadador (herencia múltiple)
Una clase concreta implementa los métodos declarados por una interfaz. Línea punteada con triángulo vacío hacia la interfaz. Principio: "PUEDE COMPORTARSE COMO".
Conecta una clase concreta con una interfaz. La clase se compromete a implementar todos los métodos declarados en la interfaz.
Los estereotipos refinan el tipo de dependencia entre clases, indicando exactamente cómo una clase usa a otra. Se escriben entre «guillemets».
| Estereotipo | Significado | Ejemplo de uso |
|---|---|---|
«call» | Una operación de A invoca una operación de B | Sistema «call» Logger.registrar() |
«create» | A crea instancias de B (A es fábrica de B) | Fábrica «create» Producto |
«derive» | El elemento destino se puede calcular desde A | EdadActual «derive» FechaNacimiento |
«instantiate» | A crea objetos de la clase B (más específico que «create») | Builder «instantiate» Objeto |
«permit» | B otorga permiso especial de acceso a A (como friend en C++) | Prueba «permit» ClasePrivada |
«refine» | A es una especificación más detallada de B (otro nivel de abstracción) | DiseñoDetallado «refine» DiseñoAltoNivel |
«use» | A requiere B para su implementación correcta (dependencia genérica) | Controlador «use» ServicioPago |
Diagramas de sistemas reales que integran múltiples tipos de relaciones. Explora cada ejemplo para ver cómo se combinan en la práctica.
10 preguntas sobre todo lo aprendido. Retroalimentación inmediata en cada respuesta.
| Relación | Notación UML | Símbolo clave | Pregunta clave |
|---|---|---|---|
| Dependencia | Línea punteada → (con estereotipo opcional) | - - → | ¿Usa temporalmente? |
| Asociación | Línea sólida (con o sin flecha) | ——— | ¿Se conocen permanentemente? |
| Agregación | Línea sólida + diamante vacío en el todo | ◇——— | ¿Parte existe sin el todo? |
| Composición | Línea sólida + diamante relleno en el todo | ◆——— | ¿Parte muere con el todo? |
| Reflexiva | Asociación que vuelve a la misma clase | ↺ | ¿Se relaciona con su mismo tipo? |
| Herencia | Línea sólida + triángulo vacío hacia el padre | ——▷ | ¿Es un tipo de? |
| Realización | Línea punteada + triángulo vacío hacia la interfaz | - - ▷ | ¿Implementa la interfaz? |