[SOLVED] Cab201 assignment2

User Stories

 

User Interface

The Arriba Eats company has plans to eventually develop a graphical user interface for this application; however, the prototype implementation will have a simple text-based interface. To make it easier to switch to a graphical user interface in the future, we want to ensure the user interface code is kept separate from the application logic.

The detailed specification for this application’s user interface is available here: CAB201 OO Assignment – Interface Specification

 

Database

The Arriba Eats company plans to eventually use a relational database to store and save all customer data. However, for this prototype, all data will be kept in memory (and will therefore be lost when the application is shut down).

 

Recommended Approach

You are encouraged to design and develop the application using an iterative and incremental approach — implementing one user story at a time. You can implement the user stories in any order you choose; however, for each new user story, you should design and implement only the classes and methods required to implement that user story.

The following points need to be emphasised.

When producing your solution, you may need to first refactor some of the classes and methods that you have already implemented for earlier user stories to better facilitate the new user story. After each user story, you should have working code that achieves all of the user stories considered so far.

If your submitted code does not compile, then you will receive 0 marks for functionality.

 

Restrictions

The following restrictions will apply to your input.

 

In addition to the above, the following restrictions will apply:

 

Test Cases

Assignment 2 – Inputs and Outputs.zipDownload Assignment 2 – Inputs and Outputs.zip

We have provided a set of input and output text files that you can use to develop your assignment. These files are exact duplicates of the Gradescope test cases.  The input files capture your typed input, such as menu responses and names. The output files record the results that would typically be displayed on the screen.

This will enable you to test each case individually, rather than going through Gradescope every time. However, one you have implemented each test successfully, we recommend resubmitting to Gradescope to make sure that your submission does not introduce errors to cases that you have previously passed.

There are two ways you can use these files.

executable < directory/inputfile

or if you are using Powershell use:

Get-Content directory/inputfile | executable

Where:

On Windows using Visual Studio 2022, follow these steps:

C:cd “C:CAB201ArribaEatsbinDebug
et8.0”
C:CAB201ArribaEatsbinDebug
et8.0>

C:cab201ArribaEatsbinDebug
et8.0>ArribaEats < “Inputs1. Startup Menu.txt”
Welcome to Arriba Eats!
Please make a choice from the menu below:
1: Login as a registered user
2: Register as a new user
3: Exit
Please enter a choice between 1 and 3:
Thank you for using Arriba Eats!

C:cab201ArribaEatsbinDebug
et8.0>

Your screen will display the output. You can compare this output with the corresponding Gradescope output either by manually inspecting the corresponding file in the RefOutputs folder, or by redirecting the output of your program into a file and then using the fc command:

C:cab201ArribaEatsbinDebug
et8.0>ArribaEats < “Inputs1. Startup Menu.txt” > MyOutput.txt

C:cab201ArribaEatsbinDebug
et8.0>fc “RefOutputs1. Startup Menu.txt” MyOutput.txt
Comparing files REFOUTPUTS1. Startup Menu.txt and MYOUTPUT.TXT
FC: no differences encountered

Remember, anytime you enter invalid input, the program will loop until valid data is provided. This could potentially lead to an infinite loop if your implementation handles errors incorrectly.

Test Cases Code Quality

While it is possible to write poor quality code that passes all of the autograder tests, it is also important to write high-quality code. Below is a non-exhaustive list of how each test can help improve your code quality. Please note that this list will help you write better code, but you will still need to apply other code quality techniques discussed during the semester to achieve a high mark (e.g. object-oriented class design, visibility, SOLID design) .

 

 

Code Smells

Code smells are issues that indicate poor code quality. While the code may be functional and pass Gradescope tests, you may be marked down when your code quality is assessed. Note that the list is diverse: some smells can be fixed after your first attempt at writing code, but others should be avoided from the start. Some are simple issues, while others are more serious. Refactoring is a good way of addressing them (https://refactoring.guru/refactoringLinks to an external site., https://refactoring.com/Links to an external site.).

Gradescope Smells

 

Marking Criteria

There are of 50 marks available for this assessment item. Your submission will be marked with a mix of automated and manual processes.

Autograder: 20 marks

When you submit your code to Gradescope, it will be automatically run against a battery of test cases, checking many different combinations of customers, restaurants, restaurant items, delivery drivers and orders, testing different paths through your program. These have been designed to vary in complexity, ensuring that you can pass some test cases even with a very early implementation. For this reason, it is recommended that you submit to Gradescope early and often, to ensure that your code is successfully compiling and running on our grading platform.

Each test case has the same structure, where you will be presented with a menu and you have to enter input to navigate it.

There are also a handful of test cases that purposefully provide invalid input. Your program will receive full marks for that test case if it behaves correctly in that situation, and no marks otherwise.

It is important that your program produces the same expected output as Gradescope. Variations in the output formatting (i.e. the messages your program prints out) may cause Gradescope to misinterpret your input and cause you to fail test cases that you would have otherwise passed.

Make sure you use Console.ReadLine() for reading all text – other Console functions for reading keys may not work with Gradescope, even though they might seem to be fine when run on your machine. Every input is on a line by itself and terminated by pressing the enter key, and that goes for selecting options from the menu as well as text and numeric inputs.

One last note: While we do not vary the test cases from run to run, if we discover during manual inspection of your program that you have hard-coded in our test cases and results (that is, instead of implementing the restaurant ordering and delivery logic, you have built your program to specifically recognise our test cases and produce the output we expect) you will receive a score of 0 for functionality, and likely a poor score from the object-oriented design and implementation, since it will not be considered useful work.

 

Abstraction: 7 marks

Your use of abstraction is marked by analysing your source code. Under this criterion, the following will be penalised:

In general, we are looking for anything other than code clarity and your OOP design (as those are marked in their own criteria) that makes your code more difficult to maintain.

 

Object-oriented design and implementation: 10 marks

Your object-oriented design and implementation will be checked by looking at your class inheritance hierarchy and examining source code to check your use of polymorphism and encapsulation, as well as the private/protected/internal/public state of your methods, fields and properties.

 

Coupling and cohesion: 8 marks

Your coupling and cohesion will be checked by examining class interdependencies and looking at the methods/fields/properties present in each class.

As a refresher, coupling is something you are trying to minimise (it means unhealthy dependencies between classes that make your code less reusable), while cohesion is something you are trying to maximise (it means each class is responsible for a single unified task and all methods/fields/properties support that task).

 

Code clarity and comments: 5 marks

Code clarity is marked by looking at how your choice of identifiers (names of classes, methods, properties, fields, local variables) and your program’s flow (use of loops / branching) affects the comprehensibility and maintainability of your code. For comments, we are looking for two different kinds: top-level XML tag comments (///) and body-level comments (usually single-line // comments).