Diagramas UML: Clases, Objetos, Casos de Uso, Estados, Componentes, Secuencia y Actividades

Diagrama de clases

Un diagrama de clases es un diagrama que muestra un conjunto de clases, interfaces, colaboraciones y sus relaciones. Al igual que otros diagramas, los diagramas de clases pueden contener notas y restricciones. También pueden contener paquetes o subsistemas, que se usan para agrupar los elementos de un modelo en partes más grandes. A veces se colocarán instancias en los diagramas de clases, especialmente cuando se quiera mostrar el tipo (posiblemente dinámico) de una instancia.

Diagrama de objetos

En UML, los diagramas de clases se utilizan para visualizar los aspectos estáticos de los bloques de construcción del sistema. Los diagramas de interacción se utilizan para ver los aspectos dinámicos del sistema y constan de instancias de estos bloques y mensajes enviados entre ellos. Un diagrama de objetos contiene un conjunto de instancias de los elementos encontrados en un diagrama de clases. Por lo tanto, un diagrama de objetos expresa la parte estática de la interacción, consistiendo en los objetos que colaboran pero sin ninguno de los mensajes enviados entre ellos.

Interacciones

En cualquier sistema, los objetos interactúan entre sí pasándose mensajes. Una interacción es un comportamiento que incluye un conjunto de mensajes intercambiados por un conjunto de objetos dentro de un contexto para lograr un propósito.

Diagrama de casos de uso

Muestran un conjunto de casos de uso y actores (tipo especial de clase) y sus relaciones. Cubren la vista estática de los casos de uso y son especialmente importantes para el modelado y organización del comportamiento.

Diagrama de estados

Muestran una máquina de estados compuesta por estados, transiciones, eventos y actividades. Estos diagramas cubren la vista dinámica de un sistema y son muy importantes a la hora de modelar el comportamiento de una interfaz, clase o colaboración.

Diagrama de componentes

Muestra la organización y las dependencias entre un conjunto de componentes. Cubren la vista de la implementación estática y se relacionan con los diagramas de clases, ya que un componente suele tener una o más clases, interfaces o colaboraciones.

Arquitectura

El desarrollo de un sistema con gran cantidad de software requiere que este sea visto desde diferentes perspectivas. Distintos usuarios (usuario final, analistas, desarrolladores, integradores, jefes de proyecto...) siguen distintas actividades en distintos momentos del ciclo de vida del proyecto, lo que da lugar a las diferentes vistas del proyecto, dependiendo de qué interesa más en cada instante de tiempo.

La arquitectura es el conjunto de decisiones significativas sobre:

• La organización del sistema.
• La selección de elementos estructurales y sus interfaces a través de los cuales se constituye el sistema.
• El comportamiento, cómo se especifican las colaboraciones entre esos componentes.
• La composición de elementos estructurales y de comportamiento en subsistemas progresivamente más grandes.
• El estilo arquitectónico que guía esta organización: elementos estáticos y dinámicos y sus interfaces, sus colaboraciones y su composición.

Diagrama de secuencia

Un diagrama de secuencia destaca la ordenación temporal de los mensajes. Se forma colocando en primer lugar los objetos que participan en la interacción en la parte superior del diagrama, a lo largo del eje X. Normalmente, se coloca a la izquierda el objeto que inicia la interacción, y los objetos subordinados a la derecha. A continuación, se colocan los mensajes que estos objetos envían y reciben a lo largo del eje Y, en orden de sucesión en el tiempo, desde arriba hasta abajo. Esto ofrece al lector una señal visual clara del flujo de control a lo largo del tiempo.

Diagrama de actividades

Así pues, un diagrama de actividades muestra el flujo de actividades. Una actividad es la ejecución no atómica en curso, dentro de una máquina de estados. Las actividades producen finalmente alguna acción, que está compuesta de computaciones atómicas ejecutables que producen un cambio en el estado del sistema o la devolución de un valor. Las acciones incluyen llamadas a otras operaciones, envío de señales, creación o destrucción de objetos o simples cálculos, como la evaluación de una expresión. Gráficamente, un diagrama de actividades es una colección de nodos y arcos.

Transiciones

Cuando se completa la acción o la actividad de un estado, el flujo de control pasa inmediatamente al siguiente estado de acción o estado de actividad. Este flujo se especifica con transiciones que muestran el camino de un estado de actividad o estado de acción al siguiente. En UML, una transición se representa como una línea dirigida.

Bifurcación

Las transiciones secuenciales son frecuentes, pero no son el único camino que se necesita para modelar un flujo de control. Como en los diagramas de flujo, se puede incluir una bifurcación, que especifica caminos alternativos, según el valor de alguna expresión booleana. La bifurcación se representa con un rombo. La bifurcación puede tener una transición de entrada y 2 o más de salida. En cada transición de salida se coloca la expresión booleana, que se evalúa solo una vez al entrar en la bifurcación. Las guardas de las transiciones de salida no deben solaparse (de otro modo el flujo de control sería ambiguo), pero deberán cubrir todas las posibilidades (de otra manera el flujo de control se vería interrumpido).

División y unión

Las transiciones secuenciales y las bifurcaciones son los caminos más utilizados en los diagramas de actividades. Sin embargo, también es posible encontrar flujos concurrentes, especialmente cuando se modelan flujos de trabajo o procesos de negocio. En UML se utiliza una barra de sincronización para especificar la división y unión de estos flujos de control. La barra de sincronización se representa como una línea horizontal o vertical ancha.