[SOLVED] Cab201 assignment 2- user stories

1. As a user (customer, deliverer, or client), I would like to register with the application using my name, age, email address, mobile number, and password so that my records are kept private and secure.
2. As a user, I want to authenticate myself using my email and password so I can access my private records and conduct transactions securely.
3. As a user, I would like to be able to see my registered details (my name, age, email address and mobile number)
4. As a user, I want to be able to log out from the app so that the next person cannot use my account.
5. As a customer, I would like to register with my X/Y location so that my food can be delivered to me.
6. As a deliverer, I would like to register with my licence plate number so that customers and clients know who I am. (All vehicles have licence plates in this scenario, including bicycles.) 7. As a client, I would like to register my restaurant with its name, its style (Italian, French, Chinese, Japanese, American, Australian), and X/Y location so that customers can order food from my restaurant.
8. As a client, I would like to be able to see the restaurant name, style and location that I registered it so that I can ensure these details are correct.
9. As a client, I would like to add items to my menu by including their name and price so that customers will be able to order specific items.
10. As a customer, I would like to see each restaurant’s name, X/Y location, distance, style, and average rating so that I can order food from them.
11. As a customer, I would like to be able to see the available restaurants sorted by my choice of name (alphabetically), distance, style or average rating so I can find the type of restaurant I’m looking for.
12. As a customer, I would like to see the menu from each restaurant so I can decide which one to order from.
13. As a customer, I would like to see details about each restaurant so that I can choose one.
14. As a customer, I would like to see the menu items from my selected restaurant so I can choose which item to order.
15. As a customer, I would like to order items from the menu and specify the quantity of those items so I can get some food.
17. As a customer, I would like to be able to see the location I registered with, as well as how many orders I have made and keep track of how much of my money I’ve spent getting food delivered.
18. As a client, I would like to see all the orders from my restaurant so that I know what items to cook.
19. As a client, I would like to change the status of an order from “ordered” to “cooking” to indicate that I have started cooking the meal.
20. As a client, I would like to change the status of an order from “cooking” to “cooked” to indicate that I have finished cooking the meal.
21. As a deliverer, I would like to see a list of orders that are available to pick up, and to be able to select one of them to claim the order and prevent any other deliverer from taking it.
22. As a deliverer, I would like to see the total distance from myself to the restaurant and to the customer to determine how far I need to travel when choosing which order to take.
23. As a deliverer, I want to be able to see which order I’m currently delivering, the restaurant (and its location) I am picking it up from and the customer (and their location) I am delivering it to, in case I forget.
24. As a deliverer, I would like to set my status as “at the restaurant” once I have arrived so I can pick up the order.
26. As a client, I would like to change the status of an order from “cooked” to “being delivered” once the driver has left the restaurant so the customer is informed.
27. As a customer, I would like to see the current status of my order so I can be assured that my order is being handled professionally.
28. As a customer, I would like to see the licence plate number of the deliverer so I know they are the correct person.
29. As a deliverer, I would like to change the status of an order from “being delivered” to “delivered” once I have arrived at the customer’s house.
30. As a customer, I would like to rate the restaurant with a short comment and a star rating (between 1 and 5 stars) to inform others about my customer experience.
31. As a client, I would like the order to be removed from my order list once it has been delivered so that I can focus on other orders.

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.
1. In general, the user stories are designed to become more complex as you progress down the list. However, some user stores relay on others to be implemented
2. When registering a user, only the customer’s input for the shared data (name, age, email address, mobile number, and password) will be tested. It is recommended that you start by registering a customer rather than the other types of users. The other user type specific data will be tested when the other types are registered.
3. You have to submit your code to Gradescope. So, you have to make sure that your output matches Gradescope’s output perfectly. There is also, a video on Canvas that provide an example of the application and demonstrates how to achieve some of the user stories.
4. The interaction is menu based that ultimately uses the standard input and output statements. As you progress you do have to implement every menu option, only to display those options to the screen. This will allow you to ‘fast track’ throughout your testing.

Restrictions

