1-Bucles_y_Caminos_Alternativos_en_DSS_y_en_DSD_v1_08 - Andrés López

Vista previa del material en texto

Bucles y Caminos Alternativos en DSS y en DSD - Dis eño de Sistemas 
Autor: E. Porta - S. Dotti - L. Ripani Versión: 1.08 [<18-03-2010>] 
 Diseño de Sistemas – UTN FRR 
 
 
1 / 9 
 
Bucles y Caminos Alternativos en DSS y en DSD 
Diseño de Sistemas 
 
UML 2 utiliza marcos para representar las estructuras de condicionales (alt), de opcionales 
(opt) y de bucles (loop) en los diagramas de secuencia. Esto permite dibujar diagramas de 
secuencia con bucles y con caminos alternativos. 
 
Un DSS para todos los escenarios 
Según una directriz del libro de Larman, hay que dibujar un DSS para el camino básico, y un 
DSS para cada uno de los escenarios complejos de los Casos de Uso. 
A partir de la incorporación de los marcos en UML 2, se puede hacer un DSS que incluya a 
todos los escenarios, por eso la cátedra adopta hacer un solo DSS por caso de uso, a 
diferencia de lo que recomienda Larman (Ver referencias al final del documento). 
 
Representación del operador del marco 
 
Para indicar el operador del marco, UML propone poner el operador en el Angulo superior 
izquierdo como se ve en la siguiente figura. Al dibujar manualmente un diagrama de secuencia, 
se debe respetar dicha forma. 
 
 
En caso de utilizar Rational XDE, que no soporte marcos, se permitirá utilizar una nota para 
poner el operador como se ve en la siguiente figura (ver ejemplos en este documento). 
 
 
Representación de un actor 
 
Para indicar un actor, UML propone utilizar la siguiente notación: 
 
 
Además, UML propone utilizar como notación alternativa la siguiente: 
 
Al dibujar manualmente el DSS, se debe respetar alguna de dichas notaciones. 
 
En caso de utilizar Rational XDE se permitirá utilizar la siguiente notación (ver ejemplos en este 
documento). 
 
 
 
 
Bucles y Caminos Alternativos en DSS y en DSD - Dis eño de Sistemas 
Autor: E. Porta - S. Dotti - L. Ripani Versión: 1.08 [<18-03-2010>] 
 Diseño de Sistemas – UTN FRR 
 
 
2 / 9 
 
Caminos alternativos que no afectan al DSS 
 
Existen caminos alternativos que no afectan a la interacción Actor- Sistema, y solo originan 
cambios en el comportamiento interno del sistema, y en consecuencia no afectan al DSS. 
 
Ejemplo del caso de uso Devolución de ejemplares de los libros, que contiene caminos 
alternativos que no afectan a la interacción Actor- Sistema 
 
Caso de Uso: Devolución de ejemplares de los libros 
Nivel de la meta: Usuario Alcance del Caso de Uso: Sistema 
Caja: Negra Instanciación: Real Interacción: Dialogal 
 
ACTORES Primario: Socio Iniciador: Bibliotecario 
 
PRECONDICIONES: (de sistema): El sistema tiene el o los préstamos del Socio registrados 
DISPARADOR: El socio se presenta en el mostrador con los ejemplares de los libros. 
 
FLUJO DE SUCESOS: 
CAMINO BÁSICO: 
1. El bibliotecario ingresa la identificación del socio. 
2. El sistema: 
a. valida que el socio exista 
b. muestra el apellido y nombre del socio y de los libros que tiene pendiente de 
devolución 
c. muestra la identificación del ejemplar y el título del libro. 
3. El bibliotecario selecciona (dentro de los que muestra el sistema en el paso anterior) los 
ejemplares de los libros que devolvió el Socio e indica que se registre la devolución. 
4. El sistema: 
a. registra la devolución de los ejemplares 
b. emite un comprobante de la devolución. 
5. El bibliotecario le entrega el comprobante al Socio. 
 
 
CAMINOS ALTERNATIVOS: (Se considera un único camino alternativo para simplificar el ejemplo) 
 4.a. <posterior> Hay ejemplares devueltos fuera de término. 
 4.a.1. El Sistema calcula y registra la sanción 
 
 
