CASOS DE USO - ingswuniremington.files.wordpress.com · •Casos de uso son una técnica de...
Transcript of CASOS DE USO - ingswuniremington.files.wordpress.com · •Casos de uso son una técnica de...
CASOS DE USO
Elizabeth Suescún MonsalveD.Sc. Eng. Informática
PUC, Rio de Janeiro – [email protected]
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