CHAPTER-3

SYSTEM DESIGN

3.1 Introduction

Software design sits at the technical kernel of software engineering and is

applied regardless of the software process model that is used. Beginning once
software requirements have been analyzed and specified, software design is the first
of three technical activities-design, code generation, and test –that are required to
build and verify the software. Each activity transforms information in a manner that
ultimately results in validated computer software.
Design is a meaningful engineering representation of something that is to be
built. Software design is a process through which the requirements are translated into
a representation of the software. During design we make decisions that will ultimately
affect the success of software construction and, as important, the ease with which
software can be maintained. The importance of software design can be stated with a
single word-quality. Design is the place where quality is fostered in software
engineering.
Design provides us with representations of software that can be assessed for
quality. Design is the only way that we can accurately translate a customer’s
requirements into a finished software product or system.
Software design serves as the foundation for all the software engineering and software
support steps that follow. Without design we risk building an unstable system-one that
fail when small changes are made ;one that may be difficult to test; one whose quality
cannot be accessed until late in the software process, when time is short and many
dollars have already been spent.
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.

1. User Model View

 This view represents the system from the users perspective.
 The analysis representation describes a usage scenario from the end-users
perspective.
2. Structural model view
 In this model the data and functionality are arrived from inside
the system.
 This model view models the static structures.
3. 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.
4. Implementation Model View
 In this the structural and behavioral as parts of the system are represented as they
are to be built.
5. 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:

1. UML Analysis modeling, this focuses on the user model and structural model
views of the system.
2. UML design modeling, which focuses on the behavioral modeling,
implementation modeling and environmental model views.
 3.2 Design Principles

Basic design principles enable the software engineer to navigate the design process.
Davis suggest a set of principles for software design, which have been adapted and
extended in the following list:
 The design process should not suffer from “tunnel vision”. A good
designer should consider alternative approaches, judging each based on the
requirements of the problem, the resources available to do the job.
 The design should be traceable to the analysis model. Because a single
element of the design model often traces to multiple requirements, it is necessary to
have a means for tracking how requirements have been satisfied by the design model.
 The design should not reinvent the wheel. Systems are constructed using a
set of design patterns, many of which have likely been encountered before. These
patterns should always be chosen as an alternative to reinvention. Time is short and
resources are limited! Design time should be invested in representing truly new ideas
and integrating those patterns that already exist.
 The design should “minimize the intellectual distance” between the
software and the problem as it exists in the real world. That is, the structure of the
software design should mimic the structure of the problem domain.
 The design should exhibit uniformity and integration. A design is uniform
if it appears that one person developed the entire thing. Rules of style and format
should be defined for a design team before design work begins. A design is integrated
if care is taken in defining interfaces between design components.
 The design should be structured to accommodate change. The design
concepts enable a design to achieve this principle.
 The design should be structured to degrade gently, even when aberrant
data, events, or operating conditions are encountered. Well-designed software
should never “bomb”. It should be designed to accommodate unusual circumstances,
and if it must terminate processing, do so in a graceful manner.
 Design is not coding, coding is not design. Even when detailed procedural
designs are created for program components, the level of abstraction of the design
model id higher than source code. The only design decisions made at the coding level
address the small implementation details that enable the procedural design to be
coded.
 The design should be assessed for quality as it is being created, not after
the fact. A variety of design concepts and measures are available to assist the
designer in assessing quality.
 The design should be reviewed to minimize conceptual errors. There is
sometimes a tendency to focus on minutiae when the design is reviewed, missing the
forest for the trees. A design team should ensure that major conceptual elements of
the design have been addressed before worrying about the syntax of the design model.
When these design principles are properly applied, the software engineer creates a
design that exhibits both external and internal quality factors. External quality factors
are those properties of the software that can be readily observed by users. Internal
quality factors are of importance to software engineers.

3.3 DESIGN METHODOLOGY

The purpose of the design phase is to plan a solution of the problem specified
by the requirement document. This phase is the first step in moving from problem
domain to the solution domain. The design of a system is perhaps the most critical
factor affecting the quality of the software, and has a major impact on the later phases,
particularly testing and maintenance. The output of this phase is the design document.
This document is similar to a blue print or plan for the solution, and is used later
during implementation, testing and maintenance.

The design activity is often divided into two separate phase-system design and
detailed design. System design, which is sometimes also called top-level design, aims
to identify the modules that should be in the system, the specifications of these
modules, and how they interact with each other to produce the desired results. At the
end of system design all the major data structures, file formats, output formats, as well
as the major modules in the system and their specifications are decided.
 During detailed design the internal logic of each of the modules specified in
system design is decided. During this phase further details of the data structures and
algorithmic design of each of the modules is specified. The logic of a module is
usually specified in a high-level design description language, which is independent of
the target language in which the software will eventually be implemented. In system
design the focus is on identifying the modules, whereas during detailed design the
focus is on designing the logic for each of the modules. In other words, in system
design the attention is on what components are needed, while in detailed design how
the components can be implemented in software is the issue.

3.3.1 Software Development Life Cycle

This document play a vital role in the development of life cycle (SDLC) as it
describes the complete requirement of the system. It means for use by developers and
will be the basic during testing phase. Any changes made to the requirements in the
future will have to go through formal change approval process.

The trends of increasing technical complexity of the systems, coupled with the
need for repeatable and predictable process methodologies, have driven System
Developers to establish system development models or software development life
cycle models.

Nearly three decades ago the operations in an organization used to be limited

and so it was possible to maintain those using manual procedures. But with the
growing operations of organizations, the need to automate the various activities
increased, since for manual procedures it was becoming very difficult, slow and
complicated. Like maintaining records for a thousand plus employees company on
papers is definitely a cumbersome job. So, at that time more and more companies
started going for automation.

Since there were a lot of organizations, which were opting for automation, it
was felt that some standard and structural procedure or methodology be introduced in
the industry so that the transition from manual to automated system became easy. The
concept of system life cycle came into existence then. Life cycle model emphasized
on the need to follow some structured approach towards building new or improved
system. There were many models suggested. System development begins with the
recognition of user needs. Then there is a preliminary investigation stage. It includes
evaluation of present system, information gathering, feasibility study, and request
approval. Feasibility study includes technical, economic, legal and operational
feasibility. In economic feasibility cost-benefit analysis is done. After that, there are
detailed design, implementation, testing and maintenance stages.

In this session, we'll be learning about various stages that make system's life
cycle. In addition, different life cycles models will be discussed. These include
Waterfall model, Prototype model, Object-Oriented Model, spiral model and Dynamic
Systems Development Method (DSDM).

3.3.2 Spiral Model

