Sesion 5 1 diagrama de secuencia

Diagramas de Secuencia

Lic. César Alcántara Loayza

Diagramas De Secuencia
 El objetivo del análisis del problema es definir
el propósito e interfaces de cada recurso del
dominio del problema.
 Se determinó el propósito al definir cada
clase y sus relaciones en un diagrama de
clases.
 Ahora veremos las interfaces. Las principales
herramienta para descubrir y comprender las
interfaces son los diagramas de interacción .
CAL/Fundamentos 2

 Los diagramas de secuencia y
colaboración son usados para modelar
interacciones entre los objetos . Los
diagramas de secuencia ilustran la
interacción entre objetos en el tiempo.
Los diagramas de colaboración ilustran
las interacciones de los objetos a través
de enlaces entre objetos.
CAL/Fundamentos 3

 Las interacciones ayudan a definir el propósito
de un objeto, esto decir, las formas en las que
un objeto participa en tareas, como se comunica
y trabaja con otros objetos, el por que se
necesita del objeto.
 Las interfases son preguntas y solicitudes que
un objeto es capaz de responder. Si la
declaración del problema dice que un objeto
debe ser capaz de responder una pregunta o
responder a una solicitud, entonces el objeto
debe tener una interface correspondiente.
CAL/Fundamentos 4

 Operaciones y atributos:
 Una interface aparece como una operación
en una definición de clase. Las
operaciones describen lo que el objeto
puede hacer y lo que puede hacerle al
objeto. Las operaciones pueden recibir,
manipular y regresar información. Esta
información aparece en las definiciones de
clase como atributos.
CAL/Fundamentos 5

 Los diagramas de secuencia muestran
objetos que se comunican unos con
otros a lo largo del tiempo. Utilizando,
objetos, linea de vida de los objetos y
flechas de mensaje.

CAL/Fundamentos 6

 En siguiente diagrama de secuencia:
 Los objetos usan la notación estandar, un
rectangulo que contiene el nombre del objeto, dos
puntos y el nombre de la clase del objeto. Estos
tres elementos subrayados. El nombre del objeto
es opcional. Nombreobjeto:nombreclase.
 La linea de vida del objeto es una línea
discontínua vertical.
 Los mensajes aparecen como flechas.

CAL/Fundamentos 7

Factura : Cliente Orden de Factura : Orden : Inventario

orden( )

retornar orden

AddArticulo( )
ProductoDisponible(Producto)

retorno verdadero

AddProducto(producto)

retorno ok

CAL/Fundamentos 8

 Mensaje.
 Un mensaje se presenta como una flecha
horizontal desde la línea de vida del objeto que
envía hasta la línea de vida del objeto que recibe.
 La terminología puede varias entre las versiones
de UML ..
 Una posición en la línea de vida indica un punto
relativo en el tiempo. El tope de la línea
representa el comienzo de la línea de vida. La
parte baja corresponde al final de la linea de vida.

CAL/Fundamentos 9

 El contexto del diagrama de secuencia
es la comunicación entre objetos. El
alcance del diagrama de secuencia
está determinado por la fase actual del
ciclo de vida del proyecto. Durante el
análisis del problema, el alcance es la
comunicación entre los actores, el
sistema y los recursos del sistema .
CAL/Fundamentos 10

 Al construir un diagrama de secuencia es útil
partir el proceso en dos partes:
 Paso 1: describir las interacciones entre el actor y el
sistema. Esto permite mantener el diagrama tan
simple como sea posible. Mientras se trabaja en
comprender como debe trabajar el caso de uso.
 Paso 2: expandir el sistema para incluir los recursos
usados por el sistema. Una vez que se sabe como
debe trabajar el caso de uso, se remapea el
comportamiento del sistema para mostrar los objetos
recursos usados por el sistema para completar el
comportamiento.
CAL/Fundamentos 11

: Sistema Bancario
: Cliente

Primer paso: retira $100

fondos insuficientes ¿otro monto?

retira $45

denominación inválida ¿otro monto?

