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 Mandar Kavishwar Prafulla Ingle Ajay Chate Shailesh Thakre Gaurav Bhuyar
Department Of Computer Science And Engineering

Prof. Ram Meghe Institute of Technology And Research, Badnera 2007-08
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 Mandar Kavishwar Prafulla Ingle Ajay Chate Shailesh Thakre Gaurav Bhuyar
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
Department Of Computer Science and Engineering

Prof. RAM MEGHE INSTITUTE OF TECHNOLOGY & RESEARCH, BADNERA 2007-08
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 Abstract Introduction Literature Survey 2.1 Timetabling 2.1.1 The General View 2.1.2 The Object-Oriented View 2.1.3 Planning 2.1.4 Constraints 2.2 Rich Internet application 2.2.1 Introduction 2.2.2 History 2.2.3 General Benefits 2.2.4 Performance Benefits 2.2.5 Shortcomings 2.2.6 Software development complications 2.2.7 Current status of development 2.3 AJAX 2.3.1 Introduction 2.3.2 Use of AJAX 3 General Problem Formulation 3.1 Strong Constraints 3.2 Weak Constraints Requirements and Analysis 4.1 Automatic Generation of Timetable 4.1.1 Details about Java 4.1.2 Different criteria and conditions to consider while generating timetable 4.2 Standardized Knowledgebase representation 4.2.1 XML 4.3 Responsive Interface 4.3.1 Details about Google Web Tool Kit 4.3.2 Introduction of the Google Web Toolkit (GWT) 4.3.3 GWT execution modes 4.3.4 GWTs four major components/libraries 4.4 Jakarta Tomcat System Design Page No 1 2 4 4 5 6 6 9 10 10 10 11 12 13 15 17 23 23 24 25 26 26 28 28 29 29 30 30 31 32 32 32 33 34 35
1 2
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 40 visually as follows 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 5.7 The Working Of Perform Allocation_Method 5.8 Data Flow within Algorithm 5.9 Front End Design Implementation 46 47 48 49 51 51 51 55 69 69 73 74 81 90 90 91 92 93 94 95
6.1 Timetabling Algorithm 6.1.1 Details about Main class which is responsible for generating timetable 6.1.2 Step by Step Execution of Algorithm 6.2 Front End Implementation 6.2.1 Implementation GWT Client Side Package 6.2.2 Implementation GWT Server Package 6.3 Screenshots of execution of algorithm 6.4 Screenshots of our front end built using Google Web ToolKit 6.4 Installation Manual 6.5 Operation Manual 6.6 Performance of Algorithm 7 Conclusions References Future Work Bibliography
List of Figures
No. Fig.2.1 Fig.2.2 Fig.2.3 Fig.4.1 Fig.5.1 Fig.5.2 Fig.5.3 Fig.5.4 Fig.5.5 Fig.5.6 Fig.5.7 Fig.5.8 Fig.5.9 Fig.5.10 Fig.5.11 Fig.5.12 Fig.5.13 Fig.5.14 Fig.5.15 Fig.5.16 Fig.5.17 Fig.5.18 Fig.6.1 Fig.6.2-6.12 Fig.6.13 Fig.6.14 Fig.6.15 Fig.6.16 Fig.6.17 Fig.6.18 Fig.6.19 Fig.6.20-6.28 Fig.6.29 Fig.6.30 Title Class View & Teacher View Mapping of Timetables Redundancy of Information The Structure of GWT Various Components of Project Flow of Data within Project Design of Algorithm Data Structures Teacher-Subject Constraint Teacher-Slot Constraint Teacher-Day Constraint Teacher-Year Constraint Year-Room Constraint Constraints Matrix Design of Working of Algorithm I Design of Working of Algorithm II Sample Timetable Steps for Initializing Timetable Working of Perform Allocation Method Data Flow within Algorithm Client-Server Architecture Compilation Process of GWT Structure of Timetable Step wise Execution of Algorithm Debugging in NetBeans IDE Representations of Lists in Memory Internal Memory Allocation Object Storage in Timetable Grid Memory Representation of Teacher List Memory Representation of Constraints List Final HTML Output Screen Shots of Front End Performance of Algorithm Conflict & Collision Percentage Page No. 07 08 09 33 35 36 39 40 41 41 42 42 43 43 44 45 45 46 47 48 49 50 57 58-68 74 75 76 77 78 79 80 81-89 91 91
Rich Internet Application for Weekly Automatic College Timetable Generation
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 clients 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.
PRMIT&R//DCSE//07-08
1/95
1. Introduction
Even though most college administrative work has been computerized, the lecturetimetable 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
2/95
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 Googles Web Toolkit (GWT) for building RIA. This decision is taken during our Requirement and Analysis phase and details GWT is explained in that section.
3/95
2. Literature Survey
2.1 Timetabling
A timetable construction is an NP-complete scheduling problem. It is not a standard jobshop 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
4/95
(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
5/95
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.
6/95
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).
7/95
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.
8/95
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.
9/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
10/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
11/95
Rich Internet Application for Weekly Automatic College Timetable Generation 2. 3.
updates/upgrades to new versions are automatic 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
12/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
13/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 clientside 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.
14/95
Rich Internet Application for Weekly Automatic College Timetable Generation 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,
15/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
16/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 users 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-toserver) 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,
17/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 crossbrowser-compatible JavaScript. Designed specifically for Java developers, GWT enables Java
18/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.
19/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
20/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.
21/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.
22/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.
23/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-todate 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.
__________________________________________________________________
24/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 weekdays 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:
25/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 instructors 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 instructors 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.
26/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 departments exclusive-use classrooms.
C16: The classrooms should be allocated in a manner to minimize the distances between adjacent classess 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.
27/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 colleges timetabling problem. Also due to fixed time period, we have decided to develop our own timetabling algorithm tailored to our colleges 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.
28/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. 2. 3. 4.
Teachers Courses Semesters Rooms
It should provide mechanism for specifying various constraints such as

