HOTEL MANAGEMENT SYSTEM

A PROJECT REPORT

Under the guidance of Mr. BALA SUBRAMANYAM

FACULTY in INDIAN INSTITUTE OF HOTEL MANAGEMENT, Hyderabad,

_____________________________________________
Submitted by SUNEETHA BNCK LAKHAMRAJU
_____________________________________________

in partial fulfillment of the requirement

for the award of the degree

Of

MBA IN Information Systems

JANUARY - 2013

Page 1
 ACKNOWLEDGEMENT

I express thanks and gratitude to my family members and friends without whose uncontained

support; I could not have made career in MBA IT.

I wish to place on my record my deep sense of gratitude to my project guide, Mr. BALA

SUBRAMANYAM, Faculty in Indian Institute of Hotel Management, Hyderabad for his

constant motivation and valuable help through the project work. Express my gratitude to

Mr. G. PRAVEEN KUMAR, Director of ACME COLLEGE Institute of INFORMATION

TECHNOLOGY for his valuable suggestions and advices throughout the MBA IT course. I also

extend my thanks to other Faculties for their Cooperation during my Course.

Finally I would like to thank my friends for their cooperation to complete this project.

Page 2
 BONAFIDE CERTIFICATE

Certified that this project report titled “HOTEL MANAGEMENT SYSTEM”

is the bonafide work of “ LAKHAM RAJU BNCK SUNEETHA” who carried

out the project work under my supervision.

SIGNATURE SIGNATURE

HEAD OF THE DEPARTMENT FACULTY IN CHARGE

Mr. G. PRAVEEN KUMAR Ms. S. MADHAVI

ACME College, Hyderabad ACME College, Hyderabad

Page 3
 ABSTRACT
“HOTEL MANAGEMENT SYSTEM” deals with providing all the facilities of a
hotel in an easier way. The clients can gain information about the hotel through the
website. They can get the view of the hotel with the click of a mouse. The clients
can also book the rooms or halls online.

In the conventional system, clients had to go to the site and book their rooms. The
information they get would be based on the word of mouth of the staff. The
information provided in the new system is more reliable.

The administrator will be updating all the details and the authorized user will login
and book rooms or halls as per his requirements. This system provides ease and
security while making transactions.

Page 4
 CONTENTS
No. Topics Page No.

1.0 HOTEL MANAGEMENT 7

1.1 Modules of the application 7
2.0 HARDWARE AND SOFTWARE REQUIREMENTS 9
2.1 Hardware Requirements 9
2.2 Software Requirements 9
2.3 Functional Specification 11
2.4 Product Design Specification 12
2.5 Design Brief 12
2.6 Design Specification 13
3.0 REQUIREMENT ANALYSIS 15
3.1 Types of requirements 16
3.2 Software Development process 18
3.3 Software Development Activities 19
3.4 Planning 20
3.5 Deployment and maintenance 21
3.6 Specification & Description Languages 21
3.7 System Requirements 23
3.8 Hardware Requirements 23
3.9 Architecture 24
3.10 System Analysis & Design 28
3.11 Different Phases of DLC 29

Page 5
No. Topics Page No.

4.0 JAVA SERVER PAGES 36

5.0 ORACLE 39
5.1 Applications 39
5.2 Advantages & Disadvantages of Oracle 45
6.0 HTML 47
7.0 DESIGN 49
7.1 Data Flow Diagrams 49
7.1.1 Login 49
7.1.2 Booking 49
7.1.4 Restaurant 50
7.1.5 Tourism 50
7.2 UML Diagrams 51
7.2.1 Class Diagram 52
7.2.2 Use case diagram 53
7.2.3 Object diagram 53
7.2.4 Collaboration diagram 54
7.2.5 Activity Diagram 58
8.0 SCREEN SHOTS 59
9.0 TABLES 69
10.0 SAMPLE CODE 73
11.0 CONCLUSION 77
12.0 BIBLIOGRAPHY 78

Page 6
1.0 HOTEL MANAGEMENT SYSTEM
System Description: This project deals with creating and managing a website for a hotel.
It gives all the details of the hotel and provides various functions of a client.

User Characteristics: Administrator and Client

Administrator : The administrator maintains all the information about the rooms, halls
and users in different tables. The administrator has the privileges to make changes to the
above mentioned tables.

Client : The client is the one visiting the website and gaining information regarding the
hotel. The client has the flexibility to book the rooms or halls as per his requirements.
The client has various functions.

1.1 Modules of the application:

1) About us
2) Login
3) Registration
4) Booking
5) Restaurants
6) Function halls
7) Tourism
8) Feedback
9) Gallery

 About us :
In this module, we provide basic information about the hotel and a general overview
of what’s in the website. This helps the client to know more about the hotel.

 Login :
In this module, a registered user can login to book rooms or halls. A user once logged
in must log out before closing the window.

 Registration :
A user must login to book rooms or halls and only registered user can login. A
registered user gets many facilities like special offers and latest news through mail.
The details of every user registered are stored in a table.

Page 7
 Booking :
This module provides booking facilities. The clients can book rooms as per their
requirements only after logging in. The details of the rooms are stored in a table. The
user selects a room and after booking, the details of the user is stored along with the
rooms.

 Restaurants :
Here, the clients can view the menu card which is stored in a database along with
other details like the amount. The clients can also ask for home delivery.

 Function halls :
This module provides event management. The clients select a hall based on the
number of people, type of event and time of event. The details of the function halls
are stored in the database. After booking, the details of the client are stored along
with the function halls.

 Tourism :
This module provides an extra feature. The hotel provides details about the climate
and weather conditions of the city and the roadmap to the hotel. It also provides
details of various tourist spots and shopping sites in the city.

 Feedback :
Every organization needs to know what its clients think about them. This is helpful in
improvisation. In this module, the hotel asks for feedback from the clients after they
have logged in. The type of questions asked is based upon the service used by the
client. This is also purely online.

 Gallery :
In this module, the client can view the photos of the infrastructure of the hotel. The
client will also get to know the awards and recognitions received by the hotel in
various fronts.

Page 8
2.0 HARDWARE & SOFTWARE REQUIREMENTS

2.1 Hardware Requirements

 PIII 500MHZ or above
 128MB RAM or above
 2 GB Hard disk space.

2.2 Software Requirements

 Operating system: WINDOWS XP
 Front-end: JSP
 Back-end: Oracle 10g
 JAVA1.4
 TOMCAT
 OJDBC
Software requirements are a sub-field of Software Engineering that deals with the
elicitation, analysis, specification, and validation of requirements for software.

Software requirements specification (SRS) is a complete description of the behavior of

the system to be developed. It includes a set of use cases that describe all of the
interactions that the users will have with the software. Use cases are also known
as functional requirements. In addition to use cases, the SRS also contains nonfunctional
(or supplementary) requirements. Non-functional requirements are requirements which
impose constraints on the design or implementation (such as performance requirements,
quality standards, or design constraints).

Recommended approaches for the specification of software requirements are described

by IEEE 830-1998. This standard describes possible structures, desirable contents, and
qualities of a software requirements specification.

The software requirement specification (SRS) document generates all necessary

requirements for project development. To derive the requirements we need to have clear
and thorough understanding of the products to be developed. This is prepared after
detailed communications with project team and the customer.

Page 9
An SRS clearly defines the following:

 External interfaces of the system: They identify the information which is to flow
'from and to' the system.
 Functional and nonfunctional requirements of the systems. They stand for the finding
of run-time requirements.
 Design constraints.

Stages:

 Functional specification
 Product design specification
 Requirements analysis
 Software development process
 Specification(technical standard)
 Specification and description language
 System requirements
 Verification and validation

Page 10
2.3 Functional specification

A functional specification (also, functional spec, specs, functional specifications

document (FSD), or Program specification) in systems engineering and software
development is the documentation that describes the requested behavior of an
engineering system. The documentation typically describes what is needed by the system
user as well as requested properties of inputs and outputs (e.g. of the software system).

