Student Edition | Instructor Edition | Information Center | Home
Object-Oriented Software Engineering
Information Center
Sample Chapter
Table of Contents

Help Center



The wheel has turned full circle.
In 1988, I wrote a textbook entitled Software Engineering. Virtually the only mention of the object-oriented paradigm in that book was one section that described object-oriented design.
By 1994, the object-oriented paradigm was starting to gain acceptance in the software industry, so I wrote a textbook called Classical and Object-Oriented Software Engineering. Six years later, however, the object-oriented paradigm had become more important than the classical paradigm. To refl ect this change, I switched the order of the two topics in the title of the textbook I wrote in 2000, and called it Object-Oriented and Classical Software Engineering.
Nowadays, use of the classical paradigm is largely restricted to maintaining legacy software. Students learn C++ or Java as their fi rst programming language, and object-oriented languages are used in subsequent computer science and computer engineering courses. Students expect that, when they graduate, they will work for a company that uses the object-oriented paradigm. The object-oriented paradigm has all but squeezed out the classical paradigm. And that is why I have written a textbook entitled Object-Oriented Software Engineering.

Features of This Book

  • The Unifi ed Process is still largely the methodology of choice for object-oriented software development. Throughout this book, the student is therefore exposed to both the theory and the practice of the Unifi ed Process.
  • In Chapter 1 (“The Scope of Object-Oriented Software Engineering”), the strengths of the object-oriented paradigm are analyzed in depth.
  • The iterative-and-incremental life-cycle model has been introduced as early as possible, namely, in Chapter 2 (“Software Life-Cycle Models”). Agile processes are also discussed in this chapter.
  • In Chapter 3 (“The Software Process”), the workfl ows (activities) and processes of the Unifi ed Process are introduced, and the need for two-dimensional life-cycle models is explained.
  • A wide variety of ways of organizing software teams are presented in Chapter 4 (“Teams”), including teams for agile processes and for open-source software development.
  • Chapter 5 (“Tools of the Trade”) includes information on important classes of CASE tools.
  • The importance of continual testing is stressed in Chapter 6 (“Testing”).
  • Objects are the focus of attention in Chapter 7 (“From Modules to Objects”).
  • In Chapter 8 (“Reusability and Portability”), design patterns have been stressed.
  • The new IEEE standard for software project management plans is presented in Chapter 9 (“Planning and Estimating”).
  • Chapter 10 (“The Requirements Workfl ow”), Chapter 11 (“The Analysis Workfl ow”), Chapter 12 (“The Design Workfl ow”), and Chapter 13 (“The Implementation Workflow”) are largely devoted to the workfl ows (activities) of the Unifi ed Process.
  • The material in Chapter 13 (“The Implementation Workfl ow”) clearly distinguishes between implementation and integration.
  • The importance of postdelivery maintenance is stressed in Chapter 14 (“Postdelivery Maintenance”).
  • Chapter 15 (“More on UML”) provides additional material on UML to prepare the student thoroughly for employment in the software industry. This chapter is of particular use to instructors who utilize this book for the two-semester software engineering course sequence. In the second semester, in addition to developing the team-based term project or a capstone project, the student can acquire additional knowledge of UML, beyond what is needed for this book.
  • There are two running case studies. The MSG Foundation case study and the elevator problem case study have been developed using the Unifi ed Process. Java and C++ implementations are available online at
  • In addition to the two running case studies that are used to illustrate the complete life cycle, seven mini case studies highlight specifi c topics, such as the moving-target problem, stepwise refi nement, design patterns, and postdelivery maintenance.
  • I stress the importance of documentation, maintenance, reuse, portability, testing, and CASE tools. It is no use teaching students the latest ideas unless they appreciate the importance of the basics of object-oriented software engineering.
  • Attention is paid to object-oriented life-cycle models, object-oriented analysis, objectoriented design, management implications of the object-oriented paradigm, and the testing and maintenance of object-oriented software. Metrics for the object-oriented paradigm also are included. In addition, many briefer references are made to objects, a paragraph or even only a sentence in length. The reason is that the object-oriented paradigm is not just concerned with how the various workfl ows are performed but rather permeates the way we think about software engineering. Object technology pervades this book.
  • The software process underlies the book as a whole. To control the process, we have to be able to measure what is happening to the project. Accordingly, there is an emphasis on metrics. With regard to process improvement, there is material on the capability maturity model (CMM), ISO/IEC 15504 (SPICE), and ISO/IEC 12207; the people capability maturity model (P–CMM) has been included in the chapter on teams.
  • The book is language independent; the few code examples are presented in C++ and Java, and I have made every effort to smooth over language-dependent details and ensure that the code examples are equally clear to C++ and Java users. For example, instead of using cout for C++ output and System.out.println for Java output, I have utilized the pseudocode instruction print. (The one exception is the second case study, where complete implementation details are given in both C++ and Java.)
  • This book contains over 600 references. I have selected current research papers as well as classic articles and books whose message remains fresh and relevant. There is no question that object-oriented software engineering is a rapidly moving fi eld, and students therefore need to know the latest results and where in the literature to fi nd them. At the same time, today’s cutting-edge research is based on yesterday’s truths, and I see no reason to exclude an older reference if its ideas are as applicable today as they originally were.
  • With regard to prerequisites, it is assumed that the reader is familiar with one high-level object-oriented programming language such as C++ or Java. In addition, the reader is expected to have taken a course in data structures.

