73360839 Project Report on Rich Internet Application for Automatic College Timetable Generation 24th March 2008

ON

Guided By

Prof. M. A. Pund

Submitted By

Ajinkya Kulkarni Ajay Chate

Mandar Kavishwar Shailesh Thakre

Prafulla Ingle Gaurav Bhuyar

DDeeppaarrttmmeenntt OOff CCoommppuutteerr SScciieennccee AAnndd EEnnggiinneeeerriinngg

PPrrooff.. RRaamm MMeegghhee IInnssttiittuuttee ooff TTeecchhnnoollooggyy AAnndd RReesseeaarrcchh,,

BBaaddnneerraa

22000077--0088

This is to certify that the Project work entitled,

"RICH INTERNET APPLICATION FOR WEEKLY AUTOMATIC

COLLEGE TIMETABLE GENERATION"

has been duly completed by the following students

in a satisfactory manner as partial fulfillment for the

Degree of Bachelor of Engineering in Computer Science and Engineering

Submitted By

Ajinkya Kulkarni Ajay Chate

Mandar Kavishwar Shailesh Thakre

Prafulla Ingle Gaurav Bhuyar

DDeeppaarrttmmeenntt OOff CCoommppuutteerr SScciieennccee aanndd EEnnggiinneeeerriinngg

Prof. RAM MEGHE INSTITUTE OF TECHNOLOGY & RESEARCH, BADNERA

2007-08

Prof. M. A. PUND

GUIDE

Department of Computer Science

And Engineering

P.R.M.I.T. & R, Badnera

Prof. Dr. M. S. ALI

HEAD OF DEPARTMENT

Department of Computer Science

And Engineering

P.R.M.I.T. & R, Badnera

We have no words to express our gratitude and thanks to our

guide, Prof. M. A. Pund. His interest and inspiration always boosts our moral to be

progressive in our project. We are very much grateful and thankful for his

guidance, we are indebt to him for his guidance, valuable suggestions and

encouragement during the preparation of project.

We express our special thanks to our H.O.D. Prof. Dr. M. S. Ali for

teaching us Extensible Markup Language, on which our knowledgebase is based.

We will be failing in our duty if we do not express our sincere

thanks to all staff members of Computer Science and Engineering Department.

Last but not the least; we thank all those who helped us directly or

indirectly in completing this project work.

Thanking you!

Projectees….

Table of Contents

Sr. No

Title Page No

Abstract 1

1 Introduction 2

2 Literature Survey 4

2.1 Timetabling 4

2.1.1 The General View 5

2.1.2 The Object-Oriented View 6

2.1.3 Planning 6

2.1.4 Constraints 9

2.2 Rich Internet application 10

2.2.1 Introduction 10

2.2.2 History 10

2.2.3 General Benefits 11

2.2.4 Performance Benefits 12

2.2.5 Shortcomings 13

2.2.6 Software development complications 15

2.2.7 Current status of development 17

2.3 AJAX 23

2.3.1 Introduction 23

2.3.2 Use of AJAX 24

3 General Problem Formulation 25

3.1 Strong Constraints 26

3.2 Weak Constraints 26

4 Requirements and Analysis 28

4.1 Automatic Generation of Timetable 28

4.1.1 Details about Java 29

4.1.2 Different criteria and conditions to consider while

generating timetable

29

4.2 Standardized Knowledgebase representation 30

4.2.1 XML 30

4.3 Responsive Interface 31

4.3.1 Details about Google Web Tool Kit 32

4.3.2 Introduction of the Google Web Toolkit (GWT) 32

4.3.3 GWT execution modes 32

4.3.4 GWT’s four major components/libraries 33

4.4 Jakarta Tomcat 34

5 System Design 35

5.1 Various Components of Project 35

5.2 Flow of Data within project 36

5.3 Design of Knowledge Base 37

5.4 Design of Timetabling Algorithm 39

5.4.1 The Proposed Timetabling Method 40

5.4.2 The Timetabling Algorithm 40

5.4.3 Data Structure for these lists is represented

visually as follows

40

5.4.4 Teacher-Subject Constraint 41

5.4.5 Teacher –Time Slot Constraint 41

5.4.6 Teacher -Day Constraint 42

5.4.7 Teacher-Year Constraint 42

5.4.8 Year (Semester) – Room Constraint 43

5.4.9 Constraint Matrix 43

5.5 Design of working of algorithm 44

5.6 Initialize Timetable Method 46

5.7 The Working Of Perform Allocation_Method 47

5.8 Data Flow within Algorithm 48

5.9 Front End Design 49

6 Implementation 51

6.1 Timetabling Algorithm 51

6.1.1 Details about Main class which is responsible for

generating timetable

51

6.1.2 Step by Step Execution of Algorithm 55

6.2 Front End Implementation 69

6.2.1 Implementation GWT Client Side Package 69

6.2.2 Implementation GWT Server Package 73

6.3 Screenshots of execution of algorithm 74

6.4 Screenshots of our front end built using Google

Web ToolKit

81

6.4 Installation Manual 90

6.5 Operation Manual 90

6.6 Performance of Algorithm 91

7 Conclusions 92

References 93

Future Work 94

Bibliography 95

List of Figures No. Title Page No.

Fig.2.1 Class View & Teacher View 07

Fig.2.2 Mapping of Timetables 08

Fig.2.3 Redundancy of Information 09

Fig.4.1 The Structure of GWT 33

Fig.5.1 Various Components of Project 35

Fig.5.2 Flow of Data within Project 36

Fig.5.3 Design of Algorithm 39

Fig.5.4 Data Structures 40

Fig.5.5 Teacher-Subject Constraint 41

Fig.5.6 Teacher-Slot Constraint 41

Fig.5.7 Teacher-Day Constraint 42

Fig.5.8 Teacher-Year Constraint 42

Fig.5.9 Year-Room Constraint 43

Fig.5.10 Constraints Matrix 43

Fig.5.11 Design of Working of Algorithm I 44

Fig.5.12 Design of Working of Algorithm II 45

Fig.5.13 Sample Timetable 45

Fig.5.14 Steps for Initializing Timetable 46

Fig.5.15 Working of Perform Allocation Method 47

Fig.5.16 Data Flow within Algorithm 48

Fig.5.17 Client-Server Architecture 49

Fig.5.18 Compilation Process of GWT 50

Fig.6.1 Structure of Timetable 57

Fig.6.2-6.12 Step wise Execution of Algorithm 58-68

Fig.6.13 Debugging in NetBeans IDE 74

Fig.6.14 Representations of Lists in Memory 75

Fig.6.15 Internal Memory Allocation 76

Fig.6.16 Object Storage in Timetable Grid 77

Fig.6.17 Memory Representation of Teacher List 78

Fig.6.18 Memory Representation of Constraints List 79

Fig.6.19 Final HTML Output 80

Fig.6.20-6.28 Screen Shots of Front End 81-89

Fig.6.29 Performance of Algorithm 91

Fig.6.30 Conflict & Collision Percentage 91

Rich Internet Application for Weekly Automatic College Timetable Generation

PRMIT&R//DCSE//07-08 1/95

Abstract

A college timetable is a temporal arrangement of a set of classes and classrooms in

which all given constraints are satisfied. Timetabling has long been known to belong to the

class of problems called NP hard. This project introduces a practical timetabling algorithm

capable of taking care of both strong and weak constraints effectively, used in an automated

timetabling system.

Rich Internet applications (RIA) are web applications that have the features and

functionality of traditional desktop applications. RIAs typically transfer the processing

necessary for the user interface to the web client but keep the bulk of the data (i.e.,

maintaining the state of the program, the data etc) back on the application server. We have

used the Google Web Toolkit, which is RIA framework, for the same purpose. Our project

reduces the overhead on server of rendering client’s UI components and makes room for

processing time of Timetable Generator Algorithm.

Our Timetabling Algorithm is main component of our project which produces the

HTML based weekly timetable sheet as the output. Our project takes various inputs from the

user such as Teacher List, Course List, Semester List, Room List, Day List and Timeslot as well

as various rules, facts and constraints using web based forms, which are stored in XML based

knowledge base. This knowledge base serves as input to our Timetable Generator Algorithm

residing on server machine.

Both GWT Client Side UI code and our algorithm are written in JAVA, which makes our

project platform independent. Further benefits of choosing these frameworks are explained in

later part of report with practically acceptable results.



1. Introduction

Even though most college administrative work has been computerized, the lecture-

timetable scheduling is still mostly done manually due to its inherent difficulties. The manual

lecture-timetable scheduling demands considerable time and efforts. The lecture-timetable

scheduling is a constraint satisfaction problem in which we find a solution that satisfies the

given set of constraints.

The college lecture-timetabling problem asks us to find some time slots and classrooms

which satisfy the constraints imposed on offered courses, instructors, classrooms and so on.

Therefore, the variables to be instantiated are time slots and classrooms of offered courses.

Since the problem is a combinatorial optimization problem belonging to NP-hard class, the

computation time for timetabling tends to grow exponentially as the number of variables

increase.

There have been a number of approaches made in the past decades to the problem of

constructing timetables for colleges and schools. Timetabling problems may be solved by

different methods inherited from operations research such as graph coloring and

mathematical programming, from local search procedures such as tabu search and simulated

annealing, from genetic algorithms or from backtracking-based constraint satisfaction

manipulation

In our project, timetabling problem is formulated as a constraint satisfaction problem and

we proposed a practical timetabling algorithm which is capable of taking care of both strong

and weak constraints and finding variables’ instantiation, which is based on the forward

tracking search.

During designing of our project, we first decided to define the way of representation of

Knowledgebase. Since representation of knowledgebase was certainly going to affect our way



of thinking during building of timetabling algorithm. We decided that XML is appropriate

because of its inherent features which are discussed in next section.

Our knowledgebase is in the middle, because it is between our timetabling algorithm and

GUI front end which is designed in the last. After the representation of KB is standardized, we

designed the timetabling algorithm. The design of timetabling algorithm took most of our

total time. During design of algorithm, first problem was, from where to start? Second

problem was, does it really going to work? But after all due to our superior design of

knowledgebase, flowcharts and enough thinking on timetabling data structure representation

helped us to really boosted building our fine working algorithm.

The algorithm which we have built totally uses our knowledge of theory subjects including

programming methodology, data structure and designing and analysis of algorithms. The

