Project Report

On
School Management System
Submitted By
Subhadip Chanda

Department of MCA
Calcutta Institute of Technology

Under the guidance of

Mr. Biplab Kanti Das

Teacher, Dept. of MCA
Calcutta Institute of Technology
 ACKNOWLEDGEMENT

In the very beginning I would like to give my heartiest gratitude to

Mr. Biplab Kanti Das, Teacher, MCA Department, Calcutta
Institute of Technology (Also our project guide) for giving me this
opportunity to get involved in such a real life project for web page
design.

We are also grateful to our collage faculties to let us introduced to

such a sophisticated and good infrastructure Institution. During
the full span of this complete web page lots of people around me
help our in various ways. We want to give all of these our hearty
gratefulness.

Finally, we are very happy to design this complete web page of

Online Directory System. This is the first time when we designed
any web page for actual use of people.
 STUDENT DECLARATION

We hereby declare that this project report entitled “Online

Directory System” has been prepared by our self under the
guidance of Mr. Barun Maity, Teacher of Computer Science &
Application Department, P. K. College, Contai.

We would like to declare that this is the result of our own effort
and that it has not been satisfied to this Collage or to other
Universities or boards for the award of degree.

Prepared by:

Subhadip Chanda
Registration no.- 000276 of 2012-2013
Roll- 4611223 No.- 024

Prasanta Jana
Registration no.- 000262 of 2012-2013
Roll- 4611223 No.- 010

Surajit Bar
Registration no.- 000295 of 2011-2012
Roll- 4611123 No.- 020

Sourav Pahari
Registration no.- 000321 of 2011-2012
Roll- 4611123 No.- 039

----o----
BCA
DEPT. OF COMPUTER SCIENCE AND APPLICATION

P.K Collage, Contai

Purba Medinipur
 TABLE OF CONTENTS

1. INTRODUCTION
1.1 PURPOSE
1.2 SCOPE
1.3 ACRONYMS
1.4 REFERENCES
1.5 OVERVIEW
2. GENERAL DESCRIPTION
2.1 FEASIBILITY STUDY
2.1.1 TECHNICAL FEASIBILITY
2.1.2 OPERATIONAL FEASIBILITY
2.1.3 ECONOMICAL FEASIBILITY
2.2 PRODUCT PERSPECTIVE
2.2.1 ARCHITECTURAL DIAGRAM
2.2.2 TECHNOLOGIES USED
2.2.3 SOFTWARE SPECIFICATION
2.2.4 HARDWARE SPECIFICATION
2.3 SOFYWARE REQUIREMENT SPECIFICATION (SRS)
2.3.1 PURPOSE OF SRS
2.3.2 SOPE OF PRODUCT
2.4 PRODUCT FUNCTIONS
2.4.1 FUNCTIONAL REQUIREMENTS
2.4.2 NON FUNCTIONAL REQUIREMENTS
2.5 USER CHARACTERISTICS
2.6 GENERAL CONSTRAINTS
2.7 ASSUMPTIONS AND DEPENDENCIES
3. TOOLS DESCRIPTION
3.1 XAMPP SERVER
3.2 PHP
3.3 HTML
3.4 JAVA SCRIPT
3.4 MY SQL DATABASE
4. ENTITY RELATIONSHIP DIAGRAM
5. DATA FLOW DIAGRAM
6. SPECIFIC REQUIREMENTS
6.1 DATABASE MODEL
6.1.1 DATABASE DIAGRAM
6.1.2 DATABASE REPORT
7. SCREEN SHOT
8. TESTING
9. MAINTENANCE
10. ADVANTAGES
11. DISADVANTAGES
12. BIBLIOGRAPHY
 1. INTRODUCTION
1.1 Purpose:
This web Application provides facility to conduct online searching for
various real life services like grocery, plumber, carpenter, doctor etc daily
needs worldwide. It saves times as it allows people to give advertise of their
services, they can promote their services also. It primarily helps those people
who are new in a location. They can got the address and contact details of
service provider.

1.2 Scope:
 Administrator
Administrator has a privilege to create, modify and delete some
website content, category. Admin can deactivate or activate a service
and user. Admin can also solve the report against any service or any
query.
 User
Here user can register as a service provider. User can also search for
any service. User can promote his/her services.

1.3 Acronyms
 AJAX: Asynchronous JavaScript and XML
 GUI: Graphical User Interface
 HTML: Hyper Text Markup Language
 HTTP: Hyper Text Transfer Protocol
 JSP: Java Server Programming
 J2EE: Java 2 Enterprise Edition
 UML: Unified Modeling Language
 XHTML: Extensible Hyper Text Markup Language
 XML: Extensible Markup Language.

