Cascadia College MWC Tutor Reservation System

Cascadia College MWC Tutor Reservation System Software Requirements Specification Iteration 3 06.06.16

Source for Image: http://www.cascadia.edu/

FujaMC Cyrus Sarkosh Fuli Lan Jacob Parkinson Michael Nissenson

MWC TUtor Reservation System

Table of Contents S e c t i o n P a g e

Table of Contents 2

Project Proposal 6

Problem 6

Solution 6

User Description 6

Team Setup and Logistics 6

Work Distribution 7

Schedule 7

Scope and Schedule Revisions 7

Design 8

Requirements 8

Entity-Relationship Diagram 9

Relational Model 11

Normalization 12

Triggers 13

Stored Procedures 17

Database Usability Rules 19

General Rules for Inserting, Updating, and Deleting 19

Testing Methodology 21

Design Specification Document Page 2


Sample Test Data 21

Sample Test Cases 23

SQL Query Statements (More Examples) 27

Results 28

What we Accomplished 28

Mistakes Made 28

Plans for the Future 28

Change Log

R e v i s i o n D a t e W h a t W h y

Version 0.1 (Iteration 0)

13 April 2016

Created Initial Proposal Formed Team and set Bylaws and Schedules

Explain project idea and set rules for teams and meetings.

Version 0.2

25 April 2016 Initial Version of Specifications Added Create initial set of specifications based on meeting with client.

Version 0.3 2 May 2016 Revised Specifications Updated specifications based on meeting with the client.

Version 0.3.1 2 May 2016 Added Initial ER diagram Created initial ER diagram based on updated specifications.

Version 0.4 4 May 2016 Added Problem / Solution statement to proposal Added Schema Updated ER Model

Provide insight into why application is being developed. ER Model modified to be simpler after creating schema.

Version 0.5 8 May 2016 Updated ER Model ER Model modified based on group discussion to better



reflect requirements.

Version 0.5.1 8 May 2016 Added Description of ER Model Provide context for diagram.


11 May 2016 Final Revision before Submission Design ER diagram and Relational Schema.

Version 1.1 18 May 2016 Added Triggers section Provide Context for the Numerous Triggers and their Intended Purpose

Version 1.1.1 18 May 2016 Updated ER Diagram Text To Reflect how Tables are Actually Used

Keep Documentation Current

Version 1.2 20 May 2016 Added Test Methodology Highlight Some Test Cases with Code

Version 1.3 21 May 2016 Added Scope and Schedule Revision Section

Add Rational Behind Modification to Scope

Version 1.4 21 May 2016 Added Stored Procedure Section Provide Context for Stored Procedures

Version 1.5 22 May 2016 Added Schedule Section Provide Estimate of Schedule for Project

Version 1.6 23 May 2016 Added Database Usability Rules Section

Provide instructions on how to use and interact with our database.

Version 1.7 24 May 2016 Added Test Data Section under Testing Methodology Section

Describe How Test Data was Generated


25 May 2016 Final Revision Before Submission

Version 2.1 04 June 2016 Update Testing Methodology Update Documentation to be Current with DB

Version 2.2 04 June 2016 Update Trigger Section Update Documentation to be Current with DB

Version 2.2.1 05 June 2016 Updated Stored Procedure Section Update Documentation to be Current with DB



Version 2.3 05 June 2016 Added Project Results Section Clearly Lay out Results

of Project

Version 2.4 05 June 2016 Added Normalization Assessment Section

Report on Normalization of our DB

Version 2.5 05 June 2016 Added Sample SQL Query Statements Show Sample Queries To Retrieve Information


06 June 2016

Final Revision Before Submission



Project Proposal FujaMC seeks to create a one-on-one tutor scheduling application for Cascadia College’s Math and Writing Center. Currently, students must speak with an office assistant (either through email, phone, or in person) to schedule an appointment. FujaMC seeks to automate the process to make the entire experience quicker and easier through a web based scheduling application.

Problem Cascadia College’s Math and Writing Center (CCMWC) burdens Cascadia College’s (CC) students when attempting to schedule one-on-one tutoring reservations. Students must either email back and forth with an office assistant to have them check when a tutor is available, or go to the CCMWC in person and see if/when tutors are available. The current process wastes a large amount of time for both the office assistant and student when checking the availability of a tutor; this can discourage students from using the service and is a significant time sink for office assistants.

Solution The Cascadia College Math and Writing Center Reservation System (CCMWCRS) is a web application that provides students who want to know the availability of one-on-one tutors with an easy-to-use GUI for searching and booking one-on-one tutoring times.

User Description The application focuses on three types of users

1. Students (also refereed to as tutees) will be able to access tutor’s availability times and reserve one-on-one appointments with tutors.

2. Tutors will be able to have their availability set for the week and confirm or deny a one-on-one appointment request from a student.

3. Office staff will be able to view the availability of tutors, set CCMWC’s operating hours, set the tutor’s availability of the week, and confirm or deny a one-on-one appointment request from a student to a tutor.

Team Setup and Logistics FujaMC consists of the following four members: Cyrus Sarkosh, Fuli Lan, Jacob Parkinson, and Michael Nissenson.



Work Distribution So far, our has work has been almost exclusively collaborative as we’re still primarily designing how our database is to function and how we want the front end of the application to interact with the backend. Once we move farther along in the project, we will start to delegate tasks out to specific individuals.

Schedule Below is a rough outline of when we have expect to have certain features complete.

D e l i v e r a b l e M i l e s t o n e S t a t u s

Initial Requirements Gathering

