Ingeniería de Software I – Universidad Carlos III de Madrid

La Academia

Enunciado
Se desea realizar una aplicación para gestionar los datos académicos de los alumnos de una
academia en la que se imparten varios diplomas.
Cada diploma consta de una serie de asignaturas obligatorias y optativas, entre las cuales los
alumnos deberán obtener el número de créditos del diploma. Algunas asignaturas pertenecen a varios
diplomas simultáneamente, en ocasiones con distinto carácter obligatorio u optativo.
La matrícula en una asignatura da derecho a una convocatoria, y los alumnos deben superar
cada asignatura en un máximo de 4 convocatorias. En caso contrario no podrán obtener el diploma, si
se trata de una asignatura obligatoria, o no podrán repetir la matrícula en la asignatura, si se trata de
una optativa.
En el momento de matricularse, los alumnos proporcionan en el terminal sus datos
personales (si ya están registrados de matrículas anteriores, sólo los que hayan sufrido alguna
modificación), y eligen las asignaturas en las que desean matricularse. Seguidamente se les informa
del importe que han de abonar, de acuerdo con el número total de créditos matriculados y el precio
unitario por crédito. La validez de la matrícula queda pendiente de que el alumno entregue el
justificante del pago de la misma en la cuenta corriente de la academia mediante dinero en efectivo,
tarjeta de crédito, talón, o transferencia bancaria. Dicho justificante será comprobado por el personal
administrativo, que dará validez a la matrícula en el sistema mediante la actualización de un campo
de la misma.
Los profesores pueden obtener listas de los alumnos matriculados en las asignaturas que
imparten, e introducir las calificaciones que los alumnos obtengan en las pruebas de evaluación. Los
alumnos pueden consultar estas calificaciones, así como el resto de datos personales registrados, por
si desean comunicar alguna actualización a las oficinas de la academia.
El personal administrativo de la academia se encarga de mantener los datos de diplomas,
asignaturas, y tarifas académicas en cada edición de los cursos. Así mismo, puede suplir en caso de
necesidad a un profesor o alumno que por alguna razón no pueda acceder personalmente a la
aplicación y solicite la ayuda del personal administrativo.
Tanto alumnos como profesores y personal administrativo acceden a la aplicación
identificándose con un nombre de usuario y contraseña previamente asignados.

Se pide
1. Diagrama de clases de la aplicación.
[este enunciado no debe considerarse definitivo]
Representar en un diagrama de clases (clases, atributos, asociaciones, agregaciones, roles y
multiplicidades) la organización de la docencia de los cursos impartidos en la academia (estudios,
asignaturas, alumnos matriculados, profesores y horarios). Considerar dos interpretaciones distintas
del problema: a) cada asignatura pertenece a un y solo un diploma, pero puede haber asignaturas
con la misma denominación en diplomas distintos; b) cada asignatura puede pertenecer a más de un
diploma, y no puede haber dos asignaturas distintas con la misma denominación.

1
 Ingeniería de Software I – Universidad Carlos III de Madrid

Solución
De una primera lectura del texto ya podemos ir anotando aquellos conceptos que podrán ser
las clases del sistema. Dichos conceptos son: asignatura, matrícula, alumno, diploma y profesor.
Posteriores lecturas más detalladas nos van a ir confirmando o rechazando su categoría de clases,
las relaciones entre ellas y si existen otros conceptos que haya que añadir a este diagrama.
El enunciado nos empieza a dar pistas de cómo construir este diagrama en el segundo
párrafo, donde encontramos que “cada diploma consta de una serie de asignaturas”. Se nos muestra
una clara relación de agregación entre ambas clases. Sin embargo el enunciado no es preciso y deja
un margen para que sean válidas diferentes interpretaciones en cuanto al significado de la frase
“algunas asignaturas pertenecen a varios diplomas simultáneamente, en ocasiones con diferente
carácter obligatorio u optativo”. Esta frase puede significar al menos dos cosas diferentes:
1. Hay asignaturas que aun siendo diferentes y perteneciendo a diferentes diplomas tienen el
mismo nombre (por ejemplo una asignatura “Matemáticas” del diploma “Física” y una
asignatura “Matemáticas“ del diploma “Economía”)
En este primer caso la agregación entre las clases Diploma y Asignatura es una composición,
ya que cada diploma está constituido por diferentes asignaturas [este motivo es insuficiente
para para caracterizarla como composición] que pertenecen cada una a un único diploma; la
eliminación de un diploma determinado del sistema implicaría necesariamente la eliminación
de las asignaturas que lo componen. En tal caso, el diagrama de clases sería

