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

Mss. Pratishtha Singh Prof.

Rajesh Boghey
(Asst. Proffesor) HOD
TIT Excellence Department of C. S. E.
 DEPARTMENT OF COMPUTER SCIENCE & ENGINEERING 
TECHNOCRATS INSTITUTE OF TECHNOLOGY (EXCELLENCE),
BHOPAL

To Whom It May
Concern
This is to certify that the work embodied in this Project entitled “ Time Table
Management“has 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:

Miss.Pratishtha Singh Prof.

Rajesh Boghey
(Asst. Proffesor) Head of
Department of C. S. E. 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 Enroll. No. Signature

Mukesh Kumar Sanodiya 0191cs081044

3
 Place: Bhopal

Date: June 04, 2011

CERTIFICATE OF APPROVAL

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) (EXTERNAL EXAMINER)

Date: Date:

4
                                       
                                  ACKNOWLEDGEMENT

Thanks GOD for giving me knowledge and ability to complete this work in this 
final form.

The satisfaction that accompanies the success in completion of any task would 
be   incomplete   without   mentioning   the   people   who   made   it   possible,   whose 
constant guidance and encouragement crowned our effort with success.

I   feel   pleasure   in   conveying   my   profound   thanks   to   my   Thesis   guide,   Miss. 

Pratishtha   Singh   (Asst.   Proffesor)   TIT   Excellence,   for   his   constant   Support, 
valuable Guidance and Encouragement. During the entire course of this project 
he reviewed with greatest care and his innovative ideas led to the successful 
completion of this work. His continuous strong and encouragement had some 
very profound effect on me that went beyond scientific supervision.

I   have   been   able   to   successfully   complete   this   Project   because   of   excellent 

guidance and infinite help given to me by my HOD Prof. Rajesh Boghey Head 
Department   of   CSE.   It   is   difficult   to   acknowledge   adequately   the   help   and 
encouragement I received from them but I take this opportunity to thanks them 
profusely.

               I wish to thank Dr. C.K. Teckchandani, Director Technocrates Institute
of Technology (Excellence),, Bhopal for his constant support and encouragement.

I  am thankful to  all other  faculty  members  and all computer   centre staff  in 

Department of CSE for their cooperation extended during the project work.

I am also thankful to my colleagues and classmates who helped me directly or 
indirectly throughout my project work.

5
 Mukesh Kumar Sanodiya
Enrollment No: 0191cs081044
B. E. (CSE)
Technocrats Institute of Technology
(Excellence)

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,
nor-
2.mally resulting in multiple iterations of creation and proof-reading. Changes
3.desired by teaching sta
, changes of course locations etc. also require an adap-
4.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 Insti-
8.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 Introduction……………………………………8
Chapter 2 SRS……………………………………………...10
Chapter 3 System Documentation………………………….15
3.1 Flowchart……………………………………………………15

3.2 Data Flow Diagram…………………………………………16

3.3 Entity Relationship Diagram…….. ……………………….21

Chapter 4 Problem Description………………………23

4.1 Product Perspective……………………………………….23

4.2 Objective…………………………………………………...23

4.3 Terminology used ……………………................................24

4.4 Scope……………………………………………………….33

4.5 Benefits…………………………………………………….34

Chapter 5. Feasibility
Report………………………….35
5.1 Technical Feasibility……………………………………..35
5.2 Economical Feasibility………………………………..35
5.3 Legal Feasibility…………………………………………36
7
 5.4 Operational Feasibility………………………………….36
5.5 Schudle Feasibility………………………………………36
Chapter 6 System Design and Development………..37
6.1 Design Pattern……………………………………………37

6.2 Requirements…………………………………………..38

6.3 Screenshots …………………………………..……...39

Chapter 7 Testing……………………………44
7.1 Code
Testing…………………………………………….45

7.2 Specification
Testing……………………………………..45

Chapter 8. System Implemention……………………46

Chapter 9 Discussion……………………………….47
Chapter 10. Lmitation…………………………………48
Chapter 11. Future Work……………………………….48
Chapter 12. Bibliography………………………………..49

1. INTRODUCTION

The Problem is to Manage the Time Table of the all class of the college
according to teacher, and the Purpose of Manage Timetable of the
College is, for any College Teacher timetable scheduling is a very arduous
and time-consuming task. College Timetable management module helps you
to generate class time table as well campus and teacher time table. Time
table management module organizes the campus week, holidays, breaks in
between classes and subject teacher. Timetable Management module
automatically creates your Campus Timetable for classes, class teachers and
students. This module also allows you to generate temporary timetables.
8
Class-Teacher Timetabling - This problem is normally associated with
Engineering College where the students are scheduled as a “class”. All
students in the same class take exactly the same/different set of courses.
Typically, teachers and classes are busy most of the day, and the problem is
to find times when each teacher can meet with his/her required classes with
no conflicts
We have decided to investigate the use of a Timetable Management System.
This system would be used by members who may be students or
professors/Teacher’s of that College to check and update the Timetable of
the Classes of College. The purpose of this document is to analyze and
elaborate on the high-level needs and features of the Timetable Management
System. It focuses on the capabilities and facilities provided by a Time table
of Class. The details of what all are the needs of the Timetable Management
System and if it fulfils these needs are detailed in the use-case and
supplementary specifications.