retira $40

$40 + recibo

CAL/Fundamentos 12

: Sistema Bancario : Cuenta
: Cliente

retira $100
retira $100

fondos insuficientes
fondos insuficientes ¿otro monto?

Segundo paso retira $45

denominación válida?

denominación inválida ¿otro monto?

retira $40
retira $40

OK

$40 + recibo

CAL/Fundamentos 13

 Muchos casos de uso incluyen decisiones.
Cursos de acción que resultan de multiples
decisiones pueden ser muy complejas. Los
diagramas de secuencia UML permiten
bifurcaciones pero son dificiles de leer, por
ello se recomienda que el diagrama de
secuencia se limite a un solo escenario. Un
escenario es una ruta lógica (ejecución
particular) del caso de uso.

CAL/Fundamentos 14

Modelando Escenarios
 Transformar una especificación textual en un
diagrama de secuencia:
 Un escenario describe una serie ordenada de
eventos dentro de un caso de uso. El objetivo del
diagrama de secuencia es asignar
responsabilidades de los eventos a los objetos, de
forma que definan las interfaces del objeto. Para
construir un diagrama de secuencia se debe
emparejar cada evento del escenario con los
objetos que participan en el evento como
remitente y receptor.

CAL/Fundamentos 15

 Para dibujar un diagrama de secuencia,
evalue cada evento del escenario e
identifique el objeto que inicia el evento .
Luego identifique el objeto que está
mejor preparado para responder.
Dibuje una flecha de evento desde el
objeto iniciador al objeto que responde.
Rotule la flecha de evento con la
descripción del evento
CAL/Fundamentos 16

 A medida que coloca eventos en el
diagrama de secuencia cuide la
posición sobre la linea de vida del
objeto desde arriba hacia abajo en el
orden en el que ocurren. Ajuste el
orden de ser necesario.

CAL/Fundamentos 17

Realización
 La realización de los CUS se pueden
hacer con diagramas de colaboración
(modelo de análisis y luego aplicación
del análisis de robustez) ó se pueden
emplear diagramas de secuencia ó se
puede hacer textualmente.

CAL/Fundamentos 18

Obtener las 20 siguientes
presentaciones por fecha Evento 1

A C

Muestre las Obtener los eventos para las 20 Evento 3
Evento 2 presentaciones presentaciones seleccionadas

Mostrar los Evento 4
eventos

Evento 5 B
Evento 5
[ selecciona evento ]
selecciona presentación
[ Ingresa rango fechas ]
Validar fechas [ timeout ]

Tomarlo ingresadas Obtener detalle de obtener presentaciones para
[ cancela ] presentaciones
Mostrar mensaje evento seleccionado

solo como timeout

ejemplo visual fechas válidas
mostrar detalle de

de escenarios Muestra presentaciones para el [ fechas inválidas ]
presentaciones A

rango de fechas

Evento 6
mostrar mensaje
de error B

C

B
CAL/Fundamentos 19

 Utilice un escenario como fuente de los
eventos. De la especificación (representada
por el diagrama de actividad) se ha
seleccionado un escenario (marcado con
color celeste)  una ruta lógica.
 En el diagrama de actividad se ha utilizado
las notas como conectores (color gris).

CAL/Fundamentos 20

 Para el primer evento (Obtener las 20
siguientes presentaciones por fecha),
escoja la clase del diagrama de clases
que describa el objeto que inicia el
evento. El objeto que da inicio puede
ser una clase que representa un actor,
el sistema mismo, o uno de los
recursos del dominio del problema . En
este caso el objeto iniciador es el
cliente.
CAL/Fundamentos 21

 Las clases que participan

Evento
SistemaDeBoletaje

Cliente
0..*
Presentación

CAL/Fundamentos 22


: SistemaDeBoletaje
: Cliente

Obtener 20 siguientes presentaciones por fecha

CAL/Fundamentos 23

 Para cada evento se encoge una clase que
describa el objeto que recibe y responde al
evento.

: SistemaDeBoletaje
: Cliente