[en la medida de lo posible, conviene simplificar los nombres de atributos; en este caso, se
puede sustituir perfectamente “nº de créditos” por “créditos”; también me gusta más
“denominación” que “nombre”, pero esto es menos importante]
[indicar el criterio de especialización o discriminador, “carácter”]
El carácter optativo u obligatorio se representa como una especialización de la clase
Asignatura, que es en este caso abstracta al no existir ninguna instancia de la clase padre
que no pertenezca a alguna de las clases hijas. El carácter también se podría haber
modelado como un atributo de Asignatura, que en este caso no sería abstracta, ni existirían
las subclases Optativa y Obligatoria.
2. Hay asignaturas que pertenecen a diferentes diplomas, siendo obligatorias en unos y
optativas en otros (por ejemplo: “Dibujo Técnico”, que es compartida por los diplomas
“Arquitectura”, en el que es obligatoria, y “Física”, donde es optativa). Es decir, no se trata de

2
 Ingeniería de Software I – Universidad Carlos III de Madrid

dos asignaturas que coinciden en el nombre, sino de una y la misma asignatura que se
imparte en más de un diploma.
En este caso la relación es una agregación a secas, ya que los objetos agregantes pueden
formar parte de más de un agregado. Sin embargo tenemos el problema de representar el
carácter optativo u obligatorio que adquiere la asignatura en función del diploma del que
forme parte. Parece claro que ese carácter es un atributo, pero no de la clase Asignatura, ni
obviamente de la clase Diploma, sino de la relación que existe entre ambas, que debemos
modelar como una clase-asociación [escribe siempre clase-asociación, con guión] con dicho
atributo “carácter”, como representamos en el diagrama siguiente:

[obviamente, la multiplicidad de Diploma para Asignatura está mal en este diagrama, debe ser
1..*]
Aunque el enunciado permite ambas interpretaciones, a nuestro parecer, la más próxima a
aquél es la segunda, por lo que será esta la que utilicemos en el diagrama de clases de la aplicación
completa.
En ese mismo párrafo el enunciado nos dice que los alumnos necesitan una determinado
número de créditos para obtener un diploma. Es decir, necesitamos una asociación entre Diploma y
una nueva clase Alumno, donde guardaremos como atributos los datos personales que un poco más
adelante nos dicen que el alumno facilitará en el momento de matricularse. Como no especifican
cuáles son estos datos pondremos por ejemplo los siguientes atributos: nombre, apellidos, DNI,
dirección y fecha de nacimiento [no está en el diagrama] [yo no me liaría, si el enunciado no requiere
más información que el nombre, yo no me inventaría otros datos, que al fin y al cabo no aportan nada
a la solución]. También se podría incluir un atributo que contuviese el número de créditos conseguidos
hasta ese momento por el alumno, si bien sería un atributo derivado como veremos a continuación.
También tendremos que incluir entre sus atributos el nombre de usuario y contraseña que el alumno
utiliza para acceder a la aplicación [tampoco dice nada el enunciado acerca de esto, yo lo suprimiría].
El diagrama de esta parte sería el siguiente:

3
 Ingeniería de Software I – Universidad Carlos III de Madrid

