程序代写代做 html graph Java javaFx 15.05.2020

15.05.2020
148024
Applications Programming Assignment 2
Topics:
OO Design, GUI, MVC, Tables, Lists
Learning Outcomes:
This assessment task addresses the following subject learning objectives (SLOs): 3, 4 and 5
Due date:
11:59PM Monday 8 June
Weight:
30%
Platform:
PLATE
Individual Work
All work is individual. You may discuss ideas, approaches and problems, but you should write every line of code yourself except for code copied from the lecture notes, lecture code or lab code. You MUST NOT let another student see your solution code, and you MUST NOT look at another st􏰄dent􏰅s sol􏰄tion code. More information about Academic Misconduct can be found at:
http://www.gsu.uts.edu.au/rules/student/section-16.html
Specification
After a successful trial run of the Assignment 1 timetable system, UTS has decided it would like you to build a graphical user interface for the application using JavaFX.
Functionality
When the application is la􏰄nched, the 􏰆Uni􏰇ersit􏰈􏰉 􏰊indo􏰊 appears which shows a list of students, or the
1

15.05.2020
placeholder 􏰆No st􏰄dents􏰉 if there are no st􏰄dents (as is the case initiall􏰈):
Clicking 􏰆Add St􏰄dent􏰉 brings 􏰄p the 􏰆Add St􏰄dent􏰉 􏰊indo􏰊 􏰊ith a data entr􏰈 form:
Clicking 􏰆Cancel􏰉 closes the 􏰊indo􏰊 􏰊itho􏰄t adding a ne􏰊 st􏰄dent. The 􏰆Add􏰉 b􏰄tton is disabled 􏰊hile the student number is blank, or the student name is blank, or an attendance mode has not been chosen. Clicking 􏰆Add􏰉 􏰊ill res􏰄lt in the error 􏰆St􏰄dent alread􏰈 e􏰋ists􏰉 if a st􏰄dent 􏰊ith the gi􏰇en n􏰄mber alread􏰈 exists in the university.
Other􏰊ise, clicking 􏰆Add􏰉 􏰊ill add a ne􏰊 st􏰄dent to the 􏰄ni􏰇ersit􏰈 􏰄sing the data entered, and the 􏰆Add St􏰄dent􏰉 􏰊indo􏰊 is closed. The 􏰆Uni􏰇ersit􏰈􏰉 􏰊indo􏰊 instantl􏰈 displa􏰈s the new student in the list:
2

15.05.2020
The 􏰆Remo􏰇e St􏰄dent􏰉 and 􏰆Login􏰉 b􏰄ttons are enabled onl􏰈 􏰊hen a st􏰄dent has been selected in the list. Clicking 􏰆Remo􏰇e St􏰄dent􏰉 􏰊ill remo􏰇e the st􏰄dent from the 􏰄ni􏰇ersit􏰈 and 􏰊ithdra􏰊 the st􏰄dent from all activities in which that student is enrolled. The user interface is immediately updated to reflect this change.
Selecting a st􏰄dent and clicking 􏰆Login􏰉 􏰊ill open the 􏰆St􏰄dent􏰉 􏰊indo􏰊:
3

