UML

UML (Lenguaje de Modelado Unificado) es un conjunto de diagramas que ayudan a describir/diseñar sistemas de software orientados a objetos.

Tradicionalmente, el modelado se realiza antes de escribir el código fuente. Las metodologías actuales rechazan el modelado completo del software, basado en el ciclo de vida en cascada. UML surgió en este contexto. Sin embargo, UML puede utilizarse también como herramienta de modelado de partes del software, y así escoger las arquitecturas más adecuadas.

En definitiva UML es una herramienta para facilitar la documentación y descripción de un proyecto.

UML y las metodologías ágiles

En las metodologías ágiles, los requisitos de un sistema suelen cambiar continuamente, por lo que la documentación exhaustiva desde un principio no es una opción. Lo normal en este caso es que los diagramas UML surjan en pizarras durante las reuniones de análisis, diseño o implementación. Estos diagramas pueden ser desechados o modificados conforme el proyecto va avanzando. Sólo un diagrama que aparece frecuentemente debe ser añadido a la documentación.

UML

Existen diferentes versiones de UML. UML 1.x incluye diagramas de estructura y diagramas de comportamiento. Los primeros describien componentes del sistema y su relación, mientras que los segundos muestran cómo actúal el sistema a lo largo del tiempo.

UML 2.x por su parte es una revisión de el estándar 1.x que data de 2007. En esta versión, se incluyen 13 tipos de diagramas, agrupados en diagramas de estructura, diagramas de comportamiento y diagramas de interacción:

  • Diagramas de Estrucutra
    • Diagrama de clases
    • Diagrama de componentes
    • Diagrama de composición de estructuras (nuevo en UML 2)
    • Diagrama de despliegue
    • Diagrama de objetos (nuevo en UML 2)
    • Diagrama de paquetes (nuevo en UML 2)
  • Diagramas de Comportamiento
    • Diagrama de actividad
    • Diagrama de casos de uso
    • Diagrama de estados
  • Diagramas de interacción (nuevo en UML 2) - Subcategoría de Diagramas de Comportamiento -
    • Diagrama de secuencia
    • Diagrama de comunicación
    • Diagrama de temporización

Diagrama de clases

Un diagrama de clases es un diagrama estructural. Describen los componentes del sistema y sus relaciones. Muestran las clases que componen el sistema y sus relaciones con otras clases.

Diagrama de clases de un juego.

En el diagrama de una clase se puede ver:

  • Nombre de la clase
  • Atributos y su tipo y su valor por defecto
  • Métodos, su firma y su tipo
  • Visibilidad

Sobre la visibilidad, existe la siguiente notación

  • +: pública
  • #: protegida
  • -: privada
  • ~ o vacío: paquete

Los estereotipos son un mecanismo que permite extender UML dando cierta información extra sobre el diagrama. Por ejemplo, podríamos estar interesados en expresar que:

  • Una clase es una colección de métodos estáticos. Se expresa con el estereotipo <<Utility>>
  • Una clase es estática. Se expresa con el estereotipo <<Utility>>
  • Un método es un constructor. Se expresa con el estereotipo <<Create>>

Un estereotipo se puede usar para clasificar el comportamiento de una clase o un método, indicando, por ejemplo, que un método es un constructor (<<create>>) y que otro es un getter (<<getter>>).

En ocasiones podemos observar la etiqueta <<interface>>, que puede parecer un estereotipo, pero en realidad es un clasificador. Un clasificador permite mostrar interfaces, clases, tipos de datos y componentes.

Actividad 1. Partiendo del proyecto calculadoraTDD, modela (utilizando algún programa de modelado) las clases correspondientes a modelo/Operador.php y modelo/OperadorBinario.php

Entrega la actividad en un archivo llamado Act1-uml.png

Relaciones entre clases

En un diagrama de clases se pueden mostrar relaciones entre clases en los que unos métodos llamarán a los métodos de otras clases. Por ello, un método de una clase A que llama a un método de una clase B debe contener una referencia de B. Esta referencia se puede representar de diferentes maneras:

  • Asociación
  • Agregación
  • Composicón
  • Dependencia

Además se pueden reflejar relaciones de herencia y de implementación (interfaces):

  • Generalización (herencia)
  • Realización (implementación de interfaces)