[errata en créIDtos, y además debe ser derivado, “/créditos”, y además más adelante le
cambias el nombre y lo llamas “créditos conseguidos”; la verdad es que yo lo eliminaría, aunque
tampoco está mal mencionarlo como derivado; ya puestos, ten en cuenta que cualquier información
que puedas obtener de otra clase es derivada, por ejemplo, el número de créditos matriculados
actualmente, el número de créditos matriculados en total (conseguidos y no conseguidos), el
porcentaje de optativas y obligatorias, etc. Además, el número de créditos conseguidos depende del
diploma de que se trate, no es algo propio del alumno en cuanto tal…]
[simplificar: nombre de usuario  usuario]
[multiplicidad Diploma.alumno debe ser 0..*]
Pasamos ahora a ver cómo se relacionan el concepto de alumno con el de asignatura. Para
ello el enunciado nos presenta otro concepto distinto, que es el de matrícula. Como este concepto no
está suficientemente descrito, volvemos a tener dos interpretaciones diferentes de lo que una
matrícula representa:
1. El registro de cada alumno en un conjunto de asignaturas cada curso [el enunciado
no habla, intencionadamente, de “años”, ya que no es una universidad, sino una
academia; en cambio, sí se menciona el concepto de “edición de los cursos”
(penúltimo párrafo); revisa por favor el resto del documento para cambiar año o anual
y todos los derivados por los correspondientes de curso], con lo que tendríamos unas
sola matrícula por curso para cada alumno.
2. El registro de cada alumno en cada asignatura, con lo que tendríamos tantas
matrículas por cada alumno como asignaturas haya escogido cada año.
De ambas interpretaciones, la más lógica es la primera, por funcionalidad y porque es el
concepto más acorde con el lenguaje natural. Además, en el enunciado se nos dan más pistas que la
hacen la opción más adecuada: se nos dice que cuando el alumno se matricula, se le informa del
“importe a pagar de acuerdo con el número total de créditos matriculados”, lo que indica que el
importe, concepto propio de la matrícula, recoge el precio de los créditos correspondientes a todas las
asignaturas elegidas [bueno, no estoy seguro de que esta frase apoye tan claramente tu
interpretación, pero acepto que es natural]. Bajo dicha interpretación, el diagrama de clases sería:

[año  curso, edición, o como le quieras llamar]

[en general conviene omitir los atributos si ya los has definido en otro diagrama, pero si no
sigues este criterio, ¿por qué aquí no aparece Asigantura.nombre?]

4
 Ingeniería de Software I – Universidad Carlos III de Madrid

Como vemos, aparece una clase-asociación que representa la relación entre la clase
Asignatura y la clase Matrícula. Es clase-asociación porque la necesitamos para almacenar un dato
que el enunciado nos exige tener en cuenta, que es el número de convocatoria de cada alumno en
cada asignatura. Cada matrícula contendrá entonces entre 1 y varias asignaturas y cada asignatura
estará contenida en un rango de entre 0 y muchas matrículas [“en entre” es muy cacofónico]. También
incluimos como atributo la calificación en esa convocatoria, que será rellenada al final del curso por el
profesor correspondiente. Sólo existe un enlace entre cada asignatura y cada matrícula, por lo que es
una clase asociación y no una clase asociativa. El atributo “importe” de la clase Matrícula es derivado
del atributo “créditos” de la clase Asignatura, calculado multiplicando éste por el precio de cada
crédito, que consideramos fijo, en cada objeto de Asignatura enlazado con cada uno de Matrícula.
También, aunque el enunciado no lo dice explicitamente, conviene incorporar como atributo el año en
que se formaliza, a modo de identificador (o trimestre, según el periodo de validez de la matrícula; el
enunciado no lo dice).
Por otro lado, cada alumno realizará a lo largo de sus estudios varias matrículas, por lo que
ponemos multiplicidad “1..*” en la asociación “formaliza” en el lado de Matrícula, pero una Matrícula
puede pertenecer como máximo y como mínimo a un alumno (multiplicidad “1..1” en el lado de
Alumno).
La segunda interpretación del concepto “matrícula”, que sin ser la más apropiada, también
podemos considerar válida, sería de la siguiente forma:

Vemos que la diferencia fundamental entre este diagrama y el anterior es que la clase-
asociación se ha transformado en una asociación a secas. Los atributos que antes asignábamos a
dicha clase asociación, se asignan ahora a la clase Matrícula. Las multiplicidades, aunque
representan cosas diferentes, no cambian, salvo en el caso de la asociación “contiene” en el lado de
Asignatura, que ahora pasa a ser “1..1”. Obsérvese que Matrícula es ahora una clase asociativa entre
Alumno y Asignatura.
En adelante, y para el diagrama completo, consideraremos que la interpretación más
adecuada es la primera de las dos anteriormente expuestas.
Hasta aquí hemos representado la estructura de la parte de la aplicación que contiene la
información referente a alumnos, diplomas, matrículas y asignaturas. Nos queda un concepto que
habíamos seleccionado como una posible clase en una primera lectura y que ahora vamos a ver si
realmente debemos modelar como tal, la clase Profesor. La clave está en el hecho de que entre las
funcionalidades del actor profesor está la de calificar a los alumnos matriculados en las asignaturas
que imparte, por lo tanto debe existir una relación que represente el vínculo semántico entre cada
profesor y sus asignaturas. La clase Asignatura ya la hemos definido, luego entonces nos queda
definir la clase Profesor y la relación entre ambas, que podemos llamar “imparte”:

