Contenidos

Tema 3.
Casos de uso

Ingeniera del Software I

3 I.T.I.Gestin

3.1. Requisitos funcionales: los casos de uso

3.2. Descripcin y Construccin de los casos
de uso

3 3 Relaciones entre casos de uso.

3.3.
uso

3.4. Ventajas y peligros de los casos de uso

Miguel A. Laguna

3.5. Utilidad de la tcnica: el paso a los

objetos

Objetivos del tema

3.1

Identificar los actores y casos de uso

Representar en UML y textualmente los casos
de uso

Requisitos funcionales:
los casos de uso

Utilizar las relaciones <<include>> y

<<extend>>

Relacionar los casos de uso con otras

tcnicas de modelado de UML

Requisitos funcionales: Modelo de casos de uso

Representacin en UML
Definicin de caso de uso y escenario

Documentacin de requisitos

Tipos de requisitos

Visin

Se describe con casos de uso

Requisitos no funcionales

Funcionales: caractersticas del sistema

Catlogo de requisitos

Seguridad
Rendimiento
Fiabilidad
Facilidad de uso
etc

Objetivos
Restricciones, alcance del proyecto
Requisitos funcionales

Requisitos no funcionales
Reglas de negocio
Requisitos de informacin

Glosario

Modelo del dominio

Tambin Reglas del negocio (restricciones

legales, etc.) y Requisitos de informacin

Requisitos funcionales
Modelo de casos de uso,
uso describe en detalle los requisitos
funcionales

Terminologa bsica del dominio

Modelo de casos de uso

Modelo de casos de uso

Un Modelo de casos de uso describe los

requisitos funcionales (nivel sistema) desde el
punto de vista de cmo se usar la aplicacin
en la prctica diaria

Los casos de uso describen:

Un caso de uso representa una

interaccin tpica entre un usuario y un
sistema informtico:

el sistema (casos de uso)

el entorno del sistema (actores).
la relacin entre el sistema y su entorno

Los casos de uso capturan el

comportamiento deseado del sistema bajo
desarrollo, pero...
no especifican cmo se implementa ese
comportamiento

Utilidad de los casos de uso

UML: diagramas de casos de uso

Los casos de uso tienen tres papeles

fundamentales:

Capturar el detalle de los requisitos

funcionales del sistema
Simplificar la construccin de los modelos
de objetos
Servir de base para las pruebas del sistema

Un diagrama de casos de uso es un grafo con dos

tipos de nodos:

Actor - que representa cualquier elemento que

intercambia informacin con el sistema, por lo que est
fuera de l
Caso de uso - Es una secuencia de intercambios que
representan el dilogo entre el sistema y uno o varios
actores.
Tiene una descripcin informal en lenguaje natural o en
un lenguaje estructurado

Entre ellos hay relaciones de asociacin

Diagramas de Casos de uso

10

Notacin de los casos de uso

El usuario teclea la cantidad que quiere sacar

Los casos de uso se representan por una

elipse y un nombre, que puede ir dentro o
debajo de la elipse.

El sistema comprueba que tiene billetes suficientes

El sistema enva la peticin al banco emisor...

Sistema

Caso de uso X

Actor A
Actor B

Los actores se representan con el icono de

estereotipo estndar para casos de uso (el
stick man o monigote) con el nombre del
actor al pie de la figura. Los nombres de los
actores suelen empezar por mayscula.

Caso de uso Y
11

12

Definicin de casos de uso (I)

Una secuencia de acciones realizadas por el sistema,

que producen un resultado valioso para un actor en
particular

Una accin es p
procedimiento atmico. Se invoca
cuando:

Definicin de casos de uso (II)

Un resultado valioso:

el actor enva un estmulo al sistema

el sistema recibe un evento temporal

Realizadas por el sistema:

Una secuencia de acciones realizadas por el sistema,

que producen un resultado valioso para un actor en
particular

El sistema proporciona una respuesta (pero es una caja

negra)

Un actor en particular:

13

En realidad, la definicin corresponde a un

escenario o instancia del caso de uso:

Una secuencia particular de acciones que lleva a

un resultado valioso (o exito)
Tambin puede llevar a un resultado de fracaso

El actor suele ser una persona, pero se diferencia de

un usuario
Un actor representa un cierto papel que distintos
usuarios pueden jugar.

Un caso de uso es un conjunto de escenarios

(xitos y fracasos) relacionados por el
resultado que el actor pretende obtener

El actor
t sera
la
l clase
l
y ell usuario
i una instancia
i t
i de
d la
l clase.
l
Un mismo usuario podra ser instancia de varios actores.

Una mquina o un sistema tambin puede ser un

actor

El actor es la llave para encontrar casos de uso correctos

(Entrevistas, actividades asociadas a un actor...)
Un actor interacciona a travs de una instancia concreta del
caso de uso (escenario)
14

Actores y casos de uso

Escenarios y casos de uso

Un caso de uso debe asegurar que un actor pueda