Asociación

Si hay una asociación entre la clase A y la clase B, significa que en la clase A hay un atributo de tipo B y/o viceversa. Además se suelen indicar los roles y la multiplicidad.

Asociación entre clases.

En ocasiones la navegabilidad es bidireccional y otras es unidireccional (lo que se expresa mediante una flecha).

Asociación unidireccional. OverdrawnAccountsReport sabe de la existencia de BankAccount, pero no al revés.

Obsérvese que no se especifica el atributo de la asociación. Para eso está el diagrama.

Las multiplicidades se expresan del siguiente modo:

  • 1..1: exactamente una instancia
  • 1: equivalente a 1..1
  • 0..*: número indefinido de veces
  • 2..3: entre 2 y tres instancias

Agregación y composición

La agregación y la composición muestran asociaciones que representan una relación entre un todo y sus partes. Por ejemplo, un coche tiene ruedas. También es cierto que una compañía se compone de departamentos.

La diferencia entre ambas relaciones es que una agregación describe una relación que indica que una clase es parte de otra, pero que puede existir independientemente de la primera. Por ejemplo, una rueda puede existir de manera independiente al coche.

Relación de agregación

En la composición, sin embargo, la clase hija no tiene sentido sin la existencia de la clase padre.

Relación de composición

Generalización

La generalización recoge el mecanismo de herencia de los lenguajes orientados a objetos.

Generalización

Cuando una clase es abstracta (contiene algún método abstracto), las clases herederas no tienen que volver a mostrar el método implementado. Las clases y los métodos abstractos se representan en cursiva

Herencia de métodos abstractos. El método getPerimeter es abstracto.

Interfaces y realización

Una interfaz es una clase abstracta pura. Su implementación (realización se representa del siguiente modo):

Player es una interfaz implementada por DVDPlayer, CDPlayer y Recorder (que es a su vez otra interfaz).

Es importante recordar que una clase puede implementar varias interfaces, mientras que solo puede heredar de una.

Dependencia

Una dependencia es una relación semántica entre dos clases, pero que no se ajusta a ninguna de las anteriores. Suele hacer referencia a una clase que utiliza brevemente a otra (llamando a uno de sus métodos). En el ejemplo siguiente, Mapa no almacena en ningún momento un objeto de clase Coordenadas, y sólo lo utiliza durante las conversiones de dirección a coordenadas y viceversa

Mapa utiliza "brevemente" las coordenadas.

Actividad 2. Analiza la relación entre las clases del proyecto calculadoraTDD y realiza un diagrama de clases con su estructura.

Entrega la actividad en un archivo llamado Act2-uml.png

Diagrama de actividad

Un diagrama de actividad permite comprobar el flujo de acciones paso a paso, permitiendo expresar condiciones, iteraciones y concurrencia. Los elementos gráficos de un diagrama de actividad son:

Elementos en un diagrama de actividad

El siguiente es un ejemplo del libro UML Práctico.

Diagrama que muestre el funcionamiento de una máquina de café.

