Busca en este sitio:
Twitter
. Soy Novato
. Soy Gerente de Proyectos
. Quiero ganar más
. Quiero mejorar a mi empresa
y sus proyectos
. Tengo experiencia, pero no soy experto
. Soy experto (o eso creo)
.
.

Contáctanos
Escríbenos a:
contacto@liderdeproyecto.com
Para información de cursos:
cursos@liderdeproyecto.com

Teléfono en México D.F:
+52 (55) 2652 4590


Aviso de privacidad
+
.
Humor del Líder

Problemas de comunicación
+
.
Glosario
Ven a conocer el glosario de administración de proyectos. Nuevas definiciones: Condiciones, Diagrama de flujo, Proceso de negocio, Producción, Secuencia.
+
.
Colaboradores

Conoce a los colaboradores de LiderDeProyecto.com. Tu puedes ser uno de ellos.
+
.
 
UML

Trabajando en Equipo: Diagramas de Interacción
Por Sergio Orozco y Carlos Macías

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.

Publicado en la revista Software Gurú.
Reproducido con permiso del autor.


Temas relacionados:
Curso de análisis y diseño orientado a objetos con UML


indice del manual



miguel ortega dijo el 26 Agosto de 2010:
muchas gracias por la el conocimiento teorico recibido como por la documentacion-

Sergio dijo el 19 Octubre de 2009:
Perdón, quise decir que es uno de los tipos de diagrama de interacción que existen. El otro es el diagrama de comunicación, antes llamado de colaboración.

Sergio dijo el 19 Octubre de 2009:
Hola Juan, Un diagrama de secuencia es uno de los tipos de interacción que existen en UML. Saludos y gracias por tu pregunta.

juan pascua dijo el 15 Octubre de 2009:
que paso? diagrama de secuencia y de interaccion? es la misma cosa?



Cambios previstos para el PMBOK® Guide 6ta edición (Raymundo Sánchez Ticó)
+
.
.
.
Quienes somos I Base de conocimiento I Apoyo y servicios profesionales I Carrera y desarrollo profesional I Material de apoyo I Productos y souvenirs I Comunidad I Contacto I Aviso de privacidad
© LiderDeProyecto.com - Todos los derechos reservados. PMBOK, PMP, Project Management Professional, Project Management Professional (PMP), PgMP, Program Management Professional (PgMP), PMI-RMP, PMI Risk Management Professional (PMI-RMP), CAPM, Certified Associate in Project Management (CAPM), PMI-SP, PMI Scheduling Professional (PMI-SP), THE PMI TALENT TRIANGLE and the PMI REP Logo are registered marks of the Project Management Institute. 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.