desempear una tarea que tiene un valor
Esto es importante para determinar el nivel correcto para un
caso de uso (casos de uso que no son demasiado pequeos)

Incluso el tiempo (un cronmetro) puede ser un actor

La relacin entre escenario y caso de uso es

idntica a la que existe entre objeto y clase

15

3.2
Descripcin y Construccin de los
casos de uso

16

Descripcin de los Casos de uso

Descripcin: plantillas
El proceso de encontrar y construir los
casos de uso

Un caso de uso describe su objetivo (la funcionalidad

que se pretende) ms una interaccin entre un actor y
un sistema en forma de secuencia de estmulos y
respuestas
La descripcin se centra en lo que debe hacerse, no en
la manera de hacerlo
Deben evitarse expresiones imprecisas: sencillez y
claridad
Puede utilizarse un lenguaje estructurado (secuencia,
repeticiones y situaciones opcionales)

18

Casos de uso y caja negra

Formatos de descripcin

Incorrecto o Correcto?

El caso de uso se puede describir con varios

niveles de detalle:

El cajero pulsa la tecla Inicio

El sistema genera un registro en un fichero
de ventas
El cajero solicita iniciar una nueva venta
El sistema genera una sentencia SQL
El sistema registra la venta

Breve

Informal

Completo

Un resumen inicial en un par de frases

U conjunto
Un
j
de
d prrafos
f y alternativas
l
i
Con todas las alternativas, pre y post-condiciones, etc.

Cf. Ejemplos del Larman

19

20

Formatos de descripcin

Descripcin de los Casos de uso

Por otro lado, se distinguen:

Casos de uso Esenciales

La descripcin debe contener:

El comportamiento del sistema sin entrar en

detalles tecnolgicos

Casos de uso Concretos

Con el detalle de la interfaz de usuario

Ser necesario ajustarlos a los requisitos no

funcionales de tipo tecnolgico antes de
completar el diseo de la capa de interfaz

Inicio del caso de uso

Fin del caso de uso
Interaccin entre el caso de uso y los actores
Intercambios de datos
Cronologa y origen de los datos

La descripcin se puede completar con

diagramas de secuencia o de transicin de
estados

21

22

Plantilla de casos de uso

(cabecera)

<Identificador> <nombre descriptivo>

Descripcin de los Casos de uso

Descripcin

Secuencia
Normal

Habitualmente se
utiliza una plantilla
se algn tipo:

Excepciones

El sistema deber permitir a [lista actores] en [instante en el que se

puede realizar el caso de uso] [funcionalidad que define el caso de uso]
segn se describe en el siguiente caso de uso:
Paso

Importancia
Urgencia
Comentarios

<nombre del requisito funcional>

Versin

<numero de versin y fecha>

Autores

<autor>

Fuentes

<fuente
f
de la versin actual>

Accin

Objetivos asociados

<nombre del objetivo>

En el caso de que [situacin que provoca la excepcin] el

sistema deber {<accin a realizar>, realizar el caso de uso
[caso de uso]}

Descripcin

El sistema deber comportarse tal como se describe en el

siguiente caso de uso { concreto cuando <evento de activacin>
, abstracto durante la realizacin de los casos de uso <lista de
casos de uso>}

<Situacin que produce una alternativa>

2a Si [Situacin que produce una alternativa] el sistema

deber {<accin a realizar>, realizar el caso de uso
[caso de uso]}
2b Si [Situacin que produce una alternativa] el sistema
deber {<accin a realizar>, realizar el caso de uso
[caso de uso]}
.

Paso

Frecuencia

RF- <id del requisito>

{<accin a realizar>, realizar el caso de uso [caso de uso]}

Rendimiento

Accin

q
El sistema deber realizar la/s accin /es descrita/s en {los pasos
[primer paso] al [ltimo paso], el paso [nmero de paso]} en un
mximo de [cota de tiempo]
Este caso de uso se espera que se lleve a cabo una media de [nmero de
veces] al [unidad temporal]
{vital, importante,quedara bien}
{inmediatamente, hay presin, puede esperar}
<otras consideraciones en formato libre>

23

24

Plantilla (pie)
Rendimiento

Paso

Plantilla (secuencia normal)

Cota de tiempo

Precondicin

<precondicin del caso de uso>

Paso

n segundos

Secuencia
Normal

n segundos

Frecuencia esperada

<n de veces> veces / <unidad de tiempo>

Importancia

{sin importancia, importante, vital}

Urgencia

{puede esperar, hay presin, inmediatamente}

Comentarios

<comentarios adicionales>

Accin
{El <actor> , El sistema} <accin realizada por el
actor o sistema>, se realiza el caso de uso
< caso de uso RF-x>
Si <condicin>,
> {el <actor> , el sistema} <accin
realizada por el actor o sistema>>, se realiza el caso
de uso < caso de uso RF-x>

3
4
5
6
n
Postcondicin

<postcondicin del caso de uso>

25

26

Descubrir y construir los Casos de uso

