Diagrama de Secuencia

Análisis y Diseño de
Sistemas Orientado a Objeto
Captura y Análisis de Requerimiento

Análisis y Diseño Orientado a Objeto
Diagramas UML para Análisis

Diagramas UML para Análisis :
Diagramas de Interacción
 Diagramas de Interacción
 ¿Para qué sirven?
 Para mostrar la relación entre los distintos
objetos que participan en un escenario
 La relación se establece mediante el paso
de mensajes
 Existen dos tipos
 Diagramas de Secuencia
 Diagramas de Colaboración
 Usos comunes
 Modelar los aspectos dinámicos de un sistema.
 El uso de estos diagramas es en el contexto del
sistema como un todo, un subsistema, una
operación, o una clase.
 Podemos unir diagramas de interacción para
casos de uso (para modelar un escenario) y
para colaboraciones (para modelar los aspectos
dinámicos de una sociedad de objetos).
 Usos comunes
 Cuando modelamos los aspectos dinámicos de un
sistema, usamos diagramas de interacción de dos
maneras:
 Para modelar flujos de control por orden de tiempo
 Se usan diagramas de secuencia. Se hace énfasis en el paso de
mensajes, en cómo se desenvuelven sobre el tiempo, lo cual es
una manera útil para visualizar el comportamiento dinámico en
el contexto de un escenario de un caso de uso.
 Para modelar flujos de control por organización
 Se usan diagramas de colaboración. Se hace énfasis en las
relaciones estructurales entre las instancias dentro de la
interacción y junto con los mensajes que pueden ser pasados.
 Los diagramas de colaboración hacen un mejor
trabajo para visualizar iteraciones y bifurcaciones
complejas y para visualizar flujos de concurrencia
múltiple de control.
 Sugerencias
 Un diagrama de interacción bien estructurado si:
 Esta enfocado en comunicar el aspecto dinámico de un sistema.
 Contiene solamente a los elementos que son esenciales para
entender ese aspecto.
 Provee un detalle coherente con sus niveles de abstracción y
debería revelar solamente los adornos que son esenciales para su
entendimiento.
 No es tan minimalista
 Cuando dibujamos un diagrama de interacción, debemos:
 Darle un nombre que comunique su propósito.
 Usar un diagrama de secuencia si queremos enfatizar el orden de
tiempo de los mensajes. Usar un diagrama de colaboración si
queremos enfatizar la organización de los objetos involucrados en
la interacción.
 Usar notas y color como indicaciones visuales para prestar atención
a características importantes de nuestro diagrama.
 Usar bifurcaciones limitadas; podemos representar mucho mejor
bifurcaciones complejas usando diagramas de actividad.
 Relación con los Casos de Uso
 Cada caso de uso es una telaraña de escenarios
 Primarios: Flujo normal del caso de uso y
 Secundarios: Flujos excepcionales y alternativos.
 Para un caso de uso podemos definir diferentes instancias
(escenarios) que nos ayudan a la identificación de objetos,
clases e interacciones entre objetos necesarios para llevar a
cabo la parte de funcionalidad que especifica el caso de uso.
 El flujo de eventos de un caso de uso se puede representar por:
 Especificación texto más,
 Distintos escenarios especificados mediante diagramas de interacción,
 Cada diagrama será una visión gráfica de un escenario.
 Los diagramas de interacción se deben usar cuando se quiere
 Analizar el comportamiento de varios objetos dentro del mismo caso
de uso,
 Mostrar colaboraciones entre objetos.
 En otro caso, si se quiere
 Mostrar comportamiento de un único objeto (en varios casos de uso),
utilizar los diagramas de estados.
 Mostrar el comportamiento de una sociedad de objetos (en varios
casos de uso) habrá que considerar un diagrama de actividades.
Diagramas UML para Análisis:

Interacción: Secuencia
 Definición según OMG
 "Un diagrama que representa una interacción poniendo
el foco en la secuencia de los mensajes que se
intercambian, junto con sus correspondientes
ocurrencias de eventos en las líneas de vida.”
 "A diferencia de un diagrama de comunicación, un

diagrama de secuencias incluye secuencias de tiempo
pero no incluye relaciones de los objetos. Un diagrama
de secuencias puede existir en una forma genérica
(describe todos los escenarios posibles) y en una forma
de instancia (describe un escenario actual). Los
diagramas de secuencias y los diagramas de
comunicación expresan información similar, pero la
muestran de diferentes formas."

 Un diagrama de secuencia muestra las interacciones entre
objetos ordenadas en secuencia temporal.
 Muestra los objetos que se encuentran en el escenario y la
secuencia de mensajes intercambiados entre ellos para
ejecutar la funcionalidad descrita por el escenario.
 Los diagramas de secuencia, se utilizan con frecuencia para
validar los casos de uso.
 Documentan el diseño desde el punto de vista de los casos de
