CHAPTER 1

INTRODUCTION
In recent years, a boom in web application has emerged allowing users to provide
services at their best and flexibly right at their use. But taking account of the
uncertainty in social world, we find several factors affecting now-a-days life in spite of
the plenty pertinent and relevant applications around you. For example, you are in the
urgency for hospitality and the ever ready increase in medicines prices haunts you and
it can worsen if no aid is available, Or on the interesting side, you are in an unknown
area craving for some delicious food, need to go to some theatre and cant find one,
stuck in the middle of road with damaged vehicle, you need not to worry for these now
and dont need to mug up the application with each kind of application for each kind of
help. These difficulties are now taken care by this web application, INSTAHELP: Help
is always online.

1.1

STATEMENT

The purpose of the Instahelp is to provide assistance for 24*7 hour availability. It also
provides the searching of places for entertainment, medical facilities, instant alarm on
click and every other which can enhance the meaning of assistance.

1.2

PRESENT SYSTEM

For every other thing you have to mug up various sources.

It gets worse when the place you are residing in is new to you.
There was no possibility till now for instant alarm so that, if you are in any
perilous situation, assistance can be guaranteed

Drawbacks of present system

It is cumbersome for the user to look for services present around him if he is not

a native.
The quality is not assured.
The lack of choices also makes it an involuntary decision.
Every other day it is not possible to get the assistance every time.

1.3 PROPOSED SYSTEM

Login to the system through the first page of the application.

This will track location and will take username and password to provide

authentication.
One can not log in without email verification.

Instant profile page will be opened for 30 sec which is having link for complete
profile page. And if the link is not clicked with in 30 sec then it will generate

instant alert.
Complete profile page will have details of user and 4 option namely Enjoy,
problem, alert and additional. Besides the 4 main modules it will also have

option for searching route and distance.

Enjoy and problem pages will have a lot of option available like hotel, medical,

party etc.
Alert will generate instant alert which will send email to all your connection.

Advantages of proposed system

It provides "better and efficient" service to customers.

Customers according to their needs get the required items and specific services.
A myriad of alternatives for the consumer for the regular amenities..
The Instahelp also cares and reciprocates according to the mood of consumers.
It provides the location for restaurants, partying, food and pubs around you in a

single click.
It provides the medical services too such as doctor, clinic, ambulance etc.
The references used in designing this project are studying the regular need of
humans and the services by which they have assistance every time.

CHAPTER 2
REQUIREMENT ANALYSIS
In this phase we find the need of this project. Since the Instahelp comprises a number
of users and a large number of service providers, handling them was a tough task. The

analysis included gathering of data such as, hardware and software requirements, types
of users required, types of service daily required and in emergency. The analyses also
included the aspects such as, whether it is economical to make this project and life time
validity of the project.

CHAPTER 3
FEASIBILITYSTUDY

FEASIBILITY STUDY:
The feasibility study is carried out to find out whether the proposed system can be
developed and implemented without any problem. Feasibility is considered for the
project in order to ensure that the project is viable and it does not have any major
obstructions.
Any system is feasible when given infinite time and resources. The problem is whether
the proposed system achieves the goal by using available resources in pre-specified
time. To start any project we have to study the system so that the requirements and
goals should match. This feasibility study involves:
Technical Feasibility
Operational Feasibility
Economical Feasibility

3.1 TECHNICAL FEASIBILITY:

The proposed system needs data in an efficient manner i.e., it needs protection and
authorized access to data. This is when we use the software which supports console
oriented methodology and database methodology .This technical skill is necessary to
carry out the project and how this is obtained.
This system is feasible on the following grounds:
All necessary technologies are available to those who want to develop an application.
The existing resources are capable of holding all the necessities in an efficient way.
The system is too flexible and can be expanded further whenever new modules are
added.

3.2 OPERATIONAL FEASIBILITY:

This determines if the proposed system has satisfied user objectives and can fit into the
current operation. It is a measure of how well a proposed system solves the problem,
and takes advantage of the opportunities identified during scope definition and how it
satisfies the requirement identified in the requirements analysis phase of system
development.
The operational feasibility assessment focuses on the degree to which the proposed
development projects fits in with the existing business environment and objectives with

regard to development schedule, delivery date, corporate culture and existing business
processes.
The proposed system will certainly satisfy the user requirements and will also enhance
their capability. It can be best fitted into current operations. Also the maintenance of the
system is very easy and requires minimal effort. Therefore, the system is operationally
feasible.