Plantilla (excepciones)
Excepciones

Paso

Es un proceso iterativo.
Se van descubriendo los escenarios desde el
punto de vista del ACTOR y sus objetivos y
actividades.

Pasos del proceso:

Accin

Si <condicin de excepcin>,{el <actor> , el

sistema} }<accin realizada por el actor o
sistema>>, se realiza el caso de uso
< caso de
d uso RF
RF-x>, a continuacin
ti
i este
t
caso de uso {continua, queda sin efecto}

...

27

Cliente

Actores principales y secundarios

Empresa
Tienda
TPDV

Recaudar
Comprar cosas

Gerente de
Ventas

Cajero

Analizar ventas
*Objetivos

Procesar venta

29

Diagrama de actividades

Fijar los lmites del sistema

Identificar los actores principales
Identificar los objetivos/actividades de cada actor
Definir (elaborar) cada caso de uso
28

Actores y lmites del sistema

Hacienda

1.
2.
3.
4.

La estructura del sistema debe decidirse teniendo en

cuenta a los actores principales:
Los actores principales utilizan directamente el
sistema
Los actores secundarios existen para que los
principales puedan utilizar el sistema
Pueden utilizarse tcnicas de observacin o entrevista
La mayora de los objetivos y actividades son obvios
(vender, cobrar, gestionar una devolucin...)

30

Preguntas

Ms preguntas

Para detectar todos los casos de uso, se puede

preguntar:

Escribe/lee/modifica el actor alguna informacin

del sistema?
Cules son las principales tareas de cada actor?

Informa el actor al sistema de los cambios

externos?

Desea el actor ser informado de cambios no

esperados?

Preguntas estndar para encontrar otros

actores y objetivos:

quin arranca el sistema?

quin gestiona los usuarios y la seguridad?
el sistema debe hacer algo cada cierto tiempo?
quin evala la actividad del sistema?
Cmo se actualiza el software?

31

32

Proceso de elaboracin

Resultado final (I)

Identificar a grandes trazos los casos de uso

Las principales etapas de cada caso de uso se
describen con un par de frases
Se distingue un camino principal y se identifican
los caminos alternativos y excepciones

Se debe cuidar que:

Proceso iterativo:

Los casos de uso se amplan, profundizndose en su

descripcin
Se buscan etapas comunes y alternativas que representar en
otros caso de uso relacionados por las relaciones incluye,
generaliza y extiende

Exista una descripcin breve que represente una

verdadera imagen del caso de uso
Las condiciones de arranque y parada, prepre y
postcondicin del caso de uso estn bien definidas
Los usuarios estn satisfechos de la secuencia de
interacciones entre el actor y el caso de uso

33

34

Resultado final (II)

El problema fundamental es encontrar el nivel de

abstraccin adecuado.

Escenarios y casos de uso

En general si un caso de uso se hace demasiado grande a

medida que se va detallando es conveniente dividirlo en
varios.

Se pueden hacer preguntas como:

es posible ejecutar un paso de forma independiente a los

otros o siempre va encadenado con ellos?
es lgico agrupar varios pasos para documentarlos,
probarlos o modificarlos en conjunto?

Un caso de uso tiene como instancias los escenarios:

Se deben considerar en lo p
posible todos los
escenarios de modo que se pueda validar el caso de
uso.

La ltima comprobacin consiste por tanto en asegurar que

el caso de uso represente todos los escenarios.

A veces se confunden casos de uso con escenarios:

35

situaciones concretas que pueden recorrer total o

parcialmente el caso de uso

Si aparecen muchos casos de uso puede que sea un sntoma

de una mala descripcin del sistema
36

CU-003
Descripcin

Casos de uso - Ejemplo

Secuencia
Normal

Sacar dinero
El sistema deber permitir al cliente del banco, en cualquier momento,
sacar dinero segn se describe en el siguiente caso de uso:
1+ El usuario inserta la tarjeta en el cajero
2 + El cajero lee el cdigo de la banda magntica de la tarjeta y verifica
si es aceptable y pide el cdigo del usuario
3+ El usuario introduce el cdigo
4 + Si el cdigo es correcto, el cajero pide al usuario que seleccione el
tipo de transaccin deseada
5+ El usuario selecciona la funcin sacar dinero,
6 + El cajero le pide al usuario que teclee la cantidad deseada
7 + El usuario teclea la cantidad que quiere sacar,
8 + El cajero enva la peticin al sistema del banco

sacar dinero

9 a Si conecta el sistema deber comprobar si hay dinero en la cuenta

usuario
9 b Si no conecta el sistema deber comprobar si el dinero es menos
que el lmite

sistema del banco emisor

Consulta de saldo

Excepciones

recarga mvil
operador

administracin

Compaa telefnica

Cajero automtico
37

Cajero automtico: secuencia normal

1

El sistema visualiza un mensaje de bienvenida en la pantalla

El usuario inserta la tarjeta en el cajero

El sistema lee el cdigo de la banda magntica de la tarjeta,

