format for minor

7/29/2019 Format for Minor

1/53

A Minor Project Report

onTIME 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 SanodiyaEnroll. No.

0191CS081044

.

Under t he Supervision of

Mss .Pr atishtha Singh Prof.

RajeshBoghey(Asst. Proffesor) HOD

TIT Excellence Department of C. S. E.


2/53

DEPARTMENT OF COMPUTER SCIENCE & ENGINEERING TECHNOCRATS INSTITUTE OF TECHNOLOGY (EXCELLENCE),

BHOPAL

To Whom ItMayConcern

This is to certify that the work embodied in this Project entitled Time TableManagementhas 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 lifeGuided by:

Miss .Pratishtha Singh Prof.RajeshBoghey

(Asst. Proffesor) Head of

Department of C. S. E. Department of C. S. E.

Forwarded by:

Dr. C.K. Teckchandani

Director

2


3/53

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 Managementis 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 orprofessional diploma.

Name Enroll. No. Signature

Mukesh Kumar Sanodiya 0191cs081044

3


4/53

Place: Bhopal

Date: June 04, 2011

CERTIFICATEOF 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


5/53

ACKNOWLEDGEMENT

Thanks GOD for giving me knowledge and abili ty to complete this work inthis finalform.

The satisfaction that accompanies the succes s in completion of any task wouldbe incomplete without mentioning the people who made it possible, whose

constant guidance and encouragement crowned oureffort with success .

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

Pratishtha Singh (Ass t. Proffesor) TIT Excellence, for his constant Support,valuable Guidance and Encouragement. During the entire course of this projecthe reviewed with greatest care and his inno vative ideas led to the successful

completion of this work. His continuous strong and encouragement had someveryprofoundeffec t on me that went beyond scientific supervision.

I have bee n able to success fully complete this Proj ect bec ause of excellent

guidance and infinite help given to me by my HOD Prof. Rajesh Boghey HeadDepartment of CSE. It is difficult to acknowledge adequately the help and

encouragement I received from them but I take this oppor tunity to thanks them

profusely.

I wish to thank Dr. C.K. Teckchandani, DirectorTechnocrates Institute

of Technology (Excellence),,Bhopal forhis 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 coll eagues and classmates who h elped me directly or

indirectly thro ughout my proj ect work.

5


6/53


7/53

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 Introduction8

Chapter 2 SRS...10

Chapter 3 System Documentation.15

3.1 Flowchart15

3.2 Data Flow Diagram16

3.3 Entity Relationship Diagram.. .21

Chapter 4 Problem Description23

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 Feasibility36

7


8/53

5.4 Operational Feasibility.36

5.5 Schudle Feasibility36

Chapter 6 System Design and Development..376.1 Design Pattern37

6.2 Requirements..38

6.3 Screenshots .....39

Chapter7 Testing44

Testing.45

7.1 Code

Testing..45

7.2 Specification

Chapter 8. System Implemention46

Chapter 9 Discussion.47

Chapter 10. Lmitation48

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 Teache r timetable scheduling is a very

arduous and time-consum ing task. College Timetable management module

he lps you to gene rate class time table as well camp us and teacher time

table. Time table management module organizes the campus wee k,

holidays, breaks in between classes and subject teache r. Ti metable

Management module automatically creates your Campus Timetable for

classes, class teachers and student s. This module alsoallows you to gene rate

temp orary timetables.


9/53

8


10/53

Class -Teache rTimetabling - Thisproblemis normallyassociatedwith

Engineering College whe re the students are schedu led as a class. All

students in the same classtake exact ly the same/different set of courses.

Typically, teache rs and classesare busy most of the day, and the problem is

to find times when each teacher can meet with his/her requ ired classeswith

no conflicts

We have decidedto investigate the use of a Ti metableManagement

System. This system would be used by membe rs who may be students or

professors/Teache rs of that College to che ck and u pdate the Ti metableof

the Classes of College. The purpose of this document is to analyzeand

