Visit https://ebookultra.

com to download the full version and

explore more ebooks

Object oriented software development using Java

principles patterns and frameworks 2nd Edition
Xiaoping Jia.

_____ Click the link below to download _____

https://ebookultra.com/download/object-oriented-
software-development-using-java-principles-patterns-
and-frameworks-2nd-edition-xiaoping-jia/

Explore and download more ebooks at ebookultra.com

Here are some suggested products you might be interested in.
Click the link to download

Object Oriented Software Engineering Using UML Patterns

and Java 2nd Edition Bernd Bruegge

https://ebookultra.com/download/object-oriented-software-engineering-
using-uml-patterns-and-java-2nd-edition-bernd-bruegge/

Component Oriented Development and Assembly Paradigm

Principles and Practice using Java 1st Edition Piram
Manickam
https://ebookultra.com/download/component-oriented-development-and-
assembly-paradigm-principles-and-practice-using-java-1st-edition-
piram-manickam/

Foundations of Object Oriented Programming Using NET 2 0

Patterns 1st Edition Christian Gross (Auth.)

https://ebookultra.com/download/foundations-of-object-oriented-
programming-using-net-2-0-patterns-1st-edition-christian-gross-auth/

Object Oriented Software Engineering 7th Edition Stephen

Schach

https://ebookultra.com/download/object-oriented-software-
engineering-7th-edition-stephen-schach/
Object Oriented Design with UML and Java 1st Edition
Kenneth Barclay

https://ebookultra.com/download/object-oriented-design-with-uml-and-
java-1st-edition-kenneth-barclay/

Java the UML way integrating object oriented design and

programming Else Lervik

https://ebookultra.com/download/java-the-uml-way-integrating-object-
oriented-design-and-programming-else-lervik/

Applying UML and Patterns An Introduction To Object

Oriented Programming 2Ed Edition Larmen

https://ebookultra.com/download/applying-uml-and-patterns-an-
introduction-to-object-oriented-programming-2ed-edition-larmen/

Scientific Software Design The Object Oriented Way 1st

Edition Damian Rouson

https://ebookultra.com/download/scientific-software-design-the-object-
oriented-way-1st-edition-damian-rouson/

Design patterns explained a new perspective on object

oriented design 2. ed Edition Shalloway

https://ebookultra.com/download/design-patterns-explained-a-new-
perspective-on-object-oriented-design-2-ed-edition-shalloway/
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
Another Random Scribd Document
with Unrelated Content
sing pun shen.” The pronunciation of the province of Szechuen is a
little heavier, viz: “Jen dze tsou, sin pen chan.” Now the boys of New
China are concluding that “Man in the beginning was essentially
misinformed!”
That the Chinese can become linguists has seldom been more
uniquely illustrated than in the following experience related by Prince
Henri d’Orleans. He was about to travel through the territories of the
aboriginal Lolo tribes of Yunnan province. The difficulty was to find
an interpreter. The general interpreter who only knew the Mandarin
pronunciation of the north, or the Cantonese pronunciation of the
south, would not do. The prince found at the Mission d’Etrangeres at
Tali, in remote Yunnan, an interpreter who knew the Lolo dialects,
and though he could not converse with the prince in French or
English, he could converse fairly well in Latin, and they got along
splendidly. It appears that the Catholic fathers had taught the
convert from the Latin Fathers, Jerome, Chrysostom, etc!
Eager as the Chinese are to learn from text-books, they more
eagerly cry for exhibits which appeal to the eye, and the
establishment of museums, heretofore neglected, except in the few
universities already mentioned, should be undertaken. Take one
week’s records at the Hongkong Museum, for instance. Four hundred
and sixteen non-Chinese and 163 Chinese used the library, but 193
non-Chinese and 3,100 Chinese studied in the museum. The
resourceful Canadian government sent a traveling exhibit through
China. It is what the Chinese call for. We shall yet see floating and
wheeled museums, in parvo, throughout the empire, as educational
bodies and merchants appreciate this as the quickest way to
approach the Chinese mind.
When the revolution of 1911 had developed strength, the
Chinese government found itself unable to remit to the thousands of
students who were studying in foreign countries. The American and
British universities, without exception, nobly offered to aid any
needy Chinese student. The move was brilliant and humane, and will
be bread scattered upon returning waters of appreciation some day.
 The new representative assemblies have necessitated the
introduction of shorthand in China. The Tsze Chen Yuan (National
Assembly) in session at Peking as early as August, 1911, ordered
night classes to be opened for learning the art, so that the civil
service clerks might attend. I know that missionaries, helpless in
committing to paper accurately the sounds of the scores of Lolo,
Miaotsze, and other dialects in Yunnan, Szechuen and Kweichou
provinces (where aborigines abound) have had recourse effectually
to phonography. If the brilliant Dickens, John Hay, the American
secretary of state, who founded the policy of “non-partition of
China,” and many others, were phonographers, why might a
missionary not be one also!
Some of the educational proverbs of the Chinese are the
following:
“A lion breeds lions, and a brave father has brave sons.”
“Learn easy, forget easy; learn hard, forget hard.”
“Life is a river; if you are not going forward on it, you are falling
behind.”
“Youth jumps and slips; age picks its steps and crosses safely.”
“Measure words by the height of the brain, not the height of the
body.”
“A loose rein for a good head; a tight rein for a loose heart.”
“Faces are alike, but minds are myriad.”
“It takes longer to determine than to do.”
“Fate doesn’t plan the lot of a fool.”
“The mind chisels the face.”
“It isn’t far at the turn of two roads, but they end far apart.”
“With weeds, and with learning, get at the root.”
“Nothing that is human is alien to a good man’s interest.”
 “He who has no ambition is like an ax without edge.”
