UNIVERSIDAD PRIVADA SAN

PEDRO
FACULTAD DE INGENIERIA
CURSO
INGENIERIA DEL SOFTWARE

”CASOS DE USO - PRACTICAS”

DOCENTE: ING. SANTOS GABRIEL BLAS

Ingeniería del Software Ing. Santos Gabriel Blas

09/03/2012
1
Préstamo de Libros – Caso de uso
 Préstamo de Libros - Escenarios
Ejemplos:
Escenario 1: José se lleva prestado el tercer ejemplar de
“Guerra y Paz” que hay en la biblioteca. No tiene ningún otro
libro en préstamo

Escenario 2: Mónica intenta llevarse prestado el primer

ejemplar de “Corín Tellado”, pero no puede porque ya tiene
tres libros en préstamo, que es el máximo.

Todos los escenarios de un caso de uso deben tener en

común intentos de hacer esencialmente “lo mismo” (en este
caso llevarse un libro en préstamo)

Los escenarios pueden y deben posteriormente

documentarse mediante diagramas de interacción o de
actividad.
Relación entre casos de uso - <Include> (Incluye)
Se puede incluir una relación entre dos casos de uso de
tipo <include>(incluye) si se desea especificar
comportamiento común entre dos o mas casos de uso
Relación entre casos de uso - <Include> (Incluye)
Préstamo de Libros - <Include>
 Relación entre casos de uso - <Extended> (extiende)
Se puede incluir una relación entre dos casos de uso de
tipo <extend>(extiende) si se desea especificar diferentes
variantes del mismo caso de uso.
Dicho de otra forma, la relación <extended> implica que el
comportamiento de un caso de uso es diferente
dependiendo de ciertas circunstancias.
Relación entre casos de uso - <Extended> (extiende)
 Generalizaciones

En un diagrama de casos de uso

también pueden mostrarse
generalizaciones (relaciones de
herencia) para mostrar que diferentes
elementos están relacionados como
tipos de otros.

Son aplicables a actores o casos de

uso, pero para estos últimos la
semántica es muy similar a las
relaciones <extend>
Generalizaciones
Generalizaciones
 Generalizaciones

La especialización
es la presencia de
unas características
específicas de un
subconjunto de
elementos de un
determinado
conjunto
Generalizaciones
 Limites del Sistema
Es útil dibujar los limites del sistema cuando se pretende
hacer un diagrama de casos de uso para mostrar parte
del sistema.
 Caso de uso – Maquina Recicladora
Sistema que controla una máquina de reciclamiento de botellas,
tarros y jabas. El sistema debe controlar y/o aceptar:
• Registrar el número de ítems ingresados.
• Imprimir un recibo cuando el usuario lo solicita:
a) Describe lo depositado
b) El valor de cada ítem
c) Total
• El usuario/cliente presiona el botón de comienzo
• Existe un operador que desea saber lo siguiente:
a) Cuantos ítems han sido retornados en el día.
b) Al final de cada día el operador solicita un resumen de
todo lo depositado en el día.
• El operador debe además poder cambiar:
a) Información asociada a ítems.
b) Dar una alarma en el caso de que:
i. Ítem se atora.
ii. No hay más papel.
 Caso de uso – Maquina Recicladora

Como una primera aproximación identificamos a

los actores que interactúan con el sistema:
 Caso de uso – Maquina Recicladora
Luego, tenemos que un Cliente puede Depositar
Ítems y un Operador puede cambiar la información de
un Ítem o bien puede Imprimir un informe
 Caso de uso – Maquina Recicladora
Además podemos notar que un ítem puede ser una
Botella, un Tarro o una Jaba.
 Caso de uso – Maquina Recicladora
Otro aspecto es la impresión de comprobantes, que
puede ser realizada después de depositar algún ítem
por un cliente o bien puede ser realizada a petición
de un operador.
 Caso de uso – Maquina Recicladora
Diseño completo del diagrama Use Case es:
Caso de uso – Juego Buscaminas

¿Qué casos de uso identificamos?

