Вы находитесь на странице: 1из 42

CASOS DE USO

DIAGRAMAS DE CASOS DE USO

CASOS DE USO Que es un caso de uso?


Es un conjunto de escenarios que tienen una meta de Usuarios en comn
Martin Fowler

Un caso de uso especifica un conjunto de secuencias de acciones, incluyendo variantes, que el sistema puede ejecutar y que produce un resultado observable de valor para un particular actor
(Definicin en UML)

Los Casos de Uso describen qu hace el sistema, no cmo lo hace

Ejemplo Registro en un Foro Pero Luego empiezan las Preguntas??


(Historia referida por un Usuario) Yo quisiera como usuario poder registrarme en el sistema

Que datos quisiera colocar en el registro? Que pasa si el nombre de Usuario esta asignado? Que pasa si el correo esta siendo utilizado por otro usuario? Que pasa si el usuario introduce mal la clave de verificacin? Que pasa con la activacin? El usuario se activa automticamente o la activa el administrador , o el usuario recibe un correo y a travs del correo la activa?

La historia de usuario define una funcionalidad bsica que le da valor al usuario. El Caso de uso detalla esos posibles escenarios y las posibles causas que puedan ocurrir

CASOS DE USO Que es un caso de uso?


Es una manera especifica de utilizar el sistema, es una historia que describe el uso particular del Sistema. Es la imagen de una funcionalidad del sistema, desencadenada en respuesta al estimulo de un actor o rol externo.
EL actor hace algo en el sistema y el caso de uso se dispara o arranca. Se pone a funcionar.

Siguiendo con el ejemplo del Registro en un Foro Imaginemos que el registro en el foro tiene varias etapas 1. 2. 3. Llenar el formulario de registro Ir al correo y recibir el link de activacin y activar el link. Introducir datos adicionales para finalizar la activacin

Un caso de Uso no describe una sola de esas etapas, describe todo el proceso de inicio a fin; el proceso completo de registro que le da valor de alguna forma al sistema frente al usuario. Es muy interactivo en funcin del actor que esta asociado.

ESCENARIOS?

Escenario?
Cuando se habla de escenario se plantea algo que puede ocurrir. Ejemplo.
Puede Ocurrir que el nombre de usuario que la persona introdujo en el foro para el registro no este utilizado. Entonces hago esto, esto y esto O puede ocurrir que el nombre del usuario s esta registrado. Entonces tengo que ofrecerles alternativas de nombre

Escenario desde el punto de vista de un caso de uso ?


Es una secuencia de acciones e interacciones(pasos) entre los usuarios (actores) y el sistema .. Por ejemplo
EL usuario introduce su nombre de usuario y contrasea. El sistema verifica la validez del nombre de usuario y de la contrasea y permite al usuario el acceso al sistema. El sistema muestra la pantalla principal. El usuario selecciona la opcin de aadir nuevo empleado. El sistema muestra..

Actor o Rol?
Un actor representa el rol jugado por una persona o cosa que acta con el sistema. (Se piensa en algo
genrico no en una persona en particular)

Cliente, Administrador, Usuario no registrado, Usuario registrado, jefe de compras, Jefe de Personal, Moderador, Jefe de departamentos, Obrero de Planta, Supervisor.

NOTA: NO TODOS los interesados en el sistema (stakeholder) son actores, sol son actores aquellos que utilizarn el sistema.

CASOS DE USO (Algunas Caractersticas)


Actualmente mucha gente considera que los casos de uso son de vital importancia en los proyectos de Software (Procesos guiados por casos de uso)

Describen bajo la forma de acciones y reacciones el comportamiento de un sistema desde el punto de vista de un usuario

Se puede considerar que hasta cierto punto, cada caso de uso es independiente de los dems
Permiten definir los limites del sistema y las relaciones entre el sistema y su entorno

!
Un Caso de Uso NO es un Diagrama, NO es un smbolo dentro de un diagrama

....es una forma de describir un escenario de interaccin usuario sistema.. .. Los diagramas vienen despus(o antes) y son una forma de tener una visin general de los casos de uso, sus relaciones con los actores y con otros casos de uso.

Descripcin textual de los actores del sistema


Requerimientos: Quienes interactan con el sistema?
Nombre:
Descripcin: <descripcin del actor> Nombre: Usuario no Autenticado

