Insurance System With Tracking Manager

Submitted to

FOR THE DEGREE OF

BY:-
RAJEEV KUMAR PRAMANIK
ROLL NO: 37
 Contents:

1.0 Introduction

1.1 Purpose

1.2 Scope

1.3 Definition, Acronyms

1.4 Technologies to be Used

1.4.1 Net Beans

1.4.2 Glassfish

1.4.3 Back End DB2

1.4.4 Front End JSP

1.5 Overview

1.6 Use Case Design

1.7 Class Diagram

1.8 ER Diagram

1.9 Tables Description

2.0 Activity Diagram

2.1 Screen Shots

1.0 INTRODUCTION

1.1 Purpose-
Insurance system with tracking manager is a web application software which provides insurance services
to users in different fields which includes Life insurance, Medical insurance, Motor insurance and House
insurance. It also provides the loan facility for motor purchasing.

1.2 Scope-
This application software has three types of users
A. Policy Holders
B. Company officials
C. Administrator
 The existing policy holders can login and view their profile, pay premium and view the
existing policy details.
 The company’s officials can login to the system and can generate new policies grant
loans to the existing policy holders and add new schemes but it should be approved
legally by administrator and then these policies will be updated.
 The administrator approves the policies generated by company officials and only the
administrator has the right to update any information.

1.3 Definition, Acronyms & Abbreviations- Policy Holders-

They are the existing policy holders, they are provided with particular username and password to
access their profile.

Company Officials-
The company officials will be given a particular username and password from which they can
login and generate policies and view policy holder details.

Administrator-
There will be an admin, who will have an admin id and password and he/she can give approval of
new policies generated and can alter information.

XML (Extensible Markup Language)-

It is a flexible way to create common information formats and share both the format and data on
the World Wide Web (WWW), internets or elsewhere.

DB-2 express edition ‘C’-

A database management system that provides a flexible and efficient database platform to
maintain records of policy holders, company officials and administrator.

J2EE- Java 2 enterprise edition is a programming platform which is a part of a java platform for
developing and running distributed java.

1.4 Technologies to be used-

1.4.1 NETBEANS IDE-

NetBeans IDE

NetBeans IDE 7.2 in Microsoft Windows 7.

Developer(s) Oracle Corporation

Written in Java
 Operating system Cross-platform (multi-platform)

Platform Java SE

Type Java IDE

License CDDL or GPL2 + "certain source files" allow class path exception

Website netbeans.org

1.4.1 NetBeans-
It is an integrated development environment (IDE) for developing primarily with Java, but
also with other languages, in particular PHP, C/C++, and HTML5. It is also an application
platform framework for Java desktop applications and others. The NetBeans IDE is written in
Java and can run on Windows, OS X, Linux, Solaris and other platforms supporting a compatible
JVM. The NetBeans Platform allows applications to be developed from a set of modular software
components called modules. Applications based on the NetBeans Platform (including the
NetBeans IDE itself) can be extended by third party developers.

1.4.2 Glassfish Server-

It is an open-source application server project started by Sun Microsystems for the Java EE
platform and now sponsored by Oracle Corporation. The supported version is called Oracle
Glassfish Server. Glassfish is free software, dual-licensed under two free software licenses:
the Common (CDDL) and the GNU General Public License (GPL).

1.4.3 DATABASE PLATFORM-DB2-

The name DB2 was first given to the Database Management System or DBMS in 1983 when
[1]
IBM released DB2 on its MVS mainframe platform . Prior to this, a similar product was named
SQL/DS on the VM platform. Prior to that in the mid 1970's IBM released the QBE relational
database product for the VM
platform with a table-oriented "Query By Example" front-end which produced a linear-syntax
language that was a recognizable precursor to QBE and drove transactions to its relational
database. Later the QMF feature of DB2 produced real SQL and brought the same "QBE"
look and feel to DB2. The System 38 platform also contained a relational DBMS. System
Relational, or System R, was a research prototype developed in the 1970s. DB2 has its roots
back to the beginning of the 1970s when E.F. Codd, working for IBM, described the theory of
relational databases and in June 1970 published the model for data manipulation

1.4.4 About Front End-

About JSP-

JSP technology offers a simple way to create dynamic web pages that are platform independent
and server independent. It includes html language embedded within it. Java Server Pages (JSP)
technology provides a simplified, fast way to create web pages that display dynamically-generated
 content. The JSP specification, developed through an industry-wide initiative led by Sun
