Universidad de Tarapac Tecnologa de Objetos Clase Casos de Uso

Profesor: Eduardo Jaramillo C. Master of Science in Business Administration MBA Magster en Tecnologas de Informacin y Gestin

1. Introduccin a los casos de uso

Los casos de uso son relatos para describir requisitos funcionales

Son muy usados para descubrir y describir requisitos, principalmente funcionales:
Influencian varios aspectos de un proyecto, p.ej., anlisis y diseo Participan en varios artefactos subsecuentes, p.ej., visin y especificaciones suplementarias

Son relatos en texto acerca de un actor usando un sistema para lograr objetivos:
No son diagramas, sino principalmente texto La idea es simple, pero es difcil descubrir lo que se necesita y escribirlo bien

Ejemplo: Caso de uso Procesar Venta en formato breve

Un cliente llega a la caja con los artculos que quiere comprar; el cajero usa el sistema de PdV para registrar cada artculo comprado; el sistema muestra un total y detalles por artculo; el cliente ingresa informacin para pagar, que el sistema valida y registra; el sistema actualiza el inventario; el cliente recibe una boleta del sistema y se lleva los artculos que compr

2. Definiciones bsicas

Un actor es algo con comportamiento

P.ej.,
una persona (identificada por su rol con respecto al sistema): cajero, cliente, SII, etc. un sistema computacional una organizacin

(El propio sistema en estudio es un actor si llama a los servicios de otros sistemas) Hay 3 tipos de actores:
Actores principales Actores secundarios Actores fuera de escena

Un escenario es un relato particular de cmo usar un sistema

Escenario:
Una secuencia especfica de acciones e interacciones entre actores y el sistema tambin, una instancia de un caso de uso Un relato particular de cmo usar un sistema, o una ruta a travs del caso de uso

P.ej.,
el escenario de comprar exitosamente artculos con efectivo el escenario de no poder comprar artculos debido a una denegacin del pago con tarjeta de crdito

Los casos de uso involucran a actores y mltiples escenarios

Un caso de uso es una coleccin de escenarios exitosos y fallidos relacionados que describen a un actor usando un sistema para lograr un objetivo Tambin, un caso de uso es un conjunto de escenarios o instancias de casos de uso; cada instancia es una secuencia de acciones realizadas por un sistema que producen un resultado observable de valor para un actor particular

Ejemplo: Caso de uso Manejar Devoluciones en formato casual

Escenario exitoso principal:
Un cliente llega a una caja con los artculos que quiere devolver; el cajero usa el sistema de PdV para registrar cada artculo devuelto;

Escenarios alternativos:
Si el cliente pag con tarjeta de crdito, pero la transaccin de reembolso es rechazada, Si el cdigo identificador del artculo no se encuentra en el sistema, Si el sistema no consigue comunicarse con el sistema de contabilidad externo,

Los actores principales usan los servicios del sistema

Tienen objetivos de usuario que se logran usando servicios del sistema:
P.ej., el cajero del sistema de PdV

Los identificamos para encontrar los objeti-vos de usuario, que son los que motivan los casos de uso

Los actores secundarios proporcionan servicios al sistema

P.ej., el servicio automatizado de autorizacin de pagos A menudo son sistemas computacionales, pero podran ser organizaciones o personas Los identificamos para clarificar interfaces y protocolos externos

Los actores fuera de escena tienen inters en el sistema

Tienen inters en el comportamiento del caso de uso, pero no son principales ni secundarios:
P.ej., el servicio de impuestos internos

Los identificamos para asegurarnos que todos los intereses necesarios estn considerados:
Estos intreses son fciles de pasar por alto, si no los nombramos explcitamente

3. Por qu casos de uso?

Empleemos formas simples para capturar objetivos

Nosotros tenemos objetivos y queremos que los computadores nos ayuden a lograrlos:
Registrar ventas, jugar juegos, estimar el flujo de petrleo de futuros pozos

Las mejores formas para capturar objetivos son aqullas que son simples y familiares:
Facilitan especialmente a los clientes contribuir a su definicin y revisin, reduciendo el riesgo de equivocarse La falta de involucramiento de usuarios est al comienzo de la lista de razones por las que los proyectos de software fracasan

Los casos de uso enfatizan la perspectiva y objetivos del usuario

Hacemos las siguientes preguntas:
Quin est usando el sistema? Cules son sus escenarios de uso tpicos? Cules son sus objetivos?

ste es un nfasis ms centrado en el usua-rio comparado con simplemente preguntar por una lista de caractersticas del sistema

Los casos de uso son principalmente requisitos funcionales

Pueden ser usados para otros tipos de requisitos, especialmente cuando stos se relacionan estrechamente con un caso de uso. Un caso de uso define un contrato de cmo se comportar un sistema.

4. Pautas de estilo para escribir casos de uso

Hay 3 tipos de formatos (y niveles de formalidad)

Breve:
Resumen de un prrafo del escenario exitoso principal.

Casual:
Formato de prrafo informal; mltiples prrafos que cubren varios escenarios.

