modelo dinámico uml reference manual

Estas transparencias proveen sólo una referencia a los temas. Para su estudio debe remitirse a la bibliografía.

1

Universidad Nacional del Sur – Departamento de Ciencias e Ingeniería de la Computación Análisis y Diseño de Sistemas – 1er.Cuatrimestre de 2013.

Mg. María Mercedes Vitturini

[[email protected]]

Dpto. Cs. e Ing. de la Computación

Universidad Nacional del Sur

ANÁLISIS Y DISEÑO DE

SISTEMAS

Clase XV: Modelo Dinámico

Diagramas de

Secuencia y Comunicación Primer Cuatrimestre 2013

• El modelo dinámico (MD) o modelo de

comportamiento representa los aspectos del

sistema relacionados con el tiempo y los cambios

que se producen.

• El MD se ocupa de modelar la evolución de los

objetos y sus relaciones a medida que pasa el

tiempo.

• Los conceptos destacados del MD son: los

eventos, mensajes/señales enviados entre objetos

y estados por los que atraviesan los objetos.

Modelo Dinámico – Generalidades

2 AyDS2012 - Clase 15- MMV 2

Modelo Dinámico

• Los distintos modelos que conforman la vista

dinámica de un sistema se organizar en:

– Modelos de Interacción

• Diagramas de Secuencia

– Diagrama de Secuencia del Sistema

• Diagramas de Comunicación (ex-colaboración)

• Diagrama de CU

– Modelo de Estados

• Diagrama de Estados

– Diagramas de Actividades

AyDS2012 - Clase 15- MMV 3

UML Reference Manual

“The interaction view describes sequences of

message exchanges among roles that implement

behavior of a system.

A classifier role is the description of an object that

plays a particular part within an interaction, as

distinguished from other objects of the same class.

This view provides a holistic view of behavior in a

system— that is, it shows the flow of control

across many objects. “


Modelos de Interacción

Diagramas de interacción – modelan aspectos

dinámicos relacionados con el diseño de los objetos.

• Describen interacciones entre un conjunto de

objetos del sistema y sus colaboraciones.

• Las interacciones sirven para: visualizar, especificar,

construir y documentar la dinámica de una sociedad

particular de objetos.

• Unos de los usos de los diagramas de interacción es

modelar el flujo mensajes entre objetos que

colaboran en un caso de uso.

5 AyDS2012 - Clase 15- MMV

Modelos de Interacción

• Respetando el principio de generalidad, los

modelos de interacción se construyen a distintos

niveles de abstracción:

De mayor nivel de abstracción:

– Interacciones entre Actor y Sistema

• Diagrama de Secuencia del Sistema

De mayor nivel de detalle (variable):

– Intercambio de mensajes entre los objetos del sistema

• Diagramas de Secuencia y Diagramas de

Comunicación.



2


Repaso – Diagrama de Secuencia del Sistema (DSS)

DSS del

escenario de

«Procesar Venta

al Contado»

Iteración

AyDS2012 - Clase 15- MMV

Interacción con «El Sistema»

7

Escenarios

• Un escenario es una secuencia específica de

acciones y eventos entre actor/es y el sistema

objeto de estudio.

– Un escenario es “una historia” particular de uso del

sistema.

• Se los asocia con el concepto de instancia de

caso de uso.

– Depende!! (nivel de detalle de casos de uso).

• Existen múltiples escenarios de la ejecución de un

sistema.

– Casos de éxito y casos alternativos.


Escenarios

• El alcance de un escenario puede variar, aunque se

aconseja reducirlo a la ejecución de Procesos de

Negocio Elementales EBPs (Elementary Business

Processes).

EBP – es una tarea realizada por “una persona” en un

lugar y en un momento como respuesta a un evento del

negocio; que añade un valor cuantificable para el

negocio y deja los datos en un estado consistente.

• Ejemplos:

– Autorizar crédito, registrar venta, dar de alta a un

cliente.


• Como vimos, la descripción de un caso de uso debe

abarcar todas las situaciones posibles del caso de

uso.

• Un escenario cubre una instancia del casos de uso.

