downloading - Assembla

groanaberrantInternet and Web Development

Feb 2, 2013 (4 years and 9 months ago)

176 views






TiTiS

S
ystem Design
Document


Authors: Özgür Akgün, Yiğit Demirbaş

却S牴r䑡Me㨠㈰:9
-

-


EnT⁄ 瑥W′〰
-

-


Page
2

of
25


CONTENTS

1.

INTRODUCTION

................................
................................
................................
................................
..........

4

1.1.

PURPOSE AND SCOPE

................................
................................
................................
............................

4

1.2.

P
RODUCT AND ENVIRONMENT

................................
................................
................................
.............

4

1.3.

DEFINITIONS, ACRONYMS, AND ABBREVIATIONS

................................
................................
.................

4

1.4.

OVERVIEW

................................
................................
................................
................................
.............

5

2.

OVERVIEW OF THE SYSTEM

................................
................................
................................
.......................

5

2.1.

APPLICATION ENVIRONMENT
................................
................................
................................
................

6

2.1.1.

TOOLS

................................
................................
................................
................................
................

6

2.1.2.

SETTING UP THE DEVELOPMENT ENVIRONMENT

................................
................................
.............

6

2.2.

INTERFACES

................................
................................
................................
................................
...........

6

2.3.

HARDWARE

................................
................................
................................
................................
............

6

2.4.

SOFTWARE

................................
................................
................................
................................
.............

7

2.5.

STANDARDS COMPLIANCE
................................
................................
................................
.....................

7

3.

ARCHITECTURAL DESIGN
................................
................................
................................
............................

7

3.1.

G
ENERAL GUIDELINES

................................
................................
................................
............................

7

3.2.

DATABASE ARCHITECTURE

................................
................................
................................
....................

8

3.3.

SOFTWARE ARCHITECTURE

................................
................................
................................
...................

9

4.

DETAILED DESIGN
................................
................................
................................
................................
.....

10

4.1.

USER

................................
................................
................................
................................
....................

13

4.1.1.

OVERVIEW AND PURPOSE

................................
................................
................................
...............

13

4.1.2.

IMPLEMENTATION

................................
................................
................................
...........................

13

4.2.

ADMIN

................................
................................
................................
................................
.................

13

4.2.1.

PURPOSE

................................
................................
................................
................................
..........

13

4.2.2.

IMPLEMENTATION

................................
................................
................................
...........................

14

4.3.

HEAD OF DEPARTMENT

................................
................................
................................
.......................

15

4.3.1.

PURPOSE

................................
................................
................................
................................
..........

15

4.3.2.

IMPLEME
NTATION

................................
................................
................................
...........................

15

4.4.

STUDENT AFFAIRS

................................
................................
................................
................................

16

4.4.1.

PURPOSE

................................
................................
................................
................................
..........

16

4.4.2.

IMPLEMENTATION

................................
................................
................................
...........................

16

4.5.

PROFESSOR

................................
................................
................................
................................
..........

17

4.5.1.

PURPOSE

................................
................................
................................
................................
..........

17

4.5.2.

IMPLEMENTATION

................................
................................
................................
...........................

17

4.6.

TEACHING ASSISTANT

................................
................................
................................
..........................

18

4.6.
1.

PURPOSE

................................
................................
................................
................................
..........

18

Page
3

of
25


4.6.2.

IMPLEMENTATION

................................
................................
................................
...........................

18

4.7.

STUDENT

................................
................................
................................
................................
..............

19

4.7.1.

PURPOSE

................................
................................
................................
................................
..........

19

4.7.2.

IMPLEMENTATION

................................
................................
................................
...........................

19

5.

SPE
CIFIC TECHNICAL SOLUTIONS

................................
................................
................................
.............

20

5.1.

SECURITY
................................
................................
................................
................................
..............

20

5.2.

BACKUPS AND RECOVERY

................................
................................
................................
....................

20

5.
3.

MAINTAINABILITY

................................
................................
................................
................................

20

5.4.

FLEXIBILITY

................................
................................
................................
................................
...........

21

5.5.

PORTABILITY

................................
................................
................................
................................
........

21

6.

REJECTED ALTERNATIVES

................................
................................
................................
.........................

21

7.

R
EFERENCES

................................
................................
................................
................................
.............

21

8.

APPENDIX

................................
................................
................................
................................
.................

22

8.1.

USE CASES

................................
................................
................................
................................
............

22

8.1.1.

ADMIN

................................
................................
................................
................................
.............

22

8.1.2.

HEAD OF DEPARTMENT

................................
................................
................................
...................

23

8.1.3.

STUDENT AFFAIRS

................................
................................
................................
............................

23

8.1.4.

PROFESSOR

................................
................................
................................
................................
......

24

8.1.5.

TEACHING ASSISTANT

................................
................................
................................
......................

24

8.
1.6.

STUDENT

................................
................................
................................
................................
..........

24

8.2.

SEQUENCE DIAGRAM

................................
................................
................................
..........................

25














Page
4

of
25


1.

INTRODUCTION

1.1.

PURPOSE AND SCOPE

This document is the proposed project plan and guideline to design and implement time table scheduling
system TiTiS. All the information included in this document is derived from the previous project
plan
documents, mostly system requirements specifications, for design decisions.

