Informe Proyecto ELO329: Malla interactiva con proyección de semestres restantes
Integrantes:
· José Flores Fuentes
· Javier Coñiam
· Jesús Bustamante
Descripción del problema
El estudiante promedio, para bien o mal, reprueba ramos. Por ello, al momento de reprobar alguno, normalmente uno va a la malla de la carrera y empieza a investigar si hay algún ramo que tenga
como prerrequisito el ramo reprobado. De esta manera, el estudiante se hace una idea acerca de los semestres adicionales que, si corresponde, tendrá que cursar por esos ramos con prerrequisitos.
El problema que precisamente se quiere cubrir, es que las herramientas actuales de mallas interactivas no son del todo de ayuda para el caso descrito, pues efectivamente ayudan a proyectar los
ramos restantes, pero no específicamente el tiempo restante de carrera. Entonces, la solución que se propone es una malla interactiva progresiva, de manera que el estudiante pueda ir llenando
semestre a semestre los ramos reprobados (si tiene), y así proyectar el tiempo restante y de egreso.
Análisis del problema
El escenario en el que se basa el proyecto es simple: un alumno reprueba ramos y específicamente quiere averiguar cuanto tiempo de carrera le sumó eso. Hay herramientas existentes simples para
ver cuantos ramos lleva un alumno aprobados y cuantos le quedan, tal vez incluyendo un porcentaje, para visualizar cuanto le falta, sin embargo, esas herramientas responden a otra pregunta del
alumno: “¿Cuántos ramos me quedan?”. Entonces, la pregunta del estudiante que se busca responder y facilitar su respuesta, sería “¿Cuántos semestres me quedan?”, donde hay que tomar en
cuenta otros parámetros (enfoque distinto al de una malla interactiva genérica) como elementos centrales (como prerrequisitos de un ramo) del proyecto. La solución propuesta es mediante un
programa desarrollado en Qt Creator y C++, donde el estudiante carga desde un archivo de configuración su malla académica y puede ir actualizando semestre a semestre su progreso y la aplicación
agranda su malla en cuanto a semestres tomando en cuenta los ramos reprobados. Además, el estudiante puede guardar su progreso en un formato que después puede cargar nuevamente en el programa.
Definición de requerimientos
- Caso de uso 1: Actualización de tamaño de malla en semestres
Actores: Alumno
Evento: Alumno aprieta botón “Actualizar” en la aplicación
Precondiciones:
· Alumno debe tener una malla cargada en el programa (sea malla base o cargada de un progreso ya hecho).
· Alumno agrega progreso a la malla por lo menos en 1 semestre (marca cuales aprueba y reprueba).
Curso normal del evento:
|
Actor |
Sistema |
|
1) Alumno apreta actualizar en la aplicación |
|
|
|
2) El sistema agranda la malla en ventana principal por columnas si se tuvieron que agregar semestres y muestra el N° de semestres restantes. |
- Caso de uso 2: Cargar progreso de malla interactiva
Actores: Alumno
Evento: Alumno aprieta botón “Cargar progreso” en el Menú “Archivo” de barra de menús.
Precondiciones:
· Usuario debe tener un archivo con su progreso hecho en otra instancia con la aplicación.
Curso normal del evento:
|
Actor |
Sistema |
|
1) Alumno aprieta botón “Archivo” en la barra de menús. |
|
|
|
2) El sistema despliega opciones “Importar”, “Guardar progreso”, “Cargar progreso”. |
|
3) Alumno selecciona opción “Cargar progreso”. |
|
|
|
4) Sistema despliega ventana de selección de archivo. |
|
5) Alumno selecciona archivo txt con su progreso. |
|
|
|
6) Sistema carga malla con progreso y la despliega en la ventana principal. |
- Caso de uso 3: Guardar progreso de malla interactiva
Actores: Alumno
Evento: Alumno aprieta botón “Guardar progreso” en el Menú “Archivo” de barra de menús.
Precondiciones:
· Alumno debe haber hecho algún progreso sobre una malla base o una malla cargada con progreso.
Curso normal del evento:
|
Actor |
Sistema |
|
1) Alumno aprieta botón “Archivo” en la barra de menús. |
|
|
|
2) El sistema despliega opciones “Importar”, “Guardar progreso”, “Cargar progreso”. |
|
3) Alumno selecciona opción “Guardar progreso”. |
|
|
|
4) Sistema despliega ventana de selección de directorio donde guardar archivo de progreso. |
|
5) Alumno selecciona directorio donde guardar archivo de progreso. |
|
|
|
6) Sistema guarda archivo de progreso en directorio seleccionado por usuario. |
- Caso de uso 4: Importar malla base
Actores: Alumno
Evento: Alumno aprieta botón “Guardar progreso” en el Menú “Archivo” de barra de menús.
Precondiciones:
· Alumno debe tener algún archivo de malla base.
Curso normal del evento:
|
Actor |
Sistema |
|
1) Alumno aprieta botón “Archivo” en la barra de menús. |
|
|
|
2) El sistema despliega opciones “Importar”, “Guardar progreso”, “Cargar progreso”. |
|
3) Alumno selecciona opción “Importar”. |
|
|
|
4) Sistema despliega ventana de selección de archivo de malla base. |
|
5) Alumno selecciona archivo de malla base. |
|
|
|
6) Sistema arma y muestra malla académica base, permitiendo a usuario marcar ramos aprobados o reprobados desde cero. |
Diseño
de la solución
Diagrama de clases UML
Figura 1: Diagrama de clases UML de solución
Diagrama de secuencia de Caso de Uso 1(Base)
Figura 2: Diagrama de secuencia de CU1
Respecto al diseño del proyecto, se tomaron las siguientes decisiones:
- No hacer una entidad semestre: Se pensó también acerca de una tercera entidad “Semestre”, que tendría que ir entre malla y ramo, tal
que un semestre tenga varios ramos, y una malla varios semestres. No se optó por ello dado que lo comparamos con la opción de un
simple atributo “semestre” de ramo, que era lo más sencillo en la práctica para la programación, pues en el contexto la entidad “Semestre”
no hubiera tenido otro rol además de contener ramos.
- No tomar en cuenta ramos complementarios: Ramos complementarios pudieron haber sido un subtipo de ramo, pero se optó por no
tomarlos en cuenta como ramos distintos, pues ahí nos metíamos con lo que tiene que decidir el alumno, cosa que no está contemplada
en el diseño. Además, bajo el contexto, un ramo complementario también se adhiere a un calendario de ramos que pueden ser impartidos
en ciertos semestres depende directamente de cada departamento en la universidad (y no hay una API de estos tampoco).
- No armar interfaz para introducir ramos o armar mallas: El punto del proyecto es que el alumno le da una malla (en el formato que nosotros
estimamos) y la aplicación le facilita una interfaz para responder la pregunta inicial: ¿Cuántos semestres me quedan?. De todas maneras,
sería una buena proyección del proyecto a futuro el poder hacer otra interfaz para diseñar una malla desde 0 con herramienta de crear ramos,
de forma que el usuario no tenga que escribir a mano un txt (como en este caso) para usar el programa que acá si diseñamos e implementamos.
- No tomar en cuenta ramos con “candado”: En el contexto real, al reprobar un ramo, este queda con “candado”, que significa que sí o sí debe
tomarse al siguiente semestre. Nuestra aplicación no toma en cuenta eso.
-
Toma en cuenta paridad: El programa toma en
cuenta la paridad por omisión. Esto es, si el ramo es anual y está en un semestre
impar, entonces
el siguiente semestre que
estará disponible (si lo reprueba el alumno) es otro semestre impar.
Implementación
de la solución
La interfaz, en general tomó la siguiente forma:
Figura 3: Interfaz general
Donde en azul están los ramos que se pueden marcar como aprobados(disponibles) y en gris están los bloqueados.
Figura 4: Selección de ramos de primer semestre menos MAT-021 aprobados (sin actualizar)
Ahora, en verde se encuentran los ramos marcados como aprobados. En pos de la demostración, MAT-021 se configuró como un ramo anual,
a pesar de que en realidad no lo es.
A continuación, se muestran las implementaciones para algunos casos de uso.
CU1: Actualización de tamaño de malla en semestres
Figura
5: Selección de ramos de primer semestre menos MAT-021 aprobados (actualizado)
Se puede apreciar que, en primer lugar, la malla creció en 1 año (corresponde para ramos anuales). Además, en esta malla, FIS-110 requiere
tener MAT-021 aprobado, además de MAT-022 necesitar MAT-021.
Figura 6: Formato en archivo de configuración
Se puede notar en el “slot” antepenúltimo, que es donde se ponen los prerrequisitos, que está MAT-021 en ambos ramos, que se aplazan en 1
semestre, además de los que necesitaban MAT-022, FIS-120, etc.
CU2 y CU3: Guardar y cargar progreso
Figura 7: Opciones de MenuBar
Figura 8: Ventana emergente de guardar progreso
Figura 9: Ventana emergente de cargar progreso
Nota: Se omite prueba para
CU4, pues su prueba es el hecho de tener la malla base. Además, las imágenes
usan harto espacio.
Dificultades en el progreso
Una dificultad notable en la parte gráfica es que la interfaz se cortaba al extender una proyección de 13 o más semestres y realmente no
supimos durante gran parte del proyecto arreglarlo, pues la mayor parte del tiempo nos centramos en la parte de código de “procesamiento”
del txt, que era muy tedioso, dado que se trabajó con QString y se tuvo que revisar harta librería de Qt Creator, por tanto, gráficamente, se
trabajó con un prototipo que se acababa tapando con la ventana, pero por lo menos podíamos verificar la lectura del txt. No fue sino hasta la
“fase final” que se arregló (para verificar que todo se leyera bien) ajustando setMinimumSize() y updateGeometry() para que la grilla se auto-
comprima a la ventana al presionar actualizar. Además, hubo dificultades también ligadas a como organizar el proyecto en cuanto a métodos,
pues teníamos el método ligado al botón de actualizar, pero también tuvimos que implementar otro método para actualizar los estados (color de
aprobación) cada vez que se clickeaba un ramo, para actualizar el color del ramo clickeado(ahí la dificultad estuvo en reconocer eso, que era otro
método de actualización el que había que implementar). En la “fase final” del proyecto (con el bug de interfaz cortada arreglado, pero antes del entregable
final), hubo un error de cálculo y movimiento de los ramos que movía todo incorrectamente, de manera que a veces bajo ciertas condiciones, ramos
reprobados anuales que fueron aprobados posteriormente volvían a su lugar en semestre 1, en lugar de mantenerse en su lugar del semestre que fueron
aprobados. Esto provocaba que la malla se achicase de nuevo, a veces volviendo a 12 semestres a pesar de reprobar ramo anual.
Figura 10: Bug fase final, reprobando MAT-021
Figura 11: Bug fase final, después de actualizar pasando 2 semestres seguidos
La figura 10 corresponde a lo que pasa al actualizar con MAT-021 reprobado en primer semestre tanto para la versión final tanto
como para la versión de la fase final (antes del entregable). Después, en figura 11 se aprueba todo 2 semestres seguidos y se
actualiza, lo que provoca que MAT0-21 se vaya a semestre 1 y, por tanto, desaparezcan las columnas de semestre 13 y 14.
Lo que se pudo arreglar, en la versión entregable final, es que no desaparezcan los últimos semestres, pero el ramo, al ser
aprobado (independiente del semestre), siempre volvía al semestre original donde se supone que se aprueba.
Nota final: Disculpas de
antemano por la calidad de las imágenes en formato htm, parece ser que Word
comprime imágenes para
este formato.