Project: Jalil Enterprises Stock List
1. Overview
1.1. Project Portfolio Overview
This Project Portfolio is to illustrate the contribution of me, He Haowei (GitHub: HeHaowei) to the JalilEnterprises project.
This includes my feature added as well as my contributions to the User Guide and Developer Guide.
2. Summary of contributions
-
Code contributed: Project Code Dashboard
-
Major enhancement: added the ability to do lost and found features.
-
What it does: allows the user to save the current inventory as a .xml file and open it anytime in a table format.
-
Justification: This feature improves the product significantly because it can help the lab technicians to report the lost items in a quite convenient way and can handle the lost and found problem easily.
-
Highlights: This enhancement affects existing commands and commands to be added in the future. It is challenging as it requires to make some user interface changes and be coordinate with some existing commands.
-
-
Other contributions:
-
Modify the logic class in the test folder.
-
Modify the editCommand and changeStatusCommand thus editCommand, changeStatusCommand, lostCommand and foundCommand can cooperate with each other.
-
Project management:
-
Managed project releases
V1.0
on GitHub -
Responsible for milestone completion on GitHub
-
Responsible for Readme file on GitHub
-
-
Enhancements to existing features:
-
Modify the logic class in the test folder.
-
Wrote tests for LostCommand to increase coverage
-
-
3. 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. |
3.1. Lost an item: lost
Lost an item From the stock list
Format: lost INDEX q/QUANTITY
Examples:
-
lost 1 q/25
=== Found an item:found
Found an item From the Lost&Found List
Format: found INDEX q/QUANTITY
Examples:
-
found 1 q/25
=== Listing Lost&Found List:lost&found
Shows the number of every lost item that has been lost
Format: lost&found
4. 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. |
4.1. Architecture
The Architecture Diagram given above explains the high-level design of the App. Given below is a quick overview of each component.
The .pptx files used to create diagrams in this document can be found in the diagrams folder. To update a diagram, modify the diagram in the pptx file, select the objects of the diagram, and choose Save as picture .
|
Main
has only one class called MainApp
. It is responsible for,
-
At app launch: Initializes the components in the correct sequence, and connects them up with each other.
-
At shut down: Shuts down the components and invokes cleanup method where necessary.
Commons
represents a collection of classes used by multiple other components. Two of those classes play important roles at the architecture level.
-
EventsCenter
: This class (written using Google’s Event Bus library) is used by components to communicate with other components using events (i.e. a form of Event Driven design) -
LogsCenter
: Used by many classes to write log messages to the App’s log file.
The rest of the App consists of four components.
Each of the four components
-
Defines its API in an
interface
with the same name as the Component. -
Exposes its functionality using a
{Component Name}Manager
class.
For example, the Logic
component (see the class diagram given below) defines it’s API in the Logic.java
interface and exposes its functionality using the LogicManager.java
class.
Events-Driven nature of the design
The Sequence Diagram below shows how the components interact for the scenario where the user issues the command delete 1
.
delete 1
command (part 1)
Note how the Model simply raises a StockListChangedEvent when the Stock List data are changed, instead of asking the Storage to save the updates to the hard disk.
|
The diagram below shows how the EventsCenter
reacts to that event, which eventually results in the updates being saved to the hard disk and the status bar of the UI being updated to reflect the 'Last Updated' time.
delete 1
command (part 2)
Note how the event is propagated through the EventsCenter to the Storage and UI without Model having to be coupled to either of them. This is an example of how this Event Driven approach helps us reduce direct coupling between components.
|
The sections below give more details of each component.
4.2. Lost and Found feature
4.2.1. Current Implementation
The Lost and Found mechanism is facilitated by LostCommand
, FoundCommand
and LostandFoundCommand
. These three commands extend Command
. And two class: LostDescriptor and Found Descriptor are created as well. The 3 commands implement the following operations:
* LostCommand#lost()
— Lost an item with its number from the Stock List.
* FoundCommand#found()
— Found a number of lost items from the Stock List.
* LostandFoundCommand#lost&found()
— List the lost items and the lost number.
Given below are example usage scenarios and how the Lost and Found mechanism behaves at each step.
Scenario 1:
Step 1. The user executes lost 1 q/20
command to indicate 20 Arduinos are lost from the Stock List.
Step 2. The LostDescriptor
consists of the lost quantity of the item.
Step 3. The lost
command firstly calls getFilteredItemList()
to get the item of the given index and its original quantity.
Step 4. Then LostDescriptor
will be called and the lost quantity of the item will be returned.
Step 5. By using the original quantity of the item minus the lost quantity, the updated quantity of the item will be got.
Step 6. A copy is created and the change of the quantity is made to the copy. The copy then replaces the original item.
Step 7. The updated item list and success message is shown to the user. Updates are committed to the storage.
Scenario 2:
Step 1. The user executes found 1 q/20
command to indicate 20 lost Arduinos from the Stock List are found.
Step 2. The FoundDescriptor
consists of the found quantity of the item.
Step 3. The found
command firstly calls getFilteredItemList()
to get the item of the given index and its original quantity.
Step 4. Then FoundDescriptor
will be called and the found quantity of the item will be returned.
Step 5. By using the original quantity of the item adds the found quantity, the updated quantity of the item will be got.
Step 6. A copy is created and the change of the quantity is made to the copy. The copy then replaces the original item.
Step 7. The updated item list and success message is shown to the user. Updates are committed to the storage.
Scenario 3:
Step 1. The user executes lost 1 q/5
command to indicate 5 Arduinos are lost.
Step 2. The user executes lost 2 q/3
command to indicate 3 Rasperry Pis are lost.
Step 3. The user executes found 1 q/2
command to indicate 2 lost Arduinos are found.
Step 4. The user executes lost&found
.
Step 5. The lost list will be shown to the user.
4.2.2. Design Considerations
Aspect: How Lost and Found executes
-
Alternative 1 (current choice) Create a lost&found list to record the lost&found history.
-
Pros: Able to list all the lost&found records and history.
-
Cons: May have performance issues in terms of usage and require more memory.
-
-
Alternative 2 When executing lost or found command, update the quantity of the item in the StockList.
-
Pros: Easy to handle while only increasing and decreasing the quantity will be used and no need to record all the lost history.
-
Cons: Unable to list all the lost and found history.
-