“Moments are more precious than jewels, for the first can not be
recovered if lost; the second may be found.”
“A right beginning makes a proper ending.”
“A tight mouth keeps back much mischief.”
“Heaven never put a bar against resource.”
“When you know yourself thoroughly, you know everyone else.”
“Prejudice is the thief of persuasion.”
“Two things strangle, the tongue and the cord.”
“Be as cross to yourself as you are to others; be as sweet to
others as you are to yourself.”
“Never too great to learn.”
“The last step must be as steady as the first in climbing a hill.”
“The downy chin goes over it; the bristly chin goes round it; or,
the young head for the long jump, and the old head for the long
thought.”
“Good gives the tangible, evil but the shadows.”
“If you insist on every one being like you, look nowhere but in
your mirror.”
 XIX

NOTES ON CHINESE LITERATURE AND

LANGUAGE

Among the treasures of Buddhist monasteries are the stone

tablets called “Pei Tze.” It used to be the custom of celebrated
visitors to write an epigram, a witticism, a poem, or a sentence of
philosophy, which the monks had a stone-cutter engrave as near the
beautiful chirography as possible on these tablets, which constitute
through the empire a great literary treasure which is not likely now to
be renewed. Not a little of the sententiousness is humorous. A sign
hanging up in a celebrated Buddhist monastery in the Chingtu plain,
Szechuen province, makes this merry reference to fleas, which
constitute the largest part of the present immense population of
China: “There are animals with more legs than ponies at Inns other
than this Inn.” Another popular humorous motto is: “One can carry
kindness too far, such as the fisherman who had such pity for fish
that he would only go fishing with straight hooks.” The idiom for
inaction is: “keeping one’s hands in one’s sleeves.” For “eating crow”
the Chinese say: “eating a dumb man’s bitterness.” More of their
wisdom follows:
“Meekness and gentleness are the boat and the sail for crossing
the rough stream of this world.”
“The truths that we least wish to hear are those which it is most
to our advantage to know.”
 “The way to glory lies through a palace; to riches through a
market; to virtue through a desert.”
“The Manchu court is like the sea, where everything depends on
the wind.”
“He who wishes to secure the good of others has already
secured his own.”
“The prison is shut night and day, yet is always full; the temples
are always open, yet you find no one in them.”
“He who lets things be given to him is not good at taking.”
“The dog in the kennel barks at his fleas, but the dog who is
hunting does not feel them.”
“The finest roads are the shortest ones.”
“Man may bend to virtue, but virtue can not bend to man.”
“The wise man does not speak of all he does, but he does
nothing that can not be spoken of.”
The Occidental manner of emphasizing a plea is: “If you don’t
follow this advice, look out for the consequences.” Here is the
Chinese phrase, as concluding Wu Ting Fang’s plea, in December,
1911, to the Prince Regent Chun to abdicate: “Our voice is hoarse
and our tears are exhausted; no more can be said.” Their idiom for:
“I’m not my own boss” is: “I eat another’s bread; I watch at the
door.” More of their proverbs are:
“Who is he, though he never goes out, yet has seen all that is
under the sky? The scholar among his books.”
“If the ruby is unpolished, it is not a gem.”
“Age for a sharp chin, and a sharp tongue.”
“It is with human nature as with wines: age sweetens some and
sours others.”
“Happiness and misery both come in doubles.”
 “Going through college doesn’t mean that the college has gone
through you.”
“You can lead a boy to the right book, the rest depends on
himself.”
“The deeper the water, the slower the stream.”
“It is easier to escape a splinter that you see, than a beam that
you don’t see.”
“Familiarity takes the height off a mountain.”
“Wit may purchase wealth, but wealth can not purchase wit.”
“Originality can go so far back that it becomes aboriginality.”
“Your parents died when you were a child,” is the bitterly
sarcastic way in which the Chinese express that one has no manners,
or up-bringing. The following repartee is credited to almost every
traveled Chinese official, but it originated in the imagination of an
Occidental wit, because the Chinese consider manners and
forgiveness the first rule of public conduct. Official Bu was asked by
an impertinent Occidental why he wore such a ludicrous appendage
as a queue. “Why do you wear a mustache?” asked the Oriental,
“Because I’ve such an awful mouth.” “I thought so, from your first
question,” was the Oriental’s rejoinder.
Yu Yuen, a satirist of 400 B. C., when China was divided into
many states, ruled by inferior princes, wrote in defense of the able
prime ministers who were trying to save the states: “I, too, am glad I
can not fall to the intellect and moral level of princes.”
Chang Jo Hu, A. D. 800, with Isaiah-like emphasis reminds even
long-lived proud China that
“There’s no rock of empire man shall make,
But tooth and tide of time shall shake.”

He also wrote:
 “The waves of the Yangtze that pass to the sea,
Nevermore shall return to me;
So, friend of my soul, ’tis with me and with thee.”

Po Chuh Ih, A. D. 772, once president of the Board of War, and

later an exile, wrote some Scott-like lays, including the Never Ending
Wrong, and the famous Lute Girl, which is full of silver music coming
over a moon-lit lake. At the lake he meets the lute-girl, once a court
favorite, but now old and deserted. The poet does not try to disguise
the truth. He says:
“The eye of Beauty wins a monarch’s soul,
And wrecks an Empire, too.”