In systems engineering a specification is a document that clearly and accurately describes

the essential technical requirements for items, materials, or services including the
procedures by which it can be determined that the requirements have been met.
Specifications help avoid duplication and inconsistencies, allow for accurate estimates of
necessary work and resources, act as a negotiation and reference document for
engineering changes, provide documentation of configuration, and allow for consistent
communication among those responsible for the eight primary functions of Systems
Engineering. They provide a precise idea of the problem to be solved so that they can
efficiently design the system and estimate the cost of design alternatives. They provide
guidance to testers for verification (qualification) of each technical requirement.

A functional specification does not define the inner workings of the proposed system; it
does not include the specification how the system function will be implemented. Instead,
it focuses on what various outside agents (people using the program, computer
peripherals, or other computers, for example) might "observe" when interacting with the
system.

Purpose: There are many purposes for functional specifications. One of the primary
purposes on team projects is to achieve some form of team consensus on what the
program is to achieve before making the more time-consuming effort of writing source
code and test cases, followed by a period of debugging. Typically, such consensus is
reached after one or more reviews by the stakeholders on the project at hand after having
negotiated a cost-effective way to achieve the requirements the software needs to fulfill.

Page 11
 Process: In the ordered industrial software engineering life-cycle (waterfall model),
functional specification describes what has to be implemented. The next system
specification document describes how the functions will be realized using a chosen
software environment. In not industrial, prototypical systems development, functional
specifications are typically written after or as part of requirements analysis.
When the team agrees that functional specification consensus is reached, the functional
spec is typically declared "complete" or "signed off". After this, typically the software
development and testing team write source code and test cases using the functional
specification as the reference. While testing is performed the behavior of the program is
compared against the expected behavior as defined in the functional specification.

2.4 Product design specification

A product design specification (PDS) is a statement of what a not-yet-designed product
is intended to do. Its aim is to ensure that the subsequent design and development of a
product meets the needs of the user. The PDS acts as an initial boundary in the
development of products.

PDS Vs Product specification:

The PDS is a specification of what is required but not the specification of the product
itself. Describing the actual product is done in the technical specification, once the
product has been designed. The difference is important since describing the product itself
at the stage of creating a PDS, effectively constrains the range of alternatives that are
considered during the design process.

PDS Vs Design brief:

The PDS evolves from the design brief. While the design brief outlines the design goal
and major constraints and considerations, the PDS goes further to determine the precise
limits for the full set of requirements in the product being designed.

2.5 Design Brief

A design brief is a comprehensive written document for a design project developed in
concert by a person representing the business need for design and the designer. The
document is focused on the desired results of design – not aesthetics.
Design briefs are an extremely important part of the functions
of companies and corporations, especially engineering firms.

Page 12
2.6 Design specification
A design specification provides explicit information about the requirements for a
product and how the product is to be put together. It is the most traditional kind of
specification, having been used historically in public contracting for buildings, highways,
and other public works, and represents the kind of thinking in which architects and
engineers have been trained. Its use is called for where a structure or product has to be
specially made to meet a unique need. For example, a design specification must include
all necessary drawings, dimensions, terms, and definitions of non-standard terms, and the
materials used must be described fully to include thickness, size, color, etc.

Specification : A specification is an explicit set of requirements to be satisfied by a

material, product, or service. Should a material, product or service fail to meet one or
more of the applicable specifications, it may be referred to as being out of specification;

A technical specification may be developed privately, for example by a corporation,

regulatory body, or military organization, or it may be developed by standards
organizations which often have more diverse input and usually develop
voluntary standards (Voluntary standards may become mandatory if adopted by a
government or business contract).

Sometimes the term specification is used in connection with a data sheet (or spec sheet).

A data sheet is usually used for technical communication to describe technical
characteristics of an item or product. It can be published by a manufacturer to help people
choose products or to help use the products.

Specifications can be of following types:

 Formal specification
 Program specification
 Functional specification
 Web service specification
 Document specification

Page 13
Formal specification:

A formal specification is a mathematical description of software or hardware that

may be used to develop an implementation. It describeswhat the system should
do, not (necessarily) how the system should do it. Given such a specification, it is
possible to use formal verificationtechniques to demonstrate that a candidate
system design is correct with respect to the specification. This has the advantage
that incorrect candidate system designs can be revised before a major investment
has been made in actually implementing the design. An alternative approach is to
use provably correct refinement steps to transform a specification into a design,
and ultimately into an actual implementation, that is correct by construction.

Program specification:
A program specification is the definition of what a computer program is expected
to do. It can be informal, in which case it can be considered as a blueprint or user
manual from a developer point of view, or formal, in which case it has a definite
meaning defined in mathematical or programmatic terms. In practice, most
successful specifications are written to understand and fine-tune applications that
were already well-developed, although safety-critical software systems are often
carefully specified prior to application development. Specifications are most
important for external interfaces that must remain stable.

Functional specification:
In software development, a functional specification (also, functional
spec or specs or functional specifications document (FSD)) is the set
of documentation that describes the behavior of a computer program or
larger software system. The documentation typically describes various inputs
that can be provided to the software system and how the system responds to
those inputs.

Web service specification:

Web services specifications are often under the umbrella of a quality management
system.
A quality management system (QMS) can be expressed as the organizational
structure, procedures, processes and resources needed to implement quality
management.
Document specification:
These types of documents define how a specific document should be written,
which may include, but is not limited to, the systems of a document naming,
version, layout, referencing, structuring, appearance, language, copyright,

Page 14
hierarchy or format, etc. Very often, this kind of specifications is complemented
by a designated template.

Page 15
3.0 REQUIREMENT ANALYSIS
Requirements analysis in systems engineering and software engineering, encompasses
those tasks that go into determining the needs or conditions to meet for a new or altered
product, taking account of the possibly conflicting requirements of the
various stakeholders, such as beneficiaries or users.

Requirements analysis is critical to the success of a development project.

Requirements must be documented, actionable, measurable, testable, related to identified
business needs or opportunities, and defined to a level of detail sufficient for system
design. Requirements can be architectural, structural,behavioral, functional, and non-
functional.
Conceptually, requirements analysis includes three types of activity:

 Eliciting requirements: the task of communicating with customers and users to

determine what their requirements are. This is sometimes also called requirements
gathering.
 Analyzing requirements: determining whether the stated requirements are unclear,
incomplete, ambiguous, or contradictory, and then resolving these issues.
 Recording requirements: Requirements might be documented in various forms,
such as natural-language documents, use cases, user stories, or process specifications.

Requirements analysis can be a long and arduous process during which many delicate
psychological skills are involved. New systems change the environment and relationships
between people, so it is important to identify all the stakeholders, take into account all
their needs and ensure they understand the implications of the new systems. Analysts can
employ several techniques to elicit the requirements from the customer. Historically, this
has included such things as holding interviews, or holding focus groups (more aptly
named in this context as requirements workshops) and creating requirements lists. More
modern techniques include prototyping, and use cases. Where necessary, the analyst will
employ a combination of these methods to establish the exact requirements of the
stakeholders, so that a system that meets the business needs is produced.

Page 16
3.1 Types of requirements
Requirements are categorized in several ways. The following are common
categorizations of requirements that relate to technical management.
Customer Requirements :
Statements of fact and assumptions that define the expectations of the system in terms of
mission objectives, environment, constraints, and measures of effectiveness and
suitability (MOE/MOS). The customers are those that perform the eight primary
functions of systems engineering, with special emphasis on the operator as the key
customer. Operational requirements will define the basic need and, at a minimum, answer
the questions posed in the following listing.

 Operational distribution or deployment: Where will the system be used?

 Mission profile or scenario: How will the system accomplish its mission
objective?
 Performance and related parameters: What are the critical system