S
cope of this document does not extend beyond the design plans of project TiTiS and does not include any
implementation issues.


1.2.

PRODUCT AND ENVIRONMENT

TiTiS project has the
intention of building an

university scheduling system capable of efficiently gathering data
from its users, scheduling and creating time tables, analyzing feedbacks and re
-
scheduling if necessary.
Databases will be used to store relevant information requir
ed to make scheduling
processes and

user
information.

Server
-
side will consist of distributed servers running on Linux operating system. Distributed computing will be
achieved by communicating virtual machines running on all servers. Each server will be re
sponsible for
its

own
use. End
-
Users will only require a compatible web browser to use the system.

1.3.

DEFINITIONS, ACRONYMS, AND ABBREVIATIONS

Project name:


TiTiS TTS is the abbreviation for “
Timetable Scheduler”.
Titiz in Turkish means accurate and careful
; inspiring
from that we named our project TiTiS.


Other acronyms:





RDBMS: Relational database management system.



HDD: Hard disk drive



CPU: Central Processor Unit



Admin: Administrator



HTML: Hypertext Markup Language



xHTML: eXtensible Hypertext Markup Language



CSS: Cascading Style Sheets



UI: User Interface (generally referring to GUI)



GUI: Graphical User Interface



AJAX: Asynchronous JavaScript and XML



XML: eXtensible Markup Language



JS: JavaScript



IDE: Integrate
d Development Environment



ROR: Ruby on Rails framework



RAD: Rapid Application Development



MVC: Model View Controller




Page
5

of
25


1.4.

OVERVIEW



Chapter 2 gives an overview of the system also detailing development tools



Chapter 3 briefly discusses the architectural
design.



Chapter 4 gives details about the architectural design.



Chapter 5 determines the specific technical alternatives.



Chapter 6 lists rejected alternatives and possible further development ideas.



Chapter 7 lists all the references used for writing this

document.

2.

OVERVIEW OF THE SYST
EM

System will consist three separate servers running for user interaction, data storage and solver application for
scheduling. Keeping different servers for each of these will benefit us with modularity over the system as mu
ch
as possible. Also our web
-
oriented server approach will benefit the users by them not needing

any

client
software. All they will need is a compliant web
-
browser

and internet connection.






Page
6

of
25


2.1.

APPLICATION ENVIRONMENT

2.1.1.

TOOLS

TiTiS will be developed by ruby

programming language and ruby on rails framework in order to benefit from
RAD methodologies.

Below is a list to software that will be used to implement the project and also tools for writing this design
document.



Notepad++ text editor



Ruby 1.8.7



Ruby
Gems
0.8.7



Ruby on Rails 2.3



MySQL 5.4



WEBrick application server



Smart Draw

2009



Microsoft Office Word

2.1.2.

SETTING UP THE DEVEL
OPMENT ENVIRONMENT

Ruby programming language version 1.8.3 or upper must be
installed first of all. If the development machine is
a Linux

box, then it must be compiled manually by considering dependencies. If it is a Windows box then a
precompiled executable file exists.

On top of a ruby installation, Ruby Gems must be installe
d. RubyGems is a ruby program that allows the
developers to
install additional plug
-
ins and most importantly Ruby on Rails framework. Upon installing MySQL

and
ruby
-
M
y
SQL

connector
, simply starting the database will make development environment ready.

2.2.

INTERFACES

A graphical user interface is crucial for the project
. Different views with different interface models exist for
different types of users.

Graphical user interfaces will be available through a web browser.

Interface between data and user interfaces is achieved explicitly by Ruby on Rails architectural patter
n Model
-
View
-
Controller (often abbreviated as MVC). In MVC, the
model

represents the information (the data) of the
application; the
view

corresponds to elements of the user interface such as text, checkbox items, and so forth;
and the
controller

manages th
e communication of data and the business rules used to manipulate the data to
and from the model

[1]
.

TiTiS

require additional hardware interfaces between server
s

if the
y
are
present in different computers, but in
this project all servers will be installed

to just one computer so there is no need for any hardware connections.

Database interface is explicitly achieved by ruby
-
MySQL database connector
[2]
.

2.3.

HARDWARE

An application server is highly dependent on CPU and swap memory, a database server is highly d
ependent on
HDD whereas a web server needs a high bandwidth and internet speed. Any hardware which has moderate
qualifications from each will be adequate.

Page
7

of
25


There is no required hardware for the client
-
side as only a computer with an internet connection and
web
browser is enough. It is assumed that this computer has a connected mouse, keyboard and monitor.

2.4.

SOFTWARE

Servers need to run on a Linux operating system with network managers are configured and ready to access to
the internet. Web Server is required t
o have latest versions of Ruby, RubyGems and Ruby on Rails, database
server is required to have latest versions of MySQL and ruby
-
MySQL connector.

There are no software needs for the client
-
side, an internet connection and a compatible web browser is simpl
y
adequate.

2.5.

STANDARDS COMPLI
A
NCE

Implementation must comply with W3C Quality Assurance, Standards Compliant Sites Technical Report
[3]
.

3.

ARCHITECTURAL DESIGN

3.1.

GENERAL GUIDELINES

Main purpose
of this project is, having a complete solution to course timetable

sch
eduling problem of a
university by implementing

