Trabajando en Equipo: Diagramas de Interacción

Trabajar de forma aislada podría dar resultados sólo 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.

Un proceso donde no interactúen por lo menos un par de personas o áreas probablemente sería muy simple. En la mayoría de los procesos importantes nos encontramos con varias áreas o roles que interactúan para lograr el objetivo común.

De la misma forma, el paradigma de la orientación a objetos lleva al análisis y diseño de sistemas el concepto de colaboración para alcanzar más eficientemente los objetivos del mismo. El principal objetivo del sistema se encuentra en satisfacer requerimientos, muchos de los cuales se traducen en funcionalidad. En UML esa funcionalidad está descrita principalmente en casos de uso, escenarios y métodos del sistema a modelar donde un conjunto de objetos interactúan para cumplir con dicha funcionalidad.

El Mundo de los Negocios llevado al Mundo del 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 software orientado a objetos nos podemos encontrar a un objeto llamado cliente interactuando con un objeto venta para realizar la funcionalidad correspondiente a una venta.

La orientación a objetos trata de llevar el mundo que todos conocemos de los objetos reales (físicos o abstractos) al mundo del software en elementos de código que se mapeen de la mejor forma posible a la realidad. Objetos, que además de ser identificados de manera única, de tener sus propias características y un comportamiento asociado, normalmente no van a funcionar en el sistema de manera aislada, sino que interactúan con otros objetos de software para cumplir ciertas funciones del sistema.

Modelando la Colaboración

UML nos presenta un par de artefactos que facilitan 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.

Los artefactos que nos sirven para este fin son los diagramas de interacción, aunque en realidad este nombre se utiliza para una clasificación de diagramas donde se identifican dos tipos de diagramas que cumplen con funciones similares. Estos diagramas son los de secuencia y los de comunicación (El diagrama de comunicación era conocido como diagrama de colaboración en versiones anteriores de UML).

En la notación tradicional de UML las interacciones que se modelan son las que se dan entre objetos de software al ejecutar ciertas funciones del sistema. Pero, esta misma representación se puede utilizar para representar las interacciones entre los elementos del mundo real al ejecutar un proceso de negocio, en las extensiones de UML para modelado 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 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 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 éste ú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 ejecutarla.

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


Figura 1


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, así mismo, 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 muestran en la figura 2.


Figura 2

La figura 2 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 que colaboran en el proceso al recibir los mensajes.

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 al diagrama de clases derivado del análisis (Modelo Conceptual) a uno enfocado en el diseño. Los mensajes, que implican responsabilidades son transformados en operaciones que finalmente definen las responsabilidades de las clases lo cual expondremos en nuestro próximo artículo.


Ver más artículos

Póliza Abiztar Plus

Descubre aquí todos los beneficios de La Póliza Abiztar Plus.

Garantía Universal

Los ambientes ubicuos de aprendizaje Abiztar, incluyen Garantía Universal. ¿Qué es esto?

Información general
Conoce la Póliza Abiztar Plus
Recomendaciones de capacitación
Calendario de cursos

Base de conocimiento
UML y Arquitecturas
Administración de Proyectos
Procesos de Software
Artículos

Contáctanos

Teléfono en México D.F. - +52 (55) 5594 6411 / E-mail: cursos@abiztar.com.mx

O si lo prefieres llena el formulario de contacto

Ver aviso de privacidad

© Abiztar. PMI, PMBOK Guide, OPM3, CAPM, PMP, PMI-SP y PMI-RMP son marcas registradas (en EUA y otos países) del Project Management Institute, Inc. Capability Maturity Model y CMM son marcas registradas en la Oficina de Patentes de los EUA por el Software Engineering Institute (SEI) de la Universidad Carnegie Mellon. CMM, IntegrationSM, IDEALSM y SCAMPISM son marcas de servicio de la Universidad Carnegie Mellon. MDA, BPMN, SysML, MOF, OMG y UML son marcas registradas en los EUA y en otros países por el Object Management Group. Microsoft® es una marca registrada en los EUA y en otros países; Microsoft Office, Microsoft Excel y Microsoft Project son productos propiedad de Microsoft Corp. Enterprise Architect es un producto propiedad de Sparx Systems, Australia. RUP es una marca registrada por IBM Corp."