A Minor Project Report on

TIME TABLE MANAGEMENT Bachelor of Engineering Minor Project

Submitted in Partial fulfillment of the Requirement for the award of Bachelor of Engineering in Computer Science & Engineering
Submitted to:

RAJIV GANDHI PROUDYOGIKI VISHWAVIDYALAYA, BHOPAL (M.P.)

By:

Mukesh Kumar Sanodiya

Enroll. No. 0191CS081044 .

Under the Supervision of

Ms . Pr atishtha s Rajesh Boghey

(Asst. Proffesor) TIT Excellence

Singh
HOD Department of C. S. E.

Prof.

DEPARTMENT OF COMPUTER SCIENCE & ENGINEERING

TECHNOCRATS INSTITUTE OF TECHNOLOGY (EXCELLENCE), BHOPAL

To Whom It May Conc ern

This is to certify that the work embodied in this Project entitled Time Table Managementhas been satisfactorily completed by Mr. Mukesh Kumar Sanodiya. It is a bonafied piece of work, carried out under my supervision and guidance in the Department of Computer Science & Engineering, Technocrates Institute of Technology(Excellence), Bhopal, for partial fulfillment of the degree Bachelor of Engineering in Computer Science & Engineering during the academic year 2010-2011. We wish them every success in life Guided by:

Mis .Prati shtha Singh s Rajesh Boghey

(Asst. Proffesor) Department of C. S. E.

Prof.
Head of Department of C. S. E.

Forwarded by:

Dr. C.K. Teckchandani

Director
2

TECHNOCRATS INSTITUTE OF TECHNOLOGY (EXCELLENCE), BHOPAL

TECHNOCRATS INSTITUTE OF TECHNOLOGY (EXCELLENCE) BHOPAL

DECLARATION
We, Mukesh Kumar Sanodiya student of Bachelor of Engineering, Computer science Branch, Technocrats Institute of technology (Excellence), Bhopal hereby declare that the work presented in this Minor project entitled Time Table Management is outcome of our own work, is bonafide, correct to the best of my knowledge and this work has been carried out taking care of Engineering Ethics. The work presented does not infringe any patented work and has not been submitted to any University for the award of any degree or professional diploma.
Name Mukesh Kumar Sanodiya
3

Enroll. No. 0191cs081044

Signature

Place: Bhopal Date: June 04, 2011

CERTIFICATE OF APP ROVAL

The foregoing project is hereby approved as a creditable study of an engineering subject carried out and presented in a manner satisfactory to warrant its acceptance as a prerequisite to the degree for which it has been submitted. It is understood that by this approval the undersigned do not necessarily endorse or approve any statement made, opinion expressed or conclusion drawn therein , but approve the project only for the purpose for which it has been submitted.

(INTERNAL EXAMINER)
Date:

(EXTERNAL EXAMINER)
Date:

ACKNOWLED GEMENT
Thanks GOD for giving me knowledge and abili ty to complete this work in this final form. The satisfaction that acc om pani es the succes s in completion of any task would be incomplete without mentioning the pe ople who made it possible, whose con stant guidance and encouragement crowned our eff ort with success . I feel pleasure in conveying my profound thanks to my Thesis guide, Miss. Prat ishtha Singh (Ass t. Proffesor) TIT Excellence, for his con stant Supp ort, valuable Guidance and Encouragement. During the entire course of this project he reviewed with gr eat es t care and his inno vat ive ide as led to the succe ssful completion of this wor k. His con tinuous strong and encouragement had some very profound effec t on me that went be yond scientific supervision. I have bee n able to success fully complete this Proj ect bec ause of excellent guidance and infinite help given to me by my HOD Prof. Rajesh Bo ghey Head Dep artment of CS E. It is difficult to acknowledge ade quat ely the help and encouragement I rece ived from them but I take this opp or tuni ty to thanks them profusely. I wish to thank Dr. C.K. Teckchandani, Dir ector Technocrates Institute of Technology (Excellence),, Bho pal for his con stant supp ort and encouragement. I am thankful to all other faculty membe rs and all com put er centre staff in Dep artment of CSE for their cooperation extended during the proj ect work. I am also thankful to my coll eagues and classmates who h elpe d me directly or indirectly thro ugh out my proj ect work.

Muke sh Kumar Sanodiya

Enrollment No: 0191cs081044 B. E. (CSE) Techn ocrats Institute of Techn ology (Excellenc e)

