please check my assignment and give me a quote, its due in a week.thanks
ITECH2100 / ITECH6100 Assignment 1:
Flight Management System
Due date: Sunday evening at end of Week 7, by 11:59 PM
Cut-off: 1 week (168 hours) after the due date. The cut-off date is the date after which no submission will be accepted without an approved extension having been granted to you. This is because feedback and sample solutions may be released from this date.
Assessment Value: 20% of final course result.
The work you submit must be your own individual work. Your work may be submitted by staff to an online code-plagiarism checking software service to compare your work to other students’ work.
Objectives
The purpose of this assignment is to assess your progress towards attainment of a selection of the learning objectives of weeks 1 through 5.
On successful completion of this assignment you should have demonstrated that you are able to:
• Write a program that provides the requested functionality.
• Use suitable relational expressions to selectively run different parts of code.
• Apply the principles of encapsulation and information hiding to ensure that classes have appropriate attributes and appropriate methods to access and manipulate the attributes and to ensure object state is always sensible and enforced.
• Write methods that accept parameters and which return values as a result of their execution.
• Choose the most appropriate scope for identifiers.
• Write code to implement simple association and/or composition relationships and write a program consisting of multiple objects which interact with each other.
• Distribute responsibilities appropriately across classes by applying a range of quality design practices.
• Write a text menu-based interactive driver to provide the user an appropriate way to control program operation at runtime.
• Declare, instantiate and use ArrayList objects and/or arrays.
• Implement a data management façade class including provision of a facility to search against criteria.
• Draw a class diagram showing the relationships between classes
The assignment may cause you to demonstrate that you have attained other learning objectives; the above list is not necessarily exhaustive. However, we are not expecting you to demonstrate attainment of learning objectives from week 6 onwards. The above items essentially form the criteria against which you will be assessed.
Overview of Assignment
This assignment requires you to write an application that meets a list of provided functional and design requirements, utilising the concepts and techniques taught in this course. You will choose your own classes to code, that will create a text-menu based program.
You will be required to develop your application using Java (preferably in the Eclipse IDE). You will need to add all your work to a zip file when you are finished and submit it on Moodle by the due date. You will also need to submit a short report which will require some written information describing your system as well as addressing design and testing requirements which will be outlined
below. Please write this supporting documentation clearly and IN YOUR OWN WORDS (plagiarism is NOT acceptable – refer to Course Description).
Before you begin, read over this entire assignment and understand all the tasks.
All code must conform to stylistic standards including proper commenting, appropriate choice of identifier names, proper indenting and other readability issues. Otherwise, marks may be deducted. Consult http://www.oracle.com/technetwork/java/codeconventions-150003.pdf
Context/Background Information (CI)
For this assignment, you will create a program for an airline to allow it to manage details about flights and passengers.
The airline operates a range of flights between cities each day of the week.
In the days and hours leading up to departure, and even after departure, several things need to be updated within the system.
Firstly, the airline must create a new flight in the system, so that passengers can be assigned to seats on the flight. Closer to the departure it may be necessary for someone to cancel their booking.
Secondly, the meals to be served on the flight need to be organised.
Thirdly, as passengers arrive at the airport, they may need to check-in some luggage. Also, as they go through the gate, they need to be recorded as being on the plane.
When the plane actually departs, this significant occurrence needs to be notified to the destination airport; and when it arrives at the destination, this also needs to be recorded.
The following sections describe the required functionality and other details of the system you need to develop.
Required behaviour of the final system
This section outlines the functionality required to be provided by the program that you write for the assignment. Keep in mind that you need to address the criteria against which the work will be judged (the assessment criteria), when you implement the following behaviour (described as functional requirements or FRs) of the system.
FR-1: User interaction and control of main program
The program must provide a means by which the user can direct the program to do things. This should be in the form of a textual menu-based system for input and for output. It should provide the ability for the user to do the following:
• Change the current ‘day’ of the system (see FR-2)
• Create a new flight for some day in the future (see FR-3)
• Add a new passenger to a flight (see FR-4)
• Check-in a passenger for a flight (see FR-5)
• Note a passengers as boarding (see FR-6)
• Note plane as now departed (see FR-7)
• Note plane as now landed (see FR-8)
• Report about a flight (see FR-9)
FR-2: Time within the system
The program is intended to work in place over many days. However, due to the impracticality of testing it by waiting for hours and days to pass, you will need to simulate the changing of days. To do this, when the program starts you can make some assumptions:
1. The first day for which any flights can happen, will be Monday.
2. Assume that when the program begins, it is the day before Monday
The user must select a menu option to cause the system to update the “current” day to be the next day. At the same time, (i.e. after updating) it should display a list of all the flights scheduled to depart on that (new) day.
FR-3: Ability to store basic information about a flight in memory
The following information, at minimum, needs to be recorded at instantiation time for each flight about which the system knows and which the user can specify for generate reports or performing queries:
• The name of the origin city
• The name of the destination city
• The day of the week when the flight will be
• The hour and minute when the flight is due to depart.
• The code of the flight, usually a few letters and then numbers, e.g. QF625 might be the 4:05pm flight from Melbourne to Perth.
Additional information may need to be recorded as explained in other FRs. You also need to consider issues regarding the state of the object.
FR-4: Ability to add a passenger to a flight
For simplicity, assume that each flight can carry at most 20 passengers.
You MUST use a plain array to store the flight’s passengers.
The system should ask the user to specify which flight the passenger will be added to. This will require first asking the user to select a day, so that the flights of that day may be shortlisted for selecting from. Once a flight is selected, if there are available seats, then the details of a passenger should be collected, and associated with that flight. The following details are required at the time when the booking is made:
• Name of passenger
• Age of passenger
• Do they require special dietary requirements for food: vegetarian only, halal meals only, or other special requirements; or just the standard meal.
Note however that passengers can only be added to a flight if the flight has not yet departed!
FR-5: Ability to check-in a passenger
This will only be possible on the day the flight is scheduled to depart, and only if the flight has not already departed.
The system should allow the user to choose which passenger to mark as having arrived at the origin airport, and to record the number of bags which are being checked-in to be carried as checkedluggage, and the weight of that luggage.
FR-6: Ability to note passenger as having boarded the plane
This will only be possible on the day the flight is scheduled to depart, and only if the flight has not already departed.
The system should allow the user to choose a flight (that has not already departed), and then choose which passenger to mark as having gone through the gate which leads directly to the plane (and therefore assume that they have boarded the plane). For convenience, allow the user the ability to make passenger selections one after another, without leaving from this functionality unless they choose an option that explicitly exits from it back to the main menu.
FR-7: Ability to note a plane as having departed
This will only be possible on the day the flight is scheduled to depart. The system should present the user with a list of flights scheduled to depart, that have not already departed, and allow the user to select one. That flight will be noted as having now departed, so that no further passengers could board it (e.g. if they were running late). The flight should now know who was actually on board, in addition to knowing who had booked to be on the flight but had for some reason not boarded.
FR-8: Ability to note a plane as having landed at destination
The system should present the user with a list of flights that have already departed, and allow the user to select one, which will be noted as having now arrived at the destination.
FR-9: Report about a flight
It should be possible at any time, to request a report about any flight, for either a future day, the current day, or a past day.
All flights should report the flight’s code, origin and destination.
For flights from the past, or the current day which have already departed, the report also needs to show:
• The passengers who boarded,
• what type of meal each passenger needed
• The total number of each type of meal that was needed, based on the passengers that actually boarded.
For flights that are for the current day but which have not yet departed, the report should also show:
• Which passengers have checked-in
• Which passengers have not checked-in
For flights that are currently boarding, the report should show:
• Which passengers have boarded
• Which passengers have still not boarded
• The total number of each type of meal that will be needed, based on the passengers that have checked-in
ADDITIONAL FUNCTIONAL REQUIREMENTS FOR ITECH6100 Students
ITECH2100 students can do these if they wish, but it attracts no marks. Ensure they are integrated into the main program’s menu.
FR-10: Ability to cancel a booking
For flights that have not yet departed, it should be possible for the user to select a passenger on a selected flight, and cancel their booking, i.e. the seat becomes available for someone else to book. But if the passenger has already checked-in, then they cannot cancel.
FR-11: List all flights departing from the same city.
When this menu option is selected, it should ask the user to enter the name of a city. It should then present a list of all known flights that will be departing from that city (i.e. past days’ flights are ignored). The details to list for each flight are:
• The day, and time when the flight will depart that city
• The destination city
• The flight code
• How many seats remain for booking on that flight
Additional Design Requirements – All Students
The following are additional things which must be considered by both ITECH2100 and
ITECH6100 students, and so must be addressed in your solution, in order to meet the assessment’s objectives.
ADR-1: Solution must make use of both Arrays and ArrayLists
You are expected to make use of plain arrays, as well as ArrayLists, in your program
ADR-2: Include evidence of testing
In a document created in Microsoft Word, give an explanation of some of the ways you have tested your code to confirm it works as intended. This means: writing down the inputs entered or actions to be performed, which the marker could follow to reproduce on their computer the scenarios you used on your computer to check the program is working – but just for 3 or 4 different parts of the code.
Tasks to Complete
Task-1: Plan your program
Consider the functional and additional design requirements, and determine which classes you will need to implement. In the Word document, write a short description of the role/purpose of each class that you have in your program – please sort them in alphabetic order by class name.
Draw a class diagram showing the relationship between different classes in your system. (Note: this could be drawn by hand and photographed using your mobile phone to make it digital, as long as it is legible when included in the Word document).
Task-2: Code a functioning program that addresses the behavioural and additional design requirements
Write the classes that you have determined are needed to make a functioning program. The program should be a text-menu based program, meaning that after the initial setting up of the system, it should present the user with a list of options of what action they would like to perform next, and then does the corresponding action, looping this until the user chooses to exit the program. You should aim to write code following high quality coding practices that have been taught in this course this semester – including comments and exhibiting good design where code is separated into separate methods.
Task-3: Ensure all supplementary documentation is complete.
Go through you Word document and make sure that everything required to be included, has actually been included and is complete.
Submission Requirements
All files which you wish to submit for marking must be placed into a single ZIP file (with extension of .zip, using your full name as the name of the file). Upload this file to Moodle through the assignment link labelled “Submit Major Assignment”. This link will only become available after you have completed the ‘Declaration of Originality’ form associated to it, and accept the Student’s Statement – which is instead of you needing to sign a paper cover sheet.
At minimum, the following files (if they are attempted) should be present:
• Assignment.docx – for the supplementary documentation/responses.
• All source-code files (.java) to allow your program to be compiled and run.
The work submitted must be your own work.
Guide to how the assignment will be graded
The work will be assessed both for correctness of functional behaviour, and also against the assessment criteria (derived directly from the objectives that are listed on page 1 as bullet points).
The assessment criteria will each be given a rating on the following scale: Excellent, Good, Satisfactory, Poor (i.e. attempted, but not to satisfactory level), Not Demonstrated.
In general, to achieve a high distinction, your submitted work must:
• Have correctly implemented all functionality required
• You must achieve ‘excellent’ rating for all except one assessment criteria that can be rated as ‘good’
To achieve a pass, your submitted work must:
• Have attempted all the functional requirements FR-1 through FR-10
• You must achieve at least ‘satisfactory’ rating for most of the first 7 assessment criteria.
To receive distinction you cannot have more than one thing rated ‘satisfactory’.
To receive credit, you would have achieved some ratings of at least ‘Good’, but some ‘satisfactory’ (considering the first 7 criteria).
END OF ASSIGNMENT SPECIFICATION