The following restrictions will apply to your input.
Input Restriction Example of Valid Input
Name Must consist of at least one letter and only letters, spaces, apostrophes and hyphens. Tommy Galvin
Age An integer value between 18 -100 inclusive. 20
Mobile Must consist of only numbers, be exactly 10 characters long, and have a leading zero. 0123456789
Email Must include exactly one @ character and have at least one other character on either side. [email protected]
Password Must be at least 8 characters long and contain at least 1 number, lowercase letter and uppercase letter HelloWorld12
Food Style Italian, French, Chinese, Japanese, American or Australian. Note, this will be entered via a menu option so you will need to enter a numeric value between 1 -6 inclusive. 3 (which is Chinese)
Restaurant Name Must consist of at least one non-whitespace character Alan’s Bar & Grill
Location Must be of the format X,Y where X and Y are both integer values 3,4
Item Price Must be between $0.00 and $999.99 $12.50

In addition to the above, the following restrictions will apply:
1. Every user must be registered before performing any other actions.
2. Each email address must be unique.

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.
• You can open up the contents of one of the ‘Inputs’ files in a text editor, copy the contents of the file and then paste it into your program. You can then scroll up and read the output of the program, comparing it with the respective ‘RefOutputs’ file to see when errors crop up.
• You can also supply your inputs to your assignment’s executable using input redirection. This will also allow you to redirect the output for easier comparisons (e.g. using a tool like WinMergeLinks to an external site.). You can use redirection with the less-than symbol (<) following this template:
executable < directory/inputfile
or if you are using Powershell use:
Get-Content directory/inputfile | executable
Where:
• Directory is the folder containing your executable.
• Inputfile is the input file name.
1. Click the magnifying glass icon in Windows and type ‘Command Prompt.’ Then, click on the Command Prompt application.

C:cd “C:CAB201ArribaEatsbinDebug
et8.0”
C:CAB201ArribaEatsbinDebug
et8.0>
2. To execute the program using an input file, use executable < inputfile. For example, if your executable is named ArribaEats, you would run ArribaEats < “Inputs1. Startup Menu.txt” to execute the first case study.
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

Number Description
01 Startup Menu
02 Register Customer
03 Register Customer – Invalid Name
04 Register Customer – Invalid Age
05 Register Customer – Invalid Email
06 Register Customer – Invalid Mobile Number
07 Register Customer – Invalid Password
08 Register Customer – Invalid Location
09 Register Customer – Email Already In Use
10 Login as Customer
11 Login as Customer – Wrong Email or Password
12 Display User Information – Customer
13 Login as Customer, try each option
14 Display User Information – Multiple Customers
15 Register Deliverer and Login
16 Register Deliverer – Invalid Plate
17 Display User Information – Deliverer
18 Register Client and Login
19 Register Client – Invalid Restaurant Name
20 Display User Information – Client
21 Add item to menu
22 Add item to menu – Invalid Price

Code Smells

23 Place order
24 Display User Information – after placing order
25 Place order – Multiple Customers
26 Place order – multiple instances of same item in order
27 Multiple menu items
28 Accept delivery job
29 Display User Information – after accepting job
30 See orders and cook order
32 Deliver order
33 Write review
34 Display User Information – after placing multiple orders
35 Multiple orders, deliverers and reviews
36 Multiple customers, reviews
37 Multiple restaurants, ordered alphabetically
38 Multiple restaurants, ordered by distance
39 Multiple restaurants, ordered by style
40 Multiple restaurants, ordered by average rating
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.).
• Inappropriate identifiers.
• Fields not segmented into classes correctly.
• Too many fields clumped together (an indication that they should form a separate class).
• Overusing basic types instead of objects.
• Not using types correctly (e.g. Enums, Booleans, etc.).
• Not using constants correctly.
• Using a constant or literal for the length of a collection rather than calling the length method.
• Methods not segmented into classes correctly.
• Duplicate code (which probably should be moved into a method).
• Inappropriate visibility for fields, methods, or properties.
• Inappropriate use of getters and setters.
• Methods directly interact with data in other classes.
• A small change requires changes in many places.
• Excessive use of switch/if statements instead of using inheritance or polymorphism.
• A “God” object that does too much and has responsibilities that should belong to other classes.
• Inappropriate global fields or classes (usually via the keyword static).
• Too many responsibilities in a class.
• Too many responsibilities in an interface.
• Structs used inappropriately instead of classes (i.e. classes without methods).
• Too few responsibilities in classes.
• Use of magic numbers or values.
• Methods not segmented correctly within a class (e.g. one large method instead of several smaller ones).
• Code repetition.
• Errors in input handling are not placed inside a loop but instead handled with a “backup” statement (i.e. if it fails the first time, it gets the correct input the second time but does not handle multiple incorrect inputs).
• Incorrect use of static fields in an interface that is then implemented by a class (these should be placed in a parent class instead).
• Inappropriate use of an abstract class.
• Interfaces are not used correctly.
• Subclasses are not used correctly.
• Data classes directly interact with the user interface (which they shouldn’t).
• Managing a collection of objects is placed within the individual object.
• Methods are tightly coupled via control coupling, where special parameter values are used to control internal operations.
• Classes are coupled via stamp coupling, where a complex data object is passed as a parameter but only part of it is used in each class.
Gradescope Smells • Using Write instead of WriteLine can result in messy or unclear output.
• Be careful of trailing spaces when printing to the screen, as text will look the same but will be interpreted differently by Gradescope.