» Iniciar una nueva partida.
» Descubrir una casilla.
» Marcar una casilla.
¿Quién realiza estos casos de uso?
» El jugador.
Caso de uso – Juegos Buscaminas
 Caso de uso – Juego SOKOBAN
Sokoban es un juego de varios niveles.
 Cada nivel está compuesto por un jugador, cajas, repisas y
muros.
 El objetivo del jugador es empujar todas las cajas sobre las
repisas.
 Cuando esto sucede el jugador pasa al siguiente nivel.
 Para mover una caja, el jugador debe colocarse al lado y
empujarla.
 Si la casilla hacia la que está empujando la caja está libre la
caja se moverá.
 Si el jugador se queda bloqueado, es decir, no puede terminar
el nivel, puede reiniciar el nivel perdiendo una vida.
 Cuando el jugador pierde todas sus vidas la partida termina.
Caso de uso – Juego SOKOBAN
 Caso de uso – Centros Hospitalarios
Un cierto hospital necesita organizar la asignación de
guardias de sus médicos en sus diferentes centros
hospitalarios mediante una aplicación informática. Para
ello asigna a un Analista el diseño del sistema utilizando la
notación UML.
Un médico jefe tiene asignada la función de Planificador
de guardias y debe tener en cuenta los médicos
disponibles, las guardias que debe cubrir y algunas
incompatibilidades como asignaciones de tareas de más
alta prioridad.
Por otra parte, los datos de todos los médicos los
mantiene un Supervisor, encargado de mantener esta
información: altas, bajas, cambios de datos, etc.
 Caso de uso – Centros Hospitalarios
Existe también un Administrador del sistema que se
encarga de la asignación y revocación de permisos a los
planificadores.

Se desea, asimismo, disponer de una función estadística

que permita generar listados informativos.
Dado que varios planificadores de guardias pueden trabajar
en paralelo, se quiere que se actualicen automáticamente
las estadísticas que vea cada uno cada vez que haya un
cambio por parte de cualquiera de ellos. Asimismo, cada
planificador puede editar y modificar planes de guardias.
Se pide realizar el Diagrama de Casos de Uso de la
aplicación. Realizar una descripción textual de los
casos de uso y actores contemplados.
 Caso de uso – Centros Hospitalarios
Solución:
Los casos de uso son:
Gestionar Médicos: dar de alta, de baja y cambio de datos
a todos los médicos de cada centro hospitalario.
Gestionar Estadísticas: actualizar las Estadísticas y
presentarlas a los usuarios de la aplicación cuando lo
soliciten.
Editar Planes: asignar los médicos disponibles a las
guardias previstas.
Gestionar Planes: creación y borrado de planes, apertura y
cierre de planes ya creados, edición e impresión (por ello se
incluye al anterior “Editar Planes”)
Gestionar Usuarios: gestionar las cuentas de los
planificadores de guardias autorizados, creando usuarios y
asignándoles una palabra clave.
 Caso de uso – Centros Hospitalarios
Los actores son:
Supervisor: empleado administrativo que trabaja con
datos confidenciales y que tiene que tener permisos
especiales de acceso a datos restringidos.
Planificador: encargado de la asignación de guardias
teniendo en cuenta la restricciones introducidas
previamente en el sistema por el Supervisor
Administrador: responsable de la asignación de cuentas
de acceso y de asegurar la confidencialidad y la integridad
de la información del sistema.
Caso de uso – Centros Hospitalarios
 Pautas a seguir para un buen modelo
• Asegurarse que cada caso de uso describe una parte
significativa del funcionamiento del sistema.
• Evitar un número excesivo de casos de uso
• Un caso de uso no es un paso, operación o actividad
individual en un proceso.
• Un caso de uso describe un proceso completo que
incluye varios pasos (flujo de trabajo de la empresa).
• Los casos de uso deben ser simples, dado que podrían
cambiar con facilidad
• Los casos de uso tienen que ser entendibles tanto por
desarrolladores software como por expertos del
dominio
• Es una descripción de alto nivel del sistema
• Evitar conceptos de diseño
 Identificarlos para un buen modelo