previous efforts which we have spent on learning these subjects at that time helped us during

designing and building of our whole project, especially in our timetabling algorithm.

After completion of testing of our timetable generator algorithm, we moved towards

designing of Front End. Our prime aim was to build the Rich Internet Application (RIA). Why

we have chosen RIA architecture is explained in details in next section along with our survey

for various RIA architectures. Once the survey was over we choose the Google’s Web Toolkit

(GWT) for building RIA. This decision is taken during our Requirement and Analysis phase and

details GWT is explained in that section.



2. Literature Survey

2.1 Timetabling

A timetable construction is an NP-complete scheduling problem. It is not a standard

job–shop problem because of the additional classroom allocation. It is large and highly

constrained, but above all the problem differs greatly for different schools and educational

institutions. It is difficult to write a universal program, suitable for all imaginable timetabling

problems. Although manual construction of timetables is time-consuming, it is still

widespread, because of the lack of appropriate computer programs.

Many real-world Timetabling Problems are composed of organizational parts that need

to timetable their staff in an independent way, while adhering to some global constraints.

Later, the departmental timetables are combined to yield a coherent, consistent solution. The

last phase involves negotiations with the various agents and requests for changes in their own

solutions. Most of the real-world distributed timetabling problems that fall into this class have

global constraints that involve many of the agents in the system.

There exist many different timetabling problems such as university or examination

timetabling, school timetabling, sports timetabling or employee timetabling. Furthermore,

there exist many problem solving methods, which usually use the concepts of standard

optimization algorithms such as Backtracking, Evolutionary Algorithms or Constraint Logic

Programming.

In recent years two main approaches seem to have been successful. The first approach

is based on local search procedures such as simulated annealing , tabu search and genetic

algorithms . These methods express constraints as some cost functions, which are minimized

by a heuristic search of better solutions in a neighborhood of some initial feasible solution.

Their greatest disadvantages are (1) the difficulty of taking into account hard constraints and



(2) the need to determine their parameters through experimentation. Although they are good

for optimizing the initial feasible solution, they have problems with finding it.

The second approach is based on constraint programming (CP). Its main advantage is

declaratively: a straightforward statement of the constraints serves as part of the program.

This makes the program easy to modify, which is crucial in timetabling problems. The

constraints are handled through a system of constraint propagation, which reduces domains

of variables, coupled with backtracking search. In modern CP languages, both features do not

need to be programmed explicitly. The main disadvantages of this approach are (1) difficulties

with expressing soft constraints and (2) possible problems with improving the initial feasible

solution, which – as a rule – may be determined without difficulties. An attempt to overcome

the drawbacks with soft constraints was discussed, successfully combined local search with

constraint satisfaction to reduce their drawbacks. They determined an initial solution using

constraint logic programming and then optimized it using tabu search.

The ability to express complex constraints in a simple, declarative way is crucial for

introducing the requirements of the high school and university timetabling problem into the

program and is decisive for their successful solution, – a custom-tailored distribution strategy

is able to introduce soft constraints during a search, leading quickly to a “good” timetable, –

incorporation of local search into CP gives the ability to optimize effectively the timetable.

2.1.1 The General View

As mentioned before, many types of timetabling problems exist. But all these

problems have several properties in common. One of these similarities is that certain entities

have to be scheduled. For example, the high school timetabling problem has several entities

such as classes or students, teachers, subjects, lessons and rooms. All these entities have

properties. For example classes are linked to the subject the students of this class are taught.

Usually, these entities are differentiated into resources and events (or sometimes

called meetings). In addition, constraints have to be considered. In the employee timetabling



case, for instance, we find those entities, too. There are employees with different

qualifications and monthly target hours or there are shifts to be assigned to employees. As

already mentioned, some of these entities are linked with others. There exist links from the

shifts to the employees assigned to these shifts or from the classes to their teachers. Some of

these links are fixed, such as the links from the shifts to the employees with the qualifications

required to work on these shifts, and cannot be changed. Others have to be assigned during a

planning process, e.g. linking a lesson to a suitable room. A planning algorithm has to

construct a timetable, so we have to define what a timetable consists of. A timetable can be

interpreted as an arbitrary sequence of events. To every event a certain number of time

intervals are assigned, each having a starting and an ending point.

2.1.2 The Object-Oriented View

The above section can be used to describe timetabling problems in an object-oriented

manner: There are different resources whose instances have references to each other, e.g. an

instance of the subject class refers to instances of the teacher class who are able to teach that

subject. Moreover, there are entities with a certain property, called events. This property is a

certain time interval (or several time intervals) that is assigned to these events

2.1.3 Planning

An algorithm for constructing a timetable has to assign instances of the different

resource classes to the event class instances. Some of these assignments are predetermined

and cannot be changed, and some have to be done during the planning phase. To construct a

timetable, one of the views mentioned in above section is used. In the school timetabling case

our algorithm might use the class view to assign a subject, teacher and room to a lesson. In

this case the class is fixed and the other instances have to be assigned to (see Figure 2.1).

Additionally, a time interval has to be assigned to each event class instance.



Figure 2.1

For each viewing perspective there are as many timetables as instances of this class to

be planned exist. If we have t teachers at a high school, for example, t different teacher

timetables belong to them. That is, if there exist l lessons in a high school timetabling

problem, furthermore t teachers, r rooms and c classes, the number of instances of event

classes including all views will be (t+r+c)×l.

The timetables of the instances of one planning class contain all information necessary

to construct the timetables for the instances of the other planning classes: i.e. the timetables

of the different views can be mapped to timetables of other views. In the school timetabling

case the t teachers’ timetables can be mapped to the r rooms’ timetables (see Figure 2.2).



Figure 2.2

That is why it is usually sufficient for a timetabling program to save the timetables of

one resource type only. This avoids data redundancy caused by storing the same event

information in different places, i.e. from different views (see Figure 2.3). Nevertheless, to be

able to check constraint violations, translations to other views have to be done, for example

to compute the number of assigned lessons of a teacher when working with the class view.

Otherwise expensive computing time has to be accepted in order to compute the necessary

information.



Figure 2.3

Nevertheless, to be able to check constraint violations (see the next section), translations to

other views have to be done, for example to compute the number of assigned lessons of a

teacher when working with the class view.

Otherwise expensive computing time has to be accepted in order to compute the necessary

information.

2.1.4 Constraints

Assignments usually cannot be done arbitrarily, but many constraints have to be

considered. We distinguish two different types, namely hard and soft constraints. A solution is

feasible if no hard constraints are violated. A feasible solution is better than another if fewer

soft constraints are violated.

A timetabling algorithm can use different strategies to get a solution without violations

of hard constraints. Violations can either be avoided from the outset or penalized to lead the

algorithm towards better solutions and introduce repair mechanisms.


PRMIT&R//DCSE//07-08 10/95

2.2 Rich Internet application

2.2.1 Introduction

Rich Internet applications (RIA) are web applications that have the features and

functionalities of traditional desktop applications. RIAs typically transfer the processing

necessary for the user interface to the web client but keep the bulk of the data (i.e.,

maintaining the state of the program, the data etc) back on the application server.

RIAs typically:

• run in a web browser, or do not require software installation

• run locally in a secure environment called a sandbox

2.2.2 History

The term "Rich Internet Application" was introduced in a white paper of March 2002 by

Macromedia, though the concept had existed for a number of years earlier under names such

as:

• Remote Scripting, by Microsoft, circa 1998

• X Internet, by Forrester Research in October 2000

• Rich (web) clients

• Rich web application

Traditional web applications centered all activity around a client-server architecture with a

thin client. Under this system all processing is done on the server, and the client is only used

to display static (in this case HTML) contents. The biggest drawback with this system is that all

interaction with the application must pass through the server, which requires data to be sent

to the server, the server to respond, and the page to be reloaded on the client with the

response. By using a client side technology which can execute instructions on the client's


PRMIT&R//DCSE//07-08 11/95

computer, RIAs can circumvent this slow and synchronous loop for many user interactions.

This difference is somewhat analogous to the difference between "terminal and mainframe"

and Client-server/Fat client approaches.

Internet standards have evolved slowly and continually over time to accommodate these

techniques, so it is hard to draw a strict line between what constitutes an RIA and what does

not. But all RIAs share one characteristic that they introduce an intermediate layer of code,

often called a client engine, between the user and the server. This client engine is usually

downloaded at the beginning of the application, and may be supplemented by further code

downloads as the application progresses. The client engine acts as an extension of the

browser, and usually takes over responsibility for rendering the application's user interface

and for server communication.

What can be done in an RIA may be limited by the capabilities of the system used on

the client. But in general, the client engine is programmed to perform application functions

that its designer believes will enhance some aspect of the user interface, or improve its

responsiveness when handling certain user interactions, compared to a standard Web

browser implementation. Also, while simply adding a client engine does not force an

application to depart from the normal synchronous pattern of interactions between browser

and server, in most RIAs the client engine performs additional asynchronous communications

with servers.

2.2.3 General Benefits

Although developing applications to run in a web browser is a much more limiting,

difficult, and intricate process than developing a regular desktop application, the efforts are

often justified because:

1. installation is not required -- updating and distributing the application is an instant,

automatically handled process


PRMIT&R//DCSE//07-08 12/95

2. updates/upgrades to new versions are automatic

3. users can use the application from any computer with an internet connection, and

usually regardless of what operating system that computer is running

4. web-based applications are generally less prone to viral infection than running an

actual executable

Because RIAs employ a client engine to interact with the user, they are:

1. Richer. They can offer user-interface behaviors not obtainable using only the HTML

widgets available to standard browser-based Web applications. This richer

functionality may include anything that can be implemented in the technology being

used on the client side, including drag and drop, using a slider to change data,

calculations performed only by the client and which do not need to be sent back to the

server, for example, a mortgage calculator.

2. More responsive. The interface behaviors are typically much more responsive than

those of a standard Web browser that must always interact with a remote server.

2.2.4 Performance Benefits

The most sophisticated examples of RIAs exhibit a look and feel approaching that of a

desktop environment. Using a client engine can also produce other performance benefits:

1. Client/Server balance. The demand for client and server computing resources is better

balanced, so that the Web server need not be the workhorse that it is with a

traditional Web application. This frees server resources, allowing the same server

hardware to handle more client sessions concurrently.

2. Asynchronous communication. The client engine can interact with the server without