3.3 ECONOMICAL FEASIBILITY:

It determines whether the project goal can be within the resource limits allocated toit.
The purpose of economic feasibility assessment is to determine positive economic
benefits to the organization that the proposed system will provide. It include
quantification and identification of all the benefits expected. This assessment typically
involves a cost/benefits analysis.
Proposed system requires no extra manpower cist almost nil. Also the cost invested to
implement the proposed system can be easily recovered. So, the system is economically
feasible.

CHAPTER 4
SOFTWAREREQUIREMENTSPECIFICATION
4.1 INTRODUCTION
4.1.1 PURPOSE:

The main objective of this project is to brief up the process of providing necessary help
to the people. Instahelp is a network in which various connections are there to help each
other and various service provider are there to provide help. Hence it is not an easy task
to make up this entire information manually. Hence there is a requisite for maintaining
a Database of the records so that access to pertinent service can be done with a mouse
click. This ensures a very quick and accurate retrieval of data which ever the end users
intend to obtain. Hence, this project aims at reducing the human efforts and increasing
the efficiency in implementing the help System effectively. Therefore we can avoid the
problems which are faced by current users of the system and can fulfill all requirements
as much as possible.

4.1.2 SCOPE:

To make the existing system more efficient.

To provide a user friendly environment where user can be serviced better.
Make availability of services faster and easier.
To minimize the time taken to provide the assistance.
The different areas where we can use this application are:
In case of any emergency this application has a very salient
feature of Instant alarms to send your location to nearest police

station.
It can be used by users who are in the search of best restaurants

or some good place to eat.

The entertainment part is also included to look for theatres,
multiplexes are pubs.

4.1.3 LIFETIME:
This product works until the used software is in existence.

4.1.4 SUCCESS CRITERIA:

Our main goal is to complete this project within allotted dead line with complete front
end implementation. It is necessary to develop a method for capturing benefits through
testing.
Hence the Instahelp is being developed, tested, and after it is rolled out for use. If the
project takes a little longer to complete or costs a little more than planned, it will still
be viewed as a success if it helps promote an excellent management.

4.2 FUNCTIONAL REQUIREMENTS:

Administrator is capable of whole and sole that means all DBA features will be
implemented in Admin module with the support of GUI features.
An End User should be able to login into the system.
After his/ her login is done then user can access the application and can make use of
enjoying, medical, instant alarm . . . etc;
While inserting values in the database, only valid values must be entered.
Main motto is to provide the help to the user in every situation whether it is
entertainment or training, which is being searched by the user. So that it reduces
manual burden.

4.3 NONFUNCTIONAL REQUIREMENTS:

4.3.1 USABILITY:
The product could be used by two categories of people mainly: service provider and Users.

4.3.2 RELIABILITY:
Users can look for services and their location based on his location. The application as a whole
is highly reliable.

4.3.3 PERFORMANCE:
It provides users with access to information based on the type of service they are searching.

4.3.4 SUPPORTABILITY:
All kinds of information which can be supported in the database are supported by the system
and the application supports the utilities of the system over which it is deployed.

4.4 HARDWARE REQUIREMENT SPECIFICATION:

Processor: Intel Pentium III or above
Hard Disk: 30GB or above

RAM: 256MB or above

4.5 SOFTWARE REQUIREMENT SPECIFICATION:

Platform required: J2SE

CHAPTER 5
INTERFACES
5.1 USER INTERFACES:
The project provides GUI forms to the users for easy understanding and application.
The screens are designed in JAVA. The project offers different menus to the user to
select from the given options.

5.2 HARDWARE INTERFACES:

Monitor screen the software shall display information to the user via the monitor
screen.
Mouse the software shall interact with the movement of the mouse and the mouse
buttons.
The mouse shall activate areas for data input, buttons and select options from menus.
Keyboard the software shall interact with the keystrokes of the keyboard. The
keyboard will input data into the active area of the database.
5.3 SOFTWARE INTERFACES:
Windows is the operating system employed in this project as a software interface.

CHAPTER 6
OBJECT ORIENTEDANALYSIS
6.1 USE CASE MODEL:
Use cases are used during the requirements elicitation and analysis to represent
functionality of the system. Use cases focus on the behavior of the system from an
external point of view. In its simplest form, a use case can be described as a specific
way of using the system from a users (actors) perspective. Use cases describe the

1. A pattern of behavior the system exhibits