uso. Observando qué mensajes se envían a los objetos,
componentes o casos de uso y viendo a grosso modo cuanto
tiempo consume el método invocado,
 Ayudan a comprender los cuellos de botella potenciales, para
así poder eliminarlos.
 A la hora de documentar un diagrama de secuencia resulta
importante mantener los enlaces de los mensajes a los
métodos apropiados del diagrama de clases.

 Elementos de un
Diagrama de Secuencia
 Actor: Es el equivalente al
actor que identificamos en
el caso de uso que se
quiere representar con el
diagrama de secuencia
 Gráficamente Igual Usuario

 Línea de Vida
 Una línea de vida es un participante
individual en una interacción
 No tienen multiplicidad!!!.
 Las líneas de vida están disponibles en
los diagramas de Secuencias y de
Tiempos, y aunque la representación
difiere entre los dos, el significado de la
línea de vida es el mismo.

 Línea de Vida
 Definición según OMG
 Una línea de vida representa un
participante individual en la Interacción.
Mientras las Partes y Características de
Estructuras pueden tener multiplicidades
mayores a 1, las Líneas de Vida
representan solamente una entidad
interactuante. La línea de vida es una
especialización de un Elemento nombrado.

 Línea de Vida
 Representación Gráfica Objeto1
 No tiene Sentido
Representarla sino
está asociada a la
representación de un
Objeto Línea de
Vida

 Mensajes
 Indican un flujo de información o
transición del control entre elementos.
 Se pueden utilizar por todos los
diagramas de interacción.
 Corresponden en el modelo de software
a operaciones y comportamientos de
clases. Son semánticamente similares a
los mensajes pasados entre elementos
en un diagrama de Comunicación.

 Mensajes
 Propiedades:
 Condiciones
 Indican qué debe ser verdadero para que el mensaje
se envíe
 Valor de retorno
 Sincronización
 Frecuencia
 Creación (Ciclo de Vida)
 Se utiliza Nuevo o Crear Nuevo para la creación de
elementos
 Eliminar o Destruir para la destrucción de elementos

 Mensajes
 Representación
Gráfica Objeto1 Objeto2
 Posee distintos
tipos de Mensaje1
Mensaje2 <<llamada>>
representación Mensaje <<Respuesta>>

Mensaje <<Nuevo>>
Objeto3
dependiendo del Mensaje3 <<llamada>>
tipo de mensaje Mensaje <<Destruir>>
al que
corresponda

 Mensajes Objeto1 Objeto2
 Flujos Alternativos
 Los diagramas de
secuencia Mensaje1
permiten mostrar
flujos alternativos {X > 10 }
en base a una
condición Lógica Mensaje2

 Mensajes
 Automensajes
 Un auto mensaje refleja un nuevo proceso
o método que se invoca dentro de la
operación de la misma línea de vida. Es una
especificación de un mensaje.
 Auto Mensaje como Retorno
 Es posible describir un retorno desde la
llamada de un auto mensaje.

 Mensajes Objeto
 Automensajes
 Graficamente
Mensaje4
Mensaje5

 Mensajes Objeto2
 Mensajes Recurrentes
 Indican
Recursividad. No es
lo mismo que un Mensaje4
automensaje

 Límites (boundary)
 Un límite es una clase estereotipada que
modela algunos límites del sistema
 Normalmente una pantalla de interfaz de
usuario.
 Se usa en la fase conceptual para
capturar usuarios interactuando con el
sistema a un nivel de pantalla (o algún
otro tipo de interfaz de límite).

 Límite
 Gráficamente
 Interacción Necesaria
con Actor

 Entidad
 Una entidad es un
almacén o
mecanismo de
persistencia que
captura la
información o el
conocimiento en un
sistema.
 Gráficamente

 Notas y Restricciones
 Sirven para hacer una Objeto3 Objeto5
especificación en caso
de tener estructuras
repetitivas o bien { Repetir
Mensaje3
para aclarar ciertas Hasta Nro Msg = 10}
interacciones
 Restricciones «requisito» Mensaje6
especiales a clases o
Una vez que han
terminado de enviarse
mensajes también
los mensajes anteriores
pueden ser incluidas


 Modelando flujos de control por orden de tiempo
(Secuencia)
 Establecer el contexto para la interacción (sistema, subsistema,
operación, clase o escenario de un caso de uso o colaboración).
 Establecer el escenario para la interacción identificando cuáles objetos
juegan un rol en la interacción.
 Poniéndolos en el diagrama de secuencia de izquierda a derecha,
colocando los objetos más importantes y a sus objetos vecinos a la
derecha.
 Establecer la línea de vida para cada objeto.
 En muchos casos los objetos persistirán a través de toda la interacción.
 Para objetos que son creados y destruidos durante la interacción,
indicar su nacimiento y su muerte con mensajes estereotipados
adecuados.
 Empezar con los mensajes que inician esta interacción
 Poner cada mensaje subsecuente de arriba hacia abajo entre las líneas
de vida, mostrando cada propiedad del mensaje.
 Indicar, si se necesita, en cada mensaje con una marca de tiempo y