1.4 References:
 Project Scenario provided by IBM-TGMC `09
 IEEE SRS Format
 SAMS Teach Yourself UML In 24 Hours by Joseph Schmuller
 PHP Project for Beginners by Sharanam Shah, Vaishali Shah

1.5 Overview:
 General Description: will describe major components of the system,
technologies used and its software and hardware requirements. It also
depicts the functional and non-functional requirements of the system.
 Specific Requirements: It contains diagrams and their reports. The
diagrams describe what a system is supposed to do.
 Database Diagram consists of a number of tables with their
attributes, and the relationship between them.
 2. GENERAL DESCRIPTION

This section of the SRS describes the general factors that affected the
product and its requirements. This section contains following sub sections
 Feasibility Study
 Product Perspective
 Product Function

2.1 Feasibility Study

Estimation is made of whether the identified problem definition and problem
domain can be satisfied by using current software and hardware
technologies. We also have done accost effective study form a business point
of view and budgetary constraints. Our feasibility study is cheap and quick.
The result of feasibility study will inform us to determine whether developing
the system is in different respect. There exists three of feasibility study
 Technical feasibility
 Operational feasibility
 Economical feasibility

2.1.1 Technical feasibility

 Development risk: The system elements have been designed so
that the necessary function and performance are achieved within the
 constraints. Some additional features may easily be added in the
features which have been seen uncovered during the analysis.
 Resource availability: The system has been made so user friendly
that even non-technical and untrained people can use it easily. The
hardware and software used to build it are easily available.

 Technology: This package will work on Windows NT, Windows 98,

Windows 2K, Windows ME and Windows XP, Windows 7. It is also
work on LINUX operating system. Therefore it is highly compatible to
any stand-alone system or mainframe with the Windows environment.

2.1.2 Operational feasibility

 Hardware and software requirements.
 Operators and trainer requirements.
 Communication media requirements.

2.1.3 Economical feasibility:

This is actually the cost benefit analysis. Since this is live project so we have
for the time being skipped over this issue. This website designing and
planning is economically feasible.

2.2 Product Perspective

2.2.1 Architectural Diagram:

 The web pages are present to provide the user interface on client side.
Communication between client and server is provided through
HTTP/HTTPS protocols.
 On the server side web server is for EJB and database server is for
storing the information.
2.2.2 Technologies Used:
 J2EE: Application Architecture (Java, JavaBeans, Servlet, JSP,
JavaScript etc.)
 XML: Technique to transport and store data.
 AJAX: Technique for creating more interactive web application.
 Web 2.0: facilitates interactive information sharing, interoperability,
user-centered design and collaboration on the www.
 Web-services: is software system designed to support interoperable
machine-to machine interaction over a network.
 Dream Weaver: Technique to design and develop website (HTML,
XHTML, CSS etc.).

2.2.3 Software Specification:

 Web Browser: Internet Explorer, Mozila Firefox, Operating System
(any).
 Web Server: XAMPP, Operating System (any).
 Data Base Server: SQL, Operating System (any).

2.2.4 Hardware Specification:

2.3 SOFTWARE REQUIREMENT SPECIFICATION (SRS):

2.3.1 Purpose of SRS:
This is the Software Requirements Specification (SRS) for the college a
complete website. The purpose of this document is to convey information
about the application's requirements, both functional and non-functional, to
the reader. This document provides
 A description of the environment in which the application is expected
to operate.
 A definition of the application's capabilities and
 A specification of the application's functional and nonfunctional
requirements.
The document is intended to serve several groups of audiences:
  First, it is anticipated that the SRS will be used by the application
designers. Designers will use the information recorded here as the
basis for creating the application's design.
 Second, the client for the project, the Administrator in our case, is
expected to review this document.  The SRS will serve to establish a
basis for agreement between the client and development team about
the functionality to be provided by the application.
 Third, the application maintainers will review the document to clarity
their understanding of what the application does.
 Fourth, test planners will use this document to derive test plans and
test cases.
 Finally, the project manager will use this document during project
planning and monitoring.

2.3.2 Scope of Product:

The purpose of this website is to create a new application called: website
designing the client for this project wishes to enter the PC-and web-based
LAN environment. The Resource Management System will be PC-base with a
LAN, allowing valid users to search Employees to manage the system and
Employee database. The application will provide the following capabilities:
 The application will be access via a web server on a PC terminal in the
Organization.
 Administrator will be able to manage resource accounts including
remove, change, and add.
 The application will provide search function on Places based on name.
The project's client has determined that this application will provide the
following benefits:
 Provide additional flexibility and convenience to the Administrator.
 Provide better reliability and security of the User’s Information.
 Reduce the cost of the Organization operations.
2.4 Product Functions
2.4.1 Functional Requirements:
 To provide the service searching facility to people.
 User can search a service from his location.
 Our system provide all searched service around 20 KM by default.
 There are more than 1200 categories and sub categories available.
 User can get the direction from his location to service destination in
Google map.
 To provide login interface through which only authorized user can
pass by.
 Service provider can list their service.
 Service provider can promote their service.
 For promote a service, service provider need to buy coin. Through
PayPal payment gateway.
 A user can give a review about a service.
 An authorized user can file a report about a service. If he detect that
service is fake or unnecessary.
  There is an effective support system & FAQ system.
 A registered can refer our site to his friend through social media.
 Admin can active or reactive services or service provider.
 Multilingual system is implemented using Google translator.
2.4.2 Non Functional Requirements:
 User’s details must be kept confidential.
 System should be available 24 X 7.
 The Web Application Server should provide good performance and the
ability to manage performance with techniques.
 Application should serve dynamic user based customized web pages to
its clients from server.
 The system should be reliable and robust.
 The system should be User friendly.
 The system should be completely Consistent and Secure.
2.5 User Characteristics:
 Educational level: Users should be comfortable with the English
language.
 Experience: Users should have prior knowledge about computer or
mobile..
 Skills: Users should have basic knowledge and should be comfortable
using general purpose applications on computers.
2.6 General Constraints:
 The GUI is only in English. But other language also available.
 Login and password is used for identification of users.
 Guests have restricted viewing facility.
 Limited to HTTP/HTTPS.
 Network connectivity must be facilitated to every area.
 To support large number of users the system requires larger
bandwidth and more resources.

2.7 Assumptions and Dependencies:

 Administrator is created in the system already.

 The facility of creating a new entry or modifying an existing entry

given only to Administrator.
 3. Tools Description

Software Requires developing the project:

 XAMPP Server
 PHP
 HTML
 JAVA SCRIPT
 MySql Database

Details of software used:

3.1 XAMPP Server:
XAMPP Server is a Windows web development environment. It allows you to
create web applications with Apache, PHP and the MySQL database. It also
comes with PHP MyAdmin and SQLiteManager to easily manage your
databases.
XAMPP Server installs automatically (installer), and its usage is very
intuitive. You will be able to tune your server without even touching the
setting files.
XAMPP Server is the only packaged solution that will allow you to reproduce
your production server. Once XAMPP Server is installed, you have the
possibility to add as many Apache, MySQL and PHP releases as you want.
XAMPP Server also has a tray icon to manage your server and its settings.
  Installing:
Double click on the downloaded file and just follow the instructions.
Everything is automatic. The XAMPP Server package is delivered which the
latest releases of Apache, MySQL and PHP.
Once XAMPP Server is installed, you can add other releases by downloading
them on this website. They will then appear in the XAMPP Server menu and
you will be able to switch releases with a simple click.
Each release of Apache, MySQL and PHP has its own settings and its own
files (datas for MySQL).
 Functionalities:
XAMPP Server's functionalities are very complete and easy to use so we
won't explain here how to use them.
With a left click on XAMPP Server's icon, you will be able to:
- manage your Apache and MySQL services
- Switch online/offline (give access to everyone or only localhost)
- install and switch Apache, MySQL and PHP releases
- manage your server’s settings
- access your logs
- access your settings files
- create alias

With a right click:

- manage your Apache and MySQL services

 How to start:
When you install XAMPP Server, a "htdocs" directory is created (generally c:\
XAMPP\ htdocs). Create a directory inside for your project and put your PHP
files in it.
Click on the link "Localhost" in the XAMPP Server menu or open your
browser and open the http://localhost address.
An icon on the taskbar tray displays the status of XAMPP, letting you know
if;
 XAMPP is running but no services are opened (the icon will appear
red)
 XAMPP is running and one service is opened (the icon will appear
yellow) or
 XAMPP is running with all services opened (the icon will appear
white). Apache and MySQL are considered to be services (they can be
disabled by left-clicking on the taskbar icon, guiding your cursor over
the service you wish to disable and selecting "Stop Service").
The files/web pages that are hosted on your XAMPP server can be accessed
by typing http://localhost/ or http://127.0.0.1/ in the address bar of your
web browser. XAMPP must be running in order to access either of the above
addresses.
If you would like to share your files/web pages with others, click on the icon
located on your taskbar tray and select "Put Online." You must have access
to the Internet in order to continue.

 Add Apache, MySQL and PHP releases:

XAMPP Server allows you to install almost all the existing releases of
Apache, PHP and MySQL so you can reproduce exactly the settings of your
production server. To add a new release, download it here and install it.
Then click on the XAMPP Server menu and activate the release that you
want to use. Wait until the XAMPP Server icon become white and start to
work.

3.2 PHP Hypertext Preprocessor:

PHP5.2.0 is the latest incarnation of PHP – the “PHP Hypertext
Preprocessor”. It’s a programming language for building dynamic, interactive
web sites, originally devised by RasmusLerdorf way back in 1994. Since
then it’s been though a great many changes, and has been adopted by web
programmers all around the world. So what exactly is it?
It technical terms, PHP 5.2.0 is a cross-platform, HTML-embedded, server-
side web scripting language. Let’s take a moment to define these terms:

 Cross-platform:
You can run most PHP5.2.0 code, without alternation, on computers
running many different operating systems. A PHP5.2.0-script that runs on
Linux will generally run on Windows as well.
  HTML-embedded:
PHP5.2.0 code is written in files containing a mixture of PHP instructions
and HTML code.
 Server-side:
The PHP5.2.0 programs we write are run on a server – specifically, a web
server (Apache).

 A web scripting language:

We run PHP5.20 programs via a web browser. We access the web server on
which they reside, and this runs the program, sending any resulting output
back to the browser (Internet Explorer).
This means that we’re going to be write programs that mix PHP5.2.0 code
and HTML together, using the former to control and format the latter. We’ll
need to put the program onto to web-server to run them. Finally, we are
going to access them from a web browser.

3.2.1 Why PHP?

One of the best things about PHP 5.2.0 is that it is supported by a large
number of Internet Service Providers(ISPs), which is means that once you’ve
written an application in PHP5.2.0, you can easily put it on the Web for
anyone to use. You can find list of ISPs who can help you with hosting PHP
based websites at http://hosts.php.net/.

3.2.2 The prompt:

When we start looking at the database, we will be introducing MySql
database manager, and making extensive use or its command line interface.
If you’re primarily using your computer in a graphical environment like
Windows of X, you may not be familiar with using the command line
interface, or “shell”. The “shell” is the program that takes the name from
you-the “shell prompt” (or just” prompt”) refers specifically to the text that
prompts you to enter a new program name, and more generally to working
with the shell instead of using a graphical interface.

3.2.3 PHP Resources:

Your first stop for information should be the official PHP site, which you can
find at www.php.net. This not only features news, downloads, and completes
documentation. PHP is based on the Zend scripting engine, owned by Zend
Technologies, whose site can be found at www.zend.com. Another very
useful resource is the www.phpbuilder.com site, a community-driven forum
for PHP programmers.

3.2.4 Writing PHP Programs:

PHP is written within the tags <?php and ?>. The scripts in php written
within between these tags are identified by the server and transformed to
pure html. The php programs can be included with the include and require
keyword. The echo and print statements are used to print the output.
3.3 HTML:
HTML is composed of tags. HTML tags are always enclosed in angle-brackets
(<>) and are case-insensitive; that is, it doesn't matter whether you type
them in upper or lower case. I almost always use upper case, because it
makes the tags easier to pick out in a document, but that's just me. You can
do whatever you like.
Tags typically occur in begin-end pairs. These pairs are in the form
<tag> ... </tag>
Where the <tag> indicates the beginning of a tag-pair, and the </tag>
indicates the end. (The three dots indicate an arbitrary amount of content
between the tags.) The usual way to refer to each tag is "tag" for the first and
"slash-tag" for the second, where tag is the actual name of the tag being
discussed.
These pairs define containers. Any content within a container has the rules
of that container applied to it. For example, the text within a "boldface
container" would be boldfaced. Similarly, paragraphs are defined using a
"paragraph container."
Thinking of tag-sets as containers will help in another way: it will help you
remember that tags should always be balanced. In other words, you should
keep containers nested within each other, just as you would have to do in
the real world. Let's try some visual examples where we actually draw the
containers:

One more thing to keep in mind with regards to containers. Since HTML is
based on these structures, it is often the case that the arrangement of text
within a container is irrelevant. For example, within a paragraph container,
all of the text can be in one long line, or in a series of separate lines, or with
every word on its own line, or with every word separated from every other by
nineteen spaces. These would all be displayed exactly the same.
Therefore, try to keep in mind this thought: white space doesn't matter.
(White space is all of the blank areas in a text file--empty lines, extra spaces,
and so on.) We'll mention this again when discussing the paragraph tag and
it will crop up in other places. Again: whites pace doesn't matter.
Having said all that, we will now attempt to muddy the waters a bit by
mentioning that not every tag in HTML is paired. Some tags, such as the
line-break tag, stand on their own (that is, they have no closing tag). These
are known as empty tags. As we encounter them, I'll point them out.
The first and last tags in a document should always be the HTML tags.
These are the tags that tell a Web browser where the HTML in your
document begins and ends. The absolute most basic of all possible Web
documents is:
<HTML>

</HTML>
That's it. If you were to load such a page into a Web browser, it wouldn't do
anything except give you a blank screen, but it is technically a valid Web
page. Obviously, you'll want more than that.

 HEAD:
The HEAD tags contain all of the document's header information. When I
say "header," I don't mean what appears at the top of the browser window,
but things like the document title and so on. Speaking of which...

 TITLE:
This container is placed within the HEAD structure. Between the TITLE
tags, you should have the title of your document. This will appear at the top
of the browser's title bar, and also appears in the history list. Finally, the
contents of the TITLE container go into your bookmark file, if you create a
bookmark to a page.
What you type should probably be something which indicates the
document's contents, but it doesn't have to be. The length of the title is
pretty much unlimited, but don't go overboard. Users will either sneer at or
be confused by exceedingly long titles.
If you don't type anything between the TITLE tags, or don't include the
TITLE tags at all -- remember the blank document in the HTML section
earlier? – Then the browser will typically use the actual file name for the
title. Therefore, a document titled "TCh4ex4.html" will have that name
appear in the history list. Again, you can choose to do this, but it will likely
generate either confusion or contempt.

 BODY:
BODY comes after the HEAD structure. Between the BODY tags, you find all
of the stuff that gets displayed in the browser window. All of the text, the
graphics, and links, and so on -- these things occur between the BODY tags.
So, putting everything we've covered thus far into one file, we have:
<HTML>
<HEAD>
<TITLE>Document Title</TITLE>
</HEAD>

<BODY>

</BODY>
</HTML>

This time, the result would be a document with a completely blank browser
window, but at least the words "Document Title" would appear in the
browser's history list. But don't take my word for it lets look at the above
block of HTML again, but this time with container lines sketched in. Note
that the TITLE tags and text have been rearranged to make it easier to draw
in the container lines. The rearrangement of the text does not in any way
change the resulting Web page's appearance.

 COMMENT TAGS:
If you want to leave yourself notes in an HTML document, but don't want
those notes to show up in the browser window, you need to use the
comment tag. To do that, you would do the following:
<! -- Hi, I'm a comment. -->
Your note would go where the text Hi, I'm a comment Appears. Yes, you do
need an exclamation point after the opening bracket, but not before the
closing bracket. That's the way the standard is written. I have no idea why.
Also, there is no end tag; that is, a tag like </! -- Text --> does not exist. The
comment tag is not a container. This is our first example of an empty tag.
You can put comments pretty much anywhere, but you have to be aware of
one important thing: you shouldn't put any HTML markup within a
comment tag. Theoretically, you should be able to, but most browsers
handle this less than gracefully (i.e., they either mess up or crash).
What if you get the tag wrong, like forgetting to include the exclamation
point? In that case, the text you did type in would be displayed.

 HEADINGS:
The heading structures are most commonly used to set apart document or
section titles. For example, the word "Headings" at the beginning of this
section is a heading. So is this document's title (it's at the top of the page, in
case you somehow missed it).
Remember that these heading structures go into the body of the document.
The headings being discussed here have nothing to do with the HEAD
structure from the previous chapter.
There are six levels of headings, from Heading 1 through Heading 6.
Heading 1 (H1) is "most important" and Heading 6 (H6) is "least important."
By default, browsers will display the six heading levels in the same font,
with the point size decreasing as the importance of the heading decreases.
Here are all six HTML pairs, in descending order of importance:
<H1>Heading 1</H1>
<H2>Heading 2</H2>
<H3>Heading 3</H3>
<H4>Heading 4</H4>
<H5>Heading 5</H5>
<H6>Heading 6</H6>
These six lines, when placed into an HTML document, will simply display
the six levels of headings.
Since, as we have discussed, whites pace doesn't matter, you might think
that the above block of HTML would just string the content into one line of
text. However, because headings are meant for section titles and the like,
they are defined as existing on a line by themselves. A heading always
begins at the margin of a line and always forces a line break at the end of
the heading. In other words, you cannot have two heading levels on the
same line.

 PARAGRAPHS:
As you might suspect, paragraphs are quite common in Web pages. They are
one of the most basic structures in HTML. If you regard a document as a
collection of structures and sub-structures, you may come up with
something like:
The overall structure is a page. The page is composed of a number of
sections, each of which is composed of one or more paragraphs. Each
paragraph is composed of words, and each word of letters.
Admittedly, this is a simplified way of looking at text, but it will do for our
purposes. The furthest HTML goes down this progression is to the
paragraph level.
The beginning of a paragraph is marked by <P>, and the end by </P>. This
tutorial is obviously filled with examples of this container, and you can look
at the following example page to get a more direct idea of how the paragraph
tag works.
Let's say you want to create a paragraph. You start to wonder, "What
happens if I hit return at the end of every line in the paragraph? Should I
make the paragraph just one long continuous line? What if I accidentally
put too many spaces between words?"
At this point, you should once again be saying to yourself: whites pace
doesn't matter. You could put each word on its own line, and the paragraph
would look completely normal. In fact, no matter how much whites pace you
put between words, whether returns or spacebar hits, the words will be
separated by one space in a Web browser.
Got all that? If you're not sure you completely understand, go through the
section again -- or better still, try it on your own.

 LINE BREAK:
So what if you want to end a line after a certain word, but don't want to
start a new paragraph? Well, what you need is a line break, which is
invoked by using the <BR> tag. This forces a line break wherever you place
it in the content (that is, whatever is after the <BR> tag will start from the
left margin of the next line on the screen.)
And no, there is no </BR> tag. The line break tag is -- that's right! -- An
empty tag. And when you think about it, this makes sense. The concept of a
line break beginning and ending doesn't really work, since a line break is a
one-shot occurrence.

3.4 JAVASCRIPT:
JavaScript is a scripting language most often used for client-side web
development. Its standardized name is ECMAScript, though "JavaScript" is
much more commonly used. "JavaScript" is actually Netscape
Communications Corporation's (and now the Mozilla Foundation's)
implementation of the ECMAScript standard.
JavaScript is a dynamic, weakly typed, prototype-based language with
first-class functions. JavaScript was influenced by many languages and was
designed to have a similar look to Java, but be easier for non-programmers
to work with. The language is best known for its use in websites (as client-
side JavaScript), but is also used to enable scripting access to objects
embedded in other applications.
Despite the name, JavaScript is unrelated to the Java programming
language; though both have a common debt to C syntax. The language was
renamed from Live Script in a co-marketing deal between Netscape and Sun
in exchange for Netscape bundling Sun's Java runtime with their browser,
which was dominant at the time. JavaScript semantics is much more similar
to the Self programming language.
"JavaScript" is a registered trademark of Sun Microsystems, Inc. It was used
under license for technology invented and implemented by Netscape
Communications.

3.5 MySQL:
SQL, or Structured Query Language is the standard command set used to
communicate with a relational database management system on any given
platform. All tasks such as creating databases or tables, as well as saving,
retrieving, deleting, and updating data from databases are done via SQL
statements.
When you create a database table, the type and size of each field must be
defined. A field is similar to PHP variables. The three usual sets of data are
supported in MySql: numeric, date/time, and characters.

 Why MySQL:
MySQL is a freely available RDBMS, which fully joined the Open Source
Community only recently, when it was released under the GNU Public
License.

 MySQL provides a whole lot of other features:

o Open Source Software:
 o SQL Support:
o Supped Performance and Reliability:
o Easy use:
o Free Support:
o Cross-platform:

 Running the mysql client:

Fire up the mysql client by issuing the following command prompt:
>mysql –uUSER –pPASSWORD –Hhost
mysql>show databases
mysql>use MYSQL_DATABASE
mysql>show tables
 PHP MySQL connection:
Mysql_connection()
$link_id = mysql_connection(“localhost”,”USER”,”PASSWORD”);
Mysql_select_db()
Mysql_select_db(“MYSQL_DATABASE”,$link_id);
4. Entity Relationship Diagram
5. Data Flow Diagram
 6. SPECIFIC REQUIREMENTS
6.1 Database Model
6.1.1 Database Design:
The figure below provides a visual representation of Entity Relationship i.e.
the relationships between the tables used to store data of the online
Directory system. Database name is “onlinedir”.

6.1.2 Database Report:

Fully normalized table structures together with a detailed description of
each table column used in the online Directory system follows:
Table Definition:
Table Name: my_admin
Primary Key: admin_id
Column Definition:
Column Name Data Type Allow Null Comments
admin_id int(11) No
password varchar(255) No
email varchar(255) No
paypal_id varchar(255) No
contact_no bigint(20) No
admin_name varchar(255) No
admin_position varchar(255) No
admin_image text No
admin_details text No
admin_address text No
status enum('1', '0') No 1=Active, 0=Inactive
Table Description:
Column Name Description

admin_id It is the unique id for an admin.

password Password for administrative login.
email Admin email id.
paypal_id Admin PayPal id for get payment from the website.
contact_no Admin contact no.
admin_name Admin name.
admin_position Admin position i.e. he/she is owner or staff.
admin_image Admin image.
admin_details Admin personal details.
admin_address Admin address.
status Admin is active or inactive.
Explanation: This table is a lookup table, which stores the admin’s login id,
password and details.
Table Definition:
Table Name: my_content
Primary Key: id
Column Definition:
Column Type Null Comments
id int(11) No
page_title varchar(255) No
content_title varchar(255) No
content text No
status enum('1', '0') No 1=Active 0=Inactive
created_on date No
created_by int(11) No
Table Description:
Column Description
id It holds the unique id for all content.
page_title Page name where this content will be showed.
content_title Content title.
content Content details.
status This content is active or in active.
created_on Creation date.
created_by Created by which admin.
Explanation: This table is a lookup table, which stores the website extra
content and details which is provide from admin panel.

Table Definition:
Table Name: my_sitesetup
Primary Key: site_id
Column Definition:
Column Type Null Comments
site_id int(11) No
site_name varchar(255) No
site_email varchar(255) No
site_contact bigint(20) No
site_address text No
site_moto varchar(255) No
site_path varchar(255) No
site_author varchar(255) No
site_description text No
site_keyword text No
logo_image varchar(255) No
Table Description:
Column Type
site_id Unique id for this website.
site_name Site name.
site_email Website contact email.
site_contact Website contact no.
site_address Office address.
site_moto Tagline for this website.
site_path Path or Web address.
site_author Site Developer.
site_description Website details or metadata.
site_keyword Meta keyword for SEO.
logo_image Site logo.
Explanation: This table is a lookup table, which stores all the site
information,logo,site name including meta data and keyword.

Table Definition:
Table Name: my_ category
Primary Key: cat_id
Column Definition:
Column Type Null Comments
cat_id int(10) No
parent_cat_id varchar(255) No
main_cat_id int(10) No
cat_name varchar(255) No
cat_icon varchar(255) No
status enum('1', '0') No 1=Active 0=Inactive
Table Description:
Column Details
cat_id  Unique id for all categories.
parent_cat_id  Hierarchical path for a category.
main_cat_id  Root category of a sub category.
cat_name  Category title.
cat_icon  Specific font awesome icon for every category.
status This category is currently Active or Inactive.
Explanation: This table is a lookup table, which stores all category and sub
categories.

Table Definition:
Table Name: my_user
Primary Key: user_id
Column Definition:
Column Type Null Comments
user_id int(10) No
first_name varchar(255) No
last_name varchar(255) No
email varchar(255) No
email_verified enum('0', '1') No 0=not verified,1=verified
password text No
contact_no bigint(20) No
contact_no_verifie enum('0', '1') No 0=not verified,1=verified
d
user_img text No
date_of_birth varchar(255) No
date_of_joining varchar(255) No
gender enum('0', '1', '2') No 0=Male,1=Female,2=Others
add_street text No
add_city text No
add_pin int(10) No
add_state text No
add_country text No
add_lat text No
add_long text No
reffer_id text No
reffer_by text No
odc_count text No
ban_cause text No
status enum('0', '1') No 1="Active",0="Inactive"
Table Description:
Column Details
user_id  Unique user id for every user.
first_name  User first name.
last_name  User last name.
email  User email id. It must be unique for every user.
email_verified Email is verified or not.
password  Login password.
contact_no  User contact no. It must be unique for every user.
contact_no_verifie Contact no is verified or not.
d
user_img  User image or profile picture.
date_of_birth  User date of birth.
date_of_joining  Date of joining or registration in our website.
gender User gender.
add_street  User Street address.
add_city  User city address.
add_pin  User PIN code.
add_state  User State.
add_country  User Country.
add_lat  User Latitude that is generated from address.
add_long  User Longitude that is generated from address.
reffer_id  User referral id which can he/she use for promote our website.
reffer_by  If this user is registered from any one’s referral. Then it holds the
referral user id.
odc_count  Number of coin own by this user.
ban_cause  If this user profile deactivate. Then this field holds the banning
cause.
status User profile is active or  inactive.
Explanation: This table is a lookup table, which stores service provider
details.
Table Definition:
Table Name: my_user_service
Primary Key: service_id
Column Definition:
Column Type Nul Comments
l
service_id int(10) No
user_id int(10) No
service_name varchar(255 No
)
service_category int(10) No
service_parent_category text No
service_details text No
service_contact_no bigint(20) No
service_email varchar(255 No
)
service_website text No
service_time_from varchar(255 No
)
service_time_to varchar(255 No
)
service_charge text No
service_keyword text No
service_keyword_predefine text No
d
service_add_landmark varchar(255 No
)
service_add_street varchar(255 No
)
service_add_city varchar(255 No
)
service_add_state varchar(255 No
)
service_add_country varchar(255 No
)
service_add_pin varchar(255 No
)
service_add_lat varchar(255 No
)
service_add_long varchar(255 No
)
service_registration_date text No
ban_cause text No
service_status enum('0', No 1="Active",0="Inactive"
'1')
odc_alloted varchar(255 No
)
Table Description:
Column Details
service_id  Unique service id.
user_id  User id (Service provider id) whis is taken from “my_user”
table.This is the primary ke of “my_user” table.
service_name  Service name.
service_category  Service is in which category.
service_parent_category  Hierarchical path of this category.
service_details  Service details.
service_contact_no  Contact no which is very important.
service_email  Email id which is also very important.
service_website  Website if available.
service_time_from  Starting time of time duration.
service_time_to  Closing time of time duration.
service_charge  Charge for service.
service_keyword  Keyword defined by the user that is helpful to service
provider.
service_keyword_predefine  Some keyword which will be defined by the system.
d
service_add_landmark  Landmark or notable place from where the service is
provided.
service_add_street  Service Street address.
service_add_city  Service city address.
service_add_state  Service PIN code.
service_add_country  Service State.
service_add_pin  Service Country.
service_add_lat  Service Latitude that is generated from address.
service_add_long  Service Longitude that is generated from address.
service_registration_date  Date of service registration.
ban_cause   If this service deactivate. Then this field holds the banning
cause.
service_status This service is active or not.
odc_alloted  Coin allotted for a service to promote this service.
Explanation: This table is a lookup table, which stores the service details.

Table Definition:
Table Name: my_user_service_image
Primary Key: img_id
Column Definition:
Column Type Null Comments
img_id int(11) No
service_id int(11) No
service_image text No
Table Description:
Column Details
img_id  Unique id for every image.
service_id  Service id for which the image will be inserted. Service i is taken
from “my_user_service” table which is primary key in
 “my_user_service” table.
service_image  Service image.
Explanation: This table is a lookup table, which stores the service image.

Table Definition:
Table Name: my_user_service_review
Primary Key: review_id
Column Definition:
Column Type Null Comments
review_id int(11) No
service_id int(11) No
review_name varchar(255) No
review_contact bigint(20) No
review_email varchar(255) No
review_pic text No
review_star int(11) No
review_details text No
review_date text No
Table Description:
Column Details
review_id  Unique id for every review.
service_id  Service id for which the review is given. Service id is taken from
“my_user_service” table which is primary key in “my_user_service”
table.
review_name  Reviewer’s name.
review_contact  Reviewer’s contact no.
review_email Reviewer’s email.
review_pic  Reviewer’s picture if he/she is a registered user.
review_star  Rating by Reviewer.
review_details  Review details or comment.
review_date  Review given date.
Explanation: This table is a lookup table, which stores the review against
any service.

Table Definition:
Table Name: my_user_service_report
Primary Key: report_id
Column Definition:
Column Type Null Comments
report_id int(10) No
service_id int(10) No
reported_by int(10) No
report_cause text No
report_date text No
report_time text No
report_condition enum('1', '0') No 1=True 0=False
final_decision text No
status enum('1', '0') No 1=Active 0=Close
Table Description:
Column Details
report_id  Unique id for every report.
service_id  Service id for which the report is filed. Service id is taken from
“my_user_service” table which is primary key in “my_user_service”
table.
reported_by  This column hold id of the user who filed this report. User id is taken
from “my_user” table which is primary key in “my_user” table.
report_cause  Report cause.
report_date  Report Date.
report_time  Report time.
report_condition Decided by our support team that the report is valid or not.
final_decision  Final decision against this report.
status Report is solved or not.
Explanation: This table is a lookup table, which stores the report filing
information against any service.

Table Definition:
Table Name: my_user_service_upgrade
Primary Key: invoice_id
Column Definition:
Column Type Null Comments
invoice_id varchar(255) No
user_id int(11) No
contact_no bigint(20) No
transaction_id text No
item_name varchar(255) No
quantity varchar(255) No
ammount int(11) No
date_time text No
status enum('1', '0') No 1=Paid 0=Due
Table Description:
Column Details
invoice_id  Unique system generated invoice id for every transaction.
user_id  This column hold id of the user who bought coin. User id is taken
from “my_user” table which is primary key in “my_user” table.
contact_no  This column hold contact no of the user who bought coin. Contact no
is taken from “my_user” table.
transaction_id  This transaction return by PayPal.
item_name  Coin package name.
quantity  How much coin this user bought.
ammount  Price of this package.
date_time  Purchase time.
status Payment status (paid or unpaid).
Explanation: This table is a lookup table, which stores user coin buying
details.

Table Definition:
Table Name: my_support
Primary Key: support_id
Column Definition:
Column Type Null Comments
support_id int(11) No
support_subject varchar(255) No
support_name varchar(255) No
support_email varchar(255) No
support_contact_no bigint(20) No
support_msg text No
support_result text No
support_query_date text No
support_solve_date text No
status enum('1', '0') No 1=open 0=close
Table Description:
Column Details
support_id  Support token id.
support_subject  Subject.
support_name  Name of the user.
support_email  Email id of this user.
support_contact_no  Contact number of this user.
support_msg  Query details.
support_result  Solution by our support team.
support_query_date  Query date.
support_solve_date  Problem solving date.
status This token is open or close.
Explanation: This table is a lookup table, which stores the user query,
complains etc.

Table Definition:
Table Name: my_odc_manager
Primary Key: id
Column Definition:
Column Type Null Comments
id int(11) No
user_id int(11) No
service_id int(11) No
odc_count varchar(255) No
odc_type enum('1', '0') No 1=Earning,0=Expence
Table Description:
Column Comments
id  Unique id for coin earns or expense.
user_id  This column hold id of the user who earn or expense coin. User id is taken
from “my_user” table which is primary key in “my_user” table.
service_id  If user expense coin. Then this column holds the promoted service id.
Service id is taken from “my_user_service” table which is primary key in
“my_user_service” table.
odc_count  How much coin earns or expense.
odc_type Type of behavior that means coin earns or expense.
Explanation: This table is a lookup table, which stores the details of coin
buying and expensing.

7. Screen Shot
7.1 Database
Database Design

Table Admin
Table Site setup

Content Table
Category Table

User Table
 Service Table

Service Image Table

Service Review Table

Service Report Table

Service Upgrade Table

Support Table
 Coin Manager Table

8.2 Admin Panel

Login Page

Dashboard
Manage Admin Details
Manage Site Details
Manage Content
Manage Category
Manage User
Manage Service
Manage Report

Manage Order
Manage Support
8.2 User Panel
Welcome to Online Directory
 Search Result

Sub Category Listing

 Registration & Login

Account Management Dropdown

Edit Profile
Add new service

List of Services
Edit Service
Promote Service

Refer & Earn

Buy Coins for Upgrade
Pay Using PayPal
 Print Invoice

If payment cancelled
Coin manager
Service Details
Service Details-Information

Service Details-Review

Service Details-Direction

Service Details-Report
Our Support

FAQ
Multilingual
 8. Testing
Testing presents an interesting anomaly for the software developing. During
the earlier development phases, the engineer attempts to build software
from an abstract concept to a tangible implementation. Now comes testing
the engineer creates a series of test cases that are intended to “demolish”
the software that has been built.
Test Information Flow:
Information flow for testing follows the pattern described in figure below.
Two classes of input are provided to test process:
 A software configuration that includes a software requirements
specification, a design specification and source code.
 A test configuration that includes a test plan and procedure, any
testing tools that are to be used and test cases and their expected
results.

Test Case Design:

The design of tests for software and other engineered products can be as
challenging as the initial design of the product. Over the past decade a rich
variety of test case design methods have evolved for software. This method
provides the developer with a systematic approach of testing. Any
engineering product can be tested in one of two ways:
 Knowing the specified function that a product has been designed to
performed; tests can be conducted that demonstrate each function is
fully operational.
 Knowing the internal workings of a product, tests can be conducted to
ensure that “all the gears mesh” that is the internal operation of the
product performs according to specification and all internal
components have been adequately exercised.
A Software Testing Strategy:
The software engineering process may be viewed as a spiral, as illustrate in
figure below. Initially system engineering defines the roles of software and
leads to software requirements analyses. A strategy of software testing may
also be envisioned by moving outwards along the spiral of this figure. Unit
testing begins at the vortex of the spiral and concentrated on each unit of
the software as implemented in the source code. Testing processes by
moving outwards along the spiral to integration testing, where focus is on
the design and the construction of the software architecture. Taking another
terms outwards of the spiral, we encountered validation testing, where
requirements establish as part of software requirements analysis are
validated against the software that has been constructed. Finally we arrived
at system testing, where software and other system elements are tested as a
whole. To test computer software, we spiral out along streamlines that
broaden the scope of testing with each term.
Unit Testing:
Unit testing focuses verification effort on the smallest unit software design-
The module. Using the detailed design description as a guide, important
controlled paths are tested to uncovered errors within the boundary of the
module. The relative complexity of tests and the error detected as a result is
limited by constraints scope establish for unit testing.
Unit testing is normally considered an adjunct to coding step. After source
level code has been developed, reviews, and verified for correct syntax, unit
test case design begins. A review of design information provides guidance for
establishing test cases that are likely to uncover errors in each of the
categories discussed above. Each test case should be coupled with a set of
expected results.
Integration Testing:
A neophyte in the software world might ask a seemingly legitimate question
once ask modules have been unit tested: if they all work individually why do
you doubt that that will work when we put them together? The problem, of
course, is “putting them together”-interfacing. Data can be lost across an
interface; One module can have an inadvertent, adverse effect on another;
sub function , when combined, may not produce the desired major function;
individually acceptable imprecision may be magnified to unacceptable level;
global data structures can present problems.
Top-Down Integration:
Top-down integration is an incremental approach to the construction of
program structure. Modules are integrated by moving down ward through
the control hierarchy, beginning with a main control module. A top-down
integration strategy may be implemented with the following steps:
The main controlled module is used as a test driver and stubs are substitute
for all module.
The main controlled module is used as a test driver and stubs are substitute
for all module. Depending on the integration approach selected,
subordinates stubs are replaced one at the time with actual modules.
 Tests are conducted as each module is integrated.
 On the completion of each set of tests, another stub is replaced with
the real module
 Regression testing may be conducted to ensure that new errors have
not been introduced.
Bottom-Up Integration:
Bottom-Up integration testing, as its name implies, begins construction and
testing with atomic modules. A bottom-up integration strategy may be
implemented with the following steps:
 Low level modules are combined into a cluster that performed a
specific software sub function
 A driver is written to co-ordinate test case input and output.
 The cluster is tested
 Drivers are removed and clusters are combined moving upwards in
the program structure.
Validation Testing:
At the culmination of integration testing, software is completely assembled
as a package, interfacing errors have been uncovered and corrected and a
final series of software tests- Validation Testing may begin. Software
validation is achieved through a series of black box test that demonstrate
conformity with requirements. After each validation test case has been
conducted, one of two possible conditions exists:
 The function of performance characteristics conforms to specification
and are accepted, or
 A deviation from specification is uncovered and a deficiency lists is
created.
Alpha and beta testing:
It is a virtually impossible for software developer to foresee how the
customer will really use a program. Instructions for use may be
misinterpreted; strange combination of data may be regularly used; output
that seemed clear to the tester may be unintelligible to a user in the field.

The alpha test is conducted at developer’s site by a customer. More software

product builders use a process called alpha and beta testing to uncovered
errors that only end users seems able to find.

System Testing:
At the beginning, we stressed the fact that software is only one element of a
larger computer-based system. A classic system problem is “finger pointing”.
This occurs when a defect is uncovered, and one system element developer
blames another for the problem. Rather than indulging in such nonsense,
the software engineer should anticipate potential interfacing problem and
 Design error handling paths that test all information coming from
other elements of the system;
 Conduct a series of tests that simulate bad data or other potential
errors at the software interface;
 Record the results of test to use as “evidence” if finger pointing does
occur;
 Participate in the planning and designing of the system tests to ensure
that software is adequately tested.
System testing is actually a series of different tests whose primary purpose
is fully exercised the computer based system.
 9. Maintenance
The last part of our system development life cycle is system maintenance,
which is actually the implementation of the post-implementation review
plan. Maintenance is the enigma of system development. It holds the
software industry captive, tying up programming resources. When system is
installed, it is generally used for long periods. The average life of a system is
4 or 6 years, with oldest application often in use for over 10 years. However,
this period of use brings with it the need to continually maintain the system.
There is also a need of time-to-time maintenance of this Online Directory
System according to the requirement of the correction house staff and
management. Analyst and programmers spend far more time maintaining
programs than they do writing them.
The study on the maintenance requirement for the information system
reveals the following three facts:
 50 to 70 per cent of the overall cost of software during the life of
system is spent on maintenance.
 In documented cases, the cost of maintenance, when measured on the
basis of writing each instruction in coding form, is more than 50 times
the cost of developing a system.
 The software demand is increasing at faster rate than supply. Many
programmers are devoting more time on systems maintenance than
on new software development. There is a backlog of new development
work.
Most programmers view maintenance as low-level drudgery. After they
develop an application, they spend years locked into maintaining it.
Eventually, boredom sets in, with subsequent turnover and loss of expertise
necessary to maintain the system. It is obvious that the more carefully a
system is thought out and developed, with attention paid to external
influence over a reasonable lifetime, the less maintenance will be required.
Classification of Maintenance:
Maintenance can be classified as corrective, adaptive or perfective.
Corrective maintenance means repairing processing or performance failures
or making changes because of previously uncorrected problems or false
assumptions. Adaptive maintenance means changing the program function.
Perfective maintenance means enhancing the performances or modifying the
program(s) to respond to the user’s additional or changing needs. Of these
types, more time and money are spent on perfective than on corrective and
adaptive maintenance together.
Maintenance covers a wide range of activities, including corrective coding
and design errors, updating documentation and test data, and upgrading
user support. Maintenance means restoring something to its original
condition. Unlike hardware, software does not wear out, it is corrected.
Although software does not wear out like a piece of hardware, it “ages” and
eventually fails to perform because of cumulative maintenance. Over time,
the integrity of the program, test data and documentation degenerates as a
result of modifications. Eventually, it takes more effort to maintain the
application then to rewrite it.
A major problem with software maintenance is its labor-intensive nature
and therefore the likelihood of errors. For example, if a change is occurred in
the code then altering the code, no matter how slight, must be manually
introduced into each program because there is no easy way of making sure
that the changes will interface with all the programs. Reusing the old codes
depends heavily on the programmer’s ability to judge what code can and
cannot be reused. It is an error-prone process that is still perceived by many
as more cost effective than writing programs from scratch.
Primary Activities of a Maintenance Procedure:
Maintenance activities begin where conversion leaves off. Maintenance is
handled by the same planning and control used in a formal system project.
The following Figure shows the basic activities. Documentation is as much
part of maintenance as it is of system development.
Briefly, the maintenance staff receives a request for service from an
authorized user, followed by a definition of the required modifications. The
source program and written procedures for the system are acquired from the
programming library. Program changes are then tested and submitted to
the user for approval. Once approved, the modified documentation is filed
with the library and project completion notice is sent to the user, signaling
the termination of the project.

Reducing Maintenance Cost:

The keys to reduce the need for maintenance while making it possible to
carry on with essential tasks more efficiently are as follows:
 We have to define the user’s requirement more accurately during
systems development.
 We have to prepare the system documentation in a better way.
 We have to use more effective ways to design processing logic and
communicating it to project team leaders.
 We have to make the better use of existing tools and techniques.
 We should manage the systems engineering process effectively.

Request for systems service

2

Requestin Submissi
System and program documentation
g system on of test
and results
programd for user
ocumenta approval
Return of
Specifying Modification requirements
modified
tion
required documentati
modificatio on to library
n
Acquiring
source
Source program statement printout Project completion notice
Notification
program to the user of
statement project
printout completion
from library
Making
required
changes to
programsan
d systems

Testing
of
changes
1

Fig: Primary Activities of a Maintenance Procedure

Advantages:
 This system is cost effective because no Printing or Distribution
expenses for question papers.
 This system is highly secure. Maintain confidentiality and avoid paper
leaks.
 No data loss even in situation of power and internet failure.
 Users can view the exam results immediately after the exam. Option
to display the feedback for correct answers.
 Users can take exams as per their convenience. Exams can be
configured for 24X7 availability.
 You will be saving a substantial amount of paper by using online
mode of exams. Prevent the use of paper and save the planet.

Limitations:
 Certificate cannot generate in this exam system.
 User cannot see the answer instantly.
 Administrator cannot give the diagram for the corresponding
questions.

BIBLIOGRAPHY
The following books were very helpful during the completion of project.

 Software engineering
-K K Aggarwal and Yogesh Singh.
 Web Enable Commercial Application development
-Ivan Bayrowss.
 Head First Servlets and JST.
-Bryan Basham, Kathysierres and Bert Bates.