1

IV. UML

MODULO IV

4.5 Diagramas de Interacción

1

Análisis y Diseño de Sistemas de Información

INF-162

Facilitador: Miguel Cotaña 10 de Diciembre 2012

2 2

Cuando se modela algo, se crea una simplificación de la realidad para comprender mejor el sistema que se está desarrollando.

Un diagrama es una representación gráfica de un conjunto de elementos.

Los diagramas se utilizan para visualizar un sistema desde diferentes perspectivas

DIAGRAMAS

3 3

4 4

DIAGRAMAS DE INTERACCION

Son una subcategoria de los diagramas de comportamiento. Muestran la interacción entre diferentes clasificadores de un modelo desde distintos puntos de vista

Un diagrama de interacción muestra una interacción, que consiste en un conjunto de objetos y sus relaciones, incluyendo los mensajes que se pueden enviar entre ellos

5 5

Un diagrama de secuencia es un diagrama de interacción que destaca la ordenación temporal de los mensajes.

Un diagrama de secuencia se forma colocando los objetos en la parte superior del diagrama, a lo largo del eje X.

El objeto que inicia se encuentra a la izquierda y los subordinados a la derecha.

DIAGRAMAS DE SECUENCIA

6 6

Ej: Realizar un pedido, mediante la Web. Creamos un diagrama de secuencia, a un nivel alto de abstracción.

:ReceptorPedido :RealizaciónPedido

emitirPedido

realizarPedido

confirmarPedido

7 7

Un programador responsable de implementar este escenario, tendrá que trabajar sobre el diagrama anterior, expandiendo ciertos mensajes y adicionando otros actores en el diagrama de secuencia, que es parte del diagrama de interacción.

8 8

:receptor DePedidos

:agente TarjetaCredito

emitirPedido

realizarPedido

confirmarPedido

:agente Facturación

:realizacion Pedido

procesarTarjeta

emitirFactura

9 9

Luego, se colocan los mensajes que estos objetos envían y reciben a lo largo del eje Y, en orden de sucesión en el tiempo, desde arriba hasta abajo.

Contiene una línea de vida (línea discontinua vertical) que representa la existencia de un objeto a lo largo de un periodo de tiempo.

Pueden crearse objetos durante la interacción.

10 10

