Issuu on Google+

IIE ­ Instituto de Ingeniería Eléctrica. DesaSoft ­ Desarrollo de Software para Ingeniería Eléctrica. Guías de clase.   Parte II: Ingeniería de Software.

Diagramas de Interacción. Índice de contenido Diagramas de Interacción.................................................................................................................1 Responsabilidades...................................................................................................................1 Diagramas de Colaboración.....................................................................................................2 Clases e instancias..........................................................................................................2 Enlaces...........................................................................................................................3 Mensajes, parámetros, retorno.......................................................................................3 Mensajes al propio objeto...............................................................................................3 Creación de objetos........................................................................................................3 Numeración de mensajes................................................................................................3 Mensajes condicionales y bifurcaciones..........................................................................4 Iteración.........................................................................................................................4 Diagrama de Secuencia...........................................................................................................5 Clases e instancias..........................................................................................................6 Enlaces...........................................................................................................................6 Mensajes, parámetros, retorno.......................................................................................7 Mensajes al propio objeto...............................................................................................7 Mensajes condicionales y bifurcaciones..........................................................................7 Creación de objetos........................................................................................................7 Iteración.........................................................................................................................8 Comparativo de diagramas de Interacción...............................................................................8 Referencias y lecturas recomendadas.......................................................................................8 Lecturas recomendadas..................................................................................................8 Referencias.....................................................................................................................8 En UML los Diagramas de Interacción describen el modo en que los objetos interaccionan entre sí  por medio de mensajes. Existen dos variedades: los Diagramas de Colaboración y los Diagramas de  Secuencia. Ambos pueden usarse indistintamente; el Diagrama de Colaboración destaca mejor las  bifurcaciones complejas e iteraciones, el Diagrama de Secuencia muestra claramente la ordenación  en el tiempo de los mensajes intercambiados entre los objetos. Los dos diagramas son idénticos en  cuanto a la información registrada, y sustituibles uno por otro. La diferencia reside en el énfasis  sobre la visualización de una u otra característica.

Responsabilidades. Cuando un objeto recibe un mensaje realiza las acciones esperadas por el emisor de ese  mensaje; el mensaje equivale a la invocación de un método residente en el receptor de ese mensaje.  Cuando un objeto contiene un método está exhibiendo el comportamiento definido por ese  método; este comportamiento es una responsabilidad asumida por la clase a la cual pertenece el  objeto. Se entiende por asignación de responsabilidades el adjudicar a las diferentes clases el  comportamiento necesario para cumplir ciertas tareas. La asignación de responsabilidades responde a la pregunta: “esta tarea, ¿quién la debe  realizar?”. Frecuentemente habrá varias clases candidatas a las cuales podría adjudicarse la  responsabilidad, unas más adecuadas que otras, por diferentes motivos, generalmente por serle  1 de 9


más fácil hacerlo a una que a las otras. La asignación de responsabilidades, junto con la abstracción, son dos de las habilidades más  importantes para el buen diseño del software. La asignación de responsabilidades es a tal punto  importante, y es tan grave equivocarse en ella, que muchas situaciones típicas se han registrado en  patrones de diseño, formas de asignar responsabilidades en casos muy conocidos, buenas prácticas  consagradas por años de experiencia en diseño. La asignación de responsabilidades se realiza al momento de construirse los diagramas de  interacción. Estudiaremos a continuación la forma de dibujar los diagramas. El tema de asignación  de responsabilidades se desarrollará próximamente, durante el estudio de los patrones de diseño. En resumen: los diagramas de interacción se construyen asignando responsabilidades a las  clases, siguiendo en lo posible patrones de diseño reconocidos como de buena práctica.

Diagramas de Colaboración. Los Diagramas de Colaboración ilustran las interacciones entre objetos en forma de grafo o red.  Los objetos se pueden colocar en cualquier lugar del diagrama. Esto ofrece ventajas prácticas para  el dibujo. La siguiente figura muestra los elementos de notación de los diagramas de colaboración.

 

Elementos gráficos de los Diagramas de Colaboración

Clases e instancias. Los Diagramas de Interacción representan objetos, instancias de una clase. Los objetos del  diagrama de interacción se representan con un rectángulo, y se designan con el nombre de la clase  a la que pertenecen precedido de ":" y subrayado. Puede darse nombre a la instancia (nombre de  variable), anteponiéndolo al nombre de clase subrayado. Instancias múltiples de una clase o  multiobjeto (una colección de objetos) se indica con el nombre de clase subrayado colocado dentro  2 de 9


