Reconociendo los Diagramas: Buen comportamiento con diagramas de secuencia

Una de las principales preguntas al analizar y diseñar software con UML es ¿cómo se hace o reconoce un buen diagrama? Conocer la notación es apenas el inicio del camino, la mejor analogía la encontramos en la literatura, saber leer y escribir no garantiza que podamos escribir obras como Shakespeare o Quevedo, de la misma forma el conocer UML no garantiza que tengamos la capacidad de hacer un buen análisis o diseño. En otros artículos se han mostrado las reglas básicas para elaborar un diagrama de secuencia, en esta ocasión nos ocuparemos de los principios mínimos para hacer el diseño de un caso de uso en un diagrama de secuencia de UML.

Intención del diagrama de secuencia

El diagrama de secuencia nos permite diseñar el comportamiento del software. Sirve, entre otras cosas, para diseñar casos de uso, generalmente se hace al menos uno por cada caso de uso, se diseña tomando en cuenta los resultados del análisis, por lo que los artefactos que se necesitan para elaborarlo son los mostrados en la figura 1.

Figura 1. Entradas y salidas del diseño de un caso de uso.

El diagrama de secuencia es un diagrama de comportamiento y modela lo que sucede internamente en el software cuando, por ejemplo, los usuarios aprietan botones y teclas, ahí debemos definir con qué objetos de frontera (GUI, servicios web, etcétera) interactúa el actor y qué objetos de negocio se ven involucrados para atender los eventos generados, todo esto apegado al guión especificado en el texto del análisis.

Este tipo de diagrama puede verse como una traducción del texto del análisis en términos de objetos y métodos con todas las consideraciones técnicas de la arquitectura.

Hacer un buen diseño no es cuestión de complejidad, es decir, el mejor diagrama de secuencia no es el que tenga más objetos y mensajes, pero hay tres principios básicos que debe cumplir un buen diagrama de secuencia:

1. Identificar a los objetos involucrados.
2. Definir la responsabilidad de cada objeto.
3. Mostrar el ciclo de vida de cada objeto.

El diagrama de secuencia modela el comportamiento de un caso de uso desde la perspectiva del diseño, por lo que el comportamiento de una aplicación de escritorio para 25 usuarios es distinto al de una aplicación web para 700 usuarios, esta particular interacción entre los objetos de la aplicación debe quedar plasmada en el diagrama aplicando los principios mencionados.

Identificar a los objetos involucrados

La primera parte de traducir el texto del análisis a objetos y métodos consiste en identificar qué objetos están involucrados, el texto del análisis menciona normalmente sólo a los objetos de negocio; mismos que posiblemente tengamos ya incluidos en el modelo conceptual. Es responsabilidad del diseñador identificar e incluir el resto de los objetos que participan en el caso de uso y que no son de negocio, como ventanas, formas, servicios web, persistencia, seguridad, etcétera.

Tampoco se trata de modelar todos y cada uno de los objetos, solo los más importantes para la ejecución del caso de uso, no tiene sentido modelar una y otra vez en cada caso de uso cuáles son los objetos involucrados en las tareas repetitivas como esta, pueden omitirse por un sentido práctico.

Una parte importante de la identificación de los objetos consiste en nombrarlos y asignarlos a la clase a la que pertenecen, esto evita que los programadores dupliquen objetos y clases que ya existen.

La identificación de los objetos involucrados usualmente se hace en paralelo con la asignación de responsabilidades de cada objeto, el cual es el siguiente punto.

Definir la responsabilidad decada objeto

Este es el aspecto más importante de un diagrama de secuencia, la mejor forma de asignarle responsabilidad a un objeto es usando los Patrones de Diseño y los Patrones Generales de Asignación de Responsabilidades (GRASP por sus siglas en inglés). Pero, otro aspecto importante que no abarcan los sistemas de patrones anteriores, es lo que tiene que ver con el negocio del sistema que se diseña. En el caso de uso Prestar Libro, ¿qué objetos de negocio están involucrados?, ¿cuántas ventanas se necesitan?, ¿cuáles son los objetos de persistencia necesarios?, ¿qué objeto lleva el control del CU? Estas preguntas se deben resolver al diseñar cada caso de uso.

Una de las técnicas más utilizadas para definir las responsabilidades de los objetos es clasificar cada objeto de acuerdo al patrón Modelo-Vista-Control (MVC) como frontera, control o entidad.

