Visit https://ebooknice.

com to download the full version and

explore more ebooks

(Ebook) Object-oriented software development using

Java: principles, patterns, and frameworks / by
Xiaoping Jia. ISBN 9780201737332, 0201737337

_____ Click the link below to download _____

https://ebooknice.com/product/object-oriented-software-
development-using-java-principles-patterns-and-
frameworks-12073598

Explore and download more ebooks at ebooknice.com

Here are some recommended products that might interest you.
You can download now and explore!

(Ebook) Biota Grow 2C gather 2C cook by Loucas, Jason; Viles, James

ISBN 9781459699816, 9781743365571, 9781925268492, 1459699815,
1743365578, 1925268497

https://ebooknice.com/product/biota-grow-2c-gather-2c-cook-6661374

ebooknice.com

(Ebook) Object-oriented software engineering : using UML, Patterns,

and Java by Bruegge, Bernd; Dutoit, Allen H. ISBN 9781292024011,
1292024011

https://ebooknice.com/product/object-oriented-software-engineering-
using-uml-patterns-and-java-7113000

ebooknice.com

(Ebook) Object-Oriented Software Engineering: Practical Software

Development using UML and Java by Timothy Lethbridge, Robert Laganiere
ISBN 9780072834956, 0072834951

https://ebooknice.com/product/object-oriented-software-engineering-
practical-software-development-using-uml-and-java-2450308

ebooknice.com

(Ebook) Object-Oriented Software Engineering: Using UML, Patterns and

Java (2nd Edition) by Bernd Bruegge, Allen H. Dutoit ISBN
9780130471109, 0130471100

https://ebooknice.com/product/object-oriented-software-engineering-
using-uml-patterns-and-java-2nd-edition-1407332

ebooknice.com
(Ebook) Matematik 5000+ Kurs 2c Lärobok by Lena Alfredsson, Hans
Heikne, Sanna Bodemyr ISBN 9789127456600, 9127456609

https://ebooknice.com/product/matematik-5000-kurs-2c-larobok-23848312

ebooknice.com

