Casos de Uso / Registro de Notas

El primer examen de Ingeniería del Software del semestre A2011 incluyó un problema en el que era necesario obtener un diagrama de casos de uso a partir de un enunciado dado.

El enunciado del examen se puede encontrar en el siguiente documento:

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.

Citas...

Los seres humanos nos creemos la gran cosa, pero en el fondo no somos
más que una minúscula parte del caos resultante de una gran explosión.
Como el humo de cualquier explosión, nuestro destino es seguir el
camino de la entropía y terminar extinguiendonos en algún frio y
retirado rincón del universo --- ¿o no?

dmi

Cursos