elaborate on the high-level nee ds and features of the Ti metable

Management System . Itfocuses on the capabilitiesand facilitiesprovidedby

a Time table of Class .The details of what all are the needs of the Ti metable

Management Sy stem and ifit fulfils the se nee ds are detailedin the use-case

and supplement aryspecifications.

Technology makes lifestyle easier by providing better support to

different systems, better accuracy, better security options, easier

maintenance, etc.

Now a days technology eventually means computers which is the

greatest achievements of last century. Day by day computers are being more

and more popular because of its features like ease of work, ease of learning,

greater accuracy with the least time consumption and the last but not the

least i.e. ease of maintenance with cost effectiveness.

So as a part of these ongoing evolutionary approach traditional

systems are being computerized to make them more fruitful than ever.

9


11/53

2. SOFTWARE REQUIREMENT SPECIFICATION

Purpose

The purpose of So ftware Requirements Speci fica tion

(SRS) document is to describe the external behavior of theTi metable Management System. Requirements Specification

defines and d escribes the operations, inte rfaces,

performance, and quality assurance requ irements of the

Ti metable Management System. The document also describes the

nonfunc tional requ irements such as the user inte rfaces. It also

describes the design constraints that are to be

10


12/53

considered when the system is to be designed, and other factors

nece ssary toprovide a complete and comprehensive description of the

requ irements for the software. The Software Requirements

Specification (SR S) captu res the complete software requ irements for

the system, or a por tion of the system. Requirements described in this

document are derived from the Vision Do cument prepared for

TimetableManagement System.

Scope

Describethe scope of the softw are app licationtobe

produced.Within the descriptionident ify the software produc t,

describe its func tionality,and app lications of the softw are. Inc ludeany

description of the bene fits,objectives,and goals of the software.

User Characteristics

Identify each type of user of the softw are by funct ion, location,

and type of device. Spec ify the number of users in each group

and the nature of the ir use of the system. Describe the

characteristicsand inte ractions of the users that will inte ractwith

the software during the ph ases of the software life cycle.

System State/Assumptions,Dependencies and Constraints

Assumptions

Describe assumpt ions made that can affect the requ irements of

the SRS. Assumptions are f actors that are believe to be true

during the life cycle of the project, that ifchanged may affect the

outc ome of the project.

Dependencies

Describe each depen dency that can affect the requirements

specified in the SRS. Dependenc ies are outside of the scope

and cont rol of the project and mu st remain true for the

project to succee d.

11


13/53

Con straints

Describe factors that limit the scope and func tionality of the

software. Constraints are requ irements 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, semesters details.

Scopes and boundaries of the package

As it is a computer-based package so maintenance and workingis 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


14/53

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

database for unsocial activities. Also easier to destroy the existing ones.

Fun ction al Requirements

The func tional requ irements sect ions should be customized to

cont ain the information nece ssary to define the fundamental actions

that must take place within the softw are to process inputs and

to p rocess and gene rate outputs. Func tional requ irements

should inc lude specific requ irements for business rules, wh ich

describe and document the steps in a businessprocess .

In the func tional requ irement subsect ions, specify all software

requ irements to a level of detail sufficient to enablethe developer to

build the software app lication. Each func tional requirement

documented in the requ irements sect ions mu st have a unique

identifier for requ irements traceability and should be ranked for

importanceand/o rstability.

Business Requirements

Describe all requ irements from a businesspe rspect ive. Business

requ irements are the parts of the fully definedbusinessprocess

that willbe automated by the software.

Non Functional Requirements

The Non func tional requ irements sect ions should be customized

to contain the information necessary to define the fundamental

act ions that mu st take place within the software to process and

gene rate its result. N on Func tional requ irements should inc lude

specific requ irements for business rules, wh ich describe and

document the steps in a businessprocess .

LogicalDa ta Requirements

Describethe logical data requ irements for the system.

13


15/53

User Requirements

Describe the user requ irement s; these should captu re the