ABSTRACT
Time Table Management system is an automated system which genets time table according to the data given by the user. The main requirement of the application is to provide the details about the branch, subjects, no. of labs, total no. of period and details about the lab assistance. Then the application generates the time table according to your need. 1.Timetable creation for each semester has always been an error-prone task, nor2.mally resulting in multiple iterations of creation and proof-reading. Changes 3.desired by teaching sta , changes of course locations etc. also require an adap4.tation of the previously created timetables. This project aims to alleviate the 5.pain of this process by automatically generating timetables for selected courses 6.from the UIBK course database. A side-e ect of this is of course that students 7.can themselves generate personal timetables. A further problem at the Insti8.tute of Computer Science was the tracking of exams for all courses o ered by 9.the Institute. In the course of this project, a small script was written to hook 10.into the CMS used on the Institute's website to automatically get exam dates 11.from the University's course database.
6

 The basic project is to create a Time Table Management System.

To create Databases of different entities involved in this process. Maintaining database-containing information about the various semesters, subjects, Labs, teachers etc.

Table of contents :
Chapter 1 Chapter 2 Chapter 3
3.1 3.2 3.3

Introduction8 SRS...10 System Documentation.15

Flowchart15 Data Flow Diagram16 Entity Relationship Diagram.. .21

Chapter 4
4.1 4.2 4.3 4.4 4.5

Problem Description23
Product Perspective.23 Objective...23 Terminology used ................................24 Scope.33 Benefits.34

Chapter 5. Report.35

Feasibili ty

5.1 Technical Feasibility..35 5.2 Economical Feasibility..35 5.3 Legal Feasibility36 7

5.4 Operational Feasibility.36 5.5 Schudle Feasibility36

Chapter 6
6.1 6.2 6.3

System Design and Development..37

Design Pattern37 Requirements..38 Screenshots .....39

Chapter 7

Testing44
7.1 Code

Testing.45
7.2 Specification Testing.. 45

Chapter 8. Chapter 9 Chapter 10. Chapter 11. Chapter 12.

System Implemention46 Discussion.47 Lmitation48 Future Work.48 Bibliography..49

1. INTRODUCTION
The Problem is to Manage th e Time Table of the all class of the

college acc ording to teacher, and th e Purp os e of Manage Timetable of the Coll ege is, for any Coll ege Teache r timetable sche duling is a ve ry arduous and time-consum ing task. Coll ege Ti metable managem ent table. Time table managem ent breaks in betw een modu le or ganizes classes and subject the cam pus modu le tim e wee k, he lps you to gene rate class tim table as well cam us and teacher e p holidays,

teache r. Ti metable Ti metable for

Management

module aut omatically creates

your Campus

classes, class teachers and student s. This module also allo ws you to gene rate tem or ary timetables. p

Class -Teache r Timetabling - This problem is normally ass ociate d with Engine ering Coll ege whe re the studen ts are schedu led as a class. All students in the same class take exact ly the same/different set of courses. Typically, teache rs and class es are bu sy most of the day, and the problem is to find tim when each teacher can m es eet with his/her requ ired class es with no conflicts We have decided to inv estigate the use of a T metable Management i Syste m. This system would be used by membe rs who may be students or profess ors/Teache rs of that Coll ege to che ck and u pdate the Ti metable of the Classes of Coll ege. The purpose of this document is to analyze and elaborate on the high-level nee ds and features of the Ti metable Management Sy stem . It focu ses on the capabilities and facili ties provided by a Ti me table of Class . The details of wh at all are the needs of the T metable i Management Sy stem and if it fulfils the se nee ds ar e detailed in the use-case and supplement ary specifications.

Technology makes lifestyle easier by providing better support to different systems, better accuracy, better security options, easier maintenance, etc. Now a days technology eventually means computers which is the greatest achievements of last century. Day by day computers are being more and more popular because of its features like ease of work, ease of learning, greater accuracy with the least time consumption and the last but not the least i.e. ease of maintenance with cost effectiveness. So as a part of these ongoing evolutionary approach traditional systems are being computerized to make them more fruitful than ever.

2. SOFTWARE REQUIREMENT SPECIFICATION

Purpose The purpose of is to So ftw are describe Sy stem . the Requirements the external Requirements ope rations, requ irem ents Speci fica tion behavior of the Specification inte rfaces, of It the also

(SRS) document define s pe rfor mance, nonfunc tional

T metable Management i and

and d escribes Sy stem .

quality assurance

T metable Management i

The docum ent

also describes the

requ irem ents

such as the user inte rfaces.

describes the design constraints that ar e to be 10

considered when requ irem ents for

the system is to be designe d, and other the softw are. The Softw are

factors

nece ssa ry to provide a complete and comprehe nsive description of the Requirements for for Specification (SR S) captu res the complete softw are requ irem ents docum ent Scope Describe the scope of the softw are app lication to be produc ed.Within the description ident ify the softw are produc t, describe its func tionality, and app lications of the softw are. Inc lude any description of the bene fits, objectives, and goals of the software. are derived from the Vision Do cum ent prep ared

the system or a por tion of the system Requirements described in this , . Timetable Management Syste m.

User Characteristics
Ident ify each type of user of the softw are by funct ion, location, and type of device. Spec ify the number and the nature of the ir use of the of users in each group system . Describe the

