A Project Report on Insurance System with Tracking Manager

Source code : https://github.com/sachinkariyattin/Insurance-System

1. Date of submission: 24.05.2013













Shri Dharmasthala Manjunatheshwar College of Engineering &Technology
Dharwad-580002
(Department of Computer Science & Engineering)
Team Members
Amol Ekande 2SD10CS010
Sachin Kariyattin 2SD10CS083
Sachin Ostawal 2SD10CS084
Vineet Doddamani 2SD10CS118

Project Guide
H. Manoj.T. Gadiyar
Lecturer
Dept. of Computer Science
& Engineering

Team Name

TECH CRUNCHERS
Project Report On
INSURANCE SYSTEM WITH TRACKING MANAGER

2. Insurance System With Tracking Manager Page 1

Contents:

1.0 Introduction 2
1.1 Purpose 2
1.2 Scope 2
1.3 Definition, Acronyms 2
1.4 Technologies To be Used 3
1.4.1 NetBeans 3
1.4.2 Glassfish 4
1.4.3 UML Designing Tool 4
1.4.4 Back End DB2 4
1.4.5 Front End JSP 8
1.5 Overview 9
1.6 Use Case Design 9
1.7 Class Diagram 12
1.8 Sequence Diagram 13
1.9 ER Diagram 16
2.0 Tables Description 19
2.1 Activity Diagram 22
2.2 Screen Shots 24

3. Insurance System With Tracking Manager Page 2

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

4. Insurance System With Tracking Manager Page 3


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
Stable release 7.3 / February 21, 2013
Written in Java
Operating system Cross-platform (multi-platform)
Platform Java SE
Available in Multilingual
Type Java IDE
License CDDL or GPL2 + "certain source
files" allowclasspath exception
Website netbeans.org

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

5. Insurance System With Tracking Manager Page 4


1.4.2 Glassfish Server-
Glassfish 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) with the class path. Glassfish is the reference
implementation of Java EE and a s such supports Enterprise JavaBeans, JPA, Java Server
Faces, JMS, RMI, JavaServer Pages, servlets, etc. This allows developers to create enterprise
applications that are portable and scalable, and that integrate with legacy technologies. Optional
components can also be installed for additional services. Glassfish is based on source code released by
Sun and Oracle Corporation's TopLink persistence system. It uses a derivative of Apache Tomcat as
the servlet container for serving Web content, with an added component called Grizzly which uses
Java New I/O (NIO) for scalability and speed.

1.4.3 UML MODELLING TOOL

RATIONAL ROSE-
Rational Rose is an object-oriented Unified Modeling Language (UML) software design tool
intended for visual modeling and component construction of enterprise-level software applications. In much
the same way a theatrical director blocks out a play, a software designer uses Rational Rose to visually
create (model) the framework for an application by blocking out classes with actors (stick figures), use
case elements (ovals), objects (rectangles) and messages/relationships (arrows) in a sequence diagram
using drag-and-drop symbols. Rational Rose documents the diagram as it is being constructed and then
generates code in the designer's choice of C++, Visual Basic, Java, Oracle8, Corba or Data Definition
Language.
Two popular features of Rational Rose are its ability to provide iterative development and round-trip
engineering. Rational Rose allows designers to take advantage of iterative development (sometimes called
evolutionary development) because the new application can be created in stages with the output of one
iteration becoming the input to the next. (This is in contrast to waterfall development where the whole
project is completed from start to finish before a user gets to try it out.) Then, as the developer begins to
understand how the components interact and makes modifications in the design, Rational Rose can
perform what is called "round-trip engineering" by going back and updating the rest of the model to ensure
the code remains consistent.
1.4.4 DATABASE PLATFORM- DB2



Developer(s) IBM

6. Insurance System With Tracking Manager Page 5

Initial release 1983
Development status Active
Written in C, C++
Operating system Cross-platform
Available in English
Type RDBMS
License Proprietary EULA



