An Introduction to Software Design

Chenglie Hu

An Introduction to
Software Design
Concepts, Principles, Methodologies,
and Techniques
Chenglie Hu
Computer Science
Carroll University
Waukesha, WI
USA

ISBN 978-3-031-28310-9 ISBN 978-3-031-28311-6 (eBook)

https://doi.org/10.1007/978-3-031-28311-6

# The Editor(s) (if applicable) and The Author(s), under exclusive license to Springer Nature Switzerland AG
2023
This work is subject to copyright. All rights are solely and exclusively licensed by the Publisher, whether the
whole or part of the material is concerned, specifically the rights of translation, reprinting, reuse of illustrations,
recitation, broadcasting, reproduction on microfilms or in any other physical way, and transmission or information
storage and retrieval, electronic adaptation, computer software, or by similar or dissimilar methodology now
known or hereafter developed.
The use of general descriptive names, registered names, trademarks, service marks, etc. in this publication does not
imply, even in the absence of a specific statement, that such names are exempt from the relevant protective laws
and regulations and therefore free for general use.
The publisher, the authors, and the editors are safe to assume that the advice and information in this book are
believed to be true and accurate at the date of publication. Neither the publisher nor the authors or the editors give a
warranty, expressed or implied, with respect to the material contained herein or for any errors or omissions that
may have been made. The publisher remains neutral with regard to jurisdictional claims in published maps and
institutional affiliations.

This Springer imprint is published by the registered company Springer Nature Switzerland AG
The registered company address is: Gewerbestrasse 11, 6330 Cham, Switzerland
Preface

According to the Accreditation Board for Engineering and Technology (or ABET as
commonly known), software design is one of the core subjects of computer science
alongside data structures, computer architecture, algorithms, and programming languages.
Yet, unlike the other core areas, there is no widely accepted “table of contents” for software
design that can be used for curriculum development. As a result, what software design may
be or entail largely depends on the interpretation of an instructor. There are a variety of
ways how design is taught in a computer science program, including a learning of the
Unified Modeling Language, a learning about design patterns, or simply a chapter-worth
coverage in a software engineering course. Though students may have learned pieces of
software design in various courses even in elementary programming courses, such
fragmented coverages may not always be coherent and consistent. Computer science
education research has shown that graduating computer science students may lack neces-
sary software design knowledge and skills due to inadequate design education students
have received.
After all, software design is not a well-defined discipline in terms of its foundation
(concepts and theories), a defined body of knowledge that allows foundational research to
be carried out, its terminologies, its research methods, and, perhaps most importantly, some
institutional manifestation in the form of subjects taught at colleges and universities. In
fact, we might not even agree on what appears to be a basic question: What is software
design? In the extreme, a software design may be fully documented like one we may see in
a structural engineering discipline, or it may only exist in code artifacts. But most likely in
practice, we often create critical yet often incomprehensive design artifacts for a variety of
reasons to communicate about our design thoughts and facilitate the code construction. On
the one hand, a design must work logically; thus, doing design might sound like doing
some sort of mathematics (though whether both share similar ways of thinking remains
debatable). On the other hand, there are many ways we can design a program, and we
eventually must choose one. Thus, doing design might be considered a form of art with an
“aesthetic” value in the viewpoint of a designer. But at all events, design is unlikely an
engineering act or thing because we may start constructing the software when we do not

v
vi Preface