characte ristics and inte ractions of the users that will inte ract with the softw are during the ph ases of the softw are life cycle. System State/Assumptions, Depen den cies and Constraints

Assumption s
Describe assum ions made that can affect the requ irem pt ents of the SRS. Ass um ptions are f act or s that are believe to be true during the life cycle of the project, that if ch anged may affect the outc om of the project. e

Dependencies
Describe each depen dency and cont rol of the project that can affect the and m st remain u requirements true for the specified in the SRS. Dependenc ies are out side of the scope project to suc cee d.

11

Con strai nts

Describe factor s that limit the scope and func tionality of the softw are. Constraints ar e requ irem ents softw are solut ion. that are imposed on the

12.NEED As we discussed earlier that manual maintenance of a Time Table Management System is a tedious job. So to enhance the ease of working we go for this package. Manual maintenance of databases of items, time table processing is a time taking process and somehow erroneous. To give more accuracy to the system i.e. rather going manual modification we involve computer for accuracy. The least but most important it saves time. Objectives of the package Create a Time Table Management System to be used by any College. To perform the basic requirements of the firm. Maintaining databases of subject, Class, semesters details.

Scopes and boundaries of the package As it is a computer-based package so maintenance and working As it is not possible to associate each and every requirement of

is somewhat difficult from manual mode of approach. the system so in some way or other it will going to create problem at some stage of execution (like report generation).
12

As a computer based System it is easier to fetch data from the

database for unsocial activities. Also easier to destroy the existing ones.
Fun ction al Requirements The func tional requ irem ents that must take place within the to p roce ss and gene rate sect ions should be customized to softw are to proce ss inputs Func tional for and cont ain the information nece ssa ry to define the fun damental actions out put s. requ irem ents

should inc lude specific requ irem ents describe and document In the build requ irem ents the docum ented func tional requ irem ent softw are in the

busine ss rules, wh ich

the steps in a busine ss process . subsect ions, specify all software Each func tional requirement

to a level of detail sufficient to enable the developer to app lication. requ irem ents sect ions m st have a un ique u

ident ifier for requ irem ents importanc e and/o r stability.

traceability and should be ranked for

Busi ness Require ments

Describe all requ irem ents requ irem ents from a busine ss pe rspect ive. Busine ss are the parts of the fully define d busine ss process

that will be aut omated by the software.

Non Fun ction al Require ments

The Non func tional requ irem ents sect ions should be customized to cont ain the information ne cessa ry to define the fun damental act ions that m st take place within the so ftw are to proce ss and u gene rate its result. N on Func tional requ irem ents specific requ irem ents document for the steps in a busine ss process . should inc lude busine ss rules, wh ich describe and

Logical D ta Require ments a

Describe the logical data requ irem ents for the system.

13

User Require ments

Describe the user requ irem ent s; these should captu re the inte nded behavior of the hu man inte rface of the app lication.

Over all Description

1.

In few minute s, the pro gram gene rates a complete timetable that fulfills all your requ irem ent s. The program follows all psycho hy gienic and organizational requ irem ents such as:

2.

Selection for Number of wor king days of the week (ex. Saturday off)

3. 4.

Ze ro (atten dance) period insertion Periods per day selection .This selection is day wise ex. Can be made 4 periods on Saturday etc.)

5. Subjects could be en tered considering 6. Hard subjects in f irst 4 or 5 periods 7. Subject in wh ich classroo m 8. Singl e or double du ration consecut ively 9. Periods per week per subject 10. Type of subject ( Hard, easy) 11 . Subjects distribute d even ly for ent ire we ek

14

3. System Document

15 1

3.1FlowChart

16 1

3.2 DATA FLOW DIAGRAM

1 17

Data Flow Diagram is a diagrammatic representation of data movement through a system manual or automated - from inputs to outputs through processing. The data flow diagrams help in the analysis of the flow of data through a system and thus help in identifying the system requirements. These are of two types Logical Data Flow Diagrams and Physical Data Flow Diagrams. The Data Flow Diagram (DFD) clarifies system requirements and identifies major transformations that will become programs in system design. It is the starting point of system design that decomposes the requirements specifications down to the lowest level of detail. Logical Data Flow Diagrams The Logical Data Flow Diagrams represent the transformation of the data from input to output through processing logically and independently of the physical components that may be associated with the system. Physical Data Flow Diagrams The Physical Dataflow Diagrams show the actual implementation and movement of data between people, departments, and workstations. Each component of a DFD is labeled with a descriptive name. Process names are further numbered that will be used for identification purposes. The number assigned to a specific process does not correspond to the sequence of processes. It is strictly for identification purposes. A data flow diagram allows parallel activities i.e. a number of data-flows coming out from the source and going into the destination. A DFD concentrates on the data moving through the system and not on the devices or equipments. A DFD may consist of a number of levels. The top-level diagram is called the Context Diagram, which
18

