Guía 4. Parte 2. Modelo de Casos de Uso.

MODELO DE CASOS DE USO

• Muestra la funcionalidad del sistema como es percibida por actores externos.

• Para clientes y equipos de diseño, desarrollo, y prueba.

• Utiliza:
– Diagramas de Casos de Uso.
– Diagramas de Actividad (opcional).

• Su contenido conduce el proceso de desarrollo y verificación.

Sirve para describir las interacciones del sistema con su entorno, identificando:

Los Actores, que representan los diferentes roles desempeñados por los usuarios del sistema (Los
actores no son solamente humanos, pudiendo ser también otros sistemas con los cuales el
sistema en desarrollo interactúa de alguna manera).

y los Casos de Uso, que corresponden a la funcionalidad que el sistema ofrece a sus usuarios,
explicada desde el punto de vista de éstos.

Los Casos de Uso se representan en 2 dimensiones, la primera es gráfica y ahí es cuando se habla
de los diagramas de casos de uso. La segunda dimensión (la más importante) es textual y para
cada caso de uso identificado hay que escribir una plantilla de casos de uso que puede ser en
formato compacto (o de Alto Nivel) y posteriormente en formato extendido.

En otras palabras, Modelo de Casos de Uso = Diagramas + Plantillas

La siguiente figura muestra un Diagrama de Casos de Uso que describe parcialmente un sistema
para la gestión de una biblioteca.

El sistema tiene cuatro actores, representados por muñecos:

el Lector,
el Monitor,
el Director
y el SI_Administrativo.

El primero de ellos (Lector) no interactúa directamente con el sistema en algunos casos de uso,
pero se lo incluye para brindar mayor claridad a la descripción de su funcionalidad.

1
Guía 4. Parte 2. Modelo de Casos de Uso.

2
 Guía 4. Parte 2. Modelo de Casos de Uso.

Los casos de uso se representan mediante óvalos, y describen lo que el sistema

hace para sus usuarios. En el diagrama se muestran los que corresponden a:

Las operaciones más relacionadas con el Monitor:

 Hacer Consulta: Buscar un recurso en la Biblioteca, con opción de reserva.
 Hacer Reserva: Asignar a un Lector un libro para que pueda retirarlo más tarde.
 Borrar Reserva: Eliminar la asignación un libro a un Lector.
 Prestar Ítem: Entregar un recurso a un Lector.
 Registrar Nuevo Lector: Registrar un nuevo Lector en el sistema y fijar sus
atributos.

Una operación que corresponde al Director:

Gestionar Monitores: Dar de alta y de baja a los Monitores y administrar sus
atributos.

Una operación común a varios tipos de usuario:

Control Acceso: Solicitar y verificar identificación (login) y clave (password).

Una operación que corresponde a un actor no humano:

Consultar Multas: Obtener información sobre las multas de los Lectores, con el fin
de tenerlas en cuenta en las actividades de la administración (contabilidad,
certificados de paz y salvo, etc.).

Entre los actores y los casos de uso se establecen asociaciones, que se

representan mediante una línea sólida e indican cuáles actores participan en un
caso de uso. Todo caso de uso tiene siempre un actor (y sólo uno) que lo "dispara",
denominado iniciador, siendo conveniente identificarlo en los casos de uso que
tienen varios actores, ya sea etiquetando su asociación con la palabra "iniciador",
o como en la figura, usando una flecha para representarla.

En el caso de uso Registrar Nuevo Lector, está claro que el actor iniciador es el
Monitor; el Director también participa en el caso de uso, pero sólo cuando recibe el
nuevo carné del Lector, para su firma, luego de que el Monitor ha ingresado toda
la información correspondiente.

Entre los casos de uso también se pueden establecer relaciones, las cuales son de
tres tipos:

 inclusión,
 extensión
 generalización.

3
 Guía 4. Parte 2. Modelo de Casos de Uso.

La relación de Inclusión se representa con una flecha de línea discontinua

etiquetada con el estereotipo «include». Una relación de Inclusión desde el caso
de uso A hacia el caso de uso B, indica que el comportamiento descrito en el caso
de uso B es incluido en el caso de uso A.

Tal es la situación con el caso de uso Borrar Reserva del ejemplo, que se "ejecuta"
cuando un Monitor cancela la reserva porque el Lector ya no requiere un título, y
como parte del caso de uso Prestar Ítem, cuando el Monitor entrega un título
reservado y debe cambiar su estado de "Reservado" a "Prestado".

La relación de Extensión es representada también por una flecha discontinua,

etiquetada con el estereotipo «extend». Una relación de Extensión desde un caso
de uso C hacia un caso de uso D, indica que el caso de uso D puede incluir
(condicionado al cumplimiento de condiciones específicas establecidas en la
extensión) el comportamiento del caso de uso C.

Esta es la situación para el caso de uso Hacer Consulta, que es extendido por el
caso de uso Hacer Reserva cuando el Lector ha encontrado un libro disponible y
desea reservarlo: cuando se cumple la condición “Lector solicita reserva”, Hacer
Reserva es una extensión (posibilidad) desde Hacer Consulta.

