Trabajando en equipo. Diagramas de interacción.

Trabajar de forma aislada podría dar resultados solamente en ciertos contextos, pues para quien pretende alcanzar grandes objetivos probablemente la única forma de lograrlo sea colaborando con otras personas; es decir, trabajando en equipo. En cualquier proceso no trivial, encontramos que son diversas áreas o roles las que colaboran para lograr un objetivo común.

El Mundo de los Negocios Trasladado al Software
En un proceso de negocio nos podemos encontrar que un cliente interactúa con un vendedor y el vendedor interactúa con el área de producción para realizar un proceso de venta. De la misma manera, en un sistema de software podemos encontrar a un objeto llamado “cliente” interactuando con otro llamado “ventas” para realizar la funcionalidad correspondiente a una venta.

Como sabemos, en el paradigma de orientación a objetos se busca representar los elementos del mundo real (ya sea físicos o abstractos), como objetos de un sistema de software. Estos objetos, que cuentan con diversas características (ver Fundamentos, SG Año 1 No. 6), normalmente no van a funcionar en el sistema de manera aislada, sino que requieren interactuar con otros objetos para cumplir la funcionalidad requerida en el sistema.

Modelando la Colaboración
UML define un tipo de diagramas cuyo objetivo es expresar las interacciones que se dan entre los objetos para cumplir los requerimientos del sistema, e incluso las interacciones de elementos del mundo real (ej. Roles o áreas) para llevar a cabo procesos de negocio. Estos diagramas se conocen como diagramas de interacción.

Existen dos tipos específicos de diagramas de interacción: los diagramas de secuencia y los diagramas de comunicación (antes conocidos como diagramas de colaboración). Aunque estos dos diagramas modelan la misma información (interacciones), ambos lo hacen desde una perspectiva diferente. El diagrama de secuencia facilita la visualización del orden en el que se llevan a cabo las operaciones, mientras que el diagrama de comunicación facilita ver qué objetos se comunican entre sí. Por ello se justifica la existencia de ambos.

Estos diagramas no sólo sirven para modelar interacciones entre objetos de software. También son una herramienta muy útil para modelar procesos de negocio, ya que permiten representar la interacción que se da entre los diferentes roles que ejecutan un proceso de negocio.

Ejemplo Básico de Interacción entre Dos Objetos
Cuando un comprador le solicita a un vendedor que le venda un producto, ambos están interactuando. Cuando el vendedor le solicita al comprador que liquide la venta, están teniendo otra interacción. También son interacciones, cuando el comprador le pide al vendedor que cobre la venta y el último le entrega los productos adquiridos al primero. Las interacciones son peticiones o mensajes intercambiados entre los objetos o elementos que colaboran.

Ayúdame que Yo te Ayudaré
Ok, tal vez la frase original no sea como este título, pero es una realidad en los procesos colaborativos. En estos, los objetos se piden ayuda para lograr un objetivo común. El mensaje es el mecanismo mediante el cual dos objetos interactúan en los diagramas de interacción (aplica para los dos tipos de diagramas de interacción, tanto para el de secuencia como para el de comunicación). El mensaje es la forma en que un objeto ayuda a otro a continuar con el trabajo requerido.

Los mensajes se representan mediante flechas que van de un objeto a otro. El objeto emisor del mensaje (de donde sale la flecha) le está solicitando al objeto receptor (a donde llega la flecha) que le ayude proporcionándole cierto servicio, es decir, podemos hablar de una relación cliente-servidor entre dos objetos.

Un Gran Poder Implica una Gran Responsabilidad
En una relación cliente-servidor, el objeto emisor es el cliente y el receptor del mensaje es el servidor. El receptor del mensaje tiene el “poder” de ayudar al emisor, pero esto también significa que el receptor tiene la “responsabilidad” de atender o procesar la petición.

Uno de los aspectos clave en el paradigma orientado a objetos consiste en realizar una adecuada asignación de responsabilidades a los objetos que colaboran en la realización de los procesos. Supongamos que vamos a una tienda a adquirir un producto y, en repetidos intentos, le solicitamos amablemente al vendedor que nos venda lo que queremos, pero este último nos ignora; llegará un momento en el que nuestra paciencia se agote y, en una forma menos amable, le exijamos al irresponsable vendedor que nos atienda. Bajo este escenario los dos objetos que interactúan, nosotros como compradores y la otra persona como vendedor, tenemos asignadas ciertas responsabilidades y quien recibe la petición debe ser el responsable de resolverla.

La figura 1 muestra al comprador interactuando con el vendedor y éste a su vez con el almacenista en un diagrama de secuencia. En el primer y el cuarto mensaje, el comprador es el emisor y por tanto juega el rol de cliente, mientras que el vendedor se desempeña como el servidor. En el tercer mensaje los papeles se invierten, siendo el vendedor el cliente y el comprador el servidor.

diagrama de secuencia

Figura 1. Diagrama de secuencia

En cuanto a las responsabilidades, el diagrama de secuencia nos indica que el comprador es responsable de liquidar la venta mientras que el vendedor es responsable de atender la venta y de aplicar el pago a la misma, de igual manera, el almacenista es responsable de entregar los productos del almacén.

Pedir Por Favor o Dar una Orden
Nótese cómo las descripciones de los mensajes no están indicando la tarea que realiza el emisor del mensaje, sino la solicitud (u orden) que éste le está haciendo al receptor.

Cuando se modela una colaboración de objetos es muy importante no confundir los eventos con las responsabilidades. De hacerlo así, podríamos llegar a modelos poco apropiados como el que se muestra en la figura 2.

Diagrama de secuencia incorrecto

Figura 2. Diagrama de secuencia incorrecto

Este diagrama nos da la noción de los pasos que se tienen que realizar para adquirir los productos, pero definitivamente no refleja las responsabilidades reales de los objetos al recibir los mensajes. Por ejemplo, da a entender que “pagar la venta” es responsabilidad del vendedor.

Nos ha dado excelentes resultados, en las prácticas realizadas con nuestros alumnos, recomendarles que los diagramas de interacción usen una conversación imperativa en los mensajes, es decir ... a veces no hay que pedir, ¡hay que dar órdenes!, pues es su responsabilidad.

Pasando del Análisis al Diseño
Los diagramas de interacción permiten cubrir la brecha natural que existe entre el análisis y el diseño. De hecho, son la clave para evolucionar el modelo de clases derivado del análisis (Modelo Conceptual) hacia uno enfocado en el diseño.

En el próximo artículo de esta serie veremos como obtener las operaciones de las diferentes clases, a partir de los mensajes que enviamos a los objetos en los diagramas de interacción.

Acerca del autor
Sergio Orozco es Director General e Instructor Senior certificado por la OMG en Milestone Consulting. Carlos Macías es Arquitecto en Jefe e Instructor Senior en Milestone Consulting, primer empresa mexicana miembro de la OMG, especializada en la capacitación práctica y consultoría en UML, CMM y orientación a objetos. www.milestone.com.mx, info@milestone.com.mx