consists of a single process and plays a very important role in studying the system. It gives the most general and broadest view of the system. Move over it gives the pictorial representation of the scope boundaries of the system under study. NOTATIONS:
Data-Flows show the movement of data in a specific direction from the

source to the destination. It represents a packet of data.

Processes show the operations performed on the data, which transform it

from input to output.

Sources and Destinations of data are the external sources and destinations of

data, which may be people, programs, organizations or other entities interacting with the system, but are outside its boundary.

Data Stores are places where data are stored such as files and tables.

Below is the top level DFD showing how the Users request processed by the server with database interaction and sends the response back to the user. Feasibility Study

19

All projects are feasible when given unlimited resources and infinite time! But the development of computer-based system is likely to be played by scarcity of resources and difficulty in completion dates. The feasibility of a computer-based system can be studied in three major areas: Economic Feasibility Technical Feasibility Functional Feasibility Economic Feasibility An evaluation of development cost weighed against the ultimate income of benefit derived from the developed system. Very important information contained in the feasibility study is that it takes care of the cost benefit analysis, which is the assessment of the economic justification for a computer based system project. The system is very user friendly and only common terms are used in the application and so it will not be difficult for the end-user in handling the system. The system provides a very guidance for every step to follow while using. Technical Feasibility A study of function, performance and constraints that may affect the ability to achieve an acceptable system. The analyst evaluates the technical merits of the system, while at the same time collects additional information about performance, reliability and maintainability end products. Technology is not a constraint to system development. The latest technologies are incorporated so as to achieve the best of these new developments on the system.
20

The systems developed fully generalize, so that any future expansion will not be a problem. Functional Feasibility: The system will be acceptable to the users who will be helped greatly by the system, further the involvement of the user in each part of the development will be helpful in increasing its success factor. The current existing system is less interactive and not up to the mark in terms of customer support. From all these, we can conclude that this system is economically, technically and functionally feasible. Project Approval Those projects that are both feasible and desirable should be put into a schedule. After a project request is approved, its cost, priority, completion time and personal requirement are estimated and used to determine where to add it to an existing list. DATA FLOW DIAGRAM
Context Level Diagram
Time Table Management

Administrator

Time Table

0.0

21

First Level DFD Admin Admin

Master Entry 1.0

Reporting 2.0

Report

DataStore

DataStore

Second Level DFD Admin Admin

Branch Master 1.1

Subject Master 1.2

Branch Master

Subject Master

Admin Admin

Admin

Period MasLtearb 1M.3aster 1.4

Teacher Master 22 Period MLaabstMer aster

1.5

Teacher

3.3 E-R Diagrams

The relation upon the system is structure through a conceptual ER-Diagram, which not only specifics the existential entities but also the standard relations through which the system exists and the cardinalities that are necessary for the system state to continue. The entity Relationship Diagram (ERD) depicts the relationship between the data objects. The ERD is the notation that is used to conduct the date modeling activity the attributes of each data object noted is the ERD can be described resign a data object descriptions. The set of primary components that are identified by the ERD are Data object Relationships Attributes Various types of indicators

23

24

4. PROBLEM DISCRIPTION
4.1 Pro duct Perspective
Th e rest of this document contains the follow ing in the

mentioned order: 1- Ove rall description of the project and its requirements. 2- Speci fic the requirements for the project includi ng fun ctionality, usability, reliabil ity, pe rformance,

security, safety, design constraints, and copy right and intellectual properties.

4.2 OBJECTIVE To utilize my knowledge and technical skills along with a dedicated desire of learning more and more, to benefit my organization and attain consistent professional growth. I want to equip myself with in-depth practical knowledge and technical skills in the field of computer science, and to design something different, something new.
Create a Time Table Management System to be used by any College. To perform the basic requirements of the firm. Maintaining databases of subject, Class, semesters details.

25

4.3 TECHNOLOGY DESCRIPTION:4.3.1 C++:This overview of C++ presents the key design, programming, and language-technical concepts using examples to give the reader a feel for the language. C++ is a general-purpose programming language with a bias towards systems programming that supports efficient low-level computation, data abstraction, object-oriented programming, and generic programming. 4.3.2 Introduction and Overview
The C++ programming language provides a model of memory and computation that closely matches that of most computers. In addition, it provides powerful and flexible mechanisms for abstraction; that is, language constructs that allow the programmer to introduce and use new types of objects that match the concepts of an application. Thus, C++ supports styles of programming that rely on fairly direct manipulation of hardware resources to deliver a high degree of efficiency plus higher-level styles of programming that rely on user-defined types to provide a model of data and computation that is closer to a humans view of the task being performed by a computer. These higher-level styles of programming are often called data abstraction, object-oriented programming, and generic programming. This paper is organized around the main programming styles directly supported by C++:
26

