MODELO DE CASOS DE USOS : Visión del sistema tal como se muestra a sus usuarios y
particiona la funcionalidad requerida del sistema en:
Transacciones o toma instantánea de algún aspecto del sistema (casos de uso)
Que producen un “valor” para los usuarios (actores)
Muestra los servicios que los actores (usuarios y otros sistemas) pueden pedir al
sistema
Cada Caso de Uso puede estar definido por:
• texto que lo describe
• secuencia de pasos (flujo de eventos) ejecutados dentro del caso de uso
• precondiciones y postcondiciones para que el caso de uso comience o
termine
• mezclando las anteriores
ELEMENTOS DE UN DIAGRAMA DE CASOS DE USO
Caso de uso: Secuencia de acciones, incluyendo variantes, que puede realizar el
sistema interaccionando con los actores del sistema.
Actor: Un conjunto coherente de roles que juegan los usuarios cuando
interaccionan con los casos de uso. Cualquier cosa con comportamiento
(hardware, software, personas)
Límite del sistema (frontera): Representa el límite entre el sistema físico y los
actores que interaccionan con el sistema
RELACIONES: se disponen de tres tipos de relaciones entre casos de uso. Los tipos de
relación son: Inclusión (con el estereotipo <<include>>), Extensión (con el
estereotipo <<extend>>) y Generalización (sin estereotipo).
1.- Relaciones de Dependencia :
• <<extend>> el primero es una función opcional del segundo (variación o punto de
extensión). Se utiliza cuando se tiene un caso de uso que es similar a otro pero
que hace un poco más.
• <<include>> el primero hace una llamada obligatoria al segundo. Ocurre cuando se
tiene una porción de comportamiento que es similar en más de un caso de uso y
no se quiere copiar la descripción de tal conducta.
Nota: Utilice “extend” cuando se describa una variación de conducta normal e “include”
cuando se desee evitar repeticiones
2.- Relación de Asociación: es la participación de un actor en un caso de uso
3.- Generalización: es una relación taxonómica entre un caso de uso más general y
otro más específico (también se aplica a actores)
Pautas a seguir para un buen modelo
Asegurarse que cada caso de uso describe una parte significativa del
funcionamiento del sistema
Evitar un número excesivo de casos de uso
Un caso de uso no es un paso, operación o actividad individual en un proceso
Un caso de uso describe un proceso completo que incluye varios pasos (flujo de
trabajo de la empresa)
Los casos de uso deben ser simples, dado que podrían cambiar con facilidad
Los casos de uso tienen que ser entendibles tanto por desarrolladores software
como por expertos del dominio
Es una descripción de alto nivel del sistema
Evitar conceptos de diseño
Plantilla para narrativa del C.U:
Caso de uso Nombre del caso de uso Numero de caso de uso: CU-01
Objetivo del C.U Definición del C.U. Ejemplo: El usuario desea iniciar una partida
Autor o Actor Nombre del rol que interactúa con el sistema. Ejemplo: Jugador
Principal
Pre-condición Cuándo y cómo se activa el CU. Datos de Entrada. Ejemplo: Ninguna
Post-condición Salida del sistema Partida Iniciada
Curso Normal: Paso Acción (Sistema)
1 El Usuario desea iniciar una nueva Partida
2 El usuario presiona el botón ingresar.
3 El sistema carga el nivel inicial
4 El sistema muestra la pantalla de juego y espera a que el usuario
realice un movimiento (Caso de Uso 02)
Curso Alterno
NO
EJEMPLOS REQUERIMIENTOS Y CASOS DE USO
CASO: GESTIÓN ACADÉMICA UNIVERSITARIA
REQUERIMIENTOS FUNCIONALES
1. El sistema debe permitir la carga de los planes de evaluación del docente
2. El sistema debe permitir que los docentes carguen las calificaciones de los estudiantes
3. El sistema debe permitir que se actualicen las fichas personales de los estudiantes
4. El sistema debe permitir que se actualicen los datos de los docentes
5. El sistema debe permitir que el encargado de control de estudio gestione las asignaturas
6. El sistema debe permitir que el encargado de control de estudio maneje los trimestres
7. El sistema debe permitir que el encargado de control de estudio gestione los periodos académicos
8. El sistema debe permitir que el docente genere estadísticas de sus cursos
9. El sistema debe permitir que se generen reportes
10. El sistema debe permitir que se emplee una calculadora al momento de cargar las calificaciones
11. El sistema debe permitir que el docente importe y exporte las actas de notas a Excel
12. El sistema debe permitir que el coordinador genere gráficos
13. El sistema debe permitir que el coordinador genere estadísticas docentes y de las unidades curriculares
14. El sistema debe permitir que los estudiantes consulten e impriman su situación académica
15. El sistema debe permitir a los docentes consultar e imprimir los listados de clase, los planes de evaluación y
las actas de notas.
Actores – Caso de Uso
Cargar plan de evaluación Añadir, Editar, Borrar, Consultar
Cargar las Calificaciones Añadir, Editar, Borrar, Consultar
Generar estadísticas Consultar, Imprimir
Docentes Exportar actas de notas Consultar, Imprimir
Importar actas de notas Consultar, Imprimir
Manejar calculadora Sumar, Restar, Multiplicar, Dividir
Generar Reportes Consultar, Imprimir
Consultar situación académica
Estudiantes
Imprimir situación académica
Manejar docentes Añadir, Editar, Borrar, Consultar
Manejar estudiantes Añadir, Editar, Borrar, Consultar
Encargado de
Gestionar asignatura Añadir, Editar, Borrar, Consultar
Control de Estudio
Gestionar Cursos Añadir, Editar, Borrar, Consultar
Manejar períodos académicos Añadir, Editar, Borrar, Consultar
Generar gráficos
Coordinador
Generar Estadísticas
Casos de Uso