parameters to accomplish the mission?
 Utilization environments: How are the various system components to be
used?
 Effectiveness requirements: How effective or efficient must the system be in
performing its mission?
 Operational life cycle: How long will the system be in use by the user?
 Environment: What environments will the system be expected to operate in
an effective manner?

Architectural Requirements:
Architectural requirements explain what has to be done by identifying the
necessary system architecture of a system.

Structural Requirements:
Structural requirements explain what has to be done by identifying the
necessary structure of a system.

Behavioral Requirements
Behavioral requirements explain what has to be done by identifying the
necessary behavior of a system.

Page 17
Functional Requirements:
Functional requirements explain what has to be done by identifying the necessary task,
action or activity that must be accomplished. Functional requirements analysis will be
used as the top level functions for functional analysis.

Non-functional Requirements:
Non-functional requirements are requirements that specify criteria that can be used to
judge the operation of a system, rather than specific behaviors.

Performance Requirements:
The extent to which a mission or function must be executed; generally measured in terms
of quantity, quality, coverage, timeliness or readiness. During requirements analysis,
performance (how well does it have to be done) requirements will be interactively
developed across all identified functions based on system life cycle factors; and
characterized in terms of the degree of certainty in their estimate, the degree of criticality
to system success, and their relationship to other requirements.

Design Requirements:
The “build to,” “code to,” and “buy to” requirements for products and “how to execute”
requirements for processes expressed in technical data packages and technical manuals.

Derived Requirements:
Requirements that are implied or transformed from higher-level requirement. For
example, a requirement for long range or high speed may result in a design requirement
for low weight.

Allocated Requirements:
A requirement that is established by dividing or otherwise allocating a high-level
requirement into multiple lower-level requirements. Example: A 100-pound item that
consists of two subsystems might result in weight requirements of 70 pounds and 30
pounds for the two lower-level items.

Page 18
3.2 Software Development Process
A software development process, also known as a software development lifecycle, is a
structure imposed on the development of a software product. Similar terms
include software life cycle and software process. There are several models for such
processes, each describing approaches to a variety of tasks or activities that take place
during the process. Some people consider a lifecycle model a more general term and a
software development process a more specific term. For example, there are many specific
software development processes that 'fit' the spiral lifecycle model.

The large and growing body of software development organizations implement process

methodologies. Many of them are in the defense industry, which in the U.S. requires a
rating based on 'process models' to obtain contracts.

Page 19
 The international standard for describing the method of selecting, implementing and
monitoring the life cycle for software is ISO 12207.

A decades-long goal has been to find repeatable, predictable processes that improve
productivity and quality. Some try to systematize or formalize the seemingly unruly task
of writing software. Others apply project management techniques to writing software.
Without project management, software projects can easily be delivered late or over
budget. With large numbers of software projects not meeting their expectations in terms
of functionality, cost, or delivery schedule, effective project management appears to be
lacking.

Organizations may create a Software Engineering Process Group (SEPG), which is the

focal point for process improvement. Composed of line practitioners who have varied
skills, the group is at the center of the collaborative effort of everyone in the organization
who is involved with software engineering process improvement.

3.3 Software Development Activities

Page 20
3.4 Planning

The important task in creating a software product is extracting

the requirementsor requirements analysis. Customers typically have an abstract idea of
what they want as an end result, but not what software should do. Incomplete,
ambiguous, or even contradictory requirements are recognized by skilled and experienced
software engineers at this point. Frequently demonstrating live code may help reduce the
risk that the requirements are incorrect.

Once the general requirements are gathered from the client, an analysis of the scope of
the development should be determined and clearly stated. This is often called a scope
document.

Certain functionality may be out of scope of the project as a function of cost or as a result
of unclear requirements at the start of development. If the development is done
externally, this document can be considered a legal document so that if there are ever
disputes, any ambiguity of what was promised to the client can be clarified.

Implementation, testing and documenting:

Implementation is the part of the process where software engineers actually program the
code for the project.

Software testing is an integral and important part of the software development process.
This part of the process ensures that defects are recognized as early as possible.

Documenting the internal design of software for the purpose of future maintenance and
enhancement is done throughout development. This may also include the writing of
an API, be it external or internal. It is very important to document everything in the
project.

Page 21
3.5 Deployment and maintenance

Deployment starts after the code is appropriately tested, is approved for release and sold

or otherwise distributed into a production environment.

Software Training and Support is important and a lot of developers fail to realize that. It
would not matter how much time and planning a development team puts into creating
software if nobody in an organization ends up using it. People are often resistant to
change and avoid venturing into an unfamiliar area, so as a part of the deployment phase,
it is very important to have training classes for new clients of your software.

Maintaining and enhancing software to cope with newly discovered problems or new

requirements can take far more time than the initial development of the software. It may
be necessary to add code that does not fit the original design to correct an unforeseen
problem or it may be that a customer is requesting more functionality and code can be
added to accommodate their requests. If the labor cost of the maintenance phase exceeds
25% of the prior-phases' labor cost, then it is likely that the overall quality of at least one
prior phase is poor. In that case, management should consider the option of rebuilding the
system (or portions) before maintenance cost is out of control.

3.6 Specification and Description Language

The Specification and Description Language covers five main aspects: structure,
communication, behavior, data, and inheritance. The behavior of components is
explained by partitioning the system into a series of hierarchies. Communication between
the components takes place with through gates connected by channels. The channels are
of delayed channel type, so communication is usually asynchronous, but when the delay
is set to zero (that is, no delay) the communication becomes synchronous.

Page 22
The first version of the language was released in 1976 using graphical syntax (SDL-76).
This was revised in 1980 with some rudimentary semantics (SDL-80). The semantics
were refined in 1984 (SDL-84), the textual form was introduced for machine processing
and data was introduced. In 1988, SDL-88 was released with a formal basis for the
language: an abstract grammar as well as a concrete grammar and a full formal definition.
The version released in 1992 (SDL-92) introduced object oriented concepts such as
inheritance, abstract generic types etc. with the object-oriented features described by
transformations into non-object oriented ones. SDL-2000 (initially released 1999) is the
latest version completely based on object-orientation, rather than description by
transformations. This version has had maintenance updates since 1999 and is
accompanied by a UML-Profile: ITU-T Recommendation Z.109 (06/07), SDL-2000
combined with UML

The Hierarchy level of SDL is structured as follows.

 Library package
 System agent
 Block agent
 Process agent
 Procedure type
 Remote procedure

Usually a system agent consists of a number of block agents. Block agent communicate
with each other using channels. A block agent consists of process agents (the required
structure in SDL-92; SDL-2000 is more flexible). Each process agent is a state machine
that contributes to the action carried out by the system. A message stimulus from the
environment or another agent to an agent is called a signal. Signals received by a process
agent are first placed in a queue (the input port). When the state machine is waiting in a
state, if the first signal in the input port is enabled for that state it starts a transition
leading to another state. Transitions can output signals to other agents or to the
environment. A process agent is allowed to contain procedure types so that the same
actions can be invoked from different places. It is also allowed to call a remote procedure
type to invoke a procedure in another agent (or even another system) and wait for a
response.

Page 23
 SDL tools:
The most well-known SDL modeling tool is Telelogic Tau. Other commercial tools
available in the market are Object Geode, Cinderella, Safire-SDL, PragmaDev which
support both SDL and SDL-RT. SDL-RT is used to develop real-time and embedded
software. There are some open source projects relative to SDL modeling like JADE
which is a JAVA based specification environment.

3.7 System Requirements

To be used efficiently, all computer software needs certain hardware components or other

software resources to be present on a computer. These pre-requisites are known as
(computer) system requirements and are often used as a guideline as opposed to an
absolute rule. Most software defines two sets of system
requirements: minimum and recommended. With increasing demand for higher
processing power and resources in newer versions of software, system requirements tend
to increase over time. Industry analysts suggest that this trend plays a bigger part in
driving upgrades to existing computer systems than technological advancements.