SPIRAL MODEL was defined by Barry Boehm in his 1988 article, “A spiral
Model of Software Development and Enhancement. This model was not the first
model to discuss iterative development, but it was the first model to explain why the
iteration models.

As originally envisioned, the iterations were typically 6 months to 2 years

long. Each phase starts with a design goal and ends with a client reviewing the
progress thus far. Analysis and engineering efforts are applied at each phase of the
project, with an eye toward the end goal of the project.

The steps for Spiral Model can be generalized as follows:

 A preliminary design is created for the new system.

  A first prototype of the new system is constructed from the preliminary
design. This is usually a scaled-down system, and represents an
approximation of the characteristics of the final product.
 A second prototype is evolved by a fourfold procedure:
 Evaluating the first prototype in terms of its strengths,
weakness, and risks.
 Defining the requirements of the second prototype.
 Planning an designing the second prototype.
 Constructing and testing the second prototype.
The preceding steps are iterated until the customer is satisfied that the refined
prototype represents the final product desired.

The following figure 3.3.2.1 shows how a spiral model acts like:
 Figure 3.3.2.1

3.3.3 Advantages of Spiral Model

 Estimates(i.e., budget, schedule etc .) become more relistic as work

progresses, because important issues discoved earlier.
  It is more able to cope with the changes that are software development
generally entails.

 Software engineers can get their hands in and start woring on the core of a
project earlier.

3.3.4 Spiral Model Description

The development spiral consists of four quadrants as shown in the figure

above.

Quadrant 1: Determine objectives, alternatives, and constraints.

Quadrant 2: Evaluate alternatives, identify, and resolve risks.

Quadrant 3: Develop, verify, next-level product.

Quadrant 4: Plan next phases.

Although the spiral, as depicted, is oriented toward software development, the

concept is equally applicable to systems, hardware, and training, for example. To
better understand the scope of each spiral development quadrant, let’s briefly address
each one.

Quadrant 1: Determine Objectives, Alternatives, and Constraints

Activities performed in this quadrant include:

1. Establish an understanding of the system or product objectives—namely

performance, functionality, and ability to accommodate change.

2. Investigate implementation alternatives—namely design, reuse, procure, and

procure/ modify

3. Investigate constraints imposed on the alternatives—namely technology, cost,

schedule, support, and risk. Once the system or product’s objectives,
alternatives, and constraints are understood, Quadrant 2 (Evaluate alternatives,
identify, and resolve risks) is performed.
Quadrant 2: Evaluate Alternatives, Identify, Resolve Risks

Engineering activities performed in this quadrant select an alternative

approach that best satisfies technical, technology, cost, schedule, support, and risk
constraints. The focus here is on risk mitigation. Each alternative is investigated and
prototyped to reduce the risk associated with the development decisions. Boehm
describes these activities as follows:

This may involve prototyping, simulation, benchmarking, reference checking,

administering user questionnaires, analytic modeling, or combinations of these and
other risk resolution techniques. The outcome of the evaluation determines the next
course of action. If critical operational and/or technical issues (COIs/CTIs) such as
performance and interoperability (i.e., external and internal) risks remain, more
detailed prototyping may need to be added before progressing to the next quadrant.
Dr. Boehm notes that if the alternative chosen is “operationally useful and robust
enough to serve as a low-risk base for future product evolution, the subsequent risk-
driven steps would be the evolving series of evolutionary prototypes going toward the
right (hand side of the graphic) the option of writing specifications would be
addressed but not exercised.” This brings us to Quadrant 3.

Quadrant 3: Develop, Verify, Next-Level Product

If a determination is made that the previous prototyping efforts have resolved

the COIs/CTIs, activities to develop, verify, next-level product are performed. As a
result, the basic “waterfall” approach may be employed—meaning concept of
operations, design, development, integration, and test of the next system or product
iteration. If appropriate, incremental development approaches may also be applicable.

Quadrant 4: Plan Next Phases

The spiral development model has one characteristic that is common to all
models—the need for advanced technical planning and multidisciplinary reviews at
critical staging or control points. Each cycle of the model culminates with a technical
review that assesses the status, progress, maturity, merits, risk, of development efforts
to date; resolves critical operational and/or technical issues (COIs/CTIs); and reviews
plans and identifies COIs/CTIs to be resolved for the next iteration of the spiral.

Subsequent implementations of the spiral may involve lower level spirals that
follow the same quadrant paths and decision considerations.

3.4 DFD and UML Diagrams

3.4 DFD/ERD/UML DIAGRAMS

3.4.1 DATA FLOW DIAGRAM

A graphical tool used to describe and analyze the moment of data through a
system manual or automated including the process, stores of data, and delays in the
system. Data Flow Diagrams are the central tool and the basis from which other
components are developed. The DFD is also known as a data flow graph or a bubble
chart. The Basic Notation used to create a DFD’s are as follows:

i) Dataflow: Data move in a specific direction from an origin to a destination.

ii) Process: People, procedures, or devices that use or produce (Transform) Data. The
physical component is not identified.

iii) Source: External sources or destination of data, which may be People, programs,
organizations or other entities.
iv) Data Store: Here data are stored or referenced by a process in the System.

3.4.1 .1 Architecture of Path-Diversity P2P Overlay Retransmission

for Reliable IP-Multicast

The architecture of the proposed Path-Diversity P2P Overlay Retransmission

for Reliable IP-Multicast is shown in below fig:3.1 in which arrow symbols
represents the flow of data from one module to another module .It recognize the lost
packets while transferring the data from one peer to another peer. It will retransmit
the lost packets to the destination peer.
 Fig: 3.1 Architecture of Path-Diversity P2P Overlay Retransmission
for Reliable IP-Multicast

3.4.2 UML Diagrams:

The Unified Modeling language allows software engineer to express

an analysis model using the modeling notation that is governed by 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.
3.4.2.1 An Overview of UML
The UML is a language for
 Visualizing
 Specifying
 Constructing
 Documenting
3.4.2.2 Relationships in the UML
The word “Notation” in UML refers to set of symbols which are used
to represent a system .These symbols play a vital role in defining a system. Based on
these notations, UML defines the four relationships.
 Dependency

 Association

 Generalization
 Realization
a)Dependency:
The relationship “Dependency” between two entities refers to position
where changes caused to one entity may have its effect on other entity. The
dependency relationship is represented as,

As seen from the figure a dashed arrow proceeding in one direction represents the
dependency symbol.

b)Association
A structural relationship that shows a connection among objects is
called as an “Association”. It is represented as,

c)Generalization
Generalization is termed as “Specialized Relationship”. In this
relationship, the objects of one entity can be substituted with the objects of another
entity. The entity whose objects are substituted is known as parent entity and the
entity, which is providing objects for replacement, is known as child entity. It is
represented as,
 d)Realization
