The object primer the application developer s

guide to object orientation 2nd ed Edition Scott

W Ambler pdf download

https://ebookgate.com/product/the-object-primer-the-application-
developer-s-guide-to-object-orientation-2nd-ed-edition-scott-w-
ambler/

Get Instant Ebook Downloads – Browse at https://ebookgate.com

Instant digital products (PDF, ePub, MOBI) available
Download now and explore formats that suit you...

The Primer of Object Relations 2nd Ed 2nd Edition Jill

Savege Scharff

https://ebookgate.com/product/the-primer-of-object-relations-2nd-
ed-2nd-edition-jill-savege-scharff/

ebookgate.com

The Unified Process Transition and Production Phases 1st

Edition Scott W. Ambler

https://ebookgate.com/product/the-unified-process-transition-and-
production-phases-1st-edition-scott-w-ambler/

ebookgate.com

Object Oriented Design and Patterns 2nd Edition Cay S.

Horstmann

https://ebookgate.com/product/object-oriented-design-and-patterns-2nd-
edition-cay-s-horstmann/

ebookgate.com

The Use of the Object in Psychoanalysis An Object

Relations Perspective on the Other David E Scharff

https://ebookgate.com/product/the-use-of-the-object-in-psychoanalysis-
an-object-relations-perspective-on-the-other-david-e-scharff/

ebookgate.com
The principles of object oriented JavaScript Zakas

https://ebookgate.com/product/the-principles-of-object-oriented-
javascript-zakas/

ebookgate.com

Modernism s other work the art object s political life 1st

Edition Siraganian

https://ebookgate.com/product/modernism-s-other-work-the-art-object-s-
political-life-1st-edition-siraganian/

ebookgate.com

Object Oriented Oracle Wenny Rahayu

https://ebookgate.com/product/object-oriented-oracle-wenny-rahayu/

ebookgate.com

Emotion and Object 1st Edition John R. S. Wilson

https://ebookgate.com/product/emotion-and-object-1st-edition-john-r-s-
wilson/

ebookgate.com

UML for the IT Business Analyst A Practical Guide to

Object Oriented Requirements Gathering 1st Edition Howard
Podeswa
https://ebookgate.com/product/uml-for-the-it-business-analyst-a-
practical-guide-to-object-oriented-requirements-gathering-1st-edition-
howard-podeswa/
ebookgate.com
The Object Primer
Second Edition
The Application Developer’s Guide to
Object Orientation and the UML

Scott W. Ambler
PUBLISHED BY THE PRESS SYNDICATE OF THE UNIVERSITY OF CAMBRIDGE
The Pitt Building, Trumpington Street, Cambridge, United Kingdom

CAMBRIDGE UNIVERSITY PRESS

The Edinburgh Building, Cambridge CB2 2RU, UK
40 West 20th Street, New York, NY 10011-4211, USA
10 Stamford Road, Oakleigh, VIC 3166, Australia
Ruiz de Alarcón 13, 28014 Madrid, Spain
Dock House, The Waterfront, Capt Town 8001, South Africa

http://www.cambridge.org

Published in association with SIGS Books

© Cambridge University Press 2001

All rights reserved.

This book is in copyright. Subject to statutory exception and to the provisions

of relevant collective licensing agreements, no reproduction of any part may
take place without the written permission of Cambridge University Press.

Any product mentioned in this book may be a trademark of its company.

First edition published by SIGS Books and Multimedia in 1995

First edition published by Cambridge University Press in 1998
Reprinted 1998, 1999
Second edition published 2001

Design by Kevin Callahan and Andrea Cammarata

Composition by Andrea Cammarata
Cover design by Jean Cohn and Andrea Cammarata

Printed in the United States of America

A catalog record for this book is available from the British Library.

Library of Congress Cataloging in Publication data available.

ISBN 0 521 78519 7 paperback

 Contents

Foreword xvii
Preface xix
Acknowledgments xxiii

Chapter 1 • Introduction 1
1.1 The Structured Paradigm versus the Object-Oriented Paradigm 2
1.2 How Is This Book Organized? 3
1.3 How to Read This Book 5
1.4 What You Have Learned 7

Chapter 2 • Object Orientation: A New Software Paradigm 9

2.1 The Potential Benefits of Object Orientation 10
2.1.1 Increased Reusability 10
2.1.2 Increased Extensibility 10
2.1.3 Improved Quality 11
2.1.4 Financial Benefits 12
2.1.5 Increased Chance of Project Success 12
2.1.6 Reduced Maintenance Burden 15
2.1.7 Reduced Application Backlog 17
2.1.8 Managed Complexity 19
2.2 The Potential Drawbacks of OO 20
2.3 Objects Are Here to Stay 22

ix
x The Object Primer

2.4 Object Standards 23

2.5 The Object-Oriented Software Process 23
2.6 What You Have Learned 26
2.7 Review Questions 28

Chapter 3 • Gathering User Requirements 31

3.1 Putting Together a Requirements Modeling Team 34
3.1.1 Choosing Good Subject-Matter Experts 38
3.1.2 Choosing Good Facilitators 39
3.1.3 Choosing Good Scribes 40
3.2 Fundamental Requirements Gathering Techniques 40
3.2.1 Interviewing 40
3.2.2 Brainstorming 42
3.3 Essential Use Case Modeling 44
3.3.1 A Picture Says 1,000 Words: Drawing Use Case Diagrams 45
3.3.2 Identifying Actors 48
3.3.3 Documenting a Use Case 50
3.3.4 Use Cases: Essential versus System 52
3.3.5 Identifying Use Cases 56
3.3.6 Modeling Different Logic Flows: Alternate Courses of Action 61
3.4 Essential User Interface Prototyping 63
3.4.1 An Example Essential User-Interface Model 67
3.4.2 Ensuring System Usability 71
3.4.3 User Interface-Flow Diagramming 72
3.5 Domain Modeling with Class Responsibility Collaborator (CRC) Cards 74
3.5.1 Preparing to CRC Model 77
3.5.2 Finding Classes 77
3.5.3 Finding Responsibilities 82
3.5.4 Defining Collaborators 85
3.5.5 Arranging the CRC Cards 89
3.5.6 The Advantages and Disadvantages of CRC Modeling 91
3.6 Developing a Supplementary Specification 95
3.6.1 Identifying Business Rules 95
3.6.2 Identifying Nonfunctional Requirements and Constraints 97
3.7 Identifying Change Cases 98
3.7.1 Documenting Change Cases 99
3.7.2 The Advantages of Change Cases 100
3.8 Tips for Organizing a Modeling Room 101
3.9 Requirements Tips and Techniques 102
3.10 What You Have Learned 105
3.10.1 The ABC Bank Case Study 105
3.11 Review Questions 108

Chapter 4 • Ensuring Your Requirements Are Correct:

Requirements Validation Techniques 109
4.1 Testing Early and Often 111
4.2 Use Case Scenario Testing 114
4.2.1 The Steps of the Use Case Scenario Testing Process 114
 Contents xi

4.2.2 Creating Use Case Scenarios 116

4.2.3 Acting Out Scenarios 119
4.2.4 The Advantages of Use Case Scenario Testing 126
4.2.5 The Disadvantages of Use Case Scenario Testing 127
4.3 User Interface Walkthroughs 128
4.4 Requirements Reviews 128
4.5 What You Have Learned 131
4.6 Review Questions 131

Chapter 5 • Understanding The Basics: Object-Oriented Concepts 133

5.1 New and Old Concepts Together 134
5.2 OO Concepts from a Structured Point-of-View 136
5.3 Objects and Classes 138
5.4 Attributes and Methods 140
5.5 Abstraction, Encapsulation, and Information Hiding 143
5.5.1 Abstraction 143
5.5.2 Encapsulation 144
5.5.3 Information Hiding 144
5.5.4 An Example 145
5.5.5 Why This Is Important 145
5.6 Inheritance 146
5.6.1 Modeling Inheritance 147
5.6.2 Inheritance Tips and Techniques 148
5.6.3 Single and Multiple Inheritance 150
5.6.4 Abstract and Concrete Classes 152
5.7 Association 152
5.7.1 Modeling Associations 153
5.7.2 How Associations Are Implemented 157
5.8 Aggregation 158
5.8.1 Modeling Aggregation 158
5.8.2 Aggregation Tips and Techniques 160
5.9 Collaboration 160
5.9.1 Messages 161
5.9.2 Collaboration Tips and Techniques 163
5.10 Persistence 165
5.10.1 Persistence Tips and Techniques 166
5.10.2 Persistent Memory: The Object Space 167
5.10.3 Object Databases (ODBs) 167
5.11 Persistent versus Transitory Associations 168
5.11.1 Persistent Associations 169
5.11.2 Transitory Associations: Dependencies 169
5.12 Coupling 170
5.12.1 Coupling Tips and Techniques 171
5.13 Cohesion 172
5.14 Polymorphism 173
5.14.1 An Example: The Poker Game 173
5.14.2 Polymorphism at the University 174
5.15 Interfaces 175
xii The Object Primer

5.16 Components 176

5.17 Patterns 178
5.18 What You Have Learned 179
5.19 Review Questions 180

Chapter 6 • Determining What to Build: Object-Oriented Analysis 181

6.1 System Use Case Modeling 185
6.1.1 Writing System Use Cases 186
6.1.2 Reuse in Use Case Models: <<extend>>, <<include>>,
and Inheritance 190
6.1.3 Good Things to Know About Use Case Modeling 193
6.1.4 Use Case Modeling Tips and Techniques 195
6.2 Sequence Diagrams: From Use Cases to Classes 197
6.2.1 How to Draw Sequence Diagrams 204
6.2.2 Why and When Should You Draw Sequence Diagrams? 207
6.2.3 How to Document Sequence Diagrams 207
6.2.4 A Good Thing to Know About Sequence Diagrams 207
6.3 Conceptual Modeling: Class Diagrams 208
6.3.1 Modeling Classes, Attributes, and Methods 213
6.3.2 Modeling Associations 216
6.3.3 Modeling Dependencies 220
6.3.4 Introducing Reuse Between Classes via Inheritance 220
6.3.5 Modeling Aggregation Associations 222
6.3.6 Modeling Association Classes 224
6.3.7 Documenting Class Models 225
6.3.8 Conceptual Class Modeling Tips 227
6.4 Activity Diagramming 229
6.4.1 How to Draw Activity Diagrams 230
6.4.2 How to Document Activity Diagrams 232
6.5 User Interface Prototyping 232
6.5.1 Determining the Needs of Your Users 232
6.5.2 Building the Prototype 234
6.5.3 Evaluating the Prototype 234
6.5.4 Determining If You Are Finished 234
6.5.5 Good Things to Understand About Prototyping 235
6.5.6 Prototyping Tips and Techniques 235
6.6 Evolving Your Supplementary Specification 237
6.6.1 The Object Constraint Language 237
6.7 Applying Analysis Patterns Effectively 238
6.7.1 The Business Entity Analysis Pattern 238
6.7.2 The Contact Point Analysis Pattern 239
6.7.3 The Advantages and Disadvantages of Patterns 240
6.8 User Documentation 242
6.8.1 Types of User Documentation 242
6.8.2 How to Write User Documentation 243
6.9 Organizing Your Models with Packages 245
6.10 What You Have Learned 246
6.11 Review Questions 246
 Contents xiii

Chapter 7 • Determining How to Build Your System:

Object-Oriented Design 249
7.1 Layering Your Models—Class Type Architecture 254
7.1.1 The User-Interface Layer 256
7.1.2 The Controller/Process Layer 256
7.1.3 The Business/Domain Layer 260
7.1.4 The Persistence Layer 260
7.1.5 The System Layer 261
7.2 Class Modeling 262
7.2.1 Inheritance Techniques 263
7.2.2 Association and Dependency Techniques 266
7.2.3 Aggregation and Composition Techniques 270
7.2.4 Modeling Methods During Design 272
7.2.5 Modeling Attributes During Design 281
7.2.6 Introducing Interfaces Into Your Model 286
7.2.7 Class Modeling Design Tips 289
7.3 Applying Design Patterns Effectively 293
7.3.1 The Singleton Design Pattern 294
7.3.2 The Façade Design Pattern 295
7.3.3 Tips for Applying Patterns Effectively 295
7.4 State Chart Modeling 296
7.4.1 How to Draw a State Diagram 299
7.4.2 When and Why Should You Draw State Diagrams? 300
7.4.3 State Diagrams and Inheritance 301
7.5 Collaboration Modeling 301
7.5.1 Drawing Collaboration Diagrams 303
7.5.2 Collaboration and Inheritance 304
7.5.3 When Should You Draw Collaboration Diagrams? 305
7.6 Component Modeling 306
7.6.1 How to Develop a Component Model 306
7.6.2 Implementing a Component 312
7.7 Deployment Modeling 312
7.7.1 How to Develop a Deployment Model 313
7.7.2 When Should You Create Deployment Models? 315
7.8 Relational Persistence Modeling 316
7.8.1 Keys and Object Identifiers 316
7.8.2 The Basics of Mapping Objects to RDBs 324
7.8.3 Mapping Associations, Aggregation, and Composition 329
7.8.4 Drawing Persistence Models 333
7.8.5 When Should You Develop Persistence Models? 334
7.9 User Interface Design 335
7.9.1 User-Interface Design Principles 335
7.9.2 Techniques for Improving Your User-Interface Design 336
7.9.3 User-Interface Flow Diagramming 339
7.9.4 User-Interface Design Standards and Guidelines 340
7.10 Design Tips 341
7.11 What You Have Learned 344
7.12 Review Questions 344
7.12.1 The Bank Case Study Six Months Later 346
xiv The Object Primer

Chapter 8 • Object-Oriented Testing 347

8.1 What Is Programming? 350
8.2 From Design to Java Code 352
8.2.1 Implementing a Class In Java 354
8.2.2 Declaring Instance Attributes In Java 356
8.2.3 Implementing Instance Methods In Java 358
8.2.4 Implementing Static Methods and Attributes in Java 360
8.2.5 Implementing Constructors 364
8.2.6 Encapsulating Attributes with Accessors 366
8.2.7 Implementing Inheritance In Java 372
8.2.8 Implementing Interfaces In Java 372
8.2.9 Implementing Associations, Aggregation,
and Composition In Java 377
8.2.10 Implementing Dependencies 384
8.2.11 Implementing Collaboration in Java 385
8.2.12 Implementing Business Rules 385
8.3 From Design to Persistence Code 386
8.3.1 Strategies for Implementing Persistence Code 387
8.3.2 Defining and Modifying Your Persistence Schema 389
8.3.3 Creating, Retrieving, Updating, and Deleting Data 389
8.3.4 Implementing Behavior in a Relational Database 391
8.4 Programming Tips 393
8.4.1 Techniques for Writing Clean Code 393
8.4.2 Techniques for Writing Effective Documentation 396
8.4.3 Miscellaneous 398
8.5 What You Have Learned 401
8.6 Review Questions 401

Chapter 9 • Object-Oriented Testing 403

9.1 Overcoming Misconceptions About Object-Oriented Testing 404
9.1.1 Misconception #1: With Objects You Do Less Testing 405
9.1.2 Misconception #2: Structured Testing Techniques Are Sufficient 406
9.1.3 Misconception #3: Testing the User Interface Is Sufficient 406
9.2 Full Lifecycle Object-Oriented Testing (FLOOT) 406
9.2.1 Regression Testing 407
9.2.2 Quality Assurance 408
9.2.3 Testing Your Requirements, Analysis, and Design Models 409
9.2.4 Testing Your Source Code 412
9.2.5 Testing Your System in its Entirety 418
9.2.6 Testing by Users 420
9.3 From Test Cases to Defects 422
9.4 What You Have Learned 424
9.5 Review Questions 425

Chapter 10 • Putting It All Together: Software Process 427

10.1 What Is So Different About Object-Oriented Development? 429
10.2 What Is a Software Process? 430
10.3 Why Do You Need a Software Process? 431
 Contents xv

10.4 From Waterfall/Serial Development… 432

10.5 …to Iterative Development… 433
10.6 …and Incremental Development 435
10.7 The Development Process Presented in This Book 437
10.8 Process Patterns of the Object-Oriented Software Process (OOSP) 438
10.9 The Unified Process 442
10.10 Other Processes 444
10.10.1 eXtreme Programming (XP) 444
10.10.2 The Microsoft Solutions Framework (MSF) 448
10.10.3 The OPEN Process 449
10.10.4 Catalysis 449
10.11 When to Use Objects 450
10.12 When Not to Use Objects 451
10.13 What You Have Learned 452
10.14 Review Questions 453

Chapter 11 • Where to Go From Here 455