Recommended system requirements:

Recommended system requirements are often suggested by software vendors for optimal

performance of a software. Although not a necessity, this set of requirements is often
sought after by power users who expect to gain a better experience of software usability.
Recommended System Requirements do not promise best possible performance of a
software and are treated as more of a guideline than a rule. Almost always a better
system is available, or will be in future, to provide better performance. Also, exceeding
by far these requirements does not guarantee to the user that everything will run with
absolute smoothness and look its best. More often than not, games are a bit disappointing
in this respect, presenting issues that may or may not be corrected with future
modifications.

3.8 Hardware Requirements

The most common set of requirements defined by any operating system or software

application is the physical computer resources, also known as hardware, A hardware
requirements list is often accompanied by a hardware compatibility list (HCL),
especially in case of operating systems. An HCL lists tested, compatible, and sometimes
incompatible hardware devices for a particular operating system or application. The
following sub-sections discuss the various aspects of hardware requirements.

Page 24
3.9 Architecture
All computer operating systems are designed for a particular computer architecture. Most
software applications are limited to particular operating systems running on particular
architectures. Although architecture-independent operating systems and applications
exist, most need to be recompiled to run on a new architecture. See also a list of common
operating systems and their supporting architectures.

Processing power:
Degree of popularity, and are often The power of the central processing unit (CPU) is a
fundamental system requirement for any software. Most software running on x86
architecture define processing power as the model and the clock speed of the CPU. Many
other features of a CPU that influence its speed and power, like bus speed, cache,
and MIPS are often ignored. This definition of power is often erroneous,
as AMD Athlon and Intel PentiumCPUs at similar clock speed often have different
throughput speeds. Intel Pentium CPUs have enjoyed a considerable mentioned in this
category.

Memory:
All software, when run, resides in the random access memory (RAM) of a computer.
Memory requirements are defined after considering demands of the application, operating
system, supporting software and files, and other running processes. Optimal performance
of other unrelated software running on a multi-tasking computer system is also
considered when defining this requirement.

Secondary Storage:
Hard-disk requirements vary, depending on the size of software installation, temporary
files created and maintained while installing or running the software, and possible use
of swap space (if RAM is insufficient).

Page 25
Display Adapter:
Software requiring a better than average computer graphics display, like graphics
editors and high-end games, often define high-end display adapters in the system
requirements.
Peripherals:
Some software applications need to make extensive and/or special use of
some peripherals, demanding the higher performance or functionality of such peripherals.
Such peripherals include CD-ROM drives, keyboards, pointing devices, network devices,
etc.

Software requirements:

Software Requirements deal with defining software resource requirements and pre-
requisites that need to be installed on a computer to provide optimal functioning of an
application. These requirements or pre-requisites are generally not included in the
software installation package and need to be installed separately before the software is
installed.

Platform:
In computing, a platform describes some sort of framework, either
in hardware or software, which allows software to run. Typical platforms include a
computer's architecture, operating system, or programming languages and
their runtime libraries.

Operating system is one of the first requirements mentioned when defining system
requirements (software). Software may not be compatible with different versions of same
line of operating systems, although some measure of backward compatibility is often
maintained. For example, most software designed for Microsoft Windows XP does not
run on Microsoft Windows 98, although the converse is not always true. Similarly,
software designed using newer features of Linux Kernel v2.6 generally does not run or
compile properly (or at all) on Linux distributions using Kernel v2.2 or v2.4.

Page 26
APIs and drivers:
Software making extensive use of special hardware devices, like high-end display
adapters, needs special API or newer device drivers. A good example is DirectX, which
is a collection of APIs for handling tasks related to multimedia, especially game
programming, on Microsoft platforms.

Page 27
Web browser:
Most web applications and software depending heavily on Internet technologies make use
of the default browser installed on system.Microsoft Internet Explorer is a frequent
choice of software running on Microsoft Windows, which makes use
of ActiveX controls, despite their vulnerabilities.

Verification and validation:

In software project management, software testing, and software engineering, Verification

and Validation (V&V) is the process of checking that a software system meets
specifications and that it fulfills its intended purpose. It is normally part of the software
testing process of a project. Also known as software quality control.

Validation checks that the product design satisfies or fits the intended usage (high-level
checking) — i.e., you built the right product. This is done through dynamic testing and
other forms of review.

According to the Capability Maturity Model ,

 Verification: The process of evaluating software to determine whether the products
of a given development phase satisfy the conditions imposed at the start of that phase.
 Validation: The process of evaluating software during or at the end of the
development process to determine whether it satisfies specified requirements.

In other words, validation ensures that the product actually meets the user's needs, and
that the specifications were correct in the first place, while verification is ensuring that
the product has been built according to the requirements and design specifications.
Validation ensures that ‘you built the right thing’. Verification ensures that ‘you built it
right’. Validation confirms that the product, as provided, will fulfill its intended use.

Page 28
From Testing Perspective:

 Fault - wrong or missing function in the code.

 Failure - the manifestation of a fault during execution.
 Malfunction - according to its specification the system does not meet its specified
functionality. Within the modeling and simulation community, the definitions of
validation, verification and accreditation are similar
 Validation is the process of determining the degree to which a model, simulation, or
federation of models and simulations, and their associated data are accurate
representations of the real world from the perspective of the intended use(s).
 Accreditation is the formal certification that a model or simulation is acceptable to be
used for a specific purpose.
 Verification is the process of determining that a computer model, simulation, or
federation of models and simulations implementations and their associate data
accurately represents the developer's conceptual description and specifications.

Test cases:
A test case is a tool used in the process.

Test cases are prepared for verification: to determine if the process that was followed
to develop the final product is right.

Test case are executed for validation: if the product is built according to the requirements
of the user. Other methods, such as reviews, are used when used early in the Software
Development Life Cycle provide for validation.

Independent verification and testing:

Verification and validation often is carried out by a separate group from the development
team; in this case, the process is called "Independent Verification and Validation".

Page 29
3.10 System Analysis and Design

Systems are created to solve problems. One can think of the systems approach as an
organized way of dealing with a problem. In this dynamic world, The subject System
Analysis and Design, mainly deals with the software

Defining A System

A collection of components that work together to realize some objective forms a system.

Basically there are three major components in every system, namely input, processing
and output.

In a system the different components are connected with each other and they are
interdependent.

For example, Human body represents a complete natural system. We are also bound by
many national systems such as political system, economic system, educational system
and so forth. The objective of the system demand that some output is produced as a
result of processing the suitable inputs.

Page 30
3.11 Different phases of Software Development Life Cycle

(a) System Study

System study is the first stage of system development life cycle. This gives a clear
picture of what actually the physical system is? In practice, the system study is
done in two phases. In the first phase, the preliminary survey of the system is
done which helps in identifying the scope of the system. The second phase of the
system study is more detailed and in-depth study in which the identification of
user’s requirement and the limitations and problems of the present system are
studied. After completing the system study, a system proposal is prepared by the
System Analyst (who studies the system) and placed before the user. The
proposed system contains the findings of the present system and
recommendations to overcome the limitations and problems of the present system
in the light of the user’s requirements.

System study phase passes through the following steps:

 problem identification and project initiation

 background analysis

 inference or findings

Page 31
(b) Feasibility Study

On the basis of result of the initial study, feasibility study takes place. The
feasibility study is basically the test of the proposed system in the light of its
workability, meeting user’s requirements, effective use of resources and .of
course, the cost effectiveness. The main goal of feasibility study is not to solve the
problem but to achieve the scope. In the process of feasibility study, the cost and
benefits are estimated with greater accuracy.

(c) System Analysis

Assuming that a new system is to be developed, the next phase is system analysis.