(Ebook) SAT II Success MATH 1C and 2C 2002 (Peterson's SAT II Success)

by Peterson's ISBN 9780768906677, 0768906679

https://ebooknice.com/product/sat-ii-success-
math-1c-and-2c-2002-peterson-s-sat-ii-success-1722018

ebooknice.com

(Ebook) Master SAT II Math 1c and 2c 4th ed (Arco Master the SAT
Subject Test: Math Levels 1 & 2) by Arco ISBN 9780768923049,
0768923042

https://ebooknice.com/product/master-sat-ii-math-1c-and-2c-4th-ed-
arco-master-the-sat-subject-test-math-levels-1-2-2326094

ebooknice.com

(Ebook) Cambridge IGCSE and O Level History Workbook 2C - Depth Study:

the United States, 1919-41 2nd Edition by Benjamin Harrison ISBN
9781398375147, 9781398375048, 1398375144, 1398375047

https://ebooknice.com/product/cambridge-igcse-and-o-level-history-
workbook-2c-depth-study-the-united-states-1919-41-2nd-edition-53538044

ebooknice.com

(Ebook) Object Oriented Programming using Java by Kendal S. ISBN

9788776815011, 8776815013

https://ebooknice.com/product/object-oriented-programming-using-
java-1131714

ebooknice.com
Object oriented software development using Java
principles patterns and frameworks 2nd Edition Xiaoping
Jia. Digital Instant Download
Author(s): Xiaoping Jia.
ISBN(s): 9780201737332, 0201737337
Edition: 2
File Details: PDF, 91.39 MB
Year: 2003
Language: english
Obje_ct-O_rie_11te____ __._eRI_NcLeLEs__ _ _

Software Development PATTERNS, AND

U_sjng_Jaya:_ ME_W_QRJ{s_ _

Xiaoping Jia
DePaul University

~
.
Addison
WPsl<•y

Uo1Jto11 San Francisco New York

London Toronto Sydney Tokyo Singapore Madrid
MexJco City Munich Purlll Cnpc Town Hong Kong Montreal
Senior Acquisitions Editor Maite Suarez-Rivas
Project Editor Katherine Harutunian
Senior Production Supervisor Juliet Silveri
Production Services P. M. Gordon Associates, Inc.
Composition and Text Illustration Windfall Software, using ZzTe)(
Cover Design Supervisor Gina Hagen Kolenda
Cover Designer Jean Wilcox
Executive Marketing Manager Michael Hirsch
Print Buyer Caroline Fell

Cover image © 2002 by PhotoDisc.

Acces the latest information about Addison-Wesley titles from our World Wide Web site:
www.aw.com/cs

Many of the designations used by manufacturers and sellers to distinguish their products are
claimed as trademarks. Where those designations appear in this book, and Addison-Wesley
was aware of a trademark claim, the designations have been printed in initial caps or all caps.

Toe programs and applications presented in this book have been included for their instructional
value. They have been tested with care, but are not guaranteed for any particular purpose. The
publisher does not offer any warranties or representations, nor does it accept any liabilities
with respect to the programs or applications.

Credits: Figure 1.2: Kruchten, Rational Unified Process 2nd ed., Fig. 2.2 (p. 23), © 2000
Addi.son Wesley Longman Inc. Reprinted by permission of Pearson Education, Inc. Figure
3.1: Riggs et al, Programming Wireless Devices w/Java 2 Platform, Micro Edition, Fig. 2.1
(p. 8), © 2001 Sun Microsystems Inc. Reprinted by permission of Pearson Education, Inc.

Library of Congress Cataloging-in-Publication Data

Jia, Xiaoping.
Object-oriented software development using Java : principles, patterns, and frameworks
/ Xiaoping Jia-2nd ed.
p. cm.
lnclude-s bibliographical references and index.
lSB 0-201-73733-7
1. Object-oriented programming (Computer science) 2. Computer
softwar~Development. 3 . Java (Computer program language) I. Title.
QA76.64 J53 2003
005.13'3--0c21
2002032639

For information on obtaining permission for the use of material from this work, please submit
a wrinen request LO Pearson Education, Inc., Rights and Contracts Department, 75 Arlington
SL, Suite 300, Boston, MA 02116 or fax. your request to 617-848-7047.

Copyright © 2003 by Pearson Education, Inc.

All rights reserved. No part of this publication may be reproduced, stored in a retrieval system,
or transmitted, in any form or by any means, electronic, mechanical, photocopying, recording,
or otherwise, without the prior written permission of the publisher. Printed in the United States
of America.
2 3 4 5 6 7 8 9 10- HT-05 04 03
To Ai-Ling and Robin
B•,ZiiiiiH

Preface xv

CHAPTER 1 Object-Oriented Software Development 1

1.1 The Challenges of Software Development 2
1.2 An Engineering Perspective 4
1.2.1 Software Development Activities 4
1.2.2 Software Development Processes 5
1.2.3 Desirable Qualities of Software Systems 6
1.2.4 Is Software Development an Engineering Process? 8
1.3 Object Orientation 9
1.3.1 Modeling the Real World 9
1.3.2 Evolution of Programming Models 10
1.3.3 A Brief History 10
1.4 Iterative Development Processes 11
1.4.1 Object-Oriented Development Activities 12
1.4.2 Rational Unified Process 13
1.4.3 Extreme Programming 15
Chapter Summary 16
Further Readings 17
Exercises 18

CHAPTER 2 Object-Oriented Modeling Using UML

2.1 Principles and Concept 19
2.1.1 Object and Cla e 20
2.1 .2 Principle 26
2.2 Modeling Relation hip and Structure 29
2.2. l Inheritance 29
2.2.2 A ociation 32
2.2.3 Aggregation and Compo ition 34
2.2.4 Dependency 35
2.3 Modeling Dynanuc Behavior 36
viii • Contents

2.3.1 Sequence Diagram 36

2.3.2 State Diagram 37
2.4 Modeling Requirements with Use Cases 41
2.4.1 Tem1s and Concepts 41
2.4.2 Use Case Diagrams 42
2.5 Case Study: An E-Bookstore 44
2.5.1 Conceptualization 44
2.5.2 Use Cases 44
2.5.3 Object Models 46
Chapter Summary 51
Further Readings 52
Exercises 52

CHAPTER 3 Introduction to Java 55

3.1 An Overview of the Java 2 Platform 56
3.2 The Java Run-Time Architecture 59
3.2.1 Program Execution Models 60
3.2.2 Java Vrrtual Machine 61
3.3 Getting Started with Java 65
3.3. l A Simple Java Application 65
3.3.2 A Java Applet 67
Common Problems and Solutions 72
Chapter Summary 73
Further Readings 73
Exercises 74

CHAPTER 4 Elements of Java 75

4.1 Lexical Elements 76
4.1.1 Character Set 76
4.1.2 Identifiers 77
4.1.3 Primitive Types and Literals 77
4.1.4 Operators and Expressions 80
4.2 Variables and Types 87
4.2.J Variable Declarations 88
4.2.2 Type Compatibility and Conversion 88
4.2.3 Reference Types 89
4.2.4 Arrays 91
4.3 Statements 93
4.3.) Expres ion Statements 94
4.3.2 Statement Blocks 94
4.3.3 Local Variable Declarations 95
4.3.4 The return Statement 95
4.3.5 Selection Statements 96
 Contents ■ ix

4.3.6 Loop Statements 96

4.3.7 The break and continue Statements 99
4.4 Class Declarations JO 1
4.4. l Syntax of Class Declarations 101
4.4.2 Creating and Initializing Objects 104
4.4.3 Accessing Fields and Methods I 06
4.4.4 Method Invocation and Parameter Passing 107
4.4.5 Class (Static) Fields and Methods 110
4.4.6 Object Reference this 114
4.4.7 Interfaces and Abstract Classes 117
4.4.8 Strings 118
4.4.9 Wrapper Classes 128
4.5 Packages 134
4.5.l Using Packages 135
4.5.2 Partitioning the Name Space 136
4.5.3 Packages and the Directory Structure 136
4.5.4 Organization of the Java Class Library 138
4.6 Exceptions 139
4.6.1 Sources of Exceptions 140
4.6.2 Hierarchy of Exceptions 140
4.6.3 Throwing Exceptions 143
4.6.4 Catching and Handling Exceptions 144
4.7 A Simple Animation Applet 148
Chapter Summary 155
Exercise 156
Project 157

CHAPTER 5 Classes and Inheritance 159

5.1 Overloading Methods and Corrtructor 159
5.2 Extending Cla e 163
5.2.1 Constructor· of Extended C la e 164
5.2.2 Subtype and Polymorphi m 165
5.2.3 Overriding Method 171
5.3 Extending and Implementing Interface 176
5.3. l Subtype RevLited 177
5.3.2 Single Ver u Multiple Inheritance 179
5.3.3 Name Colli ' ion among Interface 183
5.3.4 Marker Interfaces 184
5.4 Hidino0 Field · and Class Mel.hod · 14
5.5 Application - Animation Applets l 6
5.5. l Parameters of ppkts l 6
5.5.- An Idiom for Animation Applets 188
5.5.3 Double-Buffered Animation 193
5.5.4 Reading File · in Applet · 200
X ■ Contents

Common Problems and Solutions 202

Chapter Summary 202
Exercises 204
Projects 204

CHAPTER 6 From Building Blocks to Projects 207

6.1 Design and Implementation of Classes 207
6.1 .1 Public and Helper Classes 207
6.1.2 Class Members 209
6.1.3 Design Guidelines 209
6.1.4 Documenting the Source Code 214
6.2 Contracts and Invariants 216
6.2. l Contracts of Methods 216
6.2.2 Invaraints of Classes 222
6.2.3 Assertions 224
6.2.4 Design by Contract 226
6.3 The Canonical Form of Classes 227
6.3.1 No-Argument Constructor 228
6.3.2 Object Equality 228
6.3.3 Hash Code of Objects 230
6.3.4 Cloning Objects 231
63.5 String Representation of Objects 234
6.3.6 Serialization 234
6.4 Unit Testing 235
6.4.1 Simple Unit Testing 235
6.4.2 JUnit-A Unit-Testing Tool 239
6.4.3 Testing Coverage Criteria 241
6.5 Project Build 243
6.5.1 Ant-A Build Tool 243
Chapter Summary 246
Further Readings 247
Exercises 247

CHAPTER 7 Design by Abstraction 249

7.1 Design Patterns 249
7. l . l Design Pattern: Singleton 251
7.2 De igning Generic Components 252
7 .2.1 Refactoring 252
7 .2.2 Design Pattern: Template Method 266
7 .2.3 Generalizing 271
7.2.4 Design Pattern: Strategy 275
7.3 Abstract Coupling 276
7.3.1 Enumerating Elements 278
 Contents • Xi

7.3.2 Design Pattern: Iterator 283

7.4 Design Case Study-Animation of Sorting Algorithms 284
7.4.l The Initial Implementation 285
7.4.2 Separating Algorithms 290
7.4.3 Design Pattern: Factory 296
7.4.4 Separating Display Strategies 296
Chapter Summary 302
Further Readings 304
Exercises 304
Project 304

CHAPTER 8 Object-Oriented Application Frameworks 305

8.1 Application Frameworks 305
8.1.1 Characteristics 306
8.1.2 Design Requirements 307
8.1.3 Specific Frameworks Considered 308
8.2 The Collections Framework 308
8.2.1 Abstract Collections 309
8.2.2 Interfaces of Collections 310
8.2.3 Implementations of Collections 315
8.2.4 Iterators of Collections 319
8.2.5 Ordering and Sorting 324
8.3 The Graphical User Interface Framework-AWT and Swing 333
8.3.1 The GUI Components 333
8.3.2 Design Pattern: Composite 336
8.3.3 Layout Managers 338
8.3.4 Handling Event 348
8.3.5 Frame and Dialogs 359
8.4 The Input/Output Framework 366
8.4.1 Byte Stream 367
8.4.2 Design Pattern: Decorator 380
8.4.3 Character Streams 382
8.4.4 Random Acces File 389
Chapter Summary 392
Further Reading 394
Exerci e 394
Projects 395

CHAPTER 9 Design Case Study: A Drawing Pad 397

9.1 Planning 97
9.2 Iteration l : A Simple Scribble Pad 398
9.2. l Th Scribbling Canvas and It Li tener 399
9.2.2 The Application 40-
Xii • Contents

9.3 Iteration 2: Menus, Options, and Files 403

9.3.l Strokes 403
9.3.2 The Scribble Canvas 405
9.3.3 The Canvas Listener 408
9.3.4 The Application 409
9.3.5 Choosing Colors 416
9.4 Iteration 3: Refactoring 421
9.4.l The Shapes 421
9.4.2 The Tools 424
9.4.3 Extending Components 428
9.5 Iteration 4: Adding Shapes and Tools 432
9.5.1 The Shapes 433
9.5.2 The Toolkit 436
9.5.3 Design Pattern: State 438
9.5.4 A Concrete Tool-TwoEndsTool 439
9.5.5 Extending Components 442
9.5.6 Design Pattern: Factory Method 447
9.6 Iteration 5: More Drawing Tools 448
9 .6.1 Filled Shapes 448
9.6.2 Drawing Filled Shapes 449
9.6.3 The Application 452
9.7 Iteration 6: The Text Tool 453
9.7.1 The Text Shape 454
9 .7 .2 The Keyboard Input Tool 455
9.7.3 The Font Option Menu 459
Chapter Summary 462
Further Readings 462
Project 463

CHAPTER 1O More Design Patterns 465

IO.I Type-Safe Enumeration Types 465
10.1.1 A Simple Maze Game 465
10.1 .2 Enumeration Types 466
I0.1.3 Unordered Ty~Safe Enumeration Idiom 468
10.1.4 Ordered Type-Safe Enumeration Idiom 469
10.2 Creational Design Patterns 470
J0.2.1 A Simple Design of the Maze Game 470
J0.2.2 Design Paltem.: Abstract Factory 484
10.2.3 Design Pattern: Factory Method 491
I0.2.4 Design Pattern; Prototype 495
10.2.5 Design Paltem: Builder 502
10.3 Behavioral Patterns 507
10.3.1 Design Pallern: Command 507
 Contents ■ xiii

10.3.2 Supporting Undo 509

10.4 Structural Patterns 513
I 0.4.1 Design Pattern: Adapter 513
I0.4.2 Design Pattern: Composite 531
Chapter Summary 544
Further Readings 545

CHAPTER 11 Concurrent Programming

547
11.1 Threads 547
11.1.1 Creation of Threads 548
11.1.2 Controlling Threads 553
11.2 Thread Safety and Liveness 556
11.2.1 Synchronization 557
11.2.2 Cooperation Among Threads 564
11 .2.3 Liveness Failures 569
11.3 Design Case Study-Tic-Tac-Toe Game 571
11.3.1 The Game Board 572
11 .3.2 The Game 577
11.3.3 The Players 579
11.3.4 Idiom: Talcing Turns 582
Chapter Summary 583
Further Reading 584
Exercises 584
Projects 585

CHAPTER 12 Distributed Computing 587

12.1 Socket-Based Communication 588
12.1 .1 Server and Client Sockets 5 8
12.1 .2 Server and Client U ing Socket 590
12.1.3 De ign Ca e Study-Stock Quote I 600
12.2 Remote Method Invocation 61-+
12.2.1 The Architecture 614
12.2.2 U ing RMI 616
12.2.3 De ign Ca e Stud -Stock Quote lI 620
12.3 Java Databa e Connecti ity 628
12.4 Common Object Reque, t Broker Archite ture 640
Chapter Summary 641
Further Reading, 642
Exercise, 642
Projects 643
XiV • Contents

APPENDIX A Summary of the APPLET Tag 645

APPENDIX B Summary of Documentation Tags 647

APPENDIX C Summary of Java Naming Conventions 649

Glossary 653

References 663

Index 667
 Object-Oriented Software
Development

CHAPTER OVERVIEW
In this chapter, we provide an overview of object-oriented software development. We
start w ith a general d iscussion of software development processes and the desi@ble
qualities of software products. Next, we discuss what makes software development
difficult and the difference between software engineering and other more established
engineering practices. Then we take a close look at ite@tive software development
processes, including the Rational Unified Process (RUP) and Extreme Programming (XP).

Whether you are a novice or experienced computer u er or programmer, you would

agree that we are living in an ex iting period of time with a con tant flow of inno-
vation in both computer hard, are and oftware. The oftware indu try wa one of
the mo t ucce ful indu ·trie' during the p:l'l t, o decade . ot only wa it growth
in market value exceptional. but it was al o able to deliver technologically advanced
and innovative products at an unrelenting pa e. Today, computer software ha become
prevalent in every a pect of life. ocietie are becoming more and more dependent on
oftwa.re y tern • from autopilot sy tern , of jetliners to computerized trading system
of tock market to per-anal organizer' on palm-top computer . However, oftware i

1
2 ■ Object-Oriented Software Development

expensive. The cost of purchasing, developing, maintaining, and �pgrading so�tware

systems has become the largest single expe� diture f or many bu messes, and it con­
tinues to increase. This continuing increase m software costs contrasts sharply to the
dramatic decrease in hardware costs and the equally dramatic increase in hardware
perfonnance and capabilities. The object-oriented software develop� ent methodol­
ogy aims to significantly improve current software �evelopm_ent practice. It ha _ been
well received and widely adopted by the software mdustry m recent years. It 1s the
methodology of choice in today's software development practices.

1.1 THE CHALLENGES OF SOFTWARE DEVELOPMENT

During the past two decades, the software industry has produced many technolog­
ically advanced, innovative, and commercially successful products. However, the
process of creating these successful products (i.e., software development) i a dif­
ficult, time-consuming, and costly endeavor. For example, the initial version of the
Microsoft Windows NT operating system consisted of 6 million line of code, co t
$150 million to develop, and took 200 developers, testers, and technical writers 5 years
to complete. The struggle to create Windows NT is vividly presented in Show-Stopper
[Zachary, 1994). Furthermore, software systems tend to be "buggy"; that i , they con­
tain glitches that hamper or even disrupt their normal function or performance. Minor
glitches can be merely annoying, but serious ones can be disastrous.

• On January 15, 1990, the AT&T long-distance telephone network broke down,
interrupting nationwide long-distance telephone services in the United State f or
more than 8 hours. An ill-placed break statement in the switching software,
written in the C language, was to blame for the breakdown.
• On June 4, 1996, the maiden flight of the new and improved Ariane 5 commu­
nication satellite launcher developed by the European Space Agency exploded
37 seconds after liftoff. An incorrectly handled software exception resulting from
converting a 64-bit floating point to a 16-bit signed integer caused the disaster.
• On June 8, 200 I, a software problem in the new trading software installed
overnight for the New York Stock Exchange caused failures in trading on half of
the floor of the exchange and forced the NYSE to shut down the entire trading
floor for more than an hour.

Although uch cata trophic failures are rare, minor glitches are common in almost all
oftware. In other words, buggy software is the nom1.
However, the state of oftware development practice i far from the "software
crisis" many have proclaimed in the past. Advances in many aspects of software de­
velopment methodologies and software engineering proce ses have made it po ible
I? develop many large-scale software systems that perform as expected most of the
time. We are not capable of delivering nor required to deliver 100% reliable software
The question i , How good i good enough?
 1.1 The Challenges of Software Development ■ 3

Software development is labor intensive. A majority of software development

projects are over budget and behind schedule. The reality of software development
remains that software is very expensive and often unreliable. Despite the phenomenal
success of the software industry in technological advance and innovation, it still face
challenges in delivering high-quality software on time and under budget. The object-
oriented software development methodology is one of the solutions the software
industry is embracing now, hoping to improve the reliability of software system and
the cost-effectiveness of software development.
In order to improve software development practice, let u first examine some
of the underlying causes of the difficulties of software development: complexity,
longevity and evolution, and high user expectations.

Complexity The software ystem being developed today are often very large and
complex. Complexity is dictated by the problems the sy tem are intended to solve
and the services they are intended to provide. From the engineering perspective, both
requirements are often beyond the control of software developers. The complexity
involved in a large-scale software system is so great that no individual can comprehend
every detail of the system. To build such a complex sy tem, it mu t be broken down
into manageable parts and requires the cooperative effo11s of a team of developer
rather than the efforts of an individual. Methodologie , techniques, and tool that
work well for small systems developed by individuals usually are not effective for
large systems developed by tean1s.

Longevity and Evolution Because of economic, political, and other constraint ,

software systems are often in service for very long periods of time. Today, some
legacy systems have been operating for more than 20 year . During their lifetimes,
software systems must constantly evolve to accommodate changes in u er ' need
and environments. However, making changes to software system (i.e., maintenance)
is a difficult task. Furthermore, maintenance not only is co tly and Lime-consuming,
but also usually degrades the quality of the ystem being maintained. On average,
the maintenance cost of a software system over it li fetime i far greater than its initial
development cost.

High User Expectations In the past, whe n computer were mainly u ed in univer-
sitie , research institutions, and large corporation , the majority of software ystem
users were scientists and engineer who had the technical kill 10 handle glitche
they might encounter while using the sy tern . Today, computer are used in home ,
school , and businesses of all size , and are used for plea ure a well a for work.
The majority of today's software u er are nontechnical, ordinary people. Computer
oftware products are con idered more and more like con umer producl and are ex-
pected to perfom1 with the a me depe ndability as hou ehold appliances. Occa ional
glitche that once were con idered acceptable are now intolerable. Software Y tern
are expected to be " bug-free ," but uch perfection i next to impossible.

The challenge faced by oftware development are to find effective olution to

control the complexicie of oft ware y tern , co manage the longevity and e olution of
software y tern , and to deliver oftware y rems with higher reliability and u ability.
4 ■ Object-Oriented Software Development

I>

AN ENGINEERING PERSPECTIVE
..i
The term software engineering was coined al a NATO workshop in 1968. It repre­
ented an aspiration to m ch e practice of software development on a solid scientific
foundation and to attain the level of reliability and productivity associated with well­
e tabli hed engineering di cipline , uch as civil and mechanical engineering.
Software engineering is �jneering discipline concerned with al�
developing and delivering high-quality and use�i:�ecti-ve-manner.
Software engineering defines the various activities in the software development and
the products, or deliverables, a sociated with these activities. Software engineering
also define the sofnvare development processes, which define the order for carrying
out the development activities and the criteria for the deliverables of the activities.

1.2.1 Software Development Activities

The most important product of software development is obviously the software. Most
people equate software to computer programs, or the source code. However, the source
code is onJy a part of the products produced in software development. In software
engineering, the term software is defined in a broader sense. It encompasses the source
code as well as all the associated documentation produced during the various activities
in the sofu are development process. The documentation of software may include
requirements specifications, architecture and design documents, configuration data,
installation and user manuals, and so on. Software development usually involves the
following activities:

Requirements Analysis The goal of requirements analysis is to establish the func­

tions, services, and constraints of the software to be developed. For custom software,
that is, oftware developed for one specific customer, this is usually accomplished by
consultation with system users. For commercial ("shrink-wrapped") software, that
is, software intended to be marketed and sold to any customers who are willing to
buy it, this goal is usually accomplished by market analysis of perceived needs of
potential customers and/or feedback from existing customers. There are two cate­
gories of requirements:fimctiona/ requirements, which are concerned with functions
and ervices to be performed by the software, and nonfunctional requirements, which
are concerned with the constraints under which the software must operate, such as
response time, memory consumption, and user friendliness. The main concern of
requirements analysi is lo define the problem to be solved. The requirements are
documented in requirements specifications or system specifications.

Design The goal of design is to construct a solution to the problem by establishing

an overall architecture of the software, by partitioning the software into components
or sub ystem , and by identifying the relationships and dependencies among them.
These de ign activities can often be further divided into systern design, which is
primarily concerned with rhe decomposition of complex problems into manageable
 1.2 An Engineering Perspective ■ 5

components, and detail design, which is primarily concerned with the solutions to
each component. Software designs are often documented using various diagrams.

Implementation and Unit Testing Implementation is the realization of the soft-

ware design in programs, that is, source code. Each component is implemented
separately. Unit testing is carried out to test each individual component, or unit, inde-
pendently. The goal of unit testing is to ensure that each unit functions properly with
respect to its specification before the units are integrated.

Integration and System Testing The individual components or units are integrated
and tested as a whole to ensure that the entire software system functions properly with
respect to its specification.

Maintenance Maintenance involves a variety of activities after the delivery of

software systems. These activities include correcting bugs, improving performance,
enhancing functions or services, and adapting to new environments. Software main-
tenance continues as long as the software is in service. It is usually the longest and
most costly activity in the software life cycle.

1.2.2 Software Development Processes

The most well-known software development process is the ·<waterfall" model illus-
trated in Figure 1.1, which has been the de facto standard of the software development
process. In the waterfall model, the development activities are carried out in succes-
sive phases linearly: requirements analysis, design, implementation and unit te ting,
integration and system testing, and maintenance. A phase i the pan of time between
two major milestones of the process in which a well-defined et of objective are met,
artifacts are completed, and decisions are made whether to move into the next phase.
In principle, the deliverable of each phase must be approved (" igned off') before the

Figure 1.1
Requirements

l
analysis
The waterfall model
of software devel- +
I
I
opment. '---- - Design

+
,' _____
I
i
Implementation
and unit testing

+
I
I
i
Integration and
·----- system testing

+
I
,_____
I
Maintenance
as

6 • Object-Oriented Software Development

next phase can begin. The rationale is that changes to the requirements specification
cost much less to implement in the requirements analysis than in the later phases. The
later the phase in which a change to the requirements is introduced, the more it costs.
So the goal is to minimize changes after the documents are delivered. This requires
that the tasks of each phase be completed thoroughly, and that the deliverables of each
phase be frozen once they are delivered and approved.
However, the waterfall model is not realistic. It is very common that changes
occur during every phase of the development process. The changes may come from a
number of sources: errors or faults of the specification and design may be discovered
during implementation; assumptions made in design may be proven false during
y tern testing; some features requested by the customers may be proven to be too
low, excessive in resource consumption, or infeasible during system testing; and
user needs and requirements may have changed after the requirements analysis is
completed. Therefore, in practice, it is often necessary to have several iterations of
the phase in the waterfall model. However, one of the major shortcomings of the
waterfall model is that it does not facilitate such iterations.
There are several alternative software development processes that are designed
to carry out the software development activities in an iterative fashion. The itera-
tive software development processes are becoming popular and gaining acceptance
in practice, partly because of the wide acceptance of object-oriented development
methodologies, which are especially suited to iterative development. We will discuss
two of the common iterative development processes in Section 1.4.

1.2.3 Desirable Qualities of Software Systems

Let's now tum our attention to the products of software development-software

ystems. The following are the most desirable qualities of software systems:

Usefulness: Software systems should adequately address the needs of their

intended users in solving problems and providing services.
Trmeliness: Software systems should be completed and shipped in a timely
manner. Otherwise, they may be less useful or even useless owing to changes
in users' needs and operating environments. This factor is also important in
the software vendor's ability to remain competitive.
Reliability: Software system should perform as expected by users in terms of
the correctness of the functions being performed, the availability of service ,
and an acceptable level of failures.
Maintainability: Software ystems should be easily maintainable; that is, it
should be possible to make corrections, adaptations, and extensions without
undue costs.
Reusability: Components of software systems should not be designed as ad hoc
olutions to specific problems in specific contexts; rather they should be
designed as general solutions to a class of problems in different contex t
Such general components can be adapted and reused many times.
 1.2 An Engineering Perspective
• 7

User f .riendliness: Software systems should provide user-fn·endl Y mte · rfaces

tailored to the capabilities and the background of the intended
, ·1· users to
,aci Itate easy use and access to the full extent of the systems' capabilities.
Efficiency: Software systems should not make wasteful use of system
. . . . resources,
mcludmg processing time, memory, and disk space.

N?t all of these desir~ble qualities are attainable at the same time, nor are they of
equal importance. A crucial part of software development is dealing with the trade.-
o~s amo?g these different qualities to achieve a reasonable balance. Obviously, the
obJect-on:nted developm~ t approach cannot directly improve aJI these qualities. It
~cuse~ primarily O!!_improving_the_!!laintainability and reusabj lity of software sys- ,
terns.Maintainability should be the focuo fife development process for three main
reasons. First, for software systems with long lifetimes, maintenance co ts will far ex-
ceed initial development costs. It is imprudent to compromise maintainability because
any savings that may result ini tial ly will undoubtedly be dwarfed by maintenance cost
penalties over the long run. Second, current development technology does not yield
high reliability in the initial release of software sy tern . Reliability i u ually attained
through repeated corrections during the development pha e and throughout the life-
times of software system . Software system reliability can be everely hampered by
poor maintainabi lity. Third, high maintainability require flexibility in the de ign and
implementation of software systems. Such flexibility facilitate the kind of incremen-
tal development that enhances reliability, u efulne s, and u er friendline . a well as
the ability to contain costs.
Several factors contribute to the maintainability of oftware y tern :

Flexibility: Flexibility mean that variou aspect of ofrware y tern. hould

be easily changeable. The impact of the change can be confi ned to mall
region , and the correctnes of the change can be verified locally. that L, by
only examining the small affected region rather than examining the entire
software.
Simplicity: Human beings are fal lible. It is impo ible for people to avoid making
mi take . However, when thing are imple. people are much le s error-
prone, and making ure that thing are working properly i' much ea ier. If
there are error , they become more obviou . and correcting them i ea. ier.
Complex software y terns can be implified by the effective u e of the
divide-and-conquer technique.
Readability: A prerequi ite fo r maintainability i. readability, or under tand-
ability, because ·oftware ·y tems mu t be under tood before they can be
modified. Readability depends on the clarity and the impli ity of the de ign
and the program code, the clarity :rnd completene of the accompanying
documentation, and a ' imp le and consi tent style of de, ign, implementation,
and documentation.

These fac tors me the fo us of our discu. sion of methods and techniques in later
chapters.
8 ■ Object-Oriented Software Development

1 .2.4 Is Software Development an Engineering Process?

After more than 30 year since its inception, there is still little consensus on the pr~cise
definition of software engineering, and even the legitimacy of using software_ engmeer
as a professional title is till being debated. As Shaw and Garlan [ 1996] pomted out,
software engineering is a label that
refers to a collection of management processes, software tooling, and design activities
for oftware de,·elopment. The resulting practice, however, differs significantly from
the practice of older form of engineering.

A clo e examination of traditional, well-established engineering disciplines reveals

that e eral e ential characteristics of those practices are absent in today's software
development practice.

Analysis of Designs
Over the centuries, craftsmanship clearly has proved capable of building magnificent
tructures. such as the Egyptian pyramids, Roman aqueducts, and Notre Dame Cathe-
dral. However, modem engineering offers assurance, predictability, and efficiency
that craftsmanship cannot match. One of the key differences between engineering
and craftsmanship is that the success of engineering projects can be assured before-
hand through scientific analysis of their designs, whereas the success of craftsmanship
projects is attained through trial and error during current and prior construction.
Civil engineers depend on mechanics to help them predict with confidence before
construction begins that a newly designed bridge or building will stand and function
as it is supposed to. Aerospace engineers depend on aerodynamics and simulation to
help them predict with confidence before it is built that a newly designed airplane
will fly.
In contrast, software developers largely depend on testing and debugging (i.e.,
trial and error) to establish confidence in their products. Software development is
like building modern skyscrapers with craftsmanship, with the success of software
development projects rarely assured beforehand.

Nonrecurrence of Failures
Failures, ometimes catastrophic, also occur in well-established engineering fields.
Perhaps one of the most spectacular failures in the history of engineering was the
collapse of the Tacoma Narrows Bridge in 1940. Its design was unconventional and
innovative, and the bridge was dramatic and elegant in appearance. Careful analysis
w~s per~o~ed to en ure that the bridge would behave well under its own weight
with ant1c1pated traffic load and winds as high as 45 miles per hour. However the
~esigner did nor fore~ee that the slender ~ridge deck would act like an airplane ~ing
ma moderate crosswind of less than 40 miles per hour, which twisted the bridge apart.
A oo~ a th~ cause of the collapse _was known, 1~easures were developed to prevent
such failures in the fu1ure. Hence, rn well-established engineering fields, the same
type of failure is rarely repealed.
 1.3 Object Orientation ■ 9

In software development, the same types of failures recur all the time. Few
practical measures can be taken to ensure the absence of certain types of faults in
software systems. The sad truth about software development is that no one can ensure
that the type of failure that occurred in Ariane 5 will never occur again.

Codification of Knowledge
The success of well-established engineering fields is due largely to the accumulation
and codification of knowledge and the reuse of prior solutions. Design knowledge
and solutions often are organized and presented in manuals and handbooks to make
common and routine design not only easier and faster, but also more reliable, depend-
able, and manageable. Designers often find solutions inhandbooks and then adapt and
assemble the solutions to their specific design problems. Only rarely are original and
innovative solutions needed. Usually, the codified knowledge includes what to avoid
as well as what to do.
In software development, although a lot of design knowledge and experience has
been accumulated, very little has been systematically codified. Without the benefit of
prior design solutions, each design of a software system i treated as an original.
Therefore, it is no surprise that software design is difficult, time-consuming, and
unreliable.
Thus, software development is quite different from the traditional engineering
disciplines. At best, it is an immature engineering discipline. For software develop-
ment to become a true engineering discipline, software developers must have mech-
anisms to carry out the analysis of designs, ensure nonrecurrence of knm,vn failures,
and codify design knowledge.

1.3 OBJECT ORIENTATION

1 .3.1 Modeling the Real World

The main goal of software development i to build soft\ are y tern that provide
services to people and enhance their abilitie to . olve problem in the real world. A
software system usually con i ts of two e ential component : a model, which is a
representation of a pertinent part of the real world, and an algorithm, which captures
the computation involved in manipulating or proce ing the model.

Software system
Abstraction
Model Algorithm
Interpretation
10 ■ Object-Oriented Software Development

The real world is enonnous and complex. Many of its aspects are fuzzy, unknown,
or intangible. 1n contrast, the programming models used in software systems must be
precise ~d relatively small. A model is necessarily a~ ~bstractio11 of the real world.
It capture only the essential and relevant charactenst1cs of the real wo_rld from a
particular perspective and ignores others. Models are intended to be manipulated or
proce ed. and their behaviors should mimic those of the rea~ worl_d to reflect the
cho en perspectives reasonably accurately. The results of mampulations can be fed
back to the real world through i11terpretatio11 (i.e., the assignment of meanings to the
entitie in the models) and often represent solutions to real-world problems.

1.3.2 Evolution of Programming Models

Programming languages are the main tools used by software developers to de-
scribe computer models. The evolution of progranuning languages and progranuning
methodologies is driven by the need to build more and more sophisticated and ef-
fective models. That need in turn is driven by the ever-increasing power of modern
computers and the desire to utilize this power.
One of the fundamental problems in software development is, How does someone
model the real world? The answer largely depends on the problems to be solved. One
way to look at the evolution of software development methodologies is through the
changing views of programming models.
In the 1950s and 1960s, the focus of software developers was on the algorithm. As
a result, the main concerns at that time were solving computation problems, designing
efficient algorithms, and controlling the complexity of computation. The models used
were computation-oriented models, and the decomposition of complex systems was
primarily based on control flo w.
In the 1970s and 1980s, different types of models emerged to address the com-
plexity of the data being processed. These systems were centered on data entities
and data fl ows, with computation becoming a secondary concern. The models used
were data-oriented models, and the decomposition of complex systems was primarily
based on data flow.
Object-oriented models represent a balanced view of the data and computation
aspects of software systems. Object-oriented models are composed of objects, which
contain data and the associated computations. The decomposition of complex systems
is based on the structure of objects, classes, and the relationships among them.

1.3.3 A Brief History

The origin of object-oriented software development dates back to the late 1960s. A
computer simulation language called Simula wa,; the first programming language that
included ome important features of object-oriented programming, such as class. The
fir t full -blown and perhaps the best known object-oriented programming language
was Smalltalk, developed by Xerox PARC in the I 970s. Object-oriented technology
grew tremendously during the 1980s, with the emergence of several more sophi _
 1.4 Iterative Development Processes ■ 11

ti�ated object- oriented programming languages, including C++, Objective-C

, and
Eiffel. It also evolved from a programming methodolo gy to a software devel
opment
metho do lo gy that addresses the analysis, design, testing, and evolution o
f software
systems in addition to the implementation of software systems. Despite its long
history
of devel opment, o nly recently has the object- oriented devel
opment appro ach matured
and become widely accepted by the mainstream software industry. This acceptance is
largely due to significant advances in several aspects of object-oriented development
method olo gy in recent years:
■ A number of object-oriented programming languages have become mature, prac­
tical, and widely accepted by the oftware industry, including C++ and later Java.
■ A number of object-oriented analysis and modeling techniques and notations
have been developed and eventually unified in the fonn of Unified Modeling
Language. UML has been widely adopted in the industry.
■ In 1995, the Design Patterns book was published. It repre ented the first system­
atic attempt at codifying object-o riented de ign knowledge.
■ Iterative development processes have been gradually accepted in practice.
The o bject-o riented so ftware development approach repre ent a dramatic depar­
ture from co nventional s oftware development approaches. It looks at the world from
a rather different perspective.

1.4 ITERATIVE DEVELOPMENT PROCESSES

In contrast to the traditional waterfall oftware development model, Boehm [ 1988]

prop o sed the first iterative software development proce . knm\' n as the spiml model.
Booch [ 1994] proposed an iterative oft\ are development proce for object-oriented
oftware development. Booch' iterative o bject-oriented de\ ' elopment proce con­
si ts of a number of succes ive iteration . Each iteration contain the follo\ ing tep :
identifying the classes, identifying the emantic· (i.e., attribute and behaviors) o f
the c lasses, identifying the relation hip among the clas es, defining the cla inter­
face, and then implementing the clas e . Each iteration deal· with a relatively mall
increment of the y tern being de �loped. Thu the y tem i de\'. eloped �ncremen­
tally, not as a mo nolithic piece. The iterative pro e continue unul the enure Y tern
i complete. Thi proc e i , hat B h ailed the micro proce • Bo�ch al O pro ­
po ed a macro proce to er e a the conlrolling frarne·work of the mi� ro proc� ·
The macro proce co nsi t of the folio,\' ing pha e : analy. i and modeling, de ign,
implementation, and maintenance.
Boo c h' iterative development pro e • became the foundation of lhe more com-
plete and nov widely adopted obje l-orienled de elopmenl p roce_ , �own as_ the
Ratio11a/ U11 ified Pro •ess ( RUP). lt al O in pired a number of hghtwe1ghl obJeCl­
orient d iterative de elopm nt proces�e . The mo. t , ell-known o f t�e e proc�sse
L th s o- alled Exmm,e P,vgrcimmi11i: ( P). ln thi ection, we begm by taking a
12 ■ Object-Oriented Software Development

look at the activities of object-oriented development. We then discuss so~ne of t~e

common characteri tics of iterative development processes. Next, we provide a bnef
overview of both RUP and XP. We will revisit and elaborate on many of the underly-
ing principles and technique of both RUP and XP throughout the remainder of the
book.

1.4.1 Object-Oriented Development Activities

Object-oriented development processes consist of activities that are similar to those in

the waterfall software development model discussed in Section 1.2.2. Compared to the
activitie in the waterfall software development model, the activities in object-oriented
development proce es have a rather different focus and adopt a rather different set
of techniques, notations, tools, and criteria. Here are the common activities in object-
oriented development processes:

Conceptualization_· The goal of conceptualization is to establish the vision and

the core requirements of the software system to be developed. Unlike the
requirements analysis phase in the waterfall process model, the goal here
does involve establishing the complete requirements of the system.
Object-oriemed analysis and modeling: The goal of object-oriented analysis and
modeling is to build models of the system's desired behavior, using notations
such as the Unified Modeling Language (UML). A model intends to capture
the essential relevant aspects of the real world and to define the services to
be provided and/or the problems to be solved. A model is a simplification of
reality, created to better understand the system to be developed. In contrast
to the informal requirements analysis in the waterfall process, the emphasis
here is to use notations such as UML, which includes use cases and class
diagrams, and so on, to describe the models in a way that is semantically
richer and more precise compared to informal paper documents.
Object-oriented design: The goal of object-oriented design is to create an
architecture for implementation. Designs are represented in terms of objects
and classes and the relationships among them. Key concerns of an object-
oriented design include the following: (1) Does the design satisfy all the
stated requirements and constraints and provide all the desired services
adequately? (2) Is the design flexible enough to accommodate future changes
and enhancements? (3) Is the design feasible for implementation, and, if so,
can it be implemented efficiently?
lmplemenrarion: The goal of implementation is to implement the design by using
an object-oriented programming language, such as Java. Implementation in-
volves coding, unit testing, and debugging. Key concerns of implementation
include I.he e: (1 ) Is the implementation correct? (2) I the implementation
effi cient and maintainable? (3) I the implementation robust, that is, capable
of tolerating faults and recovering from failures?
 1.4 Iterative Development Processes ■ 13

Maintenance: The goal of maintenance is to manage postdelivery evolution. The

primary maintenance tasks include removing bugs, enhancing functionali-
ties, and adapting the system to evolving needs and environments.
A key assumption in the iterative software development process is that changes
occur throughout the life cycle of software development. Instead of trying to minimize
or prevent changes, iterative software development processes try to facilitate and
manage changes. In iterative development processes, software systems are developed
in successive iterations. Each iteration represents a complete development cycle
for a small piece, or increment, of the entire system, from analysis and design,
to implementation and testing. The key characteristics of an iteration include the
following:

■ Each iteration is relatively small and can be completed in a relatively short period
of time.
■ Each iteration results in a release of an executable product or component, which
is a part of the final product.
The final product is developed incrementally from iteration to iteration.

1.4.2 Rational Unified Process

The Rational Unified Process (RUP) is a complete software engineering process. It

provides guidelines for carrying out every aspect of software development activities
with the goal to "ensure the production of high-quality software that meet the needs
of its end users within a predictable schedule and budget [Booch et al., 1999]." The
RUP is not one process, but a process framework that can be adapted and extended
to suit the needs of different organization and different type of project . The key
practices of the RUP are to:
■ develop software iteratively.
■ systematically elicit, organize, and manage changing requirement .
■ use component-ha ed architecn1re.
■ visually model software u ing UML.
■ continuously verify oftware quality.
■ control changes to oftware.
The empha i of the RUP i on building models rather than paper document . In
the RUP there are nine model that collectively cover all the important decision that
go into ~i ualizing, specifying. construcring, and documenting a . oftware-intensive
system [Booch et al., 1999]:
1. Business model: E tabli he an abstraction of the organization
2. Domain moclel: Establi he the context of the sy tern
3. Use case mo /el: E tablishe · the 'Y tem · functional requirements
4. Analysis model (vptimwl): E tabli hes an idea de ign
14 • Object-Oriented Software Development

5. Design model: Establishes the vocabulary of the problem and its solution
6. Process model (optional): Establishes the system's concurrency and synchro-
nization mechanisms
7. Deployment model: E tablishes the hardware topology on which the system is
executed
8. Implementation model: Establishes the parts used to assemble and release the
physical sy tem
9. Test model: Establishes the paths by which the system is validated and verified
The RUP i use case driven . Use cases defined for system requirements are the
foundation for all other development activities, including design, implementation,
and te ting. The RUP is architecture centric. The main focus of early iteration of the
development process is to produce and validate an executable architecture prototype,
which gradually evolves to become the final system in later iterations.
The process structure of the RUP can be illustrated in a two-dimensional chart
as hown in Figure 1.2. One dimension represents the time in terms of phases and
itera.tion . The other dimension represents the process work.flows. The chart shows
roughly the amount of time or attention devoted to each process work.flow during
various phases and iterations.
A process workjl.oH consists of a sequence of activities that produce a set of
anifacts, or deliverables, which can be project plans, design models, source code,
tests, and documentations. The RUP defines nine process work.flows:

1. Business modeling: Describes the structure and dynamics of the organization

2. Requireme nts: Describes the use case-based method for eliciting requirements
3. Analysis and design: Describes the multiple architectural views

Figure 1.2 Organization along time

Phases
Rational Unified Workflows I Inception j I~- El-ab-o-ra-ti-on~ I I Construction Transition
Process. (From
Kruchten [2000]
c Business modeling
The Rational Uni-
fied Process, An -
(1)
C
0
CJ
Requirements ~
t:
I

Introduction. Analysis and design

Addison-Wesley.)
Cl
C
.2 Implementation
~ 1
:..-::::::::::: t:- - -~ I
ca
C Test
0
.:: Deployment
<1l
·E Configuration and
:g, change management
0 Project management _............_,. ......__.. ..._~
I
; ,m,,m,i....- .. . . . . . . . .~;. . . . . . . . . . . . .
I I

Environment ~~====::~r;::;::~~==~:,,-::=======-4r========--
lnitlal
~ - - - ~ - ~ ~ #1
I
IElabllElabl 1cons111c onstj[Const j
#2 #N
[l'ra;,1
~ #2
1Tran \

Iterations
 1.4 Iterative Development Processes • 15

4. Implementation: Takes into account software development, unit test, and integra-
tion
5. Test: Describes test cases, procedures, and defect-tracking metrics
6. Deployment: Covers the deliverable ystem configuration
7. Con.figuration management: Controls change to and maintains the integrity of a
project's artifacts
8. Project management: Describes various strategies of working with an iterative
process
9. Environment: Covers the necessary infrastructure required to develop a system

The RUP also defines four major phases:

l. Inception: Establishes the business case for the project

2. Elaboration: Establishes a project plan and a ound architecture
3. Construction: Grows the system
4. Transition: Supplies the system to its end users

Each phase is further broken down into one or more irerations. Each iteration goes
through the various process workflows (de cribed earlier) and i a complete develop-
ment cycle that results in the release of an executable product. The phase serve as the
controlling framework of the iterations. Iteration in different phases have different
emphases on process workflows as illu trated in Figure 1.2. For example, iteration
in the inception phase focus more on business modeling and requirements, while it-
erations in the construction phase focu more on implementation and configuration
management.

1.4.3 Extreme Programming

Extreme Programming (XP) i a light\ eight pro e \ ith an empha i on producing

high-quality executable code throughout the development pro e _. Since executable
code is the mo t important part of the ultimate deli erable of the oftware develop-
ment proces e , the XP pro e fo u e on e. ecutable od from the ery beginning.
Hence the name Extreme Programming. E/treme Programming i an iterative proce
with small iteration . Each iteration often le ts no more than a few day. to a few
weeks. The very fir t iteration \ ill produ e a minimum skeletal, and executable
in1plementation of the y tem to be de el peel. Ea h ub~equent iteration hould
enhance or improve upon the deli erable of the preceding iteration and produce a
new executable reka' e of the tem until the entire tern L ompleted. Extreme
Programming emphasize~ maintaining high quali in the code delivered by each
and every iteration, e p "cially in tenn of the exten ibility and maintainability. The
focu of earh iteration an b either nh ncement or refa taring. E11hanceme11ts intro-
due ne\ fun tionalitie ' r features. Refm:rori11g re true tu re the code to improve the
quality, in luding xten ibilit nnd maintainability, and lhe structure of the oftware
' YSt m while maintaining its behn ior. E, treme Programming depend heavily on
 ~--'-============================---------
16 ■ Object-Oriented Software Development

refactoring to maintain and improve qualities and to facilitate changes and enhance-
ments.
The core of XP consists of the following key practices:
Planning game: Start with a simple a plan for each iteration, and continually
refine the plan as necessary.
Frequenr and small releases: Make frequent and small releases starting as early
as possible. Each iteration, that is, the duration for producing a release,
bould not be longer than a few weeks.
Metaphor: U e metaphor to start development and communicate with the
customers.
Simple design: Make design as simple as possible. Refactor later if changes are
nece sary.
Test first: Write unit test before writing code.
Refactoring: Refactor to make the system simpler and clearer or to reduce
duplication.
Pair programming: Write all production code in pairs.
Collective ownership: Anyone may change code anywhere in the system to
improve it.
Continuous imegrarion: Integrate as soon as a task is complete.
40-hourweek: Teams are more productive if the members stay fresh and energetic
than if they work overtime.
On-sire customer: Have a customer available on-site and full time.
Coding standards: Adopt common standards and conventions for naming, source
code fonnaning, documentation, and so on.

Undoubtedly, some of the practices are unique to XP, such as pair programming.
Extreme programming and RUP share a lot in common. In some sense, XP can be
viewed as a minimalistic form of the RUP. One of the key differences between the two
is that the RUP emphasizes building object-oriented models using modeling notations
defined in UML, while XP emphasizes producing executable code. However, building
object-oriented model using UML is often done in XP as welJ. Several commonly
used notations of UML will be discussed in Chapter 2. Unit testing and continued
integration will be discus ed in Chapter 6. Refactoring will be one of the main topics
of Chapter 7.

CHAPTER SUMMARY

• Software development is difficult, time-consuming, and costly. The main causes

of problems in software development include the complexity, longevity, evolu-
tion, and high u er expectations of software systems.
 Further Readings • 17

• The weU-known waterfall model of software development consists of the fol-

lowing phases: requirements analysis, design, implementation and unit testing,
integration and system testing, and maintenance.
• Software development lacks some key characteristics of welJ-established engi-
neering disciplines, including analysis of designs, nonrecurrence of failures, and
codification of knowledge. Software development is an immature field of engi-
neering.
■ The desirable qualities of software systems include usefulness, timeliness, re-
IiabiHty, maintainability, reusability, user friendliness, and efficiency. Of these
qualities, maintainability is the most crucial and deserves the most attention
during development. Factors contributing to maintainability include flexibility,
simplicity, and readability. The object-oriented development approach focuses
primarily on improving the maintainability and reusability of oftware systems.
■ An iterative object-oriented development process consists of a number of suc-
cessive iterations. Each iteration deals with a relatively small increment of the
system being developed. The system is developed incrementally. The iterative
process continues until the entire system is complete. Two of the common itera-
tive development processes are the RUP and XP.
■ The common activities in object-oriented development proce e include con-
ceptualization, object-oriented analysis and modeling, object-oriented design,
implementation, and maintenance.

FURTHER READ I NGS

Beck, K. (2000). Extreme Programming £rp/ained. Addi on-W ley.

Brooks, F. P. (1975). The Mythical Man Mo11th-Essays on Sofnl'are Engineering.

Addison-Wesley.

Brook , F. P. (1987). "No Silver BuUet- E ence and Accident of Software Engi-
neering," IEEE Software 20(4).

Jacob on. I., G. Booch, and J. Rumbaugh ( 1999). The Unified Sofnvare Development
Process. Addi on-Wesle .
Kruchten, P. (2000). The Rational U11ified Proass. A11 Imrodu tio11, 2nd ed. Addison-
We ley.

Pre man, R. . (1997). Software Engineering: A Practitioner's Approach. McGraw-

Hill.
ommer ille, I. (_QO l ). ofMare Engi11eeri11g, 6th ed. AddL on-Wesley.
18 • Object-Oriented Software Development

EXERCISES

1.1 Search the Web or librarie to find out detail of 1.3 Search the Web or libraries to find out whether
some of the catastrophic failure of computer it is permissible to use software engineer as a
systems who e cause ha,·e be-en attributed to professional title without ce1tification in your
software failures. including the one mentioned country or state, and what the rationale is.
in this chapter.
1.2 Search the Web or librarie to find out details
of some failed oftware development projects
and the cause .
 Object-Oriented Modeling
Using UML

CHAPTER OVERVIEW
In this chapter, we discuss the basic principles, concepts, and techniques of object-
oriented modeling. We introduce a number of commonly used notations in the Unified
Modeling Language (UML), including class diagrams, object diagrams, sequence dia-
grams, and use case diagrams. We conclude the chapter with a case study of object-
oriented analysis and modeling.

PRINCIPLES AND CONCEPTS

In thi ection, we di u, the ba i con ept and the prin iple , of object-oriented
development. \Ve also introduce some ~ imp le graphi al notations in the Unified
Modeling language (U IL) (Booch et al .. 1999] 1 for des ·ribing obje t-orientcd
models. We u e a sub ·et of U IL notations with minor adJptati ns in synt, x for the
ake of con, isten , ith Ja a.

l. Ul\ IL is a stand:.ml for objc~t-orienteJ moJ ling no1~11i 1ns cnJol'\ed by the Object I\ 1:magcmcnt Group
(0 •IG), nn indu ·trial ron ·t,rtium on obj~ct tc~hnologics.

19
-
20 ■ Object-Oriented Modeling Using UML

2.1.1 Objects and Classes

Terms and Concepts

Objects and classes are two of the fundamental concep~s in object-orie~ted _develo~-
th obiect and clas es can be viewed from two different perspecuve~. (1) their
ment· Bo J • • • the real
representation in the object-oriented models, and (2) ~e1_r 111te1p~etatw,~ m
world. The repre entation of objects and classes_ dealt w1~ m the obJ~ct-onen~ed mod-
el (including programs) is only an approximauon of the mte~retallon of obJects and
classe in the real world. We can define objects and classes m tenns of ~ow th~y are
interpreted in the real world, as well as how they are represented in the obJect-onented
model.

Interpretation in the Real World Representation in the Model

Object An object repre ents anything in An object has an identity, a state,

the real world that can be distinctly and a behavior.
identified.
Gass A class represents a set of objects A class characterizes the structure
with similar characteristics and of states and behaviors that are
beha\'ior. These objects are called shared by all its instances.
the instances of the class.

Each object has a unique identity. The identity of an object distinguishes the
object from all other objects. The state of an object is composed of a set of fields, or
arrribules. Each field bas a name, a type, and a value. The behavior of an object
is defined by a set of methods that may operate on the object. In other words, a
method may access or manipulate the state of the object. Methods are sometimes
called operations, and we consider these two tenns to be synonymous. Each method
al.so bas a name, a type, and a value. The type of a method consists of the return type
and the list of parameter types of the method. The return type can be void if the
method does not return a value. The value of a method is the implementation of the
method often expressed as a sequence of statements, in languages like Java or C++.
The features of an object refer to the combination of the state and the behavior of the
objecL
Two objects are equal if their states are equal, that is, if the values of the
corre ponding fields of the two objects are equal. Two objects are identical if they are
the ame object, that is, if they have the same identity.
The value of the field of an object are mutable. Those methods of an object
chat do not modify the slate of the object are called accessors, and those methods
of an object char could modify the state of the object are called mutators. A mutable
object is an object whose state may be modified by some of its methods. A mutable
object may have different states at different times. An immutable object is an object
 2.1 Principles and Concepts • 21

whose state may never be modified by any of its methods, that is, an object that has
no mutators. The tate of an immutable object remains constant. Objects are usually
mutable. However, immutable objects are quite useful too.
A class defines a template for creating or instantiating its instances, that is,
objects. The terms object and instance are often interchangeable. The class from
which an object is created is referred to a the class of the object, and the object
is referred to as an instance of the clas . In mo t object-oriented languages, including
Java and C++, in tead of defining the feature of individual objects, the features of
objects are defined in the class that instantiate the object . Specifically, a class defines
(1 ) the names and types of all fi eld and (2) the name . type , and implementations of
all methods. The values of the fields are not defined or fixed in the class definition. The
values of the fields are mutable. Each instance of the clas · ha its own state. Different
instances of the class may have different state . The implementation of methods are
defined in the class definition and are therefore fixed for a given object. In other word ,
the values of method of an object are immutable.
Let's look at a simple cla Point that repre ent points in a two-dimensional
space. The Java code defining the class is shown on the right-hand ide.

Class name Point class Point {

Fields x, y int x, y;
Method move public void move(int dx, int dy) {
// implementation
}
}

The Point class defines two field : x and y, and one method: move O. The type
of both fields is i nt . The return type of move () i void and the Ii t of the p:irarneter
types of move() i (int, i nt ), since it take two parameter both of type int.

UML Notation for Classes

The UML notation for cla se a rectangular box \ ith as man a three compart-
ments.

Class Name The top compartment . hows the cla s name.

field1
The middle omparunent contains the decl:irations of the fields of
...
fieldn the clas .

method,
The bon m comparunent contains the declaration. of the methods
... of the cla :
methodm

If, in ome context, the detail of the field - and method of the la s i. not important,
one may omit both the middle and the b tt m l'0mpa.rtments.
22 • Object-Oriented Modeling Using UML

The name of the field is required in a field declaration. Optionally, a field

declaration may also include the visibility, the type, and/or the initial values of the
2
field. In thi book, the Java yntax is used for field declarations:
[\lisibiliry] [7)p e] Name [ [ M11/t1jJ/icity ] ] [• InitialVa/11e]
Alternatively, field declarations can also be in the following standard UML
yntax:
[Visibility] Name [ [ M11ltiplicity ] ] [: 1)'pe] [• /11itia/Val11e]

Toe name of the method is required in a method declaration. Optionally, a method

declaration may also include the visibility, the return type, and/or the list of parameters
of the method. In this book, the Java syntax is used for method declarations:
[Visibility] [T)pe] Name ([Parameter , ... ] )

Alternatively, method declarations can be also be in the following standard UML

syntax:
[Visibility] Name ( [Parameter, . . . ] ) [:Type]

The visibility, or accessibility, of fields and methods defines the scope in which
features of classe are accessible. Visibility can be one of the following:

Public The feature is accessible to any class.

Protected The feature is accessible to the class itself, all the classes in the same
package,3 and all its subclasses.
Package The feature is accessible to the class itself and all classes in the same
package.
Private The feature is only accessible within the class itself.

The acces ibility of features will be discussed in more detail in Section 4.4.1. T he
Java and UML syntaxes for visibility are as follows:

Visibility Java Syntax UMLSyntax

public public +
protected protected #
package
private private

2. In 1his book. we use the following convention to defi ne syntax: the notation Foo (e g •n , 1 ) d t
. I bI . I bol h . f .., •1/ e eno es a
nonlcnmna ~ym o ; 1em11na sym s ~re~ own 111 bold ace Courier font (e.g., •). The entities between
square brackets ! J (e.g., (T)peJ) arc opllonal.
J. Packages arc discussed laler in this section fp. 25] and in Section 4.5 Ip. 134].

