Casos de Uso
-
Upload
yenis-zuniga -
Category
Documents
-
view
183 -
download
2
description
Transcript of Casos de Uso
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 común
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”
(Definición en UML)
Los Casos de Uso describen qué hace el sistema, no cómo lo hace
Ejemplo Registro en un Foro
(Historia referida por un Usuario)
Yo quisiera como usuario poder registrarme en el
sistema
Pero Luego empiezan las Preguntas?? 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 verificación? Que pasa con la activación? El usuario se activa automáticamente o la activa el administrador , o el usuario recibe un correo y a través del correo la activa?
La historia de usuario define una funcionalidad básica 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. Llenar el formulario de registro 2. Ir al correo y recibir el link de activación y activar el link. 3. Introducir datos adicionales para finalizar la activación
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 función 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 contraseña. El sistema verifica la validez del nombre de usuario y de la contraseña y
permite al usuario el acceso al sistema. El sistema muestra la pantalla principal.
El usuario selecciona la opción de añadir nuevo empleado. El sistema muestra…………………………..
¿Actor o Rol?
Un actor representa el rol jugado por una persona o cosa que actúa con el sistema. (Se piensa en algo
genérico 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 utilizarán el sistema.
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 demás
CASOS DE USO (Algunas Características)
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 símbolo dentro de un diagrama……
..…..es una forma de describir un escenario de interacción usuario sistema……..
….. Los diagramas vienen después(o antes) y son una forma de tener una visión general de los casos de uso, sus relaciones con
los actores y con otros casos de uso.
!
Descripción textual de los actores del sistema Requerimientos: ¿ Quienes interactúan con el sistema?
Nombre: < nombre del actor>
Descripción: <descripción del actor>
Nombre: Usuario no Autenticado
Descripción: Representa aun usuario que no se a identificado frente al sistema. Generalmente estos usuarios deberían poder registrarse (crear un nuevo usuario) o ingresar al sistema para transformarse en usuarios autenticados, en moderadores o en administradores del sistema
Descripción textual de los actores del sistema Requerimientos: ¿ Quienes interactúan 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 según sus necesidades. Terminar con una lista de actores Asociar funcionalidades del sistema a un actor No debe ser lineal
Descripción textual de los Casos de Uso Requerimientos: ¿ Que debe Hacer el sistema?
Nombre: <Nombre del Caso de Uso>
Autor: <Nombre del Autor o Autores del Caso de Uso>
Fecha: <Fecha de creación del Caso de Uso>
Descripción: <Breve descripción 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 ejecución del caso de Uso>
Flujo Alternativo: <Flujo alterno de ejecución del caso de Uso>
Poscondiciones: <Condiciones que deben cumplirse al finalizar la ejecución de un caso de uso>
Planilla de Caso de Uso(Generales)
Descripción textual de los Casos de Uso Ejemplo:
Para cada caso de uso se define una documentación.
El caso de uso como tal es la documentación 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.
Descripción textual de los Casos de Uso Ejemplo:
Nombre: Crear Mensaje Foro
Autor: Pedro Perez
Fecha: 21/04/2009
Descripción: Permite crear un nuevo mensaje en el foro de discusión
Actores: Usuario/Moderador
Precondiciones: El usuario debe estar autenticado en el sistema
Continúa…….
Descripción textual de los Casos de Uso Ejemplo:
Flujo Normal: 1. El Actor(Usuario) pulsa sobre el botón para crear un nuevo mensaje. 2. El sistema muestra una caja de texto para introducir el titulo del mensaje y una zona
de mayor tamaño 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 notificación de que hay un nuevo mensaje en la cola de
moderación. 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, permitiéndole 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
En general hay muchas variaciones sobre como escribir un caso de uso
UML no define ningún estándar al respecto
Seleccione o diseñe 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.
Descripción textual de los Casos de Uso Requerimientos: ¿ Que debe Hacer el sistema?
Nombre: Crear Mensaje Foro
Autor: Pedro Pérez
Fecha: 21/04/2009
Prioridad 5
Descripción: Permite crear un nuevo mensaje en el foro de discusión
Actores: Usuario/Moderador
Precondiciones: El usuario debe estar autenticado en el sistema
Por Ejemplo en la aplantilla anterior seria bueno añadir un campo Prioridad……
¿Cómo se desarrolla un modelo de Casos de Uso?
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?
Descripción textual de los Casos de Uso Requerimientos: ¿ Que debe Hacer el sistema?
¿Qué datos debe el actor crear, guardar, modificar, destruir, leer?
¿Debe el Actor informar al sistema de cambios externos
ocurridos?
¿Debe el sistema informar al actor de cambios internos?
Ingresar al Sistema
Ver Lista de Mensajes
Leer un Mensaje
Crear un nuevo mensaje
Responder un mensaje
Agregar o Rechazar un
Mensaje
Ver lista de mensajes pendientes por
agregar
Usuario
Usuario Autenticado
Moderador
Moderador
Usuario Autenticado
Usuario
DIAGRAMA DE CASO DE USO
Ingresar al Sistema
Ver Lista de Mensajes
Leer un Mensaje
Crear un nuevo mensaje
Responder un mensaje
Agregar o Rechazar un
Mensaje
Ver lista de mensajes pendientes por
agregar
Usuario
Usuario Autenticado
Moderador
Moderador
Usuario Autenticado
Usuario
DIAGRAMA DE CASO DE USO
¿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 . También nos permite una mejor organización de los mismos
Extensión Caso de Uso
Caso de Uso
Caso de Uso Incluido
Actor
RELACIONES ENTRE CASOS DE USO
Caso de Uso Especializado
<<Extend>>
<<Especialización>>
Limite del Sistema
Usado para heredar el
comportamiento y significado del
Caso de Uso principal
Usado para modelar por separado el
comportamiento excepcional del
caso de uso base
Modificar Entidad
Listar/Buscar Entidad
Crear Entidad
Actor
Ojo este es un ejemplo de un
posible Estereotipo no se lo tomen
literal….
Limite del Sistema
Consultar Entidad
Eliminar Entidad
<<CRUD>> ENTIDAD
Actor
RELACIONES ENTRE CASOS DE USO
Registrar nuevo Usuario
Crear un Nuevo mensaje
Responder a un mensaje
Evaluar Solicitud
Moderador
Usuario Autenticado
Usuario
De esta forma debe describirse el caso de uso evaluar solicitud cuando se registra un nuevo usuario etc.
1
DIFERENTES FORMAS DE DISGRAMAR CASOS DE USO
RELACIONES ENTRE CASOS DE USO
Registrar nuevo Usuario
Crear un Nuevo mensaje
Responder a un mensaje
Moderador
Usuario Autenticado
Usuario
DIFERENTES FORMAS DE DISGRAMAR CASOS DE USO
De esta manera la aceptación o rechazo lo tengo que describir en cada uno de los casos de uso.
2
RELACIONES ENTRE CASOS DE USO
Comprar Producto
Pagar con Debito
Pagar con Crédito
Usuario
Ejemplo Include/ Extends ( Puntos de Extensión)
Sistema de Compra
RELACIONES ENTRE CASOS DE USO
Pagar en Efectivo
<<Extend>> Debito
Comprar Producto
_____________Puntos de Extensión
Efectivo Credito Debito
Pagar con Debito
Pagar con Crédito
Cliente
Ejemplo Include/ Extends ( Puntos de Extensión)
Sistema de Compra
RELACIONES ENTRE CASOS DE USO
Pagar en Efectivo
<<Extend>> Debito
Puntos de extensión es bajo que condición se invoca los distintos casos de usos. En la inclusión el caso de uso es incluido es obligatorio. En la extensión es opcional por que si el cliente decide pagar en crédito, definitivamente ni se va a invocar pagar con efectivo, ni se va invocar pagar con crédito.
Comprar Producto
_____________Puntos de Extensión
Efectivo Credito Debito
Pagar con Tarjeta
Cliente
Ejemplo Include/ Extends ( Puntos de Extensión)
Sistema de Compra
NOTAS COMENTARIOS EN UML
Pagar en Efectivo
<<Extend>> Debito/ Crédito
Colocar Notas de Comentarios es útil para decir cosas aclaratorias en un caso se uso.
Una Extensión puede estar asociada a varios puntos de extensión.
Este es un
Comentario/Nota
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- erróneo
Encargado de inscripción, Sistema Admistrativo
El nombre de un caso de uso debe indicar acción y debe ser claro y conciso
Forma General: Verbo (Infinitivo)+ predicado
Las cosas que indican Acción 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 abstracción. Eje: Caso uso Foro web.
Evitar el cruce de líneas (En general Mantenga el diagrama ordenado).
El diagrama esta pensado para poderse leer, que uno lo vea y entienda la intensión del diagrama.
Evite tener demasiados casos de uso en el mismo diagrama
y si los va atener que estén muy bien ordenado.
Evite el uso complejo de relaciones de Extensión, Especialización, e Inclusión (Nomas de tres niveles).
En general, use el Sentido Común.
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 , vótelo.
Algunas reglas de estilos (para la descripción 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
Preferir la voz activa.
“ La clave es introducida por el usuario”.
“ El usuario introduce la clave”. “El sistema valida la clave”.
Algunas reglas de estilos (para la descripción 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 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 más 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 características
“ El actor introduce su nombre de usuario y contraseña El sistema valida si los datos concuerdan con lo que esta almacenado”.
Registro de usuarios
Leer mensaje
Crear nuevo mensaje
Usuario
Ejemplo Diagrama Casos de Uso Sistema FORO
¿Que errores puede
encontrar en el diagrama?
Ver lista de mensajes
<<Extend>>
Responder mensaje
Supervisar <<Extend>>
Nuevo Mensaje
Aceptar registro
Aceptar mensaje
Actualiza base de datos
Activar usuario
Hacer mensaje visible
<<Extend>>
<<Extend>>
<<Extend>>
<<Extend>>
<<Extend>>
<<Extend>>
Base de Datos
Sistema FORO
Errores en el diagrama
Cruce de líneas Múltiples 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.
CU-01 Ingresar al
Sistema
CU_02 Ver Lista de Mensajes
CU-03 Registrar Usuario
CU-04 Publicar nuevo
mensaje
CU-05 Responder
mensaje
CU-07 Procesar
Publicación del Mensaje
CU-08 Listar solicitudes
pendientes
Usuario
Usuario Autenticado
Moderador
Moderador
Usuario Autenticado
Usuario No Autenticado
El sistema Anterior Mucho mejor Representado
CU-06
Procesar Solicitudes
Registro
<<Extend>>
<<Extend>>
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 código a los casos de uso, a los requisitos y a las historias de usuarios.
Por que? Por que es mucho mas fácil a veces manejar el papeleo con el código que con los nombres de los casos de uso.