Mostrar presentaciones

CAL/Fundamentos 24

 Se repite el procedimiento para cada evento
hasta que todos los eventos se apliquen al
diagrama de secuencia

: SistemaDeBoletaje : Presentación
: Cliente




CAL/Fundamentos 25


: SistemaDeBoletaje : Presentación
: Cliente



obtener eventos para 20 presentaciones seleccionadas

listar eventos

Mostrar eventos

CAL/Fundamentos 26

: SistemaDeBoletaje : Presentación : Evento
: Cliente




listar eventos

Mostrar eventos

Actividad 5
selecionar evento

Obtener presentaciones para evento seleccionado
evento
activador
Listar presentaciones

Valor
retornado

CAL/Fundamentos 27

: SistemaDeBoletaje : Presentación : Evento
: Cliente




listar eventos

Mostrar eventos

Actividad 5
selecionar evento

Obtener presentaciones para evento seleccionado
evento
activador

Valor
retornado
Mostrar eventos

CAL/Fundamentos 28

 Transformar eventos en objetos:
 Asignar eventos a objetos:
 Una vez que se han distribuido los eventos de
un escenario en un diagrama de secuencia,
vuelva al diagrama y verifique que el propósito
de los objetos corresponde con los eventos en
los que ellos participan.

CAL/Fundamentos 29

 Aplique una medida de cohesión preguntando:
 ¿Todos los eventos iniciados por el objeto soportan el

propósito (único) del objeto?
 ¿Los eventos a los que el objeto responde encajan con

el propósito (único) del objeto?, o ¿al objeto se le piden
algo que no lo relaciona directamente con su propósito
principal?
 Aplique una medida de acoplamiento de los objetos. Las
interacciones implícitamente identifican dependencias. Las
preguntas son:
 ¿Las dependencia refuerzan la adecuada división de

trabajo a través del objeto, o simplemente complica la
comunicación?
 ¿Las dependencias reflejan el funcionamiento del mundo

real?

CAL/Fundamentos 30

 Evalúe el propósito del objeto:
 Cuando se asigna una nueva tarea a un
objeto, se está en efecto agregando nueva
responsabilidad a la “descripción del
trabajo” de objeto. Las nuevas
responsabilidades afectan al objeto de la
misma manera que lo haría adicionar
mayores responsabilidades a su trabajo.

CAL/Fundamentos 31

Interfaces
 Convertir eventos en operaciones:
 Completar la descripción del evento
adicionando información que es pasado
con el evento y la respuesta esperada.
Ambos elementos son opcionales, es
decir, no todos los eventos necesitan
parámetros y no todos los eventos tienen
respuestas.
 Ejem., Notificar en algunos casos solo como
alarma, en otros puede esperar respuesta.
CAL/Fundamentos 32

Interfaces
 Convertir descripciones de eventos en
operaciones:
 El objetivo de crear un diagrama de secuencia es
descubrir y documentar las interfaces de cada
clase. Para definir completamente cada interface,
debe convertir la descripción del evento en una
signatura de operación formal. La definición formal
de una signatura de operación consiste de un
nombre, parámetros de entrada (o argumentos), el
tipo de dato de retorno esperado y restricciones.

CAL/Fundamentos 33

Interfaces
 +NombreOperación (NombreArg: Tipo Dato
{Restricciones}, ... ) : Tipo Dato Retornado
{Restricciones}
 NombreOperación: requerido
 Se permite cualquier número de argumentos
 Tipo de datos retornado: requerido para un valor
regresado, pero los valores de retorno son
opcionales.
 Visibilidad (+): Requerida antes de la generación
del código.

CAL/Fundamentos 34

Interfaces
 Los argumentos o parámetros son elementos
de datos que el objeto necesita para ejecutar
la operación.
 El tipo de datos retornado describe la clase
de información que debe darse como
resultado de completar la operación.
 Las restricciones son simplemente texto en
formato libre que describen las reglas y
limitaciones en la ejecución de la operación.
CAL/Fundamentos 35