Iteration 0 (4/13) Done, but still communicating with client for clarifications and updates.

ER Diagram Creation Iteration 0 (4/13) Done

DB Schema Creation Iteration 0 (4/13) Done

Initial DB Creation Iteration 1 (05/09 ) Done

Console Application Design Meeting On 5/18/2016

Done

Test Data Iteration 2 (05/25) Done

Trigger Creation Iteration 2 (05/25) Done

Stored Procedures Iteration 3 (06/06) Done

Console Application Implementation

Iteration 3 (06/06) Done

Test Cases Iteration 3 (06/06) Done

Web Application Late Summer In Progress

Scope and Schedule Revisions The primary schedule revision is that we’re focusing on delivering a console application by the project deadline instead of a web application. Our group is still commited to delivering a web application, but we lack the required ASP.NET experience to put together a web application with



the level of quality that our group wants by the deadline. As a result, we will be aiming for late summer as a realistic timeframe to complete the web app.

Design

Requirements Requirements are broken down by the Writing Center and Math Center. Although both share users, they have very different requirements for how appointments are scheduled. The writing center’s requirements are more straightforward as tutors have set hours and are always available during those hours. The math center requires making a confirmation with both the office assistant and tutor before confirming the appointment, as the tutor may not be available during their scheduled times. They also have slightly different time requirements. All requirements have been discussed with and approved by CCMWC’s office administrator.

F1.0 Tutee (Student) Requirements For Writing Center F1.1) A tutee can view and make an appointment with the system without making an account. F1.2) A tutee will be able to view all available tutoring slots for a given day. F1.3) A tutee cannot view the details of another individual’s appointments. F1.3.1) A tutee can view that an appointment was made in that time slot, if it is taken by someone else. F1.4) A tutee can only book an appointment within a set time window. F1.4.1) A tutee cannot book an appointment that is more than 3 weeks away from the current date. F1.4.2) A tutee cannot book an appointment within the next 12 “business day” hours from the current time. F1.5) To book an appointment, a tutee must enter their Name, Instructor, Course #, E-mail, phone number, and enter in why they want to schedule an appointment in a description box. F1.6) A tutee can book appointments in 45 minute time slots. F1.7) A tutee will be tracked by their e-mail. F1.8) If a tutee has missed 2 or more appointments, and the tutee attempts to make another appointment, the office assistant’s e-mail account will be sent an alert letting them know that the tutee is attempting to make another appointment and block the user from making that appointment. F1.9) If a tutee has had more than 10 appointments in one quarter, and the tutee attempts to make another appointment, the office assistant’s e-mail account will be sent an alert letting them know that the tutee is attempting to make another appointment, and the user will be blocked from letting them make that appointment.



F1.10) If a tutee attempts to make more than 1 appointment per day, block the user from making the appointment and e-mail the office assistant an alert.

F2.0 Office staff / Tutor Requirements for Writing Center 2.1) An office staff can view, modify, and delete appointments. 2.2) An office staff will receive an e-mail ([email protected]) when a new appointment is made. 2.3) A tutor can view their own appointments. 2.4) If a tutee does not show up to an appointment, a tutor or office assistant can mark the tutee as a no show. 2.5) An administrator or office staff can set days as being “closed” and no appointments can be made on this days. 2.5.1) A tutee will see “closed” dates as being completely blocked out. 2.5.2) An administrator or office staff must be able to select repeating dates and times where the MWC is “closed.” 2.6) The office staff will be able to view outstanding requests and approve or deny them.

F3.0 Math Center Specific Requirements 3.1) When a tutee makes a math center appointment, it must be confirmed by both the office assistant AND tutor being scheduled before it becomes “official” and the time is blocked out on the scheduling site. 3.1.1) As a tutor or office administrator, approving or rejecting an appointment is done by being logging in and clicking approve / deny. 3.1.2) A tutor and office assistant must be notified by e-mail when an appointment is made, so they know to accept or reject the appointment. 3.2) A tutee needs to sort by subject a tutor can tutor in (calc 2, chemistry, physics, etc). 3.2.1) An administrator or office assistant must be able to create new subjects that can be tutored. 3.2.2) An administrator or office assistant must be able to associate tutors with subjects that they can teach. 3.3) A tutee cannot book an appointment that is less than 48 “business day” hours away.

Entity-Relationship Diagram The ER diagram below consists of the following entities:

1. Tutor lists the name and e-mail of each tutor. a. Specialty holds all tutor’s “specialties,” which are the subjects a tutor can teach.

Each entry is a unique combination of a tutor and a specialty. A single tutor is likely to have multiple entries on this table.


mailto:[email protected]


i. Valid Specialty consists of all valid specialties as defined by the office

staff. It serves as a way to store constraints for what would be a valid class that a tutor can tutor, avoiding possible overlap.

b. Availability holds a tutor’s valid working hours. It contains an entry for each day a tutor is working; a script is used to generate a range of dates to insert. It handles when a tutor has multiple shifts in a day by also using the start time of their shift as a part of the primary key.

i. Operating Hours provides a table to validate tutor availability. If a tutor’s availability falls outside operating hours of the center, it will reject the time. This provides easy management for the office staff to update any changes to the normal opening and closing times on any day of the week.

ii. Special Event or Holiday (SEH) provides a way to create exceptions to the scheduling system in place as described in 1.b and 1.b.i above. It provides an easy way for the office staff to insert any non-routine changes to the opening and closing hours.

2. Tutee lists the name, e-mail, phone number, and the number of appointments missed. This table represents the student who is to be tutored (i.e tutee).