• El escenario es una ejecución particular, siguiendo

alguno de los caminos del caso de uso.

• Cada caso de uso se instancia con varios

escenarios.

• ¿Qué se construye primero? Depende!!

– Del problema, del cliente, de las preferencias …

– Tip! El objetivo es obtener los requerimientos del

cliente.

Descripción de CU y Escenarios


Escenario Sistema “MiBiblio” CU Registrar Devolución – Escenario

camino básico, devolución exitosa

1. El Empleado de Atención la Público (EAP) ingresa el número del

ejemplar que se devuelve.

2. El Sistema recupera el préstamo corriente vinculado con el ejemplar.

3. El Sistema recupera y muestra los datos del socio vinculado al

préstamo (socio-número, socio-nombre y socio-foto).

4. El Sistema muestra el detalle del préstamo (fecha-préstamo, fecha-

limite-devolución).

5. El Sistema controla que la devolución es en término.

6. El EAP confirma que el ejemplar es devuelto en condiciones.

7. El EAP confirma la devolución.

8. El Sistema registra fecha-devolución en el préstamo.

9. El Sistema cambia el estado del ejemplar a disponible.

10. El Sistema guarda los datos en la base de datos.


EAP

RegistrarDevolucion

MostrarDatosSocio

<<include>>

Niveles de Detalle • Con los escenarios también se pueden usar distintos

niveles de abstracción:

– Interacciones descriptas alto nivel

Ejemplo:

• “El cliente se loguea en el sistema.”

– Interacciones detalladas + parámetros

Ejemplo:

• Loguear (cliente_número, cliente_passwd).

• Cada empresa define sus estándares.



3


Modelos de Interacción:

Diagrama de Secuencia


• El Diagrama de Secuencia es un tipo de

diagrama de interacción provisto por UML.

• Tiene como objetivo principal describir cómo los

participantes de una interacción intercambian

mensajes para producir un resultado.

• Un diagrama de secuencia muestra (con mayor

o menor grado de detalle) cómo los objetos del

sistema intercambian mensajes en el tiempo.


• El diagrama de secuencia muestra los objetos

participantes en una interacción y la secuencia de

mensajes entre ellos.

• Cada objeto se representan por una línea vertical

denominada la línea de vida.

• Cada mensaje se representa por una línea horizontal

dirigida desde el que la envía hacia el que la recibe.

• El tiempo transcurre desde arriba hacia abajo.

• Los DS muestran secuencias de mensajes NO su

duración.

Elementos del DS


Elementos del DS

• Cada diagrama de secuencia presenta una

interacción particular (un escenario).

• En la interacción aparecen instancias de clase,

sean instancias identificadas o genéricas.

• Notación:


:Cliente miCliente:Cliente

instancia instancia nombrada

Línea de vida

Mensajes

• Mensajes: los mensajes entre objetos se

representan con una línea de flecha (línea

direccionada) entre los objetos.

• Mensajes de retorno: opcionalmente se muestran

los mensajes de retorno con una línea direccionada

punteada.

• Mensajes “self”: son los mensajes que un objeto se

envía a sí mismo.


DS: Guía para la construcción

• Los DS muestran la interacción de los objetos

internos por medio de mensajes, destacando su

ordenación temporal.

• El diagrama se desarrolla a través de un eje X donde

sobre la izquierda se ubica al objeto que inicia la

interacción y a continuación los objetos subordinados.

• Los objetos que se creen durante la interacción están

por debajo del nivel del eje X.

• Cada objeto tiene asociada su línea de vida, que

eventualmente puede indicar cuando el objeto se

destruye.



4




Objetos

Tie

mp

o

Línea de Vida Mensajes

Destrucción

del objeto

19

: Clase1 : Clase2

: Clase3mensaje1()

mensaje2()

mensaje3()

mnesaje4()

mensaje5()

• El diagrama de secuencia del sistema (DSS) es un

tipo específico de diagrama secuencia.

• Muestra los eventos entrantes y salientes vinculados

con el sistema como una caja negra.

• Acompañan las primeras descripciones de los casos

de uso como parte del modelado del dominio.

• El DSS muestra para un escenario específico, los