A partir de los actores
• Qué actores? (relacionados con el sistema o
organización)
 quién necesita el sistema?
 qué necesita el sistema para funcionar: personal,
hardware especializado, otros programas (software).
• Para cada actor, identificar los procesos que inician o en
los que participan
 ponerle nombre
 determinar límites/frontera: qué es del sistema? Qué
queda fuera?
 Qué espera recibir/obtener?
 A partir de los eventos
• Identificar los eventos externos a los que puede
responder el sistema.
• Relacionar los eventos con actores y casos de uso
 Descubrimiento
1. Determinar los límites del sistema
• ¿Es sólo una aplicación software, el hardware y la
aplicación como un todo?
• ¿Lo utiliza más de una persona o una
organización completa?
2. Identificar los actores principales
• Quienes interactúan con el sistema
3. Para cada actor, identificar sus objetivos como
usuario
• Seguir “flujos” en la empresa: dinero,
información,…
4. Definir los casos de uso que satisfagan los
objetivos de usuario
• Nombrar los casos de uso con un verbo
Descripción usando plantillas
 Casos de uso en el proceso de análisis
• Las entrevistas con el cliente inician el proceso
 Estas entrevistas producirán diagramas de clases
 Obtendremos la base de conocimiento para el
dominio del sistema, esto es, el área del cliente
 Ahora se está en condiciones de poder hablar con
el usuario
• Las entrevistas con el usuario empiezan con la
terminología del dominio, aunque deberán
alternarse hacia la terminología de los usuarios.
 Estas entrevistas desvelarán a los actores y casos
de uso de alto nivel que descubrirán los
requerimientos funcionales en términos generales
 Esta información también permitirá establecer los
límites y ámbito del sistema.
 Casos de uso en el proceso de análisis
• Entrevistas posteriores con el usuario
 Permitirán profundizar en los requerimientos, lo
que dará lugar a casos de uso que mostrarán los
escenarios y las secuencias detalladamente
• Entrevistas posteriores con el usuario
Esto podría resultar en otros casos de uso que
satisfagan las relaciones de inclusión y extensión.
En esta fase es importante confiar en la
compresión del dominio a partir de los diagramas
de clase
• Si no se comprende adecuadamente el dominio
se podrían crear demasiados casos de uso y
demasiados detalles, lo cual obstaculizaría la
labor de diseño.
 Casos de uso – Ejercicios N 01
Se desea desarrollar un sistema de encuentros virtuales
(parecido a un chat).
 Cuando se conecta al servidor, un usuario puede entrar o salir
de un encuentro.
 Cada encuentro tiene un manager.
 El manager es el usuario que ha planificado el encuentro (el
nombre del encuentro, la agenda del encuentro y el moderador
del encuentro).
 Cada encuentro puede tener también un moderador designado
por el manager.
 La misión del moderador es asignar los turnos de palabra para
que los usuarios hablen.
 El moderador también podrá dar por concluido el encuentro en
cualquier momento.
 En cualquier momento un usuario puede consultar el estado
del sistema, por ejemplo los encuentros planeados y su
información.
Casos de uso – Ejercicios N 01
 Casos de uso – Ejercicios N 02
Un sistema personal de bolsa se conecta
periódicamente a servidores que ofrecen
información de las cotizaciones.
El sistema personal permite marcar una serie de
valores para realizar un seguimiento y consultar los
datos de dichos valores.
Si a la hora de actualizar las cotizaciones uno de
los valores marcados presenta una gran subida o
bajada, informará a usuario de ello.
Casos de uso – Ejercicios N 02
 Casos de uso – Ejercicios N 03

 Un juego de teléfono móvil dónde participan dos

jugadores cada uno con su propia terminal.
 Cuando dos jugadores desean jugar, uno de ellos
crea una nueva partida y el otro se conecta.
 El objetivo del juego es manejar una nave y
disparar al contrario. Si uno de los dos jugadores
acierta, la partida termina.
 Si uno de los dos jugadores deja la partida (o se
pierde la conexión) la partida termina.
Casos de uso – Ejercicios N 03