even have an architecture of the software ready. Regardless of what software design may
be, its importance in software’s long-term success is undeniable. Despite these conceptual
and philosophical challenges, it appears clear that we need a consistent design curriculum
in computer science programs to better prepare students for real-world challenges in
software development.
Most design books are professionally oriented, focusing on a design process such as
continuous design, emergent design, domain-oriented design, agile modeling, etc. They
were not intended to be used as college textbooks. Meanwhile, there have been some
design textbooks but most with also significant coverage on programming. They vary in
style, depth, and topical focus. This diversity seen in existing textbooks may have created
difficulties for instructors to choose an appropriate textbook as the author experienced
when he started teaching the subject more than a decade ago. The author’s exploration in
teaching of design started with this fundamental question: What is an appropriate body of
knowledge about software design that every computer science student must possess? The
Guide to the Software Engineering Body of Knowledge (published by IEEE Computer
Society in 2004) specifies what constitutes body of knowledge for software design. The
backbone of this knowledge seems to be the design-enabling techniques, which, according
to the Guide, include design principles, guidelines, and key notions and concepts in regard
to design abstraction, decomposition, modularization, and module cohesion and coupling.
Also based on the Guide, some essential knowledge about software architecture should also
be included. Therefore, the design-enabling techniques, software architecture, and design
of larger software elements (necessary for understanding software architecture) may
constitute, in the author’s viewpoint, the core of the essential knowledge about software
design. This understanding has guided the author to design and improve his teaching every
year, leading to the formation of the book.
Chapter 1 is dedicated to an exploration of what software design may be and entail.
Design is a way of thinking; therefore, “design thinking”—a widely publicized mode of
critical thinking in the recent years—is prompted in the book. Readers are expected to have
appropriate knowledge in data structures. However, it is not assumed that readers have also
gained good understanding about the paradigm of object orientation. Thus, Chaps. 2 and 3
are designed to help readers better understand object orientation and the essentials of
object-oriented design. Methods, standalone or being part of larger units, are essential
program units, and design of methods may significantly impact the design attributes of
enclosing modules, subsystems, or even the entire system. Chapter 4 is dedicated to design
of methods. Object-oriented design is still the primary design paradigm in the real world;
therefore, a good portion of the book also includes topics about design of objects, modeling
with the Unified Modeling Language, and use of design patterns (Chaps. 5, 6, and 8,
respectively), though the coverage of these topics has a focus on intrigued ideas behind the
use of the concepts, techniques, tools, and patterns. Despite object orientation being still the
center of attention, there is a strong promotion throughout the book that software design
should consider all appropriate design paradigms and methodologies. Larger software
elements are often directly responsible for the formation of software architecture.
Preface vii

Chapter 7 covers four kinds of larger software elements—libraries, components,

frameworks, and microservices—and their architectural implications. Chapter 9 finally
brings the presentation of software design to an end with a coverage on software architec-
ture. However, after a well-proportioned discussion on what software architecture may be,
the focus of the chapter is on software architectural views. Case studies are important in
learning design. But as the author observed, small design examples may be more effective
for students to see the applications of design-enabling techniques than larger case studies
where we tend to integrate as many such techniques as possible with possibly insubstantial
scenarios and missed learning opportunities in exploring diverse design choices and trade-
offs. Chapter 10 then gathers some relatively small design case studies that can be used in
earlier chapters as appropriate. These case studies can be extended in different ways to
provide additional design opportunities. Besides, Chaps. 5 and 10 also include, as
exercises, a variety of larger design questions that can be used partially or entirely when
covering the respective contents. This book is an attempt by the author to explore a possible
software design curriculum that can be used across computer science programs.
The book has adequate materials to be used in a four-credit course on software design or
in a three-credit course with certain contents in Chaps. 7–9 left out. Other academic
programs such as software engineering, computer engineering, or professional software
development may also use the book as either a primary textbook or as a reference. The
depth of the book makes it also appropriate for a design textbook at beginning graduate
level. It is also appropriate to use the book as a primary reference in a software engineering
course. Professionals may also find the book useful in their professional development.
For teaching support materials, please contact the author at [email protected].
Finally, the author is grateful to his wife and other family members for their continued
understanding and support during the course of writing. He is also indebted to his students
for their efforts in learning design and for their feedback over the years. The invaluable
learning outcomes they have demonstrated over the years have not only helped the author
improve his own understanding about software design but also become ingredients of the
book in many ways.
Lastly, but not the least, the author would like to thank the Springer staffers for their
encouragement and technical support throughout the course of this project, and particularly
for the excellent editing work.

Waukesha, WI, USA Chenglie Hu

Contents

1 What Is Software Design? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 The Nature of Software Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.3 Software Design in the Context of Software Lifecycles . . . . . . . . . . . . 5
1.4 Software Design in the Context of Analytical Thinking . . . . . . . . . . . 6
1.5 Software Design in the Context of Communication . . . . . . . . . . . . . . 8
1.6 Software Design in the Context of Design Formalism . . . . . . . . . . . . . 12
1.7 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2 The Paradigm of Object Orientation and Beyond . . . . . . . . . . . . . . . . . . 19
2.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.2 What Is Object Orientation? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.2.1 Data Abstraction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.2.2 Object Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.2.3 Inheritance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.3 The Paradigm of Object-Oriented Design . . . . . . . . . . . . . . . . . . . . . 26
2.4 Embracing Multi-paradigm Design . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.5 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3 Essentials of Object-Oriented Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.2 Data Type, Data Abstraction, and Type-Safe Practices . . . . . . . . . . . . 37
3.3 More About Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.3.1 Software Sustainability . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.3.2 The Role of Interfaces Through the Lens of Data Structures . . . 42
3.3.3 Programming to an Interface, Not to an Implementation . . . . . 45
3.3.4 Interface Segregation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
3.3.5 Section Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

ix
x Contents

3.4 Abstract Classes and Design of Type Hierarchies . . . . . . . . . . . . . . . . 50