3. Appointments Made keeps track of appointments that have been made. It uses the tutor, tutee, time, and date as a unique key. It also keeps track of if the request has been approved or not with the is_outstanding attribute.

Design Diagram 1: Student Tutor ERD


https://www.lucidchart.com/documents/edit/efab8add-df53-4e32-92a4-7f05f7168b25/0?callback=close&v=2150&s=612


Relational Model Design Diagram 2: Student Tutor Relational Schema



Normalization All of our tables are normalized to 3NF. We designed our tables from the start to have no multivalued attributes, so they were already flat and in 1NF. All our attributes are fully dependent on their primary key and no attribute is dependent.

● Tutor Table Email → Fname Email → Lname

The tutor table is in third normal form. All the tutor attributes are fully dependent on Email. And there are not transient dependencies.

● Tutee Table Tutee_email → Fname Tutee_email → Lname Tutee_email → Phone Tutee_email → Appointment_missed

The tutee table is in the third normal form. All the tutee attributes are all depended on Tutee_email. And there are not transient dependencies.

● Appointments_Made Table (Appointment_date, Appointment_time) → Tutor_email (Appointment_date, Appointment_time) → Tutee_email (Appointment_date, Appointment_time) → isOutstandingOffice (Appointment_date, Appointment_time) → isOutstandingTutor (Appointment_date, Appointment_time) → Class

The Appointment _Made table is in the third normal form. All the tutee attributes are all depended on Appointment_date and Appointment_time. And there are not transient dependencies.

● Operating_Hours Table OH_date → Open_time OH_date → Close_time

The Operating_Hours table is in the third normal form. All the tutee attributes are all depended on OH_date. And there are not transient dependencies.

● Holiday_Special_Event Table HSE_date → HSE_open_hours HSE_date → HSE_close_hours HSE_date → isOpen



The Holiday_Special_Event table is in the third normal form. All the tutee attributes are all depended on HSE_date. And there are not transient dependencies.

● Tutor_Avaliablity Table (Tutor_email, TA_date, shift_start_time) → shift_end_time

The Tutor_Avaliablity table is in the third normal form. All the tutee attributes are all depended on Tutor_email, TA_date and shift_start_time. And there are not transient dependencies.

● Tutor_Speciality Table TS_email → TS_class_speciality

The Tutor_Speciality table is in the third normal form. All the tutee attributes are all depended on TS_email. And there are not transient dependencies.

● Valid Speciality Table Course_id → Name

The Valid Speciality table is in the third normal form. All the tutee attributes are all depended on Course_id. And there are not transient dependencies.

Triggers The program itself relies on numerous triggers to prevent conflicting updates on different tables. The overarching idea is that office staff maintain the OPERATING_HOURS and HOLIDAY_SPECIAL_EVENT tables; those two tables validate TUTOR_AVAILABILITY, which define when a tutor is on the clock to take appointments. Lastly, APPOINTMENTS are only inserted if the tutor does not already have a conflicting entry in the APPOINTMENTS table and if the appointment falls inside their working hours defined in TUTOR_AVAILABILITY. It is worth noting that a cursor is used to iterate in most of these triggers because it allows for cleaner (to read) triggers and allows error messages to print with less effort via variables stored when the cursor fetches the data. While it’s true that cursors are typically slower, our data sets are small enough (and will remain small enough) that any performance penalty should not be noticeable.

T1.1) InsertIntoHSE The InsertIntoHSE trigger runs when an entry is inserted into the HOLIDAY_SPECIAL_EVENT table. It is intended to remove entries in the TUTOR_AVAILABILITY table that conflict with the holiday being inserted. The trigger will also print out a message of any tutor hours removed. HOLIDAY_SPECIAL_EVENT can also set modified hours, at which point the trigger will check if a tutor’s existing hours conflict with the modified hours.



The trigger works by iterating through TUTOR_AVAILABILITY (using a cursor) and finding all availability that matches the date being inserted into HOLIDAY_SPECIAL_EVENT. If the hours being set for the holiday conflict with TUTOR_AVAILABILITY, it will remove that entry from the TUTOR_AVAILABILITY table and print a message of exactly which row was removed with all relevant information. It is worth noting that if the @is_Open bit is set to false (meaning the MWC is completely closed on that day), all entries corresponding to that day in TUTOR_AVAILABILTY are considered conflicting and are removed. Code Snippet T1.1 shows the two primary checks used to see if hours are conflicting or not when inserting into HOLIDAY_SPECIAL_EVENT. The first if statement checks if the start time being inserted into HSE is after the existing tutor’s shift, if so it removes the entry. The second if statement checks if the end time being inserted into HSE is before the existing tutor’s starting shift time, if so it removes that entry.

Code Snippet T1.1 1

2

3

4

5

6

7

8

9

10

IF @newStart > @tutor_start_shift --If new starting time > existing starting tutor time

BEGIN

print 'Error Code [...]'

DELETE FROM TUTOR_AVAILABILITY where current of @Cursor

END

ELSE IF @newEnd < @tutor_end_shift --@tutor_end_shift is existing tutor end time

BEGIN

print 'Error Code [...]'

DELETE FROM TUTOR_AVAILABILITY where current of @Cursor

END