11.1 The Post-2000 (P2K) Environment 456
11.1.1 New Software Strategies 456
11.1.2 Enabling Technologies 457
11.1.3 Leading-Edge Development Techniques 459
11.1.4 Modern Software Processes 461
11.1.5 Object Programming Languages 462
11.1.6 Internet Development Languages 465
11.2 Skills for Specific Positions 466
11.2.1 Business Analyst 466
11.2.2 IT Senior Manager 466
11.2.3 Object Modeler 467
11.2.4 Persistence Modeler 467
11.2.5 Persistence Administrator 468
11.2.6 Programmer 468
11.2.7 Project Manager 468
11.2.8 Quality Assurance Engineer 469
11.2.9 Software Architect 469
11.2.10 Test Engineer 470
11.3 Continuing Your Learning Process 470
11.3.1 Take General Introductory Training 471
11.3.2 Gain Hands-on Experience 471
11.3.3 Obtain Mentoring 471
11.3.4 Work in a Learning Team 473
11.3.5 Read, Read, Read 473
11.3.6 Take Advanced Training 474
11.4 What You Have Learned 474
11.5 Parting Words 474

Glossary 475
References and Recommended Reading 499
Index 505
 Developers are good at building systems right.

What we’re not good at is building the right system.

Chapter 1
Introduction

What You Will Learn in This Chapter

What is object orientation?

The difficulties encountered with traditional development methods
How this book is organized
How to read this book

Why You Need to Read This Chapter

To understand why you should consider embracing object-oriented techniques,

you need to understand the challenges of the structured paradigm and how the
object paradigm addresses them.

1
2 The Object Primer

This book describes the object-oriented (OO) paradigm, a development

strategy based on the concept that systems should be built from a collec-
tion of reusable components called objects. Instead of separating data and
functionality, as is done in the structured paradigm, objects encompass
both. While the object-oriented paradigm sounds similar to the struc-
tured paradigm, as you will see in this book, it is actually quite different.
A common mistake that many experienced developers make is to assume
they have been “doing objects” all along, just because they have been
applying similar software-engineering principles. The reality is you must
recognize that objects are different so you can start your learning experi-
ence successfully.

1.1 The Structured Paradigm versus the Object-

Oriented Paradigm
The structured paradigm is a development strategy based on the concept
that a system should be separated into two parts: data (modeled using a
data/persistence model) and functionality (modeled using a process
model). In short, using the structured approach, you develop applica-
tions in which data is separate from behavior in both the design model
and in the system implementation (that is, the program).
On the other hand, as you see in Figure 1-1, the main concept behind
the object-oriented paradigm is that instead of defining systems as two
separate parts (data and functionality), you now define systems as a col-
lection of interacting objects. Objects do things (that is, they have func-
tionality) and they know things (they have data). While this sounds
similar to the structured paradigm, it really isn’t.
Consider the design of an information system for a university. Taking
the structured approach, you would define the layout of a database and
the design of a program to access that data. In the database would be
information about students, professors, rooms, and courses. The program
would enable users to enroll students in courses, assign professors to
teach courses, schedule courses in certain rooms, and so on. The program
would access and update the database, in effect supporting the daily
business of the school.
Now consider the university information system from an object-
oriented perspective. In the real world, there are students, professors,
rooms, and courses. All of these things would be considered objects. In

DEFINITION
Paradigm. (pronounced para-dime) An overall strategy or viewpoint for doing
things. A paradigm is a specific mindset.
 Chapter 1 • Introduction 3

Object
Object

Functions
and Data
Procedures Object Object

A Structured Application An Object Application

the real world, students know things (they have names, addresses, birth Figure 1-1.
dates, telephone numbers, and so on) and they do things (enroll in Comparing the
courses, drop courses, and pay tuition). Professors also know things (the structured and
courses they teach and their names) and they do things (input marks and object-oriented
paradigms
make schedule requests). From a systems perspective, rooms know things
(the building they’re in and their room number) and should be able to
do things, too (such as tell you when they are available and enable you
to reserve them for a certain period of time). Courses also know things
(their title, description, and who is taking the course) and should be able
to do things (such as letting students enroll in them or drop them).
To implement this system, we would define a collection of classes (a class
is a generic representation of similar objects) that interact with each other.
For example, we would have “Course,” “Student,” “Professor,” and “Room”
classes. The collection of these classes would make up our application,
which would include both the functionality (the program) and the data.
As you can see, the OO approach results in a completely different view For individuals,
of what an application is all about. Rather than having a program that OO is a whole new
accesses a database, we have an application that exists in what is called way to think.
For organizations,
an object space. The object space is where both the program and the data
OO requires a
for the application reside. I discuss this concept in further detail in Chap- complete change
ter 5 but, for now, think of the object space as virtual memory. in its system
development
culture.
1.2 How Is This Book Organized?
The Object Primer covers leading-edge OO techniques and concepts that
have been proven in the development of real-world applications. It covers
in detail why you should learn this new approach called object orientation,
requirements techniques, such as use cases and CRC modeling, OO
4 The Object Primer

DEFINITIONS
Class. A template from which objects are created (instantiated). Although in
the real world Doug, Wayne, and Bill are all “student objects,” we would model
the class “Student” instead.
Object space. The memory space, including all accessible permanent storage,
in which objects exist and interact with one another.
Object. A person, place, thing, concept, event, screen, or report. Objects both
know things (that is, they have data) and they do things (that is, they have
functionality).
Object-oriented paradigm. A development strategy based on the concept of
building systems from reusable components called objects.
OO. An acronym used interchangeably for two terms: Object-oriented and
object orientation. For example, when we say OO programming, we really
mean object-oriented programming. When we say this is a book that describes
OO, we really mean this it is a book that describes object orientation.

The Object Primer concepts, OO analysis and design using the UML modeling techniques,
covers everything OO programming, OO testing, and the OO software process. The book
you need to know to ends with a discussion of how to continue your learning process, including
get you started in
descriptions of common object-oriented technologies and techniques you
OO development.
might want to consider applying on software projects.
Figure 1-2 depicts the organization of The Object Primer, showing the
individual chapters and the relationships between them. Table 1-1 sum-
marizes the contents of each chapter. On the left side of the diagram are
the chapters that describe the fundamental activities of the software
process, such as gathering requirements, object-oriented analysis, and
object-oriented programming. The arrows between the boxes represent
the general relationships between the chapters: you see the chapters
describing gathering requirements, validating requirements, and object-
oriented analysis are closely related to one another. Chapter 9 covers
object-oriented testing and describes testing techniques that should be
used to validate your analysis, design, and programming efforts. Along
the right-hand side of Figure 1-2 are listed several “supporting” chapters,
chapters that present material that is critical to your understanding of
the object-oriented paradigm.

DEFINITION
Unified Modeling Language (UML). The definition of a standard modeling
language for object-oriented software, including the definition of a modeling
notation and the semantics for applying it as defined by the Object Manage-
ment Group (OMG).
 Chapter 1 • Introduction 5

Gather Validate Object-Oriented

Requirements Requirements Paradigm
(Chapter 3) (Chapter 4) (Chapter 2)

Object-Oriented Object-Oriented
Analysis Concepts
(Chapter 6) (Chapter 5)

Object-Oriented Object-Oriented Object-Oriented

Testing Design Software Process
(Chapter 9) (Chapter 7) (Chapter 10)

Object-Oriented Where To Go From

Programming Here
(Chapter 8) Chapter 11

Figure 1-2.
The organization of
1.3 How to Read This Book this book

Programmers, Designers, and Project Managers

Read the entire book, cover to cover. It’s tempting to skip to Chapter 5,
which overviews object-oriented concepts, and start reading from there,
but that would be a major mistake. Chapter 5 builds on many of the
ideas presented in the first four chapters; therefore, reading ahead is not
to your advantage.

Business Analysts and User Representatives

Chapters 3 and 4 are written specifically for you, describing in detail the
techniques for gathering and validating the user requirements for an OO
application. Business analysts should also read Chapter 5, which
6 The Object Primer

Table 1-1. The material contained in each chapter

Chapter Description

2: A New Software Paradigm Discussion of the advantages and disadvantages of object ori-
entation, why objects are here to stay, and an overview of the
software process.

3: Gathering Requirements Description of requirements gathering techniques, including

use cases, change cases, CRC modeling, interviewing, and
user interface prototyping. A discussion of how the tech-
niques work together is included.

4: Validating Requirements Description of requirements validation techniques such as use

case scenario testing and requirements walkthroughs.

5: Object-Oriented Concepts Description of the fundamental concepts of object orienta-

tion, including inheritance, polymorphism, aggregation, and
encapsulation.

6: Object-Oriented Analysis Description of common object-oriented analysis techniques

such as sequence diagrams and class diagrams. A description
of how to make the transition from requirements to analysis is
presented, as well as how all the techniques fit together.

7: Object-Oriented Design Description of common object-oriented design techniques

such as class diagrams, state chart diagrams, collaboration
diagrams, and persistence models. A description of how to
make the transition from analysis to design is presented, as
well as how the techniques fit together.

8: Object-Oriented Programming Overview of common object-oriented programming tips and

techniques. A discussion of how to make the transition from
design to coding is presented.

9: Object-Oriented Testing Overview of the Full Lifecycle Object-Oriented Testing (FLOOT)

methodology and techniques.

10: Object-Oriented Software Process Overview of the Object-Oriented Software Process (OOSP)
and the enhanced lifecycle of the Unified Process.

11: Where to Go From Here Discussion of what you need to do to continue your OO
learning process, including a description of leading object
technologies and techniques such as Java, Enterprise Java-
Beans (EJB), C++, and component-based development.
 Chapter 1 • Introduction 7

DEFINITION
Full lifecycle object-oriented testing (FLOOT). A testing methodology for
object-oriented development that comprises testing techniques that, taken
together, provide methods to verify that your application works correctly at
each stage of development.

describes the fundamental concepts of object orientation, and Chapter 6,

which describes OO analysis techniques. Both groups should also read
Chapter 10, which describes the overall software process for object-
oriented software—this will help put the overall effort into context for
you and give you a greater appreciation of how software is developed,
maintained, and supported.

Students
Like the first group of people, you should also read this book from cover
to cover. Furthermore, you should read this book two or three weeks
before your midterm test on object orientation, and not the night before
the exam. This stuff takes a while to sink in (actually it takes much
longer than a few weeks, but there’s only so much time in a school term).

1.4 What You Have Learned

The object-oriented paradigm is a software development strategy based
on the idea of building systems from reusable components called objects.
As you saw in Figure 1-1, the primary concept behind the object-oriented
paradigm is, instead of defining systems as two separate parts (data and
functionality), you now define systems as a collection of interacting
objects. Objects do things (that is, they have functionality) and they
know things (that is, they have data).
 Your requirements define what is requested to be built.

Your analysis defines what will be built.

Chapter 6
Determining What to
Build: Object-Oriented
Analysis

What You Will Learn In This Chapter

How to develop a system use case model from an essential use case model
How to develop sequence diagrams
How to develop a conceptual class model from a domain model
How to develop activity diagrams
How to develop a user interface prototype
How to evolve your supplementary specification
How to apply the Object Constraint Language (OCL)
How to apply analysis patterns
How to write user documentation
How to apply packages on your diagrams

Why You Need to Read This Chapter

Your requirements model, although effective for understanding what your users
want to have built, is not as effective at understanding what will be built.
Object-oriented analysis techniques, such as system use case modeling, sequence
diagramming, class modeling, activity diagramming, and user interface
prototyping are used to bridge the gap between requirements and system design.

181
182 The Object Primer

Requirements The purpose of analysis is to understand what will be built. This is similar
engineering to requirements gathering, described in Chapter 3, the purpose of which
focuses on
is to determine what your users want to have built. The main difference
understanding
is that the focus of requirements gathering is on understanding your
users and their
usage, whereas users and their potential usage of the system, whereas the focus of analy-
analysis focuses sis shifts to understanding the system itself.
on understanding Figure 6-1 depicts the main artifacts of your analysis efforts and the
what needs to be relationships between them. The solid boxes indicate major analysis arti-
built. facts, whereas the dashed boxes represent your major requirements arti-
facts. As with the previous Figure 3-1, the arrows represent “drives”
relationships; for example, you see that information contained in your
CRC model affects information in your class model and vice versa. Figure
6-1 has three important implications. First, analysis is an iterative process.

Essential
Use Case
Use Case
Model
Model

Sequence Activity
Business Rules
Diagram Diagram

Class Model
CRC Model
(Analysis)

User Interface User Interface

Flow Diagram Prototype

Figure 6-1. Essential

User Interface
Overview of analysis
Prototype
artifacts and their
relationships
 Chapter 6 • Determining What to Build: Object-Oriented Analysis 183

Second, taken together, requirements gathering and analysis are highly

interrelated and iterative. As you see in Chapter 7, which describes object-
oriented design techniques, analysis and design are similarly interrelated
and iterative. Third, the “essential” models, your essential use case model
and your essential user interface prototype, evolve into corresponding
analysis artifacts—respectively, your use case model and user interface
prototype. What isn’t as obvious is that your Class Responsibility Collabo-
rator (CRC) model evolves into your analysis class model.
Your use case model describes how your users work with your system,
reflecting the business rules pertinent to your system, as well as aspects
of your user interface model. You can use either Unified Modeling Lan-
guage (UML) sequence diagrams or UML activity diagrams to flesh out
and verify the logic contained in your use cases. Furthermore, you see
that sequence diagrams act as a bridge to your class model, which depicts
the static structure of the classes from which your system will be built.
Your user interface model, including your user interface prototype and
your user interface flow diagram (see Chapter 3), also drives changes to
your class model.
An important concept to note about Figure 6-1, and similarly Figures Analysis is an
7-1 and 8-1, is that every possible “drives” relationship is not shown. For iterative process.
example, as you are developing your use case model, most likely you will
realize you are missing a feature in your user interface, yet a relationship
doesn’t exist between these two artifacts. From a pure/academic point of
view, when you realize your use case model conflicts with your user-
interface model, you should first consider what the problem is, update
your use case model appropriately, propagate the change to your essen-
tial use case model, and then to your essential user interface model, and,
finally, into your user interface model. Yes, you may, in fact, take this
route. Just as likely, and probably more so, is that you will, instead,
update both your use case model and user interface model together, and
then propagate the changes to the corresponding requirements artifacts.
This is an important aspect of iterative development. You don’t necessar-
ily work in a defined order; instead, your work reflects the relationships
between the artifacts you evolve over time.
A second important concept is the difference between a model and a
diagram. A diagram is a picture—typically consisting of bubbles con-
nected by lines documented with labels—that depicts an abstraction of
a portion or an aspect of a system. A model is also an abstraction,
although it is more robust because it consists of zero or more diagrams,
plus associated documentation. For example, a class model is composed
of a UML class diagram and the specifications of the classes and associa-
tions depicted on that diagram, whereas a CRC model is a collection of
CRC cards.
184 The Object Primer

DEFINITIONS
Activity diagram. A UML diagram used to model high-level business processes or the transitions
between states of a class (in this respect, activity diagrams are effectively specializations of state chart
diagrams).
Class diagram. Shows the classes of a system and the associations between them.
Class model. A class diagram and its associated documentation.
Class Responsibility Collaborator (CRC) card. A standard index card that has been divided into
three sections: one indicating the name of the class the card represents, one listing the responsibilities
of the class, and the third listing the names of the other classes with which this one collaborates to ful-
fill its responsibilities.
Class Responsibility Collaborator (CRC) model. A collection of CRC cards that model all or part
of a system.
Diagram. A visual representation of a problem or solution to a problem.
Essential use case. A simplified, abstract, generalized use case that captures the intentions of a user
in a technology and implementation independent manner.
Essential use case model. A use case model comprised of essential use cases.
Essential user interface prototype. A low-fidelity prototype of a system’s user interface that mod-
els the fundamental, abstract characteristics of a user interface.
Model. An abstraction describing a problem domain and/or a solution to a problem domain. Tradi-
tionally models are thought of as diagrams plus their corresponding documentation, although non-
diagrams, such as interview results and collections of CRC cards, are also considered to be models.
Project stakeholder. Anyone who could be materially affected by the implementation of a new sys-
tem or application.
Prototype. A simulation of an item, such as a user interface or a system architecture, the purpose of which
is to communicate your approach to others before significant resources are invested in the approach.
Sequence diagram. A diagram that models the sequential logic, in effect, the time ordering of messages.
Use case. A sequence of actions that provide a measurable value to an actor.
Use case diagram. A diagram that shows use cases, actors, and their interrelationships.
Use case model. A model comprised of a use case diagram, use case definitions, and actor defini-
tions. Use case models are used to document the behavior requirements of a system.
User interface (UI). The user interface of software is the portion the user directly interacts with,
including the screens, reports, documentation, and software support (via telephone, electronic mail,
and so on).
User interface flow diagram. A diagram that models the interface objects of your system and the
relationships between them. Also know as an interface-flow diagram, a windows navigation diagram,
or an interface navigation diagram.
User interface prototype. A prototype of the user interface (UI) of a system. User interface proto-
types could be as simple as a hand-drawn picture or a collection of programmed screens, pages, or
reports.
 Chapter 6 • Determining What to Build: Object-Oriented Analysis 185