Tai Chen, a poet, speaking for the Emperor Ming Huang, who is
pursued to Mount Omi, in Szechuen, by the rebel, An Lu Shen,
writes: “The star of empire pales before the morning beams of
conquering foes.” Some of his lyrics show pretty conceits like: “The
pansies are faces of loves that have died.” His Ruined Home reads
like parts of Solomon’s wisdom.
Tai Chen was preceded by the most famous poet of China, Li Po
(A. D. 702). He was born in Szechuen province. His patron was the
Emperor Ming Huang, then a wanderer, as we have stated. A
Browning-like poet of the world, he talks of the Tang emperors of
Nanking, patrons of sculptors, “calling down the dreams of the gods
and imprisoning them in stone.” In an ode to Nanking, he tells about:
“a woman asleep by a loom, and a beautiful dream guiding her
fingers along a glorious pattern that is known only to the gods.” He
believes in the high mission of the poet, for he sings of “the fadeless
lines of fire, running back to the births of immortal poets, who now
walk amidst the stars.” Like others of the Chinese, and many of the
new race of American poets, he has a strong sympathy with trade
unions. He addressed an ode To the Golden Presence of Guild
Brothers. He sings mightily of war in a song To my Fatherland, and
then lapses thus into a sadder note when he reflects upon whom the
sorrows of war come: “The pensive washwoman sends her heart to
the Tartar war in far Kansu province to find her conscript soldier
husband who suffers in the snows.”
Kao Shih, a contemporary poet, was a tremendous believer in the
personal soul. He wrote striking verse because of his love of the
occult, and his tendency to give to natural phenomena dramatic
personalities.
Ou Yang Hsiu, of the following dynasty, the Sung, 1007 A. D.,
himself a governor, and historian of the Tang dynasty, wrote a
famous “Autumn” poem, which is truly a march of Elizabethan
metaphors. He showed, too, a cynicism which was like the
Elizabethan:
“Fame, after all, is such a little thing!
Behold the fox and weasel’s young now play
Where lie the ashes of the great Man-Ching.”

Abbé Huc’s servant, Wei Chau, picked up in the book stores of

Nanchang, in Kiangsi province, pamphlets with the following brilliant
epigrams, which are not surpassed in any literature, and which might
have been written by Wilde:
“My books speak to my mind; my friends to my heart; all the rest
speak to my ears only.”
“One needs his wits most when dealing with a fool.”
“One forgives anything to him who forgives himself nothing.”
We call our printed Bible the “Word of God.” The Chinese have an
expression somewhat similar. Their beautiful ideographs are
delightfully called “Eyes of God.” The following is an effort of the
Manchus in literature, translated idiomatically, and it shows the
literary feebleness of the relapsed old conquerors. It is the national
anthem which the dynasty gave by edict to the Chinese to sing at the
opening of the rebellion in October, 1911:
“May the Golden Round be kept intact;
May Heaven help us;
Let the people and Nature live as quietly as ducks among lilies;
Both peoples (Chinese and Manchu) now dress alike; therefore be
alike;
In this time of the Manchu (Ta Ching—Great Pure) dynasty we are
fortunate to see true splendor and greatness;
May Heaven protect the Emperor and his line;
For Heaven is greatest,
And Nature is infinite” (the suggestion being to fear God, or Nature’s
god).

The omnivorous Goethe made some investigation of Chinese