T1.2) UpdateIntoHSE Trigger UpdateIntoHSE is quite similar to InsertIntoHSE, but with some modifications made to make it work with updating instead of Inserting. The UpdateIntoHSE trigger runs when an entry is updated in the HOLIDAY_SPECIAL_EVENT table. It is intended to remove entries in the TUTOR_AVAILABILITY table that conflict with the holiday being updated. This is so if a holiday is updated with different hours, the tutor will not appear to have any availability during that time if the time periods conflict. The trigger will also print out a message of any tutor availability that has been removed. The trigger works by iterating through TUTOR_AVAILABILITY (using a cursor) and finding all availability that matches the date being updated in HOLIDAY_SPECIAL_EVENT. If the hours being set for the holiday conflict with TUTOR_AVAILABILITY, it will remove that entry from the TUTOR_AVAILABILITY table and print a message of exactly which row was removed with all relevant information. It is worth noting that if the @is_Open bit is set to false on the holiday



being inserted, all entries corresponding to that day in TUTOR_AVAILABILTY are considered conflicting and are thus removed.

T2.1) InsertIntoOP Trigger The InsertIntoOP Trigger runs when an entry is inserted into the OPERATING_HOURS. It is intended to remove entries from TUTOR_AVAILABILITY if they do not match the hours defined in the new OPERATING_HOURS entry.

The trigger works by iterating through TUTOR_AVAILABILITY (using a cursor) and finds all entries that match the date being inserted. If the hours associated a TUTOR_AVAILABILITY conflicts with the hours being inserted into the OPERATING_HOURS table, we delete the associated TUTOR_AVAILABILITY entry. NOTE: Normally, an appointment cannot be inserted until there is a matching date in the OPERATING_HOURS table (checked via the TrigAddAppt trigger (T3.1)), so this trigger should theoretically almost never delete an entry in TUTOR_AVAILABILITY. It is here in case a couple of edge cases occur. UpdateOPEntry (T2.2) is much more likely to cause deletions of entries from TUTOR_AVAILABILITY.

T2.2) UpdateOPEntry Trigger UpdateOPEntry is quite similar to InsertIntoOP, except written to work with Updating instead of Inserting. The UpdateOPEntry Trigger runs when an entry is updated in the OPERATING_HOURS table. It is intended to remove entries from TUTOR_AVAILABILITY that conflict with the hours that are updated. The Trigger works by iterating through TUTOR_AVAILABILITY (using a cursor) and finds all entries that match the date being updated. If they match, it removes the associated entry from TUTOR_AVAILABILITY.

T3.1) TrigAddApptTrigger The TrigAddApptTrigger runs when an entry is inserted into the APPOINTMENTS table. It is intended to verify that an appointment being inserted is valid by checking that first the appointment does not conflict with another appointment already made in the APPOINTMENTS table and second That the appointment is made for a valid time based on entries in the TUTOR_AVAILABILITY table.



This is an interesting trigger as APPOINTMENTS only stores the start time of an appointment, not the end time of appointments. As a result, the trigger needs to check if if the appointment being inserted falls between the start time and the derived end time of an already existing appointment. This is done with two sets of checks. The first set checks if the new appointment’s start time falls after the existing start time and before the existing end time. The second set checks if the new appointment’s end time falls before the existing end time and then if the new appointment’s end time falls before the existing appointments start time. If either set of checks ends up as true, there’s a conflict, and we rollback the insertion. After checking for existing appointment conflicts, the trigger then verifies the start and end time of the new appointment exists in the specified tutor’s working schedule, and will reject the insertion if it is not. Code Snippet T3.1 shows the checks that the trigger performs when checking if there is a conflicting appointment. The most interesting part of this is that TSQL does not have a trigger that can check before an insertion takes place. Instead, when a trigger is called on insert, it will actually insert the row first, then perform the trigger. This means our trigger had to be designed so that we ignore the row that was just inserted when looking for conflicting appointments.

Code Snippet T3.1 1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

-- TSQL triggers on INSERT insert the row first, then perform the trigger, so the first

-- check we do is to make sure we’re not comparing the row we just inserted to itself

-- as that will return a false positive for a conflicting appointment.

IF (@SchedTime = @APP_Existing_Start) -- Check if row is the one just inserted

BEGIN

FETCH NEXT FROM [...] --Fetch next row; snipping code to save space

CONTINUE --Skip to next iteration of while loop

END

IF (@SchedTime >= @APP_Existing_Start) --If inserted start time >= existing appt start

BEGIN

IF (@SchedTime < @APP_Existing_End) --And if inserted start time < existing end

BEGIN

PRINT ‘Error Message with details of conflict [...]’

ROLLBACK -- Revert table to before last insert

RETURN -- No need to check further, exit trigger.

END

END

IF (@SchedTimeEnd <= @APP_Existing_End) --If inserted end time <= existing appt end

BEGIN

IF (@SchedTimeEnd > @APP_Existing_Start) --If inserted end time > existing start

BEGIN

PRINT ‘Error Message with details of conflict [...]’

ROLLBACK -- Revert table to before last insert

RETURN -- No need to check further, exit trigger.

END

END



T4.1) appointCheckMaxPerWeek Trigger The purpose of this trigger is to verify that a tutee cannot make more than 1 appointment per week, which is based on a requirement given to us by the Math and Writing Center staff. It is triggered on insert of a new appointment into the APPOINTMENTS table. It primarily uses a single IF EXISTS (SELECT …) statement found in Code Snippet T4.1 to determine if there is a conflicting appointment. If the select statement returns something, that means an appointment for that tutee already exists within a week in either direction, either before or after. As a result, if an appointment exists in that time frame, do a ROLLBACK, throw an assert, and print out an error message.

Code Snippet T4.1 1

2

3

4

5

6

7

8

9

10

11

12