Microsystems, defines the interaction between the server and the JSP page, and describes the
format and syntax of the page. JSP pages use XML tags and script lets written in the Java
programming language to encapsulate the logic that generates the content for the page. It passes
any formatting (HTML or XML) tags directly back to the response page. In this way, JSP pages
separate the page logic from its design and display. JSP technology is part of the Java
technology family. JSP pages are compiled into servlets and may call JavaBeans components
(beans) or Enterprise JavaBeans components (enterprise beans) to perform processing on the
server. As such, JSP technology is a key component in a highly scalable architecture for web-
based applications. JSP pages are not restricted to any specific platform or web server. The JSP
specification represents a broad spectrum of industry input.

1.5 Overview-

Existing System-
 Policy holders can view the details about policies.
 Discussion forum.
Proposed System-
 Existing policy holders can track policies, pay premium and calculate EMI (on loans)
 Admin is responsible for authentication
 Company officials generate policies and respond to the queries asked by users
in discussion forum
Drawbacks-
 People of remote areas who don’t have knowledge about internet can’t use this
application.
Our plan-
 To connect all policy holders to company officials through discussion forum
 To interact users by providing attractive policies and loan schemes
 To provide online premium paying facility to the policy holder

1.6 USE CASE MODEL-

In 1986 Ivar Jacobson first formulated textual, structural and visual modeling techniques for specifying
use cases. In 1992 his co-authored helped to popularize the technique for capturing functional
requirements, especially in software development.
Cockburn recognizes that projects may not always need detailed "fully-dressed" use cases. He
describes a Casual use case with the fields
 Title (goal)
 Primary Actor
 Scope
 Level
 (Story): the body of the use case is simply a paragraph or two of text, informally describing
what happens.

Actors
A use case defines the interactions between external actors and the system under
consideration to accomplish a goal. Actors must be able to make decisions, but need not be human:
"An actor might be a person, a company or organization, a computer program, or a computer system
— hardware, software, or both." Actors are always stakeholders, but many stakeholders are not
actors, since they "never interact directly with the system, even though they have the right to care
how the system behaves." For example, "the owners of the system, the company's board of
directors, and regulatory bodies such as the Internal Revenue Service and the Department of
Insurance" could all be stakeholders but are unlikely to be actors. Similarly, a person using a system
may be represented as different actors because he is playing different roles. For example, user
"Joe" could be playing the role of a Customer when using an Automated Teller Machine to
 withdraw cash from his own account, or playing the role of a Bank Teller when using the system
to restock the cash drawer on behalf of the bank. Actors are often working on behalf of someone
else. Cockburn writes that "These days I write 'sales rep for the customer' or 'clerk for the
marketing department' to capture that the user of the system is acting for someone else." This tells
the project that the "user interface and security clearances" should be designed for the sales rep
and clerk, but that the customer and marketing department are the roles concerned about the
results. A stakeholder may play both an active and an inactive role: for example, a Consumer is
both a "mass-market purchaser" (not interacting with the system) and a User (an actor, actively
interacting with the purchased product). In turn, a User is both a "normal operator" (an actor using
the system for its intended purpose) and a "functional beneficiary" (a stakeholder who benefits
from the use of the system). For example, when user "Joe" withdraws cash from his account, he
is operating the Automated Teller Machine and obtaining a result on his own behalf. Cockburn
advises to look for actors among the stakeholders of a system, the primary and supporting
(secondary) actors of a use case, the system under design (SuD) itself, and finally among the
"internal actors", namely the components of the system under design.
Use case notation
In the Unified Modeling Language, the relationships between all (or a set of) the use cases and actors
are represented in a Use Case Diagram or diagrams, originally based upon Ivar Jacobson's
Objector notation. Sys ML, a UML profile, uses the same notation at the system block level.
Limitations
Limitations of Use cases include:
 Use cases are not well suited to capturing non-interaction based requirements of a system
(such as algorithm or mathematical requirements) or non-functional requirements (such
as platform, performance, timing, or safety-critical aspects). These are better specified
declaratively elsewhere.
 Use case templates do not automatically ensure clarity. Clarity depends on the skill of the
writer(s).
 Use cases are complex to write and to understand, for both end users and developers.
 As there are no fully standard definitions of use cases, each project must form its own
interpretation.
 Some use case relationships, such as extends, are ambiguous in interpretation and can be
difficult for stakeholders to understand.
 In Agile, simpler user stories are preferred to use cases.
 Use case developers often find it difficult to determine the level of user interface (UI)
dependency to incorporate in a use case. While use case theory suggests that UI not be
reflected in use cases, it can be awkward to abstract out this aspect of design, as it
makes the use cases difficult to visualize. In software engineering, this difficulty is resolved
by applying requirements traceability, for example with a traceability matrix.
 Use cases can be over-emphasized. Bertrand Meyer discusses issues such as driving