2 The Design and Evolution of C++ describes the aims of C++ and the principles that guided its evolution. 3 The C Programming Model presents the C subset of C++ and other C++ facilities supporting traditional systems-programming styles. 4 The C++ Abstraction Mechanisms introduces C++s class concept and its use for defining new types that can be used exactly as built-in types, shows how abstract classes can be used to provide interfaces to objects of a variety of types, describes the use of class hierarchies in object-oriented programming, and presents templates in support of generic programming. 5 Large-Scale Programming describes namespaces and exception handling provided to ease the composition of programs out of separate parts. 6 The C++ Standard Library presents standard facilities such as I/O streams, strings, containers (e.g. v ve ec ct to or r, l li is st t, and m ma ap p), generic algorithms (e.g. s so or rt t(), f fi in nd d(), f fo or r_ _e ea ac ch h()) and support for numeric computation. To round off, a brief overview of some of the tasks that C++ has been used for and some suggestions for further reading are given.

4.3.3 The Design and Evolution of C++

C++ was designed and implemented by Bjarne Stroustrup (the author of this article) at AT&T Bell Laboratories to combine the organizational and design strengths of Simula with Cs facilities for systems programming. The initial version of C++, called C with Classes [Stroustrup,1980], was first used in 1980; it supported traditional system programming techniques (3) and data abstraction (4.1). The basic facilities for object-oriented programming (4.2-4.3) were added
27

in 1983 and object-oriented design and programming techniques were gradually introduced into the C++ community. The language was first made commercially available in 1985 [Stroustrup,1986] [Stroustrup,1986b]. Facilities for generic programming (4.4) were added to the language in the 1987-1989 time frame [Ellis,1990] [Stroustrup,1991]. As the result of widespread use and the appearance of several independentlydeveloped C++- 2 implementations, formal standardization of C++ started in 1990 under the auspices of the American National Standards Institute, ANSI, and later the International Standards Organization, ISO, leading to an international standard in 1998 [C++,1998]. During the period of standardization the standards committee acted as an important focus for the C++ community and its draft standards acted as interim definitions of the language. As an active member of the standards committee, I was a key participant in the further evolution of C++. Standard C++ is a better approximation to my ideals for C++ than were earlier versions. The design and evolution of C++ is documented in [Stroustrup,1994] [Stroustrup,1996] and [Stroustrup,1997b]. The language as it is defined at the end of the standardization process and the key design and programming techniques it directly supports are presented in [Stroustrup,1997].

28

4.3.4 C++ Design Aims

C++ was designed to deliver the flexibility and efficiency of C for systems programming together with Simulas facilities for program organization (usually referred to as object-oriented programming). Great care was taken that the higher-level programming techniques from Simula could be applied to the systems programming domain. That is, the abstraction mechanisms provided by C++ were specifically designed to be applicable to programming tasks that demanded the highest degree of efficiency and flexibility. These aims can be summarized: _ _ Aims:

C++ makes programming more enjoyable for serious programmers. C++ is a general-purpose programming language that is a better C supports data abstraction supports object-oriented programming _ supports generic programming Support for generic programming emerged late as an explicit goal. During most of the evolution of C++, I presented generic programming styles and the language features that support them (4.4) under the heading of data abstraction.
29

4.3.5 Design Principles

In [Stroustrup,1994], the design rules for C++ are listed under the headings General rules, Design-support rules, Language-technical rules, and Low-level programming support rules: _ _ General rules:

C++s evolution must be driven by real problems. C++ is a language, not a complete system. Dont get involved in a sterile quest for perfection. C++ must be useful now. Every feature must have a reasonably obvious implementation. Always provide a transition path. Provide comprehensive support for each supported style. _ Dont try to force Note the emphasis on immediate utility in real-world applications and the respect for the skills and preferences of programmers implied by the last three points. From the start, C++ was aimed at programmers engaged in demanding real-world projects. Perfection was considered unattainable because needs, backgrounds, and problems vary too much among C++ users. Also, notions of perfection change significantly over the lifespan of a general-purpose programming language. Thus, feedback from user and implementer experience is essential in the evolution of a language.- 3 _
30

people.

Design-support

rules:

Support sound design notions. Provide facilities for program organization. Say what you mean. All features must be affordable. It is more important to allow a useful feature than to prevent every misuse. _ Support composition of software from separately developed parts. The aim of C++ was to improve the quality of programs produced by making better design and programming techniques simpler to use and affordable. Most of these techniques have their root in Simula [Dahl,1970] [Dahl,1972] [Birtwistle,1979] and are usually discussed under the labels of object-oriented programming and object-oriented design. However, the aim was always to support a range of design and programming styles. This contrasts to a view of language design that tries to channel all system building into a single heavily supported and enforced style (paradigm). Language-technical rules:

