CourseScheduler
Design Description
Version 0.1
Doc. No.:
CourseScheduler
Design Description
Version:
0.1
Date: 2009-11-01
Revision History
Date
Version
Description
Author
2009-10-06
0.01
Initial Draft
Egle Samuleviciute
2009-10-08
0.02
Software architecture, Sequence diagrams
Dario Vuljanić
2009-10-09
0.03
External interfaces
Kristian Poslek
2009-10-09
0.04
Release candidate for the first iteration
Dario Vuljanić
2009-10-09
0.05
Revision of database model
Dario Vuljanić
2009-10-31
0.06
Architecture update
Narendran Sivakumar
2009-11-01
0.07
Site organization and modularization
Kristian Poslek
2009-11-01
0.08
Database model update
Dario Vuljanić
2009-11-01
0.09
Directory structure and class diagram
Zvonko Ivić
2009-11-01
0.10
Added sequence diagrams
Dario Vuljanić
2009-11-03
0.11
Architecture update
Narendran Sivakumar
Page 2
CourseScheduler
Design Description
Version:
0.1
Date: 2009-11-01
Table of Contents
1.
Introduction
4
1.1
1.2
1.3
1.4
4
4
4
4
4
4
1.5
2.
3.
External interfaces
5
2.1
2.2
6
6
6
7
7
8
8
8
3.2
3.3
5.
Modularization and organization
Fragmentation
2.2.1
Login Checker
2.2.2
Footer
2.2.3
Head
2.2.4
Admin Tabs
2.2.5
Frontpage Tabs
2.2.6
Welcome Message
Software architecture
3.1
4.
Purpose of this document
Intended Audience
Scope
Definitions and acronyms
1.4.1
Acronyms and abbreviations
References
Conceptual design
3.1.1
Client-server architecture
3.1.2
The MVC pattern
3.1.3
Architecture layers
System specification
Error handling
9
9
9
9
10
11
11
Detailed software design
12
4.1
4.2
4.3
4.4
12
13
14
15
Directory structure
Class diagram
Database model
Sequence diagrams
Approvals
Appendix A. Sequence Diagrams
System Administrator – Managing Users
System Administrator – Managing Rooms
16
17
17
18
Page 3
1.
Introduction
1.1
Purpose of this document
Purpose of this document is to describe system design of the Course Scheduler project, as a part of the
Distributed Software Development (DSD) course, held by Faculty of Electrical Engineering and
Computing in Croatia and Mälardalen University in Sweden.
1.2
Intended Audience

Customer, who should know about system design for better understanding of how we
see his ideas and how we intend to realize his ideas.

Supervisor, who should be informed about everything involving this project.

Team members, who should see the big picture about the system architecture.

Future developers of the system, who should know about the basics of the system
before they start upgrading it.
1.3
Scope
This document describes high and low level system design and explains main part of the system.
1.4
Definitions and acronyms
1.4.1
Acronyms and abbreviations
Acronym or
abbreviation
HTTP
AJAX
MVC
JSF
UI
JSP
POJO
DAO
VO
CRUD
(X)HTML
CSS
GUI
1.5
Definitions
HyperText Transfer Protocol
Asynchronous JavaScript and XML
Model-View-Controller pattern
Java Server Faces
User Interface
Java Server Pages
Plain Old Java Object
Data access object
Value Object
Create-Read-Update-Delete (basic entity actions)
(Extensible) HyperText Markup Language
Cascading Style Sheets
Graphic User Interface
References
Project homepage
http://www.fer.hr/rasip/dsd/projects/coursescheduler
Page 4
2.
External interfaces
The user interface of the Course Scheduler system is a standards-compliant web application user
interface built with ease of use in mind.
It is built using XHTML for content, CSS for design and JavaScript (through the jQuery framework)
for user interactivity. This conforms to the best practices that the World Wide Web Consortium (W3C)
recommends.
Figure 1 User interface sketch
The sketch of the Course Scheduler’s user interface shows regions of the site the user is going to
interact with.
The layout is based on two navigations. First, there is the tabbed site wide navigation which is the same
for all users and represents parts of the system all of the users can access. The second navigation is a
contextual list of links that is going to change depending on the part of the system that user is using at
the moment.
Users can use the user bar to see a welcome message, logout, see the current date and additional
functions if necessary.
Every time the user makes a request to the system that requires a message response, it is going to be
displayed in the status messages part. That message clearly indicates the nature of the response by color
(green for successful events and red for the unsuccessful ones).
Copyrights, site info and a link list are displayed in the footer part.
Page 5
2.1
Modularization and organization
Each individual page on the system is stored in it’s own JSP file. To make updating and maintaining of
the system easier all pages have been modularized by using predefined fragments.
2.2
Fragmentation
The individual fragments are:
 Login Checker,
 Footer,
 Head,
 Admin Tabs,
 Frontpage Tabs and
 Welcome Message.
