Slide 1

Developed by Dane Baldwin and David Riggleman

Slide 2

Mission Statement A+ Student Planner brings all aspects of a students calendar into a centralized database, managing school events such as homework and tests while also keeping track of current and past grades and presents this information through a user-friendly graphical user interface.

Slide 3

Mission Objectives To develop an application that interfaces with the database system and essentially acts as a functionally enhanced student planner/grade-book. To include, for the student planner part, a calendaring aspect to store homework assignments, quizzes, and exams.

Slide 4

Mission Objectives To include, for the grade-book part, the functionality to enter the grade received for each homework assignment, quiz, or exam. To calculate current grades for each class, always displaying the overall current grade information while also allowing for the generation of custom grade reports filtered by professor, class, current grade, or due date.

Slide 5

System Definition Scope and Boundaries: limit access to a single user Typical User: student who does not possess any previous experience with operations and does not know SQL (a nave user) User Views: not necessary with one user, but will be used for tables frequently joined in queries

Slide 6

Basic Requirements The application will provide a user friendly interface for the A+ Student Planner environment. A user form will allow for the easy creation of school events (homework assignments, quizzes, tests, etc.) The user will be easily able to edit, manage, and remove these events if desired. The user will have the opportunity to set up classes, specifying the grading scale, percentage breakdown by category (and creating new categories if not already existing), and additional class information, such as professors office hours and contact information.

Slide 7

Basic Requirements The application will calculate and display the current grades in each course. The user will be able to easily edit grades already entered into the program The user will be able to generate custom assignment reports based on keywords in the assignment name, the class, the professor, assignment type (HW, Quizzes, Tests, etc.) and the date/time of the event The user will be able to generate custom grade reports based on the name of the class, the number of credits, the current grade in the class, and the professor.

Slide 8

Optional Requirements Our program will interface with Google Calendar so that any events added within our program will also be added to the users Google Calendar Users will be provided with additional filters for assignment and grade reports

Slide 9

Conceptual Database Design Identify Entity Types OfficeHour Phone Professor ClassProfessor Class GradeCategory GradingScaleValue GradeLetterPoint Event GradedAssignment

Slide 10

Conceptual Database Design Identify Relationship Types Professor 0 or more phones (Phone) 0 or more office hours (OfficeHour) 0 or more classes (ClassProfessor) Class 0 or more professors (ClassProfessor) 1 or more grade categories (GradeCategory) 0 or more events (Event) 1 or more grading scale values (GradingScaleValue) 1 Point Value (Grade Letter Point)

Slide 11

Conceptual Database Design Identify Relationship Types Event 0 or 1 graded assignments (GradedAssignment) GradedCategory 0 or more graded assignments (GradedAssignment) GradeLetterPoint 0 or more grading scale values (GradingScaleValue)

Slide 12

Conceptual Database Design

Slide 13

Logical Database Design Strong Entities OfficeHour, Professor, Class, Event, GradeLetterPoint Weak Entities Phone, ClassProfessor, GradeCategory, GradedAssignment, GradingScaleValue

Slide 14

Logical Database Design Validate Relations Using Normalization All relations in BCNF No partial dependencies No transitive dependencies All determinates are candidate keys

Slide 15