Interfaces
Descripción de Evento Elementos de la descripción de la Operación
Obtener las presentaciones Nombre Operación Argumentos Retorno
Para un rango de fechas ObtPresentación FechaInicio, FechaFinal Lista presentaciones
Signatura completa: ObtPresentación (FechaInicio, FechaFinal):
ListaPresentaciones
Mostrar Mostrar ListaPresentaciones
Presentaciones Signatura completa: Mostrar (ListaPresentaciones) ó
MostrarPresentación (ListaPresentaciones)
Obtener Evento ObtenerEvento Evento
Para una Presentación Signatura completa: ObtenerEvento():Evento

Mostrar Mostrar Lista Eventos
Evento Signatura completa: Mostar (Lista Eventos)
ó MostarEvento (Lista Eventos)

CAL/Fundamentos 36

Descubriendo Atributos
 Cada pieza de información usada por el
sistema debe se definida como atributo.
Cada atributo debe pertenecer a un
objeto. Aún si un atributo es derivado y
nunca se almacena, algún objeto debe
poseer las reglas para derivarlo.

CAL/Fundamentos 37

 - / NombreAtributo: Tipo Dato = Valor
por omisión {Restricciones}

 - Visibilidad: requerida antes de generar
código.
 / Indicador de atributo derivado: opcional

CAL/Fundamentos 38

 Cada argumento de una operación
debe tener una fuente, ¿el objeto que
inicia el evento posee la data?, Si no es
así, ¿de donde lo obtiene?. Mire el
diagrama de clases y encuentre la
clase que debería tener la data.
Actualize el diagrama de secuencia
para mostrar como el objeto iniciador
ha obtenido la data desde el objeto que
la posee.
CAL/Fundamentos 39

 Ejemplo expandir un diagrama de
secuencia con parámetros
Asiento
Cliente
Boleto
1
1
Ubica 0..1
utiliza
realiza

0..* 0..* 1
reserva Pone Precio
Compra AsientoPresentación NivelPrecio
0..* 1 0..* 0..1

CAL/Fundamentos 40

 Diagrama de secuencia inicial para el caso
de uso comprar asientos:
: Cliente : Compra : AsientoPresentación : Boleto

Paga(lista asientos presentacion)

ObtenerPrecio

Precio

Descuento

UsarBoleto
Boleto

Regresar boleto

Regresar boleto

Regresar conjunto boletos

CAL/Fundamentos 41

 Retornos de la operación:
 La misma lógica se aplica a los retornos de
operaciones. ¿El objeto que responde posee la
data?, Si no es así, ¿de donde la obtiene?, ¿El
objeto deriva la data usando sus propias
operaciones?, ¿El objeto ha hallado el valor
usando otros objetos?. Actualice el diagrama de
secuencia para adicionar los objetos que poseen
la data y muestre como obtiene la data el objeto
original.

CAL/Fundamentos 42

 En el ejemplo .. cuando un cliente
quiere comprar asientos para la
presentación, debe proporcionar el tipo
de precio para cada sitio para que el
sistema conozca que tipo de precio
cargar, es decir, adulto, estudiante,
adulto mayor o niño:

CAL/Fundamentos 43

Agregue un precio
Para cada sitio

: Cliente : Compra : AsientoPresentación : Boleto


ObtenerPrecio El cliente es el único objeto que
conoce que tipo de precio
aplicar para cada sitio.
Precio
Adicionar el tipo de precio a los
parámetros de la operación de
Descuento pago invocada por el cliente.

UsarBoleto
Boleto

Regresar boleto

Regresar boleto


CAL/Fundamentos 44

 Para hallar el precio por
asientopresentación, asientopresentación
debe pedir el precio a nivelprecio. Cuando
se pide el precio asientopresentación
debe proporcionar el tipo de modo que
nivelprecio decida que precio retornar.

CAL/Fundamentos 45

: Cliente : Compra : AsientoPresentación : Boleto : NivelPrecio

ObtenerPrecio
ObtenerPrecio(TipoPrecio)

