PROJECT: ClassRepO

Overview

ClassRepO is a desktop address book application written in Java that targets secondary schools for usage by their students, tutors and staff. It is an address book like application to provide a one stop portal for all in the school to access and update any information. This portfolio is meant to document the contributions that I made to the project.

Roles

Under this project, I serve as the Scribe, monitoring all the documentation related to the project, thus ensuring that they are both coherent and informative.

Summary of contributions

  • Code Contributed - RepoSense

  • Major enhancement: added Fees feature

    • What it does: Allows the tagging both staff and students with their respective fees and the dates these fees are due.

    • Justification: This feature gives way to another important attribute being tracked in a school system.

    • Highlights: This feature allows for tracking of every Person’s fee in the address book without actually manipulating the addressbook data. It also automatically adds a 'Fees Due' tag to the person and allows for easy viewing of people with due fees.

  • Minor enhancement: Added a History Command to show the history of commands inputted by the user in that usage session, so as to visually identify mistakes in past commands.

  • Other contributions:

    • Project management:

      • Managed relevant documentation ie. About Us on GitHub, as well as to spot and rectify mistakes made in said documentation.

    • Documentation:

      • Did cosmetic tweaks

        • Tidied up team’s documentation to have consistent language and format.

        • Checks to ensure there’s no spelling and grammatical errors.

    • Community:

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.

Fees Section

Fees Commands

Below are the commands that deals with fees data:

Editing fees of a person: editfees 16

Edits the numerical fees of a person in the address book.
Format: editfees INDEX FEE DUE_DATE
FEE must have the form of 2 decimal places
DUE_DATE must have the form of DD-MM-YYYY

Words in UPPER_CASE are the parameters, the order of parameters is fixed.

Fees are automatically marked as private. private details can only be seen using the viewall command, or for fees specifically, the viewfees command.

Example(s):

  • list
    editfees 1 344.41 31-10-2018

  • list
    editfees 2 0.60 01-01-2019

Removing the fees of a person: paidfees 16

Removes the fees from a person, once he/she has paid in full, in the address book.
Format: paidfees INDEX

Words in UPPER_CASE are the parameters. The INDEX refers to the index number shown in the most recent person listing.

Example(s):

  • list
    paidfees 2
    Fees of the 2nd person in the address book are now fully paid.

View fees of a person : viewfees 16

Displays the fees(private) of the specified person.
Format: viewfees INDEX

Views the fees of the person at the specified INDEX. The INDEX refers to the index number shown in the most recent person listing.

Example(s):

  • list
    viewfees 2
    Views fees of the 2nd person in the address book.

  • find Betsy
    viewfees 1
    Views fees of the 1st person in the results of the find command.

List all fees of every person : listfees 16

Displays the fees(private) of all the people in the AddressBook.
Format: listfees

Views the fees of all the people with respect to their INDEX. Shows only the index, name and fees.

List only people with due fees : listdue 16

Displays the fees(private) of all the people in the AddressBook with overdue Fees.
Format: listdue

Views the fees of all the people with overdue fees. Shows only the index, name, fee and due status. Adds a "feesdue" tag to the people shown for easier tracking in the future.

Example(s):

  • listdue
    viewall 1
    Views all information of the 1st person in the results of the listdue command.
    Including the "feesdue" tag.

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.

Implementation of Fees

Fees Feature

FeesClassDiag
Figure 1. Class Diagram of Fees

Fees are an additional field to every Person object:

  1. Each Person will have a Fees object

  2. Fees contain both a String value as well as a String duedate

  3. Users can thus check the Fees of a particular person, or list out all the fees of the Persons in the AddressBook

Current Implementation

An attribute under the Person class is initialised when a Person is added to the AddressBook. This attribute holds 2 Strings, one being the monetary value of the fee and the other being the duedate for that respective fee. The current set of commands include:

  1. Editing a Fee

  2. Paying a Fee in full

  3. Viewing Fee of a Person

  4. Listing all Fees

  5. Listing all Due Fees

An Example of how command 1 - Editing the Fee of a Person works:

  1. The admin will be able to use the 'editfees' command to add a new fee to the Person.

  2. The existing fee with its date will be replaced by this new value in the Person object in the AddressBook.

  3. The updated fees will then be stored in the AddressBook and will be automatically private, only viewable by the admin and tutors.

This is shown in the diagram below.

EditFeesSequenceDiag
Figure 2. Sequence Diagram of EditFeesCommand

Design Considerations

Aspect: How to define a Fee for each Person

  • Alternative 1 (current choice): Instantiate Fee attribute under each Person created in the Person Class.

    • Pros: Allow us to skip the need for another data Class to be saved into any of the storage files, therefore being more convenient and reducing the number of files and Books.

    • Cons: May get messy with more data manipulation of the Fees attribute when printing/sorting.

  • Alternative 2: Use a separate date file 'FeesBook' to keep track of each Person and their respective fees.

    • Pros: Data independency and hence no conflict during data manipulation.

    • Cons: Cluttered as there may be too many data Books just to track an attribute.

  • Alternative 3: A compulsory attribute under Person Class hence occupying a data field in the input for AddPersonCommand.

    • Pros: Easy to implement and parse.

    • Cons: Input for Add Command would be too long as it will have too many data entry points.

Aspect: Paying a fee for a Person

  • Alternative 1 (current choice): Separate command for Admin to indicate a Person to have paid fees fully.

    • Pros: Convenient for admins to control Fees data of each Person.

    • Cons: May seem redundant for 2 Commands to change the attributes of Fees.

  • Alternative 2: Using EditFeesCommand to indicate the payment of Fees when edited back to 0 value.

    • Pros: Lesser commands in the Fees feature, therefore lesser clutter.

    • Cons: Counterintuitive as Admin would have to manually edit values to be "0.00".

Aspect: How to List fees of everyone

  • Alternative 1 (current choice): Shallow copies the internalList of ReadOnlyPerson, sorts the copy with a custom comparator and prints the list, showing only name and fees.

    • Pros: Allows for easy sorting and does not manipulate the date in the original internalList.

    • Cons: Does not allow for any data manipulation such as omitting any Person

  • Alternative 2: Looping through internalList and printing every name and respective Fee.

    • Pros: Easy to implement.

    • Cons: Unable to be sorted by the date dues of the Fees of each Person.

Aspect: Having another ListDueFeesCommand

  • Alternative 1 (current choice): Having another Command which only shows the people that have Fees that are due with respect to the current system date.

    • Pros: Clearer presentation of data and specific Persons involved. Ability to add "feesdue" tag to only the people shown.

    • Cons: May seem redundant as these people already appear at the top of ListFeesCommand.

  • Alternative 2: Merging it with ListFeesCommand, therefore only have one List Command with respect to Fees.

    • Pros: Less clutter of code.

    • Cons: Inability to show the list of Fees of the Persons whose Fees are not yet due. Restricted in presenting data.

Aspect: Using ViewFeesCommand with respect to INDEX

  • Alternative 1 (current choice): Follows the other ViewCommands with respect to the last INDEX presented following any List Command.

    • Pros: Coherent code template as all ViewCommands follow the INDEXED structure. Ability to be flexible depending on which List Command was called beforehand.

    • Cons: May not seem intuitive to view Fee of a specific Person if User only knows Name of the Person, therefore leading to use of the Find Command first.

  • Alternative 2: Using another parameter such as Name of the Person, instead of INDEX

    • Pros: More intuitive to layman Users.

    • Cons: There may be Persons with identical names, thus resulting in conflicts in ViewCommand.