system design too literally from use cases, and using use cases to the exclusion of
other potentially valuable requirements analysis techniques.
 Use cases are a starting point for test design, but since each test needs its own success
criteria, use cases may need to be modified to provide separate post conditions for each path.
Customer (Policy Holder) - He or she can view details of the policies and they can also
calculate EMI, interest and pay premium as well as participate in discussion forum.

Company officials- The company officials generate policies and give responses to the
queries asked by users in the discussion forum.

Admin- He is responsible for approval of policies generated by company officials and also
updates information like new schemes policies etc.
1.7 Class Diagram-
1.8 ER DIAGRAM-

In software engineering, an entity-relationship model (ER model for short) is an

abstract and conceptual representation of data. Entity-relationship modeling is a database
modeling method, used to produce a type of conceptual schema or semantic data model
of a system, often a relational database, and its requirements in a top-down fashion.
Diagrams created by this process are called entity- relationship diagrams or ER diagrams.

Overview
Using the three-schema approach to software engineering, there are three levels of ER models that
may be developed. The conceptual data model is the highest- l e v e l ER model in that it
contains the least granular detail but establishes the overall scope of what is to be included
within the model set. The conceptual ER model normally defines master reference data entities
that are commonly used by the organization. Developing an enterprise-wide conceptual ER model
is useful to support documenting the data architecture for an organization.
A conceptual ER model may be used as the foundation for one or more logical data models. The
purpose of the conceptual ER model is then to establish structural metadata commonality for the
master data entities between the set of logical ER models. The conceptual data model may be used
to form commonality relationships between ER models as a basis for data model integration.
A logical ER model does not require a conceptual ER model especially if the scope of the logical ER
model is to develop a single disparate information system. The logical ER model contains more
detail than the conceptual ER model. In addition to master data entities, operational and
transactional data entities are now defined. The details of each data entity are developed and the
entity relationships between these data entities are established. The logical ER model is however
developed independent of technology into which it will be implemented.
One or more physical ER models may be developed from each logical ER model. The physical ER
model is normally developed be instantiated as a database. Therefore, each physical ER model
must contain enough detail to produce a database and each physical ER model is technology
dependent since each database management system is somewhat different.
The physical model is normally forward engineered to instantiate the structural metadata into a
database management system as relational database objects such as database tables, database
indexes such as unique key indexes, and database constraints such as a foreign key constraint or a
commonality constraint. The ER model is also normally used to design modifications to the relational
database objects and to maintain the structural metadata of the database.

The first stage of information system design uses these models during the requirements
analysis to describe information needs or the type of information that is to be stored in a database.
The data modeling technique can be used to describe any ontology (i.e. an overview and
classifications of used terms and their relationships) for a certain area of interest. In the case of the
design of an information system that is based on a database, the conceptual data model is, at a
later stage (usually called logical design), mapped to a logical data model, such as the relational
model; this in turn is mapped to a physical model during physical design. Note that sometimes, both
of these phases are referred to as "physical design".

Primary key
An entity may be defined as a thing which is recognized as being capable of an independent existence
and which can be uniquely identified. An entity is an abstraction from the complexities of some
domain. When we speak of an entity we normally speak of some aspect of the real world which can
be distinguished from other aspects of the real world.
An entity may be a physical object such as a house or a car, an event such as a house
sale or a car service, or a concept such as a customer transaction or order. Although the
term entity is the one most commonly used, following Chen we should really distinguish
between an entity and an entity-type. An entity-type is a category. An entity, strictly
speaking, is an instance of a given entity-type. There are usually many instances of an entity-
type. Because the term entity-type is somewhat cumbersome, most people tend to use the
term entity as a synonym for this term.

Entities can be thought of as nouns. Examples: a computer, an employee, a song, a

mathematical theorem.
A relationship captures how entities are related to one another. Relationships can be thought of as
verbs, linking two or more nouns. Examples: an owns relationship between a company and a
computer, a supervises relationship between an employee and a department, a performs relationship
between an artist and a song, a proved relationship between a mathematician and a theorem.
The model's linguistic aspect described above is utilized in the declarative database query
language ERROL, which mimics natural language constructs. ERROL's semantics and
implementation are based on Reshaped relational algebra (RRA), a relational algebra which is
adapted to the entity-relationship model and captures its linguistic aspect.
Entities and relationships can both have attributes. Examples: an employee entity might have a
Social Security Number (SSN) attribute; the proved relationship may have a date attribute.