Precio

Precio

Descuento

Boleto
UsarBoleto
Regresar boleto

Regresar boleto


CAL/Fundamentos 46

 Cada vez que haga un refinamiento, itere a
traves del proceso de modelamiento:
 Evalúe el diagrama de clases para encontrar objetos
que participan en la interacción.
 Adicione nuevos objetos.
 Identifique nuevos eventos.
 Reevalúe el propósito de los objetos participantes.
 Convierta los eventos en operaciones.
 Convierta la información en atributos.
 Asigne propietario a los atributos.
 Repita hasta que todos los parámetros y retornos
esten considerados.
CAL/Fundamentos 47

Revisión
 Uno de los principales problemas en el
diseño de software es decidir que incluir en
el: cada elemento tomado en cuenta requiere
dinero y tiempo para desarrollar y soportar.
¿Cómo puede asegurarse que está gastando
el tiempo y dinero de la mejor manera? 
Utilizar diagramas de clase, de secuencia y
modelo de casos de uso como referencias
cruzadas.

CAL/Fundamentos 48

Revisión
 Comparar estas tres vistas una con otra
ayuda a descubrir y justificar las
operaciones y atributos necesarios para
soportar las expectativas del usuario.

CAL/Fundamentos 49

Revisión
 Hemos revisado:
 El propósito y la función de los diagramas de
secuencia: descubrir y definir las interfaces de
las clases.
 Transformar los escenarios de casos de uso en
diagramas de secuencia: usar un escenario
para crear un diagrama de secuencia.
Transformar cada evento del escenario en un
evento en el diagrama de secuencia. Asignar
responsabilidad del evento a los objetos emisor
y receptor.
CAL/Fundamentos 50

Revisión
 El valor de las interacciones para el modelado de
objetos: justificar la necesidad de cada interface
de clase como parte de los requerimientos de los
casos de uso.
 Como descubrir y documentar las operaciones
desde las interacciones: convertir cada evento en
una operación.
 Como descubir y documentar atributos de las
operaciones: convertir todos los argumentos y
retornos de la operación en atributos. Rastree las
fuentes de cada atributo identificado en la
secuencia.
CAL/Fundamentos 51

Reconciliar Modelos
 Un diagrama por si mismo es muy dificil de
verificar. Pero cuando se usan juntos
diferentes diagramas del mismo problema el
proceso de comparación y contraste revela
problemas potenciales.
 Para identificar discrepancias:
 Como probar escenarios.
 Como probar clases.
 Como probar interfaces.
 Como reconocer los patrones de reconciliación.

CAL/Fundamentos 52

Reconciliar Modelos
 Aunque el diagrama de clases es el
único usado para generar código los
otros diagramas son herramientas que
ayudan a comprender las clases. El
diagrama de clases tiene una
perspectiva limitada del dominio del
problema; No muestra como se
comportan los objetos cuando se usa el
sistema.
CAL/Fundamentos 53

Reconciliar Modelos
 Para ver el comportamiento de los
recursos, se necesitan modelos que
describan como se usan los recursos,
viendo las interacciones entre clases, la
creación y disposición de recursos y los
patrones de colaboración de cada
comportamiento.

CAL/Fundamentos 54

Analisis Del Problema III

Lic. César Alcántara Loayza

Reconciliar Modelos
 Un diagrama por si mismo es muy dificil de
verificar. Pero cuando se usan juntos
diferentes diagramas del mismo problema el
proceso de comparación y contraste revela
problemas potenciales.
 Para identificar discrepancias:
 Como probar escenarios.
 Como probar clases.
 Como probas interfaces.
 Como reconocer los patrones de reconciliación.
CAL/Fundamentos 56

Reconciliar Modelos
 Aunque el diagrama de clases es el
único usado para generar código los
otros diagramas son herramientas que
ayudan a comprender las clases. El
diagrama de clases tiene una
perspectiva limitada del dominio del
problema; No muestra como se
comportan los objetos cuando se usa el
sistema.
CAL/Fundamentos 57