Physical Database Design Base Relations Professor (ProfID, Title, FirstName, LastName, Email, OfficeLocation) Alternative Key: Email Phone (PhoneNumber, ProfID, Type) Foreign Key: ProfID Office Hour (OfficeHoursID, OnMonday, OnTuesday, OnWednesday, OnThursday, OnFriday, StartTime, EndTime, ProfID Foreign Key: ProfID Alternative Key: OnMonday, OnTuesday, OnWednesday, OnThursday, OnFriday, StartTime, EndTime, ProfID

Slide 16

Physical Database Design Base Relations Class (ClassID, Name, Credits, OnMonday, OnTuesday, OnWednesday, OnThursday, OnFriday, StartDate, EndDate, StartTime, EndTime, Location, CurrentGrade, CurrentLetterGrade, FinalLetterGrade) Alternative Key: StartDate, EndDate, StartTime, EndTime, OnMonday, OnTuesday, OnWednesday, OnThursday, OnFriday, Location Foreign Key: CurrentLetterGrade Foreign Key: FinalLetterGrade

Slide 17

Physical Database Design Base Relations ClassProfessor (ProfID, ClassID) Foreign Key: ProfID Foreign Key: ClassID Event (EventID, Title, Description, Location, StartDateTime, EndDateTime, IsAllDay GradedAssignment (EventID, AssignmentName, Grade, GradeTotalWorth, ClassId, Type) Foreign Key: EventID Foreign Key: Type Foreign Key: ClassID

Slide 18

Physical Database Design Base Relations GradeCategory (Type, ClassID, Percentage, CategoryGrade, GradingMethod) Foreign Key: ClassID GradeScaleValue (GradeLetter, ClassID, BottomPercentage) Alternative Key: ClassID, BottomPercentage Foreign Key: GradeLetter Foreign Key: ClassID GradeLetterPoints (GradeLetter, Point) Alternative Key: Point

Slide 19

Physical Database Design Derived Data CategoryGrade (GradeCategory) CurrentGrade (Class) CurrentLetterGrade (Class) Information is frequently retrieved, so additional attributes chosen for efficiency

Slide 20

Physical Database Design General Constraints In all tables, end time must be greater than or equal to start time All grades information must be positive (no negative grade values) Credits must be positive Percentages in GradeCategory and GradingScaleValue must be between 0 and 100 (note that these are not related to a grade, which obviously can be above 100%) The point value for a grade must be positive

Slide 21

Physical Database Design Translate Logical Data Model to Target DBMS SQLite Supports most of SQL 92 standard Supports primary and alternative keys Foreign keys supported by first executing after each connection PRAGMA foreign_keys = true Allows for null data Enforces CHECK constraints Does not support domains Does not support stored procedures Supports triggers

Slide 22

Physical Database Design File Organization B+ Trees used for storing all data and B trees used for indexes Choose Indexes Most tables will remain table Main table that will grow large in size is Event table StartDateTime and EndDateTime chosen for indexes Will be used frequently in queries to order by

Slide 23

Physical Database Design User Views ClassProfessorView Does a Double NATURAL JOIN providing detailed information on professors for each class and detailed information on the classes each professor teaches FullEventView Combines Event and GradedAssignment table as these two tables are closely tied together and information from both is frequently needed

Slide 24

Physical Database Design Security Mechanisms Encryption Uses RSA Algorithm

Slide 25

DBMS Selection Need to use an embedded database First considered Access Easy interface with C# Many limitations such as with stored procedures and triggers Instead went with SQLite (most widely deployed database engine in the world) Little setup and configuration Actively maintained and supported Core SQL standard is enforced

Slide 26

DBMS Selection Fast and lightweight One disadvantage is problems with multiple writers, but this is not a concern with the needs of our application Data types not strictly enforced

Slide 27

Application Design Menu Options File: database encryption, reset database, remove old events, exit application Add: add classes, professors, and events Edit: edit and delete classes, professors, and events Contact: change mail settings and launch form to email a professor and view contact information Sync Settings: enable syncing of events with Google Calendar

Slide 28

Application Design Menu Options View Office Hours: display professors office hours of current classes View Schedule: display current class schedule Finals Calculator: calculate grade needed on final in order to achieve a certain grade in a class

Slide 29

Application Design Left Panel Display list of nearest upcoming events Display current grades in each active class Display current semester and overall GPA

Slide 30

Application Design View Calendar Page View upcoming events Double click to edit Easily delete selected events Add event at selected time slot Change number of days to show Generate Assignment Report Page Display list of upcoming assignments filtered by professor, class, assignment type, keywords, and date

Slide 31

Application Design Generate Grade Report Page Display detailed grade report for current classes, optionally filtered by professor, classes, number of credits, and upper and lower grade boundaries Edit Grades Page Allow user to select all current classes or a single class and easily edit grades User can reset (undo) any changes made before saving

Slide 32

Application Design Screenshot

Slide 33

Database Implementation Stored Procedures Not supported by SQLite Because of nature of embedded databases, logic easily captured by higher level programming language If supported, would use for calculating GPA

Slide 34

Database Implementation Triggers Used to update grade information Null values ignored in calculation Hierarchy and propagation of triggers

Slide 35

Application Implementation Uses Calendaring Component Called DayView Calendar Licensed under GPL Open Source License Multi-threaded Keeps GUI responsive Especially when sending messages or involving sync actions Uses BackgroundWorker Class Two main events

Slide 36

Application Implementation Syncing with Google Calendar Uses Google Calendar API Handles Adds, Updates, and Deletes Application Security Utilizes Data Protection API (DPAPI) to encrypt and store Google Account password Manages keys and certificates Database password set to SHA2 hash of the password the user chooses

Slide 37

Testing Best way to test was to use program as a typical user would Tested each component Tried to test situations that could cause errors if our code was not written to handle such situations

Slide 38

Operational Maintenance Will need to monitor Event table as table increases in size in order ensure performance remains acceptable No easy way to test situation as difficult to add as many events as will accumulate over years of use of the application

Slide 39

CASE Tools Used Microsoft Visio Used to create ER Diagram SQLiteAdmin Used for management of SQLite databases Can easily view current information in database

Slide 40

Lessons Learned Process of designing and implementing a database in context of a real-world application Advanced features in C# programming language (multi-threading, sending email) Application Security (DPAPI, hashing passwords)