2. A sequence of related transactions performed by an actor and the system
3. Delivering something of value to the actor
Use cases provide a means to
1. Capture system requirements
2. Communicate with the end users and domain experts
3. Test the system
Use cases are best discovered by examining the actors and defining what the actor will
be able to do with the system. Since all the needs of a system typically cannot be
covered in one use case, it is usual to have a collection of use cases. Together this use
case collection specifies all the ways of using the system. In a use case diagram there
can be two kinds of relationships

1. Association Relationship:
An association provides a pathway for communication. The communication can be
between use cases, actors, classes or interfaces. Associations are the most general of all
relationships and consequentially the most semantically weak. If two objects are
usually considered independently, the relationship is an association

2. Generalization Relationship:
A generalize relationship is a relationship between a more general class or use case and
a more specific class or use case. A generalization is shown as a solid-line path from the
more specific element to a more general element. The tip or a generalization is a large
hollow triangle pointing to the more general element.

3. Extend Relationship:
An extend relationship is a stereotyped relationship that specifies how the functionality
of one use case can be inserted into the functionality of another use case. Extend
relationships between usecases are modeled as dependencies by using the Extend
stereotype.
Extend relationships are important because they show optional functionality or system
behavior. For example, Rational Rose allows you to place crop marks on printed
diagrams.

4. Include Relationship:
An include relationship is a stereotyped relationship that connects a base use case to an
inclusion use case. An include relationship specifies how behavior in the inclusion use
case is used by the base use case.

Include relationships are important because they represent that the inclusion use case
functionality is used by the base use case.

USECASE DIAGRAMS
User/Biller:

Administrator:

6.2 USECASE TEMPLATE

LOGIN TYPE- BILLING
Use Case Name
Participating Actor

Account login for user

1. admin

Entry Condition
Flow of events

2. user
Login by user/admin by password
1.open the billing window
2. enter the items demanded by the
customer

Exit condition
Quality requirements

3. confirm the bill

Successful submission of bill
The response is very quick, thus system is
efficient

LOGIN TYPE- PERSONAL

Use case name
Participating Actors

Functions of an administrator
Shop Manager

Entry Conditions

Administrator must be having access to

Flow of events

stored record
1.Login with unique password
2. Update database (item details, add
items)
3. Days sale

Quality requirements

4. Money paid to the wholesalers.

The response is very quick, thus system is
efficient

6.2 USE CASE MODEL SURVEY:

Actor:
1. Administrator:
Documentation: Administrator is the head of the system, manages all the
information and updates database.
2. Shopkeeper:
Documentation: Shopkeeper is the user who uses functions like billing items for
customers.

3. Database:
Documentation: Database acts like an interface between the user and the
administrator.

Use cases:
1. ADMINISTRATOR FUNCTIONS:
Documentation: Administrator will be having access to the database so that he
can update the database (addition or deletion or modification) whenever
required.
2. ADMINISTRATOR RESPONSIBILITIES:
Documentation: Administrator will be having access to the database so that he
can verify authentication and ignore invalid items along with the updation of
database. He also looks after items availability.

6.3 ACTIVITY DIAGRAM:

Activity diagrams are diagram technique showing workflows of stepwise activities and
actions, with support for choice, iteration and concurrency. In the UML, activity

diagrams can be used to describe the business and operational step-by-step workflows
of components in a system. An activity diagram shows the overall flow of control.
Activity diagrams should be used in conjunction with other modeling techniques such
as interaction diagrams and state diagrams The main reason to use activity diagrams is
to model the workflow behind the system being designed. Activity Diagrams are also
useful for: analyzing a use case by describing what actions needs to take place and
when they should occur; describing a complicated sequential algorithm; and modeling
applications with parallel processes.

Components of Activity Diagrams:

Activity diagrams are constructed with a limited set of building blocks, consisting of:
Nodes

- like initial node and activity final node, and.

Activity building

blocks, and

Sometimes activity diagrams also contain building block for decision-making, but it is
questionable if these diagrams should be called activity diagram.
The starting point of the diagram is the initial node, which is mostly located on top or
on the left. And the ending of the diagram with an activity final node is on the bottom
or on the right. In between there can be zero, one or more activity building blocks,
which can be represented by rounded rectangles.

ACTIVITY DIAGARAM:

CHAPTER 7
OBJECT ORIENTED DESIGN

7.1 SEQUENCE DIAGRAMS:

Sequence diagrams represent the objects participating in the interaction horizontally
and time vertically. Each column represents an object that participates in the
interaction. Messages are shown by solid arrows. Labels on solid arrows represent
message names and may contain arguments. Activations are depicted by the vertical
rectangles. The actor who initiates the interaction is shown in the use case diagrams. If
other actors communicate with the system during the use case, these actors are
represented on the right hand side and can receive messages. Although for simplicity,
interactions among objects and actors are uniformly represented as messages, the
modeler should keep in mind that interactions between actors and the system are of a
different nature than interactions among objects. These diagrams can be used to
describe either an abstract sequence or concrete sequences. When describing all
possible interactions, sequence diagrams also provide notations for conditionals and
iterations. A condition on a message is denoted by an expression in brackets before the
message name. If the expression is true the message is sent. Repetitive invocation of a
message is denoted by a * before the message name.
The two main components of sequence diagram are:
Focus of Control:
When a message is sent the time taken for the object to communicate with other objects
is represented by thin rectangular box.It is called as focus of control.
Lifeline:
It represents the object existence time.

ADMINISTRATOR:

Fig 7.1

Administrator sequence Diagram

7.2 STATE CHART DIAGRAMS:

A state chart diagram is a graph that represents a state machine. State chart diagrams
represent the behavior of entities capable of dynamic behavior by specifying its
response to the receipt of event in stances. State charts, often used more in real-time
embedded systems than in information systems, show for a class, the order in which
incoming calls to operations normally occur and the conditions under which the
operations respond and the response. They are a class-centric view ofsystem
functionality, as opposed to sequence and collaboration diagrams which are a use casecentric view of functionality.

Purpose:

To model dynamic aspect of a system.

To model life time of a reactive system.
Describe different states of an object during its life time.
To define a state machine to model states of an object.

Components of State Chart Diagrams

1. States - oblong boxes which indicate the stable states of the object between events
2. Transitions - the solid arrows which show possible changes of state
3. Events - the text on the transitions before the '/' showing the incoming call to the
object interface which causes the change of state.
4. Conditions - a Boolean statement in square brackets which qualifies the event
5. Actions - the text after the '/' which defines the objects response to the transition
between states.
6. Extra syntax which defines state centric functionality.

STATE CHART DIAGRAM:

Fig 7.2 State Chart Diagram

7.3 CLASS DIAGRAMS:

Class diagrams describe the structure of the system in terms of classes and objects.
Classes are abstractions that specify the attributes and behavior of set of objects. A class
is a collection of objects that share a set of attributes that distinguish the objects as
members of the collection. Objects are entities that encapsulate state and behavior. Each
object is distinguishable from others. Classes and objects are depicted by the boxes
composed of three components. The top compartment displays the name of the class or
object. The centre compartment displays its attributes and the bottom compartment
displays the functions performed by it. The object names are underlined to indicate that
they are instances. By convention, class name starts with uppercase letter and object
name starts with lowercase letter. The type of an attribute is used to specify the valid
range of the values the attribute can take. When attributes types are not essential to the
definition of the system, attribute type decisions can be delayed until object design.

Inheritance:
A very important concept in object-oriented design, inheritance, refers to the ability of
one class (child class) to inherit the identical functionality of another class (super class),
and then add new functionality of its own. To model inheritance on a class diagram, a
solid line is drawn from the child class (the class inheriting the behavior) with a closed
arrowhead (or triangle) pointing to the super class.

Association:
There are 5 types of associations:

1. Bi-directional (standard) association:

An association is a linkage between two classes. Associations are assumed to be
bidirectional. In other words, both classes are aware of their relationship and of
the other class unless you qualify the association as some other type of
association. A bi-directional associationis indicated by a solid line between the
two classes. At either end of the line, we place a rolesame and a multiplicity
value.

2. Unidirectional association:
A unidirectional association shows that two classes are related, but only one
class knows that the relationship exists. A unidirectional association is drawn as

a solid line with an open arrowhead (not the closed arrowhead, or triangle, used
to indicate inheritance) pointing to the known class.

3. Association class:
In modeling an association, there are times when you need to include another
class because it includes valuable information about the relationship. For this
you would use an association class that you tie to the primary association. An
association class (also called a drop class by my former professor) is
represented like a normal class. The difference is that the association line
between the primary classes intersects a dotted line connected to the association
class.