Individual properties of these fragments are going to be explained next.
Figure 2 - Fragments placement
2.2.1
Login Checker
The Login Checker fragment’s main responsibility is to check for the user’s system status. It’s
functionality includes only checking if the user is logged in but it’s going to expand to include
checking for roles.
If the login-checker.jsp file is included with a <%@ include file=”fragments/checklogin.jsp” %> directive, it’s going to check if the user is logged in. That’s basically protecting a
page from being accessed by unauthorized users.
Page 6
Depending on the status of the user, tree things can happen:
1. If the user isn’t logged in, he’ll be presented with the login.jsp page containing a login form with a
warning message that he isn’t authorized to view the requested page. The Logic Checker fragment
is smartly built and remembers the user’s request page so that it can redirect the user to the right
page after a successful login.
2. If the user is logged in and doesn’t have the rights to access the requested page, he’ll be redirected
to the front page with an error message.
3. If the user is logged in and has authorization to access the requested page, he’ll get the resource he
requested.
This fragment has to be included as the first thing on the page to be able to do it’s job.
2.2.2
Footer
The Footer fragment contains all the necessary copyright and impressum information. By using this
fragment, it’s possible to make a tree of links to ease the access to certain parts of the system.
2.2.3
Head
The Head fragment makes it much easier to implement a working <head> tag. It’s purpose is to
predefine some sensible values that conform to the system and generate tags out of these values. It’s
enough to just include this fragment into the <head> tag and all of the necessary tags (like character
set, title, JavaScript files, CSS files etc.) will be generated.
If the need arises, it’s easy to override the predefined values by using JSP’s parameter tag.
The possible overrides include:
 css-files – This parameter makes the inclusion of a custom string of CSS files possible. To
distinct between multiple CSS files, the pipe delimiter (|) has to be used.
Example: To include style.css and layout.css from the style folder, the parameter would have
to be “style/style.css|style/layout.css”. The fragment will then generate CSS
links to these files in the same order they were passed in (first style.css and then layout.css).
 js-files – This parameter makes the inclusion of a custom string of JavaScript files possible.
To distinct between multiple JavaScript files, the pipe delimiter (|) has to be used.
Example: To include script.js and extras.js from the script folder, the parameter would have to
be “script/script.js|script/extras.js”. The fragment will then generate JavaScript
includes to these files in the same order they were passed in (first script.js and then extras.js).
 charset – The character set that’s going to be filled into the charset meta tag.
 description – A description string that’s going to be filled into the description meta tag.
 keywords – A keywords string that’s going to be filled into the keywords meta tag.
 title – A title string that’s going to be added to the default title of the page which is
“CourseScheduler”. Note that the removal of CourseScheduler at the beginning of the title is
not possible. For example, if a title of “Dashboard” was included, the resulting title would be
“CourseScheduler > Dashboard”.
If no parameters are passed to the fragment (only the include directive is called), all of the predefined
default values will be used.
The default values are:
 css-files – style/style.css, style/CourseScheduler.css
 js-files – script/jquery-1.3.2.min.js, script/script.js, script/prototype.js, script/lightbox.js,
script/cs.js
 description – CourseScheduler is a scheduling Web application built for a course being held at
FER and MDH.
 keywords – course, courses, scheduler, scheduling, coursescheduler, fer, mdh, university,
Page 7

2.2.4
timetabling
title – CourseScheduler
Admin Tabs
The Admin Tabs fragment, like all other tab fragments, generates the tab fragments based on some
rules.
It’s duty is twofold:
1. The fragment determines the current page and makes that tab appear active. This is performed by
analyzing the current URI and activating the corresponding tab.
2. The fragment generates all the tabs that the user is allowed to see based on the roles he possesses.
2.2.5
Frontpage Tabs
The Frontpage Tabs fragment, like all other tab fragments, generates the tab fragments based on some
rules.
It’s duty is twofold:
3. The fragment determines the current page and makes that tab appear active. This is performed by
analyzing the current URI and activating the corresponding tab.
4. The fragment generates all the tabs that the user is allowed to see based on the fact that he’s logged
in. Not logged in users won’t be able to see the User page tab.
2.2.6
Welcome Message
The Welcome Message fragment makes it possible to display the welcome message and, based on the
user’s status, additional messages and/or control parts.
Based on the user’s status, the following can be displayed:
 Welcome message – if the user is logged in, he’s going to be greeted by a personalized
