Introduccin a casos de uso

Elementos de un modelo de casos de uso

Actores Casos de uso Relaciones

Introduccin

Los

CU forman parte de las especificaciones de UML 2.0, as como de metodologas de desarrollo, los mismos son empleados para la especificacin de requerimientos funcionales.

Introduccin

Cada analista de requerimientos debe conocer profundamente el significado

de escribir CU y el empleo que a stos se les dar. Los casos de uso son una manera de capturar requerimientos, para ser expresados a los equipos de anlisis, quienes encontrarn en estos su principal fuente para identificar objetos y clases.

Ejemplo resumido de caso de uso

Cuando utilizar los Casos de Uso?

Los casos de uso son un tipo de requerimientos utilizados para especificar

funcionalidad, especialmente en sistemas con un alto grado de interaccin hombre/mquina (y pueden ser utilizados hasta en sistemas de batch).

Cuando utilizar los Casos de Uso?

En esencia los casos de uso describen los intercambios entre el sistema que
se est describiendo y las personas o sistemas externos que interactan con el primero, por lo tanto son muy tiles para describir funcionalidades a varios tipos de usuarios y con muchas interfaces.

Para qu sirven los Casos de Uso?

Los casos de uso son tiles para capturar requerimientos, ayudar a definir la
arquitectura, establecer las pautas para el diseo y las pruebas funcionales. Los CU son una gua de los elementos que sern incluidos en los documentos de usuarios para las aplicaciones, as como la forma en como stos deben ser empleados. Los CU tambin establecen las bases para los protocolos de comunicacin entre aplicaciones y el diseo de las interfaces grficas, entre otros.

Para qu sirven los Casos de Uso?

La validez de los casos de uso viene dada cuando los usuarios e involucrados
del sistema aceptan el funcionamiento propuesto en los CU, siempre que la redaccin de los mismo sea buena, no dejando cabida a ambigedades.

Entonces los casos de uso deben ser tiles y ofrecer valor tanto al equipo de
usuarios e involucrados como a los desarrolladores del proyecto.

Qu es un Modelo de CU y que son los CU?

Los casos de uso describen secuencias de acciones que realiza un sistema y
que lleva a un resultado de valor a un actor especfico.

Un modelo de CU est compuesto por dos partes, un diagrama (grfico) y

una parte textual. El diagrama muestra las relaciones entre actores y casos de uso, as como las relaciones entre los CU y entre actores en caso que existan . La parte textual muestra la descripcin escrita en lenguaje natural que narra los pasos y dems caractersticas del caso de uso.

Caso de uso y actores

Casos de uso

Un caso de uso representa una unidad funcional coherente de un sistema,

subsistema o clase.

En un caso de uso uno o mas actores interaccionan con el sistema que

realiza algunas acciones.

Tipos de casos de uso

Segn cual sea el nivel de detalle

Resumidos o de 'alto nivel': Durante la fase de inicio la mayor parte de los casos de uso deben tener esta forma. Extensos: Durante la fase de elaboracin los casos de uso deben escribirse de esta forma. Esenciales

Tambin se distingue entre:

De implementacion,
Reales o concretos: hacen referencia a detalles de la interface

Actores
Un actor podra ser cualquier cosa que se comunica (interacciona) con el
sistema y que es externo a el.

Los

actores representan papeles (ROLES) que interpretan personas, perifricos u otros sistemas cuando el sistema esta en uso.
una entidad (sistema, subsistema, clase) pueden desempear al interaccionar con la misma.

Un actor representan un conjunto coherente de papeles que los usuarios de

Tipos de Actores
Primarios:
interaccionan con el sistema para explotar su funcionalidad; trabajan directa y frecuentemente con el software. el trabajo de otro actor. (No aparecen en UML pero s los consideran otros autores)

Secundarios: soporte del sistema para que los primarios puedan trabajar. Iniciadores: no utilizan directamente el sistema pero desencadenan

Flujo bsico

Concepto

El flujo bsico (FB) describe los pasos que se sucederan en el escenario del
mundo perfecto o del da feliz. El flujo bsico es un camino simple, sin ramificaciones y en l suelen hacerse una serie de asunciones, las alternativas a estos presuntos son los flujos alternos.

