CafeConnect is based on the AddressBook-Level3 project created by the SE-EDU initiative. It incorporates the following third-party libraries: JavaFX, Jackson, JUnit5.
Refer to the guide Setting up and getting started.
The Architecture Diagram given above explains the high-level design of the App.
Given below is a quick overview of main components and how they interact with each other.
Main components of the architecture
Main
(consisting of classes Main
and MainApp
) is in charge of the app launch and shut down.
The bulk of the app's work is done by the following four components:
UI
: The UI of the App.Logic
: The command executor.Model
: Holds the data of the App in memory.Storage
: Reads data from, and writes data to, the hard disk.Commons
represents a collection of classes used by multiple other components.
How the architecture components interact with each other
The Sequence Diagram below shows how the components interact with each other for the scenario where the user issues the command customerdelete 1
.
NOTE: The sequence diagram shows a simplified execution of the
DeleteCustomerCommand
.
Each of the four main components (also shown in the diagram above),
interface
with the same name as the Component.{Component Name}Manager
class (which follows the corresponding API interface
mentioned in the previous point.For example, the Logic
component defines its API in the Logic.java
interface and implements its functionality using the LogicManager.java
class which follows the Logic
interface. Other components interact with a given component through its interface rather than the concrete class (reason: to prevent outside component's being coupled to the implementation of a component), as illustrated in the (partial) class diagram below.
The sections below give more details of each component.
The API of this component is specified in Ui.java
The UI consists of several key components:
WelcomeScreen: The initial screen users see when launching the application. It provides:
MainWindow: The main application window that appears after the welcome screen. It contains:
List Panels: Each tab contains specialized panels:
StaffListPanel
: Displays staff members with their basic informationCustomerListPanel
: Shows customers with their basic detailsDrinkListPanel
: Presents the drink catalog itemsDetail Panels: Each list panel has a corresponding detail panel:
StaffDetailPanel
: Shows comprehensive staff informationCustomerDetailPanel
: Displays detailed customer informationDrinkDetailPanel
: Shows complete drink informationSupport Components:
CommandBox
: For entering commandsResultDisplay
: Shows command execution resultsStatusBarFooter
: Displays application statusHelpWindow
: Provides access to help documentationAll these components inherit from the abstract UiPart
class which captures the commonalities between classes that represent parts of the visible GUI.
The UI component uses the JavaFX UI framework. The layout of these UI parts are defined in matching .fxml
files that are in the src/main/resources/view
folder. For example, the layout of the MainWindow
is specified in MainWindow.fxml
The UI component:
Logic
componentModel
data so that the UI can be updated with the modified dataLogic
component, because the UI
relies on the Logic
to execute commandsModel
component, as it displays Customer
, Staff
, and Drink
objects residing in the Model
The HelpWindow
component is shown when you execute a help command. It contains a link to the detailed user and developer guide on this CafeConnect documentation website.
API : Logic.java
Here's a (partial) class diagram of the Logic
component:
The sequence diagram below illustrates the interactions within the Logic
component, taking execute("customerdelete 1")
API call as an example.
NOTE: The lifeline for
DeleteCustomerCommandParser
should end at the destroy marker (X) but due to a limitation of PlantUML, the lifeline continues till the end of diagram.
How the Logic
component works:
Logic
is called upon to execute a command, it is passed to an AddressBookParser
object which in turn creates a parser that matches the command (e.g., DeleteCustomerCommandParser
) and uses it to parse the command.Command
object (more precisely, an object of one of its subclasses e.g., DeleteCustomerCommand
) which is executed by the LogicManager
.Model
when it is executed (e.g. to delete a staff).Model
) to achieve.CommandResult
object which is returned back from Logic
.Here are the other classes in Logic
(omitted from the class diagram above) that are used for parsing a user command:
How the parsing works:
AddressBookParser
class creates an XYZCommandParser
(XYZ
is a placeholder for the specific command name e.g., AddCommandParser
) which uses the other classes shown above to parse the user command and create a XYZCommand
object (e.g., AddCommand
) which the AddressBookParser
returns back as a Command
object.XYZCommandParser
classes (e.g., AddCommandParser
, DeleteCustomerCommandParser
, ...) inherit from the Parser
interface so that they can be treated similarly where possible e.g, during testing.API : Model.java
The model component represents the data domain of CafeConnect and provides APIs for accessing and modifying this data.
Model Overview
The Model
component,
Person
, Staff
, Customer
, and Drink
objectsUserPrefs
classObservableList<T>
objects for UI components to bind toThe diagram above shows the main structure of the Model
component. For clarity, we'll examine each entity model in more detail below.
The Person
model:
Staff
and Customer
entitiesName
, Phone
, Email
, Address
, and Tag
sUniquePersonList
that ensures no two persons have the same identityThe Staff
model:
Person
class, inheriting all person attributesStaffId
, Role
, ShiftTiming
, HoursWorked
, and PerformanceRating
StaffId
as the primary identifier for staff members
StaffId
is used in Staff::isSamePerson
to determine staff uniquenessUniquePersonList
that enforces uniqueness based on Staff::isSamePerson
Staff
extends Person
classThe Customer
model:
Person
class, inheriting all person attributesCustomerId
, RewardPoints
, VisitCount
, FavouriteItem
, and TotalSpent
CustomerId
as the primary identifier for customers
CustomerId
is used in Customer::isSamePerson
to determine customer uniquenessUniquePersonList
that enforces uniqueness based on Customer::isSamePerson
Customer
extends Person
classThe Drink
model:
DrinkName
, Price
, and Category
description
and stock
that don't affect identityDrinkName
as the primary identifier for drinksUniqueDrinkList
that enforces uniqueness based on drink namesPrice
class:
DrinkCatalog
class that implements ReadOnlyDrinkCatalog
Each entity in the Model component follows value semantics (meaning two entities with identical fields are considered equal) and is immutable for core fields to prevent unexpected side effects.
API : Storage.java
The Storage
component,
addressbook.json
- Stores all staff and customer datadrinkcatalog.json
- Stores the drink menu datapreferences.json
- Stores user preferences like window size and positionAddressBookStorage
, UserPrefsStorage
, and DrinkCatalogStorage
, which means it can be treated as either one (if only the functionality of only one is needed).StorageManager
, which coordinates all persistence operations by delegating to specialized storage classes.JsonAdaptedPerson
serves as the base adapter for person entitiesJsonAdaptedStaff
and JsonAdaptedCustomer
extend the person adapter with specialized fieldsJsonAdaptedDrink
handles drink menu itemsModel
component (because the Storage
component's job is to save/retrieve objects that belong to the Model
).The sequence diagram below illustrates the storage operations that occur when executing a command that modifies data (such as customerdelete 1
):
When the application starts:
MainApp
initializes StorageManager
with the appropriate storage components for address book, drink catalog, and user preferences.StorageManager
attempts to load data from each storage file.When a command modifies data:
LogicManager
calls storage.saveAddressBook(model.getAddressBook())
(or the equivalent method for other data types).StorageManager
delegates to the appropriate storage component:JsonAddressBookStorage
for staff and customer dataJsonDrinkCatalogStorage
for drink menu dataJsonUserPrefsStorage
for user preferencesNOTE: If a data file is corrupted, the application will simply create a new empty data structure. Users must manage backups of their data files manually.
Classes used by multiple components are in the seedu.address.commons
package.
This section describes some noteworthy details on how certain features are implemented.
AddressBookParser
creates an instance of AddStaffCommandParser
to parse the user input string.
AddStaffCommandParser
first extracts values corresponding to the prefixes sid/
, n/
, p/
, e/
, a/
, role/
, shift/
, hours/
, rating/
, r/
and t/
.
It ensures that:
sid/
should start with an 'S' (case-insensitive) followed by digits (e.g., S1001, s1001) and must not exceed 10 characters. Duplicate staff IDs are not allowed.n/
must contain only alphanumeric characters and spaces, it cannot be blank and must not be longer than 50 characters.p/
must contain only digits and be between 3 and 20 digits long.e/
must contain a valid email address.a/
must contain a non-blank address and must not be longer than 100 characters.role/
must contain a non-empty role and must not be longer than 50 characters.shift/
must contain a non-empty shift.hours/
must contain a non-negative integer.rating/
must contain only digits that are between 0 and 5.0 (inclusive) and of 1 decimal place.r/
, if provided, must contain one non-empty remark up to 50 characters.t/
, if provided, must contain one or more non-empty tags.If any of these constraints are violated, AddStaffCommandParser
throws a ParseException
. Otherwise, it creates a new instance of AddStaffCommand
based on the user input.
AddStaffCommand
stores the staff to be added, represented as a Staff
instance.
Upon execution, AddStaffCommand
first checks the model for duplicate staff. If no existing staff member with a matching (case-insensitive) staff id is found, it adds the new staff member to the address book.
NOTE: CafeConnect identifies a staff member as a duplicate if their
SID
matches (case-insensitive) with an existing staff member in the address book. Attempting to add a duplicate will result in an error.
The delete staff feature allows users to remove staff from the address book by specifying the staff's index in the displayed list.
The implementation follows the command pattern where AddressBookParser
identifies the command type and delegates to DeleteStaffCommandParser
to create the appropriate command object.
AddressBookParser
creates DeleteStaffCommandParser
to parse user input string.
DeleteStaffCommandParser
extracts the index from the command arguments and ensures:
If the index is invalid, DeleteStaffCommandParser
throws a ParseException
. Otherwise, it creates a new instance of DeleteStaffCommand
based on the user input.
Upon execution, DeleteStaffCommand
first checks if the index is within the bounds of the filtered staff list. If the index is out of bounds, a CommandException
is thrown.
If the index is valid, DeleteStaffCommand
:
model.deleteStaff(staffToDelete)
to remove the staff from the address book.CommandResult
with a success message.NOTE: CafeConnect only allows deleting staff by index. Once a staff member is deleted, they cannot be recovered unless added again manually.
The edit staff feature allows users to modify the details of an existing staff member by specifying the staff's index in the displayed list and the new details.
The implementation follows the command pattern, where AddressBookParser
identifies the command type and delegates to EditStaffCommandParser
to create the appropriate command object.
AddressBookParser
creates EditStaffCommandParser
to parse the user input string.
EditStaffCommandParser
extracts the index and provided fields from the command arguments and ensures:
If the input is invalid, EditStaffCommandParser
throws a ParseException
. Otherwise, it creates a new instance of EditStaffCommand
based on the user input.
Upon execution, EditStaffCommand
first checks if the index is within the bounds of the filtered staff list. If the index is out of bounds, a CommandException is thrown.
If the index is valid, EditStaffCommand
:
EditStaffDescriptor
.Staff
instance using StaffBuilder
.CommandException
if a duplicate is found.CommandResult
confirming the successful edit.AddressBookParser
creates an instance of AddCustomerCommandParser
to parse the user input string.
AddCustomerCommandParser
first extracts values corresponding to the prefixes cid/
, n/
, p/
, e/
, a/
, rp/
, vc/
, fi/
, ts/
, r/
and t/
.
It ensures that:
cid/
must start with a 'C' (case-insensitive) followed by digits, e.g., C1001, c1001, and must not be longer than 10 characters. Duplicate customer IDs are not allowedn/
must contain only alphanumeric characters and spaces, it cannot be blank and cannot be longer than 50 charactersp/
must contain only digits and be between 3 and 20 digits long.e/
must contain a valid email address.a/
must contain a non-blank address not be longer than 100 characters.rp/
must contain only digits.vc/
must contain only digits.fi/
can take any value, but it cannot be blank and cannot be longer than 30 characters.ts/
must contain only digits representing the amount in dollars.r/
, if provided, must contain one non-empty remark up to 50 characters.t/
, if provided, must contain one or more non-empty tags.If any of these constraints are violated, AddCustomerCommandParser
throws a ParseException
. Otherwise, it creates a new instance of AddCustomerCommand
based on the user input.
AddCustomerCommand
stores the customer to be added, represented as a Customer
instance.
Upon execution, AddCustomerCommand
first checks the model for duplicate customers. If no existing customer with a matching (case-insensitive) customer id is found, it adds the new customer to the customer list.
NOTE: CafeConnect identifies a customer as a duplicate if their
CID
matches (case-insensitive) with an existing customer in the list. Attempting to add a duplicate will result in an error.
The delete customer feature allows users to remove customers from the address book by specifying the customer's index in the displayed list.
The implementation follows the command pattern where AddressBookParser
identifies the command type and delegates to DeleteCustomerCommandParser
to create the appropriate command object.
AddressBookParser
creates DeleteCustomerCommandParser
to parse user input string.
DeleteCustomerCommandParser
extracts the index from the command arguments and ensures:
If the index is invalid, DeleteCustomerCommandParser
throws a ParseException
. Otherwise, it creates a new instance of DeleteCustomerCommand
based on the user input.
Upon execution, DeleteCustomerCommand
first checks if the index is within the bounds of the filtered customer list. If the index is out of bounds, a CommandException
is thrown.
If the index is valid, DeleteCustomerCommand
:
model.deleteCustomer(customerToDelete)
to remove the customer from the address book.CommandResult
with a success message.NOTE: CafeConnect only allows deleting customers by index. Once a customer is deleted, they cannot be recovered unless added again manually.
The edit customer feature allows users to modify the details of an existing customer by specifying the customer's index in the displayed list and the new details.
The implementation follows the command pattern, where AddressBookParser
identifies the command type and delegates to EditCustomerCommandParser
to create the appropriate command object.
AddressBookParser
creates EditCustomerCommandParser
to parse the user input string.
EditCustomerCommandParser
extracts the index and provided fields from the command arguments and ensures:
If the input is invalid, EditCustomerCommandParser
throws a ParseException
. Otherwise, it creates a new instance of EditCustomerCommand
based on the user input.
Upon execution, EditCustomerCommand
first checks if the index is within the bounds of the filtered customer list. If the index is out of bounds, a CommandException
is thrown.
If the index is valid, EditCustomerCommand
:
EditCustomerDescriptor
.Customer
instance using CustomerBuilder
.CommandException
if a duplicate is found.CommandResult
confirming the successful edit.AddressBookParser
creates an instance of AddDrinkCommandParser
to parse the user input string.
AddDrinkCommandParser
first extracts values corresponding to the prefixes n/
, p/
and c/
.
It ensures that:
n/
must contain a valid drink name.p/
must contain a valid positive decimal value.c/
must contain a non-empty category name.If any of these constraints are violated, AddDrinkCommandParser
throws a ParseException
. Otherwise, it creates a new instance of AddDrinkCommand
based on the user input.
AddDrinkCommand
stores the drink to be added, represented as a Drink
instance.
Upon execution, AddDrinkCommand
first checks the model for duplicate drinks. If no existing drink with a matching (case-insensitive) name is found, it adds the new drink to the catalog.
NOTE: CafeConnect identifies a drink as a duplicate if its
NAME
matches (case-insensitive) with an existing drink in the catalog. Attempting to add a duplicate will result in an error.
The delete drink feature allows users to remove drinks from the catalog by specifying the drink's index in the displayed list.
The implementation follows the command pattern where AddressBookParser
identifies the command type and delegates to DeleteDrinkCommandParser
to create the appropriate command object.
AddressBookParser
creates DeleteDrinkCommandParser
to parse user input string.
DeleteDrinkCommandParser
extracts the index from the command arguments and ensures:
If the index is invalid, DeleteDrinkCommandParser
throws a ParseException
. Otherwise, it creates a new instance of DeleteDrinkCommand
based on the user input.
Upon execution, DeleteDrinkCommand
first checks if the index is within the bounds of the filtered drink list. If the index is out of bounds, a CommandException
is thrown.
If the index is valid, DeleteDrinkCommand
:
model.deleteDrink(drinkToDelete)
to remove the drink from the catalog.CommandResult
with a success message.NOTE: CafeConnect only allows deleting drinks by index. Once a drink is deleted, it cannot be recovered unless added again manually.
AddressBookParser
creates an instance of PurchaseCommandParser
to parse the user input string.
PurchaseCommandParser
first extracts values corresponding to the index, the prefix n/
, and the prefix redeem/
.
It ensures that:
n/
must refer to an existing drink in the catalog.redeem/
, if provided, must be either "true" or "false".If any of these constraints are violated, PurchaseCommandParser
throws a ParseException
. Otherwise, it creates a new instance of PurchaseCommand
based on the user input.
PurchaseCommand
stores the customer index, drink name, and redemption status.
Upon execution, PurchaseCommand
first retrieves the customer at the specified index and searches for the drink in the catalog by name. It then processes the purchase based on the redemption status:
NOTE: The points calculation follows a fixed rate of 10 points per dollar spent. Redemption follows a rate of 100 points equivalent to $1 in drink value.
The implementation of shortcut commands provides an efficient way for café owners to add new entries and record purchases with minimal typing.
CaféConnect implements two distinct types of shortcut commands:
Entity Creation Shortcuts - For quickly adding new customers and staff:
qc CID:NAME:PHONE
- Quick add a customerqs SID:NAME:PHONE
- Quick add a staff memberOperation Shortcut - For quickly recording purchases:
qp INDEX:DRINK_NAME[:r]
- Quick record a purchase (with optional redemption)These commands allow users to rapidly add new customer and staff entries during busy periods when full detailed commands might be impractical. The implementation works as follows:
AddressBookParser
detects shortcut commands and routes them to the appropriate handler:
qc
routes to the customer shortcut handler CustomerQuickCommandParser
qs
routes to the staff shortcut handler StaffQuickCommandParser
The shortcut parsers process the input using these steps:
AddCustomerCommand
or AddStaffCommand
)The command is then executed like any standard command:
NOTE: Entity creation shortcuts only accept three parameters (ID, name, and phone). Other fields are set to default values and can be updated later using the edit commands.
The purchase shortcut enables café staff to quickly record customer purchases with an optional redemption flag. The implementation differs from entity creation shortcuts:
AddressBookParser
detects the qp
command and routes it to the PurchaseCommandParser
.
The purchase parser processes the input using these steps:
^[0-9]+:.+(:r)?$
PurchaseCommand
with the extracted parametersThe purchase command execution:
:r
), deducts reward points instead of increasing total spentNOTE: The purchase shortcut uses a different parameter format than entity creation shortcuts. It takes a customer index (not ID), requires an existing drink name, and has an optional redemption flag.
This implementation adheres to the Command pattern used throughout the application while providing a streamlined interface for common operations. All shortcuts follow a colon-separated format for consistency, but with different parameter requirements based on their function.
CaféConnect uses JSON-based storage to persist data across application restarts. The storage implementation separates different entity types into distinct files:
addressbook.json
: Stores staff and customer datadrinkcatalog.json
: Stores drink catalog datapreferences.json
: Stores user preferences like window size and positionWhen saving data, the following sequence occurs:
On application startup, the reverse process occurs:
NOTE: CafeConnect implements data backup and recovery mechanisms. If a data file is corrupted, the application attempts to back it up before creating a new empty data structure.
The Café Management System is designed to help café owners efficiently manage customers, staff, and menu items while streamlining daily operations. It provides an intuitive interface with both detailed and shortcut commands for quick data entry and retrieval. The system focuses on speed, accuracy, and ease of use, making it ideal for busy café environments.
Attribute | Description |
---|---|
Primary User | Café owners and managers who need a fast, structured way to manage their café operations. |
Demographics | Small to medium café owners, typically in urban areas with moderate to high customer traffic. |
Technical Skills | Comfortable with command-line interfaces (CLI) and quick-typing, but prefer intuitive commands. |
Pain Points | Struggles with handling large amounts of customer and staff data manually, keeping track of sales, and ensuring smooth operations. |
Needs & Goals | Wants a fast, no-frills, and reliable system to manage daily tasks without unnecessary complexity. |
Usage Environment | Typically used on a desktop or laptop at the café's counter or office for quick access during operations. |
Priorities: High (must have) - * * *
, Medium (nice to have) - * *
, Low (unlikely to have) - *
Priority | As a … | I want to … | So that I can… |
---|---|---|---|
* * * | café owner | add a new customer | keep track of my regular customers and their preferences |
* * * | café owner | delete a customer | remove outdated or irrelevant customer records |
* * * | café owner | edit a customer's details | update their contact info or preferences if they change |
* * * | café owner | find a customer by name | quickly retrieve customer details |
* * * | café owner | list all customers | view a full list of my customers at any time |
* * * | café owner | add a new staff member | track my employees and their roles |
* * * | café owner | delete a staff member | remove staff who have left the café |
* * * | café owner | edit a staff member's details | update their role, contact, or working hours |
* * * | café owner | find a staff member by name | locate specific staff quickly |
* * * | café owner | list all staff members | get an overview of all employees |
* * * | café owner | add a new drink to the menu | expand my offerings for customers |
* * * | café owner | delete a drink from the menu | remove items that are no longer available |
* * * | café owner | record a purchase | track customer orders and spending habits |
* * * | café owner | allow customers to redeem points for purchases | encourage customer loyalty and reward repeat visitors |
* * * | café owner | access a help command | quickly understand how to use the system when needed |
* * | café owner | use shortcut commands for adding customers and staff | speed up data entry for frequently used actions |
(For all use cases below, the System is the Café Management System and the Actor is the café owner, unless specified otherwise)
MSS
Extensions
MSS
Extensions
MSS
Extensions
MSS
Extensions
MSS
Extensions
MSS
MSS
Extensions
MSS
Extensions
MSS
Extensions
MSS
Extensions
MSS
Extensions
MSS
MSS
Extensions
MSS
Extensions
MSS
Extensions
MSS
Extensions
MSS
The application should be able to handle up to 1000 total entries (staff, customers, and drinks combined) without noticeable sluggishness in performance.
The system should respond to user actions within 1 second for typical operations like adding, deleting, or searching for customers and staff.
The startup time should be no more than 2 seconds on a modern consumer-grade computer.
The application should consume no more than 200MB of RAM during normal operation with 1000 total entries.
The application should be compatible with Java 11 or above and run on any mainstream OS (Windows, Linux, macOS).
The application should work consistently across different screen resolutions and window sizes.
The system should be self-contained and should not require an internet connection or external databases.
A café owner with basic typing skills should be able to accomplish most tasks faster using commands than using a mouse-driven interface.
The tabbed interface should provide intuitive separation between staff management, customer records, and the drink catalog.
The application should provide clear, contextual error messages when a user makes an incorrect input.
Command shortcuts and aliases (like c
and s
) should make frequent operations more efficient.
The system should not crash or freeze when an invalid command is entered.
Customer, staff, and drink data should be persisted safely to prevent accidental loss due to application crashes.
The application should validate all inputs to prevent data corruption.
The system should be able to recover gracefully from unexpected failures (e.g., power loss, abrupt shutdowns).
The system should store customer and staff contact information securely.
The application should not expose private data unnecessarily in logs or error messages.
The codebase should maintain separation between the UI, Logic, Model, and Storage components.
New commands and features should be able to be added without modifying existing code.
The command structure should be consistent to make the application easier to learn and extend.
The reward points system should accurately track customer loyalty across multiple visits.
The application should support point redemption with clear feedback about points used and remaining.
Staff performance metrics should be maintainable and viewable.
Mainstream OS: Operating systems commonly used by the majority of users, including Windows, Linux, Unix, and macOS.
Private contact detail: A contact detail that is not meant to be shared with others, such as a personal phone number, home address, or private email.
Typical usage: Standard operations performed within the application, including adding, editing, deleting, and searching for contacts, assuming a user base of up to 1000 persons.
Command-based interaction: A method of input where users type textual commands to execute actions instead of using a graphical user interface (GUI).
Graphical User Interface (GUI): A visual interface that allows users to interact with the system through elements like buttons, forms, and icons instead of typing commands.
Error message: A message displayed by the system when a user enters an invalid input or an operation cannot be completed, providing clear guidance on how to correct the issue.
Modern consumer-grade computer: A personal computer with at least a quad-core processor and 8GB of RAM, manufactured within the last five years.
Modular codebase: A structured code design where different components can be modified, replaced, or extended independently without affecting the overall system.
Persisted data: Information that is stored and retained across application restarts, ensuring that user data is not lost when the application is closed.
Startup time: The time taken from launching the application to when it is fully ready for user interaction.
Authorized user: A user who has been granted specific permissions to access certain functionalities within the system.
Self-contained application: An application that does not require external dependencies or an internet connection for its core features to function.
Scalability: The system's ability to maintain performance and responsiveness even as the user base or data size increases.
Undo/Redo functionality: A feature that allows users to reverse or reapply their last action, improving usability and error recovery.
Extensibility: The ability to add new features or enhance existing ones without major rework of the system.
Logging and audit trail: A system feature that records user actions and system events for security, debugging, or compliance purposes.
Given below are instructions to test the app manually.
NOTE: These instructions only provide a starting point for testers to work on; testers are expected to do more exploratory testing.
Initial launch
Download the jar file and copy into an empty folder
Run java -jar cafeconnect.jar
in a terminal.
Expected: The welcome window appears with buttons to navigate to view staff/customers or drink menu. The window size may not be optimum.
Saving window preferences
After clicking on either of the two buttons, resize the window to an optimum size.
Move the window to a different location. Close the window.
Re-launch the app by double-clicking the jar file.
Expected: The most recent window size and location is retained.
Opening help window via Command Line
Prerequisites: Help window is not open
Test case: help
Expected: Help window opens.
Opening help window via Tool bar
Prerequisites: Help window is not open
Test case: Click the Help
menu, then click on the Help
option
Expected: Help window opens.
Interacting the help window
Prerequisites: Help window is now open
Test case: Scroll through content
Expected: Help window content scrolls properly.
Closing the help window
Prerequisites: Help window is open
Test case: Click on the close button on the help window
Expected: Help window closes.
Adding a customer
customeradd cid/C005 n/James Bond p/98765432 e/jamesbond@example.com a/123 Spy Street rp/0 vc/0 fi/Martini ts/0
ca cid/C005 n/James Bond p/98765432 e/jamesbond@example.com a/123 Spy Street rp/0 vc/0 fi/Martini ts/0
customeradd cid/C005 n/Duplicate Customer p/12345678 e/dup@example.com a/Duplicate Address rp/0 vc/0 fi/Coffee ts/0
Adding a customer using shortcut format
qca C099:John Smith:98761234
Deleting a customer
customerdelete 1
cd 1
customerdelete 0
customerdelete
, cd
, customerdelete x
, cd x
, customerdelete 999
, cd 999
(where x is non-numeric and 999 is larger than the list size)Editing a customer
customeredit 1 rp/500 vc/6
ce 1 rp/500 vc/6
Finding customers
customerfind John
cf n/John
customerfind all/true
cf all/true
Adding a staff member
staffadd sid/S005 n/Emily Wong p/91234567 e/emily@example.com a/456 Worker Ave role/Manager shift/9am-5pm hours/0 rating/5.0
sa sid/S005 n/Emily Wong p/91234567 e/emily@example.com a/456 Worker Ave role/Manager shift/9am-5pm hours/0 rating/5.0
Adding a staff member using shortcut format
qsa S099:Jane Doe:90001234
Deleting a staff member
staffdelete 1
sd 1
Editing a staff member
staffedit 1 p/98956743 role/manager
se 1 p/98956743 role/manager
Finding staff
stafffind n/Jane
sf Jane
stafffind all/true
sf all/true
Adding a drink to the catalog
drinkadd n/Green Tea p/3.50 c/Tea
da n/Green Tea p/3.50 c/Tea
Deleting a drink
drinkdelete 1
dd 1
Recording a purchase
purchase 1 n/Espresso
p 1 n/Espresso
Recording a purchase using shortcut format
qp 1:Espresso
Redeeming points for a purchase
purchase 1 n/Cappuccino redeem/true
p 1 n/Cappuccino redeem/true
qp 1:Cappuccino:r
purchase 1 n/Expensive Drink redeem/true
(where the customer doesn't have enough points)qp 1:Expensive Drink:r
(where the customer doesn't have enough points)sf all/true
)cf all/true
)da n/New Drink p/4.50 c/Coffee
)Exiting via command
Test case: exit
Expected: Application closes and all data is saved.
Exiting via window controls
Test case: Click on the X button at the top-right of the window
Expected: Application closes and all data is saved.
The team consists of 5 members.
Given below are enhancements planned for future versions.
CLI functionality to display customer/staff on right panel
display
command or similar feature that takes in the index of the person on the current list and displays it on the right panel.
Update right panel when new staff filtering commands are executed
sf n/Alice
), the original staff being viewed still remains on the right panel even though the list of staff displayed has changed.
Relax name constraints to support more diverse naming conventions
Implement validation for unique phone numbers and email addresses
Improve purchase logic to support multiple items in a single transaction
Make email addresses selectable and copyable
Improve staff role and shift timing validation
Enhance drink menu management and validation
Include text wrapping to accomodate longer inputs