Nota: 
En este caso el diagrama de secuencia de diseño (DSD) tendrá que contemplar al paso 
4.a.1, y se deberá utilizar un marco Opt . 
 
 
 
 
Bucles y Caminos Alternativos en DSS y en DSD - Dis eño de Sistemas 
Autor: E. Porta - S. Dotti - L. Ripani Versión: 1.08 [<18-03-2010>] 
 Diseño de Sistemas – UTN FRR 
 
 
3 / 9 
 
Ejemplos de DSS con caminos alternativos 
 
Ejemplo 1 – Caso de Uso Reservar Cabaña (Examen Final Práctica 24/11/2008) 
 
Caso de Uso: Reservar Cabaña Nivel de la meta: Usuario 
Alcance del Caso de Uso: Sistema Caja: Negra 
Instanciación: Real Interacción: Dialogal Usabilidad: No contemplada 
ACTORES Primario: Cliente Iniciador: Recepcionista 
PRECONDICIONES: (de sistema): 
DISPARADOR: El Cliente llama por teléfono o se presenta en las oficinas a realizar una reserva 
 
FLUJO DE SUCESOS: 
CAMINO BÁSICO: 
1. El Recepcionista ingresa tipo y número de documento. 
2. El Sistema 
2.1 valida que exista el cliente 
2.2 muestra el tipo y número de documento, la fecha de nacimiento, el nombre y el 
apellido del cliente 
3. El Recepcionista ingresa la fecha de inicio y la fecha de fin de la reserva 
4. El Sistema 
4.1 valida que el período pertenezca a una sola temporada 
4.2 muestra la descripción de la temporada 
4.3 recupera las cabañas que estén disponibles para el período ingresado 
4.4 muestra el código de la cabaña, el precio y la descripción de sus 
características. 
 
5 El Recepcionista selecciona una cabaña y confirma la reserva 
6 El Sistema 
6.1 registra la reserva 
 
CAMINOS ALTERNATIVOS: 
2.2.a – El cliente no existe 
 2.2.a.1. El Recepcionista ingresa tipo y número de documento, nombre, apellido, 
fecha de nacimiento, mail, domicilio y teléfono 
 2.2.a.2. El Sistema registra el nuevo cliente 
 2.2.a.3. Sigue en paso 3 
 
4.2.a. El período ingresado en punto 3 pertenece a dos temporadas 
 4.2.a.1. Muestra mensaje con situación 
 4.2.a.2. Termina el caso de uso 
 
4.4.a. No hay cabañas disponibles 
 4.4.a.1. Muestra mensaje con situación 
 4.4.a.2. Termina el caso de uso 
 
 
POSTCONDICIONES: (de sistema) 
Éxito: La reserva quedó registrada 
Éxito Alternativo: El cliente quedo registrado. La reserva quedó registrada 
Fracaso: No se registro la reserva 
 
 
 
Bucles y Caminos Alternativos en DSS y en DSD - Dis eño de Sistemas 
Autor: E. Porta - S. Dotti - L. Ripani Versión: 1.08 [<18-03-2010>] 
 Diseño de Sistemas – UTN FRR 
 
 
4 / 9 
 
DSS Caso de Uso Reservar Cabaña (Examen Final Práctica 24/11/2008) 
 
-------------------------------------------------------------------------------------------------------------
-----------------------------------------------------------------------------------------------------
-------------------------------------------------------------------------------------------------------------
 : Sistema
 : Recepcionista