1.
Teacher-Room Constraints
29/95
Rich Internet Application for Weekly Automatic College Timetable Generation 2. 3. 4. 5.
Year-Room Constraints Teacher-Timeslot Constraints Teacher-Day Constraints 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 textbased 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.
30/95
4.2.1.1 Advantages of XML

1. 2. 3. 4. 5. 6. 7. 8. 9.
10. 11. 12. 13. 14.
It is text-based. It supports Unicode, allowing almost any information in any written human language to be communicated. It can represent common computer science data structures: records, lists and trees. Its self-documenting format describes structure and field names as well as specific values. The strict syntax and parsing requirements make the necessary parsing algorithms extremely simple, efficient, and consistent. XML is heavily used as a format for document storage and processing, both online and offline. It is based on international standards. It can be updated incrementally. 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. The hierarchical structure is suitable for most (but not all) types of documents. It is platform-independent, thus relatively immune to changes in technology. Forward and backward compatibility are relatively easy to maintain despite changes in DTD or Schema. Its predecessor, SGML, has been in use since 1986, so there is extensive experience and software available. 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.
31/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.
32/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 Googles web toolkit
t Figure 4.1
33/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.
34/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.
In XML
Error Handling System
Knowledge Base
Inbuilt in Front End
Priority Maintenance System Inbuilt in Algorithm
Inference Engine
Conflict Resolution Strategy
2
Output
Figure 5.1
35/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
GUI Interface for Input (JSP/Servlet/ AJAX)
Knowledgebase including Policies, Dynamic Timetable Data & Soft Constraints (XML)
Weekly Timetable Generator Algorithm (Java)
Generated Timetable Sheet (HTML)

