Design Document 4-year Schedule Planner
Group M11
Nicholas Rabbitt: %marks
Nicholas Riesen: %marks
John Stuart: %marks
Haoyu Liu: % marks
Jake Caithamer: % marks
Version Date
0.1
Author
10/08/04 SM
Change
Initial Document
Table of Contents
1
Introduction .................................................................................................................................. 3
1.1
Purpose ................................................................................................................................................................ 3
1.2
Scope ................................................................................................................................................................... 3
1.3
Definitions, Acronyms, Abbreviations ................................................................................................................ 3
1.4
Design Goals........................................................................................................................................................ 3
2
References ..................................................................................................................................... 4
3
Decomposition Description ........................................................................................................... 5
3.1
Module Decomposition ....................................................................................................................................... 5
3.2
Concurrent Process .............................................................................................................................................. 7
3.3
Data Decomposition ............................................................................................................................................ 7
3.4
STATES .............................................................................................................................................................. 7
4
Dependency Description ............................................................................................................... 8
4.1
Intermodule Dependencies .................................................................................................................................. 8
4.2
InterProcess Dependencies .................................................................................................................................. 8
4.3
Data Dependencies .............................................................................................................................................. 8
5
Interface Description .................................................................................................................... 9
5.1
Module Interface.................................................................................................................................................. 9
5.2
Process Interface ................................................................................................................................................ 19
6
Detailed Design ........................................................................................................................... 20
7
Design Rationale ......................................................................................................................... 21
7.1
Design Issues ..................................................................................................................................................... 21
8
Traceability ................................................................................................................................. 25
BANK Project
Introduction
Page 2 of 25
1 Introduction
This document will describe some of the software interfaces that we have employed in our project,
especially those that interface between different members’ code. Each member will describe any
interfaces that they provide to the project, as well as listing any interfaces that they require from
other members.
We will also attempt to explore some of the threads and processes utilized by our project, including
their start conditions, purpose, lifespan, and death conditions.
Finally, we will go back in time to our design phase and describe and reflect upon some of our
high-level design choices, and what those choices have meant for the project thus far.
1.1.1 PURPOSE
1.1.2 SCOPE
1.1.3 DEFINITIONS, ACRONYMS, ABBREVIATIONS
Term
Description
1.1.4 DESIGN GOALS
BANK Project
Introduction
Page 3 of 25
2 References
BANK Project
References
Page 4 of 25
3 Decomposition Description
3.1.1 MODULE DECOMPOSITION
Block Diagram – Description
Our project utilizes ASP.NET MVC 5, which is a C# -based framework used for
scalable web development. MVC projects consist of three parts: Models store local
information and represent data found in a database, Views consist of HTML, JS,
CSS and specialized C# code and are used to generate webpages for a browser,
and Controllers tie Models and Views together using traditional C# code. A portion
of the webpage’s functionality will be mirrored in an Android app.
Model
We are using a MySQL database for this project. Controllers access the database
by using Entity Framework. Once accessed, information from the database is
transferred to models. There are separate models that correspond to each table in
the database, as well as additional models used to transfer information between
views and controllers. In order to query the database, controllers instantiate a new
DatabaseModelContext object, which sends SQL queries via HTTP. Result sets
from the database are then returned to the context and converted to the
appropriate model, which can then be used in views or logic.
Controller
Our project contains four distinct controllers, one each for students, administrators,
and advisers, and an additional controller for shared functionality such as logging
in, signing up, or editing a profile. When a user logs in, the account controller
forwards them to the appropriate homepage and hands control off to the
corresponding user controller. That controller then handles all actions that can be
taken by that user . Each possible action is represented by a method inside of the
controller, and each of these methods returns a View for the client to display.
Views
Each page of the website is generated by a separate View. Views consist of
traditional webpage code with the addition of special C# helper functions that help
define properties and functionality of the page. Each method in a controller returns
the view with the same name as that method. When a View is returned, any C#
code that is inside the View is converted by MVC into the appropriate HTML and is
then sent to the client via HTTP.
Android
BANK Project
Decomposition Description
Page 5 of 25
Our project will include an Android app, which will contain the core schedule design
elements, but which will lack much of the additional administrator and adviser
functionality. The app will consist of a number of Activities, one per screen, along
with supporting classes used for utility functions, such as connecting to the
database. This will be accomplished by sending an HTTP request to a PHP script
on the webserver. The script will query the database and return the result to the
app as a JSON object.
BANK Project
Decomposition Description
Page 6 of 25
3.1.2 CONCURRENT PROCESS
3.1.3 DATA DECOMPOSITION
3.1.4 STATES
BANK Project
Decomposition Description
Page 7 of 25
4 Dependency Description
4.1.1 INTERMODULE DEPENDENCIES
4.1.2 INTERPROCESS DEPENDENCIES
4.1.3 DATA DEPENDENCIES
BANK Project
Dependency Description
Page 8 of 25
5 Interface Description
5.1.1 INTERFACES OVERVIEW
Our project consists roughly of 5 parts:
1) The web app back end
2) Android app
3) A collection of methods used to parse certain properties of the database
4) The database
5) The web app front end
5.1.2 MODEL INTERFACES
Our project uses models as a means of interfacing between different controllers,
and between controllers and views. These models include the basic ones
generated by the Entity framework, as well as a number of custom models that are
used to provide specific sets of information to different views, and to pass that
information back to controllers.
LoginUser
Properties: String UserName, String Password
Description: Simplified version of a ‘profile’ object that passes the username and
password input by a user to the server for validation and proper redirecting.
SignupUser
Properties: String UserName, String Password, String ConfirmPassword, String
FirstName, String LastName, String Email, String Access
Description: A modified version of the standard ‘profile’ object that also includes a
ConfirmPassword field, and omits the ID field, which will be assigned by the server
after the user signs up. An empty SignupUser model will be passed to the Signup
view, populated by the user, and then passed back to a controller for processing
when the user presses Submit.
NewDegree
BANK Project
Interface Description
Page 9 of 25
Properties: String Name, Double HumanitiesCredits, Double TechCredits,
List<course> AllCourses
Description: Passed to the AddNewDegree view when an administrator chooses
to create a new degree program. AllCourses must be populated with the data from
every tuple in the courses table before being used by the view, while the remaining
properties are provided by the administrator
EditDegree
Properties: String Name, Double HumanitiesCredits, Double TechCredits,
List<course> AllCourses, List<course> HumanitiesCourses, List<course>
TechCourses
Description: Passed to the EditDegree view when an administrator chooses to
edit an existing degree. AllCourses will be populated with all of the information
from the courses table before being provided to the view. The rest of the properties
will be populated with the properties of the degree that is being edited, and will also
be used to pass the information back to the server.
NewSchedule
Properties: List<course>[] CoursesBySemester, List<course> AllCourses,
IEnumerable<SelectListItem> AllDegrees, String ScheduleName, String
DegreeName
Description: Model that is provided to the CreateNewSchedule view. AllDegrees
and AllCourses are first populated, so that the user can choose from degrees and
courses to use. The rest of the properties must be provided by the user.
EditSchedule
Properties: List<course>[] CoursesBySemester, List<course> AllCourses, String
SelectedDegree, IEnumerable<SelectListItem> AllDegrees, String ScheduleName
Description: Model that is provided to the EditSchedule view. AllDegrees and
AllCourses are first populated from the database so that the user may choose
different courses and degrees for their existing schedule. The other properties are
populated from the schedule that has been selected for editing, and are also used
to pass the edited values back to the controller.
BANK Project
Interface Description
Page 10 of 25
5.1.3 PHP SCRIPTS
Connecting directly to a MySQL database using the JDBC library is discouraged in android.
The drivers for JDBC are not included in android by default, and in order to use this library,
drivers must be provided.
The more preferred approach to dealing with the challenge of connecting to a database from
android is to call various PHP scripts that will connect to the database, query the database
for information, format and return the information, and close the connection with the
database. Seeing as this is the one most frequently used and recommended, this is the
technique that we chose in this project.
Below are all of the php scripts used in our project, with information regarding their
parameters, and return types.
getUser.php
Description: When provided with a username and password, this script should attempt to
find the user in the database. If the user is found, all of the information about the user is
returned to the android in the form of a json object. If the user does not exist in the database
or if the provided password does not match the stored password, the script returns null.
Parameters KeyValuePairs
(string) userName – The username provided by the current user of the android device
(string) password – The password provided by the current user of the android device
Return: Json Object User
(int) userPrimaryKey – the primary key of the user used by the database
(string) firstName – first Name of user
(string) lastName – last Name of user
(string) userName – username of user
(string) accessLevel – access level of user
getAdvisers.php
Description: Returns a list of all advisor names and there primary keys that are stored in the
database.
Parameters – none
Return: jsonArray[Json Object Adviser]
(int) userPrimaryKey – the primary key of this adviser
BANK Project
Interface Description
Page 11 of 25
(string) firstName – the first Name of this adviser
(string) lastName – the last name of this adviser
getStudents.php
Description: When provided with the primary key of an advisor, this script will return a list
of all the students under the supervision of that advisor.
Parameters KeyValuePairs
(int) userPrimaryKey – The primary key of the advisor who’s students are desired
Return: json array[Jason Object Student]
(int) userPrimaryKey – the primary key used by the database for this user
(String) studentFirstName – the first name of this student
(String) studentLastName – the last name of this student
getPlans.php
Description: When provided with the primary key of a student, this script will return the
list of abbreviated four year plans that the student has created.
Parameters KeyValuePairs
(int) userPrimaryKey – the primary key of the student whos plans are desired
Return: json array[plans name, abbreviated FourYearPlan]
(int) scheduleID – the primary key used by the database for this four year plan
(String) fourYearPlanName -- The name of the four year plan assigned by the student
getFullPlan.php
Description: When provided with the key value for a plan, this script will retrieve the entire
plan and return it as a json object.
Parameters KeyValuePairs
(int) scheduleID – the primary key used by the database for the plan desired
Return: json object fouryearplan
(degree) major – the degree that has been selected by the student
(degree array) minors – list of minors the student has selected
(string array) semesters - list of semesters all semesters. Semesters are strings of the
format “course1, course2, course3”
BANK Project
Interface Description
Page 12 of 25
getCourse.php
Description: When provided with a course name, returns all of the information about a
given course.
Parameters KeyValuePairs
(string) courseTitle – course catalog title of item requested.
Example “Com 309”
Return: json object course
(string) courseTitle -- course catalog title of item requested. Example “Com 309”
(string) courseName – Name of course. Example “System Development Practices”
(int) credits – number of credits the class is worth
(string) description – short description about what the class will cover
(string array) prereqs – an array of courseTitles of courses that are prerequisite for this
class.
5.1.4 DATABASE PARSER
Due to the inherent complexity of a schedule and the sturcture of relational databases such
as MySql some data had to be stored in a designated format. In order to make it easier to
use and understand the data in the tables, a parser was needed and each of the tables has a
C# object with properties that matches each column for easier access and increased
modularization. Having built in C# objects that relate to the database tables also reduces the
number of queries required in the normal operation of the program.
Database Parser Class
parseCompletedSchedule(string ScheduleName):
Description: This method takes the name of a desired schedule, queries the database and
returns the related C# database object CompletedSchedule. The CompletedSchedule object
can then be passed to other methods for processing.
Parameters: ScheduleName: The name of the desired schedule to be processed and
queried.
BANK Project
Interface Description
Page 13 of 25
Returns: CompletedSchedule class. The CompletedSchedule class has the following
properties:
string id;
string creator;
string name;
List<course> coursesByYear; //Each year is placed in a separate index with "||" as
delimeters between years.
string degree;
checkPrerequisites(ArrayList classes, Course course):
Description: This method will analyze and record all prereqs given in the course object. It
will then analyze all the course objects in classes to make sure that all the requirements
have been met for the specified course.
Parameters:
classes: List of Course objects already added into the schedule.
course: Course to be added to the schedule.
Returns: Boolean value, true if prereqs are not met false if not.
parseScheduleTemplate(string templateName)
Description: This method takes the name of the desired schedule template and returns the
related ScheduleTemplate C# class.
Parameters:
templateName: Name of the template to be found and processed from the MySql database.
Returns: ScheduleTemplate class. The Schedule Template class has the following
properties.
BANK Project
Interface Description
Page 14 of 25
int id;
ArrayList coursesByYear; // Same as the completed schedule coursesByYear
string name;
string degree;
parseCourse(string courseID)
Description: This method queries the database for a course with the id matching the
parameter courseID. It then creates the relevant Course c# class and populates its fields with
the relevant information.
Parameters:
courseID: Id of course needed to be found and processed from the MySql database.
Returns: Course c# class with the following populated fields.
string courseID;
string courseName;
string courseDescription;
int courseCredits;
List<course> prerequisites; contains a string list of all the prereqs for the course object
5.1.5 INTERFACE DESCRIPTION: DATABASE
Our project uses a MySQL Database to store all of its information. This data is acquired
from the database by populating the model properties, and there is a table in the database
for each model. Some of the columns in the database use delimiters to separate several
values, needing a parser class interface.
BANK Project
Interface Description
Page 15 of 25
completedSchedules
Description: Once a user finishes a schedule, the information can be saved to the
completed schedules table.
Columns:
id (primary key) - The identification number of each schedule.
name - The name displayed with the schedule.
coursesByYear - The courses are listed here, with each year separated by "||".
degree - The degree that the schedule would satisfy.
creator - The username of the user that created the schedule.
courses
Description: Courses, and the corresponding properties, can be saved into this table.
Columns:
courseID (primary key) - The identification number of the course.
courseName - The name of the course.
courseDescription - A detailed description of the listed course.
courseCredits - The number of credits that the listed course will fulfill.
prerequisites - A list of all courses needed to be completed before taking the listed
course.
degrees
Description: A table containing the requirements for each degree.
Columns:
degreeName (primary key) - The name of each degree.
humanities - A list of the humanities courses required by the degree.
tech - A list of the tech courses required by the degree.
humanititesHours - The number of credit hours needed from humanities courses.
BANK Project
Interface Description
Page 16 of 25
techHours - The number of credit hours needed from tech courses.
profiles
Description: A table containing all of the properties of each user.
Columns:
username (primary key) - The username of the user.
password - The password that is used with the username to log in.
accesslevel - The authorization of the user.
name - The full name of the user.
ID - The assigned university identification number of the user.
major - The major of the user (if applicable).
advisor - The name of the advisor assigned to the student (if applicable).
firstName - The first name of the user.
lastName - The last name of the user.
email - The email address of the user.
securityQuestion - A question set by the user to enable password recovery.
securityAnswer - The answer to the security question.
templates
Description: A table containing a list of schedules that a user could use as a template.
Columns:
id (primary key) - The unique identification number associated with the template.
name - The name of the template.
courseByYear - A list of courses separated by year with "||".
degree - The degree that the template would satisfy.
BANK Project
Interface Description
Page 17 of 25
5.1.6 AJAX INTERFACES
AJAX = Asynchronous JavaScript and XML, is a group of interrelated Web development
techniques used on the client-side to create asynchronous Web applications. With Ajax,
Web applications can send data to and retrieve from a server asynchronously (in the
background) without interfering with the display and behavior of the existing page.
RemoveSelectedCourse()
Description: the functions are used to add selected courses form the course list. It will show
the course names on the browser instantly before sending the information to server.
Method: Post
Url: ‘@Url.Action("AddToSemester", "Schedule", null, Request.Url.Scheme)?id=' +
val+'&sem='+selectedSemester
Async: True
Corresponding Server-side functions: AddToSemester(String id="", int sem=0)
This function queries the Courses database using the ‘id’ String, and stores the result in a
static array. Later, when the user presses submit, the contents of this array are used to
populate a new schedule object.
AddSelectedCourse()
Description: the functions are used to remove selected courses form the course list. It will
show the course names on the browser instantly before sending the information to server.
Method: Post
Url: '@Url.Action("RemoveFromSemester", "Schedule", null, Request.Url.Scheme)?id=' +
val + '&sem=' + selectedSemester,
Async: True
Corresponding Server-side functions: RemoveFromSemester(String id="", int sem=0)
This function removes the Course object with CourseID equal to ‘id’ from the static array.
BANK Project
Interface Description
Page 18 of 25
5.2
PROCESSES/THREADS
List:
ASP.NET Server: Runs on our remote webserver and responds to HTTP requests from
clients
MySQL Database: Runs on a remote server and responds to query requests from the ASP
Server and from PHP scripts
Web Client: A client requesting information from the ASP Server
ASP.NET Server: Automatically handles requests from remote clients by creating one or
more threads to process and respond to the requests, which may include sending
information, running business logic, or querying the database. These threads are returned to
the thread pool when the client disconnects.
MySQL Database: Handles requests from the webserver or from PHP scripts by
dedicating a thread to that request. The thread will complete the query submitted by the
request and return the result set to the webserver or PHP scripts. The thread will then be
returned to the database’s thread pool for future use.
Web Client: May vary by client, but typically consists of one thread requesting,
processing, and displaying information/webpages from the web server.
BANK Project
Interface Description
Page 19 of 25
6 Detailed Design
BANK Project
Detailed Design
Page 20 of 25
7 Design Rationale
7.1.1 DATABASE ACCESS
Because our project relies so heavily on our MySQL database, it was critical for us to find a
fast and efficient way to query the database for information. We quickly discovered that
ASP.NET does not natively include functionality to connect to databases, but that there is a
driver/library called Connector/Net, published by Oracle, that would allow us to easily
connect to and query the database.
We briefly used functionality provided by Connector/Net manually, including connecting,
querying, parsing, and destroying the connection entirely with our own code. However, this
required that we write a lot of code, and didn’t provide any automation of the process at all.
Given that we are using such an advanced IDE and framework, this seemed unnecessary, so
we set out to look for a solution that required less maintenance and provided more
accessible functionality.
We settled on Microsoft’s Entity Framework, which is an object-relational mapping
framework designed specifically for use with ASP.NET. Entity provides a representation of
the database tables as C# objects, as well as an object implementation of the database
connection and of the database itself. These features make it much easier to access and
query the database, as well as bringing the database more in line with traditional objectoriented C# code. Finally, Entity allows us to update our server-side representation of the
database at any time, meaning that changing the database does not present an obstacle to
continued development.
7.1.2 DESIGN DECISION – LIMITED FUNCTION ANDROID APP
As part of the design choices made during this project, we decided to develop an android
app with limited functionality to accompany the primary website. The app would be
capable of log in with a username and password of a pre-existing account and view four
year plans (and the plans statistics) associated with that account. If the user is an adviser,
BANK Project
Design Rationale
Page 21 of 25
the advisor could view all of the plans made by students of that adviser, and an
administrator would be able to view all four-year plans in the system. The app would not be
able to create new accounts, start a new four-year plan or modify an existing four-year plan.
There were two alternative choices to this plan. The first would have been to develop a
mobile version of the site with either limited or full capability of the full site. The other
would be to create a fully functional android app. A mobile version of the site might be
more continent for some users. The major drawback of making a mobile site however
would limit the scope of our project significantly. Most of the functionality would already
be in place. Adding a mobile site would be adding some specialized views to the main
project.
The other alternative is to build a fully functional android app with all the capabilities of the
original web site. The average user is unlikely to develop plans on their phone. If they
tried, the limited screen real estate would be a large inconvenience. What is more likely is
that they would like to view a plan when away from their computer. In this situation, most
of the apps capability is under used. The other drawback to this plan is that it would
drastically increase the scope of our project; developing this sort of app could be a project
in and of itself.
The choice to make a limited function app was based on the fact that the two reasonable
alternatives would have greatly increased or reduced the scope of the project. Because the
end goal of this project is the learning obtained along the way, and not the end program
itself, keeping the scope to a reasonable level is critical. If the scope gets too big, we will
not be able to finish the project; if too small, we wont have enough work for every member
of the team. With this goal in mind, a limited function android app keeps the scope of the
overall project at a reasonable level.
7.1.3 DESIGN CHOICE: SESSION AUTHORIZATION
BANK Project
Design Rationale
Page 22 of 25
With every application created, a huge design topic of concern is the authorization of the
users. And, there must be able to justify the level authentication to do that. We save the
level of authorization in the profiles table, but needed a way to have it available in our
program.
Initially, we obtained the access level by loading the profile properties into a user model.
This way when a user logged on their information would be saved into a model and
accessed at any time. However, this way was not very secure. Two ways that we
researched were sessions and windows forms authentication.
Eventually, we agreed on using sessions to capture the current user's properties. By
setting the current session we could globally access any of the current user's information,
for example in the controllers and views. In the controllers we use the session access level
to confirm whether the user has the authorization to access a view, or perform an action.
We can also implement a logout function by terminating the session. Lastly, we used
sessions to display the name of the user in the shared view between pages to confirm that
you are logged in and using the correct profile. The sessions are set using a helper
function in the login controller.
7.1.4 MULTIPLE DEGREES
Our project is detailed to be a 4 year planner for students entering college. However this
description is somewhat vague and brings up inherent problems such as a transfer student
who may already have classes completed or a student that may need to take more than 4
years. We focused on the issue of a student who might want to change majors or who wants
to model different course majors and minors. So in order to deal with this problem we had
to come up with a plan of action of how the program will handle this. We decided that we
wanted our program to be flexible. In order to maximize this quality we decided to make
the degree's customizable by the administrator. This is done by having the administrator
create a degree such as Computer Science with a minor in business. The administrator will
then implement details of the degree such as how many humanity credits are needed, how
many course credits in total are needed, etc. The downside of this approach is that all
degrees have to be created within the program and students will not be able to create
degrees by themselves.
BANK Project
Design Rationale
Page 23 of 25
7.1.5 DECISION TO ALLOW USERS TO DESIGN A SCHEDULE WITHOUT LOG IN
When we was designing the “view completed schedule” page, we had to make decision for
whether or not allow users to design something without login. If we didn’t allow this, users
have to login once they want to create a schedule. It will cost more time. We are thinking
about to make something like “Free trial” so that new users can try some functions before
they decided to register. Moreover, the existed users don’t need to login when they just
want to design a schedule.
BANK Project
Design Rationale
Page 24 of 25
8 Traceability
No Use Case/ Non-functional Description
Subsystem/Module/classes that handles it
1
2
FEEL FREE TO ADD APPENDICES AS NEEDED. UPDATE TOC BEFORE SUBMITTING
BANK Project
Traceability
Page 25 of 25