inte ndedbehaviorof the human inte rface of the app lication.

OverallDescription

1. Infew minute s,the program gene rates a complete timetablethat

fulfills all your requ irement s. The program follows allpsycho

hygienicand organizational requ irements such as:

2. Selection forNumber of working days of the week (ex. Saturday

off)

3. Ze ro (atten dance) period insertion

4. Periodsper day selection.This selectionis day wise ex. Canbe

made 4periodson Saturday etc.)

5. Subjects could be entered considering

6. Hard subjects in f irst 4 or 5 periods

7. Subjectin which classroom

8. Single or doubleduration consecutively

9. Periodsper week per subject

10. Type of subject ( Hard, easy)

11. Subjects distribute deven ly for ent ire week

14


16/53

1

3. System Document

15


17/53

1

3.1FlowChart

16


18/53

1

3.2 DATA FLOW DIAGRAM

17


19/53

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


20/53

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.

NOT ATI ONS:

Data-Flows show the movement of data in a specific direction from the

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

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

from input to output.

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

data, which may be people, programs, organizations or other entities

interacting with the system, but are outside its boundary.

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

Below is the top level DFD showing how the Users request processed by the

server with database interaction and sends the response back to the user.

Feasibility St udy

19


21/53

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


22/53

The systems developed fully generalize, so that any future expansion will not be a

problem.

Functional Fea s ibilit y :

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.

P r oject App r ovalThose 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 F LOW DIAGRAM

Context Level D iagram

AdministratorTime Table

Management

0.0

Time Table

21


23/53

AdminAdmin

Firs t Level DFD

Admin Admin

MasterEntry

1.0

Reporting2.0

Report

Da taStore

DataStore

Second Level DFD

AdminAdmin

BranchMaster

1.1

SubjectMaster1.2

Branch

Master

Subject

Master

Admin

PeriodMasLtearb

1M

.3aster1.4


24/53

Teacher

Master

1.5

22

PeriodM

Laab

stM

eraster

Teacher


25/53

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


26/53

24


27/53

4. PROBLEM DISCRIPTION

4.1 Product Perspective

The rest of this document contains the following in thementionedorder:

1- Ove rall description of theprojectand itsrequirements.

2- Speci fic requirements for the project including

the functionality, usability, reliabil ity, performance,

security, safety, design constraints, and copy right and

intellectualproperties.

4.2 OBJECTIVE

To utilize my knowledge and technical skills along with a dedicated

desire of learning more and more, to

benefit my organization and attain consistent professional growth. I want

to equip myself with in-depth

practical knowledge and technical skills in the field of computer science,

and to design something different,

something new.

Create a Time Table Management System to be used by any College.

To perform the basic requirements of the firm.

Maintaining databases of subject, Class, semesters details.

25


28/53

4.3 TECHNOLOGY DESCRIPTION:-

4.3.1 C++:-

This overview of C++ presents the key design, programming, andlanguage-technical concepts using examples to give the reader a feel for

the language. C++ is a general-purpose

programming language with a bias towards systems programming that

supports efficient

low-level computation, data abstraction, object-oriented programming,

and generic programming.

4.3.2 Introduction and Overview

The C++ programming language provides a model of memory and computation

that closely matches that of

most computers. In addition, it provides powerful and flexible mechanisms for

abstraction; that is, language constructs that allow the programmer to introduce and

use new types of objects that match the concepts of an application. Thus, C++

supports styles of programming that rely on fairly direct manipulation

of hardware resources to deliver a high degree of efficiency plus higher-level styles

of programming that

rely on user-defined types to provide a model of data and computation that is closer

to a humans view of

the task being performed by a computer. These higher-level styles of programming

are often called data

abstraction, object-oriented programming, and generic programming.

This paper is organized around the main programming styles directly supported by

C++:

26


29/53

2 The Design and Evolution of C++ describes the aims of C++ and the principles

that guided its evolution.

3 The C Programming Model presents the C subset of C++ and other C++