< nombre del actor>

Descripcin:
Representa aun usuario que no se a identificado frente al sistema. Generalmente estos usuarios deberan poder registrarse (crear un nuevo usuario) o ingresar al sistema para transformarse en usuarios autenticados, en moderadores o en administradores del sistema

Descripcin textual de los actores del sistema


Requerimientos: Quienes interactan con el sistema?

Se describen todos los potenciales actores que esta involucrados con el sistema. La tabla se puede incorporar al documento de requisitos. Es flexible y se puede agregar otros datos adicionales segn sus necesidades. Terminar con una lista de actores Asociar funcionalidades del sistema a un actor No debe ser lineal

Descripcin textual de los Casos de Uso


Requerimientos: Que debe Hacer el sistema?
Nombre: Autor: Fecha: Descripcin:
<Breve descripcin del caso de Uso> <Nombre del Caso de Uso> <Nombre del Autor o Autores del Caso de Uso> <Fecha de creacin del Caso de Uso>

Actores:
<Actores participantes en el caso de Uso>

Precondiciones:
<Condiciones que deben cumplirse para poder ejecutar el caso de uso>

Flujo Normal:
<Flujo normal de ejecucin del caso de Uso>

Flujo Alternativo:
<Flujo alterno de ejecucin del caso de Uso>

Poscondiciones:
<Condiciones que deben cumplirse al finalizar la ejecucin de un caso de uso> Planilla de Caso de Uso(Generales)

Descripcin textual de los Casos de Uso


Ejemplo:

Para cada caso de uso se define una documentacin. El caso de uso como tal es la documentacin de ese caso de uso (NO el Diagrama). Una Planilla o plantilla no tiene que ser exactamente igual a la expuesta. Esta puede ser una referencia.

Descripcin textual de los Casos de Uso


Ejemplo:
Nombre: Autor: Fecha: Descripcin: Crear Mensaje Foro Pedro Perez 21/04/2009

Permite crear un nuevo mensaje en el foro de discusin


Actores: Usuario/Moderador

Precondiciones:
El usuario debe estar autenticado en el sistema

Contina.

Descripcin textual de los Casos de Uso


Ejemplo:
Flujo Normal: 1. El Actor(Usuario) pulsa sobre el botn para crear un nuevo mensaje. 2. El sistema muestra una caja de texto para introducir el titulo del mensaje y una zona de mayor tamao para introducir el cuerpo del mensaje. 3. El actor introduce el titulo del mensaje y el cuerpo del mismo. 4. El sistema comprueba la validez de los datos y los almacena. 5. El moderador recibe una notificacin de que hay un nuevo mensaje en la cola de moderacin. 6. El modelador acepta el mensaje 7. El sistema publica el mensaje. Flujo Alternativo: 4. A . El sistema comprueba la validez de lo datos, si los datos no son correctos, se avisa al actor de ello, permitindole que los corrija. 6.B. El moderador rechaza el mensaje, de modo que no es publicado, sino devuelto al usuario. Poscondicion del flujo normal: El mensaje ha sido almacenado en el sistema y fue publicado

Descripcin textual de los Casos de Uso


Requerimientos: Que debe Hacer el sistema?
En general hay muchas variaciones sobre como escribir un caso de uso

UML no define ningn estndar al respecto

