Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                

DS Lab06

Descargar como docx, pdf o txt
Descargar como docx, pdf o txt
Está en la página 1de 6

Desarrollo de Software

Sesión 06: Diagrama de colaboraciones

I. OBJETIVOS

- Conocer los diagramas de colaboración


- Modelar los diagramas de colaboración usando herramientas UML

II. TEMAS A TRATAR

● Diagramas de colaboración
● Componentes de los diagramas de colaboración

III. MARCO TEORICO

DIAGRAMAS DE COLABORACIÓN

El diagrama de colaboraciones describe las interacciones entre los objetos en términos de


mensajes secuenciados. Los diagramas de colaboración representan una combinación de
información tomada de los diagramas de clases, de secuencias y de casos de uso, describiendo
el comportamiento, tanto de la estructura estática, como de la estructura dinámica de un
sistema.

El Diagrama de Colaboración presenta una alternativa al diagrama de secuencia para modelar


interacciones entre objetos en el sistema. Mientras que el diagrama de secuencia se centra
en la secuencia cronológica del escenario que estamos modelando, el diagrama de
colaboración se centra en estudiar todos los efectos de un objeto dado durante un escenario.

Los objetos se conectan por medio de enlaces, cada enlace representa una instancia de una
asociación entre las clases implicadas. El enlace muestra los mensajes enviados entre los
objetos, el tipo de mensaje (sincrónico, asincrónico, simple, blanking, y 'time-out'), y la
visibilidad de un objeto con respecto a los otros.

Un uso de un diagrama de colaboración es mostrar la implementación de una operación. La


comunicación muestra los parámetros y las variables locales de la operación, así como
asociaciones más permanentes. Cuando se implementa el comportamiento, la secuencia de
los mensajes corresponde a la estructura de llamadas anidadas y el paso de señales del
programa.

Un diagrama de secuencia muestra secuencias en el tiempo como dimensión geométrica,


pero las relaciones son implícitas. Un diagrama de comunicación muestra relaciones entre
roles geométricamente y relaciona los mensajes con las relaciones, pero las secuencias
temporales están menos claras.

Es útil marcar los objetos en cuatro grupos: los que existen con la interacción entera; los
creados durante la interacción (restricción {new}); los destruidos durante la interacción
Desarrollo de Software

(restricción {destroyed}); y los que se crean y se destruyen durante la interacción (restricción


{transient}).

Aunque las comunicaciones muestran directamente la implementación de una operación,


pueden también mostrar la realización de una clase entera. En este uso, muestran el
contexto necesario para implementar todas las operaciones de una clase. Esto permite que el
modelador vea los roles múltiples que los objetos pueden desempeñar en varias operaciones.

UTILIDAD
Los diagramas de colaboración:

 Destacan cómo se conectan las líneas de vida.


 Se centran en los elementos dentro de un sistema más que en el flujo de mensajes.
 Proporcionan más énfasis en la organización que en la cronología.

Los diagramas de colaboración también pueden tener las siguientes desventajas:

 Pueden resultar demasiado complejos.


 Dificultan explorar objetos específicos dentro de un sistema.
 Crearlos puede demandar demasiado tiempo.

Componentes

Rol de la clase

El rol de la clase describe cómo se comporta un objeto. Los atributos del objeto no se listan.

Rol de las asociaciones

Los roles de asociación describen cómo se va a comportar una asociación en una situación
particular. Se usan líneas simple etiquetadas con un estereotipo.

Mensajes

Contrariamente a los diagramas de secuencias, los diagramas de colaboración no tienen una


manera explícita para denotar el tiempo, por lo que entonces numeran a los mensajes en
orden de ejecución. La numeración puede anidarse; por ejemplo, para mensajes anidados al
mensaje número 1: 1.1, 1.2, 1.3, etc. . La condición para un mensaje se suele colocar entre
corchetes. Para indicar un loop se usa * después de la numeración.
Desarrollo de Software

IV. ACTIVIDADES (La práctica tiene una duración de 2 horas)

1. Describa el proceso del siguiente diagrama de actividades:

2. Dado un sistema de facturación, el cajero debe facturar un servicio realizado por un cliente, para
lo cual, primero debe verificar el status del cliente, verificar los servicios realizados, registrar la
factura y entregarla.
Desarrollo de Software

3. En una tienda de préstamos de videos, en la que hay un encargado y socios, el encargado puede
prestar videos a los socios siempre que primero verifique la situación del socio, luego verificará la
situación del video, registrará el préstamo y entregará el recibo.

4. En una manada hay una yegua dominante, que es la responsable de la educación de todos los
potros. La yegua pasa el relevo a otra para que vigile a un potro en concreto. La yegua dominante
delega la vigilancia del potro Travieso a otra yegua, que da una orden al potro que éste se niega a
obedecer y, a consecuencia de ello, recibe un castigo.

5. Cuando durante la secuencia se realizan distintos flujos dependiendo de una condición,


utilizamos el marco de referenca opcional:
Desarrollo de Software

VII. Ejercicios

1. : Describa el siguiente diagrama:

2. Realizar un diagrama de comunicación para el diagrama de secuencia mostrado:

3. Realizar el diagrama de comunicación para el siguiente diagrama de secuencia mostrado:


Desarrollo de Software

VII. Bibliografía y referencias

1. https://docs.staruml.io/
2. https://www.ediciones-eni.com/open/mediabook.aspx?idR=67d52f308b3eda2855042d904e2f5c2f

También podría gustarte