CASOS DE USO

Elizabeth Suescún MonsalveD.Sc. Eng. Informática

PUC, Rio de Janeiro – Brazilelizabeth.uniremington@gmail.com

Agenda

• Reseña• Definición• Casos de uso vs Escenarios• Estructura de un caso de uso simple• Organización• Heurísticas para crear casos de uso• Estructura de un caso de uso completo

Modelo SADT para Ingeniería de Requisitos

[Leite 07]

MODELARDonde estamos?

Reseña

• Casos de uso son una técnica de descubrimiento de requisitos que se introdujo en 1993.

• Casos de uso son fundamentales en el modelado con UML.

• En su forma mas sencilla casos de uso identifica los actores y se nombra el tipo de interacción.

Definición

“Un caso de uso capta un contrato […] [que] describe el comportamiento del sistema en distintas condiciones y las que el sistema responde a una petición de alguno de sus participantes […]”

Alistair Cokburn

Definición

“Un caso de uso narra una historia estilizada sobre cómo interactúa un usuario final (que tiene ciertos roles posibles) con el sistema en circunstancias especificas.”

Pressman

Definición

“Un caso de uso es un texto narrativo, un lineamiento de tareas o interacciones.”

Pressman

Casos de Uso vs Escenarios

• No existe una diferencia muy grande entre escenarios y casos de uso.

• Casos de uso encapsulan varios escenarios.

• Cada escenario es un solo hito a través del caso de uso.

• Debe haber un escenario para cada interacción.

Estructura de un caso de uso simple

Varios casos de uso que involucran un mismo actor

Heurísticas para crear casos de uso

Definir los actores (1)

• Actores que estén involucrados en las historias.• Actores son aquellas personas o dispositivos que

usaran el sistema.• Todo actor tiene uno o más objetivo cuando usa

el sistema.

Heurísticas para crear casos de uso