literature, and here is his opinion of what he had read: “The people
think, act and feel almost entirely as we do, although with them
everything is clearer, calmer and more moral. In their arrangements
everything is sensible, bourgeois, without great passion or poetry.
What is moral, proper and in strict moderation is considered.” Now
and then more or less distinct evidences of Chinese influence on the
Greeks come to view, though the thread west of the headwaters of
the Tarim is now lost. Many of the doctrines of Pythagoras and Plato
are similar to those of Chinese Lao Tse, and therefore they may have
been instructed by the Chinese sage, whose book could have gone
overland to Greece with the caravans of silk.
The advent of the many newspapers has made a great difference
in the nerves and consciousness of the Chinese. From being the most
stolid of peoples, indifferent to famine, flood, war, persecution by the
officials or by the favored, poverty, pain, hardships physical and
mental, they have become as restive, impatient, nervous and self-
conscious as other races. Famine and flood used to sweep down and
destroy millions. What was the use of complaining, since no one
knew, nobody cared, and the victim might as well not care? Now, if
disaster takes off not a million men, but one man, it is important, the
newspapers chronicle it, and show how the lot of others may be the
lot of the individual. The sufferer himself cries: “Woe is to me; isn’t
this unendurable; help me; I can not, I WILL not bear it.” The
newspaper has developed the ego. The Chinese has become self-
conscious and nervous. He can not, he will not hereafter bear
anything more than other peoples. In the August, 1911, floods and
the October, 1911, revolution more fuss was made over the loss of a
thousand men and women than over the loss of hundreds of
thousands in the Taiping rebellion in the same region in 1853.
Not long ago, a weekly at Hongkong appealed to its public for a
new name. I quote some of the names to reveal what the Far East
thinks of itself in a humorous or serious light: “Bird of Freedom”;
“Bubbles”; “China Answers”; “Cathay’s Looking Glass”; “Chop Sticks”;
“East of East”; “Fragrant Waters” (the translation of Hongkong); “Fire
Crackers”; “Murmurs and Funnosities”; “Mixed Pickles”; “Peak and
Praya”; “Topical Tropical Times”; “The Griffin” (a beginner in the
Orient); “The Gong”; “The Hit”; “Humming Top”; “Imperial Outpost”;
“The Lantern”; “Merry-Go-Round”; “The Palm”; “The Pearl”; “Sun of
Cathay”; “The Typhoon”; “The Ferret”; “The Colonel”; “Maskee” (the
Chinese way of saying “never mind”); “Puckee” (the Oriental way of
saying “O.K.”). The Chinese newspaper is a success, commercially,
patriotically and educationally. Millions now read it every day. It gave
the best and earliest news of the October, 1911, revolution. There
are Chinese newspapers in San Francisco, New York, Vancouver,
Singapore, Penang, Hongkong, Sydney, Paris and London.
Chinese plays recite the history of the clans and early states.
Even the boatman and laborer are familiar with them. Every hill,
valley, and reach and fall of a river north of the Yangtze has its hero
and story. This would seem to prove that the race first came through
the Tarim and Kansu gates to the new land. The rich, who aim to
control trade routes and privileges depending upon popular
tolerance, in Roman fashion give free theatricals to the village folk.
The acting is excellent and spirited; the feats of memory remarkable,
and the costumes gorgeous. “Once an actor always an actor,” they
say, regarding the custom of youths being bought or apprenticed by
the traveling troupes. Guild halls and some monasteries have
theaters in connection with the compound. A restaurant is run during
the long series of plays. You hurry out to dine when the play you are
least interested in is rung in by cymbal. Bets and lawsuits between
the guilds and villages are often settled by the loser paying for the
visit of a theatrical troupe. Beautiful specimens of the blue and gold
gowns of the emperor-actor can be secured at the silk shops of the
treaty ports, and in some of the Oriental shops of New York, San
Francisco and London.
The American and British college graduate wears a hood; the
Chinese wears a yellow panel on his breast and back (it may be
changed under the republicans to blue). When Yuan Shih recently
took the oath of office as provisional president, two bonzes of the
famous Lama Temple at Peking stepped up, and presented him with
honorary panels of yellow silk.
The incident will be recalled in Judges, Chapter 12, where the
Gileadites slew the Ephraimites who could only pronounce the word
“shibboleth” as “sibboleth”. The Manchus are thicker of tongue than
the Chinese. An ingenious story got about in October, 1911, that the
rebels of General Li’s army were testing some disguised Manchus
with the pronunciation of the numeral six, “Liu”, before killing them in
retaliation for a massacre, the Manchus being unable to get the
sound far enough back in their mouths and around their tongue in
the proper Chinese fashion. The proper tone, lisp and aspirate makes
all the difference, for the same written word “ho” means river and
fire; the word “shui” means water and sleep; “chih” means gas and
red, and so on.
English, and not German, has been prescribed as the language to
be used in the study of science and world politics. The Chinese idiom
and ideograph could not come near enough to distinct expression.
For instance, the best they could do with fire-engine, steam-roller,
Elijah’s chariot of fire, and automobile, was to call them all “fire
carriage”; and electricity, globe, and flash-light were all three
“lightning breath”. Geography, the world, and panorama were all
called “All Under Heaven” (Tien Hsia). “Heavenly Literature” (Tien
Wen) represented the words theology and astronomy. Lacking
pronouns, the language adopts peculiar expedients. Thus an affix
meaning “near” answers to “my”, and “that side” answers to “your”.
That is, “near house” is my house; “that side house” is obviously
your house. If this does not clearly convey the idea, the arbitrary
ideographic affix of “honorable” and “despisable” will; that is, the
“honorable house” is your house of course, and the “despisable
house” with so effusively mannerly a people could only be my house.
On account of their experience with the difficult and beautiful
Chinese character which requires accuracy, the Chinese penman who
learns to write English, does it in the most beautiful Spencerian
copper-plate. The same care and skill is shown in copying drawings
from our modern text-books, which have been translated for their
new schools. The Chinese think in pictures. The characters for “many
stars, clouds wait” means a clear night, as “clouds many, stars wait”
means a gathering storm. This is why they have chosen English for
its exactness, as they can not well express the word gathering. “It is
bad walking” is rendered by “Walk not attain” (Tsou puh te).
Passenger boats or skiffs are not so named. Those in use at
Hongkong are called “san pans” (meaning three boards), and the
famous light boats of the Yangtze gorges between Ichang and Wan
Hsien are called “wu pans” (five boards). The forcible etymology of
some Chinese words is illustrated by the words for “fan tan”
gambling, which literally means “turn and part”. The cup is turned
over a lot of coins, and the rest of the heap is brushed aside. Then
the cup is raised, and the croupier, with his separator-stick, parts four
coins at a time from the lot, until four or a particle are left, this being
the winning number of the game. That the old southern Chinese, as
contrasted with the succeeding northern Mongol invaders, invented
the language is shown in many of the words. For instance, the word
for road or path is called throughout China a “dry way”, and not a
road or street. Only the central and southern provinces flood the
fields for rice culture, leaving the raised dry paths.
Samuel Pollard, a missionary working in Yunnan, is compiling an
alphabet and reducing to writing the speech of the hitherto
unrecorded aboriginal tribes, the Miao and Lolos. He plans then to
give them some western literature in return for the ethnological
riches which they give us. They are the most unique people in the
world, older even than the Chinese. Their fortresses are in Szechuen,
Yunnan and Kweichow provinces, and there are, perhaps, two
millions of this fearless fighting race. From dimmest history they have
been pressed back to the mountain tops by the Chinese, who have
spread out from their original home in the Yellow River valley with
four hundred million people. That the Chinese have impressed some
of their language, as far as necessary trade goes, on the aborigines
can be seen from the following table, there remaining only two (two
and five) sounds in these eight, which have not been somewhat
influenced:

MIAO
ABORIGINE CHINESE
1 Ah Ee
2 Ow Erh
3 Tsz San
4 Peu Su
5 Peh Wu
6 Glow Liu
7 Ya Pah
8 Chow Chiu

The writer in the Antiquity chapter of a former book adopted the

Biblical account of the creation, that the original Chinese (Chou clan’s
ancestors) spread through Turkestan, along the Tarim valley, to their
first known home in Shensi province. Doctor Stein has found on the
site of the ruined temple of Hangayi Tuti at Khoten, in Chinese
Turkestan, birchbark and other manuscript in an unknown language.
These point the way to a further search. The Asiatic Society, of
Bengal, Calcutta, has acquired from a Montenegrin gentleman, who
traveled in Turkestan, five leaves of brownish yellow manuscripts
eight by six inches, in an unknown language, which wait to reveal
possible wonders of China’s prehistoric story. The pages show that
they were one part of an extensive work now lost in the sands and
camp ashes of central Asia. There is room for emulation by America,
Britain and China of Russia’s archeological research in Chinese
Turkestan, for the world wants to know more of ancient China, now
that the New China has become important. The professors of the
American colleges in China are sufficiently learned to make a
beginning in preserving China’s antiquities, which are now in great
danger of being lost forever. The rage, as far as the Chinese
themselves are concerned, is altogether for the new and utilitarian.
The modernized Chinese have already forgotten their conservative
Hanlin Academy.
 XX

LIFE OF FOREIGNERS IN CHINA

I know of no place where music, lanterns, romantic mountain