eventos que generan los actores externos, el orden y

los eventos de respuesta del sistema.

Diagrama de Secuencia del Sistema (DSS) - Repaso


Ejemplo: Diagrama Secuencia del Sistema


DSS Reservar Turno DNI

Diagramas de Secuencia y Escenarios

• Un diagrama de secuencia es la representación

gráfica de un escenario o ejecución particular.

• Cronológicamente:

1. Se identifica el/los casos de uso.

2. Se describen los casos de uso (camino básico y

alternativos).

3. Se elaboran uno o más escenarios asociados al caso

de uso.

4. Se construyen los diagramas de secuencia del

sistema.

5. Se construyen los diagramas de secuencia.


• Un escenario para el Caso de Uso

Realizar_Extracción del ATM:

1. El cliente solicita “Extracción”

2. El sistema ofrece el

formulario_extracción.

3. El cliente informa y confirma el

monto.

4. El sistema verifica la operación

(hay dinero y la operación es

válida para la cuenta).

5. El sistema le solicita su clave.

6. El cliente ingresa su clave.

7. El sistema verifica la clave.

8. El sistema deja registro de la

operación en la Base de Datos.

9. El sistema entrega el dinero e

imprime el ticket.

10. El cliente cierra la sesión

11. El sistema entrega la tarjeta.

Cliente

Extraer DineroRealizar_Extra

cción

Usuario

ATM • Los escenarios colaboran con la construcción de

los DS.

• Ejemplo: un escenario para la llamada de un

ascensor detenido

1. La usuario presiona el botón llamada.

2. El botón envía el mensaje al controlador del

ascensor.

3. El controlador mueve el ascensor.

4. Ascensor avisa al controlador que llegó a un piso.

5. Controlador ordena detener el ascensor.

6. Ascensor abre las puertas.

Ejemplo: Llamada al Ascensor



5


Ejemplo Ascensor


Ejemplo Realizar Pago

• A través de las evoluciones del DS se descubren

operaciones y sus argumentos.

• En el ejemplo Registro invoca al método realizarPago de

la clase Venta y le pasa como parámetro el dinero

entregado.

• …


Mensajes con argumentos

Nace el objeto

¿Diagramas de Secuencia?

Diseño de objetos – «después de la

identificación de requisitos y de la creación del

modelo de dominio, la siguiente actividad es

añadir métodos a las clases del software».

• Los diagramas de secuencia ayudan a la

decisión de:

– ¿qué métodos?,

– ¿dónde colocarlos? y

– ¿cómo deberían interactuar los objetos?


Responsabilidades y métodos

Responsabilidades de los objetos:

• Hacer

– Algo a él mismo (crear, hacer un cálculo).

– Iniciar una acción en otros objetos.

– Controlar/coordinar actividades en otros objetos.

• Conocer

– Sus datos privados encapsulados.

– Los objetos con los que se relaciona.

• Los diagramas de interacción colaboran con una

correcta elección en la asignación de responsabilidades

(«haceres» y «conoceres») a los objetos.


Ejemplo: Sistema de Reservas para un

Restaurant

El siguiente ejemplo usa varios de los modelos vistos

hasta el momento

El requerimiento • Requerimiento registrar reserva.


Actor Requerimiento Datos

Empleado Registrar la reserva de un

cliente de una o varias mesas

Novedades_Rerserva (DE)

Nro. Req F1

Categoría Funcional

Descripción Registrar reserva

Descripción

detallada

Guarda la reserva de un cliente del restaurant para una día y un

turno (mediodía / noche) para una o varias mesas. Solo se aceptan

reservas de clientes anteriores del restaurante. No se reservará una

mesa si ya está reservada para el mismo día y turno. Inicialmente

cuando se carga la reserva la misma queda en estado “pendiente”.


6


Modelos Vistos


Empleado

Registrar_Reserva

31

Cliente

+dni+apellido+nombres+telefono

Mesa

+capacidad+sector

Tipo_sector<<enumeration>>

+fumador+no_fumador

Reserva

+fecha+turno+estado

Tipo_turno<<enumeration>>

+almuerzo+cena