Analysis involved a detailed study of the current system, leading to specifications
of a new system. Analysis is a detailed study of various operations performed by
a system and their relationships within and outside the system.

During analysis, data are collected on the available files, decision points and
transactions handled by the present system. Interviews, on-site observation and
questionnaire are the tools used for system analysis. Using the following steps it
becomes easy to draw the exact boundary of the new system under consideration:

 Keeping in view the problems and new requirements

 Workout the pros and cons including new areas of the system

All procedures, requirements must be analysed and documented in the form of

detailed data flow diagrams (DFDs), data dictionary, logical data structures and
miniature specifications. System Analysis also includes sub-dividing of complex
process involving the entire system, identification of data store and manual
processes.

The main points to be discussed in system analysis are:

 Specification of what the new system is to accomplish based on the user

requirements.
 Functional hierarchy showing the functions to be performed by the new
system and their relationship with each other.
 Function network which are similar to function hierarchy but they highlight
the those functions which are common to more than one procedure.

(d) System Design

Based on the user requirements and the detailed analysis of a new system, the new
system must be designed. This is the phase of system designing. It is a most
crucial phase in the development of a system. Normally, the design proceeds in
two stages :-- Preliminary or general design & Structure or detailed design

Page 32
Preliminary or general design:

In the preliminary or general design, the features of the new system are specified.
The costs of implementing these features and the benefits to be derived are
estimated. If the project is still considered to be feasible, we move to the detailed
design stage.

Structure or Detailed design:

In the detailed design stage, computer oriented work begins in earnest. At this
stage, the design of the system becomes more structured. Structure design is a
blue print of a computer system solution to a given problem having the same
components and inter-relationship among the same components as the original
problem. Input, output and processing specifications are drawn up in detail. In the
design stage, the programming language and the platform in which the new
system will run are also decided.

There are several tools and techniques used for designing. These tools and
techniques are:

 Flowchart
 Data flow diagram (DFDs)
 Data dictionary
 Structured English
 Decision table
 Decision tree

(e) Coding

After designing the new system, the whole system is required to be converted into
computer understanding language. Coding the new system into computer
programming language does this. It is an important stage where the defined
procedure are transformed into control specifications by the help of a computer
language. This is also called the programming phase in which the programmer
converts the program specifications into computer instructions, which we refer
as programs. The programs coordinate the data movements and control the
entire process in a system. It is generally felt that the programs must be modular
in nature. This helps in fast development, maintenance and future change, if
required.

(f) Testing

Before actually implementing the new system into operations, a test run of the
system is done removing all the bugs, if any. It is an important phase of a
successful system. After codifying the whole programs of the system, a test plan
should be developed and run on a given set of test data. The output of the test run
should match the expected results.
Page 33
Using the test data following test run are carried out:

 Unit test
 System test

Unit test: When the programs have been coded and compiled and brought to working
conditions, they must be individually tested with the prepared test data. Any
undesirable happening must be noted and debugged (error corrections).

System Test: After carrying out the unit test for each of the programs of the system
and when errors are removed, then system test is done. At this stage the test is done
on actual data. The complete system is executed on the actual data. At each stage of
the execution, the results or output of the system is analysed. During the result
analysis, it may be found that the outputs are not matching the expected out of the
system. In such case, the errors in the particular programs are identified and are fixed
and further tested for the expected output.

When it is ensured that the system is running error-free, the users are called with their
own actual data so that the system could be shown running as per their requirements.

Each Module can be Tested using the following Two Strategies:

Black Box Testing:

In this strategy some test cases are generated as input conditions that fully execute all
functional requirements for the program. This testing has been uses to find errors in
the following categories:

 Incorrect or missing functions

 Interface errors
 Errors in data structure or external database access
 Performance errors
 Initialization and termination errors.

In this testing only the output is checked for correctness. The logical flow of the data
is not checked.

Page 34
White Box Testing: In this the test cases are generated on the logic of each module
by drawing flow graphs of that module and logical decisions are tested on all the
cases. It has been uses to generate the test cases in the following cases:

 Guarantee that all independent paths have been executed.

 Execute all logical decisions on their true and false sides.
 Execute all loops at their boundaries and within their operational
 Execute internal data structures to ensure their validity.

Integration Testing: Integration testing ensures that software and subsystems work
together as a whole. It tests the interface of all the modules to make sure that the
modules behave properly when integrated together.

System Testing: Involves in-house testing of the entire system before delivery to the
user. Its aim is to satisfy the user the system meets all requirements of the client’s
specifications.

Acceptance Testing: It is a pre-delivery testing in which entire system is tested at

client’s site on real world data to find errors.

Validation Testing: The system has been tested and implemented successfully and
thus ensured that all the requirements as listed in the software requirements
specification are completely fulfilled. In case of erroneous input corresponding error
messages are displayed.

Compiling Testing: It was a good idea to do our stress testing early on, because it
gave us time to fix some of the unexpected deadlocks and stability problems that
only occurred when components were exposed to very high transaction volumes.

Execution Test: This program was successfully loaded and executed. Because of
good programming there was no execution error.

Output Test: The successfully output screens are placed in the output screen section.

Page 35
(g) Implementation

After having the user acceptance of the new system developed, the
implementation phase begins.

Implementation is the stage of a project during which theory is turned into

practice. During this phase, all the programs of the system are loaded onto the
user's computer. After loading the system, training of the users starts.

Main topics of such type of training are:

 How to execute the package

 How to enter the data
 How to process the data (processing details)
 How to take out the reports

After the users are trained about the computerized system, manual working has to
shift from manual to computerized working. The following two strategies are
followed for running the system:

Parallel run: In such run for a certain defined period, both the systems i.e.
computerized and manual are executed in parallel. This strategy is helpful
because of the following:

 Manual results can be compared with the results of the computerized

system.
 Failure of the computerized system at the early stage, does not affect the
working of the organization, because the manual system continues to
work, as it used to do.

Pilot run: In this type of run, the new system is installed in parts. Some part of
the new system is installed first and executed successfully for considerable time
period. When the results are found satisfactory then only other parts are
implemented. This strategy builds the confidence and the errors are traced easily.

(h) Maintenance

Maintenance is necessary to eliminate errors in the system during its working life
and to tune the system to any variations in its working environment. It has been
seen that there are always some errors found in the system that must be noted and
corrected. It also means the review of the system from time to time.

The review of the system is done for:

 knowing the full capabilities of the system

 knowing the required changes or the additional requirements
 studying the performance

Page 36
 If a major change to a system is needed, a new project may have to be set up to
carry out the change.

The new project will then proceed through all the above life cycle phases.

WORKING:

Front end and back end are generalized terms that refer to the initial and the end stages
of a process.

The front end is responsible for collecting input in various forms from the user and
processing it to conform to a specification the back end can use. The front end is an
interface between the user and the back end.

Front-end and back-end are terms used to characterize program interfaces and services
relative to the initial user of these interfaces and services. (The "user" may be a human
being or a program.) A "front- end" application is one that application users interact with
directly. A "back-end" application or program serves indirectly in support of the front-
end services, usually by being closer to the required resource or having the capability to
communicate with the required resource. The back-end application may interact directly
with the front-end or, perhaps more typically, is a program called from an intermediate
program that mediates front-end and back-end activities.

FRONT END:

 Devices: Pc or client
 User requirement: access operational knowledge
 System requirement: operating system
 Software required: Java and Oracle 10G

Here we used Jsp as the Front End. We developed the code in Java Script.

JavaScript is THE scripting language of the Web. JavaScript is used in millions of Web
pages to add functionality, validate forms, detect browsers, and much more.

JavaScript is the most popular scripting language on the internet, and works in all major
browsers, such as Internet Explorer, Firefox, Chrome, Opera, and Safari.

Page 37
4.0 JAVA SERVER PAGE (JSP)

Java Server Pages technology is the Java technology in the J2EE platform for building
applications containing dynamic Web content such as HTML, DHTML, XHTML and
XML.