scenery, seascapes far below and delightful society in an alien
setting combine more pleasantly than at the Peak Club, Hongkong.
Above the passing clouds which now and then whirl around as in
Rubens’ pictures, over the purple Pacific Ocean which foams around
hilly islands, over the high hills as you ascend from the royal colony
of Victoria, on a terrace, they have graded a velvet lawn. Here the
military and naval bands are brought for a promenade concert in the
soft night of the fragrant Orient, beneath Bowring’s “wide Cathayan
tree”. The band of the Royal Welsh Fusiliers, from Mt. Austin
barracks, plays the stirring Welsh national march, The Men of
Harlech. The men sing the chorus:
“See! the bonfire light before ye,
How its fiery tongues do call ye,
Come as one to death or glory,
Heroes of the fight.

“Lest by fire they kill and plunder,

Harlech! Harlech! make them wonder
At thy power that none can sunder;
Freedom thou wilt give.”
Flowering plants in large colored Chinese kongs are set out
everywhere. The stars and moon shine. The pictured lanterns gently
swing, and the horn lanterns of Ningpo are opal soft. The light
flashes from swords, uniforms and jewels. The blue-gowned Oriental
servants noiselessly pass refreshments. Not a Chinese house is in
view, though half a million Chinese live hidden in the foothills. On
the hundred peaks of Hongkong Island, the lights of a hundred
palaces and villas of the merchant princes shine out. Down the
winding cement paths, chairs bearing lanterns and carrying guests
are borne with their rhythmic swing.
Every lady and every man present has come from far, and knows
much of life and geography. The conversation tires not, for there is
something of great interest to tell. Kitchener’s brother (Kitchener
himself would not come—he never moves in “society”); General
Wood, of the United States Army; Commander Greeley, United
States Navy, of North Polar fame; Admiral Scott, of the British Navy,
who invented the large gun “dotter” that made the heavy
marksmanship possible, and whose 4.7 gun saved Ladysmith;
Nathan, the hero governor of the typhoon and Hankow holocaust;
the governor of the Philippines at the far stretched-out line of
America’s new fame and empire; Kipling himself full of his colored
phrases; authors of books on China, many of whom live in
Hongkong; German, French and Russian commanders, whose
impetuous ambition has made many moves that have nearly started
world wars; ordnance and commissariat colonels, who, without a
hitch, have provisioned famous international military relief
expeditions; prince and pauper explorers who are one in the
camaraderie of adventure for science; curio collectors who are raking
the world to enrich western museums with enravishing art; Ponting,
the photographer who went with the intrepid Commander Scott to
the South Pole; seven-year indentured “griffins” who are second
sons of noble houses and whose inheritance of style is a millstone
around the necks of their impoverished incomes; subalterns who are
chafing at the bit to be let make a mark like Kitchener; visiting
lieutenants from Manila who would emulate Funston in the
Philippines; Japanese doctors who have beat the world in
discovering Bacillariaceæ; Parsees who have founded universities
and have, therefore, dined with “my friend, the king”; the merchant
princes and the missionary apostles of China, whose knowledge
would fill books; women of grace, beauty and learning, nibbling at
sweet cinnamon, musk and lotus; international spies of both sexes
from the notorious Brussels headquarters; all move over the quiet
grass, listening to the haunting strains of the bewitching music,
which makes the heathen hills unalien under the swinging lanterns
and the white-riding moon.
When you lift your glass to say “prosit”, “here’s how”, “à bon
santé”, or “here’s to you, old man”, with no national reservations,
and a feeling that all traveled men are brothers; and some
fraternally wider day possibly you will not shiver when John Celestial,
Friend Nippon, and Aryan Bengal are admitted to the delightful
company gathered under the whispering bamboos and floating
sandal scent of the Peak Club of Hongkong.
It is the same interesting story on ladies’ night at the Bund Club
of Canton; the Jockey Club of Shanghai; the Hankau Club; the
Tientsin Club; the delightful conversazioni at Sir Francis Aglen’s on
Customs Street, Peking, when the National Customs Band plays; the
Gouverneur’s “Palais” at Saigon and Hué; the International Club at
Harbin; Government House at Wei-Hai-Wei; or the consulate at
Chifu. It whets the imagination to be dancing within sight of the
stacked rifles at the front, and you reverse Tennyson and say in
Locksley Hall: “Better one night in Cathay than a cycle of Park Lane”
(or Fifth Avenue)! You recite the thrilling incidents, such as the ball
which Wellington attended on the eve before Waterloo, etc.!
Certainly the foreigner in recent years has never known when he
would be called upon at Hongkong, Canton, Hankau, Shanghai,
Tientsin, Amoy, Macao, Fuchau, etc., to rush out, in either his dress
or his business suit, or possibly his night pajamas, with his gun, to
defend property, some kind of government, and the white man’s
rights and habits of trade and international civilization. Not only
white men have suffered and borne, but the foreign heroines of
diplomacy, missions and trade of Wuchang, Hankau, Canton, Peking,
Tientsin, Chingtu, Chungking, Amoy, Fuchau, etc., are numbered in
hundreds.
The foreigner in China enters upon his sporting and social
enjoyment keenly, because his sufferings from climate, alienation
and danger are also keen. Taking his life altogether, he deserves
more than he receives as a reward for his work, and he and his wife
are unusually interesting people to meet, as I know from three
years’ life in their honored midst.
The human beasts of burden—the rickshaw coolies of Hongkong,
Shanghai, and the treaty ports—are directed by little of their own
language. Only a few of the mercantile men on station learn the
language. The foreign tourist generally learns two words, “kwai se”
(go) and “man-man” (stop-stop), and the coolies, like beasts,
therefore depend for directions as they race along in the heat, on a
tap on the left or right shaft to indicate which street the “fare”
desires to turn up. Hongkong proposes to have printed on a large
bill-board at every chair and rickshaw stand a list of fares. Hongkong
and Shanghai have become great tourist centers, whole shiploads
landing there from New York and San Francisco, and the tourist’s
generosity or lack of local information permits him to pay so large a
fare that the expenses of the resident are raised beyond endurance.
The example of Hongkong might well be copied at every tourist
center over the world. “A fair price, but not a foolish price” is the
watchword in these new days of economy and efficiency, because
world-waste can be tolerated no longer.
The regiments which from time to time come to garrison
Hongkong reveal many interesting traits in their customs and
uniform. The Royal Welsh Fusiliers, fresh from the Boer War, wore
three silk ribbons down their backs. They are the only British
regiment which is permitted thus to mourn the deprivation of the old
“pig tail” of the bewigged regiments of the Georges, which custom
they were the last regiment to discontinue. The Lincolnshires wear a
band of green to show that they are foresters recruited in Robin
Hood’s country. The Inneskilling Fusiliers and the Somersets at
Tientsin retain their traditional territorial peculiarities. The
Cameronians are the only British regiment which is allowed to bear
arms into church service, as a reminder of the old strenuous days of
surprise when the clans might leap like a wolf from behind even the
pulpit. There are so many branches of the historic British service in
Hongkong’s, Tientsin’s, etc., garrison life that American tourists are
delightfully entertained and instructed in tradition that is far from
uninteresting. The British have found that to recruit and fight a man
as a number is not a success, as compared with the picturesque
traditions in a territorial army of uniform, customs, names, fetish,
romance, glory, flags, distinctive rights, etc. In other words, they
humor Tommy Atkins as a boy, and he fights for them like a man,
every time it is necessary. This was shown when the swagger
regiments of the Guards of London, under Generals French, Paget
and Roberts hit the Boer lines as hard as the Royal Welsh, who are
recruited from sturdy fearless miners. Bret Harte’s “Caucasian
showed that he was no more played out” on those occasions than he
was when he rushed El Caney and San Juan Hill led by Roosevelt,
Lawton, Chaffee and Wheeler. The Chinese of Peking and Tientsin in
1900 had a chance to see the brilliant performance of the American
Fourteenth Infantry, Sixth Cavalry, and the marines under Captain
McCalla of the cruiser Newark, and recently the fine Fifteenth
Infantry, U. S. A., has renewed the very favorable gentlemanly
impression at Tientsin and along the railway line to Peking.
When the military weddings take place at St. John’s Cathedral,
Hongkong, and the cathedrals at Shanghai and Tientsin, it is
customary for the brother officers of the groom to unsheath their
swords and make an arch of steel over Mars and Venus as they
make their exit from the church. This old custom is not often seen
elsewhere than in India and China, and would be a pretty one to
adopt for military weddings the world over. The Germans particularly
would take to it with zest; in fact, they have just adopted it in their
“kirche” at Tsingtau, North China, and the Americans may adopt it in
the smart military life of Manila.
 Important newspapers published in English are the Times, at