1 : identificarCliente ( tipoDocumento , 
nroDocumento ) 
tipoDocumento + nroDocumento + 
fechaNacimiento + nombreCliente + 
apellidoCliente
Mensaje "El cliente no existe"
Mensaje "El período pertenece a dos 
temporadas"
Mensaje "No hay cabañas disponibles"
descripcionTemporada + { codigo
Cabaña + precio + descripcion
Características }
4 : registrarReserva ( codigoCabaña ) 
Mensaje "Reserva registrada con éxito"
2 : registrarCliente ( tipoDocumento , 
nroDocumento , fechaNacimiento , 
nombreCliente , apellidoCliente , email 
, domicilio , telefono ) 
3 : obtenerCabañas ( fechainicio , 
fechafin ) 
Mensaje "Cliente registrado con éxito"
[Cliente existe]
[Cliente no existe]
Alt
Alt
Alt
[período pertenece a dos temporadas]
[No hay cabañas disponibles]
[Hay cabañas disponibles]
[período pertenece a una temporada]
 
 
Bucles y Caminos Alternativos en DSS y en DSD - Dis eño de Sistemas 
Autor: E. Porta - S. Dotti - L. Ripani Versión: 1.08 [<18-03-2010>] 
 Diseño de Sistemas – UTN FRR 
 
 
5 / 9 
 
Ejemplo 2 – Registrar servicio a un cliente (Examen Final Práctica 15/12/2008) 
 
Caso de Uso: Registrar servicio a un cliente 
Nivel de la meta: Usuario / Alcance del Caso de Uso: Sistema / Caja: Negra 
Instanciación: Real / Interacción: Dialogal 
ACTORES Primario: Supervisor Iniciador: Encargado 
PRECONDICIONES:(de sistema): <omitidas> 
 
DISPARADOR: El supervisor llega a la Administración a informar un servicio realizado por uno 
o varios empleados a un Cliente. 
 
FLUJO DE SUCESOS: 
CAMINO BÁSICO: 
1. El Encargado ingresa la fecha 
2. El sistema: 
2.1 muestra el CUIT y la razón social de los clientes con contrato vigente a esa fecha 
 
3. El Encargado ingresa el CUIT del cliente 
4. El sistema: 
4.1 valida que el contrato del cliente este vigente para la fecha ingresada 
4.2 muestra razón social, situación impositiva, teléfono y dirección del cliente. 
4.3 valida que para esa fecha no se hayan ingresado servicios para ese cliente 
 
5. El Encargado ingresa la identificación de un empleado y las horas trabajadas por él. 
6. El sistema: 
6.1 valida que no haya horas registradas en el cliente para el empleado y fecha ingresados 
6.2 muestra el apellido y nombre del empleado 
6.3 valida que ese empleado este en el contrato del cliente 
6.4 muestra el importe a cobrar por el empleado (ver R.N. 7) 
 
 Se repiten los pasos 5 a 6 hasta que el encargado da por finalizada la operación. 
 
7. El Encargado da por finalizada la operación. 
8. El Sistema, registra el servicio realizado. 
 
CAMINOS ALTERNATIVOS: 
 
2.1.a No hay contratos vigentes para la fecha ingresada: 
2.1.a.1. El Sistema muestra mensaje informando situación, y Termina el caso de uso 
 
 
4.1.a El contrato no está vigente para la fecha ingresada: 
4.1.a.1. El Sistema muestra mensaje informando situación, y Termina el caso de uso 
 
 
4.3.a Ya hay servicios ingresados para la fecha ingresada en el paso 1: 
4.3.a.1. El Sistema muestra id, apellido y nombre de empleado, cantidad horas 
registradas, y si es permanente o suplente, para los empleados a los que ya se registraron 
horas trabajadas para la fecha y cliente ingresados 
4.3.a.2. Sigue en el paso 5 
 
 
6.1.a Ya hay horas registradas para el empleado y fecha ingresados: 
6.1.a.1. El Sistema recupera la cantidad de horas que estaban registradas en el cliente 
para el empleado y fecha ingresados 
6.1.a.2. El Sistema reemplaza las horas registradas, por la cantidad ingresada en el 
paso 5 
6.1.a.3. El Sistema muestra la cantidad de horas que estaban registradas, la cantidad 
por la que fueron modificadas, y mensaje indicando que han sido reemplazadas (ver R.N. 8) 
6.1.a.4. Sigue en el paso 6.2 
 
