Documentos de Académico
Documentos de Profesional
Documentos de Cultura
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)
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
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
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.
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:
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
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
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)
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.
Precondiciones:
El usuario debe estar autenticado en el sistema
Contina.
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.
Descripcin: Permite crear un nuevo mensaje en el foro de discusin Actores: Usuario/Moderador Precondiciones: El usuario debe estar autenticado en el sistema
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?
Usuario Usuario
Leer un Mensaje
Ver lista de mensajes pendientes por agregar
Responder un mensaje
Usuario Autenticado
Moderador
Usuario Usuario
Leer un Mensaje
Ver lista de mensajes pendientes por agregar
Responder un mensaje
Usuario Autenticado
Moderador
Actor
Caso de Uso Especializado Usado para heredar el comportamiento y significado del Caso de Uso principal
<<Especializacin>>
Consultar Entidad
Listar/Buscar Entidad
Modificar Entidad
<<CRUD>> ENTIDAD
Actor
Eliminar Entidad
Actor
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.
Usuario
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.
Sistema de Compra
Pagar en Efectivo
Comprar Producto
Usuario
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.
Cliente
Sistema de Compra
Pagar en Efectivo
Colocar Notas de Comentarios es til para decir cosas aclaratorias en un caso se uso.
Cliente
El nombre de un caso de uso debe indicar accin y debe ser claro y conciso
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.
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.
Narrar el flujo de eventos usando voz activa, en tiempo presente y desde la perspectiva del actor
La clave es introducida por el usuario. El usuario introduce la clave. El sistema valida la clave.
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
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>>
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.
Usuario
CU-06 Procesar Solicitudes Registro
<<Extend>>
CU-08 Listar solicitudes pendientes
<<Extend>>
Moderador
Usuario Autenticado
Usuario Autenticado
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.