Drink I/O - Developer Guide

This project follows oss-generic coding standards. IntelliJ’s default style is mostly compliant with ours but it uses a different import order from ours. To rectify,

Optionally, you can follow the UsingCheckstyle.adoc document to configure Intellij to check style-compliance as you write code.

After forking the repo, the documentation will still have the SE-EDU branding and refer to the se-edu/addressbook-level4 repo.

If you plan to develop this fork as a separate product (i.e. instead of contributing to se-edu/addressbook-level4), you should do the following:

Set up Travis to perform Continuous Integration (CI) for your fork. See UsingTravis.adoc to learn how to set it up.

After setting up Travis, you can optionally set up coverage reporting for your team fork (see UsingCoveralls.adoc).

Optionally, you can set up AppVeyor as a second CI (see UsingAppVeyor.adoc).

When you are ready to start coding,

To facilitate the analyses of total profit, revenue and costs of the company over various periods of time, transactions (sales and purchases) are logged using Transaction s. They will be logged when the drink stock increases due to a purchase (TransactionType is PURCHASE), or when they decrease due to a sale (TransactionType is SALE). These transactions are stored into a list of transactions, in TransactionList.

Analyses are conducted in AnalysisManager, with the API exposed in Analysis. The following operations are implemented for the analyses of profit, revenue and costs:

The implementation of these operations are elaborated in the below sub-sections.

AnalysisPeriodType is an enum class that denotes the period for analysis:

These are indicated respectively as:

A user may enter an analysis command with additional time period parameters. For the period of a day, no parameter is indicated. For the period of 7 days, -w is appended to the command. (e.g. costs -w) For the period of 30 days, -m is appended to the command. (e.g. costs -m)

The following is the sequence of steps when the user enters an analysis command with a time period:

Step 1. User enters an analysis command (e.g. costs -m).

Step 2. The appropriate parser (e.g. AnalyseCostsCommandParser) parses the time period parameter, and retrieves the AnalysisPeriodType value corresponding to the time period.

Step 3. The relevant TransactionPeriodPredicate for the AnalysisPeriodType value is retrieved. It is assigned to an Analysis Command (e.g. AnalyseCostsCommand).

The available TransactionPeriodPredicate s corresponding to each AnalysisPeriodType are:

These are retrieved using AnalysisPeriodType#getPeriodFilterPredicate().

Step 4. The analysis command is executed, and the TransactionPeriodPredicate predicate is passed to the appropriate ModelManager. This is done through the analyseCosts() method in the appropriate ModelManager.

Step 5. In the appropriate ModelManager (Accountant or Manager), the predicate is passed to the filtered transaction list. This is in order to filter the transactions by their dates such that the filtered transaction list only contains transactions with dates within the relevant period.

FilteredList<Transaction> handles the filtering using the given predicate.

The following sequence diagram shows how the first part of the AnalyseCostCommand works, as described above:

The actual analysis of costs continues from the the filtering of the filtered transaction list. This section focuses on the actual computation of the costs incurred by the company.

Step 1. In addition to passing the analysis period Predicate, a PurchaseTransactionPredicate is also passed to the filtered transaction list simultaneously.

This filters the list further, leaving only the TransactionType.PURCHASE transactions, which contribute to the costs of the company.

Overall, the filtered transaction list will also be updated in the UI.

Step 2. ModelManager passes control to the AnalysisManager.

Step 3. In AnalysisManager, the helper method AnalysisManager#calculateTotalCost() is called to compute the total costs of the filtered transactions.

It iterates through the filtered transaction list, and checks the Transaction 's TransactionType as a precuation. If the TransactionType is PURCHASE, the amountMoney transacted is obtained and added to a sum of costs. The sum of costs is then wrapped in a Price object and returned to the calling function.

The implementation of the analysis of revenue is similar to that of costs. However, a SaleTransactionPredicate is passed to the filtered transaction list instead.

In Step 3, the helper method AnalysisManager#calculateTotalRevenue() is called. It iterates through the filtered transaction list, and checks if the Transaction 's TransactionType is SALE. If so, the amountMoney transacted is added to the sum of revenues. The sum of revenues is then wrapped in a Price object and returned to the calling function.

The analysis of profit continues from the filtering of the filtered transaction list by period. This section focuses on the actual computation of the profit earned by the company.

Step 1. ModelManager passes control to the AnalysisManager. No additional filtering is done.
Step 2. In AnalysisManager, the helper method AnalysisManager#calculateTotalProfit() is called to compute the total profit of the filtered transactions.