The Java Server Pages technology enables the authoring of Web pages that create
dynamic content easily but with maximum power and flexibility.

The Java Server Pages technology provides a textual description for the creation of a
response from a request.

Template Data:

Substantial portions of dynamic content are actually fixed. The JSP technology allow for
the natural manipulation of this data.

Addition of Dynamic Data:

The JSP technology allows the addition of dynamic data to the template data in a way
that is simple yet powerful.

Encapsulation of Functionality:

The JSP technology provides two related mechanisms for the encapsulation of
functionality: the standard Java Beans component architecture and the tag library
mechanism.

Good Tool Support:

The JSP technology has features that enable the creation of good authoring tools.The
result is a flexible and powerful server-side technology.

Benefits of the Java Server Pages Technology:

The Java Server Pages technology offers a number of benefits:

Write Once, Run Anywhere properties:

The Java Server Pages technology is platform independent, both in its dynamic Web
pages, Web servers, and its underlying server components. You can author JSP pages on
any platform, run them on any Web server or Web enabled application server, and access
them from any Web browser.

Page 38
Reuse of components and tag libraries:

The Java Server Pages technology emphasizes the use of reusable components such as
Java Beans components, Enterprise Java Beans components and tag libraries.

Support for scripting and actions

The Java Server Pages technology supports scripting elements as well as actions. Actions
permit the encapsulation of useful functionality in a convenient form that can also be
manipulated by tools; scripts provide a mechanism to glue together this functionality in a
per-page manner.

The Java Server Pages technology is an integral part of the Java 2 Platform Enterprise
Edition (J2EE), which brings Java technology to enterprise computing.

Page 39
It is true that both servlets and JSP pages have many features in common and can be used
for serving up dynamic web content. Naturally, this may cause some confusion as to
when to opt for one of the technologies over the other. Java Server Pages provide a much
cleaner separation of presentation from logic, and are simpler to write. Together, JSP
technology and servlets provide an attractive alternative to other types of dynamic web
scripting/programming that offers platform independence, enhanced performance,
separation of logic from display, ease of administration, extensibility into the enterprise
and most importantly, ease of us.

Page 40
5.0 ORACLE

Introduction to Oracle:
Oracle Database Architecture:

An Oracle database is a collection of data treated as a unit. The purpose of a database is

to store and retrieve related information. A database server is the key to solving the
problems of information management. In general, a server reliably manages a large
amount of data in a multiuser environment so that many users can concurrently access the
same data. All this is accomplished while delivering high performance. A database server
also prevents unauthorized access and provides efficient solutions for failure recovery.

Oracle Database is the first database designed for enterprise grid computing, the most
flexible and cost effective way to manage information and applications. Enterprise grid
computing creates large pools of industry-standard, modular storage and servers. With
this architecture, each new system can be rapidly provisioned from the pool of
components. There is no need for peak workloads, because capacity can be easily added
or reallocated from the resource pools as needed.

The database has logical structures and physical structures. Because the physical and

logical structures are separate, the physical storage of data can be managed without
affecting the access to logical storage structures.

5.1 Overview of Application Architecture

There are two common ways to architect a database: client/server or multitier. As internet
computing becomes more prevalent in computing environments, many database
management systems are moving to a multitier environment.

Client/Server Architecture
Multiprocessing uses more than one processor for a set of related jobs. Distributed
processing reduces the load on a single processor by allowing different processors to
concentrate on a subset of related tasks, thus improving the performance and capabilities
of the system as a whole.

An Oracle database system can easily take advantage of distributed processing by using
its client/server architecture. In this architecture, the database system is divided into two
parts: a front-end or a client, and a back-end or a server.
The Client

The client is a database application that initiates a request for an operation to be

performed on the database server. It requests, processes, and presents data managed by
the server. The client workstation can be optimized for its job. For example, it might not

Page 41
need large disk capacity, or it might benefit from graphic capabilities. Often, the client
runs on a different computer than the database server, generally on a PC. Many clients
can simultaneously run against one server.

The Server

The server runs Oracle software and handles the functions required for concurrent, shared
data access.

The server receives and processes the SQL and PL/SQL statements that originate from
client applications. The computer that manages the server can be optimized for its duties.
For example, it can have large disk capacity and fast processors.

Multitier Architecture:

Application Servers

A multitier architecture has the following components:

 A client or initiator process that starts an operation

 One or more application servers that perform parts of the operation. An application
server provides access to the data for the client and performs some of the query
processing, thus removing some of the load from the database server. It can serve as
an interface between clients and multiple database servers, including providing an
additional level of security.

 An end or database server that stores most of the data used in the operation

This architecture enables use of an application server to do the following:

 Validate the credentials of a client, such as a Web browser

 Connect to an Oracle database server

 Perform the requested operation on behalf of the client

If proxy authentication is being used, then the identity of the client is maintained
throughout all tiers of the connection.

Overview of Physical Database Structures

The following sections explain the physical database structures of an Oracle database,
including datafiles, redo log files, and control files.

Data files

Every Oracle database has one or more physical datafiles. The datafiles contain all the
database data.

Page 42
The data of logical database structures, such as tables and indexes, is physically stored in
the datafiles allocated for a database.

The characteristics of data files are:

 A datafile can be associated with only one database.

 Datafiles can have certain characteristics set to let them automatically extend when
the database runs out of space.

 One or more datafiles form a logical unit of database storage called a tablespace.

Data in a datafile is read, as needed, during normal database operation and stored in the
memory cache of Oracle. For example, assume that a user wants to access some data in a
table of a database. If the requested information is not already in the memory cache for
the database, then it is read from the appropriate datafiles and stored in memory.
Modified or new data is not necessarily written to a datafile immediately. To reduce the
amount of disk access and to increase performance, data is pooled in memory and
written to the appropriate datafiles all at once, as determined by the database writer
process (DBWn) background process.

Control Files

Every Oracle database has a control file. A control file contains entries that specify the
physical structure of the database. For example, it contains the following information:

 Database name
 Names and locations of datafiles and redo log files

 Time stamp of database creation

Oracle can multiplex the control file, that is, simultaneously maintain a number of

identical control file copies, to protect against a failure involving the control file.

Every time an instance of an Oracle database is started, its control file identifies the
database and redo log files that must be opened for database operation to proceed. If the
physical makeup of the database is altered (for example, if a new datafile or redo log file
is created), then the control file is automatically modified by Oracle to reflect the
change. A control file is also used in database recovery.

Archive Log Files

You can enable automatic archiving of the redo log. Oracle automatically archives log
files when the database is in ARCHIVELOG mode.

Page 43
Backup Files

To restore a file is to replace it with a backup file. Typically, you restore a file when a
media failure or user error has damaged or deleted the original file.

User-managed backup and recovery requires you to actually restore backup files before
you can perform a trial recovery of the backups.

Server-managed backup and recovery manages the backup process, such as scheduling of
backups, as well as the recovery process, such as applying the correct backup file when
recovery is needed.

Overview of Logical Database Structures

The logical storage structures, including data blocks, extents, and segments, enable
Oracle to have fine- grained control of disk space use.

Table spaces

A database is divided into logical storage units called tablespaces, which group related
logical structures together. For example, tablespaces commonly group together all
application objects to simplify some administrative operations.

Each database is logically divided into one or more tablespaces. One or more datafiles are
explicitly created for each tablespace to physically store the data of all logical structures
in a tablespace. The combined size of the datafiles in a tablespace is the total storage
capacity of the tablespace.

Every Oracle database contains a SYSTEM table space and a SYSAUX table space.

Oracle creates them automatically when the database is created. The system default is to
create a small file table space, which is the traditional type of Oracle table space.
The SYSTEM and SYSAUX table spaces are created as small file table spaces.

