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.
Parts
» The Concurrent Development Model
» SUMMARY Software engineering is a discipline that integrates process, methods, and tools for
» PEOPLE In a study published by the IEEE [CUR88], the engineering vice presidents of three
» THE PROCESS The generic phases that characterize the software process—definition, development,
» THE PROJECT In order to manage a successful software project, we must understand what can go
» METRICS IN THE PROCESS AND PROJECT DOMAINS
» Extended Function Point Metrics
» METRICS FOR SOFTWARE QUALITY
» INTEGRATING METRICS WITHIN THE SOFTWARE PROCESS
» METRICS FOR SMALL ORGANIZATIONS
» ESTABLISHING A SOFTWARE METRICS PROGRAM
» Obtaining Information Necessary for Scope
» An Example of LOC-Based Estimation
» QUALITY CONCEPTS 1 It has been said that no two snowflakes are alike. Certainly when we watch snow
» SUMMARY Software quality assurance is an umbrella activity that is applied at each step in the
» R diagram 1.4 <part-of> data model; data model <part-of> design specification;
» SYSTEM MODELING Every computer-based system can be modeled as an information transform using an
» Facilitated Application Specification Techniques
» Data Objects, Attributes, and Relationships
» Entity/Relationship Diagrams
» Hatley and Pirbhai Extensions
» Creating an Entity/Relationship Diagram
» SUMMARY Design is the technical kernel of software engineering. During design, progressive
» Data Modeling, Data Structures, Databases, and the Data Warehouse
» Data Design at the Component Level
» A Brief Taxonomy of Styles and Patterns
» Quantitative Guidance for Architectural Design
» Isolate the transform center by specifying incoming and outgoing
» SUMMARY Software architecture provides a holistic view of the system to be built. It depicts the
» The User Interface Design Process
» Defining Interface Objects and Actions
» D E S I G N E VA L U AT I O N
» Testing for Real-Time Systems
» Organizing for Software Testing
» Criteria for Completion of Testing
» The Transition to a Quantitative View
» The Attributes of Effective Software Metrics
» Architectural Design Metrics
» Component-Level Design Metrics
» SUMMARY Software metrics provide a quantitative way to assess the quality of internal product
» Encapsulation, Inheritance, and Polymorphism
» Identifying Classes and Objects
» The Common Process Framework for OO
» OO Project Metrics and Estimation
» Event Identification with Use-Cases
» SUMMARY Object-oriented analysis methods enable a software engineer to model a problem by
» Partitioning the Analysis Model
» Designing Algorithms and Data Structures
» Program Components and Interfaces
» SUMMARY Object-oriented design translates the OOA model of the real world into an
» Testing Surface Structure and Deep Structure
» Deficiencies of Less Formal Approaches 1
» What Makes Cleanroom Different?
» Design Refinement and Verification
» SUMMARY Cleanroom software engineering is a formal approach to software development that
» Structural Modeling and Structure Points
» Describing Reusable Components
» SUMMARY Component-based software engineering offers inherent benefits in software quality,
» Guidelines for Distributing Application Subsystems
» Middleware and Object Request Broker Architectures
» An Overview of a Design Approach
» Consider expert Web developer will create a complete design, but time and cost can be appropriate
» A Software Reengineering Process Model
» Reverse Engineering to Understand Data
» Forward Engineering for Client/Server Architectures
» SUMMARY Reengineering occurs at two different levels of abstraction. At the business level,
Show more