CourseSchedulerDesign Description

Version 0.1

Doc. No.:

CourseScheduler Version: 0.1Design Description Date: 2009-11-01

Revision HistoryDate 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 Version: 0.1Design Description Date: 2009-11-01

Table of Contents1. Introduction 4

1.1 Purpose of this document 41.2 Intended Audience 41.3 Scope 41.4 Definitions and acronyms 4

1.4.1 Acronyms and abbreviations 41.5 References 4

2. External interfaces 52.1 Modularization and organization 62.2 Fragmentation 6

2.2.1 Login Checker 62.2.2 Footer 72.2.3 Head 72.2.4 Admin Tabs 82.2.5 Frontpage Tabs 82.2.6 Welcome Message 8

3. Software architecture 93.1 Conceptual design 9

3.1.1 Client-server architecture 93.1.2 The MVC pattern 93.1.3 Architecture layers 10

3.2 System specification 113.3 Error handling 11

4. Detailed software design 124.1 Directory structure 124.2 Class diagram 134.3 Database model 144.4 Sequence diagrams 15

5. Approvals 16

Appendix A. Sequence Diagrams 17System Administrator – Managing Users 17System Administrator – Managing Rooms 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 orabbreviation Definitions

HTTP HyperText Transfer ProtocolAJAX Asynchronous JavaScript and XMLMVC Model-View-Controller patternJSF Java Server FacesUI User InterfaceJSP Java Server PagesPOJO Plain Old Java ObjectDAO Data access objectVO Value ObjectCRUD Create-Read-Update-Delete (basic entity actions)(X)HTML (Extensible) HyperText Markup LanguageCSS Cascading Style SheetsGUI Graphic User Interface

1.5 References

Project homepagehttp://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/check-login.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

timetabling title – CourseScheduler

2.2.4 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 JSFo JSPo HTMLo CSSo jQuery

Backendo Java

Databaseo SQL queries (as a part of stored procedures)

No special framework, except jQuery, will be used.

3.3 Error handling

Error ActionUser input error Cancel the current action. Notify the user.Data access error Notify the user. Notify the system administrator.Server error Notify the user. Notify the system administrator.Client error (JavaScript) 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 applicationIn 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 TomcatBeside 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 Title Dateyyyy-mm-dd Signature

Ivica Crnković customerRikard Land 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