online distributed system outstanding with its own information system which will
be available to run over a web browser for the end users.

Web server will gather all the data a priori to the scheduling
and sent it over to the database server. By the
time of data gathering is finished application server will take all the data into an unscheduled timetable and
schedule it according to the constraints given by users.

After the scheduling what users will see

via the web server will be their time table schedules stored in the
database.













Page
8

of
25


3.2.

DATABASE ARCHITECTUR
E



Page
9

of
25


3.3.

SOFTWARE ARCHITECTUR
E

WEBrick and MySQL are connected with the ruby
-
MySQL connector. WEBrick is a web server based on ruby
libraries and it
is default for ROR. ROR with its MVC architectural engine makes it possible to connect all the
data to the representation with certain configurations. Solver algorithm’s implementation language will not
matter as it will only be connected to the database a
nd will not be aware of the ruby side of the system.










Page
10

of
25


4.

DETAILED DESIGN


class SystemUsers
SystemClasses::User
#
EMai l: Stri ng
#
ID: unsi gned i nt
#
Name: Stri ng
#
Password: Stri ng
#
PhoneNumber: Stri ng
#
Surname: Stri ng
#
Logi n(Stri ng, unsi gned i nt) : bool ean
#
Logout() : bool ean
SystemClasses::Admin
::User
#
EMai l: Stri ng
#
ID: unsi gned i nt
#
Name: Stri ng
#
Password: Stri ng
#
PhoneNumber: Stri ng
#
Surname: Stri ng
-
Backup() : fi l e {query}
-
CreateHODAcc(Stri ng, Stri ng, Stri ng, unsi gned i nt, Stri ng, Stri ng, Stri ng, Stri ng) : HeadOfDepartment {query}
-
CreateStdAffAcc(Stri ng, Stri ng, Stri ng, Stri ng, Stri ng, unsi gned i nt) : StudentAffai rs {query}
-
Del eteHODAcc(HeadOfDepartment) : bool ean {query}
-
Del eteStdAffAcc(StudentAffai rs) : bool ean {query}
-
IncrementSemester(i nt, Stri ng) : bool ean
-
Logi nAsUser(Stri ng, Stri ng, unsi gned i nt) : bool ean
-
Moni torActi vi ti es() : fi l e
-
PauseAccount(User) : bool ean
-
Restore(fi l e) : bool ean {query}
-
StartPhase() : bool ean
-
StopPhase() : bool ean
-
UpdateHODAcc(HeadOfDepartment*) : HeadOfDepartment {query}
-
UpdateStdAffAcc(StudentAffai rs*) : StudentAffai rs {query}
::User
#
Logi n(Stri ng, unsi gned i nt) : bool ean
#
Logout() : bool ean
«Impl ementor»
-
Schedul e(Student, Ti mePreference, Atomi cCourseInstanceParti ti on*, Cl assRoom) : Atomi cCourseInstanceParti ti on[]
-
ReSchedul e() : Atomi cCourseInstanceParti ti on[]
SystemClasses::Professor
-
Department: Stri ng
-/
Ti mePreferences: Ti mePreference
::User
#
EMai l: Stri ng
#
ID: unsi gned i nt
#
Name: Stri ng
#
Password: Stri ng
#
PhoneNumber: Stri ng
#
Surname: Stri ng
-
ApproveResul tParti al (Atomi cCourseInstanceParti ti on) : voi d
-
ApproveResul tsAl l () : bool ean
-
Assi gnTAs(Teachi ngAssi stant) : Atomi cCourseInstanceParti ti on
-
EnterGrades(i nt, Student) : Transcri pt
-
EnterTi mePreferences(HourSl ots, Semester, Preferences, i nt, Day) : Ti mePreference[]
-
RequestTi meChange(Atomi cCourseInstanceParti ti on) : Atomi cCourseInstanceParti ti on
-
Vi ewStudentLi st(CourseInstance) : <l i st>Students {query}
::User
#
Logi n(Stri ng, unsi gned i nt) : bool ean
#
Logout() : bool ean
SystemClasses::Student
-
Department: Stri ng
-
Doubl eMaj orDepartment: Stri ng
-
IsThereDMaj or: bool ean = fal se
-
IsThereMi nor: bool ean = fal se
-
Mi norDepartment: Stri ng
-/
Ti mePreferences: Ti mePreference
-
CurrentGPA: doubl e
-
Cl assyear: i nt
::User
#
EMai l: Stri ng
#
ID: unsi gned i nt
#
Name: Stri ng
#
Password: Stri ng
#
PhoneNumber: Stri ng
#
Surname: Stri ng
-
AddDMaj orOrMi norCourses(CourseInstance, i nt, i nt) : CourseInstance[]
-
AddEl ecti veCourses(i nt, i nt, CourseInstance, doubl e) : CourseInstance[]
-
EnterTi mePreferences(i nt, Semester, Day, Preferences, HourSl ots) : Ti mePreference[]
-
RankMandotaryCourseSecti ons(CourseInstance*) : CourseInstance[]
::User
#
Logi n(Stri ng, unsi gned i nt) : bool ean
#
Logout() : bool ean
SystemClasses::StudentAffairs
::User
#
EMai l: Stri ng
#
ID: unsi gned i nt
#
Name: Stri ng
#
Password: Stri ng
#
PhoneNumber: Stri ng
#
Surname: Stri ng
-
CreateStudentAcc(Stri ng, Stri ng, bool ean, bool ean, Stri ng, Stri ng, Stri ng, Stri ng, Stri ng, unsi gned i nt) : Student {query}
-
UpdateStudentAcc(Student*) : Student {query}
-
Del eteStudentAcc(Student*) : bool ean {query}
-
EnterStudentYearInfo(i nt, Student*) : Student
-
CreateCl assroomTypes(i nt, Stri ng, i nt) : Cl assRoomType {query}
-
UpdateCl assroomTypes(Cl assRoomType*) : Cl assRoomType {query}
-
Del eteCl assroomTypes(Cl assRoomType*) : bool ean {query}
-
CreateCl assroom(Stri ng, Cl assRoomType) : Cl assRoom {query}
-
UpdateCl assroom(Cl assRoom*) : Cl assRoom {query}
-
Del eteCl assroom(Cl assRoom*) : bool ean {query}
-
ManageRul esForLetter() : voi d
-
ManageRul esForLetterGrades() : voi d
::User
#
Logi n(Stri ng, unsi gned i nt) : bool ean
#
Logout() : bool ean
SystemClasses::TeachingAssistant
-/
Ti mePreferences: Ti mePreference
::User
#
EMai l: Stri ng
#
ID: unsi gned i nt
#
Name: Stri ng
#
Password: Stri ng
#
PhoneNumber: Stri ng
#
Surname: Stri ng
-
EnterTi mePreferences(HourSl ots, Preferences, Day, Semester, i nt) : Ti mePreference[]
-
Vi ewStudentLi st(CourseInstance) : <l i st>Students {query}
::User
#
Logi n(Stri ng, unsi gned i nt) : bool ean
#
Logout() : bool ean
SystemClasses::HeadOfDepartment
-
Department: Stri ng
::User
#
EMai l: Stri ng
#
ID: unsi gned i nt
#
Name: Stri ng
#
Password: Stri ng
#
PhoneNumber: Stri ng
#
Surname: Stri ng
-
ApproveTAAssi gnments(Atomi cCourseInstanceParti ti on*) : voi d
-
CreateProfessorAcc(Stri ng, Stri ng, Stri ng, Stri ng, unsi gned i nt, Stri ng, Stri ng) : Professor {query}
-
CreateTAAcc(Stri ng, Stri ng, Stri ng, unsi gned i nt, Stri ng, Stri ng) : Teachi ngAssi stant {query}
-
Del eteProfessorAcc(Professor*) : bool ean {query}
-
Del eteTAAcc(Teachi ngAssi stant*) : bool ean {query}
-
Fi l l NeverPreferences(Ti mePreference*) : Ti mePreference
-
UpdateProfessorAcc(Professor*) : Professor {query}
-
UpdateTAAcc(Teachi ngAssi stant*) : Teachi ngAssi stant {query}
-
Vi ewStudentLi st(CourseInstance) : <l i st>Students {query}
-
CreateCourses(Condi ti ons, Stri ng, i nt, i nt, i nt, i nt, Stri ng) : Course {query}
-
UpdateCourses(Condi ti ons*, Course*) : Course {query}
-
Del eteCourses(Condi ti ons*, Course) : bool ean {query}
-
CreateCourseInstances(Semester, Professor, i nt, i nt, Course) : CourseInstance
-
UpdateCourseInstance(CourseInstance*) : CourseInstance
-
CreateACIP(CourseType, Cl assRoomType, i nt, i nt, CourseInstance) : Atomi cCourseInstanceParti ti on
-
UpdateACIP(Atomi cCourseInstanceParti ti on*) : Atomi cCourseInstanceParti ti on
::User
#
Logi n(Stri ng, unsi gned i nt) : bool ean
#
Logout() : bool ean
ISA
«i mpl ementati on»
ISA
«i mpl ementati on»
ISA
«i mpl ementati on»
ISA
«i mpl ementati on»
ISA
«i mpl ementati on»
ISA
«i mpl ementati on»
Page
11

