This page showcases my contribution to the SecureIT project.

PROJECT: SecureIT

Overview

SecureIT is an application to help manage your confidential information. More importantly, it stores your information locally, and does not use any form of online storage!

SecureIT 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).

Here’s a sneak peak of our application:

UG first page
Figure 1. Sneak peak of SecureIT

Summary of contributions

Major enhancement

Implemented a series of commands to manage the user’s password. This includes adding a Password model and its subclasses of Description, Username, PasswordValue, Website, PasswordModifiedAt, PasswordExpiredAt, ExpiryMode.

In addition, I implemented the supportive commands to the password model such as AddPasswordCommand, FindPasswordCommand, CopyPasswordCommand, DeletePasswordCommand, ReadPasswordCommand and EditPasswordCommand.

What it does

  • Allows the user to manage their passwords and keep track of the expiry dates of the passwords.

Justification

  • Many small and medium enterprises now have a plethora of accounts to use for day-to-day activities. It is hard to keep track of all the passwords without compromising on security. This feature aims to alleviate the password management on businesses and improve data security.

Highlights

  • A new Password model was created to support the management of passwords. Numerous commands were also implemented for this enhancement. This enhancement requires in depth analysis of the current structure of the architecture as it touches every component of the architecture. In addition, many Software Engineering Principles, such as SOLID, YAGNI and DRY Principles, were used. Defensive programming is also evident throughout the enhancement.

Minor enhancement Designed the UI of the current application by adding in a ReadDisplayPanel and ModeDisplay.

