UML: diagramas de estructura

UML es el lenguaje de modelado con el que se documenta un sistema orientado a objetos. Es una notación, no una metodología: dice cómo se dibuja lo que se ha decidido, no cómo hay que llevar el proyecto.

En su versión 2.5 define catorce tipos de diagrama, repartidos en dos grandes ramas. Los diagramas de estructura describen cómo está hecho el sistema, es decir, qué piezas hay y cómo se relacionan, sin que pase el tiempo. Los diagramas de comportamiento describen qué ocurre: cómo se usa el sistema y cómo evoluciona.

Los cuatro diagramas de interacción no son una tercera rama: cuelgan del diagrama de interacción, que es uno de los de comportamiento. Por eso la cuenta sale a catorce y no a quince.

El diagrama de clases es el diagrama central de UML: en él todo son clases. Cada una se dibuja con su nombre, sus atributos y sus métodos, y las líneas que las unen expresan cómo se conocen entre ellas.

La relación básica es la asociación, que equivale a lo que en un modelo entidad-relación es una relación entre entidades. Ese paralelismo es útil para entenderlo, pero conviene no llevarlo demasiado lejos: el diagrama de clases modela objetos con comportamiento, no tablas.

Un atributo que apunta a otra clase y una asociación dibujada entre las dos son la misma cosa vista de dos formas. La asociación es la forma gráfica de decir que una clase guarda una referencia a la otra.

Además de la asociación simple, el diagrama de clases distingue varios tipos de relación con significados distintos. Las dos primeras se parecen mucho y se preguntan justo por eso.

La regla rápida para separar agregación de composición: en la agregación la parte sobrevive al todo, en la composición no. Un tema agrega preguntas, que existen aunque el tema se retire; un intento se compone de sus respuestas, que no significan nada sin él.

El diagrama de objetos representa un ejemplo concreto del árbol de objetos que hay en memoria en un instante dado. Donde el diagrama de clases dice «un tema tiene muchas preguntas», el de objetos dice «este tema tiene estas tres preguntas».

No aporta información nueva sobre el modelo: es una fotografía de un caso particular, y su utilidad está en poder visualizarlo mejor. Es la herramienta a la que se recurre cuando una parte del diagrama de clases resulta difícil de entender en abstracto.

Clases frente a objetos, otra vez: el diagrama de clases describe lo que puede haber y el de objetos enseña lo que hay en un momento concreto.

Un componente es una idea de alto nivel: reúne varias clases y presta un servicio al resto del sistema. Está pensado para ser reutilizado, y por eso se define por lo que ofrece hacia fuera y no por lo que tiene dentro.

Un componente no suele ser autónomo del todo: además de ofrecer su servicio, normalmente necesita consumir el de otro. El diagrama de componentes dibuja precisamente esas dos caras y quién encaja con quién.

El diagrama de despliegue muestra la arquitectura del sistema desde otro ángulo: cómo se distribuyen físicamente los artefactos software, es decir, qué se instala y dónde.

Componentes y despliegue responden a preguntas distintas: el de componentes dice en qué piezas lógicas se divide el sistema, y el de despliegue dice en qué máquinas acaban esas piezas.

El diagrama de paquetes agrupa elementos: clases, componentes o cualquier otro elemento de UML. Sirve para poder mirar un sistema grande sin ahogarse en el detalle, y para dejar claras las dependencias entre grandes bloques.

El diagrama de estructura compuesta muestra la estructura interna de una clase y las colaboraciones que se dan dentro de ella. Es el que se usa cuando una sola clase esconde por dentro un montaje que merece explicarse aparte.

El diagrama de perfil sirve para adaptar UML a una plataforma concreta, como una tecnología empresarial de Java o el entorno de desarrollo de otro fabricante. Recoge las extensiones propias de esa plataforma para poder modelar con sus conceptos.

UML no se puede ampliar con símbolos nuevos, pero sí trae mecanismos previstos para añadir significado a los elementos que ya existen. Son cuatro y van en escalera: los tres primeros son piezas sueltas y el cuarto las empaqueta.

El caso típico de estereotipo es marcar que una clase pertenece a la capa de interfaz de usuario. La clase sigue siendo una clase corriente y se dibuja igual; lo que aporta el estereotipo es decir de qué tipo de clase se trata dentro de este proyecto.

Un perfil no es un mecanismo más al mismo nivel que los otros tres: es el conjunto de todos ellos aplicado a un mismo ámbito. Por eso el diagrama de perfil es el que adapta UML a una plataforma concreta.