of
25



class Assignments
SystemClasses::Course
+
CourseID: Stri ng
+
Versi on: i nt
+
Credi t: i nt
+
ECTSCredi t: i nt
+
Total LectureHours: i nt
+
Department: Stri ng
+/
Condi ti ons: Condi ti ons
SystemClasses::Conditions
«col umn»
*PK
Condi ti onID:
*
Prequi si teOrMandatoryCondi ti on:

Department:
*
Educati onYear:
*
Semester:
*
Mi nGPA:
*
Appl i estoDoubl eMaj or:
*
Appl i estoMi nor:
*
Appl i estoOther:

Facul ty:
«PK»
+
PK_Condi ti ons()
«uni que»
+
UQ_Condi ti ons_Condi ti onID()
+
UQ_Condi ti ons_Educati onYear()
SystemClasses::
CourseInstance
+
Year: i nt
+
Secti on: i nt
+/
ProfessorInfo: Professor
::Course
+
CourseID: Stri ng
+
Versi on: i nt
+
Credi t: i nt
+
ECTSCredi t: i nt
+
Total LectureHours: i nt
+
Department: Stri ng
+/
Condi ti ons: Condi ti ons
«enum»
+/
Semester: Semester
SystemClasses::
AtomicCourseInstancePartition
+
Parti ti onID: i nt
+
Parti ti onLectureHours: i nt
+/
Cl assroom: Cl assRoom
+/
TAInfo: Teachi ngAssi stant
+/
Cl assroomType: Cl assRoomType
::CourseInstance
+
Year: i nt
+
Secti on: i nt
+/
ProfessorInfo: Professor
::Course
+
CourseID: Stri ng
+
Versi on: i nt
+
Credi t: i nt
+
ECTSCredi t: i nt
+
Total LectureHours: i nt
+
Department: Stri ng
+/
Condi ti ons: Condi ti ons
«enum»
+/
CourseType: CourseType
::CourseInstance
+/
Semester: Semester
User
SystemClasses::Professor
-
Department: Stri ng
-/
Ti mePreferences: Ti mePreference
::User
#
EMai l: Stri ng
#
ID: unsi gned i nt
#
Name: Stri ng
#
Password: Stri ng
#
PhoneNumber: Stri ng
#
Surname: Stri ng
-
ApproveResul tParti al (Atomi cCourseInstanceParti ti on) : voi d
-
ApproveResul tsAl l () : bool ean
-
Assi gnTAs(Teachi ngAssi stant) : Atomi cCourseInstanceParti ti on
-
EnterGrades(i nt, Student) : Transcri pt
-
EnterTi mePreferences(HourSl ots, Semester, Preferences, i nt, Day) : Ti mePreference[]
-
RequestTi meChange(Atomi cCourseInstanceParti ti on) : Atomi cCourseInstanceParti ti on
-
Vi ewStudentLi st(CourseInstance) : <l i st>Students {query}
::User
#
Logi n(Stri ng, unsi gned i nt) : bool ean
#
Logout() : bool ean
User
SystemClasses::TeachingAssistant
-/
Ti mePreferences: Ti mePreference
::User
#
EMai l: Stri ng
#
ID: unsi gned i nt
#
Name: Stri ng
#
Password: Stri ng
#
PhoneNumber: Stri ng
#
Surname: Stri ng
-
EnterTi mePreferences(HourSl ots, Preferences, Day, Semester, i nt) : Ti mePreference[]
-
Vi ewStudentLi st(CourseInstance) : <l i st>Students {query}
::User
#
Logi n(Stri ng, unsi gned i nt) : bool ean
#
Logout() : bool ean
SystemClasses::
ClassRoom
+
Cl assRoomID: Stri ng
::Cl assRoomType
+
TypeID: i nt
+
Capaci ty: i nt
+
TypeSpecs: Stri ng
SystemClasses::
ClassRoomType
+
TypeID: i nt
+
Capaci ty: i nt
+
TypeSpecs: Stri ng
«access»
needs
«subscri be»
«subscri be»
assi gned
«subscri be»
i nheri ts
«subscri be»
HAS
HAS
Page
12

