Design and Develop an Environment to Analyse Object-Oriented Software and Quality Assurance Introduction with Literature Review 1 CHAPTER – 1 INTRODUCTION AND LITERATURE REVIEW 1.1 Foundation for Related System Generally, software development is an activity incorporating close amalgamation of various stages and interlinked processes which play an important role at every stage of development. Due to these problems, involving various issues, occur invariantly at different level, stifle and affect the development work. This leads to degradation of software quality and lowering of system performance. The issues dealing with software artifacts, Reengineering, System Design and software metrics play an important role in all these matters. In light of this, to overcome these difficulties at different stages, there is need of automated environment which will assess generated design artifacts from natural language as forward engineering and from source code as reengineering and finally suggest and validates alternate designs options for better quality assurance. Before getting into the crux of the research, it is mandatory to get a first hand brushing of the basic theory of the research work for creating a good base for understanding the various aspects, so as to able to probe the work in a planned and systematic manner for the desired outcomes. 1.1.1. The Fine Art of Analysis - Object Oriented Analysis (OOA) Analysis is concerned with devising a precise, concise, understandable model of the real world business. Object oriented analysis consist of identifying, extracting the needs of business and what system must do to satisfy the business requirements. This analysis is to understand the responsibilities of system and the interaction of user with the system. The immediate task is that the artifacts or elements (use cases, classes, relationships) that make up the system must be
40
Embed
INTRODUCTION AND LITERATURE REVIEWshodhganga.inflibnet.ac.in/bitstream/10603/14005/10/10_chapter 1.p… · Reengineering, System Design and software metrics play an important role
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Design and Develop an Environment to Analyse Object-Oriented Software and Quality Assurance Introduction with Literature Review
1
CHAPTER – 1
INTRODUCTION AND LITERATURE REVIEW
1.1 Foundation for Related System
Generally, software development is an activity incorporating close
amalgamation of various stages and interlinked processes which play an
important role at every stage of development. Due to these problems, involving
various issues, occur invariantly at different level, stifle and affect the
development work. This leads to degradation of software quality and lowering
of system performance. The issues dealing with software artifacts,
Reengineering, System Design and software metrics play an important role in all
these matters. In light of this, to overcome these difficulties at different stages,
there is need of automated environment which will assess generated design
artifacts from natural language as forward engineering and from source code as
reengineering and finally suggest and validates alternate designs options for
better quality assurance.
Before getting into the crux of the research, it is mandatory to get a first hand
brushing of the basic theory of the research work for creating a good base for
understanding the various aspects, so as to able to probe the work in a planned
and systematic manner for the desired outcomes.
1.1.1. The Fine Art of Analysis - Object Oriented Analysis (OOA)
Analysis is concerned with devising a precise, concise, understandable model of
the real world business. Object oriented analysis consist of identifying,
extracting the needs of business and what system must do to satisfy the business
requirements. This analysis is to understand the responsibilities of system and
the interaction of user with the system. The immediate task is that the artifacts or
elements (use cases, classes, relationships) that make up the system must be
Design and Develop an Environment to Analyse Object-Oriented Software and Quality Assurance
identified and their responsibilities and relationships among them. OOA
concentrate on the describing what system does? Rather than the how it does it?
This is accomplished by constructing the several models of the system from
fuzzy set of system description such as use case model and class model as
depicted in fig 1.1. The use case model describes the
or user’s needs. Another activity in the
subparts such as attributes, methods and relationships among them in the system
as stated by Ali ( 1999
1.1.2 The UML Use Case Model
According to Ali ( 1999
in a system whose task is to yield to result of measureable value to an individual
actor of the system”
set of use cases and the communication relationships between
cases. Generally, the model defines outside (Actor) and inside (Use Case) of
system’s behavior. The use case depicts a systemat
system. The actor, who is generally a user, plays a role in regards to the system.
The actor holds the key to findings the correct use cases. Actor carries out the
use cases. In the model an actor can be performing many use ca
versa. It must enable
The basic principle of use case diagram is that it enables us in capturing the
dynamic aspect of the system. This is a generic definition, which is not enough
to describe its basic purpose. The other drawings in the UML mainly activity,
sequence, collaboration and State chart moreover have the similar purpose. As a
to Analyse Oriented Software and Quality Assurance Introduction with Literature
identified and their responsibilities and relationships among them. OOA
concentrate on the describing what system does? Rather than the how it does it?
plished by constructing the several models of the system from
fuzzy set of system description such as use case model and class model as
1.1. The use case model describes the user’s view of the system
or user’s needs. Another activity in the OOA is to identify the classes and
subparts such as attributes, methods and relationships among them in the system
1999).
Fig. 1.1 Software Analysis Process
The UML Use Case Model
1999) “Use case model is nothing but a sequence of transition
in a system whose task is to yield to result of measureable value to an individual
actor of the system”. It is a graph or diagram representing actors along with a
set of use cases and the communication relationships between the units
cases. Generally, the model defines outside (Actor) and inside (Use Case) of
system’s behavior. The use case depicts a systematic flow of events within the
system. The actor, who is generally a user, plays a role in regards to the system.
The actor holds the key to findings the correct use cases. Actor carries out the
use cases. In the model an actor can be performing many use ca
must enable it to perform its task having some identifiable value.
The basic principle of use case diagram is that it enables us in capturing the
dynamic aspect of the system. This is a generic definition, which is not enough
ibe its basic purpose. The other drawings in the UML mainly activity,
sequence, collaboration and State chart moreover have the similar purpose. As a
Introduction with Literature Review
2
identified and their responsibilities and relationships among them. OOA
concentrate on the describing what system does? Rather than the how it does it?
plished by constructing the several models of the system from
fuzzy set of system description such as use case model and class model as
user’s view of the system
OOA is to identify the classes and
subparts such as attributes, methods and relationships among them in the system
nothing but a sequence of transition
in a system whose task is to yield to result of measureable value to an individual
graph or diagram representing actors along with a
the units and the
cases. Generally, the model defines outside (Actor) and inside (Use Case) of
ic flow of events within the
system. The actor, who is generally a user, plays a role in regards to the system.
The actor holds the key to findings the correct use cases. Actor carries out the
use cases. In the model an actor can be performing many use cases or vice-
to perform its task having some identifiable value.
The basic principle of use case diagram is that it enables us in capturing the
dynamic aspect of the system. This is a generic definition, which is not enough
ibe its basic purpose. The other drawings in the UML mainly activity,
sequence, collaboration and State chart moreover have the similar purpose. As a
Design and Develop an Environment to Analyse Object-Oriented Software and Quality Assurance Introduction with Literature Review
3
matter of fact, it needs to give some very specific targeted purpose, which will
enable us to distinguish it from the remaining diagrams. The use case diagrams,
generally gather the requirements of the system taking into account the inside
and outside control. The general requirements are more specifically design
requirements. Whenever the system is critically analyzed for gathering its
functionalities, the use cases are generated and actors identified.
The next task is modeling use case diagrams for presenting the outside view.
Hence, the use case diagrams can be used for the following purpose:
• For collecting requirements of the system.
• To get a snapshot of outside and inside view of the system.
• Helping in identifying factors both external and internal, which
influence the system.
• For depicting the interaction between the requirements and the end
user of the system.
The use case diagrams never demonstrate how they can be put into training. Use
case diagrams might be anticipated as a black box where only the input signal,
output and the use of the black box is known. These diagrams are utilized at an
elevated stage of design. This improved stage design is superior again and again
to acquire a reasonable and total picture of the system. The pre condition is also
described by a well planned use case, post state, exception conditions. When
executing, the screening of these additional fundamentals are used to produce
test cases. Exactly the same is accurate for reverse engineering. Still use case
diagram is employed otherwise to help it become a candidate for reverse
engineering.
In the field of forward engineering, the use case diagrams serve the purpose of
making test cases, while in reverse engineering it plays the role in preparing the
requirement details from an existing application. The use case diagrams are
mainly applicable in the following areas:
• For the purpose of getting the Requirement Analysis and elevated
stage design.
Design and Develop an Environment to Analyse Object-Oriented Software and Quality Assurance Introduction with Literature Review
4
• Help in modeling the system background.
• For the purpose of performing Reverse Engineering.
• Development using Forward Engineering.
1.1.3 Analysis Model : UML Class Model
It is considered as the main static analysis model. This model shows the static
structure of the system to be analyzed, as depicted in Ali Bahrami (1999). A
class model is nothing but the collection of the static modeling artifacts such as
classes and their relationships, and multiplicity among them connected as graph
to each other and to their contents. The class model core and mandatory element
is the classes and relationships among them. Among the other features, a class
can also constitute of sub artifacts as attributes, and methods. Such model
represents the mapping of objects in the real world to actual objects to be used in
computer program.
Usually, the class diagram represents a static diagram, consisting of the static
view of the system. Its purpose is not only for thinking about, recitation and
documenting of the diverse features of a system but it can also serve the purpose
of constructing executable code of the system. It mainly tells about the features
or attributes and operations performed by a class, but also the restrictions
imposed by it on the system. They are generally used for representation of
object oriented systems, as they are the specific UML diagrams which can be
directly decoded with the object oriented languages. The diagram depicts a
collected works of classes, interfaces, associations, collaborations and
constraints. With all the features discussed, this diagram is also represented as a
structural diagram of system at analysis and design level. The basic purpose of
the class diagram is representation of the stationary view of the system or the
object oriented applications. Because of this, they are the only diagrams which
serve the purpose of being very easily translated with the object oriented
languages. Due to this, they are extensively used during creation of object
oriented systems or applications.
Design and Develop an Environment to Analyse Object-Oriented Software and Quality Assurance Introduction with Literature Review
5
Thus, it is possible to summarize underlying principles behind the construction
of the class diagram:
• It helps in analysis and design of the still view of a system or an
application.
• It distinguishes responsibilities relating to all business entities in the
system.
• It lends support for the other diagrams, mainly the component and
deployment diagrams.
• In the process of Forward and reverse engineering.
Mainly, it is a static diagram used to model static view of the system being
developed. The purpose of the static view is to describe the use of vocabulary of
the system. They are considered as the major foundation for the component and
deployment diagrams. They help in visualizing the static view of the system. It
also plays a major role in constructing the executable code for forward and
reverse engineering of any system.
There has been a major drawback, basically the UML diagrams are not openly
translated with several existing object oriented programming languages. But
there is an exception in the form of the class diagram. The diagram showcases
the ability to translate with the existing object oriented languages like Java,
C++, Ada, small talk or .NET platform etc. Hence, it can be concluded that from
sensible knowledge class diagram can help and are generally used for erection
of system purpose. The diagrams are used for:
• Creating and understanding and also unfolding the static view of the
system or object oriented applications.
• Showing the association among the business elements within the system
of the static view.
• Showing and depicting the various functionalities performed by the
system.
• Generating Models of software applications using object oriented
languages.
Design and Develop an Environment to Analyse Object-Oriented Software and Quality Assurance Introduction with Literature Review
6
1.1.4 Understanding the Semantic Business Vocabulary and Rules (SBVR)
The OMG created SBVR in a bid to reduce the gap between Business analyst
and IT persons as mentioned in OMG, Semantics of Business vocabulary and
Rules (2008). This is an contemporary and better way of capturing the business
requirements in natural language like structure which is very simple,
understandable for human beings and easy to give machine for processing as it
is important order of basic foundation. One can generate a business model of the
system using the SBVR with the same communicative influence of standard
natural language. For this purpose, all specific expressions and definition of
facts are considered to be its main and useful vocabulary. In this a formal
presentation under the business influence are considered as rules which are used
in a way for expressing the operations performed of a particular business entity
under certain given conditions.
The main method of its principles is through the use of textual specifications
instead of some diagrams. One has to observe business concepts are they are
related, it perhaps good design for expressing rules and explaining language.
This theory may be shortened as follows: "Company guidelines are centered on
facts, and details are based on terms".
Following rules or “mantra”, it can define different fundamental elements like:
� A noun concept;
� A fact type;
� A business rule.
Business knowledge is organized by SBVR into lexical units. It has two models
defined within the lexical units and specs:
� Vocabulary for Describing Business Vocabularies, This lexical
part is defined to comprise "all the specific terms and meanings of
ideas that a specified firm or community uses in their speaking and
writing within the program of performing business"
� Vocabulary for Describing Business Rules, mainly it deals with
the lexical aspect for describing domain lexical unit and handles the
specs of the significance of domain rules.
Design and Develop an Environment to Analyse Object-Oriented Software and Quality Assurance Introduction with Literature Review
7
1.1.5 The Real SBVR – Unfolding the Myth
� It's about as well as for the company and never for information
program (IS). SBVR acknowledges specific knowledge that may be
used in developing methods for the system;
� It is company viewpoint, seldom the IS viewpoint;
� It utilizes terminology used by company people; it does not have a
research to any IS units and is sovereign of other IS design ;
� It is managed by people who are not IT folks. If needed but, IT
individuals can understand SBVR specifications too, consequently,
they might handle SBVR business vocabularies and business
guidelines.
1.1.6 The Role of Software Reverse Engineering (SRE)
Since it has a significant impact on the research work, it can be understood as
the procedure involving analyzing on the software system in a way to reveal or
identify the different system entities, components, feature, characteristics,
behavior and properties and their interrelationships and also construct the
representation of software system into an additional form or for the purpose of
higher level abstraction i.e. for creating design view of software system. Design
view contain information such as UML class diagram, source code information,
documentation etc. this design view information is mainly extracted from the
system source code and any existing documentation. In this process of
recovering a program`s design is rightly called as design recovery, which forms
an important element of software reverse engineering. The design is created by
information, documents and individual outcomes with the system and the area of
work knowledge.
Overall Software Reverse Engineering comprises activity that is performed to
find product behavior and to invent ideas and technology useful for product.
Software Reverse Engineering executes at many levels. SRE is an activity of
maintenance. SRE mainly deals with findings from the system system, complete
or in pieces and taking out design and execution details. For purpose of
Design and Develop an Environment to Analyse Object-Oriented Software and Quality Assurance Introduction with Literature Review
8
understanding, Software Reverse Engineering situation would generally be
Reverse engineering skills mainly identify and remove viruses and malware.
It has the abilities which were not common in programmer. It has been
performed to make established just what kinds of steps fall into its group an the
capabilities could possible to be trained to programmer and tester.
To aid deal with the scarce resource of SRE learning, several editorial and
articles on SRE, reengineering, reuse, care, advancement, and protection were
collected with the object of creating useful, workable exercises for teaching
purposes. The study exposed that SRE is quite nicely explained and the majority
of-the related measures fall into one of two groups: software development
related and security related. Practical reverse engineering exercises were made
with the aim of providing a standard education in treating Java byte code and
both Wintel machine code and Java byte code.
Fig. 1.2 Structure of Software Reverse Engineering
To have in-depth understanding, the following example of Software Reverse
Engineering can be considered
Requirements
Design
Source code
Behavior
Design and Develop an Environment to Analyse Object-Oriented Software and Quality Assurance Introduction with Literature Review
9
A class called Box defines three instant variables: width, height and depth.
The Box contains instant method: volume. Class Box represents as follows
Class Box
{
private double width;
public double height;
protected double depth;
public double volume;
}
After the class is reverse engineered, the class should be represented into design
view i.e. above class represents into UML class as follows
: Box
Attributes
� Width : Double
+ height : Double
# depth : Double
Method
+ volume() : Double
Therefore, extraction of design view from source code and existing
documentation of software system is called as software reverse engineering. It is
the primary or initial step of Software Reengineering which shows into fig. 1.3:
Structure of Software Reverse Engineering. It is main element of this thesis
which will explain into further chapter of this thesis. The basic purpose for using
Software Reverse Engineering is for:
� Getting the lost information and proper software documentation.
� Performing maintenance and identification of negative aspect.
� Shifting to another hardware or software platform.
� Making software reusable.
Design and Develop an Environment to Analyse Object-Oriented Software and Quality Assurance Introduction with Literature Review
10
The far reaching benefits of Software Reverse Engineering can be given as
� Maintenance cost savings
� Fewer efforts are required to reengineer the existing software system
with help of SRE because it is the first step or pre-step of Software
Reengineering process.
� SRE gives major improvements
� Getting ahead of Competition
� Making Software reusable
Limitations of Software Reverse Engineering
� There is void between the affected area and solution.
� Also void between firm and casual.
� void between coherency and disintegration
� void between hierarchical and associational
1.1.7 Moving Ahead with Forward Engineering
Forward Engineering is defined as the procedure of analyzing on the design
view of software system to reveal or identify or generate the source code of
software system along with entities, components, feature, characteristics,
behavior and properties of source code of software system and their
interrelationships and also build the representation of design view of software
system into another form or at a specification level i.e. generate source code of
software system directly.
This source code is generated from the design view of the software system and
any existing documentation. Hence it becomes mandatory to have an
understanding of the stages involved in this process.
Design and Develop an Environment to Analyse Object-Oriented Software and Quality Assurance Introduction with Literature Review
11
Fig. 1.3 Structure of Forward Engineering
Forward Engineering is opposite process of the Software Reverse Engineering
i.e. it will generate source code from the design view of software system which
shows into above fig 1.3: Structure of Forward Engineering.
The same example for Forward Engineering can be discussed for Software
Reverse Engineering..
Consider the UML class with an example. A UML class called Box that defines
three instant variables: width, height and depth along with their symbol. The
Box contains instant method: volume with symbol. Class Box represents as
follows
: Box
Attributes
� width : Double
+ height : Double
# depth : Double
Method
+ volume() : Double
Requirements
Design
Source code
Behavior
Design and Develop an Environment to Analyse Object-Oriented Software and Quality Assurance Introduction with Literature Review
12
After the Forward engineered of this above UML class, this class should be
represented into source code i.e. above class represents into source code as
simple java class as follows
Class Box
{
private double width;
public double height;
protected double depth;
public double volume;
}
Therefore generation of source code from design view and existing
documentation of software system is called as software Forward engineering. It
is next or subsequently step of Software Reengineering which shows into
fig.1.4: Basic structure of Software Reengineering. It is also main element of
Software Reengineering which will start after the completion of SRE step.
Fig. 1.4 Basic structure of Software Reengineering
Abstraction system
Old system New system
Software Reverse Engineering Abstraction
Forward Engineering Re-Implementation
Design and Develop an Environment to Analyse Object-Oriented Software and Quality Assurance Introduction with Literature Review
13
1.1.8 The Concept of Software Reengineering
Software Reengineering is not just requires including new performance or
creating a totally new system according to an initial system's specification using
forwards engineering methods. Software Reengineering appears from the needs
� It defines the lexical and rules for creating documents in the semantics of
business lexicals, business facts, and business rules; also XMI schema for the
interchange of business lexicals and business rules between organizations and
tools.
� In software modeling, it is refined way of taking need specifications in NLs
which is easy to read for human beings but simplifies machine process. SBVR
organization guidelines are straightforward to device procedure because of the
proper logic basis.
� Using SBVR, a shared domain model can be generated by one (based on
company vocabularies and rules). Both components of the standardized SBVR
portrayal are described under:
Design and Develop an Environment to Analyse Object-Oriented Software and Quality Assurance Introduction with Literature Review
36
SBVR Business Vocabulary
SBVR Business Vocabulary is the collection of business entities, their instances
and relationships between them, which can be used by any organization in their
writing and talking during the course of their business.
� Terms: These are the noun or group of words which can be collectively
used for the designation of a business entity. For example: “bank” or
“investment bank”
� Name: These are the words which are used to represent the instance of
a particular term. For Example: “SBI” which is an instance of bank.
� Fact Type: These are the sentences which represent the relationship
between terms.
The template term-verb-term is used to establish the relation between two terms,
as it is very obvious that a mutual relationship between 3 entities can be easily
broken down to maximum of 3 binary relations.
For example, the fact type “customer owns account is member” states that a
customer is related with account and account is related with member and a
person who owns an account will be a member. This relationship can be
breakdown to two relations as described by the two fact type like” customer
owns account” and “customer is member”.
There are five types of SBVR vocabulary:
� Object Type
� Individual Noun
� Verb Concept
� Characteristic: An abstraction of a property of an object.
� Fact Type
SBVR Business Rules
These are the sentences under business jurisdiction which guide the structure
and behavior of an organization. The rules guiding the structure are known as
Structural Rules and the rules guiding behavior are known as Operative Rules.
Design and Develop an Environment to Analyse Object-Oriented Software and Quality Assurance Introduction with Literature Review
37
The conventional rendering of the business entities construction or conduct
under a business authority is known as a SBVR business rule. It is commonly
shows the arrangement or functioning of a special business entity in-a given
business site. Each of the guideline relies on one or more fact kind.
The rules could be of two kinds:
� SBVR Structural Rule: These guidelines define an organizational setup
� SBVR Behavioral Rule: These guidelines are applied to conveying of
conduct
Major font styles are used for revealing business terms, fact types and business
rules Structured English:
Table 1.1 Font styling for the SBVR Structured English Keywords and Phrases for Logical Formulations
Font Description
term
The “term” font is used to represent object types (general concepts) and roles. Terms are defined in singular form using lower case letters. Examples: car, driver, loan, modal formulation, fact type etc.
Name
The “Name” font is used to represent individual concepts that usually are proper nouns. The first letter of a name is capitalized. One of the exceptions to the latter is the presentation of numerical values that are also shown in this style (e.g. 25).
verb
The “verb” font is used to represent a verb, a preposition, or a combination of these two. Verbs are used in singular active or passive forms – these two are used as synonymous forms. For example, for the active form of an associative fact type “driver drives car” there is a synonymous passive form “car is driven by driver”. Fact types, representing characteristics, are always used in passive form, e.g. “car is damaged”.
keyword
The “keyword” font represents linguistic symbols that are used to construct statements and definitions. Examples: each, It is obligatory that, greater than, “ ” etc.
Keywords and phrases are used to express logical formulations. The letters “n”
and “m” represent integers, and “p” and “q” – expressions of propositions.
Table 1.2 Keywords and Phrases for Logical Formulations
Quantification each at least one at least n at most one
1. Used with a general concept to make a reference to a previous use of the same concept; 2. Introduction of the name of an individual thing or of a definite description.
a, an Universal or existential quantification
that When used after a noun concept and before a fact type symbol, this keyword introduces some restriction on that noun concept.
not Used within an expression to introduce a logical negation.
� Seema Sharma, et al. (2011)
� Given Literature explains the drawbacks of JSD,SA/SD approaches. It
describes how GA can be used to optimize the Object Oriented Designs .It
also explains actual working of crossover operator.
� The extracted from this paper is how to generate initial population of
different string. It also guides to identify fitness function.
Design and Develop an Environment to Analyse Object-Oriented Software and Quality Assurance Introduction with Literature Review
39
� Stan Jarzabek (1993)
� Due to the paucity in the existing maintenance methods, previous programmes
fail in meeting the current strategic needs. It raises the one question can
developer reengineer program? or it re-implement from start point.
� Main objective of software reengineering is to enhance maintainability of
programmes and then upgrade to existing technology into a newer computer,
database or language.
� Thomas Panas, et al. (2010)
� VizzAnalyzer : The tool is a framework or environment that analyses and
visualizations a software system. It helps in coordinating engineering
activities like re-engineering.
���� Timothy M. Meyers and David Binkley (2007)
� Software reengineering can be a costly process because of the vagueness of
where one can concentrate reengineering effort. Cohesion and coupling
metrics are sophistication metrics out of which especially cohesion metrics
possess the possibility to measure improvement and to aid in identification.
The absolute expansive work on such metrics has been coherence metrics. It
uses information which makes them a great option for cohesion valuation.
� In future study, it ought to be raise the problem such as does a computer expert
might be able to access intricacy metric values related to program and do a
much better job of rewriting the program.
� Tom V. Mathew (2009)
� This paper gives details regarding Genetic Algorithm .It explains working
of GA by applying Its different operator such as selection, crossover,
mutation. It gives direction to use GA in computer science.
Design and Develop an Environment to Analyse Object-Oriented Software and Quality Assurance Introduction with Literature Review
40
� The concept in this paper helps a lot in proposed system, because it gives
basis to encode different classes in bit streams. And how different GA
operators can be used for to generate alternate designs.
1.3 Thesis Organization
The Thesis contains six chapters
Chapter 1 – This section gives overall idea and introduction about the research
work and title and also deals with the basics concepts need to understand the
thesis. It also covers the literature review.
Chapter 2 - This section discusses about the observations based on the literature
review, motivation, objectives, goals, principals and the propose framework to
be developed for the research work.
Chapter 3 – This section explain the various aspect of system analysis and
System modeling and design with the help of Unified Modeling Language
diagrams along with the planning and scheduling for the research work.
Chapter 4 – This section deals with the Step wise detail implementation of the
system along with the possible test cases is described in this section.
Chapter 5 – This section mainly deals with the integration of the three modules
in the proposed framework along with their execution details.
Chapter 6 – This section describes the results and observations of system to be
developed as well as results are compared with the existing system
Finally this thesis report based on the proposed research work ends with the