de un rectángulo doble.

Enlaces. Un enlace es un camino de conexión entre dos objetos; indica una forma de navegación y  visibilidad entre objetos. Un enlace es una instancia de asociación; indica que es posible enviar un  mensaje desde un objeto a otro. La flecha indica la dirección de invocación. A lo largo de un enlace  pueden fluir varios mensajes, y en ambas direcciones. Puede dibujarse el enlace como una línea sin flechas y cada mensaje con su propia flecha  encima de la línea del enlace, o también pueden dibujarse directamente los mensajes de un objeto  a otro; si hay varios mensajes habrá varias flechas de un objeto al otro, en un sentido o en otro.

Mensajes, parámetros, retorno. En el presente contexto, un mensaje corresponde a la invocación de un método descrito en la  clase del objeto hacia el cual se dirige el mensaje; el método reside en el objeto apuntado por la  flecha. En la figura anterior, la clase EspecificacionDeArticulo tiene un método  getprecioArticulo(idArticulo); el objeto idlv instancia de la clase LineaDeVenta  invoca el método getprecioArticulo(idArticulo) del objeto innominado instancia de la  clase EspecificacionDeArticulo. La notación completa para un mensaje es:   <número>:<retorno>=<nombreMétodo>(<listaParámetros>):<tipoRetorno> El número se emplea para indicar el orden en una secuencia de mensajes. No siempre se indican todos los elementos, por razones de espacio en el dibujo. Lo mínimo es el  número y el nombre del método. Cuando la notación de mensajes no es completa en el diagrama,  debe indicarse aparte en un texto adjunto al diagrama.

Mensajes al propio objeto. Un objeto puede enviarse un mensaje a sí mismo, en una autoasignación de responsabilidad. Se  representa con una flecha dirigida hacia el propio objeto. En los lenguajes de programación el propio objeto se designa con las palabras reservadas "this"  (Java) o "self" (Python). 

Creación de objetos. Un objeto puede crear otro objeto. Si bien cualquier nombre de mensaje puede usarse para crear  un objeto, en UML suele usarse un mensaje de nombre create(), eventualmente con parámetros.  Si se usa otro nombre, conviene adornar el mensaje con el estereotipo <<create>> para indicar  específicamente la creación de un objeto mediante ese mensaje.

Numeración de mensajes. El número es un número de secuencia para indicar el orden en que se intercambian los  mensajes. La forma de numeración más frecuente se rige por estas reglas: • No se numera el primer mensaje. • Los mensajes emitidos por un objeto a partir del mensaje recibido desde otro objeto  incluyen primero el número del mensaje recibido desde el otro objeto, un punto y luego el  número de mensaje enviado por el objeto actual. • Ejemplo: un objeto A recibe el primer mensaje, no numerado; emite luego un mensaje 1  hacia B; B recibe un mensaje 1 y emite a su vez un mensaje a un objeto C, numerado 1.1.  La lista de números permite seguir el orden de invocación. • Un mismo objeto puede enviar varios mensajes; estos se numeran en secuencia. 3 de 9


Ejemplo: un objeto A recibe el primer mensaje, no numerado, y genera 3 mensajes; estos se  numeran 1, 2, 3. El objeto B recibió el mensaje 2 y genera a su vez 2 mensajes, estos se  numeran 2.1 y 2.2. Esta numeración deja claro el anidamiento de mensajes: cuando un mensaje provoca en un  objeto el disparo de otros mensajes secundarios, se aguarda por la terminación de estos mensajes  secundarios antes de dar por terminado el primer mensaje. Esto se aplica a mensajes sincrónicos, en  los cuales se aguarda una notificación de terminación (retorno) antes de continuar las siguientes  acciones. UML puede representar también mensajes asincrónicos, de los cuales no se espera retorno para  continuar la acción; la notación es un mensaje con media flecha. Un ejemplo de mensaje  asincrónico puede ser una confirmación de desconexión; se confirma la desconexión enviando un  mensaje de confirmación, sin esperar retorno alguno; la acción continúa inmediatamente de  emitido este mensaje.