waiting for the user to perform an interface action such as clicking on a button or link.

This allows the user to view and interact with the page asynchronously from the client

engine's communication with the server. This option allows RIA designers to move


PRMIT&R//DCSE//07-08 13/95

data between the client and the server without making the user wait. Perhaps the

most common application of this is prefetching, in which an application anticipates a

future need for certain data, and downloads it to the client before the user requests it,

thereby speeding up a subsequent response. Google Maps uses this technique to

move adjacent map segments to the client before the user scrolls their view.

3. Network efficiency. The network traffic may also be significantly reduced because an

application-specific client engine can be more intelligent than a standard Web browser

when deciding what data needs to be exchanged with servers. This can speed up

individual requests or responses because less data is being transferred for each

interaction, and overall network load is reduced. However, use of asynchronous

prefetching techniques can neutralize or even reverse this potential benefit. Because

the code cannot anticipate exactly what every user will do next, it is common for such

techniques to download extra data, not all of which is actually needed, to many or all

clients.

2.2.5 Shortcomings

Shortcomings and restrictions associated with RIAs are:

1. Sandboxing. Because RIAs run within a sandbox, they have restricted access to system

resources. If assumptions about access to resources are incorrect, RIAs may fail to

operate correctly.

2. Disabled scripting. JavaScript or another scripting language is often required. If the

user has disabled active scripting in their browser, the RIA may not function properly, if

at all.

3. Client processing speed. To achieve platform independence, some RIAs use client-side

scripts written in interpreted languages such as JavaScript, with a consequential loss of

performance (a serious issue with mobile devices). This is not an issue with compiled

client languages such as Java, where performance is comparable to that of traditional


PRMIT&R//DCSE//07-08 14/95

compiled languages, or with Flash movies, in which the bulk of the operations are

performed by the native code of the Flash player.

4. Script download time. Although it does not have to be installed, the additional client-

side intelligence (or client engine) of RIA applications needs to be delivered by the

server to the client. While much of this is usually automatically cached it needs to be

transferred at least once. Depending on the size and type of delivery, script download

time may be unpleasantly long. RIA developers can lessen the impact of this delay by

compressing the scripts, and by staging their delivery over multiple pages of an

application.

5. Loss of integrity. If the application-base is X/HTML, conflicts arise between the goal of

an application (which naturally wants to be in control of its presentation and

behaviour) and the goals of X/HTML (which naturally wants to give away control). The

DOM interface for X/HTML makes it possible to create RIAs, but by doing so makes it

impossible to guarantee correct function. Because an RIA client can modify the RIA's

basic structure and override presentation and behavior, it can cause failure of the

application to work properly on the client side. Eventually, this problem could be

solved by new client-side mechanisms that granted an RIA client more limited

permission to modify only those resources within the scope of its application.

(Standard software running natively does not have this problem because by definition

a program automatically possesses all rights to all its allocated resources).

6. Loss of visibility to search engines. Search engines may not be able to index the text

content of the application.

7. Dependence on an Internet connection. While the ideal network-enabled replacement

for a desktop application would allow users to be "occasionally connected" wandering

in and out of the hot-spots or from office to office, today (in 2008) the typical RIA

requires network connectivity.


PRMIT&R//DCSE//07-08 15/95

8. Accessibility. There are a lot of known Web accessibility issues in RIA, most notably the

fact that screen readers have a hard time detecting dynamic changes (caused by

JavaScript) in HTML content.

2.2.6 Software development complications

The advent of RIA technologies has introduced considerable additional complexity into

Web applications. Traditional Web applications built using only standard HTML, having a

relatively simple software architecture and being constructed using a limited set of

development options, are relatively easy to design and manage. For the person or

organization using RIA technologies to deliver a Web application, their additional complexity

makes them harder to design, test, measure, and support.

Use of RIA technology poses several new service level management (SLM) challenges, not

all of which are completely solved today. SLM concerns are not always the focus of application

developers, and are rarely if ever perceived by application users, but they are vital to the

successful delivery of an online application. Aspects of the RIA architecture that complicate

management processes are:

1. Greater complexity makes development harder. The ability to move code to the client

gives application designers and developers far more creative freedom. But this in turn

makes development harder, increases the likelihood of defects (bugs) being

introduced, and complicates software testing activities. These complications lengthen

the software development process, regardless of the particular methodology or

process being employed. Some of these issues may be mitigated through the use of a

web application framework to standardize aspects of RIA design and development.

However, increasing complexity in a software solution can complicate and lengthen

the testing process, if it increases the number of use cases to be tested. Incomplete

testing lowers the application's quality and its reliability during use.

One could argue that the above comment applies not specifically to RIA technology,


PRMIT&R//DCSE//07-08 16/95

but to complexity in general. For example, that exact same argument was used when

Apple and Microsoft independently announced the GUI in the 1980s, and perhaps

even when Ford announced the Model T. Nonetheless, humans have shown a

remarkable ability to absorb technological advances for decades, if not centuries.

2. RIA architecture breaks the Web page paradigm. Traditional Web applications can be

viewed as a series of Web pages, each of which requires a distinct download, initiated

by an HTTP GET request. This model has been characterized as the Web page

paradigm. RIAs invalidate this model, introducing additional asynchronous server

communications to support a more responsive user interface. In RIAs, the time to

complete a page download may no longer correspond to something a user perceives

as important, because (for example) the client engine may be prefetching some of the

downloaded content for future use. New measurement techniques must be devised

for RIAs, to permit reporting of response time quantities that reflect the user's

experience. In the absence of standard tools that do this, RIA developers must

instrument their application code to produce the measurement data needed for SLM.

3. Asynchronous communication makes it harder to isolate performance problems.

Paradoxically, actions taken to enhance application responsiveness also make it harder

to measure, understand, report on, and manage responsiveness. Some RIAs do not

issue any further HTTP GET requests from the browser after their first page, using

asynchronous requests from the client engine to initiate all subsequent downloads.

The RIA client engine may be programmed to continually download new content and

refresh the display, or (in applications using the Comet approach) a server-side engine

can keep pushing new content to the browser over a connection that never closes. In

these cases, the concept of a "page download" is no longer applicable. These

complications make it harder to measure and subdivide application response times, a

fundamental requirement for problem isolation and service level management. Tools

designed to measure traditional Web applications may -- depending on the details of

the application and the tool -- report such applications either as a single Web page per


PRMIT&R//DCSE//07-08 17/95

HTTP request, or as an unrelated collection of server activities. Neither description

reflects what is really happening at the application level.

4. The client engine makes it harder to measure response time. For traditional Web

applications, measurement software can reside either on the client machine or on a

machine that is close to the server, provided that it can observe the flow of network

traffic at the TCP and HTTP levels. Because these protocols are synchronous and

predictable, a packet sniffer can read and interpret packet-level data, and infer the

user’s experience of response time by tracking HTTP messages and the times of

underlying TCP packets and acknowledgments. But the RIA architecture reduces the

power of the packet sniffing approach, because the client engine breaks the

communication between user and server into two separate cycles operating

asynchronously -- a foreground (user-to-engine) cycle, and a background (engine-to-

server) cycle. Both cycles are important, because neither stands alone; it is their

relationship that defines application behavior. But that relationship depends only on

the application design, which (in general) cannot be inferred by a measurement tool,

especially one that can observe only one of the two cycles. Therefore the most

complete RIA measurements can only be obtained using tools that reside on the client

and observe both cycles.

2.2.7 Current status of development

RIAs are still in the early stages of development and user adoption. There are a number of

restrictions and requirements that remain, which are

1. Browser adoption: Many RIAs require modern web browsers in order to run.

Advanced JavaScript engines must be present in the browser as RIAs use techniques

such as XMLHTTPRequest for client-server communication, and DOM Scripting and

advanced CSS techniques to enable the rich user interface.

2. Web standards: Differences between web browsers can make it difficult to write an

RIA that will run across all major browsers. The consistency of the Java platform,


PRMIT&R//DCSE//07-08 18/95

particularly after Java 1.1, makes this task much simpler for RIAs written as Java

applets.

3. Development tools: Some Ajax Frameworks and products such as Curl, Adobe Flex and

Microsoft Silverlight provide an integrated environment in which to build RIAs.

4. Accessibility concerns: Additional interactivity may require technical approaches that

limit applications' accessibility.

5. User adoption: Users expecting standard web applications may find that some

accepted browser functionality (such as the "Back" button) may have somewhat

different or even undesired behaviour.

2.2.7.1 JavaScript / Ajax

The first major client side language and technology available with the ability to run

code and installed on a majority of web clients was JavaScript. Although its uses were

relatively limited at first, combined with layers and other developments in DHTML it has

become possible to piece together an RIA system without the use of a unified client-side

solution. Ajax is a new term coined to refer to this combination of techniques and has recently

been used most prominently by Google for projects such as Gmail and Google Maps.

However, creating a large application in this framework is very difficult, as many different

technologies must interact to make it work, and browser compatibility requires a lot of effort.

In order to make the process easier, several open source Ajax Frameworks have been

developed, as well as commercial frameworks.

2.2.7.2 Google's GWT framework

Google released the 'Google Web Toolkit' or GWT in 2006 which allows the

development and testing of JavaScript based AJAX RIA's using the Java language. The GWT

programming paradigm centers around coding user interface logic in Java (similar to the

Swing/AWT model), and then executing the GWT compiler to translate this logic into cross-

browser-compatible JavaScript. Designed specifically for Java developers, GWT enables Java


PRMIT&R//DCSE//07-08 19/95

programming, refactoring, debugging and unit testing of RIAs using existing tools (e.g. Eclipse),

without requiring knowledge of JavaScript or specific browser DOM irregularities (although

hand-written JavaScript can still be used with GWT if desired).

2.2.7.3 Adobe Flash, Adobe Flex and Adobe AIR

Adobe Flash is another way to build Rich Internet Applications. This technology is

cross-platform and quite powerful to create an application UI. Adobe Flex provides the option

to create Flash user interface by compiling MXML, an XML based interface description

language. Adobe is currently working on providing a more powerful platform with the product

Adobe AIR, a technology combining HTMLs (including AJAX applications) Flash player based

applications and PDFs.

2.2.7.4 Appcelerator

Appcelerator is an open source platform for developing rich Internet applications using

a service-oriented architecture and standards such as HTML, CSS and Javascript. Appcelerator