No implicit violations of the static type system. Provide as good support for user-defined types as for built-in types. Locality is good. Avoid order dependencies.
31

If in doubt, pick the variant of a feature that is easiest to teach. Syntax matters (often in perverse ways). Preprocessor usage should be eliminated. These rules must be considered in the context created of the more general aims. In particular, the desire for a high degree of C compatibility, uncompromising efficiency, and immediate realworld utility counteracts desires for complete type safety, complete generality, and abstract beauty. From Simula, C++ borrowed the notion of user-defined types (classes, 4.1) and hierarchies of classes (4.3). However, in Simula and many similar languages there are fundamental differences in the support provided for user-defined types and for built-in types. For example, Simula does not allow objects of userdefined types to be allocated on the stack and addressed directly. Instead, all class objects must be allocated in dynamic memory and accessed through pointers (called references in Simula). Conversely, builtin types can be genuinely local (stack-frame allocated), cannot be allocated in dynamic memory, and cannot be referred to by pointers. This difference in treatment of built-in types and userdefined types had serious efficiency implications. For example, when represented as a reference to an object allocated in dynamic memory, a user-defined type such as c co om mp pl le ex x (4.1) incurs overheads in run-time and space that were deemed unacceptable for the kind of applications for which C++ was intended. Also, the difference in style
32

of usage would preclude uniform treatment of semantically similar types in generic programming (4.4). When maintaining a large program, a programmer must invariably make changes based of incomplete knowledge and looking at only a small part of the code. Consequently, C++ provides classes (4), namespaces (5.2), and access control (4.1) to help localize design decisions. Some order dependencies are unavoidable in a language designed for one-pass compilation. For example, in C++ a variable or a function cannot be used before it has been declared. However, the rules for class member names and the rules for overload resolution were made independent of declaration order to minimize confusion and error. _ _ Low-level programming support rules:

Use traditional (dumb) linkers. No gratuitous incompatibilities with C. Leave no room for a lower-level language below C++ (except assembler). What you dont use, you dont pay for (zero-overhead rule). _ If C++ was designed to be source-and-link compatible with C wherever this did not seriously interfere with in doubt, provide means for manual control. - 4

33

C++s support for strong type checking. Except for minor details, C++ has C [Kernighan,1978] [Kernighan,1988] as a subset. Being C-compatible ensured that C++ programmers immediately had a complete language and toolset available. It was also important that high-quality educational materials were available for C, and that C compatibility gave the C++ programmer direct and efficient access to a multitude of libraries. At the time when the decision to base C++ on C was made, C wasnt as prominent as it later became and language popularity was a minor concern compared to the flexibility and basic efficiency offered by C. However, C compatibility also leaves C++ with some syntactic and semantic quirks. For example, the C declarator syntax is far from elegant and the rules for implicit conversions among built-in types are chaotic. It is also a problem that many programmers migrate from C to C++ without appreciating that radical improvements in code quality are only achieved by similarly radical changes to programming styles.

4.3.6 The C Programming Model

A fundamental property of computers in widespread use has remained remarkably constant: Memory is a sequence of words or bytes, indexed by integers called addresses. Modern machines say, designed during the last 20 years have in addition tended to support directly the notion of a function call stack. Furthermore, all popular machines have some important facilities such as input-output that do not fit well into
34

the conventional byte- or word-oriented model of memory or computation. These facilities may require special machine instructions or access to memory locations with peculiar semantics. Either way, from a higher-level language point of view, the use of these facilities is messy and machine-architecture-specific. C is by far the most successful language providing the programmer with a programming model that closely matches the machine model. C provides language-level and machinearchitecture-independent notions that directly map to the key hardware notions: characters for using bytes, integers for using words, pointers for using the addressing mechanisms, functions for program abstraction, and an absence of constraining language features so that the programmer can manipulate the inevitable messy hardware-specific details. The net effect has been that C is relatively easy to learn and use in areas where some knowledge of the real machine is a benefit. Moreover, C is easy enough to implement that it has become almost universally available.

4.4 SCOPE:Scope is the largest region of program text in which a name can potentially be used without qualification to refer to an entity; that is, the largest region in which the name potentially is valid. Broadly speaking, scope is the general context used to differentiate the meanings of entity names. The rules for scope combined with those for name resolution enable the compiler to determine whether a reference to an identifier is legal at a given point in a file. The scope of a declaration and the visibility of an identifier can mean the same thing, but they are not necessarily the same. Scope is the mechanism by which it is
35

possible to limit the visibility of declarations in a program. The visibility of an identifier is that region of program text from which the object associated with the identifier can be legally accessed. Scope can exceed visibility, but visibility cannot exceed scope. Scope exceeds visibility when a duplicate identifier is used in an inner declarative region, thereby hiding the object declared in the outer declarative region. The original identifier cannot be used to access the first object until the scope of the duplicate identifier (the lifetime of the second object) has end

