Esta no necesariamente es la nica solucin, 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 solucin, que describe de forma precisa (si es que eso es posible usando casos de uso) la funcionalidad del sistema. A continuacin mi razonamiento y mi solucin: 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 informacin anterior es completamente irrelevante. Es decir, en "Registrar Notas" supongo que tendremos que almacenar la informacin en la Base de Datos, pero realmente no es de inters representarlo en el diagrama, como mucho se puede mencionar en la descripcin 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 ningn 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 estn viendo las notas de una seccin se debe poder filtrar por estudiante y si se estn viendo las notas de un estudiante se debe poderfiltrar por asignatura. En el prrafo 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 ms 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 opcin es separar el caso de uso en dos casos de uso: uno para la visualizacin de notas por asignatura y otro por estudiante. Se tomar la segunda opcin ya que es la que pareciera aportar mayor claridad:

Figura 4 Adicionalmente, se aadi una relacin de herencia entre estudiante y profesor. Esto nos permite decir que todo lo que puede hacer un estudiante tambin 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 tambin 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 "jerarquas de usuarios", en algunos casos puede ser buena idea, en otros no, depende del contexto. Adems, esto tiene cierta relacin con el concepto de "seguridad obligatoria" en un sistema (seguridad obligatoria? si mal no recuerdo se menciona con ese nombre en algn 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 publicacin. 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 contrasea. G) Para que un profesor pueda registrar o actualizar notas debe estar autenticado en el sistema. Estos dos puntos son prcticamente el mismo y tienen una solucin comn. 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 vlidas, entonces el usuario se transforma en un "Profesor" o en un "Estudiante" segn sea el caso. Es posible que existan muchas otras formas de expresar esta situacin, 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, slo 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 razn). A continuacin, se van a aadir un par de inclusiones y extensiones para reutilizar/separar algo de la funcionalidad comn, 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 queseleccionar 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 relacin de inclusin:

Figura 7 De esta forma, es posible describir la funcionalidad comn 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 an faltan algunas cosas. Por ejemplo, no se ha considerado que es muy probable que para registrar notas tambin 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 extensin:

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 difcil de leer, tal como se muestra a continuacin:

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

telaraa de inclusiones que tenemos, y se puede resolver separando el diagrama en varios diagramas ms pequeos y simples tal como se muestra a continuacin:

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 ms que un artefacto que podemos usar para representar superficialmente la funcionalidad de un sistema, para tener una gua visual, un mapa

general de su funcionalidad. Los diagramas de casos de uso sirven a la hora de tener una conversacin informal con los clientes o con los colegas, permitiendo hacer una revisin general de la funcionalidad del sistema, dndole nombre y coordenadas (algo a lo que sealar) 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 an que esta visin ha cambiado y sigue cambiando, se ha enriquecido en mi opinin, con la visin aportada por los mtodos / estrategias giles basados en historias de usuario (pero esto ltimo y la relacin que pueda tener con el problema actual es otra historia). Finalmente, es importante recalcar, tal como mencion al principio, que la solucin y el diagrama pueden variar dependiendo de muchos factores: su autor, la cultura de la organizacin 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 preferirn organizaciones distintas de los casos de uso, otros preferirn diagramas ms abstractos (como el de la figura 2), otros se sentirn contentos con diagramas ms concretos como los que se obtuvieron al final, otros representarn la base de datos como un actor (cosa con la que no estoy de acuerdo), otros modelarn ms cerca de la interfaz de usuario, otros considerarn modelar cerca de la interfaz de usuario un pecado mortal, otros englobarn mltiple funcionalidad en un slo caso de uso asociado a varios actores, etc.