applications can integrate automatically with several different integration points on the

service tier using Java, PHP, Python, .NET, Perl and Ruby on Rails. Appcelerator applications

can use pre-built widgets to assemble high quality RIAs. Appcelerator is licensed under the

GNU GPL version 2 License.

2.2.7.5 OpenLaszlo

OpenLaszlo is an open source rich Internet application framework developed by Laszlo

Systems Inc.. The OpenLaszlo server compiles programs written in the LZX language (a mixture

of XML tags and JavaScript) into either DHTML (commonly known as AJAX now) or Adobe

Flash bytecode, currently supporting Flash7 and Flash8. The server - which originally was a

proprietary software - was open sourced in October 2004 under the Common Public License.

OpenLaszlo is the only rich Internet application platform which is capable of compiling into

two different runtimes from the same code base.


PRMIT&R//DCSE//07-08 20/95

2.2.7.6 Curl 5.0, Rebol 2.6 and Seaside for Smalltalk

Available alternatives to Java for RIA include abstract machines for the Curl, Rebol and

Smalltalk programming languages. Curl facilitates Client-side persistent data, Rebol does not

require a browser and Seaside for Smalltalk uses a minor extension to Smalltalk to provide a

much richer web experience. All three alternatives are far more mature than more familiar

options and as old or older than Java and the JVM.

2.2.7.7 JavaFX

Sun Microsystems has announced JavaFX, a family of products based on Java

technology designed to provide a consistent experience across a wide variety of devices

including desktops, (as applets and stand-alone clients) set-top boxes, mobile devices, and

Blu-Ray players. The JavaFX platform will initially comprise JavaFX Script and JavaFX Mobile.

Invented by Sun Software Engineer Chris Oliver as a skunk works project, JavaFX Script

enables rapid development of rich 2D interfaces using a declarative syntax similar to SVG. Sun

plans to release JavaFX Script as an open source project, but JavaFX Mobile will be a

commercial product available through an OEM license to carriers and handset manufacturers.

2.2.7.8 Java applets

Java applets run in standard HTML pages and generally start automatically when their

web page is opened with a modern web browser. Java applets have access to the screen