• I•
 2.1 Principles and Concepts • 23

The multiplicity specification of a field specifies whether an object may have mul-
tiple occurrences of the field. The multiplicity specification is defined in Section 2.2.2
[p. 33].
Each parameter of a method can be specified using the Java syntax as follows:

Type Name

Alternatively, a parameter can be specified using the UML syntax as follows:

Name: Type

The following are some examples of field and method declarations:

Field declarations
Date birthday (Java syntax)
birthday : Date (UML syntax)

public int duration= 100 (Java ynta.'<.)

+duration : int = 100 (UML yntax)

private Student students [0 . . MAX_SIZE] (Java yntax)

-students[0 .. MAX_SIZE] :Student (UML yntax)

Method declarations
void move ( int dx, i nt dy) (Java yntax)
-move (dx: i nt, dy : int) (UML ynta"<.)

public int get Size ( ) (Java ynta"<.)

+get Size ( ) : int (UML yntax)

The Point cla s shown earlier can be repre ented in UML as follm • at different
levels of detail.

Full details in Java syntax:

Point
private int x
private int y
public void move(int dx, int dy)
 -
24 ■ Object-Oriented Modeling Using UML

Full details in UML syntax:

Point
-x:int
-y:int
+move(dx:int, dy:int)

Abbreviated fonns:

Point
X
y
move()

UML Notation for Objects

The UML notation for objects is a rectangular box with one or two compartments.

The top compartment shows the name of the

objectName : ClassName object and its class. The object and class names
are underlined to distinguish the object notation
from the class notation.

fieldn = valuen The bottom compartment contains a list of the

fields and their values.

There are a number of variations for the contents of the top compartment:

• objectName
Omission of the colon and the class name denotes an object named obj e ctN ame
whose class is of no interest.
• : ClassName
Omission of the object name denotes an anonymous object of class ClassName,
which can be identified only through its relationship with other objects.

The fields and their values in the bottom compartment are described with the
foUowing syntax:

Field• Value

The bottom compartment may be omitted altogether if the attributes and values of an
object are of no interest
 2.1 Principles and Concepts • 25

For example, instances of the Point class, with the states (0, 0) and (24, 40),
can be represented graphically as follows:

Point pl= new Point();

p1:Point p2:Point pl.x = O;
pl.y = O;
X=O X=24 Point p2 = new Point();
y=O Y=40 p2 .x = 24;
p2 .y = 40;

The Java code segment, on the right, shows the creation of the instances and the
assignment of the states.

Message Passing Objects communicate with one another by means of message

passing. A message represents a command sent to an object-known as the recipient
(also known as the receiving object or the receiver) of the message-to perform a
certain action by invoking one of the methods of the recipient. A message consists
of the receiving object, the method to be invoked, and (optionally) the arguments to
the method. Message passing is also known as method invocation. The following is
a message to instruct the recipient, point p1, to move IO units and 20 units in the x
and y directions, respectively, by invoking the method move() .

Recipient pl
p1.move(10, 20) Method move()
Arguments (10, 20)

Packages

Style Convention Package Names

Package names are all in lowercase letters, uch as j ava. awt. event.
Packages intended to be widely available should use the re erse of the Internet
domain as the prefix of the package name so that it will be unique globally- for
example, edu. depaul. cs.

Classes are often grouped into a package. Package. an be organized into a hierarchy.
In other words, a package may contain cla e and -ubpackage . It i important
to point out that all clas e in the ame package mu t be clo ely related, since all
feature of a cla , except tho e that are private. are ac e ible to all cla e in the
ame pa kage. Detail. for u ing pa .kag ' in Java, ill be di cus ed in Section 4.5. l .
 -
26 ■ Object-Oriented Modeling Using UML

Agure 2.1 java.awt

[Java.lang
UML notation of
packages. (b)
Point

(a)

UMl Notation of Packages

The UML notation of packages is shown in Figure 2.1. A package is represented by a
rectangular container wilh a tab at lhe upper left corner. The classes and subpackages
that belong to a package are sometimes depicted within the rectangular container. In
that case, the package name is placed in lhe tab, as in Figure 2. 1(a). When the package
contents are not included, as in Figure 2.l(b), the package name can be placed inside
the rectangular container.

2.1.2 Principles

In this section, we discuss a number of important principles in the object-oriented

development approach.

Modularity
One of the fundamental principles of the object-oriented approach is the principle of
modularity. It is intended to control the complexity of large-scale systems through the
use of the divide-and-conquer technique.

Pri~ Modularity
A complex software system should be decomposed into a set of highly cohesive but
loo ely coupled modules.

Decomposition of complex software systems into modules is one of the most

intriguing tasks in oftware development and is more an art than a science. The reason
i !.hat most of the entities in a software system are intricately interconnected like a
web and mu t be un1.angled. The basic cri teri a for decomposition are two of the best
known and mo t elu ive concepts in software development-cohesion and coupling.
• Cohesion refers to the functional relatedness of the entities within a module.
• Coupling refer to the interdependency among different module .
 2.1 Principles and Concepts • 27

A system may be extremely complex in its totality, but a modular decomposition

of the system aims to break it down into modules o that

■ each module is relatively small and simple (that is, hjghly cohesive); and
■ the interactions among modules are relatively simple (that is, loosely coupled),
ensuring that- by examining the module within, not without-each module will
be well-behaved and that, if all the modules are well-behaved, the entire system
also wiU be well-behaved.

Typically, modular decompositions are hierarchical (that i • a module may contain

other modules).
The concepts of modules, cohesion, and coupling all predate the object-oriented
approach. The forms of modules have evolved over time. In the tructured develop-
ment approach, the modules take the form of routine and function . In the object-
oriented approach, modules take the form of clas es and package .

Abstraction
In its purest sense, abstraction means separating the e ential from the none ential
characteristics of an entity. The result is a simpler but sufficiently accurate approx-
imation of the original entity, obtained by removing or ignoring the none enrial
characteristics. The abstraction principle in software development can be described
as follows:

Principle Abstraction
The behaviors, or functionalities, of a module bouJd be cbara terized in a uccinct
and precise description known as the co11tractual interface of the module. In other
words, the contractual interface capture the e en e of the behavior of the module.
The contractual interface is an ab traction of the module.

We can view a module a a senice provider and other module that u e the
services provided by the module as cliems of the module. \: e an view the contractual
interface as the service contract bet\ een the ervice pro idcr and it. clients.
service contract need only de cribe what e.rvi es ·ru1 be pro ided, not how the
service are to be provided. Therefore, de pite the fact that the rvice to be pro ided
are very complex, the , ervice ontract may be very imp le. ith a imple ervice
contract and an as uran .e by the . ervice provider of h noring the ontracl. the client
need only undectand the · imple contra t in order to u ·e the comp le , service .. The
contractual interfa e alto, s the client to u, e the . ervice , and not be oncemed with
the complexity of the er ice ·. In other , ord~. the comple. it of the module i hidden
within it.
Let us onsider the exrunpk of th telephone . The mechani m for providing
telephone . er ice i , a rather comp le. one. lt in olws routing and connecting calls,
28 • Object-Oriented Modeling Using UML

convening voice to electronic signals and back to voice, transmitting the signals. in
analog or digital mode, and possibly encrypting and decrypting the signals f~r secunt;
reason . However, telephone users (that is, the clients of a telephone service) don t
need to understand the mechanics of a phone system. All the users need to understand
i the manual that comes with the telephone set, which includes instructions on dialing,
speaking. and hanging up. The user's manual in this case is the contractual interface
of the telephone service, and it serves as an abstraction of the telephone service from
the user's perspective.

Encapsulation
A closely related and complementary principle is encapsulation, which stipulates that
the clients need know nothing more than the service contract while using the service.

Principle Encapsulation
The implementation of a module should be separated from its contractual interface
and hidden from the clients of the module.

Hence this principle is also known as information hiding. Encapsulation is in-

tended to reduce coupling among modules. The less the clients know about the im-
plementation of the module, the looser the coupling between the module and its clients
can be. An important benefit of encapsulation is that, if the clients know nothing be-
yond the contractual interface, implementation can be modified without affecting the
clients, so long as the contractual interface remains the same.
Telephone service is a good example of an app}jcation in which the contractual
interface and implementation are separated. In the past, signals were transmitted in
analog mode. Over time, telephone service bas been upgraded until, nowadays, the
signals can be transmiued in digital mode with encryption. Although the implementa-
tion of telephone service bas changed, the contractual interface remains the same. The
only effects on telephone users are that they enjoy better sound quality and greater
security.
If a contractual interface is completely separated from implementation, the con-
tractual interface can exist on its own. A contractual interface without any implemen-
tation associated with it is known as an interface in Java terminology. A module can
be represented by two separate entities: an inte,face that <;Jescribes the contractual
interface of the module and a class that implements the contractual interface.

Polymorphism
Several different service providers can honor the same contractual interface. More-
over, these service providers can be interchanged without affecting the clients. The
 2.2 Modeling Relationships and Structures • 29

ability to interchange modules dynamically without affecting the clients is known as

polymorphism.4
Let us take the telephone service example one step further and consider cellular
telephone service. Digital cellular service uses more advanced technologies but has
smaller service regions than does the more e tablished analog cellular service. An
analog/digital dual-mode cellular phone is an example of polymorphism. It provides a
single contractual interface for using the phone bat employs two different technologies
to provide the service. Users need not be concerned with-and certainly are not
affected by- which technology is u ed to provide the service at any given moment.
The dual-mode cellular phone dynamically switches (a soft switch) between the digital
and analog modes as the user crosse the boundary of the digitaVanalog service
regions. We discuss polymorphism in more detail in Section 5.2.2 [p. 165].

2.2 MODELING RELATIONSHIPS AND STRUCTURES

In this section, we introduce the UML class diagram for modeling the tatic tructures
of object-oriented software systems and various types of relation among the cJas es.
Class diagrams are the most common diagrams used in object-oriented modeling. A
class diagram consists of
■ a set of nodes that represent classes and interface ; and
■ a set of links that represent relationship among clas es.

The following relationships among clas es can be modeled in clas diagram :

■ Inheritance, including exten ion and implementation

■ A sociation, including aggregation and compo ition
■ Dependency
The graphical notation for clas e i di cu ed in Section 2.1.1. Tbe graphical nota-
tion for variou relationship are di cu ed in the next four ub ection .

2.2.1 Inheritance

Inheritance i one of the mo t important relationship in object-oriented modeling.

Inheritance define a relation hip among cl es and interface . More pecifically.
there are evenu form of inheritan e relation:
■ The t.tte11sio11 relation between two classes. Whenclas C2 extend cla Cl, class
C2 i known as a subclass of la Cl. and la Cl i knm n a a superclass of
cla s C2.

4. The word poly111orphis111 ml!un · an i:nLity , ilh multiple~ m1 ·. In lhis particular context, it refer to a
conlructual inlcrfm:i: , ilh multiple interchangeable impkmcntntions.
 --

30 • Object-Oriented Mod~ling Using UML

■ The txtension relation between two interfaces. When interface 12 extends inter-
face l 1, interface 12 is known as a subinterface of interface l 1, and interface l 1
is known as a superinterface of interface 12.
■ The implementation relation between a class and an interfacq. When class C2
implements interface 11, class C2 is known as an implementation of interface
11, and interface 11 is known as an inte1face of class C2.

UML uses a different terminology for inheritance relationships. The extension relation
is also known as specialization, and the inverse relation is known as generalization
in UML. The implementation relation is also know as realization in UML.
Graphically, the inheritance relation is represented by a link from the subclass/
subinterface to the superclass/superinterface with a hollow triangle pointing toward
the superclass. The extension relation is represented by a solid link, and the imple-
mentation relation is represented by a dashed link, as shown in Figure 2.2. In class
diagrams, the regular class, field, and method names are shown in upright roman fonts,
as in MyClass. The names of interfaces and its methods are shown in italic fonts, as
in Mylnterface.
Conceptually, inheritance models the is-a(n) relationship in the real world; that is,
if C2 is a subclass/subinterface/implementation of Cl, then every instance of C2 is an
instance of Cl, and everything that applies to instances of Cl also applies to instances
of C2. The ex.tension relation between two classes is commonly associated with the
notion of reusing or sharing the implementation (that is, the fields and methods) of a
superclass by its subclasses. The extension relation between two interfaces represents
the expansion of the service contract. The implementation relation does not connote
reuse of implementations, but rather the implementation of a contractual interface by
a class.
As an example, let us consider the following set of classes that represent different
groups of srudents in a university. The class diagram is shown in Figure 2.3.

F"tgure 2.2
Superclass Superinterface Interface
6.
UML notation fOf'
lnhattana r~la-
tionships.
Subclass Subinterface Implementation

extension extension implementation

of classes of interfaces of interfaces
 2.2 Moddlng Relationships and Structures • 31

Figure 2.3
Student
Class diagram: in-
heritance relation
among classes rep- Nondegree Undergraduate Graduate
resenting student
groups.

Master PhD

Class Description

Student Students in general

Graduate Graduate students
Mast er Graduate students pursuing a master's degree
PhD Graduate students pursuing a PhD degree
Undergraduate Undergraduate students
Nondegree Nondegree students

It is easy to see in this example that inheritance can be interpreted ru an is-a

relation. For example, the Graduate class i a subclass of Student, a e ery graduate
student is a student, and everything that applie to a student al o applie to a graduate
student. The set of students, that is. the et of the in tance of the Student class,
is a superset of the set of graduate rudents, that i . the et of the instance of the
Graduate class.
A class may inherit from multiple uperclasse . Thi capability i often referred
to as multiple inheritance. However, many object-oriented programming languages.
including Java, support only a re tricted form of inheritance known a single inher-
itance, in which each clas may inherit from only one uperclas . Java supports a
limited fonn of multiple inheritance by allowing cla_ e to implement multiple in-
terface . We di cu i sue~ related to ingle and multiple inheritance in Section 5.3.2
[p. 179].

Levels of Abstraction
Cla. se and interface repre ent ab traction , and the inheritance relation hip orga-
nizes the cla ses and interfa e into different level of ab traction.
32 ■ Object-Oriented Modeling Using UML

Principle Lerels of Abstraction

Ab traction can be ordered into different levels. The higher the level, the more
oeneral the ab traction i . The lower the level, the more specialized the abstraction is.
0

1n other words, the superclasses represent more general abstractions and the
subclasses repre ent more specialized abstractions. Consider again the example of
tudents hown in Figure 2.3. The inheritance hierarchy shows different levels of ab-
straction of students in a university. The Student class represents the most general
ab traction of tudents, whereas its subclasses represent various specialized abstrac-
tions of tudents. The leaf classes (that is, classes with no subclasses) represent the
most pecialized ab tractions of students.

2. 2-2 Association

Associations represent general binary relationships between classes. The association

can be used to model a \ ariety of relationships between classes, and the association
relationship can also be implemented in a variety of different ways. It is common that
eitherone or both classes in an association relation contain direct or indirect references
Lo the other class. The graphical notation for association is a solid line between the
two classe involved in the association with an optional label and optional adornments
anached to either end, as shown in Figure 2.4. Figure 2.5 shows several associations
among the Student, Faculty, and Course classes.
The graphical notation of an association may have an optional label that consists
of a name and a direction drawn as a solid arrowhead with no tail. In Figure 2.5,
reach and enroll are the names of the association between Faculty and Course, and
between Student and Course, respectively. The direction arrows next to the names
indicate the direction of association with respect to the name. For example, the arrow
next o the enroll association means that "a student enrolls in a course," not that "a
course enrolls in a tudent." By default, it is assumed that the direction of associations
is from left to right and from top to bottom.
The graphical notation of an association also allows an optional role name and
an optional mulripliciry specification to be attached to either of the classes involved
in the as ociation. In Figure 2.5, adviser and advisee are the role names associated

Figure 2.4
Class1I
- - - - ~ role
name
I Class2
role ~-----'
UML notation for
association rda-
tionship.
 2.2 Mod~ing Relationships and Structures • 33

Figure 2.5
Student 1-•-_ _e_n_ro __
_ll_► -1
Course
Class diagram: as- advisee •
sociation relation-
ships.
• teach

1
1
Faculty
adviser

with Facult y and Student, respectively, in the association between Faculty and
Student . The role name may also have an optional vi ibility designator, that is +,
#, - ,or-.
The multiplicity specification is a comma-separated sequence of integer intervals.
An integer interval can be one of the following:

l . .u specifies a closed, that is, inclusive, range of integers from the lower bound
I to the upper bound u. Both the lower and upper bound are integer literals.
The upper bound may also be the asterisk character ( ), which indicates an
unlimited upper bound.
i specifies a singleton range that contains integer i, which is an integer literal.
* specifies the entire nonnegative integer range: 0. 1. 2. 3.. ..

Here are some examples of multiplicity spedfication :

0 . ·* 0 or more
1. · * 1 or more
2 .. 5 2 to 5
2, 5, 7 2, 5, and 7
1, 3, 5. ·* I, 3, and 5 or more

In Figure 2.5, the enroll a ociation i man -to-man ; that i a tudent may enroll
in any number of course . and a ourse ma have any number of tudent · enrolled
in it. The reach association i one-to-man ; that i ·. ea h ourse has onl one faculty
member to teach it, but a fa ult member ma tench an number of course . The
adviser-advisee a ·ociation L al o one--to-man ; that i , ea b . tudenl ha. one advi er,
but an advi er may ha e any number of ad i ee ·.
The graphical notation of an a iation ma al o indi ate the navigation of
the a o iation. If there i, a dire t or indirect refere nee from cl Cl to clas C2,
then it is navigabl from Cl to C2. n as , iation ma b nn igable in one or both
dire tions. By default, an a. s iation is a · ·urned to be navigable in both direction .
If nn a o iation is only navigable in one dire tion, it mu t be explicitly hown with
Discovering Diverse Content Through
Random Scribd Documents
smile, made as if to rise, leaning forward with quick attention. Then
my father shook Jason till he reeled and clutched at him.
“Have a mind what you say, you mad cur!” he cried in a terrible
voice.
“It’s true! Let me go! He confessed it all to me—to me, I say!”
I stood up among them alone, stricken, and I was not afraid. I was
a better man than my accuser; a better brother, despite my sin. And
his dagger, plunged in to destroy, had only released the long-
accumulating agony of my poor inflamed and swollen heart.
“Father,” I said, “let him alone. It is true, what he says.”
He flung Jason from him with violence.
“Move a step,” he thundered, daring him, “and I’ll send you after
Modred!”
He came to me and took me gently by the shoulder.
“Renalt, my lad,” he said, “I am waiting to hear.”
I did not falter, or condone my offense, or make any appeal to
them whatsoever. The kind touch on my arm moved me so that I
could have broken into tears. But my task was before me and I could
afford no atom of self-indulgence, did I wish to get through it bravely.
As I had told my story to Jason, I told it now; and when I had
finished I waited, in a dead silence, the verdict. I could hear my
brother breathing thickly—expectantly. His fury had passed in the
triumph of his own abasement.
Suddenly my father put the hand he had held on my shoulder
before his face and a great sob coming from him broke down the
stone walls of my pride.
“Dad—dad!” I cried in agony.
He recovered himself in a moment and moved away; then faced
round and addressed me, but his eyes looked down and would not
meet mine.
“Before God,” he said, “I think you are forgiven for a single impulse
we all might suffer and not all of us recoil from the instant after, but I
think that this can be no place for you any longer.”
Then he turned upon Dr. Crackenthorpe.
“You!” he cried; “you, man, who have heard it all, thanks to that
dirty reptile yonder! Do you intend to peach?”
 The doctor pinched his wiry chin between finger and thumb, with
his cheeks lifted in a contemplative fashion.
“The boy,” he said, “is safe from any one’s malice. No jury would
convict on such evidence. Still, I agree with you, it’s best for him to
go.”
“You hear, Renalt?” said my father. “I’ll not drive you in any way, or
deny you harbor here if you think you can face it out. You shall judge
for yourself.”
“I have judged,” I answered; “I will go.”
I walked past them all, with head erect, and up to my room, where
I sat down for a brief space to collect my thoughts and face the
future. Hardly had I got hold of the first end of the tangle when there
came a knock at the door. I opened it and Zyp was outside.
“You fool!” she whispered; “you should have done as I told you. It’s
too late now. Here, take this. Dad told me to give it you”—and she
thrust a canvas bag of money into my hand, looking up at me with
her unfathomable eyes.
As I took it, suddenly she flung her arms about my neck and
kissed me passionately, once, twice, thrice, on the lips, and so
pushed me from her and was gone. And as I stood there came to my
ears a faint wail from above, and I said to myself doggedly: “It is a
gull flying over the house.”
Taking nothing with me but cap, stick and the simple suit of clothes
I had on, I descended the stairs with a firm tread and passed the
open door of the sitting-room. There was silence there, and in
silence I walked by it without a glance in its direction. It held but bitter
memories for me now and was scarce less haunted in its way than
the other. And so to me would it always be—haunted by the beautiful
wild memory of a changeling, whose coming had wrought the great
evil of my life, to whom I, going, attributed no blame, but loved her
then as I had loved her from the first.
The booming of the wheel shook, like a voice of mockery, at me as
I passed the room of silence. Its paddles, I thought, seemed reeling
with wicked merriment, and its creaking thunder to spin
monotonously the burden of one chant.
“I let you go, but not to escape—I let you go, but not to escape.”
The fancy haunted my mind for weeks to come.
 In the darkness of the passage a hand seized mine and wrung it
fiercely.
“You don’t mean to let the grass grow on your resolve, then,
Renalt?” said my father’s voice, rough and subdued.
“No, dad; I can do no good by delaying.”
“I’m sore to let you go, my boy. But it’s for the best—it’s for the
best. Don’t think hardly of me; and be a fine lad and strike out a path
for yourself.”
“God bless you, dad,” I said, and so left him.
As I stepped into the frosty air the cathedral bells rung out like iron
on an anvil. The city roofs and towers sparkled with white; the sun
looked through a shining mist, giving earnest of gracious hours to
come.
It was a happy omen.
I turned my back on the old decaying past and set my face toward
London.
 CHAPTER XIII.
MY FRIEND THE CRIPPLE.

In the year 1860, of which I now write, so much of prejudice

against railways still existed among many people of a pious or
superstitious turn of mind, that I can quote much immediate
precedent in support of my resolve to walk to London rather than
further tempt a Providence I had already put to so severe a strain. It
must be borne in mind of course that we Trenders were little more
than barbarians of an unusual order, who had been nourished on a
scorn of progress and redeemed only by a natural leaning toward
picturesqueness of a pagan kind. Moreover, the sense of mystery,
which was an integral part of our daily experience, had ingrained in
us all a general antagonism toward unconstructed agencies. Lastly,
not one of us had ever as yet been in a train.
Still, it was with no feeling of inability to carve a road for myself
through the barriers to existence that I drew, on the evening of my
third day’s tramp, toward the overlapping pall that was the roof of the
“City of Dreadful Night.”
I had slept, on my road, respectively at Farnham and Guildford,
where, in either case, cheap accommodation was easily procurable,
and foresaw a difficulty, only greater in proportion, in finding
reasonable lodging in London during the time I was seeking work.
Indifferently I pictured this city to myself as only an elongated High
street, with ramifications more numerous and extended than those of
the old burgh that was my native town. I was startled, overwhelmed,
dazed with the black, aimless scurrying of those interwoven strings
of human ants, that ran by their thronging brick heaps, eager in
search for what they never seemed to find, or shot and vanished into
tunnels and alleys of darkness, or were attracted to and scorched up
by, apparently, the broad sheets of flame that were the shop
windows of their Vanity Fair. Moving amid the swarm from vision to
vision—always an inconsiderable atom there without meaning or
individuality—always stunned and stupefied by the threatening
masses of masonry that hemmed me in, and accompanied me, and
broke upon me in new dark forms through every vista and gap that
the rank growth of ages had failed to block—the inevitable sense
grew upon me, as it grows upon all who pace its interminable streets
friendless, of walking in a world to which I was by heavenly birthright
an alien.
Near midnight, I turned into a gaunt and lonely square, where
comparative quiet reigned.
I had entered London by way of Waterloo bridge, as the wintry
dusk was falling over house and river, and all these hours since had I
been pacing its crashing thoroughfares, alive only to wonder and the
cruel sense of personal insignificance. As to a lodging and bed for
my weary limbs—sooner had Childe Roland dared the dark tower
than I the burrows, that night, of the unknown pandemonium around
me. I had slept in the open of the fields before now. Here, though
winter, it hardly seemed that there was an out-of-doors, but that the
buildings were only so many sleeping closets in a dark hall.
All round the square inside was a great inclosure encompassed by
a frouzy hoarding of wood, and set in the middle of the inclosure was
some dim object that looked like a ruined statue. Such by day,
indeed, I found it to be, and of no less a person than his late majesty,
King George the First. When my waking eyes first lighted on him, I
saw him to be half-sunk into his horse, as if seeking to shield himself
therein from the shafts of his persecutors, who, nothing
discomposed, had daubed what remained of the crippled charger
himself with blotches of red and white paint.
I walked once or twice round the square, seeking vainly, at first, to
still the tumult of my brain. The oppressive night of locked-up
London, laden like a thunder cloud with store of slumbering
passions, was lowering now and settling down like a fog. The
theaters were closed; the streets echoing to the last foot-falls.
Seeing a hole in the hoarding, I squeezed through it and withdrew
into the rank grass and weeds that choked the interior of the
inclosure. I had bought and brought some food with me, and this I
fell to munching as I sat on a hummock of rubbish, and was
presently much comforted thereby, so that nothing but sleep seemed
desirable to me in all the world. Therefore I lay down where I was
and buttoning my coat about me, was, despite the frosty air, soon
lost in delicious forgetfulness. At first my slumber was broken by
reason of the fitful rumble of wheels, or pierced by voices and dim
cries that yet resounded phantomly here and there, as if I lay in
some stricken city, where only the dying yet lived and wailed, but
gradually these all passed from me.
I awoke with the gray of dawn on my face and sat up. My limbs
were cramped and stiff with the cold, and a light rime lay upon my
clothes. Otherwise no bitterer result had followed my rather untoward
experiment.
Then I looked about me and saw for the first time that I was not
alone. Certain haggard and unclean creatures were my bed-fellows
in that desolate oasis. They lay huddled here and there, like mere
scarecrows blown over by the wind and lying where they fell. There
were women among them, and more than one pinched and tattered
urchin, with drawn, white face resolved by sleep into nothing but
pathos and starvation.
There they lay at intervals, as if on a battlefield where the crows
had been busy, and each one seemed to lie flattened into the earth
as dead bodies lie.
I could not but be thankful that I had stumbled over no one of them
when I had entered—an accident which would very possibly have
lost me my little store of money, if it had, indeed, led to nothing
worse. As it was, I prepared for a hasty exit, and was about to rise,
when I became conscious that my movements were under
observation by one who lay not twenty feet from me.
He was so hidden by the rank grass that at first I could make out
nothing but a long, large-boned face peering at me above the stems
through eyes as black and glinting as boot buttons. A thatch of dark
hair fell about his ears and forehead, and his eyebrows, also black,
were sleek and pointed like ermine tips.
The face was so full and fine that I was startled when its owner
rose, which he did on the instant, to see that he was a thick-set and
stunted cripple. He shambled toward me with a winning smile on his
lips, and before I could summon resolution to retreat, had come and
sat down beside me.
 “We seem the cocks of this company,” he said, in a deep musical
voice. “Among the blind the one-eyed—eh?”
He was warmly and decently clad, and I could only wonder at his
choice of bedroom. He read me in a look.
“I’ve a craving for experiences,” he said. “These aren’t my usual
quarters.”
“No,” I said; “I suppose not.”
“Nor yours?” he went on, with a keen glance at me.
To give my confidence to a stranger was an unwise proceeding,
but I was guileless as to the craft of great cities, and in this case my
innocence was in a manner my good fortune.
I told him that I was only yesterday from the country, after a three
days’ tramp, and how I was benighted.
“Ah,” he said. “Up after work, I suppose?”
“Yes,” I answered.
“Well,” said he, “let’s understand your capacities. Guess my age
first.”
“Forty,” said I, at a venture, for indeed he might have been that or
anything else.
“I’m 21,” he said. “Don’t I look it? We mature early in London here.
What do you think’s my business?”
“Oh, you’re a gentleman, aren’t you?” I asked, with some stir of
shyness.
“I’m a printer’s hand. That means something very different to you,
don’t it? Maybe you’ll develop in time. Where are you from?”
I told him.
“Ah,” he said. “You’ve a proverb down your way: ‘Manners
makeyth man.’ So they may, as they construe it—a fork for the
fingers and a pretty trick of speech; but it’s the manners of the soul
make the gentleman. Do you believe in after-life?”
“Of course I do. Where do the ghosts come from otherwise?”
He laughed pleasantly, rubbing his chin in a perplexed manner,
and then I noticed that his fingers were stunted like a mechanic’s
and stained with printer’s ink.
“Old Ripley would fancy you,” he said.
“Who’s he?”
 “My governor—printer, binder and pamphleteer, an opponent of all
governments but his own. He’s an anarchist, who’d like to transfer
himself and his personal belongings to some desert satellite, after
laying a train to blow up the earth with nitro-glycerin and then he’d
want to overturn the heavenly system.”
“He doesn’t sound hopeful.”
“No, he isn’t, but he’s fairly original for a fanatic. I wonder if he’d
give you work?”
“Oh, thanks!” I exclaimed.
“Nonsense; you needn’t mind him. He’s only gas. Unmixed with
his native air he wouldn’t be explosive, you know. I can imagine him
a very unprogressive angel. It’s notoriety he wants. Nothing satisfies
his sort in the end like a scaffold outside of Newgate with 40,000
eyes looking on and 12 guineas paid for a window in the ‘Magpie
and Stump.’”
“Are you——” I began, when he took me up with:
“His kind? Not a bit of it. I’m an idealist—a dreamer asking the way
to Utopia. I look about for the finger-posts in places like this. One
must learn and suffer to dream properly.”
“You can do that and yet have ugly enough dreams,” I said, with
subdued emphasis.
“That oughtn’t to be so,” he said, looking curiously at me.
“Nightmare comes from self-indulgence. Cosset your grievances and
they’ll control you. You must be an ascetic in the art of sensation.”
“And starve on a pillar like that old saint Mr. Tennyson wrote of,” I
answered.
“Go and hang yourself,” he cried, pushing at me with a laugh.
“Hullo! Who’s here?”
A couple of the scarecrows, evil-looking men both, had risen, and
stood over us to one side, listening.
“Toff kenners,” I heard one of them mutter, “and good for jink, by
the looks.”
“Tap the cady,” the other murmured, and both creatures shuffled
round to the front of us.
“Good for a midjick, matey?” asked the more ruffianly looking of
the two in a menacing tone.
 I started, bewildered by their jargon. My companion looked up at
them smiling and drumming out a tune on his knee.
“Stow it,” said the smaller man to the other; “I’ve tried the griffin
and it don’t take.” Then he bent his body and whined in a fulsome
voice: “Overtaken with a drop, good gentlemen? And won’t you pay
a trifle for your lodgings, now?”
I was about to rise, but a gesture on the part of both fellows
showed me that they intended to keep us at our disadvantage. A
blowzed and noisome woman was advancing to join the group.
“Be alert,” whispered my companion. “We must get out of this.”
The words were for me, but the men gathered their import and
assumed a threatening manner. No doubt, seeing but a boy and a
cripple, they valued us beneath our muscular worth.
“Come,” said the big man, “we don’t stand on ceremony; we want
the price of a drink.”
He advanced upon us, as he spoke, with an ugly look and in a
moment my companion had seized him by the ankles and whirled
him over against his friend, so that the two crashed down together.
The woman set up a screech, as we jumped to our feet, and we saw
wild heads start up here and there like snakes from the grass. But
before any one could follow us we had gained the rent in the
hoarding and slipped through. Glancing back, after I had made my
exit, I saw one of the men strike the woman full in the face and fell
her to the ground. It was his gentle corrective to her for not having
stopped us, and the sight made my blood so boil that I was on the
point of tearing back, had not my companion seized and fairly carried
me off. As in many cripples, his strength of arm was prodigious.
“Now,” he said, when he had quieted me, “we’ll go home to
breakfast.”
“Where?” said I.
“Home, my friend. Oh, I have one, you know, for all my sleeping
out there. That was a test for experience; my first one of the kind, but
valuable in its way.”
“But——” I began.
“Yes, you will,” he cried. “You’ll be my guest. I’ve taken a bit of a
fancy to you. What’s your name?”
 When I had told him, “Duke Straw’s mine,” he said; “though I’m not
of strawberry-leaf descent. But it’s a good name for a dreamer, isn’t
it? Have you ever read ‘Feathertop,’ by Hawthorne?”
“No,” I said.
“Never mind, then. When you do, you’ll recognize my portrait—a
poor creature of straw that moves by smoke.”
“What smoke?” I asked, bewildered.
“Perhaps you’ll find out some day—if Ripley takes a fancy to you.”
“You don’t want me to go to him?”
“Certainly I do. I’m going to take you with me when I tramp to work
at 9 o’clock.”
He was so cool and masterful that I could only laugh and walk on
with him.
 CHAPTER XIV.
I OBTAIN EMPLOYMENT.

It was broad day when we emerged from the inclosure, and sound
was awakening along the wintry streets. London stood before me
rosy and refreshed, so that she looked no longer formidably
unapproachable as she had in her garb of black and many jewels. I
might have entered her yesterday with the proverbial half-crown, so
easily was my lot to fall in accommodating places.
Duke Straw, whom I was henceforth to call my friend, conducted
me by a township of intricate streets to the shop of a law stationer, in
a petty way of business, which stood close by Clare market and
abutted on Lincoln’s Inn Fields. Here he had a little bedroom,
furnished with a cheap, oil-cooking stove, whereon he heated his
coffee and grilled his bacon.
Simon Cringle, the proprietor of the shop, was taking his shutters
down as we walked up. He was a little, spare man, with a vanity of
insignificance. His iron-gray hair fell in short, well-greased ringlets
and his thin beard in a couple more, that hung loose like dangled
wood shavings; his coiled mustaches reminded one of watch
springs; his very eyebrows, like bees’ legs, were humped in the
middle and twisted up into fine claws at the tips. Duke, in his search
for lodging and experience, had no sooner seen this curiosity than
he closed with him.
He gave my companion a grandiloquent “Good-morning.”
“Up with the lark, Mr. Straw,” said he, “and I hope, sir, with success
in the matter of getting the first worm?” Here he looked hard at me.
“He found me too much of a mouthful,” said I; “so he brought me
home for breakfast.”
Duke laughed.
“Come and be grilled,” said he. “Anyhow they roast malt-worms in
a place spoken of by Falstaff.”
We had a good, merry meal. I should not have thought it possible
my heart could have lightened so. But there was a fascinating
individuality about my companion that, I am afraid, I have but poorly
suggested. He gave me glimmerings of life in a higher plane than
that which had been habitual to me. No doubt his code of morals
was eccentric and here and there faulty. His manner of looking at
things was, however, so healthy, his breezy philosophy so infectious,
that I could not help but catch some of his complaint—which was,
like that of the nightingale, musical.
Perhaps, had I met him by chance six months ago, my
undeveloped soul would have resented his easy familiarity with a
cubbish snarl or two. Now my receptives were awakened; my armor
of self-sufficiency eaten to rags with rust; my heart plaintive for
communion with some larger influence that would recognize and not
abhor.
At 8:45 he haled me off to the office, which stood a brief distance
away, in a thoroughfare called Great Queen street. Here he left me
awhile, bidding me walk up and down and observe life until his chief
should arrive, which he was due to do at the half-hour.
I thought it a dull street after some I had seen, but there were
many old book and curiosity shops in it that aroused my interest.
While I was looking into one of them I heard Duke call.
“Here,” he said, when I reached him; “answer out and I think
Ripley will give you work. I’m rather a favorite with him—that’s the
truth.”
He led me into a low-browed room, with a counter. Great bales of
print and paper went up to the ceiling at the back, and the floor
rumbled with the clank of subterranean machinery. One or two clerks
were about and wedged into a corner of the room was a sort of
glazed and wooden crate of comfortable proportions, which was, in
fact, the chapel of ease of the minister of the place.
Into this den Duke conducted me with ceremony, and, retreating
himself, left me almost tumbling over a bald-headed man, with a
matted black beard, on which a protruding red upper lip lay like a
splash of blood, who sat at a desk writing.
“Shut the door,” he said, without looking up.
“It is shut, sir.”
He trailed a glance at me, as if in scrutiny, but I soon saw he could
only have been balancing some phrase, for he dived again and went
on writing.
Presently he said, very politely, indeed, and still intent on his
paper: “Are you a cadet of the noble family of Kinsale, sir?”
“No, sir,” I answered, in surprise.
“You haven’t the right to remain covered in the presence of the
king?”
“No, sir.”
“Well, I’m king here. What the blazes do you mean by standing in
a private room with your hat on?”
I plucked it off, tingling.
“I’m sorry,” I said. “Mr. Straw brought me in so suddenly, I lost my
head and my cap went with it, I suppose. But I see it’s not the only
thing one may lose here, including tempers!” And with that I turned
on my heel and was about to beat a retreat, fuming.
“Come back!” shouted Mr. Ripley. “If you go now, you go for good!”
I hesitated; the memory of my late comrade restored my
equilibrium.
“I didn’t mean to be rude, sir,” I said. “I shall be grateful to you if
you will give me work.”
He had condescended to turn now, and was looking full at me with
frowning eyes, but with no sign of anger on his face.
“Well, you can speak out,” he said. “How do you come to know
Straw?”
“I met him by chance and we got talking together.”
“How long have you been in London?”
“Since yesterday evening.”
“Why did you leave Winton?”
“To get work.”
“Have you brought a character with you?”
Here was a question to ask a Trender! But I answered, “No, I
never thought of it,” with perfect truth.
“What can you do?”
“Anything I’m told, sir.”
“That’s a compromising statement, my friend. Can you read and
write?”
“Yes, of course.”
“Anything else?”
 “Nothing.”
“Nothing? Don’t you know anything now about the habits of birds
and beasts and fishes?”
“Oh, yes! I could tell you a heap about that.”
“Could you? Very well; I’ll give you a trial. I take you on Straw’s
recommendation. His opinion, I tell you, I value more than a score of
written characters in a case like this. You’ve to make yourself useful
in fifty different ways.”
I assented, with a light heart, and he took me at my word and the
further bargain was completed. My wages were small at first, of
course; but, with what I had in hand, they would keep me going no
doubt till I could prove myself worth more to my employer.
In this manner I became one of Ripley’s hands and later on myself
a pamphleteer in a small way. I wrote to my father that evening and
briefly acquainted him of my good fortune.
For some months my work was of a heterogeneous description.
Ripley was legitimately a job printer, on rather a large scale, and a
bookbinder. To these, however, he added a little venturesomeness in
publishing on his own account, as also a considerable itch for
scribbling. Becoming at a hint a virulent partisan in any extremist
cause whatsoever, it will be no matter for wonder that his private
room was much the resort of levelers, progressives and abolitionists
of every creed and complexion. There furious malcontents against
systems they were the first to profit by met to talk and never to listen.
There fanatical propagandists, eager to fly on the rudimentary wing
stumps of first principles, fluttered into print and came flapping to the
ground at the third line. There, I verily believe, plots were laid that
would presently have leveled powers and potentates to the ground at
a nod, had any of the conspirators ever possessed the patience to sit
on them till hatched. This, however, they never did. All their fiery
periphrastics smoked off into the soot of print and in due course
lumbered the office with piles of unmarketable drivel.
Mr. Ripley had, however, other strings to his bow, or he would not
have prospered. He did a good business in bookselling and was
even now and again successful in the more conventional publishing
line. In this connection I chanced to be of some service to him, to
which circumstance I owed a considerable improvement in my
position after I had been with him getting on a year. He had long
contemplated, and at length begun to work upon, a series of
handbooks on British birds and insects, dealt with county by county.
In the compilation of these much research was necessary, wherein I
proved myself a useful and painstaking coadjutor. In addition,
however, my own knowledge of the subject was fairly extensive as
regarded Hampshire, which county, and especially that part of it
about Winton, is rich in lepidoptera of a rare order. I may say I fairly
earned the praise he bestowed upon me, which was tinged, perhaps,
with a trifle of jealousy on his part, due to the fact that the section I
touched proved to be undoubtedly the most popular of the series, as
judged subsequently by returns.
Not to push on too fast, however, I must hark back to the day of
my engagement, which was marked by my introduction to one who
eventually exercised a considerable influence over my destinies.
During the course of that first morning Mr. Ripley sent me for some
copies of a pamphlet that were in order of sewing down below. By
his direction I descended a spiral staircase of iron and found myself
in the composing-room. At a heavy iron-sheeted table stood my new-
found friend, who was, despite his youth, the valued foreman of this
department. He hailed me with glee and asked: “What success?”
“All right, thanks to you,” I said; “and where may the bookbinding
place be and Dolly Mellison?”
“Oh, you’re for there, are you?” he said, with I thought a rather
curious look at me, and he pointed to a side door.
Passing through this I found myself in a long room, flanked to the
left with many machines and to the right with a row of girls who were
classifying, folding or sewing the sheets of print recent from the
press.
“I’m to ask for Dolly Mellison,” I said, addressing the girl at my end
of the row.
“Well, you won’t have far to go,” she said. “I’m her.”
She was a pretty, slim lily of a thing, lithe and pale, with large gray
eyes and coiled hair like a rope of sun-burned barleystraw, and her
fingers petted her task as if that were so much hat-trimming.
“I’m sent by Mr. Ripley for copies of a pamphlet on ‘The
Supineness of Theologicians,’” I said.
 “I’m at work on it,” she answered. “Wait a bit till I’ve finished the
dozen.”
She glanced at me now and again without pausing in her work.
“You’re from the country, aren’t you?”
“Yes. How do you know?”
“A little bird told me. What gave you those red cheeks?”
“The sight of you,” I said. I was growing up.
“I’m nothing to be ashamed of, am I?” she asked, with a pert
laugh.
“You ought to be of yourself,” I said, “for taking my heart by storm
in that fashion.”
“Go along!” she cried, with a jerk of her elbow. “None of your
gammon! I’m not to be caught by chaff.”
“It wasn’t chaff, Dolly, though I may be a man of straw. Is that what
you meant?”
“You’re pretty free, upon my word. Who told you you might call me
by my name?”
“Why, you wouldn’t have me call you by any one else’s? It’s pretty
enough, even for you.”
“Oh, go away with you!” she cried. “I won’t listen.”
At that moment Duke put his head in at the door.
“The governor’s calling for you,” he said. “Hurry up.”
“Well, they’re ready,” said the girl—“here,” and she thrust the
packet into my hands, with a little blushing half-impudent look at me.
I forgot all about her in a few minutes. My heart was too full of one
only other girlish figure to find room in itself for a rival. What was Zyp
doing now?—the wonderful fairy child, whose phantom presence
haunted all my dreams for good and evil.
As I walked from the office with Duke Straw that afternoon—for, as
it was Saturday, we left early—a silence fell between us till we
neared Cringle’s shop. Then, standing outside, he suddenly stayed
me and looked in my face.
“Shall I hate or love you?” he said, with his mouth set grimly.
He made a gesture toward his deformed lower limbs with his
hands, and shrugged his shoulders.
“No,” he said; “what must be, must. I’ll love you!”
 There was a curious, defiant sadness in his tone, but it was gone
directly. I could only stare at him in wonder.
“You’re to be my house-fellow and chum,” he said. “No, don’t
protest; I’ve settled it. We’ll arrange the rest with Cringle.”
And so I slept in a bed in London for the first time.
But the noise of a water wheel roared in my ears all night.
 CHAPTER XV.
SWEET, POOR DOLLY.

“Trender,” said Duke, unexpectedly after a silence the next

morning, as we loitered over breakfast, “pay attention to one thing. I
don’t ask you for a fragment of your past history and don’t want to
hear anything about it. You’ll say, as yet you haven’t offered me your
confidence, and quite right, too, on the top of our short acquaintance.
But don’t ever offer it to me, you understand? Our friendship starts
from sunrise, morning by morning, and lasts the day. I don’t mean it
shall be the less true for that; I have a theory, that’s all.”
“What is it, Straw?”
“Sufficient for the day, it’s called. Providence has elected to give
us, not one existence, but so many or few, each linked to the next by
an insensibility and intercalated as a whole between appropriate
limits.”
“I don’t quite understand.”
“Wait a bit. Each of these existences has its birth and death, and
should be judged apart from the others; each is pronounced upon in
succession by one’s familiar spirit and its minutes pigeon-holed and
docketed above there. When the chain of evidence, for or against, is
complete, up these links are gathered in a heap and weighed in both
sides of the balance.”
“It sounds more plausible than it is, I think,” said I, with frank
discourtesy. “The acts of one day may influence those of the next—
or interminably.”
“That’s your lookout; but they needn’t necessarily. With each new
birth comes a new capacity for looking at things in their right
proportions.”
“How far do you push your theory?”
“As far as you like. I’d have, all the world over, a daily revival of
systems.”
“Government—law?”
“Certainly. Of everything.”
 “Then justice, injustice, vindictiveness, must all revive, too.”
“No. They’re recalled; they don’t revive.”
“But must a criminal, for instance, be allowed to escape because
they have failed to catch him the day he did the deed?”
“That’s exactly it. It makes no difference. He couldn’t atone here
for an act committed by him during another existence. But that
particular minute goes pretty red into its pigeon-hole, you may be
sure.”
“Oh, it’s wild nonsense,” I laughed. “You can’t possibly be
consistent.”
“Can’t I? Look here, you are my friend yesterday, and to-day, and
always, I hope. I judge you daily on your merits, yet, for all I know,
you may have committed murder in one of your past existences?”
The blood went back upon my heart. Then a great longing awoke
in me to tell all to this self-reliant soul and gain comfort of my sorrow.
But where was the good in the broad face of his theory?
“Well,” I said, with a sigh, “I’ve done things at least I bitterly repent
of.”
“That’s the conventional way of looking at it. Repentance in this
won’t avail a former existence. Past days of mine have had their
troubles, no doubt, but this day I have before me unclouded and to
do what I like with.”
“Well, what shall we do with it?” said I. “I hand it over to you to
make it a happiness for me. I dare say we shall find plenty of
sorrows between sunrise and evening to give it a melancholy
charm.”
“Rubbish!” cried my friend. “Cant, cant, cant, ever to suppose that
sorrow is necessary to happiness! We mortals, I tell you, have an
infinite capacity for delight; given health, spiritual and bodily, we
could dance in the sunbeams for eternity and never reach a surfeit of
pleasure.”
“Duke,” said I—“may I call you Duke?”
“Of course.”
“It puzzles me where you got—I don’t mean offense—only I can’t
help wondering——”
“How I came to have original thoughts and a grammatical manner
of speech? Look here——” he held up his stained fingers—“aren’t
these the hands of a man of letters?”
“And a man of action,” I said, with a laugh. “But——”
“It’s no use, Renny. I can’t look further back than this morning.”
“You can recall, you know. You don’t deny each existence that
capacity?”
“Perhaps I could; but to what advantage? To shovel up a whole
graveyard of sleeping remembrances to find the seed of one dead
nettle that thrusts its head through? No, thank you. Besides, if it
comes to that, I might put the same question to you.”
“Oh, I can easily answer it. I get all my way of speaking from my
father first, and, secondly, because I love books.”
He looked at me oddly.
“You’re a modest chicken,” he said. “But I should like to meet your
father.”
I could not echo his wish.
“Still,” he went on, “I will tell you, there was a little inexperience of
mankind in your wonder. I think—I don’t refer to myself, of course—
that no man in the world is more interesting to talk with than the
skilled mechanic who has an individuality and a power of expressing
it in words. He is necessarily a man of cultivation, and an ‘h’ more or
less in his vocabulary is purely an accident of his surroundings.”
At this moment Mr. Cringle tapped at the door and walked into the
room.
“I hope I see you ro-bust, gentlemen? And how do you like this
village of ours, Mr. Trender?”
“It’s dirty after Winton,” said I.
“Ah,” he said, condescendingly; “the centers of such enormous
forces must naturally rise some dust. It’s a proud thing, sir, to
contribit one’s peck to the total. I feel it in my little corner here.”
“Why,” said I, “you surprise me, Mr. Cringle. I’m only an ignorant
country lad, of course; but it seems to me you are quite a remarkable
figure.”
He gave an extra twist to his mustache and sniggered comfortably.
“Well,” he said, “it is not for me to contradict you—eh, Mr. Straw?”
“Certainly not,” said Duke; “why, you are famous for your deeds.”
“Very good, Mr. Straw, and perhaps, as you kindly mean it in the
double sense. You mightn’t think it, but it wants some knowledge of