5
 Ingeniería de Software I – Universidad Carlos III de Madrid

[¿Profesor.nombre de?]
Aunque el enunciado no lo menciona de forma explícita, este modelo nos plantea un
problema: según este diagrama no se puede saber qué profesor imparte una asignatura en un
periodo determinado (año, trimestre, curso...). Es decir, podemos saber qué profesores han impartido
alguna vez esa asignatura, pero no en qué periodo, pudiéndose dar el caso de que un profesor que
impartió la asignatura en un año anterior pero no en el actual tuviese la posibilidad de calificar u
obtener listados de asignaturas en el año actual. Esto se resuelve almacenando en el sistema el
periodo en el que cada profesor imparte cada asignatura. Es decir, doto de un atributo “periodo” a la
asociación “imparte” [no es una buena solución, comento al final]. Esto nos podría invitar a crear una
clase asociación Imparte, pero con el inconveniente de que los enlaces que constituyen dicha clase
asociación no son únicos para cada tupla de la misma. Por tanto, debemos representarla como una
clase asociativa, como muestra el siguiente diagrama:

[multiplicidades mal: Profesor.imparte debe ser 0..*, Asignatura.imparte debe ser 1..*]
Para finalizar, podríamos representar en nuestro diagrama final la similitud semántica que
existe entre las clases Alumno y Profesor, creando una generalización de ambas, que podríamos
llamar Usuario, abstracta, y en la que incluyéramos los atributos comunes a ambas, quedando así el
correspondiente diagrama parcial de clases:

6
 Ingeniería de Software I – Universidad Carlos III de Madrid

Así pues, sólo nos resta dibujar el diagrama de clases completo a partir de los anteriores
diagramas parciales. Dicho diagrama representa aquellas interpretaciones del enunciado que, como
hemos comentado, se han considerado más adecuadas.

[corregir multiplicidades ya mencionadas: Asignatura.diploma, Profesor.imparte,

Asignatura.imparte, Diploma.alumno, Imparte.asignatura]
[aunque tú mismo dices que consideras más apropiada la primera interpretación de matrícula,
sin embargo aquí has tomado la segunda, Matrícula como clase asociativa]
Creo que es necesario añadir una nueva clase Curso o Edición con los atributos
importeCrédito y fechas (fechaInicio y fechaFin si lo prefieres) para resolver el problema del periodo
de impartición de los profesores y el cálculo del importe de la matrícula.
Desaparece Matrícula.año, sustituida por la asociación Matrícula (0..*)---(1..1) Curso
Desaparece Importe.periodo, sustituida por la asociación Imparte (0..*)---(1..1) Curso

7
 Ingeniería de Software I – Universidad Carlos III de Madrid

