Abstract

Insurance Management system is an intranet based private web application, which is designed by a group of insurance Agent agents, to make their application work of insurance policies and claims process easier and flexible. The web based application is used within their organization under the distributed accessibility to check the status of the customers who have taken new policies and their proper track and reminding of policy premium payments and claim conditions. The system is actually developed to cater to the process speed up in their Business process such that the customer satisfaction rates increase and the generic flow of customers into this domain follows a smooth and steady fashion. The major problem under the manual process is to keep track of the existing insurance policy holders, and remaining them at regular intervals about their policy premium payments. In order to render the ordinary services also it takes a great lot of time in just searching through the registers for the existing customers base. If the process of data storage can be automated and follow up of search can be increased, there is always a heavy chance of getting extra customers in turn, which can increase the profits ratio upon the organization. The actual purpose of going for this system is to make the organizational process to get speed up. The Agents can have the expected information at its desk at any time, with respect to any instance. Generating required reports as per the operational requirements becomes much easier and information availability at hand. The system not only becomes false proof, and higher levels of satisfaction prevail at the side of customer. The application is also security oriented and gets associated within the system, as the general structure of accessibility is fastly demandable.

Any registered Agent within the organization can get on to the system to know the specific information, which he feels that it is requirement with respect to the business policies. The referential information also gets ported on to the forms, where the search criteria are greatly reduced. The total portal has been planned to be associated through the conceptual constant of the .NET Framework network and databases technologies, the concept handles the late trends that are set for higher date transfer rates optimized bandwidth utilizations of the network by using the technologies like C#.NET the web content is applied through dynamic with oriental usage of ASP.NET at various stages.

Project Synopsis

The entire project has been developed keeping in view of the distributed client server computing technology, in mind. The specifications have been normalized up to 3NF to eliminate all the anomalies that may arise due to the database transaction that are executed by the general users and the organizational administration. The user interfaces are browser specific to give distributed accessibility for the overall system. The internal database has been selected as MS-SQL server 2000.The basic constructs of table spaces, clusters and indexes have been exploited to provide higher consistency and reliability for the data storage. The MS-SQL server 200 was a choice as it provides the constructs of high-level reliability and security. The total front end was dominated using the ASP.Net technologies. At all proper levels high care was taken to check that the system manages the data consistency with proper business rules or validations. The database connectivity was planned using the latest SQL Connection technology provided by Microsoft Corporation. The authentication and authorization was crosschecked at all the relevant stages. The user level accessibility has been restricted into three zones namely Admin Zone, Agents Zone, Customer Zone.

About The Organization

Manual Process

Customer

Explains the policy details

Physically Visits Waits for response

Dispatches the information with the insurance company Registers him with a insurance policy of the customer choice

Continues on the one or two follow-ups

If customer approve to take a policy

Regularly checks her ledgers to cross check the premium payment customers for that month

Prepare a list of all the customers

Details the information related to the reminders and types them physically

Sends reminders port

the through

Checks and verifies the portal addresses

As the above diagrams depict, it is a very tedious process for the Agent to keep track through the system, related to what is happening and the required information that generically may be needed at all stages. In the customer base increases the manual search process is too tedious and time consuming which can frustrate the Agent as well as the customer many times.

Why the new system? With the new system the following activities get more momentum. 1. The actual process of the organization can be modularized into three different independent views Agent view Policy holders view System administrators view 2. The Agent at any time can view the required information whether it is policies, or customers at the click of a mouse and instance of a second. 3. If planned in an organized manner the customers can be provided an online terminal where they can access the information at their own hands with out the basic intervention manually. 4. The customers or policyholders reminders can be generated at lightening speed just by query for the specific customers. 5. The information while it is collected can referentially be segregated into their respective databases from single window, saving the time of multiple data entries. 6. The customers policy premium payment status can be viewed in a systematized manner by the Agents and cross verify the defaulters. 7. The claim status raised by a specific policyholder can be tracked very clearly in a transparent manner, and checked until the claim is settled. 8. Above all the overall system can at any time provide consistent and reliable information authenticated upon its operations.

Feasibility Report

Technical Descriptions Database: The total number of databases that were identified to build the system is 13. The major parts of the databases are categorized as administration components and customer of based components. The administration components are useful is managing the actual master date that may be necessary to maintain the consistency of the system. These databases purely used for the internal organizational needs and necessities. The Agent, policyholder and system administrator components are designed to handle to transactional states that arise upon the system whereas customer makes a visit onto the portal for the same of a product purchase. The customers components are scheduled accept parametrical information from the uses as per the system necessity. Whenever the Agent or the policy holder makes a visit onto the user interface for the sake of information related to the policies, payments, claims etc. The Agents and policy holder components are scheduled to accept parametrical information from them as per the systems necessity. GUI In the flexibility of the uses the interface has been developed a graphics concept in mind, associated through a browses interface. The GUIS at the top level have been categorized as Administration users interface Agents and Customer users interface The Administration users interface concentrate on the consistent in that is practically part of organizational activities and which needs proper

authentication for date collation. These interfaces to the visitors with all the transactional states lute date in date deletion and date updation only with the Date search capabilities. The Agents and policyholders user interface helps the respective actors in transactions the actual information as per their necessities with specific to the required services. The GUIs restrict the ordinary users from mismanipulating the systems data, which can make the existing system nonoperational. The information with specific to their personal standards and strategies can be changed through proper privileges.
Number of Modules
1)

Insurance

company

information

module:

This

module

maintains the information related to all the insurance companies that exist within the Business domain. This module integrates itself to the policies module and the customer policies module to maintain the proper integration and consistency that can arise necessary from time to time.
2)

Agents information module:

This

module

maintains

the

information related to all the Agents who got registered upon the system. This module fairly maintains the integration between the modules related to companies and the policyholders who have come up onto the system for registering themselves for anew policy. This module also binds itself with the customers claims and premium payment schedules.
3)

Customers information module: This module maintains the information related to the customers who have been signed upon to the system. The module integrates itself with the other modules like the policies that are provided by the company. This

module acts as a major integrator with customers premium and the claims that are raised by the customers.
4)

Policies Information module: This module manages the information related the policies that are uniquely launched by the companies. The entire policy information is revealed in this module. The module manages itself to have an integrated relational approach with the customer policies and the premium payments that are executed by the customers. The module takes care of the overall integration among the systems existence with specific to the general necessities.

5)

Policy payments module: This module manages and keeps track of the policy payments by the registered policyholders. It has interaction to policy information module to keep track of the consistency of information form time to time as they are executed.

6)

Policy claims module: This module manages and keeps track of the policy claims that are raised by the policyholders. Its priority of check is executed with modules of policy payments and policy information modules. This module integrates with the above two modules to keep track of the specification like consistency and integrity.

7)

Security information module: This module standardizes the security issues that come up on to the system when an authorized person should make his entry onto the database .The system manages the information related to the authorized staff that is entitled to work upon the existing database in a confidential manner.

Financial Feasibility It across references ourselves through the manual process that is given in the earlier chapters, by visiting the customer personally and counseling him, it always costs the time and effort of the brocker. On the on are average as the physical system was studied, the number of customers who can be visited physically in a day are not more than five. Two numbers does not suite organization in any way with specific to the capital of the investment to the profits what it is achieving. If the number of customer base can be increased ,the overall profit up on the organization drastically increased. The only way that is possible is to give the customer a touch of semen with the required information in the least possible time at hand and elaborate his sense of psychological thinking. This kind of approach is possible. When the information is at hand.