3.4.1 Use of Abstract Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
3.4.2 A Case Study . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
3.4.3 Section Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
3.5 When to Avoid Inheritance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
3.6 Subtyping with Consistent Object Behavior . . . . . . . . . . . . . . . . . . . . 59
3.6.1 Representation Invariants . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
3.6.2 Liskov Substitution Principle . . . . . . . . . . . . . . . . . . . . . . . . 60
3.6.3 Design by Contract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
3.7 Lazy Object Creation Allowing Delayed Decision-Making . . . . . . . . . 64
3.8 Object-Oriented Design in the Large: Design Principles . . . . . . . . . . . 66
3.9 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
4 Design of Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
4.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
4.2 Essential Characteristics of a Method . . . . . . . . . . . . . . . . . . . . . . . . 76
4.2.1 Procedural Abstraction and Modularity . . . . . . . . . . . . . . . . . 76
4.2.2 Design Attributes of a Method . . . . . . . . . . . . . . . . . . . . . . . 78
4.3 Cohesion of a Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
4.4 Method Coupling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
4.4.1 The Phenomenon of Coupling . . . . . . . . . . . . . . . . . . . . . . . 82
4.4.2 Effects of Coupling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
4.4.3 Categorization of Coupling . . . . . . . . . . . . . . . . . . . . . . . . . 87
4.5 Module Redesign and Code Refactoring . . . . . . . . . . . . . . . . . . . . . . 88
4.6 Method Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
4.6.1 The Nature of a Module Specification . . . . . . . . . . . . . . . . . . 91
4.6.2 Method Specification with Some Formalism . . . . . . . . . . . . . 93
4.7 A Case Study: Overriding “Equals” . . . . . . . . . . . . . . . . . . . . . . . . . . 96
4.8 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
5 Design of Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
5.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
5.2 The Context and Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
5.3 Essentials of Object Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
5.3.1 Object to Model One Thing . . . . . . . . . . . . . . . . . . . . . . . . . 107
5.3.2 Diverse Object Design Possibilities . . . . . . . . . . . . . . . . . . . 108
5.3.3 Prototyping Object Interaction . . . . . . . . . . . . . . . . . . . . . . . 110
5.3.4 Designing Objects Around a Structural Style . . . . . . . . . . . . . 110
5.3.5 More About Object Discovery . . . . . . . . . . . . . . . . . . . . . . . 113
5.3.6 Design to Ensure Objects’ Behavioral Correctness . . . . . . . . . 115
Contents xi

5.4 Design of Control Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116

5.4.1 Highly Centralized vs. Coordinated Controls . . . . . . . . . . . . . 117
5.4.2 Process Control with a Framework . . . . . . . . . . . . . . . . . . . . 118
5.4.3 Controls for Event-Driven Systems . . . . . . . . . . . . . . . . . . . . 118
5.4.4 Different Control Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
5.4.5 Objects Are Designed to Control . . . . . . . . . . . . . . . . . . . . . 120
5.5 Object Cohesion and Coupling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
5.5.1 What Are the Issues? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
5.5.2 Law of Demeter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
5.5.3 Objects with No Overlapping Behavior . . . . . . . . . . . . . . . . . 125
5.6 Iterative Design of Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
5.6.1 Initial Design of Domain Abstractions . . . . . . . . . . . . . . . . . 126
5.6.2 Subsequent Design Validation and Refactoring . . . . . . . . . . . 127
5.7 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
Further Reading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
6 Software Modeling Languages and Tools . . . . . . . . . . . . . . . . . . . . . . . . . 137
6.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
6.2 Software Analysis and Modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
6.3 Developing Effective Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
6.3.1 Use-Case Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
6.3.2 Use of Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
6.3.3 Development of Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . 146
6.3.4 Use-Case Diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
6.4 Other UML Diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
6.4.1 Class Diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
6.4.2 Sequence Diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
6.4.3 State (Machine) Diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . 159
6.4.4 Activity Diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
6.5 Use of UML Diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
6.6 Dataflow Diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
6.7 Modeling with Customized Diagrams . . . . . . . . . . . . . . . . . . . . . . . . 179
6.8 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
Further Reading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
7 Design of Larger Software Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
7.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
7.2 Software Interfaces and APIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
7.3 Characterization of Larger Software Elements . . . . . . . . . . . . . . . . . . 189
xii Contents

7.4 Design of a Library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192