Technology makes lifestyle easier by providing better support to

different systems, better accuracy, better security options, easier
maintenance, etc.
Now a day’s 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.

9
 2. SOFTWARE REQUIREMENT SPECIFICATION

Purpose

The purpose of Software Requirements Specification (SRS)

document is to describe the external behavior of the Timetable
Management System. Requirements Specification defines and
describes the operations, interfaces, performance, and quality
assurance requirements of the Timetable Management System. The
document also describes the nonfunctional requirements such as the
user interfaces. It also describes the design constraints that are to be

10
 considered when the system is to be designed, and other factors
necessary to provide a complete and comprehensive description of the
requirements for the software. The Software Requirements
Specification (SRS) captures the complete software requirements for
the system, or a portion of the system. Requirements described in this
document are derived from the Vision Document prepared for
Timetable Management System.
Scope
Describe the scope of the software application to be
produced.Within the description identify the software product,
describe its functionality, and applications of the software. Include any
description of the benefits, objectives, and goals of the software.

User Characteristics
Identify each type of user of the software by function, location,
and type of device. Specify the number of users in each group
and the nature of their use of the system. Describe the
characteristics and interactions of the users that will interact with
the software during the phases of the software life cycle.
System State/Assumptions, Dependencies and Constraints

Assumptions
Describe assumptions made that can affect the requirements of
the SRS. Assumptions are factors that are believe to be true
during the life cycle of the project, that if changed may affect the
outcome of the project.

Dependencies
Describe each dependency that can affect the requirements
specified in the SRS. Dependencies are outside of the scope and
control of the project and must remain true for the project to
succeed.

11
Constraints
Describe factors that limit the scope and functionality of the
software. Constraints are requirements that are imposed on the
software solution.
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, semester’s details.

Scopes and boundaries of the package

 As it is a computer-based package so maintenance and working

is somewhat difficult from manual mode of approach.
 As it is not possible to associate each and every requirement of
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.
Functional Requirements
The functional requirements sections should be customized to
contain the information necessary to define the fundamental actions
that must take place within the software to process inputs and to
process and generate outputs. Functional requirements should
include specific requirements for business rules, which describe and
document the steps in a business process.
In the functional requirement subsections, specify all software
requirements to a level of detail sufficient to enable the developer to
build the software application. Each functional requirement
documented in the requirements sections must have a unique
identifier for requirements traceability and should be ranked for
importance and/or stability.

Business Requirements
Describe all requirements from a business perspective. Business
requirements are the parts of the fully defined business process
that will be automated by the software.

Non Functional Requirements

The Non functional requirements sections should be customized
to contain the information necessary to define the fundamental
actions that must take place within the software to process and
generate its result. Non Functional requirements should include
specific requirements for business rules, which describe and
document the steps in a business process.

Logical Data Requirements

Describe the logical data requirements for the system.

13
User Requirements
Describe the user requirements; these should capture the
intended behavior of the human interface of the application.

Overall Description
1. In few minutes, the program generates a complete timetable that
fulfills all your requirements. The program follows all psycho
hygienic and organizational requirements such as:

2. Selection for Number of working days of the week (ex. Saturday

off)

3. Zero (attendance) period insertion

4. Periods per day selection .This selection is day wise ex. Can be
made 4 periods on Saturday etc.)

5. Subjects could be entered considering

6. Hard subjects in first 4 or 5 periods

7. Subject in which classroom

8. Single or double duration consecutively

9. Periods per week per subject

10. Type of subject ( Hard, easy…)

11. Subjects distributed evenly for entire week

14
 3. System Document

15
3.1FlowChart

16
 3.2 DATA FLOW DIAGRAM

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 User’s 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 Time Table

Administrator Management
0.0

21
First Level DFD

Admin Admin

Master
Entry Reporting Report
1.0 2.0

DataStore
DataStore

Second Level DFD

Admin
Admin

Subject
Branch Master
Master 1.2
1.1

Subject
Branch Master
Master

Admin Admin
Admin

Period Teacher
Lab
Master Master
Master
1.3 1.5
1.4

22
Period
Teacher
Master
Lab Master
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 Product Perspective

The rest of this document contains the following in the

mentioned order:
1- Overall description of the project and its requirements.
2- Specific requirements for the project including the
functionality, usability, reliability, performance, 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, semester’s 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 human’s 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 C’s 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 independently-
developed 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
Simula’s 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.
Don’t 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.
_ Don’t try to force people.
_______________________________________________________ 
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
_ 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 real-
world 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 user-
defined 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 don’t use, you don’t pay for (zero-overhead rule).
_
If in doubt, provide means for manual control.
_______________________________________________________________ - 4
-
C++ was designed to be source-and-link compatible with C wherever this did not
seriously interfere with

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 wasn’t 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 machine-
architecture-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
free data to analyze.
 This package would limit the time and money factor involve in
“Time Table Management System”.
 Maintenance is much easier and accurate than the existing
manual system.
 Security features are somewhat higher of manual approach.

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

DATA
SOURC
BUSINESS OBJECT E
DATA ACCESS OBJECT

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 : Pentium IV

Random access memory : 256 MB
Hard disk capacity : 40 GB

Software configuration

Operating system : Windows (2000, ME, NT, XP)

Programming specification : C++
Integrated Development
C & C++ graphics

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 it’s 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