Hay que notar que ahora Matrícula es parecida a una clase asociativa entre Alumno,
Asignatura y Curso (aunque un poco especial porque puede tener varias asignaturas, no una sola), e
Imparte es una clase asociativa entre Asignatura, Profesor y Curso. Supongo que por esta razón
surgen las dudas de si en realidad no deberían ser asociaciones ternarias.
Comento ahora las ideas que habéis enviado por correo.
Falta la restricción de que un alumno sólo puede matricularse en asignaturas de alguno de
sus diplomas. Aunque el enunciado no lo dice explícitamente, parece natural. Lo que no acabo de ver
claro es si es necesaria la asociación Matrícula-Diploma que Isidro ha suprimido; creo que tiene parte
de razón. Esto significa, por supuesto, que una Matrícula (en un conjunto de Asignaturas) puede
referirse a varios diplomas… Respecto a la notación, basta con describir la restricción, y añadirla
entre corchetes dentro de una nota ligada a la clase Matrícula.
Cuando me matriculo, ¿cómo sé a qué diploma pertenece la matrícula? Cada posible solución
tiene sus propios problemas:
1. Si lo dejamos como está, entonces la relación es indirecta o derivada, inferida a
través de Asignatura.diploma. Es decir, la matrícula en la asignatura A vale para
todos los diplomas que la contengan, el número de convocatoria y calificación es
único, etc. En la línea de la argumentación de Isidro: es una única instancia de
asignatura que pertenece a dos diplomas distintos, no meramente dos instancias
que tienen algunos o incluso todos los atributos iguales.
2. Si añadimos una asociación Matrícula-Diploma, entonces hay que incluirla en la
restricción, pero además hay que prever un procedimiento de “convalidaciones”,
que a mí me parece más propio cuando hablamos de asignaturas distintas con el
mismo nombre. En cambio, si se trata de la misma asignatura, no hay nada que
convalidar, sino simplemente contabilizarla en el diploma que corresponda, dando
la razón también a Isidro.
A veces me parece que la solución más natural no es la que propone Isidro (asignaturas
compartidas) sino la de asignaturas distintas con igual nombre, lo que requiere un procedimiento de
“convalidación” para añadir la matrícula en caso de cursar nuevos diplomas. En este punto pienso si
no se nos está yendo el problema de las manos y ha resultado demasiado complicado.
En todo caso, si añadimos una asociación Matrícula-Diploma, creo que Jorge y Vicente tienen
razón en decir que Matrícula “se puede” transformar en asociación ternaria (clase-asociación ternaria
en realidad, para alojar atributos; en mi versión sería cuaternaria, peor todavía, ya que Curso entra en
juego también). Las multiplicidades serían, creo:
(Diploma, Asignatura) --- * Alumno
(Alumno, Diploma) --- * Asignatura
(Alumno, Asignatura) --- 1 Diploma o * Diploma dependiendo de la opción de Asignaturas que
tomemos.
Tened en cuenta que casi siempre que una clase A está asociada con otras dos o más clases,
podemos plantearnos si A en realidad no debería ser una asociación n-aria. Pocas veces esto resulta
en una clarificación conceptual, debido a la dificultad inherente a las n-arias. Y en todo caso, como se
pierde la información de las multiplicidades internas para poner las externas, poco se gana con la
transformación.
Desde luego, si la matrícula significa conjunto de asignaturas, entonces para la calificación
necesitamos algo más, no puede ser un atributo de Matrícula.
En resumen, una cosa es que “se pueda” transformar en ternaria, perdiendo y ganando algo a
cambio, y otra cosa es que salgamos beneficiados con el negocio. Yo creo que en este caso salimos
perjudicados.
La solución que propuso Vicente no la acabo de entender: “Suponiendo que la Matrícula
engloba varias asignaturas: ternaria Alumno-Diploma-Asignatura con clase asociación "estudia"
(contiene el atributo calificación) y con una clase Matricula agregado de "estudia" y que contiene la
convocatoria.”
Jorge plantea el problema de los horarios. No creo que haga falta ni ayude el uso de
ternarias. Esta información no es propia de cada asignatura, puesto que puede variar en cada curso,
ni de cada profesor, por el mismo motivo. Es por tanto una información propia de la relación Profesor-
Asignatura, que ha sido modelada mediante la clase Imparte. Esta clase tendría una asociación (o
atributo multivaluado) con un conjunto de intervalos horarios, algo así como Imparte(1..1)---

8
 Ingeniería de Software I – Universidad Carlos III de Madrid

(1..*)Sesión, es decir, cada impartición puede estar asociada con una o más sesiones, cada sesión
define el lugar y hora, etc. Pero nos estamos acercando demasiado al problema que tuvimos que
resolver en Navarra hace seis años, con varios profesores por asignatura, sesiones de teoría y
práctica, asignaturas de libre elección… ¡Yo quería simplificar!
No entiendo por qué Vicente dice que la “asociación con el carácter” evita el uso de la
restricción y de la ternaria.
Propuesta final
Para ordenar un poco el debate, os propongo que esperemos a que Isidro envíe la siguiente
versión del documento, aceptando las modificaciones que he señalado, o no aceptándolas (lo cual
tendrá que justificar…).
Creo que el planteamiento general del documento debería ser: explicar alternativas cuando
las hay, escoger una de modo razonado, y seguir con ella hasta el final. No añadir complejidades
innecesarias que no estén contenidas en el enunciado (datos de alumnos; usuario y contraseña;
horarios, etc.). Básicamente tenemos dos alternativas de interpretación:
1. asignatura compartida / no compartida
2. matrícula en asignatura / en conjunto de asignaturas
Y en cuanto a las técnicas de modelado, podemos optar por asociaciones ternarias o clases
asociativas. Yo me inclino por estas últimas, aunque se puede mencionar su (pobre) equivalencia con
las ternarias.
Isidro, si en alguno de estos casos tienes duda de qué opción es mejor tomar, después de
todo lo que hemos discutido, no decidas y plantea el problema.
Finalmente, ¿os parece que deberíamos cambiar el enunciado para simplificar el problema?