4.5 BENEFIT:C++ is used by hundreds of thousands of programmers in essentially every application domain. This use is supported by about a dozen independent implementations, hundreds of libraries, hundreds of textbooks, several technical journals, many conferences, and innumerable consultants. Training and education at a variety of levels are widely available.

than that On implementing this package the farm will get error This package would limit the time and money factor involve in Maintenance is much easier and accurate than the existing Security features are somewhat higher of manual approach.

free data to analyze.

Time Table Management System. manual system.

36

5.FEASIBILITY REPORT
5.1 Technology and system feasibility
The assessment is based on an outline design of system requirements in terms of Input, Processes, Output, Fields, Programs, and Procedures. This can be quantified in terms of volumes of data, trends, frequency of updating, etc. in order to estimate whether the new system will perform adequately or not. Technological feasibility is carried out to determine whether the company has the capability, in terms of software, hardware, personnel and expertise, to handle the completion of the project. When writing a feasibility report the following should be taken to consideration:

A brief description of the business The part of the business being examined The human and economic factor The possible solutions to the problems

At this level, the concern is whether the proposal is both technically and legally feasible (assuming moderate cost).

5.2 Economic feasibility

Economic analysis is the most frequently used method for evaluating the effectiveness of a new system. More commonly known ascost/benefit analysis, the procedure is to determine the benefits and savings that are expected from a candidate system and compare them with costs. If benefits outweigh costs, then the decision is made to design and implement the system. An entrepreneur must accurately weigh the cost versus benefits before taking an action. Cost-based study: It is important to identify cost and benefit factors, which can be categorized as follows: 1. Development costs; and 2. Operating costs. This is an analysis of the costs to be incurred in the system and the benefits derivable out of the system.

37

Time-based study: This is an analysis of the time required to achieve a return on investments. The future value of a project is also a factor.

5.3 Legal feasibility

Determines whether the proposed system conflicts with legal requirements, e.g. a data processing system must comply with the local Data Protection Acts.

5.4 Operational feasibility

Operational feasibility is a measure of how well a proposed system solves the problems, and takes advantage of the opportunities identified during scope definition and how it satisfies the requirements identified in the requirements analysis phase of system development.

5.5 Schedule feasibility

A project will fail if it takes too long to be completed before it is useful. Typically this means estimating how long the system will take to develop, and if it can be completed in a given time period using some methods like payback period. Schedule feasibility is a measure of how reasonable the project timetable is. Given our technical expertise, are the project deadlines reasonable? Some projects are initiated with specific deadlines. You need to determine whether the deadlines are mandatory or desirable. Design: The goal of the design phase is to transform the requirements specified in the SRS document into a structure that is suitable for implementing in some programming language. In this phase we followed Object-oriented design (OOD) approach. In this technique, various objects that occur in the problem domain and solution domain are first identified and then the different relationships exists among those objects are identified.

38

6.SYSTEM DESIGN & DEVELOPMENT 6.1 Design Pattern Used:

DAO (Data Access Object) Model DTO (Data Transaction Object) Model

Data Access & Data Transfer Object Model:

The Data Access Object (or DAO) pattern: resource's client Separates a data interface from its data access mechanisms Adapts a specific data resource's access API to a generic client interface

The DAO pattern allows data access mechanisms to change independently of the code that uses the data.

DAO FACTORY

BUSINESS OBJECT

DATA ACCESS OBJECT

DATA SOURC E

DATA TRANSFER OBJECT

The DAO design pattern is another abstraction layer over the persistence mechanism of the application. The application deals
39

with Data Access Objects and Data Transfer Objects (DTO) rather than directly calling the driver. Changing the persistence method at a later date doesn't require the application code to change, only adding a new set of DAOs. Using DAO in the web application allows more concentration on the data access rather than on the mechanics of how the data is stored and retrieved. The standardization provided by this new layer also makes it easier to automatically generate the Java code necessary to access the database. Most Jcalls are very repetitive and time consuming. Using a DAO Generator is a good way to eliminate that work and make the application development faster

6.2 REQUIRMENTS:Hardware configuration Main processor Hard disk capacity Software configuration Operating system Programming specification Integrated Development C & C++ graphics : Windows (2000, ME, NT, XP) : C++ : Pentium IV : 40 GB

Random access memory : 256 MB

40

6.3 SCREENSHOTS: MENU BAR

41

42

43

44

7. TESTING
45

