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

TECHNOCRATS INSTITUTE OF TECHNOLOGY (EXCELLENCE), BHOPAL

2

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. SignatureMukesh Kumar Sanodiya 0191cs081044

Place: Bhopal

Date: June 04, 2011

3

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.

5

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

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. Changes3.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 the5.pain of this process by automatically generating timetables for selected

courses6.from the UIBK course database. A side-e

ect of this is of course that students7.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 by6

9.the Institute. In the course of this project, a small script was written to hook10.into the CMS used on the Institute's website to automatically get exam dates11.from the University's course database.

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……………………………………………………153.2 Data Flow Diagram…………………………………………163.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 5.4 Operational Feasibility………………………………….36 5.5 Schudle Feasibility………………………………………36

Chapter 6 System Design and Development………..376.1 Design Pattern……………………………………………376.2 Requirements…………………………………………..38

7

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.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 conflictsWe have decided to investigate the use of a Timetable Management System. This system would be used by members who may be students or 8

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 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

10

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 CharacteristicsIdentify 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

AssumptionsDescribe 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.

DependenciesDescribe 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.

ConstraintsDescribe 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.11

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).

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.

12

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 RequirementsDescribe 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 RequirementsThe 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 RequirementsDescribe the logical data requirements for the system.

User RequirementsDescribe 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)

13

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

3.2 DATA FLOW DIAGRAM 16

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 DiagramsThe 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 17

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

18

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.

19

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 ApprovalThose 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

20

Time Table Management

0.0AdministratorTime Table

First Level DFD

Second Level DFD

21

DataStore

Master Entry1.0

Reporting2.0

Admin Admin

Report

DataStore

Branch Master

Branch Master

1.1

Admin

Subject Master

Subject Master

1.2

Admin

Teacher

Teacher Master

1.5

Admin

Period Master

Period Master

1.3

Admin

Lab Master

Lab Master

1.4

Admin

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

22

23

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.

24

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 OverviewThe 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++:

25

§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

26

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].

27

4.3.4 C++ Design AimsC++ 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.’’

28

4.3.5 Design PrinciplesIn [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 -

________________________________________________________________ _

29

_ 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.30

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 style31

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

32

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 ModelA 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

33

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

34

thing, but they are not necessarily the same. Scope is the mechanism by which it is

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.

35

5.FEASIBILITY REPORT

5.1 Technology and system feasibilityThe 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 feasibilityEconomic 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.

36

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 feasibilityDetermines 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 feasibilityOperational 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 feasibilityA 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.

37

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.

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

38

DAO FACTORY

DATA ACCESS OBJECT

DATA TRANSFER OBJECT

BUSINESS OBJECT

DATA SOURCE

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

39

6.3 SCREENSHOTS:

MENU BAR

40

41

42

43

7. TESTING

44

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:

45

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 followedLevels 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 46

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.47

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

48

. 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. ConclusionsSince 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

49

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.

50