The name DB2 was first given to the Database Management System or DBMS in 1983 when IBM
released DB2 on its MVS mainframe platform
[1]
. 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.
To apply the model Codd needed a relational database language he named Alpha. At the time
IBM didn't believe in the potential of Codd's ideas, leaving the implementation to a group of programmers
not under Codd's supervision, who violated several fundamentals of Codd's relational model; the result
was Structured English QUEry Language or SEQUEL. When IBM released its first relational database
product, they wanted to have a commercial-quality sublanguage as well, so it overhauled SEQUEL and
renamed the basically new language (System Query Language) SQL to differentiate it from SEQUEL. IBM
bought Metaphor Computer Systems to utilize their GUI interface and encapsulating SQL platform that had
already been in use since the mid 80's.
When Informix acquired Illustra and made their database engine an object-SQL DBMS by
introducing their Universal Server, both Oracle and IBM followed suit by changing their database engines
to be capable of object-relational extensions. In 2001, IBM bought Informix and in the following years
incorporated Informix technology into the DB2 product suite. Today, DB2 can technically be considered to
be an object-SQL DBMS.
For some years DB2, as a full-function DBMS, was exclusively available on IBM mainframes. Later
IBM brought DB2 to other platforms, including OS/2, UNIX and Windows servers, then Linux (including
Linux on zSeries) and PDAs. This process occurred through the 1990s. The inspiration for the mainframe
version of DB2's architecture came in part from IBM IMS, a hierarchical database, and its dedicated

7. Insurance System With Tracking Manager Page 6

database manipulation language, IBM DL/I. DB2 is also embedded in the i5/OS operating system for IBM
System i (iSeries, formerly the AS/400), and versions are available for z/VSE and z/VM.
An earlier version of the code that would become DB2 LUW (Linux, Unix, Windows) was part of an
Extended Edition component of OS/2 called Database Manager. IBM extended the functionality of
Database Manager a number of times, including the addition of distributed database functionality that
allowed shared access to a database in a remote location on a LAN. Eventually IBM declared that
insurmountable complexity existed in the Database Manager code, and took the difficult decision to
completely rewrite the software in their Toronto Lab. The new version of Database Manager, called DB2
like its mainframe parent, ran on the OS/2 and RS/6000 platforms, was called DB2/2 and DB2/6000
respectively. Other versions of DB2, with different code bases, followed the same '/' naming convention
and became DB2/400 (for the AS/400), DB2/VSE (for the DOS/VSE environment) and DB2/VM (for the VM
operating system). IBM lawyers stopped this handy naming convention from being used and decided that
all products needed to be called "product FOR platform" (for example, DB2 for OS/390).
The next iteration of the mainframe and the server-based products were named DB2 Universal
Database (or DB2 UDB), a name that had already been used for the Linux-Unix-Windows version, with the
introduction of widespread confusion over which version (mainframe or server) of the DBMS was being
referred to. At this point, the mainframe version of DB2 and the server version of DB2 were coded in
entirely different languages (PL/S for the mainframe and C++ for the server), but shared similar
functionality and used a common architecture for SQL optimization: the Starburst Optimizer.
Over the years DB2 has both exploited and driven numerous hardware enhancements,
particularly on IBM System z with such features as Parallel Sysplex data sharing. In fact, DB2 UDB
Version 8 for z/OS now requires a 64-bit system and cannot run on earlier processors, and DB2 for z/OS
maintains certain unique software differences in order to serve its sophisticated customers. Although the
ultimate expression of software-hardware co-evolution is the IBM mainframe, to some extent that
phenomenon occurs on other platforms as well, as IBM's software engineers collaborate with their
hardware counterparts.
In the mid-1990s, IBM released a clustered DB2 implementation called DB2 Parallel Edition,
which initially ran on AIX. This edition allowed scalability by providing a shared nothing architecture, in
which a single large database is partitioned across multiple DB2 servers that communicate over a high-
speed interconnect. This DB2 edition was eventually ported to all Linux, UNIX, and Windows (LUW)
platforms and was renamed to DB2 Extended Enterprise Edition (EEE). IBM now refers to this product as
the Database Partitioning Feature (DPF) and sells it as an add-on to their flagship DB2 Enterprise product.
In mid 2006, IBM announced "Viper," which is the codename for DB2 9 on both distributed
platforms and z/OS. DB2 9 for z/OS was announced in early 2007. IBM claimed that the new DB2 was the
first relational database to store XML "natively". Other enhancements include OLTP-related improvements
for distributed platforms, business intelligence/data warehousing-related improvements for z/OS, more
self-tuning and self-managing features, additional 64-bit exploitation (especially for virtual storage on
z/OS), stored procedure performance enhancements for z/OS, and continued convergence of the SQL
vocabularies
 Improved operational efficiencies for "out-of-the-box" DB2 CPU savings
 Unsurpassed resiliency for business-critical information
 Rapid application and warehouse deployment for business growth
 Enhanced business analytics and data visualization solutions with QMF

