Designing Satellite Data Processing Software Systems using Object ...

Designing Satellite Data Processing Software Systems using ObjectOriented 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 Use of high-resolution space-borne imagery in cartography is becoming increasingly popular. Spaceborne 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

Indian Cartographer, 2002

1. Introduction Use of high-resolution satellite imagery in cartography is 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 highresolution 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 & turnaround 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

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. 2. 3. 4.

5.

High Quality & Reliability Short development & maintenance times Reusability across the different satellite missions Extensibility for incorporating new requirements (such as new and improved mathematical models) Inter-operability with commercial software packages such as ERDAS-Imagine, thus requiring Component-based software architectures.

•

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 concepts). The object-oriented approach to software development 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.

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.

Real world modeling i.e. software objects / components directly models their real-world counterparts. In other words, there is a one-toone 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)

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.

3.

Suitable for evolutionary development process model, i. e. Object-oriented software is developed 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, domainexperts, 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.

In the modern era, the procedure-oriented approach is subject to the following concerns:

50

•

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?

DAPI-09

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 ObjectOriented 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 twodimensional 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 oneanother 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 realworld 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 realworld. 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 conceptoriented 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:

52

•

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 mathematical representation of the phenomenon under consideration. This may involve testing the alternative mathematical solutions using standard 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 domainexperts throughout the software development process for ensuring the correctness of analysisand-design decisions.

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.

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

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

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 objectoriented 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 objectoriented 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, AddisonWesley [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