Ingeniería de Software

Clase 10

Casos de Uso - UML

Gloria Lucía Giraldo G. Of. M8A 313

 Modelando los requisitos
Casos de uso
• Los requisitos de un sistema describen lo que el
usuario espera del sistema.
• En la fase de definición del sistema, éste debe verse
como una caja negra  solo las características
externas son consideradas.
• Con los casos de uso se modelan los requisitos
funcionales del sistema.
• Los casos de uso se extendieron para poder modelar
las requisitos no funcionales.
• Con los casos de uso se modelan las entradas y salidas
del sistema y luego los detalles se modelan con los
modelos estáticos, como es por ejemplo, el diagrama
E/R.
 Un poco de historia …
• En 1986, Ivar Jacobson formuló técnicas de
modelado textual, estructural y visual de los CU.
• Solamente en 1992, Jacobson popularizó los CU
con el libro “Object-Oriented Software
Engineering - A Use Case Driven Approach”, el
cual escribio con otros autores (Magnus
Christerson, Patrik Jonsson and Gunnar
Övergaard)
 Un poco de historia …
• Después de que Jacobson creó los CU, muchos
otros investigadores aportaron para mejorarlos.
• Por ejemplo, inicialmente los CU no tenían una
forma de explicarlos, entonces se vio la necesidad
de crear lo que se llama “Especificaciones de los
casos de uso”, las cuales no hacen parte de UML.
• Durante los 90’s, los CU llegaron a ser una de las
herramientas más utilizadas para capturar los
requisitos funcionales.
 ¿Qué es un caso de uso?
• Un CU define una secuencia de interacciones
entre uno o más actores y el sistema.
• Un modelo de CU describe los requisitos
funcionales del sistema, en términos de los
actores y de los CU.
• Son muy importantes pues permiten visualizar
rápidamente la funcionalidad del sistema y los
actores que tienen acceso a cada una de las
funciones.
 ¿Qué es un caso de uso?
• En un CU, el sistema es tratado como una caja
negra.
• Es decir, los CU tienen que ver con el “qué
hace el sistema en respuesta a la entrada de
un actor”, dejando de lado el cómo lo hace.
 Elementos de un Caso de uso:
Actor(es)
• Es una entidad externa que interactúa con el
sistema.
• Los actores están fuera del sistema, no hacen
parte de él.
• Un actor representa un rol jugado en el
dominio de aplicación, por todos los usuarios
del mismo tipo.
• La mayoría de las veces los actores son seres
humanos, pero no siempre!!!
 Elementos de un Caso de uso:
Actor(es) no humano(s)
Hay actores tipo “Sistema externo”, por ejemplo
un “sistema remoto” en un sistema de
monitoreo de emergencias.
Hay actores tipo “dispositivo de entrada o de
entrada y salida”, por ejemplo un sensor de
monitoreo.
Hay actores tipo “timer” que periódicamente
envían eventos de tiempo al sistema.
Un actor primario es quien inicia el CU.
Otros actores que participan en el caso de uso,
son actores secundarios.
 Elementos de un Caso de uso:
Actor(es)
• Pero hay que tener en cuenta, que muchas veces
los actores humanos se comunican con el sistema
a través de dispositivos de I/O, como un teclado.
Sin embargo en ese caso, estos dispositivos NO
son actores.
• Por ejemplo en un cajero electrónico, el Sistema y
el Cliente interactúan a través de un teclado, de un
lector de tarjetas, etc. Pero el único actor allí es el
Cliente.
• Así, entonces, los actores son usuarios finales.
 Elementos de un Caso de uso:
Actor(es)
EJEMPLOS
 Generalización de actores
Existen actores que tienen roles en común, en
cuyos casos el actor puede ser generalizado para
capturar allí la parte común
¿Cómo identificar un caso de uso?
• Identificar primero los actores y las
interacciones con el sistema.
• Cada CU describe una secuencia de
interacciones entre el actor y el sistema.
• Hay que evitar la atomización de
funcionalidades.
• También hay que evitar casos de uso generales,
que abarcan muchas funcionalidades.
Ejemplo de un diagrama de Casos de
Uso

Requisitos Funcionales
del Sistema