15.05.2020
The st􏰄dent􏰅s name, n􏰄mber, attendance and scholarship is sho􏰊n at the top. The attendance is sho􏰊n as either 􏰆F􏰄ll Time􏰉 or 􏰆Part Time􏰉. The scholarship is sho􏰊n as either 􏰆Yes􏰉 or 􏰆No􏰉. The 􏰆M􏰈 Acti􏰇ities􏰉 table displays all the activities that the student is currently enrolled into, or the placeholder 􏰆Not enrolled in an􏰈 acti􏰇ities􏰉 if the st􏰄dent is not enrolled in any activities.
To enrol into an activity, the user first chooses a subject from the ComboBox. After selecting a subject, the table below the ComboBox presents a list of activities in that subject:
The 􏰄ser ma􏰈 then select an acti􏰇it􏰈 from that table and click 􏰆Enrol􏰉. The 􏰆Enrol􏰉 b􏰄tton is enabled onl􏰈 􏰊hen an activity has been selected and there is an a􏰇ailable seat in that acti􏰇it􏰈 and the st􏰄dent isn􏰅t alread􏰈 enrolled in that acti􏰇it􏰈. Clicking the 􏰆Enrol􏰉 b􏰄tton res􏰄lts in the st􏰄dent being enrolled into that acti􏰇it􏰈, and being withdrawn from any activity in that subject with the same group as the new activity being enrolled into. The 􏰄ser interface is immediatel􏰈 􏰄pdated to reflect the ne􏰊 s􏰈stem state. In partic􏰄lar, the 􏰆Enrolled􏰉 col􏰄mn for the selected acti􏰇it􏰈 increases b􏰈 1, and the acti􏰇it􏰈 appears in the 􏰆M􏰈 Acti􏰇ities􏰉 table. If the st􏰄dent 􏰊as first 􏰊ithdra􏰊n from another acti􏰇it􏰈, the 􏰆Enrolled􏰉 col􏰄mn for that acti􏰇it􏰈 decreases b􏰈 1. B􏰄ttons sho􏰄ld also be appropriately enabled or disabled based on the current state (see above for the when to disable the 􏰆Enrol􏰉 b􏰄tton and belo􏰊 for 􏰊hen to disable the 􏰆Withdra􏰊􏰉 b􏰄tton).
To 􏰊ithdra􏰊 from an acti􏰇it􏰈, the 􏰄ser selects an acti􏰇it􏰈 from the 􏰆M􏰈 Acti􏰇ities􏰉 table and clicks 􏰆Withdra􏰊􏰉. 4