of
25
















class TimePreferences
SystemClasses::TimePreference
+
Year: i nt
«enum»
+/
Semester: Semester
+/
Day: Day
+/
Ti meSl ots: HourSl ots
+/
Preferences: Preferences = NoDi fferent
User
SystemClasses::Professor
-
Department: Stri ng
-/
Ti mePreferences: Ti mePreference
::User
#
EMai l: Stri ng
#
ID: unsi gned i nt
#
Name: Stri ng
#
Password: Stri ng
#
PhoneNumber: Stri ng
#
Surname: Stri ng
-
ApproveResul tParti al (Atomi cCourseInstanceParti ti on) : voi d
-
ApproveResul tsAl l () : bool ean
-
Assi gnTAs(Teachi ngAssi stant) : Atomi cCourseInstanceParti ti on
-
EnterGrades(i nt, Student) : Transcri pt
-
EnterTi mePreferences(HourSl ots, Semester, Preferences, i nt, Day) : Ti mePreference[]
-
RequestTi meChange(Atomi cCourseInstanceParti ti on) : Atomi cCourseInstanceParti ti on
-
Vi ewStudentLi st(CourseInstance) : <l i st>Students {query}
::User
#
Logi n(Stri ng, unsi gned i nt) : bool ean
#
Logout() : bool ean
User
SystemClasses::TeachingAssistant
-/
Ti mePreferences: Ti mePreference
::User
#
EMai l: Stri ng
#
ID: unsi gned i nt
#
Name: Stri ng
#
Password: Stri ng
#
PhoneNumber: Stri ng
#
Surname: Stri ng
-
EnterTi mePreferences(HourSl ots, Preferences, Day, Semester, i nt) : Ti mePreference[]
-
Vi ewStudentLi st(CourseInstance) : <l i st>Students {query}
::User
#
Logi n(Stri ng, unsi gned i nt) : bool ean
#
Logout() : bool ean
«enumerati o...
SystemClasses::
Day
«enum»

Monday

Tuesday

Thursday

Wednesday

Fri day

Saturday

Sunday
«enumerati o...
SystemClasses::
HourSlots
«enum»

Sl ot1

Sl ot2

Sl ot3

Sl ot4

Sl ot5

Sl ot6

Sl ot7

Sl ot8

Sl ot9

Sl ot10

Sl ot11

Sl ot12
«enumerati o...
SystemClasses::
Preferences
«enum»

never

NoDi fferent

