Microsoft Word – CS6310 A3 Individual_Implementation Fall2021.docx
CS6310 – Software Architecture & Design
Assignment #3 [150 points]: Grocery Express Project – Individual Implementation (v1)
Fall Term 2021 – Instructor: Mark Moss
Submission Deliverables
• This assignment must be completed as an individual, not as part of a group.
• You must submit the following items in Canvas:
(1) A ZIP file named 2021-10-A3.zip that includes your source code. The structure of the zip file is
shown in more detail below.
(2) An updated copy of the UML Design Class Diagram from the earlier assignment reflecting
any problem requirement updates as described below, named class_diagram.pdf.
(3) A UML Sequence Diagram that captures the sequence of actions described below, named
sequence_diagram.pdf.
• You must notify us via a private post on Canvas and/or Ed Discussion BEFORE the Due Date if you
are encountering difficulty submitting your project. You will not be penalized for situations where
Canvas is encountering significant technical problems. However, you must alert us before the due
date – not well after the fact. You are responsible for submitting your answers on time in all other
cases.
• Please consider that uploading files to Canvas might occasionally take a long time, even in the
case of seemingly “relatively small” submissions. Plan accordingly, as submissions outside of the
Canvas Availability Date will likely not be accepted. You are permitted to do unlimited
submissions, so we recommend you save, upload, and submit often. You should use the same file
naming standards for the (optional) “interim submissions” that you do for the final submission.
General Intent
In the first phase of the Grocery Express Project, you were required to provide design artifacts to
describe your approach to structuring the classes, attributes, operations, methods and relationships
needed to simulate the problem. Now, you are required to provide a lightweight implementation of
the system in Java that reflects your design.
You are required to demonstrate fundamental separation of classes in your source code indicative of
a reasonable design. This means that your source code should show some indication of being
divided up into classes, files, etc. that match your design. You will lose points if you submit poorly
structured code.
And don’t panic if you realize that your original design had flaws while working on this assignment –
this is common for “agile styles” of development. Make sure that your implementation works per
these requirements and specifications and note your earlier design oversights with some brief
comments in your code. You’re also being asked to provide improved design artifacts based on your
“revised and improved understanding” of the problem space, and especially in light of the problem
requirement changes included in this document.
We provide some examples of the expected input and output for a few test cases. You must provide
the actual Java source code. We must also be able to recompile your application from your source
code as part of the evaluation process.
Problem Scenario
Your requirements for the Grocery Express Project are continued here. Any requirements from the
earlier assignments are carried over here unless explicitly modified and/or otherwise cancelled. If you
feel that there are any conflicts between any of the earlier requirements and the more recent
requirements, then please seek clarification immediately. In general, though, the newer requirements
will take precedence.
This assignment involves implementing some of the core architecture and functional capabilities for
the Grocery Express Project that you designed in the earlier assignments. Your system must
implement the following functionality:
(1) Create stores and allow them to offer items for purchase.
(2) Create drones that can be used by stores to deliver orders.
(3) Create pilots who can be hired by stores and assigned to fly the drones.
(4) Create customers who can start orders and request items on those orders.
(5) Allow orders to be eventually purchased or cancelled by customers.
(6) Display various reports of the system’s information (e.g., stores, customers, etc.) to view the
system’s state and verify that the operations are working correctly.
The instructions below will provide more details about the specific functions, including input and
output formats, that your system will need to implement. Your system does not have to provide a
Graphical User Interface. At this point, we will evaluate your system based on the text-based output
and the structure of the source code. You’ll have ample opportunity to develop a more advanced
interface during the group project.
Evaluation/Grading Your Submissions
• Your submission will be evaluated based on four main areas:
(1) 20 points for your system’s correctness: source code provided, the capability to recompile your
code, etc.
(2) 40 points for correct operation of the system on the selected scenario (test) files
(3) 50 points for reasonably structured source code
(4) 40 points for your updated Class & Sequence diagrams
Don’t lose sight of the goal for the course: there are many more potential improvements that you
could make to this system, but you really need to think about how you will separate and distribute the
complexity of the overall problem across separate classes; and, how the objects instantiated from
those classes then communicate and collaborate to solve the problem. Helping you develop a solid
structure for your design is the most important aspect of working on this assignment.
(1) 20 points for your submission correctness: the capability to recompile your code, etc.
Common issues that cause you to lose points in this category:
• The code doesn’t function properly in docker during testing – for example, JNI errors, etc.
• Gross formatting errors – we’ve designed the testing harness to be as robust as possible when
processing the submissions, but errors caused by including graphical displays of the space region,
diagnostic output, and other random messages will also cause you to lose points.
• Formatting is important! Syntax is important! Use the matching characters for the output strings,
and don’t put extra spaces between elements of the output strings. Strings that do not match the
correct output because of formatting (syntax) errors might receive significant penalties.
(2) 40 points for correct operation of the system on the selected scenario (test) files
(3) 50 points for reasonably structured source code
The main issue that will cause you to lose points in this category is submitting poorly structured,
possibly monolithic source code that doesn’t display any indication of separation of responsibilities
among classes, objects, etc. There isn’t a specific set of objects that you must have, but you do need
to display some significant effort to apply object-oriented analysis & design principles.
(4) 40 points for your updated Class & Sequence diagrams
The main issue that will cause you to lose points in this category is submitting Class & Sequence
Diagrams that are inconsistent, and/or that don’t reflect the latest changes to the problem
requirements. For your Sequence Diagram, you only need to show the interactions required to
successfully complete the following commands in your system:
• start_order
• request_item
• purchase_order
You should create enough notional objects to demonstrate the messages and related data being
shared to complete each of these operations successfully. They can be demonstrated as one
connected sequence, or as three separate sequences.
Input/Output & Command Formatting Requirements
We will test your program at this point using a relatively simple, text-based Command Line Interface
(CLI) approach. The commands that we will use are listed below and your system is expected to
follow the syntax of the commands as listed. Your program should accept input from a basic
command (Terminal) interface – please don’t use any windows, third-party text-input libraries, etc.
Welcome to the Grocery Express Delivery Service!
The following commands demonstrate a solid use case that exercises all the required functions with
some sample data. We have also provided “starter code” that highlights the required syntax for the
functions to include parameters positions and data types (all Strings or Integers).
[1] > make_store,kroger,33000
OK:change_completed
The make_store command must create a store with the provided name that can be used to sell
items to customers, along with the store’s initial revenue. The name of the store must be unique.
The “OK” message is used for commands that change the system state to acknowledge that it
completed successfully. And the [] numbers are simply being used here to identify required
functions – they are not required for the system’s output.
[2] > display_stores
name:kroger,revenue:33000
OK:display_completed
The display_stores command must display the information about the all the stores that have
been created. Note that the “OK” message here is for commands that display information about the
system state.
[3] > sell_item,kroger,pot_roast,5
OK:change_completed
> sell_item,kroger,cheesecake,4
OK:change_completed
The sell_item command must add the item provided to the “catalog” of items available to be
requested and purchased from the store. The name of the store must be valid, and the item name
must be unique within that store. The weight of the item will also be provided.
[4] > display_items,kroger
cheesecake,4
pot_roast,5
OK:display_completed
The display_items command must display the information about all the items that are available
for request/purchase at a specific store.
[5] > make_pilot,ffig8,Finneas,Fig,888-888-8888,890-12-3456,panam_10,33
OK:change_completed
The make_pilot command must create a pilot who could fly a drone later to support grocery
deliveries. The pilot must have an account (i.e., ffig8) that is unique among all pilots, along with a
first and last name, phone number, tax ID, license ID and experience level measured in terms of the
number of deliveries completed successfully. The license ID (i.e., panam_10) must also be unique
among all pilots.
[6] > display_pilots
name:Finneas_Fig,phone:888-888-8888,taxID:890-12-3456,licenseID:panam_10,
experience:33
OK:display_completed
The display_pilots command must display the information about all the pilots who’ve been
introduced in the system.
[7] > make_drone,kroger,1,40,3
OK:change_completed
The make_drone command must create a drone that can be used to deliver groceries to the
appropriate customer when an order has been purchased. The drone’s identifier (i.e., 1) must be
unique for the drones at that store. Drones will also have a weight capacity and a measure of the
number of deliveries that the drone can make before needing refueling.
[8] > display_drones,kroger
droneID:1,total_cap:40,num_orders:0,remaining_cap:40,trips_left:3
OK:display_completed
The display_drones command must display the information about all the drones that can be used
to deliver grocery orders for a specific store. Note that a drone will not include the name of the pilot
unless one has been assigned.
[9] > fly_drone,kroger,1,ffig8
OK:change_completed
The command must assign the given pilot (i.e., ffig8) to take control of the given drone (i.e., drone
1 at the store kroger). A pilot can only control one drone at a time, and a drone can only be
controlled by one pilot at a time.
> display_drones,kroger
droneID:1,total_cap:40,num_orders:0,remaining_cap:40,trips_left:3,flown_by
:Finneas_Fig
OK:display_completed
The display_drones command has already been introduced. Note that the listing now includes
the name of the pilot who was recently assigned (i.e., flown_by:Finneas_Fig).
[10] > make_customer,aapple2,Alana,Apple,222-222-2222,4,100
OK:change_completed
The make_customer command must create a customer who can start orders, request items and
eventually purchase (or cancel) those orders. The customer must have an account (i.e., aapple2) that
is unique among all customers, along with a first and last name, phone number, customer rating and
credits (i.e., money used to purchase items).
[11] > display_customers
name:Alana_Apple,phone:222-222-2222,rating:4,credit:100
OK:display_completed
The display_customers command displays all the customers who have been introduced in the
system.
[12] > start_order,kroger,purchaseA,1,aapple2
OK:change_completed
> start_order,kroger,purchaseB,1,aapple2
OK:change_completed
The start_order command must create the initial “stub” for an order at a given store for a given
customer (i.e., aapple2). The identifier (i.e., purchaseA) must be unique for all orders at that store.
Also, the drone and customer identifiers must be valid.
[13] > display_orders,kroger
orderID:purchaseA
orderID:purchaseB
OK:display_completed
The display_orders command must display information about all the orders at a given store. The
orders should also display all the items that have been requested for each order.
[14] > request_item,kroger,purchaseA,pot_roast,3,9
OK:change_completed
> request_item,kroger,purchaseB,pot_roast,4,4
OK:change_completed
The request_item command must add an item to the designated order. The quantity and unit
price (i.e., 3 and 9, respectively) will be decided at the time the command is entered. An item can
only be added to an order once. More importantly, the item must be added to the order if – and
only if – the following conditions are true: (1) the customer has enough remaining credits to afford the
new item; and, (2) the drone has enough remaining capacity to carry the new item as part of its
payload.
> display_orders,kroger
orderID:purchaseA
item_name:pot_roast,total_quantity:3,total_cost:27,total_weight:15
orderID:purchaseB
item_name:pot_roast,total_quantity:4,total_cost:16,total_weight:20
OK:display_completed
The command has already been introduced. Note that the display now includes information about
all the items listed under each order.
[15] > purchase_order,kroger,purchaseA
OK:change_completed
The command must complete the purchase of the order and the delivery of the groceries to the
appropriate customer. The purchase must be completed if – and only if – the drone delivering the
order has a pilot assigned and enough fuel to complete the delivery. There are five significant
changes to the system’s state that must be enacted to successfully complete the purchase: (1) the
cost of the order must be deducted from the customer’s credits; (2) the cost of the order must be
added to the store’s revenue; (3) the number of remaining deliveries (i.e., fuel) for the drone must be
reduced by one; (4) the pilot’s experience (i.e., number of successful deliveries) must be increased by
one; and, (5) the order must otherwise be removed from the system.
> display_customers
name:Alana_Apple,phone:222-222-2222,rating:4,credit:73
OK:display_completed
> display_stores
name:kroger,revenue:33027
OK:display_completed
> display_orders,kroger
orderID:purchaseB
item_name:pot_roast,total_quantity:4,total_cost:16,total_weight:20
OK:display_completed
> display_pilots
name:Finneas_Fig,phone:888-888-8888,taxID:890-12-3456,licenseID:panam_10,
experience:34
OK:display_completed
These commands have been displayed to demonstrate the changes to the system’s state after the
delivery of the purchaseA order. The $27 of credits for the purchaseA order have been
transferred from aapple2 to kroger, and the drone fuel and pilot experience have been updated.
[16] > cancel_order,kroger,purchaseB
OK:change_completed
The cancel_order command simply removes the order from the system without otherwise
changing the system’ state.
> display_customers
name:Alana_Apple,phone:222-222-2222,rating:4,credit:73
OK:display_completed
> display_stores
name:kroger,revenue:33027
OK:display_completed
> display_orders,kroger
OK:display_completed
> display_pilots
name:Finneas_Fig,phone:888-888-8888,taxID:890-12-
3456,licenseID:panam_10,experience:34
OK:display_completed
These commands have already been introduced and are displayed here just to confirm that the
system’s state has not been modified after the purchaseB order was cancelled.
[17] > stop
stop acknowledged
simulation terminated
This command simply causes the (otherwise infinite) interactive loop to halt.
Additional commands to create, update, delete and display elements of the system will be added
during later phases of the project.
Sample Code
We’ve included some sample Java source “starter code” that provides the command loop for
terminal-based data input. You are also welcomed to use portions of the code in your own
solution and use of the provided starter code is 100% optional: you are NOT required/obligated to
use this code. We’ve also provided some test cases, though you are also welcome (and
encouraged) to develop your own tests as well. You are permitted to share your test cases with
fellow students, but you are not permitted to share code and/or specific directions on the code or
designs need to pass the cases.
If you would like to take a closer look at the starter code, then the best way might be to create a
new Java project with blank Main and DeliveryService files, and then import the provided content.
Similarly, you can compile and experiment with the code and create a new JAR file as well. We’ve
also provided an initial copy of the JAR file that can be executed in two ways:
[1] Interactively (Enter the commands manually as highlighted):
$ java -jar drone_delivery.jar
Welcome to the Grocery Express Delivery Service!
make_store,kroger,33000
> make_store,kroger,33000
OK:change_completed
display_stores
> display_stores
name:kroger,revenue:33000
OK:display_completed
…
stop
> stop
stop acknowledged
simulation terminated
$
[2] Scripted (Recommended: Enter the commands via a text file as highlighted):
$ java -jar drone_delivery.jar < test_case_0.txt
Welcome to the Grocery Express Delivery Service!
> make_store,kroger,33000
OK:change_completed
> display_stores
name:kroger,revenue:33000
OK:display_completed
…
> stop
stop acknowledged
simulation terminated
$
Also, the test cases that we will use for this phase of the project will be fundamentally correct and
consistent and will not include any errors like duplicate references (e.g., attempting to make two
stores with the same name), invalid references (e.g., referring to non-existent stores or customers),
or other (logical) constraints with respect to the problem/scenario description.
Submission Details (Zip File)
• You must submit a single ZIP file with the following structure:
o 2021-10-A3 (folder)
§ src (folder)
• bunch of *java files (files)
• No changes to the docker file or other files will be allowed in your submission.
• Your system must complete each test case in less than three (3) seconds (real time) – otherwise,
your result will be considered to be a failure for that scenario. The scale of these scenarios
shouldn’t require more computing resources than this – in fact, many systems from the previous
term completed all of the test cases (e.g., 20+ cases) in less than three (3) seconds total. Let us
know if you feel that you are unable to develop your system to meet this requirement.
• Your program should display the output directly to “standard output” on the command line or
terminal – not to a file, special console, etc. And you are welcome to use diagnostic output when
testing and troubleshooting your program; however, you must disable or otherwise remove any
“excess output” before you submit your program. Any excess (i.e. non-required) output will
disrupt the automated evaluation of your system, and requests to re-evaluate your system on this
basis will be penalized heavily.
• On a related note, it’s highly suggested that you test your finished system on a separate machine
if possible, away from the original development environment. Unfortunately, we do receive
otherwise correct solutions that fail during our tests because of certain common errors:
o forgetting to include one or more external libraries, etc.
o having your program read files from a specific, hardcoded (and non-existent) folder
o having your program read test files embedded files in its own JAR package
• Many modern Integrated Development Environments (IDEs) such as Eclipse, IntelliJ, Android
Studio, etc. offer very straightforward features that will allow you to create a runnable JAR file
fairly easily. Also, please be aware that we will recompile your source code to verify the
functionality & evaluation of your solution compared to your submitted source code.
Closing Comments & Suggestions
This is the information that has been provided by the customer so far. We (the OMSCS 6310 Team)
will likely conduct an Office Hours where you will be permitted to ask us questions in order to clarify
the client’s intent, etc. We will answer some of the questions, but we will not necessarily answer all of
them. Also, though this current version of the system if “the core” of the system going forward, our
clients will very likely add, update, and possibly remove some of the requirements over the span of
the course. One of your main tasks will be to ensure that your architectural documents and related
artifacts remain consistent with the problem requirements – and with your system implementations –
over time.
Quick Reminder on Collaborating with Others
Please use Ed Discussion for your questions and/or comments, and post publicly whenever it is
appropriate. If your questions or comments contain information that specifically provides an answer
for some part of the assignment, then please make your post private first, and we (the OMSCS 6310
Team) will review it and decide if it is suitable to be shared with the larger class. Best of luck on to
you this assignment, and please contact us if you have questions or concerns.