6.1 System Use Case Modeling

During analysis, your main goal is to evolve your essential use cases into System use cases
system use cases. The main difference between an essential use case and a reflect analysis
system use case is, in the system use case, you include high-level imple- decisions and,
arguably, even
mentation decisions. For example, a system use case refers to specific user-
design decisions.
interface components—such as screens, HTML pages, or reports—some-
thing you wouldn’t do in an essential use case. During analysis, you make
decisions regarding what will be built, information reflected in your use
cases, and, arguably, even how it will be built (effectively design). Because
your use cases refer to user interface components, and because your user
interface is worked on during design, inevitably design issues will creep
into your use cases. For example, a design decision is whether your user
interface is implemented using browser-based technology, such as HTML
pages or graphical user interface (GUI) technology such as Windows.
Because your user interface will work differently depending on the imple-
mentation technology, the logic of your system use cases, which reflect
the flow of your user interface, will also be affected.
What is a system use case model? Similar to essential use case models
described in Chapter 3, a system use case model is composed of a use case
diagram (Rumbaugh, Jacobson, and Booch, 1999) and the accompanying
documentation describing the use cases, actors, and associations. Figure 6-4,
which provides an example of a use case diagram, depicts a collection of
use cases, actors, their associations, a system boundary box (optional), and
packages (optional). A use case describes a sequence of actions that provide
a measurable value to an actor and is drawn as a horizontal ellipse. An
actor is a person, organization, or external system that plays a role in one
or more interactions with your system. Actors are drawn as stick figures.
Associations between actors and classes are indicated in use case diagrams,
a relationship exists whenever an actor is involved with an interaction
described by a use case. Associations also exist between use cases in system
use case models, a topic discussed in the following section, something that
didn’t occur in essential use case models. Associations are modeled as lines
connecting use cases and actors to one another, with an optional arrow-
head on one end of the line indicating the direction of the initial invoca-
tion of the relationship. The rectangle around the use cases is called the
system boundary box and, as the name suggests, it delimits the scope of
your system—the use cases inside the rectangle represent the functionality
you intend to implement. Finally, packages are UML constructs that enable
you to organize model elements (such as use cases) into groups. Packages
are depicted as file folders that can be used on any of the UML diagrams,
including both use case diagrams and class diagrams. Section 6.9 presents
strategies to apply packages effectively in your UML models.
186 The Object Primer

6.1.1 Writing System Use Cases

Writing system use cases is fairly straightforward. You begin with your
essential use cases and modify them to reflect the information captured
within your UML sequence diagrams (Section 6-2), your UML activity
diagrams (Section 6-7), your user interface prototype (Section 6-5), and
the contents of your evolved supplementary specification (Section 6-6).
You will also rework your use cases to reflect opportunities for reuse,
applying the UML stereotypes of <<extend>> and <<include>>, as well as
the object-oriented concept of inheritance, techniques covered next in
Section 6.1.2.
Consider the system use case presented in Figure 6-4. Notice how it is
similar to the essential use cases of Chapter 3, with the main exceptions
being the references to user interface elements and references to other use
cases. The use case has a basic course of action, which is the main start-to-
finish path the user will follow. It also has three alternate courses of
action, representing infrequently used paths through the use case, excep-
tions, or error conditions. Notice how I have added an identifier, some-
thing I could have done for the essential use cases depicted in Chapter 3.
It also has sections labeled “Extends,” “Includes,” and “Inherits From”
indicating the use cases, if any, with which this use case is associated. I
discuss what you need to put here in Section 6.1.1.
Two common Until now, I have presented use cases in what is called narrative
styles exist for style—the use case of Figure 6-2 is written this way—where the basic and
writing use cases: alternate courses of action are written one step at a time. A second style,
narrative style
called the action-response style, presents use case steps in columns, one
and action-
column for each actor and a second column for the system. Figure 6-3
response style.
Choose one style presents the basic course of action for Figure 6-4 rewritten using this
and stick to it. style. For the sake of brevity, I didn’t include rewritten versions of the
alternate courses. Of the two columns, one is for the Student actor and
one for the system, because only one actor is involved in this use case.

DEFINITIONS
Extend association. A generalization relationship where an extending use case
continues the behavior of a base use case. The extending use case accomplishes
this by inserting additional action sequences into the base use case sequence.
This is modeled using a use case association with the <<extend>> stereotype.
Include association. A generalization relationship denoting the inclusion of
the behavior described by a use case within another use case. This is modeled
using a use case association with the <<include>> stereotype Also known as a
“uses” or a “has-a” relationship.
Chapter 6 • Determining What to Build: Object-Oriented Analysis 187

Name: Enroll in Seminar Figure 6-2.

Identifier: UC 17 “Enroll in seminar”
Description: Enroll an existing student in a seminar for which he is eligible. written in narrative
style
Preconditions: The Student is registered at the University.
Postconditions: The Student will be enrolled in the course he wants if he
is eligible and room is available.
Extends: —
Includes: —
Inherits From: -—
Basic Course of Action:
1. The student wants to enroll in a seminar.
2. The student inputs his name and student number into the system via
“UI23 Security Login Screen.”
3. The system verifies the student is eligible to enroll in seminars at the
university, according to business rule “BR129 Determine Eligibility to
Enroll.”
4. The system displays “UI32 Seminar Selection Screen,” which indicates
the list of available seminars.
5. The student indicates the seminar in which he wants to enroll.
6. The system validates the student is eligible to enroll in the seminar,
according to the business rule “BR130 Determine Student Eligibility to
Enroll in a Seminar.”
7. The system validates the seminar fits into the existing schedule of the
student, according to the business rule “BR143 Validate Student Semi-
nar Schedule.”
8. The system calculates the fees for the seminar based on the fee pub-
lished in the course catalog, applicable student fees, and applicable
taxes. Apply business rules “BR 180 Calculate Student Fees” and
“BR45 Calculate Taxes for Seminar.”
9. The system displays the fees via “UI33 Display Seminar Fees Screen.”
10. The system asks the student whether he still wants to enroll in the
seminar.
11. The student indicates he wants to enroll in the seminar.
12. The system enrolls the student in the seminar.
13. The system informs the student the enrollment was successful via
“UI88 Seminar Enrollment Summary Screen.”
14. The system bills the student for the seminar, according to business rule
‘BR100 Bill Student for Seminar.”
15. The system asks the student if he wants a printed statement of the
enrollment.
16. The student indicates he wants a printed statement.
17. The system prints the enrollment statement “UI89 Enrollment Sum-
mary Report.”
18. The use case ends when the student takes the printed statement.

continued on page 90
188 The Object Primer

Alternate Course A: The Student is Not Eligible to Enroll in Seminars

A.3. The system determines the student is not eligible to enroll in seminars.
A.4. The system informs the student he is not eligible to enroll.
A.5. The use case ends.
Alternate Course B: The Student Does Not Have the Prerequisites
B.6. The system determines the student is not eligible to enroll in the sem-
inar he has chosen.
B.7. The system informs the student he does not have the prerequisites.
B.8. The system informs the student of the prerequisites he needs.
B.9. The use case continues at Step 4 in the basic course of action.
Alternate Course C: The Student Decides Not to Enroll in an Available
Seminar
C.4. The student views the list of seminars and doesn’t see one in which
he wants to enroll.
C.5. The use case ends.

The advantage of the action-response style is it is easier to see how actors

interact with the system and how the system responds. The disadvantage
is, in my opinion, it is a little harder to understand the flow of logic of
the use case. This is particularly true for alternate courses and their refer-
ences to other courses of action. The style you choose is a matter of pref-
erence. What’s important is that your team and, ideally, your
organization selects one style and sticks to it.
I want to point out an important style issue pertaining to Steps 2 and
3 of the use case of Figure 6-2. I could just as easily have defined a pre-
condition that the student has already logged in to the system and has
been verified as an eligible student. Actually, this should be two precon-
ditions: one for being logged in and one for being eligible (this way, the
preconditions are cohesive). To support the first precondition, being
logged in, I would be tempted to write a “Log Into System” use case that
would describe the process of logging in and validating the user, perhaps
including alternate courses for obtaining a login identifier. This use case
would be a candidate for inclusion in your common, enterprise model
because it is a feature that should belong to your organization’s shared
technical architecture. Cross-project issues such as this are among the
topics I cover in Process Patterns (Ambler, 1998b) and More Process Patterns
(Ambler, 1999), the third and fourth books in this series. The second pre-
condition, the one for being eligible to enroll, likely doesn’t need its own
use case, but I would still reference the appropriate business rule.
 Chapter 6 • Determining What to Build: Object-Oriented Analysis 189

Student System
1. The student wants to enroll in a seminar. 3. The system verifies the student is eligible to enroll
2. The student inputs his name and student number in seminars at the university, according to business
into the system via “UI23 Security Login Screen.” rule “BR129 Determine Eligibility to Enroll.”
4. The system displays “UI32 Seminar Selection
Screen,” which indicates the list of available seminars.
5. The student indicates the seminar in which she 6. The system validates the student is eligible to
wants to enroll. enroll in the seminar, according to the business
rule “BR130 Determine Student Eligibility to Enroll
in a Seminar.”
7. The system validates the seminar fits into the
existing schedule of the student, according to the
business rule “BR143 Validate Student Seminar
Schedule.”
8. The system calculates the fees for the seminar
based on the fee published in the course catalog,
applicable student fees, and applicable taxes.
Apply business rules “BR 180 Calculate Student
Fees” and “BR45 Calculate Taxes for Seminar.”
9. The system displays the fees via “UI33 Display
Seminar Fees Screen.”
10. The system asks the student whether she still
wants to enroll in the seminar.
11. The student indicates she wants to enroll in the 12. The system enrolls the student in the seminar.
seminar. 13. The system informs the student the enrollment
was successful via “UI88 Seminar Enrollment Sum-
mary Screen.”
14. The system bills the student for the seminar,
according to business rule “BR100 Bill Student for
Seminar.”
15. The system asks the student if she wants a
printed statement of the enrollment.
16. The student indicates she wants a printed 17. The system prints the enrollment statement
statement. “UI89 Enrollment Summary Report.”
18. The use case ends when the student takes the
printed statement.

Figure 6-3.
Basic course of
action for “Enroll in
Seminar” written in
action-response style
190 The Object Primer

6.1.2 Reuse in Use Case Models: <<extend>>, <<include>>,

and Inheritance
You can indicate One of your goals during analysis is to identify potential opportunities
potential for reuse, a goal you can work toward as you are developing your use case
opportunities for model. Potential reuse can be modeled through four generalization rela-
reuse on your use
tionships supported by the UML use case models: extend relationships
case models
between use cases, include relationships between use cases, inheritance
between use cases, and inheritance between actors.

6.1.2.1 Extend Associations Between Use Cases

The <<extend>> An extend association, formerly called an extends relationship in the
stereotype is used UML v1.2 and earlier, is a generalization relationship where an extending
to indicate an
use case continues the behavior of a base use case. The extending use
extend association.
case accomplishes this by conceptually inserting additional action
sequences into the base use case sequence. This enables an extending use
case to continue the activity sequence of a base use case when the appro-
priate extension point is reached in the base use case and the extension
condition is fulfilled. When the extending use case activity sequence is
completed, the base use case continues. In Figure 6-4, you see that the
use case “Enroll International Student in University” extends the use case
“Enroll in University;” the notation for doing so is simply a normal use
case association with the stereotype of <<extend>>. In this case, “Enroll
in University” is the base use case and “Enroll International Student in
University” is the extending use case.
Extending use cases An extending use case is, effectively, an alternate course of the base
are often introduced use case. In fact, a good rule of thumb is you should introduce an
to resolve extending use case whenever the logic for an alternate course of action is
complexities of
at a complexity level similar to that of your basic course of action. I also
alternate courses.
like to introduce an extending use case whenever I need an alternate
course for an alternate course; in this case, the extending use case would
encapsulate both alternate courses. Many use case modelers avoid the use
of extend associations as this technique has a tendency to make use case
diagrams difficult to understand. My preference is to use extend associa-
tions sparingly. Note that the extending use case—in this case “Enroll
International Student in University”—would list “UC33 Enroll in Univer-
sity,” the base use case, in its “Extends” list.
Extension points Just as you indicate the point at which the logic of an alternate course
are placed in base replaces the logic of a portion of the basic course of action for a use case,
use cases to you need to be able to do the same thing for an extending use case. This is
indicate where the
accomplished through the use of an extension point, which is simply a
logic of the
extending use case
marker in the logic of a base use case indicating where extension is
replaces that of allowed. Figure 6-5 presents an example of how an extension point would
the base use case. be indicated in the basic course of action of the “Enroll in University” use
 Chapter 6 • Determining What to Build: Object-Oriented Analysis 191

Figure 6-4.
The opportunities
for reuse in use case
models
Registrar

Enroll in Enroll in
<<include>>
University Seminar

Student

<<extend>>

Enroll Enroll Family

International Student Member in
in University University

International
Student

case. Notice how the identifier and the name of the use case is indicated.
If several use cases extended this one from the same point, then each one
would need to be listed. A condition statement, such as “Condition:
Enrollee is an international student,” could have been indicated immedi-
ately following the name of the use but, in this example, it was fairly
obvious what was happening.

6.1.2.2 Include Associations Between Use Cases

A second way to indicate potential reuse within use case models exists in An include
the form of include associations. An include association, formerly known association is the
as a uses relationship in the UML v1.2 and earlier, is a generalization rela- equivalent of a
tionship denoting the inclusion of the behavior described by another use function call.

case. The best way to think of an include association is that it is the invo-
cation of a use case by another one. In Figure 6-4, notice that the use case

Figure 6-5.
4. The system displays “UI43 Student Information Entry.” [Extension Point: Documenting an
UC34 Enroll International Student In University.] extension point
5. The student… within a use case
192 The Object Primer

DEFINITIONS
Base use case. A use case extended by another via an extend association.
Extending use case. A use case that extends another use case via an extend
association.
Extension point. A marker in a use case where extension is allowed.

“Enroll in University” includes the use case “Enroll in Seminar”; the nota-
tion for doing so is simply a normal use case association with the stereo-
type of <<include>>. Figure 6-6 presents an example of how you would
indicate where the use case is included in the logic of the including use
case. Similar to calling a function or invoking an operation within source
code, isn’t it? Object-oriented programming is covered in Chapter 8.
You use include associations whenever one use case needs the behav-
ior of another. Introducing a new use case that encapsulates similar logic
that occurs in several use cases is quite common. For example, you may
discover that several use cases need the behavior to search for and then
update information about students, indicating the potential need for an
“Update Student Record” use case included by the other use cases.
As you would expect, the use case “Enroll in University” should list
“UC17 Enroll in Seminar” in its “Includes” list. Why should you bother
maintaining an “Includes” and an “Extends” list in your use cases? The
answer is simple: Your use cases should stand on their own; you shouldn’t
expect people to have your use case diagram in front of them. Yes, it
would be nice if everyone has access to the use case diagram because it
also contains this information, but the reality is that sometimes you use
different tools to document each part of your model. For example, your
diagrams could be drawn using a drawing package and your use cases
documented in a word processor. Some of your project stakeholders may
have access to the word processor you are using, but not the drawing
package. The main disadvantage of this approach is you need to main-
tain these two lists in parallel with the diagram, the danger being they
may become unsynchronized.

Figure 6-6.
Indicating the 8. The student indicates the seminar(s) she wants to take via the use case
inclusion of a UC 17 Enroll in Seminar.
use case 9. The student…
 Chapter 6 • Determining What to Build: Object-Oriented Analysis 193