Linea_reserva

+nro_linea+estado

1..*

reservado_a

1 0..*

1

0..*

Estado<<enumeration>>

+pendiente+cancelada+deshabilitada

Descripción del CU

32

Caso de Uso: REGISTRAR_RESERVA Parámetros de Entrada: Novedades_Reserva Descripción: funcionalidad registrar la reserva de una o más mesas a nombre de un cliente

para un día y turno Clases / Asociaciones: Reserva (C), Linea_Reserva (C), Reservas_Cliente (A), Mesas_Reservadas(A)

Curso Básico:

1. El empleado selecciona “Registrar Reserva”

2. El sistema muestra el formulario de reserva.

3. El empleado ingresa [fecha, turno, cliente_dni] s/Novedades_Reserva

4. El sistema verifica que el cliente existe.

5. El sistema crea una nueva reserva(número, fecha, turno) asociada al cliente en estado

«pendiente»

REPETIR

6. El empleado selecciona [nro_mesa] a reservar s/Novedades_Reserva

7. El sistema verifica si la mesa está disponible para reservar en el día-turno.

8. El sistema agrega una líena_reseva para la mesa con estado «pendiente»

FIN

9. El empleado confirma la reserva

10. El sistema almacena la información.

11. Finalizar

Caminos Alternativos:

4.1. El cliente no existe

4.1.1 Informar error.

4.1.2 Ir a 11.

7.1. La mesa tiene una reserva [fecha, turno].

7.1.1 Informar error.

7.1.2 Ir a 6

9.1. El empleado cancela la reserva

9.1.1 Ir a 11.

Fecha: 13/05/2010

Autor: Mercedes Vitturini AyDS2012 - Clase 15- MMV

En el Diccionario de Datos • Novedades_Reserva = cliente_dni + fecha + turno + {mesa_nro}*

Mesa

Cliente


Atributo Tipo Reglas

Número Entero R1 : = not null

Capacidad Entero R2 : >=1 y <=8

Sector Tipo_Sector R3: = [Fumador|No

Fumador]

R4: El número de mesa es único


DNI Entero R1 : = not null

Apellido Cadena (25) R2 : = not null

Nombres Cadena (25) R2 : = not null

R4: El dni es único para todos los clientes

En el Diccionario de Datos


Reserva

Línea Reserva


Número Serial R1 : = not null

Fecha Fecha R2 : = not null

Turno Tipo_Turno R3 := not null

R4 := [almuerzo | cena ]

Estado Tipo_Estado R5 := [pendiente|

cancelada | cumplida]

R6: El número de reserva es único


Número Entero R1 : = not null

R2: = < 5

Estado Tipo_Estado R5 := [pendiente|

cancelada | cumplida]

Un escenario para una reserva exitosa

1. El empleado inicia una nueva reserva.

2. El sistema le solicita: cliente, día y turno.

3. El sistema verifica que el cliente exista.

4. El sistema crea una nueva reserva.

REPETIR

1. El empleado ingresa un número de mesa a reservar.

2. El sistema confirma que la mesa está disponible en esa fecha y

turno.

FIN

5. El empleado confirma la reserva

6. El sistema almacena la información de la reserva

35 AyDS2012 - Clase 15- MMV AyDS2012 - Clase 15- MMV 36

Loopi

:GUIReserva

: Empleado

:CatalogoObjetos

MiR : Reserva

m : Mesa

: Linea_reserva

cl : Cliente

1 : RegistrarReserva(dni, dia, turno)

2 : cl := getCliente(dni)

3 : cl4 : isnull(cl)

5 : getNombres()

6 : nombre, apellido

7 : apellido || nombre

8 : miR := crear(dni, fecha, turno, "PENDIENTE")

9 : ingresar_mesa(nro_mesa)

10 : m := getMesa(nro_mesa)

11 : isnull(m)

12 : vdisponible := disponible(fecha, turno)

13 : agregar_linea_reserva(m, i)

14 : crearLineaReserva(m, i "PENDIENTE")

15 : miR

16 : confirmar()

17 : putReserva(miR)


7



Mesa

+numero

+capacidad