verifica si es aceptable

10 En cualquiera de los dos casos el sistema:

+ expulsa la tarjeta
+ imprime el recibo
+ entrega el dinero
2' La tarjeta no es aceptada
+ Se expulsa emitiendo un sonido
4' Cdigo incorrecto (1,2)
+ Se emite un mensaje dando al usuario la oportunidad de volver a
introducir el cdigo (paso 3)
4'' Cdigo incorrecto (3)
+ Se emite un mensaje y se retiene la tarjeta
9' No autorizado para sacar dinero
+ El sistema de banco no autoriza a sacar dinero. Se emite un
mensaje de informacin y se expulsa la tarjeta
9 a ', 9 b' No hay dinero suficiente
+ El cajero no dispone de la cantidad pedida. Emite un mensaje y
vuelve al paso 7
1..10' Cancelar
+ En cualquier momento el usuario puede cancelar la transaccin,
con lo que se expulsa la tarjeta

Cajero automtico: secuencia normal

10

El usuario teclea la cantidad que quiere sacar

11

El sistema comprueba que tiene billetes suficientes

12

El sistema cajero enva la peticin al sistema del banco emisor

El sistema pide el PIN al usuario

13

El banco emisor confirma que hay fondos

El usuario introduce el cdigo

14

El sistema imprime un recibo

El sistema valida el PIN

El sistema pide al usuario que seleccione el tipo de transaccin

deseada

15

El sistema expulsa la tarjeta

16

El sistema entrega el dinero

El usuario selecciona la funcin sacar dinero,

El sistema pide al usuario que teclee la cantidad deseada

39

Cajero automtico: excepciones

3
6
6

38

40

Casos de uso - Ejemplos

Si la tarjeta no es aceptada, el sistema la expulsa emitiendo un

sonido. El caso de uso termina.
Si el usuario introduce un cdigo errneo, el sistema pide de
nuevo el PIN y el caso de uso continua en el paso 5
Si el usuario introduce un cdigo errneo por tercera vez, el
sistema retiene la tarjeta y el caso de uso termina.

Monitor
cardiaco

Disparo si algo
est fuera
de lo normal

11

Si el sistema no tiene suficiente dinero, emite un mensaje y el

caso de uso continua en el paso 9

13

Si el banco emisor no autoriza a sacar dinero, el sistema emite un

mensaje de informacin y el caso de uso continua en el paso 7

13

Si no se consigue comunicacin y la cantidad excede del lmite

mximo, el sistema emite un mensaje de informacin y el caso de
uso continua en el paso 9

MonitorRemoto

Paciente

Mdico

...

Impresin
impulsos card.
Almacn de
diagramas

Sistema que controla la actividad cardiaca de un paciente.

41

42

Relaciones entre Casos de uso: UML

3.3
Relaciones entre casos de uso.

Incluye (<<incluye>>) (<<include>>)

Generalizacin (sin estereotipo)

Incluye
Generaliza
Extiende

Es un estereotipo de dependencia. Indica que un caso de uso es

incluido dentro de otro.

Indica que un caso de uso es una variante de otro.

otro
Tambin se usa entre actores para indicar que un actor hereda
el comportamiento de otro y aade nuevas posibilidades

Extiende (<<extiende>>) (<<extend>>)

Es un estereotipo de dependencia. Ofrece una forma de

extensin ms controlada que la relacin de generalizacin.

44

Relacin Incluye

Resumen de los tipos de relaciones

Relacin
Asociacin

Extiende

Generalizacin

Incluye

Funcin
Camino de comunicacin
entre un actor y un caso de
uso en el que participa
Insercin de comportamiento
adicional en un caso de uso
base (sin que ste tenga
conocimiento)
Relacin entre un caso de uso/actor
general y otro ms especfico
que hereda caractersticas y
aade otras
Insercin de comportamiento
adicional dentro de un caso de
uso que describe la insercin

Notacin

<<extiende>>

Es una relacin de dependencia donde un caso de

uso utiliza otro caso de uso completo, indicando que
se incrusta en el primero.
Cuando un nmero de casos de uso comparten un
comportamiento comn, se extrae en un caso de uso
que es utilizado (<<include>>) por otros.

<<incluye>>

El caso de uso incluido es el factor comn.

Si el caso de uso nunca se utiliza por s mismo se denomina
caso de uso abstracto.

45

46

Relacin Incluye

Relacin Incluye

<<include>>
Comprobar tarjeta y
PIN
Sacar dinero

<<include>>

Actor
Consultar saldo

47

El sistema visualiza un mensaje de bienvenida en la pantalla

El usuario inserta la tarjeta en el cajero

El sistema lee el cdigo de la banda magntica de la tarjeta,

verificaSe
si esrealiza
aceptable el caso de uso

El sistema pide el PIN al usuario

<Comprobar
tarjeta
El usuario
introduce el cdigo

y PIN>

El sistema valida el PIN

