代做data编程、Java/c++程序代写

项目预算：开发周期：发布时间：要求地区：

University of Technology Sydney, FEIT – Assessment 1 Page 1
Assessment 2 – Part 2: Software Development
Due date: Monday October 30, 2023, by 09:00 AM
Weight: 50 out of total assessment 1 weight 70
Project: University Application (CLI system and GUI system)
Collaboration: Group of three. Group and individually assessed.
1- 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.
University of Technology Sydney, FEIT – Assessment 1 Page 2
2- 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.
University of Technology Sydney, FEIT – Assessment 1 Page 3
3- 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:
o 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.
o 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:
o 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.
o mark is randomly generated where 25<= mark <= 100
o 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.
University of Technology Sydney, FEIT – Assessment 1 Page 4
4- 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 University System Scenario:
The Student System – Register:
In the login/register scenarios, students’ credentials are verified against regular expressions stored
as constants in the Utils class.
Email regex should ensure that the dot ( . ), the (@) and the (university.com) are present
Password regex should ensure that entered passwords are:
- Start with upper case
- Minimum 6 letters
- Following by minimum 3-digits
Registered users are saved in the “students.data”. When logging in, your program should read the
data from the file and verify the student credentials (as per Sample I/O)
University of Technology Sydney, FEIT – Assessment 1 Page 5
The Student System – Login:
University of Technology Sydney, FEIT – Assessment 1 Page 6
The Student Course System – Enrolment:
In the enrolment scenario, no controls are needed to sort the subjects.
Every time a student enrols in a subject, the overall mark should be re-calculated.
In the enrolment scenario, you must keep track of the enrolled subjects
Subject enrolment data is saved in the file “students.data” within the Student objects
University of Technology Sydney, FEIT – Assessment 1 Page 7
The Student Course System – Remove Subject:
The Student Course System – Change Password:
In the change password, you may reuse the same password.
University of Technology Sydney, FEIT – Assessment 1 Page 8
The Admin System – View Students – Groups - Partitions:
The Admin System – Remove a Student and Removing all Students:
University of Technology Sydney, FEIT – Assessment 1 Page 9
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”.
5- 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.
University of Technology Sydney, FEIT – Assessment 1 Page 10
6- Marking Scheme
Total assessment Part 2 mark is 50/70. The program must work so marks can be awarded for
functionality, correctness, design, output matching with the sample I/O.
Your program solution (should it work) will be marked according to the following marking
schema:
a. The University System (4 Marks)
Entity Criteria Mark
Student Can go to student menu 1
Admin Can go to the admin menu 1
Browsing Student/Admin can browse between menus 1
Matching I/O I/O wording, coloring, indentation matches the sample 1
b. The Student System (9 Marks)
Entity Criteria Mark
Register Student can register – data saved to file 2
Login Student can login – data read from file 2
RegEx For login and register 2
Error Handling Exceptions, errors, logical scenarios are handled 2
Matching I/O I/O wording, coloring, indentation matches the sample 1
c. The Student Course system (15 Marks)
Entity Criteria Mark
Enroll Student can enroll in a subject – 4 maximum 2
Tracking Subject enrolment is tracked 2
Remove a subject Remove by ID 2
Show subjects Subject listing 1
Change password Student can change their password 2
Read/Write to file Student and subject data are read/written from/to file 3
Error Handling Exceptions, errors, logical scenarios are handled 2
Matching I/O I/O wording, coloring, indentation matches the sample 1
University of Technology Sydney, FEIT – Assessment 1 Page 11
d. The Admin System (15 Marks)
Entity Criteria Mark
Show students Admin list all students 1
Group students Admin groups students according to the grade 2
Partition students Admin partitions students as Pass/Fail 2
Remove a student Admin can remove a student by ID 2
Clear file Admin can remove all students and clear the file 2
Read/Write to file Student and subject data are read/written from/to file 3
Error Handling Exceptions, errors, logical scenarios are handled 2
Matching I/O I/O wording, coloring, indentation matches the sample 1
e. GUIUniApp (7 Marks)
Entity Criteria Mark
Login window Login window works and on login, students are taken to the
enrollment window. Use the registered students from students.data
2
Enrollment window Enrollment window allows students to add subjects (maximum 4) 2
Subjects window Enrolled subjects are added to the list in the subjects’ window 2
Exception window Handle incorrect format exception and max 4 subjects’ exception 1
7- Deliverables and Contribution
The assessment requires collaboration and equal amount of contribution between all group
members. The individual student contributions or parts will be collated in a group deliverable for
submission and assessment (group submission but individual assessment). The deliverables of this
assessment task also include a compulsory oral/visual presentation (no PowerPoint slides) of the
individually implemented working software application during the scheduled assignment
assessment or review session (showcase).
The submitted “case study software” CLI / GUI must fully work before marks can be awarded.
CLI (and GUI) applications can be in the same project folder and submitted in the same ZIP file (if
your team chose to complete the GUI challenge task.
8- Assessment Submission
Submit your assessment project code (single submission only/group) as a ZIP file.
Assessment file name: Assessment file name: (group-Cmp.zip)
to Canvas/Assignments/Task1/Part2. Submit your assessment ZIP project by the due date: Monday
30/10/2023 by 9:00 AM
University of Technology Sydney, FEIT – Assessment 1 Page 12
9- Assessment Showcase
Assessment 1 working software project demonstration and showcase will be conducted during
usual class hours in week 12. All team members must attend the showcase. Students who failed to
appear and present in this compulsory assignment assessment and review sessions (Showcase) will
receive zero (0) as a final individual mark for assessment 1 – Part 2.
10- Special Consideration
Special consideration, for late submission, must be arranged beforehand with the subject coordinator (email: georges.boughantous-1@uts.edu.au). Please also see the UTS Special
Consideration Process: www.sau.uts.edu.au/assessment/consideration
11- Late Penalty
See subject outline for late submission penalty unless an extension has been approved by the
subject coordinator.
12- Assessment Misconduct
Please see the subject outline for plagiarism and academic integrity in conjunction with UTS policy
and procedures for the assessment for coursework subjects.