Oracle also lets you create big file table spaces. This allows Oracle Database to contain
table spaces made up of single large files rather than numerous smaller ones. This lets
Oracle Database utilize the ability of 64-bit systems to create and manage ultra large
files. The consequence of this is that Oracle Database can now scale up to 8 Exabyte’s in
size. With Oracle-managed files, big file table spaces make data files completely
transparent for users. In other words, you can perform operations on table spaces, rather
than the underlying data files.

Page 44
Oracle Data Blocks

At the finest level of granularity, Oracle database data is stored in data blocks. One data
block corresponds to a specific number of bytes of physical database space on disk. The
standard block size is specified by the DB_BLOCK_SIZE initialization parameter. In
addition, you can specify up to five other block sizes. A database uses and allocates free
database space in Oracle data blocks.

Extents

The next level of logical database space is an extent. An extent is a specific number of
contiguous data blocks, obtained in a single allocation, used to store a specific type of
information.

Tables

Tables are the basic unit of data storage in an Oracle database. Database tables hold all
user-accessible data. Each table has columns and rows. A table that has an employee
database, for example, can have a column called employee number, and each row in that
column is an employee's number.Indexes

Indexes 

Indexes are optional structures associated with tables. Indexes can be created to increase
the performance of data retrieval. Just as the index in this manual helps you quickly
locate specific information, an Oracle index provides an access path to table data. When
processing a request, Oracle can use some or all of the available indexes to locate the
requested rows efficiently. Indexes are useful when applications frequently query a table
for a range of rows (for example, all employees with a salary greater than 1000 dollars)
or a specific row. Indexes are created on one or more columns of a table. After it is
created, an index is automatically maintained and used by Oracle. Changes to table data
(such as adding new rows, updating rows, or deleting rows) are automatically
incorporated into all relevant indexes with complete transparency to the users.

Page 45
Views

Views are customized presentations of data in one or more tables or other views. A view
can also be considered a stored query. Views do not actually contain data. Rather, they
derive their data from the tables on which they are based, referred to as the base tables of
the views. Like tables, views can be queried, updated, inserted into, and deleted from,
with some restrictions. All operations performed on a view actually affect the base tables
of the view.Views provide an additional level of table security by restricting access to a
predetermined set of rows and columns of a table. They also hide data complexity and
store complex queries.

Clusters

Clusters are groups of one or more tables physically stored together because they share
common columns and are often used together. Because related rows are physically stored
together, disk access time improves.

How Oracle Works?

The following example describes the most basic level of operations that Oracle performs.
This illustrates an Oracle configuration where the user and associated server process are
on separate computers (connected through a network).

 An instance has started on the computer running Oracle (often called

the host or database server).
 A computer running an application (a local computer or client workstation) runs
the application in a user process.

 The client application attempts to establish aconnection to the server using the
proper Oracle Net Services driver.

 The server is running the proper Oracle Net Services driver. The server detects the
connection request from the application and creates a dedicated server process on
behalf of the user process.

 The user runs a SQL statement and commits the transaction. For example, the
user changes a name in a row of a table.

 The server process receives the statement and checks the shared pool for any
shared SQL area that contains a similar SQL statement. If a shared SQL area is
found, then the server process checks the user's access privileges to the requested
data, and the previously existing shared.

Page 46
 SQL area is used to process the statement. If not, then a new shared SQL area is allocated
for the statement, so it can be parsed and processed.

 The server process retrieves any necessary data values from the actual datafile (table)
or those stored in the SGA.
 The server process modifies data in the system global area. The DBWn process writes
modified blocks permanently to disk when doing so is efficient. Because the
transaction is committed, the LGWR process immediately records the transaction in
the redo log file.

 If the transaction is successful, then the server process sends a message across the
network to the application. If it is not successful, then an error message is
transmitted.

 Throughout this entire procedure, the other background processes run, watching for
conditions that require intervention. In addition, the database server manages other
users' transactions and prevents contention between transactions that request the
same data.

5.2 Advantages & Disadvantages of Oracle

Page 47
Page 48
6.0 HTML

Introduction to HTML

HTML, which stands for HyperText Markup Language, is the predominant language

for web pages. HTML is the basic building-blocks of webpages.

HTML is written in the form of HTML elements consisting of tags, enclosed in angle

brackets(like <html>), within the web page content. HTML tags normally come in pairs
like <h1> and </h1>. The first tag in a pair is the start tag, the second tag is the end
tag (they are also called opening tags and closing tags).

The purpose of a web browser is to read HTML documents and compose them into visual
or audible web pages. The browser does not display the HTML tags, but uses the tags to
interpret the content of the page.

HTML elements form the building blocks of all websites. HTML allows images and
objects to be embedded and can be used to create interactive forms. It provides a means
to create structured documents by denoting structural semantics for text such as headings,
paragraphs, lists, links, quotes and other items. It can embed scripts in languages such
as JavaScript which affect the behavior of HTML webpages.

Page 49
Web browsers can also refer to Cascading Style Sheets (CSS) to define the appearance
and layout of text and other material. The W3C, maintainer of both the HTML and the
CSS standards, encourages the use of CSS over explicitly presentational HTML markup.

HTML markup consists of several key components, including elements (and

their attributes), character-based data types, character references and entity references.
Another important component is the document type declaration, which triggers standards
mode rendering.

ELEMENTS:

HTML documents are composed entirely of HTML elements that, in their most general
form have three components: a pair of tags, a "start tag" and "end tag";
some attributes within the start tag; and finally, any textual and
graphical content between the start and end tags, perhaps including other nested elements.
The HTML element is everything between and including the start and end tags.
Each tag is enclosed in angle brackets.

The general form of an HTML element is therefore: <tag attribute1="value1"

attribute2="value2">content</tag>. Some HTML elements are defined as empty
elements and take the form <tag attribute1="value1" attribute2="value2" />. Empty
elements may enclose no content. The name of an HTML element is the name used in the
tags. Note that the end tag's name is preceded by a slash character, "/", and that in empty
elements the slash appears just before the closing >. If attributes are not mentioned,
default values are used in each case.

Hypertext features NOT in HTML:

HTML lacks some of the features found in earlier hypertext systems, such as typed
links, source tracking, fat links and others. Even some hypertext features that were in
early versions of HTML have been ignored by most popular web browsers until recently,
such as the link element and in-browser Web page editing.

Sometimes Web services or browser manufacturers remedy these shortcomings. For

instance, wikis and content management systemsallow surfers to edit the Web pages they
visit.

Page 50
7.0 DESIGN

7.1 Data Flow Diagrams

Page 51
Page 52
7.2 UML DIAGRAMS

7.2.1 Class Diagram

Page 53
7.2.2 Use Case Diagram

Page 54
7.2.3 Object Diagram:

Page 55
7.2.4 Collaboration and Sequence Diagrams:

Function Halls:

Page 56
Rooms:

Page 57
Restaurant:

Page 58
Page 59
7.2.5 Activity Diagram

Page 60
8.0 SCREENSHOTS

HOME PAGE:

This gives the overall description of the hotel. Its latest news and various links redirected. The
Hotel’s map is also provided along with Photogallery.

Page 61
LOGIN PAGE:

Login page are for the security purpose. The Login page consists of username and password. On
entry of data it gets validated. It is meant for already registered users.

Page 62
REGISTRATION PAGE :

The Registration page is intended gor naïve user to enroll all his details in to the hotels database.
A registered user gets many facilities like special offers and latest news through mail.

Page 63
HOTEL OVERVIEW :

This gives the hotels complete overview map. Each floor’s overview is provided.

Page 64
BOOKING PAGE:

This Booking page includes different type of rooms and the user can book the rooms based on
his requirement. The allotment of rooms is based on its availability criteria.

Page 65
FUNCTION HALLS :

This module provides event management. The clients select a hall based on the number of
people, type of event and time of event. The details of the function halls are stored in the
database.