El sistema pide al usuario que seleccione el tipo de transaccin

deseada

El usuario selecciona la funcin sacar dinero,

El sistema pide al usuario que teclee la cantidad deseada

48

Relacin de Generalizacin

Comprobar tarjeta y PIN

Caso de uso UC-00X
Comprobar tarjeta y PIN
1

El sistema lee el cdigo de la banda magntica de la

tarjeta, verifica si es aceptable

El sistema pide el PIN al usuario

d
ell cdigo
d
Ell usuario introduce

El sistema valida el PIN

Indica que un caso de uso es una variante de otro.

El caso de uso especializado puede variar cualquier

aspecto del caso de uso base:
Cuando un caso de uso extiende otro, significa que el primero
puede incluir parte del comportamiento del caso de uso que l
extiende.

Excepciones
1
4
4

Si la tarjeta no es aceptada, el sistema la expulsa

emitiendo un sonido. El caso de uso termina.
Si el usuario introduce un cdigo errneo, el sistema pide
de nuevo el PIN y el caso de uso continua en el paso 2
Si el usuario introduce un cdigo errneo por tercera vez,
el sistema retiene la tarjeta y el caso de uso termina.

No tiene porque incluir el comportamiento completo; pudiendo

elegir que partes se quieren reutilizar.

Es una relacin muy (demasiado?) flexible.

49

50

Relacin Extiende

Relacin de Generalizacin

Es una relacin de dependencia donde un caso de uso

aade acciones al caso de uso base.

Cliente Internet

Transferencia por
Internet

Cliente

Giro
Transferencia

El caso de uso base declara un conjunto de puntos de

extensin
extensin.
El caso de uso especializado slo puede alterar el
comportamiento de los puntos de extensin marcados.

El cliente por Internet tambin puede hacer una

transferencia convencional en cualquier sucursal

51

Si hay ms de uno, hay que identificar exactamente cul es es

punto extendido.

Un caso de uso extendido puede manejar excepciones,

alternativas, etc.
52

Relaciones entre Casos de uso:

Extiende

Generaliza y Extiende

Procesar Venta
Process Sale

Puntos de Extensin :
Forma de Pago
Cliente VIP

transferencia por internet

Cashier

extend
extend
t d

extend Forma de Pago,

transferencia
Giro

extend

si el Cliente desea
pagar con cupones....
Pago con Cupn
de regalo

Customer

Handle Check
Payment
extend

Handle Cash
Payment
extend

actor
Accounting
g
System

Handle Credit
Payment
extend

actor
Credit
Authorization
Service

Process Rental

53

54

Relaciones entre Casos de uso:

Incluye (condicionalmente)

Relaciones entre Casos de uso

Si el cliente paga en efectivo, se realiza el caso de uso <Handle Cash Payment >

<<extend>>

Si el cliente paga por cheque, se realiza el caso de uso <Handle Check Payment >

transferencia local

Si el cliente paga con tarjeta, se realiza el caso de uso <Handle Credit Payment >

Cliente

<<extend>>
Process Sale
Cashier

include

include
include

Customer

Handle Check
Payment
include

Handle Cash
Payment

transferencia
por Internet

actor
Accounting
System

transferencia
<<include>>

Handle Credit
Payment
actor
Credit
Authorization
Service

include
include

Identificacin

Process Rental
55

56

Casos de uso - Ejemplos

Casos de uso - Ejemplos

Venta por catalogo telefnico

Comprobacin del
estado

Peticiones al
catlogo con
pedidos

Vendedor

Realizacin de un
pedido
Orden de pago

Realizacin de un
pedido
Atencin al
Cliente
Completar pedido

Empleado

Informacin
suministrada por el
Cliente

Pedido de productos

Establecer crdito
Supervisor

57

58

Casos de uso: Ventajas

3.4.
Ventajas y peligros de los casos
de uso

Ayudan a asegurar que se desarrolla el sistema correcto

Excelente forma de comunicacin con los clientes y los
usuarios
Ayudan a gestionar la complejidad de los proyectos
grandes

Ofrecen una buena base para la verificacin y validacin

Modo objetivo para el seguimiento del proyecto

60

10

Casos de uso: Peligros

Casos de uso: Ventajas tcnicas

Documentan las respuestas funcionales de

caja negra

Llevan a una descomposicin funcional del

sistema.

Los casos de uso son funcionales por naturaleza (esto

es, localizan la informacin en torno a las funciones).

Proporcionan el fundamento de los mensajes

Debe tenerse cuidado cuando se utilizan dentro de un

desarrollo orientado a objetos.

Pueden servir como base para especificar

respuestas a aplicaciones de control y tiempo
real

Los problemas pueden surgir cuando en un desarrollo

software se utilizan diferentes estrategias

61

62

Descomposicin funcional

Casos de uso: Peligros

Violacin de la ocultacin de la informacin.

Cuando se describen casos de uso, se debe conocer no
slo el elemento p
para el que
q se desarrolla el caso de uso,,
sino tambin la interfaz pblica definida de cada
elemento.