message containing his name. Otherwise, a guest message is displayed with the login form to
log in.
 Login form – if the user isn’t logged in he’s going to be presented with a login form. After a
successful login, he’ll be brought back to the page he logged in from.
 Logout link – if the user is logged in, he can log out of the system by following this link.
 Admin access – if the user is logged in and has the privileges, an additional menu with Admin
pages that he has access to, will be displayed.
Page 8
3.
Software architecture
3.1
Conceptual design
3.1.1
Client-server architecture
Figure 3 Client-server architecture overview
The Course Scheduler system is a web based system using standard client-server architecture. On the
client side, client computer uses web browser to access the CourseScheduler system. Standard HTTP
protocol is used in the client-server communication. On the server side, web server receives requests
from the client, handles them and sends a response to the client. Web server communicates with the
database, to load and save data. Basic client-server communication will be enhanced with AJAX.
3.1.2
The MVC pattern
Figure 4 JSF implementation of the MVC pattern
The Course Scheduler system is created using the MVC pattern, JSF implementation of it. The MVC
design pattern makes JSF applications more manageable because it separates the user interface
consisting of JSF pages (View) from the application data and logic (Model). Client interactions are
managed using front-end Faces servlets (Controller).
Page 9
3.1.3
Architecture layers
Figure 5 Architecture layers
The CourseScheduler architecture is a multitier architecture, consisting of four main layers:
presentation layer, business layer, database (data access) layer and data storage. First three layers are
running in a web container of an Apache Tomcat web server.
The presentation layer is built upon JSF technology and consists of front-end controllers managing
client interactions, various UI components, JSP files which are describing how UI should look like,
backing beans connected with the UI and JSP files and various resource files. The final output from the
presentation layer, headed towards the client, will be HTML and CSS enhanced with JavaScript.
The business layer consists of JSF beans and delegate classes. JSF beans are used to describe data
model entities. Delegate classes delegate actions on JSF beans to the database layer.
The database layer is used as for data access and consists of POJOs and Data Access objects. POJO
serves the need for abstracting DAO from the delegate layer. The POJO layer is where the bulk of data
processing is done. It also provides a way to plug in future persistence solutions or transaction control
frameworks like EJB’s into the database layer. DAO “knows” all the information needed to
communicate with the database and enables executing actions involving data in the database (CRUD).
The data layer consists of the database. The MySQL database is used on this project. Except the tables,
there will be stored procedures (enabling CRUD and other actions on entities) defined in the database.
Page 10
3.2
System specification
The CourseScheduler system is powered by an Apache Tomcat web server hosted on a virtual machine
and available on the address http://161.53.67.186:8080/. The MySQL database management system
that is used on this project is hosted on the same virtual machine. Rules and responsibilities for
handling the application and the database are explained in the VM management policy document,
available on the project homepage.
Various technologies and tools are going to be used on this project:
 Frontend
o JSF
o JSP
o HTML
o CSS
o jQuery
 Backend
o Java
 Database
o SQL queries (as a part of stored procedures)
No special framework, except jQuery, will be used.
3.3
Error handling
Error
User input error
Data access error
Server error
Client error (JavaScript)
Action
Cancel the current action. Notify the user.
Notify the user. Notify the system administrator.
Notify the user. Notify the system administrator.
Notify the user.
Page 11
4.
Detailed software design
4.1
Directory structure
Figure 6 Directory structure
Figure 6 shows directory structure of the application.
We have two main folders:
 src – contains all the Java source code, and external libraries that are used
Page 12

WebContent – contains the parts of application that are need to present the application as web
application
Folders in src folder are arranged into packages:
 com.cs.dao – contains the classes of DAO layer
 com.cs.dao.exception – contains the classes the define errors that may occur while accessing the