Every entity (unless it is a weak entity) must have a minimal set of uniquely identifying attributes,
which is called the entity's primary key.
Entity-relationship diagrams don't show single entities or single instances of relations. Rather, they
show entity sets and relationship sets. Example: a song is an entity. The collection of all songs in a
database is an entity set. The eaten relationship between a child and her lunch is a single relationship.
The set of all such child-lunch relationships in a database is a relationship set. In other words, a
relationship set corresponds to a relation in mathematics, while a relationship corresponds to a
member of the relation.
Certain cardinality constraints on relationship sets may be indicated as well.

Relationships, roles and cardinalities

In Chen's original paper he gives an example of a relationship and its roles. He describes a
relationship "marriage" and its two roles "husband" and "wife".
A person plays the role of husband in a marriage (relationship) and another person plays the role of
wife in the (same) marriage. These words are nouns. That is no surprise; naming things requires a
noun.
However as is quite usual with new ideas, many eagerly appropriated the new terminology but
then applied it to their own old ideas. Thus, the lines, arrows and crows-feet of their diagrams owed
more to the earlier Bachman diagrams than to Chen's relationship diamonds. And they similarly
misunderstood other important concepts.
In particular it became fashionable (now almost to the point of exclusivity) to "name" relationships
and roles as verbs or phrases.

Relationship names
A relationship expressed with a single verb implying direction, makes it impossible to discuss the
model using the following proper English. For example:
 the song and the performer are related by a 'performs'
 the husband and wife are related by an 'is-married-to'.

Expressing the relationships with a noun resolves this:

 the song and the performer are related by a 'performance'
 the husband and wife are related by a 'marriage'.

Traditionally, the relationships are expressed twice, (using present continuous verb phrases), once in
each direction. This gives two English statements per relationship. For example:
 the song is performed by the performer
 the performer performs the song
Role naming
It has also become prevalent to name roles with phrases e.g. is-the-owner-of and is-owned-by etc.
Correct nouns in this case are "owner" and "possession". Thus "person plays the role of owner" and
"car plays the role of possession" rather than "person plays the role of is-the-owner-of" etc.
The use of nouns has direct benefit when generating physical implementations from semantic
models. When a person has two relationships with car then it is possible to very simply generate
names such as "owner person" and "driver person" which are immediately meaningful.
Cardinalities
Some modifications to the original specification are beneficial. Chen described look-across
cardinalities. UML perpetuates this. (As an aside, the Barker-Ellis notation, used in Oracle Designer,
uses same-side for minimum cardinality (analogous to optionality) and role, but look-across for
maximum cardinality (the crows foot)).

ER MODEL-
1.9 Tables
Description
Login:

Company Official:

Policy:

Health Insurance:
Life Insurance:

Home Insurance:

House Members:

Motor Insurance:
Nominee:

Customer:

Loan:
2.1 Screen Shots
Home

Employee Login:
Generate Policies:

Policy Details Home:

Insurance Detail:

Loan Calculator:
Payment Schedule:

Payments:
Change Password:

Discussion Forum:
2.2 VALIDATION LIST
 Employee Login
 Loan Calculator
 Change Password

Thank you
CERTIFICATE OF ORIGINALITY

This is to certify that the project report entitled………………………………………………………

Submitted to the Department of Computer Applications, Sinhgad Institute of Business

Administration and Research in partial fulfilment of the requirement for the award of
the degree of MASTER OF COMPUTER APPLICATIONS (MCA Affiliated to Savitribai
Phule Pune University), is an original work carried out by
Mr/Ms……………………………………………………………………………… Exam No……………. ……………… under my
guidance.

The matter embodied in this project is a genuine work done by the student and has not
been submitted whether to this Organization or to any other University/ Organization
for the fulfilment of the requirement of any course of study.

Signature of the Student:

Name of the student:

Signature of the Guide:

Name and Designation of the Guide:

Signature of Director-MCA

Dr. Arpita Gopal:

Date:
CERTIFICATE OF APPROVAL

This is to certify that the project report entitled…………………………………………

submitted to the Department of Computer Application, Sinhgad Institute of Business

Administration and Research in partial fulfilment of the requirement for the award of
the Degree of MASTER OF COMPUTER APPLICATIONS (MCA Affiliated to Savitribai
Phule Pune University) is an original work carried out by Mr./Ms.......................................

Exam No…………………………………… The matter embodied in this project is a genuine work done
by the student and has been certified by the following internal and external examiners
deputed by Savitribai Phule Pune University.

Internal Examiner External Examiner