Los autores de casos de uso deben evitar la tentacin

de ir ms all de la interfaz pblica, e intentar describir la
estructura interna del elemento.

63

64

Casos de uso: Peligros

Casos de uso: Peligros

No saber cuando parar.

Falta de formalidad.

Puede existir confusin entre la elicitacin de

requisitos y los casos de uso y entre el diseo y los
casos de uso. Por ejemplo,
Es un juego completo de casos de uso lo
mismo que los requisitos de un producto?
Existen otros requisitos (del producto o del
proyecto) que no estn capturados en los casos
de uso?
Hay algn aspecto del diseo/arquitectura
del sistema que no se ha capturado con los
casos de uso?

La informalidad de los casos de uso lleva a un falso

sentido de seguridad.
La gente se olvida de las normas para los nombres y
otras convenciones de estilo.
Aumenta la posibilidad de cometer errores
Disminuye la probabilidad de reutilizar el caso de uso

65

66

11

Casos de uso: Peligros

3.5.
Utilidad de la tcnica:
el paso a los objetos

La cobertura es el mayor problema de quien

usa los casos de uso:

Una cosa es decir que el

el conjunto de todos los
casos de uso especifican la totalidad de la
funcionalidad del sistema

Especificacin e implementacin
Diagramas de secuencia de caja negra
Descomposicin funcional vs colaboracin

Otra cosa es demostrar que se ha capturado

por completo la funcionalidad deseada del sistema
en un conjunto de casos de uso.

67

Diagramas de secuencia: prstamo

(DSS de caja negra)

Especificacin e implementacin

La especificacin de los casos de uso nos

permite conocer el comportamiento externo
que define la posible secuencia de mensajes
intercambiados entre los actores y el sistema.

sistema :
Sistema
: Bibliotecario
1: comenzar el proceso de prstamo

Al nivel de casos de uso esto se especifica

como

Se realiza el caso de uso Identificacin de socio

2: comprueba la situacin del socio

un diagrama de secuencia (dilogo actor/sistema)

una mquina de estados (o un diagrama de

actividad)

3: identifique el libro
4: identifica el libro
5: ejemplares disponibles
6: identifica un ejemplar y solicita al sistema que registre el prstamo
7: proceso de registro ha terminado

69

70

Casos de uso: Implementacin

Mquina de estados: cajero automtico

bienvenida

tarjeta
retirada

entry/ ^display.mostrar_bienvenida

insertada( numero )
esperando PIN

La relacin entre los casos de uso y su

implementacin es una Realizacin.

entrega dinero

entry/ ^display.pedirPIN

entry/ entregardinero
entry/ ^lector.expulsar_tarjeta

PINtecleado( PIN )[ error ]

La implementacin de un caso de uso puede

ser vista como una colaboracin:

PINtecleado( PIN )[ ok ]
Opciones

transaccion[ ok ]

entry/ ^display.mostrar_opciones

seleccionar "sacar"

when( 30 seg ) ^display.mensaje(mximo)

conexion banco

Importe
entry/ ^display.pedir_cantidad

entry/ conectar(banco)
entry/ ^display.mostrar_mensaje("espere...conectando")

importe introducido

71

Se trata de objetos y enlaces (instancias de

clases y asociaciones) junto con las posibles
secuencias de flujos de mensajes que provoca el
caso de uso en cuestin.

72

12

Transicin hacia los objetos

Transicin hacia los objetos

Una descomposicin que siga directamente la forma de los

casos de uso conduce a una aproximacin estructurada clsica,
funcional...

Es necesario realizar un paso al mundo de los

objetos

Realizacin de un
pedido
Orden de pago

Informacin
suministrada por el
Cliente

Pedido de productos

Realizacin de un pedido
Orden de
pago

Pedido de
productos

Informacin
suministrada

Se efecta asociando una colaboracin a cada caso

de uso
La colaboracin describe objetos del mbito, las
conexiones entre estos objetos y los mensajes que
intercambian stos

La realizacin de un caso de uso por una

colaboracin es momento crucial del modelado;
Es el momento del cambio hacia la
orientacin a objeto

73

74

Casos de uso y UP

Transicin hacia los objetos

Donde

Cundo
inicio

Caso de uso

Colaboracin

elaboracin

<<Realiza>>

January

February

Two adjacent projections.

<<Participa>>

<<Participa>>
Use Case: Capture a Sale
...
Main Success Scenario:
1. ...
2. ...
3. ...
Extensions:

<<Participa>>

Objeto

Objeto

Objeto

Analista

Usuario

Cliente

Desarrollador

Arquitecto

Quin

Bibliografa Recomendada

Caso de estudio Punto de venta

Larman, C. UML y Patrones. Introduccin al Anlisis y Diseo

Orientado a Objetos y al Proceso Unificado . Prentice Hall,
2002.

Captulos 6..9, 25

Actores, actividades y casos de uso:

Elicitacin de Requisitos de Sistemas Software. 2003.