La relación de Generalización desde un caso de uso E hacia un caso de uso F

indica que E es una especialización de F. Se representa mediante una flecha con la
línea sólida y la cabeza cerrada y vacía (un triángulo), que es la notación de
generalización.

4
 Guía 4. Parte 2. Modelo de Casos de Uso.

Una vez identificados los actores y los casos de uso en el diagrama, se detallan
estos últimos, utilizando una descripción textual aunque para casos de uso más
complejos puede usarse un Diagrama de Actividad.

La descripción de los casos de uso de un sistema no es homogénea ni en el tiempo

ni en el espacio. Su nivel de detalle se incrementa a medida que se avanza en el
proceso de desarrollo, y en un momento dado es posible tener un mayor nivel de
detalle para ciertos casos de uso, los más críticos, mientras que otros menos
importantes se dejan para más tarde.

Se proponen dos clasificaciones para los casos de uso, según su nivel de detalle y
el nivel de abstracción de su descripción:

a) Casos de Uso de Alto Nivel. Describen las interacciones entre los actores y el
sistema de manera muy breve, usando dos o tres frases. Se utilizan durante las
fases iniciales de captura de requerimientos con el fin de obtener rápidamente una
visión de la funcionalidad y el grado de complejidad del sistema.

El siguiente ejemplo ilustra el formato para la descripción de los casos de uso de

alto nivel:

Caso de uso: Hacer Reserva

Actores: Monitor (iniciador)
Tipo: Primario
Descripción: El Monitor solicita al sistema reservar un ítem solicitado por un Lector.
El Sistema verifica la información del ítem y del Lector.
El Sistema verifica e informa la disponibilidad del ítem solicitado.
El Sistema modifica el estado del ítem, asignándolo al Lector.

En el campo Actores deben incluirse todos los actores que están asociados al caso
de uso, señalando cuál de ellos es el iniciador.

El Tipo corresponde a una categoría asignada a los casos de uso dependiendo de

su importancia, y que es la base para establecer un orden de prioridad en el
momento de planificar su implementación. Los tipos son:
- Primario. Representa una interacción principal y común en el sistema.
- Secundario. Representa una interacción menor o de rara ocurrencia.
- Opcional. Representa una interacción que puede no ser abordada.

5
 Guía 4. Parte 2. Modelo de Casos de Uso.

b) Casos de Uso Extendidos. Describen las interacciones con mayor detalle que
los de alto nivel, enumerando paso a paso los eventos que se presentan durante
una ocurrencia típica del caso de uso. El siguiente ejemplo ilustra el formato para
la descripción de los casos de uso extendidos:

Información General
Caso de uso: Hacer Reserva
Actores: Monitor (iniciador)
Propósito: Asignar a un Lector un libro para que pueda retirarlo más tarde.
Resumen: El Monitor ingresa la información del Lector y del libro solicitado. El
Sistema verifica la información del ítem y del Lector, verifica e
informa la disponibilidad del libro solicitado, y modifica el estado del
ítem, asignándolo al Lector.
Tipo: Primario y abstracto.
Referencias cruzadas: Requisitos: R1.1, R1.6.
Casos de Uso: Control de Acceso, Hacer Consulta.

Precondiciones
El sistema debe contar con la siguiente información:
- Información del Lector: Código, nombre, estado (Activo, Suspendido, etc.).
- Información de los libros: Código, título, estado (Disponible, Reservado, etc.).
El Monitor debe ejecutar el caso de uso Control de Acceso.
Puede iniciarse con el caso de uso Hacer Consulta.

Flujo Principal
1. Este caso de uso empieza cuando el Monitor elige en el menú principal del Sistema la
opción Reserva.
2. El Sistema presenta al Monitor el Formulario de Reserva de la Figura 1, que solicita
el código del Lector y el código del libro a reservar.
3. El Monitor captura total o parcialmente la información de reserva, y selecciona una
de las opciones del final del formulario: Aceptar y Cancelar.
3.1. Si elige la opción Aceptar, Subflujo S1: Verificar Lector y Estado de un
Libro.
3.2. Si elige la opción Cancelar, Subflujo S2: Cancelar la Reserva de un Libro.

Figura 1. Formulario de Reserva.

6
 Guía 4. Parte 2. Modelo de Casos de Uso.

Y aquí aparece un concepto clave: el concepto de ESCENARIO.

Un caso de uso tiene como instancias los escenarios: situaciones concretas que deben
recorrer total o parcialmente el caso de uso.

Se deben considerar en lo posible todos los escenarios de modo que se pueda validar el
caso de uso.

La última comprobación consiste por tanto en asegurar que el caso de uso represente todos
los escenarios.

A veces se confunde el caso de uso con alguno de sus escenarios: Si aparecen muchos
casos de uso puede que sea un síntoma de una mala descripción del sistema.

Subflujos