6.3.a El empleado no está en el contrato del cliente: 
6.3.a.1. El Sistema registra al empleado como suplente en el contrato 
6.3.a.2. El Sistema muestra mensaje informando que se incorpora al empleado como 
suplente en el contrato 
6.3.a.3. Sigue en el paso 6.4 
 
POSTCONDICIONES: (de sistema) 
Éxito: El servicio quedó registrado 
Fracaso: El servicio no fue registrado 
 
Bucles y Caminos Alternativos en DSS y en DSD - Dis eño de Sistemas 
Autor: E. Porta - S. Dotti - L. Ripani Versión: 1.08 [<18-03-2010>] 
 Diseño de Sistemas – UTN FRR 
 
 
6 / 9 
 
DSS Caso de Uso Registrar servicio a un cliente (Examen Final Práctica 15/12/2008) 
-----------------------------------------------------------------------------------------------------
-----------------------------------------------------------------------------------------------------
 : Sistema : Encargado
1 : obtenerContratos ( fecha ) 
Mensaje "No hay contratos vigentes 
para la fecha ingresada"
{ CUIT + razonSocial }
2 : identificarCliente ( CUIT ) 
Mensaje "El contrato no está vigente 
para la fecha ingresada"
razonSocial + situacionImpositiva + 
telefono + direccion
3 : agregarJornadaEmpleado ( id
Empleado , horasJornada ) 
{idEmpleado + apellidoEmpleado + 
nombreEmpleado + horasRegistradas 
+ caracter}
apellidoEmpleado + nombreEmpleado
4 : registrarServicio ( ) 
horasPreviasRegistradas + horas
NuevasRegistradas
importeACobrar
Mensaje "Servicio registrado con éxito"
Mensaje "Se incorpora al empleado 
como suplente en el contrato"
Alt [No hay contratos vigentes para la fecha ingresada]
[Hay contratos vigentes para la fecha ingresada]
[El contrato no está vigente para la fecha ingresada]Alt
Opt [Ya hay servicios ingresados para esa fecha]
Loop
Opt [Hay horas registradas para ese empleado]
Opt [El empleado no está en el contrato del cliente]
[mas empleados]
 
 
Bucles y Caminos Alternativos en DSS y en DSD - Dis eño de Sistemas 
Autor: E. Porta - S. Dotti - L. Ripani Versión: 1.08 [<18-03-2010>] 
 Diseño de Sistemas – UTN FRR 
 
 
7 / 9 
 
Ejemplo 3 – Venta de Medicamentos (Examen Final Práctica 05/10/2009) 
 
Caso de Uso: Venta de Medicamento 
 
Nivel de la meta: Usuario - Alcance del Caso de Uso: Sistema 
Caja: Negra - Instanciación: Real - Interacción: Dialogal - Usabilidad: NO contemplada 
 
ACTORES Primario: Paciente Iniciador: Farmacéutico 
PRECONDICIONES: (de sistema): <omitidas> 
DISPARADOR: El paciente se presenta con una receta para realizar compra de medicamento 
FLUJO DE SUCESOS: 
CAMINO BÁSICO: 
 
1. El Farmacéutico ingresa código obra social y nro. afiliado del paciente 
2. El Sistema 
2.1 valida que el paciente no exceda cantidad máxima de recetas (ver RN 6) 
2.2 muestra el nombre obra social, nombre y apellido del paciente 
 
3 El Farmacéutico ingresa el nombre del medicamento 
4 El Sistema 
4.1 valida que exista el medicamento 
4.2 muestra las presentaciones posibles para el medicamento 
 