Reconciliar Modelos
 Para ver el comportamiento de los
recursos, se necesitan modelos que
describan como se usan los recursos,
viendo las interacciones entre clases , la
creación y disposición de recursos y los
patrones de colaboración de cada
comportamiento.

CAL/Fundamentos 58

Prueba De Escenarios
 Los escenarios de los casos de uso son
fuentes para los diagramas de interacción.
 Los escenarios son incialmente de muy alto
nivel. De hecho, deberian describir solo lo
que es visible a un actor desde fuera del
sistema. Cuando se crea el diagrama de
secuencia, existen solo dos objetos, el actor
y el sistema. En una segunda iteración,
adiciona los recursos que el sistema usa para
completar los eventos asignados al mismo.
CAL/Fundamentos 59

 Durante el diseño este mismo proceso
continuará a medida que adicione
clases de software. Reemplazará a los
actores con objetos interfaces de
usuario y reemplazará el objeto
“sistems” con las clases interfaz y
control que componen el software .

CAL/Fundamentos 60

 Invariablemente el diagrama de
secuencia tendrá mas detalle que los
escenarios. Los objetivos y las
audiencias son diferentes. Los
escenarios son dirigidos a los usuarios
fuera del sistema. Los diagramas de
secuencia son dirigidos para describir
el sistema y sus recursos internos .
CAL/Fundamentos 61

 Agregando detalle el diagrama de
secuencia:
 Si agrega detalle al diagrama de secuencia
adicione dichos detalles a los escenarios y
viceversa. De forma que ambos diagramas
se encuentren coherentes durante el
proceso de mejoras.

CAL/Fundamentos 62

 Cuando se buscan objetos que poseen
los niveles de conocimiento requeridos
para resolver el problema. Ud. No está
limitado a enlaces directos. En el
ejemplo de ATM, el banco es una
fuente que ATM accede para obtener
información que necesita. No hay
enlace directo entre ATM y el banco.
CAL/Fundamentos 63

Escenarios Y Secuencias
 Paso 1: en este primer diagrama de
secuencia se refleja la secuencia de
eventos descrita por el escenario.

 Escenario: retiro con éxito $100.
1. El cliente pide retirar $100.
2. El sistema ATM responde
proporcionando el dinero y un recibo.
CAL/Fundamentos 64


: SistemaATM
: Cliente

Retira $100

Dinero + recibo

CAL/Fundamentos 65

 Paso 2: incorpora los flujos referenciados por
otros escenarios pero no mostrados
explicitamente en el diagrama de secuencia
original.

 Desde dos escenarios de excepción se
conoce que el sistema actualmente pasa por
dos ediciones antes de avalar el retiro.

CAL/Fundamentos 66


: SistemaATM
: Cliente

Retira $100
Denominación válida?

Fondos suficientes?

Dinero + recibo

CAL/Fundamentos 67

 Escenario: Retiro con éxito $100.
2. ¿La cantidad ingresada es divisible por la
denominación disponible en la máquina?
3. ¿Existe suficientes fondos en la cuenta
para cubrir la cantidad de retiro?.
4. El sistema ATM entrega el dinero y recibo.

CAL/Fundamentos 68

 Paso 3: revisar mejoramientos:
 Una vez que se ha dibujado el diagrama
se revisa con los miembros del equipo.
Ellos le preguntan si intenta incluir la
verificación de limite diario que tiene el
banco. ¿Qué hará? Preguntar a los
usuarios.
 Los usuarios manifiestan que olvidaron
mencionar antes y que desean la
verificación de limite diario en el sistema.
CAL/Fundamentos 69


: SistemaATM
: Cliente

Retira $100

Dentro de los límites diarios?

Fondos suficientes?

Dinero + recibo

CAL/Fundamentos 70

3. ¿El retiro está dentro de los límites de
retiro diario?
5. El sistemaatm entrega dinero y recibo.
CAL/Fundamentos 71

 Paso 4: adicionar recursos del sistema.
 Identificar los recursos que el sistema atm