6.1.2.3 Inheritance
Use cases can inherit from other use cases, offering a third opportunity to Use cases may
indicate potential reuse. Figure 6-4 depicts an example of this, showing inherit from other
that “Enroll Family Member in University” inherits from the “Enroll In use cases.
University” use case. Inheritance between use cases is not as common as
either the use of extend or include associations, but it is still possible. The
inheriting use case would completely replace one or more of the courses
of action of the inherited use case. In this case, the basic course of action
is completely rewritten to reflect that new business rules are applied when
the family member of a professor is enrolling at the university. Family
members are allowed to enroll in the school, regardless of the marks they
earned in high school; they don’t have to pay any enrollment fees, and
they are given top priority for enrollment in the university.
Inheritance between use cases should be applied whenever a single condi- Apply inheritance
tion, in this case, the student is a family member of a professor, would result between use cases
in the definition of several alternate courses. Without the option to define when a single
condition would
an inheriting use case, you need to introduce an alternate course to rework
result in several
the check of the student’s high-school marks, the charging of enrollment alternate courses.
fees, and for prioritization of who is allowed to enroll in the given semester.
The inheriting use case is much simpler than the use case from which
it inherits. It should have a name, description, and identifier, and it
should also indicate from which use case it inherits in the “Inherits
From” section. In sections that you replace, you may need to rewrite the
preconditions, postconditions, or courses of action. If something is not
replaced, then leave that section blank, assuming it is inherited from the
parent use case (you might want to put text, such as “see parent use
case,” in the section).
The fourth opportunity for indicating potential reuse within use case Actors may inherit
models occurs between actors: An actor on a use case diagram can inherit from other actors.
from another actor. An example of this is shown in Figure 6-4, where the
“International Student” actor inherits from “Student.” An international stu-
dent is a student, the only difference being he or she is subject to different
rules and policies (for instance, the international student pays more in
tuition). The standard UML notation for inheritance, the open-headed
arrow, is used and the advice presented about the appropriate use of inheri-
tance still applies: It should make sense to say the inheriting actor is or is
like the inherited actor.

6.1.3 Good Things to Know About Use Case Modeling

Associations
An important thing to understand about use case models is that the asso- between actors
ciations between actors and use cases indicate the need for interfaces. and use cases
When the actor is a person, then to support the association, you need to imply the need for
develop user interface components, such as screens and reports. When interfaces.
194 The Object Primer

the actor is an external system, then you need to develop a system inter-
face, perhaps a data file transfer or a real-time online link to the external
system. For example, in the “Enroll in Seminar” use case of Figure 6-2,
the Student actor interacts with the system via several major UI compo-
nents, particularly “UI23 Security Login Screen,” “UI32 Seminar Selec-
tion Screen,” “UI33 Display Seminar Fees Screen,” “UI88 Seminar
Enrollment Summary Screen,” and “UI89 Enrollment Summary Report.”
You should be able Second, use cases are often written under the assumption that you can
to exit from a use exit at any time. For example, in the middle of the “Enroll in Seminar”
case at any time. use case, the student may decide to give up and try again later or the sys-
tem may crash because the load on it is too great. The description of the
use case doesn’t include these as alternate courses because it would
greatly increase the complexity of the use case without adding much
value. Instead, it is assumed, if one of these events occurs, that the use
case simply ends and the right thing will happen. However, your subject
matter experts (SMEs) may want to define nonfunctional requirements
that describe how situations such as this should be handled.
Beware of the “use Third, in my opinion, use case modeling has received far more atten-
case driven” hype tion than it actually deserves. Yes, it is a useful technique but no, it isn’t
of consultants and the be-all-and-end-all of requirements and analysis modeling. You saw in
tool vendors. Chapter 3 that essential use case modeling is one technique of several
you can use to gather requirements and, as you see in this chapter, it is
also one of several techniques to perform object-oriented analysis. Don’t
let the marketing hype of CASE tool vendors and object-oriented consul-
tants deceive you into thinking everything should be “use case driven.”
Use case modeling is merely one of many important techniques you
should have in your modeling toolkit.
Include, extend, Fourth, although the reuse techniques— extend associations, include
and inheritance associations, and inheritance—are useful, don’t overuse them. Include
associations associations and, to a lesser degree, extend associations, lead to func-
between use cases tional decomposition within your use case model. The problem is use
can lead to
cases are not meant to describe functions within your source code; they
functional
decomposition if
are meant to describe series of actions that offer value to actors. A good
you are not rule of thumb to use is if you are able to describe a use case with a single
careful. sentence, then you have likely decomposed it too much, something that
occurs when you apply include associations too often. Another rule of
thumb is, if you have more than two levels of include associations, for
example, if use case A includes use case B, which includes use case C,
then two levels of include exist, and then you are in danger of functional
decomposition. The same can be said of extend associations between use
cases, as well as inheritance.
 Chapter 6 • Determining What to Build: Object-Oriented Analysis 195

6.1.4 Use Case Modeling Tips and Techniques

In this section, I want to share a collection of tips and techniques I have
found useful over the years to improve the quality of my system use case
models.

1. Write from the point-of-view of the actor in the active voice.

Use cases should be written in the active voice: “The student
indicates the seminar,” instead of in the passive voice, “The sem-
inar is indicated by the student.” Furthermore, use cases should
be written from the point-of-view of the actor. After all, the pur-
pose of use cases is to understand how your users will work with
your system.
2. Write scenario text, not functional requirements. A use case
describes a series of actions that provide value to an actor; it
doesn’t describe a collection of features. For example, the use
case of Figure 6-2 describes how a student interacts with the sys-
tem to enroll in a seminar. It doesn’t describe what the user
interface looks like or how it works. You have other models to
describe this important information, such as your user interface
model and your supplementary specifications. Object-oriented
analysis is complex, which is why you have several models to
work with, and you should apply each model appropriately.
3. A use case is neither a class specification nor a data specifica-
tion. This is the sort of information that should be captured by
your conceptual model, described in Section 6.3, which in the
object world is modeled via a UML class model. You are likely to
refer to classes described in your conceptual model; for example,
the “Enroll in Seminar” use case includes concepts, such as semi-
nars and students, both of which would be described by your
conceptual model. Once again, use each model appropriately.
4. Don’t forget the user interface. System use cases often refer to
major user interface (UI) elements, often called boundary or sim-
ply user interface items, and sometimes minor UI elements as
appropriate.
5. Create a use case template. As you can see in Figure 6-2, use
cases include a fair amount of information, information that can
easily be documented in a common format. You should consider
either developing your own template based on what you have
learned in this book or adopting an existing one you have either
purchased with an object modeling tool or downloaded from the
Internet.
196 The Object Primer

6. Organize your use case diagrams consistently. Common prac-

tice is to draw inheritance and extend associations vertically,
with the inheriting/extending use case drawn below the parent/
base use case. Similarly, include associations are typically drawn
horizontally. Note that these are simple rules of thumb, rules
that, when followed consistently, result in diagrams that are eas-
ier to read.
7. Don’t forget the system responses to the actions of actors.
Your use cases should describe both how your actors interact
with your system and how your system responds to those inter-
actions. With the “Enroll in Seminar” use case, had the system
not responded when the student indicated she wanted to enroll
in a seminar, I suspect the student would soon become discour-
aged and walk away. The system wasn’t doing anything to help
the student fulfill her goals.
8. Alternate courses of action are important. Start with the happy
path, the basic course of action, but don’t forget the alternate
courses as well. Alternates courses will be introduced to describe
potential usage errors, as well as business logic errors and excep-
tions. This important information is needed to drive the design
of your system, so don’t forget to model it in your use cases.
9. Don’t get hung up on <<include>> and <<extend>> associa-
tions. I’m not quite sure what happened, but I’ve always thought
the proper use of include and extend associations, as well as uses
and extends associations in older versions of the Unified Model-
ing Language (UML), were never described well. As a result, use
case modeling teams had a tendency to argue about the proper
application of these associations, wasting an incredible amount of
time on an interesting, but minor, portion of the overall model-
ing technique. I even worked at one organization that went so far
as to outlaw the use of the <<include>> and <<extend>> stereo-
types, an extreme solution that had to be reversed after a few
weeks when the organization realized it still needed these con-
cepts, even though the organization hadn’t come to a full agree-
ment as to their proper use. Anyway, I believe Section 6.1.2 does a
good job explaining how to apply these associations effectively.
10. Use cases drive user documentation. The purpose of user docu-
mentation is to describe how to work with your system. Each use
case describes a series of actions taken by actors using your sys-
tem. In short, use cases contain the information from which you
can start writing your user documentation. For example, the
 Chapter 6 • Determining What to Build: Object-Oriented Analysis 197

“how to enroll in a seminar” section of your system’s user docu-

mentation could be written using the “Enroll in Seminar” use
case as its base.
11. Use cases drive presentations. Part of software development is
communicating your work efforts with project stakeholders, result-
ing in the occasional need to give presentations. Because use cases
are written from the point-of-view of your users, they contain valu-
able insight into the type of things your users are likely to want to
hear about in your presentations. In other words, use cases often
contain the logic from which to develop presentation scripts.

6.2 Sequence Diagrams: From Use Cases to Classes

Sequence diagrams (Rumbaugh, Jacobson, and Booch, 1999) are used to Sequence
model the logic of usage scenarios. A usage scenario is exactly what its name diagrams enable
you to visually
indicates—the description of a potential way your system is used. The logic
model the logic of
of a usage scenario may be part of a use case, perhaps an alternate course. It
your system.
may also be one entire pass through a use case, such as the logic described
by the basic course of action or a portion of the basic course of action, plus
one or more alternate scenarios. The logic of a usage scenario may also be a
pass through the logic contained in several use cases. For example, a student
enrolls in the university, and then immediately enrolls in three seminars.
Figure 6-7 models the basic course of action for the “Enroll in Seminar” use
case. Sequence diagrams model the flow of logic within your system in a
visual manner, enabling you both to document and validate your logic, and
are commonly used for both analysis and design purposes.
The boxes across the top of the diagram represent classifiers or their Objects, classes,
instances, typically use cases, objects, classes, or actors. Because you can and actors are
send messages to both objects and classes, objects respond to messages depicted in
sequence
through the invocation of an operation, and classes do so through the
diagrams.
invocation of static operations, it makes sense to include both on

DEFINITIONS
Major user interface element. A large-grained item, such as a screen, HTML
page, or report.
Minor user interface element. A small-grained item, such as a user input
field, menu item, list, or static text field.
Supplementary specification. An artifact where all requirements not contained
in your use case model, user interface model, or domain model are documented.
198 The Object Primer

sequence diagrams. Because actors initiate and take an active part in

usage scenarios, they are also included in sequence diagrams. Objects
have labels in the standard UML format “name: ClassName,” where
“name” is optional (objects that haven’t been given a name on the dia-
gram are called anonymous objects). Classes have labels in the format
“ClassName,” and actors have names in the format “Actor Name”—both
UML standards as well. For example, in Figure 6-7, you see the Student
actor has the name “A Student” and is labeled with the stereotype
<<actor>>. The instance of the major UI element representing “UI32
Seminar Selection Screen,” is an anonymous object with the name
“:SeminarSelector” and the stereotype <<UI>>. The “Student” class is
indicated on the diagram, the box with the name “Student,” because the
static message “isEligible(name, studentNumber)” is sent to it. More on
this later. The instance of “Student” was given a name “theStudent”
because it is used in several places as a parameter in a message, whereas
the instance of the “StudentsFees” class didn’t need to be referenced any-
where else in the diagram and, thus, could be anonymous.
The dashed lines hanging from the boxes are called object lifelines, rep-
resenting the life span of the object during the scenario being modeled.
The long, thin boxes on the lifelines are method-invocation boxes indicat-
ing that processing is being performed by the target object/class to fulfill a
message. The X at the bottom of a method-invocation box is a UML con-
vention to indicate that an object has been removed from memory, typi-
cally the result of receiving a message with the stereotype of <<destroy>>.
Messages are Messages are indicated as labeled arrows, when the source and target of
indicated by a message is an object or class the label is the signature of the method
labeled arrows, invoked in response to the message. However, if either the source or target
and return values
is a human actor, then the message is labeled with brief text describing
by dashed and
the information being communicated. For example, the “:EnrollInSemi-
labeled arrows.
nar” object sends the message “isEligibleToEnroll(theStudent)” to the
instance of “Seminar.” Notice how I include both the method’s name and
the name of the parameters, if any, passed into it. Figure 6-7 also indicates
that the Student actor provides information to the “:SecurityLogon”
object via the messages labeled “name” and “student number” (these
really aren’t messages; they are actually user interactions). Return values
are optionally indicated as using a dashed arrow with a label indicating
the return value. For example, the return value “theStudent” is indicated
coming back from the “Student” class as the result of invoking a message,
whereas no return value is indicated as the result of sending the message
“isEligibleToEnroll(theStudent)” to “seminar.” My style is not to indicate
the return values when it’s obvious what is being returned, so I don’t clut-
ter my sequence diagrams (as you can see, sequence diagrams get compli-
cated fairly quickly).
 Enroll In Seminar
Basic Course of Action
schedule
A Student :EnrollInSeminar :SecurityLogon :SeminarSelector :FeeDisplay Student seminar:Seminar theStudent :StudentFees
SD #: UC17-01
:StudentSchedule
<<actor>> <<controller>> <<UI>> <<UI>> <<UI>> :Student

1. Student indicates wish to enroll wish to enroll

<<create>>

2. Student inputs name and number name

student number
isEligible(name, studentNumber)
3. System verifies student <<create>>
theStudent
theStudent
<<destroy>> Note: Need to
X flesh this message
<<create>> out more.
4. System displays seminar list
selection
5. Students picks seminar
isEligibleToEnroll(theStudent) qualifications()
6. System determines eligibility to enroll
getSchedule()
determineFit(seminar)
7. System determines schedule fit

8. System calculates fees

X calculateFees(seminar, theStudent)

<<create>>
9. System displays fees
10. System verifies student wishes to enroll
11. Students indicates yes. verification
enrollStudent(theStudent)
12. System enrolls student in seminar X

Figure 6-7.
A UML sequence
diagram for the basic
course of action for
Figure 6-2
200 The Object Primer

Messages fulfill the logic of the steps of the use case, summarized
down the left-hand side of the diagram. Notice how the exact wording of
the use case steps isn’t used because the steps are often too wordy to fit
nicely on a diagram. What is critical is that the step numbers correspond
to those in the use case and that the general idea of the step is apparent
to the reader of the diagram.
Stereotypes may Notice the use of stereotypes throughout the diagram. For the boxes, I
be applied to applied the stereotypes <<actor>>, <<controller>>, and <<UI>> indicating
actors, objects, that they represent an actor, a controller class, or a user interface (UI)
classes, and class, respectively. For now, a controller class is a placeholder for one or
messages on
more classes that would be fleshed out during design (Chapter 7) to
sequence
implement the business logic of your system. As you see in Chapter 7,
diagrams.
you want to layer your system, separating your user interface logic, busi-
ness logic, system logic, and persistence logic away from each other.
Stereotypes are also used on messages. Common practice on UML dia-
grams is to indicate creation and destruction messages with the stereo-
types of <<create>> and <<destroy>>, respectively. For example, you see
that the “:SecurityLogon” object is created in this manner (actually, this
message would likely be sent to the class that would then result in a
return value of the created object, so I cheated a bit). This object later

DEFINITIONS
Anonymous object. An object appearing on the diagram that hasn’t been
given a name; instead, the label is simply an indication of the class, such as
“: Invoice.”
Classifier. A mechanism that describes behavioral or structural features. Classi-
fiers include use cases, classes, interfaces, and components.
Lifeline. Represents, in a sequence diagram, the life span of an object during
an interaction.
Method. Something a class or object does. A method is similar to a function or
procedure in structured programming and is often referred to as an operation
or member function in object development.
Message-invocation box. The long, thin, vertical boxes that appear on sequence
diagrams, which represent invocation of an operation on an object or class.
Signature. The combination of the name, parameter names (in order), and
name of the return value (if any) of a method.
Static method. A method that operates at the class level, potentially on all
instances of that class.
Stereotype. A stereotype denotes a common usage of a modeling element.
Stereotypes are used to extend the UML in a consistent manner.
 Chapter 6 • Determining What to Build: Object-Oriented Analysis 201

destroys itself in a similar manner, presumably when the window is