--All variables (Preceded by @) are from the appointment being inserted

IF EXISTS (select * FROM APPOINTMENTS A

WHERE (A.APP_Tutee_email = @SchedTuteeEmail AND --Get matching appointments for tutee

( (A.app_date <= DATEADD(dd, 6, @SchedDate)

AND A.app_date >= @SchedDate) --Is appointment within a week AFTER existing appt?

OR (A.app_date <= @SchedDate --Is appointment within a week BEFORE existing appt?

AND A.app_date >= DATEADD(dd, -6, @SchedDate)))

AND ( (@TimeOfAPPT != A.APP_Time)

OR (@SchedDate != A.app_date)

OR (@TutorEmail != A.Tutor_email ))

) ) -- The final AND checks that we aren't pulling the appointment that was just

-- inserted (as TSQ triggers on inserts always happen AFTER an insert)

Stored Procedures

P1.1) insertOHForDateRange The insertOHForDateRange allows for easy insertion of operating hours for a supplied range of dates. The stored procedure can be invoked via Code Snippet P1.1.0. If the day passed in does not match the day of the week specified, it will automatically advance to the next Monday after the date. For example, if someone passes in Monday and 2016-06-05 (a Sunday), it will automatically advance to the next monday, 2016-06-06, and start inserting there.

Code Snippet P1.1.0 1

2

3

4

--To insert operating hours from 14:00 - 15:00 for JUST Mondays between 05-14 to 05-28

EXEC insertOHForDateRange Monday, '2017-05-14', '2017-05-28', '14:00:00', '15:00:00';

--To insert operating hours from 09:00 to 15:00 for JUST Fridays between 04-14 to 05-28

EXEC insertOHForDateRange Friday, '2017-04-14', '2017-05-28', '09:00:00', '15:00:00';

It works by first checking if the day passed in matches the starting date passed in. If it doesn’t, it advances the date forward to match it. It then iterates through each of the specified day, and



inserts on those days with the designated hours. Code Snippet P1.1.1 shows the main loop that handles the inserts for the Stored Procedure. @Date_start is the only variable that is advanced, and when @Date_start ends up later than @Date_end, we stop the loop.

Code Snippet P1.1.1 1

2

3

4

5

6

7

WHILE (@Date_start <= @Date_end) --This loop continues to insert until date_start

BEGIN --passes date_end.

INSERT INTO OPERATING_HOURS(OH_Day_of_week, Open_time, Close_time)

VALUES (@Date_start, @Time_start, @Time_end);

SET @Date_start = DATEADD(wk, 1, @Date_start); --Advance the start date one week

END

P1.2) insertAvailabilityForTutor insertAvailabilityForTutor is quite similar to insertOHForDateRange above, with one small change. When invoking the function, a tutor’s e-mail must be passed in as well. Code Snippet P.1.2 shows how to invoke the stored procedure. Note the only difference is just the e-mail being added.

Code Snippet P1.2 1

2

3

4

--To insert into Tutor_availability for [email protected] on just Mondays between the

--dates 2017-05-14 and 2017-05-28 for the hours of 14:00 to 15:00

EXEC insertAvailabilityForTutor Monday, '2017-05-14', '2017-05-28', '14:00:00',

'15:00:00', '[email protected]';

The only major difference is that when an insert is done, it inserts the Tutor’s e-mail as well. Everything else about the stored procedure is identical to insertOHForDateRange.

P2.1) pullTimeSlots pullTimeSlots accepts just one parameter, a date value. While it is easy to select all appointments that are booked for a given day, it is actually quite tricky to retrieve information on what time slots are available to be booked. pullTimeSlots is intended to return all open time slots that a student could book an appointment during. pullTimeSlots will change in subsequent revisions and should be broken up into smaller stored procedures once we understand how best to store and pass information to a front end. Code Snippet P2.1 shows how to invoke the script.

Code Snippet P2.1 1

2

--Show all open tutoring slots for 2016-05-16.

EXEC pullTimeSlots @Date_to_check = '2016-05-16'

For now, however, pullTimeSlots currently does two things:

1. It prints out all available and taken time slots to the console.



2. Stores all available time slots for a given day in a temporary table that can then be easily

accessed by other programs.

Database Usability Rules Our database is set up with a very strict set of rules enforced by triggers. This section is to provide clarity on how to interact with the database in a meaningful way. The end user is never intended to interact directly with the SQL database, instead we will always provide a proxy (through a console or web application) for them to interact with it, thus eliminating any confusion on their end. The crux behind the complexity can be seen in UR Diagram 1.1. APPOINTMENTS rely on TUTOR_AVAILABILITY to validate when an appointment can or cannot made. Similarly, TUTOR_AVAILABILITY relies on OPERATING_HOURS and HOLIDAY_SPECIAL_EVENT to determine when a tutor’s shift can be inserted. When a change is made in OPERATING_HOURS or HOLIDAY_SPECIAL_EVENT, that change propagates down to TUTOR_AVAILABILITY, when then propagates down to APPOINTMENTS. For example, if a holiday (such as Memorial Day) is added to the HOLIDAY_SPECIAL_EVENT table, all tutor shifts on that same day will be removed, and all appointments that were booked are also removed. All items that were removed are output to the console to keep track of changes.

