Diferencia entre revisiones de «Diagrama de casos de uso»
(→Nombre) |
(→Pre-condiciones) |
||
| Línea 45: | Línea 45: | ||
Ejemplos: | Ejemplos: | ||
“1. El usuario pudo ingresar al sistema y es válido” | “1. El usuario pudo ingresar al sistema y es válido” | ||
| + | |||
“2. El número de abonado ya ha sido asignado por el sistema” | “2. El número de abonado ya ha sido asignado por el sistema” | ||
Revisión del 21:13 25 nov 2010
Los diagramas de casos de uso se utilizan para la especificación de usuario. Las especificaciones se valen actores y casos de uso.
Actores
Sirven para identificar los usuarios del sistema. Deberán ser creados dentro de su correspondiente directorio y desde allí utilizados en los diagramas de casos de uso y de secuencia del sistema.
Casos de Uso
Sirven para documentar la etapa de análisis.
Nombre
Todo caso de uso debe estar identificado en forma unívoca con un nombre que aplique una nomenclatura. Se recomienda usar:
- Verbos en infinitivo
- Nombres descriptivos relacionados con la funcionalidad del negocio y no con particularidades técnicas o de implementación
- Los mismos verbos para referirse a una misma actividad
Ejemplos:
- Ingresar Datos Solicitud
- Validar Plan Tarifario.
Autor
Identifica a la persona creadora del caso de uso. No debería modificarse aún cuando se modifique el caso de uso.
Descripción
Describe brevemente la funcionalidad que representa el caso de uso.
Estereotipo
Clasifica al caso de uso. Algunos estereotipos propuestos son:
- Función Interna: para identificar a los casos de uso que describen la funcionalidad del sistema.
- Función Externa: para identificar a los casos de uso que describen funcionalidad externa al sistema que se debe desarrollar por necesidad del proyecto.
- Servicio: para identificar funcionalidad embebida en procedimientos de base de datos y procesos propios ó externos del sistema ya desarrollados, que no serán relevados ni modificados.
- Servicio por Evento: para identificar funcionalidad embebida en triggers de base de datos ya desarrollados, que no serán relevados ni modificados, pero tienen importancia para el modelado del negocio y son utilizados implícitamente por componentes del sistema.
Pre-condiciones
Indican todo aquello que el sistema asume como requisito previo al inicio del caso de uso. Debido a ello se dan por cumplidas y no se vuelven a considerar durante el desarrollo del caso de uso. Generalmente indican que un caso de uso anterior se ejecutó para hacer que esa condición se cumpla.
Ejemplos: “1. El usuario pudo ingresar al sistema y es válido”
“2. El número de abonado ya ha sido asignado por el sistema”
Invariantes
Detallan las condiciones que deben cumplirse durante toda la ejecución del caso de uso. Incluir bloqueos que serán necesarios. Por ejemplo, en un caso de uso de Modificación de Datos de Clientes, se incluye una invariante para indicar que mientras se estén modificando los datos, no puedan realizarse otras operaciones con el Cliente.
Post-condiciones
Describen el estado del sistema al concluir exitosamente el caso de uso. Responden a los objetivos planteados en el caso de uso.
Ejemplo: “1. Abonado dado de alta en el sistema con el equipo, accesorios y SVAs adquiridos”
Buenas prácticas para escribir el caso de uso
- Utilizar los mismos verbos para referirse a una misma actividad. Ejemplos de verbos aplicables: ingresar, validar, determinar, registrar.
- No describir acciones relacionadas con la presentación gráfica o de formato.
En lugar de: “1. El actor tilda de la lista valores…” Utilizar: “1. El actor ingresa…”.
El objetivo es transmitir “qué” información ingresa el actor sin decir “cómo” la ingresa.
- No indicar de diferente forma los mismos conceptos:
En lugar de utilizar indistintamente “Abonado”, “Línea” y “Cuenta” Utilizar, por ejemplo, “Abonado” como término univoco para referirse a lo mismo.
- Mientras no sea necesario identificar el rol del actor, referirse al actor genéricamente.
En lugar de “1. El empleado de venta de Movistar ingresa…”. Utilizar: “1. El actor ingresa…”
- En caso de ser necesario identificar el rol del actor, describirlo dentro de los pasos del escenario del caso de uso como una tarea.
Ejemplo:
“1. El sistema determina que es un empleado de venta de Movistar y permite el ingreso…”.
- Los requerimientos u otros casos de uso que deban mencionarse en el escenario tendrán que estar contenidos entre [ ] (corchetes).
Ejemplos:
“1. El actor ingresa los [Datos de Categoría Impositiva]”
“2. El actor ingresa los datos del cliente a través del caso de uso [SGA-CU-VE-021 Especificar Cliente]”
- Las entidades del modelo conceptual que deban mencionarse en el escenario tendrán que estar contenidas entre # #. (numeral)
Ejemplo:
“3. El sistema determina que se generó un #Presupuesto de Venta#”.
- Siempre que se haga referencia a un valor constante deberá escribirse en mayúsculas y entre “” (comillas dobles).
Ejemplo:
“3. El sistema determina que el [Tipo de operación] es "VENTA"”.
- No indicar conceptos que no estén representados como un requerimiento, entidad conceptual, otro caso de uso o un actor.
- En cada paso describir la acción de un único actor.
En lugar de: “1. El actor ingresa el [Número de abonado] y el sistema lo valida según [Validar abonado]”
Utilizar:
“1. El actor ingresa el [Número de abonado]” “2. El sistema valida el [Número de abonado] según [Validar abonado]”
- Aseverar la tarea en lugar de escribir en forma condicional de forma de poder evitar escribir pasos alternativos de alternativas.
En lugar de: “1. El sistema valida si el abonado es válido”. Utilizar: “1. El sistema determina que el abonado es válido”
- Evitar casos de uso cuyo escenario normal supere los 10 ó 12 pasos. Cuando se presentan situaciones que requieran más detalle, separar la funcionalidad en más de un caso de uso.
- Si una validación es compleja o involucra muchas tareas y a su vez presenta diferentes alternativas, se deberá escribir un caso de uso aparte que comprenda la validación con sus diferentes alternativas, en lugar de incluir la validación como un requerimiento del caso de uso original.
- Si una funcionalidad puede llegar a ser utilizada por más de un caso de uso, se deberá escribir en un caso de uso aparte para poder ser usada por otro caso de uso.
Escenario Normal
Tomar como escenario normal al que describa la operatoria más frecuente según el usuario o en su defecto la estadística de uso. Enumerar los pasos de 1 en 1.
Escenarios Alternativos
La alternativa de un paso normal se enumera con el número de paso más el número de alternativa.
Ejemplos: “1. El sistema determina que el [Número de abonado] es válido…” “1.1. El sistema determina que el [Número de abonado] no es válido...”
Ante la necesidad que una alternativa genere nuevas alternativas se deberá incorporar un tercer dígito para identificarla en forma unívoca.
Ejemplos: “1. El sistema determina que el [Tipo de servicio] es “TOP” “ “1.1. El sistema determina que el [Tipo de servicio] es “ACTIVA”. “1.1.1.El sistema determina que el [Tipo de línea prepaga] es “PO”” “1.1.2. El sistema determina que el [Tipo de línea prepaga] es “PR”” “1.2. El sistema determina que el [Tipo de servicio] es “AHORRO”.
Requerimientos
Los requerimientos describen el detalle de los datos o reglas del negocio que se manejan en los escenarios del caso de uso. Corresponden a lo que en el escenario queda contenido en [ ] (corchetes). Esta abstracción permite que el caso de uso solo enumere las tareas a realizar, dejando en los requerimientos los objetos sobre los cuáles se realizan esas tareas.
Los tipos posibles de requerimiento son:
- Visualización: describe conceptualmente la información que se debe mostrar al usuario. No indica formato ni medio tecnológico.
- Funcional: describe conceptualmente la información que circula dentro del caso de uso. Incluye datos que el actor debe ingresar y datos no visibles calculados por el sistema.
- Validación: describe la regla de validación que aplica sobre un requerimiento funcional y que no se refiere a reglas de negocio.
- Negocio: describe una definición impuesta por el negocio más allá de una funcionalidad específica.
- Constante: especifica valores fijos necesarios para la descripción del caso de uso. Por ejemplo, código de identificación de la compañía.
- No Funcional: aplicable para casos de uso de tipo servicio para describir características técnicas de los servicios utilizados.
Un requerimiento puede ser Interno o Externo respecto de un caso de uso. Al crearlo como Externo puede ser utilizado desde más de un caso de uso.
No se deberán incluir decisiones y/o alternativa de negocio en un requerimiento, más allá de su tipo, y su tamaño deberá ser reducido.
Un requerimiento de tipo funcional se referirá, normalmente, a datos a ingresar por el actor. La validación de estos datos se realizará a través de un requerimiento de tipo validación, por lo tanto, para cada requerimiento de tipo funcional, se tendrá como mínimo un requerimiento de tipo validación asociado.
En el requerimiento de tipo validación deberán especificar cada una de las condiciones que hacen válidos a los datos. Por cada condición se indicará también el mensaje de error que deberá mostrarse en caso de que la condición no se cumpla. Ese mensaje de error será un requerimiento de tipo visualización. Al incluir el mensaje de error dentro del requerimiento de validación, no se deberá indicar en el paso alternativo de error. Se asume como entendido que en caso que la validación falle siempre se mostrará el mensaje asociado a la condición que falló. El paso de error solamente describirá la acción a realizar como consecuencia del error.
Ejemplos: “1. El sistema determina que los [Datos del plan] son válidos según [Validar Plan]” “1.1 El sistema determina que los [Datos del plan] no son válidos y retorna al paso 1 del caso de uso”
Únicamente cuando se deba aplicar una solución distinta por error en la validación, se deberá indicar en el paso alternativo de error que tarea corresponde realizar.
Ejemplos: “1. El sistema determina que los [Datos del plan] son válidos según [Validar Plan]” “1.1 El sistema determina que los [Datos del plan] no son válidos, no muestra el mensaje de error, asume el [Plan por defecto] y continúa en el paso 3 del caso de uso”
Diagrama de casos de uso
En el diagrama se representan los casos de uso y los actores que interactúen con el sistema. La relación entre caso de uso y actor será de una relación de asociación. La relación entre dos casos de uso podrá ser una relación de inclusión o de extensión.
Relación de inclusión
Será una relación de inclusión cuando un caso de uso necesite de la realización de otro caso de uso para lograr su objetivo. El primero se llama caso de uso base y el segundo se llama caso de uso adicional ó incluido.
Relación de extensión
Será una relación de extensión cuando un caso de uso, en determinada condición puede ser extendido por otro caso de uso. Este último también es llamado caso de uso adicional o que extiende.
La dirección de la relación de asociación siempre será en el mismo sentido, tanto para la inclusión o como para la extensión. En un caso estará etiquetada con <<include>> y en el otro con <<extend>>.