Completamente detallado:
Todos los pasos y variaciones estn escritos en detalle, y hay secciones de apoyo, p.ej., pre y poscondiciones

El formato completamente detallado incluye mltiples secciones

Nombre Alcance Nivel: objetivo de usuario o subfuncin Actor principal Interesados e intereses Precondiciones Poscondiciones Escenario exitoso principal Escenarios alternativos Requisitos no funcionales relacionados Variaciones tecnolgi-cas y de datos Frecuencia de ocurrencia Otros

Preguntemos por el objetivo del objetivo

En un taller de requisitos, el cajero dice que uno de sus objetivos es to log in:
El cajero est pensando en una GUI, cajas de dilogo, ID de usuario y contrasea Este es un mecanismo para lograr un objetivo; no es el objetivo propiamente tal

Al subir por la jerarqua de objetivos (Cul es el objetivo del objetivo?), llegamos a obje-tivos que no dependen de un mecanismo:
identificarme y ser autentificado prevenir robos

Dejemos fuera la GUI, concentrmonos en la intencin

La motivacin para esta pauta ha sido explorada en profundidad justamente en el contexto de crear mejores interfaces de usuario y hacer ingeniera de la usabilidad El estilo de escritura resultante se llama esencial:
La narrativa es expresada al nivel de las intenciones del usuario y de las responsabilidades del sistema, y no de sus acciones concretas Los casos uso en las transps. anteriores estn escritos siguiendo un estilo esencial

El estilo esencial deja abiertas las opciones de diseo

P.ej., si el caso de uso Manejar Usuarios requiere identificacin y autentificacin, lo escribimos as:
El administrador se identifica El sistema autentifica la identidad

La solucin de diseo para estos objetivos y responsabilidades est abierta:

Lectores biomtricos, GUIs, etc.

El estilo concreto incluye las decisiones de UI en el caso de uso

P.ej., Manejar Usuarios lo escribimos asi:
El administrador ingresa su ID y contrasea en una caja de dilogo (ver Fig.3) El sistema autentifica al administrador El sistema muestra la ventana editar usuarios

Los casos de uso concretos no son apropia-dos durante el anlisis inicial de requisitos:
pero pueden ser tiles durante el diseo detallado de la GUI, en etapas posteriores

Escribamos casos de uso de caja negra

Los casos de uso de caja negra no describen el funcionamiento interno del sistema, sus componentes, o diseo El sistema es descrito simplemente como teniendo responsabilidades:
Tema metafrico unificador comn en OO Los elementos de software objetos, mdulos tienen responsabilidades y colaboran con otros elementos que tambin tienen responsabilidades

En anlisis de requisitos evitemos tomar decisiones de cmo

P.ej.,
Escribamos El sistema registra la venta No escribamos El sistema escribe la venta en una base de datos ni tampoco El sistema genera una sentencia SQL INSERT para la venta

Especificamos lo que el sistema debe hacer anlisis de comportamiento o requisitos funcionales sin decidir cmo lo har diseo de la solucin

Tomemos la perspectiva del actor y su objetivo

La frase un resultado observable de valor para un actor particular, destaca dos actitudes durante el anlisis de requisitos:
Escribamos requisitos focalizndonos en los actores o usuarios de un sistema, preguntndonos por sus objetivos y situaciones tpicas Focalicmonos en entender qu considera el actor un resultado valioso

La industria del software est llena de proyectos fallidos que no entregaron lo que la gente quera realmente

5. Pasos para encontrar casos de uso

Para escribir casos de uso, sigamos los siguientes pasos

1.

Elijamos la frontera del sistema:

Es slo una aplicacin, la aplicacin ms el hardware como una unidad, sta ms la persona que la usa, o toda una organizacin?

2.

Identifiquemos los actores principales:

Aqullos que tienen objetivos que se logran usando los servicios del sistema

3. 4.

Identifiquemos los objetivos de cada actor Definamos casos de uso que satisfagan objetivos de usuario:
Normalmente, un caso de uso para cada objetivo

Paso 1: Elijamos la frontera del sistema

En nuestro ejemplo, el sistema de PdV es el sistema en estudio:
Todo lo que est fuera del sistema de PdV est fuera de la frontera del sistema, incluyendo cajero, sistema de autorizacin de pagos, etc.

Se pueden ilustrar otras fronteras posibles, ms all del sistema PdV:

Para la Caja, el actor principal es el Sistema de anlisis de ventas; el Cajero es parte del sistema Para el Supermercado, el actor principal es el Cliente; el Sistema de anlisis de ventas es parte del sistema

Actores, objetivos, sistemas, fronteras

Obj.: recaudar impuestos sobre las ventas

Supermercado Caja

Servicio de Impuestos internos Sistema de anlisis de ventas Cajero

Sistema PdV

Cliente
Obj.: comprar artculos

Obj.: analizar ventas y desempeo

Obj.: procesar ventas

Pasos 2 y 3: Encontremos los actores principales y sus objetivos

Es artificial hacer la identificacin de todos los actores principales estrictamente antes que la de los objetivos de usuario:
A veces, objetivos revelan a actores, o vice versa Sugerencia: Preguntmonos acerca de los actores principales primero