15.05.2020
The 􏰆Withdra􏰊􏰉 b􏰄tton is enabled onl􏰈 􏰊hen an acti􏰇it􏰈 has been selected from the 􏰆M􏰈 Acti􏰇ities􏰉 table. Upon clicking 􏰆Withdra􏰊􏰉, the 􏰄ser interface is immediatel􏰈 􏰄pdated to reflect the ne􏰊 s􏰈stem state.
Clicking 􏰆Logo􏰄t􏰉 closes the 􏰆St􏰄dent􏰉 􏰊indo􏰊.
Layout
Every window is divided vertically into 3 overall parts: a header section, a content section, and a footer section.
􏰌 The 􏰆Uni􏰇ersit􏰈􏰉 􏰊indo􏰊 sho􏰊s:
􏰍 A header containing the UTS logo (do􏰊nloadable from http://www.uts.edu.au/sites/default/files/logo_2.png ) and the heading text 􏰆Timetable S􏰈stem􏰉.
􏰍 A content section containing a ListVie􏰊 􏰊ith a preferred 􏰊idth of 300 pi􏰋els and a preferred height of 200 pixels. The ListView is centred horizontally within the content section.
􏰍 A footer containing 3 b􏰄ttons centred hori􏰎ontall􏰈.
􏰌 The 􏰆Add St􏰄dent􏰉 􏰊indo􏰊 sho􏰊s:
􏰍 A header containing the heading te􏰋t 􏰆Add ne􏰊 st􏰄dent􏰉.
􏰍 A content section containing a form laid o􏰄t in a GridPane. The grid has 5 rows containing 4 Labels, 2 TextFields, 2 RadioButtons, 1 CheckBox and a Text to display the error message. The error message spans 2 columns and is centred horizontally.
􏰍 A footer containing 2 b􏰄ttons centred hori􏰎ontall􏰈.
􏰌 The 􏰆St􏰄dent􏰉 􏰊indow shows:
􏰍 A header containing the heading te􏰋t 􏰆Logged in as 􏰉 at the top left, and a GridPane at the top right. The GridPane contains 3 Labels in the left column and 3 Texts in the right column.
􏰍 A content section containing t􏰊o s􏰄bsections:
􏰏 The first section begins 􏰊ith the heading te􏰋t 􏰆M􏰈 Acti􏰇ities􏰉 aligned to the left, and a button aligned to the right. Below both is a TableView.
􏰏 The second section begins 􏰊ith the heading te􏰋t 􏰆Enrol into s􏰄bject􏰉 followed by a ComboBox, both aligned to the left, and a button aligned to the right. Below these is a TableView.
􏰍 A footer containing a b􏰄tton centred hori􏰎ontall􏰈.
Style
The following CSS colours are used:.
􏰌 #0099cc is 􏰄sed as the backgro􏰄nd colo􏰄r of the header sections and the buttons. 􏰌 #00749b is 􏰄sed as the backgro􏰄nd colo􏰄r of the content sections.
􏰌 #252b2b is 􏰄sed as the backgro􏰄nd colo􏰄r of the footer sections.
􏰌 #333333 is 􏰄sed as the colo􏰄r of labels.
􏰌 #ffffff is 􏰄sed as the colo􏰄r of heading te􏰋t and b􏰄tton te􏰋t.
􏰌 FIREBRICK is used as the colour of error messages.
􏰌 #00bfff is 􏰄sed as the backgro􏰄nd colo􏰄r of a b􏰄tton d􏰄ring the ho􏰇er state.
The following fonts are used:
􏰌 Heading te􏰋t is Arial 􏰊ith font si􏰎e 32p􏰋.
􏰌 Labels 􏰄se font si􏰎e 12p􏰋.
􏰌 Label te􏰋t, B􏰄tton te􏰋t and error text is bold. 􏰌 Defa􏰄lt fonts are 􏰄sed else􏰊here.
Spacing and padding is also important. While exact measurements are not given in this specification, your application should include spacing and padding roughly equivalent to the screenshots above.
Code
Your solution must satisfy the following code requirements:
5

15.05.2020
􏰌 Yo􏰄r sol􏰄tion m􏰄st follo􏰊 an MVC architect􏰄re.
􏰌 Yo􏰄r package str􏰄ct􏰄re sho􏰄ld place the models in a package named 􏰆model􏰉, the views in a package named 􏰆􏰇ie􏰊􏰉 and the controllers in a package named 􏰆controller􏰉.
􏰌 The models m􏰄st notif􏰈 the 􏰇ie􏰊s of changes b􏰈 correctl􏰈 appl􏰈ing the Ja􏰇aFX property patterns and observable lists. Any model data that can change must be observable. Any model data that never changes does not need to be observable.
􏰌 The attendance mode m􏰄st be stored in the st􏰄dent􏰅s attendance String propert􏰈. The 􏰇al􏰄e 􏰆ft􏰉 sho􏰄ld be stored to represent F􏰄ll Time, and the 􏰇al􏰄e 􏰆pt􏰉 sho􏰄ld be stored to represent Part Time.
􏰌 Each 􏰇ie􏰊 m􏰄st be defined in FXML.
􏰌 The 􏰆St􏰄dent alread􏰈 e􏰋ists􏰉 error message m􏰄st be implemented as an e􏰋ception. The model should throw an exception, and the controller must catch the exception and show the error message on the view.
Skeleton Code
Download the skeleton code for Assignment 2 from the Assignment 2 assessment page on PLATE ( https://plate.it.uts.edu.au/ ). Your solution must be based on this skeleton code.
Included in the skeleton code is a text file called progress.txt which must be filled in by you as you progress through the assignment (see 􏰆PLATE marking􏰉 and 􏰆S􏰄bmission and Ret􏰄rn􏰉 belo􏰊).
Expected Workload
The time to do the assignment to a distinction level (i.e. a mark between 75% to 84%) has been estimated at 15 hours for a student of average ability who has completed all the tutorial and lab exercises.
Online Support
The Assignment 2 discussion board has been set up in ED so that students can ask questions, and other students can reply. The course coordinator will post a reply only if the student response was wrong, or in the case of correcting a mistake in the assignment specification.
You must not post or share Java code to the discussion board. The board is there to help you, not to provide the solution. Posting your code is academic misconduct and will reported. Each time this rule is 􏰇iolated, the code 􏰊ill be remo􏰇ed and replaced 􏰊ith a comment of the form: 􏰆Strike 1: Posting code􏰉. After 3 strikes, the discussion board will be deleted because it did not work.
FAQs (Frequently Asked Questions) and their answers will be posted in the platform. If you have a question, check the FAQ first; it may already be answered there. You should read the FAQ at least once before you hand in your solution, but to be safe check it every couple of days. Anything posted on the FAQ is considered to be part of the assignment specification. The FAQ will be frozen (no new entries) two days before the due date; no questions will be answered after it is frozen.
If anything about the specification is unclear or inconsistent, contact the subject coordinator who will try to make it clearer by replying to you directly and posting the common questions and answers to the FAQ. This is similar to working on the job, where you ask your client if you are unsure what has to be done, but then you write all the code to do the task. Email huan.huo@uts.edu.au to ask for any clarifications or corrections to the assignment.
Submission to PLATE
READ THIS ENTIRE SECTION CAREFULLY
PLATE cannot test the behaviour and appearance of a graphical user interface on its own. Instead, Assignment 2 is marked by a combination of PLATE, student peer marking (including peer marking others and marked by others within due time), and the subject coordinator.
Included in the skeleton code is a file called progress.txt which you must fill out as you progress through the assignment 2. A sample of the beginning of this file is shown below:
6

15.05.2020
Launch the application
[?] The UTS Logo is shown
[?] The “Timetable System” heading is shown
[?] “No students” is shown in the empty list
[?] “Add Student” appears and is enabled
[?] “Remove Student” appears and is disabled
[?] “Login” appears and is disabled
[?] The layout arranges the header, content and footer sections vertically
[?] All colours and fonts are correct
[?] The spacing and padding look like the screenshots
Click “Add Student”
[?] The “Add Student” window is shown
[?] The “Add new student” heading is shown
[?] The student number label and text field are shown
[?] The student name label and text field are shown
[?] The attendance label, “Full Time” radio button and “Part Time” radio button are shown [?] The scholarship label and checkbox are shown
[?] The “Cancel” button is shown and enabled
[?] The “Add” button is shown and disabled
[?] The layout arranges the header, content and footer sections vertically
[?] The form is laid out in a GridPane
[?] All colours and fonts are correct including the error message
[?] The error message is included in the GridPane, centred horizontally spanning 2 columns [?] The spacing and padding look like the screenshots
Click “Cancel”
[?] The “Add Student” window is closed
This file tells you how to test the functionality of your application. Here is how it works:
􏰐 Each line without a [?] is an action you need to perform on your application.
􏰐 Each line with a [?] is verification point that you must check. You must replace the [?] by either a
[y] (for yes) or a [n] (for no) to record whether or not your application behaves correctly in that respect.
For example, you should first launch the application, and then you should then check that the UTS Logo is sho􏰊n, the 􏰆Timetable S􏰈stem􏰉 heading is sho􏰊n, and so on. If 􏰈o􏰄r application does not displa􏰈 the logo, b􏰄t does displa􏰈 the heading 􏰆Timetable S􏰈stem􏰉, then you should fill in that part of the progress.txt file as follows:
Launch the application
[n] The UTS Logo is shown
[y] The “Timetable System” heading is shown
If a verification point lists multiple things to check, they must all be true for you to give a [y] answer. For example:
[?] “Add Student” appears and is enabled
This 􏰇erification point can onl􏰈 be ans􏰊ered [􏰈] if BOTH the 􏰆Add St􏰄dent􏰉 b􏰄tton appears AND it is enabled. Before your final submission, you should recheck every answer you gave, to ensure that your answers are accurate.
There are 85 verification points like this to fill in. Each [y] answer contributes a potential 1 mark to your total, which makes up a maximum of 85 marks out of 100. The mark reported by PLATE when you submit is the provisional mark for peer review, not the final mark.
You are required to submit your project (including the updated progress.txt file) to PLATE regularly. Serious penalties apply if you do not s􏰄bmit 􏰈o􏰄r progress in small increments (See 􏰆Penalty􏰉 below).
If you are not sure how to implement a certain feature, in many cases it is possible to skip that feature and come back to it later if it is nonessential to testing the following features.
For example, style and layout can be refined after you get the application working. Correct enabling and disabling of buttons can be addressed later. Radio buttons and checkboxes can be done later. In such cases where it is possible to continue testing your app after skipping a particular verification point, you are permitted to just enter [n] for that verification point and continue on with the next one.
7

15.05.2020
However, you must perform all actions mentioned in progress.txt in sequence before attempting to check any particular verification point. For example, you cannot just 􏰆La􏰄nch the application􏰉 and then skip to the last verification point shown above and answer [y] that the 􏰆Add St􏰄dent􏰉 􏰊indo􏰊 is closed. In order to be eligible to answer [y] for that verification point, you must have first also performed the action to open the 􏰆Add St􏰄dent􏰉 􏰊indo􏰊, and then also performed the action to click the 􏰆Cancel􏰉 b􏰄tton. Onl􏰈 then, if the 􏰆Add St􏰄dent􏰉 window is closed, are you eligible to answer [y] that this window was closed.
Penalty for lack of progress evidence
You must submit your progress to PLATE in increments of no larger than 25 marks. The penalty for making a submission to PLATE that is N marks higher than your previous best mark, where N > 25 is N marks. Here is an example:
Submission #1: 5 marks (OK. This is 5 marks higher than the previous best of 0) Submission #2: 18 marks (OK. This is 13 higher than the previous best of 5) Submission #3: 15 marks (OK)
S􏰄bmission #4: 42 marks (􏰆J􏰄st􏰉 OK. This is 24 higher than the pre􏰇io􏰄s best of 18) Submission #5: 85 marks ( Penalty of 43 . This jump is 43 marks higher than 42)
To avoid a penalty, submit your progress in smaller increments. That is, you should not introduce more than 25 new [y] answers in your progress.txt file in a single submission.
Marking
Your solution is to be submitted to PLATE at https://plate.it.uts.edu.au/ under Applications Programming / Assessments / Assignment 2. Your assignment should be submitted as a JAR file that includes:
􏰐 All Java source files required to compile your assignment.
􏰐 All FXML, CSS and image files required to run your assignment.
􏰐 The progress.txt file at the top level of your project directory structure.
A provisional mark of up to 85 marks is generated immediately from your progress.txt file each time you submit to PLATE.
In your scheduled week 12 lab class, you will be assigned two other students to peer mark based on your reference mark, and two other students will be assigned to peer mark you. The purpose of this peer marking is to mark the functionality of your application which cannot be tested by PLATE. Your marks for functionality will be based on these peer marks after they are moderated by the subject coordinator. Aside from marks for the functionality, the subject coordinator will also mark your code to ensure that all code requirements have been met. If the code requirements have not been met (for example, the observer pattern not used, marks will be deducted for those components). Your final mark will be a combination of marks for functionality and marks for code (See 􏰆Marking scheme􏰉). Note that 􏰈o􏰄 can onl􏰈 be marked for feat􏰄res that can be demonstrated to work.
There is no scheduled late submission period. An extension of up to one day may be given by the subject coordinator before the d􏰄e date; 􏰈o􏰄 ha􏰇e to s􏰄ppl􏰈 doc􏰄mentar􏰈 evidence of your claim. An extension CANNOT be given after the due date. You may also apply for special consideration for reasons including unexpected health, family or work problems. More information about how to apply for special consideration can be found at http://www.sau.uts.edu.au/assessment/consideration.html .
Your presence is required at this class. Any student who is not present without being granted prior permission may have up to 50% of their marks for this assignment deducted.
Marking the code and analyzing spoofing, cheating and plagiarism is done in the two weeks following the due date. If you are suspected of Academic Misconduct, I will forward your case to the Misconduct Committee and will notify you by email. Your mark will be finalized within 2 weeks of the due date.
Marking Scheme
The marks for the assignment are divided into the following functionality components (detailed description is available in PLATE):
8

15.05.2020
Task
Mark
Show main window on launch
6%
Add a student
19%
Login
16%
Enrol
21%
Withdraw
4%
Remove a student
5%
Layout
7%
Style
7%
MVC architecture and FXML
5%
Correct package structure
1%
JavaFX observable properties and lists
4%
Attendance mode stored as ft/pt
2%
Correct use of exceptions
3%
This adds to a mark out of 100 and makes up 30% of your final assessment mark.
9