S1: Verificar Lector y Estado de un Libro.

1) El Sistema verifica el código del Lector (E1).
2) El Sistema verifica el código del libro solicitado (E2).
3) El Sistema consulta el estado del libro solicitado.
4) Si el libro solicitado está disponible, el Sistema modifica su estado a Reservado, lo asigna al
Lector indicado al comienzo, y presenta al Monitor el cuadro de diálogo de la Figura X para
informarle del éxito de la operación. Cuando el Monitor elige “Aceptar” el Sistema regresa al
Menú Principal.
5) Si el libro solicitado está reservado o prestado, el Sistema presenta al Monitor el cuadro de
diálogo de la Figura Y donde le informa la fecha en la que el libro estará disponible. Cuando
el Monitor elige “Aceptar” el Sistema regresa al Menú Principal.
6) Si el libro solicitado está en proceso por parte del personal de la biblioteca (mantenimiento,
clasificación, etc.), el Sistema presenta al Monitor el cuadro de diálogo de la Figura Z donde
le informa que el libro está fuera de servicio. Cuando el Monitor elige “Aceptar” el Sistema
regresa al Menú Principal.

S2: Cancelar la Reserva de un Libro.

1) El Sistema despliega el mensaje de la Figura 1 solicitando confirmar la cancelación.
2) El Monitor presiona el botón Aceptar.
3) El Sistema regresa al Menú Principal.

Flujos de excepción

E1: Mensaje de error: código del Lector no es válido.

1) El Sistema despliega el mensaje de error de la Figura W informando que el código del Lector
no es válido
2) El Monitor presiona el botón Aceptar.
3) El Sistema regresa al Menú Principal.

E2: Mensaje de error: código del libro no es válido.

1) El Sistema despliega el mensaje de error de la Figura Z informando que el código del Libro no
es válido
2) El Monitor presiona el botón Aceptar.
3) El Sistema regresa al Menú Principal.

7
 Guía 4. Parte 2. Modelo de Casos de Uso.

Algunas observaciones sobre la descripción de los casos de uso extendidos:

1) En la información general, cuando se declaran los actores, debe señalarse cuál es el

actor iniciador del caso de uso.

2) En el resumen puede usarse la descripción del caso de uso de alto nivel

correspondiente.

3) Las referencias cruzadas indican con cuáles funciones del sistema y otros casos de uso
existe relación. Las funciones se nombran utilizando la etiqueta que se les asigna en la
Tabla de Funciones del Sistema, elaborada durante la captura de requerimientos.

4) El flujo principal debe comenzar con la frase "Este caso de uso empieza cuando el actor
...", mencionando el iniciador.

5) Los Subflujos corresponden a diferentes caminos que sigue la interacción de manera

normal.

6) Los flujos de excepción describen situaciones que se salen del funcionamiento normal
del sistema.

7) Es conveniente acompañar la descripción con figuras mostrando las interfaces de

usuario (GUI, listados, etc.), ya sea como maquetas, en los casos de uso abstractos, o
con gráficos capturados en la pantalla y formatos finales de impresión, en los casos de
uso reales.

Los casos de uso extendidos pueden a su vez clasificarse de acuerdo a su nivel de

abstracción, en dos categorías:

a) Casos de Uso Abstractos. Describen las interacciones de manera ideal, abstrayendo

los detalles de tecnología e implementación, especialmente aquellos relacionados con
las interfaces de usuario.

b) Casos de Uso Reales. Describen las interacciones en términos de su diseño real,

incluyendo los detalles de las tecnologías empleadas en las entradas y salidas. Cuando
se utilizan interfaces de usuario, se muestran imágenes capturadas de la pantalla y se
discute el manejo de los elementos gráficos.

8
 Guía 4. Parte 2. Modelo de Casos de Uso.

--------------------------------------------------------------------------------------
Y DE AQUÍ EN ADELANTE, ¿CÓMO HACEMOS?

Construcción de Casos de uso. Es un proceso iterativo. Se van descubriendo los

escenarios desde el punto de vista del usuario, es decir los ACTORES.

Para detectar los casos de uso es conveniente hacer las siguientes preguntas:
– ¿Cuáles son las principales tareas de cada actor?
– ¿Escribe/lee/modifica el actor alguna información del sistema?
– ¿Informa el actor al sistema de los cambios externos?
– ¿Desea el actor ser informado de cambios no esperados?

Los casos de uso no pueden ser demasiado pequeños, ya que deben aportar algún valor al
actor. La estructura del sistema debe decidirse teniendo en cuenta a los actores principales.

Proceso de elaboración. Identificar a grandes trazos los casos de uso:

 Las principales etapas de cada caso de uso se describen en un par de frases.
 Se distingue un caso principal y se identifican los casos alternativos y excepciones.

Se debe cuidar que:

 Exista una descripción breve que represente una real imagen del caso uso.
 Las condiciones de arranque y parada del caso de uso estén bien definidas.
 Los usuarios estén satisfechos de la secuencia de interacciones entre el actor y el caso