Page 66
RESTAURANT PAGE :

In Restaurant page the client is provided with a menu card, the details of which are stored in
database.The hotel provides various delicious recipes popular in that geographical location.

Page 67
GALLERY:

The Gallery page gives the Hotels latest won awards globally and its achievements. The
clients can view the photographs of the hotel which states its efficient infrastructure.

Page 68
TOURISM:

This module provides an extra feature. The hotel provides details about the climate and weather
conditions of the city and the roadmap to the hotel. It also provides details of various tourist
spots and shopping sites in the city.

Page 69
FEEDBACK:

Every organization needs to know what its clients think about them. This is helpful in
improvisation. In this module, the hotel asks for feedback from the clients after they have logged
in. The type of questions asked is based upon the service used by the client.

Page 70
9.0 TABLES

1. Client Table

2. Credit Table

3. Home delivery Table

4. Items Table

Client Table:

CREATE TABLE "CLIENT"

( "NAME1" VARCHAR2(4000),
"NAME2" VARCHAR2(4000),
"PASSWORD" VARCHAR2(4000),
"OCCUPATION" VARCHAR2(4000),
"EMAIL" VARCHAR2(4000),
"DOB" VARCHAR2(4000),
"PHONE" NUMBER,
"GENDER" VARCHAR2(4000)
)

Page 71
Credit Table:

CREATE TABLE "CREDIT"

( "CARDTYPE" VARCHAR2(4000),
"CARDNAME" VARCHAR2(4000),
"CARDNUMBER" VARCHAR2(4000),
"EXPIRYMONTH" VARCHAR2(4000),
"EXPIRYEAR" VARCHAR2(4000)
)

Page 72
Home Delivery Table:

CREATE TABLE "HOMEDELIVERY"

( "CUSTOMERNAME" VARCHAR2(40),
"DOORNO" NUMBER,
"AREA" VARCHAR2(40),
"STREET" VARCHAR2(40),
"CITY" VARCHAR2(30),
"PIN" NUMBER,
"ITEMLIST" VARCHAR2(50)
)

Page 73
Items Table:

CREATE TABLE "ITEMS"

( "SERIALNO" NUMBER,
"ITEMNAME" VARCHAR2(30),
"ITEMTYPE" VARCHAR2(34),
"PRICE" NUMBER,
PRIMARY KEY ("ITEMNAME") ENABLE
)

Page 74
10.0 SAMPLE CODE

MAIN FRAME:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"

"http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<title>Mont Blanc Apartments</title>
<meta http-equiv="Content-Type" content="text/html; charset=windows-1251">
<link rel="stylesheet" type="text/css" href="style.css" />
</head>
<body>
<div id="header">
<a href="index.html" id="logo"><img src="images/logo.jpg" alt="" width="504"
height="128" /></a>

<span>Traditionally Royal hotel</span>

<img src="images/image.jpg" alt="" width="800" height="301" ><br />
<table align="left">
<tr> <td> <h1>Login </h1> <p> The users who have registered can login into the page. <iframe
src="login.jsp" name="mumbaiframe" width="300" height="250" scrolling="No"
frameborder="0" id="mumbaiframe" ></iframe></td>
<td> <br><br><br>New users have to register first...
<iframe src="registration.html" width="400" height="550" scrolling="No"
frameborder="0"></iframe> </p> </td></tr>
</table>
</body> </html>

Page 75
LOGIN:

<%@ page contentType="text/html; charset=iso-8859-1" language="java" import="java.sql.*"

errorPage="" %>
<html>
<head><center><b><u><h1>LOGIN PAGE</h1></u></b></center></head>
<br><br><br>
<body id="log">
<FORM >
<table align="center">
<tr>
<td>USERNAME:</td>
<td><INPUT TYPE="text" name="login"></td>
</tr>
<tr>
<td>PASSWORD:</td>
<td><INPUT TYPE="PASSWORD" name="password"></td>
</tr>
<tr> <td colspan="2"> <input type="submit" value="Submit">
<input type="reset" value="Reset"></td>
</tr>
</table>
</FORM>
<%
String username=request.getParameter("login");
String password=request.getParameter("password");
String luser,lpass;
Class.forName("oracle.jdbc.OracleDriver").newInstance();
String connectionURL = "jdbc:oracle:thin:@127.0.0.1:1521:XE";
Connection conn = DriverManager.getConnection(connectionURL, "system", "parents");
String queryString = "select * from customer";
Statement stmt=conn.createStatement();
ResultSet rset = stmt.executeQuery(queryString);
while(rset.next()){
luser=rset.getString("username");
lpass=rset.getString("password");
if(lpass.equals(password) && luser.equals(username)){
response.sendRedirect("index1.html");
}
else{
}
return;
} %>
</body>
</html>

Page 76
CREDIT:
<%@ page contentType="text/html; charset=iso-8859-1" language="java" import="java.sql.*"
errorPage="" %>
<html>
<head><center><b><u><h1>CREDIT-CARD PAGE</h1></u></b></center></head>
<body>
<FORM>
<table align="center">
<tr><td>CREDIT-CARD TYPE : </h3></td>
<td><select name="type"><option>Master Card</option>
<option>Visa</option>
<option>ICICI</option></select></td>
</tr>
<tr><td> NAME OF THE HOLDER :</h3></td> <td><input type="text"
name="hname"></td></tr>
<tr><td> CREDIT-CARD NUMBER :</h3></td> <td><input type="text"
name="cnum"></td></tr>
<tr><td>CREDIT EXPIRY :</td> <td>month<select name="month">
<option>January</option>
<option>February</option>
<option>March</option>
<option>April</option>
<option>May</option>
<option>June</option>
<option>July</option>
<option>August</option>
<option>September</option>
<option>October</option>
<option>November</option>
<option>December</option></select></td>
<td><b> / </b>year<select name="year">
<option>2011</option>
<option>2012</option>
<option>2013</option>
<option>2014</option></select></td>
<tr><td> </td></tr>
<tr><td> </td></tr>
<tr><td> </td></tr>
<td colspan="2"><input type="submit" value="Submit"><input
type="reset" value="Reset"></td>
</tr> </table> </FORM>
<%
Connection cn=null;
PreparedStatement ps=null;
String t,h,c,m,yr,qry;
t=request.getParameter("type");

Page 77
 h=request.getParameter("hname");
c=request.getParameter("cnum");
m=request.getParameter("month");
yr=request.getParameter("year");
qry="insert into credit values(?,?,?,?,?)";
int y;
y=0;
Class.forName("oracle.jdbc.OracleDriver");
String connectionURL = "jdbc:oracle:thin:@127.0.0.1:1521:XE";
cn=DriverManager.getConnection(connectionURL,"system","atul");
ps=cn.prepareStatement(qry);
ps.setString(1,t);
ps.setString(2,h);
ps.setString(3,c);
ps.setString(4,m);
ps.setString(5,yr);
y=ps.executeUpdate();
if(y!=0){ %>
<script type="text/javascript">
alert("Message Sent");
</script>
<%}
%> </body> </html>

Page 78
11.0 CONCLUSION

The project named HOTEL MANAGEMENT SYSTEM is done with JSP and HTML
pages and with the oracle 10g. This project would enable a user to interact with the site
created. It would be compatible even for a new user to register and then access the
services of the hotel.

As the coding includes JSP it would be easier to interact and its user friendly nature is
the most attractive part of the project. The JSP pages are run in an APACHE TOMCAT
server.

The future scope of this would be that it will replace the conventional methods of
booking similar to the Railway Reservation System. It would also enable the user to book
the recipes and home delivery is also provided.

Page 79
12.0 BIBLIOGRAPHY

1. Internet and the World wide web: Dietel & Dietel

2. Web Technologies : Chris Bates

3. www.wikipedia.org

4. www.w3schools.com

5. www.templatesonweb.com

Page 80