Realization is a relationship between classifiers in which one classifier lays
down a contract and another classifier guarantees to carry out this contract.

3.4.2.3 Diagrams in the UML

 Structural Diagrams:
The Structural Diagrams are four types. They are as follows.
 Class diagrams
 Component Diagrams
 Deployment Diagrams
a) Class Diagrams
Class diagrams are the most common diagrams found in modeling object-oriented
systems. A

class diagram shows a set of classes, interfaces, and collaborations and their
relationships.

Graphically, a class diagram is a collection of vertices and arcs. The class diagram of
the

Flexible Rollback Recovery in Dynamic Heterogeneous Grid Computing is shown in

Fig: 3.2.

Contents
Class Diagrams commonly contain the following things
Classes
Interfaces
Collaborations
Dependency, generalization and association relationships
 b) Component Diagrams
A component is the physical implementation of classes and collaborations.
Architecture of a system can be explained with its components. Therefore a
component is the basic building block of a system. These diagrams can be achieved
by modeling various physical components like libraries, tables, and files etc. which
are residing internal to given node.
Contents
Components
Interfaces
Relationships
c) Deployment Diagrams
The deployment diagrams indicate the processing elements, processes,
software components. The static deployment view of a system in terms of different
components, processes can be modeled by deployment diagrams.

A deployment diagram contains-nodes and relationships (dependency and

association). This diagram is used to know which components will run on which
nodes (with the stereo type<<supports>>) similarly the migration of components will
be represented by the stereo type<<becomes>>.
Contents
Nodes
Relationships
 Behavioral Diagrams:
The behavioral Diagrams are four types. They are as follows.
 Use case diagrams
 Sequence diagrams
 Collaboration diagrams
 Activity diagrams and
 State Chart diagrams
a) Use Case Diagrams
Use Case diagrams are one of the five diagrams in the UML for modeling the
dynamic aspects of systems (activity diagrams, sequence diagrams, state chart
diagrams and collaboration diagrams are the four other kinds of diagrams in the UML
 for modeling the dynamic aspects of systems). Use Case diagrams are central to
modeling the behavior of the system, a sub-system, or a class. Each one shows a set of
use cases and actors and relationships. The use case diagram for Flexible Rollback
Recovery in Dynamic Heterogeneous Grid Computing the is shown in fig 3.5
Common Properties
A Use Case diagram is just a special kind of diagram and shares the same
common properties, as do all other diagrams- a name and graphical contents that are a
projection into the model. What distinguishes a use case diagram from all other kinds
of diagrams is its particular content.

Contents
Use Case diagrams commonly contain:
 Use Cases
 Actors
 Dependency, generalization, and association relationships
Like all other diagrams, use case diagrams may contain notes and constraints. Use
Case diagrams may also contain packages, which are used to group elements of your
model into larger chunks. Occasionally, you will want to place instances of use cases
in your diagrams, as well, especially when you want to visualize a specific executing
system..
b) Sequence Diagrams
A sequence diagram is an interaction diagram that emphasizes the time
ordering of the messages. Graphically, a sequence diagram is a table that shows
objects arranged along the X-axis and messages, ordered in increasing time, along the
Y-axis.
Typically you place the object that initiates the interaction at the left, and
increasingly more sub-routine objects to the right. Next, you place the messages that
these objects send and receive along the Y-axis, in order of increasing time from top
to the bottom. This gives the reader a clear visual cue to the flow of control over time.
Sequence diagrams have two interesting features

There is the object lifeline. An object lifeline is the vertical dashed line that
represents the existence of an object over a period of time. Most objects that appear in
the interaction diagrams will be in existence for the duration of the interaction, so
these objects are all aligned at the top of the diagram, with their lifelines drawn from
the top of the diagram to the bottom.
There is a focus of the control. The focus of control is tall, thin rectangle that
shows the period of time during which an object is performing an action, either
directly or through the subordinate procedure. The top of the rectangle is aligns with
the action; the bottom is aligned with its completion. The sequence diagram for the
Flexible Rollback Recovery in Dynamic Heterogeneous Grid Computing is shown in
fig 3.3
c) Collaboration Diagram:

The collaboration diagram represents a collaboration, which is a set of objects

related in a particular context, and interaction, which is a set of messages exchanged
among the objects within the collaboration to achieve a designed Outcome. The
Collaboration Diagram for Flexible Rollback Recovery in Dynamic Heterogeneous
Grid Computing is shown in fig 3.4.

d) Activity Diagram:

The purpose of activity diagram is to provide a view of flows and what is

going on inside a use case or among several classes. Activity diagram can also be

used to represent a class’s method implementation. A token represents an operation.

An activity is shown as a round box containing the name of the operation. An

outgoing solid arrow attached to the end of activity symbol indicates a transition

triggered by the completion. The Activity Diagram for Flexible Rollback Recovery in

Dynamic Heterogeneous Grid Computing in fig 3.6

e) State Chart Diagram:

A state chart diagram shows a state machine. State chart diagrams are used to
model the dynamic aspects of the system. For the most part this involves modeling the
behavior of the reactive objects.
 A reactive object is one whose behavior is best characterized by its response to
events dispatched from outside its context. A reactive object has a clear lifeline whose
current behavior is affected by its past.
A state chart diagram show a state machine emphasizing the flow of control
from state to state. A state machine is a behavior that specifies the sequence of states
an object goes through during its life time in response to events together with its
response to those events.
A state is a condition in the life of the object during which it satisfies some
conditions, performs some activity or wait for some events. An event is a
specification of a significant occurrence that has a location in time and space.
Graphically a state chart diagram is a collection of vertices and arcs. State chart
diagram commonly contain, Simple states and Composite states, transitions, including
events and actions.
Class Diagram:
UML Class diagram shows the static structure of the model. The class
diagram is a collection of static modeling elements, such as classes
and their relationships, connected as a graph to each other and to
their contents
Use Case Diagram:
A use case diagram is a graph of actors, a set of use cases enclosed by a
system boundary, communication (participation) associations between the actors and
users and generalization among use cases. The use case model defines the outside
(actors) and inside (use case) of the system’s behavior.

Execute No.of nodes

Enter the Distance

Update Network

Enter the Destination

Find possible paths

Node

Find Node disjoint path

Pactorization

Send

Possible Retransmit

Sequence Diagram:
Sequence diagram are an easy and intuitive way of describing the behavior Of a
system by viewing the interaction between the system and its environment. A
Sequence diagram shows an interaction arranged in a time sequence. A sequence
diagram has two dimensions: vertical dimension represents time; the horizontal
Dimension represents different objects. The vertical line is called is the object’s life
line. The lifeline represents the object’s existence during the interaction