Los objetos de frontera son los que interactúan con el actor, mostrando información o recibiendo peticiones. Estos objetos representan ventanas, páginas web y servicios web entre otros.

Los objetos de control son los que reciben mensajes de los objetos frontera y deciden qué curso de acciones tomar, enviando mensaje a todos los objetos involucrados en atender la petición del usuario. En una de las variantes del patrón MVC se modela un objeto de control para cada caso de uso, el cual tiene los pasos necesarios para ejecutarlo.

Los objetos entidad son los que ya se han identificado como clases en el modelo conceptual, aunque se podrían identificar nuevos conceptos de negocio en el diseño. También se pueden modelar los objetos de una capa de persistencia como objetos entidad.

Figura 2. Estereotipos visuales para frontera, control y entidad.

En los objetos de negocio es donde el diseñador debe aplicar su pericia para definir la responsabilidad de cada objeto, por ejemplo, si hay que validar que una credencial esté vigente, no es responsabilidad del objeto ventana, si no de un objeto credencial, verificar que el lector no tenga más de tres préstamos vigentes y ninguna multa sin pagar, lo debe hacer el objeto lector y no la ventana de préstamos. Estas responsabilidades las podemos ver en la figura 3.

Figura 3. Responsabilidad de los objetos

Para definir las responsabilidades en un diagrama de secuencia se deben identificar que objetos de frontera intercambian mensajes con el actor y que objetos de control solicitan a los objetos de entidad ejecutar las operaciones de negocio necesarias para realizar el caso de uso.

Mostrar el ciclo de vida de cada objeto

Saber qué objetos ya existen y cuáles son los que deben crearse durante la ejecución de un caso de uso es importante para evitar que en cada caso de uso se reserve memoria a diestra y siniestra y se dupliquen objetos haciendo viajes innecesarios a la Base de Datos. En un diagrama de secuencia debe modelarse con mensajes de creación (- - - >) en qué momento se necesita crear un objeto, al encontrar  una X en la línea de vida de un objeto, sabemos que es elegible para recolección de basura.

Los objetos que no reciben un mensaje de creación se asume que ya existen antes de comenzar el caso de uso y el símbolo del objeto está hasta arriba en el diagrama de secuencias, como puede observarse en la figura 4.

Figura 4. Símbolo del objeto.

Ventajas de diseñar con un diagrama de secuencia

Elaborar un diagrama de secuencia para cada caso de uso representa un esfuerzo importante dentro del proyecto, pero nos permite detectar comportamiento común en varios casos de uso, identificando tempranamente a los objetos y clases reutilizables al modelar y no cuando estamos programando, por ejemplo, si únicamente diseñamos con un diagrama de clases, corremos el riesgo de que cuando estemos programando el caso de uso Pagar Multa y nos demos cuenta de que el objeto credencial se comporta similar en el caso de uso Prestar Libro, tengamos que hacer refactoring sobre el código de ambos casos de uso, y definitivamente es más rápido y barato modificar diagramas que código.

Otra ventaja está en la posibilidad de desarrollar una arquitectura consistente para todo el sistema. Si sólo diseñamos utilizando diagramas de clases, cada programador puede codificar sus casos de uso con un estilo muy particular y distinto al de los demás, que dependerá más de la calidad de la especificación del caso de uso y la habilidad de cada programador.

Pero, como le solemos explicar a nuestros alumnos en nuestros cursos, la proporción de casos de uso a los cuales conviene diseñarles sus diagramas de secuencia depende de la situación del proyecto y sus tiempos. Debido a que en la mayoría de los casos no contamos con tantos recursos ni tiempo como para poder desarrollarlos todos.

Conclusión

Un buen diagrama de secuencia debe dejar claro cuáles son los objetos involucrados, cómo colaboran dichos objetos para realizar el caso de uso, y qué objetos se crean durante el caso de uso y cuáles existían previamente.

No es necesario indicar el algoritmo para validar el número de una credencial o la sintaxis de una dirección de email, eso le corresponde al programador, pero si es imprescindible indicar qué objeto es el responsable de validar y además a qué clase pertenece. 

No olvides que, siempre que te sea posible, es sano apoyarte en gente con mayor experiencia en las buenas prácticas. Al final tu usuario te lo agradecerá al beneficiarse con la calidad de tus sistemas.