de uso.

El problema fundamental es encontrar el nivel de abstracción adecuado. En general si un

caso de uso se hace demasiado grande, a medida que se va detallando es conveniente
dividirlo en varios.

Se pueden hacer preguntas como:

 ¿Es posible ejecutar un paso de forma independiente a los otros o siempre va
encadenado con ellos? Dos pasos que siempre se encadenan forman parte
habitualmente del mismo caso de uso.
 ¿Es lógico agrupar varios pasos para documentarlos, probarlos o modificarlos en
conjunto? Si es así, deben formar parte del mismo caso de uso.
------------------------------------------------------------------------------------------

En las próximas páginas veremos algunos ejemplos para generar diagramas de casos de
uso.

9
 Guía 4. Parte 2. Modelo de Casos de Uso.
2. ALGUNOS EJEMPLOS PARA GENERAR DIAGRAMAS DE CASOS DE USO.

EJERCICIO 1. GESTIÓN BÁSICA DE INMUEBLES

Una empresa gestiona un conjunto de inmuebles, que administra en calidad de propietaria. Cada inmueble
puede ser bien un local (local comercial, oficinas, etc.), un apartamento o bien un edificio que a su vez tiene
pisos y locales. Como el número de inmuebles que la empresa gestiona no es un número fijo, la aplicación
debe permitir tanto introducir inmuebles nuevos, así como darlos de baja, modificarlos y consultarlos.

Asimismo, que una empresa administre un edificio determinado no implica que gestione todos sus
apartamentos y locales, por lo que la aplicación también deberá permitir introducir nuevos apartamentos o
locales, darlos de baja, modificarlos y hacer consultas sobre ellos.

Cualquier persona que tenga una nómina, un aval bancario, un contrato de trabajo o venga avalado por otra
persona puede alquilar el edificio completo o alguno de los apartamentos o locales que no estén ya alquilados,
y posteriormente desalquilarlo. Por ello, deberán poder ser dados de alta, si son nuevos inquilinos, con sus
datos correspondientes (nombre, DNI, edad, sexo, ...), poder modificarlos, darlos de baja, consultarlos, etc.

La aplicación ofrece acceso web para que un inquilino puede modificar o consultar sus datos, pero no darse de
baja o de alta. Para la realización de cualquiera de estas operaciones es necesaria la identificación por parte
del inquilino.

<Ext>
Alquilar Edificio

<Ext> <Ext>

Alquilar Alquilar Local

<Ext>
<Ext>
Alquilar Apartamento

<Ext>
Gestor
Inmobiliaria <Ext>
Alta Inquilinos
Mantener Inquilinos
<Ext>
<Ext>
<Ext>
Consulta Inquilinos
Baja Inquilinos

Des-alquilar Modificación Inquilinos

<Ext>
<Ext>

Modificación Vía Web

Consulta Vía Web <Inc>

Inquilino

<Inc>

Validar
Usuario

Figura 1. Diagrama de Casos de uso Ejercicio 1.

10
 Guía 4. Parte 2. Modelo de Casos de Uso.
EJERCICIO 2. GESTIÓN CALIFICACIONES.

Enunciado. Se desea desarrollar una aplicación de gestión de las calificaciones de los alumnos para satisfacer
las numerosas quejas de los profesores, por el uso del lápiz y papel. La aplicación deberá cubrir únicamente
aquellos aspectos relacionados con dicho tema, y que se describen a continuación:

El profesor recibe las actas en blanco de las asignaturas de las que es responsable, en formato electrónico. El
acta contiene los siguientes datos de la asignatura (titulación, campus, curso académico, denominación de la
asignatura, convocatoria y grupo) y la lista de alumnos matriculados (cédula, código, nombre y apellidos).
Alguna de las acciones que puede hacer el profesor son:

 Completar un acta con las notas de los alumnos.

 Añadir o borrar un alumno de un acta.
 Integrar las actas de varios grupos de una misma asignatura en una sola acta.

Otras de las opciones que se le exige a la aplicación, para satisfacer completamente las necesidades del
profesor, son las siguientes:

 Permitir la consulta de la siguiente información de cualquier alumno seleccionado: Cédula, Código, Lista de asignaturas
en las que está matriculado el alumno (Código asignatura-Nombre asignatura).
 Obtener una estadística de las calificaciones obtenidas por los alumnos en un determinado grupo de una asignatura. En
esta estadística se tendrá para cada posible calificación: Número de personas con esa calificación, Porcentaje sobre
los presentados, Porcentaje sobre el total del grupo.
 Consultar el porcentaje de personas sobre el total del grupo que se han presentado y el de los que no se han presentado.
 Poder visualizar un gráfico indicativo del número de personas que han obtenido una calificación entre 0-0.99, 1-1.99,
2-2.99, 3-3.99, 4-4.99, 5-5.99, 6-6.99, 8-8.99, 9-10; indicándose la nota media obtenida por la clase.
 Disponer de una calculadora que permita realizar las operaciones de suma, resta, multiplicación, división. Esta