When the system is computerized and the database is maintained as a relational timestamp, it is always easy to keep that level of information in front of customer at a proper glance with in a short period of time. This approach increases the total number of customers, hereby increasing the overall profit of the organization. The proper arrangement of the data in a relational approach also can help the agents in the providing the value added services like policy premium payment remainders new policy arrivals, claims that are scheduled for the next of the immediate month etc., Which in turn increases the overall goodwill of the system and can get as a word of the month advertisement in the market.

Analysis Report
SRS Document: Intended Audience And Reading Suggestions The document is prepared keeping is view of the academic constructs of my Bachelors Degree / Masters Degree from university as partial fulfillment of my academic purpose the document specifies the general procedure that that has been followed by me, while the system was studied and developed. The general document was provided by the industry as a reference guide to understand my responsibilities in developing the system, with respect to the requirements that have been pin pointed to get the exact structure of the system as stated by the actual client. The system as stated by my project leader the actual standards of the specification were desired by conducting a series of interviews and questionnaires. The collected information was organized to form the specification document and then was modeled to suite the standards of the system as intended. Document Conventions: The overall documents for this project use the recognized modeling standards at the software industries level. ER-Modeling to concentrate on the relational states existing upon the system with respect to Cardinality. The Physical dispense, which state the overall data search for the relational key whereas a transactions is implemented on the wear entities. Unified modeling language concepts to give a

generalized blue print for the overall system.

The standards of flow charts at the required states that are the functionality of the operations need more concentration.

Scope of The Development Project:

Database Tier: The concentration is applied by adopting the MS SQL Server 2000. SQL is taken as the standard query language. User Tier: The user interface is developed in a browser specific environment to have distributed architecture. The components are designed using HTML standards and ASP.NET power the dynamic content generation in the page design. Data Base Connectivity Tier: The communication architecture is designed by concentrating on the standards of ADO.NET technology for database connectivity. Role of MS SQL Server 2000 MS SQL Server 2000 is one of the many database services that plug into a client / server model. It works efficiently to manage resources, a database information, among the multiple clients requesting & sending. Structured Query Language (SQL) SQL is an inter-active language used to query the database and access data in database. SQL has the following features: 1. It is a unified language. 2. It is a common language for relational database

3. It is a non-procedural language.

Introduction to MS SQL Server 2000 Microsoft SQL Server 7.0 Storage Engine Introduction SQL Server 7.0 a scalable, reliable, and easy-to-use product that will provide a solid foundation for application design for the next 20 years. Storage Engine Design Goals Database applications can now be deployed widely due to intelligent, automated storage engine operations. Sophisticated yet simplified architecture improves performance, reliability, and scalability. Feature Reliability Description and Benefits Concurrency, scalability, and reliability are improved with simplified data structures and algorithms. Run-time checks of critical data structures make the database much more robust, minimizing the need for consistency checks. The new disk format and storage subsystem provide storage that is scalable from very small to very large databases. Specific changes include:

Scalability

Simplified mapping of database objects to files eases management and enables tuning flexibility. DB objects can be mapped to specific disks for load balancing.

More efficient space management including increasing page size from 2 KB to 8 KB, 64 KB I/O, variable length character fields up to 8 KB, and the ability to delete columns from existing tables without an unload/reload of the data.

Redesigned utilities support terabyte-sized databases efficiently.

Ease of Use

DBA intervention is eliminated for standard operations enabling branch office automation and desktop and mobile

database applications. Many complex server operations are automated. Storage Engine Features Feature Description and Benefits

Data Type Sizes Maximum size of character and binary data types is dramatically increased. Databases Files Dynamic Memory and Databases creation is simplified, now residing on operating system files instead of logical devices. Improves performance by optimizing memory allocation and usage. Simplified design minimizes contention with other resource managers. Dynamic Row- Full row-level locking is implemented for both data rows and index entries. Dynamic locking automatically chooses the optimal level of lock (row, page, multiple page, table) for all database operations. This feature provides improved concurrency with no tuning. The database also supports the use of "hints" to force a particular level of locking. Dynamic Space A database can automatically grow and shrink within Management configurable limits, minimizing the need for DBA intervention. It is no longer necessary to pre allocate space and manage data structures. Evolution The new architecture is designed for extensibility, with a foundation for object-relational features. Large Support Memory SQL Server 7.0 Enterprise Edition will support memory addressing greater than 4 GB, in conjunction with Windows NT Server 5.0, Alpha processor-based systems, and other techniques. Unicode Native Unicode, with ODBC and OLE DB Unicode APIs, improves multilingual support.

Level Locking

Storage Engine Architectural Overview Overview The original code was inherited from Sybase and designed for eightmegabyte Unix systems in 1983.These new formats improve manageability and scalability and allow the server to easily scale from low-end to high-end systems, improving performance and manageability. Benefits There are many benefits of the new on-disk layout, including: Improved scalability and integration with Windows NT Server Better performance with larger I/Os Stable record locators allow more indexes More indexes speed decision support queries Simpler data structures provide better quality Greater extensibility, so that subsequent releases will have a cleaner development process and new features are faster to implement Storage Engine Subsystems Most relational database products are divided into relational engine and storage engine components. This document focuses on the storage engine, which has a variety of subsystems: Mechanisms that store data in files and find pages, files, and extents. Record management for accessing the records on pages. Access methods using b-trees that are used to quickly find records using record identifiers. Concurrency control for locking, used to implement the physical lock manager and locking protocols for page- or record-level locking. I/O buffer management. Logging and recovery. Utilities for backup and restore, consistency checking, and bulk data loading.

Databases, Files, and File groups Overview SQL Server 7.0 is much more integrated with Windows NT Server than any of its predecessors. Databases are now stored directly in Windows NT Server files. SQL Server is being stretched towards both the high and low end. Files SQL Server 7.0 creates a database using a set of operating system files, with a separate file used for each database. Multiple databases can no longer share the same file. There are several important benefits to this simplification. Files can now grow and shrink, and space management is greatly simplified. All data and objects in the database, such as tables, stored procedures, triggers, and views, are stored only within these operating system files:

File Type Primary file

Description

data This file is the starting point of the database. Every database has only one primary data file and all system tables are always stored in the primary data file.

Secondary data files

These files are optional and can hold all data and objects that are not on the primary data file. Some databases may not have any secondary data files, while others have multiple secondary data files.

Log files

These files hold all of the transaction log information used to recover the database. Every database has at least one log file.

When a database is created, all the files that comprise the database are zeroed out (filled with zeros) to overwrite any existing data left on the disk by previously deleted files. This improves the performance of day-to-day operations.

Filegroups A database now consists of one or more data files and one or more log files. The data files can be grouped together into user-defined filegroups. Tables and indexes can then be mapped to different filegroups to control data placement on physical disks. Filegroups are a convenient unit of administration, greatly improving flexibility. SQL Server 7.0 will allow you to back up a different portion of the database each night on a rotating schedule by choosing which filegroups to back up. Filegroups work well for sophisticated users who know where they want to place indexes and tables. SQL Server 7.0 can work quite effectively without filegroups. Log files are never a part of a filegroup. Log space is managed separately from data space. Using Files and Filegroups Using files and filegroups improves database performance by allowing a database to be created across multiple disks, multiple disk controllers, or redundant array of inexpensive disks (RAID) systems. For example, if your computer has four disks, you can create a database that comprises three data files and one log file, with one file on each disk. As data is accessed, four read/write heads can simultaneously access the data in parallel, which speeds up database operations.Additionally, files and filegroups allow better data placement because a table can be created in a specific filegroup. This improves performance because all I/O for a specific table can be directed at a specific disk. For example, a heavily used table can be placed on one file in one filegroup and located on one disk. The other less heavily accessed tables in the database can be placed on other files in another filegroup, located on a second disk. Space Management There are many improvements in the allocations of space and the management of space within files. The data structures that keep track of page-to-object relationships were redesigned. Instead of linked lists of pages, bitmaps are used because they are cleaner and simpler and facilitate parallel scans. Now each file is more autonomous; it has more data about itself, within itself. This works well for copying or mailing database files.

SQL Server now has a much more efficient system for tracking table space. The changes enable Growing and shrinking files Better support for large I/O Row space management within a table Less expensive extent allocations

SQL Server is very effective at quickly allocating pages to objects and reusing space freed by deleted rows. These operations are internal to the system and use data structures not visible to users, yet are occasionally referenced in SQL Server messages. File Shrink The server checks the space usage in each database periodically. If a database is found to have a lot of empty space, the size of the files in the database will be reduced. Both data and log files can be shrunk. This activity occurs in the background and does not affect any user activity within the database. You can also use the SQL Server Enterprise Manager or DBCC to shrink files as individually or as a group, or use the DBCC commands SHRINKDATABASE or SHRINKFILE. SQL Server shrinks files by moving rows from pages at the end of the file to pages allocated earlier in the file. In an index, nodes are moved from the end of the file to pages at the beginning of the file. In both cases pages are freed at the end of files and then returned to the file system. Databases can only be shrunk to the point that no free space is remaining; there is no data compression. File Grow Automated file growth greatly reduces the need for database management and eliminates many problems that occur when logs or databases run out of space. When creating a database, an initial size for the file must be given. SQL Server creates the data files based on the size provided by the database creator and data is added to the database these files fill. By default, data files are allowed to grow as much as necessary until disk space is exhausted. Alternatively, data files can be configured to grow automatically, but only to

a predefined maximum size. This prevents disk drives from running out of space. Allowing files to grow automatically can cause fragmentation of those files if a large number of files share the same disk. Therefore, it is recommended that files or file groups be created on as many different local physical disks as available. Place objects that compete heavily for space in different file groups. Physical Database Architecture Microsoft SQL Server version 7.0 introduces significant improvements in the way data is stored physically. These changes are largely transparent to general users, but do affect the setup and administration of SQL Server databases. Pages and Extents The fundamental unit of data storage in SQL Server is the page. In SQL Server version 7.0, the size of a page is 8 KB, increased from 2 KB. The start of each page is a 96-byte header used to store system information, such as the type of page, the amount of free space on the page, and the object ID of the object owning the page. There are seven types of pages in the data files of a SQL Server 7.0 database. Page Type Data Contains Data rows with all data except text, ntext, and image. Index Log Index entries Log records recording data changes for use in recovery Text/Image Global Allocation Map Page Free Space Index Allocation Map Text, ntext, and image data Information about allocated extents Information about free space available on pages Information about extents used by a table or index.

To rn P a ge De t e c t i o n

Torn page detection helps insure database consistency. In SQL Server 7.0, pages are 8 KB, while Windows NT does I/O in 512-byte segments. This discrepancy makes it possible for a page to be partially written. This could happen if there is a power failure or other problem between the time when the first 512-byte segment is written and the completion of the 8 KB of I/O. There are several ways to deal with this. One way is to use battery-backed cached I/O devices that guarantee all-or-nothing I/O. If you have one of these systems, torn page detection is unnecessary. In SQL Server 7.0, you can enable torn page detection for a particular database by turning on a database option. Locking Enhancements Row-Level Locking SQL Server 6.5 introduced a limited version of row locking on inserts. SQL Server 7.0 now supports full row-level locking for both data rows and index entries. Transactions can update individual records without locking entire pages. Many OLTP applications can experience increased concurrency, especially when applications append rows to tables and indexes. Dynamic Locking SQL Server 7.0 has a superior locking mechanism that is unique in the database industry. At run time, the storage engine dynamically cooperates with the query processor to choose the lowest-cost locking strategy, based on the characteristics of the schema and query. Dynamic locking has the following advantages: Simplified database administration, because database administrators no longer need to be concerned with adjusting lock escalation thresholds. Increased performance, because SQL Server minimizes system overhead by using locks appropriate to the task.

Application developers can concentrate on development, because SQL Server adjusts locking automatically.

Multigranular locking allows different types of resources to be locked by a transaction. To minimize the cost of locking, SQL Server automatically locks resources at a level appropriate to the task. Locking at a smaller granularity, such as rows, increases concurrency but has a higher overhead because more locks must be held if many rows are locked. Locking at a larger granularity, such as tables, is expensive in terms of concurrency. However, locking a larger unit of data has a lower overhead because fewer locks are being maintained. Lock Modes SQL Server locks resources using different lock modes that determine how the resources can be accessed by concurrent transactions. SQL Server uses several resource lock modes: Lock mode Shared Description Used for operations that do not change or update data (read-only operations), such as a SELECT statement. Update Used on resources that can be updated. Prevents a common form of deadlock that occurs when multiple sessions are reading, locking, and then potentially updating resources later. Exclusive Used for data-modification operations, such as UPDATE, INSERT, or DELETE. Ensures that multiple updates cannot be made to the same resource at the same time. Intent Schema Used to establish a lock hierarchy. Used when an operation dependent on the schema of a table is executing. There are two types of schema locks: schema stability and schema modification.

Table and Index Architecture Overview Fundamental changes were made in

table

organization.

This

new

organization allows the query processor to make use of more nonclustered indexes, greatly improving performance for decision support applications. The query optimizer has a wide set of execution strategies and many of the optimization limitations of earlier versions of SQL Server have been removed. In particular, SQL Server 7.0 is less sensitive to index-selection issues, resulting in less tuning work. Table Organization The data for each table is now stored in a collection of 8-KB data pages. Each data page has a 96-byte header containing system information such as the ID of the table that owns the page and pointers to the next and previous pages for pages linked in a list. A row-offset table is at the end of the page. Data rows fill the rest of the page. SQL Server 7.0 tables use one of two methods to organize their data pages: Clustered tables are tables that have a clustered index. The data rows are stored in order based on the clustered index key. The data pages are linked in a doubly linked list. The index is implemented as a b-tree index structure that supports fast retrieval of the rows based on their clustered index key values. Heaps are tables that have no clustered index. There is no particular order to the sequence of the data pages and the data pages are not linked in a linked list. Table Indexes A SQL Server index is a structure associated with a table that speeds retrieval of the rows in the table. An index contains keys built from one or more columns in the table. These keys are stored in a structure that allows SQL Server to quickly and efficiently find the row or rows associated with the key values. This structure is called a heap. The two types of SQL Server indexes are clustered and nonclustered indexes

Clustered Indexes A clustered index is one in which the order of the values in the index is the same as the order of the data stored in the table. The clustered index contains a hierarchical tree. When searching for data based on a clustered index value, SQL Server quickly isolates the page with the specified value and then searches the page for the record or records with the specified value. The lowest level, or leaf node, of the index tree is the page that contains the data. Non clustered Indexes A non clustered index is analogous to an index in a textbook. The data is stored in one place; the index is stored in another, with pointers to the storage location of the indexed items in the data. The lowest level, or leaf node, of a non clustered index is the Row Identifier of the index entry, which gives SQL Server the location of the actual data row. The Row Identifier can have one of two forms. If the table has a clustered index, the identifier of the row is the clustered index key. If the table is a heap, the Row Identifier is the actual location of the data row, indicated with a page number and offset on the page. Therefore, a non clustered index, in comparison with a clustered index, has an extra level between the index structure and the data itself. When SQL Server searches for data based on a non clustered index, it searches the index for the specified value to obtain the location of the rows of data and then retrieves the data from their storage locations. This makes non clustered indexes the optimal choice for exact-match queries. Some books contain multiple indexes. Since non clustered indexes frequently store clustered index keys as their pointers to data rows, it is important to keep clustered index keys as small as possible. SQL Server supports up to 249 non clustered indexes on each table. The

nonclustered indexes have a b-tree index structure similar to the one in clustered indexes. The difference is that nonclustered indexes have no effect

on the order of the data rows. The collection of data pages for a heap is not affected if nonclustered indexes are defined for the table. Data Type Changes Unicode Data SQL Server now supports Unicode data types, which makes it easier to store data in multiple languages within one database by eliminating the problem of converting characters and installing multiple code pages. Unicode stores character data using two bytes for each character rather than one byte. There are 65,536 different bit patterns in two bytes, so Unicode can use one standard set of bit patterns to encode each character in all languages, including languages such as Chinese that have large numbers of characters. Many programming languages also support Unicode data types. The new data types that support Unicode are ntext, nchar, and nvarchar. They are the same as text, char, and varchar, except for the wider range of characters supported and the increased storage space used. Improved Data Storage Data storage flexibility is greatly improved with the expansion of the maximum limits for char, varchar, binary, and varbinary data types to 8,000 bytes, increased from 255 bytes. It is no longer necessary to use text and image data types for data storage for anything but very large data values. The Transact-SQL string functions also support these very long char and varchar values, and the SUBSTRING function can be used to process text and image columns. The handling of Nulls and empty strings has been improved. A new unique identifier data type is provided for storing a globally unique identifier (GUID). Normalization Normalization is the concept of analyzing the inherent or normal

relationships between the various elements of a database. Data is normalized in different forms. First normal form: Data is in first normal form if data of the tables is moved in to separate tables where data in each table is of a similar type,

giving each table a primary key a unique label or an identifier. This eliminates repeating groups of data. Second normal form: Involves taking out data that is only dependent on part of key. Third normal form: Involves removing the transitive dependencies. This means getting rid of any thing in the tables that doesnt depend Solely on the primary key. Thus, through normalization, effective data storage can be achieved eliminating redundancies and repeating groups.

Client Server Technologies

MS.NET
Overview of the .NET Framework The .NET Framework is a new computing platform that simplifies application development in the highly distributed environment of the Internet. The .NET Framework is designed to fulfill the following objectives: To provide a consistent object-oriented programming environment whether object code is stored and executed locally, executed locally but Internet-distributed, or executed remotely. To provide a code-execution environment that minimizes software deployment and versioning conflicts. To provide a code-execution environment that guarantees safe execution of code, including code created by an unknown or semitrusted third party. To provide a code-execution environment that eliminates the performance problems of scripted or interpreted environments. To make the developer experience consistent across widely varying types of applications, such as Windows-based applications and Webbased applications. To build all communication on industry standards to ensure that code based on the .NET Framework can integrate with any other code. The .NET Framework has two main components: the common language runtime and the .NET Framework class library. The common language runtime is the foundation of the .NET Framework. You can think of the runtime as an agent that manages code at execution time, providing core services such as memory management, thread management, and remoting, while also enforcing strict type safety and other forms of code accuracy that ensure security and robustness. In fact, the concept of code management is a fundamental principle of the runtime. Code that targets the runtime is known as managed code, while code that does not target the runtime is

known as unmanaged code. The class library, the other main component of the .NET Framework, is a comprehensive, object-oriented collection of reusable types that you can use to develop applications ranging from traditional command-line or graphical user interface (GUI) applications to applications based on the latest innovations provided by ASP.NET, such as Web Forms and XML Web services. The .NET Framework can be hosted by unmanaged components that load the common language runtime into their processes and initiate the execution of managed code, thereby creating a software environment that can exploit both managed and unmanaged features. The .NET Framework not only provides several runtime hosts, but also supports the development of thirdparty runtime hosts. For example, ASP.NET hosts the runtime to provide a scalable, server-side environment for managed code. ASP.NET works directly with the runtime to enable Web Forms applications and XML Web services, both of which are discussed later in this topic. Internet Explorer is an example of an unmanaged application that hosts the runtime (in the form of a MIME type extension). Using Internet Explorer to host the runtime enables you to embed managed components or Windows Forms controls in HTML documents. Hosting the runtime in this way makes managed mobile code (similar to Microsoft ActiveX controls) possible, but with significant improvements that only managed code can offer, such as semi-trusted execution and secure isolated file storage.

Features of the Common Language Runtime The common language runtime manages memory, thread execution, code execution, code safety verification, compilation, and other system services. These features are intrinsic to the managed code that runs on the common language runtime. With regards to security, managed components are awarded varying degrees of trust, depending on a number of factors that include their origin (such as

the Internet, enterprise network, or local computer). This means that a managed component might or might not be able to perform file-access operations, registry-access operations, or other sensitive functions, even if it is being used in the same active application. The runtime enforces code access security. For example, users can trust that an executable embedded in a Web page can play an animation on screen or sing a song, but cannot access their personal data, file system, or network. The security features of the runtime thus enable legitimate Internet-deployed software to be exceptionally feature rich. The runtime also enforces code robustness by implementing a strict typeand code-verification infrastructure called the common type system (CTS). The CTS ensures that all managed code is self-describing. The various Microsoft and third-party language compilers generate managed code that conforms to the CTS. This means that managed code can consume other managed types and instances, while strictly enforcing type fidelity and type safety. In addition, the managed environment of the runtime eliminates many common software issues. For example, the runtime automatically handles object layout and manages references to objects, releasing them when they are no longer being used. This automatic memory management resolves the two most common application errors, memory leaks and invalid memory references. The runtime also accelerates developer productivity. For example,

programmers can write applications in their development language of choice, yet take full advantage of the runtime, the class library, and components written in other languages by other developers. Any compiler vendor who chooses to target the runtime can do so. Language compilers that target the .NET Framework make the features of the .NET Framework available to existing code written in that language, greatly easing the migration process for existing applications.

While the runtime is designed for the software of the future, it also supports software of today and yesterday. Interoperability between managed and unmanaged code enables developers to continue to use necessary COM components and DLLs. The runtime is designed to enhance performance. Although the common language runtime provides many standard runtime services, managed code is never interpreted. A feature called just-in-time (JIT) compiling enables all managed code to run in the native machine language of the system on which it is executing. Meanwhile, the memory manager removes the possibilities of fragmented memory and increases memory locality-of-reference to further increase performance. Finally, the runtime can be hosted by high-performance, server-side applications, such as Microsoft SQL Server and Internet Information Services (IIS). This infrastructure enables you to use managed code to write your business logic, while still enjoying the superior performance of the industry's best enterprise servers that support runtime hosting.

Common Type System The common type system defines how types are declared, used, and managed in the runtime, and is also an important part of the runtime's support for cross-language integration. The common type system performs the following functions: Establishes a framework that enables cross-language integration, type safety, and high performance code execution. Provides an object-oriented model that supports the complete

implementation of many programming languages. Defines rules that languages must follow, which helps ensure that objects written in different languages can interact with each other. In This Section Common Type System Overview Describes concepts and defines terms relating to the common type system.

Type Definitions Describes user-defined types. Type Members Describes events, fields, nested types, methods, and properties, and concepts such as member overloading, overriding, and inheritance. Value Types Describes built-in and user-defined value types. Classes Describes the characteristics of common language runtime classes. Delegates Describes the delegate object, which is the managed alternative to unmanaged function pointers. Arrays Describes common language runtime array types. Interfaces Describes characteristics of interfaces and the restrictions on interfaces imposed by the common language runtime. Pointers Describes managed pointers, unmanaged pointers, and unmanaged function pointers. Related Sections . NET Framework Class Library Provides a reference to the classes, interfaces, and value types included in the Microsoft .NET Framework SDK. Common Language Runtime Describes the run-time environment that manages the execution of code and provides application development services.

Cross-Language Interoperability

The common language runtime provides built-in support for language interoperability. However, this support does not guarantee that developers using another programming language can use code you write. To ensure that you can develop managed code that can be fully used by developers using any programming language, a set of language features and rules for using them called the Common Language Specification (CLS) has been defined. Components that follow these rules and expose only CLS features are considered CLS-compliant. This section describes the common language runtime's built-in support for language interoperability and explains the role that the CLS plays in enabling guaranteed cross-language interoperability. CLS features and rules are identified and CLS compliance is discussed.

In This Section Language Interoperability Describes built-in support for cross-language interoperability and introduces the Common Language Specification. What is the Common Language Specification? Explains the need for a set of features common to all languages and identifies CLS rules and features. Writing CLS-Compliant Code Discusses the meaning of CLS compliance for components and identifies levels of CLS compliance for tools. Common Type System Describes how types are declared, used, and managed by the common language runtime.

Metadata and Self-Describing Components Explains the common language runtime's mechanism for describing a type and storing that information with the type itself. . NET Framework Class Library The .NET Framework class library is a collection of reusable types that tightly integrate with the common language runtime. The class library is object oriented, providing types from which your own managed code can derive functionality. This not only makes the .NET Framework types easy to use, but also reduces the time associated with learning new features of the .NET Framework. In addition, third-party components can integrate seamlessly with classes in the .NET Framework. For example, the .NET Framework collection classes implement a set of interfaces that you can use to develop your own collection classes. Your collection classes will blend seamlessly with the classes in the .NET Framework. As you would expect from an object-oriented class library, the .NET Framework types enable you to accomplish a range of common programming tasks, including tasks such as string management, data collection, database connectivity, and file access. In addition to these common tasks, the class library includes types that support a variety of specialized development scenarios. For example, you can use the .NET Framework to develop the following types of applications and services: Console applications Scripted or hosted applications. Windows GUI applications (Windows Forms). ASP.NET applications. XML Web services. Windows services.

For example, the Windows Forms classes are a comprehensive set of reusable types that vastly simplify Windows GUI development. If you write an ASP.NET Web Form application, you can use the Web Forms classes. Client Application Development Client applications are the closest to a traditional style of application in Windows-based programming. These are the types of applications that display windows or forms on the desktop, enabling a user to perform a task. Client applications include applications such as word processors and spreadsheets, as well as custom business applications such as data-entry tools, reporting tools, and so on. Client applications usually employ windows, menus, buttons, and other GUI elements, and they likely access local resources such as the file system and peripherals such as printers. Another kind of client application is the traditional ActiveX control (now replaced by the managed Windows Forms control) deployed over the Internet as a Web page. This application is much like other client applications: it is executed natively, has access to local resources, and includes graphical elements. In the past, developers created such applications using C/C++ in conjunction with the Microsoft Foundation Classes (MFC) or with a rapid application development (RAD) environment such as Microsoft Visual Basic. The .NET Framework incorporates aspects of these existing products into a single, consistent development environment that drastically simplifies the development of client applications. The Windows Forms classes contained in the .NET Framework are designed to be used for GUI development. You can easily create command windows, buttons, menus, toolbars, and other screen elements with the flexibility necessary to accommodate shifting business needs. For example, the .NET Framework provides simple properties to adjust visual attributes associated with forms. In some cases the underlying operating system does not support changing these attributes directly, and in these cases the .NET Framework automatically recreates the forms. This is one of

many ways in which the .NET Framework integrates the developer interface, making coding simpler and more consistent. Unlike ActiveX controls, Windows Forms controls have semi-trusted access to a user's computer. This means that binary or natively executing code can access some of the resources on the user's system (such as GUI elements and limited file access) without being able to access or compromise other resources. Because of code access security, many applications that once needed to be installed on a user's system can now be safely deployed through the Web. Your applications can implement the features of a local application while being deployed like a Web page. Managed Execution Process The managed execution process includes the following steps: Choosing a Complier To obtain the benefits provided by the common language runtime, you must use one or more language compilers that target the runtime. Compiling your code to Microsoft Intermediate Language (MSIL) Compiling translates your source code into MSIL and generates the required metadata. Compiling MSIL to native code At execution time, a just-in-time (JIT) compiler translates the MSIL into native code. During this compilation, code must pass a verification process that examines the MSIL and metadata to find out whether the code can be determined to be type safe. Executing your code The common language runtime provides the infrastructure that enables execution to take place as well as a variety of services that can be used during execution. Assemblies Overview Assemblies are a fundamental part of programming with the .NET Framework. An assembly performs the following functions:

It contains code that the common language runtime executes. Microsoft intermediate language (MSIL) code in a portable executable (PE) file will not be executed if it does not have an associated assembly manifest. Note that each assembly can have only one entry point (that is, DllMain, WinMain, or Main). It forms a security boundary. An assembly is the unit at which permissions are requested and granted. For more information about security boundaries as they apply to assemblies, see Assembly Security Considerations It forms a type boundary. Every type's identity includes the name of the assembly in which it resides. A type called MyType loaded in the scope of one assembly is not the same as a type called MyType loaded in the scope of another assembly. It forms a reference scope boundary. The assembly's manifest contains assembly metadata that is used for resolving types and satisfying resource requests. It specifies the types and resources that are exposed outside the assembly. The manifest also enumerates other assemblies on which it depends. It forms a version boundary. The assembly is the smallest versionable unit in the common language runtime; all types and resources in the same assembly are versioned as a unit. The assembly's manifest describes the version dependencies you specify for any dependent assemblies. For more information about versioning, see Assembly Versioning It forms a deployment unit. When an application starts, only the assemblies that the application initially calls must be present. Other assemblies, such as localization resources or assemblies containing utility classes, can be retrieved on demand. This allows applications to be kept simple and thin when first downloaded. For more information about deploying assemblies, see Deploying Applications

It is the unit at which side-by-side execution is supported. For more information about running multiple versions of the same assembly, see Sideby-Side Execution Assemblies can be static or dynamic. Static assemblies can include .NET Framework types (interfaces and classes), as well as resources for the assembly (bitmaps, JPEG files, resource files, and so on). Static assemblies are stored on disk in PE files. You can also use the .NET Framework to create dynamic assemblies, which are run directly from memory and are not saved to disk before execution. You can save dynamic assemblies to disk after they have executed. There are several ways to create assemblies. You can use development tools, such as Visual Studio .NET, that you have used in the past to create .dll or .exe files. You can use tools provided in the .NET Framework SDK to create assemblies with modules created in other development environments. You can also use common language runtime APIs, such as Reflection. Emit, to create dynamic assemblies. Server Application Development Server-side applications in the managed world are implemented through runtime hosts. Unmanaged applications host the common language runtime, which allows your custom managed code to control the behavior of the server. This model provides you with all the features of the common language runtime and class library while gaining the performance and scalability of the host server. The following illustration shows a basic network schema with managed code running in different server environments. Servers such as IIS and SQL Server can perform standard operations while your application logic executes through the managed code.

Server-side managed code ASP.NET is the hosting environment that enables developers to use the .NET Framework to target Web-based applications. However, ASP.NET is more than just a runtime host; it is a complete architecture for developing Web sites and Internet-distributed objects using managed code. Both Web Forms and XML Web services use IIS and ASP.NET as the publishing mechanism for applications, and both have a collection of supporting classes in the .NET Framework. XML Web services, an important evolution in Web-based technology, are distributed, server-side application components similar to common Web sites. However, unlike Web-based applications, XML Web services components have no UI and are not targeted for browsers such as Internet Explorer and Netscape Navigator. Instead, XML Web services consist of reusable software components designed to be consumed by other applications, such as traditional client applications, Web-based applications, or even other XML Web services. As a result, XML Web services technology is rapidly moving application development and deployment into the highly distributed environment of the Internet. If you have used earlier versions of ASP technology, you will immediately notice the improvements that ASP.NET and Web Forms offers. For example, you can develop Web Forms pages in any language that supports the .NET Framework. In addition, your code no longer needs to share the same file with your HTTP text (although it can continue to do so if you prefer). Web Forms pages execute in native machine language because, like any other managed application, they take full advantage of the runtime. In contrast, unmanaged ASP pages are always scripted and interpreted. ASP.NET pages are faster, more functional, and easier to develop than unmanaged ASP pages because they interact with the runtime like any managed application. The .NET Framework also provides a collection of classes and tools to aid in development and consumption of XML Web services applications. XML Web

services are built on standards such as SOAP (a remote procedure-call protocol), XML (an extensible data format), and WSDL (the Web Services Description Language). The .NET Framework is built on these standards to promote interoperability with non-Microsoft solutions. For example, the Web Services Description Language tool included with the .NET Framework SDK can query an XML Web service published on the Web, parse its WSDL description, and produce C# or Visual Basic source code that your application can use to become a client of the XML Web service. The source code can create classes derived from classes in the class library that handle all the underlying communication using SOAP and XML parsing. Although you can use the class library to consume XML Web services directly, the Web Services Description Language tool and the other tools contained in the SDK facilitate your development efforts with the .NET Framework. If you develop and publish your own XML Web service, the .NET Framework provides a set of classes that conform to all the underlying communication standards, such as SOAP, WSDL, and XML. Using those classes enables you to focus on the logic of your service, without concerning yourself with the communications infrastructure required by distributed software development. Finally, like Web Forms pages in the managed environment, your XML Web service will run with the speed of native machine language using the scalable communication of IIS. Programming with the .NET Framework This section describes the programming essentials you need to build .NET applications, from creating assemblies from your code to securing your application. Many of the fundamentals covered in this section are used to create any application using the .NET Framework. This section provides conceptual information about key programming concepts, as well as code samples and detailed explanations.

Accessing Data with ADO.NET Describes the ADO.NET architecture and how to use the ADO.NET classes to manage application data and interact with data sources including Microsoft SQL Server, OLE DB data sources, and XML. Accessing Objects in Other Application Domains using .NET Remoting Describes the various communications methods available in the .NET Framework for remote communications. Accessing the Internet Shows how to use Internet access classes to implement both Web- and Internet-based applications. Creating Active Directory Components Discusses using the Active Directory Services Interfaces. Creating Scheduled Server Tasks Discusses how to create events that are raised on reoccurring intervals. Developing Components Provides an overview of component programming and explains how those concepts work with the .NET Framework. Developing World-Ready Applications Explains the extensive support the .NET Framework provides for developing international applications. Discovering Type Information at Runtime Explains how to get access to type information at run time by using reflection.

Drawing and Editing Images Discusses using GDI+ with the .NET Framework. Emitting Dynamic Assemblies Describes the set of managed types in the System.Reflection.Emit

namespace. Employing XML in the .NET Framework Provides an overview to a comprehensive and integrated set of classes that work with XML documents and data in the .NET Framework. Extending Metadata Using Attributes Describes how you can use attributes to customize metadata. Generating and Compiling Source Code Dynamically in Multiple Languages Explains the .NET Framework SDK mechanism called the Code Document Object Model (CodeDOM) that enables the output of source code in multiple programming languages. Grouping Data in Collections Discusses the various collection types available in the .NET Framework, including stacks, queues, lists, arrays, and structs. Handling and Raising Events Provides an overview of the event model in the .NET Framework. Handling and Throwing Exceptions Describes error handling provided by the .NET Framework and the

fundamentals of handling exceptions.

Overall Description: Product Perspective: The software application has been developed to out as bridge between the agents and the companies, companies and the customers and the agents and customers. The normal latency that exists in the system is eliminated and also the job scheduling standards becomes very faster within the system. Basic Structure Of The System Maintains and manages the information of all the insurance companies that exists in the industry. Maintains and manages the list of agents who are designated upon the system for executing the business along with applicable avocation of company that belongs to. Maintains and manages the list of all insurance policies exist in the industry, along with the association of the company that executes the specific policy. Maintains and manages the list of all customers who have availed the policies and the associated nominees and dependents. Maintains and manages the information of the customers premium payment standards and the claims if any executed by the policyholders. Specifically maintains the list of agents, who are associated with policy.

Product Functions
The major function that product executes are divided into two categories.
1.Administrative Functions. 2.User Interface Functions.

Administrative Functions: The functions take care of the actual date interpretation standards at the level of the administrative officer area. All these transactions that need consistency function the system existence. All the master table transaction with respect to then data insertion, deletion and updation are totally managed by the system administrators. The generic information maintained by the administrations is: Companies information management Agents information management Customer information management Policies information management Policy payments information management Security information management User interface functions The general functions that are taken care of at the user level are a are the customer can view their respective policy information at any time. The customers can also view their premium payment standards and the claims duration strategy. The system also helps the Agents to just view the standardized information of the customer with whom he has established business policies etc.

Project Plan The total project consists of 7 modules which are particular way has follows: Insurance company information module Agents information module Customer information module Policies information module Policy payment module Policy claims module Security information module The description for all the above modules has been provided in the previous section. Number of Databases: The project consists of 12 databases, which are as follows 1. Insurance companies master: This database maintains the list of all unique insurance companies that participate under the business. 2. Agent Master: This database maintains the list of all the Agents, which are registered with the company. Each Agent uniquely identified within the system. 3. Customer master: This database gives the information of all the customers who are coming upon the system for the executing the standards of the insurance policies. 4. Customer dependent master: This database maintains the information related to the dependent the customer provides.

5. Policies master: This database maintains all the unique policies that are raised by the companies as the part of the insurance business. 6. Customer policies master: This database provides the

information related to which customer has adopted which policy through association of which Agent. 7. Nominees customers. 8. Policy payments master: The database provides the details master: The database provides the

information related to the legal heirs that are represented by the

information related to all premium payments that are executed by the customers. 9. Policy claim master: This database maintains the information that is raised by the policy, holders for claim of their policy as soon as the policy is matured. 10. Claim status code: This database specifically states what are the different statuses that a policy can have while it is under operation. 11. Agent security master: The database maintains the status give information of the Agent login standards. 12. Customer security master: The database maintains the

information related to the customer login standards.

Design Document
Design Document The entire system is projected with a physical diagram which specifics the actual storage parameters that are physically necessary for any database to be stored on to the disk. The overall systems existential idea is derived from this diagram. The relation upon the system is structure through a conceptual ER-Diagram, which not only specifics the existential entities but also the standard relations through which the system exists and the cardinalities that are necessary for the system state to continue. The content level DFD is provided to have an idea of the functional inputs and outputs that are achieved through the system. The system depicts the input and out put standards at the high level of the systems existence. Data Flow Diagrams This Diagram server two purpose. moves

Provides an indication of how data is transformed as it through the system.

Disputes the functions and sub functions that transforms the dataflow. The Data flow diagram provides additional information that

is used during the analysis of the information domain, and server as a basis for the modeling of functions. The description of each function presented in the DFD is

contained is a process specifications called as PSPEC

FIRST LEVEL DTAFLOW DIAGRAM

Insurance Company Information Module

Reports on the Insurance Company Information

Agent Information Module

Reports on the Agent Information Reports on the customer Information

Customer Information Module

Policies Information Module

Insurance Managem ent

Reports on the Policies Information Management Reports on the Policy Payments Information

Policy Payment Module

Policy Claims Module

Report on the Policy Claims Information

Security Information Module

Reports on the Security Information

2nd Level DFDs

DFD For New Insurance Company

Insurance Companies Agent Master

Agent Master

Insert New Insurance Company Agent

Verify Data 1.1

Check for Company Agent

Verify Data 1.2

Check for the Agent

Verify Data Insurance Companies Agent Master Check for Insurance Company 1.3

Inser t
Insurance Companies Master

DFD For New Policy Entry

Policies Master

Company Master

Insert New Policy

Verify Data 2.1

Check for the Policy

Verify Data

2.2

Check for the Company

Insert

Verify Data 2.3

Policies Master

DFD For New Customer Policy Entry

Customer Policies Master

Customer Master

Policy Master

Insert New Customer Policy Verify Data 3.1

Check for Customer Verify Data 3.1

Check for the Customer

Verify Data 3.1

Check for Policy Insert

Customer Policies Master

DFD For New Policy Payment Entry

Customer Policy

Policy Payments Master Check for Payment Verify Data 4.1

Master
Check for the Policy Number Insert

Insert New Policy Payment

Verify Data 4.2

Policy Payments Master

DFD For New Policy Claim Entry

Policy Claim Master

Customer Policy Master

Claim Status Master

Insert New Claim

Verify Data 5.1

Check for Policy Claim

Verify Data 5.2

Check for Policy Number

Verify Data 5.3

Check for the Claim Status Code

Insert

Policy Claim Master

3rd Level DFD

DFD For New Insurance Company

Agent Master

Request a New Insurance Company Agent

Validate Agentid( ) 1.2

Validate Compid()

Insurance Companies Agent Master

1.3

Commit( )

Insurance Companies Master

DFD For New Policy Entry

Policies Master

Company Master

Request for New Policy

Validate Policyid( ) 2.1

Validate Compid() 2.2

Policies Master

Commit( )

Validate Reftypei d() 2.4

Validate Policyid( )

2.3

Policy Ref Type field Master

Policy Type Master

DFD For New Customer Policy Entry

Customer Policies
Master

Customer Master

Policy Master

Request for a New Customer Policy

Validate CustPolic yid()

Validate Custid() 3.2

Validate Policyid()
3.3

3.1

Commit()

Customer Policies Master

DFD For New Policy Payment Entry

Policy Payments Master Request for a New Policy Payment Customer Policy

Master

Validate PolPayid( )

Validate CustPolid( ) 4.2

Commit()

4.1

Policy Payments Master

DFD For New Policy Claim Entry

Claim Master

Customer Policy Master

Claim Status Master

Request For a New Claim

Validate PolClaimid() 5.1 Validate PolicyNO() 5.2

Validate Claimstat usid() 5.3

Commit()

Claim Master

Insurance Management System consists of various tables like login_master,insurance_company_master,agent_master,custom er_master,cust_policy_master,policies_master etc. NOTE: tables. Primary key is denoted by * for all the database

TABLES :

Login_master

SNO

Name

Type

Nullable

1 2

username pwd

varchar varchar

yes yes

INSURANCE_COMPANY_MASTER

SNO

Column_name

Type

Null

1 2 3 4 5 6 7

company_id company_name company_address company_email company_phone company_fax_no

int varchar varchar varchar numeric numeric

no yes yes yes yes yes yes

comapny_website_link varchar

AGENT_MASTER

SN O
1 2 3 4 5 6 7 8

Nullabl Column_name Type agent_id int agent_name agent_address agent_phone_no agent_email_id agent_dob agent_gender agent_experience varchar varchar int varchar datetime varchar int e no yes yes yes yes yes yes yes

Policies_Master

S NO Column_name Type e

Nullabl

* 1 2 3 4 5 6 7 9 10

policy_id policy_name

int varchar

no yes yes yes yes yes yes yes yes

policy_launched_date datetime policy_type_field_id policy_min_value policy_max_value int numeric numeric

policy_min_age_limit int policy_max_age_limit int company_id int

ER-Diagrams

The

entity

Relationship

Diagram

(ERD)

depicts

the

relationship between the data objects. The ERD is the notation that is used to conduct the date modeling activity the attributes of each data object noted is the ERD can be described resign a data object descriptions.

The set of primary components that are identified by the

ERD are

Data object Attributes

Relationships Various types of indicators.

The primary purpose of the ERD is to represent data objects

and their relationships.

ER Diagram

ONLINE TRADING TRANSACTION:

Unified Modeling Language Diagrams

The unified modeling language allows the software engineer

to express an analysis model using the modeling notation that is governed by a set of syntactic semantic and pragmatic rules. A UML system is represented using five different views that

describe the system from distinctly different perspective. Each view is defined by a set of diagram, which is as follows. User Model View i. ii. This view represents the system from the users perspective. The analysis representation describes a usage scenario from the end-users perspective.

Structural model view

In this model the data and functionality are arrived from inside the system.

This model view models the static structures.

Behavioral Model View

It represents the dynamic of behavioral as parts of the system, depicting the interactions of collection between various structural elements described in the user model and structural model view.

Implementation Model View

In this the structural and behavioral as parts of the system are represented as they are to be built.

Environmental Model View

In this the structural and behavioral aspects of the environment in which the system is to be implemented are represented. UML is specifically constructed through two different domains they are

UML Analysis modeling, which focuses on the user model and structural model views of the system.

UML design modeling, which focuses on the behavioral modeling, implementation modeling and environmental model views.

Use Case Diagrams Use cases model the system from the end users point of view, with the following objectives To define the functional and operational requirements of the system by defining a scenario of usage. To provide a class and unambiguous description of how the end user and the system interact with one another. To provide a basis for validation testing.

Use Cases
The actors who have been recognized within the system are 1. Agent 2. Policy holder

3. System administrator High level Diagrams

Agent: This actor acts as a bridge between the companies policies and the policyholders who have taken the policies.

Login

Companies information

Agent

Policies Information

Customer policies

Policy types information

Policy Holder
This actor is the outer who insures himself or any item with a specific policy. He goes for policy premium payments and policy claims from time to time.

Login

Policies information

Policy Holder

Policies Registration

Nominees information

Policy payments

Policy claims

System Administrator
He is the actor who takes care of the actual data administration upon the system. He is the sole responsibility, to check the consistency and reliability of information.

Login

Companies registration

Agent Registration

Admin
Customers Registration Policy Registration

Security information registration

Elaborated Diagrams <<Uses>> Login <<Uses>>

Authenticate login name

<<Uses>> Authenticate password Enable privileged access

<<Uses>>
Raise request for company information

<<Uses>> Authenticate the given parameter <<Uses>> Handle the schedules Query Analyzer

Agent

<<Uses>> Raise request for existing or new policies information <<Uses>>

Raise request for customer policy information
Supply the customer ID
Check for any specific schedules allocated upon him

<<Uses>>

Query Analyzer <<Uses>>

Authenticate the customer ID

<<Uses>> Display

Raise request for generating service report

<<Uses>>

Enter the required policy parameters

<<Uses>> Query Analyzer

<<Uses>> Login

<<Uses>>
Authenticate login name

<<Uses>> Authenticate password Enable privileged access

<<Uses>>
Raise request for new policy or existing policy information

<<Uses>> Authorize the parameter <<Uses>>

Generate a policy ID which is unique

<<Uses>> Display <<Uses>> Select the required policy Supply the nominee details

Enter the required policy parameters

<<Uses>>

Policy Holder

Raise request for new policies registration <<Uses>>

Raise request for policy payment information

<<Uses>>
Accept the policy number Display the payment status & Details

Select policy term & amount Select premium payment period Authenticate data Store

<<Uses>>
Raise request for policy claims
Accept the policy number

<<Uses>> Check for due payments <<Uses>> Check for due payments

<<Uses>> Login

<<Uses>>
Authenticate login name

<<Uses>> Authenticate password Enable privileged access

<<Uses>>
Raise request for new company information

<<Uses>> Enter the required data along with standards <<Uses>> Check the authentic of information

<<Uses>> Store

<<Uses>>

System Administrator

Raise request for new customer registration <<Uses>>

Raise request for new policy registration

Enter the required data as per the standards

Check the authenticity of information

<<Uses>>

Store

Enter the required data as per the standards

<<Uses>>
Check the authenticity of information

<<Uses>>

<<Uses>>
Raise request for new Agent registration

<<Uses>>
Enter the required data as per the standards

<<Uses>> Check for due payments Store

<<Uses>>
Raise request for new user login creation

<<Uses>>
Enter the required data as per the standards

Check the authenticity of information

<<Uses>>

Store

Sequence Diagrams Agent Login

Login screen Enter log name Validate Log name ()

Agent master Validate Password ()

Agent login master

Agent master

Check in required privileges ()

Authentica te the Agent id

Provide privileged access to the Agents view

Policy Holders Login Sequence

Login screen Enter log name Validate Log name ()

Policy login master

Policyholder Customer policy master login master

Validate Password () Check in required privileges () Authenticate the Customer id

Provide privileged access to the Agents view

System Administrator Login Sequence

Login screen Enter log name

Administrator login master Validate

Administrator login master

Employee master

Validate Log name ()

Password ()

Check for required privileges () Authenticate the Employee id

Provide privileged access to the administrations view

Sequence for querying for customer policy information

Customer Customer policy master master screen Customer master Enter the Validate customer Accept number policy Customer ID () number () Authenticate the policy number

Call search function ()

Display data

Coding
Program Design Language The program design language is also called as structured English or pseudopodia. PDL is a generic reference for a design language PDL looks like a modern language. The difference between PDL and real programming language lies in the narrative text embedded directly within PDL statements.

The characteristics required by a design language are:

A fixed system of keywords that provide for all structured constructs date declaration and modularity characteristics. A free syntax of natural language that describes processing features. Date declaration facilities that should include both simple and complex data structures. Subprogram definition and calling techniques that support various nodes of interface description.

PDL syntax should include constructs for subprogram definition, interface description date declaration techniques for structuring, conditions constructs, repetition constructs and I/O constructs. PDL can be extended to include keywords for multitasking and/or concurrent processing interrupt handling, interposes synchronization the

application design for which PDL is to be used should dictate the final form for the design language.

Testing & Debugging Strategies

Testing
Testing is the process of detecting errors. Testing performs a very critical role for quality assurance and for ensuring the reliability of software. The results of testing are used later on during maintenance also.

Psychology of Testing
The aim of testing is often to demonstrate that a program works by showing that it has no errors. The basic purpose of testing phase is to detect the errors that may be present in the program. Hence one should not start testing with the intent of showing that a program works, but the intent should be to show that a program doesnt work. Testing is the process of executing a program with the intent of finding errors.

Testing Objectives The main objective of testing is to uncover a host of errors, systematically and with minimum effort and time. Stating formally, we can say, Testing is a process of executing a program with the intent of finding an error. A successful test is one that uncovers an as yet undiscovered error. A good test case is one that has a high probability of finding error, if it exists. The tests are inadequate to detect possibly present errors. The software more or less confirms to the quality and reliable standards.

Levels of Testing In order to uncover the errors present in different phases we have the concept of levels of testing. The basic levels of testing are as shown below

Client Needs

Acceptance Testing

Requirements

System Testing

Design

Integration Testing

Code

Unit Testing

System Testing The philosophy behind testing is to find errors. Test cases are devised with this in mind. A strategy employed for system testing is code testing. Code Testing: This strategy examines the logic of the program. To follow this method we developed some test data that resulted in executing every instruction in the program and module i.e. every path is tested. Systems are not designed as entire nor are they tested as single systems. To ensure that the coding is perfect two types of testing is performed or for that matter is performed or that matter is performed or for that matter is performed on all systems.

Types Of Testing Unit Testing Link Testing Unit Testing Unit testing focuses verification effort on the smallest unit of software i.e. the module. Using the detailed design and the process specifications testing is done to uncover errors within the boundary of the module. All modules must be successful in the unit test before the start of the integration testing begins. In this project each service can be thought of a module. There are so many modules like Login, HWAdmin, MasterAdmin, Normal User, and PManager. Giving different sets of inputs has tested each module. When developing the module as well as finishing the development so that each module works without any error. The inputs are validated when accepting from the user. In this application developer tests the programs up as system. Software units in a system are the modules and routines that are assembled and integrated to form a specific function. Unit testing is first done on modules, independent of one another to locate errors. This enables to detect errors. Through this errors resulting from interaction between modules initially avoided. Link Testing Link testing does not test software but rather the integration of each module in system. The primary concern is the compatibility of each module. The Programmer tests where modules are designed with different parameters, length, type etc.

Integration Testing After the unit testing we have to perform integration testing. The goal here is to see if modules can be integrated proprerly, the emphasis being on testing interfaces between modules. This testing activity can be considered as testing the design and hence the emphasis on testing module interactions. In this project integrating all the modules forms the main system. When integrating all the modules I have checked whether the integration effects working of any of the services by giving different combinations of inputs with which the two services run perfectly before Integration. System Testing Here the entire software system is tested. The reference document for this process is the requirements document, and the goal os to see if software meets its requirements. Here entire ATM has been tested against requirements of project and it is checked whether all requirements of project have been satisfied or not. Acceptance Testing
Acceptance Test is performed with realistic data of the client to demonstrate that the software is working satisfactorily. Testing here is focused on external behavior of the system; the internal logic of program is not emphasized. In this project Network Management Of Database System I have collected some data and tested whether project is working correctly or not. Test cases should be selected so that the largest number of attributes of an equivalence class is exercised at once. The testing phase is an important part of software development. It is the process of finding errors and missing

operations and also a complete verification to determine whether the objectives are met and the user requirements are satisfied.

White Box Testing This is a unit testing method where a unit will be taken at a time and tested thoroughly at a statement level to find the maximum possible errors. I tested step wise every piece of code, taking care that every statement in the code is executed at least once. The white box testing is also called Glass Box Testing. I have generated a list of test cases, sample data, which is used to check all possible combinations of execution paths through the code at every module level. Black Box Testing This testing method considers a module as a single unit and checks the unit at interface and communication with other modules rather getting into details at statement level. Here the module will be treated as a block box that will take some input and generate output. Output for a given set of input combinations are forwarded to other modules. Criteria Satisfied by Test Cases 1) Test cases that reduced by a count that is greater than one, the number of additional test cases that much be designed to achieve reasonable testing. 2) Test cases that tell us something about the presence or absence of classes of errors, rather than an error associated only with the specific test at hand.

User Manual

Installation The database as it is developed by MS SQL Server 2000 can be installed only by using the export and import concepts. Using .NET components like ASP.NET and VB.NET needs proper deployment as per general specifications developed.

Conclusions & Recommendations

The entire project has been developed and deployed as per the requirements stated by the user, it is found to be bug free as per the testing standards that is implemented. Any specification-untraced errors will be concentrated in the coming versions, which are planned to be developed in near future. The system at present does not take care off the money payment methods, as the consolidated constructs need SSL standards and are critically to be initiated in the first face, the application of the credit card transactions is applied as a developmental phase in the coming days. The system needs more elaborative technicality for its inception and evolution.

B i b l i o g r ap hy :
References for the Project Development were taken from the following Books and Web Sites.

SQL Server
Mastering SQL Server 2000 by Gunderloy, Jorden BPB Publications Beginning SQL Server 2000 by Thearon Willis wrox publications

Visual Basic .NET

Programming Visual Basic .NET, Mircrosoft Press VisulaBasic .NET by Mc Donald, Microsoft Press