Node Update Network Destination Path Discovery Node Disjoint Pactorization Send Retransmit

1 : distance()

2 : enter the dstination()

3 : find available paths()

4 : find node disjoint path()

5 : paths()

6 : select Data file()

7 : pactorize()
8 : packets()

9 : possible retransmit()

Collaboration Diagram:
The collaboration diagram represents a collaboration, which is a set of objects
Related in a particular context, and interaction, which is a set of messages exchanged
among the objects within the collaboration to achieve a designed Outcome.
 Send

5 : paths()

Node Disjoint
8 : packets()
7 : pactorize()
4 : find node disjoint path()

Pactorization
Path Discovery

Retransmit

3 : find available paths()

6 : select Data file()
Update Network
9 : possible retransmit()

1 : distance()
Destination

2 : enter the dstination()

Node

Activity Diagram:
The purpose of activity diagram is to provide a view of flows and what is going on
inside a use case or among several classes. Activity diagram can also be used to
represent a class’s method implementation. A token represents an operation. An
activity is shown as a round box containing the name of the operation. An outgoing
solid arrow attached to the end of activity symbol indicates a transition triggered by
the completion.
Deployment Diagram

Deployment diagram indicates the processing elements, process, and software

components. The static deployment view of a system in terms of different
components, processes can be modeled by deployment diagram.
 Enter the no.of nodes

Ente theDestination
UpdateNetwork
Enterthediistance

Find Possible paths

FindNode disjointpath

Packetization

send

Possible retransmit
 CHAPTER-4

IMPLEMENTATION

4.1 Introduction
A programming tool or software tool is a program or application that software
developers use to create, debug, maintain, or otherwise support other programs and
applications. The term usually refers to relatively simple programs that can be
combined together to accomplish a task. The Chapter describes about the software
tool that is used in our project.

Java Technology

Initially the language was called as “oak” but it was renamed as “Java” in
1995. The primary motivation of this language was the need for a platform-
independent (i.e., architecture neutral) language that could be used to create software
to be embedded in various consumer electronic devices.

 Java is a programmer’s language.

 Java is cohesive and consistent.
 Except for those constraints imposed by the Internet environment, Java
gives the programmer, full control.
 Finally, Java is to Internet programming where C was to system
programming.
Importance of Java to the Internet

Java has had a profound effect on the Internet. This is because; Java expands
the Universe of objects that can move about freely in Cyberspace. In a network, two
categories of objects are transmitted between the Server and the Personal computer.
They are: Passive information and Dynamic active programs. The Dynamic, Self-
executing programs cause serious problems in the areas of Security and probability.
But, Java addresses those concerns and by doing so, has opened the door to an
exciting new form of program called the Applet.

Java can be used to create two types of programs

Applications and Applets : An application is a program that runs on our

Computer under the operating system of that computer. It is more or less like one
creating using C or C++. Java’s ability to create Applets makes it important. An
Applet is an application designed to be transmitted over the Internet and executed by a
Java –compatible web browser. An applet is actually a tiny Java program,
dynamically downloaded across the network, just like an image. But the difference is,
it is an intelligent program, not just a media file. It can react to the user input and
dynamically change.

Features of Java Security

Every time you that you download a “normal” program, you are risking a viral
infection. Prior to Java, most users did not download executable programs frequently,
and those who did scan them for viruses prior to execution. Most users still worried
about the possibility of infecting their systems with a virus. In addition, another type
of malicious program exists that must be guarded against. This type of program can
gather private information, such as credit card numbers, bank account balances, and
passwords. Java answers both these concerns by providing a “firewall” between a
network application and your computer. When you use a Java-compatible Web
browser, you can safely download Java applets without fear of virus infection or
malicious intent.

Portability

For programs to be dynamically downloaded to all the various types of

platforms connected to the Internet, some means of generating portable executable
code is needed .As you will see, the same mechanism that helps ensure security also
helps create portability. Indeed, Java’s solution to these two problems is both elegant
and efficient.

The Byte code

The key that allows the Java to solve the security and portability problems is
that the output of Java compiler is Byte code. Byte code is a highly optimized set of
instructions designed to be executed by the Java run-time system, which is called the
Java Virtual Machine (JVM). That is, in its standard form, the JVM is an interpreter
for byte code.

Translating a Java program into byte code helps makes it much easier to run a
program in a wide variety of environments. The reason is, once the run-time package
exists for a given system, any Java program can run on it.

Although Java was designed for interpretation, there is technically nothing

about Java that prevents on-the-fly compilation of byte code into native code. Sun has
just completed its Just In Time (JIT) compiler for byte code. When the JIT compiler is
a part of JVM, it compiles byte code into executable code in real time, on a piece-by-
piece, demand basis. It is not possible to compile an entire Java program into
executable code all at once, because Java performs various run-time checks that can
be done only at run time. The JIT compiles code, as it is needed, during execution.

Java Virtual Machine (JVM)

Beyond the language, there is the Java virtual machine. The Java virtual
machine is an important element of the Java technology. The virtual machine can be
embedded within a web browser or an operating system. Once a piece of Java code is
loaded onto a machine, it is verified. As part of the loading process, a class loader is
invoked and does byte code verification makes sure that the code that’s has been
generated by the compiler will not corrupt the machine that it’s loaded on.

Byte code verification takes place at the end of the compilation process to
make sure that is all accurate and correct. So byte code verification is integral to the
compiling and executing of Java code.
 Java Source Java byte code JavaVM

Java .Class

Fig: 4.1 Development process of JAVA

Java programming uses to produce byte codes and executes them. The first
box indicates that the Java source code is located in a. Java file that is processed with
a Java compiler called javac. The Java compiler produces a file called a. class file,
which contains the byte code. The .Class file is then loaded across the network or
loaded locally on your machine into the execution environment is the Java virtual
machine, which interprets and executes the byte code.

Java Architecture
Java architecture provides a portable, robust, high performing environment for
development. Java provides portability by compiling the byte codes for the Java
Virtual Machine, which is then interpreted on each platform by the run-time
environment. Java is a dynamic system, able to load code when needed from a
machine in the same room or across the planet.
Compilation of code
When you compile the code, the Java compiler creates machine code (called
byte code) for a hypothetical machine called Java Virtual Machine (JVM). The JVM
is supposed to execute the byte code. The JVM is created for overcoming the issue of
portability. The code is written and compiled for one machine and interpreted on all
machines. This machine is called Java Virtual Machine.
Compiling and interpreting Java Source Code
During run-time the Java interpreter tricks the byte code file into thinking that
it is running on a Java Virtual Machine. In reality this could be a Intel Pentium
Windows 95 or SunSARC station running Solaris or Apple Macintosh running system
and all could receive code from any computer through Internet and run the Applets.

