SCHEDULE TRACKER
Declaration We declare that this written submission represents our ideas in our own words and where others' ideas or words have been included, we have adequately cited and referenced the original sources. We also declare that we have adhered to all principles of academic honesty and integrity and have not misrepresented or fabricated or falsified any idea/data/fact/source in ou ourr su subm bmiss issio ion. n. We un unde derst rstan and d th that at an any y vi viol olat atio ion n of th thee ab abov ovee wi will ll be ca caus usee fo for r disciplinary action by the Institute and can also evoke penal action from the sources which have thus not been properly cited or from whom proper permission has not been taken when needed.
Declaration We declare that this written submission represents our ideas in our own words and where others' ideas or words have been included, we have adequately cited and referenced the original sources. We also declare that we have adhered to all principles of academic honesty and integrity and have not misrepresented or fabricated or falsified any idea/data/fact/source in ou ourr su subm bmiss issio ion. n. We un unde derst rstan and d th that at an any y vi viol olat atio ion n of th thee ab abov ovee wi will ll be ca caus usee fo for r disciplinary action by the Institute and can also evoke penal action from the sources which have thus not been properly cited or from whom proper permission has not been taken when needed.
CONTENT Chapter 1
Introduction. 1.1 eed for a new system 1." #etailed problem definition 1.! %urpose 1.$ &cope 1. (ime)rame &chedule 1.* +onclusion
12
1! 1$ 1$ 1$ 1 1*
Chapter 2
Review of Literature
17
".1 inear %rogramming/Integer %rogramming
1-
"." volutionary and enetic 0lgorithms
1
".! )easibility study
12
".!.1. (e (echnical chnical feasibility
"3
".!." 4perational feasibility
"3
".!.! )inan )inancial cial feasibi feasibility lity
"3
".$+onclusion
"3
Chapter 3
Reuire!ent "nal#$i$
21
!.1 5ardware requirement
"1
!." &oftware requirement
"1
!.! +onstraint6s
""
!.!.1 5ard +onstraints
""
!.!." &oft +onstraints
""
!.$ %roduct )eatures
""
!. +onclusion
"!
Chapter %
&#$te! De$i'n
2%
$.1 Use case diagram "$ $." Wo Work rk 7reakdown &tructure
"*
$.! #ata )low diagram
"-
$.$ 8 diagram
"
$. 0ctivity diagram
!3
$..1 0+(I9I 0+(I9I(: (: #I080 #I080; ; )48 I<=I8: +0&& 090I07
!"
0# +0&& 744>I
$.." 0+(I9I(: #I080; )48 0## &=7?+( 48 +0&&
!!
$.* &<=+ #I080;
!$
$.*.1 &<=+ #I080; @0## (0+58A
!
$.*." &<=+ #I080; @0## &+5#=A
!*
$.- +onclusion
!-
Chapter (
I!ple!entation
3)
.1 Interface Implementation
!2
." 0lgorithm Implementation
$3
.! #atabase Implementation
$1
.$ +onclusion
$"
Chapter *
Te$tin'
%3
*.1 (est 0pproach
$$
*." (est 0pproach
$$
*.! 9a 9alidati lidation on (esting
$
*.$ )unctional testing
$
*. Integration (e (esting sting
$
*.* =ser 0cceptance (e (est st
$
*.- &ystem (e (est st +riteria
$
*. (e (est st cases and (e (est st results
$
*.2 +onclusion
1
Chapter 7
Re$ult and appendi+
(2
-.1 &napshots
!
Chapter )
Conclu$ion Conclu$io n and ,uture -o -or$ r$
*3
.1 +onclusion
*$
." )uture Work
*
/i0lio'raph#
**
Li$t of ,i'ure$ ,i'ure No.
Caption
a'e No.
1.1
Timeframe Schedule
15
4.1
Use case Diagram
25
4.2
Work Breakdown Structure
26
4.
Data flow Diagram
2!
4.4
"# Diagram
2$
4.5
%cti&it' Diagram (or )ogin
1
4.5.1
%cti&it' Diagram (or *n+uir' ,lass %&aila-le %nd ,lass Booking
2
4.5.2
%cti&it' Diagram (or %dd Su-ect /r ,lass
4.6
Se+uence Diagram (or 0alidation
4
4.6.1
Se+uence Diagram %dd Teacher
5
4.6.2
Se+uence Diagram %dd Schedule
6
6.3.1
)ogin
46
6.3.2
Ttgenerator
46
6.3.
/en Ta-le
4!
6.3.4
Su-ect
4!
6.3.5
Teacher
43
6.3.6
Batch
43
6.3.!
Su-ectTeacher
4$
6.3.3
BatchSu-ect
4$
6.3.$
BatchSelect
5
6.3.1
Ta-le 0iew
5
6.3.11
Sa&e
51
!.1.1
Branches
52
!.1.2
#ooms
5
!.1.
Teachers
54
!.1.4
Su-ects
55
!.1.5
Da's
56
!.1.6
Slots
5!
!.1.!
BranchesTeachers
53
!.1.3
)ectures
5$
!.1.$
Select
6
!.1.1
Schedule
61
Abstract
The manual system of preparing schedule in colleges with large number of students is very time consuming and usually ends up with various classes clashing either at same room or with same teachers having more than one class at a time. These are just due to common human errors which are very difficult to prevent. To overcome these problems people usually taking the previous years’ schedule and modifying it but still it is a tedious job to incorporate changes. To overcome all these problems we propose to make an automated system. The system will take various inputs like details of students, subjects and class rooms and teacher’s availability, load distribution, lab availability depending upon these inputs it will generate a possible schedule, making optimal utilization of all resources in a way that will best suit any of constraints or college policies. List of subjects may include electives as well as core subjects. The case is similar to colleges and other educational institutions. So our aim is to develop a general purpose which can efficiently generate optimal solutions.
Chapter 1
Introduction
&cheduling has been in human requirements since they thought of managing time effectively. It is widely used in colleges and other teaching institute like crash courses, couching centers, training programs etc . In early days, scheduling was done manually with a single person or some group involved in task of scheduling it with their hands, which take lot of effort and time. While scheduling even the smallest constraints can take a lot of time and the case is even worse when the number of constraints or the amount of data to deal with increases. ngineering colleges are the regular users of such time tables. (hey need to schedule their course to meet the need of current duration and facilities that are available to them. 5owever, their schedule should meet the requirement of new course addition and newly enrolled students to fresh batches. (his defines the proBect being developed along with the description of eCisting systems of similar type. 5ere the need for the new system, its future prospects and currently available systems of similar types have been defined which therefore presents a brief overview of the system being developed in terms of its differences with the previously available systems and the newly embedded functionalities.
1.1 NEED ,OR " NE- &&TE4
&chedule tracker is a very important part of the college management system. It helps the college management to maintain the discipline in the college premises. (he schedule tracker creation is a very old process in the college management. (ill now, it is done manually. (he college management assigns one teacher for this purpose and his Bob is to create schedule tracker manually for each branch of every semester.
0s there are so many subBect in each branch and there might be a case when same professor will teaches different subBects in one semester. (here might be case when some collision will occur during assign the lectures manually. 0lso, the manual assignment of the lectures is a very tedious and long process work. In the eCisting system, the problem occurs when any teacher is on the leave and he will not able to inform or inform it late than the manual assignment of substitute teacher is also a very difficult Bob. When the schedule tracker is generated manually, there is a case when the department head want to makes some changes in the lectures. 0t this situation, the chances of the collision of the period or assignment of the teachers will increase because it is not possible for one teacher to remember all assignment done earlier. &o the chance of the mistake will increase. (hese are some of the mistakes which occur during developing the schedule tracker manually. (he manual maintenance of the databases of items, schedule tracker processing is a time taking process and somehow erroneous. &o there is a need for the new system to resolve such problems. In our college schedule tracker management system we are trying to solve these problems and along with that we try to provide the user friendly and efficient way to generate the schedule tracker automatically. 4ur proBect is a web based system in which user has to fill some form related to the college, subBects, labs, teachers and the branch and then our system will generate the most possible schedule tracker.
1." DET"ILED RO/LE DE,INITION 4ur basic function is to create a schedule tracker for a college including different branches and semester. (he main problem that occurred during the proBect is to create and maintain the databases of different entities involved in this process. (he database contains the information about the various semesters, subBects, lab, teachers etc. &o maintain such a large database is a big challenge for us. (he problem we face during our proBect is how the collision of two subBects or the teachers can avoid. very proBect has some drawbacks. (here is a chance when the collision will occur when we generate more schedule trackers for different branches. &o, these are some problem which we face in our proBect.
1.3 5RO&E4
%lanning schedules is one of the most compleC and errorDprone applications. (here are still serious problems like generation of high cost schedules are occurring while scheduling and these problems are repeating frequently. (herefore there is a great requirement for an application distributing the course evenly and without collisions. 4ur aim here is to develop a simple, easily understandable, e cient and portable application, which could automatically generate good quality schedules with in secDonds.
1.% &COE4
4ur software allows users to generate schedule for newly occurring changes in less time, with less effort and with more efficiency. It will allow users to work on and view schedules in different platforms and view different information simultaneously.
1.( TIE,R"E &C6ED5LE 4
(his is our proposed timeframe for our proposed &C6ED5LE TR"CER &C6ED5LE TR"CER
238978291% 398978291%
1389)8291% 2789)8291% 1789:8291% 2%89:8291% 9)8198291%
&elected $chedule tracer as a proBect. &tarted to collect various information about proBect, like different scheduling algorithms, different available resources. 0nalyEed different information. Initially discuss the process of timetable with respective professor. &et the algorithm which is generic algorithm based on genetic algorithm. &elected front end as %5% and back end as ;y&ql. %repare the &8& document and submitted for phase 0 report.
228198291% 978918291(
&ubmitted the presentation on theory related to genetic algorithm. #ownloaded required software6s.
118928291(
Install Campp control panel and netbbeans I#. &tarted to study the various functionality of software6s and their features. &ubmitted our software design report.
2(8928291(
+hanged I# to netbeans
1)8938291(
+ompleted the interface design.
2(8938291(
+ompleted the logic.
9)89%8291(
Integration and modification of #atabase.
1(89%8291(
8eports and slides are completed.
1%8918291( 2)8918291(
)igure 1.1F (imeframe &chedule
1.* Conclu$ion4 (his chapter glanced on why we required schedule tracker, necessity of schedule tracker for any engineering colleges. It figure out the issues in eCisting timetable system which is done manually and how this issues get resolved in our proposed system. It glanced on our (imeframe &chedule which we carried throughout the completion of our $chedule tracer.
Chapter 2
Review of Literature (his chapter provides an analysis of the automated schedule literature broadly organiEed by algorithmic technique. It begins with a presentation of the maBor schedule
solution generation algorithms that have persisted in the literature. 0 detailed eCamination of the academic literature is provided within the conteCt of these fundamental solution generation algorithms. 0n analysis of the literature, grouped by the solution generation technique used, is then presented.
2.1 Linear ro'ra!!in'8Inte'er ro'ra!!in' 4
(he inear and Integer %rogramming techniques, the first applied to scheduling, were developed from the broader area of mathematical programming. ;athematical programming is applicable to the class of problems characteriEed by a large number of variables that intersect within boundaries imposed by a set of restraining conditions @(hompson, 12*-A. (he word GprogrammingG means planning in this conteCt and is related to the type of application @)eiring, 12*A. (his scheme of programming was developed during World War II in connection with nding optimal strategies for conducting the war e ort and used afterwards in the elds of industry, commerce and government services @7unday, 12$A.
inear %rogramming @%A is that subset of mathematical programming concerned with the e cient allocation of limited resources to known activities with the obBecDtive of meeting a desired goal such as maCimiEing profits or minimiEing costs @)eiring, 12*A. Integer %rogramming @I%A deals with
the solution of mathematical programming problems in which some or all of the variables can assume nonDnegative integer values only. 0lthough % methods are very valuable in formulating and solving problems related to the efficient use of limited resources they are not restricted to only these problems @7unday, 12$A. inear programming problems are generally acknowledged to be efficiently solved by Bust three methods, namely the graphical method, the simpleC method, and the transportation method @see eg, %almers and Innes, 12-*H ;akower and Williamson, 12A. (he construction of a linear programming model involves three successive problemD solving steps. (he first step identifies the unknown or independent decision variables. &tep two requires the identification of the constraints and the formulation of these constraints as linear equations. )inally, in step three, the obBective function is identified and written as a linear function of the decision variables.
2.2 Evolutionar# and ;enetic "l'orith!$
volutionary 0lgorithms @0sA are a class of direct, probabilistic search and optimiEation algorithms gleaned from the model of organic evolution. 0 enetic 0lgorithm @0A is a type of 0 and is regarded as being the most widely known 0 in recent times. 0 0 differs from other search techniques in the following waysF 0s optimiEes the tradeDo between eCploring new points in the search space and eCploiting the information discovered thus far. 0s has the property of implicit parallelism. Implicit parallelism means that the 0s effect is equivalent to an eCtensive search of hyper planes of the given space, without directly testing all
hyper plane values . ach schema denotes a hyper plane. 0s are randomiEed algorithms, in that they use operators whose results are governed by probability. (he results for such operations are based on the value of a random number . (his means 0s use probabilistic transition rules, not deterministic rules. 0s operates on several solutions simultaneously, gathering information from current search points to a direct subsequent search. (heir ability to maintain multiple solutions concurrently makes them less susceptible to the convergence problem of local maCima and noise . 0s work with a coding of the parameter set, not the parameters themselves. 0s search from a population of points, not a single point . 0s use @obBective functionA information, not derivatives or other auCiliary knowledge. It is demonstrated that the literature is currently converging on the use of conDstraint based solution algorithms and implementations. It is also noted that the neCt most commonly reported implementation involves the use of hybrid algorithms.
2.3 ,ea$i0ilit# $tud#4
#ue to the advent of various schedule tracker management systems, we need to analyEe the efficiency of user in implementing and using these functionalities. &o a new schedule tracker management system is developed which is feasible in all respect which would be time saving and beneficial to the user. We need to analyEe the proposed system for its feasibilities. #uring the preliminary stage of designing the system, the feasibility study for the system was undertaken and it was found that the system was technically, financially and operationally feasible in nature. (he feasibility study can be categoriEed intoF
2.3.1. Technical fea$i0ilit#4
(he technical issues usually raised during the feasibility stage of the investigation include the followingD #oes the necessary technology eCist to do what is suggested, Will the proposed system provide the adequate response to the inquires and perform all the eCpected functions, +an the system be upgraded if it is developed more in later and are they have technical guaranty of accuracy, reliability, ease of access and data security.
2.3.2 Operational fea$i0ilit#4
0ny system is beneficial if they can be turned out into information system. (his will helps in meeting the operating requirements of the organiEation. 4perational feasibility aspects of the proBect are to be taken as an important part of the proBect implementation. (he well planned design will ensure the user for the optimal utiliEation of the computer resources and will help in the improvement of performance status. 4ur system follows all the standards given above. &o, our system is operational feasible.
2.3.3 ,inancial fea$i0ilit#4
In the economic feasibility, the development cost in creating the system is evaluated against the ultimate benefit derived from the new systems. conomical benefits must equal or eCceed the costs. 4ur system is economical feasible.
Conclu$ion4
(his chapter Review of literature specifically glanced on enetic algorithm which is used in proposed system. (he generic algorithm which in turn acts as our proBect logic is basically derived from genetic algorithm. It concludes that the inear and Integer %rogramming techniques, the first applied to scheduling were developed from the broader area of mathematical programming. (his chapter gives feasibility study in every aspect like (echnical feasibility, operational feasibility and financial feasibility.
Chapter 3
Reuire!ent "nal#$i$
(his gives minimum requirement your system should have in order to make this software work. (his software works fine in any operating system in which the developer tools or the user tools can be installed. &ince we had limited resources we could only test in Widows -, Windows %, =buntu 11.3$, =buntu 13.13. &o usually the requirement specification will be same as that of the operating system. &o we are providing a standard specification.
3.1 6ardware reuire!ent • • •
%rocessorF " 5E C* 5ard disk spaceF "37@requiredA or more ;emoryF "* ;7 80;
3.2 &oftware reuire!ent • • • •
(oolF otepadJJ &erverF ampp &erver #atabaseF ;y&ql anguageF %5%,+&& and 5(;
3.3 Con$traint<$
&ome of the most common constraints to deal with are listed below. &ome of these are soft constraints meaning they only increase the cost. &ome are hard which cannot be violated.
3.3.1 6ard Con$traint$4
•
o teacher or student must be assigned to more than one class.
•
(here should be required number of periods for each course.
•
ach course must have required consecutive periods. )or eCample lab is assigned to " consecutive hours.
3.3.2 &oft Con$traint$4
•
+ourses must be evenly distributed.
•
&ame teacher must not have consecutive periods unless specified.
3.% roduct ,eature$ 4
&ome of the most important features offered by our software are •
&imple wiEard type user interface
•
ogin authentication with ;y&< login details ;essage dialogs for user assistance.
•
;ouse or/and keyboard for inputs, keyboard shortcuts are available.
•
&eparate database maintaining basic information6s, subBects, teachers, batches and their associations and other details
•
#atabase for holding generated schedule and for storing required schedules.
•
)eatures for assigning priorities for subBects.
•
)eatures for editing generated table, saving edited tables and opening saved tables
•
5igh portability, works on almost all systems available.
•
5ighly efficient, needs only few minutes to complete whole procedure.
3.( Conclu$ion4
(his chapter Reuire!ent anal#$i$ basically provides the idea about necessary resources required to build proposed system. We select the %5% as our front end and ;y&ql as our back end. It also glanced on constraints that must be resolved in proposed system. )or the simplicity constraints are divided in two parts soft constraint and hard constraints. 7y
resolving all these constraints our software will achieve some significant features, that features also listed in this chapter.
Chapter %
&#$te! De$i'n (his chapter gives an overview of the system in the use case diagram, overview of the activities in the work break down diagram, overview of the working of activities in data flow diagram, and overview of the database in 8 diagram. $.1 5$e ca$e dia'ra! 0s shown in the diagram the #atabase ntry 4perator@#4A is responsible of the system. 5e should be aware of various courses and subBects available in the collegeH he should also know the various rules and regulations of the institution. 5is Bob is as follows •
+ollect teachers' information
•
+ollect students' information
•
Input these information to the system
•
%rovide the output to others
•
;ake necessary modifications
•
;aintain the database for future works
(he #4 must have some basic knowledge about computers. 5e or she must have the skill to properly address the priorities. &chedule tracker will take care of the rest. It will provide teachers view for teachers and subBect view for students.
Figure 4.1: Use case Diagram
$." -or /readown &tructure 0bove is a activity based work breakdown structure. (he diagram shows how we divided the whole process into simpler ones. ach of the process is carried out by various group members. ;ost of the steps are repeated again and again in the life cycle of the proBect.
Figure 4.2: Work Breakdown Structure %.3 Data flow dia'ra!
(he data flow through database is described in following diagram. ach process repDresent the working of user with the interface and followed by its associated operation performed in the database. 5ere open square represents the operation that is perDformed in databases.
Figure 4.3: Data flow Diagram %.% ER dia'ra!
(he database schema is represented by the 8 #iagram. 5ere each boC represent a table. (he table name is given at the top and the fields are given at the bottom. (he bold italics fields are the primary keys used, along with field name its data type and length are given.
•
info table stores general information such as college name, academic year, working hours and days and stores information in its associated fields in database.
•
batches table stores information of the batches such as batch id and name.
•
(eachers table stores information of teachers such as teacher id and name.
•
&ubBects table stores information of subBects such as subBect id, name, working hours
and the number of teachers needed. •
&ubKtea table stores association of subBects and teachers. 5ere the subid is the foreign key associated with the id of the teachers table and the batid refers the id of the batches table.
•
7atKsub table stores association of batches and subBects. 5ere the batid is the foreign key associated with the id of the batches table and the subid refers the id of the subBects
table. •
(imKtab stores the generated schedule and it is associated with all other tables.
Figure 4.4: E Diagram
%.( "ctivit# dia'ra!4
)igure above shows the activity diagram for ogDin. )irst, the lecturers, students and administrator need to log in using the username and password that was created during registration. (he system will validate the username and password. If the password or username is invalid, an error message will be displayed and the lecturer or student or administrator can try to log in again. If log in is successful, the system will identify the user as a lecturer, student or an administrator.
LOGIN
VALIDATE(USER,PASSWORD DISPLAY LOGIN ERROR MESSAGE VALIDATE
!"AILURE#
!SUCCESS#
DISPLAY ADMINISTRATOR MENU (ADMINISTRATOR
(LECTURER/STUDENTS
DISPLAY LECTURER/STUDENT MENU
4.! "#$%&%$' D%"(") F* +*(%,
%.(.1 "CTI=IT DI";R" ,OR IN>5IR CL"&& "="IL"/LE "ND CL"&& /OOIN;
IN$UI RY CLASS AVAILA%LE
READ INPUT DISPLAY SUCCESS RESULT
(AVAILA%LE
%OO&ING CLASS
READ INPUT (SUCCESS
(NOT AVAI LA%LE
(NOT SUCCESS DISPLAY NOT AVAILA%LE CLASS MESSAGE
4.!.1 "#$%&%$' D%"(") F* %,-U%' #+"SS "&"%+"B+E ",D #+"SS B**%,(
)igure above shows the activity diagram for the Inquiry class available for lecturers. (o inquire whether a class is available, the lecturers have to select the class based on the list in the system. 4nce the submit button has been clicked, the system will check the query. If inquiry is successful, the message successful page will be displayed. If fails, a message error will also displayed. (hen if the class is available, lecturer can go to booking class menu to book the class. (he message Lsuccessful bookingM of the class is displayed and if the booking failed the message will also be displayed.
%.(.2 "CTI=IT DI";R" ,OR "DD &5/?ECT OR CL"&&
SELECT MENU ADD CLASS
DISPLAY ERROR MESSAGE READ INPUT
("AILURE (ADD CLASS
READ INPUT
ADD SU%'ECT
(SUCCESS
DISPLAY SUCCESS MESSAGE DISPLAY ERROR MESSAGE ("AILURE (SUCCESS
REGISTER SU%' ECT
4.!.2 "#$%&%$' D%"(") F* "DD SUB/E#$ * #+"SS
0bove figure shows the activity diagram for add subBect and class. 7oth screens are the same. If the administrator wants to add the subBect or the class, he or she has to fill in the form the subBect or the class information. (hen click on the neCt button. 9alidation of the form will be carried out before the data is stored in the database. =pon successful adding the subBect or class, a successful application page will be display. If validation failed, an error message window will pop up.
%.* &E>5ENCE DI";R"
USER/ADMIN
LOGIN
DATA%ASE
) USER NAME/PASSWORD( * ) C+EC& VALIDATION(
, ) VERI"Y USER( - ) MDI SCREEN(
. ) UNSUCCESS"UL VALIDATION(
) UNSUCCESS"UL VALIDATION(
4.0 SE-UE,#E D%"(") F* &"+%D"$%*,
)igure above shows a sequence diagram for the user validation. In order to log in, the lecturer/student/administrator need to key in their username and password. (hen the browser will send the information to the web server and validate the information with the database. &uccessful validation will be sent to the web server, and the server will display the ;ain ;enu page according to the user type. 0s for unsuccessful validation, the server will send an error login page to the monitor.
%.*.1&E>5ENCE DI";R" @"DD TE"C6ERA
ADMINISTRATOR
"RONTEND
DATA%ASE
) RE$UEST ADD "UNCTION(
* ) DISPLAY ADD "UNCTION( ) IN"ORMATION "ILLED(
- ) SENDS "IELD(
. ) DATA VALIDATION SUCCESS"ULLY(
/ ) MESSAGE DATA I S SAVED(
0 ) UNSUCCESS"UL( 1 ) ERROR MESSAGE(
4.0.1SE-UE,#E D%"(") "DD $E"#E
)igure above shows a sequence diagram for 0dding teacher. (he browser will send a request to the web server and it will return the teacher information page. (he teacher will have to fill information form. If validation is successful, the query will be passed to the database and after the data is stored successfully, the message will be displayed. If the form validation failed, a window with the error message will pop out.
%.*.2&E>5ENCE DI";R" @"DD &C6ED5LEA
ADMINISTRATOR
"RONTEND
DATA%ASE
) SELECT COURSE(
* ) SELECT WOR&LOAD( ) ENTER TEAC+ER,ROOM AND COURSE(
- ) SENDS "IELD(
. ) DATA VALIDATION SUCCESS"ULLY(
/ ) MESSAGE SUCCESS"ULLY ADDED(
0 ) UNSUCCESS"UL( 1 ) ERROR MESSAGE(
4.0.2SE-UE,#E D%"(") "DD S#EDU+E
)igure above shows a sequence diagram for adding &chedule. (he browser will send a request to the web server and it will return the information page which include information to be filled related to teacher,subBect, class,labs. 0fter filling these fields it is been send for validation. If validation is successful, the information will be passed to the database and after the data is stored successfully, the message will be displayed. If the page validation failed, a window with the error message will pop out.
Conclu$ion4
(his chapter gives an overview of the system in the use case diagram, overview of the activities in the work break down diagram, overview of the working of activities in data flow diagram, and overview of the database in 8 diagram, overview of the sequence in sequence diagram, overview in steps in 0ctivity diagram.
Chapter (
I!ple!entation (his application has been developed using %5% as front end tool and ;y&< &erver as its back end tool. (he application has been coded to be platform t running on Camp control panel. et beans I# has been chosen as its development environment because of the following features •
#esigning interface for the application has been simpli ed by its drag and drop =I pallet.
•
#ebugging can be easily done using the ogger class.
•
asy database access with et7eans database plugin.
•
&implified automated editor error detection.
•
0utomatic code generation.
•
&implified class factory method lookups.
•
asy to create Bar les using build option.
•
%roBect can be run on debugging mode which provides current state of the variables with the help of break points.
•
et7eans I# has wide help and support on the Camp.
While coding schedule tracker application several constraints related to its computation has been taken into account. &chedule generating problem provides us with various alternatives in the design of the algorithm, interface and the database. 0mong the various designs what we have implemented is detailed below
(.1 Interface I!ple!entation 4
(here are ten classes associated with an interface. (he association are as followsF
ain.cla$$ for login interface 'enerate.cla$$ for basic information interface &ubBects.class for subBect interface Teacher$.cla$$ for teachers interface 7atches.class for batches interface &u0Tea.cla$$ for &ubBect (eacher interface 7at(ea.class for 7atch (eacher interface &el/at.cla$$ for 7atches &election and %riority interface &how(able.class for &chedule
4utput interface &electTa0le.cla$$ for open and save interface Lo'in Interface
nter the ;y&
nter basic information related to collage name, academic year, select working hours from drop down list and select check boCes for working days. (o open saved table click on 4pen (able. &u0Bect Interface
nter the &ubBect I# and &ubBect ame, enter continuous working hours per week, enter the number of teachers needed in subBect and click &ave. (o edit select the &ubBect I# and click &ave. (o remove select the &ubBect I# and click 8emove. Teacher Interface
nter the (eacher I# and (eacher ame and click &ave. (o edit select the (eacher I# and click &ave. (o remove select the (eacher I# and click 8emove. /atch Interface
nter the 7atch I# and 7atch ame and click &ave. (o edit select the 7atch I# and click &ave. (o remove select the 7atch I# and click 8emove. &u0BectTeacher Interface
&elect the &ubBect I# and their respective (eacher I#. +lick the double headed symbol to add or remove from &elected (eachers list. /atch&u0Bect Interface
&elect the 7atch I# and their respective &ubBect I#. +lick the double headed symbol to add or remove from the &elected &ubBects list. /atch &election Interface
&elect the 7atches to be scheduled. +lick the double headed symbol to add or remove from the &elected 7atches list and if necessary set or remove subBects priority for the selected batch. (he priority is set by selecting subBect, day, hour from the drop down list. &chedule Output Interface
&elect 7atch tab to view associated batch schedule. &elect teachers view or subBects view to display schedule in teacher or subBect respectively. (o edit generated list select the period and edit using keyboard. (o save generated schedule click &ave.
&ave Ta0le Interface
nter name to be saved to the database and select save. (o replace an eCisting le or delete a le, use delete and then save the new schedule to the database. (o avoid changes click cancel. Open Ta0le Interface
&elect the name and click the 4pen (able option. (o delete an eCisting le, select the le and click delete. (o go back press cancel.
(.2"l'orith! I!ple!entation 4
&chedule generation is an %D+omplete problemH specifically speaking %D5ard. &o it lacks a proper time bound for eCecution i.e. problems like these often can have many different outputs. &o we assign cost to each output which gives the measure of deviation of the output from the desired one. &o our aim is to get the output with minimum cost if there is one. enetic algorithm can give best results but the time needed for it to compute cannot be determined so we have developed an alternative approach which can be applied to solve most of the %D+omplete problems. )irst determine the various constraints which the output must satisfy. We then categoriEe them as soft and hard constraints.
(hird step is to make a procedure which can generate an output for most of the possible inputs. (he final step is to reduce the cost. (he current working scenarios these can be eCplained as followsF (he rest two steps are eCplained earlier. (he procedure mentioned in the third step here is the generate@A function in the class. What this function does is to assign priorities to teacher, subBect and position. &o that if we arrange schedule according to this priority there is a greater probability to end up in the output which satisfies all the hard constraints. )irst and foremost priority is that of teachers. &ubBect priority and position priority depends on teacher priority, also teacher is the most important resource in the schedule. (he priority of teacher increases if the number of periods he handled increases, also if the
number of batches he is present increases and decreases if an alternative teacher is available. &ubBect priority is also similar to that of teacher priority. It must also increase with the continuous hours needed. &o in the algorithm we have considered subBect which have different consecutive periods need as different subBects. %osition has priority if it correctly placed and the adBacent portions are not that of the same subBect. )inally we need to manually assign priority and optimiEe the table to reduce cost.
(he main logic of our algorithm resides in the generate class. (he gene function in the class reads the various data needed for generation of schedule for current batches from the database creates the table in an 0rray ist and copies it back to the database. (.3 Data0a$e I!ple!entation
In order to incorporate portability we use ;y&< as our backend. It provides many features such as different engines and high end sql commands to create and manipulate database. It also provides tools called ;y&< dump to backup database.
In our proBect as mentioned in the 8 diagram, we use a single database called ttgenerator which contains the above mentioned tables. ngine for table other than info and tim tab are made Inno#7 for foreign key annotation, whereas info and tim tab are made ;yI&0; for easy editing and backup. %rimary keys are properly assigned for each table eCcept the info as to avoid duplicate entries which may later create problems. ven though we designed =I so as to avoid such conditions, still we don't recommend to accessing the database directly. 4ur algorithm assumes that the database entries are correct so any changes may cause problem. (he software when installed rest checks if such a database is available, if not found it automatically creates the necessary tables. (he default engine for window is Inno#7 and that for linuC is ;yI&0; these are properly addressed in our database. &o the user need not worry anything about database creation. We added a feature to save schedule from generated table @tim tabA. It simply copies the data in tim tab to a table with starting name saved. 7esides this, a user can backup other tables or the whole database using mysq ldump command but its procedure differs on different operating systems. ater this backup can be restored.
(.% Conclu$ion4
(his chapter specifically talks about implementation phase of &chedule tracker. While coding schedule tracker application several constraints related to its computation has been taken into account, 0ll this constraints are noted into this chapter.
Chapter *
Te$tin' (esting is an important phase in software lifecycle. (esting improves reliability and 8obustness of the application. (he basic operations to be tested are •
(here should be at least one working day and one working hour
• •
#ifferent inputs must be checked for its range. )or eCample no of hours in morning or evening should be between 3D, total number of periods for a course must be between 3D-3, code for course must be 3D character
•
long. =ser should not be given permission to edit or modify subBects, teachers or batches
•
without releasing its associations 4pening and saving of databases should show eCceptions if they occur @same le
•
should not be used while savingA 7efore generating table it should be checked if all subBects are assigned at least one teacher, no of periods available@@morning hours Jevening hoursANno of daysA must be
•
equal to no of periods assigned. If any problem occurs during generation @due to constraintsA it must be propDerly displayed.
*.1Te$t "pproach
(he system is to be tested at various stages of the proBect developmentF ach user interface is tested individually for its function. Interfaces meant for data input are tested by entering data in the data tables through each interface. &imilarly each data base operation is tested through interfaces. 0ll the user interfaces are Boined in the desired sequence and their back end coding is tested for the desired result. ike previous window close as the neCt desired window opens and each button performs its desired task etc. very class in the Bava code is tested individually with the help of test cases. Whole of the algorithm is tested with sample run of data to generate an optimal
&chedule for the provided database.
*.2Te$t lannin'
;ost of the testing requires checking connectivity of the user interfaces with the database, so a properly designed database is required for testing. #esign interfaces and connect each of them to the database and test them for proper output as is it is in the database.
Inter connect all the user interfaces in the desired sequence. +heck if each of the buttons result in the desired result. #evelop the Bava classes for data retrieval. (est each of them according to test cases. #evelop Bava code for schedule generation. (est the coding with a small database by generating a schedule.
,unctional Te$t Criteria
(he obBective of this test is to ensure that each element of the application meets the functional requirement of the user.
Reuire!ent$ Catalo'ue
4ther functional documents produced during the course of the proBect i.e. resolution to issues/change requests/feedback.
*.3=alidation Te$tin' D which is intensive testing of the new )ront end fields and screensO
Windows =I &tandardsH valid, invalid and limit data inputH screen look and appearance, and overall consistency with the rest of the application.
*.%,unctional te$tin' D these are lowDlevel tests which aim to test the individual processes
and data flows.
*.(Inte'ration Te$tin'
(his test proves that all areas of the system interface with each other correctly and that there are no gaps in the data ow. )inal Integration (est proves that system works as integrated unit when all the Ces are complete.
*.*5$er "cceptance Te$t
(his test, which is planned and eCecuted by the =ser 8epresentative@sA, ensures that the system operates in the manner eCpected, and any supporting material such as procedures, forms etc. are accurate and suitable for the purpose intended. It is high level testing, ensuring that there are no gaps in functionality.
*.7&#$te! Te$t Criteria Entrance Criteria • • • •
0ll developed code must be unit tested. =nit and ink (esting must be completed and signed o by development team. 0ll human resources must be assigned and in place. 0ll test hardware and environments must be in place, and free for &ystem test use.
E+it Criteria4
0ll 5igh %riority errors from &ystem (est must be fiCed and tested.
*.) Te$t ca$e$ and Te$t re$ult$4
4utlined below are the main test types that are performed for this release. 0ll test entries on wrong input has been tested to verify code stability and correctness. (he test cases presented here are based on criteria6s presented above to validate its test implementation. ach test case table list the detailed test case results for each interface and its user inputs that can be assinged by the user to check the correctness of its implematation.
Figure 0..1: +ogin
Figure 0..2: ttgenerator
Figure 0..3: *5en $a6le
Figure 0..4: Su67ect
Figure 0..!: $eac8er
Figure 0..0: Batc8
Figure 0..9: Su67ect$eac8er
Figure 0..9: Batc8 su67ect
Figure 0..;: Batc8 Select
Figure 0..1<: $a6le &iew
Figure 0..11: Sa=e
*.: Conclu$ion4 (o maintain the robustness and to build the user friendly system testing is necessary. (his whole chapter contains the different test cases which we performed on &chedule tracker.
Chapter 7
Re$ult and appendi+
In$tallation anual
•
Install Campp Install mysqlDessentials 4n Windows double click on (imeene.Bar or (imeene.bat 4n inuC run in terminal (imeene.sh or type in terminal Gsh path/(imeene.shG or
•
Gbash path/(imrene.shG nter necessary information6s @described in user interface scenariosA et the desired
• • •
schedule as output
7.1&N"&6OT& 4
7.1.1/R"NC6E& 4
• • • •
&elect the 7ranches. =ser can =iew Edit Delete the particular branch. =ser can 0dd new branch. It also shows the list of branches present in college.
7.1.2ROO&4
• • • •
&elect the class room or labs for particular class. =ser can add the new classroom. It shows the available class room along with their id. =ser can =iew Edit Delete the particular classroom.
7.1.3 TE"C6ER&4
•
0dd teacher along with necessary information like )ull name, u$er na!e pa$$word
•
"'e >ualification "ddre$$ hone nu!0er. (he very special feature we added here is the "vaila0ilit# on li!ited da#$ . 7ased on availability of teacher algorithm creates the appropriate timestamp for that
•
• •
particular teacher. =ser can =iew Edit Delete the particular (eacher. It also shows list of available teachers.
7.1.% &5/?ECT&4
• • • •
0dd subBect for particular semester. =ser can =iew Edit Delete the particular &ubBect. It also shows the list of all subBect. We can also add the particular time duration for each subBect.
7.1.( D"&4
• •
=ser can =iew Edit Delete the particular #ay. It shows all academic days.
7.1.*&LOT&4
7.1.7 /R"NC6E&TE"C6ER&4
• • •
(his is the mapping of particular teacher to particular branch. =ser can =iew Edit Delete the particular branch and teacher. 5ere we can assign particular TE"C6ER TO &5/?ECT and also specified about T6EOR OR R"CTIC"L.
7.1.) LECT5RE&4
• •
(his is the class map showing every information in table. (his class map is rough timetable for department/branches.
7.1.: &ELECT4
•
In T"/LE LECT5RE& tab by selecting particular /R"NC6 we get the particular schedule for that branch.
7.1.19 &C6ED5LE4
Chapter )
Conclu$ion and ,uture -or$
).1Conclu$ion 0utomatic &chedule (racker is a standalone application for generating schedule automatically. It is a great difficult task that to manage many )aculty's and allocating subBects for them at a time manually. &o proposed system will help to overcome this disadvantage. It basic function is to generate the schedule tracker according to the data filled. (he user which has login id and password can login or otherwise he can register himself. 0fter login, he will fill all the details related to the college, labs, teacher, seminar, and proBect and submit the related form. (he user will distribute the subBect among the teacher. (hen he can also view the teacher and subBect load also. 0fter filling the entire data, schedule tracker will generates. (he user can also print the schedule tracker from the website only. 4ur system is very user friendly and it is secure enough.
).2,uture wor$ 4
(ime ene future works may includeF 1.&tudent 8oom &cheduling (his will allow room scheduling for students in particular batches where there are multiple
sections with strong strength. ".Cam &chedule eneration (his will allow teachers/users to develop schedule smoothly when multiple batches is required to hold eCams . !.Cam 8oom &cheduling (his will allow users to schedule rooms for students effectively. $.(ime +onstrain %roblem &ome institute have large campus where travelling time is needed to be considered. .enerating different +hoices of &chedule. 7y eCchanging weeks or periods using enetic 0lgorithm of generated schedule various choice for schedule can be provided. .