Tientsin; the Mail, Telegraph, Press and Post, of Hongkong; the
Herald, News, Mercury, Press, Far Eastern Review and Times, of
Shanghai; the Post, of Hankau; the Gazette and Times, of Amoy, and
the Echo, of Fuchau. The Times and the Cable News, of Manila; the
Free Press and Echo, of Singapore; and the Englishman, of Calcutta,
may be included, together with the Chronicle, of Japan, because
they circulate in China ports, “nothing that is Oriental being alien” to
their fascinating news columns. Their editorials are illuminating, and
often exhibit in their cultured English positive genius. They are an
authoritative source of information on the absorbing theme of
golden Cathay, and the interest of the brave Occidental pioneer in
her awakening.
Water polo, swimming, launch, golf, cricket, tennis, yacht,
dramatic, polo, etc., clubs are established at nearly all the treaty
ports, and inter-Hong, inter-service, international and inter-
regimental contests are constantly going on to take the edge off
ennui in the long day of Oriental exile in a seven-year indenture. For
those inclined to literature, science and ethnology, there are notable
library and Asiatic associations, and some of them superintend an
indispensable press. Royalty visits Hongkong frequently and
encourages every phase of life in the premier colony. On the
occasion of the Duke of Connaught’s last visit with his family they
received the military at the landing pier and the populace at the City
Hall; unveiled statues to the late King Edward and King George;
lunched with the governor and council; attended a meeting of the
Scottish Rite Masons, lunched with the mess of the Indian frontier
regiment camped out on the foothills of China; attended a Chinese
theater; ate at a Chinese restaurant; attended a daylight try-out of
the racing ponies, Indian-breds and Walers at the Wong-Nei-Chong
Jockey Club; and went with “Hoi-Polloi” on a week-end trip on the
steamer Fat Shan to see Canton’s sights, and “tiffin”, as does the
whole world of globe-trotters, on the third veranda of the five-
storied pagoda. German royalty is just as active at Tsingtau, French
nobility at Saigon and Haiphong, Portugese nobility at lovely Macao,
and the cosmopolitan world at the “Paris of the East”, Shanghai. Of
Macao, the famous poet, Sir John Bowring, wrote:
“Gem of the Orient earth and open sea,
Macao! that in thy lap and on thy breast
Hast gathered beauties all the loveliest,
Which the sun smiles on in his majesty.
The very clouds that top each mountain crest,
Seem to repose there, lingering lovingly.
How full of grace the green Cathayan tree
Bends to the breeze—and now thy sands are pressed
With gentle waves which ever and anon
Break their awakened furies on thy shore.
Were these the scenes that Camoens looked upon,
Whose lyre, though known to fame, knew misery more?”

In a former book, The Chinese, I have referred to the high cost

of living at Hongkong, Shanghai, etc., as far as rent is concerned.
This is because a navy and army have to be maintained. It is well
known that Hongkong contributes to the British Budget more pro
rata than any part of the long red line of British empire. The man
who goes to the hot damp East to advance the cause of imperialism,
and who reads Kipling and Gilbert Parker, pays high for it in money
as well as health, and he deserves more than he receives. Land
values are twice what they are in the suburban cities of New York,
such as Brooklyn and Jersey City, and twice what they are in the
outlying wards of London. Yaumati is a section of Hongkong’s colony
on the China mainland, and values there are not so high as on hilly
Hongkong Island. Yet a plot of land 150 by 140 feet, recently sold in
Yaumati for $8,700 gold. No American or European should be sent to
the treaty ports of the Far East to support any cause, diplomatic,
military, commercial, scientific, academic, religious, or international
customs, who is not given twice the emolument that he would
receive at home. Yet the mission leaders in particular generously
accept far less than they would receive as workers in America.
 The foreigner has a larger list of supplies to pick from than was