Mensajes condicionales y bifurcaciones. Cuando un mensaje depende del cumplimiento de una condición (mensaje condicional), la  condición se indica en el mensaje, entre paréntesis rectos después del número:     1 [haySaldo = true]: aceptarPago(monto) El mensaje sólo se envía si se cumple la condición. Cuando el cumplimiento de una condición determina comportamientos mutuamente  excluyentes, se generan distintos mensajes según la condición cumplida. Esto se indica con la  condición y agregando letras al número de mensaje para indicar claramente los comportamientos  alternativos: ... 3.2.pagar() 3.2.1a [pago=contado]: pago(monto) 3.2.1b [pago=cheque]: pago(idBanco, nroCheque, nombreEmisor, monto) 3.2.1c [pago=tarjeta]: pago(idTarjeta, monto)   3.2.1c.1 hs=haySaldo(idTarjeta, monto):boolean   3.2.1c.2 [hs=true]: emitirVoucher() ... El número inicial 3.2 asume que esta secuencia de operaciones es parte de una secuencia de  mayor alcance, no mostrada.

Diagrama de Colaboración para modalidades de Pago.

Iteración. Una iteración, lazo o bucle repetitivo se indica en la invocación con un * seguido de la condición  4 de 9


de repetición entre paréntesis rectos, después del número del mensaje: 3.2.2 *[i=1..nroLineas]: actualizarStock(idArticulo, cantidad) Cuando no interesan los detalles de la condición de repetición puede ponerse solamente un *. Cuando se realiza una iteración sobre una colección de objetos, se dirige el mensaje hacia un  multiobjeto (rectángulo doble), con la notación habitual de iteración. En UML, el término  multiobjeto denota instancias múltiples, i.e., una colección. Un * al extremo de la asociación, contra  la colección, indica el envío del mensaje a cada objeto de la colección, en lugar del envío de  múltiples mensajes a la colección en sí.

Envío de mensaje hacia multiobjeto (colección).

Diagrama de Secuencia. Los Diagramas de Secuencia ilustran las interacciones entre objetos colocando los objetos en una  fila horizontal, con el transcurso del tiempo representado por líneas descendentes que parten de los  objetos. Los objetos se agregan a la misma fila, extendiendo el diagrama hacia la derecha. Esto  ofrece una dificultad para el dibujo, extendido siempre hacia un solo lado. La siguiente figura muestra los elementos de notación de los diagramas de secuencia.

5 de 9


Elementos gráficos de los Diagramas de Secuencia 

Clases e instancias. Los Diagramas de Interacción representan objetos, instancias de una clase. Los objetos del  diagrama de interacción se representan con un rectángulo, y se designan con el nombre de la clase  a la que pertenecen precedido de ":" y subrayado. Puede darse nombre a la instancia (nombre de  variable), anteponiéndolo al nombre de clase subrayado. Instancias múltiples de una clase o  multiobjeto (una colección de objetos) se indica con el nombre de clase subrayado colocado dentro  de un rectángulo doble. Los objetos se colocan en una misma fila, agregando sobre el lado derecho los nuevos objetos.  Cada objeto tiene una línea punteada vertical descendente representativa del transcurso del  tiempo: es la línea de vida del objeto; a lo largo de esta línea transcurre el tiempo durante el cual el  objeto existe. Un rectángulo superpuesto a la línea de vida, llamado caja de activación, indica el  período de tiempo durante el cual se está realizando la operación invocada por el mensaje recibido. En algunas situaciones, y algunos lenguajes como C++ lo requieren, un objeto debe ser  específicamente destruido. Esto se indica terminando la línea de vida con una cruz, como respuesta  a un mensaje con estereotipo <<destroy>>.

Enlaces. Los Diagramas de Secuencia no representan enlaces, sólo mensajes.

6 de 9


Mensajes, parámetros, retorno. La notación general para un mensaje es:     <retorno>=<nombreMétodo>(<listaParámetros>):<tipoRetorno> El mensaje se representa con una flecha dirigida desde el objeto invocante al objeto cuyo  método se invoca. No suele graficarse el retorno de una operación, salvo por razones de claridad u otras a juicio  del diseñador; el valor de retorno se indica en la propia invocación. Cuando se muestra un retorno  se hace con una flecha punteada.

Mensajes al propio objeto. Un objeto puede enviarse un mensaje a sí mismo, en una autoasignación de responsabilidad.  Se  representa con una flecha dirigida hacia la caja de activación del propio objeto. En los lenguajes de programación el propio objeto se designa con las palabras reservadas "this"  (Java) o "self" (Python).