NotPreferred

Preferred
«enumerati o...
SystemClasses::
Semester
«enum»

Fal l

Spri ng

Summer
User
SystemClasses::Student
-
Department: Stri ng
-
Doubl eMaj orDepartment: Stri ng
-
IsThereDMaj or: bool ean = fal se
-
IsThereMi nor: bool ean = fal se
-
Mi norDepartment: Stri ng
-/
Ti mePreferences: Ti mePreference
-
CurrentGPA: doubl e
-
Cl assyear: i nt
::User
#
EMai l: Stri ng
#
ID: unsi gned i nt
#
Name: Stri ng
#
Password: Stri ng
#
PhoneNumber: Stri ng
#
Surname: Stri ng
-
AddDMaj orOrMi norCourses(CourseInstance, i nt, i nt) : CourseInstance[]
-
AddEl ecti veCourses(i nt, i nt, CourseInstance, doubl e) : CourseInstance[]
-
EnterTi mePreferences(i nt, Semester, Day, Preferences, HourSl ots) : Ti mePreference[]
-
RankMandotaryCourseSecti ons(CourseInstance*) : CourseInstance[]
::User
#
Logi n(Stri ng, unsi gned i nt) : bool ean
#
Logout() : bool ean
«subscri be»
«subscri be»
«subscri be»
Page
13

of
25


4.1.

USER

4.1.1.

OVERVIEW AND PURPOSE

User class is an interface class only used by its

inherited subclasses. In implementation all the user entities and
their attributes are in a single table. Our purpose is to implement a single table inheritance to ease the
implementation of access control and inheritance features of all other user types.

4.1.2.

IMPLEMENTATION


Attributes;



Name:

first name of the user



Surname:

second name of the user



ID:
given identification number to the user



Password:
secret key that is required to login to the system



Phone Number:

optional information of available phone number



Email:

e


mail address of the user is required information used for notifications.

Functions;



Login:

this function is used to login to the system by the valid information with password



Logout:

this is the logout function to terminate session after
system has been used.

4.2.

ADMIN

4.2.1.

PURPOSE

Admin users are responsible for installing, maintaining and troubleshooting the system. Also they have the
ability to logon as any user account type to manually rea
ct to user faults. Recoveries and Backups are made by
too. Starting and stopping phases one after another is required to be conducted manually and admin users are
responsible for them.



Page
14

of
25


4.2.2.

IMPLEMENTATION


Attributes;

All attributes are the same as user clas
s. There are no additional attribute in admin class.

Functions;

Login and logout functions are inherited through user class. Additionally,



CreateHODAcc:
this function creates head of department accounts.



UpdateHODAcc:

This function updates the head of deparment account's information.



DeleteHODAcc:

This function deletes head of department accounts from the system.



CreateStdAffAcc:

This function creates student affairs accounts.



UpdateStdAffAcc:

This function updates t
he head of deparment account's information.



DeleteStdAcc:

This function deletes student affairs accounts



Backup:

This function backups all the data currently resident in the system. It also can be used to
export all the data to import to a different hard
ware medium. Regular backups are crucial for security.



Restore:

This function restores a past backup to the system. It can also be used as an import from a
different hardware medium.



IncrementSemester:

After a full process cycle has been completed. A new semester (process cycle)
must be created. This function incerements the semeter to the next one in order to achieve this.



LoginAsUser:

This is an abstract function, admin can login as any user with any
privilage to maintain
the system and resolve inconsistent data inputs.



MonitorActivities:

This function is used by admins to view a full system log.



PauseAccount:

This is an abstract function. Admins can pause any accounts from any activities while
the u
ser can be informed that he/she is doing some activities that can cause system inconsistencies. It
can also pause users who are trying to crack into the system.



StartPhase:

Admin must start and stop every system phase.



StopPhase:

Admin must start and sto
p every system phase.



Schedule:

This is the main schedule function. It has been described in the formal schedule
specification document.



ReSchedule:

This is the reschedule function. It has been described in the formal schedule specification
document.


Page
15

of
25


4.3.

HEA
D OF DEPARTMENT

4.3.1.

PURPOSE

Head of department class is required for all department related functions such as creating courses, assigning
professors to courses and also assigning TAs, managing professors’ accounts and also filling never preferences
as never pr
eferences can only be used by the permission of head of departments.

4.3.2.

IMPLEMENTATION


Attributes;

All attributes are the same as user class.
Additionally
;



Department
: Defines the user as head of which department he/she is.

Functions;

Login and logout
functions are inherited through user class. Additionally,



ApproveTAAssignments()
void :

After professor's assign Teaching assistants to their courses, head of
department must approve them.



CreateProfessorAcc()
Professor :

This function creates a Professor

account. Department information is
not necessary because it will be the same with the Head of Department's department



CreateTAAcc()
TeachingAssistant :

This function is used to create a Teaching Assistant Account



DeleteProfessorAcc()
boolean :

This func
tion is used to delete the no longer necessary professor
accounts from the system



DeleteTAAcc()
boolean :

This function is used for deleting a teaching assistant account

Page
16

of
25




FillNeverPreferences()
TimePreference :

This function allows the head of department
to fill never time
preferences of any professor, student or TA in his/her own department.



UpdateProfessorAcc()
Professor :