It iterates through the filtered transaction list, and checks the Transaction 's TransactionType.

Step 3. Total profit is calculated using the formula: "profit = revenue - cost". This total profit value is checked to determine whether it is negative.

Aspect: Filtering the transactions by date

The command partition is an implementation of the role system.

The model contain all the API that is common for every user. StockTakerModel contains API for for stockTaker. Similar idea applied to AccountantModel and ManagerModel. However, AdminModel extends all three models. As such, adminModel will contains all APIs.

After login, logicManager will assign a particular role to user according to their authenticationLevel. As such, it will prevent one role from accessing other role’s command.

The login feature is a standalone feature that enable security check on user. It has a fxml page that name LoginPage.fxml at main\resources\view The controller of the fxml page named LoginController at seedu.address\controller The model of is at loginInfo which storage the format in JSON with the help of JsonUtils. Also, there is a loginInfoManager which include all the API for loginInfo. As such, this is a design that fulfil the Model-View-Controller pattern.

Given below is a class diagram for login function. LoginUtils has attributes of LoginInfoModel userName and Password. It also use passwordUtils to hashed verify the password with LoginInfoModel

Given below is an example usage scenario and how login mechanism behave at each step.

The LoginController will check for username and password will the LoginUtils.

A user may enter a buy command with the above parameters to record a purchase of drinks.

The following is the sequence of steps when the user enters an buy command with specified name and quantity: Step 1. User enters a buy command (i.e. buy n/Coca cola q/400).

Step 2. The appropriate parser parses the name and quantity parameters and assigns the name and quantity variables to the buy command.

Step 3. The buy command is executed, and a new Transaction object is created with the name , quantity and a transactionType variable. This Transaction object is then passed to the StockTakerModelManager.

Step 4. In the StockTakerModelManager, recordTransaction(Transaction) is used to record the transaction and increaseDrinkQuantity(Name, Quantity) is called to update the change in quantity in the inventory list.

Step 5. The inventory list then passes the name and quantity variables down to the UniqueDrinkList which calls the increaseQuantity(Quantity) method in the relevant Drink object.

Step 6. In the Drink object, a new Batch object is created with the name and quantity variables and passed to the Drink’s UniqueBatchList through the addBatch method.

Step 7. In the UniqueBatchList , the Batch that was passed down would be checked against the other Batch objects in the list for uniqueness based on its date. If it has a unique date, a new Batch would be created and stored in the UniqueBatchList, else the currently existing Batch object in the UniqueBatchList with the same date will have its Quantity attribute incremented by the quantity value of the Batch object added.

Step 8. The totalQuantity attribute of the UniqueBatchList is then updated by looping through the batches in the list, and is handed up to the Drink object which updates its Quantity attribute with the value of the totalQuantity attribute.

To facilitate sales of drinks from the stock of the company, sales of drinks from the inventory are conducted with the command sell n/DRINK_NAME q/QUANTITY

A user may enter a buy command with the above parameters to record a purchase of drinks.

The following is the sequence of steps when the user enters an buy command with specified name and quantity:

Step 1. User enters a sell command (i.e. sell n/Coca cola q/400).

Step 2. The appropriate parser parses the name and quantity parameters and assigns the name and quantity variables to the sell command.

Step 3. The sell command is executed, and a new Transaction object is created with the name , quantity and a transactionType variable. This Transaction object is then passed to the StockTakerModelManager.

Step 4. In the StockTakerModelManager, recordTransaction(Transaction) is used to record the transaction and decreaseQuantity(Name, Quantity) is called to update the change in quantity in the inventory list.

Step 5. The inventory list then passes the name and quantity variables down to the UniqueDrinkList which calls the decreaseQuantity(Quantity) method in the relevant Drink object.

Step 6. In the Drink object, updateBatchTransaction(Quantity) is called and the quantity variable is passed down to the UniqueBatchList.

Step 7. In the UniqueBatchList , quantity passed down will be checked against the totalQuantity variable. If quantity is more than totalQuantity, a InsufficientQuantityException will be thrown which would be handled in the SellDrinkCommand class. Else, the updateBatchTransaction would loop through the UniqueBatchList and decrement the quantity of the individual batches starting from the one with the oldest date.

Step 8. The totalQuantity attribute of the UniqueBatchList is then updated by looping through the batches in the list, and is handed up to the Drink object which updates its Quantity attribute with the value of the totalQuantity attribute.

Aspect: Facilitating the Buy and Sell Commands