Designing Satellite Data Processing Software Systems using Object-

Oriented Technology
Amit Gupta, Nitant Dubey, Devakanth Naidu, P Neethinathan,
T P Srinivasan, B Gopala Krishna, R Nandakumar and P K Srivastava
ISRO, Space Applications Centre, Ahmedabad - 380 015
{amit, nitant, devakanth, neethi, tps, bgk, pradeep}@ipdpg.gov.in
Keywords: image data processing software, object-oriented technology, software engineering

Abstract 1. Introduction

Use of high-resolution space-borne imagery in Use of high-resolution satellite imagery in cartography is

cartography is becoming increasingly popular. Space-
borne imagery must be pre-processed for rectifying
radiometric and geometric distortions using sophisticated
mathematical models. These models must be applied in
the form of software. The software for satellite data
processing is inherently complex and needs to be reused
across the different satellite missions. Moreover, the
software components should be pluggable in commercial
software packages so as to enable the development and
use of effective cartographic applications.
This paper highlights the relationship of cartography and
object-oriented software engineering. More importantly,
this paper presents a methodology framework for
designing satellite data processing software systems
using object-oriented technology based on our practical
experience. Additionally, an introduction to various
fundamental object-oriented concepts has also been
included for better understanding of proposed
methodology framework.
Overview
1. Introduction
1.1 Relationship between Cartography and Software
Engineering
1.2 Rationale for adopting Object-Oriented
technology
2. Object-Oriented Concepts
2.1 Objects
2.2 Attributes & Operations
2.3 Class
2.4 Data Abstraction
2.5 Message Passing
2.6 Encapsulation
2.7 Inheritance
2.8 Polymorphism
2.9 Unified Modeling language (UML)
3. Proposed Methodology Framework for Designing
Satellite Data Processing Software
3.1 Guidelines for Software Modeling
4. A Report on Practical Experience with usage of
Object-Oriented Technology
5. Conclusions
6. Acknowledgments
7. Bibliography
becoming increasingly popular as a consequence of
launching advanced remote-sensing satellites with
progressively higher resolutions such as Cartosat series
of remote sensing satellites to be launched in near future.
Keeping the objective of digital cartography using high-
resolution space-borne imagery in mind, our heavy
dependence on the advanced, high quality, reliable &
reusable computer hardware & software is
unquestionable. Computer hardware industry has
constantly demonstrated its capability to yield highly
sophisticated products at lower costs & thus has made
the use of computers affordable to a general mass.
To make effective use of computers for satisfying the
needs of highly advanced technologies like Digital
Cartography using satellite imagery along with other
information, an equal demand on the sophistication of
software is absolutely essential.
1.1 Relationship between Cartography and Software
Engineering: It is obvious that when a technology such
as Cartography or GIS adds value to the better living style
of general mass, the demand for more software solutions
is exponentially high. Thus, it becomes mandatory to
design technological systems that can provide high
quality solutions at progressively lower costs & turn-
around times.
One way to satisfy such needs of Cartography is the use
of high-resolution space-borne imagery from advanced
remote-sensing satellites. Future remote-sensing satellites
(such as Cartosat series) dedicated for cartographic
applications will provide rapid and repetitive images of
the earth, thus strengthening the practical use of
Cartography towards contribution to country’s
development.
It is clearly evident that satellite imagery is inevitably
prone to radiometric & geometric distortions at raw level.
Consequently, there is a need to evolve mathematical
models for correction processing before the imagery is
disseminated for its end-use in mapping. Furthermore,
there is a stringent need for uninterrupted R & Ds for
continuously improving these mathematical models to
yield progressively better solutions. These mathematical
models, in turn, have to be applied in the form of
computer softwares. Moreover, software so made, need
to be reused in conjunction with commercial-of-the shelf

Indian Cartographer, 2002 DAPI-09 49