calculadora se activará cuando se vayan a introducir las notas a algún alumno de forma que una vez realizada la
operación aritmética, pulsando un botón se vuelque el resultado en la casilla donde se están introduciendo las
calificaciones, redondeándose a dos cifras decimales.
 Permitir la importación y exportación de la lista de alumnos con sus calificaciones a un formato compatible con MS Excel.
 Imprimir las actas y la lista provisional de calificaciones.

Finalmente, como una ampliación extra, a la cual sólo podrá acceder quien se identifique inicialmente como
administrador de la aplicación, se deben permitir:

 Gestión ABMC (Altas/Bajas/Modificación y Consulta) de los datos de un alumno y su matrícula en una asignatura
y a un grupo.
 Gestión de Asignaturas, teniendo en cuenta que una asignatura sólo se puede dar en un único curso (primero,
segundo, tercero...) y que cada curso está formado por los datos sobre el número máximo de alumnos, número
mínimo de créditos troncales y número mínimo de créditos optativos. Algunos de los datos que vamos a poder
consultar de una asignatura son el nombre, número de créditos y cuatrimestre en el que se imparte.
 Gestión de Titulaciones, teniendo en cuenta que una titulación sólo se da en un campus determinado y los datos que
podemos consultar son el nombre, el número de créditos o carga lectiva global, si es de 1° o 2° ciclo, ...
 Gestión de grupos, en los que podemos consultar el número máximo de alumnos permitidos, si es un grupo de
mañana, de tarde o de noche, y cuál es el código empleado para identificar el grupo.
 Consultar aquellos alumnos que no se pueden matricular y el motivo de ello.
 Consultar el historial académico de un alumno.

Solución. A continuación se muestra el diagrama de casos de uso en el que se representan al actor profesor
junto con las tareas que requiere del sistema de gestión de calificaciones (ver Figura 2). Así tenemos que:

El profesor será aquel que puede realizar una serie de operaciones relacionadas con el listado de alumnos que
tiene matriculados en sus asignaturas, tales como introducir las notas de alumnos, consultar el historial de
alguno de sus alumnos, introducir o eliminar algún alumno en el listado y tareas de estadística y de importación
y exportación.

Se ha intentado reflejar toda la funcionalidad del sistema asociada al actor profesor para poder mostrar
qué es lo que se espera que haga el sistema de forma completa.

Así pues, se tiene el caso de uso de Poner notas, el cual se extiende en el caso de uso de Operaciones
Calculadora. Con ello se refleja que el profesor al introducir las notas puede en algún momento hacer
uso de las operaciones que aporta una calculadora.

11
 Guía 4. Parte 2. Modelo de Casos de Uso.
Por otra parte, el caso de uso de Gestión de alumno se ha relacionado con el caso de uso de Añadir y Borrar
mediante un extend para identificar explícitamente cuáles son las acciones que se espera que permita el
sistema y que o bien se puede realizar de forma individual o no, cuando el profesor utiliza el sistema.

Otras de las funcionalidades que constituyen un caso de uso cada una son: Integrar grupos, Información
alumno, Estadística, Gráfico, Importar y Exportar.

De la misma forma que anteriormente hemos comentado, se ha realizado el proceso de identificación explícita
de las operaciones que se pueden realizar cuando el profesor quiere Imprimir. Se ha expresado mediante el
“extend” las formas de impresión que puede tener el profesor reflejando que cuando se imprime puede
imprimir sólo las actas (Imprimir actas), sólo las listas (Imprimir Listas provisional) o ambas.

<Ext>
Operar Calculadora
Gestionar Notas
<Inc>

Añadir
<Ext>
<Inc>

Listar Alumnos Acta

<Inc>
Integrar Grupo
<Inc> Validar
Usuario
Consultar Información <Inc>
Alumno
Profesor
<Inc>
Manejar Estadísticas

<Inc>
Generar Gráficos

<Inc>
Importar Archivo

<Inc>

Exportar Archivo
<Ext>

Imprimir <Ext> Imprimir Actas

Imprimir Listas
Provisionales

Figura 2. Casos de uso relacionados con el actor "Profesor".

Finalmente se muestra que todos los casos de uso con los que se relaciona de forma directa el actor se
relacionan con el caso de uso de Validar Usuario para mostrar que es necesaria la identificación del profesor
en el sistema para poder realizar cualquier operación comentada anteriormente. En el siguiente diagrama se
muestran todos los casos de uso relacionados con el actor administrador del sistema (ver Figura 3).

El administrador será el responsable del mantenimiento de los datos que hay en el sistema respecto a las
asignaturas y a los alumnos matriculados.

12
 Guía 4. Parte 2. Modelo de Casos de Uso.