Adems de actores principales y objetivos obvios, las siguientes preguntas ayudan a identificar otros que se nos pueden pasar

Quin inicia y detiene el sistema? Quin hace gestin de usuarios y seguridad? Quin hace la administracin del sistema? Es el tiempo un actor? (si el sistema responde a eventos de tiempo) Hay un proceso que reinicie el sistema si ste falla? Cmo se actualiza el software? Quin evala el desempeo del sistema? Quin evala los logs? Son recuperados remotamente? A quin se le notifica cuando hay errores o fallas? Hay sistemas de software o robticos externos que llamen a los servicios del sistema?

Preguntemos por los objetivos de los actores, no por los casos de uso
En vez de preguntar Qu haces t?:
Las respuestas reflejarn soluciones y procedimientos vigentes, y las complicaciones asociadas

preguntemos Cules son tus objetivos cuyos resultados tienen valor observable?:
Las respuestas abren posibilidades a nuevas y mejores soluciones, se concentran en agregar valor de negocio, y van al corazn de lo que los interesados quieren del sistema

Paso 4: Definamos un caso de uso para cada objetivo de usuario

Nombremos el caso de uso similarmente al objetivo Empecemos el nombre con un verbo Una excepcin es colapsar los objetivos de crear, recuperar, actualizar, y eliminar <X> en un nico caso de uso Manejar <X> :
P.ej., los objetivos crear usuario, eliminar usuario, etc., son todos satisfechos por el caso de uso Manejar Usuarios

6. Cmo validar casos de uso?

Hay diferentes niveles de casos de uso

Cul de estos es un caso de uso vlido?
Negociar un contrato con un proveedor Manejar devoluciones Log in Mover una pieza en un tablero

Todos son casos de uso a diferentes niveles, dependiendo de la frontera del sistema, actores y objetivos

Validemos el nivel de los casos de uso

En lugar de preguntar,
Cul es un caso de uso vlido?

una pregunta ms prctica es

Cul es un nivel til para expresar casos de uso para el anlisis de requisitos de la aplicacin?

Pruebas para validar posibles casos de uso:

La prueba del jefe La prueba EBP La prueba del tamao

La prueba del jefe

Si el jefe nos pregunta,
Qu has estado haciendo todo el da?

Y nosotros le contestamos,
Logging in

Va a estar contento el jefe? Si el jefe no est contento, entonces el caso de uso no pasa la prueba del jefe:
El caso de uso no est relacionado con el logro de resultados de valor medible

La prueba EBP
Proceso de negocio elemental (EBP):
Una tarea realizada por una persona en un lugar y de una vez, en respuesta a un evento del negocio, que agrega valor de negocio medible y deja los datos en un estado consistente P.ej., Aprobar Crdito o Poner Precio a una Orden

Focalicmonos en casos de uso que reflejen EBPs:

Esta prueba es similar a la del jefe, en trminos de la calificacin de valor de negocio medible

La prueba del tamao

Rara vez un caso de uso es una accin o paso individual, tal como
Ingresar el ID de un Artculo Borrar una Lnea Imprimir el Documento

Un caso de uso tpicamente contiene varios pasos, y en el formato totalmente detallado a menudo requerir 3 a 10 pginas de texto

Aplicacin de las pruebas

Negociar un contrato con un proveedor:
Ms amplio y demoroso que un EBP Podra ser un caso de uso de negocio en vez de un caso de uso del sistema

Manejar devoluciones:
OK con el jefe; parece un EBP; tamao apropiado

Log in:
El jefe no est contento si es todo lo que hacemos todo el da

Mover una pieza en un tablero:

Paso individual falla la prueba de tamao

Hay excepciones razonables a las pruebas

A veces es til escribir casos de uso al nivel de subfuncin:
Subtareas o pasos dentro de un caso de uso al nivel EBP P.ej., si pagar con tarjeta de crdito aparece en varios casos de uso, lo separamos en su propio caso de uso y lo conectamos a los otros, para evitar duplicacin de texto

Autentificar Usuario falla la prueba del jefe:

Pero es suficientemente complejo para requerir un anlisis cuidadoso

Falla como EBP un caso de uso si necesita dos personas, o si una persona tiene que caminar?
Probablemente no

8. Aplicando UML a los casos de uso

El diagrama de casos de uso

Ilustra los nombres de los casos de uso y actores, y las relaciones entre ellos Proporciona un diagrama de contexto visual sucinto para el sistema:
Muestra la frontera del sistema, lo que est dentro y lo que est fuera

Sugerencias:
Mostrar los actores que son sistemas con una notacin diferente a la de los actores humanos Mostrar los actores primarios a la izquierda y los otros a la derecha

Procesar Venta Cliente Manejar Devoluciones Cajero frontera del sistema actor Ingresar Efectivo Analizar Actividad Manejar Seguridad Administrador del Sistema Manejar Usuarios

Diagrama de casos de uso

actor

Autorizacin de Pagos
actor

Clculo de Impuestos
actor

Contabilidad
actor

Supervisin de Actividad