JAVEN SEOW YU BIN - Project Portfolio

PROJECT: Hallper

1. Overview

This Project Portfolio Page aims to illustrate what I have learnt while working on Hallper, as well as to document my contributions to the project. The different sections below will specify my contributions to different aspects of the project.

Hallper is a desktop application that is a centralized management system which is catered for the use by the Junior Common Room Committee (JCRC) of the halls in any school. Most of my team mates have stayed or are still staying in a hall and we identified that the JCRC in our respective halls seem to be having a hard time dealing with their administrative duties as there they have to liaise with many different parties. As a result, my team decided to build a centralized management system as our project for our software engineering module so as to help alleviate the inconvenience that they encounter while executing their duties. Hallper is an easy to use application which brings about much convenience to the JCRC since not much mouse interaction is required from them as everything can be done just by typing the commands available. By consolidating the types of features needed into a single application, this will save the JCRC the trouble of having to open many different window applications on their computers.

The main features included in Hallper are email writing, budget management, calendar creation, profile picture uploading as well as import and export of Hallper. With all these features in place, we believe that Hallper will be the one-stop solution for all JCRCs.

2. Summary of contributions

Major enhancement 1: added a image function to upload profile pictures into Hallper
- What it does: This feature allows the user to upload profile pictures for residents that the user specifies.
- Justification: This feature adds value to the product as the JCRC will then be able to see the faces of each resident through Hallper.
- Highlights: This feature required the HTML file that is used to display the profile to receive relevant information, along with the tagged profile picture of the specified resident.
Major enhancement 2: added a search function to search for residents by room number, school or CCA
- What it does: This feature allows the user to search for residents based on room numbers, schools or even the CCAs that the residents are in.
- Justification: This feature improves the product significantly because a user might want to find residents based on certain specifications.
- Highlights: This enhancement required manipulation of existing data fields of the residents since multiple specifications can be used as a search criteria
Minor enhancement: Changed select command to show profile page.
Code contributed: Code
Other contributions:
- Project management:
  - Managed release v1.3 on GitHub
- Enhancements to existing features:
  - Edited the data fields of persons in Hallper to what was needed: #12
- Documentation:
  - Reorganized the User Guide to make it more user-friendly: #70
  - Designed project logo
- Community:
  - PRs reviewed (with non-trivial review comments): #18
  - Reported bugs and suggestions for other teams in the class (examples: 1, 2, 3, 4)

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.

Searching all residents under specified tag : `search`

Shows a list of all residents in the Hallper that are associated with the specified keyword.
Format: search KEYWORD [MORE_KEYWORDS]

KEYWORD can be ROOM, CCA or SCHOOL.
KEYWORD is not case-sensitive.

Examples:

Searches Hallper and lists all residents that are in basketball, staying in room A123 or studying in SoC in the resident List Panel as seen in Figure 4.2.1.1 and Figure 4.2.1.2.

Figure 4.2.3.1: Screen before running search on Hallper.

Figure 4.2.3.2: Screen after running search on Hallper.

search SoC
Searches Hallper and lists all residents that are studying in SoC.
search basketball
Searches Hallper and lists all residents that are in basketball.
search A123
Searches Hallper and lists all residents that are staying in room A123.
search basketball A123 Soc

Adding a picture to resident detail : `image`

Saves a copy of the image of resident staying in the specified room to Hallper.
Format: image r/ROOM f/FILEPATH

ROOM is not case-sensitive.
The image must be in .jpg.

Example:

image r/a123 f/C:/user/images/e0000000.jpg
Uploads the profile picture (in .jpg) of the resident living in room A123 into Hallper.

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.

Image feature

Current Implementation

The image feature allows .jpg image files to be uploaded into Hallper to a specific person from the computer. The feature is facilitated by ProfilePictureDirStorage. It implements the follow operations:

ProfilePictureDirStorage#readProfilePicture(File file) — Reads the file that is specified by the user through a path and returns a copy of the image that is being read.
ProfilePictureDirStorage#saveProfilePicture(BufferedImage image, Room number) — Saves the copied image into the computer.

Both operations are exposed in the Storage interface as Storage#readProfilePicture(File file) and Storage#saveProfilePicture(BufferedImage image, Room number) respectively.

Given below is an example usage scenario and how the image mechanism behaves at each step:

Step 1. The user specifies the file path of the .jpg image to be uploaded and the person’s room number.

Step 2. ImageCommandParser passes the room number and file that is specified by the file path to ImageCommand.

Step 3. ImageCommand searches Hallper for the person that is tagged with the specified room number. It returns an error message if the room number specified is not tagged to any person.

Step 4. Once the room number is verified, a NewImageEvent is raised from the ImageCommand to initiate the reading and copying of the image from the given file path.

Step 5. The NewImageEvent goes to the EventCenter, and is then handled by StorageManager#handleNewImageEvent(NewImageEvent event). ProfilePictureStorage#readProfilePicture(File file) is then called to read the image file. After reading a valid image file, the ProfilePictureStorage#saveProfilePicture(BufferedImage image, Room number) is called to save the image into the computer.

Step 6. Hallper then updates the person’s profile picture field with the name of the copied image.

The following sequence diagram shows how the image operation works:

Figure 4.7.1.1: Sequence diagram for image operation

The following activity diagram summarizes what happens when a user executes the image command:

Figure 4.7.1.2: Activity diagram for image operation

Design Considerations

Aspect: Choice of component to read and save the file

Alternative 1 (current choice): Read and save image file through Storage.
- Pro: Reading and saving files through Storage follows the architecture that the project is built upon.
- Con: Informing the user of invalid file path is much more complicated.
Alternative 2: Read and save image file through ImageCommand.
- Pro: Informing the user of invalid file path will be similar to when an invalid command is given.
- Con: Reading and saving the image file from ImageCommand breaks the architecture of the project.

Aspect: Image type

Alternative 1 (current choice): Only .jpg image files.
- Pro: Copying the image will be easier since all images saved will be in the form of .jpg.
- Con: Limiting users to only being able to upload one type of image file.
Alternative 2: Allow for multiple image file types i.e .jpg, .png.
- Pro: Increasing the valid image file types allows users to have more choices when choosing the picture to upload.
- Con: Copying of the image will be more complicated since all images will be saved as a .jpg image file type.