Figure 5.2
36/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>
37/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>
38/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.
Start
Stop
Read Data
Format Timetable
Initialize Timetable
Generate Timetable
Perform Allocation
Figure 5.3
39/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
40/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
41/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
42/95
5.4.8 Year (Semester) Room Constraint

Some room may have specific facility for particular year. So that years 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
43/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
44/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
45/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.
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
Stop
Figure 5.14
46/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 For All Items in Timetable is Free If Item Forward Search
Allocate
Is Current Item Allocated Then Break Current
Figure 5.15
47/95
5.8 Data Flow within Algorithm

Figure 5.16 shows various list used by timetabling algorithm to perform_allocation.
Constraints List
Days List MON TUE WED
Timeslot s List 11-12 12-1 1-2
1st 2nd 3rd
Get Teacher Name Get All TimeSlots Get All Days
Sems List 4th 6th Get All Sems
Is TimeSlot Free?
8th
Is Teacher Free?
Rooms List R1
Is Room Free?
Get All Rooms
R2 R3
Get Sem Name
Match Semester
Get Course Name
Allocate Item
Sem/Time
11-11.3
11.3-12
12-12.3
12.3-1
MON
4th 6th 8th Figure 5.16
48/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
Server
Web Container like TOMCAT
Get Web App
Client
AJAX Based UI Code Running in Clients Web Browser
AJAX+HTML
Timetable Generator Web Application Logic
Read XML KB Data() XML KB
XML Parser & Timetable Generator Algorithm
Generate timetable
Timetable in HTML Generated Timetable
Figure 5.17
49/95
5.9.2 Compilation Process of Google Web Toolkit

GWT JRE Emulation Libraries GWT UI Components
Java Client Side UI Code This diagram shows how the web pages will be designed using Googles web toolkit.
Google Web Toolkit Compiler
AJAX and HTML Code
Run in
Web browser
Open
Figure 5.18
50/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
51/95
Rich Internet Application for Weekly Automatic College Timetable Generation 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.
52/95
Rich Internet Application for Weekly Automatic College Timetable Generation 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
53/95
Rich Internet Application for Weekly Automatic College Timetable Generation 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.
54/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>
55/95
<RoomList>
<Room Name="R2" Id="1" Type="Theory" Resources="7,2"/> <Room Name="R3" Id="2" Type="Theory" Resources="7,2"/> <Room Name="R4" Id="3" Type="Theory" Resources="7,2"/> <Room Name="R5" Id="4" Type="Theory" Resources="7,2"/> <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>
56/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.
57/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
58/95
2.
<Constraint Id="2" Name="Teacher Allocation" StartTimeOnlyAfter="" AndEndTimeOnlyBefore=""
StartTime="" MaxDailyHrs="1.0" MaxHrsAtOnce="1.0" MaximumHrsPerWeek="4" CourseId="1" TeachersId="2" SemId="8" AllocateBatchWise="" RoomsId="" DaysId="" />
Figure 6.3
59/95
3.<Constraint Id="3" Name="Teacher Allocation" StartTimeOnlyAfter="13.30" AndEndTimeOnlyBefore=""

StartTime="" MaxDailyHrs="2.0" MaxHrsAtOnce="2.0" MaximumHrsPerWeek="2" CourseId="2" TeachersId="5" SemId="8" AllocateBatchWise="Yes" RoomsId="" DaysId="" />
Figure 6.4
60/95
4.<Constraint Id="4" Name="Teacher Allocation" StartTimeOnlyAfter="" AndEndTimeOnlyBefore=""

Figure 6.5
61/95

Figure 6.6
62/95

StartTime="" MaxDailyHrs="2.0" MaxHrsAtOnce="2.0" MaximumHrsPerWeek="2" CourseId="5" TeachersId="7" SemId="8" AllocateBatchWise="Yes" RoomsId="" DaysId="" />
Figure 6.7
63/95

Figure 6.8
64/95

Figure 6.9
65/95