(cajero) utiliza para satisfacer las
solicitudes de retiro. Estos recursos estan
definidos en el diagrama de clase donde
se han identificado a los recursos del
dominio del problema.

CAL/Fundamentos 72

SistemaATM

0..*

1..* Cliente
RedATM 1..*

0..* Posee

1..*
0..*
Banco CuentaBancaria
1 0..*

CAL/Fundamentos 73

 Para cada evento, determine el objeto que
mejor pueda manejar el evento. Recuerde que
para pasar el evento a un objeto debe seguir
las asociaciones definidas en el diagrama de
clases.
 1. El sistema ATM es el único objeto que
conoce su propias denominaciones.
 2. El banco es el único objeto que controla la
política de limites.
 3. El banco conoce el saldo de la cuenta.
CAL/Fundamentos 74


: SistemaATM : Banco
: Cliente

Retira $100
Note que todos los
Dentro de limites de retiro diario?
eventos y su orden
se mantienen Pero
OK

se han reasignado
Suficientes Fondos en cuenta?

OK
responsabilidades
Dinero + recibo
desde el sistema
ATM hacia el banco

CAL/Fundamentos 75

retiro diario?
CAL/Fundamentos 76

 Paso 5: evalúe el diagrama de secuencia para
mejorar el flujo de eventos.
 Note que el diagrama de secuencia hace dos
llamadas desde el sistema atm hacia el banco. Una
gran red separa físicamente estos dos sistemas.
Podría mejorar la comunicación y rendimiento para
simplificar la comunicación en un único evento.

1. Reemplce los dos eventos con un único evento “retiro.”

2. El banco ejecuta los dos eventos originales cuando
recibe un nuevo evento de retiro.

3. Asegurar de adicionar el retorno del evento de retiro para
reflejar la respuesta final del banco.

CAL/Fundamentos 77

: SistemaATM : Banco
: Cliente

Retira $100

Retira $100

Dentro de limite de retiro diario?

Fondos suficientes?

OK

Dinero + recibo

CAL/Fundamentos 78

retiro diario?
CAL/Fundamentos 79

Prueba De Interfaces
 Reconcilie el diagrama de secuencia con el
modelo de objetos.
 El formato de la signatura de una operación:
 Nombre ( argumento : datatype, ...) : returndatatype
{restricciones}.
 Cada evento debería ser traducido en una
operación. Una vez que la signatura de la
operación se ha definido, existen 4 pruebas para
aplicar a su diagrama de clases.

CAL/Fundamentos 80

 1. Verificar que cada operación en su
diagrama de secuencia aparece en el
diagrama de clases. Muchos CASE
agregan automáticamente interfaces a
los diagramas de clase.

CAL/Fundamentos 81

 2. Pruebe la cohesión de la clase. Verifique
que cada interface soporte el propósito del
objeto. Luego busque todas las interfaces de
la clase y determine si todas las interfaces
soportan el mismo propósito. Si observa que
las operaciones trabajan en dos o mas
objetivos, entonces podría necesitar partir la
clase para mejorar la cohesión.

CAL/Fundamentos 82

 3 prueba de consistencia. Si se
referencia la misma interfaces en mas
de un escenario, verifique que se use
del mismo modo en cada escenario. Es
muy facil llegar a tener operaciones con
identico nombre que ejecutan funciones
distintas.

CAL/Fundamentos 83

 4. Responda las siguientes preguntas:
 ¿La clase tiene todo lo necesario para cumplir su
propósito definido?
 ¿Las interfaces proporcionan toda la funcionalidad
que normalmente podría asociarse con el alcance
de responsabilidad que se ha asignado a la
clase?, De no ser así entonces necesitará revisar
los casos de uso y los escenarios para averiguar
lo que se pudo pasar por alto. Es posible, también
, que la responsabilidad esté fuera del alcance del
proyecto.

CAL/Fundamentos 84

Prueba De Clases
 Reconcilie el diagrama de clases con el