Other contributions:

  • Project management:

    • Set up team repository and other essential tools such as Travis on GitHub.

    • Maintained the team repository by managing issue tracking, issue assigment and milestones.

    • Reported bugs and suggestions to teammates (Pull requests: #90, #82, #113)

  • Enhancements to existing features:

    • Designed and enhanced the UI of the existing application (Pull requests: #68, #80)

    • The UI designed for the Password details was adopted for Card details.

    • Wrote additional tests for existing features to increase coverage (Pull requests: #175)

  • Documentation:

    • Developer Guide:

      • Updated Use Case (Pull Request: #6)

      • Updated UML diagrams for current implementation (Pull Request: #58)

    • User Guide:

      • Updated Basic Information for better clarity to address users (Pull Request: #60)

      • Added in icons for better clarity (Pull Request: #60)

  • Community:

    • Issues created (with non-trivial review comments): #11, #10, #9, #6, #3, #1

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 password : add

Too many passwords to remember? You can add a password to the application.

Format: add d/DESCRIPTION u/USERNAME p/PASSWORD [w/WEBSITE] [t/TAG]…​

Example: add d/Gmail u/user1 p/password1 w/www.gmail.com/signin t/work

AddPW1
AddPW2

Accessing a password : read

You can open and view the password for the specified index.

Format: read INDEX

Example: read 1

Read 2 in 1
Figure 2. Example of how an read command can be used.
tip

Tip

  • Your password will expire expire in a year.

  • You will be reminded if your password is expired or about to expire.

  • You can toggle the eye icon to see your password. Be wary of surveillance by secret agents or people standing behind you

You will see this reminder 30 days before your password expires.

PasswordExpiring

You will see this reminder if you have not changed your password for over a year.

PasswordExpired
Figure 3. Example of when your password is expired

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.

Password Management

Model

We created the Password model to support the password management feature of our application. It stores the information of all the passwords created by the user. The class diagram of the Password model is as follows:

PasswordClassDiagram
Figure 4. Class diagram of Password Model.

The Password model consists of a Password class which has its attributes implemented as separate classes to follow Single Responsibility Principle. The attributes are as follows:

Username: The username of the password model

PasswordValue: The actual password value of the password model

PasswordDescription: The description of the password model.

Website: The website where the password is being used for.

PasswordModifiedAt: The date when the password is last modified.

PasswordExpiredAt: The date 1 year after the password is last modified.

ExpiryMode: It has 3 modes: HEALTHY, EXPIRING, EXPIRED, depending on how close the current date is when compared to the expiry date of the password.

The Password objects are stored in a UniquePasswordList in the PasswordBook and the existing model manager is extended to add the functionality managing passwords into the application. We have adhered to YAGNI design principle by making sure that minimal changes are added.

Design Considerations:

Aspect: Model Manager for Password.

The design considerations would be similar for all other models including File model, Card model, Note model and Password model.

  • Alternative 1 (current choice): The current model manager is extended to handle the filtered lists of all the models.

    • Pros: Adheres to DRY design principle as it extends the functionality of the model manager without repeating code.

    • Cons: It might increase dependencies in the model manager.

  • Alternative 2: Create another Model interface and another Model Manager class.

    • Pros: Easy to implement.

    • Cons: Does not adhere to DRY design principle, where additional Model Manager class are created.

We chose alternative 1 as there is already a model manager available and it would be logical to use it instead of creating another class and possibly write repeated code.

Logic

User is allowed to add, read, edit, find, list, delete and copy. Additional PasswordBookParser, Parser and Command classes are included to support the functionality stated above. The class diagram for all Command classes available for Password model is as follows:

CopyCommand
Figure 5. Class diagram of all Command classes used in password management
Aspect: Logic Manager for Password model.

The design considerations would be similar for all other models such as the File model, Card model, Note model and Password model.

  • Alternative 1 (current choice): The current logic manager is extended to handle the model parsers. The logic manager checks for the current mode of the system and decides which model parser class to use.

    • Pros: This adheres to the Open-closed principle in SOLID. Same command words can be used in different modes and it does not increase coupling in the application.

    • Cons: Hard to implement. Requires another command to switch modes. Similar command classes will need to be implemented in different model such as AddPasswordCommand, AddNoteCommand, AddCardCommand. However, all the fields in the command classes are different and separating them into different classes reduces coupling.

  • Alternative 2: Extending one parser class to handle all the different commands. Different command will have different add command words.

    • Pros: Easy to implement.

    • Cons: User will have to remember different command words for the same add command for different modes, such as addp, addn, addc. This will impact the user experience and increase coupling as the same add command is required to perform different tasks.

We chose alternative 1 because of its pros. We place emphasis on the user experience of our application. In this implementation users will not have to remember different command words to add the same objects into our application.

Copy Command:

Current Implementation:

CopyPasswordValueCommand class, CopyWebsiteCommand class and CopyUsernameCommand class extends CopyPasswordCommand class as shown in the earlier figure.

These three classes are implemented together with CopyCommandParser class to create the functionality of copying the required details onto clipboard using CLI. Since this is a command that would be used frequently, command alias are added to increase the efficiency for the user. The activity diagram below describes the flow of the CopyPasswordCommand:

Step1
Figure 6. Activity Diagram for CopyPasswordCommand

The following sequence diagram describes the detailed interactions between any CopyPasswordCommand and the architecture:

CopyPasswordSequenceDiagram
Figure 7. Sequence Diagram for CopyPasswordValueCommand

The process of copying a password value is as follows:

1) PasswordBookParser creates CopyPasswordCommandParser and depending on the command word after copy, different copy commands will be created.

2) In this case, the index is a valid index and CopyPasswordValueCommand is created.

3) The Password object is retrieved from the filtered password list using the index and the password value is copied via ClipboardUtil#copyToClipboard() method

Design Considerations:

Aspect: Implementation of CopyPasswordCommand

  • Alternative 1 (current choice): The CopyPasswordCommand class extends Command class. CopyPasswordValueCommand class, CopyWebsiteCommand class and CopyUsernameCommand class extend CopyPasswordCommand.

    • Pros: This follows closely to Polymorphism and Inheritance concepts as all three commands share the similar functionality. The common functionality is abstracted out and placed inside the CopyPasswordCommand.

    • Cons: Any further enhancement of the child commands will have to follow Liskov Substitution Principle and it needs to be more restrictive than the parent command.

  • Alternative 2: CopyPasswordValueCommand, CopyWebsiteCommand , CopyUsernameCommand will extend Command class.

    • Pros: Easy to implement. PasswordBookParser can directly check for the command word instead of splitting into 2 command words.

    • Cons: Does not adhere to DRY design principle.

We chose alternative 1 because it is more logical and follows the DRY design principle. The cons caused by the further enhancements of child commands will not be considered because of YAGNI design principle.