Sus líneas de vida comienzan con la recepción del mensaje estereotipado como create. Los objetos pueden destruirse durante la interacción. Sus líneas de vida acaban con la recepción del mensaje estereotipado como destroy (muestra una X que marca el final de sus vidas.

11 11

El foco de control es un rectángulo delgado que representa el periodo de tiempo durante el cual un objeto ejecuta una acción.

Pueden existir anidamiento de un foco de control (que puede estar causado por recursión, una llamada a una operación propia, o una llamada desde otro objeto) colocando otro foco de control a la derecha

12 12

Diagrama de

Comunicación de análisis

y diseño:

Diferente

granularidad y nivel

de detalle;

Estereotipos

específicos para el

análisis,

interfaz

control

entidad

13

Control estructurado en los diagramas

de secuencia (operadores de control

estructurado): opt : Indica que el fragmento de diagrama es opcional;

alt : Indica que el fragmento de diagrama es una alternativa

(condicional);

loop: Indica que el fragmento de diagrama se ejecuta

repetidas veces;

par: Indica que el fragmento de diagrama incluye hilos de

ejecución paralelo (concurrente);

critical: Indica una secuencia que no puede ser interrumpida

por otro proceso;

sd: Representa un diagrama de secuencia.

14 14

Antes llamada diagrama de colaboración, destaca la organización de los objetos que participan en una interacción.

Se construye colocando los objetos que participan en la colaboración como nodos del grafo.

Luego, se representan los enlaces que conectan esos objetos, con sus respectivos adornos.

DIAGRAMAS DE COMUNICACION

15 15

:receptor DePedidos

:agente TarjetaCredito

1: emitirPedido

3: realizarPedido 4:confirmarPedido

:agente Facturación

:realizacion Pedido

2: procesarTarjeta

5: emitirFactura

6: entregarFactura

16

Un usuario inicia la interacción al oprimir una tecla, se inicia la siguiente secuencia:

La GUI notifica al sistema operativo que se oprimió la tecla El sistema operativo le notifica a la CPU El sistema operativo actualiza la GUI La CPU notifica a la tarjeta de video La tarjeta de video envía un mensaje al monitor El monitor presenta el carácter alfanumérico en la pantalla, con lo que se hará evidente al usuario.

Ejemplo: digitar una tecla

17

:GUI

:Sistema operativo

:CPU

:Tarjeta de video

:Monitor

Tecleo

1:notificar(tecleo)

3:actualizar(tecleo)

2:actualizar(tecleo)

4:notificar(tecleo)

5:mostrar(tecleo)

6:respuesta()

18 18

El propósito de los diagramas de tiempos (o temporizador) es mostrar los cambios en el estado, o la condición, de una línea de vida de una instancia, a lo largo del tiempo y de manera lineal.

Puede utilizarse para mostrar la duración en tiempo que un objeto permanece en cada estado.

DIAGRAMAS DE TIEMPOS

19 19

Por ejemplo, una reunión debe permanecer 30 minutos en un estado de búsqueda de hechos, 60 minutos de deliberación y 15 minutos de cierre:

20

IV. UML

MODULO IV

Contratos

Análisis y Diseño de Sistemas de Información

INF-162

Facilitador: Miguel Cotaña 10 de Diciembre 2012

21

El diagrama de secuencia de un sistema muestra los eventos generados por un actor externo, pero no profundiza en los detalles de la funcionalidad asociada con las operaciones invocadas. No contiene los detalles necesarios para entender la respuesta del sistema, o sea su comportamiento.

22

Es un documento que describe lo que una operación de sistema se propone hacer. Se escribe en forma declarativa, enfatizando qué sucederá y no cómo se conseguirá. Los contratos suelen expresarse a partir de los cambios de estado de las precondiciones y de las poscondiciones.

23

Caso Típico: Comprar Productos - Curso Normal de los Eventos

1 Este caso típico comienza...

Sistema

terminarVenta()

introducirProducto()

efectuarPago()

IntroducirProducto (cod, cantidad)

terminarVenta ( )

efectuarPago (monto)

Cajero Sistema

Operación: IntroducirProducto. Se trata de una nueva venta, por lo tanto después

de esta operación fue creada una Venta...

24

Nombre: Nombre de la operación y parámetros;

Responsabilidades: Descripción informal de las responsabilidades que debe cumplir la operación;

Caso: Nombre del Caso Típico;

Referencias: Nº de referencia de las funciones del sistema, casos típicos, etc.;

Notas: notas de diseño, algoritmos, e información afín;

Excepciones: Casos excepcionales.

SECCIONES DEL CONTRATO

25

Salida: Aquello que se espera recibir del sistema (objetivo del contrato).

Precondiciones: Suposiciones acerca del estado del sistema antes de ejecutar la operación.

Poscondiciones: El estado del sistema después de la operación.

26

Declaraciones de diseño referentes a la operación.

Ejemplo: la explicación de un algoritmo para manejar la operación (fórmula para calcular la cuota de financiación).

NOTAS

27

Definen la suposición sobre el estado del sistema al iniciarse la operación.

Para describir las precondiciones tener en cuenta lo siguiente:

Cosas que son importantes probar en el sistema en algún momento de la ejecución de la operación;

Cosas de las cuales depende el éxito de la operación.

PRECONDICIONES

28

Indican cómo cambió el sistema después de una operación.

Mejora la claridad si se redacta en pretérito (fue creada....).

Describe los cambios necesarios para que el sistema funcione sin necesidad de describir cómo se logran.

Nos concentramos en el qué debe suceder, no la manera de conseguirlo.

POSCONDICIONES

29

Para describir las poscondiciones utilizar las siguientes categorías:

Creación y eliminación de las instancias;

Modificación de los atributos;

Asociaciones formadas y canceladas.

30

El UML no define cómo expresar las poscondiciones. Por lo que se puede adoptar un determinado formato, tomando en cuenta la adopción de una actitud declarativa, orientada al cambio de estado y no a la acción.

31

• Nombre: IntroducirProducto (Cod, cantidad)

• Responsabilidades: Introducir (registrar) la venta de un

producto y agregarlo a la venta. Desplegar la descripción del producto y su precio.

• Tipo: Sistema.

• Referencias cruzadas: Funciones del sistema R.1.1,R1.3, R1.9

Caso típico Compra productos.

• Notas: Utilice el acceso superrápido a la BD.

• Excepciones: Si el Cod no es válido, indique que se

cometió un error.

• Salida:

• Precondiciones: El sistema conoce el Cod.

CONTRATO: introducirProductos

32

Poscondiciones:

Si se trata de una nueva venta, una Venta fue creada (creación de instancia);

Si se trata de una nueva venta, la nueva Venta fue asociada a la Caja (asociación formada);

Se creó una instancia VentaLineadeProducto a la Venta (creación de instancia);

Se asoció VentasLineadeProducto a la Venta (asociación formada);

Se estableció VentasLineadeProducto.cantidad con el valor cantidad (modificación de atributo);

La instancia VentasLineadeProducto fue asociada a una EspecificaciondeProducto, basado esto en la correspondencia del Cod (asociación formada).

33

• Nombre: TerminarVenta • Responsabilidades: Registrar que es el final de la captura de los productos de la venta y desplegar el total de la venta. • Tipo: Sistema. • Referencias cruzadas: Funciones del sistema R.1.2 Caso típico: Compra productos. • Notas: Si no se está realizando una venta indicar que se cometió un error. • Excepciones: Si el Cod no es válido, indique que se cometió un error. • Salida: • Precondiciones: El sistema conoce el Cod. • Poscondiciones:

Estableció Venta.EstaTerminada como verdadero (modificación de atributo)

CONTRATO: TerminarVenta

34

• Nombre: EfectuarPago (monto)

• Responsabilidades:Registrar el pago, calcular el saldo e

imprimir el recibo.

• Tipo: Sistema.

• Referencias cruzadas:Funciones del sistema R.2.1

Caso típico Compra productos.

• Notas:

• Excepciones: Si la venta no está concluida, indique que se cometió un error.

• Salida: Recibo

• Precondiciones:

CONTRATO: EfectuarPago

35

Poscondiciones:

Se creó un Pago (creación de instancia);

Se asignó a Pago.MontoOfrecido el valor de monto (modificación de atributo);

Se asoció el Pago a la Venta (asociación formada);

Se asoció la Venta a la Caja para agregarla al registro histórico de las ventas terminadas (asociación formada).

36

Identificar las operaciones del sistema a partir de los casos típicos y diagramas de secuencias;

Elaborar un contrato en cada operación del sistema;

Comenzar redactando la sección responsabilidades, describiendo el propósito de la operación;

COMO PREPARAR UN CONTRATO

37

Completar la sección poscondiciones describiendo los cambios de estado de los objetos en el modelo conceptual;

Para describir las poscondiciones utilizar las siguientes categorías:

Creación y eliminación de las instancias;

Modificación de los atributos;

Asociaciones formadas y canceladas.

38

1. Identificar las operaciones del sistema

2. Redactar un contrato por cada operación

3. Definir las responsabilidades

4. Indicar de manera informal el propósito de la operación

5. Completar las poscondiciones: * creación y eliminación de instancias; * modificación de los atributos; * asociaciones formadas y canceladas.

EL CONTRATO REQUIERE