Reference no: EM133694193

Fundamentals of Software Development

Assessment - Software Development

Project Abstract
A local university wants to develop a new interactive system. The system should offer access to two interactive sub-system menus for students and admins. The university interactive system is called "CLIUniApp". CLIUniApp stores students' data into a local file "students.data". All CLIUniApp CRUD operations should be operated with the storage file "students.data".

The university main system should offer access to students and admins. Students accessing the sub-system have the choice to login to the system (if they are previously registered) or register to the system. A registered student can enrol in maximum 4 subjects. A registered student can remove subject. A registered student can change their access password. A registered student can view their enrolment.

Admins already exist in the system and do not need to register. Admins using the sub-system can remove a student from the "students.data" file. Admins can view students partitioned as Pass/Fail. Admins can group and show students organized by grade Admins can view all students from file. Admins can clear all file data.

Develop the case study project using your preferred IDE with Java or Python and submit the software application as a .zip file by the due date (refer to submission section). The application should be development in a group of 3 students. Develop the application based on the requirement analysis, modelling and design completed by your team in Part 1 of the case study. Part 2 requirements are further explained in the "System Menu Requirements" section and in the "Model Classes" section. Feel free to add more classes following your class diagram of Part 1. It is important to refer to the "Sample I/O" section to understand the system menu options and possible output.

The case study has a GUI challenge task. The GUI challenge task is a standalone GUI application called GUIUniApp. Refer to section 5 for more information.

System Menu Requirements
The program system is composed of four system menus: The University System, The Student System, The Student Course System, and the Admin System

The University System
The university menu system should enable users to choose to go the Admin menu or Student Menu
(A) Admin
(S) Student
(X) exit

The Student System
The student menu system should enable students to Login and Register as follows:
(l) login
(r) register
(x) exit

Register
Students should be able to register. Email and password should be verified against pattern rules. Then the student should be checked if they exist. Only register students that do not exist in the Database file. On registration, student data should be stored in "students.data".

Login:
Students should be able to login. Then the student should be checked if they exist. Only a registered student should login. Upon login, students' data should be read from "students.data". After login, a student goes to Student Course Menu that offers the choices:

The Student Course System
Logged in students can access this menu to perform the following actions:
(c) change: enables a student to change their password
(e) enrol: Student enrols in a subject. A student can enrol in maximum 4 subjects.
(r) remove: Student can remove a subject from the subjects' enrolment list
(s) show: Shows the enrolled subjects and the marks and grades for each subject
(x) exit

The Admin System
Admin menu offers the following actions:
(c) clear database file: enables admin to clear the data file "students.data"
(g) group students: shows the students organized with respect to the grade
(p) partition students: shows the pass/fail distribution
(r) remove student: enables admin to remove a student by ID
(s) show: show the students from the data file
(x) exit

NOTE: Admins already exist in the system. They do not need to login into the system. Admins can simply use the admin sub-system.

Sample Model Classes
The program model has at least the following classes: Student, Subject, and Database. These classes are responsible for storing the program data and for supplying the program controllers with functionalities and data. You may add more classes based on Part 1 design.

The Student Class
The Student class has the fields:
ID randomly generated 1 <= ID <= 999999, unique and formatted as 6-digits width. IDs less than 6-digits width should be completed with zeroes from the left.
name, email, password, and a list of subjects
A student can only enrol in 4 subject maximum (A course of 4 subjects).
A student can enrol/drop a subject at any time.
Upon enrolment in a subject a random mark is generated for this subject 25<= mark <= 100
Upon enrolment in a subject, the grade of that subject is calculated based on the mark
A student pass/fail a course if the average mark of the subjects is greater or equal to 50
A student can change their password at any time.

The Subject Class
The Subject class has the fields:
ID randomly generated 1 <= ID <= 999, unique and formatted as 3-digits width IDs less than 3-digits width should be completed with zeroes from the left.
mark is randomly generated where 25<= mark <= 100
grade is determined based on the mark

The Database Class
The Database class should contain the functionalities to:
check if the file "students.data" exists before using it
create the file "students.data" if it doesn't exists
write objects to the file "students.data"
read objects from the file "students.data"
clear the objects from the file "students.data"
NOTE: All program menu(s) actions (Student and Admin) should use the "students.data" data and perform CRUD operations with this data.

Best Practices and Recommendations

The program is best developed using classes (controllers) to manage the data exchange between the model classes (Student, Subject, Database) and the menu(s) actions. The controllers (for example: StudentController, SubjectController, etc...) are normal classes that use the "students.data" data and perform CRUD operations with this data. The controllers contain the system menus that use the model objects and work with the data file "students.data".

NOTE: You may add any controller classes based on Part 1 case study design. Groups can implement the controllers the way that suits their program.

Sample I/O
The sample I/O should be used as a reference and guidance to help you understand the scenarios of the program. The sample I/O outlines several scenarios to help you understand how the program should work and how the output should be designed and formatted. The Sample I/O is composed of the following scenarios:

The admin should read the students data from the file "students.data" and produce the outputs shown in the scenario (listing, grouping, partitioning).
When the admin removes a student, or remove all students, that data should be removed from the file "students.data".
Case Study GUI Implementation
The case study GUI software implementation is a challenge task of Part 2. Develop a GUI application called "GUIUniApp" only for students. GUIUniApp should allow students to login into the system. The login window is the GUI main window. Once a student logs in correctly they can enrol into subjects (4 subjects maximum). Every time a student is enrolled in a subject, the subject is added to the subject menu enrolment list. Handle possible exceptions for empty login fields and for enrolment in more than 4 subjects.
Your GUIUniApp should have at least 4 windows (as indicated in the marking scheme). The GUIUniApp requirements are the following:
Access management: Login for students (No admin options)
Enrolment management: Logged in student can enrol in 4 subjects (maximum). New subjects should be added to the subject GUI menu list.
Exception handling. If there are any exceptions, for example: empty login fields, incorrect student credentials, incorrect email format.
Data source management: You should work with registered students details already saved in the file ‘students.data' and use the registered students (in the CLIUniApp) to login into the GUIUniApp.

Attachment:- Software Development.rar