J. Rumbaugh, I. Jacobson, G. Booch, El Lenguaje Unificado

A. Cockburn. Writing Effective Use Cases. Addison-Wesley

Procesar ventas
Procesar
devoluciones
Abrir y cerrar caja

Director:

de Modelado. Manual de referencia. Addison-Wesley,2000

Cajero:

Amador Durn y Beatriz Bernrdez, Metodologa para la

Lecturas complementarias

Cmo
Software:
76
Herramienta CASE + herramienta de requisitos + Hyperlink

75

Use Case: Handle Returns

...
Main Success Scenario:
1. ...
2. ...
3. ...
Extensions:

Poner en marcha
Suspender
operaciones

Administrador:

Aadir usuarios
Modificar usuarios
Gestionar tablas del
sistema

Control de ventas:

Analizar los datos de

ventas y rendimiento

2001
77

78

13

Diagrama de casos de uso

Caso de uso Procesar venta

( se inicia cuando un cliente llega a la caja con uno o varios artculos)
1. El cajero solicita iniciar una nueva venta

Procesar Venta
Actor_Cajero
Procesar Alquiler

2. El sistema solicita el cdigo del artculo

Sistema
contable

<<extend>>

3. El cajero introduce el cdigo del artculo

<<extend>>
<<extend>>
Gestionar Devolucin

4. El sistema registra una lnea de detalle y muestra el nombre y

precio del artculo
5. El cajero indica el fin de la venta

Pago con tarjeta

Pago en metlico
Sistema de
autorizacin

Pago con cupn

6. El sistema presenta el total

7. Se realiza el <Punto de extensin: FORMA DE PAGO>

Gestionar usuarios

8. El sistema registra la venta y enva la informacin al sistema

contable

Administrador
del sistema

79

Gestionar seguridad

9. El sistema imprime el recibo

80

Ejemplo Larman, completo

: Sistema
: Actor_Cajero
1. El cajero inicia una nueva
Venta
2. El sistema solicita el cdigo
del artculo
3. El cajero introduce el cdio
del artculo
4. El sistema registra una lnea
de detalle y muestra el nombre
y precio del artculo
5. El cajero indica el fin de la
venta
6. El sistema presenta el total
7. Punto de extensin: PAGO
8. El sistema registra la venta y
enva la informacin al sistema
contable
...

inicia nueva venta

(pasos 2..4 se repiten)

solicita el cdigo
introduce el cdigo del artculo
muestra el nombre y precio del artculo

fin de la venta
presenta el total
Punto de extensin:
Forma de PAGO

registra la venta

Actor principal: Cajero.

Personal involucrado e intereses:

Cajero: quiere entradas precisas, rpidas, y sin errores de pago, ya que

las prdidas se deducen de su salario.

Vendedor: quiere que las comisiones de las ventas estn actualizadas.

Compaa: Quiere registrar las transacciones con precisin y satisfacer el

inters de los clientes. Quiere asegurar que se registran los pagos
aceptados por el Servicio de Autorizacin de Pagos.
Pagos Quiere cierta tolerancia
a fallos que permita capturar la ventas .

Agencia Tributaria del Gobierno: quiere recopilar los impuestos de cada

venta ser mltiples agencias: nacional, provincial y local.

Servicio de Autorizacin de Pagos: Quiere recibir peticiones de

autorizacin digital en formato y protocolo correctos. Quiere registrar de
manera precisa las cuentas de la tienda.
Precondiciones: El cajero se identifica y autentifica.
Garantas de xito (Postcondiciones): Se registra la venta. El impuesto se
calcula de manera correcta. Se actualizan la contabilidad y el inventario. Se
registran las comisiones y se genera el recibo. Se registran las autorizaciones de
pago aprobadas.

81

82

Ejemplo Larman

El caso de uso empieza cuando un Cliente llega a un terminal PDV con mercancas
y/o servicios que compra

Escenario principal de xito (o Flujo Bsico):

1. El Cajero comienza una nueva venta.

2. El sistema solicita el identificador del artculo.
3. El Cajero introduce el identificador del artculo.
4. El Sistema registra la lnea de la venta y presenta la descripcin del artculo y
suma parcial. El precio se calcula a partir de un conjunto de reglas de precios
El Cajero repite los pasos 3-4 hasta que indique el fin de la venta
5. El Sistema presenta el total con los impuestos calculados.
6. El Cajero le dice al Cliente el total y pide que le pague e introduce la cantidad
7. El Sistema gestiona el pago.
8. El Sistema registra la venta completa y enva la informacin de la venta y el pago
al sistema de Contabilidad externo (para la contabilidad y las comisiones) y al
sistema ventas (para actualizar el inventario).
9. El Sistema emite el recibo.
10. El caso de uso termina (10. El Cliente se va con el recibo y las mercancas )83

Ejemplo Larman

Extensiones (o Flujos Alternativos):