StartTime="" MaxDailyHrs="2.0" MaxHrsAtOnce="2.0" MaximumHrsPerWeek="2" CourseId="8" TeachersId="6,1" SemId="8" AllocateBatchWise="Yes" RoomsId="" DaysId="" />
Figure 6.10
66/95

Figure 6.11
67/95

StartTime="" MaxDailyHrs="2.0" MaxHrsAtOnce="2.0" MaximumHrsPerWeek="6" CourseId="10" TeachersId="" SemId="8" AllocateBatchWise="Yes" RoomsId="" DaysId="" />
Figure 6.12
</ConstraintList> </MyData>
68/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 Tomcats 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
69/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
70/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 clients memory
71/95
Rich Internet Application for Weekly Automatic College Timetable Generation static java.util.List CourseList_Input
This is list of courses residing in clients memory

static java.util.List DayList_Input
This is list of days residing in clients memory

static java.util.List FormattingList_Input
This is list of formatting residing in clients memory

static java.util.List RoomList_Input
This is list of rooms residing in clients memory.

static java.util.List SemList_Input
This is list of semesters residing in clients memory.

static java.util.List TeacherList_Input
This is list of teachers residing in clients memory.

static java.util.List TimeSlotList_Input
This is list of timeslots residing in clients memory.
Method Summary
void GenerateAndWatch(java.lang.String XML)
This method generated the KB and passes it to server.

static GWTServiceAsync getService()
72/95
Rich Internet Application for Weekly Automatic College Timetable Generation 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
73/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
74/95
Figure 6.14 shows the various Lists loaded in to memory while execution of the algorithm .
Figure 6.14
75/95
Figure 6.15 shows the structure of internal memory representation of Timetable Grid
Figure 6.15
76/95
Figure 6.16 shows the each object we store in Timetable Grid with its different data members
Figure 6.16
77/95
Figure 6.17 shows the memory representation of our Teacher List
Figure 6.17
78/95
Figure 6.18 shows the internal memory representation of Constraint List
Figure 6.18
79/95
Figure 6.19 shows the final HTML output emited by our algorithm
Figure 6.19
80/95
6.4 Screenshots of our front end built using Google Web ToolKit
1. Management of Teachers List
Figure 6.20
81/95
2. Management of Semester List
Figure 6.21
82/95
3. Management of different courses List
Figure 6.22
83/95
4. Management of different Rooms
Figure 6.23
84/95
5. Management of Days
Figure 6.24
85/95
6. Management of Time Slot
Figure 6.25
86/95
7. Management of Formatting of Elements
Figure 6.26
87/95
8. Management of different rules, constraints while generation of Timetable
Figure 6.27
88/95
Figure 6.28 shows our final ready to use web application structure.
Figure 6.28
89/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 Tomcats 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 servers 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 dont need to save your changes. Our projects take care of it automatically.
90/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.
Conflicts & Collision Ratio
100 90 70 40 30 10 0
C1 C2 C3 C4 C5 C6 C7 C8 C9 C10 C11 C12 C13 C14 Cn
Contrains
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.
80
Conflicts & 60 Collision 50 Percent 40 increase