database
 com.cs.delegate - contains the classes of Delegate layer
 com.cs.jsf.beans – contains the Beans classes
 com.cs.jsf.servlets – contains the servlet classes
 com.cs.pojo – contains the classes of POJO layer
 com.cs.unit.test.vo – contains the classes that do unit tests of VO objects
 com.cs.vo – contains the classes that hold information about entities in database, and that “travel”
between different layers of the application
In src folder, there is one more folder called Libraries, which contains the libraries used in other parts of our
application.
Next, we have the WebContent folder, which contains the following folders:
 fragments – contains JSP files that are used as fragments in other JSP files in the application
 images – contains all the images used by the application
 META-INF – contains the MANIFEST.MF file that is used to define how the application should be run
 script – contains the Javascript classes used in the application
 style – contains the CSS files that define visual look of the JSP files
 WEB-INF- contains the libraries and definitions needed for the application to be published in web
container, like the one used in Apache Tomcat
Beside these folders, WebContent folder contains all of the JSP files used in the application.
4.2
Class diagram
Figure 7 Class diagram
Page 13
Figure 7 shows a class diagram which contains representative classes of all the layers of the application, and
shows how those classes are connected and dependant on each other.
In it we can see the class RoomBean which contains list of rooms that are represented by VO class Room. It also
uses and depends on the class RoomDelegate, which is part of Delegate layer. Class RoomDelegate in similar
way uses and depends on the class RoomPOJO, which is part of POJO layer. And class RoomPOJO uses and
depends on the class RoomDAO, which is part of DAO layer.
We can also see a class RoomUT, which contains the unit test methods that test the VO class Room.
4.3
Database model
Figure 8 Database model – entity-relationship diagram
Figure 8 shows relational database model, with tables and their connections. Program has one level assigned and
has a status indicating if it is active or not. Also, program can have multiple links with additional information
assigned. Program has many program instances, each one starting on one specific academic year. Academic year
consists of 4 periods. Year calendar defines which days are working and which are not for some academic year.
Page 14
Course is described with some general info about the course and has one language assigned as teaching
language. Like program, course also has a status indicating if the course is active or not and can have multiple
link with additional information assigned. Course can have multiple course instances, each one starting on
different period in some academic year. Course instance can be assigned to multiple program instances. Course
place is connected to course instance. Each course instance can have multiple constraints defined. All course
instance constraints for one course instance are gathered together and serve as input in the scheduling process.
Course instance has course elements defined (lectures, laboratories …) with lecturers assigned to each course
elements (one lecturer can be assigned to more course elements). Course element can also have some constraint
defined – these constraints will be lower level constraints than course instance constraints. Course element plan
describes in which periods will which course element be active (for example, in period from 2009-09-05 until
2009-10-12 lectures will be held, twice a week for 120 minutes each time). In course element plan course
element group enables defining parallel course elements that can be held at the same time (for example, there
are laboratories divided in two groups of students and scheduled at the same time). These parallel activities can
be marked as required or possible.
Before the schedule is created, lecturers can defined some general preferences as schedule proposals (preferred
room, time slot or day of the week). Schedule has exact time slot and room defined for course element. Once the
schedule is created, lecturers can make schedule change proposals. Each schedule change proposal has status
which defines in which stage the proposal is (created, being considered, rejected, accepted) and a message
explaining the status. Lecturer has some general info and a user account, which enables him to login in to the
system and manage information and settings on parts of the system she/he has access to.
4.4
Sequence diagrams
Figure 9 Sequence diagram – common actions
Figure 9 shows general concept in actions working with data, followed by every detailed sequence
diagram available. When an action is started and the data is needed, business layer is contacted.
Delegate classes in the business layer delegate the action to the database layer. The database layer
communicates with the database and executes the action. When the action is executed, the result is
returned and managed. At the end, the result is displayed in the presentation layer. Actions that don’t
use data from the database will not use the whole described cycle. Some sequence diagrams are
available in the Appendix A.
Page 15
5.
Approvals
Name
Ivica Crnković
Rikard Land
Title
Date
yyyy-mm-dd
Signature
customer
supervisor
Page 16
Appendix A. Sequence Diagrams
There are two ways of accessing the database shown in these diagrams:
 ExecuteNonQuery – the action is executed but no result set is returned (for example, deleting
users returns no data from the database, just a value indicating if it was succesfull)
 ExecuteQuery – the action is executed and the result set of values is returned (for example,
fetch the list of users from the database)
System Administrator – Managing Users
Page 17
System Administrator – Managing Rooms
Page 18