unir restricciones de tiempo o espacio adecuadas.

 Ejemplo: Solicitud
de Préstamo Sistema
 Mto Máximo del Entregar
Préstamo c/s Aval

include Informacion Financiera
 Primero Trata sin Solicita Prestamo

«extends»
Entregar Inf
aval Cliente Financiera AVAL Entregar o

Rechazar Crédito
 Sólo para clientes Obtener Datos del
del banco
Aval «extends»
Evalúa Crédito
 El Aval puede no
include Ejecutivo
Obtener Datos del
ser cliente
Cliente

 Ejercicio
 Se requiere realizar el analisis y diseño
(considerando Casos de Uso, Diagrama
Conceptual (Clases) y Diagramas de
Secuencia) para un punto de venta en un
supermercado.
 Este punto de venta es un sistema
automatizado con el que se registran las
ventas y se realizan los pagos (efectivo o
tarjeta de crédito)

 Ejercicio
 Por lo general este tipo de sistemas
comprenden hardware (un computador y
un lector de código barras) y software (el
sistema que se ejecuta en el POS).
 A modo de ayuda se establecen:
 Panorama General
 Metas
 Funciones del Sistema (sólo su definición)

 Panorama general
 Este proyecto tiene por objeto crear un sistema de
terminal para un punto de venta que se utilizará en
las ventas de un supermercado.
 Metas
 En términos generales, la meta es una mayor
automatización del pago en las cajas registradoras, y
dar soporte a servicios más rápidos, más baratos y
mejores. Concretamente, la meta incluye:
 Pago rápido de los clientes.
 Análisis rápido y exacto de las ventas.
 Control automático del inventario

 Funciones del sistema
 Las funciones del sistema serán lo que éste deberá
hacer.
 Las funciones pueden clasificarse en tres categorías:
 Evidentes.
 Las evidentes deben realizarse, y el usuario debe saber que se han
realizado.
 Ocultas
 Las ocultas también deben realizarse, y puede que no sean visibles
para el usuario.
 Superfluas
 Las superfluas son opcionales, y su inclusión no repercute
significativamente en el costo ni en otras funciones.

Ref. Función Categoría

R1.1 Registra la venta en proceso (actual): los productos comprados. evidente
R1.2 Calcula el total de la venta actual; se incluye el impuesto. evidente
R1.3 Captura la información sobre el objeto comprado usando su código
de barras, o usando una captura manual del código de producto. evidente
R1.4 Reduce las cantidades del inventario cuando se realiza una venta. oculta
R1.5 Se registran las ventas efectuadas. oculta
R1.6 El cajero debe introducir una identificación y una contraseña para
poder utilizar el sistema. evidente
R1.7 Ofrece un mecanismo de almacenamiento persistente. oculta
R1.8 Ofrece mecanismos de comunicación entre los procesos y entre
los sistemas. oculta
R1.9 Muestra la descripción y el precio del producto registrado. evidente
Análisis y Diseño de
Sistemas Orientado a Objeto
Captura y Análisis de Requerimiento

Diagrama de Secuencia

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Diagrama de Secuencia

Uploaded by

Copyright:

Available Formats

Análisis y Diseño de

Sistemas Orientado a Objeto

Captura y Análisis de Requerimiento

Diagramas UML para Análisis

Diagramas UML para Análisis :

Diagramas UML para Análisis :

Diagramas UML para Análisis :

Diagramas UML para Análisis :

Diagramas UML para Análisis :

Diagramas UML para Análisis:

 "A diferencia de un diagrama de comunicación, un

Diagramas UML para Análisis:

Diagramas UML para Análisis:

Diagramas UML para Análisis:

Diagramas UML para Análisis:

Diagramas UML para Análisis:

Diagramas UML para Análisis:

Diagramas UML para Análisis:

Diagramas UML para Análisis:

representación Mensaje <<Respuesta>>

dependiendo del Mensaje3 <<llamada>>

tipo de mensaje Mensaje <<Destruir>>

Diagramas UML para Análisis:

 Mensajes Objeto1 Objeto2

Diagramas UML para Análisis:

Diagramas UML para Análisis:

Diagramas UML para Análisis:

Diagramas UML para Análisis:

Diagramas UML para Análisis:

Diagramas UML para Análisis:

Diagramas UML para Análisis:

para aclarar ciertas Hasta Nro Msg = 10}

pueden ser incluidas

Diagramas UML para Análisis:

Diagramas UML para Análisis:

 Mto Máximo del Entregar

Préstamo c/s Aval

 Primero Trata sin Solicita Prestamo

aval Cliente Financiera AVAL Entregar o

 Sólo para clientes Obtener Datos del

Diagramas UML para Análisis:

Diagramas UML para Análisis:

Diagramas UML para Análisis:

Diagramas UML para Análisis:

Diagramas UML para Análisis:

Ref. Función Categoría

Captura y Análisis de Requerimiento

You might also like