UML II: la venganza de los diagramas

En el post anterior inicié una exploración a través del Lenguaje de Modelado Unificado (UML por sus siglas en inglés). Quizá abruptamente inicié la controversial discusión si utilizar o no usar UML y porqué. Además, exploramos algunos de los diagramas más utilizados en la industria.

UML posee 19 diagramas distintos, con los que cubre la mayoría de necesidades de modelado de software. En la práctica, se dice que el 80% por ciento de las necesidades de los proyectos se cubren con los diagramas más comunes ( descritos aqui ). El día de hoy echaremos un vistazo a diagramas que, si bien no son los más comunes, su aprovechamiento es esencial para el diseño de sistemas.

Antes de comenzar, haré un breve paréntesis, para indicar las clases de diagramas UML.

Clasificación de diagramas

UML posee dos categorías de diagramas: Los diagramas estructurales y los diagramas de comportamiento.

Digamos que, los diagramas estructurales presentan un panorama estático del sistema, su composición, como está construido. Los diagramas de comportamiento ofrecen un panorama dinámico, es decir, presenta la evolución e interacción de los subsistemas entre sí ( a veces me pongo como ejercicio mental construir definiciones con lo que previamente sé sobre un tema. En esta ocasión, se halla muy acercada a lo que hallé en este blog).

Diagramas de estado

Los diagramas de estado pertenecen a los diagramas de comportamiento. Se utilizan para modelar el comportamiento discreto de un sistema a través de transiciones de estados finitos. Son muy útiles para simplificar complicados comportamientos.
Estos diagramas permiten que podamos visualizar el comportamiento del sistema como conjunto, representado en forma de grafo.
Los vértices (nodos) representan estados o pseudoestados del sistema. Un estado modela una situación en la cual un conjunto de condiciones permanecen invariantes a lo largo del tiempo. Durante este periodo de tiempo, el sistema se mantiene continuamente realizando la misma actividad. Cuando las condiciones cambian, se produce una transición de estado.
Las aristas (flechas) direccionadas representan transiciones. Las transiciones son cambios entre estados. Para que exista una transición, suele ocurrir una actividad en el exterior que dispare este cambio. En las transiciones de estados pueden ocurrir decisiones que dirijan a estados distintos, bifurcaciones o uniones de estados.

Los diagramas de estados describen detalladamente la vida y evolución de un objeto. Todos conocemos la idea del ser humano como autómata: Naces, creces, te reproduces y mueres.

Diagramas de paquetes

Los diagramas de paquetes muestran la estructura de un sistema en un nivel de abstracción muy general. Los paquetes se representan como carpetas que contienen todas las dependencias necesarias para poder funcionar dicho componente. Un paquete reúne un conjunto de elementos que comparten elementos semánticos. La clave de estos diagramas es la agrupación. Los paquetes recogen las clases que comprenden un subsistema como conjunto.

Las clases que comparten misma composición, herencia o utilizan una gran cantidad de datos comunes, suelen pertenecer al mismo paquete.

El diagrama de paquetes sigue la estructura jerárquica de los paquetes anidados. Los módulos atómicos para paquetes anidados suelen ser diagramas de clases. Existen pocas restricciones al usar diagramas de paquetes, son las siguientes.

• El nombre del paquete no debe ser el mismo para un sistema, sin embargo, las clases dentro de diferentes paquetes podrían tener el mismo nombre.
• Los paquetes pueden incluir diagramas completos, nombres de componentes solos o ningún componente.
• El nombre completo de un paquete tiene la siguiente sintaxis.

En los diagramas de paquetes, utilizando dibujos y diagramas se condensa mucha información: Acceso, visibilidad e importación de clases.

( Hallé muy útiles estos dos artículos para tener una comprensión general de este tipo de diagramas: busca aquí o aquí ).

Diagramas de componentes

Hace un par de años, un buen amigo comenzó a trabajar en una prestigiosa empresa de software, aquí en México. Yo aún no comenzaba a estudiar CS (y ni siquiera lo tenía contemplado). Mientras tanto, mi buen amigo me contaba que su trabajo consistía en crear sistemas basados en componentes, dichos componentes se encargaban de realizar tareas bastante específicas, de tal forma que existiera relaciones débiles entre servicios. En ese entonces, poco entendí y posiblemente quedé con una cara de intriga.

Hoy por hoy, puedo al menos decir que, para el modelado de este tipo de sistemas podemos aplicar los diagramas de componentes de UML. En estos diagramas se pretende mostrar la relación y estructura de un sistema basado en componentes.

Hasta donde comprendo, un componente puede llamarse como tal, cuando es una entidad bien definida, realiza tareas específicas y es posible sustituirlo de forma modular.

Para explicar más a fondo el diagrama como tal, sé que necesito mayor conocimiento en SOA. De cualquier forma, lo que he entendido hasta ahora ha sido gracias a este post y, como se va haciendo costumbre con UML, con las notas de IBM al respecto.

Sumario UML

Durante mis 6 años como entrenador de la selección jaliscience de física, aprendí algo muy importante:

Si puedes imaginar el problema, tienes la mitad del camino para resolverlo. Si puedes imaginar el sistema, sus subsistemas y como esperas que se comporte, podrás modelar las ecuaciones pertinentes que describan el movimiento de los objetos implicados. Es por ello que es tan importante realizar dibujos y diagramas de las interacciones que sufre el objeto a analizar, la física sale sola, si imaginaste bien el sistema.

Trasladando estas ideas al desarrollo de software puedo decir que:

Si puedes imaginar el problema, tienes la mitad del camino para implementar una solución. Si puedes imaginar el sistema , sus subsistemas y como esperas que se comporte, podrás modelar la estructura de tu sistema pertinente que describa el interacción de los objetos implicados. Es por ello que es tan importante realizar dibujos y diagramas de las interacciones y relaciones que sufren los subsistemas a analizar, la implementación se produce de forma automática, si imaginaste bien el sistema.

Para realizar diagramas ( de fuerzas, torques, campos etc) en física, existen un conjunto de convenciones bien conocidas. Estas convenciones hacen que los diagramas sean universales. En software, tenemos UML.

Si realizas un buen modelado de tu sistema, la implementación será intuitiva.

O al menos, esa es mi creencia.