PROJECT: TutorHelper

Overview

TutorHelper is a desktop administration application intended for Tutors who would like to organise their students' information. TutorHelper uses CLI(command-line interface) as its main form of inputs: where tutors issues commands in the form of successive line of text. Having multiple students at once can be a hassle to deal with, especially with each student having his own curriculum, tuition timing, and payments. Our team of five decided to create TutorHelper by building upon the existing AddressBook Level 4 application. TutorHelper offers an easy way to keep track of the tutor schedule and keep tabs on the students, allowing him to efficiently plan ahead.

Some of the new main features include :
Grouping
Payment
Earnings
Add/Edit/Delete/Mark Syllabus
Add/Delete/Copy Subject

This project portfolio consists of the contributions I have made to TutorHelper.

Summary of contributions

  • Major enhancement: added the ability to group the students based on their tuition timing and sort accordingly to day or time.

    • What it does: allows the user to either group students by the day of the tuition or the timing. Grouping by day will sort the students in that day by their tuition timing and grouping by time will sort the students with that tuition timing by the days of the week.

    • Justification: Tutors are busy and want to know how many classes they have to teach in a specific day or how often in a week they have to teach at a specific timing.

    • Highlights: Grouping the students will permanently sort the list of students. This can be undone with the undo command.

  • Minor enhancement:

    • Add Subject and TuitionTiming into TutorHelper (Pull request #11)

    • Updating of test cases for new changes (Pull requests #67, #75, #97, #122)

  • Code contributed: https://nus-cs2103-ay1819s1.github.io/cs2103-dashboard/#=undefined&search=andlimey

  • Other contributions:

    • Project management:

      • Created issues for the different milestones and labelled them according to the severity and priority on Github.

    • Enhancements to existing features:

      • Refined the regex for name, phone and tuition timing (Pull request #193)

      • Wrote additional tests for new features added to increase code coverage (Pull requests #136, #144, #152)

    • Documentation:

      • Added team members' images in AboutUs (Pull request #3)

      • Edited Valid Inputs section in the User Guide (Pull request #204)

      • Added section for group in the User Guide (Pull request #155)

      • Edited User Stories and Use Cases in Developer Guide

      • Added section for group in the Developer Guide (Pull request #68)

      • Updated diagrams and images to be in TutorHelper context (Pull request #227)

    • Community:

      • Reviewed other PRs

      • Reported bugs and suggestions for other teams in the class

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.

Group Students : group

Lists all students with the specified tuition timing.
User can choose to group by time or day of the week.
Format: group TIMING

  • Lists all students with the specified TIMING.

  • The timing refers to either a time or day of the week.

  • The day entered is case sensitive. e.g. Monday is valid but MONDAY isn’t

  • The time entered must be in 12hr format. e.g. 12:00pm is valid but 1200 isn’t

Examples:

  • group Monday
    Show all classes on Monday, sorted based on timing.

  • group 12:00pm
    Show all classes at 12:00pm for the entire week, sorted based on days of the week.

Valid Inputs

Index

Index should always be an integer. It has a maximum range of 0 (exclusive) to 2,147,483,647 (inclusive). Any index outside of this range will automatically make any command an invalid input.

Name

Name should only contain alphabetical characters and spaces, and should not be blank.

Phone

Phone numbers should only be 8 digits long and should not contain spaces.

Email

  • Emails should be of the format local-part@domain

  • The local-part should only contain alphanumeric characters and these special characters, excluding the parentheses, (!#$%&'*+/=?`{|}~^.-) .

  • This is followed by a '@' and then a domain name. The domain name must:

    • be at least 2 characters long

    • start and end with alphanumeric characters

    • consist of alphanumeric characters, a period or a hyphen for the characters in between, if any.

Subjects

Valid subjects are limited to only the following subjects:

Mathematics, Biology, Chemistry, Physics, Economics, Geography, History, English, Art, Music, Computing, Chinese, Malay, Tamil, French, German, Japanese, Literature

  • In order to be valid subjects, the input must be a full substring match of length 3 or more with any of the valid subjects. This is to avoid too short of keyword matching.

  • The match must start at the beginning of the subject name. This is to avoid confusion and multiple matching.

  • Input must be a single word. This is to avoid cases where both invalid and valid keyword are input by user.

  • Matching is case insensitive.

Examples:

  • Biology, Bio, or bio will match with Biology.

  • iology will not match will Biology as the match does not start from the beginning.

  • Ma will not match Mathematics because the length of subtring is shorter than three.

  • phy will only match Physics and will not match Geography as matching is done from the beginning of the string.

  • Maths will not match Mathematics as it is not a full substring match.

  • History Literature will not match anything as it contains more than 1 word.

TuitionTiming

The days of the week are case sensitive and the valid inputs are:

Monday, Tuesday, Wednesday, Thursday, Friday, Saturday, Sunday

  • The time should follow the 12-hour clock (e.g. 12:00pm)

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.

Group Students Feature

Current Implementation

Classes related to Group and its functionality is listed below:

  • TutorHelperParser — Creates a GroupCommandParser object and parses the user’s input.

  • GroupCommandParser — Analyses the input, creates a predicate based on the input and returns a GroupCommand object with the predicate as the argument.

  • GroupCommand — Filters the list based on the predicate, sorts the list and displays it to the user.

Given below is an example usage scenario and how the group mechanism behaves at each step.

Step 1. The user launches the application for the first time.

Step 2. Assuming that the application isn’t empty, the user executes 'group Monday' command to group all students with a class on Monday. The group command will be called by GroupCommandParser.parse(), parsing the argument to check against. The application will check the list and display all students with classes on Monday, sorted based on the earliest timing.

The user can execute list to re-display the full list of students again.
The user can execute undo to undo the sorting done to the list.
The group command is CASE-SENSITIVE. E.g. Passing MONDAY as an input instead of Monday will throw an error.
Only 12-hr timings are valid.

The following sequence diagram shows how the group operation works for day parameter and time parameter:

GroupSequenceDiagramDay
GroupSequenceDiagramTime

User Stories

  1. As a busy tutor, I want to be able to manage my students' schedules individually, so that I can plan my time properly.

  2. As a tutor, I want to be able to find out where my students live and what time I should be there for tuition.

  3. As a tutor, I want to know my students' individual progress so that I know what topics I need to cover for the next tuition session.

  4. As a tutor, I want to keep track of my students' payments so that i know who to collect fees from.

  5. As a tutor, I want to keep track of my monthly earnings so that i can manage my financial accounts.

  6. As a tutor, I want to be able to edit teaching data such as editing my syllabus to keep up with changes in school’s curriculum or updating payments made by students.

Use Cases

  1. Add Student

    System: TutorHelper
Actor: Tutor
MSS:
  1. Tutor inputs to add a student and his/her details.
  2. System adds student details into the database.
  Use case ends.
Extensions:
  2a. Tutor did not key in all mandatory fields.
    2a1. System displays error message informing tutor of invalid index.
    2b1. Resume step 1.

  2. Edit Student

    System: TutorHelper
Actor: Tutor
MSS:
  1. Tutor inputs to edit a student's details.
  2. System edits student details into the database.
  Use case ends.
Extensions:
  2a. Index is out of bounds
    2a1. System displays error message informing tutor of invalid index.
    2b1. Resume step 1.

  3. Delete Student

    System: TutorHelper
Actor: Tutor
MSS:
  1. Tutor inputs student's index to delete.
  2. System deletes student details from the database.
  Use case ends.
Extensions:
  2a. Index is out of bounds
   2a1. System displays error message informing tutor of invalid index.
   2b1. Resume step 1.

  4. List Students

    System: TutorHelper
Actor: Tutor
MSS:
  1. Tutor requests to list students.
  2. System displays current list of students.
  Use case ends.

  5. Group Students

    System: TutorHelper
Actor: Tutor
Precondition: Current list of students is not empty.
MSS:
  1. Tutor requests to group students by day or timing.
  2. System filters the current list of students based on the timing entered.
  3. System sorts the filtered list of students in order of timing.
  4. System displays filtered and sorted list to Tutor.
  Use case ends.
Extensions:
  2a. Input is invalid
    2a1. System displays examples of valid input to Tutor.
    Use case ends.

  6. Record students' payments

    System: TutorHelper
Actor: Tutor
Precondition: Current list of students is not empty.
MSS:
  1. Tutor request to add in payment for a student.
  2. System searches for that student according to index entered.
  3. System adds Payment amount, month and year to student's record.
  4. System displays payment record in browser panel.
  5. System displays successful recording of payment message under command box.
  Use case ends.
Extensions:
  2a. Tutor does not enter all the required entries correctly
    2a1. System displays error message
    2a2. System gives tutor an example of a correct entry.
    2a3. Repeat step 1
  2b. Tutor does not enter a valid student index
    2b1. System displays error message telling tutor that index is invalid
    2b2. Repeat step 1.

  7. Edit students' payments

    System: TutorHelper
Actor: Tutor
Precondition: Current list of students is not empty.
Precondition: Payment for the month and year has been recorded for student before.
MSS:
  1. Tutor request to add in edited payment for a student.
  2. System finds the existing payment entry with same month and year.
  3. System adds new payment entry to existing entry.
  4. System displays payment record in browser panel.
  5. System displays successful editing of payment message under command box.
  Use case ends.
Extensions:
  2a. Tutor does not enter all the required entries correctly
    2a1. System displays error message
    2a2. System gives tutor an example of a correct entry.
    2a3. Repeat step 1
  2b. Tutor does not enter a valid student index
    2b1. System displays error message telling tutor that index is invalid
    2b2. Repeat step 1.

  8. Display tutor’s earnings for that month and year

    System: TutorHelper
Actor: Tutor
Precondition: Current list of students is not empty.
MSS:
  1. Tutor request for earnings for a specific month and year.
  2. System searches for all the payment records made from all the students for that particular month and year.
  3. System adds up all the payment.
  4. System displays total earnings under the command box.
  Use case end.
Extensions:
  2a. System does not find any payment recorded for that month and year.
    2a1. System displays $0 as result.
  2b. Tutor does not enter all the required entries correctly
    2b1. System displays error message
    2b2. System gives tutor an example of a correct entry.
    2b3. Repeat step 1.

  9. Edit students' syllabus for that subject

    System: TutorHelper
Actor: Tutor
Precondition: Tutor has an existing syllabus entry at the index.
MSS:
  1. Tutor request to edit syllabus for a specific student, subject and syllabus
  2. System searches for the student and the respective subject and syllabus at specified index.
  3. System edits the syllabus at the specified index with new syllabus
  4. System displays edited syllabus list in browser panel
  5. System displays successful editing of syllabus under command box.
  Use case end.
 Extensions:
  2a. System does not find any student entry at specified index.
    2a1. System displays error message telling tutor that index is invalid
    2a2. Repeat step 1.
  2b. System does not find any subject entry at specified index.
    2b1. System displays error message telling tutor that index is invalid
    2b2. Repeat step 1.
  2c. System does not find any syllabus entry at specified index.
    2c1. System displays error message telling tutor that index is invalid.
    2c2. Repeat step 1.
  2d. System finds same syllabus entry already exists in subject.
    2d1. System displays error message telling tutor that syllabus already exist.
    2d2. Repeat step 1.