Cada paso del flujo bsico contiene

Un nmero de paso o flujo Titulo del paso y La descripcin del paso.

La numeracin del paso es un consecutivo que inicia con el nmero 1 en el primer paso. El ttulo del paso representa un resumen de lo que el paso realiza, suele ser una oracin que inicia con un verbo en estado activo Ej. crear usuario, buscar datos de clientes mayores. La descripcin del paso contiene el detalle de lo que se espera que ocurra en el paso.

Dependiendo de la complejidad del sistema o los datos manejados, los pasos pueden tener varios intercambios

NOTA

Es obligatorio que cada paso contenga el nmero del paso y su ttulo, la descripcin puede ser opcional en casos de uso cuyos pasos se limitan a la oracin del ttulo.

Los pasos de los flujos bsicos no contienen, nunca, referencias a los flujos alternos ni a flujos bsicos.
La descripcin del primer paso del FB indica que actor comienza el flujo y cul es el disparador del mismo, ejemplo El caso de uso inicia cuando el Administrador de Tablas de O/S indica al sistema la opcin de visualizar rdenes de servicio.. El ltimo paso del flujo bsico cierra indicando que el caso de uso termina, o finaliza.

Flujos alternos

Concepto
Los flujos alternos (FA) se definen como flujos independientes, no como
subflujos, permitiendo hacer que un flujo alterno aplique de manera global a todo el CU, o a varios flujos bsicos u alternativos. Mantener los FA de forma plana facilita su lectura, su escritura y su comprensin. El formato utilizado emplea una seccin separada para los flujos alternos. Los flujos alternos pueden hacer referencia a flujos bsicos u otros flujos alternos.

Todos los FA deben indicar (en este orden):

Dnde comienzan? Desde donde parte este FA, puede ser un FB o un FA. Qu los dispara? Que hace que este FA inicie Qu sucede? Lo que pasa cuando el FA es invocado, anlogo al FB. A dnde regresa? Una vez que termina de ejecutarse el flujo alterno, A dnde regresa la ejecucin del caso de uso?

El siguiente es un ejemplo de un FA

NOTA
Al igual que los FB, los FA cuentan con un nmero de flujo, un ttulo y una
descripcin.

El nmero de flujo es un secuencial que se inicia en 1 con el primer FA del CU.

El ttulo describe la accin que realiza FA y se escribe con las mismas normas que en los FB, sin embargo, los FA que indican excepciones se presentan de forma diferente, se indica que son excepciones y el comportamiento que es errneo, no se escriben comenzando con verbo en forma activa. La descripcin debe contener la respuesta a las cuatro preguntas presentadas en el mismo orden en que se encuentran listadas.

Escenarios

Tipos de escenarios

Escenario principal Escenario Alternativo Escenario de Excepcin

Escenario principal
El escenario principal representa el flujo exitoso ms simple o habitual para
el caso de uso.

En general los escenarios son una secuencia de pasos que realiza el actor
principal o el sistema, en donde cada paso se escribe como una oracin sobre una meta que se cumple.

Escenario Alternativo

Son formas alternativas al camino princial de llegar a las postcondiciones del

caso de uso.

Son caminos distintos al principal pero que nos permiten de todas formas
alcanzar el xito.

Escenario Alternativo
Cada escenario alternativo parte de una condicin que origina la bifurcacin.
Luego se indica en qu paso contina o si, por el contrario, el escenario termina.

La

condicin debe ser una condicin detectable por el sistema. Ej. "Se prendi fuego el servidor" no tiene sentido. chequeos, selecciones, etc.

Los caminos alternativos se generan usualmente a partir de validaciones,

Ejemplo - CU Dar de Alta cliente

Escenario Principal 1. El sistema muestra el formulario de alta de cliente. 2. El usuario completa los datos del cliente y selecciona la opcin 'agregar'. 3. El sistema verifica los datos de entrada. 6. El sistema registra al cliente. 7. Fin. Escenario Alternativo 3.a condicin: Faltan ingresar datos de entrada obligatorios. 3.a.1. El sistema informa que faltan ingresar datos de entrada obligatorios. 3.a.2. El sistema muestra el formulario de alta indicando los campos faltantes. 3.a.3. Vuelve al paso 2.