the case before modern roads were opened and the Chinese were
taught to farm for the foreigner’s table. Ice houses, ice machinery,
inspected markets, and water tanks for fish all have aided. Not so
long ago we in the Far East were benzoate of soda and salicylic acid
fiends, the men Doctor Wiley bemoaned; that is to say, our gun was
a can-opener, and our game was tinned foods. We could go out into
the jungle of Queens Road or the praya, Hongkong; Nanking Road,
Shanghai; Kaiser Road, or the Chien Men Fair, Peking; or the bunds
at Tientsin, Canton or Hankau, on our way home from office, and
with our weapon bring down the foods of Europe, America and
Australia, running, of course, not a little risk of ptomaine poisoning,
positively ruining our stomachs forever, and becoming a permanent
dyspeptic charge upon the nerves of the long-suffering community!
Now things are better. Here is a list of fresh foods procurable in the
larger ports. In the plague, typhoid or cholera season, some eschew
fresh vegetables, and again, when they recall that the farmer is the
town scavenger, some eschew fresh vegetables at all seasons! I
quote the prices in gold, and give the Chinese word your lordly cook
calls out to the obsequious stallsman, so that the stranger may gain
an idea that Chinese does not sound unmusical:

MEAT
Beef sirloin, Mei Lung Pa, 10 cents a pound.
Beef steak, Ngan Yuk Pa, 10 cents a pound.
Mutton chop, Yeung Pai Kwat, 12 cents a pound.
Pork chops, Chi Pai Kwat, 10 cents a pound.
Chicken, Chu Yau, 8 cents a pound.
Duck, Ap, 15 cents a pound.
Doves, Pan Kau, 7 cents each.
Geese, Ngoi, 13 cents a pound.
Turkeys, cock, Phor Kai Kung, 20 cents a pound.
FISH
Barbel, Ka Yu, 5 cents a pound.
Carp, Li Yu, 9 cents a pound.
Cod, Mun, 7 cents a pound.
Crabs, Hai, 9 cents a pound.
Cuttlefish, Muk, 6 cents a pound.
Eels, Conger, Hai Mann, 7 cents a pound.
Frogs, Tien Kai, 20 cents a pound.
Garoupa, Sek Pan, 28 cents a pound.
Halibut, Cheung Kwan Kup, 12 cents a pound.
Lobster, Lung Ha, 18 cents a pound.
Mackerel, Chi, 16 cents a pound.
Mullet, Chai, 10 cents a pound.
Parrotfish, Kai Kung, 8 cents a pound.
Pomfret, white, Pak Chong, 13 cents a pound.
Salmon, Ma Yau Yu, 16 cents a pound.
Shrimps, Ha, 12 cents a pound.
Soles, Tat Sa, 12 cents a pound.
South China is rich in fish, and I could quote scores more.
FRUIT
Almonds, Hung Yan, 9 cents a pound.
Apples, Chifu, Tin Chun Ping Khor, 7 cents a pound.
Bananas, fragrant Canton, San Shing Heung Chiu, 1½ cents a
pound.
Carambola, Yeung Tuo, 4 cents a pound.
Cocoanuts, Yeh Tsz, 5 cents each.
Lemons, Ning Moong, 4 cents a pound.
Lichees, Lai Chi, 5 cents a pound (called “Chinese nuts”).
Lily roots, Lin Ngan, 3 cents a pound.
Limes from Saigon, Sai Kung Ning Moong, 3 cents a pound.
Pears, Canton, Sa Li, 4 cents a pound.
Peanuts, Fa Sang, 5 cents a pound.
Persimmons, Hung Chie, 10 cents a pound.
Pineapples, Sheung Poon Ti Pau Lau, 5 cents each.
Plantains, Tai Chen, 1 cent each.
Plums, Swatow, Hung Lai, 5 cents a pound.
Pumelo, Siam, Chim Lo Yau (grapefruit), 5 cents each.
 Walnuts, Hop Tuo, 6 cents a pound.
Watermelon, Sai Kwa, 1½ cents a pound.
VEGETABLES
Beans, sprouted, Ah Choi, 2 cents a pound.
Beets, Hung Choi, 1 cent each.
Brinjal, Ching Yuen, 2 cents a pound.
Cabbage, Kai Choy, 2 cents a pound.
Carrots, Kam Shun, 3 cents a pound.
Chilies, Red Hung Fa, 3 cents a pound.
Cucumbers, Ching Kwa, 1 cent each.
Garlic, Suen Tau, 3 cents a pound.
Ginger, young, Sun Tsz Keung, 3 cents a pound.
Corn, Suk Mai, 2 cents each.
Lettuce, Yeung San Choi, ½ cent each.
Onions, Sang Chung, 2 cents a pound.
Papaw, Tai Man, 5 cents each.
Potato, sweet, Fan Shu, 1½ cents a pound.
Spinach, Yin Choi, 2 cents a pound.
Tomatoes, Kan Ker, 3 cents a pound.
Vegetable marrow, Chit Kwa, 1 cent a pound.
Water cress, Sai Yeung Choi, 5 cents a pound.

The table is justly famous at the following, among other hotels