PC Compiler Java

Source Interpreter

Code Java

Java
Interpreter
………..
Interpreter
 Java
Macintosh
Byte code
compiler
Independent

SPARC

Compiler

Fig: 4.2 Compiling and Interpreting Java Source code

Simple

Java was designed to be easy for the Professional programmer to learn and to
use effectively. If you are an experienced C++ programmer, learning Java will be
even easier. Because Java inherits the C/C++ syntax and many of the object oriented
features of C++. Most of the confusing concepts from C++ are either left out of Java
or implemented in a cleaner, more approachable manner. In Java there are a small
number of clearly defined ways to accomplish a given task.
Object-Oriented

Java was not designed to be source-code compatible with any other language.
This allowed the Java team the freedom to design with a blank slate. One outcome of
this was a clean usable, pragmatic approach to objects. The object model in Java is
simple and easy to extend, while simple types, such as integers, are kept as high-
performance non-objects.

Robust
The multi-platform environment of the Web places extraordinary demands on
a program, because the program must execute reliably in a variety of systems. The
ability to create robust programs was given a high priority in the design of Java. Java
is strictly typed language; it checks your code at compile time and run time.
Java virtually eliminates the problems of memory management and de-
allocation, which is completely automatic. In a well-written Java program, all run
time errors can –and should –be managed by your program.
4.2 Overview of Implementation Language
Java Swing
 Swing is a widget toolkit for java. The main characteristics of the Swing
toolkit are platform independent, customizable, extensible, configurable and
lightweight. It has a rich set of widgets. From basic widgets like Buttons, Labels,
Scrollbars to advanced widgets like Trees and Tables.

Swing is a part of JFC, Java Foundation Classes. It is a collection of packages for

creating full featured desktop applications. JFC consists of AWT, Swing,
Accessibility, Java 2D, and Drag and Drop.
JComponent

All Swing components whose names begin with "J" descend from the
jcomponent API class. For example, JPanel, JScrollPane, JButton, and JTable all
inherit from JComponent. However, JFrame doesn't because it implements a top-level
container. The JComponent class extends the Container API class, which itself
extends Component API. The Component class includes everything from providing
layout hints to supporting painting and events. The Container class has support for
adding components to the container and laying them out.

JPanel

The JPanel class provides general-purpose containers for lightweight

components. By default, panels do not add colors to anything except their own
background; however, you can easily add borders to them and otherwise customize
their painting.

JFrame

JFrame is Swing's version of Frame and is descended directly from that class. It
is used to create Windows in a Swing program. The components added to the frame
are referred to as its contents; these are managed by the content Pane. To add a
component to a JFrame, we must use its content Pane instead.

JButton
 The JButton object generally consists of a text label and/or image icon that
describes the purpose of the button, an empty area around the text/icon and border.

JLabel

JLabel, descended from JComponent, is used to create text labels. It can

display text but images as well.

JTextArea

JTextArea component is used to accept several lines of text from user.

JTextArea can be used in conjunction with class JScrollPane to achieve scrolling. The
underlying JScrollPane can be forced to always or never have either the vertical or
horizontal scrollbar.

JList

JList provides a scrollable set of items from which one or more may be
selected. JList can be populated from an Array or Vector. JList does not support
scrolling directly, instead, the list must be associated with a scrollpane. The view port
used by the scroll pane can also have a user-defined border. JList actions are handled
using ListSelectionListener.

The Swing Message Box

Windowing environments commonly contain a standard set of message boxes
that allow you to quickly post information to the user or to capture information from
the user. In Swing, these message boxes are contained in JOptionPane sophisticated),
but the ones most commonly used are probably the message dialog and confirmation
dialog, invoked using the static JOptionPane.showMessageDialog( ) and
JOptionPane.showConfirmDialog( ).

Package Javax.Imageio Description

The main package of the Java Image I/O API. Many common image I/O
operations may be performed using the static methods of the ImageIO class. This
package contains the basic classes and interfaces for describing the contents of image
files, including metadata and thumbnails (IIOImage); for controlling the image reading
process (ImageReader, ImageReadParam, and ImageTypeSpecifier) and image writing process
 (ImageWriter and ImageWriteParam); for performing transcoding between formats
(ImageTranscoder), and for reporting errors (IIOException).
JFileChooser

File choosers provide a GUI for navigating the file system, and then either
choosing a file or directory from a list, or entering the name of a file or directory. To
display a file chooser, you usually use the JFileChooser API to show a modal dialog
containing the file chooser. A JFileChooser is a dialog to select a file or files.

The return value of the three methods is one of the following:

1. JFileChooser.CANCEL_OPTION, if the user clicks Cancel.
2. JFileChooser.APPROVE_OPTION, if the users click an OK/Open/Save
button.
3. JFileChooser.ERROR_OPTION, if the user closes the dialog

A return value of JFileChooser.APPROVE_OPTION, indicates that you can call

its getSelectedFile or getSelectedFiles methods:

public java.io.File getSelectedFile ()
public java.io.File[] getSelectedFiles ()
    

JFileChooser has supporting classes: FileFilter class, FileSystemView class, FileView.

FileFilter class is for restricting files and directories to be listed in the
FileView of the JFileChooser. The FileView controls how the directories and files are
listed within the JFileChooser. The FileSystemView is an abstract class that tries to
hide file system-related operating system specifics from the file chooser.

JScrollPane

JScrollPane is a jQuery plugin which allows you to replace the browsers

default vertical scrollbars on any block level element with an overflow: auto style.
JScrollPane is crossbrowser, working on all browsers that support jquery and it also
degrades gracefully. If a user's browser doesn't support jQuery or has JavaScript
turned off then they will see the browsers default scrollbars. If the mouse wheel
 plugin is included in the page then the scroll panes will respond to mouse wheel
events as well. JScrollPane is built on top of the awesome jQuery library and utilises
the dimensions plugin and (optionally) the mouse wheel plugin.
To place a component in one of the corners of the JScrollPane, call setCorner
(String key, Component corner) key is
1. JScrollPane.LOWER_LEFT_CORNER,
2. JScrollPane.LOWER_RIGHT_CORNER,
3. JScrollPane.UPPER_LEFT_CORNER, or
4. JScrollPane.UPPER_RIGHT_CORNER

Class BufferedImage
java.lang.Object
java.awt.Image
java.awt.image.BufferedImage

All Implemented Interfaces:

RenderedImage, WritableRenderedImage

public class BufferedImage

extends Image

implements WritableRenderedImage

The BufferedImage subclass describes an Image with an accessible buffer of