How This Book Is Organized

This book is written for both the traditional one-semester and the newer two-semester software engineering curriculum, now growing in popularity. In the traditional onesemester (or one-quarter) course, the instructor has to rush through the theoretical material to provide the students the knowledge and skills needed for the term project as soon as possible. The need for haste is so that the students can commence the term project early enough to complete it by the end of the semester. To cater to a one-semester, project-based software engineering course, Part 2 of this book covers the software life cycle, workfl ow by workfl ow, and Part 1 contains the theoretical material needed to understand Part 2. For example, Part 1 introduces the reader to CASE, metrics, and testing; each chapter of Part 2 contains a section on CASE tools for that workfl ow, a section on metrics for that workfl ow, and a section on testing during that workfl ow. Part 1 is kept short to enable the instructor to start Part 2 relatively early in the semester. Furthermore, the last two chapters of Part 1 (Chapters 8 and 9) may be postponed, and then taught in parallel with Part 2. As a result, the class can begin developing the term project as soon as possible.
We turn now to the two-semester software engineering curriculum. More and more computer science and computer engineering departments are realizing that the overwhelming preponderance of their graduates fi nd employment as software engineers. As a result, many colleges and universities have introduced a two-semester (or two-quarter) software engineering sequence. The fi rst course is largely theoretical (but often includes a small project of some sort). The second course comprises a major team-based term project. This is usually a capstone project. When the term project is in the second course, there is no need for the instructor to rush to start Part 2.
Therefore, an instructor teaching a one-semester (or one-quarter) sequence using this book covers most of Chapters 1 through 7 and then starts Part 2 (Chapters 10 through 15). Chapters 8 and 9 can be taught in parallel with Part 2 or at the end of the course while the students are implementing the term project. When teaching the two-semester sequence, the chapters of the book are taught in order; the class now is fully prepared for the team-based term project that it will develop in the following semester.
To ensure that the key software engineering techniques of Part 2 truly are understood, each is presented twice. First, when a technique is introduced, it is illustrated by means of the elevator problem. The elevator problem is the correct size for the reader to be able to see the technique applied to a complete problem, and it has enough subtleties to highlight both the strengths and weaknesses of the technique being taught. Then, the relevant portion of the MSG Foundation case study is presented. This detailed solution provides the second illustration of each technique.

The Problem Sets

This book has fi ve types of problems. First, there are running object-oriented analysis and design projects at the end of Chapters 10, 11, and 12. These have been included because the only way to learn how to perform the requirements, analysis, and design workfl ows is from extensive hands-on experience.
Second, the end of each chapter contains a number of exercises intended to highlight key points. These exercises are self-contained; the technical information for all the exercises can be found in this book.
Third, there is a software term project. It is designed to be solved by students working in teams of three, the smallest number of team members that cannot confer over a standard telephone. The term project comprises 14 separate components, each tied to the relevant chapter. For example, design is the topic of Chapter 12, so in that chapter the component of the term project is concerned with software design. By breaking a large project into smaller, well-defi ned pieces, the instructor can monitor the progress of the class more closely. The structure of the term project is such that an instructor may freely apply the 14 components to any other project that he or she chooses.
Because this book has been written for use by graduate students as well as upper-class undergraduates, the fourth type of problem is based on research papers in the software engineering literature. In each chapter, an important paper has been chosen. The student is asked to read the paper and answer a question relating to its contents. Of course, the instructor is free to assign any other research paper; the For Further Reading section at the end of each chapter includes a wide variety of relevant papers.
The fi fth type of problem relates to the case study. This type of problem has been included in response to a number of instructors who feel that their students learn more by modifying an existing product than by developing a new product from scratch. Many senior software engineers in the industry agree with that viewpoint. Accordingly, each chapter in which the case study is presented has problems that require the student to modify the case study in some way. For example, in one chapter the student is asked what the effect would have been of performing the steps of the object-oriented analysis in a different order. To make it easy to modify the source code of the case study, it is available on this website.
The website also has material for instructors, including a complete set of PowerPoint lecture notes, and detailed solutions to all the exercises as well as to the term project.

Material on UML

This book makes substantial use of the Unifi ed Modeling Language (UML). If the students do not have previous knowledge of UML, this material may be taught in two ways. I prefer to teach UML on a just-in-time basis; that is, each UML concept is introduced just before it is needed. The following table describes where the UML constructs used in this book are introduced.

ConstructSection in Which the Corresponding UML Diagram is Introduced
Class diagram, note, inheritance (generalization), aggregation, association, navigation triangle Section 7.7
Use case Section 10.4.3
Use-case diagram, use-case description Section 10.7
Stereotype Section 11.4
Statechart Section 11.9
Interaction diagram (sequence diagram, communication Section 11.18 diagram)

Alternatively, Chapter 15 contains an introduction to UML, including material above and beyond what is needed for this book. Chapter 15 may be taught at any time; it does not depend on material in the first 14 chapters. The topics covered in Chapter 15 are given in the following table:

ConstructSection in Which the Corresponding UML Diagram is Introduced
Class diagram, aggregation, multiplicity, composition, generalization, associationSection 15.2
Note Section 15.3
Use-case diagram Section 15.4
Stereotype Section 15.5
Interaction diagram Section 15.6
Statechart Section 15.7
Activity diagram Section 15.8
Package Section 15.9
Component diagram Section 15.10
Deployment diagram Section 15.11