General Rules for Inserting, Updating, and Deleting VALID_SPECIALTY, SPECIALTY, TUTOR, and TUTEE are all fairly flexible in the types of updates they will accept. As long as domain and foreign key constraints are met, no further triggers are used to validate them. When INSERTING or UPDATING an entry in the APPOINTMENTS, TUTOR_AVAILABILITY, OPERATING_HOURS, or HOLIDAY_SPECIAL_EVENT tables, all inserts and updates should be done one at a time, or the corresponding trigger will throw an assertion. This will not be an issue in the final application, as the end user will be using a console or web application to interact with the database.



The primary rationale behind this design decision is that these updates (Inserting, Updating, or Deleting) can cause a large cascade deletion or modification of many different items. For outputting each item that is deleted or modified, we found it significantly easier to restrict modification of tables to one row at a time. See UR Diagram 2.1 for an example showing how to insert multiple items without causing an insertion error.

UR Diagram 2.1: How to Insert 1

2

3

4

5

6

7

8

9

10

-- This is the proper way to insert multiple entries:


VALUES ('2000-03-30', '09:00:00', '19:00:00');


VALUES ('2000-03-31', '09:00:00', '19:00:00');

--This is an incorrect way to insert multiple entries and will result in an assert:


VALUES ('2000-03-30', '09:00:00', '19:00:00'),

('2000-03-31', '09:00:00', '19:00:00');

Specific Rules for Inserting and Updating an entry in the APPOINTMENT table To INSERT or UPDATE an entry into the APPOINTMENTS (APPT) table, there must be an entry in TUTOR_AVAILABILITY (TA) with a matching date. Further, the row being inserted into APPT must start and end during that same TA entry’s start and end times. For example, if the appointment being inserted is from 11:00 to 11:45, there must be a matching TA entry that starts on or before 11:00 and ends on or after 11:45. Finally, there cannot already be another entry in the APPT table that conflicts with the row being inserted. An appointment is considered conflicting if it’s on the same day, with the same tutor, and their start or end times overlap. An example of start and ending time’s overlapping is if one tutee has an existing appointment from 12:00 to 12:45, and another tutee tries to book an appointment from 12:30 to 13:15; there’s 15 minutes of overlap, so the trigger will reject the insertion.

Specific Rules for Inserting or Updating an entry in the TUTOR_AVAILABILITY table To INSERT or UPDATE an entry into the TUTOR_AVAILABILITY (TA) table, there must be an entry in OPERATING_HOURS(OH) or HOLIDAY_SPECIAL_EVENT (HSE) that matches the date being inserted. Further, the hours set in the TA row being inserted, must correspond to hours that already exist in HSE or OH for the corresponding date, or else the insertion will be rejected.



Testing Methodology

Sample Test Data The file SQLQuery1.sql contains insertion data for populating the database. It is listed directly after the Triggers and before our test cases. Nearly all of our sample data is based on actual data from Cascadia’s Math and Writing Center for the Spring 2016 quarter. Some data has been modified to remove contact information (primarily emails). Each section of the Sample Test Data part of the documen texplores how each type of sample data was generated based on the table they’re from.

TUTOR Table Sample Data Entries for the TUTOR table were generated based on the list of tutors provided by the Cascadia College’s Math and Writing center coordinator. All e-mails have been modified to be in the generic form of [email protected]. This list includes both tutors that take part in 1-on-1 tutoring and those that are just general drop-in center tutors. This was done to include as many different types of tutors as possible.

VALID_SPECIALTY Table Sample Data Entries for the VALID_SPECIALTY comes from the list of all courses that are tutored at the Math and Writing Center, not just those that are part of the 1-on-1 tutoring center. Note that the writing center does not have specialties as the math center does, and consequently it only contains a “Writing” entry that best corresponds to ENGL&101. Data was pulled from both the list found in the MWC and online on Cascadia’s course catalog.

TUTOR_SPECIALTY Table Sample Data Entries for the TUTOR_SPECIALTY database comes from a list of tutors and their matching specialties of what they can tutor. It includes all tutors and their associated specialties that do 1-on-1 tutoring and some tutors that just do drop in center tutoring to get some tutors that will be active and some that will not.

OPERATING_HOURS Table Sample Data The OPERATING_HOURS for the quarter are based on the actual operating hours for the Math and Writing Center for the Spring 2016 quarter. A C# script was used to generate the entries, and the full script to generate the entries can be found in the PrintSetOfDatesForInsert.cs file. The script can also generate any range of dates that is inserted for either the OPERATING_HOURS table or TUTOR_AVAILABILITY table.



The script is fairly straightforward. The user specifies an start and end time, then a starting and end date, then the days of the week it applies to (so if we only want to generate operating_hours for specific date with the matching times). This allows someone to quickly generate entries for an entire quarter. Code Snippet Data 1 was included to show how the code formats the inserts used for our test data. The snippet iterates through all generated dates that are stored in a list, and prints out each entry based on the type of data the user wants.

Code Snippet Data 1

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

foreach(var date in dates) //Output dates in proper insert format

{

string sqlFormattedDate = date.ToString("yyyy-MM-dd");

if (input == 1) //If User Picked Operating Hours

{

Console.WriteLine("INSERT INTO OPERATING_HOURS(OH_Day_of_week, Open_time,

Close_time)");

Console.WriteLine("VALUES '{0}', '{1}', '{2}');",sqlFormattedDate,

StartTime, EndTime);

}

if (input == 2) //If User Picked Tutor Availability

{

Console.WriteLine("INSERT INTO TUTOR_AVAILABILITY (Shift_start,

Shift_end, Day_of_week, Tutor)");

Console.Write("VALUES "('{1}', '{2}', '{0}', '{3}');",sqlFormattedDate,

StartTime, EndTime, email);

}

}