Testing is the one step in the software engineering process that could be viewed as destructive rather than constructive. Testing requires that the developer discard preconceived notions of the correctness of the software just developed and overcome a conflict of interest that occurs when errors are uncovered. If testing is conducted successfully, it uncovers errors in the software. As a secondary benefit, testing demonstrates that software functions appear to be working according to the specification. Testing provides a good indication of software reliability and some indication of software quality as a whole. Testing cannot show the absence of defects, it can only show that software defects are present. As the developed software does not fulfill all the requirements of an organization, so it is not possible to test with real time data. Still then we tried our best to test each individual module and also as an integrated modules (as a whole) with sufficient data that may an organization have, fulfilling the objective of our Time Table Management System. Testing performs a very critical role for quality assurance and ensuring the reliability of the software. During testing, the program to be tested is executed with a set of test cases and output of the program for the test cases and output of the program for the test case is evaluated to determine if the program is performing as it is expected to. Hence Testing is the process of executing a program with the intention of finding errors. A good test case is the one that has a high probability of finding as yet undiscovered error. A successful test is one yet uncovers as yet undiscovered errors. Testing is performed according to two different strategies:
.7.1

Code Testing:

46

The code testing strategy examines the logic of program i.e. the analyst develops test cases that results in executing every instruction in the program. Basically during code testing every path through the program is tested.

7.2 Specification Testing:

To perform specification testing the analyst examines the specification starting what the program should do and how it should perform under various conditions. Then test cases are developed for each .In order to find which strategies to follow, levels of testing should be followed Levels of Testing The basic levels are unit testing, integration testing, system testing and acceptance testing. These different levels of testing attempt to detect different types of faults. The different levels of testing are as follows: 7.2.1 Unit Testing: In this testing different modules are tested against specification produced during design of the modules. Unit testing is essential for verification of code produced during the coding phase and hence its main goal is to test internal logic modules. 7.2.2 Integration Testing: In this testing tested modules are combined into subsystems which are then tested. The goal here is to see if the modules can be indicated properly and emphasis is being on testing interfaces between modules. 7.2.3 System testing: In this testing the entire software system is tested. The reference document for this process is the requirements document and the goal is to see if the system meets its requirements. This is normally performing on realistic data of the client to demonstrate for the software is working satisfactorily. Testing here focus on external behavior of the system.

8. System Implementation
47

Implementation is the stage of the project when the theoretical design turned into a working system. At this stage the main workload, the up heal and the major impact on the existing practices shift to user department. If the implementation stage is not carefully planned and controlled, it can cause chaos. Thus it can be considered to be the most crucial stage in achieving a new successful system and in giving the users confidence that the users confidence that the new system will work and be effective. The implementation view of software requirements presents the real worlds manifestation of processing functions and information structures. In some cases a physical representation is developed as the first step in software design. However most computer-based systems are specified in a manner that dictates accommodation of certain implementation details. Implementation involves careful planning, investigation of current system and constraints on implementation, design of methods to achieve the changeover, training of staff in the changeover procedures and evaluation of changeover methods. The first task is the implementation planning i.e. deciding the methods and time scale to be adopted. Once the planning has been completed, the major effort in the computer department is to ensure that the programs in the system are working properly. At the same time the user department must concentrate on training user staff. What the staffs have been trained, a full system test can be carried out, involving both the computer and clerical procedures. The main steps of implementation includes 1. Installing client machine.
48

2. Installing the software on the server. 3. Training the operational staff. Requirements keep changing with time so the implementation of this project may change with time hence implementation is an ongoing process, which may change in future.

9. DISCUSSION
As we discussed earlier during project time does not permit to complete the entire project, so as a part of the whole is being carried out and being submitted as the project in our curriculum. Total software along with extensive features will be submitted as Major project, here is the entire Time Table Management System with extensive features fulfilling the requirements of any modern distribution farms. Although we have attempted to make the entire package full proof of errors, it may have some inherent bugs (beyond out knowledge) as it is yet to being tested with real time data. Lastly, we will carry our effort in developing the software fulfilling the basic requirements of any distributing farm, if time permits. We do believe that the system will satisfy the basics and will prove to be user friendly and effective software whenever its being implemented in the organization.

10. LIMITATION

49

. IT is not show the complete time table on a single table .IT is only faculty name check

11 .FUTURE WORK:
It is use to future in save the more time of college /school This software use to future easy to allocate faculty and maintain is simple It simple to use

12. Conclusions
Since conferences usually confront attendees with a large amount of information, we tried to make this more manageable by creating a generic tool-set. Our Conference TimeTable Management (CTTM) system provides all the features that we believe will make conference time-tables more easy to manage for attendees as well as for organizers. The platform requirements are rather moderate, but also create some limits to the number of users that can be managed reasonably

13. BIBLIOGRAPHY:

FOR C++ PROGRAMMING www.planet-source-code.com c++.sun.com WIKIPEDIA, URL:

http://www.wikipedia.org
50

GOOGLE, URL: http://www.google.co.in Books:-

C++ complete Reference by Balaguruswamy C++ Theory(Balaguruswamy) LET US C Grady Booch: Object-Oriented Analysis and Design.

51