Selected features that deliver these valuable benefits to any business include:
 When compared to running on DB2 9, depending on the workload, customers may experience
reduced CPU utilization
 When compared to running DB2 9, up to five to ten times more concurrent users on a single
subsystem by avoiding memory constraints
 Greater concurrency for data management, data definition, and data access, including DDL, BIND,
REBIND, PREPARE, utilities, and SQL

8. Insurance System With Tracking Manager Page 7

 Additional online changes for data definitions, utilities, and subsystems
 Improved security with better granularity for administrative privileges, data masking, and audit
capabilities
 Temporal or versioned data to understand system and business times at the database level (Bi-
temporal feature is not available on Oracle or any other competing RDBMS products)
 pureXML™ and SQL enhancements to simplify portability from other database solutions
 Productivity improved for database administrators, application programmers, and systems
administrators
 QMF Classic Edition, an optional for-charge feature, providing greater interoperability with other
programs plus improved queries, forms, diagnostics, performance, and resource control
 QMF Enterprise Edition, an optional for-charge feature, supporting QMF-based dashboards with
visually rich page-based reports, an enhanced security model, support for HTML, PDF, or Flash
QMF report and dashboard outputs and simplified content authoring
IBM and SAP have cooperated very closely on DB2 10 for z/OS, so now SAP users can benefit from
DB2's scalability and performance enhancements significantly that allow for further growth of SAP
applications and consolidation of hardware landscape at the same time.
Competition
IDC's Worldwide Database Management Systems 2009–2013 Forecast and 2008 Vendor Shares
[2]
ranks
Oracle database as the leader in DBMS marketing share, followed by IBM DB2 and then Microsoft SQL
Server. Other competitors include open source products such as Firebird, PostgreSQL, MySQL and
Ingres, and niche players such as Sybase and MaxDB.
Technical information
DB2 can be administered from either the command-line or a GUI. The command-line interface requires
more knowledge of the product but can be more easily scripted and automated. The GUI is a multi-
platform Java client that contains a variety of wizards suitable for novice users. DB2 supports both SQL
and XQuery. DB2 has native implementation of XML data storage, where XML data is stored as XML (not
as relational data or CLOB data) for faster access using XQuery. DB2 has APIs for REXX, PL/I, COBOL,
RPG, FORTRAN, C++, C, Delphi, .NET CLI, Java, Python, Perl, PHP, Ruby, and many other programming
languages. DB2 also supports integration into the Eclipse and Visual Studio integrated development
environments.
Error processing
An important feature of DB2 computer programs is error handling. The SQL communications area
(SQLCA) structure was once used exclusively within a DB2 program to return error information to the
application program after every SQL statement was executed. The primary, but not singularly useful, error
diagnostic is held in the field SQLCODE within the SQLCA block.
The SQL return code values are:
 0 means successful execution.
 A positive number means successful execution with one or more warnings. An example is +100 ,
which means no rows found.
 A negative number means unsuccessful with an error. An example is -911, which means a lock
timeout (or deadlock) has occurred, triggering a rollback.
Later versions of DB2 added functionality and complexity to the execution of SQL. Multiple errors or
warnings could be returned by the execution of an SQL statement; it may, for example, have initiated a
Database Trigger and other SQL statements. Instead of the original SQLCA, error information should now
be retrieved by successive executions of a GET DIAGNOSTICS statement.