30 20 10 0 Constraint Check 1 Constraint Check 2 Constraint Check 3 Constraint Check 4
70
Figure 6.30
91/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 Googles 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.
92/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]. [4.2]. [4.3]. [4.4]. http://en.wikipedia.org/wiki/Google_Web_Toolkit http://code.google.com/webtoolkit/resources.html http://code.google.com/webtoolkit/gettingstarted.html http://googlewebtoolkit.blogspot.com/2007/12/developing-gwt-applicationswith.html [5] XML Tutorial [5.1]. [5.2]. http://www.w3schools.com/xml/ 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
93/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.
94/95
Bibliography
[1] Dewsbury, Ryan (2007). Google Web Toolkit Applications. Prentice Hall. ISBN 9780321501967. [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.
95/95
Abstract
Introduction
Literature Survey
Problem Definition
Requirements And Analysis
System Design
Implementation
Conclusion
Future Work
References
Bibliography

Project Report On Rich Internet Application For Automatic College Timetable Generation (24th March 2008)

Caricato da

Informazioni sul documento

Descrizione originale:

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Project Report On Rich Internet Application For Automatic College Timetable Generation (24th March 2008)

Caricato da

Copyright:

Formati disponibili

ON

Department Of Computer Science And Engineering

This is to certify that the Project work entitled,

"RICH INTERNET APPLICATION FOR WEEKLY AUTOMATIC COLLEGE TIMETABLE GENERATION"

Prof. Dr. M. S. ALI

Department Of Computer Science and Engineering

Rich Internet Application for Weekly Automatic College Timetable Generation

Rich Internet Application for Weekly Automatic College Timetable Generation

Rich Internet Application for Weekly Automatic College Timetable Generation

Rich Internet Application for Weekly Automatic College Timetable Generation

Rich Internet Application for Weekly Automatic College Timetable Generation

2.1.1 The General View

Rich Internet Application for Weekly Automatic College Timetable Generation

2.1.2 The Object-Oriented View

Rich Internet Application for Weekly Automatic College Timetable Generation

Rich Internet Application for Weekly Automatic College Timetable Generation

Rich Internet Application for Weekly Automatic College Timetable Generation

Rich Internet Application for Weekly Automatic College Timetable Generation

2.2 Rich Internet application

Rich Internet Application for Weekly Automatic College Timetable Generation

Rich Internet Application for Weekly Automatic College Timetable Generation 2. 3.

Rich Internet Application for Weekly Automatic College Timetable Generation

2.2.5 Shortcomings Shortcomings and restrictions associated with RIAs are:

Rich Internet Application for Weekly Automatic College Timetable Generation

Rich Internet Application for Weekly Automatic College Timetable Generation 8.

Rich Internet Application for Weekly Automatic College Timetable Generation

Rich Internet Application for Weekly Automatic College Timetable Generation

Rich Internet Application for Weekly Automatic College Timetable Generation

Rich Internet Application for Weekly Automatic College Timetable Generation

Rich Internet Application for Weekly Automatic College Timetable Generation

Rich Internet Application for Weekly Automatic College Timetable Generation

Rich Internet Application for Weekly Automatic College Timetable Generation

Rich Internet Application for Weekly Automatic College Timetable Generation

Rich Internet Application for Weekly Automatic College Timetable Generation

Rich Internet Application for Weekly Automatic College Timetable Generation

3. General Problem Formulation

Rich Internet Application for Weekly Automatic College Timetable Generation

3.1 Strong Constraints

3.2 Weak Constraints

Rich Internet Application for Weekly Automatic College Timetable Generation

Rich Internet Application for Weekly Automatic College Timetable Generation

4. Requirements and Analysis

4.1 Automatic Generation of Timetable

Rich Internet Application for Weekly Automatic College Timetable Generation

Teachers Courses Semesters Rooms

It should provide mechanism for specifying various constraints such as

Rich Internet Application for Weekly Automatic College Timetable Generation 2. 3. 4. 5.

Year-Room Constraints Teacher-Timeslot Constraints Teacher-Day Constraints Teacher-Year Constraints

4.2 Standardized Knowledgebase representation

Rich Internet Application for Weekly Automatic College Timetable Generation

4.2.1.1 Advantages of XML

10. 11. 12. 13. 14.

4.3 Responsive Interface

Rich Internet Application for Weekly Automatic College Timetable Generation

Rich Internet Application for Weekly Automatic College Timetable Generation

Rich Internet Application for Weekly Automatic College Timetable Generation

Rich Internet Application for Weekly Automatic College Timetable Generation

5. System Design 5.1 Various Components of Project

Error Handling System

Inbuilt in Front End

Priority Maintenance System Inbuilt in Algorithm

Conflict Resolution Strategy