4. Aggregation:
Aggregation is a special type of relationship used to model a "whole to its parts"
relationship. In basic aggregation relationships, the lifecycle of a part class is
independent from the whole class's lifecycle.

5. Composition aggregation:
The composition aggregation relationship is just another form of the
aggregation relationship, but the child class's instance lifecycle is dependent in
the parent class's instance lifecycle.

Description of various classes present in the project:

Package: Handlers
Classes:
1) Dealers
Methods:
read()
write()
2) Item Handler
Methods:
AlreadyPresent()
read()
write()
readItem()
3) LoginHandler
Methods:
Check()
Write()
4) Numchecker
Methods:

 FloatChecker()
IntChecker()
5) Payhandler
Methods:
getDate()
read()
update()
write()
6) Salehandler
Methods:
getDate()
read()
update()
write()
Package: Models
Classes:
1) Getcolor()
Methods:
Get()
2) Item
Data members:
Index
Name
Amount
Quantity
wgt
Methods:
getName()
getIndex()
getAmount()
getQuantity()
iswgt()
setName()
setIndex()
setAmount()
setQuantity()
3) Payment
Data members:
Ap
Total_sum
Methods:

 getAp()
getTotal_sum()
setAp()
settotal_sum()
4) Sale
Data members:
Date
Itemlist
Totalsum
Methods:
getDate()
getItemlist()
getTotalsum()
setDate()
setItemlist()
setTotalsum()
5) hItem
Data members:
amount
index
name
sold_item
Methods:
setamount()
setindex()
setname()
setsold_item()
getamount()
getindex()
getname()
getsold_item()
6) pItem
Data members:
amount
name
Methods:

setamount()
setName()
getAmount()
getName()

Package: View
Classes:
1)
2)
3)
4)
5)

AddItem
AddUser
BackPanel
ChangePass
InAvail

CLASS DIAGRAM:

Fig 7.3 Class Diagram

7.4 COMPONENT DIAGRAM:

Component diagrams provide a physical view of the current model. A component
diagram shows the organizations and dependencies among software components,
including source code components, binary code components, and executable
components. These diagrams also show the externally-visible behavior of the
components by displaying the interfaces of the components. Calling dependencies
among components are shown as dependency relationships between components and
interfaces on other components. Note that the interfaces actually belong to the logical
view, but they can occur both in class diagrams and in component diagrams

Component diagrams contains

Component packages

Components
Interfaces
Dependency relationships

Component packages represent clusters of logically related components, or major

piecesof your system. Component packages parallel the role played by logical packages
for class diagrams. They allow you to partition the physical model of the system.
A Component represents a software module (source code, binary code, executable,
DLL, etc.) with a well-defined interface. The interface of a component is represented
by one or several interface elements that the component provides. Components are used
to show compiler and runtime dependencies, as well as interface and calling
dependencies among software modules. They also show which components implement
a specific class. A system may be composed of several software modules of different
kinds. Each software module is represented by a component in the model. To
distinguish different kinds of components from each other, stereotypes are used.
An interface specifies the externally-visible operations of a class and/or component,
and has no implementation of its own. An interface typically specifies only a limited
part of the behavior of a class or component.
A Dependency is a relationship between two model elements in which a change to one
model element will affect the other model element. Use a dependency relationship to
connect model elements with the same level of meaning. Typically, on class diagrams, a
dependency relationship indicates that the operations of the client invoke operations of
the supplier.
COMPONENT DIAGRAM:

Fig 7.4: Component Diagram

7.5 DEPLOYMENT DIAGRAM:
A deployment diagram in the Unified Modeling Language serves to model the physical
deployment of artifacts on deployment targets. Deployment diagrams show the
allocation of Artifacts to Nodes according to the Deployments defined between them.
Deployment of an artifact to a node is indicated by placing the artifact inside the node.
Instances of nodes (and devices and execution environments) are used in deployment
diagrams to indicate multiplicity of these nodes. For example, multiple instances of an
application server execution environment may be deployed inside a single device node
to represent application server clustering.

DEPLOYMENT DIAGRAM:

Fig 7.5 Deployment Diagram

CHAPTER 8
SCREEN SHOTS

This is the first page of our project

There are two types of login

o Billing
o Personal
User enters the password for its respective login.

Fig. 8.1 Login Panel

This is the main page for the login type- Billing

All the tabs are present in this page.
Example-New Bill, Confirm bill, Add client, Pay money, etc.
Billing layout along with indexed items is also visible

Fig 8.2

Home page for login type-Billing