closed. In Java and C++, methods that create objects are called construc-
tors, and in C++, methods that destroy objects are called destructors (Java
automatically manages memory, whereas C++ doesn’t, so Java doesn’t
require destructor methods).
I used a UML note; notes are basically free-form text that can be Notes can be used
placed on any UML diagram, to provide a header for the diagram, indi- to add free-form
text to any UML
cating its title and identifier (as you may have noticed, I give unique
diagram.
identifiers to everything). Notes are depicted as a piece of paper with the
top-right corner folded over. I also used a note to indicate future work
that needs to be done, either during analysis or design; in this diagram,
the “qualifications()” message likely represents a series of messages sent
to the student object. Common UML practice is to anchor a note to
another model element with a dashed line when appropriate, as you see
in Figure 6-7, with the note attached to the message.
When I developed the sequence diagram of Figure 6-7, I made several Verify modeling
decisions that could potentially affect my other models. For example, as I decisions with
modeled Step 10, I made the assumption (arguably, a design decision) that your SMEs.
the fee display screen also handled the verification by the student that the
fees were acceptable. This decision should be reflected by the user interface
prototype, the topic of Section 6.5, and verified by my SMEs. Sequence dia-
gramming is something you should be doing together with your SMEs,
particularly sophisticated ones who understand how to develop models
such as this. Also, as I was modeling Steps 2 and 3, I came to the realiza-
tion that students should probably have passwords to get into the system.
I brought this concept up with my SMEs and discovered I was wrong: the
combination of name and student number is unique enough for our pur-
poses and the university didn’t want the added complexity of password
management. This is an interesting decision that would be documented
in the supplementary specification, likely as a business rule, because it is
an operating policy of the university. By verifying this idea with my SMEs,
instead of assuming I knew better than everyone else, I avoided an oppor-
tunity for goldplating and, thus, reduced the work my team would need
to do to develop this system.
Regarding style issues for sequence diagramming, I prefer to draw mes- Understand the
sages going from left-to-right and return values from right-to-left, basic logic during
although that doesn’t always work with complex objects/classes. I justify analysis, flesh out
the details during
the label on messages and return values, so they are closest to the arrow-
design.
head. As mentioned earlier, I prefer not to indicate return values on
sequence diagrams to simplify the diagrams whenever possible. However,
equally valid is to decide always to indicate return values, particularly
when your sequence diagram is used for design instead of analysis (I like
my analysis diagrams to be as simple as possible and my design diagrams
202 The Object Primer

DEFINITIONS
C++. A hybrid object-oriented programming language that adds object-oriented
features to the C programming language.
Constructor. A method, typically a static one, whose purpose is to instantiate
and, optionally, initialize an object.
Controller. A class that implements business/domain logic, coordinating sev-
eral objects to perform a task.
Destructor. A method whose purpose is to remove an object completely from
memory.
Goldplating. The addition of extraneous features to a system.
Java. An object-oriented programming language based on the concept of
“write once, run anywhere.”
Note. A modeling construct for adding free-form text to the UML diagrams.

to be as thorough as possible). During analysis, my goal is to understand

the logic and to ensure I have it right. During design, I then flesh out the
exact details, as the note reminds me to do with the “qualifications()”
message in Figure 6-7. I also prefer to layer the sequence diagrams from
left-to-right. I indicate the actors, then the controller class(es), and then
the user interface class(es), and, finally, the business class(es). During
design, you probably need to add system and persistence classes, which I
usually put on the right-most side of sequence diagrams. Laying your
sequence diagrams in this manner often makes them easier to read and
also makes it easier to find layering logic problems, such as user interface
classes directly accessing persistence classes (more on this in Chapter 7).
Interesting to note is the style of logic changed part way through the
sequence diagram of Figure 6-7. The user interface was handling some of
the basic logic at first—particularly the login—yet for selecting the semi-
nar, and then verifying it, the controller class did the work. This is actu-
ally a design issue. I wouldn’t get too worked up over this but, as always,
I suggest choosing one style for now and sticking to it.
Although Figure 6-7 models the logic, the basic course of action for the
“Enroll in Seminar” use case, how would you go about modeling alternate
courses? The most common way to do so is to create a single sequence dia-
gram for each alternate course, as you see depicted in Figure 6-8. This dia-
gram models only the logic of the alternate course, as you can tell by the
numbering of the steps on the left-hand side of the diagram. The header
note for the diagram indicates that it is an alternate course of action. Also
notice how the ID of this diagram includes that this is alternate course B,
yet another modeling rule of thumb I have found useful over the years.
 Chapter 6 • Determining What to Build: Object-Oriented Analysis 203

You may have heard terms such as dynamic modeling and static modeling TIP
bantered about by other developers familiar with object-oriented modeling
techniques. You may even have heard arguments about the merits of each Sequence
style. Dynamic modeling techniques focus on identifying the behavior within Diagrams Are
your system. These techniques include sequence diagramming and activity Dynamic
diagramming (both of which are described in this chapter) and collaboration
diagramming, described in Chapter 7. Static modeling focuses on the static
aspects of your system, including the classes, their attributes, and the associations
between classes. Class models, described in this chapter, are the main artifact
of static modeling, as are persistence models, which are described in Chapter
7. Both dynamic and static modeling techniques are required to specify an
object-oriented system adequately, which makes the “dynamic modeling
versus static modeling” debates questionable at best.

The sequence diagram of Figure 6-8 is simpler than that of Figure 6-7;
this is generally the case of alternate courses. I modeled the return value
from the “isEligibleToEnroll(theStudent)” message because this is what
causes the alternate course to occur in the first place. This arguably points
to the need always to model return values in your sequence diagrams. I
still prefer to keep my diagrams as simple as possible, though, so I model
them only when the information is vital to my understanding of the
logic. I also chose to show the ineligibility notice as its own user- interface
element, once again bordering on a design decision that would need to be
reflected in the user interface prototype. I also modeled that the prerequi-
sites list is displayed as part of the seminar details user interface element,
which is more than the use case currently calls for. This implies that I
should verify the change with my SMEs because I have effectively
increased the requirements although, by doing so, I have likely indicated Figure 6-8.
an opportunity for both reuse and an overall simplification of the poten- A UML sequence
diagram for an
alternate course

Enroll In Seminar
Alternate Course of
Action: Student Does
not Have Prerequisites A Student :EnrollInSeminar :IneligibilityNotice :SeminarDetails seminar:Seminar
<<actor>> <<controller>> <<UI>> <<UI>>
SD #: UC17-01B

isEligibleToEnroll(theStudent)
B.6. System determines ineligibility to enroll
false

<<create>>
B.7. System informs the student of ineligibility
B.8. System informs the student of <<create>>
prerequisites
B.9. Use case resumes at step 4
204 The Object Primer

tial design. As you can see with this example, the line between analysis
and design is fuzzy with object-oriented development; experienced devel-
opers new to objects can take time to get used to this. Finally, I left the
“Student” actor in the diagram, even though no direct interaction occurs
at this point because this actor is referred to in the steps of the use case.

6.2.1 How to Draw Sequence Diagrams

The following steps describe the fundamental tasks of sequence diagram-
ming, tasks you perform in an iterative manner.

1. Identify the scope of the sequence diagram. Begin by identify-

ing what you are modeling. Is it the basic course of action for a
single use case? A single alternate course? The combination of
the basic course of action and one or more alternate courses?
Logic from several use cases? Once you identify the scope of your
diagram, you should add a label at the top, using a note, indicat-
ing an appropriate title for the diagram and a unique identifier
for it. You may also want to include the date and also the names
of the authors of the diagram.
2. List the use case steps down the left-hand side. I like to start a
sequence diagram by writing a summary of the original use case
text in the left-hand margin, as you saw in Figure 6-7 and Figure
6-8. This logic is what you are modeling, so you might as well
have it on your diagram from the start. Rosenberg and Scott
(1999) point out this also provides valuable traceability informa-
tion between your use cases and sequence diagrams.
3. Introduce boxes for each actor. Introduce a box for each actor
across the top of your diagram. I prefer to put actors that repre-
sent humans and organizations on the left-hand side and those
that represent external systems on the right-hand side. Label
each box with the <<actor>> stereotype.
4. Introduce controller class(es). My style is to introduce at least
one controller class whose purpose is to mediate the logic
described by the use case steps. This business logic typically does-
n’t belong in your user interface classes. Instead, it should be
encapsulated by business classes (a controller class is a type of
business class). Later, during design, you will likely refactor this
logic into one or more classes to reflect issues with your chosen
implementation technologies. Label each box with the <<con-
troller>> stereotype.
 Chapter 6 • Determining What to Build: Object-Oriented Analysis 205

5. Introduce a box for each major UI element. Major user inter-

face elements, and minor ones for that matter, are implemented
as classes in object-oriented systems. Therefore, they should be
modeled as a box in a sequence diagram. My style is to list the UI
elements to the immediate right of the controller class(es). Label
each box with the <<UI>> stereotype.1
6. Introduce a box for each included use case. Although I didn’t
include this in an example, included use cases are treated just like
objects. Mark them with the stereotype <<use case>> and give them
a name in the format “id:Use case name,” such as “UC17:Enroll in
Seminar.” To indicate that the use case is being invoked by a step, I
simply send it a message with the stereotype of <<uses>>.
7. Identify appropriate messages for each use case step. Going one
step at a time, walk through the process logic for the scenario, iden-
tifying each message that needs to be sent and its destination. The
sequencing of the messages is implied on the diagram by the order
of the messages themselves, starting at the top-left corner of the
diagram. When you are drawing sequence diagrams, the important
task is to get the logic right; you effectively flesh out your logic as
you identify messages for each step. Also, don’t forget that an
object or class can send a message to itself, as you saw in Figure 6-7.
8. Add a method-invocation box for each invocation of a method.
Every time an object or class receives a message, a method is
invoked. To represent this, you should include a method-invocation
box to the lifeline of the target. The incoming message will be
received at the top of the box and, to fulfill the logic of the step, you
may find the target needs to send messages to other objects and
classes, which, in turn, invoke methods on those new targets. From
the box, messages may be sent to other objects that, in turn, invoke
methods within those targets. Eventually, this method will com-
plete; therefore, the method invocation box “stops” and, possibly, a
value is returned to the original sender of the message.

1
Stereotypes in the UML typically begin with a lowercase letter. However, because I am
using the term “UI” for the stereotype label, instead of “user interface,” I have chosen
to capitalize it. Also, in Chapter 3, I was using the stereotype <<Actor>> instead of
<<actor>> on the Class Responsibility Collaborator (CRC) cards. I did this for two rea-
sons. First, CRC models are not part of the UML and, therefore, don’t have comply
with UML practices. Second, I did it to show you the world won’t end if you break the
rules a bit. I’ve lot track of the amount of time, easily in the hundreds of hours, that
I’ve wasted in conversations during modeling sessions over nitpicky issues such as this.
Your goal is to model your system accurately in a way that is understandable to the
people involved; whether you use <<Actor>> or <<actor>> as a stereotype is barely rele-
vant when the big picture is taken into consideration.
206 The Object Primer

9. Add destruction messages where appropriate. At the end of a

method invocation, the target object may be destroyed. This is
common for transitory objects such as user interface elements
and for business objects deleted as the result of an operation.
Therefore, a message with the stereotype <<destroy>> should be
sent to the object and the method-invocation box labeled with
an X at its bottom. Sometimes an object will destroy itself, as you
saw in Figure 6-7.
10. Add your business classes and objects. As you identify mes-
sages you also need to identify targets for those messages, targets
that will inevitably be classes or objects. The appropriate classes
(objects are instances of classes) should be in your conceptual
model (if not, then you need to add them). Use the class names
from your conceptual model for the names of the classes in your
sequence diagrams (any business class that appears on a
sequence diagram should also appear in your conceptual model).
For now, don’t worry too much whether an object or a class
should be the target of a message. You can always rework your
diagram if you get it wrong at first. The important thing is to get
the fundamental idea correct, and then you can go back to per-
fect it later. Remember to layer your classes and objects as
described in previous steps. Also, you may find you need several
instances of the same class on a single sequence diagram. For
example, had I modeled a scenario in which a student enrolled
in three different seminars, then I would have included three
seminar objects in the diagram.
11. Update your class model. Because you are sequence diagram-
ming, you will identify new responsibilities for classes and objects,
and, sometimes, even for new classes. Remember, each message
sent to a class invokes a static method/operation on that class, an
operation that should appear on your class model. Similarly, each
message sent to an object invokes an operation on that object, an
operation that should also appear on your class model. Sequence
diagramming is a significant source for identifying behavior to be
modeled on your class model, the subject of Section 6.3.
12. Update your user interface model. As you work through the
logic of each scenario, you may discover you are missing features
in your user interface or you have modeled some features inap-
propriately. When you discover this, you should work together
with your SMEs to identify the proper way for your user interface
to work, the topic of Section 6.5.
 Chapter 6 • Determining What to Build: Object-Oriented Analysis 207

13. Update your use case model. As you are sequence diagram-
ming, you may find errors in your original use case logic, errors
that need to be fixed on both your sequence diagram(s) and in
your use case(s). As always, validate any use case changes with
your SMEs first.

6.2.2 Why and When Should You Draw Sequence Diagrams?

You want to draw sequence diagrams for several reasons. First and fore- Sequence
most, sequence diagrams are a great way to validate and flesh out your diagrams are used
logic (not that this should stop you from use case scenario testing, as to test your design
and to document
described in Chapter 4). Second, sequence diagrams are a great way to
use cases.
document your design, at least from the point-of-view of use cases.
Third, sequence diagrams are a great mechanism for detecting bottle-
necks in your design. By looking at what messages are being sent to an
object, and by looking at roughly how long it takes to run the invoked
method, you quickly get an understanding of where you need to change
your design to distribute the load within your system. In fact, some CASE
tools even enable you to simulate this aspect of your software. Finally,
sequence diagrams often give you a feel for which classes in your applica-
tion are going to be complex, which, in turn, is an indication you may
need to draw state chart diagrams for those classes (UML state chart dia-
grams are described in Chapter 8).

6.2.3 How to Document Sequence Diagrams

I generally don’t develop documentation specific to sequence diagrams.
Sequence diagrams provide a bridge between your use cases and your
class model. Everything that is shown in a sequence diagram is docu-
mented in these models. For example, the steps depicted by the sequence
diagram are documented by your use cases. The boxes across the top of
the diagram are documented.

6.2.4 A Good Thing to Know About Sequence Diagrams

You need to do at least one sequence diagram for each use case and,
often, you will create several for each use case. Because the diagram
should match the narrative flow of the use case, Rosenberg and Scott

DEFINITION
Transitory object. An object that is not saved to permanent storage.
208 The Object Primer

DEFINITION
Computer-aided system engineering (CASE) tool. Software that supports
the creation of models of software-oriented systems.

(1999) point out that if you are having problems getting started drawing
sequence diagrams for a use case, then you likely wrote the use case
incorrectly and should reconsider its logic. They also point out that
sequence diagramming is the primary vehicle for allocating behavior.
During analysis, you will begin to add solution-space objects to the
problem-domain objects (from your CRC model), including controller
and user interface objects. Furthermore, during design, Rosenberg and
Scott (1999) also point out that you will infrastructure objects such as
system and persistence objects, scaffolding, and other helper objects into
your models.

6.3 Conceptual Modeling: Class Diagrams

Class models (Rumbaugh, Jacobson, and Booch, 1999) are the mainstay
of object-oriented analysis and design. Before the UML, most methodolo-
gies called them object models instead of class models.2 Class models are
created by using many of the modeling concepts and notations discussed
in Chapter 5. Class models show the classes of the system, their interrela-
tionships (including inheritance, aggregation, and association), and the
operations and attributes of the classes. During analysis, you use class
models to represent your conceptual model, an expansion of the domain
model described in Chapter 3, because it shows greater detail and a wider
range of detail. Conceptual models are used to depict your detailed
understanding of the problem space for your system. During design, this
model is evolved further to include classes that address the solution
space, as well as the problem space.
The easiest way to begin conceptual modeling is to use your domain
model as a base. In this case, you will take your Class Responsibility Col-
laborator (CRC) model (Beck and Cunningham, 1989) and convert it
directly into a UML class diagram. CRC models show the initial classes of
a system, their responsibilities, and the basic relationships (in the form of
a list of collaborators) between those classes. While a CRC model pro-
vides an excellent overview of a system, it doesn’t provide the details

2
In the original edition of this book, written in 1995, I argued for, and then used, the
term “class model,” instead of “object model,” for the simple reason that you use them
to model classes and their relationships, not objects.
 Chapter 6 • Determining What to Build: Object-Oriented Analysis 209

DEFINITIONS
Problem space. The scope of your business domain being addressed by your
system.
Solution space. The problem space being addressed by your system plus the
nondomain functionality required to implement your system.

