* Escuela Profesional de
Ingeniera de Sistemas
SESION 4:
- INGENIERIA DE SOFTWARE
- - Casos de Uso
Docente : Ing. Luis Delgado
DIAGRAMAS UML
2
3
Que son los Casos de Uso
4
*Es una estructura que ayuda a los analistas a determinar la
forma en que se usar un sistema. Con una coleccin de casos
de uso se puede hacer el bosquejo de un sistema en trminos
de lo que los usuarios intenten hacer con el.
*Los diagramas de casos de uso documentan el
comportamiento de un sistema desde el punto de vista del
usuario.
*Por lo tanto los casos de uso representan las funciones que un
sistema puede ejecutar.
*Su ventaja principal es la facilidad para interpretarlos, lo que
hace que sean especialmente tiles en la comunicacin con el
cliente.
Ejemplo
5
*Un caso de uso estable un conjunto
de escenarios para realizar algo til
para un actor. En este ejemplo, un
caso de uso es Comprar gaseosas.
6
*
*Un caso de uso especifica un comportamiento deseado del
sistema.
*Representan los requisitos funcionales del sistema.
Un caso de uso especifica un conjunto de secuencias de
acciones, incluyendo variantes, que el sistema puede
ejecutar y que produce un resultado observable de
valor para un particular actor.
Describen qu hace el sistema, no cmo lo hace.
7
CASOS DE USO
Un diagrama de casos de uso consta de los
siguiente elementos:
Actor
Casos de Uso
Relaciones
8
*
Responsable
Prestamos
Gestionar Prstamos
actor
caso de uso
asociacin
9
*
Un actor representa un conjunto coherente de roles
que juegan los usuarios de los casos de uso al
interaccionar con el sistema.
*Roles jugados por personas, dispositivos, u otros
sistemas.
*El tiempo puede ser un actor (procesos iniciados
automticamente por el sistema).
*No forman parte del sistema.
10
*
*Un usuario puede jugar diferentes roles.
*En la realizacin de un caso de uso pueden
intervenir diferentes actores.
*Un actor puede intervenir en varios casos de uso.
*Identificar casos de uso mediante actores y
eventos externos.
*Un actor necesita el caso de uso y/o participa en
l.
11
*
*Dos tipos de actores:
*Principal:
Requiere al sistema para el cumplimiento de
un objetivo.
*Secundarios:
El sistema necesita de ellos para satisfacer
un objetivo.
12
*
*Es una operacin/tarea especfica que se
realiza tras una orden de algn agente
externo, sea desde una peticin de un actor o
bien desde la invocacin desde otro caso de
uso.
*Describen bajo la forma de acciones y
reacciones el comportamiento de un sistema
des desde el punto de vista del usuario.
13
*
*Comunicacin (Asociacin )
*Relacin (asociacin) entre un actor y un
caso de uso. El estereotipo de la relacin
de comunicacin es: <<communicate>>
aunque generalmente no se estipula ningn
nombre, como podemos apreciar en el
siguiente ejemplo de comunicacin
14
*
*Inclusin (<<include>> anterioremnete <<uses>>)
*La relacin de inclusin sirve para enriquecer un caso de uso con
otro y compartir una funcionalidad comn entre varios casos de
uso, tambin puede utilizarse para estructurar un caso de uso
describiendo sus subfunciones. El caso de uso incluido existe
nicamente con ese propsito, ya que no responde a un objetivo
de un actor.
15
*
*Inclusin (<<include>> anterioremnete <<uses>>)
*Estas relaciones se representan mediante una flecha discontinua
con el estereotipo <<include>>.
*Algunos casos de uso tpicos de inclusin son: comprobar,
verificar, buscar, validar, autentificar o login.
16
*
*Extensin (<<extend>>
*Denota cuando un caso de uso es una especializacin de otro. Se
usa cuando se describe una variacin sobre el normal
comportamiento.
*Partes opcionales de un caso de uso
*Un Caso de Uso origen extiende el comportamiento del Caso de
Uso destino.
17
*
*Generalizaciones
*Una generalizacin se utiliza cuando varios actores juegan
aparte de su rol un rol ms generalizado.
* Esto ocurre cuando el comportamiento del rol generalizado es
descrito por la superclase actor.
*Los actores especializados heredan el comportamiento de una
superclase y lo extienden de una forma.
18
*
*Resulta til dibujar los lmites del sistema
cuando se
*pretende hacer un diagrama de casos de uso
como parte del sistema .
19
*
*Son iniciados por un actor con un objetivo en mente y es
completado con xito cuando el sistema lo satisface.
*Puede incluir secuencias alternativas que llevan al xito
y fracaso en la consecucin del objetivo.
*El sistema es considerado como una caja negra y las
interacciones se perciben desde fuera.
*El conjunto completo de casos de uso especifica todas
las posibles formas de usar el sistema, esto es el
comportamiento requerido.
20
*
*Un escenario es una iteracin entre el sistema y los
actores, que puede ser descrito mediante una secuencia
de mensajes.
* Un caso de uso es una generalizacin de un escenario.
*Un caso de uso describe un conjunto de secuencias de
interacciones entre actores y el sistema (escenarios):
flujo principal y flujos alternativos o excepcionales.
*Un escenario es una instancia de un caso de uso
*Un escenario es una historia particular de uso de un
sistema.
21
*
*Son documentos de texto, no son diagramas.
*El modelado de casos de uso consiste en escribir texto, no
en dibujar diagramas.
*Describir el flujo de eventos
*Texto estructurado informal
*Texto estructurado formal (plantillas)
*Pseudocdigo
*Notaciones grficas: diagramas de secuencia
*Debe ser legible y comprensible para un usuario no
experto.
*Debe indicar: actores, flujos principal y excepcionales.
22
*
23
*
Nro Caso de Uso
CU1
Caso de Uso:
<<Nombre del Caso de Uso>>
Descripcin:
<<Descripcin del Caso de Uso>>
Actores:
<<Actores involucrados del Caso de Uso>>
Precondiciones
<<Pre-Condiciones del Caso de Uso>>
PostCondiciones
<<Post-Condiciones del Caso de Uso>>
Flujo de Eventos
<<Flujo de Eventos del Sistema Vs Actor para el Caso de Uso>>
Flujo de Eventos Alternativo
<<Flujo de Eventos Alternativos del Sistema Vs Actor para el Caso de
Uso>>
24
*
25
Nro Caso de Uso CU1
Caso de Uso: Sacar Dinero
Descripcin:
El sistema deber permitir al cliente del banco, en cualquier momento, sacar dinero segn se describe
en el siguiente caso de uso.
Actores: Cliente, Sistema del Banco
Precondiciones El cliente tiene una cuenta en el banco asi como una tarjeta emitica por el mismo banco
Postcondiciones La tarjeta se valida correctamente
Flujo de Eventos
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
de usuario
3+ El usuario introduce el cdigo
4+ Si el cdigo es correcto, el cajero pide al usuario que seleccione el tipo de transaccin desada.
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 de banco
9a Si conecta el sistema el sistema deber comprobar si hay dinero en la cuenta.
9b Si no conecta el sistema deber comprobar si el dinero es menos que el lmite
10 En cualquiera de los dos el sistema:
'+ expulsa la tarjeta
'+ imprime el recibo
'+ entrega el dinero
Flujo de Eventos
Alternativo
2' La tarjeta no es aceptada
+ Se expulsa emitiendo un sonido
4' Codigo incorrecto (1,2)
+ Se emite un mensaje dando al usuario la oportunidad de volver a introducir el cdigo (paso 3)
4'' Codigo 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
9a', 9b' No hay dinero suficiente
'+ El cajero no dispone de la cantidad pedida. Emite un mensaje y vuelve al paso 7
10' Cancelar
*
26
Reservar Libro
Prestamo Libro
Devolver Libro
Socio
Extender Prestamo
Prestamo Revista
Profesor
Devolver Revista
Bibliotecario
Actualizar Catalogo
Socio
Consultar
27
*
1) Identificar los usuarios del sistema.
2) Encontrar todos los roles que juegan los usuarios y que
son relevantes al sistema.
3) Para cada rol identificar todas las formas (objetivos) de
interactuar con el sistema.
4) Crea un caso de uso por cada objetivo.
5) Estructurar los casos de uso.
6) Revisar y validar con el usuario.
28
* Realizar
Venta
*Resumen: Un cliente llega al TPV con un conjunto de
artculos. El cajero registra los artculos y se genera un
ticket. El cliente paga en efectivo y recoge los
artculos.
*Actores: Cajero (principal), Sistema (secundario)
*Personal Involucrado e Intereses:
*Cajero: quiere entradas precisas, rpidas y sin errores de pago.
*Compaa: quiere registrar transacciones y satisfacer clientes.
*...
*Precondicin: El cajero se identifica y autentifica.
*Poscondiciones: Se registra la venta. Se calcula el
impuesto. Se actualiza la contabilidad y el inventario.
29
* Realizar
Venta
*Escenario Principal (Flujo Bsico):
1. El cliente llega al TPV con los artculos.
2. El cajero inicia una nueva venta.
3. El cajero introduce el identificador de cada artculo.
4. El sistema registra la lnea de venta y presenta descripcin del
artculo, precio y suma parcial.
El cajero repite los pasos 3 y 4 hasta que se indique.
5. El sistema presenta el total.
6. El cajero le dice al cliente el total a pagar .
7. El cliente paga y el sistema gestiona el pago.
8. El sistema registra la venta completa y actualiza el inventario.
9. El sistema presenta recibo.
30
* Realizar Venta
*Extensiones (Flujos Alternativos):
A1: Identificador no vlido
La secuencia A1 comienza en el punto 3.
4. El sistema seala el error y rechaza la entrada.
El escenario vuelve al punto 3.
A2: El cliente pide eliminar un artculo de la compra.
La secuencia A2 puede ocurrir entre los puntos 3-6.
1. El cajero introduce identificador a eliminar.
2. El sistema actualiza la suma.
El escenario contina en el punto 6.
A3: Pago en efectivo
La secuencia A3 ocurre en el punto 7.
1. El cajero introduce la cantidad entregada por el cliente.
2. El sistema muestra cantidad a devolver.
El escenario contina en el punto 8.
31
* Realizar Venta
*Requisitos de Interfaz de Usuario:
- Pantalla tctil en un monitor de pantalla plana.
- El texto debe ser visible a un metro de distancia.
*Requisitos No-Funcionales:
- El identificador del producto podra ser cualquier
esquema de cdigo de barras UPC, EAN-8, EAN-13, ...
- El tiempo de respuesta para autorizar el pago con la
tarjeta de dbito o de crdito es de 30 segundos.
*Cuestiones Pendientes:
- Explorar cuestiones de recuperacin de accesos a
servicios remotos.
- Qu adaptaciones son necesarias en un TPV para
diferentes negocios?
32
*
*Hay consenso en considerar casos de uso como
esenciales para capturar requisitos y guiar el
modelado.
*Pero todava existe mucha confusin sobre cmo
usarlos.
*Cul es el nmero de casos de uso apropiado en un
proyecto?
*Qu casos de uso hay en el sistema?
