Examen_1_IS.

pdf

Pensé que podía ser una buena idea publicar la solución a este problema del
examen, en especial describiendo mi punto de vista al respecto.

Esta no necesariamente es la única solución, ya que en general, a lo largo de mi

carrera me he encontrado con muchos estilos distintos a la hora de modelar casos
de uso. Sin embargo, creo que es una buena solución, que describe de forma
precisa (si es que eso es posible usando casos de uso) la funcionalidad del
sistema. A continuación mi razonamiento y mi solución:

A) Un profesor puede registrar notas:

Figura 1

B) Cuando un profesor registra una nota es almacenada en una base de datos.

En lo que respecta al diagrama de casos de uso la información anterior es

completamente irrelevante. Es decir, en "Registrar Notas" supongo que tendremos
que almacenar la información en la Base de Datos, pero realmente no es de
interés representarlo en el diagrama, como mucho se puede mencionar en la
descripción textual del caso de uso.

C) Adicionalmente un profesor puede actualizar notas. Cuando esto sucede,

primero debe seleccionar la asignatura y el estudiante y luego el profesor
puede actualizar la nota. Finalmente la nota actualizada es almacenada en la base
de datos.

En principio, esto es bastante simple, lo único que interesa aquí por los momentos
es que el profesor puede "actualizar notas". La parte de "seleccionar la asignatura
y el estudiante" se puede incluir dentro del caso de uso "Actualizar Notas" sin
ningún problema. La parte de la Base de Datos, por las razones ya mencionadas
no es relevante para el diagrama.

El resultado hasta los momentos es:

Figura 2

D) Los estudiantes y los profesores pueden visualizar las notas.

Esto se resuelve con un actor adicional, y evidentemente, con un caso de uso

adicional:

Figura 3

E) Las notas se pueden visualizar por asignatura (todos los estudiantes de una
asignatura) y por estudiante (todas las asignaturas de un estudiante). En
cualquier caso, si se están viendo las notas de una sección se debe poder filtrar
por estudiante y si se están viendo las notas de un estudiante se debe
poder filtrar por asignatura.

En el párrafo anterior resulta importante la funcionalidad "visualizar por asignatura"

y "visualizar por estudiante", así como "filtrar por estudiante" y "filtrar por
asignatura". Por lo pronto, la funcionalidad de "filtrar por estudiante" y "filtrar por
asignatura" se considera incorporada dentro del caso de uso "Visualizar Notas",
por lo que el diagrama no se modificará. Sin embargo, es probable que más
adelante se hagan algunas modificaciones al respecto.

Sobre a la diferencia entre "visualizar por asignatura y por estudiante" tenemos

dos opciones, la primera es mantener el caso de uso "Visualizar Notas" y asumir
que contiene tanto la funcionalidad de visualizar notas por asignatura como la de
visualizar notas por estudiante. La segunda opción es separar el caso de uso en
dos casos de uso: uno para la visualización de notas por asignatura y otro por
estudiante. Se tomará la segunda opción ya que es la que pareciera aportar mayor
claridad:
Figura 4

Adicionalmente, se añadió una relación de herencia entre estudiante y profesor.

Esto nos permite decir que todo lo que puede hacer un estudiante también lo
puede hacer un profesor (pero no al contrario). De manera que en este caso si el
estudiante puede "Visualizar Notas por Asignatura" y "Visualizar Notas por
Estudiante" entonces el profesor también puede acceder a estos casos de uso. En
principio ésta es una forma de simplificar un poco las relaciones entre los actores y
los casos de uso estableciendo "jerarquías de usuarios", en algunos casos puede
ser buena idea, en otros no, depende del contexto. Además, esto tiene cierta
relación con el concepto de "seguridad obligatoria" en un sistema (¿seguridad
obligatoria? si mal no recuerdo se menciona con ese nombre en algún lugar del
Navathe de bases de datos), es decir que funcionalidad puede o no puede
acceder un determinado (tipo de) usuario, pero esto probablemente ya es tema de
otra publicación.

F) Para que un usuario pueda ver las notas registradas debe de estar autenticado
en el sistema, es decir, debe haber ingresado su nombre de usuario y su
contraseña.

G) Para que un profesor pueda registrar o actualizar notas debe estar autenticado
en el sistema.

Estos dos puntos son prácticamente el mismo y tienen una solución común.
Generalmente resuelvo esto con un actor adicional y un caso de uso adicional:
Figura 5

La idea es simple: "Usuario no Autenticado" tiene acceso al caso de uso "Ingresar

al Sistema", que es el que se encarga de autenticar al usuario (del modo que sea)
y si el resultado es satisfactorio, es decir si las credenciales del usuario son
válidas, entonces el usuario se transforma en un "Profesor" o en un "Estudiante"
según sea el caso. Es posible que existan muchas otras formas de expresar esta
situación, pero en este caso, ésta me parece bastante apropiada.

H) El sistema tiene que generar un reporte de notas por asignatura. Para esto, el
profesor selecciona la asignatura y el sistema genera un PDF con todas las
notas de la asignatura seleccionada.

I) Al igual que en el caso anterior, el sistema tiene que generar un reporte de notas
por estudiante. Para esto, el profesor selecciona al estudiante y el sistema
genera un PDF con todas las notas del estudiante seleccionado.