image data. A BufferedImage is comprised of a ColorModel and a Raster of image data.
The number and types of bands in the SampleModel of the Raster must match the number
and types required by the ColorModel to represent its color and alpha components. All
BufferedImage objects have an upper left corner coordinate of (0, 0). Any Raster used to
construct a BufferedImage must therefore have minX=0 and minY=0.

JCreator
 JCreator is a powerful IDE for java. JCreator is the best development tool for
programming. It is faster, more efficient and more reliable than other IDE’s.
Therefore it is the perfect tool for programmers of every level, from learning
programmer to Java-specialist.
JCreator provides the user with a wide range of functionality such as Project
management, project templates, code-completion, debugger interface, editor with
syntax highlighting, wizards and a fully customizable user interface
With JCreator you can directly compile or run your Java program without
activating the main document first. JCreator will automatically find the file with the
main method or the html file holding the java applet, and then it will start the
appropriate tool.
JCreator is written entirely in C++, which makes it fast and efficient
compared to the Java based editors/IDE.
Java Database Connectivity

What Is JDBC?

JDBC is a Java API for executing SQL statements. (As a point of interest,
JDBC is a trademarked name and is not an acronym; nevertheless, JDBC is often
thought of as standing for Java Database Connectivity. It consists of a set of classes
and interfaces written in the Java programming language. JDBC provides a standard
API for tool/database developers and makes it possible to write database applications
using a pure Java API.

Using JDBC, it is easy to send SQL statements to virtually any relational

database. One can write a single program using the JDBC API, and the program will
be able to send SQL statements to the appropriate database. The combinations of Java
and JDBC lets a programmer write it once and run it anywhere.

What Does JDBC Do?

Simply put, JDBC makes it possible to do three things:

 Establish a connection with a database
 Send SQL statements
 Process the results.
 JDBC versus ODBC and other APIs

At this point, Microsoft's ODBC (Open Database Connectivity) API is that

probably the most widely used programming interface for accessing relational
databases. It offers the ability to connect to almost all databases on almost all
platforms.

So why not just use ODBC from Java? The answer is that you can use ODBC
from Java, but this is best done with the help of JDBC in the form of the JDBC-
ODBC Bridge, which we will cover shortly. The question now becomes "Why do you
need JDBC?" There are several answers to this question:

1. ODBC is not appropriate for direct use from Java because it uses a C interface.
Calls from Java to native C code have a number of drawbacks in the security,
implementation, robustness, and automatic portability of applications.
2. A literal translation of the ODBC API into a Java API would not be desirable.
For example, Java has no pointers, and ODBC makes copious use of them, including
the notoriously error-prone generic pointer "void *". You can think of JDBC as
ODBC translated into an object-oriented interface that is natural for Java
programmers.
3. ODBC is hard to learn. It mixes simple and advanced features together, and it
has complex options even for simple queries. JDBC, on the other hand, was designed
to keep simple things simple while allowing more advanced capabilities where
required.
4. A Java API like JDBC is needed in order to enable a "pure Java" solution.
When ODBC is used, the ODBC driver manager and drivers must be manually
installed on every client machine. When the JDBC driver is written completely in
Java, however, JDBC code is automatically installable, portable, and secure on all
Java platforms from network computers to mainframes.
Two-tier and Three-tier Models

The JDBC API supports both two-tier and three-tier models for database
access.
In the two-tier model, a Java applet or application talks directly to the
database. This requires a JDBC driver that can communicate with the particular
database management system being accessed. A user's SQL statements are delivered
to the database, and the results of those statements are sent back to the user. The
database may be located on another machine to which the user is connected via a
network. This is referred to as a client/server configuration, with the user's machine as
the client, and the machine housing the database as the server. The network can be an
Intranet, which, for example, connects employees within a corporation, or it can be
the Internet.

JAVA
Application Client machine

JDBC
DBMS-proprietary protocol

DBMS Database server

Fig: 4.3 Two-Tier Architecture of JDBC

In the three-tier model, commands are sent to a "middle tier" of services,

which then send SQL statements to the database. The database processes the SQL
statements and sends the results back to the middle tier, which then sends them to the
user. MIS directors find the three-tier model very attractive because the middle tier
makes it possible to maintain control over access and the kinds of updates that can be
made to corporate data. Another advantage is that when there is a middle tier, the user
can employ an easy-to-use higher-level API which is translated by the middle tier into
the appropriate low-level calls. Finally, in many cases the three-tier architecture can
provide performance advantages.

Java applet or
Html browser Client machine (GUI)

HTTP, RMI, or CORBA calls

Application
Server (Java)
Server machine (business Logic)
JDBC
DBMS-proprietary protocol

Database server

DBMS

Fig: 4.4 Three-Tier Architecture of JDBC

Until now the middle tier has typically been written in languages such as C or
C++, which offer fast performance. However, with the introduction of optimizing
compilers that translate Java byte code into efficient machine-specific code, it is
becoming practical to implement the middle tier in Java. This is a big plus, making it
possible to take advantage of Java's robustness, multithreading, and security features.
JDBC is important to allow database access from a Java middle tier.
 Fig: 4.5 Data Base Specific API’s

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
 Native-API partly-Java driver
 JDBC-Net pure Java driver
 Native-protocol pure Java driver
JDBC-ODBC Bridge

If possible, use a Pure Java JDBC driver instead of the Bridge and an ODBC
driver. This completely eliminates the client configuration required by ODBC. It also
eliminates the potential that the Java VM could be corrupted by an error in the native
code brought in by the Bridge (that is, the Bridge native library, the ODBC driver
manager library, the ODBC driver library, and the database client library).

What Is the JDBC- ODBC Bridge?

The JDBC-ODBC Bridge is a JDBC driver, which implements JDBC
operations by translating them into ODBC operations. To ODBC it appears as a
normal application program. The Bridge implements JDBC for any database for
 which an ODBC driver is available. The Bridge is implemented as the Sun.jdbc.odbc
Java package and contains a native library used to access ODBC. The Bridge is a joint
development of Innersole and Java Soft.
JDBC connectivity
The JDBC provides database-independent connectivity between the J2EE
platform and a wide range of tabular data sources. JDBC technology allows an
Application Component Provider to:

 Perform connection and authentication to a database server

 Manager transactions
 Move SQL statements to a database engine for preprocessing and
execution
 Execute stored procedures
 Inspect and modify the results from Select statements

4.3 Overview of implementation Database:

A database management system (DBMS) is computer software designed for

the purpose of managing databases, a large set of structured data, and run operations
on the data requested by numerous users. Typical examples of DBMSs include
Oracle, DB2, Microsoft Access, Microsoft SQL Server, Firebird, PostgreSQL,
MySQL, SQLite, FileMaker and Sybase Adaptive Server Enterprise. DBMSs are
typically used by Database administrators in the creation of Database systems.
Typical examples of DBMS use include accounting, human resources and customer
support systems.

Originally found only in large companies with the computer hardware needed
to support large data sets, DBMSs have more recently emerged as a fairly standard
part of any company back office.

Description
 A DBMS is a complex set of software programs that controls the organization,
storage, management, and retrieval of data in a database. A DBMS includes:

 A modeling language to define the schema of each database hosted in the DBMS,
according to the DBMS data model.
 The four most common types of organizations are the hierarchical, network, relational
and object models. Inverted lists and other methods are also used. A given database
management system may provide one or more of the four models. The optimal
structure depends on the natural organization of the application's data, and on the
application's requirements (which include transaction rate (speed), reliability,
maintainability, scalability, and cost).
 The dominant model in use today is the ad hoc one embedded in SQL, despite the