Como podemos observar, se ha intentado expresar toda la funcionalidad del sistema y por ello se han
desglosado al máximo todos los casos de uso hasta que cada uno refleja una funcionalidad del sistema. En la
siguiente figura se muestran cuáles son de forma explícita las funcionalidades que conlleva la gestión de los
alumnos (caso de uso Gestión ABMC Alumnos). Así pues, se ha expresado mediante la relación de “extend” las
distintas posibilidades que ofrece la gestión de alumnos, mostrándose además que ninguna es excluyente y
que se pueden realizar algunas de las operaciones o todas cuando el administrador gestiona a los
alumnos (casos de uso Alta, Baja, Modificación, Consulta Historial Académico).

El resto de funcionalidades que el administrador espera del sistema son las siguientes:

 Matriculas, que identifica a la capacidad del sistema para realizar la matricula de un alumno en las asignaturas,
titulaciones y grupos existentes.

 Gestión de Asignaturas, que identifica la posibilidad que tiene el administrador para introducir, borrar, modificar y
consultar las asignaturas. En este caso no se ha reflejado de forma explícita, ya que en el enunciado no aparece detallado
cuál es el alcance de la gestión de asignaturas.

<Ext>
<Ext> Dar de Alta
Dar de Baja
<Ext>
<Ext> Consultar Historial
Mantener Alumnos
Académico
Modificar
<Inc>
Mantener Matrículas <Inc>

Mantener Asignaturas <Inc>

Administrador
<Inc>
Mantener Titulaciones Validar
<Inc>
Usuario

Mantener Grupos

Figura 3. Casos de uso relacionados con el actor "Administrador".

Gestión de Titulaciones y Gestión de Grupos reflejan la posibilidad para que el administrador introduzca en
el sistema los datos de titulaciones y Grupos. Como ocurría anteriormente, al no detallarse en el enunciado del
problema cuál es el alcance real de estas operaciones sólo se reflejan estos casos de uso sin el detalle mostrado
para la Gestión ABMC Alumnos.

Resaltar el hecho de que el caso de uso de Validar Usuario esté relacionado, mediante la asociación
de include, con todos los casos de uso con los que se relaciona directamente el actor administrador. De
esta forma indicamos que cualquier administrador que tenga que realizar una tarea o función debe
identificarse en el sistema. El caso de uso que aparece en el gráfico siguiente es el mismo que se identificó
anteriormente.

13
 Guía 4. Parte 2. Modelo de Casos de Uso.
EJERCICIO 3. Gestión Tienda de Productos de Informática.

Se desea desarrollar una aplicación que permita gestionar una tienda de productos de informática a
través de Internet. Para realizar un pedido, el sistema pregunta al usuario si es la primera vez que hace un
pedido, en cuyo caso le pide sus datos personales; de lo contrario, el usuario introduce su nombre de usuario
y su clave para acceder a sus datos. A partir del momento en que el usuario está registrado, el sistema le
permite acceder a sus secciones en modo compra, pues ningún cliente no registrado puede realizar
compras, sólo consultas de precios y operaciones sencillas.

La aplicación ofrece al usuario una serie de pantallas a través de las cuales puede navegar, que representan
las diferentes secciones de la tienda: ofertas, hardware, software, juegos para videoconsolas, etc. pudiendo
seleccionar los artículos e incluirlos en su carro de compra.

El usuario puede acceder en cualquier momento a los datos de su carro de compra, para por ejemplo modificar
la cantidad elegida de un determinado artículo, eliminar un producto o simplemente listar por pantalla
el contenido actual del carro y el subtotal acumulado en pesos. Cuando termina de elegir, el usuario
pulsa un botón etiquetado como “enviar” que pone en marcha la generación del pedido y la correspondiente
factura que se adjunta en el paquete que el usuario recibe en su casa. Cada artículo puede estar disponible o
no, y en caso de no estarlo, tendrá un tiempo estimado de entrada en stock.

Hay que tener en cuenta que en el caso de aquellos pedidos que incluyen artículos que no están disponibles,
el envío se retrasa hasta que dichos productos estén disponibles, excepto cuando alguno de los artículos
no disponibles va a tardar más de 15 días, en cuyo caso se envía en el momento un primer envío con los
artículos disponibles y cuando entre en stock el o los artículos retrasados se manda un segundo envío al
usuario.

Los gastos de envío de un pedido van en función del tipo de artículos solicitados (el hardware es generalmente
más caro), del número total de artículos encargados y de la distancia en kilómetros desde el centro más cercano
hasta la casa del cliente (esto se calcula gracias al código postal del cliente). Los gastos de envío en ningún
caso serán función del número de envíos necesarios.

El cliente puede consultar siempre que lo desee el estado de sus pedidos actuales y pasados, con el nivel de
detalle que desee según dos modalidades:

 Sencilla: incluye fecha del pedido, fecha de entrega de c/u de los envíos a que dio lugar (si aún no se ha
servido algún artículo se muestra como pendiente), precio total de los artículos y precio total incluyendo
gastos de envío.

 Completa: incluye fecha de pedido, fecha de entrega de c/u de los envíos, detalle de artículos por envío