Acá vemos:
tres casos de uso  Retirar dinero, Consultar la cuenta y
Transferir dinero
Actor  Cliente del cajero
 … tener en cuenta que …
• Solamente se describe la interacción del actor
con el sistema informático.
• La interacción es del tipo petición – acción.
• Se recomienda indicar cómo inicia el caso de
uso: “Este caso de uso inicia cuando…”
(Disparador)
• Se recomienda indicar el final del caso de uso.
• Siempre se indica quién ejecuta la acción: ej.
El Sistema o el Estudiante.
• Se debe ser consistente con los nombres de
los actores
 tener en cuenta que …
• Los casos de uso describen el qué, pero no el
cómo. Por ejemplo, nuestro CU no dice:
– ¿Cómo hace el sistema para entregar el
dinero?
– ¿Cómo el sistema transfiere el dinero?
• Por lo tanto, los casos de uso deben ir
acompañados de una especificación, la cual
no hace parte de UML, pero es necesaria !!!
 Especificación de los casos de uso
• Plantilla
Flujo Normal Vs Flujos alternativos
• En el Flujo Normal de los eventos se describe
el flujo IDEAL.
• En los flujos alternativos se describen eventos
que pueden ocurrir en los pasos del proceso y
la forma en que son controlados estos
eventos.
• En programación (Java): Manejo de
Excepciones.
 Ejemplo – Flujos Alternativos.

• ¿Qué pasa si el Cliente no tiene fondos

suficientes?
Entonces existe un posible flujo alternativo:

El Cliente no tiene fondos El sistema muestra un

suficientes para retirar la mensaje “Fondos
cantidad solicitada insuficientes en la cuenta”

18
Casos de Uso – Flujos Alternativos.
• Analizar cada paso.
• No dejar nada al azar.
• Revisar requisitos del interesado.
• Los flujos alternativos son fundamentales para
un buen desarrollo.

19
ACTIVIDAD EN CLASE
Piense en un sistema de préstamo de libros.
Realice un diagrama de casos de uso para dicho sistema:
• Identificar los actores
• Identificar las funcionalidades del sistema
• Realizar las especificaciones para uno de los casos de uso

FIN DE LA PRIMERA PARTE

Otro ejemplo de un diagrama de Casos
de Uso
 Los Casos de Uso y las interfaces
gráficas de usuario (GUI - Graphical
User Interfaces)
• ¿Por qué una Interfaz Gráfica de Usuario?.
• En el ejemplo:

Este caso de uso inicia cuando

el Estudiante selecciona la
opción cancelar cursos.

22
 Los Casos de Uso y las GUIs

El sistema presenta los

cursos matriculados por
el estudiante.

El Estudiante selecciona los cursos

que desea cancelar y selecciona
la opción “Cancelar Cursos”.

23
 Asociaciones entre Casos de Uso
• Cuando un caso de uso es muy complejo, se
pueden definir asociaciones entre casos de
uso, tales como:
– Inclusión (Include)
– Extensión (Extend)
• El objetivos es maximizar la reutilización y la
capacidad de extensión de los CU
 Asociaciones entre Casos de Uso
Inclusión (Include)
• La inclusión de CU, nace cuando se identifican
secuencias comunes de interacciones en
muchos casos de uso, las cuales pueden ser
extraídas y reutilizadas.
• La inclusión de CU refleja funcionalidades
comunes en más de un CU.
• Cuando esas funcionalidades comunes se
agrupan en un CU, éste puede ser reutilizado
por otros casos de uso.
 Asociaciones entre Casos de Uso
Inclusión (Include)
EJEMPLO
 Asociaciones entre Casos de Uso
Extensión (Extend)
• Algunas veces los casos de uso son muy
complejos y tienen muchas ramas opcionales.
• La asociación de extensión se usa para
modelar esas ramas opcionales que los CU
pueden tomar.
• El objetivo de estos CU es extender la
funcionalidad del caso de uso base.
Asociaciones entre Casos de Uso
Extensión (Extend)
Metamodelo Casos de Uso

LA SERVILLETA … FINAL DE LA CONFUSIÓN

 REFERENCIAS
• BOOCH G., JACOBSON I. y RUMBAUGH J.
(2002), “El lenguaje de Modelado Unificado”.
Madrid. Addison Wesley Longman, 464 p.

30