objections of purists who believe this model is a corruption of the relational model,
since it violates several of its fundamental principles for the sake of practicality and
performance. Many DBMSs also support the Open Database Connectivity API that
supports a standard way for programmers to access the DBMS.
 Data structures (fields, records, files and objects) optimized to deal with very large
amounts of data stored on a permanent data storage device (which implies relatively
slow access compared to volatile main memory).

 A database query language and report writer to allow users to interactively interrogate
the database, analyze its data and update it according to the users privileges on data.
 It also controls the security of the database.
 Data security prevents unauthorized users from viewing or updating the database.
Using passwords, users are allowed access to the entire database or subsets of it called
subschemas. For example, an employee database can contain all the data about an
individual employee, but one group of users may be authorized to view only payroll
data, while others are allowed access to only work history and medical data.
 If the DBMS provides a way to interactively enter and update the database, as well as
interrogate it, this capability allows for managing personal databases. However, it
may not leave an audit trail of actions or provide the kinds of controls necessary in a
multi-user organization. These controls are only available when a set of application
programs are customized for each data entry and updating function.
 A transaction mechanism, that ideally would guarantee the ACID properties, in order
to ensure data integrity, despite concurrent user accesses (concurrency control), and
faults (fault tolerance).
 It also maintains the integrity of the data in the database.
 The DBMS can maintain the integrity of the database by not allowing more than one
user to update the same record at the same time. The DBMS can help prevent
duplicate records via unique index constraints; for example, no two customers with
the same customer numbers (key fields) can be entered into the database. See ACID
properties for more information (Redundancy avoidance).

The DBMS accepts requests for data from the application program and
instructs the operating system to transfer the appropriate data.

When a DBMS is used, information systems can be changed much more easily
as the organization's information requirements change. New categories of data can be
added to the database without disruption to the existing system.

Organizations may use one kind of DBMS for daily transaction processing and
then move the detail onto another computer that uses another DBMS better suited for
random inquiries and analysis. Overall systems design decisions are performed by
data administrators and systems analysts.

Detailed database design is performed by database administrators. Database

servers are specially designed computers that hold the actual databases and run only
the DBMS and related software. Database servers are usually multiprocessor
computers, with RAID disk arrays used for stable storage. Connected to one or more
servers via a high-speed channel, hardware database accelerators are also used in
large volume transaction processing environments.
 DBMSs are found at the heart of most database applications. Sometimes
DBMSs are built around a private multitasking kernel with built-in networking
support although nowadays these functions are left to the operating system. Structured
Query Language (SQL) is the language used to manipulate relational databases. SQL
is tied very closely with the relational model.

In the relational model, data is stored in structures called relations or tables.

SQL statements are issued for the purpose of:

Data definition: Defining tables and structures in the database (DDL used to create,
alter and drop schema objects such as tables and indexes).

Data manipulation: Used to manipulate the data within those schema objects (DML
Inserting, Updating, Deleting the data, and Querying the Database).

A schema is a collection of database objects that can include: tables, views, indexes
and sequences

List of SQL statements that can be issued against an Oracle database schema are:

 ALTER - Change an existing table, view or index definition (DDL)

 AUDIT - Track the changes made to a table (DDL)
 COMMENT - Add a comment to a table or column in a table (DDL)
 COMMIT - Make all recent changes permanent (DML - transactional)
 CREATE - Create new database objects such as tables or views (DDL)
 DELETE - Delete rows from a database table (DML)
 DROP - Drop a database object such as a table, view or index (DDL)
 GRANT - Allow another user to access database objects such as tables or views
(DDL)
 INSERT - Insert new data into a database table (DML)
 No AUDIT - Turn off the auditing function (DDL)
 REVOKE - Disallow a user access to database objects such as tables and views
(DDL)
 ROLLBACK - Undo any recent changes to the database (DML - Transactional)
 SELECT - Retrieve data from a database table (DML)
 TRUNCATE - Delete all rows from a database table (can not be rolled back) (DML)
 UPDATE - Change the values of some data items in a database table (DML)
 CHAPTER-5

TESTING

5.1 INTRODUCTION

Software Testing:

Software testing is a critical element of software quality assurance and

represents the ultimate reuse of specification. Design and code testing represents
interesting anomaly for the software during earlier definition and development phase,
it was attempted to build software from an abstract concept to tangible
implementation.

The testing phase involves, testing of the development of the system using
various techniques such as White Box Testing, Control Structure Testing.

5.2 Testing Fundamentals

5.2.1. White Box & Black Box Testing

White Box Testing:

White box testing is a test case design method that uses the control
structure of the procedural design to derive test cases. After performing white
box testing it was identified that

 The Leave Recording System (LRS) software guarantees that all independent
paths within the modules have been exercised at least once.
 It has been exercised all logical decisions on their true and false sides.
 It was tested to execute all loops at their boundaries and within their
Operational bounds.
 It was tested for the internal data structures to ensure their validity.

Black box Testing:

It is the testing process in which tester can perform testing on an application

without having any internal structural knowledge of application.

Usually Test Engineers are involved in the black box testing.

5.2.2. Control Structure Testing

The following tests were conducted and it was noted that the BCBS is
performing them well.

 Basic path Testing

 Condition Testing
 Data Flow Testing
 Loop Testing
Black box testing methods focuses on the functional requirements of the
software by conducting black box testing using the methods Equivalence partitioning
Boundary Value Analysis and Cause-Effect-Graphing techniques.

 Functional validity of LRS checked.

 Checked the isolation of the boundaries of a class.
 The tolerance of the system for the data rates and data volumes.
5.3 Testing Strategy

A strategy for software testing must accommodate low-level tests that are
necessary to verify that a small source code segment has been correctly implemented
as well as high level against customer requirements.

Verification and Validation:

Verification is a Fundamental concept in the software design. Verification