facilities supporting traditional systems-programming styles.

4 The C++ Abstraction Mechanisms introduces C++s class concept and its use

for defining new types

that can be used exactly as built-in types, shows how abstract classes can be used to

provide interfaces to objects of a variety of types, describes the use of class

hierarchies in object-oriented programming, and presents templates in support of

generic programming.

5 Large-Scale Programming describes namespaces and exception handling

provided to ease the composition of programs out of separate parts.

6 The C++ Standard Library presents standard facilities such as I/O streams,

strings, containers (e.g.

v ve ec ct to or r, l li is st t, and m ma ap p), generic algorithms (e.g. s so or rt t(), f

fi in nd d(), f fo or r_ _e ea ac ch h()) and support for

numeric computation.

To round off, a brief overview of some of the tasks that C++ has been used for and

some suggestions for

further reading are given.

4.3.3 The Design and Evolution of C++

C++ was designed and implemented by Bjarne Stroustrup (the author of this

article) at AT&T Bell Laboratories to combine the organizational and design

strengths of Simula with Cs facilities for systems programming. The initial version

of C++, called C with Classes [Stroustrup,1980], was first used in 1980;

it supported traditional system programming techniques (3) and data abstraction

(4.1). The basic facilities for object-oriented programming (4.2-4.3) were added

27


30/53

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


31/53

4.3.4 C++ Design Aims

C++ was designed to deliver the flexibility and efficiency of C for systems

programming together with

Simulas facilities for program organization (usually referred to as object-oriented

programming). Great

care was taken that the higher-level programming techniques from Simula could be

applied to the systems

programming domain. That is, the abstraction mechanisms provided by C++ were

specifically designed to

be applicable to programming tasks that demanded the highest degree of efficiency

and flexibility.

These aims can be summarized:

_

_ Aims:

C++ makes programming more enjoyable for serious programmers.

C++ is a general-purpose programming language that is a better C

supports data abstraction

supports object-oriented programming

_ supports generic programming

Support for generic programming emerged late as an explicit goal. During most of

the evolution of C++, I

presented generic programming styles and the language features that support them

(4.4) under the heading

of data abstraction.

29


32/53

4.3.5 Design Principles

In [Stroustrup,1994], the design rules for C++ are listed under the headings

General rules, Design-support

rules, Language-technical rules, and Low-level programming support rules:

_

_ General rules:

C++s evolution must be driven by real problems.

C++ is a language, not a complete system.

Dont get involved in a sterile quest for perfection.

C++ must be useful now.

Every feature must have a reasonably obvious implementation.

Always provide a transition path.

Provide comprehensive support for each supported style.

_ Dont try to force 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


33/53

_ 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


34/53

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


35/53

of usage would preclude uniform treatment of semantically similar types in generic

programming (4.4).

When maintaining a large program, a programmer must invariably make changes

based of incomplete

knowledge and looking at only a small part of the code. Consequently, C++

provides classes (4), namespaces (5.2), and access control (4.1) to help localize

design decisions.

Some order dependencies are unavoidable in a language designed for one-pass

compilation. For example, in C++ a variable or a function cannot be used before it

has been declared. However, the rules for class

member names and the rules for overload resolution were made independent of

declaration order to minimize confusion and error.

_

_ Low-level programming support rules:

Use traditional (dumb) linkers.

No gratuitous incompatibilities with C.

Leave no room for a lower-level language below C++ (except assembler).

What you dont use, you dont pay for (zero-overhead rule).

_

If 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


36/53

C++s support for strong type checking. Except for minor details, C++ has C

[Kernighan,1978] [Kernighan,1988] as a subset. Being C-compatible ensured that

C++ programmers immediately had a complete

language and toolset available. It was also important that high-quality educational

materials were available

for C, and that C compatibility gave the C++ programmer direct and efficient

access to a multitude of

libraries. At the time when the decision to base C++ on C was made, C wasnt as

prominent as it later

became and language popularity was a minor concern compared to the flexibility