(COTS) software components for the ultimate objective of
mapping.
It would not be difficult to appreciate that the software is
the back-bone of scientific R & Ds relating to the choice of
suitable mathematical photogrammetric models required
for geometric correction of satellite imagery and for
generating data products of cartographic quality. It turns
out that the software has to be developed systematically
rather than haphazardly. That is where the object-oriented
software engineering comes into focus.
Thus, it becomes clear that Software Engineering has an
equal role to play in conjunction with other disciplines
such as Physics, Mathematics and Image Processing. If
not given due consideration to Software Engineering, it
may result in severe problems even if the state-of-the-art
mathematical models are in place.
1.2 Rationale for adopting Object-Oriented
Technology: The operational satellite data products
generation software for its end-use in cartographic
mapping requires fulfillment of the following objectives:
1. High Quality & Reliability
2. Short development & maintenance times
3. Reusability across the different satellite missions
4. Extensibility for incorporating new requirements
(such as new and improved mathematical
models)
5. Inter-operability with commercial software
packages such as ERDAS-Imagine, thus
requiring Component-based software architec-
tures.
The software industry’s general experience as well as our
own experience concerning satellite data products
software confirms that use of object-oriented technology
results in smooth fulfillment of the above-mentioned
objectives. This is made possible due to real-world
modeling philosophy employed by object-oriented
technology.
One may argue that traditional procedure-oriented
software development approach could be used for
developing software systematically. It was true during
1970-80s while conventional approach demonstrated
significant advantages over haphazard way of developing
software.
In the modern era, the procedure-oriented approach is
subject to the following concerns:
• Can user requirements be easily translated into
software?
• Can the software be extended easily to include
new features?
• Requirements change rapidly as a consequence
of various reasons including technological
advances. Can this approach incorporate
changes without much rework & side effects?
50 DAPI-09
• Can the users and / or domain-experts be
involved during the development to validate the
software and highlight any defects early in the
development life cycle?
• Can the software be reused significantly across
the projects to avoid duplication of efforts?
The answer to all the above-mentioned questions is
no in the context of procedure-oriented software
development approach. One major reason is its
emphasis on functions rather than data (or con-
cepts).
The object-oriented approach to software develop-
ment resolves many problems that are encountered
in conventional approach. The O-O approach stems
from the need to create systems that are not only
easy to develop and maintain but also easy to
extend.
We know that concepts are much more stable than
functions. The object-oriented (O-O) technology
exploits this fact fruitfully. The object-oriented
approach advocates the principle that “objects are
responsible for their own actions” as opposed to
procedure-oriented approach that emphasizes
“perform actions on data”.
The salient features of the promising O-O technology
for designing remarkable scientific software systems
can be summarized as follows:
1. Real world modeling i.e. software objects /
components directly models their real-world
counterparts. In other words, there is a one-to-
one relationship between real-world physical /
abstract concept and software unit.
2. Primary focus is on data rather than functions
while decomposing a complex software system
into simpler objects (building blocks or units)
3. Suitable for evolutionary development process
model, i. e. Object-oriented software is devel-
oped in an iterative and incremental manner.
4. Incorporation of changes and new requirements
is easy and efficient resulting in maintainability
goal.
5. Involvement of software engineers, domain-
experts, managers and end-users throughout
the software development life cycle enabling the
quality to be built at the source itself.
6. High profiles of reusability leading to the
development of reliable software systems at
lower costs andrapid turn-around times.
2. Object-Oriented Concepts
Object-Oriented approach to software development
handles the increased complexity of the software by
incorporating the best of structured programming
Indian Cartographer, 2002
features along-with powerful object-oriented concepts.
Using this new paradigm, it is possible to model systems
in terms that match human thinking and language.
Before proposing a methodology for designing satellite
data processing software systems, it is worthwhile to
review the meaning of important object-oriented
concepts.
2.1 Objects: We all live in a world of objects (entities) that
communicate and collaborate to accomplish certain
goals. Some examples of entities are instances of
Cartographer, Scientist, Engineer, Computer, Map, Image,
Imaging Sensor, Tree, River, Road, DEM etc. From Object-
Oriented Programming (OOP) point of view, objects are
the software representation of real-world entities that are
required for the operation of a system. An object may also
represent abstract concepts such as instances of vector,
matrix, time and file etc.
An object-oriented software solution analyses the
problem in terms of objects, their behavior (i.e. services
or operations offered), and the nature of communication
among these objects. Program objects should be chosen
such that they match closely with the real-world objects.
2.2 Attributes & Operations: Real-world objects can be
described in terms of their characteristics and behavior.
To capture the features of real-world entities; software
objects are defined in terms of their attributes (i.e.
characteristics) and operations (i.e. behavior) that operate
on these attributes. For example, an object
‘AhmedabadImage’ can have attributes such as
no_of_rows, no_of_columns, no_of_gray_levels and two-
dimensional array of gray values etc. and operations
such as ReadFromFile(), WriteToFile(),
ComputeHistogram(), Enhance(),
ComputeFastFourierTransform() etc.. Operations are also
referred to as ‘functions’, ‘services’, or ‘methods’.
2.3 Class: Objects that are similar to one-another in terms
of their attributes and functions (i.e. operations) can be
grouped in a class. From OOP point of view, a class
defines the attributes and functions that apply to all the
objects of that class. For example, a class ‘satellite’
defines all the attributes and operations that are common
to its objects (such as “IRS-1C”, “IRS-1D”, “Cartosat-1”
etc.)
Another example of a class is ‘C/C++’ language data
type int. The data type ‘int’ is a class of integers.
Consider the following example:
int m, n;
Here ‘int’ is a class and m & n are objects of ‘int’ class.
From programming point of view, a class serves as a
‘user-defined’ data type, which contains data and
functions that manipulate data in a single unit of code.
Objects can be defined by declaring them as variables of
this class.
Please note that we will use the terms “class” and
Indian Cartographer, 2002
“object” interchangeably as the distinction is not
significant for our further discussion.
2.4 Data Abstraction: Abstraction refers to the act of
representing essential features without including
extraneous features such as background details or
explanations. Classes use the concept of data abstraction
and are defined as a list of abstract attributes and
functions to operate on these attributes. A class may not
contain details such as how and when the values for its
attributes were gathered.
2.5 Message Passing: Objects communicate with one-
another by sending and receiving information much the
same way as people pass messages to one-another. The
concept of message passing makes it easier to talk about
building systems that directly model or simulate their real-
world counterparts.
A message for an object is a request for execution of a
function and, therefore, will invoke a function (operation)
in the receiving object that generates the desired result.
Message passing involves specifying the name of the
object, the name of the function, and the information to
be passed to the function.
The following three OO (Object-Oriented) concepts make
the OO approach distinct from classical approaches of
software development.
2.6 Encapsulation: The wrapping up of data and
functions into a single unit (called class) is known as
encapsulation. Encapsulation doesn’t allow the data to be
accessed by the outside world. Only those functions,
which are wrapped in the class, can access the data.
These functions provide the interface between the
object’s data and the user of the object. This insulation of
the data from direct access by the program is called data
hiding, a desirable property of a good software.
2.7 Inheritance: It is not unusual in Object-Oriented
Programming (OOP) that one class can have attributes
and operations that may also be common to some other
class. To avoid redefinition of these attributes and
operations, OO approach offers a mechanism called
inheritance, a process by which objects of one class
acquire the properties of objects of some other class.
In fact, inheritance is a common phenomenon of the real-
world. A child inherits physical and intellectual
characteristics of his / her parents. In the same way, a
class at a lower level in the hierarchy inherits attributes
and operations from the class (or classes) at an upper
level (or levels). In other words, a class at a particular
level contains its own characteristics in addition to some
other characteristics from other class (or classes).
Inheritance promotes the idea of reusability.
2.8 Polymorphism: Polymorphism means the ability to
take more than one form. It means an operation may
exhibit different behavior in different instances. The
behavior depends upon the type of object(s) used in the
DAPI-09 51
operation. For example, consider the operation of
addition. For two numbers, the operation will generate a
sum. If the operands are strings, the operation would
produce a third string by concatenation. This is
something similar to a particular word having more than
one meaning depending on the context.
2.9 Unified Modeling Language (UML): The UML is a
standard modeling language for software- a language for
visualizing, specifying, constructing and documenting the
artifacts of a software-intensive system. Basically, the UML
enables the developers to visualize their work products in
standardized blue-prints or diagrams. Consequently, it
becomes easier to communicate across different teams,
thus making software-outsourcing task more practical.
The UML diagrams describe the system from different
viewpoints. These include use-case diagram, package
diagram, class diagram, collaboration diagram, sequence
diagram, state transition diagram, activity diagram etc.
3. Proposed Methodology Framework for
Designing Satellite Data Processing Software
In the context of scientific software systems, we propose
to treat this revolutionary software technology as concept-
oriented software development approach. This essentially
means that software is analyzed and designed in such a
way that it can be thought of as an integrated system of
independent entities technically known as objects (or
classes). These objects (or components at higher level of
abstraction) model real-world concepts (generally
appearing as nouns in the literature pertaining to the
problem domain).
In our practice of OO technology we have found the
following set of major activities fruitful in designing
effective scientific software:
• PHYSICAL MODELING: Understanding and
describing the phenomenon and underlying
concepts. This generally requires grasping the
physics behind the phenomenon using usual
scientific methods.
• MATHEMATICAL MODELING: Deriving math-
ematical representation of the phenomenon
under consideration. This may involve testing the
alternative mathematical solutions using stan-
dard tools (such as IDL) or software prototypes
built using the available library of software
components / classes.
• SOFTWARE MODELING: Mapping the concepts
found in physical and mathematical modeling to
corresponding software objects. This requires
that the software engineer clearly understands
the physical and mathematical models. The
software engineer needs to consult domain-
experts throughout the software development
process for ensuring the correctness of analysis-
and-design decisions.
52 DAPI-09
We will discuss the guidelines for object-oriented software
modeling and design in the following section.
3.1 Guidelines for software modeling: We have found
that a mix of top-down and bottom-up approaches is of
high utility in software modeling of the system. The
object-oriented software can be modeled and designed in
the following two major steps:
1. SYSTEM ANALYSIS & DESIGN: It deals with the
overall understanding of the system objectives,
detailed requirements analysis and specifications
and decomposition into simpler, highly independent
subsystems / components using top-down
approach.
2. COMPONENT ANALYSIS & DESIGN: Application of
the fundamental concepts of OO approach to yield a
set of objects that collaborately implement the
component under consideration using bottom-up
approach.
3.1.1 Steps in System Analysis and Design: The
following steps are taken for decomposing a system into
subsystems and modeling these subsystems using
various kinds of modeling diagrams.
3.1.1.1 Defining the problem: A clear, complete, concise,
precise, and grammatically correct statement for the
system to be developed must be provided as a starting
point for analysis and design. This problem statement is
very crucial for the successful development of a system.
The problem statement must clearly state the objectives
and background to aid understanding of the objectives. It
should also bring out the essence of the procedure if the
system (or subsystem / component) realizes any scientific
algorithm. Moreover, known constraints and assumptions
should also be recorded in the problem statement.
3.1.1.2 Requirements analysis & specifications: Based
on the problem statement formulated in previous step,
detailed requirements (such as, functional requirements,
interface requirements, performance requirements etc.)
and constraints are captured and documented. This step
concentrates on what of the problem. Please note that
requirements should be modeled using a use-case
diagram, which describes the various ways in which the
system is used by the external entities attached to it. Each
use-case in the use-case diagram identifies a thread of
usage for the proposed system. Each use-case is
associated with a detailed description of events that are
undertaken as part of the use-case. Such a description is
often called a scenario. Furthermore, data flow diagrams
may also be used to aid the understanding of the
problem.
3.1.1.3 Decomposition into subsystems / components:
Based on the careful analysis of requirements laid down
in the previous step, the system is decomposed into a set
of highly independent subsystems (or components)
which collectively define the overall system. The package
diagram must be used to visualize the decomposition.
Indian Cartographer, 2002
3.1.1.4 Modeling each subsystem / component: The
previous three steps are repeated until we reach a level
where the components can be regarded as elementary
enough so that those can be realized using objects /
classes. If the component realizes a scientific algorithm
that is procedural in nature, activity diagram may be used
to visualize the activity flow.
3.1.2 Steps in component analysis & design using OO
concepts: Usually, there is no sharp distinction between
object-oriented analysis and design. Nevertheless, based
on the nature of activities, we can categorize them in the
following manner.
3.1.2.1 Object-Oriented Analysis: Object-Oriented
Analysis (OOA) provides us with a simple, yet powerful,
mechanism for identifying objects / classes, the building
blocks of OO software. The following object-oriented
analysis steps are basically concerned with the
decomposition of a component into classes / objects and
establishment of a class model of the component.
• Identification of classes: One way to identify
classes / objects is to look at the key concepts
involved in the problem domain. These key concepts
(when occurring as nouns) are good indicators of
classes. An analyst then determines exactly which
classes so identified are useful for the solution. One
criterion for choosing these concepts as classes is
that the concept should have significant structure (in
terms of attributes) and behavior.
• Identification of attributes and operations: Once
we have identified classes, it is the time to identify
the attributes and operations of these classes.
• Establishing relationships among classes: Here
we establish relationships among different classes
identified so far. These relationships are visualized
using class diagram The following three kinds of
relationships are identified among classes:
a) Association: If a class collaborates with another
class to perform some function, there exists an
association between them. Association may be of
two types: one-to-one and one-to-many.
b) Aggregation: An aggregation relationship is a
whole-part relationship among classes. It means that
a class may be composed of other smaller classes.
c) Inheritance: An inheritance relationship is a
generalization-specialization relationship among
classes.
• Modeling the class dynamics: To further aid the
understanding of the component, other UML
diagrams can be used to visualize the dynamic
behavior of the classes. For instance, use-case
scenarios developed during System Analysis and
Design phase may be visualized using Collaboration
and Sequence diagrams. State-transition diagram
may be used to model the dynamics of individual
classes.
Indian Cartographer, 2002
3.1.2.2 Object-oriented design: Object-Oriented Design
is an extension of Object-Oriented Analysis. Design is
concerned with the creation of data structures (for
attributes) and algorithms (for operations) for each class.
It is also important to construct structured hierarchies of
classes and to identify abstract classes, which contain
most general attributes, and operations that can be
inherited by other classes. The following design steps can
be followed to extend the class model prepared during
OOA steps.
• Revising class model developed in analysis
stage: The final solution may require some
additional classes besides of those found in analysis
stage, such as GUI classes, mathematical classes
(e.g. matrix, vector), data management classes (such
as file) etc. For this reason, classes found in analysis
stage must be reviewed for determining whether they
can be implemented (or they require restructuring)
and for identifying new auxiliary classes.
• Optimizing class hierarchies: During OOA, we
examined the inheritance relationships. We must re-
examine them and create class hierarchies so that
we can reuse as much data and/or functions that
have been designed already. Organization of class
hierarchies involves identification of common
attributes and functions among a group of related
classes and then combining them to form a new
class. This new class would serve as the super class
and other classes as subordinate classes, which
inherit features from the super class. The new class
may or may not have the meaning of an object by
itself. If the class is purely created to combine the
common features, it is then called an abstract class.
This process may be repeated until we are sure that
no new class can be formed. The most general
classes remains at the top of the class hierarchy. All
lower level classes are specialization of higher-level
classes in the hierarchy.
• Extract reusable classes from class repository: As
we already discussed, O-O technology promotes the
strategy of reusability. For this reason, a class
repository (or library) must be planned and
maintained for reuse across projects. In this step, we
examine the class repository in the light of class
model developed in the previous steps and extract
classes to maximize the reuse.
• Design of classes: Design of classes involves
specifying data structures for attributes and
algorithms for operations. This step also provides
specifications for some additional operations such
as data access functions, class constructor and
destructor functions, and error-handling functions
etc. for each class. Please note that if a class is
already contained in some class repository, it should
be reused. If the class contained in the class
repository is not exactly same as the class required
by the application, it can be tailored to suit the
application using inheritance.
DAPI-09 53
• Design of the driver class / program: This involves
specification for a driver class / program, which
makes use of various classes designed so far to
implement the component.
4. A Report on Practical Experience with usage
of Object-Oriented Technology
We have witnessed the fruitful application of object-
oriented approach by means of tremendous reduction in
development and maintenance times of data products
software. We have also demonstrated the revolutionary
reuse benefits of this approach by developing new
photogrammetric R&D software tools by means of
reusing OO software library generated as a result of data
products software development.
First, a software library (class repository) for geometric
precision processing of IRS-1C/1D image data was
developed using object-oriented approach. The same
library was reused and tuned for geometric correction
and precision processing of high resolution data provided
by contemporary satellite with step-and-stare imaging
technology. The amount of reuse has been around 80-90
percent. Then the library could be easily extended to
support new features. The reuse of already tested
software components has helped in ensuring the
correctness and reliability of data products generation
software.
The reusable library of photogrammetric software
components / classes has also enabled rapid, cheaper
and reliable development of data analysis tools such as
(i) overlap-analysis between multiple strip images of high
resolution satellite, (ii) in-flight calibration and (iii) satellite
foot-print analysis. These tools have helped a lot in
providing feedback for improving the mapping accuracy
of satellite imagery. In addition, the photogrammetric
software library has also been used as plug-and-play
component by commercial image-processing software
vendors such as ERDAS and PCI-Geomatics for
processing IRS-1C/1D data.
Moreover, a bonus advantage resulting from the
adoption of O-O technology is that it encourages better
understanding of phenomenon, concepts and
mathematical models by requiring focus on concepts
rather than procedures. Consequently, it may contribute
to better quality of scientific R & Ds in a team mode.
The OO library developed so far is expected to be highly
reused and extended during the development of software
for Cartosat standard data products and value-added
data products / services leading to the generation and
use of cartographic mapping applications.
5. Conclusions
Based on our discussion, it turns out that object-oriented
software engineering has a crucial role to play in the
design and development of complex satellite data
processing software systems required for effective
utilization of high-resolution space-borne imagery in the
54 DAPI-09
field of Cartography. Owing to real-world modeling
philosophy, object-oriented software systems are capable
of satisfying the objectives of maintainability, reliability,
extensibility, reusability and inter-operability. Furthermore,
object-oriented technology also helps in stimulating
scientific R & Ds essential for continuously improving the
methods of exploiting high-resolution space-borne
imagery in various cartographic application areas.
It is also deduced that the scientific software needs to be
developed in three major phases: physical modeling,
mathematical modeling and software modeling. Physical
modeling refers to understanding the phenomenon and
underlying concepts. Mathematical modeling is
concerned with describing the physical model using
mathematical formulae. Software modeling translated the
physical and mathematical models into practical
solutions.
Software modeling requires a mix of top-down and
bottom-up approaches to software development.
Software modeling is done in two sub-phases viz. (i)
System Analysis-and-design using top down approach
and (ii) Component Analysis-and-Design using bottom-up
approach.
6. Acknowledgements
We express our sincere gratitude to Dr. K. L. Majumder,
Group Director, SIPG for allowing pioneering efforts for
applying object-oriented technology to the development
and maintenance of operational satellite data products
generation software. We are highly thankful to Dr. Arvind
Kumar Singh, Shri Kannan V. Iyer, Shri Y. P. Rana, Smt.
Medha S. Alurkar, Smt. Sunanda P. Trivedi, Shri Jagjeet
Singh Nain, Shri Sanjay Singh, Smt. Deepa
Padmanabhan, and Dr. B. Kartikeyan for their
encouragement and positive attitude towards object-
oriented technology.
7. Bibliography
[1] Balagurusamy, E., 1995, Object-Oriented
Programming with C++, Tata McGraw-Hill, India
[2] Booch, Grady, 1994, Object Oriented Analysis and
Design with Applications, Reading, MA, Addison-
Wesley
[3] Coad, Peter and Edward Yourdon, 1990, Object
Oriented Analysis, Prentice Hall, Englewood Cliffs,
N.J.
[4] Pressman, Roger S., 1997, Software Engineering: A
Practitioner’s Approach, McGraw-Hill, New York
[5] Rumbaugh, James, et al, 1997, Object-Oriented
Modeling and Design, Prentice-Hall of India, New
Delhi
[6] Rumbaugh, James, Ivar Jacobson and Grady
Booch, 1998, Unified Modeling Language Reference
Manual, Addison-Wesley, Reading, MA
[7] Sigfried, Stefan, 1996, Understanding Object-Oriented
Software Engineering, IEEE Press, New York
Indian Cartographer, 2002