5 El Farmacéutico ingresa la presentación que corresponde a la receta, y el nro. matrícula del 
profesional 
6 El Sistema 
6.1 valida que exista el profesional 
6.2 muestra nombre medicamento, cantidad en existencia y precio del 
medicamento recetado 
6.3 muestra para los medicamentos sustitutos posibles que tengan cantidad en 
existencia mayor a cero: nombre medicamento y precio (ver RN 4) 
 
7 El Farmacéutico ingresa medicamento elegido y cantidad a comprar 
8 El Sistema 
8.1 Muestra importe a pagar por el paciente (ver RN 7) 
8.2 Registra la venta 
 
 
CAMINOS ALTERNATIVOS: 
 
2.1.a. El paciente excede la cantidad máxima de recetas permitidas 
 2.1.a.1 Muestra mensaje “El paciente excede la cantidad máxima de recetas permitidas” 
 2.1.a.2 Termina el caso de uso 
 
4.1.a. No existe el medicamento solicitado 
 4.1.a.1 Muestra mensaje “El medicamento solicitado no existe” 
 4.1.a.2 Vuelve al paso 3 
 
6.1.a. El profesional no existe 
 6.1.a.1 Muestra mensaje “El profesional no existe” 
 6.1.a.2 Termina el caso de uso 
 
Nota: Para simplificar se excluyen el resto de caminos alternativos 
 
POSTCONDICIONES: (de sistema) 
Éxito: La venta quedó registrada 
Fracaso: La venta no se registró 
 
 
Bucles y Caminos Alternativos en DSS y en DSD - Dis eño de Sistemas 
Autor: E. Porta - S. Dotti - L. Ripani Versión: 1.08 [<18-03-2010>] 
 Diseño de Sistemas – UTN FRR 
 
 
8 / 9 
 
DSS Caso de Uso Venta de Medicamentos (Examen Final Práctica 05/10/2009) 
--------------------------------------------------------------------------------------------------------------------
----------------------------------------------------------------------------------------------------------------
--------------------------------------------------------------------------------------------------------------
 : Sistema : Farmaceutico
1 : identificarAfiliado ( codObraSocial , 
nroAfiliado ) 
Mensaje "paciente exede cantidad de 
recetas maximas"
nombre + apellido + nombreObra
Social
2 : medicamentoSolicitado ( nombre
Medicamento ) 
Mensaje "El medicamento solicitado 
no existe"
1{ presentacion } n
3 : ingresarPresentacion ( 
presentacion , nroMatriculaProfesional 
) 
Mensaje "El profesional no existe"
medicamento+ cantidad en 
existencia+ precio +{medicamento 
sustituto + precio }
4 : ingresarMedicamento ( 
medicamento , cantAComprar ) 
importe
ALT
Loop
Alt
[paciente exede cantidad de recetas maximas]
[mientras no exista medicamento]
[El medicamento solicitado no existe]
[El medicamento solicitado existe]
Alt [El profesional no existe]
[El profesional existe]Bucles y Caminos Alternativos en DSS y en DSD - Dis eño de Sistemas 
Autor: E. Porta - S. Dotti - L. Ripani Versión: 1.08 [<18-03-2010>] 
 Diseño de Sistemas – UTN FRR 
 
 
9 / 9 
 
Referencias 
 
- Applying UML and Patterns: An Introduction to Objec t-Oriented Analysis and Design 
and Iterative Development, Third Edition 
 
 
- RUP ���� UML Basics > Differences Between UML 1.x and UML 2.0 
 
…. 
With the new capabilities to represent fragments, interaction occurrences and loops, 
sequence diagrams can be used in two forms: 
• Instance form: describes a specific scenario in detail, documenting one possible 
interaction, without conditions, branches, or loops. This form is used to represent 
one use case scenario. Different scenarios of the same use-case are 
represented in different sequence diagrams. Modeling tools that support UML 
1.x semantics only allow this form of representation. 
• Generic form: describes all possible alternatives in a scenario, taking advantage 
of new UML 2.0 capabilities like conditions, branches, and loops. This form can 
be used to represent several scenarios of the same use case in a unique 
sequence diagram, where it makes sense. 
 ….