and basic efficiency

offered by C.

However, C compatibility also leaves C++ with some syntactic and semantic

quirks. For example, the

C declarator syntax is far from elegant and the rules for implicit conversions

among built-in types are

chaotic. It is also a problem that many programmers migrate from C to C++

without appreciating that radical improvements in code quality are only achieved

by similarly radical changes to programming styles.

4.3.6 The C Programming Model

A fundamental property of computers in widespread use has remained remarkably

constant: Memory is a

sequence of words or bytes, indexed by integers called addresses. Modern

machines say, designed during

the last 20 years have in addition tended to support directly the notion of a

function call stack. Furthermore, all popular machines have some important

facilities such as input-output that do not fit well into

34


37/53

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 is35


38/53

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


39/53

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 technicallyand le g ally 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/b e nefit

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
http://en.wikipedia.org/wiki/Legallyhttp://en.wikipedia.org/wiki/Legallyhttp://en.wikipedia.org/wiki/Cost-benefit_analysishttp://en.wikipedia.org/wiki/Cost-benefit_analysishttp://en.wikipedia.org/wiki/Cost-benefit_analysishttp://en.wikipedia.org/wiki/Cost-benefit_analysishttp://en.wikipedia.org/wiki/Cost-benefit_analysishttp://en.wikipedia.org/wiki/Cost-benefit_analysishttp://en.wikipedia.org/wiki/Legally


40/53

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

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.

De s ign:

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


41/53

6.SYSTEM DESIGN & DEVELOPMENT

6.1 Design Pattern Used:

DAO (Data Access Object) Model

DTO (Data Transaction Object) Model

Data Access & Data Transfer Object Mode l:

The Data Access Object (or DAO) pattern:

resource's client Separates a data interface from its data access mechanisms

Adapts a specific data resource's access API to a generic client interface

The DAO pattern allows data access mechanisms to change independently of the

code that uses the data.

DAO FACTORY

BUSINESS OBJECTDATA ACCESS OBJECT

DATA

SOURC

E

DATA TRANSFER

OBJECT

The DAO design pattern is another abstraction layer over the

persistence mechanism of the application. The application deals

39


42/53

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


43/53

6.3 SCREENSHOTS:

M E N U B A R

41


44/53

42


45/53

43


46/53

44


47/53

7. TESTING

45


48/53

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


49/53

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 startingwhat 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 T e s t ing:

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 I n t egration T e s t ing:

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 Sy s t em t e s t in g :

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


50/53

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


51/53

2. Installing the software on the server.

3. Training the operational staff.

Requirements keep changing with time so the implementation of this

project may change with time hence implementation is an ongoing process, which

may change in future.

9. DISCUSSION

As we discussed earlier during project time does not permit to complete the entire

project, so as a part of the whole is being carried out and being submitted as the

project in our curriculum. Total software along with extensive features will be

submitted as Major project, here is the entire Time Table Management System

with extensive features fulfilling the requirements of any modern distribution

farms.

Although we have attempted to make the entire package full proof of errors, it may

have some inherent bugs (beyond out knowledge) as it is yet to being tested with

real time data.

Lastly, we will carry our effort in developing the software fulfilling the basic

requirements of any distributing farm, if time permits.

We do believe that the system will satisfy the basics and will prove to be user

friendly and effective software whenever its being implemented in theorganization.

10. LIMITATION

49


52/53

. 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

WIKIPEDIA, URL:

www.planet - s ou r ce-code.com

c++.sun.com

http://www.wikipedia.org

50
http://www.planet-source-code.com/http://www.wikipedia.org/http://www.planet-source-code.com/http://www.wikipedia.org/


53/53

GOOGLE, URL:

Books: -

http://www.google.co.i n

C++ complete Reference by Balaguruswamy

C++ Theory(Balaguruswamy)

LET US C

Grady Booch: Object-Oriented Analysis and Design.
http://www.google.co.in/http://www.google.co.in/

format for minor

Documents