Cuando hay una toma de desión en un punto de control, se indican las condiciones entre corchetes (en el ejemplo, las condiciones son café, capuchino y cortado

Otro ejemplo:

Diagrama de actividad.

Los diagramas de actividad pueden seccionarse en particiones para mejorar la comprensión sobre la responsabilidad de las acciones del modelo. Por ejemplo:

Las particiones indican la responsabilidad de cada conjunto de actividades.

Actividad 3. Realizar un diagrama de actividad que muestre el proceso de devolución de un artículo por parte de un cliente. Cuando el cliente solicita una devolución, el departamento de ventas por Internet se encargará de darle un código de devolución. Una vez obtenido, el cliente envía el artículo defectuoso por mensajería, adjuntando dicho código. El almacén es entonces el encargado de la recepción de la mercancía y de la recolocación del artículo. Al mismo tiempo que se recoloca, el departamento de contabilidad actualiza las cuentas. Después de realizarse ambas tareas, el departamento de contabilidad realiza el ingreso a favor del cliente.

Para el ejercicio, debes utilizar particiones.

Entrega la actividad en un archivo llamado Act3-uml.png

Diagramas de estados

Diagramas que modelan los diferentes estados en que puede estar un sistema. Los diferentes estímulos, puden hacer que el sistema cambie de estado, y ante las mismas entradas producirse diferentes respuestas. A este sistema, lo llamamos máquina de estados. Las características principales de una máquina de estados es la siguiente:

  • Una máquina de estados sólo puede estar en un estado a la vez
  • Para un mismo estado y un mismo conjunto de estímulos, la máquina siempre debe comportarse igual

Son útiles para modelar la vida de un objeto. El diagrama de estados muestra las secuencias de estados por las que pasa un objeto a lo largo de su vida en respuesta a eventos, junto con sus respuestas a esos eventos.

Los elementos que forman parte de un diagrama de estados son:

Elementos que forman parte de un diagrama de estados

El siguiente es un ejemplo:

Otro ejemplo de diagrama de estados

Actividad 4. Para entrar en un centro de datos hay una puerta con dos sistemas de seguridad: uno biométrico que consiste en el reconocimiento de la palma de la mano, y un teclado donde el operador debe introducir su PIN. Inicialmente la pantalla indica que se debe introducir el PIN (números de 0 a 9), seguido de la tecla "Intro".

  • Si el PIN es válido, la pantalla pedirá apoyar la mano en el detector
  • Si la mano también es correcta, se abrirá la cerradura
  • Cuando el usuario cierra la puerta, ésta se volverá a bloquear
  • También se bloqueará si el usuario no abre la puerta en 10 segundos
  • Si se abre la puerta pero no se cierra en 10 segundos, sonará una alarma que sólo se detendrá cuando se vuelva a cerrar la puerta

En caso de fallar alguna de las dos verificaciones habrá que empezar el proceso de identificación de nuevo

Entrega la actividad en un archivo llamado Act4-uml.png

Diagramas de secuencia

Un diagrama de secuencia expresa qué objetos se relacionan con qué objetos, enfatizando el orden en que lo hacen y qué tipo de mensajes se envían entre sí. Los elementos que pueden intervenir en un diagrama de secuencia son los siguientes:

Elementos que intervienen en los diagramas de secuencia

Es importante tener en cuenta los siguientes consejos:

  • Sólo representa secuencias de mensajes (no intervalos precisos).
  • No hay que incluir todos los métodos de todos los objetos del diagrama. Sólo aquellos que sean de nuestro interés en un momento dado.
  • Cuando más complicado sea, menos útil será.
Diagrama de secuencia de un sistema de publicidad robotizada, que lee la propaganda y después cuelga.

Actividad 5. Modelar el diagrama de secuencia seguido por tu aplicación web de conversión de unidades.

Entrega la actividad en un archivo llamado Act5-uml.png

Diagrama de colaboración

Son similares a los diagramas de secuencia, pero cambian su representación. Aunque contiene la misma información, su disposición permite incluir más elementos. Las siguientes imágenes muestran dos diagramas equivalentes.

Diagrama de colaboración de una lavadora. El diagrama es equivalente al siguiente.
Diagrama de secuencia de una lavadora. El diagrama es equivalente al anterior.

Diagramas de casos de uso

Los daigramas de casos de uso describen lo que debe hacer un sistema desde el punto de vista de quien lo va a utilizar. Un caso de uso captura algunas de las acciones y comportamientos del sistema y cómo los actores interactúan con él.

Diagramas de casos de uso.

En el diagrama anterior aparece el estereotipo <<extend>>, que indica que un caso de uso aporta cierto comportamiento adicional en determinadas circunstancias o cuando se cumple cierta condición. Otro ejemplo:

Extensión de un caso de uso

También podemos encontrar los estereotipos <<include>> o <<use>> indicando que un caso de uso se incluye dentro del comportamiento de otro. Por ejemplo:

Inclusión de casos de uso.

Por último podemos encontrar generalizaciones, que se utilizan para expresar que un caso de uso especializado es una forma particular de otro caso de uso más general. Por ejemplo:

Generalización de casos de uso.

Los casos de uso no deben reflejar el funcionamiento del sistema completo. Sólamente las interacciones más importantes.

Actividad 6. Realiza un diagrama de casos de uso que describa el funcionamiento de tu aplicación de conversión de unidades.

Entrega la actividad en un archivo llamado Act6-uml.png