Seleccione o disee una o mas plantillas que considere adecuadas para sus necesidades
Conozca bien la plantilla que va a utilizar, sepa para que sirve cada campo (argumente sobre su utilidad y sea coherente a lo largo de todas las plantillas.

Por Ejemplo en la aplantilla anterior seria bueno aadir un campo Prioridad


Nombre: Autor: Fecha: Prioridad Crear Mensaje Foro Pedro Prez 21/04/2009 5

Descripcin: Permite crear un nuevo mensaje en el foro de discusin Actores: Usuario/Moderador Precondiciones: El usuario debe estar autenticado en el sistema

Cmo se desarrolla un modelo de Casos de Uso?

Descripcin textual de los Casos de Uso Requerimientos: Que debe Hacer el sistema?

Antes de Hacer un caso de uso es necesario tratar de entender los requerimientos del sistema. Trate de expresar lo que el sistema debe hacer.

..el sistema debe permitir a los usuarios registrarse. El administrador debe poder validar las peticiones de registro antes de que los usuarios puedan publicar nuevos mensajes.
En base a esto, trate de responder las preguntas Cuales son las tareas del/los actores involucrados? Debe el Actor informar al sistema de cambios externos ocurridos? Qu datos debe el actor crear, guardar, modificar, destruir, leer? Debe el sistema informar al actor de cambios internos?

Ingresar al Sistema Ver Lista de Mensajes

Usuario Usuario
Leer un Mensaje
Ver lista de mensajes pendientes por agregar

Crear un nuevo mensaje Agregar o Rechazar un Mensaje

Usuario Autenticado Moderador

Responder un mensaje

Usuario Autenticado

DIAGRAMA DE CASO DE USO

Moderador

Ingresar al Sistema Ver Lista de Mensajes

Usuario Usuario
Leer un Mensaje
Ver lista de mensajes pendientes por agregar

Crear un nuevo mensaje Agregar o Rechazar un Mensaje

Usuario Autenticado Moderador

Responder un mensaje

Usuario Autenticado

DIAGRAMA DE CASO DE USO

Moderador

Relaciones entre Casos de Uso?


Estas relaciones nos permiten reutilizar algunos textos, algunas descripciones de los casos de uso para no redundar y escribir menos .
Tambin nos permite una mejor organizacin de los mismos

Limite del Sistema


Usado para modelar por separado el comportamiento excepcional del caso de uso base

Caso de Uso Incluido

Caso de Uso <<Extend>>

Extensin Caso de Uso

Actor
Caso de Uso Especializado Usado para heredar el comportamiento y significado del Caso de Uso principal

<<Especializacin>>

RELACIONES ENTRE CASOS DE USO

Limite del Sistema


Crear Entidad

Consultar Entidad

Listar/Buscar Entidad

Modificar Entidad

<<CRUD>> ENTIDAD

Actor

Ojo este es un ejemplo de un posible Estereotipo no se lo tomen literal.

Eliminar Entidad

Actor

RELACIONES ENTRE CASOS DE USO

DIFERENTES FORMAS DE DISGRAMAR CASOS DE USO


1

Registrar nuevo Usuario

Usuario

Evaluar Solicitud
Crear un Nuevo mensaje

Moderador

Usuario Autenticado

Responder a un mensaje

De esta forma debe describirse el caso de uso evaluar solicitud cuando se registra un nuevo usuario etc.

RELACIONES ENTRE CASOS DE USO

DIFERENTES FORMAS DE DISGRAMAR CASOS DE USO


2

Registrar nuevo Usuario

Usuario

Crear un Nuevo mensaje

Moderador

Usuario Autenticado

Responder a un mensaje

De esta manera la aceptacin o rechazo lo tengo que describir en cada uno de los casos de uso.

RELACIONES ENTRE CASOS DE USO

Ejemplo Include/ Extends ( Puntos de Extensin)

Sistema de Compra
Pagar en Efectivo

Comprar Producto

Pagar con Debito

<<Extend>> Debito Pagar con Crdito

Usuario

RELACIONES ENTRE CASOS DE USO

Ejemplo Include/ Extends ( Puntos de Extensin)

Sistema de Compra
Pagar en Efectivo

Puntos de extensin es bajo que condicin se invoca los distintos casos de usos. En la inclusin el caso de uso es incluido es obligatorio. En la extensin es opcional por que si el cliente decide pagar en crdito, definitivamente ni se va a invocar pagar con efectivo, ni se va invocar pagar con crdito.

Comprar Producto _____________


Puntos de Extensin

Pagar con Debito

Cliente

Efectivo Credito Debito

<<Extend>> Debito Pagar con Crdito

RELACIONES ENTRE CASOS DE USO

NOTAS COMENTARIOS EN UML


Este es un Comentar io/Nota

Sistema de Compra
Pagar en Efectivo

Colocar Notas de Comentarios es til para decir cosas aclaratorias en un caso se uso.

Comprar Producto _____________


Puntos de Extensin

Cliente

Efectivo Credito Debito

Pagar con Tarjeta

<<Extend>> Debito/ Crdito

Una Extensin puede estar asociada a varios puntos de extensin.

Ejemplo Include/ Extends ( Puntos de Extensin)

Algunas reglas de estilos (para los diagramas de caso de Uso)


Cada actor y caso de uso debe tener un nombre nico
Los actores deben tener nombres y/o iconos representativos. Los nombres de los actores deben representar roles Ej. No colocar como nombre a un actor Inscribir- errneo Encargado de inscripcin, Sistema Admistrativo

El nombre de un caso de uso debe indicar accin y debe ser claro y conciso

Forma General: Verbo (Infinitivo)+ predicado


Las cosas que indican Accin son verbos

Imprimir Reportes de Ventas

Algunas reglas de estilos (para los diagramas de caso de Uso)

Mantener todos los casos de usos a un mismo nivel de abstraccin. Eje: Caso uso Foro web.
Evitar el cruce de lneas (En general Mantenga el diagrama ordenado).
El diagrama esta pensado para poderse leer, que uno lo vea y entienda la intensin del diagrama.

Evite tener demasiados casos de uso en el mismo diagrama y si los va atener que estn muy bien ordenado. Evite el uso complejo de relaciones de Extensin, Especializacin, e Inclusin (Nomas de tres niveles). En general, use el Sentido Comn.

VISION (Estrategias para los diagramas)


El diagrama tiene que ser algo que va a servir. Cada diagrama que se haga, es un diagrama que va tener que mantener.

Un diagrama, que cuando cambie el sistema tiene que actualizarlo, puede llegar a tener mucho trabajo actualizarlo.
Cada diagrama debe tener un sentido y un valor, si el diagrama no tiene un sentido y un valor , vtelo.

Algunas reglas de estilos (para la descripcin textual del caso de uso)

Narrar el flujo de eventos usando voz activa, en tiempo presente y desde la perspectiva del actor

Evitar el uso de la voz pasiva

La clave es introducida por el usuario. El usuario introduce la clave. El sistema valida la clave.

Preferir la voz activa.

Algunas reglas de estilos (para la descripcin textual del caso de uso) Exprese cada paso del flujo usando la forma llamada y respuesta(refleja el hecho de que el actor ejecuta algo y el sistema responde a la solicitud del actor El actor introduce su nombre de usuario y contrasea El sistema valida si los datos concuerdan con lo que esta almacenado. El caso de uso que se describe debe expresar un solo requisito funcional (No trate de expresar mas de un requisito funcional en el mismo caso de uso. Sin embargo , un caso de uso puede expresar ms de un requisito NO funcional (Esto esta Bien) Ej: el tiempo de respuesta debe ser menor a 10 segundo La interfaz de usuario debe tener tales y tales caractersticas

Ejemplo Diagrama Casos de Uso Sistema FORO


Actualiza base de datos
Activar usuario <<Extend>>
Leer mensaje

Registro de usuarios
Ver lista de mensajes

Nuevo Mensaje
<<Extend>>

Usuario

Base de Datos

<<Extend>> <<Extend>> Crear nuevo mensaje Aceptar registro <<Extend>> Aceptar mensaje Hacer mensaje visible

Sistema FORO

<<Extend>>

Supervisar

<<Extend>> Responder mensaje

<<Extend>>

Que errores puede encontrar en el diagrama?

Errores en el diagrama
Cruce de lneas Mltiples Extensiones Limite del sistema Nombre del actor (Supervisar), Base de Datos Nombre de los casos de uso (solicitudes pendientes, nuevo mensaje, actualiza base de datos, hacer mensaje visible(redactar de una forma mas elegante). Representando el sistema que estoy modelando como un actor. Representado base de datos como un sistema y se esta representando con un monigote.

El sistema Anterior Mucho mejor Representado


CU-01 Ingresar al Sistema CU_02 Ver Lista de Mensajes Usuario No Autenticado CU-03 Registrar Usuario

Usuario
CU-06 Procesar Solicitudes Registro

<<Extend>>
CU-08 Listar solicitudes pendientes

CU-04 Publicar nuevo mensaje CU-07 Procesar Publicacin del Mensaje

<<Extend>>

Moderador

Usuario Autenticado

Usuario Autenticado

CU-05 Responder mensaje

Moderador

NOTA:
Es buena idea que los nombres de los casos de usos sean relativamente simples, describan bien la funcionalidades del sistema.

Es buena idea en algunos casos ponerle un cdigo a los casos de uso, a los requisitos y a las historias de usuarios.
Por que? Por que es mucho mas fcil a veces manejar el papeleo con el cdigo que con los nombres de los casos de uso.