needed to actually build it. Luckily, those details have been captured in
the notes taken down by the scribe(s) during CRC modeling. Figure 6-9
depicts the CRC model we developed in Chapter 3, the “SecurityLogon”
class identified in the sequence diagrams earlier has been introduced to
CRC model, and Figure 6-10 depicts the UML class diagram that would
be created based on that CRC model.
For each card in the CRC model, you create a concrete class in the class
diagram, with the exception of cards that represent actors (actors exist in the Figure 6-9.
real world). Notice how the names stayed the same (spaces were removed A CRC model for
the university

Professor
Name
Seminar
Address
Phone number
Email address
Salary
Transcript <<UI>>
Provide information
Seminars instructing
**See the prototype** Student
Student <<Actor>> Get student info Seminar
Get seminars student Professor .
Provide information Enroll in Seminar took Enrollment Record
about self Transcript Determine average Seminar
Request to enroll in mark
seminar Name
Output self Student
Request Transcript Seminar number
Professor
Fees
Waiting list
Enrolled students
Enroll in Seminar <<UI>> Instructor
Add student
**See the prototype** Seminar Drop student
Enable seminar search Professor
Display seminar list
Display seminar fees Student
Display professor info
Name Enrollment
Address Record
Phone number
Email address
Student number
Average mark received
SecurityLogon <<UI>> Validate identifying info
Provide list of seminars
**See the prototype** Student taken
Request identifying
info for student
Enrollment Record

Mark(s) received Seminar

Average to date
Final grade
Student
Seminar
Other documents randomly have
different content
furious barking of the hounds.
Just as it passed through the entrance and turned into the road,
the head and arms of Madame Berthier appeared at the coach
window, the latter extended, and her cry, shrill and full of agony,
was echoed back from the front of the chateau:
‘Gabrielle! save me, save me!’
‘That,’ said Berthier, rubbing his eyes, ‘that is more than Gabrielle
or any one else can do, excepting myself or the king.’
 CHAPTER XIII.

Thomas Lindet stood at his window thinking. One by one the lights
died out in the town. A candle had been shining through the curtain
in Madame Leroux’s bedroom for an hour, and now that was
extinguished. The red glow of the forge at the corner had become
fainter. For long it had shot a scarlet glare over the pavement, and
had roared before the bellows. The clink on the anvil was hushed,
the shutters were closed, and only a feeble glimmer shone through
their chinks, and under the door. The watch had closed the tavern of
the ‘Golden Cross.’ None traversed the square. Lindet saw a light still
in Madame Aubin’s windows. She had a child ill, and was sitting up
with it. There was a glimmer also from the window of M. François
Corbelin, and the strains of a violin issued from his room. There was
no moon now. The stars shone in the black vault above, and the
priest fixed his eyes upon them.
Save for the violin, all was hushed; the frogs indeed trilled as
usual, but the curé was so accustomed to the sound that he did not
hear them, or rather did not know that his ear received their
clamorous notes. Then suddenly he heard the baying of some
hounds, distant, but approaching.
A moment after, Lindet saw a figure dart across the market-place,
with extended arms, and rush to his door. Looking fixedly at the
form, he distinguished it to be that of a woman. She struck at his
door, and gasped, ‘Let me in! they are after me.’
‘Who are you, and what do you want?’ asked the curé from his
window.
‘Oh! quick, let me in,’ she cried; ‘the dogs! the dogs!’
 ‘Who are you?’
‘I am Gabrielle——’ she broke off with a scream, for instantly from
the street, out of which she had started, appeared the bloodhounds,
baying and tracking her.
‘For God’s sake! or they will tear me!’ she cried.
Lindet flung himself down the stairs, tore the door open, beat off
the dogs with a staff he snatched up, as the girl sprang in; then
slammed and barred the door upon the brutes.
‘Have they hurt you?’
She could not answer; her breath was nearly gone.
‘Stay there,’ he said; ‘I will light a candle.’ He groped his way to
the kitchen, felt for the tinder and steel, and struck a light. Having
kindled from it a little lamp, he returned to the girl. She had sunk
upon the ground beside the door, outside of which the hounds
leaped and barked, and at which they attempted to burrow.
‘How came you here?’ asked the curé. He set down the lamp, and
raised her from the floor in his arms.
‘I have escaped,’ she gasped. ‘I ran. They are after me.’
Voices were now heard without, calling off the dogs.
‘Bah! she has taken refuge with her dear friend the curé. I thought
as much.’ The voice was that of Foulon.
‘Sacré!’ exclaimed Berthier; ‘I wish we had discovered her flight a
little earlier. I wish the dogs had brought her down in the forest.
Sacré! I wish——’
‘My dear good Berthier,’ said Foulon, ‘what is the use of wishing
things to be otherwise than they are? always accept facts, and make
the most of them. Gustave! take the dogs away. They make a
confounded noise.’
‘Remain here,’ said Lindet, in an agitated voice; ‘I will go and
summon Madame Pin, the old woman whose house this is. She is as
deaf as a post.’
‘Do not go!’ pleaded Gabrielle, trembling; ‘perhaps they may get
in. Wait, wait, to defend me.’
Lindet stood and listened to the voices outside. The dogs were
collared and withdrawn. Foulon tapped at the door.
‘Do not open,’ entreated Gabrielle.
‘Well! Monsieur le Curé,’ said the old gentleman through the door;
‘sly priest! so the little rogue is with you? What will the bishop say?
So late at night!’
The noise had attracted the musician to his window. The mother
of the sick child had opened her casement, and was looking out.
Madame Leroux started out of the dose into which she had fallen,
and appeared at her garret window.
‘What is the matter?’ asked the musician.
‘Ah, M. Corbelin!’ exclaimed Foulon, in a loud voice; ‘what foxes
these curés are! We have just seen one admit a young and pretty
girl to his house. Hark! it is striking midnight. No wonder all the dogs
in the town have been giving them a charivari.’ Then, in a low tone
to Berthier, he said: ‘My good boy! I have served out our curé now,
for having repeated in the pulpit certain observations I made in
private. Those she-dragons yonder’—he pointed up at the windows
—‘will have ruined Thomas Lindet for ever. Come, let us go home.’
 C H A P T E R X I V.

It was evident that the States-general must be convoked. All

attempts on the part of the Court at evasion provoked so loud and
so indignant a burst of feeling from every quarter of France, that
Louis XVI finally resolved on conquering his repugnance and yielding
to popular pressure.
When Brienne resigned the ministry, he engaged Louis to summon
Necker, a banker of Geneva. Necker decided the king to convoke the
States-general, and to determine the mode of convocation, the
notables were summoned. Necker was now prime minister of
France. He was adored by the people, who believed him to be
liberal-minded and honest; and on his influence the Court relied to
keep in check and subordination the third estate, and use its weight
as a counterpoise to that of the nobility and clergy, who had acted
so decided a part in resisting the crown in the equal distribution of
taxation. As the object desired by the Court was to make the two
privileged classes bear their share in the burden, and as the States-
general consisted of three houses, of which two were composed of
those enjoying immunities, it was evident that they would unite
against the wishes of the king and Necker, and the Tiers État. To
avoid this, Necker proposed that the number of those representing
the third estate should equal the number of the noble and clerical
delegates conjointly. The assembly of notables, perceiving the
design of the prime minister, rejected the double representation
demanded in favour of the communes, and the Parliament of Paris
declared that the States-general must be composed in the same
manner as in 1614, when they last met. An assembly of peers, held
on the 20th November, expressed the same sentiment, and the
notables were dismissed. The courtiers were so accustomed to
consider their will the rule of government, that the opinion of the
notables, the parliament, and the peers would have prevailed, had
not the necessity of filling the deficit in the finances inclined the
ministry towards the Tiers État. Necker procured a decree of council
deciding the double representation, on the 27th December; as to the
question of deliberations by orders or by the three houses united,
that was remitted to the decision of the States-general, convoked for
the end of April, 1789.
Although the hopes of the king rested on the third estate, he
feared it. He desired that it should vote taxes; he resolved that it
should do nothing more. Some persons advised him to assemble the
States at Blois, at Orléans, or at Bourges, and to avoid Paris, which
would exert an incalculable influence over the third house. Louis XVI,
however, decided that the assembly should take place at Versailles,
where the splendour of the Court was calculated to overawe the
representatives of the people, and render them complaisant tools of
the royal will.
When, in the autumn of 1788, it became apparent to the whole of
France that a crisis would arrive in the following spring, and that
there would be a struggle between the privileged and the
unprivileged classes, which would end either in the country asserting
its rights and liberties, or in its further and final subjugation, it
became important to those whose representatives occupied the
upper houses, that they should present a compact front to the
common enemy—Justice.
The nobility were almost unanimous; but it became daily more
apparent that the second privileged class was by no means so. The
Church was divided into two classes, the upper and the lower clergy,
and the scission between them was almost as sharp as that between
the noble and the roturier. The eyes of the Court were turned on the
Church, which held the scales between the parties, anxious to know
whether its bias would be cast on the side of the third, or of the
higher estate. The bishops and high clergy were stirred into activity,
and became political agents; they exerted their influence on all the
clergy within their sway, to promote the election of candidates
favourable to the ancien régime.
The opportunity of acting a part as a political agitator inspired the
Bishop of Évreux, when recovered from his attack of apoplexy, to
make the circuit of his diocese, and by flattery and promises
extended to some, by pressure brought to bear on others, to secure
the election of candidates recommended by himself as partizans of
privilege and abuse. Indeed, his ambition was to be himself elected.
His negotiations had not been as successful as he had anticipated;
he discovered that his clergy were by no means so enthusiastic in
their devotion to the existing state of affairs as were those who
largely profited by them. Some listened to him and respectfully
declined to promise their votes to him or his candidate, others would
consider his lordship’s recommendation, others again would give no
answer one way or another. The bishop was personally unpopular;
he had a domineering manner which offended his clergy, and a
tenacity to his dignity, which rendered him disliked. If a living in his
gift were vacant, he kept it open for six months, and then appointed
to it a priest of another diocese; if he were written to on business by
one of his clergy, he either gave him no answer, or did not reply for
months. Towards the close of his circuit, he arrived at Bernay, not in
the best humour at his ill success, and accepted Berthier’s invitation
to stay at Château Malouve. Thither Lindet was summoned.
Rumours had come to the bishop’s ears that the liberal party
among his clergy, in casting about for a suitable delegate at the
approaching convocation, had mentioned the name of the curé of S.
Cross. No name could possibly have been suggested more calculated
to irritate monseigneur; and the bishop had arrived at Bernay with a
settled determination to crush Lindet. The means were simple: he
had but to sign his name and Lindet was cast adrift; but he must
have some excuse for inhibiting him; and to provide him with this,
Ponce, the officiel, was summoned to Bernay. The excuse was,
however, ready, and awaiting his arrival,—an excuse a great deal
more plausible than he had ventured to expect. The bishop had not
been an hour in the château before Foulon had made him
acquainted with ‘a scandal which had compromised Religion and the
Church in that neighbourhood,’ and had told him how that Lindet
had received a young woman into his house at midnight, and had
not dismissed her till next morning, when he had sent her to his
brother, the lawyer, to be his servant.
Now it happened that the incident had caused no scandal in
Bernay, as Foulon had predicted, for the musician had from his
window witnessed what had taken place; Berthier’s character was
well known in Bernay, and the disappearance of Gabrielle had been
widely commented upon. A few malicious persons, perhaps, alluded
to the priest’s part in recovering the girl, as indicating a very
unaccountable interest in her, but the circumstance had roused a
deep indignation against the Intendant in the breasts of the Bernay
people, which was not allayed when it transpired through Lindet,
that Madame Berthier, the protectress of the girl, had been carried
off to Paris by soldiers, to be incarcerated in the Bastille.
When Thomas Lindet reached Château Malouve, he was shown
into the yellow room, once occupied by the afflicted lady, and which
Berthier had surrendered to the prelate as his office during his stay.
Lindet found the bishop seated near the window, at the head of a
long table, beside which sat M. Ponce, acting as his secretary.
Monseigneur de Narbonne bowed stiffly, without rising from his
chair, or removing his biretta; his red face flushed purple as the
priest entered, but gradually resumed its usual ruddy hue.
‘I have received a paper, which M. Ponce will do us the favour of
reading,’ said the bishop in a pompous tone, without raising his eyes
from the table, or for a moment looking the curé full in the face—‘a
paper which contains grave charges of a moral nature against you,
Robert Thomas Lindet—your name is correctly stated, is it not?’
‘Yes, my Lord.’
‘But your brother, the lawyer, is also Robert.’
‘Monseigneur, his name in full is Jean Baptiste Robert.’
 ‘Then you are both Robert?’
‘Both, my Lord; but I have always been called by my second
name.’
‘M. Ponce, will you kindly——’ the bishop bent slightly towards his
officer.
That gentleman rose, and taking up a paper, read in a voice
devoid of expression:—
‘We, the undersigned, did, on the night of September 3, 1788, see
a young girl, Gabrielle André, secretly enter the parsonage of Robert
Thomas Lindet, curé of S. Cross, at Bernay, between the hours of
eleven and twelve at night, the said Robert Thomas Lindet himself
admitting her, and closing and locking the door after her. And we,
the undersigned, have ascertained that the said girl, Gabrielle André,
did remain in the house of the priest that night till the hour of seven
in the morning.’
This document was signed by Foulon, Berthier, Gustave, and
Adolphe.
The bishop closed his fingers over his breast, leaned back in his
chair, thrust his feet out under the table, settled his neck
comfortably in his cravat, and looked at Lindet.
The priest grew pale, not with fear, but with indignation.
‘Have you anything to say upon this?’ asked the prelate, blandly.
Lindet flashed a glance at him, and the bishop’s eyes fell instantly.
‘Is this true?’ again asked the bishop, after a pause.
‘Perfectly,’ answered the priest in a hard voice.
‘I ask you whether, or not, you have thereby brought scandal on
the Church?’
‘I do not care.’
‘M. Lindet, please to remember in whose presence you stand.’
‘I am not likely to forget, monseigneur.’
 ‘Then answer in a becoming way.’
‘My Lord! I ask to see my accusers.’
‘This is no public trial.’
‘I shall not answer till they are brought here face to face with me.’
‘I am your bishop. I insist on your answering me what I ask. You
are contumacious, sir. You forget where you are.’
‘That also,’ said Lindet, ‘I do not forget. I remember but too
distinctly that I am in the house of a man notorious for his crimes,
and whose hospitality you accept. I ask you, my Lord, whether or
not you have thereby brought scandal on the Church.’
The bishop half started out of his chair.
‘This insolence is simply intolerable. To my face——’
‘Better than behind your back. I tell you—the head of the Church
in this diocese, the guardian of religion and morality—that you are
outraging decency by lodging in this polluted den.’
‘Leave my presence this instant,’ said the bishop. ‘Ponce! turn him
out.’
‘No,’ said Lindet, taking a chair, and leaning his hands on the back
to steady himself, for his limbs trembled with excitement; ‘no,
monseigneur; a charge has been brought against me, a slur has
been cast on my character, and I ask to meet my accusers face to
face.’
‘Pardon me!’ The door opened, and Foulon stepped in, bearing
some peaches on a leaf. ‘My dear Lord, I must positively offer you
this fruit, the very last on the tree. I thought all were gone, but
these are so luscious. Pray accept them.’
Lindet faced him instantly, with abruptness.
‘Monsieur Foulon, I am glad you are here.’
‘Ah, ha! my dear curé. Sly fellow! Do you remember the pretty
little peasantess? Well, I allow she was pretty, bewitching enough to
have captivated a saint, therefore quite excusable in a curé to have
been ensnared.’
‘Monsieur Foulon!’ said the prelate with dignity, ruffling up, and
throwing a tone of reprimand into his voice.
‘I beg your lordship’s pardon a thousand times, but he is too sly.
He amuses me infinitely.’
Thomas Lindet had much difficulty in controlling his naturally quick
temper. He gripped the back of the chair with nervous force, and his
lips whitened and trembled.
‘I know you will allow me,’ said Foulon, withdrawing the chair; and
bringing it to the table, he seated himself upon it.
Lindet, standing without support, shook like a leaf in the wind. He
folded his arms on his breast, and pressed them tightly against it, to
keep down the bounding heart.
‘Monseigneur,’ he said, ‘this person has charged me with having
received a poor girl into my house.’
‘I saw her slip in, and I heard you bolt the door after her,’ said
Foulon; ‘you did not suppose that anyone would be about at
midnight, eh?’
‘Was she a relation?’ asked the bishop.
‘She was not, my Lord,’ answered the curé.
‘A relative of your housekeeper?’
‘No.’
‘Who was she?’
‘She was a poor orphan girl, whom Madame Berthier, that person’s
daughter, had entrusted to my charge, to protect her from M.
Berthier. The child was in danger here——’
‘Excuse me,’ said Foulon in a grave tone, addressing himself to the
bishop, ‘is this curé to bring charges of such a nature as this against
my son-in-law, in his own house?’
 ‘You are right,’ answered Monseigneur de Narbonne; ‘I insist on
you, M. Lindet, exculpating yourself without slandering others.’
‘M. Foulon,’ said the priest, turning upon the old gentleman, then
engrossed in snuffing; ‘you know that what I say is true. You know
that the child was decoyed into this house by your son-in-law; you
know that your own daughter stood between her and her would-be
destroyer.’
‘He is mad,’ said Foulon, calmly. ‘Dear, dear me!’
Lindet could endure no more; his blood boiled up, and the
suppressed passion blazed into action. He sprang upon the
imperturbable old man, and caught him by the shoulders, and forced
him round in his chair to face him.
‘Take some snuff,’ said Foulon, extending his box.
‘Deny what I have said, if you dare!’
‘Certainly not; I will deny nothing. Of course the girl was brought
here; of course my Imogène stood between her and ruin; of course
she besought you to stand protector to the child;—there, does that
satisfy you? I grant all, you see, now be calm. Always say “yes, yes”
to a maniac; it is safest,’ he added, aside to the bishop.
‘I think,’ said Monseigneur de Narbonne, ‘that I have heard quite
enough of this,—enough to satisfy me that M. Lindet is not a fit
person to minister in my diocese. I will trouble you,’ he added,
turning to M. Ponce, ‘to give me that paper you have been so
diligently and kindly drawing up for me. I must inform you,’ he said,
turning his face towards Lindet, ‘that I withdraw your licence, and
inhibit you from performing any ecclesiastical function within my
jurisdiction till further notice.’
He took the paper from his secretary, and in a bold hand signed it
—‘F. Ebro.’
‘You condemn and punish me, you destroy my character, and ruin
me, without investigating the charge laid against me,’ said the priest.
 ‘You have acknowledged that the charge is substantially correct.’
‘I have not acknowledged it, nor can you prove that my moral
character is thereby affected.’
‘I am quite satisfied that you are greatly to blame,’ said the
bishop. ‘I will not hold a public investigation, because it would only
increase the scandal, and I desire to spare you and the Church that
shame. I am satisfied that you are to blame; that is enough.’
‘I demand a thorough investigation,’ said the curé, with great
firmness.
‘You may demand one,’ answered the bishop, ‘but you shall not
get one.’
‘What!’ exclaimed Lindet; ‘I am to be ruined, and to be deprived of
the means of clearing myself!’
‘I am satisfied,’ said the bishop, drawing himself up.
‘But I am not,’ retorted the priest.
The bishop bowed stiffly, and then turning to M. Ponce, said: ‘I
think we will proceed with other business. Good morning, M. Lindet.
Here is your inhibition.’
The curé stood silent for a moment, looking first at the secretary,
then at Foulon, who was engaged in pouring snuff into his palm;
then at the bishop, who had taken up one of the peaches, and with
a silver pocket-knife was pealing it.
‘My lord bishop!’ said Lindet, ‘hear what I say. We, the priests of
the Church of France, have groaned under an intolerable oppression:
we have been subject, without redress, to the whims and caprices of
the bishop; neither justice nor liberty has been accorded us. I shall
resist this treatment. I shall not submit to be crushed without a
struggle. I appeal to the law.’
‘You have no appeal,’ said the prelate, coldly; ‘you are a mere
curate,—a stipendiary curate, and not an incumbent; the incumbent
is under the protection of the law, the curate is removable at the will
of the bishop.’
Lindet paused again.
‘These peaches are delicious,’ said the bishop to Foulon.
‘Then,’ said the curé, ‘I appeal to the country against ecclesiastical
tyranny. You spiritual lords, with your cringing subserviency to the
crown, with your utter worldliness, with your obstructiveness to all
religious movement in your dioceses, with your tenacious adherence
to abuses, and with your arbitrary despotic treatment of your clergy,
have taught us to hate the name of Establishment; to cry to God
and the people to destroy a monstrous, odious sham, and restore to
the Church its primitive independence. I wait the assembly of the
States-general, at which the clergy shall have a voice; and then, my
Lord, then I shall speak, and you shall hear me.’
He turned abruptly on his heel, and left the room.
 C H A P T E R X V.

By an order dated January 24th, 1789, the king required that the
desires and reclamations of all his subjects should be transmitted to
him. Every parish was to draw up a statement of its grievances and
its wishes, which was to be handed into the assembly of the
secondary bailiwick, by it to be fused into one which was forwarded
to the grand bailiwick. The secondary bailiwicks of Beaumont-le-
Royer, Breteuil, Conches, Ezy-Nonancourt, Orbec, and Bernay,
belonged to the grand bailiwick of Évreux. The nobility and the
clergy drew up their papers separately.
Another operation, not less important than the composition of
these cahiers, was to be simultaneously accomplished. This was the
election of delegates.
According to the edict of the 24th January, the ancient distinction
of electors and deputies into three orders, the clergy, the nobility,
and the third estate, was maintained. These orders had a common
electoral circumscription, the grand bailiwick. The mode of election
in the two first orders was made the same, but it was different in the
third.
The nomination of deputies for the clergy was to be made directly
by the bishops, abbés, canons, and other beneficed clergy in the
grand bailiwick. The curés, who subsisted on the portion congrue, in
another word, nearly all the clergy in country parishes, could only
vote in person if their parish were within two leagues of the town in
which was held the assembly, unless they had a curate to take their
place during their absence, and provide for the religious
requirements of the people.
 The election was equally direct for the deputies of the nobility. The
nobles possessing fiefs within the jurisdiction of the grand bailiff,
might appear by representatives, but all others were required to
appear in person.
The third estate, on the contrary, in naming its representatives,
had to traverse three stages. Eight days at latest after having
received the notification, the inhabitants composing the tiers état in
the towns and country parishes, above the age of twenty-five, were
invited to unite in their usual place of assembly, before the justice,
or, in his default, before their syndic, for the purpose of naming a
number of delegates, the number being proportioned to the
population—two for two hundred fires and under, three for more
than two hundred, four for three hundred and over, and so on, in
progression. These delegates were required to betake themselves to
the seat of the secondary bailiwick of their arrondissement, and
there elect one quarter of their number. Those who had passed this
ordeal were next bound to transport themselves to the principal
bailiwick, and there, united with the deputies of that particular
arrondissement of the bailiwick, and with the delegates of the town
corporations, to form, under the presidence of the lieutenant-
general, a college to which was remitted the final election of
deputies.
Such organization had this advantage,—it gave to the elections, at
a period when the relations of men with each other were much more
limited than they are at present, guarantees of sincerity which they
could not have had by direct universal suffrage. At each stage the
electors knew those who solicited their votes. A communication was
established through an uninterrupted chain of confidential trusts,
from the most humble member of the primary assemblies to the
delegates sent to Versailles from the grand colleges.
On Monday, the 16th March, 1789, seven hundred and fifty
ecclesiastics, four hundred and thirty nobles, and three hundred
deputies of the third estate, assembled in Évreux for the final
election of delegates.
 At eight o’clock in the morning, the great bell of the Cathedral
boomed over the city to announce the opening of the first session.
From the summit of the central spire floated a white standard,
powdered with golden lilies. Ropes had been flung across the
streets, and from them were slung banners and flags bearing
patriotic inscriptions, ‘Vive le Roy!’ and ‘Vive les États Généraux.’ The
lilies of France fluttered from the windows of the barracks, the
hospital, and the Palais de Justice.
The weather was cold. The winter had been of unprecedented
severity, and the snow was not gone. On the north side of the
Cathedral it was heaped between the buttresses in dirty patches. It
glittered on the leaden roof of the aisles. In the streets it was
kneaded into black mud; it lurked white and glaring in corners.
Women had been up at daybreak sweeping the slush from their
door-steps, and making the causeway before their houses look as
clean as the season permitted. The limes in the palace-garden had
not disclosed a leaf; the buds were only beginning to swell.
It was a bright morning, almost the first really sunny springtide
day that year, and it was accepted by all as a glad omen of a bright
era opening on France with the elections of that day.
A stream of people poured into the Cathedral through the west
gate and northern portal. The nave was reserved for the electors;
the people of Évreux filled the transepts and aisles. In the centre,
under Cardinal Balue’s tower, sat the nobility, many of them dressed
with studious splendour; the clergy occupied the choir, and
overflowed into the choir-aisles. The third estate sat west of the
central tower. This body of men presented marked contrasts in the
appearance of the members constituting it. Side by side with the
lawyer and surgeon, in good black cloth suits, black satin breeches,
and black silk stockings, sat the peasant delegate in coarse blue
cloth jacket, brown cap,—that cap which has been mounted on the
flag-staff of the Republic as the badge of liberty,—and shoes of
brown leather without heels, laced in front. Next to him a miller, with
a broad-brimmed hat, pinched to make it triangular, a velvet
waistcoat, and a coat set with large mother-of-pearl buttons, and
here and there also a curé in cassock turned green with age, and
black bands, edged with white; for some of the country villages sent
their priests to bear their complaints before the great assembly.
Never had that noble church looked more impressive than on that
March morning. It is peculiarly narrow and lofty, and darkened by
the immense amount of painted glass which fills the windows,—glass
of the highest style of art, and great depth of colour, and thickness
of material.
The bishop occupied his throne, and the Abbé de Cernay, dean of
the chapter, sang the mass of the Holy Ghost, in crimson vestments.
Never, probably, has that grand church resounded with a finer
choral burst of song than when, at the conclusion of the mass, those
seven hundred and fifty priests, with the choir, and a number of the
laity, joined with the thunder of the organ, in the Veni Creator, sung
to the melody composed by good King Robert of France.
The assembly was then constituted in the nave of the Cathedral.
The candles were extinguished, the fumes of incense faded away,
the clergy who had assisted in robes retired to lay aside their
vestments; seats and a table were placed in the nave at the
intersection of the transepts, and M. de Courcy de Montmorin, grand
bailiff of Évreux, took his seat as president. Beside him sat M.
Girardin, lieutenant-general of the bailiwick, and on his left M.
Gozan, procureur of the king. Adrian Buzot, chief secretary, sat pen
in hand at the table. On the right, filling the northern transept, sat
the clergy in a dense black body, with the bishops of Évreux and
Lisieux at their head in purple velvet chairs, studded with gold-
headed nails. The bishops wore their violet cassocks, lace rochets,
and capes, over which hung their episcopal crosses. In the south
transept were placed the nobles; and the third estate filled the first
three bays of the nave below the cross.
As soon as the assembly was seated, and silence had been
established, the grand bailiff rose. He was a venerable man, of noble
appearance, with a fresh complexion, bright clear grey eyes, and a
flowing beard whiter than the late snow without. Raising his chapel
from his blanched head as he began his speech, he replaced it
again. His voice, at first trembling and scarcely audible in that vast
building, gradually acquired tone, and was, towards the close of the
address, heard by every one in that great concourse.
‘I give thanks to Heaven,’ said the old man, lifting his cap and
looking upwards, ‘that my life has been prolonged to this moment,
which opens before us, under the auspices of a beloved monarch, a
perspective of happiness, which we should hardly have ventured to
hope for.
‘What an epoch in our annals, and, indeed, in those of humanity!
A sovereign consults his people on the means of assuring their
felicity, and assembles around him all those gifted with political
knowledge, to strengthen, or rather, to relay the bases of general
prosperity.
‘Already, from one end of France to the other, those social ideas
which establish the rights of man and citizenship on true and solid
foundations have been disseminated. Government, far from
attempting to hinder the spread of these ideas, has allowed them a
liberty in accordance with its own generous purposes.
‘It is for us, gentlemen, to show ourselves worthy of this noble
confidence reposed in us by our sovereign; it is for us to second the
views of a monarch who consecrates for ever his power, by showing
that he desires to endear it to his subjects.
‘Experience has taught kings, as it has their subjects, that this
alone is the means of protecting and securing the royal prerogative
from the seductions of their ministers, who too frequently have
stamped the decrees of their selfish passions, their errors, and their
caprice, with the seal of a cherished and sacred authority.
‘In order that we may arrive at that patriotic aim, dear to our
hearts, we have to endeavour to maintain concord and mutual
consideration between the three orders. Let us then from this
moment suppress our own petty, selfish interests, and subordinate
them to that dominant interest which should engross and elevate
every soul—the public weal.
‘The clergy and the nobility will feel that the grandest of all
privileges is that of seeing the person and property of each under
national security, under the protection of public liberty, the only
protective power which is durable and infallible.
‘The third estate will remember the fraternal joy with which all
orders have hailed the success of the third in obtaining its demands.
Let it not envy its elder brethren those honorific prerogatives,
rendered legitimate by their antiquity, and which, in every monarchy,
accompany those who have rendered service to their country, and
whose families are venerable through their age.
‘Generous citizens of all orders, you whom patriotism animates,
you know all the abuses, and you will demand their reform at the
ensuing council of the nation.
‘I do not agitate the question of the limit of the powers given to
our deputies. Public opinion has decided that; in order that they may
operate efficaciously, they must be, if not wholly unlimited, at least
very extensive.
‘Such are the ideas, gentlemen, which I submit to your
consideration.
‘I assure you solemnly of the sincerity with which I offer up my
prayers for the public welfare. This hope—so sweet, yet so late in
coming to me, now far advanced in years, is the consolation of my
age, rejuvenated by the light of a new era which promises to dawn,
inspiring with hope us who stand on the brink of eternity, and which
will be the glory of our posterity. We shall lay the foundations,
another generation will rejoice in the superstructure. I thank God
that this feeble hand is called even to the preparatory work, and,
gentlemen, I conclude with the words of the Psalmist: “Respice in
servos tuos, et in opera tua, et dirige filios eorum.”’
 The venerable bailiff sat down; a thrill of emotion ran through the
assembly. In perfect silence, the roll-call and verification of powers
was begun.
Amongst those names first proclaimed, in the order of the nobility,
was that of Louis-Stanislas Xavier, son of France, Duke of Anjou,
Alençon and Vendôme, Count of Perche, Maine and Senonches, Lord
of the bailiwicks of Orbec and Bernay. This prince, who was
afterwards Louis XVIII, was represented by the Marquis of
Chambray.
When the names of the clergy were read, Monseigneur de
Narbonne turned his ear towards Adrian Buzot.
‘Robert Thomas Lindet, curate of S. Cross, at Bernay.’
‘I object,’ said the bishop, raising his hand.
The secretary turned to him, and asked his reason.
‘He is disqualified from appearing. He is under inhibition.’
Lindet sprang to his feet and worked his way to the front. ‘I
maintain,’ said he, ‘that an inhibition does not disqualify me from
appearing.’
The bishop leaned back in his velvet chair, crossed his feet, folded
his hands, and looked at the president.
‘I have been inhibited without just cause, without having been
given a hearing, or allowed to clear myself of imputations maliciously
cast upon me.’
‘M. Lindet,’ said the grand bailiff, ‘we cannot enter upon the
question of the rights of the inhibition; we are solely concerned with
the question, whether that said inhibition incapacitates you from
voting.’
‘Quite so,’ the prelate interjected; then his cold grey eye rested
upon Lindet, who returned the look with one of defiance.
M. de Courcy whispered with the Procureur du Roi.
 ‘I think,’ said the bishop, in a formal tone, ‘that, whatever may be
the decision on the legality of your appearing, M. Lindet, there can
be but one opinion on its propriety. If you have not the decency to
remain in retirement, when lying under rebuke for scandalous and
immoral conduct, you will probably not be shamed by anything I
may say.’
‘My Lord,’ began the curé, ‘I protest—’ but he was interrupted by
the president, who, nodding to M. Gozan, the agent for the king,
said:
‘The objection raised by monseigneur appears to me not to
invalidate the claim of M. Lindet to have a voice in the redaction of
the cahiers and the election of the clerical delegates. The order of
his Majesty makes no provision for the case of a clerk under
censure, and silence on this point may fairly be construed in his
favour. The sentence upon him was purely spiritual, his status as
stipendiary curate remains unaltered. If he have a grievance, an
opportunity is graciously afforded him by his Majesty of declaring it.
The ends proposed would be frustrated, if all those who had
grievances were precluded by an exercise of authority on the part of
their lords, feudal or spiritual, from expressing them.’
The bishop coloured, bowed stiffly, and began to converse in a low
tone with M. de la Ferronays, bishop of Lisieux.
The preliminary work of calling over the names of electors and
delegates occupied the session of that day. At four o’clock in the
afternoon it was dissolved, and the vast concourse began to flow out
at the Cathedral doors.
But it was observed by the bishops, that the clergy showed no
signs of moving from their places.
M. de Narbonne rose from his violet velvet chair, and with a smile
at his brother prelate, and then at the dean, suggested that they
should retire through the private entrance in the south transept to
the palace garden.
 He was about to cross before the table at which Adrian Buzot was
still engaged with his papers, when Thomas Lindet, standing on his
chair, addressed him.
‘My Lord! you have this morning publicly attacked my character, by
asserting that my conduct has been “scandalous and immoral.” I
demand of you, before these my brother priests, to state the
grounds upon which you base that charge.’
The bishop, taking the arm of his suffragan, did not even turn to
look at the curé, but began to speak rapidly to his brother prelate.
‘My Lord! are you going to answer me, or are you not?’ again
asked Lindet. ‘I appeal to you as a Christian—not as a bishop. You
have damaged my character. State frankly your reasons for doing so.
Give me an opportunity of clearing myself.’ He had spoken calmly so
far, but all at once his natural impetuosity overpowered him, and he
burst forth with the sentence: ‘Stay! you have just genuflected
towards the Host! you have bent the knee in homage to Him who is
Mercy and Justice, whose minister you are. In His name I demand
justice. Mercy I have long ago ceased to expect.’
‘I had rather be keeper of a lunatic asylum,’ said the Bishop of
Lisieux, ‘than be custos of a herd of wild curés.’
The Bishop of Évreux laughed aloud. The laugh echoed through
the aisles, and was heard by the priests, as he laid his hand on the
private door.
The dense black mass of clerics rose, and the bishop darted
through the door with purple cheek and blazing eye, as a hiss, long
and fierce, broke from that body of priests he shepherded.
‘Barbarians! blackguards!’ said the bishop, shaking his fist at the
Cathedral, as he shut the door behind him and quenched that
terrible sound. ‘Wait! I have chastised you hitherto with whips; when
these States-General are over, I shall thrash you into subserviency
with scorpions.’
 CHAPTER XVI.

On the following day, March 17, the three orders betook

themselves to their several places of reunion, to draw up their
memorials of grievances. The clergy assembled in the hall of the
Seminary of S. Taurinus under the presidency of the bishop of the
diocese, assisted by the Bishop of Lisieux, Féron de la Ferronnais.
The nobility met in the Church of S. Nicholas, with the grand bailiff
as their chairman, and the third estate occupied the audience
chamber of the Viscount’s court, and was presided over by M.
Girardin.
The deliberations of the third estate presented no incident worthy
of note. Unanimity reigned among the members, and its resolutions
were in accordance with, and had indeed been prepared by, the
discussions conducted in the earlier stages of election. What were
the pressing grievances weighing on the people, have been already
shown. The cahiers from the villages and towns which were read
before it threw a clear light also on ecclesiastical abuses; the
principal we shall extract from these documents for the edification of
the reader.
Intolerable abuses had invaded the collation to benefices. The
revenues which had been provided by the piety of the past for the
maintenance of public worship, for the subsistence of the ministers
of religion, and for the support of the poor, had accumulated in the
hands of a few abbés about the Court and high dignitaries of the
Church. M. de Marbeuf, archbishop of Lyons, was Abbot
commendatory of Bec, the nursery of S. Anselm and Lanfranc; the
celebrated Abbé Maury held in commendam the Abbey of Lyons-la-
Forêt; Dom Guillaume-Louis Laforcade, a Benedictine resident at S.
Denis, was Prior of Acquigny; De Raze, minister of the Prince-bishop
of Bâle, was Prior of Saint-Lô, near Bourg-Achard; Loménie de
Brienne, archbishop of Sens, who was minister of finance in 1788,
and of whom M. Thiers well says, that ‘if he did not make the
fortune of France, he certainly made his own,’ possessed 678,000
livres per annum, drawn from benefices all over France, and his
brother, the Archbishop of Trajanopolis was non-resident Abbot of
the wealthy Abbey of Jumiéges. This state of things drew from the
redactors of the cahiers of the third estate many bitter
recriminations. ‘It is revolting,’ said Villiers-en-Vexin, ‘that the goods
of the Church should only go to nourish the passions of titulars.’
‘According to the canons,’ said the parish of Thilliers, ‘every
beneficed clergyman is bound to give a quarter of his income to the
poor. In our parish, with a revenue of twelve thousand livres flowing
into the Church, nothing returns to the poor but the scanty alms of
the ill-paid curate.’ ‘Is it not surprising,’ said the people of Plessis-
Hébert, ‘to see so many bishops and abbés squander their revenues
in Paris, instead of expending them on religious works, in those
places whence they are derived?’
Fontenay wrote in stronger terms: ‘The most revolting abuse is
the miserable exspoliation of the commendatory abbeys. The people
are indignant at it. They see the fruit of their toil pass into the
covetous hands of a titular, deaf to the cries of misery, whose ears
are filled with the clatter of political affairs and the rattle of pleasure.
Let the king seize on the property of the Church and pay with it the
debts of the State—this is what the country desires! The Church has
no need of fiefs to govern souls.’
Whilst the high dignitaries rolled in riches, a large class of priests,
and that the most deserving, vegetated in a wretched condition of
poverty. These were the curés of parishes, who were deprived of the
tithe which passed into the hands of some lay or high clerical
impropriator, and who received only a small indemnity, called the
portion congrue, scarcely sufficient to keep them from perishing with
hunger.
 The cahiers are full of commiseration for these poor disinherited
sons of the Church. Villiers-sur-le-Roule and Tosny assert ‘that the
benefice of their curés, reduced to the portion congrue, is absolutely
insufficient for their support, and for enabling them to render help to
the poor. The Abbé of Conches absorbs half the tithe, and he does
not give a sous to the relief of the parish.’ At Muids, ‘the collegiate
church of Ecouis receives all the tithes. The chapter gives nothing to
the poor, and seeks only to augment the revenue. The curé is
reduced to misery.’ The situation is the same at Saint-Aubin-sur-
Gaillon: ‘The extent of this parish makes the presence of a curate
necessary, and as he receives from the Abbé de la Croix-Saint
Leufroy, who holds the great tithes, only three hundred and fifty
livres, and as the sum is quite insufficient, he is obliged to go round
at harvest-time, like a begging friar, through the hamlets, asking for
corn and wine and apples. Surely this is lowering the priest, and is
adding an impost to the already taxed parish.’ ‘When the curés have
hardly a bare subsistence,’ says the memorial of Fontenay; ‘when
they are reduced to live on what is strictly necessary, what can they
offer to the poor? They have only their tears. Let the curés have the
tithe of the parishes in which they minister.’
Still more hardly treated were the town curés, for the portion
congrue paid them was smaller in proportion than that given to the
country priests, upon the excuse that the difference was made up by
the increased number of fees. But it was forgotten that the charges
and other expenses of a town, the calls on the priest’s purse, were
far greater in a populous city than in a country village.
The house of the clergy was the theatre of stormy scenes, which
broke out between the high dignitaries and the curés living on the
portion congrue. These latter had a numerical advantage; they
formed a majority of thirty to one. On the evening of the 16th,
instead of bearing to the episcopal palace the expression of their
deference, they assembled, to the number of three hundred, in a
chapel. There, disdaining all moderation of language, a curé of the
diocese of Évreux boldly said that the inferior clergy had groaned too
long under the oppression of the bishops, and that it was time to
shake off a yoke which had become as odious as it was intolerable.
A second orator, a curé of the diocese of Lisieux, no less
energetically expressed the same opinion. A third priest, having risen
to speak, began to defend the episcopate, whereupon he was
silenced by the clamour of the throng of priests, and his cassock was
torn off his back. When, on the 17th of March, the official
deliberation of the clergy was opened at the Seminary of S.
Taurinus, the Bishop of Évreux proposed to nominate a secretary,
and mentioned his choice; but his nomination was rejected with a
firmness which let him understand that the vast majority of his
clergy were antagonistic to his wishes. Every proposition made by
this prelate and his colleague met with a similar fate, and the
memorial addressed to the Crown was drawn up without their
participation, and in a spirit hostile to the high clergy.
On March 21, the Bishop of Évreux, smarting under the
humiliations to which he was exposed, wrote a letter to M. Necker,
Minister of Finances, filled with complaints. It contained the
following passage:—‘It is impossible for me, say what I will to them,
to keep this assembly of wild, excited curates in control. I am cast,
like a Christian of old, ad leones. These priests, calculating on their
numbers, are inflated with pride, and bear down all remonstrance.
And these are the men we are to send to the States-General,
without a shadow of knowledge of our ecclesiastical affairs; without
a trace of interest in the maintenance of our prerogatives; without a
glimmer of sympathy for our rights, jurisdictions, fiefs, and our
territorial possessions. They are prepared to overturn everything;
they are indifferent to the spoliation of the Church; they are even
prepared to hail its disestablishment, if one were fool enough to
suggest such a possibility.
‘The high beneficed clergy are unrepresented; how can they be
otherwise, when the great majority of the deputies are taken from
amongst curés who have, as a general rule, no interest in defending
our properties? You are too just not to be struck with the
inconveniences which this general summons of our clergy to an
assembly must drag down on us, and I venture to hope that in
future I shall not be again subjected to the indignity of presiding
over a tumultuous and disorderly rout, such as that at present
assembled. My zeal for the public welfare, and my devotion to the
Crown, have alone sustained me against the outrages I have
endured, to the like of which I have never previously been subjected
in my diocese.’
A few days after, the bishop received an answer from M. Necker,
couched in these laconic terms:—
‘Monseigneur, I grieve to hear of the schism in the assembly under
your presidence. But who is to blame if the children revolt against
their father? I have read somewhere the injunction, which you, my
Lord, may also possibly have seen, “Fathers, provoke not your
children to wrath.”’
On the 23rd, the cahiers, or memorials of complaints and
recommendations, were completed, and on the 24th the election of
deputies took place. In the hall of the Seminary the election of
clerical delegates was the scene of the final struggle between the
upper and lower clergy, and it was fought with greatest violence. On
the preceding evening the bishops had concerted with those clergy
on whom they thought they could rely, and had resolved to bring
forward M. Parizot de Durand, incumbent of Breteuil, and M. de la
Lande, curé of Illiers-l’Évêque. The former was a worthy priest,
greatly beloved for his piety, exceedingly obstinate in his adhesion to
the existing state of affairs, and utterly averse to change in any
form. He had a favourite maxim, ‘quieta non movere,’ which he
produced on every possible occasion, and which was, in fact, the law
of his life. It was in vain for those who saw the agitation of mind,
and the effervescence of popular feeling, to assure him that nothing
was quiet; the stolid old Conservative was not to be shaken from his
position, and maintained that this excitement was due to the moving
of things hitherto quiet, and that the only cure for it was to reduce
them to their former condition of stagnation.
M. de la Lande was a man of family. He had been appointed in
1765 incumbent of the church of Nôtre-Dame in Illiers-l’Évêque; he
was a pluralist, enjoying, in addition, the incumbency of S. Martin,
the second parish in the barony. The collation to these two rich
benefices belonged to the Bishop of Évreux, who was lord of Illiers,
the barony having been made over to the see by Philip de Cahors in
the thirteenth century. M. de la Lande was a courtier, and was often
at Versailles. In his parish he was liked as an amiable, easy-going
parson, fond of his bottle, and passionately addicted to the chase.
It was arranged that the bishops and beneficed clergy should not
appear prominently as supporting these candidates, but that they
should be proposed and seconded by members of the assembly not
suspected of being rigid partizans of the ancien régime. Monseigneur
de Narbonne had given up the hope of being himself elected, and
deemed it prudent not to allow his name to be proposed.
At nine o’clock the Bishop of Évreux took his seat in the hall of the
Seminary. The large windows admitted floods of light, and the
casements were opened to allow the spring air to enter. The snow
had wholly disappeared during the last few days, and a breath of
vernal air had swept over the land, promising a return of warmth
and beauty. The swallows were busy about the tower of S. Taurin;
from the bishop’s seat the belfry was visible, and the scream of the
excited birds that wheeled and darted to and fro was audible. Now
and then a jackdaw dashed through the fluttering group with a dry
stick in its beak, to add to the accumulation of years which
encumbered the turret stairs. The Cathedral bell summoned the
electors, and they came to their assembly-room in groups of two
and three, and took their seats in silence. The bishop looked sullen
and discontented; he sat rubbing his episcopal ring, breathing on it,
and polishing it on his cuff, and then looking out of the window at
the birds. His large fleshy cheeks hung down, and their usual beefy
redness was changed to an unwholesome mottle of pink and purple.
His barber had not attended on him that morning, or the prelate had
been too busy to allow himself to be shaved, so that his chin and
upper lip presented a rough appearance, which helped to make him
look more ill at ease and out of condition than he had during the
earlier part of the session. He took no notice of the clergy as they
entered, and was regardless of Monsieur de la Ferronnais when he
took his place near him. Every now and then he muttered to himself
expressions of disgust at the situation in which he was placed, and
aspirations for a speedy termination to the session.
‘Good morning, my dear Lord,’ said the Bishop of Lisieux, touching
his arm. The Bishop of Évreux looked round sulkily, placed his hands
on the arms of his chair, and raised himself slightly from the seat.
Monseigneur de la Ferronnais was a bright old man, amiable, fond of
fun, not particularly anxious about the turn matters took. He was
sure that ‘all would come right in the end.’
‘This is your last day in purgatory,’ he said to his colleague.
‘I thank Heaven,’ answered Monseigneur de Narbonne, without
looking at him.
‘You take these troubles too seriously, you lay them too much to
heart,’ continued the Bishop of Lisieux. ‘Let the boys wrangle over
their precious cahiers and doléances; we know very well that they
are sops—sops to Cerberus. The Government will never read them,
and it pleases the poor fellows to be called to scribble their
complaints. Possibly the charming queen wants curl-papers for the
ladies of the Court, and has hit on this sweet expedient of obtaining
paper at no personal cost.’
‘I cannot, and will not, stand this much longer,’ said the Bishop of
Évreux. ‘I am like the martyr who was stabbed to death with the
styles of his scholars. It is the indignity which I am subjected to that
galls me to the quick.’
‘Put your pride in your pocket,’ laughed M. de la Ferronnais. ‘We
have long ago learned to pocket our conscience at the bidding of the
Crown; perhaps our self-respect may fill the other pocket, and so
balance be preserved.’
The Bishop of Évreux did not answer. The Cathedral bell had
ceased, and, with an expression of impatience and disgust visible to
all in the room, he rang his hand-bell and opened the sitting.
 ‘Gentlemen,’ he said, ‘we have before us this day an important
duty to fulfil. Let me ask of you to remember that it is not to be
undertaken lightly and in a spirit of private pique. You have to elect
delegates to the national council. You are hardly aware how great
are the issues in the hands of that assembly. If you send men to
utter there the wild sentiments you have been pleased to express in
your paper to the king, you will revolutionise France and the Church.
That there have been, and still exist, abuses in the political and
ecclesiastical worlds, I am the last to deny. In times of great
excitement, extreme partizans of change may precipitate the
constitution into an abyss from which it would take centuries of
reconstruction to recover it. You will be good enough to remember
that the Church in this land is established, that it enjoys great
privileges and possessions; that to wrest from her those possessions
would be to leave her suddenly in a condition of destitution for
which she is wholly unprovided, and to rob her of her privileges will
be to subject her to an indignity from which it is your place to shield
her, as your spiritual mother and the bride of Christ. Gentlemen,
hitherto you have exhibited yourselves as a compact and resolute
body of malcontents. I do not use the word in an injurious sense. I
say you have exhibited yourselves as malcontents, as dissatisfied
with the existing state of affairs in Church and State. If you wish to
have abuses rectified, it will not be by violent men who endeavour to
tear down every institution which by its antiquity has become full of
rents, but it will be by men of calm judgment and reconstructive
ability, who will carefully and reverently restore and re-adapt what is
decayed and antiquated. I ask of you, then, in the interest of your
order, to elect persons of matured judgment and practical
experience. It can be no secret to you that the fate of France
depends on the attitude assumed by your delegates. The house of
the nobility is naturally attached to conservative principles, that of
the third estate is liberal and revolutionary. It will be our mission to
arbitrate between these contending interests, on the one side to
conciliate the people, and on the other to move the aristocracy to
relinquish their most obnoxious privileges, and to lend their
shoulders to ease the third estate of the yoke which, it is universally
Welcome to Our Bookstore - The Ultimate Destination for Book Lovers
Are you passionate about books and eager to explore new worlds of
knowledge? At our website, we offer a vast collection of books that
cater to every interest and age group. From classic literature to
specialized publications, self-help books, and children’s stories, we
have it all! Each book is a gateway to new adventures, helping you
expand your knowledge and nourish your soul
Experience Convenient and Enjoyable Book Shopping Our website is more
than just an online bookstore—it’s a bridge connecting readers to the
timeless values of culture and wisdom. With a sleek and user-friendly
interface and a smart search system, you can find your favorite books
quickly and easily. Enjoy special promotions, fast home delivery, and
a seamless shopping experience that saves you time and enhances your
love for reading.
Let us accompany you on the journey of exploring knowledge and
personal growth!

ebookgate.com