+sector

+disponible(dia, turno)

+crear()

Cliente

+dni

+apellido

+nombres

+dar_apellido_nombre()

reserva

+nro_reserva

+estado

+agregar_linea_reserva(nro_mesa)

+crear(dni, dia, turno, 'habilitada')

Linea_Reserva

+crear(nro_mesa)

GUIReserva

+agregar_reserva(dni, dia, turno)

+mesa_nula(mesa)

+cliente_nulol(cliente)

+ingresar_mesa(nro_mesa)

+mostrar_datos_cliente()

RepObjetos

+getMesa(nro_mesa)

+getCliente(dni)

+putReserva(reserva)

• IMPORTANTE: Si en el diagrama de secuencia existe

un mensaje desde un objeto de alguna clase a otro

objeto de otra clase, en el diagrama de clases dichas

clases deben estar comunicadas por una asociación.

• Un escenario es al modelo dinámico como el diagrama

de instancias es al modelo de objetos.

Balanceo entre Modelos


Diseño Orientado a Objetos

• El modelado dinámico forma parte del diseño del

sistema. De él surgen las primeras clases de diseño.

• Los diagramas de secuencia acompañan la definición

de operaciones de las clases y sus argumentos.

• En diseño orientado a objetos GRASP (General

Responsibility Assignment Software Patterns) son

patrones generales de software para asignación de

responsabilidades. Son "buenas prácticas" de diseño

de software que maximizan la cohesión y minimizan el

acoplamiento.


Principio GRASP del Experto en información

• La responsabilidad de la creación de un objeto o la

implementación de un método, debe recaer sobre la clase

que conoce toda la información necesaria para crearlo.

• Cohesión mide la relación entre los elementos internos

de un módulos. Si los elementos están fuertemente

relacionados y cooperan para lograr un objetivo común.

• Acoplamiento mide la interdependencia entre módulos

distintos.

• Un buen diseño debe:

– maximizar la cohesión y

– minimizar el acoplamiento.


Patrones GRASP

• Creador: identificar quién debe ser responsable de la

creación (o instanciación) de nuevos objetos o clases. La

nueva instancia deberá ser creada por la clase que

– Tiene la información necesaria para realizar la creación del objeto,

o

– usa directamente las instancias creadas del objeto, o

– Almacena o maneja varias instancias de la clase

– Contiene o agrega la clase.

• Controlador: es un patrón que sirve como intermediario.

Recibe los datos del usuario y los envía a las distintas

clases según el método llamado. Este patrón sugiere que

la lógica de negocios debe estar separada de la capa de

presentación.


• El diagrama de comunicación ilustra las

interacciones entre los objetos en un grafo o red.

• Tiene la misma información que un diagrama de

secuencia.

• Los objetos se distribuyen en cualquier lugar del

diagrama. Resta valor a la dimensión tiempo

• La idea es resaltar las interacciones quitando

importancia al orden temporal.

Diagrama de Comunicación (DC)



8


Diagrama de Comunicación

:Persona

:Botón Llamada

:Controlador

:Ascensor

1. llamar_

ascensor

2.notificar_llamada

3.mover_ascensor

5.detener_ascensor

4.avisar_llegada_piso 6.abrir_puerta


43

• Los diagramas de secuencias:

– Destacan la ordenación temporal de los mensajes.

– Incluye la línea de vida de los objetos.

– Cuando participan varias clases están limitados por el

ancho de la «hoja»

• Los diagramas de comunicación:

– Muestran los caminos.

– El número de secuencia indica la ordenación temporal

de los mensajes.

– La ordenación temporal no es tan relevante.

DS vs. DC


• Modelo Dinámico

– Generalidades.

– Diagramas del Modelo Dinámico:

• Escenarios

• Diagramas: Secuencia del Sistema, Secuencia, Colaboración

(UML).

• Bibliografía

– “Object Oriented Modeling and Design” – James

Rumbaugh. Capítulos 5 y 7.

– “Applying UML and Patterns” – Craig Larman

Capítulos 10 y 15.

Temas de la Clase de Hoy


modelo dinámico uml reference manual

Documents