Definir los actores (2

• Un usuario puede tener uno o más papeles dentro del sistema.

• Existen actores secundarios, estos dan apoyo al sistema, para que los actores primarios puedan hacer su trabajo.

Organización

Inclusión:El workflow del proceso entero está en el caso de uso base y el (los) caso(s) de uso incluido(s).Se usa para evitar describir el mismo flujo de eventos repetidas veces, poniendo el comportamiento común en un caso de uso aparte.Se representa con la dependencia estereotipada <<include>>

Organización

La inclusión se justifica cuando:

Se puede reusar en otros casos de uso el comportamiento incluido en el caso de uso base.

Simplifica la compresión del caso de uso base.

O sea, es bueno para reusar o para crear casos de uso que participan pero que no interactúan con el actor.

Organización

Ejemplo de include

Organización

Extensión:

Para modelar un workflow complejo o un sub-flujo separado, que raramente ocurre u ocurre bajo ciertas condiciones.

Se usa esta relación cuando se tiene un caso de uso que es similar a otro, pero que hace un poco más.

Flujos distintos que pueden ejecutarse en base a la selección del actor.

Organización

Ejemplo Extensión

Diferencia entre include o extend

ORGANIZACIÓN

Generalización-especificación

• Se aplica el mismo concepto de generalización de clases.

• El caso de uso hijo hereda comportamiento y significado del caso de uso padre.

• El hijo puede añadir o redefinir el comportamiento del padre.

Organización

Generalización-especificación

Herencia: el caso de uso origen hereda la especificación del caso de uso destino.

Organización

Generalización-especificación

Se usa para mostrar workflows que comporten estructuras, propósito y comportamiento.

Ejemplo: Un caso de uso padre se puede especificar en uno o más casos de uso hijos que representan formularios más específicos del padre.

Organización

Generalización-especificación

Se utiliza para:Para no tener que describir el mismo flujo varias veces, que puede ser colocado en el comportamiento común en un caso de uso.

Se recomienda usar cuando:Se puede afirmar que constituyen tipos de procesos. Generalmente tienen un comportamiento similar pero con diferencias sustanciales que provocan que sean considerados casos de uso diferentes.

Heurísticas para crear casos de uso

Preguntas que debe responder un caso de uso (1)

• Quien es el actor(es) principal y quien(es) secundario(s)?

• Cuáles son los objetivos de los actores?

• Qué precondiciones deben existir antes de comenzar la historia?

• Qué tareas o funciones principales son realizadas por el actor?

• Qué excepciones deben considerarse al describir la historia?

Heurísticas para crear casos de uso

Preguntas que debe responder un caso de uso (2)

• Cuáles variaciones son posibles en la interacción del actor?

• Qué información del sistema adquiere, produce o cambia el actor?

• Tendrá que informar el actor al sistema acerca de cambios en el ambiente externo?

• Qué información desea obtener el actor del sistema?

• Quiere el actor ser informado sobre cambios inesperados?

Importante

• Los casos de uso se definen desde el punto de vista de un actor.

• Un actor es un papel que desempeñan las personas (usuarios) o los dispositivos cuando interactúan con el software a ser construido.

Estructura de un caso de uso completo

Caso de usoActor principalObjetivo en contextoPrecondiciones DisparadorEscenarioExcepciones PrioridadCuándo estará disponibleFrecuencia de usoCanal para el actorActores secundariosCanales para los actores secundarios

Ejemplo: Continuando el Escenario CasaSegura

Actores identificados:

• Propietario de la casa: usuario.• Gerente de arranque: Tal vez la misma persona que el

propietario de la casa, pero en un papel diferente.• Sensores: dispositivos adjuntos al sistema• Subsistema de vigilancia y respuesta: estación central

que vigila la función de seguridad de la casa de CasaSegura.

El contexto

• Introduce una clave que permita todas las demás interacciones.

• Pregunta sobre el estado de una zona de seguridad.

• Interroga acerca del estado de un sensor.

• En una emergencia, oprime el botón de pánico.

• Activa o desactiva el sistema de seguridad.

La situación descrita de una forma general

1. El propietario observa el panel de control de CasaSegura para determinar si el sistema está listo para recibir una entrada. Si el sistema no está listo, se muestra el mensaje no esta listo en la pantalla de cristal liquido y el propietario debe cerrar físicamente ventanas o puertas de modo que desaparezca dicho mensaje [el mensaje no está listo implica que un sensor está abierto, por ejemplo, que una puerta o ventana está abierta].

La situación descrita de una forma general

2. El propietario usa el teclado para introducir una clave de cuatro dígitos. La clave se compara con la que guarda el sistema como válida. Si la clave es incorrecta, el panel de control emitirá un sonido una vez y se reiniciará para recibir una entrada adicional. Si la clave es correcta, el panel de control espera otras acciones.

La situación descrita de una forma general

3. El propietario selecciona y teclea permanecer o fuera para activar el sistema. La primera entrada permanecer activa sólo sensores perimetrales (se desactivan los sensores de detención de movimiento interior). La entrada fuera activa todos los sensores.

La situación descrita de una forma general

4. Cuando ocurre una activación, el propietario observa una luz roja de alarma.

La Alama de CasaSegura

Caso de uso básico (1)

• Presenta una historia de alto nivel del la interacción entre el usuario y el sistema.

Caso de uso básico (2)

Caso de uso básico (3)

Ejercicio

• Definir un caso de uso detallado para alguna de las siguientes funcionalidades:

Caso de uso básico

Referencias

1. Pressman, Roger S. Ingeniería del Software: Un enfoque práctico. Mc Graw Hill, Séptima Edición 2010.

2. Sommerville, Ian. Ingeniería del software. Pearson Educación, Novena Edición, 2011.

3. http://www.slideshare.net/123jou/actividad2-diagrama-de-casos-de-uso-del-negocio-y-del-sistema?related=3