PROJECT: Inventarie Pro

Overview

Inventarie Pro is for self employed business owners who prefer to use a desktop app for managing inventory. More importantly, Inventarie Pro is optimized for those who prefer to work with a Command Line Interface (CLI) while still having the benefits of a Graphical User Interface (GUI). If you can type fast, Inventarie Pro can get your inventory management tasks done faster, simpler and easier than traditional GUI apps.

Summary of contributions

  • Major enhancement: added the ability to login as users

    • What it does: Inventarie Pro now supports multiple users on a single system by seperating user accounts and application data.

    • Justification: This feature allows multiple employees to use a single system without the fear of intrusion on each other. It also prevents any unauthorized access which maintains a measure of integrity and confidentiality.

    • Highlights: This enhancement affects existing commands and commands to be added in future. It required an in-depth analysis of design alternatives. Model and Storage components were heavily modified to support a User Database.

  • Minor enhancement:

  • Code contributed: [Code Dashboard]

  • Other contributions:

    • Project management:

      • Managed releases v1.1 - v1.4 (7 releases) on GitHub

    • Enhancements to existing features:

      • Wrote additional tests for existing features to increase converage from 21% to 25% (Pull requests #111)

      • Wrote additional tests for existing features to increase coverage from 30% to 42% (Pull requests #179, #186)

      • Wrote additional tests for existing features to increase coverage from 49% to 55% (Pull request #207)

      • Proposed data encryption for v2.0 (Pull request #177)

    • Documentation:

      • Did cosmetic tweaks to existing contents of the User Guide: #186

    • Community:

      • PRs reviewed (with non-trivial review comments): #56, #156

      • Resolved issues found in PE1: #142

    • Tools:

      • Integrated a continuous integration service (Travis CI) to the team repo (#42)

      • Integrated a continuous integration service (AppVeyor) to the team repo (#42)

      • Integrated a coverage reporting service (Coveralls) to the team repo

      • Integrated an automated code quality tool (Codacy) to the team 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.

Authentication

Register new user : register

Format: register u/USERNAME p/PASSWORD
Creates a new user account in the application.

Examples:

  • register u/John p/pass

Login : login

Format: login u/USERNAME p/PASSWORD
Logs the user into the application.

  • The password is case-sensitive.

Examples:

  • login u/John p/pass

Logout: logout

Format: logout
Logs the user out of the application.

Deregister: deregister

Deregister the user account in the application.
Format: deregister u/USERNAME p/PASSWORD

Examples:

  • deregister u/John p/pass

Encrypting data files [coming in v2.0]

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.

Storage component

StorageClassDiagram
Figure 1. Structure of the Storage Component

API : Storage.java

The Storage component,

  • can save UserPref objects in json format and read it back.

  • can save the Distributor Book data in xml format and read it back.

  • can save the User Database data in xml format and read it back.

  • can save the Product Database data in xml format and read it back.

Model component

ModelClassDiagram
Figure 2. Structure of the Model Component

API : Model.java

The Model,

  • stores a UserPref object that represents the user’s preferences.

  • stores the

    1. Product data

    2. Distributor Book data

    3. User data

  • exposes an unmodifiable

    1. ObservableList<Product>

    2. ObservableList<Distributor>

    3. ObservableList<Transaction>

    4. ObservableList<Reminder>

that can be 'observed' e.g. the UI can be bound to this list so that the UI automatically updates when the data in the list change. * does not depend on any of the other three components.

As a more OOP model, we can store a Tag list in both Product Database and Distributor Book, which Product/Distributor can reference. This would allow Product Database and Distributor Book to only require one Tag object per unique Tag, instead of each Product/Distributor needing their own Tag object. An example of how such a model may look like is given below.

ModelClassBetterOopDiagram

Authentication

Current Implementation

Multiple Users

Each storage file is now stored in separate XML files. They are identified in the following format:

  1. addressbook-[USERNAME].xml

  2. distributorbook-[USERNAME].xml

  3. saleshistory-[USERNAME].xml

Login

The following sequence diagram shows how the user authentication process works:

AuthenticationSequenceDiagram
Logout

This feature allows the user to log out from the application, securing data. When the user is logged out, some of the user commands are limited. This is handled by LogicManager.

The user will be unable to logout if not logged in.

Deregistration

When the user is deleted, the following storage files stored in the system managed by the user will be deleted.

  1. addressbook-[USERNAME].xml

  2. distributorbook-[USERNAME].xml

  3. saleshistory-[USERNAME].xml

Proposed Enhancements

  1. Hiding/showing of panels when logged in/out for confidentiality.

  2. 2-FA

  3. Login Status Identifier

Design Considerations

Aspect: Implementation of Users Database

  • Alternative 1 (current choice): All users stored collectively in one XML file. (users.xml)

    • Pros: Inexpensive and adapts well to existing codebase

    • Cons: Maintenance

  • Alternative 2: SQL/NoSQL Databases.

    • Pros: Powerful and stable

    • Cons: Complexity

[Proposed] Data Encryption

Proposed Implementation

Data needs to be encrypted to protect from unauthorized access. The process to transform data stored in the databases is to be facilitated by DataEncryptionUtil class. It is a class containing utility methods to encrypt and decrypt files for Storage. Additionally, it implements the following operations:

  • DataEncryptionUtil#encrypt() - Encrypts file using a secret key.

  • DataEncryptionUtil#decrypt() - Decrypts file using a secret key.

  • DataEncryptionUtil#processFile() - Encrypts or decrypts a given file using a cipher.

Design Considerations

Aspect: Possible schemes

  • Alternative 1 (proposed choice): AES/CBC/PKCS5Padding

  • Alternative 2: AES/ECB/PKCS5Padding

Aspect: How encryption and decryption executes

  • Alternative 1 (proposed choice): Intercept XMLUtil when reading and saving XML Storage files.

    • Pros: Best practice

    • Cons: Require remodeling of application

  • Alternative 2: Individual encrypt and decrypt command.

  • Alternative 3: Create temporary file to contain decrypted data

    • Pros: This will work with current architecture style.

    • Cons: Bad information security practice as there is a momentary vulnerability.