T H E O B J E C T - O R I E N T E D PA R A D I G M For many years, the term object oriented (OO) was used to denote a software devel-

20.1 T H E O B J E C T - O R I E N T E D PA R A D I G M For many years, the term object oriented (OO) was used to denote a software devel-

opment approach that used one of a number of object-oriented programming lan- guages (e.g., Ada95, Java, C++, Eiffel, Smalltalk). Today, the OO paradigm encompasses

a complete view of software engineering. Edward Berard notes this when he states [BER93]:

The benefits of object-oriented technology are enhanced if it is addressed early-on and

“With objects, it’s

throughout the software engineering process. Those considering object-oriented technol-

actually easier to build models [for ogy must assess its impact on the entire software engineering process. Merely employing

complex systems]

object-oriented programming (OOP) will not yield the best results. Software engineers and

than to engage in

their managers must consider such items as object-oriented requirements analysis (OORA),

sequential

object-oriented design (OOD), object-oriented domain analysis (OODA), object-oriented

programming.”

database systems (OODBMS) and object-oriented computer aided software engineering

David Taylor

(OOCASE).

A reader who is familiar with the conventional approach to software engineering (presented in Part Three of this book) might react to this statement with a shrug: “What’s the big deal? We use analysis, design, programming, testing, and related tech-

CHAPTER 20

OBJECT-ORIENTED CONCEPTS AND PRINCIPLES

F I G U R E 20.1

The OO Identify process model

Construct Look up Customer

nth iteration classes Communication

of system in library Put new

Extract classes

classes in library

if available Engineer

classes Evaluation

Customer

Engineering,

Construction & Release

if unavailable OO analysis

OO design OO programming OO testing

nologies when we engineer software using the classical methods. Why should OO

be any different?” Indeed, why should OO be any different? In short, it shouldn’t! In Chapter 2, we discussed a number of different process models for software engi-

OO systems are neering. Although any one of these models could be adapted for use with OO, the engineered using an

best choice would recognize that OO systems tend to evolve over time. Therefore, evolutionary process

an evolutionary process model, coupled with an approach that encourages compo- model. Later in this

nent assembly (reuse), is the best paradigm for OO software engineering. Referring chapter, it will be

referred to as a to Figure 20.1, the component-based development process model (Chapter 2) has recursive parallel

been tailored for OO software engineering. model.

The OO process moves through an evolutionary spiral that starts with customer communication. It is here that the problem domain is defined and that basic problem classes (discussed later in this chapter) are identified. Planning and risk analysis estab- lish a foundation for the OO project plan. The technical work associated with OO software engineering follows the iterative path shown in the shaded box. OO soft-

WebRef

ware engineering emphasizes reuse. Therefore, classes are “looked up” in a library One of the Web’s most

(of existing OO classes) before they are built. When a class cannot be found in the extensive lists of OO

library, the software engineer applies object-oriented analysis (OOA), object-oriented resources can be found at

mini.net/cetus/

design (OOD), object-oriented programming (OOP), and object-oriented testing (OOT)

software.html

to create the class and the objects derived from the class. The new class is then put into the library so that it may be reused in the future.

The object-oriented view demands an evolutionary approach to software engineering. As we will see throughout this and the following chapters, it would be The object-oriented view demands an evolutionary approach to software engineering. As we will see throughout this and the following chapters, it would be

a single iteration. As the OO analysis and design models evolve, the need for addi- tional classes becomes apparent. It is for this reason that the paradigm just described works best for OO.