ACKNOWLEDGMENT

Firstly, we would like to express our heartfelt gratitude to our project guide Mr Swapnil Soner, for guiding us throughout the course of the project. We are highly indebted to them for their invaluable guidance and ever-ready support, which was necessary for the successful completion of the project in, stipulates time. Their deep knowledge of computer engineering field made us realize that theoretical knowledge always helps develop efficient operational industrial software, which are a blend of all core subjects of the field. Working under their guidance has been a fruitful experience, which will be very valuable for us, when we enter the corporate world. We would like to give a warm expression of thanks to Dr.Sunil Somani, Principal S.V.C.E, Indore for providing the facilities and academic environment for our project work. We also thank our respected Head of Department, Mr J. S. Khatwani, for his valuable guidance and encouragement. We also thank all the staff members for their encouragement and support throughout this project and all those who have embedded us with technical knowledge of computer technology. We sincerely thank to all our friends and well-wishers for directly or indirectly helping us during the course of the work.

ACHINT JAIN (0822CS051003) SACHIN SACHDEV (0822CS051048) YOGESH VISHWANI (0822CS051060)

ABSTRACT
Every one needs a fast and easy access to the medical assistance whether its a small injury or an emergency. As the population of city is increasing day-by-day problems related with health are increasing rapidly. It takes lot of time to search for appropriate medicine practioner or specialists by consulting into the hospitals or clinics. There is no centralized facility which provides easy n convenient access to the medical facility which gives us the required information .We do not have any facility that we could find our nearest located hospitals or clinics so that we dont have to waste much time on them. D is the solution of the problem , which stands for Doctors and Donations . D is a Web Site which provides with a platform which gives us information regarding health .This Web Site provides advanced search of doctors with their Hospitals , Specialization and area . So u can search your desired doctor at the nearest Healthcare Centre. This Web Site also finds the nearest blood donor in case of emergency on basis of its database.

1. INTRODUCTION
1.1 1.2 1.3 1.4 1.5 Problem Definition Problem Solution Need & scope of the project Feature List Report Organization

INTRODUCTION

1.1 PROBLEM DEFINITION

In this fast pace environment, everyone prefers less time consuming and easy going tracks for them. Every one needs a fast and easy access to the medical assistance whether its a small injury or an emergency. As the population of city is increasing day-by-day problems related with health are increasing rapidly. It takes lot of time to search for appropriate medicine practioner or specialists by consulting into the hospitals or clinics. There is no centralized facility which provides easy and convenient access to the medical facility which gives us the required information. We do not have any facility that we could find our nearest located hospitals or clinics so that we dont have to waste much time on them. For taking the appointments and enquiring about either doctors or blood availability or donors one has to keep taking rounds of respective place.

1.2 PROBLEM SOLUTION

D is designed to cope up with the drawbacks of Existing system. Our software is the solution of the problem , which stands for Doctors, Directories and Donations . D is a Web Site which provides with a platform which gives us information regarding health services. This Web Site provides advanced search of doctors with their Hospitals , Specialization and area . So u can search your desired doctor at the nearest Healthcare Centre. This Web Site also finds the nearest blood donor in case of emergency on basis of its database. Through this software one can view all the information related to Doctors, Blood Donations & Hospitals in less time, hence time is reduced. It provides with detailed information that is too in seconds. D is the system which provides a user friendly environment.

1.3 NEED & SCOPE OF THE PROJECT

Need Every one needs a fast and easy access to the medical assistance whether its a small injury or an emergency. As the population of city is increasing day-by-day problems related with health are increasing rapidly. It takes lot of time to search for appropriate medicine practioner or specialists by consulting into the hospitals or clinics. There is no centralized facility which provides easy n convenient access to the medical facility which gives us the required information .We do not have any facility that we could find our nearest located hospitals or clinics so that we dont have to waste much time on them. There was no one to instruct us to take which step, opt for which nearest health care center and who can tell us about nearest life saver. Therefore there is need for a guide with complete information regarding health services. Scope D is a Web Site which provides with a platform which gives us information regarding health .This Web Site provides advanced search of doctors with their Hospitals, Specialization and area . So u can search your desired doctor at the nearest Healthcare Centre. This Web Site also finds the nearest blood donor in case of emergency on basis of its database. The main objective is to design a website that can provide information regarding health services on your desktop. The purpose is to provide quick search to health care center i.e. hospitals, doctors. To make a website that must offers a free login for its users so that their data is secured. To provide a status of blood bank at every hospitals in case of an emergency. To provide online appointments.

1.4 FEATURES
D is designed to cope up with the drawbacks of Existing system. D is a Web Site which provides with a platform which gives us fast and easy access to information regarding health services. This Web Site provides advanced search of doctors with their visiting Hospitals, Specialization and area. So u can search your desired doctor at the nearest Healthcare Centre. D keeps a record of blood donors which can be useful in case of an emergency like their contact no. and address. D provides a quick search to hospitals , their address, their e-mail address and phone number Fast operation Reduced time Detailed information Provides a user friendly environment It provides with complete latest information of particular hospital given by the hospital admin. D provides a facility to make appointments with doctor at the time of their visit to a particular hospital. The local Healthcare events and camps like blood donation camps , free checkup camps are informed to the user through our NEWS section.

OBJECTIVE OF THE PROJECT : The objective is to create a web application, which surpasses the expectations of the person needing the information regarding the various IT companies. The following are the objective of the proposed system. USER FRIENDLY INTERFACE: Since main interaction of the system has to be with the user, the user interface should be attractive and meaningful. MINIMUM EFFORT: Ensure that very less effort will be required the site and generation of report. FLEXIBILITY: Provides maximum flexibility to the Administrator in maintaining and modifying the information about existing modules functionalities. SECURITY : Since the information entered is of vital Importance to the organization and to the owner of the website, it should be made to allow only the website developers to manipulate the data FAST : The system should be fast enough to give User of the system the feel of using the best online system.

REPORT ORGANIZATION The report consists of four chapters and appendix. The brief description of each chapter is as follows: CHAPTER 1----------------- INTRODUCTION

This chapter gives an introduction to the project. It explains the problem definition and solution behind this project with the need & scope of the project. CHAPTER 2 ----------------- ANALYSIS

Deals with the literature, tools, and technologies that are being explored and adopted throughout the project development. This chapter describe about various models that were developed during Project designing phase. Such as Use-case models, Use-case description, CHAPTER 3 ----------------- DESIGN

This chapter deals with the architecture of the project means it defines it purpose, design, representation, size and performance goals. This chapter deals with the design of the software components its overview, complete class Diagram, sequence diagram, entity relationship diagram, designing tables and normalization. CHAPTER 4 ----------------------- IMPLEMENTATION

This chapter deals with high level algorithm and data structures. Also details about implementation language, third party software and package diagrams. CHAPTER 5 ----------------------- TESTING

After implementation, this chapter tells how its tested by using various methods of testing and test cases. CHAPTER 6 ------------------------ DEPLOYMENT

This chapter tells about the hardware and software requirements. It also includes Deployment diagrams. APPENDIX

It includes screen shots and instructions for deployment and operation.

2. ANALYSIS
2.1 2.2 2.3 2.4 2.5 Project Plan Requirement Specification Use Cases Use Case Diagram Activity Diagram

ANALYSIS
2.1 PROJECT PLAN
Before designing a system, the requirement of the system has to be properly determined and user need have to be properly determined and user needs have to be taken into account, initial investigation is the first step in the development of the system. This is the way handle the investigation of need i.e. the user request to change, improve or enhance an existing system. During this phase that are to be considered: How the present system works? Volume of the work type of transaction etc Time taken to process the data through system By the following the above steps of initial investigation are carried out first the existing system was carried out. The reporting format are gathered, the next step in initial investigation is to find out and collect more information from users and respective users who actually carry the existing system.

2.2 REQUIREMENT SPECIFICATION

Requirement analysis is a software-engineering task that bridges the gap between system level requirements and software design. Requirement engineering activities result in the specification of the softwares operational characteristics (functions, data, and behavior), indicate softwares interface with other system elements, and establish constraints that the software must meet. Requirement analysis allows the software engineer (analyst) to refine the software allocation and build models of data, functional and behavioral domains that will be treated by software. Requirement analysis provides the software designer with a representation of information, function, and behavior that can be translated to data, architectural, interface and component level designs. You also find out if there is a real need in the market for the software product you are trying to develop. In this stage, marketing and sales people or people who have direct contact with the customers do most of the work. These people talk to these customers and try to understand what they need. A comprehensive understanding of the customers needs and writing down features of the proposed software product are the keys to success in this phase. This phase is actually a base for the whole development effort. If the base is not laid correctly, the product will not find a place in the market. If you develop a very good software product which is not required in the market, it does not matter how well you build it. The following information gathering tools were used: Study of the existing applications: We studied and gathered the knowledge about the various features and drawbacks of the existing system. Consulting with our project in-charge: With proper guidance of our project incharge we were able to plan and execute our project in the right direction. Looking to the need of project , we had a company visit to have a analysis of presently working system effectively. Referred websites for to view information about the existing production system so that implementation could be done more

SYSTEM FEASIBILITY: After the analysis and specifications of the requirements of the proposed system feasibility study is conducted. It is done to find out whether the system is beneficial to the organization or not. For each proposed solution it is checked whether it is practical to implement that solution, this is done through feasibility study. Various feasibility aspects are considered . Econom ic Organizatio Managemen nal t Feasibility study Operation al Leg al

Technic Behavioral al The feasibility study includes the investigation of the information needs of the end user and objectives, constraints, basic resource requirement and cost benefits. The main and prime objective of feasibility study is not to solve the problem but to acquire a sense of its scope. The feasibility study includes the investigation of Information Needs of the end user and objectives Constraints Basic resource requirements

 ECONOMIC FEASIBILITY The system is economically feasible because there are no requirements of any special Costly hardware or software to develop the system. This system uses minimum resources for development and usage so it is very economic and user friendly system. The organization for which it is meant can avail it at a very low cost. The objectives are fulfilled within minimum resources. Hence our project is economically feasible. TECHNICAL FEASIBILITY The project is technically feasible because it will not develop or use any technology which is under research. The project uses Java as front end and designing is done using a well recognized software of MICROSOFT that is .NET framework IDE. The back end of the project is SQL SERVER 2005 which is again a genuine product. In technical feasibility the following issues are taken into consideration: Whether the required technology is available or not? The work for the project can be done wih the current equipment and existing software technology that the organisation possessess. Whether the required resources are available? The system does not have any rigid hard-ware and software requirements and there is availability of the people who can perform the software engineering activities required for the development of the system. Hence, the system is technically feasible.

 BEHAVIOURAL FEASIBILITY Behavioral feasibility is concerned with as curtaining the views of the examiners and organizers about the use of the computer facility. The support or the lack of the support that the examiners are likely to give to the system is the critical aspect of the feasibility in all respects except the behavioral and fails miserably because of human problems. Our project is behavioral feasible because it is time saving and reliable.

For which problem do you lack good solutions?

There was need to create a integrated system which surpasses the expectations of the person needing the information regarding pvc pipes manufacturing company and through which Administrators can also update & access the information from any location all over the world. How would you like to solve it?

To solve this problem we have made a web based application through which customer that can do online Registration on the site and without extra effort can get the all the basic information about company.Admin module is also made web based and hence administrators can access from any where in the world.

TECHNOLOGY
Front-End Tool : ASP.NET ASP.NET is a new programming framework from Microsoft for developing next generation web Applications. It talks the net language and is a framework built on the Common Language Runtime and introduces a new paradigm to server-side Web development. ASP.NET is more than the next version of Active Server Pages (ASP); it is a unified Web development platform that provides the services necessary for developers to build enterprise-class Web applications. While ASP.NET is largely syntax compatible with ASP, it also provides a new programming model and infrastructure for more secure, scalable, and stable applications. You can feel free to augment your existing ASP applications by incrementally adding ASP.NET functionality to them. ASP.NET is a managed framework that facilitates building server-side applications based on HTTP, HTML, XML and SOAP ASP.NET supports building HTML-based applications with Web forms, server-side controls and data binding ASP.NET supports building non-visual request handlers and Web services

There are several advantages that ASP.NET offers, such as:

Performance: - The code written in .Net Framework is complied in Common Language Runtime. ASP.NET can take advantage of early binding, just-in-time compilation, automatic resource optimization, runtime profiling, automatic memory management, enhanced exception handling, and caching services, right out-of-the-box, this improves the performance before you start coding. ASP.NET comes with a data-caching module. This data-caching module allows you to specify what data on an ASP page to cache and on what conditions to empty the cache and re-query the data-store. Tool Support:- Now you can drag-and-drop web controls like you do VB controls, double-click and write the server code for the control. ASP .NET supports XCOPY deployment that requires no registration or stopping of the server, supports dynamic DLL updates and extensible configuration using XML files. Flexibility: - Because ASP.NET is based on the Common Language Runtime, the power and flexibility of that entire platform is made available to web application developers. The Common Language Runtime's Base Class libraries, Messaging, and Data Access solutions are all seamlessly accessible from the web.ASP.NET is also language-independent. Further, Common Language Runtime interoperability guarantees that your existing investment in COM-based development is preserved when migrating to ASP.NET. Simplicity: - ASP.NET makes it easy to perform common tasks, from simple form submission and client authentication to deployment and site configuration. For example, the ASP.NET Page Framework allows you to build user interfaces that cleanly separate application logic from presentation code, and handle events in a simple, VB-like forms processing model. Additionally, the Common Language Runtime simplifies development with managed code services like automatic reference counting and garbage collection.

Manageability: -The ASP.NET configuration system handles both ends, and provides a hierarchical configuration setup that enables extensible configuration data to be defined and used throughout an application, a Web site, and/or an entire domain. No server restart is required, even to deploy or replace running compiled code!

Scalability: -ASP.NET has been designed with scalability in mind, enables automatic process recovery through error and memory overload detection. Session state can now be maintained in a number of ways. Session data can be passed in a hidden field within the pages, or in one of two out-of-process State Stores. The two flavors they come in are the ASP.NET State Store, which maintains stateful data in memory, or the SQL State Store, for writing stateful data to your SQL Server database. Customizability and Extensibility: - ASP.NET delivers a well-factored architecture that allows developers to "plug-in" their code at the appropriate level. In fact, it is possible to extend or replace any sub-component of the ASP.NET runtime with your own custom-written component. Implementing custom authentication or state services has never been easier. SecurityASP.NET works in conjunction with the Microsoft .NET Framework and Internet Information Server (IIS) 5.0 to provide outstanding security capabilities.

Backend Tool : SQL SERVER

Database Concepts: A database is an integrated set of interrelated data stored in an online medium with control redundancy to solve several applications within an enterprise. Database management system is a software and/or hardware system that manages the database of an enterprise and provides facilities to the users to use the database with practical ease. The advantages of working with DBMS is that: In no database systems each application has its own private files, which lead to redundancy in stored data. DBMS provides centralized control on operational data hence redundancy that also results in saving storage space. Centralized control ensures that all applicable standards can be enforced. Security instructions are applied as centralized storage of data which makes the data very sensitive, hence it can be ensured that the only means of access to the database is through proper channel. Integrity can be maintained. Inconsistency between two entries representing the same fact is an example of lack of integrity. Centralized control of database helps in avoiding these situations by permitting the database administrator to define validation procedure to be out whenever any update operation is attempted. Relational Database Management System: A relational database system is defined as a collection of related tables Rows are of same type. Each table entry represents one data at one time. Each row is distinct. Rows need to be ordered. A relation could be base relation or derived relation. Base relation Have independent existence like distinct files on a storage media. In other words, it corresponds to conceptual record type and may have indexes. Derived relation Are virtual relation derived from database relation and are called views. Microsoft SQL Server 2005 extends the performance, reliability, quality, and easeof-use of Microsoft SQL Server version 7.0. Microsoft SQL Server 2005 includes

several new features that make it an excellent database platform for large-scale online transactional processing (OLTP), data warehousing, and e-commerce applications. The database component of Microsoft SQL Server 2005 is a Structured Query Language (SQL)based, scalable, relational database with integrated Extensible Markup Language (XML) support for Internet applications. SQL statements return their results in a relational, or tabular, result set, the SQL Server 2000 database component supports a FOR XML clause that returns results as an XML document. SQL Server 2005 also supports XPath queries from Internet and intranet applications. XML documents can be added to SQL Server databases, and the OPENXML clause can be used to expose data from an XML document as a relational result set.

2.3 USE CASE

A use case is a class, not an instance. An instantiation of a use case is called a scenario. Interaction between use case & actors are detailed here. A use case is applied to capture the intended behavior of the system being developed, without having to specify how that behavior be implemented A use case specifies the behavior of the system or part of a system and is description of a set of sequence of action including variants that a system performs to yield an observable result of value to an actor. Thus use cases server to help validate the architecture and to verify the system as it evolves during the development. We have identified the following use cases in our project. A use case describes a sequence of actions that provide something of measurable value to an actor and is drawn as a horizontal ellipse. 1. A use case is drawn as a horizontal ellipse on a UML use case diagram. 2. Use Case Names Begin With a Strong Verb 3. Name Use Cases Using Domain Terminology 4. Place Your Primary Use Cases In The Top-Left Corner Of The Diagram 5. Imply Timing Considerations By Stacking Use Cases

Horizontal Ellipse

Actors An actor is a person, organization, or external system that plays a role in one or more interactions with your system (actors are typically drawn as stick figures on UML)

Actors Place Your Primary Actor (S) In the Top-Left Corner of the Diagram.

1. 2. 3. 4. 5. 6. 7.

Draw Actors To The Outside Of A Use Case Diagram Name Actors With Singular, Business-Relevant Nouns Associate Each Actor With One Or More Use Cases Actors Model Roles, Not Positions Use <<system>> to Indicate System Actors Actors Dont Interact With One Another Introduce an Actor Called Time to Initiate Scheduled Events

Relationships There are several types of relationships that may appear on a use case diagram:

An association between an actor and a use case An association between two use cases A generalization between two actors A generalization between two use cases

Associations are depicted as lines connecting two modeling elements with an optional open-headed arrowhead on one end of the line indicating the direction of the initial invocation of the relationship. Generalizations are depicted as a close-headed arrow with the arrow pointing towards the more general modeling element. System Boundary Boxes The rectangle around the use cases is called the system boundary box and as the name suggests it indicates the scope of your system the use cases inside the rectangle represent the functionality that you intend to implement.

Indicate Release Scope with a System Boundary Box. Avoid Meaningless System Boundary

USE CASE MODEL

Use Case Model is a model that describes a systems functional requirements in terms of use cases. Consists of all the actors of the system and all the various use cases by which the actor interact with the system, thereby describing the total functional behaviour of the system. There are two main entities in the use case approach: actor and use cases. Actors An actor is a person who will use the system we are designing. Use Cases A use case is a specific task, usually initiated by an actor. It describes a single goal the actor wants to attain. USE CASE TEMPLATES There is no standard template for documenting detailed use cases. There are a number of competing schemes, and individuals are encouraged to use templates that work for them or the project they are on. . USE CASE NAME A use case name provides a unique identifier for the use case. ACTORS An actor is someone or something outside the system that either acts on the system a primary actor or is acted on by the system a secondary actor. PRECONDITIONS A preconditions section defines all the conditions that must be true (i.e., describes the state of the system) for the trigger (see below) to meaningfully cause the initiation of the use case. TRIGGERS A 'triggers' section describes the event that causes the use case to be initiated. This event can be external, temporal or internal. BASIC COURSE OF EVENTS At a minimum, each use case should convey a primary scenario, or typical course of events, also called "basic flow", "happy flow" and "happy path". ALTERNATIVE PATHS Use cases may contain secondary paths or alternative scenarios, which are variations on the main theme.

POSTCONDITIONS The post-conditions section describes what the change in state of the system will be after the use case completes. Post-conditions are guaranteed to be true when the use case ends. Use Case diagrams are one of the five diagrams in the UML for modeling the dynamic aspects of systems (activity diagrams, sequence diagrams, state chart diagrams and collaboration diagrams are the four other kinds of diagrams in the UML for modeling the dynamic aspects of systems).

2.4 USE CASE DIAGRAM

Use case:1

Use case: 2

2.5 ACTIVITY DIAGRAM

The workflows of business use cases are described in detail using Activity Diagram. In the Unified Modeling Language, an activity diagram represents the business and operational step-by-step workflows of components in a system. An Activity Diagram shows the overall flow of control. In SysML the Activity diagram has been extended to indicate flows among steps that convey physical element (e.g., gasoline) or energy (e.g., torque, pressure). Additional changes allow the diagram to better support continuous behaviors and continuous data flows. Activity diagrams show the procedural flow of control between two or more class objects while processing an activity. Activity diagrams can be used to model higher-level business process at the business unit level, or to model low-level internal class actions. In my experience, activity diagrams are best used to model higher-level processes, such as how the company is currently doing business, or how it would like to do business. This is because activity diagrams are "less technical" in appearance, compared to sequence diagrams, and business-minded people tend to understand them more quickly. An activity diagram's notation set is similar to that used in a state chart diagram. Like a state chart diagram, the activity diagram starts with a solid circle connected to the initial activity. The activity is modeled by drawing a rectangle with rounded edges, enclosing the activity's name. Activities can be connected to other activities through transition lines, or to decision points that connect to different activities guarded by conditions of the decision point. Activities that terminate the modeled process are connected to a termination point (just as in a state chart diagram). Optionally, the activities can be grouped into swim lanes, which are used to indicate the object that actually performs the activity.

3. DESIGN
3.1 3.2 3.3 3.4 3.5 Architecture Database Design User Interface Design Logical Design Sequence Diagram

DESIGN

3.1 ARCHITECTURE DESIGN:

In a three-tier architecture (also known as a multi-tier architecture), there are three or more interacting tiers, each with its own specific responsibilities (see Figure 3):

Figure 3. Three-Tier Architecture

Tier 1: the client contains the presentation logic, including simple control and user input validation. This application is also known as a thin client. Tier 2: the middle tier is also known as the application server, which provides the business processes logic and the data access.

Tier 3: the data server provides the business data.

These are some of the advantages of a three-tier architecture:

It is easier to modify or replace any tier without affecting the other tiers. Separating the application and database functionality means better load balancing. Adequate security policies can be enforced within the server tiers without hindering the clients

Three Tier Architecture of D

3.2 DATABASE DESIGN

Purpose Of Database Before database management system came along, organizations usually stored information in file-processing systems. Keeping organizations information in a fileprocessing system has a number of major disadvantages: Data redundancy and inconsistency Difficulty in accessing data Data isolation Integrity problems Atomicity problems Concurrent access anomalies Security problems

Characteristics of the Database approach A database management system consists of a collection of interrelated data and a set of programs to access those data. The collection of data usually referred to as the database, contains information about one particular enterprise. The primary goal of a database management system is to provide an environment that is both convenient and efficient to use in retrieving and storing database information. Database systems are designed to manage large bodies of information. This management includes both the definition of structures for the storage of information and the provisions of mechanisms for the manipulation of information. In addition, the database system must provide for the safety of the information stored, despite system crashes or attempts at unauthorized access. A number of characteristics distinguish the database approach from the traditional approach of programming with files. In traditional file processing, each user defines

and implements the files needed for a specific application as part of programming the application. In the database approach, a single repository of data is maintained that is defined once and then is accessed by various users. The main characteristics of the database approach versus the file-processing approach are the following. Self-describing Nature Insulation between Programs and Data, and Data Abstraction Support of Multiple Views of Data. Sharing Of Data and Multi-user Transaction Processing.

Self-Describing Nature of a Database System A fundamental characteristic of the database approach is that the database system contains not only the database itself but also a complete definition or description of the database structure and constraints. This definition is stored in the system catalog, which contains information such as the structure of each file, the type and storage format for each data item, and various constraints on the data. The information stored in the catalog is called meta-data, and it describes the structure of the primary database. Insulation between Programs and Data, and Data Abstraction In traditional file processing, the structure of data files is embedded in the access programs, so any changes to the structure of a file may require changing all programs that access this file. By contrast, DBMS access programs do not require such changes in most cases. The structure of data files us stored in the DBMS catalog separately from the access programs. This property is called program-data independence. In object-oriented and object-relational database, users can define operations as part of the database definitions. An operation (or function) is specified in two parts. The interface (or signature) of an operation includes the operation name and the data types of its arguments (or parameters). The implementation (or method) of the operation is specified separately and can be changed without affecting the interface. User application programs can operate on the data by invoking these operations through their names and arguments, regardless of how the operations are implemented. This may be termed program-operation independence. The characteristic that allows program-data independence and program-orientation independence is called data abstraction. A DBMS provides users with a conceptual representation of data that does not include many of the details of how the data is stored or how the operations are implemented. Support of Multiple Views of the Data

A database typically has many users, each of whom may require a different perspective or view of the database. A view may be a subset of the database or it may contain virtual data that is derived from the database files but is not explicitly stored. Some users may not need to be aware of whether the data they refer to is stored or derived. A multi-user DBMS whose users have a variety of applications must provide facilities for defining multiple views. Sharing of Data and Multi-user Transaction Processing A multi-user DBMS, as its name applies, must allow multiple users to access the database at the same time. This is essential if data for multiple applications is to be integrated and maintained in a single database. The DBMS must include concurrency control software to ensure that several users trying to update the same data do so in a controlled manner so that the result of the updates is correct. Such types of problems generally occur in on-line transaction processing (OLTP) applications. A fundamental role of multi-user DBMS software is to ensure that concurrent transactions operate correctly.

ADVANTAGES OF USING DBMS : Query Ability

Querying is the process of requesting attribute information from various perspectives and combinations of factors. Example: "How many 2-door cars in Texas are green?" A database query language and report writer to allow users to interactively interrogate the database, analyze its data and update it according to the users privileges on data. It also controls the security of the database. Data security prevents unauthorized users from viewing or updating the database. Using passwords, users are allowed access to the entire database or subsets of it called sub schemas. If the DBMS provides a way to interactively enter and update the database, as well as interrogate it, this capability allows for managing personal databases. However, it may not leave an audit trail of actions or provide the kinds of controls necessary in a multi-user organization. These controls are only available when a set of application programs are customized for each data entry and updating function. Backup And Replication Copies of attributes need to be made regularly in case primary disks or other equipment fails. A periodic copy of attributes may also be created for a distant organization that cannot readily access the original. DBMS usually provide utilities to facilitate the process of extracting and disseminating attribute sets. When data is replicated between database servers, so that the information remains consistent throughout the database system and users cannot tell or even know which server in the DBMS they are using, the system is said to exhibit replication transparency.

Rule Enforcement

Often one wants to apply rules to attributes so that the attributes are clean and reliable. For example, we may have a rule that says each car can have only one engine associated with it (identified by Engine Number). If somebody tries to associate a second engine with a given car, we want the DBMS to deny such a request and display an error message. However, with changes in the model specification such as, in this example, hybrid gas-electric cars, rules may need to change. Ideally such rules should be able to be added and removed as needed without significant data layout redesign. Security Often it is desirable to limit who can see or change which attributes or groups of attributes. This may be managed directly by individual, or by the assignment of individuals and privileges to groups, or (in the most elaborate models) through the assignment of individuals and groups to roles which are then granted entitlements. Computation There are common computations requested on attributes such as counting, summing, averaging, sorting, grouping, cross-referencing, etc. Rather than have each computer application implement these from scratch, they can rely on the DBMS to supply such calculations. Change and access logging Often one wants to know who accessed what attributes, what was changed, and when it was changed. Logging services allow this by keeping a record of access occurrences and changes.

Automated optimization

If there are frequently occurring usage patterns or requests, some DBMS can adjust themselves to improve the speed of those interactions. In some cases the DBMS will merely provide tools to monitor performance, allowing a human expert to make the necessary adjustments after reviewing the statistics collected. DISADVANTAGES OF USING DBMS In spite of the advantages of using a DBMS, there are a few situations in which such a system may involve unnecessary overhead costs, as that would not be incurred in traditional file processing. The overhead costs of using a DBMS are due to the following: High initial investment in hardware, software and training. Generally that a DBMS provides for defining and processing data. Overhead for providing security, concurrency control, recovery and integrity functions. Additional problems may arise if the database designers and DBA do not properly design the database or if the database system applications are not implemented properly. Hence, it may be more desirable to use regular files under the following circumstances: The database and applications are simple, well defined and not expected to change. There are stringent real-time requirements for some programs that be met because of DBMS overhead. Multiple-user access to data is not required. may not

The following are the snap shots of the database being used in this project:

3.3 USER INTERFACE DESIGN

The goal of user interface design is to make the user's interaction as simple and efficient as possible, in terms of accomplishing user goalswhat is often called user-centered design. Good user interface design facilitates finishing the task at hand without drawing unnecessary attention to itself. Graphic design may be utilized to apply a theme or style to the interface without compromising its usability. The design process of an interface must balance the meaning of its visual elements that conform the mental model of operation, and the functionality from a technical engineering perspective, in order to create a system that is both usable and easy to adapt to the changing user needs. There are several phases and processes in the user interface design some of which are more demanded upon than others depending on the project. (note for the remainder of this section the word system is used to denote any project whether it is a web site, application, or device) Functionality requirements gathering assembling a list of the functionality required of the system to accomplish the goals of the project and the potential needs of the users. User analysis analysis of the potential users of the system either through discussion with people who work with the users and/or the potential users themselves. Typical questions involve: o What would the user want the system to do? o How would the system fit in with the user's normal workflow or daily activities? o How technically savvy is the user and what similar systems does the user already use? o What interface look & feel styles appeal to the user? Information architecture development of the process and/or information flow of the system (i.e. for phone tree systems, this would be an option tree flowchart and for web sites this would be a site flow that shows the hierarchy of the pages). Prototyping development of wire frames, either in the form of paper prototypes or simple interactive screens. These prototypes are stripped of all look & feel elements and most content in order to concentrate on the interface. Usability testing testing of the prototypes on an actual useroften using a technique called talk aloud protocol where you ask the user to talk about their thoughts during the experience. Graphic Interface design actual look & feel design of the final graphical user interface (GUI). It may be based on the findings developed during the usability testing if usability is unpredictable, or based on communication objectives and styles that would appeal to the user. In rare cases, the graphics may drive the prototyping, depending on the importance of visual form versus function. If the interface requires multiple skins, there may be multiple interface designs for one control panel, functional feature or widget. This phase is often a collaborative effort between a graphic designer and a user interface designer, or handled by one who is proficient in both disciplines.

User interface design requires a good understanding of user needs. User interface is the one of the most important feature of a project . It is the User interface through which a user interacts with the project . User interface is the first thing which a user look first time , so it gives the first impression about the project . Good User interface is very essential for the commercial projects to compete in the market , because good features of project are useless if they are not shown properly . User interfaces should be appealing to the users but also they should be meaningful, they must provide easy and fast access to the services of the software even to the user using software first time. Features of UI: 1). It should be good looking. but keeping the aim of project in mind , i.e. It should be decent looking for commercial , medical , education use , and can be glamorous for entertainment purpose. 2). It should provide all the main features at the same place . 3). It should be easy to use and understandable. 4). It should also provide little help for the new user to use the system, it can be done by things like popup messages.

We have tried to design such UI which have all the above features. Our UI is very decent looking which suites the aim of our project , which is in Medical domain . WE have tried to design a UI that is easy to use . Popup help is given at anywhere possible . All the essential features can be assessed from the same place with ease. We have also tried to minimize the user side errors up to some extent .

3.4 LOGICAL DESIGN: Class Diagram

3.4 SEQUENCE DIAGRAMS

A sequence diagram is an interaction diagram that emphasizes the time ordering of the messages. Graphically, a sequence diagram is a table that shows objects arranged along the X-axis and messages, ordered in increasing time, along the Y-axis. A sequence diagram shows, as parallel vertical lines ("lifelines"), different processes or objects that live simultaneously, and, as horizontal arrows, the messages exchanged between them, in the order in which they occur. This allows the specification of simple runtime scenarios in a graphical manner. In order to display interaction, messages are used. These are horizontal arrows with the message name written above them. Solid arrows with full heads are synchronous calls, solid arrows with stick heads are asynchronous calls and dashed arrows with stick heads are return messages. Activation boxes, or method-call boxes, are opaque rectangles drawn on top of lifelines to represent that processes are being performed in response to the message. Objects calling methods on themselves use messages and add new activation boxes on top of any others to indicate a further level of processing.

4 .IMPLEMENTATION
4.1 High Level Algorithm 4.2 Data Structures Used 4.3 Third Party Software 4.4 Package Diagram

4.1 HIGH LEVEL ALGORITHM

First the website is configured on the IIS server. The website is opened by client using the address http://localhost:1432/ddd/index.aspx When this ip opens the user is provided with the options to navigate through the features of the website. User can navigate through the all the pages if he is not a registered user. for accessing the other services like will of donating blood he must register him self. There is no need of registration for accessing the searching services . If the login user is customer then he is send to his profile page where he can update his profile and if he is a admin then he will be send to the admin page where he can update, insert and delete all the records. The search will come on the entries user entered for the search.

4.2 PACKAGE DIAGRAM

5. TESTING
5.1 Unit Testing 5.2 Integration Testing 5.3 System Testing 5.4 Test Plan 5.5 Test Cases

5.1 UNIT TESTING

Unit testing is a software development process in which the smallest testable parts of an application, called units, are individually and independently scrutinized for proper operation. Unit testing is often automated but it can also be done manually. Unit testing involves only those characteristics that are vital to the performance of the unit under test. This encourages developers to modify the source code without immediate concerns about how such changes might affect the functioning of other units or the program as a whole. Once all of the units in a program have been found to be working in the most efficient and error-free manner possible, larger components of the program can be evaluated by means of integration testing. Unit testing can be time-consuming and tedious. It demands patience and thoroughness on the part of the development team. Rigorous documentation must be maintained. Unit testing must be done with an awareness that it may not be possible to test a unit for every input scenario that will occur when the program is run in a real-world environment. The primary goal of unit testing is to take the smallest piece of testable software in the application, isolate it from the remainder of the code, and determine whether it behaves exactly as you expect. Each unit is tested separately before integrating them into modules to test the interfaces between modules. Unit testing has proven its value in that a large percentage of defects are identified during its use. The most common approach to unit testing requires drivers and stubs to be written. The driver simulates a calling unit and the stub simulates a called unit. The investment of developer time in this activity sometimes results in demoting unit testing to a lower level of priority and that is almost always a mistake. Even though the drivers and stubs cost time and money, unit testing provides some undeniable advantages. It allows for automation of the testing process, reduces difficulties of discovering errors contained in more complex pieces of the application, and test coverage is often enhanced because attention is given to each unit. For example, if you have two units and decide it would be more cost effective to glue them together and initially test them as an integrated unit, an error could occur in a variety of places: * Is the error due to a defect in unit 1? * Is the error due to a defect in unit 2? * Is the error due to defects in both units? * Is the error due to a defect in the interface between the units? * Is the error due to a defect in the test? Finding the error (or errors) in the integrated module is much more complicated than first isolating the units, testing each, then integrating them and testing the whole.

Drivers and stubs can be reused so the constant changes that occur during the development cycle can be retested frequently without writing large amounts of additional test code. In effect, this reduces the cost of writing the drivers and stubs on a per-use basis and the cost of retesting is better controlled.

5.2 INTEGRATION TESTING

Integration testing is a logical extension of unit testing. In its simplest form, two units that have already been tested are combined into a component and the interface between them is tested. A component, in this sense, refers to an integrated aggregate of more than one unit. In a realistic scenario, many units are combined into components, which are in turn aggregated into even larger parts of the program. The idea is to test combinations of pieces and eventually expand the process to test your modules with those of other groups. Eventually all the modules making up a process are tested together. Beyond that, if the program is composed of more than one process, they should be tested in pairs rather than all at once. Integration testing identifies problems that occur when units are combined. By using a test plan that requires you to test each unit and ensure the viability of each before combining units, you know that any errors discovered when combining units are likely related to the interface between units. This method reduces the number of possibilities to a far simpler level of analysis. You can do integration testing in a variety of ways but the following are three common strategies: * The top-down approach to integration testing requires the highest-level modules be test and integrated first. This allows high-level logic and data flow to be tested early in the process and it tends to minimize the need for drivers. However, the need for stubs complicates test management and low-level utilities are tested relatively late in the development cycle. Another disadvantage of top-down integration testing is its poor support for early release of limited functionality. * The bottom-up approach requires the lowest-level units be tested and integrated first. These units are frequently referred to as utility modules. By using this approach, utility modules are tested early in the development process and the need for stubs is minimized. The downside, however, is that the need for drivers complicates test management and high-level logic and data flow are tested late. Like the top-down approach, the bottom-up approach also provides poor support for early release of limited functionality. * The third approach, sometimes referred to as the umbrella approach, requires testing along functional data and control-flow paths. First, the inputs for functions are integrated in the bottom-up pattern discussed above. The outputs for each function are then integrated in the top-down manner. The primary advantage of this approach is the degree of support for early release of limited functionality. It also helps minimize the need for stubs and drivers. The potential weaknesses of this approach are significant, however, in that it can be less systematic than the other two approaches, leading to the need for more regression testing.

5.3 SYSTEM TESTING

System testing of software or hardware is testing conducted on a complete, integrated system to evaluate the system's compliance with its specified requirements. System testing falls within the scope of black box testing, and as such, should require no knowledge of the inner design of the code or logic. 5.3.1 BLACKBOX TESTING It is also known as functional testing. A software testing technique whereby the internal workings of the item being tested are not known by the tester. For example, in a black box test on a software design the tester only knows the inputs and what the expected outcomes should be and not how the program arrives at those outputs. The tester does not ever examine the programming code and does not need any further knowledge of the program other than its specifications.

The advantages of this type of testing include: 1. The test is unbiased because the designer and the tester are independent of each other. 2. The tester does not need knowledge of any specific programming languages. 3. The test is done from the point of view of the user, not the designer. 4. Test cases can be designed as soon as the specifications are complete. The disadvantages of this type of testing include: 1. The test can be redundant if the software designer has already run a test case. 2. The test cases are difficult to design. 3. Testing every possible input stream is unrealistic because it would take a inordinate amount of time; therefore, many program paths will go untested.

5.3.2 WHITE BOX TESTING

The purpose of any security testing method is to ensure the robustness of a system in the face of malicious attacks or regular software failures. White box testing is performed based on the knowledge of how the system is implemented. White box testing includes analyzing data flow, control flow, information flow, coding practices, and exception and error handling within the system, to test the intended and unintended software behavior. White box testing can be performed to validate whether code implementation follows intended design, to validate implemented security functionality, and to uncover exploitable vulnerabilities. White box testing requires access to the source code. Though white box testing can be performed any time in the life cycle after the code is developed, it is a good practice to perform white box testing during the unit-testing phase. White box testing requires knowing what makes software secure or insecure, how to think like an attacker, and how to use different testing tools and techniques. The first step in white box testing is to comprehend and analyze source code, so knowing what makes software secure is a fundamental requirement. Second, to create tests that exploit software, a tester must think like an attacker. Third, to perform testing effectively, testers need to know the different tools and techniques available for white box testing. The three requirements do not work in isolation, but together A white box or clear box is a device, program or system whose internal workings are well understood. White box testing , also called white box analysis , clear box testing or clear box analysis , is a strategy for software debugging in which the tester has excellent knowledge of how the program components interact and also is familiar with the details of its internal operation. White box testing is highly effective in detecting and resolving problems because bugs can often be found before they cause trouble. It is possible to detect subtle flaws in source code that might be missed when less intrusive methods are used. However, white box testing is difficult to scale between small and large systems. The method can also cause personnel conflicts as software authors and testers question developers.

Advantages of White box testing are: There are many benefits to white box testing, including the following: 1. Analyzing source code and developing tests based on the implementation details enables testers to find programming errors quickly. For example, a white box tester looking at the implementation can quickly uncover a way, say, through an error handling mechanism, to expose secret data processed by a component. Finding such vulnerabilities through black box testing require comparatively more effort than found through white box testing. This increases the productivity of testing effort. 2. Executing some (hard to set up) black box tests as white box tests reduces complexity in test setup and execution. For example, to drive a specific input into a component, buried inside the software, may require elaborate setup for black box testing but may be done more directly through white box testing by isolating the component and testing it on its own. This reduces the overall cost (in terms of time and effort) required to perform such tests. 3. Validating design decisions and assumptions quickly through white box testing increases effectiveness. The design specification may outline a secure design, but the implementation may not exactly capture the design intent. For example, a design might outline the use of protected channels for data transfer between two components, but the implementation may be using an unprotected method for temporary storage before the data transfer. This increases the productivity of testing effort. 4. Finding unintended features can be quicker during white box testing. Security testing is not just about finding vulnerabilities in the intended functionality of the software but also about

Disadvantages of white box testing are:

1. As knowledge of code and internal structure is a prerequisite, a skilled tester is needed to carry out this type of testing, which increases the cost. 2.And it is nearly impossible to look into every bit of code to find out hidden errors, which may create problems, resulting in failure of the application. The general outline of the white box testing process is as follows: 1. Perform risk analysis to guide the whole testing process.

2. Develop a test strategy that defines what testing activities are needed to accomplish testing goals.

3. Develop a detailed test plan that organizes the subsequent testing process.

4. Prepare the test environment for test execution.

5. Execute test cases and communicate results.

5.4

TEST PLANS

A test plan documents the strategy that will be used to verify and ensure that a product or system meets its design specifications and other requirements. A test plan is usually prepared by or with significant input from Test Engineers.

Depending on the product and the responsibility of the organization to which the test plan applies, a test plan may include one or more of the following:

1. Design Verification or Compliance test - to be performed during the development or approval stages of the product, typically on a small sample of units. 2. Manufacturing or Production test - to be performed during preparation or assembly of the product in an ongoing manner for purposes of performance verification and quality control. 3. Acceptance or Commissioning test - to be performed at the time of delivery or installation of the product. 4. Service and Repair test - to be performed as required over the service life of the product...... 5. Regression test - to be performed on an existing operational product, to verify that existing functionality didn't get broken when other aspects of the environment are changed (e.g., upgrading the platform on which an existing application runs).

A complex system may have a high level test plan to address the overall requirements and supporting test plans to address the design details of subsystems and components.

Test plan document formats can be as varied as the products and organizations to which they apply, but there are three major elements of a test strategy that should be described in the test plan: Test Coverage, Test Methods, and Test Responsibilities.

Test coverage in the test plan states what requirements will be verified during what stages of the product life. Test Coverage is derived from design specifications and other requirements, such as safety standards or regulatory codes, where each requirement or specification of the design ideally will have one or more corresponding means of verification. Test coverage for different product life stages may overlap, but will not necessarily be exactly the same for all stages. For example, some requirements may be verified during Design Verification test, but not repeated during Acceptance test. Test coverage also feeds back into the design process, since the product may have to be designed to allow test .

5.4 TEST PLAN

Following are the steps that we used in order to develop our test plan: 1. Test Group: We created no test groups instead we assign the job of testing to one of the team members. He was made responsible to create test data and test cases in order to execute his corresponding test activity. 2. Preliminary test of each component : He tested each component form wise. Each form after it was built was executed with test data to check for its data validation and also to check proper establishment of connection. For example: Contacts form was tested to check to see the validation that was imposed during coding are followed or not. The validation that we used was that to check whether the name and address field is full or not. If user doesnt enter anything in this field then an error or warning should be generated indicating that this field should not remain empty. Similarly if phone field is empty it should generate the same message. Same is the case when we checked for the size of the fields and same is for other forms also. 3. Final Test: In this he checked the whole system together taking all the values and forms together. 4. Documentation: Last step that comes in our test plan is the documentation of all the cases that our encountered while entering data in the field .This is important for conducting test sequentially and helps in scheduling. In order to make it more clearly, following is the example of the documentation of one of our form.

5.5 TEST CASES:

1.User Login Test Case Number 1. Action Expected Result Success Comments

Username, password The user is prompted Yes or user type fields are to enter username or left blank and Login password. button is clicked. Click the submit button with invalid username or password . If user is not already registered If user create account with the existing user name. If User name and password is matching with the admin id . Enter valid username and password . Either the username or Yes password is incorrect. Invalid entry please re-enter. create account page is loaded. A message is displayed of user name already exist . User is made to navigate to admin mode. Navigation page displayed and user can start accessing the services. Yes Yes

2.

3. 4.

5.

Yes

6.

Yes

2. Register:

Test case Number 1.

Action

Expected Result

Success

Comments

If user gives null The user is prompted Yes values of username, to enter mandatory email id, password fields. (any field in the form) & clicks on submit button.

If user selects a The user is prompted Yes user_id which is to choose another already assigned to username. another user. If user successfully The user is provided Yes registers. with all the services

3.

3) Menu :

Test case Action Number 1. If user clicks About us

Expected Result

Success

Comments

on Then About us page Yes is opened and he can view the company profile on Then the user is Yes provided with create account window after filling that this page is opened. on Then product page is Yes opened from here he can view the specification .

2.

If user clicks Registration .

3.

If user clicks Product .

4.

If user Logout .

clicks

on Then user session is Yes invalidated and he is redirected to Home page. on Then user is Yes redirected to home page

5.

If user Home .

clicks

DEPLOYMENT

6.1 HARDWARE AND SOFTWARE REQUIREMENTS

SERVER SIDE HARDWARE REQUIREMENTS: Hard disk - 20 GB Minimum Processor - Pentium 4 or higher R.A.M - 512 MB or Higher Any Network Connection

CLIENT SIDE HARDWARE REQUIREMENTS: Hard disk - 10 GB Minimum Processor - 850 MHz or Higher R.A.M - 256 MB or Higher SERVER SIDE SOFTWARE REQUIREMENTS: ASP.NET as front-end tool IIS server SQL 2005 Windows server edition CLIENT SIDE SOFTWARE REQUIREMENT: Operating system with internet facility . A web browser.

6.2 DEPLOYMENT DIAGRAM

Deployment Diagram depicts a static view of the run-time configuration of processing nodes and the components that run on those nodes. In other words, deployment diagrams show the hardware for your system, the software that is installed on that hardware, and the middleware used to connect the disparate machines to one another. You want to create a deployment diagram for applications that are deployed to several machines, for example a point-of-sales application running on a thin-client network computer which interacts with several internal servers behind your corporate firewall or a customer service system deployed using web services architecture such as Microsofts .NET. Deployment diagrams can also be created to explore the architecture of embedded systems, showing how the hardware and software components work together. In short, you may want to consider creating a deployment diagram for all but the most trivial of systems. Identify the scope of the model. Does the diagram address how to deploy a version of a single application or does it depict the deployment of all systems within your organization? Consider fundamental technical issues. What existing systems will yours need to interact/integrate with? How robust does your system need to be (will there be redundant hardware to failover to)? What/who will need to connect to and/or interact with your system and how will they do it (via the Internet, exchanging data files, and so forth)? What middleware, including the operating system and communications approaches/protocols, will your system use? What hardware and/or software will your users directly interact with (PCs, network computers, browsers, and so forth)? How do you intend to monitor the system once it has been deployed? How secure does the system need to be (do you need a firewall, do you need to physically secure hardware, and so forth)? Identify the distribution architecture. Do you intend to take a fat-client approach where the business logic is contained in a desktop application or a thin-client approach where business logic is deployed to an application server? Will your application have two tiers, three tiers, or more? Your distribution architecture strategy will often be predetermined for your application, particularly if you are deploying your system to an existing technical environment. Distribute software to nodes. Both versions of the deployment diagrams indicate the software that is deployed on each node, critical information for anyone involved in development, installation, or operation of the system.

DEPLOYMENT DIAGRAM

APPENDIX

HOME PAGE

BLOOD SEARCH PAGE

USER REGISTRATION PAGE

NEW USER PAGE

BLOOD BANK SHEET

HOSPITAL ENTRY PAGE

HOSPITALS RECORD UPDATION FORM

DOCTORS UPDATE FORM

DOCTOR ENTRY FORM

HOSPITALS RECORD DELETION FORM

ADMINISTRATOR HOME PAGE

HELP PAGE

DOCTORS APPOINMENT PAGE