This is the main page of the login type- Personal

All the required tabs are present in this page.
Example- Add item, change details, money paid, etc.

Fig 8.3

Home page for login type- Personal

This is the screen for the tab CHANGE DETAILS

Admin can change the details of the indexed product.
Details which can be changed are- Availability and price.

CHANGE DETAILS tab screen

This is the screen for the tab ITEM SOLD
It shows the details of the sale on a particular date.

ITEM SOLD tab screen

Screen 1- Change Password

Screen 2- Change Password

Screen 3- Change Password

Screen 4- Change Password

Screen 1- Add Client

Screen 2- Add Client

Screen 1- Pay Money

Screen 2- Pay Money

Screen 3- Pay Money

CHAPTER 9
TESTING
9.1 Definition:
Testing is the process of finding differences between the expected behavior specified by
the system model and the observed behavior of the implemented system.

9.2 Description:
It is a fault detection technique that tries to create failures or erroneous states in a
planned way. This allows the developer to detect failures in the system before it is
released to the customer. System testing is an expensive process but it is required in
order to achieve a complete system. Generally the users tend to think that the process of
providing that there do not exist, any errors in the system forms the testing part.

9.3 Types of Testing:

Unit Testing:
1.
2.
3.
4.
5.
6.
7.
8.

The most micro scale of testing.

A unit is smallest software component
Objects and methods
Procedures and functions
Performed by programmer and units are tested in isolation.
Ensure that system is working according build design.
Not to be confused with debugging.
Also known as component, module testing

Integration Testing:
1. Testing of more than one (tested) unit together to determine if they function
correctly.
2. Focuses on interfaces of Communication between units
3. It is done using the integration test design prepared during the architecture
design.
4. Helps assembling incrementally a whole system, ensuring the correct flow of
data
5. Done by developers/designers and testers in collaboration

6. Also called Interface Testing or Assembly Testing.

System Testing:
Testing the system as a whole - Black-box type testing that is based on overall
requirements specifications; covers all combined parts of a system.
1.
2.
3.
4.

Ensures that system meets all functional and business requirements.

Focus on verifying that specifications are met
Validating that the system can be used for the intended purpose
The system test design is derived from the system design documents and is used

in this phase.
5. It can involve a number of specialized types of tests to check performance,
stress,documentation etc. Sometimes testing is automated using testing tools
one by Independenttesting group

Acceptance testing:
1. To determine whether a system satisfies its acceptance criteria and business
requirements ornot.
2. Similar to System testing in that the whole system is checked, but the important
difference isthe change in focus.
3. Done by real business users.
4. It enables the customer to determine whether to accept the system or not.

9.4 Test Cases:

A test case is a set of input data and expected results that exercises the component with
the purpose of causing failures and detecting faults. Test cases are classified into black
box test and white box test. Black box test focuses on input/output behavior of the
component. White box test focuses on the internal structure of the components.

Message shown in case of incorrect password

Error message shown in case of invalid input

Message shown in case of any field left blank

CHAPTER 10
CONCLUSION
After we have completed the project we are sure the problems in the existing system
would overcome. The BILLING AND INVENTORY MANAGEMENT SYSTEM
process made computerized to reduce human errors and to increase the efficiency. The
main focus of this project is to lessen human efforts. The maintenance of the records is
made efficient, as all the records are stored, through which data can be retrieved easily.
The navigation control is provided in all the forms to navigate through the large amount
of records. If the numbers of records are very large then user has to just type in the
search string and user gets the results immediately. The editing is also made simpler.
The user has to just type in the required field and press the update button to update the
desired field. The items are given a particular unique Id number so that they can be
accessed correctly and without errors. Our main aim of the project is to get the correct
information about a particular item available in the shop. The problems, which existed
in the earlier system, have been removed to a large extent. And it is expected that this
project will go a long way in satisfying users requirements. The computerization of the
Billing Management will not only improve the efficiency but will also reduce human
stress thereby indirectly improving human recourses.

REFERENCES
1.

The Unified Modeling Language Reference Manual - James Rumbaugh, Ivar

2.

Jacobson,Grady Booch- Addison Wesley

Object Oriented Software Engineering Using UML, Patterns and Java, Second

3.
4.

Edition -Bernd Bruegge, Allen H. Dutoit, Pearson Education

JAVA: The complete reference by Herbert schildt.
CORE JAVA: An Integrated Appproach by Dr. R. Nageswara Rao