TUTOR_AVAILABILITY Table Sample Data TUTOR_AVAILABILITY was made from actual shift schedules for 1-on-1 tutors from the Math and Writing Center for Spring 2016. A C# script was used to generate the entries, and the full script to generate the entries can be found in the PrintSetOfDatesForInsert.cs file. The script can also generate any range of dates that is inserted for either the OPERATING_HOURS table or TUTOR_AVAILABILITY table. Code Snippet Data 1 shows how the actual inserts are formatted for the user. For additional details on how the script works, see the OPERATING_HOURS Table Sample Data section. The only major difference how the script works when generating data for TUTOR_AVAILABILITY is that a tutor is specified for TUTOR_AVAILABILITY, and the actual inserts it generates are different to match the type of insert being created.



TUTEE Table Sample Data The TUTEE table contains the only data that is not based on actual data from the Math and Writing Center. This is because we felt it would be inappropriate to use actual tutee names. The names are either one of our team member’s names, random words chained together, or a combination of our names and a number. Each type of data (IE phone numbers, names, and so on) do have the correct type of data to be inserted, but the values themselves are made up.

APPOINTMENTS Table Sample Data The APPOINTMENTS table contains real data, except for the tutee’s names. Everything else contains a data from actual time slots that can exist for an appointment. When creating data, we tried to create a couple different scenarios. We tried to fill up a tutor’s schedule completely with appointments for one day. We also tried to insert appointments for another tutor on that same data. We also added appointments for different days with the same and different tutors.

HOLIDAY_SPECIAL_EVENT Table Sample Data The HOLIDAY_SPECIAL_EVENT table contains the fewest number of sample inserts because we tried to keep it as realistic as possible. The only days we were aware of this quarter when the center would be closed would be for Memorial Day on May the 30th and for a non-instructional day on April 29th. We added a made up holiday on May the 26th with reduced hours to make sure we had proper coverage of all days that were closed. One interesting thing to note is that because we are inserting three entries into HOLIDAY_SPECIAL_EVENT, our sample data will actually go back and delete TUTOR_AVAILABILITY that conflicts with these dates when we perform inserts for all our sample data.

Sample Test Cases See the bottom of the file CreateDBandTriggers.sql to see additional test cases we’ve developed.. Most of our test cases revolve around testing the triggers used to maintain consistency in our DB. If one of those has a major issue, then our entire DB breaks down and may generate data that doesn’t make sense.



TC1.1) TUTOR_AVAILABILITY Trigger Test Cases For testing our TUTOR_AVAILABILITY (the table that holds a tutor’s shifts) triggers, we test that we can only insert an entry into TUTOR_AVAILIBILITY if it falls within the bounds of OPERATING_HOURS (OH) or HOLIDAY_SPECIAL_EVENT (HSE). For example, code snippet TC1.1 tests if we can insert a tutor’s shift if there is no corresponding entry in OH or HSE.

Code Snippet TC1.1 1

2

3

4

5

6

7

-- **test case: inserting tutor_availability that does not have a corresponding entry

-- in operating_hours or holiday_special_event

-- should fail (with exception thrown as it rolls back) as no hours are set for

-- 2016-01-01

insert into tutor_availability (shift_start, shift_end, day_of_week, tutor)

values ('06:00:00', '10:00:00', '2016-01-01', '[email protected]');

GO

Similarly, Code Snippet TC1.2 tests if we can insert a tutor’s shift when OH exist for the day, but the tutor’s hours fall outside of it. We have similar tests that check if just the start time does not match, or if the end time does not match.


2

3

4

5

6

7

-- **test case: inserting tutor_availability when operating_hours exists, but there is

-- a start and end time mismatch.

-- should fail (with exception thrown as it rolls back) as some operating hours are set

--for 2016-5-20, but the end hours we're attempting to set are after the center closes.



GO

Code Snippet TC1.3 tests when a tutor’s shift matches an entry in OH, but do not match hours in a corresponding HSE entry. This means that we’re trying to insert tutor hours into a day that someone has specified as a closed holiday, meaning it will block all entries that someone tries to make.


2

3

4

5

6

7

8

9

10

-- **test case: inserting tutor_availability when operating_hours exists, and start and

-- end times are within boundaries, but HSE has it closed

-- should fail (with exception thrown as it rolls back) as even though hours are valid

-- in OPERATING_HOURS, HSE has reduced hours.

-- This test checks if we're allowed to insert availability when availability hours

-- match OH, but do not match EITHER start or end times of HSE

-- It should fail because HSE hours take precedence of OH hours.

INSERT INTO OPERATING_HOURS(OH_Day_of_week, Open_time, Close_time) --Inserting new

-- operating_hours for the test.

VALUES ('2006-06-06', '09:00:00', '19:00:00');



11

12

13

14

15

16

17

18

19

20

21

INSERT INTO HOLIDAY_SPECIAL_EVENT (hse_date, isopen, hse_open_time, hse_close_time)

values ('2006-06-06', 1, '10:00:00', '11:00:00' ); --HSE from 10:00 to 11:00.



GO

DELETE FROM HOLIDAY_SPECIAL_EVENT --Cleaning up HSE and OS inserts by deleting inserts

WHERE HSE_Date = '2006-06-06';

GO

DELETE FROM OPERATING_HOURS

WHERE OH_Day_of_week = '2006-06-06';

GO