Escenario de Excepcin

Un escenario de excepcin es una secuencia de pasos alternativos a los del

camino principal que lleva a que el objetivo del caso de uso NO sea alcanzado, es decir que no se logre llegar a las post-condiciones el sistema.

Son caminos que hacen que el usuario no pueda cumplir con su objetivo.

Ejemplo - CU Autorizar operacin X

Escenario Principal 1. El sistema muestra el formulario de autorizacin. 2. El usuario secciona la opcin 'autorizar'. 3. El sistema autoriza la operacin X. 4. ... Excepcin 3.a condicin: El usuario no tiene permiso de autorizacin. 3.a.1. El sistema informa que el usuario no tiene permiso de autorizacin. 3.a.2. FIN

Hace falta escribir todos los escenarios?

Idealmente si. Para que un caso de uso sea completo debe manejar todas las
alternativas de interaccin posibles, todos los escenarios que pueden darse en el uso real.

Si por algn motivo uno decide no escribir todos los escenarios, pensar al
caso de uso en funcin de estos tres tipos de caminos nos ayuda al menos a analizar que pasa en cada caso, ms all de que los escribamos o no.

Hace falta escribir todos los escenarios?

Evaluar aunque sea mentalmente todos los caminos, nos permite identificar
validaciones, acciones, reglas de negocio, excepciones, etc. haciendo que el anlisis sea mucho ms completo y que estas cosas no sean encontradas recin al momento de la implementacin cuando un programador nos viene a decir "y cuando entra por el ELSE que pasa?".

Relaciones de uses y extend

Asociaciones entre actores y casos de uso

Se representan mediante una lnea continua Significan la participacin del actor en el caso de uso Pueden indicarse restricciones de cordialidad

Generalizacion-especializacion entre actores

Indicaran que un actor es mas general que otro Si A es una especializacin de B, una instancia de A podr comunicarse con
los mismos casos de uso que B

Ejemplo - Generalizacion

Relaciones entre casos de uso

Entre casos de uso pueden darse relaciones:

Extensin (extend) Inclusin (include) Generalizacin - Especializacin

Inclusin
El

caso de uso inicial incluye el comportamiento del caso de uso final (subcasos). relacin A include a B significa que una instancia de A tambin incorporara el comportamiento especificado en B.

Una

Se incorporara en el lugar indicado en A.

Ejemplo - Include

Extensin

El caso de uso final se puede extender con el comportamiento del caso de uso inicial en un punto concreto del primero. si A extend B, significa que una instancia del caso de uso B podr incorporar el comportamiento especificado en A (si se cumplen las condiciones especificadas en el punto de extensin). El comportamiento se aadir en el punto de extensin de B, referenciado por la relacin extend. Un punto de extensin es una referencia al interior del caso (B), hacia el punto donde se podrn insertar secuencias de acciones de otros casos (A).

Ejemplo - Extend

Recomendaciones para escribir casos de uso

Recomendacin 1

Buscar una comunicacin real entre actores y sistema

Recomendacin 2

No complicar las cosas

Recomendacin 3

Tener en cuenta a los interesados (stakeholders)

Recomendacin 4

Lo mejor es enemigo de lo bueno (El caso de uso hay que terminar por
escribirlo en algn momento)

Recomendacin 5

Hay que revisar los casos de uso cuidadosamente, junto con el usuario.

Recomendacin 6

Los casos de uso deben describir la interaccin entre el actor y el software

sin ambigedad.

Recomendacin 7

Permiten expresar tanto requisitos funcionales como no funcionales.

Recomendacin 8

Expresan el funcionamiento del sistema como un TODO (no de sus partes).

Recomendacin 9

Se pueden priorizar los casos de uso, con una escala de 1 a 10 p.e., para
desarrollar el sistema incrementalmente.

Recomendacin 10

Los casos de uso aumentan la trazabilidad del sistema.

Recomendacin 11

Los casos de uso permiten desarrollar casos de prueba.

Gracias por su atencin