and clubs, and the wines are as cheap as in Europe, because no
duty is charged at Hongkong, and only five per cent. in China. In
Japan, however, and in French China there is a heavy duty on
foreign liquor. The Grand Hotel and the club, at Yokohama; the club,
Kobe; Wagon Lits and club, Peking; Imperial Hotel and club,
Tientsin; Astor House and club, Shanghai; Peak, Grand, Craigieburn,
Hongkong and Astor Hotels and club, at Hongkong; Victoria Hotel
and club, Canton; Boa Vista, Hing Kee and club, at Macao. When you
go there, next time, tourist, ask for broiled samli or Sek Pan at
Macao; toasted rice birds or Ap ducks at Shanghai; Mongolian
mutton at Peking; roasted imperial pheasant at Tientsin; preserved
comquats in ginger syrup, Hungyan almonds, and Sai Kwa
watermelons at Canton; Hung Lai plums at Swatow; Tin Chun Khor
apples at Chifu; fresh lichees or Phor Kai turkey at Hongkong, and
ruby red persimmons at Yokohama. It is not well to be a gourmand
always, but it is well to be an epicure on eminent occasions, so as to
remember them forever, from fear that, as in Senator Ingalls’ poem,
“Opportunity knocks but once.”
 XXI

FOREIGN CITIES OF CHINA

At all the great treaty port cities and colonies, such as

Hongkong, Shanghai, Canton, Macao, Tientsin, etc., the stranger is
accosted by crowds of rickshaw coolies, venders, fortune-tellers,
flower sellers, etc., urging his patronage. Efforts are being made to
limit this noise, which is at present like the reception that a football
hero gets when he wins a game. The Chinese think we like the
attention, because so many of us smile, and if one looks cross, a
native wit will call out: “Don’t ask Honorable Sad-Face to ride; he
has just lost his white mother-in-law, and must demurely walk
behind her ghost.”
The first motor-car used in China was brought to Hongkong by
an American dentist in 1900. It was a storage electric vehicle, as the
authorities prohibited for a while the use of gasoline on account of
the fire risk. Gasoline cars and launches are now used throughout
the treaty ports, but kerosene engines are preferred in motor-boats.
Kerosene can be procured anywhere in China, but gasoline is
procurable only within a limited area.
As a foreign steamer enters a port, a fleet of sanpans throw out
hooks and grapple with the ship. This picturesque nuisance the
authorities are trying to stop, on account of the danger to life which
is involved. The hotel runners, gamblers, and venders desire to be
over the rail before any passengers leave. The health authorities
desire to stop the irrepressible boarders as much as the harbor
masters do. The boarders shout out to their countrymen: “You there!
Throw over a fastened rope; we want to kotow to you on board, and
leave you some of our money in a little game.” Over the rope goes,
despite the frantic mate, who is a white man, and like ants, the agile
Chinese clamber up the sides of the big trans-Pacific or Suez liner.
Peking, Haukau, Tientsin, Shanghai, Ningpo, Hongkong and
other cities of China all have fine race courses, club-houses and
stables. In hot Hongkong the racing, gymkana and polo meets occur
from September to April. Szechuen and Mongolian ponies, Australian
and Indian horses are used, but few American or British, the cost
and insurance risk for the latter being too great. Every white man,
singly or in clubs, goes in for the “king of sports”, and from a military
point of view this interest in racing is very advantageous. The
betting is generally on the French method of Paris Mutuels, where
those who bet on the winning animal divide the pool, less eight per
cent. for club expenses. The Chinese are beginning to understand
the horse, and mafoo-jockeys and trainers are being developed. Up
and down the China coast the owners ship their champion racers,
and the interport rivalries are keen in this, and every other sport.
The main ambition is for the owner to ride his horse as a
“gentleman-jockey” in the crowning Derby event, and quite a few
Hebrew and Parsee owners enter their horses in a widening sporting
fraternity, which not long ago was limited to Saxons, and which may
yet include Chinese gentry. The stocky Mongolian pony, weighing
fifteen hundred pounds, only covers the mile in two minutes and
eight seconds, and being hard of mouth and stubborn, he is as likely
as not to cover the mile the opposite way to that which has been
prescribed by the stewards! Not only has Hongkong two very fine
golf courses, but Canton, Macao, Hankau, Shanghai, Peking,
Tientsin, and other treaty ports have excellent courses famous for
their novel bunkers of tombstones, etc., and club-houses. During
most of the year at Hongkong the game is played on the Wong Nei
Chong course shortly after daylight, as after eight o’clock the
overhead sun is too hot for that exercise which is essential if one
expects to keep “fit” in the Orient.
 Copyright, 1913, The Bobbs-Merrill Company.

The mountain palaces of Hongkong; clouds almost cover the great

peaks. Note gate house, covered chairs; extensive verandas.
Hongkong’s architecture dominates the New China; it is a heavy
adaptation of the Renaissance, with massive verandas added.
 Copyright, 1913, The Bobbs-Merrill Company.

Race meet at the Jockey Club, Wong Nei Chong Valley, Hongkong.
The cosmopolitan crowd: Hindus, Portuguese, Britons,
Americans, Japanese, Chinese, Parsees, etc. Note the famous
mat-shed for the “Hoi Polloi” in the background. These immense
structures are erected overnight, with matting and bamboo.
 Copyright, 1913, The Bobbs-Merrill Company.

The railway breaking through the wall of Peking. The

immense new railway development of China has
been put under the direction of the Honorable Sun
Yat Sen.

Many have asked what was the organization of the crown colony
of Hongkong Island, where 3,000 white troops, a navy, 2,000 Indian
troops, and 500 British, Indian and Chinese police guard and rule
Welcome to our website – the ideal destination for book lovers and
knowledge seekers. With a mission to inspire endlessly, we offer a
vast collection of books, ranging from classic literary works to
specialized publications, self-development books, and children's
literature. Each book is a new journey of discovery, expanding
knowledge and enriching the soul of the reade

Our website is not just a platform for buying books, but a bridge
connecting readers to the timeless values of culture and wisdom. With
an elegant, user-friendly interface and an intelligent search system,
we are committed to providing a quick and convenient shopping
experience. Additionally, our special promotions and home delivery
services ensure that you save time and fully enjoy the joy of reading.

Let us accompany you on the journey of exploring knowledge and

personal growth!

ebookultra.com