This repository is the final project for the subject “Object-Oriented Programming” of the “Analysis, development and programming of applications” career. The idea of the project was to create an application for an institute where all the information must be saved locally through serialization.
ENGLISH: This project is the final delivery of the course “Object Oriented Programming”. The work will consist of programming an application with a visual interface applying the knowledge learned in the career. The use of the concepts seen in the subject will be evaluated, as well as the exhaustiveness in solving the problem. The project is for "Caminemos el Trayecto" Institute, they needs an application to control its courses, which are taught by teachers and taken by students. The courses are proposed by the professors, and may require that the student have taken a previous course (no more than 2). They also have a description that says what they are about and a limit on the number of students to enroll. By default, courses must have the status "Proposed". After the teacher proposes a course, it must be approved by the Institute administrator, after which it becomes available for students to register, or "Enabled". Any Student can see what courses they are enrolled in, their list of approved courses, and the list of courses they have attended. If a student does not meet previous course requirements or the course is fully enrolled, the student should not be able to register nor see it. At the end of the course, the teacher will mark the course as "Finished" and must decide which students passed and which failed. After this, the course can be restarted without having to repeat the aprobation of the administrator. At any time while the course is enabled, it can be marked as “Closed”, to prevent students from registering, and once this is done, they cannot return to the previous state. The Institute administrator can register teachers and students, who will access the system with they document number. The default password must be the same as the document, and the first time they access the system they have to change it, obligatory. The administrator can also clear their password, which returns it to its default value (and again requiring them to change it in the next log in).The administrator can also cancel courses that are "completed" or "proposed". Canceled courses are not deleted! The Administrator can also disable a teacher or student account as a penalty, in which case they must leave a message that will be shown when the user is trying to enter the system, so that in the future they can regularize their situation. Teachers can view their list of enabled or closed courses. In the case of closed courses they can see a list of all the students that are enrolled to the course and can finish it as previously explained. The professor can also see the list of completed courses so that they can rehabilitate them whenever they want, and in sections separated those proposed and those canceled. Students can see the complete list of courses for which they can register and the list of approved courses. Failed courses are not stored. Once registered in a course the student cannot unsubscribe. All users can change their password at any time. Consider making individual windows for each type of user and dividing model, visual and exceptions in 3 separate packages.
ESPAÑOL: El Instituto "Caminemos el Trayecto" necesita una aplicación para controlar sus cursos, los cuales están dictados por docentes y tomados por alumnos. Los cursos son propuestos por docentes, y pueden requerir que el alumno tenga hecho algún curso previo (no más de 2). También tienen una descripción que dicen de qué tratan y un tope de alumnos a inscribir. Por defecto los cursos deben tener un estado de "Propuesto". Luego de que el docente proponga un curso, debe ser aprobado por el administrador del Instituto, luego de lo cual se pone a disposición de los alumnos para registrarse, o "Habilitado". Cualquier alumno puede ver a qué cursos está inscripto, su lista de cursos aprobados y la lista de cursos a los cuales inscribirse. Si un alumno no cumple con los requisitos de cursos previos o el curso está con la matrícula completa, el alumno no debe poder verlo. Al finalizar el curso, el docente marcará el curso como "Finalizado" y deberá decidir qué alumnos lo aprobaron y cuáles lo desaprobaron. Luego de esto, el curso puede reiniciarse sin tener que volver a pasar por la etapa de habilitación, pero sólo cuando el docente que la dicta quiera. En cualquier momento mientras el curso está habilitado se lo puede marcar como "Cerrado", para evitar que se inscriban alumnos una vez empezado, y una vez hecho esto no puede volverse al estado anterior. El administrador del Instituto puede registrar docentes y alumnos, los cuales accederán al sistema con su número de documento. La contraseña por defecto deberá ser la misma al documento, y la primera vez que accedan al sistema se les debe pedir que la cambien. También puede blaquearles la contraseña, la cual la vuelve a su valor por defecto (y volviendo a requerir que la cambien en su primer acceso). El administrador también puede cancelar cursos que estén finalizados o propuestos. Los cursos cancelados no se borran! El administrador también puede deshabilitar una cuenta de docente o alumno como sanción, en cuyo caso debe dejar un mensaje que se les mostrará al intentar ingresar al sistema de forma tal que en un futuro puedan regularizar su situación. Los docentes pueden ver su lista de cursos habilitados o cerrados, en los cuales ve la lista de alumnos y puede finalizarlos como fue explicado previamente. También puede ver la lista de cursos finalizados de forma tal de rehabilitarlos cuando quiera, y en apartados separados aquellos propuestos y aquellos cancelados. Los alumnos pueden ver la lista completa de cursos a los que puede registrarse y la lista completa de cursos aprobados. Los cursos desaprobados no son almacenados. Una vez registrado en un curso el alumno no puede darse de baja. Todos los usuarios pueden cambiar su contraseña en cualquier momento. Considerar hacer ventanas individuales para cada tipo de usuario y dividir modelo, visual y excepciones en 3 paquetes por separado.