This function is used by head of department to update the professor
account's information



UpdateTAAcc()
TeachingAssistant :

This fu
nction is used to update a teaching assistant account
information



ViewStudentList()
<list>Students : This function allows the head of department to view any course
instance's student list that his own department offers.



CreateCourses()
Course :

Head of d
epartments can create courses with defining required conditions
for that courses.



UpdateCourses()
Course :

Head of department can update course information and related condition
requirements.



DeleteCourses()
boolean :

Head of departments can delete cours
es if just updating and giving another
version number is not adequate.



CreateCourseInstances()
CourseInstance :

Head of departments will create course instances from
courses every semester. Only updating will be possible and deleting a course instance is
not possible.



UpdateCourseInstance()
CourseInstance :

Head of departments can update the course instance
information but these informations are not deleteable.



CreateACIP()
AtomicCourseInstancePartition :

This function is used by head of departments to c
reate
an atomic course partition.



UpdateACIP()
AtomicCourseInstancePartition :

Atomic Course Instance Partitions are updateable by
head of departments but they cannot be deletable.

4.4.

STUDENT AFFAIRS

4.4.1.

PURPOSE

Student affairs class is required to manage
information about facilities like classes, labs and also

managing rules
for grades and information about students.

4.4.2.

IMPLEMENTATION



Attributes,

All attributes are the same as user class. There are no additional attribute in admin class.

Page
17

of
25


Functions;


Login

and logout functions are inherited through user class. Additionally,



CreateStudentAcc()
Student : This function is used to create student accounts



UpdateStudentAcc()
Student :

This function is used for updating student information account



DeleteStudentA
cc()
boolean :

This function deletes student accounts



EnterStudentYearInfo()
Student : Sometimes it is hard to tell and calculate if a student is in 2nd year
or 3rd year and year information must be edited manually.



CreateClassroomTypes()
ClassRoomType :

Student affairs can create classroom types.



UpdateClassroomTypes()
ClassRoomType :

This function updates the classroom types.



DeleteClassroomTypes()
boolean :

This function deletes classroom types



CreateClassroom()
ClassRoom :

This function is used to
create classrooms in the university



UpdateClassroom()
ClassRoom :

This function is used to update classroom information



DeleteClassroom()
boolean :

This function is used to delete classrooms



ManageRulesForLetter()
void :

This is an abstract function. It
will be used to determine how many
additional courses a student can take according to his/her GPA.



ManageRulesForLetterGrades()
void :

This is an abstract function. It will be used to determine the
rules for which number grade intervals will be associated

with which letter grades.



4.5.

PROFESSOR

4.5.1.

PURPOSE

Professor class is needed to perform such actions as managing the grades of a course given by the professor or
requesting time changes to the courses for convenience.

4.5.2.

IMPLEMENTATION


Attributes;

Page
18

of
25


All
attributes are the same as user class. Additionally;



Department:

Defines the user as head of which department he/she is.



TimePreferences:

Time Preferences are hold in a different table in database and every professor can
define time preferences for himself/herself. Never preferences are still needed to be filled by head of
department.

Functions;

Login and logout functions are inherited thr
ough user class. Additionally,



ApproveResultPartial()
void :

Professor can select if he/she approves any course partition in the
generated time table schedule. If a course time is approved then it cannot be changed in the re
-
scheduling phase



ApproveResult
sAll()
boolean :

This function will let professor approve all course schedule in the
feedback phase. If a schedule is approved it cannot be changed in the re
-
scheduling phase



AssignTAs()
AtomicCourseInstancePartition :

Professor's will assign TA's to atom
ic course partitions
that must be later approved by the head of department



EnterGrades()
Transcript :

Professors will enter their grades to the system.



EnterTimePreferences()
TimePreference :

Professors will enter time preferences for their courses



Requ
estTimeChange()
AtomicCourseInstancePartition :

Professors can request to change any course
partition's time while in the feedback phase. All the change requests will store until the desired
feedback interval is finished. Then the rescheduling will take pl
ace. Reason behind the choice that why
we do not make any real time change requests is, even the request is unavailable at any time, it may
be become available later on when another professor requests a change that makes the first request
feasible. So ther
e are no real time feedback changes.



ViewStudentList()
<list>Students :

A professor can view his/her course's student list.


4.6.

TEACHING ASSISTANT

4.6.1.

PURPOSE

TeachingAssistant class
makes it available for TAs to view the student list of their courses and also
enter time
preferences for their choices.

4.6.2.

IMPLEMENTATION


Page
19

of
25


Attributes;

All attributes are the same as user class. Additionally;



TimePreferences:

Time Preferences are hold in a different table in database and every teaching
assistant can define time preferences for himself/herself. Never preferences are still needed to be
filled by head of department.

Functions;

Login and logout functions are
inherited through user class. Additionally,



EnterTimePreferences()
TimePreference :

This function is used to enter the time preferences of the
teaching assistant



ViewStudentList()
<list>Students :

This function is used by TA in order to see the student li
st of his/her
assigned course


4.7.

STUDENT

4.7.1.

PURPOSE

Student class is an essential class to the system as students will rank their preferred courses or choose electives
through this class. Also they will have the opportunity to add double major or minor courses

by this class too.

4.7.2.

IMPLEMENTATION


Attributes;

