Introducción a la notación UML

Siguiendo con nuestro de programación en esta ocasión vamos a explicar que es el lenguaje unificado de modelado (UML, por sus siglas en inglés, Unified Modeling Language) es uno de los lenguaje de modelado de sistemas de software más conocido y utilizado en la actualidad. Especialmente esta presente en los sistemas orientados a objetos. Su función es la de mediante un lenguaje gráfico poder visualizar, especificar, construir y documentar un sistema.

Es importante remarcar que UML es un "lenguaje de modelado" para especificar o para describir métodos o procesos, pero que no tiene nada que ver con el lenguaje que se use. El utilizar un lenguaje u otro lo único que hará será cambiar la interpretación de ese diagrama y la codificación del mismo, de todas formas el comportamiento descrito debe ser el mismo independientemente de la plataforma.

No entraremos mucho más en detalle, simplemente añadir que el lenguaje puede estar estructurado de varias formas:

• Diagrama de clases
• Diagrama de objetos
• Diagrama de componentes
• Diagrama de estructura compuesta
• Diagrama de paquetes
• Diagrama de despliegue

Nosotros emplearemos diagramas de clases.

Elementos básicos de lenguaje

Los diagramas de clases son los más utilizados. Describen los tipos de objetos en el sistema y las distintas relaciones estáticas que existen entre ellos:

• Ejemplo de asociaciones: Un cliente puede alquilar un número de vídeos
• Ejemplo de subtipos: Una enfermera es un tipo de empleado

También los atributos y operaciones de una clase y ciertas restricciones que se aplican al modo en que se conectan los objetos como por ejemplo: la navegabilidad, la cardinalidad...

Según Martin Fowler, podemos distinguir las siguientes perspectivas:

• Conceptual: se dibujan diagramas que representan los conceptos del dominio.
• Especificación: atendemos a las interfaces del software y no a su implementación.
• Implementación: atendemos a las propias clases.

La diferencia entre las dos perspectivas software (de especificación y de implementación) era tan sutil que Fowler decidió juntarlas en una sola: la perspectiva de software (aunque normalmente deberemos seguir es forzándonos por enfatizar las interfaces de los objetos más que los detalles de implementación).

En el ejemplo vemos tenemos varios elementos:

Entidades o clases

Las entidades o clases que son los rectángulos: Order, Customer, OrderLine y Producto.

Asociaciones

Las asociaciones son las lineas que los unen. Representan las relaciones entre las clases. Tenemos que tener claros los conceptos de multiplicidad y navegabilidad.

• Multiplicidad: situada en los extremos de una relación representa cuantos objetos de esa clase pueden participar en dicha relación. Multiplicidades comunes: 1, * (muchos o, lo que es lo mismo, 0..n) y 0..1.

• Navegabilidad: es en un modelo de especificación, que un pedido tiene la responsabilidad de conocer qué cliente lo ha hecho, pero no a la inversa. La podemos ver en el siguiente ejemplo:

En el ejemplo anterior Order mantiene una referencia a un objeto de tipo Customer, pero éste no guarda una colección de referencias a objetos Order.

Dependencias

Se dice que existe relación de dependencia entre dos elementos si cambios en la definición de uno de ellos pueden causar cambios en el otro (el cliente). Son una relación más vaga que una asociación. Una dependencia no implica asociación, pero al revés sí.

El diagrama también nos aporta otra información importante:

1. La dependencia es sólo en una dirección y va de la clase de presentación a la de dominio. Eso significa que podemos cambiar libremente la clase BenefitsWindow sin que afecte al empleado o a otros objetos del dominio (lo cual es normalmente una valiosa regla de diseño: que la presentación dependa del dominio, y no a la inversa).
2. No hay dependencias directas entre la clase BenefitsWindow y las dos clases DataGateway: si éstas cambian, probablemente tenga que cambiar la clase Employee. Pero, mientras esos cambios se refieran sólo a su implementación, no a la interfaz, los cambios se detienen ahí.

Atributos y métodos

Los elementos están dentro de los rectángulos, en un primer nivel, son los atributos de la propia clase y un segundo nivel los métodos o funciones de la clase. En los atributos y métodos únicamente tenemos que tener claro que: Si es público (+), privado (-) o protegido (#). Lo demás son añadidos que en muchas ocasiones molestas. Con especificar el nivel de acceso, el nombre y el tipo es suficiente. Todo esto depende del lenguaje.

En Java, la clase OrderLine podría quedar así:

public class OrderLine {    private int quantity;    private Money price;    private Order order;    private Product product;    // getters y setters}

En C#, que tiene la noción de propiedades, se correspondería con:

 public class OrderLine {    public int quantity { get; set; }    public Money price { get; set; }    public Order order { get; set; }    public Product product { get; set; } }

Interfaces y clases abstractas

Hasta ahora solo habíamos hablado de clases "normales". La especificación de una interfaz o una clase abstracta la podemos ver en la siguiente imagen. Es importante observar como en la imagen también observamos como podemos representar la implementación (que una clase implemente una interfaz) y la extensión (que una clase herede de otra clase sea o no abstracta).

Para terminar tenemos que tener claro que la finalidad de la notación UML es que nos entiendan y por eso es fundamental que el desarrollo de los proyectos siempre que nos comuniquemos lo hagamos mediante un diagrama no mediante el propio código.

Bibliografía consultada: UML Distilled de Martin Fowler.

Este artículo sugiere de forma objetiva e independiente productos y servicios que pueden ser de interés para los lectores. Cuando el usuario realiza una compra a través de los enlaces específicos que aparecen en esta noticia, Urban Tecno percibe una comisión. Únete al canal de chollos de Urban Tecno para enterarte de las mejores ofertas antes que nadie.