Mensajes condicionales y bifurcaciones. Cuando un mensaje depende del cumplimiento de una condición (mensaje condicional), la  condición se indica en el mensaje:     [haySaldo = true]: aceptarPago(monto) El mensaje sólo se envía si se cumple la condición. Cuando el cumplimiento de una condición determina comportamientos mutuamente  excluyentes, se generan distintos mensajes según la condición cumplida. Esto se indica con la  condición en el mensaje y haciendo surgir las flechas del mismo punto en la caja de activación del  objeto invocante. Si el caso lo justifica por su complejidad, se realizan varios diagramas, uno por  cada condición.

Diagrama de Secuencia para modalidades de Pago.

Creación de objetos. Un objeto puede crear otro objeto. En UML el mensaje destinado a la creación de objetos se  indica por un llamado o invocación create(). En este caso la flecha de creación sigue siendo  horizontal, pero la caja del objeto se dibuja a la altura del mensaje de creación, quedando por  debajo de la fila de objetos preexistentes. Si se usa otro nombre distinto de create(), conviene  adornar el mensaje con el estereotipo <<create>> para indicar específicamente la creación de un  objeto mediante ese mensaje.

7 de 9


Iteración. Si la iteración es sobre un único mensaje, basta con indicarlo en la flecha de invocación:     *[i=1,nroLineas] actualizarStock(idArticulo, cantidad) Si la iteración se produce sobre varios métodos se encierran estos en un rectángulo dentro del  cual se indica la condición de iteración de igual modo. Cuando se realiza una iteración sobre una colección de objetos, se dirige el mensaje hacia un  multiobjeto (rectángulo doble), con la notación habitual de iteración. Un * al extremo del mensaje,  contra la colección, indica el envío del mensaje a cada objeto de la colección, en lugar del envío de  múltiples mensajes a la colección en sí.

Comparativo de diagramas de Interacción. Cada tipo de diagrama tiene sus ventajas y desventajas. Convendrá seleccionar aquel que mejor  refleje el comportamiento a modelar, el que resulte más claro o el que cuente con la preferencia de  los diseñadores. Tipo

Ventajas

Desventajas

secuencia

Muestra claramente la ordenación en el  Obliga a extender el diagrama hacia la  tiempo de los mensajes. derecha cuando se agregan nuevos  objetos. Notación simple, fácil de entender. Consume espacio horizontal.

Economiza espacio, flexible para añadir  Difícil para ver la secuencia de mensajes. nuevos objetos. colaboración Ilustra mejor bifurcaciones complejas,  Notación compleja. iteraciones y comportamiento  concurrente.

Referencias y lecturas recomendadas. El contenido de este documento está basado en las fuentes citadas a continuación, cuya lectura o  consulta no pretenden sustituir.

Lecturas recomendadas. •

• •

[Larman2003] Larman, Craig. UML y patrones. Una introducción al análisis y diseño  orientado a objetos y al Proceso Unificado, 2a. edición. Madrid, 2003. ISBN 84­205­3438­2. [Fowler1997] Fowler, Martin y Scott, Kendall. UML distilled. Applying the Standard Object  Modelling Language. Addison Wesley Longman, Inc., 1997. ISBN 0­201­32563­2. [Pfleeger2002] PFLEEGER, SHARI LAWRENCE. Ingeniería de software, teoría y práctica,  1a. edición. Buenos Aires, Pearson educación, 2002. ISBN: 987­9460­71­5.

Referencias. • •

[Jacobson2000] Jacobson, Ivar; Booch, Grady; Rumbaugh, James. El proceso unificado de  desarrollo de software. Pearson Educación, Madrid, 2000. ISBN: 84­7829­036­2. [Booch1999] Booch, Grady; Jacobson, Ivar; Rumbaugh, James. El lenguaje unificado de  modelado. Pearson Educación, Madrid, 2000. ISBN: 84­7829­028­1.

8 de 9


Errores, omisiones, comentarios: Víctor González Barbone, vagonbar en fing.edu.uy Desarrollo de Software para Ingeniería Eléctrica ­ Rev. 2009­05­12  Instituto de Ingeniería Eléctrica  ­     Facultad de Ingeniería     ­ Universidad de la República, Uruguay.    

9 de 9


13_Diagramas de iteración