modelo de casos de uso.
 Reconcilie la terminología del modelo de
casos de uso y los nombres de clase.

CAL/Fundamentos 85

Prueba De Clases
 1. ¿Existe una clase que maneje cada
recurso mencionado en el modelo de
casos de uso?. Cuando se crea
inicialmente el diagrama de clases se usa
el vocabulario del dominio del problema
como se documenta en la declaración del
problema y en los casos de uso. A medida
que se continua el análisis, es frecuente
los cambios en estos documentos.
CAL/Fundamentos 86

Prueba De Clases
 Verifique que los nuevos recursos sean
añadidos (o removidos) de su diagrama
de clases y que su propósito esté
completamente definido. Defina sus
interfaces y actualize su diagrama de
secuencias.

CAL/Fundamentos 87

Prueba De Clases
 2. Usando el modelo, haga preguntas
que requieran navegar a través del
modelo para verificar que los objetos
pueden, de hecho soportar la
navegación. P.E., En el caso de uso
“comprar asientos”, ¿puede obtener el
nombre del evento que se debería
imprimir en el boleto?.
CAL/Fundamentos 88

Prueba De Clases Ejemplo
1. Para cada evento buscar todos las
presentaciones.
2. Para cada presentación buscar
mapaasientospresentación.
3. Para cada mapaasiento buscar
asientopresentación.
4. Por cada asientopresentación buscar boleto.
5. Obtener el precio pagado por cada boleto.

CAL/Fundamentos 89

Prueba De Clases
Evento

1

1
0..*
1 1
Presentación MapaAsientosPresentación

1

3
2
0..*

Asiento Presentación

1

Navegación utiliza
4
0..1

Boleto

5
CAL/Fundamentos 90

Prueba De Clases
 Durante la prueba de navegación del
caso de uso, notará algunas veces que
la ruta para responder en muy larga. No
se preocupe, durante el diseño, se
optimizará el modelo usando atajos
llamados asociaciones derivadas.

CAL/Fundamentos 91

Reconociendo Patrones
 Resumen: tres formas de comparación
entre diagramas:
 Concordar los diferentes diagramas puede
ser la forma mas efectiva de mejorar sus
modelos. La revisión iterativa, el
refinamiento y el mejoramiento mantienen
el proceso y remueven cualquier elemento
de pérdida de información.

CAL/Fundamentos 92

 Patrones de reconciliación:
 Casos de uso y escenarios.
 Casos de uso y diagramas de clases.
 Diagrama de clases y diagramas de interacción
(secuencia).
 Escenarios y diagramas de interacción.
 Diccionario de datos y casos de uso.
 Diccionario de datos y diagrama de clases.
 Diagrama de objetos y diagrama de clases.

CAL/Fundamentos 93

 Recordar que nada es inmutable, todo
debiera ser cuestionado y probado .
Utilice los diagramas como
herramientas (mas que como fines) y
aliente la participación retando al
equipo a ver el problema.

CAL/Fundamentos 94

 El modelado de objetos involucra el uso
de diferentes diagramas para
representar aspectos diferentes del
dominio del problema. La comparación
y contraste de estas diferentes vistas
ayudan a revelar discrepancias y son
oportunidades para mejorar y refinar.

CAL/Fundamentos 95

 Se hace mejor el análisis creando
rápidamente dibujos iniciales (borradores) de
todos los diagramas. No se preocupe de que
su análisis sea 100% correcto ni completo .
Utilice los diagramas como una referencia
para conversar; Actualice a medida que se
identifican cambios. Capture el conocimiento
inmediatamente para hacerlos disponible a
todos en el proyecto.

CAL/Fundamentos 96

Sesion 5 1 diagrama de secuencia

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Andere mochten auch

Andere mochten auch (6)

Ähnlich wie Sesion 5 1 diagrama de secuencia

Ähnlich wie Sesion 5 1 diagrama de secuencia (20)

Mehr von Julio Pari

Mehr von Julio Pari (20)

Sesion 5 1 diagrama de secuencia