Primary Heading Goes Here

· Monthly charge is centred and the word discounted only appears if a discount has been applied.

· If discount is not applied, the word None should be displayed instead of the percentage value.

· The border should be included with the summary.

A console application (no GUIs or GUI dialogs) is required. Your prototype should display a menu similar to the following:

1. Enter new Contract

2. Display Summary of Contracts

3. Display Summary of Contracts for Selected Month

4. Find and display Contract

5. Modify existing Contract

Once an option is selected and processed, the menu should be redisplayed until the exit option is selected. Each operation is described below:

· Option 1: Enter new Contract

· Ask the user for the inputs: client name, package, data bundle, reference, period and include international calls. Alternatively, the estimated minutes and data (megabytes) can be entered and the program automatically selects the appropriate package and data bundle. Note: All inputs should be validated.

· Calculate the total and discounted prices for the contract.

· Display the summary (it must use the format in the example).

· Create the appropriate sub class object

· Save (append) the data for the contract to the text-based summary file (contracts.txt). Each line in the file must hold the details for a single contract with the following information separated by spaces or tabs:

· Contract Date (today’s date - see technical details for format).

· Period in Months

· Option 2: Summary of Contracts

User is asked to select the main (contracts.txt) or archive (archive.txt) contacts and a summary of the following is displayed:

· Total number of contracts.

· Number of contracts with High or Unlimited Data Bundles.

· Average charge of large package contracts.

· Total number of contracts per month (assume the files only include data for the current year). Show an entry for all twelve months even those that have an entry of zero.

A sample archive file can be downloaded from Blackboard. For the supplied archive file, the output should look similar to the following:

Contracts with High or Unlimited Data Bundles: 300 Average charge for large packages: 12.7

Number of contracts per Month:

See additional notes below about the archive file.

· Option 3: Summary of Contracts for a Selected Month

The user is asked to select the main or archive contracts and to enter a month. A summary of contracts (as specified in option 2) should then be displayed for the specified month.

Secondary Heading 2

See additional notes below about the archive file.

· Option 4: Find and Display Contract

The user is asked to select the main or archive contracts and enter the search text. The selected file should be searched for any matches (full or partial) against the reference or client name. For example entering DE would match against reference number “DE123N” and Client Name “C Sanderson”.

For each matching entry, the contract summary (see option 1) should be displayed.

See additional notes below about the archive file.

· Option 5: Modify existing contract

The main contracts file should be searched for any matches (full or partial) against the reference or client name. For example entering DE would match against reference number “DE123N” and Client Name “C Sanderson”.

· For multiple matches the user must then select one contract from the selection.

· Apart from the reference number, any of the contract’s details can be changed if the contract has been running for at least 50% of its original period. Only contracts longer than 6 months can be changed, except for charity contracts.

· One the change has been confirmed, and the details saved back to the main contracts file successfully, a notification is sent to both the customer and the finance department.

o You don’t need to do anything else, only simulate that they’ve been notified of the change.

Display an appropriate message and exit the application.

Notes about archived data file

All the archived data is taken from an older system. The way the data is stored is slightly different:

1. Reference numbers are in the format AA-123 (two letters, a dash, and 3 digits).

2. There is an additional field for the contract type, which is one of the following:

a. BUSINESS

b. CHARITY

c. NORMAL

3. Price is stored as decimal

4. When accessing the archived data file the data is to be treated as if they are in the new format, although the archive data file always in the old format

Additional features/enhancements

Once the basic requirements have been met, students wishing to achieve higher marks can implement appropriate addition features and functionality. This can include a Graphical User Interface (GUI) using Swing.

Test Requirements

As well as developing the prototype, the client requires a test plan for the application that demonstrates how each feature will be tested to ensure that it performs as expected.

For maximum marks you should provide Unit tests for the application, otherwise use the test plan detailed below.

Secondary Heading 3

Unit-tests: Provide unit tests for the two classes you’ve designed and developed with unit- tests. All tests should pass. Tests that do not pass should be documented with reasonable consideration given to what is causing the tests to fail.

The test plan should use the following format:

Once the test plan has been completed, use it to check your design and application. If any of the tests fail, update your application and re-test (keep the original entry that failed in the plan along with the new entry for the re-test).

Technical Information

1. Name your project ContractManager.

2. Data files must be named contracts.txt and archive.txt. A sample of the archive file can be downloaded from the Assessment section of the blackboard module

3. The implementation must include a Contract class that represents a single contract. This class should use appropriate encapsulation and not include any keyboard input or console output.

4. The following method will get today’s date:

You will need to import java.util.Calendar and java.text.SimpleDateFormat;

5. The prototype must be developed in NetBeans 8.2.

Tasks and Marking Criteria Implementation [45 marks]

Your implementation will be assessed on the following:

1. Its completeness to satisfy the requirements of the brief as described.

2. It performs well and in a consistent way.

3. The code is written to a good standard, elegantly specified, making it easy to read and understand by someone who did not write the original code.

4. Where additional comments are provided, they are not to a superfluous level of detail and add value to reader.

5. The code is demonstrably easy to extend and maintain.

Testing [15 marks]

1. Test Plan [5 marks]

You have provided a suitable test plan that is used to check that the functionality of the application works as expected.

2. Unit-tests [5 marks]

You have provided unit-tests for at least 2 of the classes that you’ve implemented.

Portfolio documentation [40 marks]

You write 6 portfolio entries; the format of the portfolio is described below.

Portfolio entry 1 [10 marks]

Discussion of the overall problem scenario, the initial steps taken, and identification of the basic data types that you needed. Portfolio entries 2 to 6 [6 marks each]

Will discuss the implementation of each menu option (not including option 0 to exit).

Portfolio format

· The following sections will be included:

o Tools & techniques

This section should describe important tools & techniques you have used for this portfolio entry, including:

§ important features from the API

§ New types of events, collections, control structures

§ OO collaborations & patterns

o Results

Describe your observations, for example:

§ How does the program perform?

§ Does the program/options work as expected?

§ Which parts have been successfully implemented and those parts which have not been fully successful.

§ A description of any known errors.

o Critique

§ What choices were made

§ Trade-offs/compromises made 

§ What is well presented

§ What can be improved

 General Notes/Advice

· DESIGN your solution using pseudo code or flow charts. Resist the urge to start hacking away immediately.

· Save frequently and backup your work every day.

· Work methodically and proceed using small steps.

· Work individually. Your code will be checked for plagiarism.

· You are strongly advised to retain all versions of your code and your development notes, so that you can show the development of your work. This may be required as evidence in the event of any query about the authorship of your work.

Your assessment work must be submitted electronically as a single zip file to the module support site on Blackboard. The zip file must contain the code, data files, test plan and report and be named K1234567-ICA (where K1234567 is your user id).

Further instruction on uploading your work will be provided closer to the submission date