*a En cualquier momento el Sistema falla:
Para dar soporte a la recuperacin y registro correcto, asegura que
todos los eventos significativos de una transaccin puedan recuperarse
desde cualquier punto del escenario.

3a. Identificador no vlido:

1. El Cajero reinicia el Sistema, inicia la sesin, y solicita la recuperacin al tenor.

2. El Sistema reconstruye el estado anterior.
2a. El Sistema detecta anomalas intentando la recuperacin:
1. El Sistema informa del error al Cajero, registra el error, y pasa a limpio.
2. El Cajero comienza una nueva venta.
1. El Sistema seala el error y rechaza la entrada.

3b. Hay muchos artculos de la misma categora y tener en cuenta una

nica identidad del artculo no es importante (ej. 5 paquetes de
hamburguesas vegetales):

1. El Cajero puede introducir el identificador de la categora del artculo y la cantidad.

84

14

Ejemplo Larman
3-6a. El Cliente le pide al Cajero que elimine un artculo de la compra:

Ejemplo Larman

1. El Cajero introduce el identificador del artculo para eliminarlo de la compra.

2. El Sistema muestra la suma parcial actualizada.

3-6b. El Cliente le pide al Cajero que cancele la venta:

3-6c. El Cajero detiene la venta:

1. El Cajero cancela la venta en el Sistema.

1. El sistema registra la venta para que est disponible su recuperacin en cualquier

t
terminal
i l PDV.
PDV

1. El Cajero introduce el precio alternativo.

2. El Sistema presenta el precio nuevo.

5a. El sistema encuentra algn fallo para comunicarse con el servicio

externo del sistema de clculo de impuestos.

7a. Pago en efectivo:

1.
2.
3.
4.

El
El
El
El

Cajero introduce la cantidad de dinero en efectivo entregada.

Sistema muestra la cantidad de dinero a devolver y abre el cajn de caja.
Cajero deposita el dinero entregado y devuelve el cambio al Cliente.
Sistema registra el pago en efectivo.

Ejemplo Larman

7c. Pago con cheque...

7d. Pago a cuenta...
7e. El Cliente presenta cupones:

7b. Pago a crdito:

1. El Cliente introduce la informacin de su cuenta de crdito.

2 El Sistema enva la peticin de autorizacin del pago al Sistema externo de Servicio
2.
de Autorizacin de Pagos, y solcita la aprobacin del pago.
2a. El Sistema detecta un fallo en la colaboracin con el sistema externo:

1. El Sistema seala el error al Cajero.

2. El Cajero le pide al Cliente un modo de pago alternativo.

3. El Sistema recibe la aprobacin del pago y lo notifica al Cajero.
3a. El Sistema recibe la denegacin del pago:

1. El Sistema seala la denegacin al Cajero.

2. El Cajero le pide al Cliente un modo de pago alternativo.

4. El Sistema registra el pago a crdito, que incluye la aprobacin del pago

5. El Sistema presenta el mecanismo de entrada para la firma del pago a crdito.

6. El Cajero le pide al Cliente que firme el pago a crdito. El Cliente introduce la

firma.
87

1a. El Cliente utiliza un mtodo de pago alternativo.

1b. El Cliente le dice al Cajero que cancele la venta. El Cajero cancela la venta en el
Sistema.

86

Ejemplo Larman

1. Ell Cajero
C j
seala
l la
l peticin
i i de
d crdito.
di
2. El Cajero introduce la identificacin del Cliente.
3. El Sistema aplica el crdito hasta que el precio O, y reduce el crdito que queda.

6a. El Cliente dice que su intencin era pagar en efectivo pero que no
tiene suficiente:

1. El Sistema reinicia el servicio en el nodo PDV y contina.

1a. El Sistema detecta que el servicio no se remida.

1. El Sistema seala el error.

2. El Cajero podra calcular e introducir manualmente el impuesto, o cancelar la

venta.
85

1. El Cajero seala la peticin de descuento.

2. El Cajero introduce la identificacin del Cliente.
3. El Sistema presenta el descuento total, basado en las reglas de descuento.

5c. El Cliente dice que tiene crdito en su cuenta, para aplicar a la

venta:

4a. El Sistema genera el precio de un artculo que no es el deseado (ej.

el Cliente se queja por algo y se le ofrece un precio ms bajo):

5b. El Cliente dice que le son aplicables descuentos (ej. empleado,

cliente preferente):

1. Antes de gestionar el pago, el Cajero recoge cada cupn y el Sistema reduce el

pago como sea oportuno. El sistema registra los cupones utilizados por razones de
contabilidad.
la. El cupn introducido no es vlido para ninguno de los artculos comprados
1 El Sistema seala el error al Cajero.
1.
Cajero

9a. Hay rebajas en los artculos:

9b. El Cliente solicita un vale-regalo (sin precio visible):

1. El Sistema presenta los formularios de rebaja y los recibos de descuento para cada
artculo con una rebaja.
1. El Cajero solicita el vale-regalo y el Sistema lo proporciona.

88

15