PROJECT: iTrack Pro

Overview

iTrack Pro is for the grocery shop owners to keep track of the products, customers, and transactions of the shop and have a better understanding of the business by viewing the performance of products and behaviors of customers. It is also able to provide an analysis of the entire business to help the owner manage the shop.

Summary of contributions

  • Major enhancement:

    1. Added the ability to manage products (add, list, find, delete, clear, edit)

      • What it does: allows the user to manage products in the inventory easily. User can add, delete or edit products, and list or clear all products. Users can also find products based on keywords.

      • Justification: This feature improves the product significantly because shop owners can have many products and managing them manually can be inefficient. Hence, the inventory system provides a convenient way for them to keep track of their products.

      • Highlights: Though the implementation seems similar to the Person class in the addressbook, it was challenging as the fields were different and the execution of some commands varied due to the different requirements.

    2. Added the ability to view and analyse statistics (revenue, profit, predict sales, view top selling products)

      • What it does: allows the user to view and analyse statistics based on transactions added to the inventory system.

      • Justification: This feature improves the product significantly because shop owners can gain insight to their business and know how profitable they are. By knowing the revenue and profit, the user can gauge market demand for their products and employ suitable marketing strategies to improve sales. Moreover, users can get the predicted sales for the next month, enabling them to make more informed business decisions.

      • Highlights: This enhancement required an in-depth analysis of design alternatives. The difficult part was to determine how and when the revenue/ profit was to be calculated, and the best way to structure the classes.

  • Minor enhancement:

    • Added id for Customer and Product and made use of customer and product id fields to prevent duplicate transactions (during transaction edit) (Pull request #122)

    • Added view top-selling products function (Pull request #112)

    • Updated ui for statistics window and notification (Pull requests #130, #112)

    • Wrote tests for product features to increase coverage by 16.3% to 66.752% (Pull request #82)

    • Wrote tests for statistics features (Pull requests #119, #97)

  • Code contributed: tp-dashboard

  • Other contributions:

    • Project management:

      • Reviewed and merge code of teammates

      • Created and assigned issues

    • Enhancements to existing features:

      • Updated the GUI color scheme (Pull requests #93, #94, #187)

      • Added restrictions for each field (e.g. max value for price and quantity, max length for address) (Pull request #142)

    • Documentation:

      • Edited ArchitectureSequenceDiagram, BetterModelClassDiagram, DeleteSequenceDiagram, LogicClassDiagram to reflect current app structure (Pull request #184)

      • Replaced ModelClassDiagram, UiClassDiagram and StorageClassDiagram with created diagrams to reflect current class structure (Pull requests #184, #187)

      • Added implementation section, and sequence and activity diagrams for product features (Pull requests #100, #103)

      • Added implementation section, and sequence and activity diagrams for revenue/profit features (Pull request #184)

      • Modified glossary and design sections, add target audience, manual testing, effort and use cases to developer guide (Pull requests #19, #194, #202)

      • Add product features and statistics (revenue, predict, profit) features to user guide (Pull request #24)

    • Community:

      • Reported bugs and suggestions for other teams in the class: T09-1

    • Tools:

      • Created team organisation on github and set up address book in organisation repo

Contributions to the User Guide

Given below are sections I contributed to the User Guide. They showcase my ability to write documentation targeting end-users.

Adding a product: addp

Adds a product to the product list.
Format: addp d/DESCRIPTION pr/PRICE q/QUANTITY cp/COSTPRICE [s/SALES]

  • Duplicate products (with the same description, cost price, price) are not allowed.

  • The price, cost price, quantity and sales can take integers up to 1000000.

  • The price and cost price must be at least $1.

  • Duplicate fields are not allowed. E.g. keying in the price field for more than one time.

The default threshold value is 20% of quantity of product.
A product created without providing values for sales (in SGD) will be created with 0 sales.
AddProduct

Examples:

  • addp d/iphone x pr/1000 q/10 cp/300

  • addp d/camera pr/2000 q/90 s/100 cp/1000

Editing a product : editp

Edits an existing product in the displayed product list.
Format: editp INDEX [d/DESCRIPTION] [pr/PRICE] [q/QUANTITY] [cp/COSTPRICE] [s/SALES]

  • Edits the product at the specified INDEX. The index refers to the index number shown in the displayed product list. The index must be a positive integer 1, 2, 3, …​

  • At least one of the optional fields must be provided.

  • Existing values will be updated to the input values.

  • Duplicate fields are not allowed. E.g. keying in the price field for more than one time.

Examples:

  • editp 1 pr/1150 q/80
    Edits the price and quantity of the 1st product in the list to be $1150 and 80 respectively.

  • editp 2 s/1000
    Edits the sales of the 2nd product in the list to be $1000.

Clearing all products : clearp

Clears all entries from the product list.
Format: clearp

Permanently deletes all the stored product data in the application.
Deletes all transactions as well.

Deleting a product : deletep

Deletes the specified product from the system.
Format: deletep INDEX

  • Deletes the product at the specified INDEX.

  • The index refers to the index number shown in the displayed product list.

  • The index must be a positive integer 1, 2, 3, …​

This action deletes transactions that are associated with this particular product as well.

Examples:

  • listp
    deletep 2
    Deletes the 2nd product in the product list.

  • findp camera
    deletep 1
    Deletes the 1st product in the results of the find command.

Listing all products : listp

Show all products in the product list.
Format: listp

Sorts all of the product by the product quantity, represented by the bar indicator beside the product name.

Getting the revenue made in a certain period : revenue

Gets the revenue made in a selected period. (start date to end date, both inclusive)
Format: revenue [sd/START_DATE] [ed/END_DATE]

  • The start date and end date must follow a format of yyyy-mm-dd hh:mm

  • The start date must be before or equal to end date

  • At least one product must be present

Example:

  • revenue sd/2020-01-01 10:00 ed/2020-12-31 10:01
    Returns the revenue from Jan 1 2020 10am to Dec 31 2020 10:01am

Getting the profit made in a certain period : profit

Gets the profit made in a selected period (start date to end date, both inclusive).
Format: profit [sd/START_DATE] [ed/END_DATE]

  • The start date and end date must follow a format of yyyy-mm-dd hh:mm

  • The start date must be before or equal to end date

  • At least one product must be present

Example:

  • profit sd/2020-01-01 10:00 ed/2020-12-31 10:01
    Returns the profit from Jan 1 2020 10am to Dec 31 2020 10:01am

Predicting the sales for the next month : predict

Predicts sales for the next month based on sales in the previous three months
Format: predict

The average of the profits made in the past three months is the predicted sales for next month.

Viewing the top-selling and worst-selling products.

Displays and updates the top-selling and worst-selling products (sorted by profit) as transactions are made.

This is a passive feature.

Contributions to the Developer Guide

Given below are sections I contributed to the Developer Guide. They showcase my ability to write technical documentation and the technical depth of my contributions to the project.

Add/delete/edit/clear/list/find customer/product feature

The manage product mechanism is facilitated by InventorySystemParser. First, the InventorySystemParser class parses the user command. This results in a Command object which is executed by the LogicManager. The command execution modifies Model’s customer list depending on the command. The result of the command execution is encapsulated as a CommandResult object which is passed back to the Ui.

The following commands are available to be parsed by InventorySystemParser:

  • AddCustomerCommand/AddProductCommand

    • Adds the customer/product into the list in the inventory system.

  • ListCustomerCommand/ListProductCommand

    • Lists all customer/product in the list.

  • ClearCustomerCommand/ClearProductCommand

    • Clears all customer/product in the list.

  • DeleteCustomerCommand/DeleteProductCommand

    • Deletes the selected customer/product from the list in the inventory system.

  • EditCustomerCommand/EditProductCommand

    • Edits the customer/product details.

  • FindCustomerCommand/FindProductCommand

    • Finds customer/product with attributes containing given keyword(s).

The commands all inherit from superclass Command. Only add, delete, edit and find commands require a command parser to parse the arguments entered by the user.

The following sequence diagram shows how the add operation works:

AddItemSequenceDiagram

The following sequence diagram shows how the list operation works:

ListItemSequenceDiagram

The following sequence diagram shows how the edit operation works:

EditItemSequenceDiagram

The following activity diagram summarizes what happens when a user executes a command that changes the customer/product list in the model:

CommandActivityDiagram

Design Considerations

Aspect: How commands are executed

  • Alternative 1 (current choice): Keep customers/products in the inventory system

    • Pros: Easy to implement, use less memory

    • Cons: If inventory system is corrupted then the data is lost

  • Alternative 2: Keep customers/products in individual management systems, separate each of the classes

    • Pros: Keep implementation of products, customers and transactions separate

    • Cons: Use more memory, tedious implementation

Aspect: Data structure to support the commands

  • Alternative 1 (current choice): Use a list (ArrayList) to store the customers/products

    • Pros: Easy to sort and iterate through the list, get(index) method always gives an O(1) performance

    • Cons: allows duplicates

  • Alternative 2: Use a hashmap to store the customers/products

    • Pros: Find can be done in O(1), does not allow duplicate keys

    • Cons: Difficult to sort and iterate through hashmap, get(key) can be O(1) in the best case and O(n) in the worst case.

Get revenue/profit feature

The manage product mechanism is facilitated by InventorySystemParser. First, the InventorySystemParser class parses the user command. Then the RevenueCommandParser/ProfitCommandParser parses the user input arguments into Command objects. The resulting RevenueCommand/ProfitCommand is executed by the LogicManager. The command execution calculates the revenue/profit depending on the command. The result of the command execution is encapsulated as a CommandResult object which is passed back to the Ui.

The following commands are available to be parsed by InventorySystemParser:

  • RevenueCommand

    • Gets the revenue made in a selected period.

  • ProfitCommand

    • Gets the profit made in a selected period.

The commands all inherit from superclass Command and require command parsers to parse the user input arguments.

The following sequence diagram shows how the profit operation works:

ProfitSequenceDiagram

The revenue operation works in the same way as the profit operation.

Design Considerations

Aspect: How commands are executed

  • Alternative 1 (current choice): Calculate revenue/profit only when needed

    • Pros: Decreases coupling, easy to test

    • Cons: Need to keep calculating if command is frequently used (increase time complexity especially if transaction list is long)

  • Alternative 2: Keep track of revenue/profit in a singleton class

    • Pros: No need to calculate when revenue/profit command is executed (instead, revenue/profit is updated whenever a transaction is added or edited)

    • Cons: Hard to unit test, increase coupling