Marking Criteria

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.
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.
Marking criterion
7: High Distinction
6: Distinction (15-
3: Marginal fail (8-

Your use of abstraction is marked by analysing your source code. Under this criterion, the following will be penalised:
• Overly long or complex methods that should be broken up into simpler methods
• Repetitive coding constructs that should be a loop instead
• Sections of code or methods that are overly similar to other sections of code/methods and should be abstracted out into a common method
• Use of magic numbers in your code (these should be replaced by declaring a const field with a descriptive name containing the value)
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.
Mark Marking criterion
7: High
Distinction 7 The program contains no code that could be improved by abstracting it into an additional method, and all members are appropriately named.
6.5 The program can be improved by abstracting out at least one additional method or correcting at least one instance of an inappropriately named member.
6:
Distinction 6 The program features no repetition, and almost all members have been appropriately named, with all methods being less than 50 lines long.
5: Credit 5 The program features no repetition, most members are appropriately named, and the code is mostly broken up into appropriately sized methods, with nearly all methods being under 50 lines.
4: Pass 4 The program features no or only minor instances of repetition, most members are appropriately named, and most methods are less than 50 lines long.
3: Marginal
Fail 3 The program features several instances of repetition that could be abstracted out into methods, and most members are appropriately named.
2: Fail 2 The program features long methods with large amounts of repetition.
1: Low Fail 1 The program features only a very small number of methods.
0.5 The program features at least one method other than main().
0 Everything is in main() or too little code was submitted to evaluate the use of abstraction.

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.
7: High
Distinction 10
Features high-quality class design and interaction that are implemented extremely well, with no changes needed. Advanced object-oriented design and SOLID principles are fully followed.
9.5 Features high-quality class design and interaction
that are implemented extremely well, but with at least one change needed. Advanced object-oriented design and SOLID principles are almost fully followed.
9 Features high-quality class design and interaction that are implemented extremely well, but with a few minor changes needed. Advanced object-oriented design and SOLID principles are almost fully followed.
8.5 Features high-quality class design and interaction
that are implemented extremely well, but with some minor changes needed. Advanced object-oriented design and SOLID principles are almost always followed.
6: Distinction 8 Features a quality class design, well-structured interactions, and solid implementations. Advanced object-oriented paradigms like inheritance and polymorphism are implemented well, with only slight improvements needed. SOLID principles are almost always followed, but there is at least one significant instance of divergence.
7.5 Features a quality class design, well-structured interactions, and solid implementations. Class design and interactions are implemented well. Advanced object-oriented paradigms like inheritance and polymorphism are implemented but could be

improved. SOLID principles are almost always followed, but there is at least one significant instance of divergence.
5: Credit 7 Features a thoughtful object-oriented design with appropriate classes. More than one instance of an advanced object-oriented paradigm is implemented. Several cases of SOLID design are implemented, but there are some minor divergences.
6.5 Features a thoughtful object-oriented design with appropriate classes. At least one instance of an advanced object-oriented paradigm is implemented. Several cases of SOLID design are implemented, but there are some minor divergences.
4: Pass 6 The program is implemented using classes with appropriate division of data and methods, suitable interaction between classes, and good object-oriented design. There are multiple minor examples of mid-level object-oriented design, such as method overloading. However, it lacks advanced object-oriented design and implementation, such as inheritance and polymorphism, and it mostly diverges from SOLID principles.
5.5 The program is implemented using classes with appropriate division of data and methods, suitable interaction between classes, and fair object-oriented design. There is at least one instance of mid-level object-oriented design, such as method overloading. However, it lacks advanced object-oriented design and implementation, such as inheritance and polymorphism, and it majorly diverges from SOLID principles.
5 The program is implemented using classes with an appropriate division of data and methods, with suitable interaction between classes and some object-oriented design. However, significant improvements are needed. There are no instances of mid- to advanced object-oriented design, such as inheritance, polymorphism, and method overloading, and it majorly diverges from SOLID principles.
3: Marginal Fail 4 The program is implemented using a suitable number of classes, mostly with appropriate data, methods, and interaction, but with little use of object-oriented design or programming, and it is poorly aligned with SOLID principles.
2: Fail 3 A small number of classes exist, or there are many more classes than needed. All suitable classes contain both data and methods, but they are poorly structured.
1: Low Fail 2 A very small number of classes exist, but there is too much separation between data and methods, with many classes just acting as data containers (like structs). Alternatively, there are
many more classes than needed, leading to a very confusing structure.
1 More than one class exists. However, there are poor interactions between the classes. Too many classes act as data containers (like structs), with methods implemented in only one class. Additionally, there are too many static classes.
0 No object-oriented design, entirely procedural code in one class, or only uses global variables. Alternatively, too little code was submitted to evaluate the appropriateness of the design.

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).
7: High Distinction 8 Coupling is minimal, and cohesion is maximal, with no code changes required.
7 The classes are highly cohesive, but there are some minor cases of negative coupling.
6: Distinction 6 Classes are highly cohesive, and the worst types of coupling (content, common, temporal) are avoided.
5: Credit 5 Classes are highly cohesive, but some forms of harmful coupling are present.
4: Pass 4.5 Classes are highly cohesive, with responsibility solely contained within each appropriate class.
4 Classes are mostly cohesive, but some responsibilities are creeping into other classes.
3: Marginal fail 3 Classes are fairly cohesive, but some responsibilities are mixed.
2.5 Data is placed in appropriate classes, and some of the related responsibilities are implemented in the correct class along with the data.
2: Fail 2 Classes have poor cohesion, and responsibilities are mixed.
1.5 Data is placed in appropriate classes, but most functionality is
implemented in a small number of central classes that manipulate the state of instances of other classes.
1: Low Fail 1 Almost all functionality is placed in a central class that manipulates the state of instances of other classes.
0 The program is not divided into multiple classes or too little code was submitted to evaluate the quality of the design.

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).
7: High
Distinction 5 All public classes, methods, and properties feature C# XML documentation comments at the top level, explicitly defining the code’s external interface.
Appropriate comments are used to explain complex code.
6:
Distinction 4.25 Almost all public classes, methods, and properties feature C# XML documentation comments at the top level, explicitly defining the code’s external interface, and appropriate comments are almost always used to explain complex code.
5: Credit 3.75 Most public classes, methods, and properties feature C# XML documentation comments at the top level, explicitly defining the code’s external interface, and appropriate comments are used most of the time to explain complex code.
4: Pass 2.5 Most public classes, methods, and properties feature C# XML documentation comments at the top level, explicitly defining the code’s external interface, and appropriate comments are frequently used to explain complex code.
3: Marginal
Fail 2 Useful comments are sparse, or comments are far too frequent to the point that they interfere with reading the code, or identifiers are poorly chosen, or the program flow is confusing.
2: Fail 1 There are only a minimal number of useful comments throughout the code.
1: Low Fail 0 No useful comments are present, or too little code was submitted to evaluate the quality of the comments.