7.4.1 Software Libraries of Different Kinds . . . . . . . . . . . . . . . . . . 192
7.4.2 Characteristics, Benefits, and Risks of a Library . . . . . . . . . . 194
7.4.3 Initial Design of a Library . . . . . . . . . . . . . . . . . . . . . . . . . . 196
7.4.4 Design of a Library’s API . . . . . . . . . . . . . . . . . . . . . . . . . . 197
7.5 Design of Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198
7.5.1 Component Concepts, Structures, and Models . . . . . . . . . . . . 199
7.5.2 Component Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205
7.5.3 Component Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208
7.5.4 Component Composition . . . . . . . . . . . . . . . . . . . . . . . . . . . 210
7.5.5 Component-Based Architecture . . . . . . . . . . . . . . . . . . . . . . 213
7.6 Design of Application Frameworks . . . . . . . . . . . . . . . . . . . . . . . . . . 216
7.6.1 Characteristics of an Application Framework . . . . . . . . . . . . 216
7.6.2 Framework Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218
7.6.3 A Case Study . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219
7.7 Microservices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221
7.7.1 Some Background Information . . . . . . . . . . . . . . . . . . . . . . . 222
7.7.2 The Promises of Microservices . . . . . . . . . . . . . . . . . . . . . . . 224
7.7.3 Internal Operations of a Microservice . . . . . . . . . . . . . . . . . . 225
7.8 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226
Further Reading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230
8 Software Design Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231
8.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231
8.2 Creational Design Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232
8.2.1 Singleton . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232
8.2.2 Abstract Factory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233
8.2.3 Builder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234
8.2.4 Prototype . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236
8.2.5 Section Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237
8.3 Structural Design Pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238
8.3.1 Adapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238
8.3.2 Proxy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239
8.3.3 Façade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241
8.3.4 Decorator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242
8.3.5 Composite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244
8.3.6 Bridge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245
8.3.7 Flyweight . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246
8.3.8 Twin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247
8.3.9 Section Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248
Contents xiii

8.4 Behavioral Design Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250

8.4.1 Strategy, Servant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250
8.4.2 Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252
8.4.3 State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253
8.4.4 Visitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257
8.4.5 Iterator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259
8.4.6 Chain of Responsibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260
8.4.7 Observer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262
8.4.8 Mediator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264
8.4.9 Section Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265
8.5 More About Object Communication . . . . . . . . . . . . . . . . . . . . . . . . . 266
8.6 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275
9 Software Architecture and Architectural Views . . . . . . . . . . . . . . . . . . . . 277
9.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277
9.2 What Is Software Architecture? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278
9.2.1 A Characterization of Software Architecture . . . . . . . . . . . . . 279
9.2.2 Architectural Styles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280
9.2.3 Structural Layers of Software Elements . . . . . . . . . . . . . . . . 282
9.2.4 The Impact of Software Architecture . . . . . . . . . . . . . . . . . . 284
9.2.5 Architectural Views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286
9.3 The 4+1 Architectural View Model . . . . . . . . . . . . . . . . . . . . . . . . . . 289
9.3.1 An Overview of the View Model . . . . . . . . . . . . . . . . . . . . . 289
9.3.2 The Logic View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291
9.3.3 The Process View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292
9.3.4 The Development View . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294
9.3.5 The Physical View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295
9.3.6 The “+1” View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297
9.4 The C4 View Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 298
9.4.1 The Layers of the C4 View Model . . . . . . . . . . . . . . . . . . . . 298
9.4.2 An Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300
9.5 Effective Development of Architectural Views . . . . . . . . . . . . . . . . . . 303
9.6 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309
Further Reading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 310
10 Design Case Studies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311
10.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311
10.2 Two Simple Case Studies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312
10.2.1 A Simple Service Application . . . . . . . . . . . . . . . . . . . . . . . 312
10.2.2 A Generic Data Sorting Framework . . . . . . . . . . . . . . . . . . . 315
xiv Contents

10.3 A Card Game . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317

10.3.1 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 318
10.3.2 Two Abstract Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320
10.4 A Framework for Animation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323
10.4.1 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323
10.4.2 Two Examples of Using the Framework . . . . . . . . . . . . . . . . 326
10.5 An Analyzer for Frequencies of Words in a Text . . . . . . . . . . . . . . . . 328
10.5.1 Design Story and Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 328
10.5.2 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 329
10.5.3 More Details About Implementation . . . . . . . . . . . . . . . . . . . 330
10.5.4 Details of the Application Control . . . . . . . . . . . . . . . . . . . . 332
10.6 Getting People to Sleep . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333
10.6.1 Application Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . 334
10.6.2 Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334
10.6.3 Logic View of the Design . . . . . . . . . . . . . . . . . . . . . . . . . . 335
10.6.4 Process View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 338
10.7 Wheel of Fortune Game . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342
10.7.1 The Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343
10.7.2 A Use Case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344
10.7.3 First Three Views in the C4 View Model . . . . . . . . . . . . . . . 344
10.7.4 The Code View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348
10.7.5 Console Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 350
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 359