(incluyendo cantidad de c/u y precio unitario) (si aún no se ha servido algún artículo se muestra como
pendiente), tarjeta a la que se cargó el pedido, fecha del cargo, precio total de los artículos y precio
total incluyendo gastos de envío.

Se deberá tener en cuenta que en el sistema deberán realizarse las operaciones de

mantenimiento propias de una tienda de este tipo, como por ejemplo aquellas que permitan mantener el stock
de productos al día, que actualicen los precios, etc.

14
 Guía 4. Parte 2. Modelo de Casos de Uso.

Registrarse

Mantener
Usuario Stock
Consultar
Precios

<I>
Actualizar
Precios Gestor
Operar Carro de Compras Validar
<I> Usuario Pedidos
<I>

Generar <I>
Pedido Consulta Establecer
Cliente <E> Completa Disponibilidad
Artículos

Consultar
<E>
Pedido Consulta
Sencilla

Figura 4. Diagrama de Casos de uso para el Ejercicio 3.

15
 Guía 4. Parte 2. Modelo de Casos de Uso.

3. SOBRE LA RELACION <<EXTENDS>> Y LAS OPERACIONES CRUD (Create, Read,

Update, Delete).

3.1. Recordando ideas. Primero recordemos que cuando escribimos un caso de uso (la plantilla
en formato extendido), lo primero que tenemos es una secuencia normal. Al escribir esa secuencia
normal, es posible que nos demos cuenta que algunos de los pasos de dicha secuencia pueden tener
variaciones, y aquí es cuando hablamos de los subflujos. Recordemos que cuando en un paso se
debe tomar un curso de acción en función de una condición por la naturaleza propia del mismo
problema o negocio (o sea, son normales), estos cursos alternativos serán identificados como
subflujos.

Ahora bien, al revisar los pasos del curso normal, se recomienda que nos preguntemos ¿qué puede
fallar en este paso? Y aquí es cuando hablamos de las excepciones. Una excepción se utiliza para
describir funcionalidades indeseadas o excepcionales de un paso a causa de una condición no
cumplida.

Tanto los subflujos (variaciones normales del curso normal) como las excepciones se les denominan
Alternativas (o Cursos Alternativos). O escrito de otra forma, las alternativas se dividen en:

Subflujos (variaciones normales).

Excepciones (variaciones indeseadas).

Y lo recomendado es que se dibujen todas las alternativas como extensiones del caso de uso
que estemos analizando.

3.2. La relación de <<extends>>. Se utiliza una relación de tipo <<extends>> entre casos de
uso cuando nos encontramos con un caso de uso similar a otro pero que hace algo más que éste
(variante). En una relación <<extends>>, un actor que lleve a cabo el caso de uso base puede
realizar o no sus extensiones. Es decir, el caso de uso base no conoce los casos de uso de extensión,
está completo (y debe estar completo) sin las extensiones.

Para el caso de las operaciones CRUD (Create, Read, Update, Delete) conceptualmente está bien
representar esto:

<<extends>>
Crear Usuario
Mantener Usuario
<<extends>>

Actualizar Usuario

Figura 5. Diagrama de Casos de Uso con operaciones CRUD.

A lo que me refiero que está bien es la relación <<extends>> ya que “Crear Usuario” es una
variación de “Mantener Usuario”, al igual que “Actualizar Usuario”.

16
 Guía 4. Parte 2. Modelo de Casos de Uso.

Si lo escribimos, tenemos lo siguiente:

Caso de Uso: Mantener Usuario

Secuencia Normal:
1. El caso de uso inicia cuando el Administrador accesa al sistema. El Administrador ingresa su
nombre de usuario y su contraseña y el sistema valida al Administrador.
2. El sistema despliega las funciones disponibles al Administrador. Estas funciones son: Crear
Usuario, Actualizar Usuario, Cancelar.
3. El Administrador selecciona una de las opciones disponibles:
3.1. Si elige Crear Usuario, se ejecuta el subflujo Crear Usuario.
3.2. Si elige Actualizar Usuario, se ejecuta el subflujo Actualizar Usuario.
3.3. Si elige Cancelar, ir al paso 6.
4. El Administrador indica que el proceso está completo. El Sistema valida la información y se la
muestra al Administrador.
5. El Sistema guarda la información del usuario.
6. Fin del Caso de Uso.

Figura 6. Plantilla con la Secuencia Normal del Caso de Uso “Mantener Usuario”.

Como puede verse, el caso de uso está completo, y aunque simple, hay un camino que no necesita
tomar subflujo alguno: 1 – 2 – 3.3 – 6.

3.3. Las operaciones CRUD. Se recomienda que el nombre del caso de uso que agrupa las
operaciones CRUD sea “Mantener X”. De hecho, se trabaja así en muchas partes.

Para no alargar el cuento, los panoramas son los siguientes:

El primer panorama es el caso de usuarios “Administrador”, no veo más remedio con estos casos
de uso CRUD, ya que esa es la labor de este usuario, la de “hacerle mantenimiento” (Mantener) la
información importante de todo el sistema y que es la que afecta a todos los demás usuarios
adscritos a dicho sistema.