9. Insurance System With Tracking Manager Page 8

1.4.5 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.
Java Server Pages (JSP) is a technology that helps software developers create dynamically
generated web pages based on HTML, XML, or other document types. Released in 1999 by Sun
Microsystems
]
, JSP is similar to PHP, but it uses the Java programming language. To deploy and run, a
compatible web server with a servlet container (such as Apache Tomcat) is required with it.
Overview:
Architecturally, JSP may be viewed as a high-level abstraction of Java servlets. JSPs are translated into
servlets at runtime; each JSP's servlet is cached and re-used until the original JSP is modified. JSP can be
used independently or as the view component of a server-side model–view–controller design, normally
with JavaBeans as the model and Java servlets (or a framework such as Apache Struts) as the controller.
This is a type of Model 2 architecture. JSP allows Java code and certain pre-defined actions to be
interleaved with static web markup content, with the resulting page being compiled and executed on the
server to deliver a document. The compiled pages (and any dependent Java libraries) use Java byte code
rather than a native software format. Like any other Java program, they must be executed within a Java
virtual machine (JVM) that integrates with the server's host operating system to provide an abstract
platform-neutral environment. JSP pages are usually used to deliver HTML and XML documents, but
through the use of Output Stream, they can deliver other types of data as well. JSP pages use several
delimiters for scripting functions. The most basic is <% ... %>, which encloses a JSP script let. A script let
is a fragment of Java code that is run when the user requests the page. Other common delimiters include
<%= ... %> for expressions, where the value of the expression is placed into the page delivered to the
user, and directives, denoted with <%@ ... %>. Java code is not required to be complete (self contained)
within its script let element block, but can straddle markup content providing the page as a whole is
syntactically correct. For example, any Java if/for/while blocks opened in one script let element must be
correctly closed in a later element for the page to successfully compile. Markup which falls inside a split
block of code is subject to that code, so markup inside an if block will only appear in the output when the if
condition evaluates to true; likewise, markup inside a loop construct may appear multiple times in the
output depending upon how many times the loop body runs.
Comparison with similar technologies
JSP pages are similar to PHP pages and ASP.NET Web Forms, in that all three add server-side code to
an HTML page. However, all three terms refer to a different component of the system. JSP refers to the
JSP pages, which can be used alone, with Java servlets, or with a framework such as Apache Struts. PHP
is itself a programming language, designed for dynamic Web pages. ASP.net is a framework comparable
to Struts or Java Server Faces that uses pages called Web Forms. While JSP pages use the Java
language, ASP.NET pages can use any .NET-compatible language (usually C#).ASP.NET is designed for

10. Insurance System With Tracking Manager Page 9

a Microsoft Windows web server, while PHP and Java server technologies (including JSP) support
Windows or GNU/Linux, among other platforms.
Criticism
In 2000, Jason Hunter criticized JSP for either tempting or requiring the programmer to mix Java code and
HTML markup, although he acknowledged it would "wean people off of" Microsoft's Active Server Pages.
Later, he added a note to his site saying that JSP had improved since 2000, but also cited its competitors,
Apache Velocity and Tea.
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 book[1] helped to popularize the technique for capturing functional
requirements, especially in software development. Originally he used the terms usage scenarios and
usage case – the latter being a direct translation of his Swedish term användningsfall – but found that
neither of these terms sounded natural in English, and eventually he settled on use case.[2] Since then,
others have contributed to improving this technique, notably including Alistair Cockburn.
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

11. Insurance System With Tracking Manager Page 10

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 Objectory
notation. SysML, 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.

12. Insurance System With Tracking Manager Page 11


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.






Approve Policies
Update Information
calculate EMI
Calculate Interest
Pay Premium
Administrator
Customer
(from Actors)
Discussion Forum
Login
View Profile
View Details
Grant Loans
Generate Policies
Company
Officials

13. Insurance System With Tracking Manager Page 12




1.7 Class Diagram-

14. Insurance System With Tracking Manager Page 13

1.8 Sequence Diagram-
A sequence diagram in a Unified Modeling Language (UML) is a kind of interaction diagram that
shows how processes operate with one another and in what order. It is a construct of a Message
Sequence Chart. A sequence diagram shows object interactions arranged in time sequence. It depicts
the objects and classes involved in the scenario and the sequence of messages exchanged between the
objects needed to carry out the functionality of the scenario. Sequence diagrams typically are associated
with use case realizations in the Logical View of the system under development.
Sequence diagrams are sometimes called event diagrams, event scenarios, and timing diagrams.

Sequence Diagram for Policy Holders-

15. Insurance System With Tracking Manager Page 14






Sequence Diagram for Company Officials-

16. Insurance System With Tracking Manager Page 15




Sequence Diagram for Admin-

17. Insurance System With Tracking Manager Page 16

1.9 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 level 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.[3]
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.

18. Insurance System With Tracking Manager Page 17

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 particular 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.[citation needed]
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'.[original research?]

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[citation needed]
Role naming

19. Insurance System With Tracking Manager Page 18

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.[citation needed].
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)).[clarification needed]
In Merise, Elmasri & Navathe and others there is a preference for same-side for roles and both minimum
and maximum cardinalities. Recent researchers (Feinerer, Dullea et al.) have shown that this is more
coherent when applied to n-ary relationships of order > 2.
In Dullea et al. one reads "A 'look across' notation such as used in the UML does not effectively represent
the semantics of participation constraints imposed on relationships where the degree is higher than
binary."
In Feinerer it says "Problems arise if we operate under the look-across semantics as used for UML
associations. Hartmann investigates this situation and shows how and why different transformations fail."
(Although the "reduction" mentioned is spurious as the two diagrams 3.4 and 3.5 are in fact the same) and
also "As we will see on the next few pages, the look-across interpretation introduces several difficulties
which prevent the extension of simple mechanisms from binary to n-ary associations."