All attributes are the same as user class. Additionally;

Page
20

of
25




Department:

Defines the user as head of which department he/she is.



TimePreferences:

Time Preferences are hold in a different table in database and ev
ery professor can
define time preferences for himself/herself. Never preferences are still needed to be filled by head of
department.



Classyear:

this attribute holds the information of year of students in the school. This information can
be changed by stu
dent affairs manually as it can differ student to student if they fail some courses or
repeat the year.



CurrentGPA:

Current GPA is needed in case of a course has a GPA requirement. Our system assumes
this information is given beforehand by student affairs.



IsThereDMajor:

This is the Boolean attribute to define if student is pursuing a double major program.



IsThereMinor:

This is the Boolean attribute to define if student has minor program.




DoubleMajorDepartment:

If student is pursuing a double major program, this attribute defines in
which department.



MinorDepartment:

If student is pursuing a minor program, this attribute defines in which department.

Functions;

Login and logout functions are inherited through use
r class. Additionally,




AddDMajorOrMinorCourses()
CourseInstance :

Student may add double major or minor courses
without restricted with their GPA.



AddElectiveCourses()
CourseInstance :

Students will add electives and other courses and rank them,
also they must state an interval for defining how many of those ranked courses they wish to take.



EnterTimePreferences()
TimePreference :

This function allows the student to make time preference
s.



RankMandotaryCourseSections()
CourseInstance :

Students cannot rank mandatory courses but they
can rank which section of those mandatory courses they wish to take.

5.

SPECIFIC TECHNICAL S
OLUTIONS

5.1.

SECURITY

System will include authorization, authentication

and access control features to ensure the overall system
security. In addition system will have log files to register history of data sets. Database and application
connections will be achieved by the official connectors available by Sun Microsystems’ dat
abase connectors so
it assumingly will be secure.

5.2.

BACKUPS AND RECOVERY

All information is kept under the database which is very easy to make backups and recoveries. As TiTiS is
intended to run under a Linux operating system any such attempt by admin users
can be achieved by MySQL
Administrator program. This program is an official product of MySQL running on Linux operating systems and in
addition to many monitoring and editing functions it has one
-
click backup and recovery components.

5.3.

MAINTAINABILITY

As it
has been indicated before in the software requirements specification document TiTiS needs at least one
person to perform maintenance operations. System will include a configuration and initialization manual with
itself so that the administrators can know h
ow to use and configure the system so minor software maintenance
of the software itself can be easily done.


Page
21

of
25


5.4.

FLEXIBILITY

Ruby on Rails framework
provide the system modularity as it is one of the key philosophies behind the ROR
framework.
In case of reengineering or reverse engineering, it will be much easy because
Ruby on Rails is
intended to emphasize Convention over Configuration (CoC), and the rapid development principle of Don't
Repeat Yourself (DRY).

5.5.

PORTABILITY

The system
will be
easily portable to all Linux environments on the server side.

Any system which holds the
required dependencies such as ruby, ROR and MySQL will be able to run server side applications. Also even
though it is not an aim of this project, TiTiS can be easily
imported to any Windows or Mac computer with
dependency requirements fulfilled.

Client side is portable as much as it can be because there is no need of any software other than a web browser.

Databases are always easily ported to other machines with their
own RDBMS’ export and import functions.

6.

REJECTED ALTERNATIVES

There have been many rejected alternatives during the design phase of our TiTiS project. First of all, many of
our proposed technologies were different. We intended to use Java programming langu
age with Oracle XE
database. In addition, we were going to use Google Web Toolkit

(GWT)
. These ideas were rejected at the
beginning of the design phase.

There were many reasons why these alternatives were rejected. Firstly, there were many frameworks for j
ava
programming language, all of them
were
complicated
or

complex

for learning and implementing from scratch
for a team consisting of two members. Also, time constraints were pushing us into more agile development
methodologies. Lastly, we were not very fa
miliar with GWT and Oracle as we should. This was a problem since
GWT was lacking reference materials and Oracle had a steep learning curve.

Ruby on Rails, made it possible for us to use RAD tools and Agile development with a near zero learning curve.
Also

it is highly documented and it is easy to obtain tutorials for development. As ROR was compatible with
MySQL, PostgreQL and sqllite, we quickly turned our Oracle decision for database down in exchange of MySQL
in which we are highly familiar.

7.

REFERENCES

[1]
-

Information and general definition about Model View Controller architectural pattern
:

http://en.wikipedia.org/wiki/Model
-
View
-
Controller

[2]


Documentation regarding to Ruby MySQL co
nnector:
http://www.kitebird.com/articles/ruby
-
mysql.html

[3]
-

Requirements list:
http://www.w3.org/QA/2002/0
7/WebAgency‐Requirements#reqlist

IEEE Recommended Practice for

Software Design Descriptions

-

IEEE STD 1016
-
1998




Page
22

of
25


8.

APPENDIX

8.1.

USE CASES

8.1.1.

ADMIN











Page
23

of
25


8.1.2.

HEAD OF DEPARTMENT



8.1.3.

STUDENT AFFAIRS


Page
24

of
25



8.1.4.

PROFESSOR


8.1.5.

TEACHING ASSISTANT


8.1.6.

STUDENT





Page
25

of
25


8.2.

SEQUENCE DIAGRAM