(inside an area designated in its page's HTML), as well as the speakers, keyboard and mouse of

any computer their web page is opened on, as well as access to the Internet, and provide a

sophisticated environment capable of real time applications.

2.2.7.9 Java applications

Java based RIAs can be launched from within the browser or as free standing

applications via Java Web Start which integrate with the desktop. Java RIAs can take


PRMIT&R//DCSE//07-08 21/95

advantage of the full power of the Java platform to deliver rich functionality, 2D & 3D

graphics, and off-line capabilities.

Java is widely adopted and there is a vast range of both commercial and open source

libraries available for the platform, making it possible to include support for virtually any

system, including native applications via JNI or JNA. When it comes to RIAs Java's main

weakness is its multimedia support. Java 6 Update N improves some features that have

hindered the use of Java for RIAs including startup time and download size, and Sun may even

include new multimedia support in this release (due Q2,2008).

Numerous frameworks for Java RIAs exist, including XUL-like XML-based frameworks

such as XUI, Swixml, or Canoo's, UltraLightClient.

2.2.7.10 Microsoft Silverlight

Microsoft Silverlight, which can be considered a subset of Windows Presentation

Foundation (WPF) allows developers to develop RIA. Like Windows Presentation Foundation,

Silverlight uses XAML. Therefore, developers with previous development experiences in the

field of .NET Framework 3.0 and XAML will find Silverlight familiar, appealing and easy to use.

Client machines need to install a small (about 2MB) plug-in (Silverlight Runtime) in

order to be able to play Silverlight contents. At this time, Silverlight client for Windows and OS

X is available from Microsoft. A third-party open-source plug-in called Moonlight is also

available for Linux. Microsoft has also promised to broaden the range of supported clients.

During the opening keynote at MIX08 conference in Las Vegas, the first beta of Silverlight 2

was shown running on a Nokia S60 platform as well as a Microsoft Windows Mobile 6 device.


PRMIT&R//DCSE//07-08 22/95

2.2.7.11 Mozilla Prism

Mozilla Prism is a product in development which integrates web applications with the

desktop, allowing web applications to be launched from the desktop and configured

independently of the default web browser

2.2.7.12 ActiveX controls

Embedding ActiveX controls into HTML is a very powerful way to develop rich Internet

applications. However they are only guaranteed to run properly in Internet Explorer, since no

other web browser at this time supports ActiveX controls. In addition, ActiveX controls are not

executed in sandbox. Therefore, they are potential targets for computer viruses and malware

making them high security risks.

At the time of this writing, the Adobe Flash Player for Internet Explorer is implemented as an

ActiveX control for Microsoft environments, as well as in multi-platform Netscape Plugin

wrappers for the wider world. Only if corporations have standardized on using Internet

Explorer as the primary web browser, is ActiveX per se a good choice for building corporate

applications.

2.2.7.13 User interface languages

Instead of HTML/XHTML, new user interface markup languages can be used in RIAs.

For instance, the Mozilla Foundation's XML-based user interface markup language XUL - this

could be used in RIAs though it would be restricted to Mozilla-based browsers, since it is not a

de facto or de jure standard. The W3C's Rich Web Clients Activity has initiated a Web

Application Formats Working Group whose mission includes the development of such

standards . The original DARPA project at MIT which resulted in the W3C also resulted in the

web content language Curl which is now in version 5.0.


PRMIT&R//DCSE//07-08 23/95

RIA's user interfaces can also become richer through the use of scriptable scalable

vector graphics (though not all browsers can render those natively yet) as well as

Synchronized Multimedia Integration Language (SMIL).

2.2.7.14 Eclipse Rich Ajax Platform (RAP)

The RAP project enables developers to build rich, Ajax-enabled Web applications by

using the Eclipse development model, plug-ins with the well known Eclipse workbench

extenstion points, JFace, and a widget toolkit with SWT API (using qooxdoo for the client-side

presentation). The project has graduated from incubation and released its 1.0 release.

2.3 AJAX

2.3.1 Introduction

AJAX (Asynchronous JavaScript and XML), or Ajax, is a group of inter-related web

development techniques used for creating interactive web applications. A primary

characteristic is the increased responsiveness and interactivity of web pages achieved by

exchanging small amounts of data with the server "behind the scenes" so that entire web

pages do not have to be reloaded each time there is a need to fetch data from the server. This

is intended to increase the web page's interactivity, speed, functionality, and usability.

AJAX is asynchronous; in that extra data is requested from the server and loaded in the

background without interfering with the display and behavior of the existing page. JavaScript

is the scripting language in which AJAX function calls are usually made.[1]

Data is retrieved

using the XMLHttpRequest object that is available to scripting languages run in modern

browsers, or alternatively Remote Scripting in browsers that do not support XMLHttpRequest.

There is, however, no requirement that the asynchronous content be formatted in XML.

AJAX is a cross-platform technique usable on many different operating systems, computer

architectures, and web browsers as it is based on open standards such as JavaScript and the

DOM. There are free and open source implementations of suitable frameworks and libraries.


PRMIT&R//DCSE//07-08 24/95

2.3.2 Use of AJAX

• Real-time form data validation: Form data such as user IDs, serial numbers, postal

codes, or even special coupon codes that require server-side validation can be validated

in a form before the user submits a form.

• Autocompletion: A specific portion of form data such as an email address, name, or

city name may be autocompleted as the user types.

• Load on demand: Based on a client event, an HTML page can fetch more data in the

background, allowing the browser to load pages more quickly.

• Sophisticated user interface controls and effects: Controls such as trees, menus, data

tables, rich text editors, calendars, and progress bars allow for better user interaction

and interaction with HTML pages, generally without requiring the user to reload the

page.

• Refreshing data and server push: HTML pages may poll data from a server for up-to-

date data such as scores, stock quotes, weather, or application-specific data. A client

may use Ajax techniques to get a set of current data without reloading a full page.

Polling is not the most effecient means of ensuring that data on a page is the most

current.

• Partial submit: An HTML page can submit form data as needed without requiring a

full page refresh.

• Mashups: An HTML page can obtain data using a server-side proxy or by including an

external script to mix external data with your application's or your service's data. For

example, you can mix content or data from a third-party application such as Google

Maps with your own application.

• Page as an application: Ajax techniques can be made to create single-page

applications that look and feel much like a desktop application.

__________________________________________________________________


PRMIT&R//DCSE//07-08 25/95

3. General Problem Formulation

The considered college is a four-year college which has the following characteristics on its

course administration. The college offers courses for daytime students. The classes for

daytime students are scheduled in the weekday’s daytime and Saturday morning.

The types of lectures are theory lecture, tutorial, or practical. The class size of theory

lectures is from 40 to 70. A minimum time slot is a 30 minutes interval. For theory and tutorial

classes, 2 slot time corresponds to 1 credit, and 1 credit for practical takes 4 slots time.

Once an instructor decides to offer a course for a specific year-session of a

department, an offered course Xi takes place in the timetabling problem, which is expressed

as a tuple of attributes (course, credits, department, instructor, year, section, class-group,

course-type, lecture-type, TimeSlots, Rooms). Except TimeSlots and Rooms, all attributes of Xi

are determined at the time the course is decided to be offered. Both TimeSlots and Rooms are

list fields to contain assigned time slots and classrooms for the course Xi. To indicate an

attribute attr of an offered course Xi, we use the notation Xi.attr.

The time slots are generally assigned from 11 AM to 5.30 PM for weekdays and from

7.30 AM to 11 AM on Saturday. The time time slots are labeled as Ti (i = 1 . . . 55)..

There are various constraints to be satisfied at the time to instantiate variables about

time slots and classrooms. The constraints can be categorized into strong and weak

constraints as follows:


PRMIT&R//DCSE//07-08 26/95

3.1 Strong Constraints

C1: A classroom is not assigned to more than one lecture at the same time.

C2: An instructor cannot teach more than one class at the same time.

C3: Courses for the same year-session students of a department cannot take place at the

same time.

C4: The classroom for a course should have enough capacity to take students registered in the

course.

C5: The classroom should be well equipped with required facilities for the classes.

3.2 Weak Constraints

C6: The lectures are not assigned to time slots which are in the instructor’s forbidden time

zones.

C7: Instructors’ daily lecture hours should be restricted to be within the allowed maximum

hours.

C8: As far as possible, classes are scheduled in the instructor’s preferred time zones.

C9: A lunch/dinner break must be scheduled.

C10: If possible, the lectures should not be scheduled on too late night time slots.

C11: The theory courses are scheduled on Monday and Tuesday, and the practical courses are

scheduled on Wednesday, Thursday, and Friday.


PRMIT&R//DCSE//07-08 27/95

C12: For daytime students, the cultural subjects courses are scheduled in the morning time

slots (1st to 4th time slots on weekdays), and major courses are scheduled in the afternoon

time slots (5th to 8th time slots).

C13: For nighttime students, the cultural-subjects courses are scheduled on the 11th

to 12th

slots, and the major courses are scheduled on the 13th

to 16th

time slots on weekdays.

C14: If possible, the lecture hours for a course should be scheduled consecutively.

C15: As far as possible, classes should be scheduled in their corresponding department’s

exclusive-use classrooms.

C16: The classrooms should be allocated in a manner to minimize the distances between

adjacent classes’s classrooms.

It is desirable for timetables to satisfy all strong and weak constraints. However, it is

usually not easy to meet all these constraints. The strong constraints must be satisfied all the

times, but weak constraints can be somewhat sacrificed to find feasible timetables. Among

the weak constraints, constraints from C6 to C14 are imposed on the allocation of time slots.

Constraints C15 and C16 are imposed on the allocation of classrooms. The constraints

are arranged in the order of importance in the scheduling. For example, if it is impossible to

find schedules satisfying both C6 and C7 simultaneously, it is preferred to choose a schedule

that satisfies C6 but C7 rather than a schedule satisfying C7 but C6.


PRMIT&R//DCSE//07-08 28/95

4. Requirements and Analysis

In this section we formulate the various requirements of our project.

4.1 Automatic Generation of Timetable

The prime requirement was to build the automatic weekly Lecture-Room timetable generator

application for our college which will solve problem involved manual construction of timetable. There

are always weekly or monthly changes in structure of timetable, so all the time reconstructing the

timetable is very tedious job. So we wanted to build the automatic timetable generator algorithm that

is adaptable to these changes.

There are various timetabling algorithm developed for solving our college timetabling

problem. But in most of the cases either the actual implementation is not available on the Internet or

the projects which are available freely are not suitable to our meet requirement of our college’s

timetabling problem.

Also due to fixed time period, we have decided to develop our own timetabling algorithm

tailored to our college’s timetabling problem rather than wasting time for searching various

timetabling algorithms or ready to use software.

Although during literature survey, we found only one open source software name UniTime

available from www.unitime.org to be very impressive or effective to implement. But again this

software was developed on very large scale, it has hundreds of packages and it has used all leading

Java Web based frameworks including Strut & Hibernate. It uses MySQL database for storing its data.

So finally we decided that we will not borrow our algorithm from any other source rather we

will build it our self. Next question came to mind was, which language we should use. Whether we

should use LISP or Prolog? But since we were not familiar with these languages, we decided that we

will go with JAVA only. Since JAVA is cross platform and there are various IDE available to assist us

building algorithm. Also GWT uses JAVA for writing web application. We decided that we will use JAVA

only.


PRMIT&R//DCSE//07-08 29/95

4.1.1 Details about Java

Java is a programming language originally developed by Sun Microsystems and

released in 1995 as a core component of Sun's Java platform. The language derives much of its

syntax from C and C++ but has a simpler object model and fewer low-level facilities. Java

applications are typically compiled to bytecode which can run on any Java virtual machine

(JVM) regardless of computer architecture.

On 13 November 2006, Sun released much of Java as free software under the terms of

the GNU General Public License (GPL). On 8 May 2007 Sun finished the process, making all of

Java's core code open source, aside from a small portion of code to which Sun did not hold the

copyright.

4.1.1.1 Platform independence

One characteristic, platform independence, means that programs written in the Java

language must run similarly on any supported hardware/operating-system platform. One

should be able to write a program once, compile it once, and run it anywhere.

4.1.2 Different criteria and conditions to consider while generating timetable

We wanted that timetable generator should be able to consider following different resources

available

1. Teachers

2. Courses

3. Semesters

4. Rooms

It should provide mechanism for specifying various constraints such as

1. Teacher-Room Constraints


PRMIT&R//DCSE//07-08 30/95

2. Year-Room Constraints

3. Teacher-Timeslot Constraints

4. Teacher-Day Constraints

5. Teacher-Year Constraints

4.2 Standardized Knowledgebase representation

Not just we wanted to implement automation process but we also wanted to keep out data in

standard form, so that any external application can access our data. By doing to so we were

thinking ahead of time. We were thinking about Future implementation of automatic timetable

generator by some other groups or by our self in other language and on other platform. Keeping

knowledgebase portable, we can write cross platform application and transfer our knowledgebase

seamlessly between two platforms.

We decided we will go with XML. Details about choosing XML for Knowledgebase are as

follows.

4.2.1 XML

The Extensible Markup Language (XML) is a general-purpose specification for creating

custom markup languages. It is classified as an extensible language because it allows its users

to define their own elements. Its primary purpose is to facilitate the sharing of structured data

across different information systems, particularly via the Internet, and it is used both to

encode documents and to serialize data. In the latter context, it is comparable with other text-

based serialization languages such as JSON and YAML.

It started as a simplified subset of the Standard Generalized Markup Language (SGML),

and is designed to be relatively human-legible. By adding semantic constraints, application

languages can be implemented in XML. These include XHTML, RSS, MathML, GraphML,

Scalable Vector Graphics, MusicXML, and thousands of others. Moreover, XML is sometimes

used as the specification language for such application languages.

XML is recommended by the World Wide Web Consortium. It is a fee-free open

standard. The W3C recommendation specifies both the lexical grammar and the requirements

for parsing.


PRMIT&R//DCSE//07-08 31/95

4.2.1.1 Advantages of XML

1. It is text-based.

2. It supports Unicode, allowing almost any information in any written human language to be

communicated.

3. It can represent common computer science data structures: records, lists and trees.

4. Its self-documenting format describes structure and field names as well as specific values.

5. The strict syntax and parsing requirements make the necessary parsing algorithms extremely

simple, efficient, and consistent.

6. XML is heavily used as a format for document storage and processing, both online and offline.

7. It is based on international standards.

8. It can be updated incrementally.

9. It allows validation using schema languages such as XSD and Schematron, which makes

effective unit-testing, firewalls, acceptance testing, contractual specification and software

construction easier.

10. The hierarchical structure is suitable for most (but not all) types of documents.

11. It is platform-independent, thus relatively immune to changes in technology.

12. Forward and backward compatibility are relatively easy to maintain despite changes in DTD or

Schema.

13. Its predecessor, SGML, has been in use since 1986, so there is extensive experience and

software available.

14. An element fragment of a well-formed XML document is also a well-formed XML document.

4.3 Responsive Interface

We knew that the success of any application lies not only in powerful algorithms but also in the

successful graphical user interface designs. We wanted to build the Rich Internet Application which will

exactly behave as our normal desktop application. So that user will find it friendly and easy to work on.

We also wanted the output of our algorithm to flexible enough so that we can zoom it, print it or able

modify it manually.

Question was how to build the Rich Internet Application? So we did lot of survey on various

platforms available for RIA. Finally we decided we will go with AJAX based Google Web ToolKit.


PRMIT&R//DCSE//07-08 32/95

4.3.1 Details about Google Web Tool Kit

Google Web Toolkit (GWT) is a Java development framework that seeks to ease AJAX

(Asynchronous JavaScript and XML) application development. GWT allows you to develop and

debug AJAX-based applications in Java using common Java development tools and deploy the

same applications as client-side HTML and JavaScript, and server-side Java. GWT also

simplifies typical AJAX-style RPC (remote procedure call) conversations between client-side

JavaScript and server-side Java services.

4.3.2 Introduction of the Google Web Toolkit (GWT)

The Google Web Toolkit is an application development platform composed of a Java

class library, AJAX-style UI components called widgets, an RPC-based request/response

communication framework, and an integrated debugging environment. GWT provides a

subset of the java.lang and java.util packages, along with a Java API that facilitates

component-based GUI development, which can be compiled to HTML and JavaScript for

deployment to a browser.

4.3.3 GWT applications can be executed in two modes:

1. Hosted mode: This mode executes a GWT application as a regular Java application,

allowing standard Java debugging. To support hosted mode, GWT provides a proprietary Web

browser that can interact with a JVM.

2. Web mode: This mode allows a GWT application to be deployed and executed as

native JavaScript and HTML, generated from Java source code by the GWT Java-to-JavaScript

compiler.


PRMIT&R//DCSE//07-08 33/95

4.3.4 GWT has four major components/libraries, as follows:

1. GWT Java-to-JavaScript compiler: This component translates Java source code to

native JavaScript and HTML

2. GWT hosted Web browser: This component allows GWT applications to be

executed as Java code within a JVM-aware Web browser

3. JRE emulation library: This library provides subsets of the java.lang and java.util

packages

4. GWT Web UI class library: This library is a set of proprietary interfaces and classes,

called widgets, that can be used to create browser-based GUI components

Figure 4.1 shows the structure of Google’s web toolkit

t

Figure 4.1


PRMIT&R//DCSE//07-08 34/95

4.4 Jakarta Tomcat

Tomcat is the servlet container that is used in the official Reference Implementation

for the Java Servlet and JavaServer Pages technologies. The Java Servlet and JavaServer Pages

specifications are developed by Sun under the Java Community Process.

We have choosen Apache Tomcat web server for our development and deployment purpose

because of its 100% compatibility of Google Web Toolkit.


PRMIT&R//DCSE//07-08 35/95

5. System Design

5.1 Various Components of Project

Figure 5.1 shows how the knowledge base, Error Handling System, inference engine, conflicts

resolution strategy and priority maintenance systems are interconnected.

Figure 5.1

Inference Engine

Knowledge Base

Error

Handling

System

Conflict

Resolution

Strategy

Priority

Maintenance

System

Output

Inbuilt in Front End

In XML

Inbuilt in Algorithm

1

2

3


PRMIT&R//DCSE//07-08 36/95

5.2 Flow of Data within project

Figure 5.2 shows the flow of data from user to timetable generator algorithm and back to user

Figure 5.2

Generated Timetable Sheet

(HTML)

GUI Interface

for Input

(JSP/Servlet/

AJAX)

GUI Interface

for Input

(JSP/Servlet/

AJAX)

GUI Interface

for Input

(JSP/Servlet/

AJAX)

GUI Interface

for Input

(JSP/Servlet/

AJAX)

Knowledgebase

including Policies,

Dynamic Timetable

Data & Soft

Constraints (XML)

Weekly Timetable Generator

Algorithm (Java)


PRMIT&R//DCSE//07-08 37/95

5.3 Design of Knowledge Base

The middle part is the representation of knowledge based using XML format

We have defined the standard format for representing the knowledgebase so that Front End and Last

End can communicate successfully to generate effective timetable.

XML File contains following sections

1. Teacher List

2. Course List

3. Day List

4. Semester List

5. Room List

6. Formatting Options

7. Constraints, Rules, Policies

The sample XML file will look as follows

<?xml version="1.0" encoding="UTF-8"?>

<MyData>

<TeacherList>

<Teacher Name="Prof.M.A.Pund" Initials="m.a.p" Id="1"/>

</TeacherList>

<CourseList>

<Course Name="Digital Signal Processing" ShortForm="DSP" Id="1" Sem="8th" Type="Theory" />

</CourseList>

<RoomList>

<Room Name="R2" Id="1" Type="Theory" Resources="7,2"/>

</RoomList>


PRMIT&R//DCSE//07-08 38/95

<SemList>

<Sem Name="8th" Id="8" BatchList="K1,K2,K3,K4" NoOfStudentsPerBatch="15,15,15,15"/>

</SemList>

<DayList>

<Day Name="Monday" Id="1"/>

</DayList>

<TimeSlotList>

<TimeSlot StartTime="11.00" EndTime="17.30" Id="1"/>

</TimeSlotList>

<Formatting>

<Format Id="2" Type="TimeSlot" TypeId="1" FontName="Arial" ForeColor="Black"

BackColor="Yellow"

</Formatting>

<ConstraintList>

<Constraint Id="1" Name="Recess Allocation" StartTimeOnlyAfter="13.00"

AndEndTimeOnlyBefore="16" StartTime="" MaxDailyHrs="0.5" MaxHrsAtOnce="0.5"

MaximumHrsPerWeek="3" CourseId="11" TeachersId="" SemId="8" AllocateBatchWise=""

RoomsId="" DaysId="" />

</ConstraintList>

</MyData>


PRMIT&R//DCSE//07-08 39/95

5.4 Design of Timetabling Algorithm

Figure 5.3 shows the steps in which our timetabling algorithm is going to work. After it

starts its execution, it will read data from knowledge base and using that data, it will

initialize the table in memory. After using various facts, rules, policies or constraints from

knowledge base, it will perform allocation. After allocation is done, the HTML timetable is

generated which is afterwards formatted for colorful look.

Figure 5.3

Read Data

Initialize

Timetable

Start Stop

Format

Timetable

Perform

Allocation

Generate

Timetable


PRMIT&R//DCSE//07-08 40/95

5.4.1 The Proposed Timetabling Method

This section presents the timetabling algorithm we have decided to develop in the

implemented system. The algorithm uses sequential First Entered First Server (FEFS) priority

method to assign to teacher names and to allocate room. It uses the simple data structure for

storing data. This algorithm is relatively simple and has inbuilt conflict resolution strategy.

5.4.2 The Timetabling Algorithm

The timetabling algorithm consists of set of different lists, such as Teachers List, Subjects List,

Rooms List, Times Slots List, Semesters List, and Days List. The input will be taken from user. This

algorithm works sequentially on two main criteria

1. Priority based on First Entered First Serve ( FEFS)

2. Constrains And Rule specified by user

5.4.3 Data Structure for these lists is represented visually as follows

Figure 5.4


PRMIT&R//DCSE//07-08 41/95

5.4.4 Teacher-Subject Constraint

In this constraint Teacher is assigned to various Subjects. A Teacher can be assigned to more

than one subject. But then again using FEFS, subjects will be allocated sequentially.

Figure 5.5

5.4.5 Teacher –Time Slot Constraint

A Teacher may have some hours as favorable hours and some as forbidden hours for

conducting lectures. Our algorithm will consider this constraint checking.

Figure 5.6


PRMIT&R//DCSE//07-08 42/95

5.4.6 Teacher -Day Constraint

A Teacher may be busy on some day in week, so algorithm consider which days are suitable for

particular teacher.

Figure 5.7

5.4.7 Teacher-Year Constraint

A Teacher can teach more than one year simultaneously. Algorithm must consider this

association.

Figure 5.8


PRMIT&R//DCSE//07-08 43/95

5.4.8 Year (Semester) – Room Constraint

Some room may have specific facility for particular year. So that year’s students must seat in

that room only. This constraint should be considered by algorithm.

Figure 5.9

5.4.9 Constraint Matrix

When all data is entered in the all lists and when all constraints are mentioned by user. Then

whole matrix is created in memory which helps algorithm to check constraints and perform allocation.

Figure 5.10


PRMIT&R//DCSE//07-08 44/95

5.5 Design of working of algorithm

Procedure:

1. Start

2. Load Data from Knowledge Base

3. Initialize Table

4. For each element in Time Slots List , create new time slot and add it as table header

5. For each element in Years (or Semester) List, create new year slot

Figure 5.11

6. Now check the various constraints specified for user before proceeding to check

empty timeslot and free teacher

7. If all constraints are feasible then proceed next otherwise start again


PRMIT&R//DCSE//07-08 45/95

8. Now for each item in teacher list, assign teacher to first empty time slot. If next time

teacher is busy for given time slot , then pick next unassigned teacher name from list

and perform allocation

9. Marks, timeslot =Busy and particular Teacher=Busy

Figure 5.12

10. In similar manner assign rooms using FEFS method

Figure 5.13


PRMIT&R//DCSE//07-08 46/95

5.6 Initialize Timetable Method

The initialize timetable is the important method, which creates the table like structure in

memory.

Figure 5.14 visually shows the steps involved in this method.

Figure 5.14

Stop

Start

Divide Total

Timeslot from

KB in Half

Hour Slots

Each

For all days

from KB

For all

semesters

from KB

Add Single

Unit Item in

Timetable


PRMIT&R//DCSE//07-08 47/95

5.7 The Working Of Perform Allocation_Method

Start For All Constraints

For All Teachers

For All Half Hour Timeslot

Match Simple Constraints

For All Days

Check Teachers Daily &

Weekly Hours Allocation

For All Rooms

Check whether current

room teacher is free

Add item in timetable

Is Current Item Allocated

Then Break Current

For All Items in

Timetable If Item is Free

Forward Search

Allocate

Figure 5.15


PRMIT&R//DCSE//07-08 48/95

5.8 Data Flow within Algorithm

Figure 5.16 shows various list used by timetabling algorithm to perform_allocation.

Sem/Time 11-11.3 11.3-12 12-12.3 12.3-1

4th

6th

8th MO

N

Is TimeSlot Free?

Is Room Free?

11-12

12-1

1-2

Timeslot s’ List

R1

R2

R3

Rooms’ List

MON

TUE

WED

Days’ List

4th

6th

8th

Sems’ List

1st

2nd

3rd

Constraints’ List

Get Teacher Name

Get All Rooms

Is Teacher Free?

Get All Days

Get All TimeSlots

Match Semester

Allocate Item Get Course Name

Get Sem Name

Get All Sems

Figure 5.16


PRMIT&R//DCSE//07-08 49/95

5.9 Front End Design

We are using the client server technology while developing Front End. So the Google Web

Toolkit is the right option. It supports writing web application in JAVA. The design is as follows.

5.9.1 Client Server Architecture

Figure 5.17

AJAX Based UI Code

Running in Client’s Web

Browser

Generated Timetable

Web Container like

TOMCAT

Timetable

Generator Web

Application Logic

XML Parser

&

Timetable

Generator

Algorithm

Server Client Get Web App

AJAX+HTML

Read XML KB Data()

XML KB

Generate timetable

Timetable in HTML


PRMIT&R//DCSE//07-08 50/95

5.9.2 Compilation Process of Google Web Toolkit

Figure 5.18

Java Client

Side UI Code

Google Web

Toolkit

Compiler

Run in

AJAX and HTML

Code

GWT UI

Components

GWT JRE

Emulation

Libraries

Open

Web browser

This diagram shows how

the web pages will be

designed using Google’s

web toolkit.


PRMIT&R//DCSE//07-08 51/95

6. Implementation

6.1 Timetabling Algorithm

6.1.1 Details about Main class which is responsible for generating timetable

Package: MyTimeTableGenerator

Class Main

java.lang.Object

MyTimeTableGenerator.Main

public class Main

extends java.lang.Object

Nested Class Summary

static class Main.Constraint

This class holds various constraint

static class Main.Course

This class holds the details of Course

static class Main.Day

This class holds the details of Day

static class Main.Formatting

This class holds the details of Formatting

static class Main.Room

This class holds the details of Room

static class Main.Sem

This class holds the details of Semester


PRMIT&R//DCSE//07-08 52/95

static class Main.SingleTimeSlot

This class holds the single half hour timeslot details

static class Main.Teacher

This class holds the details of Teacher

static class Main.TimeSlot

This class holds the details of Timeslot

static class Main.TimeTableGrid

This class represents the table grid for holding allocated items

static class Main.TimeTableGridCell

This class represents a unit cell in TimeTableGrid

Field Summary

static java.util.List<Main.Constraint> ConstraintList_Input

This is list of all constraints.

static java.util.List<Main.Course> CourseList_Input

This is list of all courses.

static java.util.List<Main.Day> DayList_Input

This is list of all days to consider.

static java.util.List<Main.Formatting> FormattingList_Input

This is list of all formatting rules.

static Main.TimeTableGrid MyTable

This list holds TimeSlots and

TimeTableGrid Lists

static java.util.List<Main.Room> RoomList_Input

This is list of all rooms.


PRMIT&R//DCSE//07-08 53/95

static java.util.List<Main.Sem> SemList_Input

This is list of all semesters.

Static java.util.List<Main.Teacher> TeacherList_Input

This is list of all teachers.

static java.util.List<Main.TimeSlot> TimeSlotList_Input

This is list of all timeslot.

Method Summary

Static Boolean addItemInTable(Main.TimeTableGridCell NewCell, java.lang.String MaxHrsAtOnce)

This method allocates new item in table. Return true if

successful.

Static void clearAllData()

This method clears the input data.

static java.lang.String formatHTML(java.lang.String OldHtml)

This method formats generated HTML timetable with formatting

rules

Static void generateHTMLTimeTable()

This method generate HTML timetable after allocation is done .

It creates timetable.html file in its directory.

Static void generateLogFile()

This method generates log.txt with some allocation details.

static Main.Course getCourseFromId(java.lang.String Id)

This method return Course object by specifying Id

static Main.Day getDayFromId(java.lang.String Id)

This method return Day object by specifying Id


PRMIT&R//DCSE//07-08 54/95

static Main.SingleTimeSlot getFirstTimeSlotFromHr(java.lang.String value)

This method give starting hour timeslot from TimeSlot List

static Main.SingleTimeSlot getNextSlot(Main.SingleTimeSlot currentSlot)

This method gives the next timeslot from current timeslot

static Main.Room getRoomFromId(java.lang.String Id)

This method return Room object by specifying Id

static Main.Sem getSemFromId(java.lang.String Id)

This method return Sem object by specifying Id

static Main.Teacher getTeacherFromId(java.lang.String Id)

This method return Teacher object by specifying Id

Static void initializeTable()

This method initializes the timetable grid in memory

Static Boolean isRoomFree(Main.Room r, Main.SingleTimeSlot slot, Main.Day d,

int NoOfSlotsToSearch)

This method detects whether given room is free or not.

Static Boolean isTeacherFree(Main.Teacher teacher_to_check, Main.SingleTimeSlot slot,

Main.Day d)

This method detects whether given teacher is free or not.

Static void main(java.lang.String[] args)

Static void performAllocation()

This method start allocation using given constraints.

Static void readData(java.lang.String filename)

This method reads data from XML KB specified.


PRMIT&R//DCSE//07-08 55/95

6.1.2 Step by Step Execution of Algorithm

Consider the following Sample Knowledge Base input to Algorithm.

<MyData>

<TeacherList>

<Teacher Name="Prof.M.A.Pund" Initials="m.a.p" Id="1"/>

<Teacher Name="Prof.M.S.Ali" Initials="m.s.a" Id="2"/>

<Teacher Name="Prof.G.R.Bamnote" Initials="g.r.b" Id="3"/>

<Teacher Name="Prof.Ms.S.M.Gajbhiye" Initials="s.m.g" Id="4"/>

<Teacher Name="Prof.Ms.Dembla" Initials="m.d" Id="5"/>

<Teacher Name="Prof.Ms.R.P.Sonar" Initials="r.p.s" Id="6"/>

<Teacher Name="Prof.Mr.Shrikant" Initials="s.t" Id="7"/>

</TeacherList>

<CourseList>

<Course Name="Digital Signal Processing" ShortForm="DSP" Id="1" Sem="8th" Type="Theory" />

<Course Name="Digital Signal Processing Practical" ShortForm="DSP Pract" Id="2" Sem="8th"

Type="Practical"/>

<Course Name="Software Engineering" Id="3" ShortForm="SE" Sem="8th" Type="Theory" />

<Course Name="Multimedia Technology" Id="4" ShortForm="MMT" Sem="8th" Type="Theory" /> <Course

Name="Multimedia Technology Practical" Id="5" ShortForm="MMT Pract" Sem="8th" Type="Practical" />

<Course Name="Multimedia Technology Tutorial" Id="6" ShortForm="MMT Tut" Sem="8th" Type="Theory" />

<Course Name="Internet Technology" Id="7" ShortForm="IT" Sem="8th" Type="Theory" />

<Course Name="Internet Technology Practical" Id="8" ShortForm="IT Pract" Sem="8th" Type="Practical" />

<Course Name="Internet Technology Tutorial" Id="9" ShortForm="IT Tut" Sem="8th" Type="Theory" />

<Course Name="Project And Seminar" Id="10" ShortForm="Project And Seminar" Sem="8th" Type="Practical" />

<Course Name="Recess" Id="11" ShortForm="Recess" Sem="8th" Type="Recess" />

</CourseList>


PRMIT&R//DCSE//07-08 56/95

<RoomList>





<Room Name="C-Lab" Id="5" Type="Practical" Resources="3,6"/>

<Room Name="PC-Lab" Id="6" Type="Practical" Resources="1,6"/>

<Room Name="Networking Lab" Id="7" Type="Practical" Resources="8,6"/>

</RoomList>

<SemList>

<Sem Name="8th" Id="8" BatchList="K1,K2,K3,K4" NoOfStudentsPerBatch="15,15,15,15"/>

</SemList>

<DayList>

<Day Name="Monday" Id="1"/>

<Day Name="Tuesday" Id="2"/>

<Day Name="" Id="3"/>

<Day Name="Thursday" Id="4"/>

<Day Name="Friday" Id="5"/>

<Day Name="Saturday" Id="6"/>

</DayList>

<TimeSlotList>

<TimeSlot StartTime="11.00" EndTime="17.30" Id="1"/>

</TimeSlotList>


PRMIT&R//DCSE//07-08 57/95

<Formatting>

<Format Id="2" Type="TimeSlot" TypeId="1" FontName="Arial" FontColor="Black" BackColor="Yellow"

FontSize="2"/>

<Format Id="4" Type="Teacher" TypeId="4" FontName="Arial" FontColor ="Black" BackColor="Pink"

FontSize="4"/>

<Format Id="5" Type="Sem" TypeId="8" FontName="Arial" FontColor ="White" BackColor="Blue"

FontSize="4"/>

</Formatting>

Using the rules, data specified up to this point, timetable generator can build following structure.

Figure 6.1

Now we will show what happens when constraints are executed one by one by our

algorithm.


PRMIT&R//DCSE//07-08 58/95

<ConstraintList>

1. <Constraint Id="1" Name="Recess Allocation" StartTimeOnlyAfter="13.00" AndEndTimeOnlyBefore="16"

StartTime="" MaxDailyHrs="0.5" MaxHrsAtOnce="0.5" MaximumHrsPerWeek="3" CourseId="11" TeachersId=""

SemId="8" AllocateBatchWise="" RoomsId="" DaysId="" />

Figure 6.2


PRMIT&R//DCSE//07-08 59/95

2. <Constraint Id="2" Name="Teacher Allocation" StartTimeOnlyAfter="" AndEndTimeOnlyBefore=""

StartTime="" MaxDailyHrs="1.0" MaxHrsAtOnce="1.0" MaximumHrsPerWeek="4" CourseId="1" TeachersId="2"


Figure 6.3


PRMIT&R//DCSE//07-08 60/95

3.<Constraint Id="3" Name="Teacher Allocation" StartTimeOnlyAfter="13.30" AndEndTimeOnlyBefore=""


SemId="8" AllocateBatchWise="Yes" RoomsId="" DaysId="" />

Figure 6.4


PRMIT&R//DCSE//07-08 61/95

4.<Constraint Id="4" Name="Teacher Allocation" StartTimeOnlyAfter="" AndEndTimeOnlyBefore=""



Figure 6.5


PRMIT&R//DCSE//07-08 62/95




Figure 6.6


PRMIT&R//DCSE//07-08 63/95




Figure 6.7


PRMIT&R//DCSE//07-08 64/95




Figure 6.8


PRMIT&R//DCSE//07-08 65/95




Figure 6.9


PRMIT&R//DCSE//07-08 66/95


StartTime="" MaxDailyHrs="2.0" MaxHrsAtOnce="2.0" MaximumHrsPerWeek="2" CourseId="8"

TeachersId="6,1" SemId="8" AllocateBatchWise="Yes" RoomsId="" DaysId="" />

Figure 6.10


PRMIT&R//DCSE//07-08 67/95




Figure 6.11


PRMIT&R//DCSE//07-08 68/95


StartTime="" MaxDailyHrs="2.0" MaxHrsAtOnce="2.0" MaximumHrsPerWeek="6" CourseId="10" TeachersId=""


Figure 6.12

</ConstraintList>

</MyData>


PRMIT&R//DCSE//07-08 69/95

6.2 Front End Implementation

We have built our front end using Google Web Toolkit and Netbeans. We have written code in

Java which has finally converted to JavaScript (AJAX). The final output is out Tomcat’s Web application

package. The whole GWT web app is divided in to client side code and server side code

6.2.1 Implementation GWT Client Side Package

Our Client Package has following java files in package my.company.client

1. GWTService.java

2. GWTServiceAsync.java

3. MainEntryPoint.java

6.2.1.1 Details for GWTService.java

Package: my.company.client

Interface GWTService

public interface GWTService

Method Summary

java.lang.String getXML()

This method reads the data from XML KB stored on server and returns its

containts.

java.lang.String start(java.lang.String data)

This method takes updated XML knowledge base as parameter. Passes it to

server and returns generated HTML Timetable


PRMIT&R//DCSE//07-08 70/95

6.2.1.2 Details of GWTServiceAsync.java


Interface GWTServiceAsync

public interface GWTServiceAsync

Method Summary

void getXML(AsyncCallback callback)

This is declaration of method for Asynchronous Call

void start(java.lang.String data, AsyncCallback callback)

This is declaration of method for Asynchronous Call

6.2.1.3 Details about MainEntryPoint.java


Class MainEntryPoint

java.lang.Object

my.company.client.MainEntryPoint

public class MainEntryPoint

extends java.lang.Object


PRMIT&R//DCSE//07-08 71/95

Nested Class Summary

static class MainEntryPoint.Constraint

This class holds the Constraint on client machine

static class MainEntryPoint.Course

This class holds the Course on client machine

static class MainEntryPoint.Day

This class holds the Day on client machine

static class MainEntryPoint.Formatting

This class holds the Formatting on client machine

static class MainEntryPoint.Room

This class holds the Room on client machine

static class MainEntryPoint.Sem

This class holds the Sem on client machine

static class MainEntryPoint.Teacher

This class holds the Teacher on client machine

static class MainEntryPoint.TimeSlot

This class holds the TimeSlot on client machine

Field Summary

static java.util.List ConstraintList_Input

This is list of constraints residing in client’s memory


PRMIT&R//DCSE//07-08 72/95

static java.util.List CourseList_Input

This is list of courses residing in client’s memory

static java.util.List DayList_Input

This is list of days residing in client’s memory

static java.util.List FormattingList_Input

This is list of formatting residing in client’s memory

static java.util.List RoomList_Input

This is list of rooms residing in client’s memory.

static java.util.List SemList_Input

This is list of semesters residing in client’s memory.

static java.util.List TeacherList_Input

This is list of teachers residing in client’s memory.

static java.util.List TimeSlotList_Input

This is list of timeslots residing in client’s memory.

Method Summary

void GenerateAndWatch(java.lang.String XML)

This method generated the KB and passes it to server.

static GWTServiceAsync getService()


PRMIT&R//DCSE//07-08 73/95

void onModuleLoad()

This method is called when GWT Module is loaded into memory.

void readXML(java.lang.String XML)

This method parses XML KB and loads data in respective lists

6.2.2 Implementation GWT Server Package

Our server package has only one java file- GWTServiceImpl.java

6.2.2.1 Details about GWTServiceImpl.java

Package: my.company.server

Class GWTServiceImpl

java.lang.Object

RemoteServiceServlet

my.company.server.GWTServiceImpl

public class GWTServiceImpl

extends RemoteServiceServlet

Method Summary

java.lang.String getXML()

This is actual implementation of getXML() method defined in client package

java.lang.String start(java.lang.String data)

This is actual implementation of start() method defined in client package


PRMIT&R//DCSE//07-08 74/95

6.3 Screenshots of Execution of Algorithm

Figure 6.13 shows the debugging of our code of Algorithm in NetBeans_IDE

…………………………

Figure 6.13


PRMIT&R//DCSE//07-08 75/95

Figure 6.14 shows the various Lists loaded in to memory while execution of the algorithm .

Figure 6.14


PRMIT&R//DCSE//07-08 76/95

Figure 6.15 shows the structure of internal memory representation of Timetable Grid

Figure 6.15


PRMIT&R//DCSE//07-08 77/95

Figure 6.16 shows the each object we store in Timetable Grid with its different data members

Figure 6.16


PRMIT&R//DCSE//07-08 78/95

Figure 6.17 shows the memory representation of our Teacher List

Figure 6.17


PRMIT&R//DCSE//07-08 79/95

Figure 6.18 shows the internal memory representation of Constraint List

Figure 6.18


PRMIT&R//DCSE//07-08 80/95

Figure 6.19 shows the final HTML output emited by our algorithm

Figure 6.19


PRMIT&R//DCSE//07-08 81/95

6.4 Screenshots of our front end built using Google Web ToolKit

1. Management of Teachers List

Figure 6.20


PRMIT&R//DCSE//07-08 82/95

2. Management of Semester List

Figure 6.21


PRMIT&R//DCSE//07-08 83/95

3. Management of different courses List

Figure 6.22


PRMIT&R//DCSE//07-08 84/95

4. Management of different Rooms

Figure 6.23


PRMIT&R//DCSE//07-08 85/95

5. Management of Days

Figure 6.24


PRMIT&R//DCSE//07-08 86/95

6. Management of Time Slot

Figure 6.25


PRMIT&R//DCSE//07-08 87/95

7. Management of Formatting of Elements

Figure 6.26


PRMIT&R//DCSE//07-08 88/95

8. Management of different rules, constraints while generation of Timetable

Figure 6.27


PRMIT&R//DCSE//07-08 89/95

Figure 6.28 shows our final ready to use web application structure.

Figure 6.28


PRMIT&R//DCSE//07-08 90/95

6.4 Installation Manual

6.4.1 Requirements

Operating System: Windows 2000+, Linux Kernel 2.4 +

Other Software: JDK 1.5+, Tomcat 5.5+

Minimum Ram: 128 MB +

Free space: 250 MB+

6.4.2 Installation of our project is very easy and straight forward

1. Install JDK 1.5 +

2. Install Tomcat 5.5 +

3. Copy MyTimeTableManger.war to Tomcat’s webapps folder.

6.5 Operation Manual

1. Start Tomcat from its bin directory or using Link in Start Menu on Windows.

2. If you are running project on standalone machine then open following URL in your web

browser

� http://localhost:8080/MyTimeTableManager

3. If you are accessing project from remote client, then replace localhost with the

server’s IP address on which our project is installed.

4. Once application is loaded, click on “Load Data” button.

5. Once data is loaded add/modify various lists displayed as you require, using the

appropriate button provided for each specific task.

6. When you finished with your data modification. Click on “Generate Timetable” button.

7. Wait while your request is processed by server.

8. When timetable is generated output is shown just below main tab panel.

9. If there are some errors then errors will be displayed instead of timetable.

10. Once you are done, either you can stop Tomcat or just close your web browser.

11. You don’t need to save your changes. Our projects take care of it automatically.


PRMIT&R//DCSE//07-08 91/95

6.6 Performance of Algorithm

Figure 6.29 shows how conflicts go on increasing as algorithm proceeds. Since this is

sequential algorithm, conflicts increase as more timeslot are allocated.

Figure 6.29

Figure 6.30 shows how conflicts and collisions percentage increases for each next

waiting constraint for allocation. Well there is nothing wrong in this. But this is the way our

algorithm works.

0

10

20

30

40

50

60

70

80

Constraint Check 1 Constraint Check 2 Constraint Check 3 Constraint Check 4

Conflicts &

Collision

Percent

increase

Figure 6.30

Contrains

Co

nfl

icts

& C

oll

isio

n R

ati

o

C1 C2 C3 C4 C5 C6 C7 C8 C9 C10 C11 C12 C13 C14 …… Cn

100

90

70

40

30

10

0


PRMIT&R//DCSE//07-08 92/95

Conclusions

In this project we have designed and implemented our Java based automatic college timetable

generator. This algorithm is written in JAVA 5. The object oriented features of java and its string

manipulation functions helped us a lot. We have implemented the conflict resolution strategy directly

into our algorithm. So our algorithm never allocated same rooms to a same timeslot for different

semesters neither it allocates same teacher to different semesters for same timeslot.

Thought we have never tried to borrow code from any other timetabling algorithm

implementation. To just name, we can say that our algorithm is Constraint based, so it can be classified

under Constrain Satisfaction Problem Solving Algorithms.

Also we have designed the standard XML bases knowledge base for storing data, rules and facts.

While planning phase, we first decided our XML knowledge based structure and after that we have

written algorithm according to that. We have also used XML DOM parser to read data from XML

knowledge base to load it into different lists.

We have created a Rich Internet Application for our Timetable Manager Application. And we have

successfully implemented Google’s Web toolkit to create an AJAX based RIA for our project. One

added benefit of using GWT was it uses same Java code which we use to create buttons, list boxes

using AWT or Swing packages for desktop Java Application. So it saves our lot of time by automatically

converting that Java code to JavaScript for client side UI rendering. Also by developing our algorithm in

Java saved our time of learning new language and helped us to concentrate on logic of algorithm than

specific features of certain programming language. We have also achieved platform independence

with Java.

Finally we can say that our implementation is successful and practically application because to

generate timetable for one department requires a very small time varying from 2 sec to 5 sec only. So

our algorithm is definitely faster.


PRMIT&R//DCSE//07-08 93/95

References

Journals

[1] Practical Timetabling Algorithm for College Lecture-Timetable Scheduling Springer-Verlag

LNCS

[2] Practice and Theory of Automated Timetabling Volumn IV. (1997).

[3] M. A. Saleh Elmohamed, P. Coddington, G. Fax. A comparison of annealing

techniques for academic course scheduling. In Practice and Theory of Automated

Timetabling II (E. Burke and M. Carter(eds.)). Springer-Verlag LNCS 1408. (1998)

92-112.

Web References

[4] Google Web Toolkit

[4.1]. http://en.wikipedia.org/wiki/Google_Web_Toolkit

[4.2]. http://code.google.com/webtoolkit/resources.html

[4.3]. http://code.google.com/webtoolkit/gettingstarted.html

[4.4]. http://googlewebtoolkit.blogspot.com/2007/12/developing-gwt-applications-

with.html

[5] XML Tutorial

[5.1]. http://www.w3schools.com/xml/

[5.2]. http://en.wikipedia.org/wiki/XML

[6] dom4j: the flexible XML framework for Java

http://www.dom4j.org/guide.html

[7] AJAX

http://en.wikipedia.org/wiki/AJAX


PRMIT&R//DCSE//07-08 94/95

Future Work

Our future work includes the various improvements in various parts of our project

The timetabling algorithm can be improved in following ways

• The separate timetables for teachers and rooms.

• More constraints handling can be added. Such as scheduling of courses in morning

time slot on Saturday without breaking normal operation on other days.

• Facility of specifying different time slots.

• Monthly and yearly timetable generation.

• Better formatting of time tables.

• Add scheduling within practical batches.

• Add resource matching to various rooms.

• Import facility from other file formats.

• Export facility to various file formats.

The Knowledge base can be improved in following ways

• Remove unused fields.

• Make it compatible with Timetabling Markup Language.

The front end can be improved in several ways

• Different roles such as Administrator, User.

• Login facility for each user.

• Separate priority management module for Administrators.

• Drag and drop dynamic timetable change.

• More Visual Constrains Representation.

• Error checking on each field.

• Implementation of Truth Maintenance System.


PRMIT&R//DCSE//07-08 95/95

Bibliography

[1] Dewsbury, Ryan (2007). Google Web Toolkit Applications. Prentice Hall. ISBN 978-

0321501967.

[2] Chaganti, Prabhakar (2007). Google Web Toolkit: GWT Java Ajax Programming. Packt

Publishing. ISBN 978-1847191007.

[3] Geary, David (2007). Google Web Toolkit Solutions: More Cool & Useful Stuff. Prentice

Hall. ISBN 978-0132344814.

[4] Hanson, Robert; Adam Tacy (2007). GWT in Action: Easy Ajax with the Google Web

Toolkit. Manning. ISBN 978-1933988238.

[5] Cooper, Robert; Charlie Collins (2008). GWT in Practice. Manning. ISBN 978-1933988290.

Abstract

Introduction

Literature Survey

Problem Definition

Requirements

And Analysis

System Design

Implementation

Conclusion

Future Work

References

Bibliography

73360839 Project Report on Rich Internet Application for Automatic College Timetable Generation 24th March 2008

Documents

working of algorithm

teacher day constraint

performance of algorithm

step execution of algorithm

constraint matrix

timetable method

teacher time slot constraint

project work