ER MODEL-

2.0 Tables Description-

20. Insurance System With Tracking Manager Page 19

Login:


Company Official:








Policy:

Health Insurance:

Life Insurance:

21. Insurance System With Tracking Manager Page 20

House Insurance:

House Members:

Vehicle Insurance:

Query:



Reply:

22. Insurance System With Tracking Manager Page 21

Nominee:

Customer:

Receipt:


Loan:

23. Insurance System With Tracking Manager Page 22






2.1 Activity Diagrams:
Activity diagrams are graphical representations of workflows of stepwise activities and actions with
support for choice, iteration and concurrency. In the Unified Modeling Language, 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 are constructed from a limited number
of shapes, connected with arrows. The most important shape types:
 rounded rectangles represent activities;
 diamonds represent decisions;
 bars represent the start (split) or end (join) of concurrent activities;
 a black circle represents the start (initial state) of the workflow;
 an encircled black circle represents the end (final state).
Arrows run from the start towards the end and represent the order in which activities happen. Hence they
can be regarded as a form of flowchart. Typical flowchart techniques lack constructs for expressing
concurrency. However, the join and split symbols in activity diagrams only resolve this for simple cases;
the meaning of the model is not clear when they are arbitrarily combined with decisions or loops.

24. Insurance System With Tracking Manager Page 23

User Login:

The activities involved in the above diagram are:

 Visit the site: Initially the user visits the site.
 Username and Password: Then the user enters the username and password.
 Verification: The entered username and password are verified.
 Login successful: If the entered details are valid then login successful.
 If the entered details are invalid then he reenters the username and password.
 Homepage: After successful login the user visits the homepage.







2.2 ScreenShots

25. Insurance System With Tracking Manager Page 24

Home Page:


Employee Login:




Generate Policies:

26. Insurance System With Tracking Manager Page 25



Policy Details Home:





Insurance Detail:

27. Insurance System With Tracking Manager Page 26



Loan Calculator:





Payment Schedule:

28. Insurance System With Tracking Manager Page 27



Payments:





Change Password:

29. Insurance System With Tracking Manager Page 28



Discussion Forum: