PDS Documentation

93
14 ABSTRACT The Government of India launched the Targeted Public Distribution System (TPDS) with focus on the poor. Under the TPDS, States are required to formulate and implement fool proof arrangements for identification of the poor for delivery of food grains and for its distribution in a transparent and accountable manner at the FPS level. To keep track of the PDS the following has been proposed. The public should register with the government through the PDS- Seva website. A ration card is issued to each family identified by a unique number generated by the PDS application. PDS-Seva registers PDS stores dynamically. It manages the store for its creation across districts and locations. Each location will have a dynamically created database that maintains product information. The customer approaches the store to collect the products. The stores owner is supposed to feed the product supplied and the bill generated submitted on-line to the PDS-seva application. Hence the transactions of the public are readily available to the Government. The level of stocks, the stores operating and most importantly it is able to track down for any illegal sales of the product to third person.

Transcript of PDS Documentation

Page 1: PDS Documentation

14

ABSTRACT

The Government of India launched the Targeted Public Distribution System (TPDS) with

focus on the poor. Under the TPDS, States are required to formulate and implement fool

proof arrangements for identification of the poor for delivery of food grains and for its

distribution in a transparent and accountable manner at the FPS level.

To keep track of the PDS the following has been proposed. The public should register

with the government through the PDS- Seva website. A ration card is issued to each

family identified by a unique number generated by the PDS application.

PDS-Seva registers PDS stores dynamically. It manages the store for its creation across

districts and locations. Each location will have a dynamically created database that

maintains product information. The customer approaches the store to collect the products.

The stores owner is supposed to feed the product supplied and the bill generated

submitted on-line to the PDS-seva application. Hence the transactions of the public are

readily available to the Government. The level of stocks, the stores operating and most

importantly it is able to track down for any illegal sales of the product to third person.

The public on the other hand can log in to check for the availability of the commodities

and their previous purchase details. This enables them to keep track of false transactions

recorded against their cards

Page 2: PDS Documentation

14

CONTENTS

PAGE NO.

1. INTRODUCTION

1.1 PURPOSE 1

1.2 PRESENT SYSTEM

1.3 PROBLEM IN EXISTING SYSTEM

1.4 SOLUTION TO THESE PROBLEMS

2. SYSTEM ANALYSIS 2

2.1. INTRODUCTION

2.2. ANALYSIS MODEL

2.3. STUDY OF THE SYSTEM

2.4. REQUIREMENT SPECIFICATIONS

3. FEASIBILITY REPORT 6

3.1. TECHNICAL FEASIBILITY

3.2. OPERATIONAL FEASIBILITY

3.3. ECONOMIC FEASIBILITY

4. DEFINITIONS OF MODULES 8

4.1 LOGIN AND SECURITY

4.2 ADMINISTRATOR MODULE

4.3 DEALER MODULE

4.4 CUSTOMER MODULLE

5. SELECTED SOFTWARE

5.1. .NET FRAMEWORK

Page 3: PDS Documentation

14

5.2. OVERVIEW OF .NET FRAMEWORK

5.3. WHAT IS .NET?

5.4. SQL SERVER

6. SYSTEM DESIGN 20

6.1. INTRODUCTION

6.2. DFD DESCRIPTION

6.3. DATA FLOW DIAGRAMS

7. UNIFIED MODELING LANGUAGE 28

7.1 USECASE DIAGRAM

7.2 SEQUENCE DIAGRAMS

7.3 ACTIVITY DIAGRAMS

7.4 COLLABORATION DIAGRAMS

8. OUTPUT SCREENS 54

9. IMPLEMENTATION AND MAINTENANCE 61

10. CONCLUSION 68

11. BIBLIOGRAPHY 70

Page 4: PDS Documentation

14

1.0 Introduction

1.1Purpose

Implement a system that handles the tasks that are performed by the FCI and the dealers

to track the distribution of the goods from the fair price shops.

1.2Intended Audience and Reading Suggestions

Intended for FCI stock organizations and the Dealer shops to maintain the proper

distribution of the assigned goods.

1.2 PRESENT SYSTEM

In the present scenario the FCI god owns maintain the information about the goods that

are available with them and the goods that are distribution to the Dealers or Fair Price

shops allocation under them. But lacks to maintain or to track the information about the

distribution of the goods to the customers by the dealer. The Officers though visit the

dealer shops once or twice in a year but unable make proper track of the distributed

goods.

1.3 Problem with existing system

1. The system performance depends upon manually efficiency.

2. Dealers maintain the information about the goods in registers which cannot be

traced by the FCI officers.

Page 5: PDS Documentation

14

3. The customers are also not aware of the mishandlings of the goods that are to be

distributed to them.

4. FCI officers maintain information about the goods being distributed to the dealers

but not the information about the goods distributed by the dealers to the

customers.

1.4 SOLUTION TO THESE PROBLEMS

• Provide integration between FCI and customers through the Dealer as middle

layer.

• Administrator Login to maintain the Dealer, Cards and Customer information.

• Viewing the information about the sales done the specified dealer for a particular

month.

• Issue of Goods to the Dealer in the required quantities.

• Tracing the complaints by the customers on the dealers.

2. SYSTEM ANALYSIS

2.1 INTRODUCTION

After analyzing the requirements of the task to be performed, the next step is to analyze

the problem and understand its context. The first activity in the phase is studying the

existing system and other is to understand the requirements and domain of the new

system. Both the activities are equally important, but the first activity serves as a basis of

giving the functional specifications and then successful design of the proposed system.

Understanding the properties and requirements of a new system is more difficult and

requires creative thinking and understanding of existing running system is also difficult,

improper understanding of present system can lead diversion from solution.

2.2. ANALYSIS MODEL

Page 6: PDS Documentation

14

The model that is basically being followed is the WATER FALL MODEL, which

states that the phases are organized in a linear order. First of all the feasibility study is

done. Once that part is over the requirement analysis and project planning begins. If

system exists one and modification and addition of new module is needed, analysis of

present system can be used as basic model.

The design starts after the requirement analysis is complete and the coding begins

after the design is complete. Once the programming is completed, the testing is done. In

this model the sequence of activities performed in a software development project are: -

Requirement Analysis

Project Planning

System design

Detail design

Coding

Unit testing

System integration & testing

Here the linear ordering of these activities is critical. End of the phase and the

output of one phase is the input of other phase. The output of each phase is to be

consistent with the overall requirement of the system. Some of the qualities of spiral

model are also incorporated like after the people concerned with the project review

completion of each of the phase the work done.

WATER FALL MODEL was being chosen because all requirements were known

beforehand and the objective of our software development is the

computerization/automation of an already existing manual working system.

Page 7: PDS Documentation

14

Fig 2.2: Water Fall Model

Product Product

input output

Process

Communicated Requirements

Requirements Specification

Design Specification

Executable Software Modules

Integrated Software Product

Delivered Software Product

Changed Requirements

Requirements Engineering

Design

Programming

Integration

Delivery

Maintenance

Page 8: PDS Documentation

14

2.3. STUDY OF THE SYSTEM

PROPOSED SYSTEM

Login with Security

Administrator Module

o Shop Information

o Dealer Information

o Cards Information

o Customer Information

o Issued goods to Dealers

o View Dealer Sales

o View Periodic reports

o View Customer Complaints

o Set Suggestions to Dealer

Dealer Module

o View Stock

o Maintain Sales Transactions

o View Suggestions

Customer Module

o View Goods Status

o Complaint to Administrator

o View Suggestion

The Application deals with the transactions that help in handling the improper

distribution of the goods by the dealers at the fair shops. The Application is

split into Four modules namely – Login Module, Administrator Module,

Dealer Module and the Customer Module.

Page 9: PDS Documentation

14

The Login Module accepts the username and password by validating which the control is

passed to the appropriate options of the other modules.

The Administrator after logging in is provided with the options to maintain the

information of the registration of the Shops, dealers, various types of cards and the

information about the customers issued with the cards under the specified dealer fair

price shops where they can avail their specified goods. The administrator is assigned with

the privileges to view the sales transactions performed by the dealer. He can also view the

complaints placed by the customer on the dealers misdealing of the goods against which

proper suggestions can be made to the respective dealer and the customer.

The dealer after logins in can view the available stock and maintain the information

about the distribution of the goods among the customers against their issued cards. He

can also view the suggestions that are specified by the Administrator.

The customer on logging can view the status of his achieved goods from the dealer for

the specified interval. If any abnormalities are found, then they can judge a complaint to

the Administrator.

2.4 REQUIREMENT SPECIFICATION:

Software Requirements:

Operating System: Microsoft Windows-2000 (or Higher)

Language : JSP & JDBC

Back End : Sql server

Web Server : Tomcat

Page 10: PDS Documentation

14

Hardware Requirements:

Processor:PIII(orHigher)

Ram : 256 MB

Hard Disk : 4 GB

Monitor : 256 Colors, 640*480 Colors

Network : LAN

Page 11: PDS Documentation

14

3.0 FEASIBILITY REPORT

The application in whole was found to be feasible in the following study and

reports.

3.1 Technical feasibility:

The system public distribution system

is implemented keeping in mind the availability of the existing infrastructure software

and environments wherever the deployment of the application is to happen.

It is count no additional expenditure in terms of buy new software peripherals, resources

is required in the proposed system. Hence, technical feasibility is achieved.

The ISP provides the infrastructure resources wherever the application is deployed. It

includes the server, network, bandwidth, security and production. Hence, the

organization has to pay only for the web space required by them. This also means, there

is no maintenance cost involved what so ever.

3.2 Operations feasibility:

The manpower in the existing system is required at various levels and the

organization has to meet the cast towards them. Money is invested in the machinery for

maintenance, as wages to the system upgrades and operations, the cargo tracker

application address the above investment has given below,

1) As the application is deployed on ISP it is not effective when it comes to

operation. This is because the ISP provides it.

2) The manual labors required to operate the system is required only during up

gradations or revamping of the site. This has reduced considerably this

involvement of more manual labor.

3) As there is no maintenance required to be performed by the organization, which is

also taken care of by the ISP the system in whole is operations feasible

Page 12: PDS Documentation

14

3.3 Economic feasibility:

As the system is technically and operation feasible interactively, the system is

economically feasible. Economic feasibility is achieve keeping in mind that the deployed

application also reduces requiring expenditures towards maintenance cost of the server,

where entire of the machineries, warranty and guaranty of the peripherals, the data

handled and the wages pay to the employees. The above studies conclude the system is

feasible.

Economic analysis is the most frequently used method

for evaluating the effectiveness of a candidate system. More commonly

known as cost/benefit analysis, the procedure is to determine the benefits

and savings that are expected from a candidate system and compare them

with costs. If benefits outweigh costs, then the decision is made to design

and implement the system.

Otherwise, further justification or alterations in the proposed system will have

to be made if it is to have a chance of being approved. This is an ongoing

effort that improves in accuracy at each phase of the system life cycle.

Technical Feasibility:

Technical feasibility centers around the existing computer

system (hardware, software, etc.) and to what extent it can support the

proposed addition. For example, if the current computer is operating at 80

percent capacity-an arbitrary ceiling-then running another application could

overload the system or require additional hardware. This involves financial

considerations to accommodate technical enhancements. If the budget is a

serious constraint.

Page 13: PDS Documentation

14

DEFINITION OF MODULES

4.1 Login and Security:

The module deals with allowing the public to apply for a ration card. The functionality is to provide the each citizen with a ration card. Appropriate personal information is collected and the card is provided. The facility to maintain the card such edit, delete & view is possible

4.2 Administrator

o Shop Information

o Dealer Information

o Cards Information

o Customer Information

o Issued goods to Dealers

o View Dealer Sales

o View Periodic reports

o View Customer Complaints

o Set Suggestions to Dealer

4.3 Dealer

This module deals with viewing of current stock, viewing of sales on a specified

date, viewing of the suggestions.

Dealer will receive stock from the administrator, assigning of the stock to the customers

will be done by the dealer.

4.4 Customer

This module deals with the purchasing of the stock from the dealer, every customer has to

register himself with the administrator, and will be assigned with a unique customer id.

Customer can also view stock purchases.

Page 14: PDS Documentation

14

5. DEVELOPMENT ENVIRONMENT (JAVA)

5.1 ENVIRONMENT:

Java was conceived by James Gosling, Patrick Naughton, ChrisWarth, Ed Frank and Mike Sheridan at SUN Micro Systems Incorporation in 1991. It took 18 months to develop the first working version. This language was initially called “OAK”, but was renamed “JAVA” in 1995. Before the initial implementation of OAK in 1992 and the public announcement of Java in 1995, many more contributed to the design and evolution of the language.

5.1.1 OVERVIEW OF JAVA:

An Object Oriented Programming Language(OOPL) developed at Sun Microsystems. A Virtual Machine Run Time Environment that can be embedded in web browser (IE, NN). Java is a powerful but lean object oriented programming language. It has generated a lot of excitement because it makes it possible to program for Internet by creating applets, programs that can be embedded in web page.

The context of an applet is limited only by one’s imagination. For example, an applet can be an animation with sound, an interactive game or a ticker tape with constantly updated stock prices. Applets can be serious application like word processor or spreadsheet.

But Java is more than a programming language for writing applets. It is being used more and more for writing standalone applications as well. It is becoming so popular that many people believe it will become standard language for both general purpose and Internet programming. There are many buzzwords associated with Java, but because of its spectacular growth in popularity, a new buzzword has appeared ubiquitous. Indeed, all indications are that it will soon be everywhere.

Java builds on the strength of C++. It has taken the best features of C++ and discarded

the more problematic and error prone parts. To this lean core, it has added garbage

collection (automatic memory management), multithreading(the capacity for one

Page 15: PDS Documentation

14

program to do more than one thing at a time), security capabilities. The result is

simple, elegant, powerful and easy to use.

Java is actually a platform consisting of three components:

Java Programming Language.

Java Library of Classes and Interfaces.

Java Virtual Machine.

It also has a Standardized set of Packages (Class, Interfaces):

Creating Graphical User Interfaces

Controlling Multimedia Data

Communicating over Network

The following sections will say more about these components:

FEATURES OF JAVA:

JAVA IS PORTABLE:

One of the biggest advantages Java offers is that it is portable. An application written

in Java will run on all the major platforms. Any computer with a Java based browser

can run the applications or applets written in the Java Programming Language. A

programmer no longer has to write one program to run on a Macintosh, another

program to run on a windows machine, still another to run on a UNIX machine, and

Page 16: PDS Documentation

14

so on. In other words, with Java, developers write their programs only once. The

virtual machine is what gives Java is cross platform capabilities.

Rather than being compiled into machine language, which is different for each

operating systems and computer architecture, Java code is compiled into byte codes.

With other languages, the program can understand. The problem is that other

computers with different machine instruction set cannot understand that language.

Java code, on the other hand is compiled into byte codes rather than a machine

language. These byte codes go to the Java virtual machine, which executes them

directly or translate them into the language that is understood by the machine running

it. In Summary, these means that with the JDBC API extending Java, A programmer

writing Java code can access all the major relational databases on any platform that

supports the Java virtual machine.

JAVA IS OBJECT_ORIENTED:

The Java programming language is object oriented, which makes program design

focus on

what you are dealing with rather than on how you are going to do something.

This makes it more useful for programming in sophisticated projects because one

can break the things down into understandable components. A big benefit is that

these components can then be reused.

Object oriented languages use the paradigm of classes. In simplest term, a class includes both the data and the functions to operate on the data. You can create an instance of a class, also

Page 17: PDS Documentation

14

called an object, which will have all the data members and functionality of its class. Because of this, you can think of a class as being like template, with each object being a specific instance of a particular type of class.

The class paradigm allows one to encapsulate data so that specific data values are those using the data cannot see function implementation. Encapsulation makes it possible to make the changes in code without breaking other programs that use that code. If for example the implementation of a function is changed, the change is invisible to the programmer who invokes that function, and it does not affect his/her program, except hopefully to improve it. Java includes inheritance, or the ability to derive new classes from existing classes. The derived class, also called a subclass, inherits all the data and the functions of the existing class, referred to as the parent class. A subclass can add new data members to those inherited from the parent class. As far as methods are concerned, the subclass can reuse the inherited methods as it is, changed them, and/or add its own new methods.

5.1.2.3 JAVA MAKES IT EASY TO WRITE CORRECT CODE:

In addition to being portable and object oriented, Java facilitates writing correct code. Programmers spend less time writing Java code and a lot less time debugging it. In fact, developers have reported slashing development time by as much as two thirds.

The following is a list of some of Java’s features that make it easier to write correct code:

5.1.2.3.1 GARBAGE COLLECTION:

Automatically takes care of allocating and reallocating memory, a huge potential

source of errors. If an object is no longer being used (has no references to it), then it is

automatically removed from memory. Dynamic binding is possible and often very

useful, but static binding with strict type checking is used when possible.

5.1.2.3.2 SIMPLICITY:

Makes Java easier to learn and use correctly. Java keep it simple by having just one way to do something instead of having several alternatives, as in some languages. Java also stays lean by not including multiple inheritance, which eliminates the errors and ambiguity that arise when

Page 18: PDS Documentation

14

you create a subclass that inherits from two or more classes. Java lets you add functionality to a class throws by the use of interfaces.

5.1.2.4 JAVA INCLUDES A LIBRARY OF CLASSES AND INTERFACES:

The Java platform includes an extensive class library so that programmers can use already existing classes, as it is, create subclasses to modify existing classes, or implement interfaces to augment the capabilities of classes.

Both classes and interfaces contain data members (fields) and functions (methods), but there are major differences. In a class, fields may be either variable or constant, and methods are fully implemented. In an interface, fields must be constants, and methods are just prototypes with no implementations. The prototypes give the method signature (the return type, the function name, and the number of parameters with the type for each parameter), but the programmer must supply implementations.

To use an interface, a programmer defines a class, declares that it

implements the Interface, and then implements all the methods in that

interface as part of the class. These methods are implemented in a way that

is appropriate for the class in which the methods are being used. Interfaces

let one add functionality to a class and give a great deal of flexibility in

doing it. In other words interfaces provide most of the advantages of

multiple inheritance without its disadvantages.

A package is a collection of related Java classes and interfaces. The following list,

though not complete, gives example of some Java packages and what they cover.

Java.lang: The basic classes. This package is so basic that it automatically is included in

any Java program. It includes classes dealing with numeric, strings, objects, runtime,

security, and threads.

Page 19: PDS Documentation

14

Java.io: Classes that manages reading data from input streams and writing data to the

output streams.

Java.util: Miscellaneous utility classes, including generic data structures, bit sets, time,

date, the string manipulation, random number generation, system properties,

notification and enumeration of data structures.

Java.net: Classes for network support.

Java.awt: Classes that manage user interface components such as windows, dialog

boxes, buttons, checkboxes, lists, menus, scrollbars, and text fields, the “AWT” stands

for Abstract Window Toolkit.

Java.awt.image: Classes for managing image data, including color models, dropping

color flittering, setting pixel values, and grabbing snapshots.

Java.applet: The Applet class, which provides the ability to write applets, this package

also includes several interfaces that connect an applet to its documents and to its

document and to its document and to recourses for playing audio.

Java.sql: The JDBC API, classes and interfaces that access databases and send SQL

Statements.

The first three packages listed, java.lang, java.io and java.util form the foundation, they are basic classes and interfaces for general-purpose programming.

Java development kit version1.1 added some new packages, with JDBC being one of them. Other new packages include such thing as Remote Method Invocation, Security and Java Beans, the new API for creating reusable components.

In Java, packages serve as the foundation for building other packages, as discussed in the following section.

Page 20: PDS Documentation

14

5.1.2.4.1 JAVA IS EXTENSIBLE:

A big plus for Java is the fact it can be extended. It was purposely written to be lean with the

emphasis on doing what it does very well, instead of trying to do everything from the beginning,

it was return so that extending it is very easy. Programmers can modify existing classes or write

their own new classes or they can write a whole new package. The JDBC API, the java.sql

package, is one example of a foundation upon which extensions are being built. Other

extensions are being added or worked on in area such as multimedia, Internet Commerce,

conferencing, and telephony.

In addition to extensions there are also main tools being developed to make existing capabilities easier to use. For example, there is already a tool that greatly Simplifies creating and laying out Graphical User Interfaces such as menus, Dialog boxes and buttons.

5.1.2.4.2 SECURITY:

It is important that a programmer not be able to write subversive code for Applications or applets. This is especially true with the Internet being used more and more extensively for services such as electronic commerce and electronic distribution of software and multimedia content.

The Java platform builds in security in four ways.

The way memory is Allocated and laid out: In Java an object’s location in memory is not

determined until The runtime, as opposed to C and C++, where the compiler makes

memory layout Decisions. As the result, a programmer cannot look at a class definition

and figure out how it might be laid out in memory. Also since, Java has no pointers, a

programmer cannot forge pointers to memory.

Page 21: PDS Documentation

14

The way incoming code is checked: The Java virtual machine doesn’t trust any incoming

code and subjects it to what is called byte code verification. The byte code Verifier, part

of the virtual machine, checks that the format of incoming code is correct

incoming code doesn’t forge pointers, it doesn’t violate access restrictions, it

accesses objects what they are.

The way classes are loaded: The Java byte code loader, another part of the virtual

machine, whether classes loaded during program execution are local or from across a

network. Imported classes cannot be substituted for built in classes, and built in classes

cannot accidentally reference classes brought in over a network.

The way access is restricted for untested code: The Java security manager allows user to

restrict untested Java applets so that they cannot access the local network, files and

other resources.

5.1.2.5 JAVA PERFORMS WELL:

Java performance is better than one might expect. Java has many advantages, such as having built in security and being interpreted as well as compiled, do have a cost attached to them. However, various optimizations have been built in, and the byte code Interpreter can run very fast the cost it doesn’t have to do any checking. As a result, Java has done quite respectably in performance tests. Its performance numbers for interpreting byte codes are usually more than adequate to run interactive graphical end user applications.

For situations that require unusually high performance, byte codes can be translated on the fly, generating the final machine code for the particular CPU on which the application is running at run time. High level interpreted scripting language generally offer great portability and fast prototyping but poor performance. Low level compiled language like C and C++ offer great performance but require large amounts of time for writing and debugging code because of problems with areas such as memory management, pointers and multiple inheritance. Java offers good performance with the advantages of high level languages but without the disadvantages of C and C++.

Page 22: PDS Documentation

14

In the world of design trade-off,

5.1.2.6 JAVA IS ROBUST:

The multi platformed environment of the WEB places extraordinary demands on a program, because it must execute reliably in a variety of systems. Thus the ability to create robust programs was given a high priority in the design of Java. To gain reliability, Java restricts you in a few key areas to force you to find your mistakes early in program developments. At the same time, Java frees you from having to worry about many of the most common cause of programming errors. Because Java is strictly typed language, it checks your code at compile time. However, it also checks your code at run time. In fact, many hard to track down bugs that often turn up in hard to reproduce runtime situations are simply impossible to create in Java. Knowing that what you have written will behave in a predictable way under diverse conditions is a key feature of Java to understand how Java robust.

Consider two main reasons for program failure:

Memory management mistakes and mishandled exceptional conditions (run time

errors).

Memory management can be difficult, tedious task in traditional programming

environments.

For example in C/C++ the programmer must manually allocate and free all dynamic memory. This sometimes leads to problems. For example some programmers some times forget the free memory that has been previously allocated. Or worse, they may free some memory that another part of their code is still using. Java virtually eliminates these problems by managing memory allocations and reallocations. Java helps in this area by providing object oriented exception handling. In a well-written Java a program should manage program all run time errors.

5.1.2.7 JAVA SCALES WELL:

Java platform is designed to scale well, from portable consumer electronic devices to powerful desktop and server machines. The virtual machine takes a small foot print and Java byte code is optimized to be small and compact. As a result, Java accommodates the need for low storage and for low bandwidth transmission over the Internet. In addition the Java operating system offers a standalone Java platform that eliminates host operating system overhead while still

Page 23: PDS Documentation

14

supporting the full Java platform. API makes Java ideal for low cost network computers whose sole purpose is to access the Internet.

5.1.2.8 JAVA IS MULTITHREADED:

Multithreading is simply the ability of a program to do more than one thing at a time. For example an application could be faxing a document at the same time it is printing another document. Or a program could process new inventory figures while it maintains a feed for current prices. Multithreading is particularly important in multimedia. A multimedia program might often be running a movie, running a audio track and displaying text all at the same time.

5.1.2.9 JAVA IS IMPORTANT TO THE INTERNET:

The Internet helped catapult Java to the forefront of programming and Java in turn has a profound effect on the Internet. The reason is simple. Java expands the universe of objects that can move about freely in cyberspace. In a network, there are two broad categories of objects transmitted between the server, your personal computer, passive information and dynamic, active programs. For example, when you read your e-mail, you are viewing passive data. Even when you download a program, the program’s code is still only passive data until you execute it. However, there is a second type of object that can be transmitted to your computer, a dynamic, self executing program. Such a program would be an active agent on the client computer, yet it would be initiated by the server. As desirable as dynamic, networked programs are, they also present serious problems in the areas of security and portability. Prior to Java cyberspace was effectively closed to half the entities that now live there. Java addresses these concerns and doing so, has opened the door to an exiting a new form of program.

Page 24: PDS Documentation

14

5.2 JAVA DATA BASE CONNECTIVITY:

5.2.1 INTRODUCTION:

Java Database Connectivity(JDBC) is a front-end tool for connecting to a server to ODBC in that respect, However JDBC can connect only Java clients and it uses ODBC for the connectivity. JDBC is essentially a low-level application programming interface. It is called a low-level API since any data manipulation, storage and retrieval has to be done by the program itself. Some tools which provide a higher-level abstraction or expected shortly.

The next question that needs to be answered is why we need JDBC, once we have ODBC on hand. We can use the same ODBC to connect the entire database and ODBC is a proven technology. Problem for doing this is ODBC gives a ‘C’ language API, which uses pointers extensively. Since Java does not have any pointers and is object-oriented sun Microsystems, inventor of Java developed to suit its needs.

5.2.2 REQUIREMENTS TO USE JDBC:

To use JDBC you need a basic knowledge of database and SQL. Apart from this you need the jdk1.1 (Java Development Kit 1.1) or a version of Java since jdk1.1 and above come bundled with JDBC software.

After that you need to have a back-end database engine for which a JDBC driver is available. When JDBC drivers are not available JDBC-ODBC bridge drivers are used to access the database through ODBC. Back-end is not need when JDBC driver is capable of storing and retrieving the data itself, or if JDBC-ODBC bridge and the ODBC driver can be store and retrieve the information.

Page 25: PDS Documentation

14

5.2.3 DATABASE MODELS:5.2.3 DATABASE MODELS:

JDBC and accessing the database through applets, and JDBC API via an intermediate server resulted in a new type of database model which is different from the client-servers through which the request should go it is named as single tier, two tier and multi tier architecture.

5.2.4 JDBC DRIVER TYPES:5.2.4 JDBC DRIVER TYPES:

The JDBC drivers that we are aware of at this time fit into one of four categories:

JDBC-ODBC bridge plus ODBC driver: The Java Soft bridge product provides JDBC

access via ODBC drivers. Note that ODBC binary code and in many cases database

client code must be loaded on each client machine that uses this driver. As a result,

this kind of driver is most appropriate on a corporate network where client

installations are not a major problem, or for application server code written in Java

in a three-tier architecture.

Native-API partly-Java driver: This kind of driver converts JDBC calls into calls on the

client API for Oracle, Sybase, Informix, DB2, or other DBMS. Note that, like the

bridge driver, this style of driver requires that some binary code be loaded on each

client machine.

JDBC-Net all-Java driver: This driver translates JDBC calls into a DBMS-independent

net protocol that is then translated to a DBMS protocol by server. This net server

middle ware is able to connect its all-Java clients to many different databases. The

specific protocol used depends on the vendor. In general, this is the most flexible

JDBC alternative. It is likely that all vendors of this solution will provide products

suitable for Internet use. In order for these products to also support Internet access,

they must handle the additional requirements for security, access through firewalls,

Page 26: PDS Documentation

14

etc., that the Web imposes. Several vendors are adding JDBC drivers to their existing

database middle ware products.

Native-protocol all-Java driver: This kind of driver converts JDBC calls into the

network protocol used by DBMS directly. This allows a direct call from the client

machine to the DBMS server and is a practical solution for Internet access. Since

many of these protocols are proprietary, the database vendors themselves will be

the primary source. Several database vendors have these in progress.

Eventually, we expect the last two drivers will be preferred way to access databaseEventually, we expect the last two drivers will be preferred way to access database

from JDBC. And the first two driver categories are interim solutions where directfrom JDBC. And the first two driver categories are interim solutions where direct

all-Java drivers are not yet available. The last driver is in some sense the ideal one.all-Java drivers are not yet available. The last driver is in some sense the ideal one.

However, there are many cases where However, there are many cases where JDBC-Net all-Java driver may be preferable. may be preferable.

For example, where a thin DBMS- independent client is desired, or if a DBMS-For example, where a thin DBMS- independent client is desired, or if a DBMS-

independent protocol is standardized and implemented directly by many DBMSindependent protocol is standardized and implemented directly by many DBMS

vendors.vendors.

5.3 HTML

5.3.1 INTRODUCTION:

The Hyper Text Markup Language (HTML) is a simple markup language used to create hypertext documents that are portable from one platform to another. HTML documents are SGML documents with generic semantic that are appropriate for representing information from a wide range of applications. This specification defines HTML version 3.2. HTML 3.2 aims to capture recommended practice as of early ‘96 and as such to be used as a replacement for HTML 2.0(RF1866).

A set of instructions embedded in a document is called Markup Language. These instructions describe what the document text means and how it should look like in a display. Hyper Text Markup Language (HTML) is the language used to encode World Wide Web documents. It is a document layout and hyperlink specification language that defines the syntax and placement of special embedded directions that are not displayed by a web browser, but tells it how to display the contents of the documents including text, images and other supported media.

Page 27: PDS Documentation

14

1.1

1.2

1.3 5.3.2 USE OF HTML:

Web site is a collection of pages, publications, and documents that reside on web sever. While these page publications, and a document as a formatted in any single format. You should use HTML for home page and all primary pages and the site. This will enable the millions of web users it easily access and to take advantage of your website. HTML is considered first for formatting any new material you plan to publish on the web. HTML documents are platform independent, meaning that they don’t confirm to any standard. If they are created properly you can move home to any server platform or you can access them with any complaint www browser.

1.4

1.5 5.3.3 BLOCK OF HTML:

1.5.1

1.5.2 HTML elements perform a defined task. HTML uses two types of elements

o Empty tags(open tags)

o Container tags

These tags differ because of what they represent. Empty tags represent formatting constructs such as line breaks and Horizontal rules. Container tags define a section of text and specify the formatting the container dot all of the selected text. A container tag has both a beginning and an ending.

1.6

1.7 5.3.4 HTML LAYOUT:

Page 28: PDS Documentation

14

An HTML document consist of text, which comprises the content of the document and tags which, defines the structure and appearance of the document. The structure of an HTML document is simple.

<HTML>

<HEAD>

<TITLE> the title of the HTML document </TITLE>

</HEAD>

<BODY>

This is where the actual HTML documents

Text lies which is displayed in the browser

</BODY>

</HTML>

5.3.4.1 PROGRAM DESCRIPTION:

The first line i.e., <HTML> tag, HTML tag is beginning tag and second line is starting

tag for head section is <HEAD> The third line i.e., <TITLE> form example program

</TITLE> is the title of the program. It defines a text string that is interpreted as the

HTML title of the document. The tag </HEAD> will end the HEAD section of the

program. Next tag is <BODY> the beginning of the body section where HTML

document text lies, which is displayed in the browser. Next tags </BODY> </HTML> are

the ending tags for the body section and html program respectively.

1.7.1.1.1

Page 29: PDS Documentation

14

1.7.1.1.2 Each document has a head and body delimited by the <HEAD>

and <BODY> tag. The head is where you give your HTML document a title and

where you indicate other parameters the browser may use when displaying the

document. The body is where you put the actual contents of the HTML

documents. This include the text for displaying the text. Tag also references

special and hot spots that link your document to other documents.

5.5 JAVA SERVER PAGES(JSP)

5.5.1 INTRODUCTION:

Java Server Pages (JSP's) permit server side Java logic to reside within the requested document.

Upon request of a JSP document the server activates the specified JSP. The JSP then becomes

responsible for providing an HTML response.

The server side logic within a JSP is written in Java. The Java code segments, referred to as

scriptlets, are generally responsible for providing dynamic HTML content to the JSP's response

HTML. The JSP itself is compiled by the server, and is executed as an object that extends the Java

Servlet API. As such, the HTTP Servlet request and response objects are available by the

scriptlets defined within the JSP.

Page 30: PDS Documentation

14

This document reviews client-server design considerations in respect to the use of JSP’s.

Implementation options, particularly the use of JSP language extensions and use of Enterprise

Java Beans (EJB's) will also be discussed. Focus will be placed on the presentation layer and how

the JSP is used to provide a user interface and communicate business logic requests to the

supporting system.

If we consider a 3-tier architectural WEB application, the browser becomes the client side

application. The user communicates requests to the WEB/app server via the browser. The

presentation layer receives the client requests and prepares the response and server side

business functionality is executed. In the context of this example, the JSP engine represents the

presentation layer. It is responsible for processing requests and responses. Additional messages

may be passed between this layer and that which handles business processes represented

below as EJB’s.

Figure 1

Page 31: PDS Documentation

14

5.5.2 THE TECHNOLOGY:

JSP technology uses XML - like tags and scriptlets. They are used to encapsulate presentation

logic within the JSP. They can also initiate messages to distributed or server-side applications.

The logical separation of presentation and business logic lies in the implementation of the JSP.

Enterprise Java Beans provide a distinct relationship between the implementation of business

logic and the remote interfaces provided to the EJB client. The use of an EJB typically follows the

pattern:

The client application identifies itself to the server.

The client application uses the Java Naming Directory service to locate the desired

EJB.

The client application retrieves a handle to the EJB Home and subsequently Remote

interfaces.

The remote interface contains methods that the client is permitted to use. They represent a

summary of the business logic that is implemented by the bean. The implementation logic is

defined within the primary bean class. All IPC, database and resource details are restricted to

the bean class.

Page 32: PDS Documentation

14

In constructing a JSP document, the creation of the HTML base is a prudent step. It becomes the

visual template that JSP scriptlets are merged into. The post execution HTML produced from the

completed JSP should be that of the original HTML document. With the exception of comment,

dynamically generated HTML sections and JSP content substitutions. The scripting logic, except

for where desired, is completely non visual in regard to the response HTML text.

The construction of the HTML layout conceivably begins with a Web developer. The creation of

the JSP pages would be similar if not identical to the methods used to construct industry HTML

pages. The next step would be the addition of JSP specific logic to identify the sections of the

HTML that might be generated dynamically. This conversion step from pure HTML to JSP is

where server side logic is added to the page.

A completed JSP logically embodies presentation layer services and business functionality.

Physically they are blended within the JSP in an as needed swapping of HTML and JSP code.

Continued maintenance of the application and changes in the business logic need not affect

the presentation layout. Likewise, changes in the presentation layout need not affect the

scriptlet logic, it will however require that the WEB developer, not necessarily a JAVA

programmer, show care in the handling of this file which is no longer pure HTML should any

HTML maintenance become necessary.

5.5.3 THE ALTERNATIVE:

Page 33: PDS Documentation

14

A design consideration intended to reduce the complexity of maintaining the HTML aspect of a

JSP is to minimize the use of scriptlets in constructing a JSP. Custom tags, introduced in JSP 1.1,

can equally produce the functionality provided by JSP scriptlets.

Custom tags are application defined language extensions to Java Server Pages. Custom tags

can be used within a JSP in the following ways:

To produce html output.

To produce JSP output (JSP expressions, directives, ...).

To create objects.

To define objects that can be seen as scripting variables within the parent JSP.

To iterate over a body of JSP/HTML text in a finite manner.

To determine if section of the calling JSP should be processed or skipped.

The goal of using custom tags to minimize the presence of scriptlets is to produce a more HTML

– like JSP. The advantages of this goal are self-evident if we consider projects that expect

frequent HTML modifications. Assuming the business logic, pre-presented by the JSP tags, is

stable it can be identically merged into various forms of the HTML layout, without explicitly

inserting duplicate sections of scriptlet logic (Java code).

Page 34: PDS Documentation

14

Tag handlers implement JSP custom tags. One or more tag handlers can be listed in the Tag

Library Descriptor files. References to these files are included in the JSP that intends to use a

given tag handler. The tag handler itself is implemented as a Java object that extends the JSP

body. Upon execution it has access capabilities to the JSP's Http servlet objects, page attribute

and session attribute objects. It can, conceivably, provide a full HTML response to the client in

the way that servlets operate. A significant distinction from Java Server Pages is that tag

handlers are not designed to be dynamically compiled by the server.

In respect to EJB's, a tag handler accesses an EJB in the same manner as the above scriptlet. It

can additionally make available any object it creates, available to other tag handlers and JSP’s.

This is accomplished by the use of storage methods that operate within the scope of the page

and session. This includes the retention of EJB remote interface objects that can be created once

and re-used by subsequent JSP’s via scriptlets or tags.

The JSP engine and Java Server Pages logically produce presentation layer services. They also

provide the interface to business services (i.e. EJB’s). The physical separation of the logic

associated with these middle tier components is evident in the above example. The same EJB

logic in the previous example is represented here by the tag references.

Figure 2 gives a graphical representation of the physical control flow without the use of custom

tags. The client initiates execution with a JSP request. The request via URL is directed to the WEB

server that is responsible for servicing such requests. The JSP request triggers the JSP engine to

Page 35: PDS Documentation

14

locate and execute the corresponding JSP as a servlet object. The execution of the business logic

is represented by the use of Enterprise Java Beans.

Figure 2

Logically identical, figure 3 illustrates the use of tag handlers by the JSP. This is the hidden logic

implied in HTML example 2.

Figure 3

The JSP engine, in both figures, treats the compiled JSP object as a servlet object. Figure 3’s tag

handler object extends the JSP page body. This relationship grants tag handler access to various

Page 36: PDS Documentation

14

servlet attributes. These attributes therefore permit the tag handler to conceivably inspect

parameters passed by the client.

5.5.4 CONCLUSION:

As with other tools of the trade, innovations and nuances to existing tools do not invalidate

existing design methodologies. They do however provide new versatility and the expansion of

possibilities with regard to application design.

Custom tag extensions, in contrast to standard tags, provide the application builder the ability to

define custom tags to satisfy some functionality not provided by the standard API. To benefit by

using tag extensions to reduce the amount of Java functionality that the JSP API provides, might

seem oxymorinic, and it is. With the exception of dynamically compiled JSP’s, the functionality

provided by the two given examples are identical, which suggests that the payoff for

implementing this server side alternative is purely cosmetic, and it is.

While a server side application designer does not typically consider the cosmetic aspect of

implementing source code, JSP source code might prove to be the exception. It does after all

suggest the strong possibility that a Web/HTML developer perform the continued maintenance

of the HTML portion of the JSP. This is a role, of course, traditionally allied with client side

responsibilities. The nuances introduced by JSP custom tags present nuances in the maintenance

Page 37: PDS Documentation

14

of JSP’s. The arguments presented here presume that the HTML produced by the JSP’s in

discussion are non-trivial HTML documents, although non-complex HTML documents may

benefit from similar design considerations.

5.4 SQL Server 2005 Technologies

SQL Server 2005 contains these technologies.

SQL Server Database Engine Overview

The Database Engine is the core service for storing, processing, and securing data. The Database Engine provides controlled access and rapid transaction processing to meet the requirements of the most demanding data consuming applications within your enterprise. The Database Engine also provides rich support for sustaining high availability.

SQL Server Analysis Services Overview

Analysis Services delivers online analytical processing (OLAP) and data mining functionality for business intelligence applications. Analysis Services supports OLAP by allowing you to design, create, and manage multidimensional structures that contain data aggregated from other data sources, such as relational databases. For data mining applications, Analysis Services allows you to design, create, and visualize data mining models, constructed from other data sources by using a wide variety of industry-standard data mining algorithms.

SQL Server Integration Services (SSIS) Overview

Integration Services is an enterprise data transformation and data integration solution that you can use to extract, transform, and consolidate data from disparate sources and move it to single or multiple destinations.

SQL Server Replication Overview

Replication is a set of technologies for copying and distributing data and database objects from one database to another and then synchronizing between databases to maintain consistency. Using replication, you can distribute data to different locations and to remote or mobile users over local and wide area networks, dial-up connections, wireless connections, and the Internet.

SQL Server Reporting Services Overview

Reporting Services is a new server-based reporting platform that you can use to create and manage tabular, matrix, graphical, and free-form reports that contain data from

Page 38: PDS Documentation

14

relational and multidimensional data sources. The reports that you create can be viewed and managed over a Web-based connection.

SQL Server Notification Services Overview

Notification Services is the platform for developing and deploying applications that generate and send notifications. Notification Services can generate and send timely personalized messages to thousands or millions of subscribers, and deliver them to a wide variety of devices.

SQL Server Service Broker Overview

Service Broker is a technology for building reliable, scalable, and secure database applications. Service Broker is a technology within the Database Engine that provides native support for queuing. Service Broker also provides a message-based communication platform that can be used to link disparate application components into a functioning whole. Service Broker provides much of the infrastructure necessary to build a distributed application, significantly reducing the application development time. Service Broker also makes it easy to scale your application up or down to accommodate the amount of traffic the application is receiving.

Full-Text Search Overview

SQL Server contains the functionality you need to issue full-text queries against plain character-based data in SQL Server tables. Full-text queries could include words and phrases or multiple forms of a word or phrase.

SQL Server Tools and Utilities Overview

SQL Server provides the tools you need to design, develop, deploy, and administer relational databases, Analysis Services cubes, data transformation packages, replication topologies, reporting servers, and notification servers.

A database script project is an organized set of scripts, connection information, and templates that are all associated with a database or one part of a database. Microsoft SQL Server 2005 provides the SQL Server Management Studio for administering and designing SQL Server databases within the context of a script project. SQL Server Management Studio includes designers, editors, guides and wizards to assist users in developing, deploying and maintaining databases.

SQL Server Management Studio

SQL Server Management Studio is a suite of administrative tools for managing the components belonging to SQL Server. This integrated environment allows users to perform a variety of tasks, such as backing up data, editing queries, and automating common functions within a single interface.

Page 39: PDS Documentation

14

Tools that are now incorporated into the SQL Server Management Studio include:

Code Editor is a rich script editor for writing and editing scripts. The Code Editor replaces the Query Analyzer included in previous releases of SQL Server. SQL Server Management Studio provides four versions of the Code Editor; the SQL Query Editor, MDX Query Editor, XML Query Editor, and SQL Mobile Query Editor.

Object Explorer for locating, modifying, scripting or running objects belonging to instances of SQL Server.

Template Explorer for locating and scripting templates.

Solution Explorer for organizing and storing related scripts as parts of a project.

Properties Window for displaying the current properties of selected objects.

SQL Server Management Studio also provides new functionality, including:

Disconnected access. You can write and edit scripts without connecting to an instance of SQL Server.

Scripting from any dialog box. You can create a script from any dialog box so that you can read, modify, store and reuse the scripts after you create them.

Non-modal dialog boxes. When you access a UI dialog box you can browse other resources in SQL Server Management Studio without closing the dialog box.

Solutions and Script Projects

Solution Explorer is a utility to store and reopen database solutions. Solutions organize related script projects and files. Script projects store SQL Server script files, SQL templates, connection information and other miscellaneous files. When a script is saved in a script project, users are able to:

Maintain version control on scripts.

Store results options with a script.

Organize related scripts in a single script project.

Save connection information with scripts.

The Solution Explorer is a tool for developers who are creating and reusing scripts that are related to the same project. If a similar task is required later, you can use group of scripts that were stored in a project. If you have created applications with Visual Studio or Microsoft Visual Studio .NET you will find the Solution Explorer very familiar.

Page 40: PDS Documentation

14

A solution consists of one or more script projects. A project consists of one or more scripts or connections. A project may also include non-script files.

6.0 SYSTEM DESIGN

6.1 INTRODUCTION

Software design sits at the technical kernel of the software engineering process

and is applied regardless of the development paradigm and area of application. Design is

the first step in the development phase for any engineered product or system. The

designer’s goal is to produce a model or representation of an entity that will later be built.

Beginning, once system requirement have been specified and analyzed, system design is

the first of the three technical activities -design, code and test that is required to build and

verify software.

The importance can be stated with a single word “Quality”. Design is the place

where quality is fostered in software development. Design provides us with

representations of software that can assess for quality. Design is the only way that we can

Page 41: PDS Documentation

14

accurately translate a customer’s view into a finished software product or system.

Software design serves as a foundation for all the software engineering steps that follow.

Without a strong design we risk building an unstable system – one that will be difficult to

test, one whose quality cannot be assessed until the last stage.

6.2 DATA FLOW DIAGRAMS

. The development of DFD’S is done in several levels. Each process in lower

level diagrams can be broken down into a more detailed DFD in the next level. The lop-

level diagram is often called context diagram. It consists a A data flow diagram is

graphical tool used to describe and analyze movement of data through a system. These

are the central tool and the basis from which the other components are developed. The

transformation of data from input to output, through processed, may be described

logically and independently of physical components associated with the system. These

are known as the logical data flow diagrams. The physical data flow diagrams show the

actual implements and movement of data between people, departments and workstations.

A full description of a system actually consists of a set of data flow diagrams. Using two

familiar notations Yourdon, Gane and Sarson notation develops the data flow diagrams.

Each component in a DFD is labeled with a descriptive name. Process is further

identified with a number that will be used for identification purposesingle process bit,

which plays vital role in studying the current system. The process in the context level

diagram is exploded into other process at the first level DFD.

The idea behind the explosion of a process into more process is that

understanding at one level of detail is exploded into greater detail at the next level. This

is done until further explosion is necessary and an adequate amount of detail is described

for analyst to understand the process. Larry Constantine first developed the DFD as a

way of expressing system requirements in a graphical from, this lead to the modular

design.

A DFD is also known as a “bubble Chart” has the purpose of clarifying system

requirements and identifying major transformations that will become programs in system

Page 42: PDS Documentation

14

design. So it is the starting point of the design to the lowest level of detail. A DFD

consists of a series of bubbles joined by data flows in the system.

DFD SYMBOLS:

In the DFD, there are four symbols

1. A square defines a source(originator) or destination of system data

2. An arrow identifies data flow. It is the pipeline through which the information

flows

3. A circle or a bubble represents a process that transforms incoming data flow into

outgoing data flows.

4. An open rectangle is a data store, data at rest or a temporary repository of data

Process that transforms data flow.

Source or Destination of data

Data flow

Data Store

CONSTRUCTING A DFD:

Several rules of thumb are used in drawing DFD’S:

Page 43: PDS Documentation

14

1. Process should be named and numbered for an easy reference. Each name should

be representative of the process.

2. The direction of flow is from top to bottom and from left to right. Data

traditionally flow from source to the destination although they may flow back to

the source. One way to indicate this is to draw long flow line back to a source.

An alternative way is to repeat the source symbol as a destination. Since it is used

more than once in the DFD it is marked with a short diagonal.

3. When a process is exploded into lower level details, they are numbered.

4. The names of data stores and destinations are written in capital letters. Process

and dataflow names have the first letter of each work capitalized

A DFD typically shows the minimum contents of data store. Each data store

should contain all the data elements that flow in and out. Questionnaires should

contain all the data elements that flow in and out. Missing interfaces redundancies

and like is then accounted for often through interviews.

SAILENT FEATURES OF DFD’S

1. The DFD shows flow of data, not of control loops and decision are controlled

considerations do not appear on a DFD.

2. The DFD does not indicate the time factor involved in any process whether the

dataflow take place daily, weekly, monthly or yearly.

3. The sequence of events is not brought out on the DFD

6.3 DATA FLOW DIAGRAM

Level 0:

Page 44: PDS Documentation

14

7.0 UNIFIED MODELING LANGUAGE

Unified Modeling Language

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

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

Page 45: PDS Documentation

14

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.

INTRODUCTION TO THE UNIFIED MODIFIED LANGUAGE

Building a model for a software system prior to its construction is as

essential as having a blueprint for building a large building. Good models are

essential for communication among project teams. As the complexity of the

systems increases, so does the importance of good modeling techniques.

A modeling language must include:

Model elements- fundamentally modeling concepts and semantics.

Notation-visual rendering of model elements

Guidelines-expression of usage within trade

The use of visual notation to represent or model a problem can provide us several

benefits relating to clarity, familiarity, maintenance, and simplification. The main reason

Page 46: PDS Documentation

14

for modeling is the reduction of complexity. The Unified Modeling Language (UML) is a

set of notations and conventions used to describe and model an application. The UML is

intended to be a universal language for modeling systems, meaning that it can

express models of many different kinds and purposes, just as a programming

language or a natural language can be used in different ways. A model” is an

abstract representation of a system , constructed to understand the system prior to

building or modifying it. The term “system” is used here in a broad sense to

include any process or structure. For example, the organizational structure of a

corporation , health services, computer software, instruction of any sort (including

computers) , the national economy, and so forth all would be termed

“systems”. The unified modeling language is a language for specifying,

constructing, visualizing, and documenting the software system and its components.

The UML is a graphical language with sets of rules and semantics. The rules and

semantics of a model are expressed in English, in a form known as “object

constraint language”(OCL).OCL is a specification language that uses simple logic

for specifying the properties of a system.

The UML is not intended to be a visual programming language in the

sense of having all the necessary visual and semantic support to replace

programming languages. However, the UML does have a tight mapping to a family

of object-oriented languages, so that you can get the best of both worlds.

The primary goals in the design of the UML were as follows:

1. Provide users ready-to-use, expensive visual modeling languages so they can

develop and exchange meaningful models.

2. Provide extendibility and specialization mechanisms to extend the core concepts.

3. Be independent of particular programming languages and development process.

4. Provide a formal basis for understanding the modeling language.

5. Encourage the growth of the OO tools market.

6. Support higher level development concepts.

Page 47: PDS Documentation

14

7. Integrate best practices and methodologies.

UML is a language used to:

“Visualize” the software system well-defined symbols. Thus a developer or tool can

unambiguously interpret a model written by another developer, using UML

“Specify the software system and help building precise, unambiguous

and complete models.

“Construct” the models of the software system that can directly

communicate with a variety of programming languages.

“Document” models of the software system during its development

stages.

Architectural views and diagrams of the UML

The UML Meta model elements are organized into diagrams. Different diagrams are

used for

different purposes depending on the angle from which you are viewing the

system. The different views are called “architectural views”. Architectural views

facilitate the organization of knowledge, and diagrams enable the communication of

knowledge. Then knowledge itself is within the model or set of models that

focuses on the problem and solution. The architectural views and their diagrams

are summarized below:

o The “user model view” encompasses a problem and solution from the

preservative of those individuals whose problem the solution addresses. The view

presents the goals and objectives of the problem owners and their requirements of

the solution. This view is composed of “use case diagrams”. These diagrams

describe the functionality provided by a system to external interactors. These

diagrams contain actors, use cases, and their relationships.

Page 48: PDS Documentation

14

o The “Structural model view” encompasses the static, or structural, aspects

of a problem and solution. This view is also known as the static or logical

view. This view is composed of the following diagrams

o “Class diagrams” describe the static structure of a system, or how

it is declared rather than how it behaves. These diagrams contain classes and

associations.

o “object diagrams” describe the static structure of a system at a

particular time during its life. These diagrams contain objects and links.

o The “behavioral model view” encompasses the dynamic or behavioral aspects

of a problem and solution. The view is also known as the dynamic, process,

concurrent or collaborative view. This view is composed of the following

diagrams:

o “Sequence diagrams” render the specification of behavior. These diagrams

describes the behavior provided by a system to interactions. These

diagrams contain classes that exchange messages with in an interaction

arranged in time sequence. In generic form, These diagrams describe a set

of message exchange sequences among a set of classes. In instance

form(scenarios), these diagrams describe one actual message exchange

sequence among objects of those classes.

o “Collaboration diagrams” render how behavior is realized by

components with in a system. These diagrams contain classes, associations,

and their message exchanges with in a collaboration to accomplish a

purpose. In generic form, these diagrams describe a set of classes and

associations involved in message exchange sequences. In instance

form(scenarios), these diagrams describe a set of objects of those classes

links confirming to the associations, and one actual message exchange

sequence that inconsistent with the generic form and uses those objects

and links.

Page 49: PDS Documentation

14

o “State chart diagrams” render the states and responses of a class

participating in behavior, and the life cycle of an object. These diagrams

describe the behavior of a class in response to external stimuli.

o “Activity diagrams” render the activities of a class participating in behavior.

These diagrams describe the behavior of a class in response to internal

processing rather than external events. Activity diagrams describe the

processing activities with in a class.

o The “Implementation model view” encompasses the structural and

behavioral aspects of the solution’s realization. This view is also known

as the component or development view and is composed of “component

diagrams”. These diagrams describe the organization of and dependencies

among software implementation components. These diagrams contain

components and their relationships.

o The “Environment model view” encompasses the structural and behavioral

aspects of the domain in which a solution must be realized. This view is

also known as the deployment or physical view. This view is composed of

“deployment diagrams”. These diagrams describe the configuration of

processing resources elements and the mapping of software

implementation components onto them. These diagrams contain nodes,

components and their relationships.

UML DIAGRAMS

Every complex system is best approached through a small set of nearly

independent views of a model; no single viewer is sufficient. Every

model may be expressed at different levels of fidelity. The best models are

connected to reality. The UML defines nine graphical diagrams.

1. Class diagram

2. Object diagram

3. Use-case diagram

4. Behavior diagrams

Page 50: PDS Documentation

14

5. Interaction diagrams

6. Sequence diagram

7. Collaboration diagram

Page 51: PDS Documentation

14

CLASS DIAGRAM FOR PDS

set suggestions

set suggestion()

<<control>>

login

check weather()

<<boundary>>login ctrl

check validity()

<<control>>

11 11

view complaints

view complaints()

<<control>>

card

cidcnameaddr

new()edit()delete()view()

<<control>>

licence

lnohold namehold addr

<<control>>

Admin

nameid

login()issue licence()view complaints()set suggestions()

<<Actor>>

1

1

1

1

1

1

1

1

Payment

bill no.pdessmt

show()

<<control>>

products

pdidpdnamecost

<<control>>

bill submission

cidbillno.des of product

submit()

<<control>>

Dealer

nameid

login()issue card()issue products()

<<Actor>>

11

1

1

1

1

sales

cidpidqtyamtbill no.

sale()

<<control>>

11

customer

nameid

login()payment()set complaints()

<<Actor>>

1

1

1

1

1

1 1

1

1

1

1

1

1

Class diagram for Public Distribution system

1

11

set complaints

set complaints()

<<control>>

11

11

System

details of shops & licence()set complaints()view complaints()

<<entity>>

1

1

1

1

11

11

1

1

1

1

11

11

11

11

Page 52: PDS Documentation

14

USE CASE DIAGRAM FOR PDS

Registere

PDSlogin

bell

paymentmonitor recvied product

submitbill

USECASE DIAGRAM

Page 53: PDS Documentation

14

USECASE DIAGRAM FOR ADMINISTARTOR

pds

submit Bill licence productpayment

Issuecard

login

Admin

sale

check availabi...

paymentcustomer

login

Billsubmission

USECASE DIAGRAM

Page 54: PDS Documentation

14

USECASE DIAGRAM CUSTOMER

customer

login

purchase

payment

billlpayment

check availabity

USECASE DIAGRAM

Page 55: PDS Documentation

14

COLLABORATION DIAGRAM ISSUE DIAGRAMS

: customer

: i-customer

: dealer

: cissue ctrl : view ctrl

: system1

1:

5:

6:

7:

8:

9:

2:

: i-dealer

3:

4:

1.send request for card

2.send request

3.view request

4.send view request

5.process request

6.get data

7.send customer details

8.process data & issue card

9.update

collaboration diagram for Issue card

Page 56: PDS Documentation

14

SEQUENCE DIAGRAM FOR LOGIN

: user : i-reg : login ctrl : System

enter uid &pwd send id & pwd

validate details

access the system

Sequence diagram for login

Page 57: PDS Documentation

14

SEQUENCE DIAGRAM FOR ADMINISTRATOR

: Admin : i-Admin : view complaints : set suggestion : maintain db : System : licence ctrl

dealer data

enter

send dealerdata verify data &

issuelicence

update the system

req to view

complaints send req

display

enter

suggestions send suggestions

verify

update

sequence diagram for Administrator

Page 58: PDS Documentation

14

SEQUENCE DIAGRAM FOR UPADTE STOCK SALES

P;PDU S

1 : \request products\

2 : \list product\

5 : \issueproducrs\

3 : \specify products\

4 : calculate payment

6 : update stock,sales and paydb

7 : \recieve payment\

S:PDSC:PUR...

C:CUS

SEQUENCE DAIGRAM

Page 59: PDS Documentation

14

8. OUTPUT SCREENS:

9.0 IMPLEMENTATION AND MAINTENANCE

The system is implemented in two phases where one part of the application is deployed

on client server architecture while the other phase is deployed as a web module. The

client server application runs at the port enables the dealer registration, customer

registration, issuing card, assigning goods to dealers ,viewing dealer sales, viewing

customer suggestions.

The web module is deployed on the ISP (Internet Service Provider) where in a domain

name is registered an IP address is allotted. A specified amount of web space is

purchased from the ISP.A site administrator provided by the ISP is responsible for

maintenance of the site and provides the following support:

1. Revamps the site whenever the content changes.

2. To maintain the integrity of the site and data.

3. Provides support to prevent data loss by performing backing up and restore as

and when required.

4. Protect data damage from malicious ships.

5. Administration permission can be obtained from the ISP by the ports staff in

order to perform remote administration whenever required.

Page 60: PDS Documentation

14

9.1 Testing:

Introduction:

Testing is the process of detecting errors for which the required open web application

secure employment portal specifications stated. 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 the software maintenance.

The aim of testing is often used 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 doesn’t work. The main

objective of testing is to uncover an error in systematic way with minimum effort and

time.

Levels of testing

In order to uncover the errors present in different phases the different levels of

testing are:

System Testing

Function testing

The different types of testing are:

Unit testing

Link testing

Page 61: PDS Documentation

14

.

Unit testing:

This test focuses on verification effort on the smallest unit of software module. Using the

detailed design and the process specifications testing is done to uncover errors within the

boundary of the module. All the modules must be successful in the unit test before the

start of the integration testing begins.

In this project each service is a module like Login, Forms etc. Each module has to be tested by

giving different sets of inputs. The inputs are validated when accepting from user.

Integration testing:

After the unit testing the integration of modules ahs to be done and then

integration testing can be done. The goal here is to see if modules can be integrated

properly, the emphasis being on testing interfaces between different modules.

System Testing:

In the system testing the entire web portal is tested according the software

requirement specifications document.

Acceptance testing:

The acceptance testing is performed with realistic data of the client, which focus on the

external behavior of the system; the internal logic of the program is emphasized.

Page 62: PDS Documentation

14

Software testing is a critical element of software quality assurance and represents the

ultimate review of specification, design and coding. Testing is the exposure of the system

to trial input to see whether it produces correct output.

Testing Phases:

Software testing phases include the following:

Test activities are determined and test data selected.

The test is conducted and test results are compared with the expected results.

Testing Methods:

Testing is a process of executing a program to find out errors. If testing is

conducted successfully, it will uncover all the errors in the software.

Any testing can be done basing on two ways:

White Box Testing

Black Box Testing

White Box Testing:

It is a test case design method that uses the control structures of the procedural

design to derive test cases.

Using this testing a software Engineer can derive the following test cases:

Exercise all the logical decisions on either true or false sides.

Execute all loops at their boundaries and within their operational boundaries.

Exercise the internal data structures to assure their validity.

Black Box Testing

Page 63: PDS Documentation

14

It is a test case design method used on the functional requirements of the software. It will

help a software engineer to derive sets of input conditions that will exercise all the

functional requirements of the program.

Black Box testing attempts to find errors in the following categories:

Incorrect or missing functions

Interface errors

Errors in data structures

Performance errors

Initialization and termination errors

By black box testing we derive a set of test cases that satisfy the following criteria:

Test cases that reduce by a count that is greater than one

The number of additional test cases that must be designed to achieve reasonable

testing.

2. Test Plan

Testing can be done in two ways:

Bottom up approach

Top down approach

Bottom up approach:

Testing can be performed starting from smallest and lowest level modules and proceeding

one at a time. For each module in bottom up testing a short program executes the module

and provides the needed data so that the module is asked to perform the way it will when

embedded with in the larger system. When bottom level modules are tested attention

turns to those on the next level that use the lower level ones they are tested individually

and then linked with the previously examined lower level modules.

Page 64: PDS Documentation

14

Top down approach:

This type of testing starts from upper level modules. Since the detailed activities usually

performed in the lower level routines are not provided stubs are written. A stub is a

module shell called by upper level module and that when reached properly will return a

message to the calling module indicating that proper interaction occurred. No attempt is

made to verify the correctness of the lower level module.

9.2Test Cases

Module: login security

File Name: Login.aspx

Test Case

Input ExpOutput ActOutput Desc

Valid login

Uid,pwd,

utype

Success Success Test Passed. Control transferred to menu.

Invalid Login

Uid, pwd, utype

Failed Failed Test Passed. Try again.

Page 65: PDS Documentation

14

Module: customer registration

Filename: CustReg.aspx

Test Case Input ExpOutput ActOutput Desc

Register new Customer

Customer Info. Save and generate Cust. Id.

Save and generate Cust. Id.

Test Passed. Customer registered.

Register new Customer

Customer Info. Failed. Failed. Test Passed. Invalid Data.

Module: Shop id generation

Filename: Shop id generation.aspx

Test Case Input ExpOutput ActOutput Desc

Shop id sid Save and Generate sid

Save and Generate sid

Test Passed. Generate sid

Shop id sid. Failed. Failed. Test Passed. sid error.

Page 66: PDS Documentation

14

Module: customer id

File Name; customer id.aspx.vb

Test Case Input ExpOutput ActOutput Desc

customer id cid and sid Save Data. Save Data. Test Passed. cid generated

customer id cid and sid Failed. Failed. Test fails.sid not generated

TESTING :

Black box testing:-

This was tested for connection to database while performing transactions

and queries. OLEDB data provider’s functionality the ADO connection was black box

tested in all the modules related to booking, registration, delivery, consignment tracking,

scheduling and rescheduling.

White box testing:-

Page 67: PDS Documentation

14

Testing was due to check each and every line of the code executed at least

once in order to ensure these both valid and invalid inputs were provided such as null

data, invalid format, invalid datatypes, invalid length and Boolean values. Exceptions

were handled to remove their risk.

String testing:-

In most of the modules inputs were in the form of the strings which were

tested for null data, format of the data and the length of the data. Exceptions were

handled through try catch blocks to trap the errors then and there in the client server

modules while in the web modules they were taken care of by valuators.

Unit testing:-

Each and every module was tested to execute as per the SRS appropriate

inputs were provided to check if the outputs required was available. Corresponding tables

were cross verified for updation of data and complete transactions. Incomplete

transactions were rolled back and were ensured not to affect the database.

Integrated testing:-

All the modules were integrated that pertained to the 2 phases of the

application. The client server phase was checked with top down testing to check if the

screens opened in the same order starting from the splash screen to the reports module.

Synchronization of the flow of data, message passing and the database transaction

between the modules were verified.

System testing:-

Page 68: PDS Documentation

14

The client, server and the web applications modules were integrated along

with the concept of a virtual website in order to test the complete system. Errors that

arose as a result of network failure, protocols, port number, locating the web pages,

handling the URL were isolated.

LIMITATIONS:

1. Requires a server that needs to be online every time.

2. Assigning of goods is possible only when dealer register with administrator.

3. Only proper customers login and see the data..but not all the people

10. CONCLUSION

Page 69: PDS Documentation

14

The application can now ensure that the PDS stores cannot give

false information or trade illegally without the knowledge of the government. The public

on the other hand ensures that the government provided materials are readily available to

them.

11 BIBLIOGRAPHY

Page 70: PDS Documentation

14

11.1 Books:

1. Charles Petzold, 2002

Programming Windows,WP Publishers and Distributors Ltd, Bangalore.

2. Date. C. J., 1994

An Introduction to Database Systems, Addison-Wesley Publishing Company

3. Raghu Ramakrishnan, Johannes Gehrke, 2000

Database Management Systems, Mc Graw-Hill International Edition

4. Roger S. Pressman, 1997

Software Engineering, (Fourth Edition), McGraw-Hill International Edition.

11.2 Websites:

1. http://encyclopedia.laborlawtalk.com/IIS for information on IIS

2. http://aspnet.4guysfromrolla.com/articles/020404-1.aspx for relationship between IIS

and ASP.NET.

3. http://samples.gotdotnet.com/quickstart/aspplus/doc/mtstransactions.aspx for

information on Transactions in ASP.NET.