You are on page 1of 71

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

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

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

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.

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

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.

14
Changed
Requirements
Communicated
Requirements

Requirements
Specification
Requirements
Engineering

Design
Specification
Design
Maintenance
Executable
Software
Modules
Programming

Process Integrated
Software
Product
Integration

Product Delivered
Product input output Software
Product
Delivery

Fig 2.2: Water Fall Model

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.

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

14
Hardware Requirements:

Processor:PIII(orHigher)
Ram : 256 MB

Hard Disk : 4 GB

Monitor : 256 Colors, 640*480 Colors

Network : LAN

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

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.

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.

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.

14
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

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

14
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

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

14
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 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

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

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

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

14
 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.

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.

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

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

14
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++.

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

14
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 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

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

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.

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

14
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:

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, etc.,

14
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 database
from 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.
However, there are many cases where JDBC-Net all-Java driver may be preferable.
For example, where a thin DBMS- independent client is desired, or if a DBMS-
independent protocol is standardized and implemented directly by many DBMS
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

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

0.1

0.2

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

0.4

0.5 5.3.3 BLOCK OF HTML:

0.5.1
0.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.

14
0.6

0.7 5.3.4 HTML LAYOUT:

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.

14
0.7.1.1.1

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

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

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.

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.

14
5.5.3 THE ALTERNATIVE:

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

14
identically merged into various forms of the HTML layout, without explicitly

inserting duplicate sections of scriptlet logic (Java code).

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

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

14
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 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

14
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 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

14
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
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

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

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.

14
• 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.

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.

14
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
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

14
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
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

14
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:

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.

14
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:

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.

14
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

 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

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

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

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

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

14
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
5. Interaction diagrams
6. Sequence diagram
7. Collaboration diagram

14
CLASS DIAGRAM FOR PDS

Class diagram for Public Distribution system

<<Actor>>
<<boundary>> <<control>> customer
login login c trl
name
1 1 id
check weather() check validit y()
1
login()
<<Actor>> 1 payment()
<<entity>>
Admin 1 set complaints()
System
1 1
name 1
1
id 1
details of shops
1 & licence() 1 <<control>>
1 set complaints() set complaints
login() view complaints()
is sue licence() 1 <<control>>
view complaints() sales set complaints()
set suggestions() cid
1 pid
1 1
1 qty <<control>>
1 amt
<<Actor>> 1 card
<<control>> 1 bill no.
Dealer cid
licence
name sale() cname
lno addr
hold name id
1 1
hold addr new()
login()
issue card() 1 edit()
issue products() delete()
1 view()
<<control>> 1
1
Payment <<control>> 1
set sugges tions 1 <<control>>
bill no. <<control>> products
pdes bill submission pdid
smt set suggest ion()
cid pdname
billno. cost
show() 1
des of product
<<control>>
submit()
view complaint s

view complaints()

14
USE CASE DIAGRAM FOR PDS

USECASE DIAGRAM

Registere

login
PDS
submitbill

bell
paymentmonitor recvied product

14
USECASE DIAGRAM FOR ADMINISTARTOR

USECASE DIAGRAM

login

Billsubmission

Admin
Issuecard

submit Bill payment


licence product

sale

login

payment
customer

pds

check availabi...

14
USECASE DIAGRAM CUSTOMER

USECASE DIAGRAM

login

customer

billlpayment

purchase
check availabity
payment

14
COLLABORATION DIAGRAM ISSUE DIAGRAMS

c ollaboration diagram for Issue card

1:

: customer
: i-customer
: dealer
8: 3: 1.send request for card
5: 2.send request
4: 3.view request
: i-dealer 7:
4.send view request
5.process request
2:
6.get data
7.send customer details
8.process data & issue card
: cissue ctrl
9: : view ctrl 9.update

6:

: system1

14
SEQUENCE DIAGRAM FOR LOGIN

Sequenc e diagram for login

: user : i-reg : login ctrl : System

enter uid &pwd send id & pwd

validate details

ac cess the system

14
SEQUENCE DIAGRAM FOR ADMINISTRATOR

sequence diagram for Administrator

: Admin : i-A dmin : licence ctrl : view complaints : set suggestion : maintain db : Sy stem
enter
dealer data send dealer
data verify data &
issue
lic ence

update the system

req to view
complaints send req
display

enter
suggestions send suggestions

verify

update

14
SEQUENCE DIAGRAM FOR UPADTE STOCK SALES

SEQUENCE DAIGRAM

C:CUS
C:PUR...
P;PDU S:PDS
S

1 : \request products\

2 : \list product\

3 : \specify products\

4 : calculate payment

5 : \issueproducrs\ 6 : update stock,sales and paydb

7 : \recieve payment\

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.

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

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.

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

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.

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

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 Input ExpOutput ActOutput Desc


Case

Valid Uid,pwd, Success Success Test Passed. Control


login transferred to menu.
utype

Invalid Uid, pwd, Failed Failed Test Passed. Try again.


Login utype

14
Module: customer registration

Filename: CustReg.aspx

Test Case Input ExpOutput ActOutput Desc

Register new Customer Info. Save and Save and Test Passed.
Customer generate Cust. generate Cust. Customer
Id. Id. registered.

Register new Customer Info. Failed. Failed. Test Passed.


Customer Invalid Data.

Module: Shop id generation

Filename: Shop id generation.aspx

Test Case Input ExpOutput ActOutput Desc

Shop id sid Save and Save and Test Passed.


Generate sid Generate sid Generate sid

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


error.

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:-

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:-

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

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

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.

14

You might also like