refers to the set of activities that ensure that software correctly implements a specific
 function. Validation refers to a different set of activities that ensures that software that
has been build is a traceable to customers. Validation is nothing but the process of
using software in live environment in order to find errors.

Verification is typically done in two steps:

 Verification of the requirements: Verification that the software requirement

definition satisfies the customer needs.
 Verification of the design: Verification that the design satisfies the
requirements definition.
Verification and validation encompass a wide array of software quality
assurances (SQA) activities that include formal technical reuse quality and
configuration audits, performance monitoring, simulation, feasible study. Software
reviews are one of the most important SQA activities.

Reviews serve as a filter for the software process, removing errors while they are
relatively inexpensive to find and correct properly verify a system data about software
engineering process should be collected, evaluated and disseminated. SQA helps to
improve the quality of the product and software process itself.

 Code Testing
 Specification Testing
 Unit Testing
 Integration Testing
 System Testing
 Output Testing
 User Acceptance Testing
Code Testing:

Testing the logic of the program is called the code testing. Every path through
the program is tested and checked whether the logic is working properly or not. This
project was logically performing well.

Specification Testing:
 Specification testing means checking means checking the software it is as per
the specification given this project has tested for its specification such as what the
particular module or program should do and how it should perform under various
conditions.

Unit Testing:

Unit testing focuses verification on the smaller unit of software design such as
form. This is known as form testing. The testing is done individually on each form.
Using the unit test plan, prepared in design phase of the system development as a
guide important control paths are tested to uncover within the boundary of the
module. In this step, the module is working satisfactorily as a regard to the expected
output from the module.

Integration Testing:

Data can be lost across an interface, one module can have an adverse effect on
another sub function, when combined, may not produce the desired major function.
Integration testing is a systematic technique for constructing the program structure
while at the same time conducting tests to uncover errors associated with the
interface. All the modules are combined in the testing step. Then the entire program is
as a whole. Different integrated test plans like top down integration and bottom up
integration are tested and different errors found in the system are corrected using
them. Finally, all the combined modules are performed well.

Validation Testing:

The following tests were conducted to test the validity of the software. The
validation succeeds when the software functions in a manner that can be reasonably
expected by the customer. The developed software undergoes the following types of
validation testing and was succeeded.

 Alpha Testing
 Beta Testing
 System Testing:

Testing the entire system as a whole and checking for its correctness is system
testing. The system is listed for dispensaries between the system and its original
objectives. This project was effective and efficient.

Output Testing:

After performing system testing, the next step is output testing of the proposed
system, since no system could be useful if it does not procedure the desired output in
the specified format. The outputs generated are displayed by the system under

consideration or testing by asking the users about the format required by them, here
the output format is considered in two ways, one is the screen and other is the printed
form.

User Acceptance Testing:

User acceptance of a system is the key factor for the success of any system.
The system under consideration was tested for user acceptance by constantly keeping
in touch with the perspective system users at the time of developing and making
changes whenever required. The following are the testing points.

 Input screen design

 Output screen design
 Menu-driven system
5.4 Sample Test Cases

Template for Test Case

T.C.No Description Expected value Actual value Result

Table 5.1 Template for Test case

 Guidelines for Test Cases:

GUI Test Cases:

 Total no of features that need to be check

 Look & Feel
 Look for Default values if at all any (date & Time, if at all any require)
 Look for spell check
Example for Gui Test cases:

T.C.No Description Expected value Actual value Result

Check for all the The screen must contain all

features in the the features
1
screen

Check for the The alignment should be in

alignment of the proper way
2
objects as per the
validations

Table 5.2 Examples for Gui Test cases

1. Positive Test cases:

 The positive flow of the functionality must be considered
 Valid inputs must be used for testing
 Must have the positive perception to verify whether the requirements are
justified.

Example for Positive Test cases:

T.C.No Description Expected value Actual value Result

1 Check for the date Time The date and time of The date and time of Success
Auto Display the system must be the system must be
displayed displayed

2 Enter the valid paybillid It should accept It should accept Success

into the pay bill No field

Table 5.3 Example for Positive Test cases

2. Negative Test cases:

 Must have negative perception.

 Invalid inputs must be used for test.
Example for Negative Test cases:

T.C.No Description Expected value Actual value Result

1 Try to modify The Modification Modification failure

information in date and should not be should not be
time allow allow

2 Enter invalid data in to the It should not It should not failure

Mobile operators form, accept invalid accept invalid
click on save data, save data, save should
should not allow not allow
 Table 5.4 Example for Negative Test cases

5.5 MAINTENANCE ISSUES

The term “software maintenance” is used to describe the software

engineering activities that occur following delivery of a software product to the
customer. The maintenance phase of the software life cycle is the time period in
which a software product performs useful work.

In this project deals adaptive maintenance. Adaptive of software to a new

environment may involve moving the software to a different machine. Problem
correction involves modification and revalidation of software to correct errors.

The enhancement of this project can be accomplished easily. That is, any new
functional capabilities can be added to the project by simply including the new
module in the homepage and giving a hyperlink to that module. Adaptation of this
project to a new environment is also performed easily.

Adaptive Maintenance

Adaptive maintenance results in the modification to the software to accommodate

changes to its external environment. In this project, dynamically we can add new
components when ever necessary. Such as it designed to accommodate the new
change in further. Adaptation of this software to a new environment may involve
moving the software to a different machine. Such as Windows 2000, Windows NT,
Windows 98, Windows 95.
 CHAPTER-6

CONCLUSION AND FUTURE WORK

Conclusion
We introduce novel path-diversity overlay retransmission architecture for IP-
multicast based multimedia applications. The readily available network utility
function “Tracert” is used to help identify the path disjoint retransmission nodes, and
periodic probing is employed to adaptively and more accurately identify an overall
good retransmission node. A hybrid approach that exploits both has been shown to
achieve the best retransmission performance. Furthermore, to save the probing
overhead, the receiver can use selective probing to probe only a subset of the
candidate retransmission nodes who have the highest probability to be a good
candidate.

Future Work
1. As future work, a heuristic approach to combine all mapping and adaptation
approaches according to historic data, multimedia characteristics and traffic
patterns will be investigated. Moreover, QoE2M will be evaluated based on
simulation and experimental experiments.
2. Future work will include more quantitative evaluation of the impact of the
proposed framework on the perceived quality of the multimedia applications
in both simulation and real networks.
3. The next step will be to study the interaction between several traffic flows
sharing the same link and having the same, or different, network behaviour –
elastic or inelastic. These realistic conditions will help us generalize the
conclusions we have drawn so far for separate applications. We also plan to
extend our area of interest to other network applications, such as web
browsing, video streaming and teleconferencing, for which UPQ is of
considerable importance.