Estas son dos funcionalidades muy parecidas, sólo que en un caso se genera un
reporte por asignatura y en el otro un reporte por estudiante. A pesar de las
posibles similitudes, se van a manejar como dos casos de uso independientes. Por
lo pronto, voy a ignorar las partes de "seleccionar la asignatura" y "seleccionar al
estudiante", asumiendo que se pueden describir dentro de los casos de uso
asociados a los reportes respectivos:
Figura 6

Hasta aquí el diagrama transmite una idea bastante buena de la funcionalidad del
sistema. Se puede decir que lo que sigue ya tiene aires de "lujo" y mucha gente
puede pensar que es innecesario (y quizá en algunos casos tengan razón).

A continuación, se van a añadir un par de inclusiones y extensiones para

reutilizar/separar algo de la funcionalidad común, que por fuerza, tal como está el
diagrama va a ser necesario repetir en las descripciones de los respectivos casos
de uso. En este sentido, como se dice en los puntos (C), (H) e (I) parece
que seleccionar la asignatura y el estudiante son funcionalidades que se
repiten, de modo que vamos a ponerlas en casos de uso aparte y a vincularlas
usando una relación de inclusión:
Figura 7

De esta forma, es posible describir la funcionalidad común relacionada a

"seleccionar estudiante" y "seleccionar asignatura" en sus propios casos de uso y
reutilizarla desde donde sea necesaria. Sin embargo, el diagrama comienza a
complicarse y aún faltan algunas cosas. Por ejemplo, no se ha considerado que es
muy probable que para registrar notas también se necesite seleccionar el
estudiante y la asignatura.

Otra funcionalidad interesante que quizá se pueda poner aparte es la relacionada

con "filtrar por estudiante" y "filtrar por asignatura" tal como se expresa en (E).
Esta funcionalidad es opcional, de modo que se puede vincular a los casos de uso
correspondientes por medio de una extensión:
Figura 8

En este punto el enunciado comienza a agotarse, pero sin embargo, hay un par de
cosas adicionales que resultan bastante evidentes:

1. Para "Visualizar Notas por Asignatura" hay que seleccionar la asignatura, y

para "Visualizar Notas por Estudiante" hay que seleccionar el estudiante. Esto
se puede lograr incluyendo "Seleccionar Asignatura" y "Seleccionar Estudiante".

2. Para registrar una nota, es muy posible que sea necesario seleccionar la
asignatura y el estudiante. Esto se puede lograr incluyendo los casos de uso
respectivos ya mencionados.

Con estos últimos cambios el diagrama de casos de uso resultante es bastante

difícil de leer, tal como se muestra a continuación:
Figura 9

En este punto, el diagrama de casos de uso tal como está es una "mala, pero muy
mala idea", el problema de legibilidad se debe a la bonita telaraña de inclusiones
que tenemos, y se puede resolver separando el diagrama en varios diagramas
más pequeños y simples tal como se muestra a continuación:

Diagrama 1 / Usuario No Autenticado

Figura 10

Diagrama 2 / Profesor: Registrar + Actualizar Notas:

Figura 11

Diagrama 3 / Profesor: Reportes

Figura 12

Diagrama 4 / Estudiante y Profesor: Visualizar Notas por Asignatura

Figura 13

Adicionalmente, es importante recordar que el diagrama de casos de uso no es lo

verdaderamente importante a la hora de capturar requisitos. Un diagrama de
casos de uso no es más que un artefacto que podemos usar para representar
superficialmente la funcionalidad de un sistema, para tener una guía visual, un
mapa general de su funcionalidad. Los diagramas de casos de uso sirven a la hora
de tener una conversación informal con los clientes o con los colegas, permitiendo
hacer una revisión general de la funcionalidad del sistema, dándole nombre y
coordenadas (algo a lo que señalar) a la funcionalidad. En este sentido, es
importante estar claros en que este tipo de de diagrama no permite capturar todos
los detalles de la funcionalidad. Para esto existen muchos otros tipos de
artefactos, entre los que se cuentan los casos de uso en si mismos, es decir, las
descripciones textuales de los casos de uso. Todo esto sin considerar aún que
esta visión ha cambiado y sigue cambiando, se ha enriquecido en mi opinión, con
la visión aportada por los métodos / estrategias ágiles basados en historias de
usuario (pero esto último y la relación que pueda tener con el problema actual es
otra historia).

Finalmente, es importante recalcar, tal como mencioné al principio, que la solución

y el diagrama pueden variar dependiendo de muchos factores: su autor, la cultura
de la organización en la que se elabore, el contexto en el que se desea usar, los
objetivos que se quieren satisfacer con el diagrama, etc.

Algunos autores preferirán organizaciones distintas de los casos de uso, otros

preferirán diagramas más abstractos (como el de la figura 2), otros se sentirán
contentos con diagramas más concretos como los que se obtuvieron al final, otros
representarán la base de datos como un actor (cosa con la que no estoy de
acuerdo), otros modelarán más cerca de la interfaz de usuario, otros considerarán
modelar cerca de la interfaz de usuario un pecado mortal, otros englobarán
múltiple funcionalidad en un sólo caso de uso asociado a varios actores, etc.