TC2.1) APPOINTMENT Test Cases The appointment table is at the heart of our database, and thus requires fairly extensive testing. The section will highlight some of the test cases used. One of the requirements provided to us is that a tutee can only make one appointment per week. Code Snippet TC2.1 show a couple ways this was tested. First a valid appointment is inserted in a new time slot that was not occupied by the sample data that was created. Then, check a day before and a day after the insert to make sure it fails.


2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

--Insert should succeed as no conflicts.

insert into appointments (app_date, app_time, isoutstandingoffice, isoutstandingtutor,

tutor_email, class, app_tutee_email)

values ('2016-04-19', '12:00:00', 0, 0, '[email protected]', 'Help with an essay on

something or other.', '[email protected]');

GO

--Try inserting a day BEFORE an appt (should fail w/ printed message)





GO

--Try inserting a day AFTER an appt (should fail w/ printed message)





Beyond the code snippet, we also checked exactly a week before and after the appointment (should succeed), six days before and after the appointment (should fail), try to insert the same



day (should fail), and various combinations of different tutors, same tutee, and different lengths of time. Another (more basic case) is trying to make an appointment when a tutor is not working. Code Snippet T2.2 shows some of the test cases we used. It shows two fairly basic examples of tests we did ran. The first shows when we try to insert an appointment on a day when a tutor has no hours for a day. The second test shows when we try to insert an appointment on a day when a tutor does have hours, but the insert is outside those hours.


2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

-- **test case: inserting an appointment when a tutor does not have hours on a day

-- should fail (with exception thrown w/ ROLL BACK) as daphne does not have any hours

-- on 2016-05-25



values ('2016-05-25', '09:00:00', 0, 0, '[email protected]', 'This shouldn''t work,

English edition', '[email protected]');

GO

-- **test case: inserting an appointment when a tutor does have hours on a day, but

-- appointment time is completely outside range. It should fail (with exception thrown

-- as it rolls back). John's hours on 2016-05-25 do not start until 10:00:00 and end at

-- 13:00:00 so both start and end of appointment are outside John's working hours.



values ('2016-05-25', '09:00:00', 0, 0, '[email protected]', 'This shouldn''t work,

English edition', '[email protected]');

GO

After those test cases, we also test for if the tutor’s hours fall within the start of the appointment, but the appointment would run on past them, at which point we reject the appointment. We also try the opposite case where if the appointment would start before a tutor’s starting hours, but end during their working hours, we reject the appointment. There are many more test cases that were used at the bottom of the SQLQuery1.sql text.



SQL Query Statements (More Examples) Each table is used in at least one of the queries below.

S Q L S t a t e m e n t s P u r p o s e

SELECT T.Fname as 'TUTEE NAME' FROM APPOINTMENTS A, TUTEE T WHERE T.Tutee_email = A.APP_Tutee_email AND A.APP_Date = GETDATE();

List all tutee names that have appointments for the current Date. This will help office staff to determine which tutees have appointments for a given day.

SELECT DISTINCT(TA.Tutor) FROM TUTOR_AVAILABILITY TA WHERE TA.Day_of_week > '2016-05-22' AND TA.Day_of_week < '2016-05-28'

List all tutor’s who work between the dates 2016-05-22 and 2016-05-28. This could let office staff know which tutor’s are available for a given date range.

SELECT * FROM VALID_SPECIALTY VS WHERE VS.Course_id LIKE '%MATH%'

List all valid specialties for math courses. Could let office staff know which math courses exist in case they need to add more.

SELECT * FROM TUTOR_SPECIALTY TS WHERE TS.TS_email = '[email protected]'

List all courses that Lily can tutor. Good for filtering results to potential tutees or office staff.

SELECT DISTINCT(TS.TS_course_specialty) AS 'Tutorable Courses' FROM TUTOR_SPECIALTY TS, TUTOR_AVAILABILITY TA WHERE TA.Day_of_week = GETDATE() AND TS.TS_email = TA.Tutor

List all courses that can be tutored today. Useful for tutors to know so they can find out what’s available.

SELECT H.HSE_Date as 'Date', H.Description as 'Event' FROM HOLIDAY_SPECIAL_EVENT H

List all special holiday events and their description. Useful to find out when the center will be closed.

SELECT * FROM OPERATING_HOURS OH WHERE oh.OH_Day_of_week >= GETDATE() AND oh.OH_Day_of_week <= DATEADD(wk,1,GETDATE())

List operating hours for the next week. Useful to know when the center would be open.



Results

What we Accomplished We created a fully functional database for our tutoring center application. It verifies that all data being inserted or updated makes logical sense through a complex web of triggers and stored procedures. It also stores information in such a way that it can be easily retrieved. We also created a console application that has all the basic functionality required of the application, without the ease of use features that would be required of the web application. As for personal skills gained, we learned a huge amount about database design. We learned a lot about creating triggers and how they interact. We also learned a lot about TSQL and how to use it to create triggers and stored procedures.

Mistakes Made The largest mistake we made was vastly underestimating the amount of time it would take to learn to create a web application with ASP.NET. It ended up being significantly more difficult than we expected. As a result we ran out of time and transitioned to a console application instead. Beyond that, we also learned that we needed to design how our triggers were to interact upfront. Because of how complex our triggers were, we ended up wasting some time creating some unnecessary triggers because we didn’t plan far enough ahead.

Plans for the Future We plan to continue meet over the summer to try and complete the web application that the math and writing center would be able to use. We are still maintaining contact with the office staff at the math and writing center and providing updates for them as to our progress.


Date post:	13-Jan-2017
Category:	Engineering
Upload:	fuli-lan
View:	147 times
Download:	2 times

Cascadia College MWC Tutor Reservation System

Engineering