El segundo panorama es la del usuario normalito y otros usuarios (el caso de cualquiera de
nosotros en un sistema como Hotmail o Facebook), en el que efectivamente es muy importante
dibujar como caso de uso autónomo el “Registrar Usuario”, y que cuando uno ya está registrado
ese sistema le permite agregar, modificar o eliminar información PERO QUE HACE PARTE DE OTRO
PROCESO MÁS IMPORTANTE y que si el usuario agrega, modifica o elimina algo, solo afectará a ese
usuario y a nadie más.

A continuación, muestro un pequeño ejemplo de un Sistema de Registro de Cursos.

En primer lugar, deben dibujarse los Casos de Uso (vista del usuario) a un nivel de funcionalidad
alto, tal como lo describiría un usuario y no un ingeniero.

Registrarse en Curso
Estudiante

Figura 7. Diagrama de Caso de uso “Registrarse en Curso”.

17
 Guía 4. Parte 2. Modelo de Casos de Uso.

La plantilla puede ser así:

Caso de Uso: Registrarse en Curso

Secuencia normal:
1. El caso de uso inicia cuando el Estudiante accesa al Sistema de Registro de Cursos. El Estudiante ingresa
su nombre de usuario y su contraseña y el sistema valida al Estudiante.

2. El sistema despliega las funciones disponibles al Estudiante. Estas funciones son: Crear Horario,
Modificar Horario, Eliminar Horario. El Estudiante elige Crear Horario.

Ojo: aquí está la clave para este tipo de usuarios. Las operaciones CRUD, en este caso, tal como lo expresé
antes, hacen parte de un proceso más grande. En este caso concreto la operación CRUD es “Crear Horario” que
hace parte de un proceso más grande “Registrarse en Curso”.

Como también puede verse, de entrada se deja escrito que el actor ya ha elegido una opción: “Crear Horario”, y
es natural que de entrada sea la opción ofrecida, ya que se necesita Crear Horario para que sea posible
modificarlo o eliminarlo.

Ahora, para efectos de este ejemplo, el sistema permite al Estudiante que si solo crea el horario y cierra la
sesión, cuando regrese podrá elegir “Modificar Horario”, y no tendrá necesidad de crearlo de nuevo. Y como
veremos, más adelante si ya tiene un Horario creado, podrá borrarlo.

Las demás opciones “Actualizar Horario” y “Eliminar Horario” se reseñarán en la sección de subflujos de la
presente plantilla, y no hay necesidad de “llamar” esos subflujos como se hizo en los pasos 3.1. y 3.2 tal como
aparecen en la Figura 10).

3. El Sistema recupera del Catálogo de Cursos un listado con los cursos disponibles y muestra ese listado
al Estudiante.

El Estudiante selecciona 4 cursos obligatorios y 2 cursos opcionales de la lista de cursos ofrecidos.

El estudiante puede agregar o eliminar los cursos (*) que desee hasta que elija “Enviar
Horario”.
(*)(estas son operaciones simples, como lo es agregar o quitar un elemento de una lista. Esto es una operación
y no un caso de uso)

4. El Estudiante indica que el Horario está completo.

5. El Sistema valida los cursos seleccionados y muestra el horario al estudiante.

6. El Sistema calcula un número de confirmación usando un algoritmo de hashing usando el código del
estudiante.

7. El Sistema muestra el número de confirmación del horario.

8. El Sistema guarda la información del estudiante en la Base de Datos de Estudiantes.

9. Fin del caso de uso.

Figura 8. Plantilla con la Secuencia Normal del Caso de Uso “Registrarse en Curso”.

18
 Guía 4. Parte 2. Modelo de Casos de Uso.

Subflujos:

Modificar Horario.
1. A partir del paso 2 de la Secuencia Normal, el Estudiante ya tiene grabado un horario en el
Sistema.
2. El Sistema recupera y muestra al Estudiante su Horario y le permite usarlo como punto de
partida de este proceso.
3. El Caso de Uso de reinicia en el paso 3 de la Secuencia Normal.

Eliminar Horario.
1. A partir del paso 2 de la Secuencia Normal, el Estudiante ya tiene grabado un horario en el
Sistema y elige borrarlo.
2. El Sistema recupera y muestra al Estudiante su Horario.
3. El Sistema solicita al Estudiante que confirme el borrado del Horario.
4. El Estudiante confirma el Borrado del Horario.
5. El Sistema borra el Horario.
6. Fin del caso de uso.
Figura 9. Plantilla con los Subflujos del Caso de Uso “Registrarse en Curso”.

De modo que el Diagrama de Casos de Uso puede ampliarse así (recordemos que cada subflujo
representa una extensión):

<<extends>>
Modificar Horario

<<extends>>
Registrarse en Curso
Estudiante

Eliminar Horario

Figura 10. Diagrama de Caso de uso “Registrarse en Curso” con extensiones.

-------------------------------------------------------------FIN DEL DOCUMENTO

19