|  |
PrefacePreface
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 www.mhhe.com/schach.
- 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.
| Construct | Section 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:
| Construct | Section in Which the Corresponding
UML Diagram is Introduced | |
Class diagram, aggregation, multiplicity, composition,
generalization, association | Section 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 |
|
|
|
2008 McGraw-Hill Higher Education