# Object-Oriented Engineering: Building Engineering Systems Using Smalltalk-80

John R. Bourne

<figure><img src="image_1.png" /></figure>

## To cite this version:

John R. Bourne. Object-Oriented Engineering: Building Engineering Systems Using Smalltalk-80. 1992. [hal-05188461](https://HAL Id: hal-05188461)

HAL Id: hal-05188461

https://inria.hal.science/hal-05188461v1

Submitted on 26 Jul 2025

HAL is a multi-disciplinary open access archive for the deposit and dissemination of scientific research documents, whether they are published or not. The documents may come from teaching and research institutions in France or abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est destinée au dépôt et à la diffusion de documents scientifiques de niveau recherche, publiés ou non, émanant des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

<figure><img src="image_2.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
John R. Bourne

# Object-Oriented
Engineering

## Building Engineering Systems
Using Smalltalk-80

<figure><img src="image_3.png" /></figure>
<figure><img src="image_4.png" /></figure>
Object-Oriented
Engineering

Building Engineering
Systems
Using Smalltalk-80

John R. Bourne
Vanderbilt University

IRWIN

Homewood, IL 60430
Boston, MA 02116
<figure><img src="image_5.png" /></figure>

This symbol indicates that the paper in
this book is made from recycled paper. Its
fiber content exceeds the recommended
minimum of 50% waste paper fibers as
specified by the EPA.

©Richard D. Irwin, Inc., and Aksen Associates, Inc., 1992

*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.

The programs 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.

Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. The publisher has made every attempt to supply trademark information about manufacturers and their products mentioned in this book.

Cover and text designer: Harold Pattek

Compositor: Science Typographers, Inc.

Typeface: Times Roman

Printer: R. R. Donnelley & Sons

**Library of Congress Cataloging-in-Publication Data**

Bourne, John R.

Object-oriented engineering: building engineering systems using smalltalk-80/John R. Bourne.

p. cm.

ISBN 0-256-11210-X

1. Smalltalk-80 (Computer program language) 2. Object-oriented programming. 3. Engineering—Data processing. I. Title.

QA76.73.S59B68 1992

620'.00285'5133—dc20

91-37875

Printed in the United States of America.

1234567890 DOC 87654321
About
the Author

John R. Bourne is a professor of electrical engineering and Director of the Center for Intelligent Systems at Vanderbilt University in Nashville. He received a BS degree from Vanderbilt University and MS and PhD degrees from the University of Florida. He spent 1982 as a visiting professor at Chalmers University in Gothenburg, Sweden, and during 1991 and 1992 he was on industrial leave at Northern Telecom, Inc. He has been editor of the *CRC Critical Reviews in Biomedical Engineering* since 1977 and was associate editor of the *IEEE Transactions on Biomedical Engineering* during 1981 and 1982. He has published extensively in professional journals and is the author of two books and several book chapters. During the last 10 years, Dr. Bourne's research interests have been in the area of intelligent systems and object-based methodologies.
The following
are registered
trademarks:

Actor

Apple

BOSS

Eiffel

Hewlett-Packard

High C

LaserJet

Macintosh

MS-DOS

MS-Windows

NeWS

Objective-C

Objectworks

Open Look

OS/2

PageMaker

ParcBench

ParcPlace

PostScript

Presentation Manager

Simula 67

Smalltalk-80

Smalltalk/V

SUN

UNIX

X Window System
# Preface

## Introduction

Engineering is defined as the application of scientific principles to the solving of real-world problems and the creation of artifacts for our society. The principal activities of engineering are analysis and design, that is, understanding and solving problems and designing new things. To support these activities, computers have become widely used during the last decades and are now employed throughout engineering. Furthermore, to program computers effectively, a succession of ever more complex computer languages have appeared throughout the last decades that have evolved into ever more sophisticated tools that engineers can use for problem solving. One of the most recent and innovative general computer language methodologies to appear is termed *object-oriented programming*. The name comes from the focus on describing problems in terms of objects, both physical and conceptual. Object-oriented programming methodologies appear to be superior to most other programming paradigms for solving many kinds of problems, especially problems in the domain of engineering in which problems are often readily decomposed.

## Objectives and Organization

This text focuses on the understanding and use of object-oriented methodologies for engineering problem solving with a specific emphasis on analysis and design, two major topics taught in colleges of engineering and
applied in engineering practice. The concepts are covered and the techniques for analysis and design are supplemented with numerous practical examples. The material in the book is subdivided into three parts: concepts, tools, and engineering applications. The first part examines object-oriented methods broadly, starting with examples, giving basic definitions, and introducing the reader to methods for conducting object-oriented analysis and design. The second part reviews object-oriented languages and then turns to a specific discussion of the use of the Smalltalk-80 language and environment. The Smalltalk-80 language is utilized throughout for examples. Smalltalk-80¹ was one of the original object-oriented computer languages and remains as one of the most well-developed object-oriented languages. Furthermore, the Smalltalk environment is described in some detail because this environment remains prototypical of more advanced computer environments that have become essential productivity tools for industry. The final part of the text examines applications in engineering using object-oriented techniques. Specific attention is given to various methodologies for solving engineering problems.

## Intended Audience

The audience for this text is expected to range from beginning college students to engineering practitioners. Little prerequisite knowledge is needed. Because object-oriented methodologies do not have a long history in the field of engineering, not much culture has grown up in this domain. Considerable attention has been given to explaining concepts starting with basic ideas, so that the text is appropriate for undergraduate engineering students. With appropriate explanation, the text could be used at the freshman level; however, the target level is approximately the junior undergraduate engineering student who has some background in computational methodologies.

## How to Use This Text

The most effective way to learn object-oriented programming is to work problems on the computer while reading this and other textbooks. There is much to know; hence, Chapter 1 provides a supplementary reading list which the serious student will need to examine while learning about object-oriented methodologies. Perhaps more important is the need to have an object-oriented environment to work with during learning of these concepts. The author

<footnote n="1">¹Smalltalk-80 is a trademark of ParcPlace Systems.</footnote>
recommends the Objectworks\Smalltalk (Smalltalk-80) environment, marketed by ParPlace Systems, Inc. (1550 Plymouth St., Mountain View, CA 94043; Info@ParcPlace.{com,uucp}). This environment runs on many different types of computer systems including inexpensive PC-386 and Macintosh systems. These personal computer systems, when equipped with sufficient memory, are quite adequate for learning Smalltalk-80. Especially useful is the on-line tutorial provided with Smalltalk-80. Students who have access to this tutorial should go through it as soon as possible. Single-copy educational licenses and site licenses for Smalltalk-80 are available from ParcPlace Systems.

An instructor's manual for this textbook, available from the publisher, contains (1) notes about implementing an undergraduate course around the material contained in this textbook, (2) solutions for the exercises, and (3) information about Smalltalk-80 code that is available with the instructor's manual.

## Smalltalk-80 Versions

Examples in the current edition of this text are coded in Objectworks\Smalltalk, Release 4. During 1990 and 1991, ParcPlace Systems released Release 4 as a major change from the previous release (Version 2.5). The major new features of Release 4 were the addition of color and the enhanced portability of code between various hardware platforms and windowing systems. A significant part of the text is not dependent on which version of ST-80 is used; however, the second part of the text concerned with tools provides some examples that are release dependent. Almost all examples given are in Release 4. However, when it is useful to contrast methods used in the two releases, examples from the previous version are given and discussion provided about version differences. A preliminary edition of this text was written using only Version 2.5 code. This edition is available from the author.

## Acknowledgments

The author thanks students who have, in one form or another, contributed to the material presented and have helped shape the character of this book. A special thanks is given to Zhihe Jiang who created the ViewBuilder program used in the text. Furthermore, colleagues who have worked with object-oriented methods are thanked, as well as the sponsors of many research projects that have supported the author's research during the last two decades. Thanks are given to Jacqueline Lusk, who prepared the figures, and Ellen P. Bourne, who edited and provided moral support during the writing of the text.
Thanks are also given to Howard Aksen, who was always attentive and worked hard to ensure the best possible product. Finally, thanks are given to the following reviewers of this book who carefully read and provided detailed constructive advice: Nader Bagherzadeh, University of California, Irvine; James L. Beug, Cal Poly, San Luis Obispo; Edward F. Gehringer, North Carolina State University; Howard Jachter, IBM; Fred Mowle, Purdue University.

ParcPlace Systems, Inc. grants permission to the author to use the copyrighted material, including source code excerpts and screen dumps from ParcPlace Systems' books and products, used in this book. Readers may copy such material, including all or any portions of the class hierarchy or message names, only under license from ParcPlace Systems.

J. Bourne
Nashville, Tennessee
# Contents

Preface xiii

Part One: The Concepts 1

1 Introduction 3

1.1 Objectives 3

1.2 Object-Oriented Analysis and Design 3

1.3 Object-Oriented Methodologies for Engineering 6

1.4 Tool Support for Practicing Object-Oriented Engineering 12

1.5 Recommended Concurrent Reading 14

1.6 Overview of Chapters 15

References 16

Exercises 17

2 Representing the World with Objects 19

2.1 Introduction 19

2.2 Defining Characteristics of Object-Oriented Methods 23

2.3 Representing Objects 28

2.4 The Causal Nature of Engineering Systems 33

2.5 Representing Time 35

2.6 Modeling and Simulation 36
<table><tbody><tr><td>2.7</td><td>Representation of Complex Systems:<br/>An Example of an Advice-Giving System</td><td>37</td></tr><tr><td>2.8</td><td>Summary<br/>References<br/>Exercises</td><td>43<br/>43<br/>43</td></tr><tr><td><b>3</b></td><td><b>Object-Oriented Analysis</b></td><td><b>45</b></td></tr><tr><td>3.1</td><td>Introduction</td><td>45</td></tr><tr><td>3.2</td><td>Analytical Methodologies for Building<br/>Object-Oriented Systems</td><td>46</td></tr><tr><td>3.3</td><td>Organizing Applications Using the<br/>Application/Class Organization Method (ACOM)</td><td>47</td></tr><tr><td>3.4</td><td>Analysis Maxims</td><td>56</td></tr><tr><td>3.5</td><td>Example Analysis of a Digital Circuit Simulator<br/>References<br/>Exercises</td><td>59<br/>67<br/>67</td></tr><tr><td><b>4</b></td><td><b>Introduction to Object-Oriented Design for Smalltalk-80</b></td><td><b>69</b></td></tr><tr><td>4.1</td><td>Design and Analysis</td><td>69</td></tr><tr><td>4.2</td><td>Major Design Aspects: The Model, the View,<br/>and the Controller</td><td>70</td></tr><tr><td>4.3</td><td>Model Design</td><td>73</td></tr><tr><td>4.4</td><td>View Design</td><td>76</td></tr><tr><td>4.5</td><td>Controller Design</td><td>78</td></tr><tr><td>4.6</td><td>Maxims for Design of Systems Using<br/>the MVC Triad</td><td>79</td></tr><tr><td>4.7</td><td>Example View Design Scenarios for Digital Circuits</td><td>80</td></tr><tr><td>4.8</td><td>Summary<br/>References<br/>Exercises</td><td>83<br/>83<br/>84</td></tr><tr><td><b>Part Two:</b></td><td><b>The Tools</b></td><td><b>85</b></td></tr><tr><td><b>5</b></td><td><b>Object-Oriented Languages</b></td><td><b>87</b></td></tr><tr><td>5.1</td><td>Procedural Languages and Object-Oriented<br/>Enhancements</td><td>87</td></tr><tr><td>5.2</td><td>Major Object-Oriented Languages</td><td>91</td></tr><tr><td>5.3</td><td>The Syntax of the Smalltalk Language</td><td>95</td></tr><tr><td>5.4</td><td>A Language Prospectus and Comparison<br/>References<br/>Exercises</td><td>99<br/>105<br/>107</td></tr></tbody></table>
6

<table><tr><td><strong>Introduction to the ST-80 Environment</strong></td><td><strong>109</strong></td></tr><tr><td>6.1 Environment Concepts</td><td>109</td></tr><tr><td>6.2 Characteristics of the ST-80 Graphics User Interface</td><td>112</td></tr><tr><td>6.3 The Class Library</td><td>116</td></tr><tr><td>6.4 Standard ST-80 Tools</td><td>117</td></tr><tr><td>6.5 Creating Applications Using the Smalltalk Environment</td><td>125</td></tr><tr><td>References</td><td>130</td></tr><tr><td>Exercises</td><td>130</td></tr></table>

7

<table><tr><td><strong>User Interface Design</strong></td><td><strong>133</strong></td></tr><tr><td>7.1 The User Interface</td><td>133</td></tr><tr><td>7.2 Characteristics of Graphics Direct-Manipulation Interfaces</td><td>139</td></tr><tr><td>7.3 Visual Display Methods</td><td>143</td></tr><tr><td>7.4 Backward Compatibility for DisplayObjects: Forms, Pens, and Paths</td><td>148</td></tr><tr><td>7.5 Windows and Views (Release 4)</td><td>154</td></tr><tr><td>7.6 Basic Direct-Manipulation Interface Design Elements</td><td>159</td></tr><tr><td>7.7 Graphically Tailoring the User View</td><td>165</td></tr><tr><td>References</td><td>171</td></tr><tr><td>Exercises</td><td>172</td></tr></table>

8

<table><tr><td><strong>Tools for Building Applications: The Model-View-Controller Paradigm and View Components</strong></td><td><strong>175</strong></td></tr><tr><td>8.1 Model-View-Controller Concepts</td><td>175</td></tr><tr><td>8.2 The View Framework</td><td>181</td></tr><tr><td>8.3 Selection-in-List</td><td>184</td></tr><tr><td>8.4 Buttons and Switches</td><td>186</td></tr><tr><td>8.5 Transcripts and Text Editors</td><td>187</td></tr><tr><td>8.6 Building Menus</td><td>188</td></tr><tr><td>8.7 Using Forms</td><td>190</td></tr><tr><td>8.8 Using Images</td><td>191</td></tr><tr><td>8.9 Building and Using Icons</td><td>192</td></tr><tr><td>8.10 Other View Components</td><td>193</td></tr><tr><td>8.11 Putting the Components Together</td><td>194</td></tr><tr><td>8.12 ViewBuilder</td><td>203</td></tr></table>
<table><tr><td>8.13 Comparison to ST/V Interface</td><td>213</td></tr><tr><td>References</td><td>213</td></tr><tr><td>Exercises</td><td>214</td></tr></table>

## Part Three: Applications in Engineering 217

### 9 Relating Engineering Problems to Object-Oriented Methodologies 219

9.1 Objective 219

9.2 The Nature of Engineering 219

9.3 Evaluation of Common Requirements in Engineering 223

9.4 Engineering and Object-Oriented Problem-Solving Methodologies 226

9.5 Characterizing Problems Using the Model-View-Controller Paradigm 233

9.6 Capitalizing on Abstraction and Reusability 245

9.7 Building Object-Oriented Solutions to Problems 247

9.8 Coupling to Traditional Solutions: Building an Integrated Problem-Solving Environment 248

9.9 Summary 253

References 253

Exercises 254

### 10 Constraint Methods 255

10.1 Basic Constraint Concepts 255

10.2 Using Constraints 257

10.3 Implementing Constraints: An Example for Digital Circuit Simulation (DCS) 260

10.4 Wiring and Testing Example Digital Circuit Simulation 269

10.5 Enhancing the Digital Circuit Simulation System: An Example in Tutoring Systems 273

10.6 A Petri Net Example 276

10.7 General Use of Constraint-Based Techniques References 279

Exercises 281

### 11 Representing and Using Engineering Knowledge 283

11.1 Engineering Knowledge 283

11.2 Representing and Acquiring Knowledge 288
<table><tr><td>11.3</td><td>Frames, Semantic Nets, and Object Representations</td><td>290</td></tr><tr><td>11.4</td><td>Rules, Procedures, and Algorithms</td><td>303</td></tr><tr><td>11.5</td><td>Acquiring Knowledge</td><td>308</td></tr><tr><td>11.6</td><td>Representational Relationships</td><td>309</td></tr><tr><td>11.7</td><td>Identifying the Knowledge Organization Needed for Problem Solving</td><td>310</td></tr><tr><td></td><td>References</td><td>311</td></tr><tr><td></td><td>Exercises</td><td>312</td></tr></table>

<table><tr><td>12</td><td><strong>Integrating Object-Based Environments with the Real World</strong></td><td><strong>315</strong></td></tr><tr><td>12.1</td><td>Concepts</td><td>315</td></tr><tr><td>12.2</td><td>The External Environment</td><td>317</td></tr><tr><td>12.3</td><td>Interfacing Procedures and External Devices to the ST-80 Environment</td><td>323</td></tr><tr><td>12.4</td><td>Applications Using the External Environment</td><td>329</td></tr><tr><td>12.5</td><td>The Wrapper Concept</td><td>338</td></tr><tr><td>12.6</td><td>Object-Oriented Database Management</td><td>341</td></tr><tr><td>12.7</td><td>Summary</td><td>342</td></tr><tr><td></td><td>References</td><td>343</td></tr><tr><td></td><td>Exercises</td><td>343</td></tr></table>

<table><tr><td>13</td><td><strong>Building an Application: Concepts in Rapid Prototyping</strong></td><td><strong>345</strong></td></tr><tr><td>13.1</td><td>Introduction</td><td>345</td></tr><tr><td>13.2</td><td>The Digital Circuit Simulator Problem</td><td>346</td></tr><tr><td>13.3</td><td>Maxims for Rapid Prototyping</td><td>347</td></tr><tr><td>13.4</td><td>The Digital Circuit System: Teleological and Functional Assessment</td><td>350</td></tr><tr><td>13.5</td><td>DCS Architectural Organization</td><td>352</td></tr><tr><td>13.6</td><td>Organizing the Information to Store</td><td>354</td></tr><tr><td>13.7</td><td>Building the View</td><td>359</td></tr><tr><td>13.8</td><td>Interfacing to the Model</td><td>363</td></tr><tr><td>13.9</td><td>Operating the Simulator</td><td>365</td></tr><tr><td>13.10</td><td>The Digital Circuit Simulator Code</td><td>366</td></tr><tr><td>13.11</td><td>Additions to the DCS Application</td><td>377</td></tr><tr><td>13.12</td><td>Summary</td><td>378</td></tr><tr><td></td><td>References</td><td>378</td></tr><tr><td></td><td>Exercises</td><td>379</td></tr></table>
14 Engineering Simulation Methodologies and Simulation Frameworks 381

14.1 Introduction 381

14.2 The Kinds of Simulation 382

14.3 Multiple Independent Processes 391

14.4 Probability Distributions 393

14.5 A Simple Framework for Discrete-Event Simulation 395

14.6 A Discrete-Event-Simulation Framework 396

14.7 Simulation Using Petri Nets 398

14.8 Building an Example Simulation for Manufacturing 400

14.9 Summary 403

References 404

Exercises 406

15 Conclusions 409

15.1 Review 409

15.2 Prognosis for Object-Oriented Methodologies 409

15.3 Object-Oriented Methods in Engineering 410

15.4 The Importance of Environments 411

15.5 Reusability and Productivity 411

15.6 The Reduction of Complexity and Improvement in Rapid Prototyping 412

15.7 Graphics and Visualization 413

15.8 Language and Environment Trends 413

15.9 Near and Long-Term Trends for Object-Oriented Methodologies 414

15.10 Concluding Statement 415

Exercises 415

Appendix 417

Index 419
# Part One
## The Concepts

The first part of the text, *the concepts*, describes basic ways of representing the world with objects. The first chapter gives an overview of the field of object-oriented engineering. Chapter 2 presents basic concepts associated with object-oriented methodologies, including comparison with several other types of representation methodologies. Chapter 3 examines the concept of object-oriented analysis with an emphasis on analytical techniques that will help the reader analyze problems that can be ultimately implemented in Smalltalk-80. The first section concludes with Chapter 4 on object-oriented design using Smalltalk-80.
<figure><img src="image_6.png" /></figure>
# Introduction

## 1.1 Objectives

The world is composed of objects. New objects and classes of objects are created by a process known as design. Existing objects and collections of objects can be understood through a collateral practice known as analysis, in which scientific principles are used to analyze the world. These two processes, *analysis* and *design*, make up most of the field of engineering, which is generally defined to be the application of scientific principles to practical problems. This textbook examines these two fundamental engineering practices in the context of object-oriented methodologies, loosely defined here as consisting of: (1) ways of thinking about and understanding the world as collections of objects and (2) programming methods for actually creating operable abstractions of objects in the world. The combination of these methodologies is defined here as *object-oriented engineering*.

The primary objectives of this text are (1) to create a framework for thinking about object-oriented analysis and design, (2) to describe and explicate tools and methodologies for building abstract program descriptions of objects and collections of objects, and (3) to show how object-oriented systems can be used for engineering problem solving.

## 1.2 Object-Oriented Analysis and Design

Consider Figure 1.1 in which the nature of engineering is schematically depicted. Different types of engineering practitioners are listed in the upper left part of the figure, including designers, analysts, and simulation-ori-
<figure><img src="image_7.png" /><figcaption>**Figure 1.1 The Nature of Engineering.**</figcaption></figure>

Engineers. Engineers typically utilize different approaches for problem solving; the methodologies used are actually most often composites of these stereotypic labels. Indeed, a typical problem-solving sequence may well consist of (1) analyzing a problem, (2) designing a new object, and (3) simulating the object using a computer. Engineering systems, as shown in the center of Figure 1.1, consist of a mixture of many problem-solving techniques which include those just discussed, as well as other more abstract approaches such as the use of analogy. The result of engineering activities, as portrayed in the rightmost box in Figure 1.1, consists of two main outcomes: (1) products and (2) solutions to problems. Analysis of problems and creation of new products revolve around the domain selected, that is, the environment that contains measurable variables, causal relationships between objects, constraints between entities, and physical laws that govern the behavior of objects. The complexities of describing the world mandate simple and descriptive mechanisms. This book will make the case that object-oriented techniques fill this need.

Next, consider Figure 1.2. This figure shows a framework for organization of a computer-based engineering problem-solving system. General-purpose problem-solving systems do not actually exist today because of the scope and difficulty of organizing knowledge about engineering. Discussion of this general problem-solving system is included here to indicate how such systems could be built to facilitate specific tests in engineering analysis and design and to serve as
<figure><img src="image_8.png" /><figcaption>**Figure 1.2** A Framework for a Problem-Solving System for Engineering.</figcaption></figure>

a model for example systems described in later chapters. Furthermore, systems having this general framework can be constructed using the object-based technology discussed throughout this textbook. In the same way as in Figure 1.1, problems enter on the left side of the figure and solutions exit on the right. The problem-solving system is shown with four layers: (1) a graphics user interface (GUI) on the top layer, (2) a set of problem-solving paradigms (heuristic and algorithmic), (3) computer tools, and (4) computer hardware support. These facilities are arranged hierarchically to indicate how each lower layer supports the next higher layer. Shown also in the diagram is a knowledge source (e.g., a collection of information composed of data, methodologies, and algorithms) that is separated from the problem-solving system. The knowledge source is basically a knowledge-based management system that includes knowledge about a domain of interest as well as data. Knowledge types include knowledge about how to solve problems, as well as knowledge about the world and how things work.

The organization of the problem-solving system in layers is a typical methodology used to break down a system into smaller, less complex parts. A
graphics direct-manipulation interface (GDMI; see Chapter 7) provides facili-
ties for interfacing the user to the system. Typical GDMIs employ a "point-
and-click" metaphor in which the user employs a mouse or similar pointing
device to operate the system. Often consisting of multiple overlapping windows,
lists from a user can select items, or buttons that a user can press. GDMIs are a
distinctly different interface from common "command line" interfaces in which
users type in specific commands to cause computer operations to happen. The
"Problem-Solving Paradigms" layer in the example in Figure 1.2 consists of
various mechanisms for utilizing and accessing the tool layer. For example,
problem-solving methodologies should be contained in layer 2, including tech-
niques for organizing, inspecting, and understanding knowledge, as well as
interfaces to specific tools that might be part of the system. The third layer from
the top is basically a tool kit that provides the user with extended capabilities
for problem solving. For example, tools in a tool kit might include inference
systems (e.g., rule-based systems), interfaces to computer-aided-design (CAD)
tools, analysis tools, simulation tools, and tutorial and information understand-
ing assistants. Finally, at the lowest level of this example system is computer
support, which consists of both hardware and software support. To be most
useful, software should be runnable on and transportable across many types of
hardware and basic software support should provide the same capabilities on
hardware manufactured by different vendors.

The general-purpose problem-solving system described previously mir-
rors the problem-solving capabilities of engineers who conduct analysis and
design. It is alleged that the cognitive skills that engineers use can be made
explicit rather than implicit. As problem solvers, engineers can call on a wide
range of inspection and manipulation tools (graphs, lists, references), different
problem-solving methods, tools of various sorts, and computer support. These
typical elements in the engineer's tool kit are reflected in the layers shown in
this hypothetical system. This text offers a look at many of the elements that can
be used in building problem-solving systems that may ultimately become avail-
able for use in analysis and design tasks in engineering.

1.3 Object-Oriented Methodologies for Engineering

Object-oriented programming is a methodology that permits descrip-
tion of objects, including functional, behavioral, and declarative information.
Function refers to what an object is designed to do, behavior refers to what it
actually does, and declarative information consists of information about an
object's state. For example, the function of a car is to move, to turn, to transport
people, and so on. The behavior of a car implements function; computer
descriptions of behavior are often turned into simulations that can be used to
assist designers in observing changes in behavior as design specifications are varied. Declarative information simply provides a specification of the attributes of an object; for example, a car might have four doors, four wheels, and so on. The object-oriented paradigm provides a programming framework that can assist in such descriptions. Although there is some controversy about what makes a programming language or methodology object oriented, a typical definition is that an object: (1) has local state, (2) inherits characteristics from more abstract objects, and (3) responds to messages, decoding the meaning of messages in the object's local context. Such characteristics make objects very useful for describing how things work in the real world and ideal for use in problem-solving systems that facilitate the work of engineers.

Next, as an introduction to what one can do with object-oriented methods, four examples are examined that typify the use of object-based systems in engineering practice. The systems shown could be created in traditional programming environments; however, they fit more naturally to object-based methods due to the strong coupling of the paradigm to the real world. In each of the examples, this coupling will be discussed in an attempt to show the strength of object-oriented methods for use in engineering. The examples cover a range of applications: (1) a computer-aided-design (CAD) tool for electronics, (2) a signal analysis system, (3) an interface to instrumentation, and (4) an example of an object-oriented traffic simulator. These examples emphasize interactive graphics user interfaces which are easily built using the object-based methodologies described in this text.

### 1.3.1 Computer-Aided Design

New things used to be designed by hand. Engineers would work from requirements to generate designs which would be laboriously committed to detailed paper specifications and drawings, from which an actual new object could be fabricated. During recent decades this "design-by-hand" methodology has been gradually replaced with computer-aided design (CAD), in which computers assist engineers in (1) creating specifications for a new design and (2) testing a design using computer-based simulation. The advantages of the methodology lie chiefly in the ability to prototype designs rapidly, make changes quickly, and observe the effects of engineering decisions on the final product.

As an example, consider a simple CAD tool for design of electronic systems. The objective of designing an electronic system based on digital circuits could be to construct a new digital device or class of digital devices such as digital telephones, computers, or perhaps even microwave oven controllers. Decisions must be made about which electronic parts to use, how much the parts cost and their availability, and how the parts will work when connected. A
<figure><img src="image_9.png" /><figcaption>**Figure 1.3** A Computer-Aided-Design Tool for Digital Electronics.</figcaption></figure>

CAD tool will permit a design engineer to design a circuit, build a simulation of the circuit on the screen, and evaluate how the design will work prior to ever building an actual circuit. During design, the engineer may try different alternative circuit designs to attempt to achieve the same functionality with a reduced number of chips, for example. The capability for rapidly doing “what-ifs” (“what if I change this or that…”) coupled with the ability to simulate the resulting design makes CAD a powerful tool for designing most things. Perhaps the most powerful feature is simulation, because simulation helps the designer to understand how the designed system will work without actually having to build the system.

Figure 1.3 shows an example of how a computer screen might look for a CAD tool constructed for digital electronic design. The screen has a number of features: (1) at the top are several buttons that the user can press by moving a cursor inside a button and pressing a key on the mouse to activate the command on the button label. On the left side of the view are buttons which, when
activated, attach an icon<fnref n="1" /> to the cursor and permit the user to place the icon on the graphics drawing pad in the center of the screen. By simply pointing and clicking, the designer can build a digital circuit by selecting components and wiring them together. Once wiring is completed, signals can be introduced at inputs in the simulated system and the behavior of the system can be observed. In this example, a signal could be added to an input wire using "Set Signal." Automatically, the signal would propagate throughout the circuit. If a signal appeared at the output, the bulb shown would change from empty to filled to show that a signal had appeared at the output wire. Using this methodology, the designer could probe different points in the system to determine if the conceptual design and simulated implementation were correct prior to making a commitment to implementation in hardware.

Of course, industrial-strength CAD systems are tremendously more complex than the example just described [see, e.g., van der Meulen (1989)]. Most commercial systems have the capability of creating and simulating very complex systems and providing detailed analyses of problems in the design. However, the simple system shown in Figure 1.3 could be extended to handle more complex circuits and systems.

### 1.3.2 Signal Analysis

The term *analysis* may be applied to many things about which an understanding is sought. In engineering, one may wish to understand the nature of a physical system such as the stresses on a bridge or the meaning of signals secured from strain gauges measuring stresses in an earthquake fault zone. Signal analysis is a popular engineering activity in which signals obtained from many different kinds of physical processes are evaluated to secure information. Examples range from geological evaluation to analysis of biological signals.

In much the same spirit as the design example given previously, consider the view of a computer screen given in Figure 1.4 which shows a signal analysis system based on the same "point-and-click" methodology discussed previously. This example system permits sampling of external analog signals, displaying of signals, and viewing of fast Fourier transforms (FFT; Blahut, 1985) in a separate window. This set of activities is typical of many simple signal analysis systems in which the FFT is used to reveal a plot of the amplitude of the signal activity with respect to the frequency. The time-domain signal shown at the bottom of the figure and the frequency-domain signal at the top of the figure represent the same data from these two different perspectives. The

<footnote n="1">¹An icon is a graphic representation of an object.</footnote>
<figure><img src="image_10.png" /><figcaption>**Figure 1.4** A Signal Analysis System User View.</figcaption></figure>

capabilities of the example system, as reflected in the buttons to the left of the view include starting and stopping sampling of a signal, saving and loading files, filtering, compressing and expanding the signal, and finally producing an FFT. Arrows shown in the margins of the graphics views of the signals permit scrolling of the information up and down or left and right.

To clarify the use of an analysis system of the type shown in Figure 1.4, consider the task of a highway engineer who is attempting to determine if noise has been reduced sufficiently by noise barriers. The engineer would visit a highway site with a portable computer equipped with a microphone, sampling equipment, and the analysis system described previously. Placing a microphone at various locations in the environment, the engineer could use our example system to acquire noise data. By pressing "FFT," the engineer could then evaluate the range of frequencies that are present (e.g., the presence of low-frequency rumbling could be easily detected by examining the FFT plot in low-frequency ranges). Using this information, decisions about modifications to the site could be made.

### 1.3.3 Instrumentation Interface

Many engineers conduct experiments in the real world; that is, they interface measurement and control instruments to experiments or control
<figure><img src="image_11.png" /><figcaption>Figure 1.5 Control Panel for IEEE-488 Bus Instruments.</figcaption></figure>

systems. In experimental laboratory situations, numerous instruments of various types are used to measure information from an experimental preparation. For example, oscilloscopes can secure electrical information, flow meters measure information about the flow of gases and liquids, and temperature gauges provide information about heat and cold. Often it is useful for engineers to employ collections of interconnected instruments that can be used in experimental laboratories. One popular interface to the world through instruments is the IEEE-488 bus [see, e.g., Gates (1989)], also known as the GPIB (general-purpose interface bus). Following the same paradigm as shown previously for design and analysis, object-oriented systems can be designed to facilitate the use of instruments in experimentation and control.

Consider Figure 1.5 in which a view of a control panel for an IEEE-488 instrumentation controller is shown. In this example, one could construct a laboratory containing different types of instruments that might need to be connected at various times to conduct different experiments. Each instrument would have a unique address (as shown here, A:02, A:03... are different addresses). The type of graphics interface shown would permit the users to "wire up" an instrument system by simply "pointing and clicking" to connect instruments on the screen. IEEE-488 bus technology provides the capability of making electrical connections, so that a complete custom instru-
mentation system could be rapidly constructed without the need to physically
wire any instruments together. The panel on the right of the figure shows
common operations such as "add an instrument" or "delete an instrument"
from the configuration. The graph shown in the figure consists of nodes which
are replaced with icons (e.g., the printer icon) when the type of instrument
desired by the experimenter is selected.

The strength of object-oriented methodologies in the instrumentation
example lies in the ability to encapsulate the behavior of instruments in objects
and in the capability of graphically representing collections of instruments wired
together in networks in an easily understandable way. Object-oriented lan-
guages provide excellent support for the building of the graphics interfaces that
connect the user with the application.

### 1.3.4 Object-Oriented Simulation

The final example in this introductory material is concerned with using
object-oriented methods for building simulation systems. Consider Figure 1.6
which shows a simulation of traffic at a traffic light. The view that the user sees
is shown with connections to the computer objects that simulate the behavior of
the objects displayed. In the simulation, each object described has its own
individual behavior (e.g., the car objects). In the view, the user can observe the
behavior of the cars operating in the constrained simulated environment around
the traffic light. Object-oriented methodologies are particularly good for simu-
lating these types of situations which include many different cases in which
objects give and receive service. Other examples, including management of
aircraft, manufacturing flow of material, personnel flow, decision making, hydro-
logical systems, customers in a bank, cars in a car wash, and so on, operate using
the same principles.

## 1.4 Tool Support for Practicing Object-Oriented Engineering

Table 1.1 displays introductory information about tool support for
practicing object-oriented engineering. The first part of the table shows environ-
ments and languages that are commonly employed, and the second part of the
table displays some of the myriad of tools that are currently commercially
available.

The language and environment with the longest history is Smalltalk-80,
originally developed at Xerox in the 1970s. Smalltalk/V, a similar system for
<figure><img src="image_12.png" /><figcaption>**Figure 1.6** A Traffic Flow Simulation.</figcaption></figure>

PCs and Macintoshes, is also shown along with C++, a Bell Laboratories-originated language, and Objective-C, a C-language-based language and environment with a Smalltalk-like flavor. These languages and environments will be described in detail in Chapter 5.

An environment is similar to an operating system in that an environment provides the user with tools in which to program applications. Although the term *operating system* is used to refer to the software that interfaces with the computer to manage the computer's resources for the benefit of users, *environment* is a term that has a higher-level meaning; in general, it describes the capabilities of the collection of tools that are available to service the needs of the user. Systems with the most useful and most user-friendly set of tools can permit users to achieve the highest levels of productivity. Due to the case of constructing tools using object-oriented methods, systems such as Smalltalk-80 have evolved over the years to have very high levels of environmental conven-
<table><caption>**Table 1.1** Examples of Commercial Environments, Languages, and Tools
Based on Object-Oriented Methods</caption><thead><tr><th colspan="3">Examples of Environments and Object-Oriented Languages</th></tr><tr><th>Language System</th><th>Function</th><th>Source/Vendor</th></tr></thead><tbody><tr><td>Smalltalk-80</td><td>Object-oriented environment and language; many hardware platforms</td><td>ParcPlace Systems</td></tr><tr><td>Smalltalk/V</td><td>Object-oriented environment and language; PC and Macintosh platforms</td><td>Digitalk</td></tr><tr><td>C++</td><td>C-based object-oriented language</td><td>AT&T and others</td></tr><tr><td>Objective-C</td><td>C-based object-oriented language</td><td>Stepstone</td></tr><tr><td>Common Lisp Object System (CLOS)</td><td>Object-oriented language built on Lisp</td><td>Xerox</td></tr><tr><td colspan="3"><strong>Example Tools</strong></td></tr><tr><td>Humble</td><td>Inference engine</td><td>Xerox Special Information Systems</td></tr><tr><td>Analyst</td><td>Integrated office environment</td><td>Xerox Special Information Systems</td></tr><tr><td>Draw-80</td><td>Drawing package</td><td>Knowledge Systems Corporation</td></tr><tr><td>Pluggable Gauges</td><td>Gauges for Smalltalk</td><td>Knowledge Systems Corporation</td></tr><tr><td>GemStone</td><td>Object-oriented database management system</td><td>Servio</td></tr><tr><td>PERT</td><td>Business tools</td><td>Fuji Xerox</td></tr><tr><td>Petri net</td><td>CASE tools</td><td>Fuji Xerox</td></tr></tbody></table>

nience that permit users to construct systems for new applications in a minimal amount of time.

The second part of Table 1.1 shows a number of different tools that have been produced commercially for use in object-oriented systems. The intention here is not to be exhaustive in listing different tools, but to show the range and type of some common tools that are available.

## 1.5 Recommended Concurrent Reading

Table 1.2 lists a few textbooks and manuals that will assist the reader of this text in securing additional background information and ancillary knowl-
<table><caption>**Table 1.2** Selected Concurrent Readings*</caption><thead><tr><td>Title</td><td>Author</td></tr></thead><tbody><tr><td>Inside Smalltalk</td><td>Pugh and LaLonde</td></tr><tr><td>Smalltalk-80: The Interactive Programming Environment</td><td>Goldberg</td></tr><tr><td>Smalltalk-80: The Language and Its Implementation</td><td>Goldberg and Robson</td></tr><tr><td>The C++ Programming Language</td><td>Stroustrup</td></tr><tr><td>Object-Oriented Programming — An Evolutionary Approach</td><td>Cox</td></tr><tr><td>An Introduction to Object-Oriented Programming and Smalltalk</td><td>Pinson and Wiener</td></tr><tr><td>Object-Oriented Analysis</td><td>Coad and Yourdon</td></tr><tr><td>Object-Oriented Design with Applications</td><td>Booch</td></tr><tr><td>Journal of Object-Oriented Programming</td><td>Wiener (Editor)</td></tr><tr><td>Objectworks \ Smalltalk User's Guide (Release 4)</td><td>ParcPlace Systems</td></tr><tr><td>Objectworks \ Smalltalk Tutorial (Release 4)</td><td>ParcPlace Systems</td></tr></tbody></table>

edge. Six books and manuals on Smalltalk are shown, as well as one book on C++, one book on Objective-C, and other texts concerned with general object-oriented analysis and design methodologies. These texts will assist a serious student of object-oriented methodologies in securing viewpoints other than those given in this text. Also, later chapters in this text occasionally make reference to materials given in some of the texts listed in Table 1.2. Extensive information and examples concerned with the Smalltalk-80 environment and language are given throughout this textbook. Although an introduction to both the environment and language will be given, detailed descriptions will not be undertaken because there are excellent reference materials available that can be used in conjunction with this text. The *Objectworks \ Smalltalk User's Guide* and *Objectworks \ Smalltalk Tutorial* (1990) are recommended concurrent reading for students and others wanting to learn the details of this language and environment.

## 1.6 Overview of Chapters

This textbook is organized into three main parts: (1) the concepts, given in Chapters 1 through 4; (2) the tools, described in Chapters 5 through 8; and (3) the applications in engineering, given in Chapters 9 through 14. Chapter 15 provides a set of conclusions and a look at the future.

In the first part of the text, *the concepts*, basic ways of representing the world with objects are given, with an examination of methods for conducting

<footnote>*See the references for complete citations.</footnote>
object-oriented analysis. Object-oriented design as an extension of object-oriented analysis is described along with an introduction to the methodologies for designing object-based applications.

The second part of the text, the tools, deals first with general object-oriented languages, second with a review of the characteristics of Smalltalk-80 graphics user interface design, and finally the tools for building applications in Smalltalk-80. This latter section takes a detailed look at the model-view-controller paradigm of Smalltalk-80 and shows how the paradigm can be used in building engineering applications.

The last part of the text deals with engineering applications. First, the general nature of the engineering methodology is examined and compared to the object-centered approach. Constraint methods, techniques for acquiring, modeling, and presenting knowledge, are given, as well as a description of interfacing object systems to the real world. Finally, a chapter on constructing object-oriented simulation systems is provided.

## References

Blahut, Richard E. (1985). *Fast Algorithms for Digital Signal Processing*. Addison-Wesley, Reading, MA.

Bobrow, D. G. et al. (1987). *Common Lisp Object System Specification*. ANSI Report 87-001, September.

Booch, Grady, (1991). *Object-Oriented Design with Applications*. Benjamin/Cummings, Redwood City, CA.

Coad, P., and E. Yourdon (1990). *Object-Oriented Analysis*. Prentice-Hall, Englewood Cliffs, NJ.

Cox, B. J. (1986). *Object Oriented Programming-An Evolutionary Approach*. Addison-Wesley, Reading, MA.

Gates, S. C. (1989). *Laboratory Automation Using the IBM PC*. Prentice-Hall, Englewood Cliffs, NJ.

Goldberg, Adele (1983). *Smalltalk-80: The Interactive Programming Environment*. Addison-Wesley, Menlo Park, CA.

Goldberg, Adele, and David Robson (1983). *Smalltalk-80: The Language and Its Implementation*. Addison-Wesley, Menlo Park, CA.

Journal of Object-Oriented Programming, P.O. Box 6338, 733 Woodland West Drive, Woodland Park, CO 80866.

Meyer, Bertrand (1988). *Object-Oriented Software Construction*. Prentice-Hall, Englewood Cliffs, NJ.

*Objectworks\Smalltalk User's Guide and Objectworks\Smalltalk Tutorial*, Release 4 (1990). ParcPlace Systems, Mountain View, CA.
Pinson, Lewis J., and Richard S. Wiener (1988). *An Introduction to Object-Oriented Programming and Smalltalk*. Addison-Wesley, Reading, MA.

Pugh, John R., and W. R. LaLonde (1990). *Inside Smalltalk, Volumes 1 and 2*. Prentice-Hall, Englewood Cliffs, NJ.

*Smalltalk/V*. Digitalk, Inc., 9841 Airport Blvd., Los Angeles, CA 90045.

Stroustrup, B. (1986). *The C++ Programming Language*. Addison-Wesley, Reading, MA.

van der Meulen, Pieter S. (1989). Development of an Interactive Simulator in Smalltalk. *Journal of Object-Oriented Programming*, Vol. 1, No. 5, January/February, 28-51.

Exercises

1.1 Secure recent promotional literature for Smalltalk-80 and Smalltalk/V. Familiarize yourself with the characteristics of the two systems and compare and contrast the two systems based on the information you obtain.

1.2 Conduct the same investigation as described in Exercise 1.1 for C++ and Objective-C.

1.3 Visit the library and review information in the concurrent readings listed in Table 1.2. Prepare a short prospectus about the contents of each of the references that you find. Look for other references in this same topic area and prepare a brief abstract of your findings.

1.4 Smalltalk-80 is delivered with an on-line tutorial and tutorial text. If you are reading this book to gain an in-depth understanding of Smalltalk and to learn how to build applications using Smalltalk, you should begin to study the ParcPlace tutorial and to work through the accompanying on-line tutorial.

1.5 List the reasons given in this chapter that object-oriented methodologies are useful for building engineering applications.
<figure><img src="image_13.png" /></figure>
# Representing the World with Objects

## 2.1 Introduction

The world is composed of objects, both animate and inanimate. We easily understand objects in nature, such as trees and rocks, that have well-known characteristics and synthetic objects, such as measuring instruments, automobiles, water heaters, and a host of other engineered artifacts. Less well understood are objects that represent abstractions, such as time, mental relationships, or even complex engineered systems composed of many interacting objects. In this chapter, we will examine the basic paradigms that are useful for representing different types of objects. Illustrations given include physical objects that have structural and behavioral characteristics and complex sets of objects that are examples of engineering systems that can be described with object-oriented techniques.

To describe an object or objects in object-oriented programming languages, four general terms are frequently employed: encapsulation, abstraction, inheritance, and polymorphism. Encapsulation refers to the hiding of the implementation of an object from the outside world. By hiding the internal structure of an object, understanding the behavior of an object is reduced to understanding the messages used to communicate with the object. Abstraction deals with separating the inherent qualities or properties of an object from an actual physical object to which they belong. For example, an abstract object might represent all automobiles with their accompanying variables and behaviors, such as the number of wheels or general information about computing automobile speed and direction. More specific objects might be specific brands of automobiles such as Toyota or Mercedes, for example. Inheritance permits more specific objects to inherit the specifications and behaviors of more abstract
objects. For the car example, a Mercedes could inherit all the behaviors and specifications that are common to all automobiles. Finally, polymorphism refers to the ability of different objects to respond in an appropriate manner to the same message. For example, the message "drive" sent to objects such as automobiles, bicycles, or ships in a vehicle simulation should cause these objects to respond in somewhat different but appropriate ways.

Consider Figure 2.1. Shown at the top of the figure is a template for describing classes and objects. The term *class* refers to a description of one or more similar objects and the term *instance* is used to designate specific objects that are members of the class. For example, a class *Car*<fnref n="1" /> would contain a description of cars in general. Objects representing specific cars would then be instances of the class *Car*. The term *instantiation* refers to the process of creating a new object that is a specific instance of a class. The template shown in Figure 2.1 is basically a structure that provides an organization for naming a class and indicating if the class inherits information from other classes. Also, the template provides places to describe the internal parts of the class: class variables, instance variables, and methods. Class variables are variables that are associated with an entire class, including all instances of the class. Instance variables are variables that contain new values for each instantiation of a class. The term *method*<fnref n="2" /> refers to the code inside an object that responds to a message sent to an object. A collection of methods defines the internal behavior of an object. Sending a *message* to an object causes a method to be selected and the code within the method to be executed. Messages provide the only interface between an object and the outside world.

As a concrete example, consider a class called **Toyota**. The class **Toyota** describes Toyotas in general. A class description can be built from the template discussed previously; as shown in the figure, class **Toyota** inherits from class **Car** and has several class variables and methods. Instances of the **Toyota** class would be specific Toyotas—samsToyota or amysToyota, for example. When one instantiates a class, a new specific instance of that class is created. The bottom of the figure shows how a class and several example instances are created from the template. The basic template is filled in to create both class and instance descriptions. A description of class **Toyota** is shown labeled as "Class Description Example." The **Toyota** class inherits information from the class **Car**, meaning that variables associated with class **Car** and the methods that define the behavior of **Car** are inherited by **Toyota**. In class **Toyota**, the number of wheels (i.e., 4) and other variables can be set and will appear in all instances of the class. Shown below this class example are three examples of instances of

<footnote n="1">¹As a convention, the names of classes will be printed in bold throughout the text.</footnote>

<footnote n="2">²Method names embedded in the text will be shown in italics.</footnote>
<figure><img src="image_14.png" /><figcaption>**Figure 2.1** Creating Objects: Class and Instance Variables. A basic template is shown at the top. An example class and three instance examples are shown at the bottom of the figure.</figcaption></figure>
<figure><img src="image_15.png" /><figcaption>**Figure 2.2 Describing the World with Instances of Objects.** (P = instances of parking lots, B = buildings, A = automobiles, Sn = street number.)</figcaption></figure>

class **Toyota**: samsToyota, amysToyota, and tonysToyota,<fnref n="3" /> all individual Toyota automobiles with different owners and models. To sum up, a class description permits describing information that is common to all instances, and the instance description permits describing individual objects that are specific instantiations of a class.

To describe the world using object-oriented methods, one can imagine defining all objects in the domain in which one is working according to the characteristics given previously. As an example, consider Figure 2.2 which shows how one might go about simulating a city block by defining objects. Such a simulation might be used for traffic planning or zoning problems. There are two layers in this diagram: On the bottom is a schematic visualization of a city block that includes parking lots, vehicles, streets, and building objects. Of course, there might be many more objects in this representation; these are simply illustrative. The top layer shows the different classes that are used to represent objects in this cityBlockWorld. The links between the class and instances of the class in the city block model are shown. This representation of a mental

<footnote n="3">³The convention for naming objects in this text will be to use descriptive names or to concatenate several words together with each concatenated word capitalized. Class names will start with a capital letter and names of instances will be uncapitalized.</footnote>
organization of classes to support a problem organization is common in object-oriented problem solving. In this example, once the basic functionality of cityBlockWorld is determined, more objects with additional and realistic behaviors can be added providing, for example, the ability to study the influence of adding traffic lights or pedestrian walkways.

## 2.2 Defining Characteristics of Object-Oriented Methods

This section describes in more detail the characteristics of object-oriented methodologies. The terms employed are commonly used in describing methodologies in Smalltalk-80, yet are general enough to understand without first learning the syntax of Smalltalk-80. The various object-oriented languages and environments in existence differ in various ways in terminology, although the basic concepts are virtually identical. The Smalltalk-80 terminology used here is widely accepted, descriptive, easily understood, and will be used throughout the text.

### Object Definition

One dictionary definition of an object is: "Anything perceptible by one or more of the senses, especially something that can be seen and felt; a material thing" (Morris, 1981). This definition is a familiar commonsense meaning; however, in the object-oriented programming world, objects also can represent abstractions of material things or even abstract concepts.

Figure 2.3 displays the anatomy of an object. Contained within an object are variables and methods. Variables are of two types: class and instance

<figure><img src="image_16.png" /><figcaption>Figure 2.3 The Anatomy of an Object.</figcaption></figure>
variables. Class variables are variables that are common to all instances of a class; instance variables may be different for each instance of a class. For example, as described previously, one might have defined a class called **Toyota** and several instances of this class—*myToyota*, *yourToyota*, and so on. Values of class variables would be shared among all the instances (e.g., wheels = 4), whereas values of instance variables could be different for each instance of **Toyota** (*color* = blue, *color* = red, etc. would be examples).

*Messages* are sent to objects to elicit different behaviors. Sending messages to objects is the only way to communicate with objects. Sending a specific message to an object triggers execution of the code for a *method* that has the same name as the message sent to the object. A typical object may contain many different methods that have been created by instantiating a specific class. Methods may reside in either the specific class or in class descriptions that are inherited by the instantiated class. Methods may also be grouped for understandability according to functionality into units called *proto-cols*. A protocol is merely a label that identifies a group of methods that perform related kinds of operations, for example, accessing, initializing, activating, terminating, and so forth. The use of protocols is primarily for assisting users in understanding the behavior of objects.

**Object Attribute Implementation**

Table 2.1 shows the basic terms associated with the characteristics of object-oriented programming. Each term will be described in detail next.

**Abstraction**

Abstraction is defined as: "The act or process of separating the inherent qualities or properties of something from the actual physical object or

<table><caption>**Table 2.1 Basic Object-Oriented Characteristics**</caption><tr><td><strong>Abstraction:</strong></td><td>Separating the inherent qualities or properties of an object from an actual physical object to which they belong.</td></tr><tr><td><strong>Encapsulation:</strong></td><td>The hiding of the implementation of an object from the outside world.</td></tr><tr><td><strong>Inheritance:</strong></td><td>The ability of a class to use local state (variables) and behaviors (methods) from more abstract classes.</td></tr><tr><td><strong>Polymorphism:</strong></td><td>The capability for many different objects to respond to the same message.</td></tr></table>
concept to which they belong" (Morris, 1981). The concrete manifestation of this definition in the object-oriented programming methodology is the collection of as many as possible inherent qualities or properties into abstract classes which can then be specialized by less abstract classes that inherit the characteristics of the abstract classes (see the following discussion on inheritance). Thus, rather than write descriptions for each specific type of automobile that exists, one attempts to create an abstraction of an automobile that contains all the qualities and properties that all automobiles have. Once this abstract class is described, each type of automobile can be described by specifying only changes or additions to the abstract class (this process is known as specialization).

There is often some confusion about the difference between abstraction and generalization. Generalization is defined as: "To reduce to a general form, class, or law" (Morris, 1981). Hence, generalization is law related, seeking principles that describe classes of things. In contrast, abstraction looks for concrete ways of amalgamating characteristics of class that are *common* to more specialized classes. Object-oriented programming methodologies use abstraction as a standard technique, not generalization.

In creating classes for representing things, a programmer should consider the following methodology. First, look for the most abstract characteristics of the object that is to be represented. For example, consider the following simple representation hierarchy:

<figure><img src="image_17.png" /></figure>

Starting from the bottom, the task is to represent a specific Boeing 767 aircraft. A specific object is called an *instance*. The specific Boeing 767 is an instance of a class called **Boeing767** from which many instances of the aircraft can be fabricated. Note that the **Boeing767** class inherits information from **Airplane**, which, in turn, inherits information from **MovingObject**. The utility of this methodology lies chiefly in the strong capability of reducing the amount of information that must be repeated in describing new things. The characteristics of all moving objects can be inherited not only by airplanes but by automobiles,
animals, astronomical objects, ships, and so forth. Likewise, the characteristics of all airplanes can be inherited by all different types of aircraft that are represented.

## Encapsulation

Encapsulation refers to capturing the state and behavior of an object entirely within the object. As indicated previously, object may contain several different types of variables: class variables, instance variables, and even local variables, which are known only to the methods within which they are defined. All of these variables are encapsulated within the object and define the state of the object. In addition, the behavior of an object is encapsulated within the object as a collection of methods that define how an object will behave when messages are sent to it.

## Inheritance

Inheritance is the ability of objects to obtain information about their internal states and methods from more abstract ancestors. Consider the example given in Figure 2.4 in which examples of objects such as ships, wheeled vehicles, and planes inherit information from the abstract class **MovingObject**. As shown, **MovingObject** is the superclass of **Ship**, **WheeledVehicle**, and **Plane** and, as such, should contain all variables and methods that would be associated with ships, vehicles, and planes. Superclass is a term that refers to the next most abstract object in the ancestral hierarchy. Conversely, subclass is a term that refers to the class that inherits from the more abstract class. **MovingObject** might contain variables concerned with direction, speed, and weight and methods that contain code for computing speed, direction, and so on. These variables and methods would be equally applicable for any subclasses constructed using **MovingObject** as a superclass. **WheeledVehicle** is also an abstract class in that it serves as a superclass for all types of vehicles that have wheels. **Car** would inherit all information from its superclass and, perhaps, add variables such as 'wheels' or 'turnSignalType.' Note the additional two abstract classes: **Power-WheeledVehicle** and **UnpoweredVehicle**. The continual breaking down of the classification hierarchy in this way permits a quite specific way of defining an object taxonomy (i.e., a classification) of the world.

The major point to be made in this discussion is that inheritance permits specific objects to be created by using a hierarchy of classes. This technique enables designers to select classes that are already built and to specialize these classes to instantiate objects that are needed for a design.
<figure><img src="image_18.png" /><figcaption>**Figure 2.4** Hierarchical Class Description. Dotted lines indicate multiple inheritance.</figcaption></figure>

Hence, two advantages are readily apparent: (1) reducing the amount of code by sharing code in abstraction hierarchies and (2) simplifying the creation of new objects by specializing classes.

Inheritance may be strictly hierarchical or tangled, as shown in Figure 2.4. Tangled hierarchies, also known as multiple inheritance hierarchies, permit inheritance of information from multiple ancestors. Figure 2.4 is primarily a hierarchical representation; however, consider the portion of the inheritance lattice at the bottom left of the figure. A composite class called *MercedesTruck* is shown that inherits characteristics from both *Car* and *Truck*. This definition would make sense in cases, for example, in which a truck may have been created using engines or other parts from the Mercedes automobile line.

## Polymorphism

Polymorphism, in general, refers to having many parts or forms. In object-oriented programming, polymorphism is the capability for different objects to respond to the same meaning of a message. Figure 2.5 gives an example of polymorphism. Four objects are shown in this example: (1) aValve,
<figure><img src="image_19.png" /><figcaption>**Figure 2.5 An Example of Polymorphism.**</figcaption></figure>

(2) `aSteamBoat`, (3) an integer number, and (4) a floating-point number. The same message is sent to each object:

anObject adjust: half

where *anObject* is the object, *adjust*: is the message sent to the object that activates the method *adjust*, and *half* is the argument (itself an object!) passed along with the message to the method. In Smalltalk-80, the colon after the message name indicates that there should be an argument following the message name. The message *adjust*: has a different implementation for each of the four objects. The valve should be turned to half-open, the steamboat's speed might be adjusted to half of full speed, and each of the two different kinds of numbers would be halved, each according to the type of number it is.

The point to this discussion is that defining polymorphic behavior of objects permits a more natural way of understanding the behavior of objects. In the preceding example, the message *half* results in different behaviors in each of the examples, even though the same message name is sent to each object. Rather than having to define different messages for each object such as *halfSpeed* or *halfTurn*, the capability of using the same message name simplifies the understanding of the behavior of the objects. Without this capability, individualized message names could proliferate, thus increasing the number and complexity of messages that need to be understood.

## 2.3 Representing Objects

There are many perspectives on representing objects in the world. Some objects may require only representation of structure, whereas others may
require representing both structure and behavior. A rock or picture could be examples in which the behavior of the object is incidental to its structure. Many objects require both structural and behavioral specifications, such as an automobile or television, for example. Still other viewpoints might stress *function*, that is, what the object is supposed to do, *teleology*, the design intent for the object, or *causality*, what other objects an object may influence. Representing the structural and behavioral characteristics of objects is discussed next.

## The Structural Representation of Objects

To analyze problems and design new material objects using computer-assisted systems, a key problem is the representation of objects in the world and in the computer environment. Many different styles of representation methodologies are used. The most common representational structure found in actual programs is often ad hoc, that is, most systems are constructed using no formal representation structure other than programming language constructs such as constants, procedures, queues, structures, and so forth. The problem with using standard language features for description of knowledge is that frequently more robust representation mechanisms are needed. Consider a part of Figure 2.4 described in textual form as shown in Table 2.2. This textual representation of an object hierarchy is clearly more difficult to read and understand than the graphical form of the hierarchy. Once the hierarchy grows beyond only a few elements, graphic representations are essential to understanding the relationships in the hierarchy. Various kinds of textual representation mechanisms have evolved in different programming languages; perhaps the most active field conducting research on representation mechanisms is artificial intelligence.

Research in the field of artificial intelligence (AI) during the last two decades has looked intensely at the representation problem, finding that rules

<table><caption>**Table 2.2** Textual Form of a Representation Hierarchy</caption><tr><td>(Object</td></tr><tr><td>(MovingObject</td></tr><tr><td>(Ship</td></tr><tr><td>(Battleship)</td></tr><tr><td>(Sailboat))</td></tr><tr><td>(WheeledVehicle)</td></tr><tr><td>(PoweredWheeledVehicle</td></tr><tr><td>(Truck)</td></tr><tr><td>(Car</td></tr><tr><td>(Mercedes)</td></tr><tr><td>(Volkswagen)</td></tr><tr><td>(Toyota</td></tr><tr><td>(Camry)</td></tr><tr><td>(Corolla)))))</td></tr></table>
for representing inferential knowledge and frames for representing facts and structures in the world can be employed to solve a wide range of problems. Frames (Fikes and Kehler, 1985) are often used to describe objects in the world and can also be used to specify behavioral characteristics of objects as well. Frames are often said to be object-oriented; however, frame-based object descriptions differ in several ways from the object-oriented mechanisms described previously. The differences and similarities of frame and object-oriented representations will be described next. Frames are important from a historical perspective because object-oriented methodologies are derived, in part, from the study of representing knowledge with frames.

Frames are a representation mechanism that permit a structured representation of objects. Table 2.2 showed how part of the hierarchy shown in Figure 2.4 could be represented as a simple definition. The syntax of Table 2.2 is that of the Lisp programming language, in which parentheses are used to group items. Other syntactic styles are used in other languages, as shown in Table 2.3, but all have the same essential meaning. Frames are generally described as having slots and values in the slots. In the example shown, slots are the names of the entries shown, that is, occupants, color, and so on. Note that the first three languages used for representation in this example define a structure and the *types* of values that go in the slot. In contrast, Smalltalk-80 employs dynamic variable binding and thus requires no initial definition of the type of value that is associated with its instance variables. Frames also permit representation of behavioral information in the form of *predication* on slots and/or structures. Predication means that a procedure can be activate when information is put into a slot or retrieved from a slot. The technique is also known by the term *active value*. Although frames allow a combination of both structural and behavioral descriptions in the same declaration, the implementation and use of frames is considered by some to be a bit cumbersome.

Object-oriented languages permit representing things in much the same manner as frames. The last entry in Table 2.3 shows the Smalltalk-80 style for representing the same information as the other languages in the table.

In this example, there appears to be no advantage to the use of an object to capture framelike information. Yet, as will be illustrated, the major difference between objects and frames is in the explicit capturing of object behavior as methods encapsulated in an object, a task that is much simpler in objects than in frame-based or conventional languages.

## Whole-Part Hierarchies

Whole-part hierarchies differ from inheritance hierarchies. Inheritance hierarchies provide a way of describing more specialized objects by
<figure><img src="image_20.png" /><figcaption>**Figure 2.6** Whole-Part Object Decomposition of an Automobile.</figcaption></figure>

## The Behavioral Representation of Objects

In addition to representing the structure of objects, one needs to represent the behavior of objects. In objects, behavior is represented by methods, as discussed earlier in this chapter. In frames, behavior is represented by active values or predicates, that is, code attached to a slot which runs when a value is retrieved or stored in a slot. This same behavior can be easily captured in objects, as shown next.

Consider the frame given in Table 2.4. A frame called *Car* is defined and an instance of *Car* called myToyota is created. In the slot for " numberOfDoors " is found a predicate called *doortest*, which is a function that is run whenever a value is inserted into this slot. Hence, if the number of doors inserted into the slot exceeds 5, a warning message is printed. This same type of
<table><caption>**Table 2.4 Implementing Active Values in Frames and Objects***</caption><thead><tr><th colspan="2">Frame Definition</th></tr></thead><tbody><tr><td>(defFrame Car</td><td>; define a car frame</td></tr><tr><td>(model symbol)</td><td>; a car model</td></tr><tr><td>(numberOfDoors integer doortest)</td><td>; check the number of doors</td></tr><tr><td>(defInstance Car myToyota</td><td>; myToyota is an instance of Car</td></tr><tr><td>(model Toyota)</td><td></td></tr><tr><td>(numberOfDoors 19)</td><td></td></tr><tr><td>(defun doortest (number</td><td>(If (number > 5) then (print 'Too Many Doors'))</td></tr></tbody><thead><tr><th colspan="2">Object Definition</th></tr></thead><tbody><tr><td>Object subclass: #Car</td><td></td></tr><tr><td>instanceVariables: 'model numberOfDoors'</td><td></td></tr><tr><td>classVariables: ''</td><td></td></tr><tr><td>Method Names</td><td></td></tr><tr><td>defineModel: aModel</td><td>"a method to name the model"</td></tr><tr><td> numberOfDoors: aNumber</td><td>"a method to set the number of doors"</td></tr><tr><td> self doorTest: aNumber</td><td>"send the number of doors to doorTest"</td></tr><tr><td> doorTest: aNumber</td><td>"a method to test if too many doors"</td></tr><tr><td>(number > 5) ifTrue:</td><td></td></tr><tr><td>[Print 'Too Many Doors']</td><td></td></tr></tbody></table>

behavior can easily be duplicated using objects by creating an object also called Car and defining methods internal to the object that permit defining the car's model name and the numberOfDoors. Testing how many doors are allowed requires the running of another method called *doorTest* whenever the instance variable "屢個門口" is set.

The mechanism of active values is particularly useful for implementing systems in which values are displayed on gauges. For example, a frame may contain information about a panel of gauges that needs to be displayed on the screen; when a new value is inserted into a slot, the gauge should be updated and displayed. Similarly, objects can contain methods that drive gauges or other visual representations that display the state of an object.

## 2.4 The Causal Nature of Engineering Systems

Causality refers to the relationship between cause and effect. In engineering, systems are frequently composed of many parts which have cause-and-effect relationships between the parts of a system. Simple examples abound in the real world. For example, push-button radios or traffic lights exhibit the

<footnote>*The details of object description syntax will be given in subsequent chapters.</footnote>
<figure><img src="image_21.png" /><figcaption>**Figure 2.7** A Simple Digital Circuit: A Half-Adder.</figcaption></figure>

behavior that causing one button to be on or one light to be on causes the remaining buttons or lights to be off. Simple commonsense causality exists such as the knowledge that applying pressure to the brakes of a car causes the car to stop; in reality there are several causal linkages in this chain, yet we abstract the overall causality to understand the functioning of the mechanism.

Figure 2.7 shows a simple digital circuit (the same one shown in Figure 1.3). If we view each element in this circuit as an object and each wire as an object that connects circuit element objects together, we can obtain an idea of how causality works for digital circuits. Imagine that a signal is sent to the 'OR' gate input marked 'A' in the diagram. The 'OR' gate contains a *constraint*, that is, a rule or condition that must always be true which describes the behavior of the 'OR' gate. When either input of the 'OR' gate goes high, the output of the gate will become high. The wire at the top of the diagram between the 'OR' gate and the 'AND' gate at the output of the circuit propagates the signal to the rightmost 'AND' gate. At this gate, the constraint propagates a 1 to the output and lights the light bulb, if the remaining input to the 'AND' gate is high. This movement of information between objects is a simulation of physical causality and is easily modeled using object-oriented methods. Furthermore, the modeling approach described here is a rudimentary technique that could be used for implementing computer-aided-design systems.

As a second example in a separate domain, consider the hot-water heater schematic shown in Figure 2.8. The physical representation of the water heater shown at the top of the figure shows a schematic of the physical arrangement of the water heater components. Water flows from an input through a heat exchanger to produce hot water at the output. Heat is produced by a burner that heats the heat exchanger. At the bottom of the figure is shown a representation of the same water heater using objects. Each object has internalized its behavior, that is, how it will react to different kinds of inputs. For example, sending more gas to the burner will cause the burner to produce more heat and hence (causally) the heat exchanger to impart more heat to the water.
<figure><img src="image_22.png" /></figure>

<figure><img src="image_23.png" /><figcaption>**Figure 2.8 Representing a Hot-Water Heater.**</figcaption></figure>

**2.5 Representing Time**

In the examples given about causality, the influence of time has been omitted. To provide more complete representations of the real world, it is necessary to include time as part of the description of real systems. In the examples just given, time would be a factor in that there would be small delays in each of the digital circuit gates described and there would be a lag between application of heat to the heat exchanger and the water reaching a certain temperature. In other design examples, such as designing a traffic system or a flush toilet, in which events occur sequentially, time needs to be explicitly represented.

To represent time, two methods are frequently used for simulation. One can keep track of the time at which things occur by posting information on
a central blackboard or queue. As events occur, information about future events
can be posted on a queue. These events can be sorted according to time and
removed from the queue one by one to simulate the activity of a system. In
another, but similar technique, incoming information (e.g., a signal) can be sent
to an object, and the object can delay forwarding information for an amount of
time to the objects to which it is connected. In the digital circuit example, after
receiving a signal at its input, a gate object might wait for a predetermined
amount of time before forwarding information on to the objects to which it is
connected. These techniques will be described in detail in Chapters 10 and 13.

2.6 Modeling and Simulation

A model is normally defined to be a representation of a physical
object. However, models of mental processes may also be represented—(so-
called “mental models” [see, e.g., Gentner and Stevens (1983)]. In the context
of the discussions of representation in this chapter, models can be defined as
structured declarative representations that capture the physical attributes of
real things. Using this definition, frames can capture the representation of
things as can objects arranged in class hierarchies. Once behavior is added to a
model, in the case of frames using active values or by defining methods in
objects, the models become runnable and thus can stimulate the behavior of
systems.

Modeling using objects is as simple as defining the characteristics of
the objects that are to be modeled. Following the methodologies discussed
earlier in this chapter, class variables, instance variables, protocols, and methods
are defined for classes. These classes typically inherit variables and methods
from classes that have already been created. New models of abstract objects can
be quickly created by recognizing that the model of an object differs only in
minor ways from a more abstract object that already exists. A complete
methodology for modeling using objects will be presented in the next chapter.

Simulation of any system can be accomplished using procedural code.
For decades, many different computer languages have been used for simulating
various physical and abstract processes. The advantage to object-oriented pro-
gramming methods for simulation lies in the modularity, understandability, and
ease of specialization capabilities inherent to the methodology. Of special
interest in using simulation in Smalltalk-80 is the existence of the Smalltalk-80
virtual machine which has the capacity to schedule and control multiple pro-
cesses that appear to run simultaneously. There is no actual multiple-processor
machine—hence, the term *virtual*, meaning existing in essence but not in actual
fact. Objects that have self-contained behaviors and operate either indepen-
dently or share resources can be readily modeled by making use of the facilities
for controlling multiple processes in Smalltalk-80. This topic will be discussed in Chapter 14.

## 2.7 Representation of Complex Systems: An Example of an Advice-Giving System

Complex object-oriented systems created for use in engineering or other domains commonly consist of many interacting objects. A typical Smalltalk-80 system will consist of objects that describe a *model* of the domain, a *controller* that interfaces the user with the system, and a *view* that displays what the user sees. Each of these subparts of a system will, in turn, contain many interacting objects. The virtue of object-oriented methodologies for creating complex systems is that complexity can often be reduced and existing classes may be specialized to achieve a certain degree of parsimony. To provide a flavor for how to represent a complex system, the architecture of a common advice-giving system will be described next.

The term *advice-giving system* describes what many types of engineering systems do. Most computer systems created to serve the needs of engineers who analyze problems and design entities require a strong component of advice giving. These systems contain sufficient domain knowledge, algorithms, and heuristics to advise users about problems encountered. Rudimentary advice givers include expert systems (Hayes-Roth, Waterman, and Lenat, 1983) that capture the knowledge of the experts in a domain, CAD tools that provide simulations of the real world, and signal analysis systems that transform signals from one domain to another. More complex advice-giving systems would provide help, tutoring, advice, and even adjust the presentation of a system to the cognitive level of the user.

As an example of an advice-giving system, consider the architecture of the problem-solving system that was shown in Figure 1.2. This general model is suitable for use in many different engineering domains. Next, the general requirements for casting this model into sets of interacting objects will be considered and a specific example provided for the signal analysis system top-level view that was given in Figure 1.4.

### Requirements

Systems that give advice need (1) to contain the knowledge to support the advice given and (2) to understand the needs of users and how to present knowledge to users. Systems that display some degree of intelligence should not only contain the knowledge but also provide the facilities to assist the user in
reasoning about the problem. To factor the problem into several parts, the object characteristics described next are divided into the three parts identified previously: (1) objects that deal with knowledge and data (the "model"), (2) objects concerned with control (the "controller," i.e., the interaction of the user with the system through the mouse and keyboard), and (3) objects that implement the "view," which consists of how information is presented on the screen. This factoring of information about construction of a relatively complex system permits conceptually separating parts of the system into logical groups, and, as we shall see in Chapter 4, fits directly into the standard Smalltalk-80 paradigm for description of systems. The terms used in describing the elements of the advice-giving example system are cast in Smalltalk-80 terminology which will be presented in increasing levels of detail in subsequent chapters.

## The Model

The model may be considered to be a collection of objects that represents knowledge and data in a system. In a very simple system, the model might be only a data structure of some type such as a "dictionary" or an array of numbers. In larger systems, the model often includes a wide range of data and knowledge types. Next, several common objects found in a model for an advice-giving system are listed.

**Dictionaries.** A simple data structure that is frequently used is a dictionary, which consists of a set of associations of key and value pairs. For example, a dictionary would be a useful representation to keep track of information about things that the system knows about. For example,

SignalAnalysisMethodsDictionary:

<table><thead><tr><td>Key</td><td>Value</td></tr></thead><tbody><tr><td>sineWave</td><td>anObject that contains information about sine waves;<br/>e.g., amplitude and frequency</td></tr><tr><td>squareWave</td><td>anObject that contains information about square waves<br/>etc.</td></tr></tbody></table>

In this example, each key in the dictionary would contain an item, which, when assessed, would return an object that provides more information about the item.

**Collections.** Collections are a popular way of capturing information. Many kinds of collections might be used for information storage; most popular are ordered collections that behave like queues and sorted collections in which the order of
the collection is maintained according to some predetermined metric such as time. When representation of two-dimensional or higher-dimensional knowledge or data is unnecessary, collections of various types provide a simple way to implement a model. In our example, a collection could be used to store the data points that represent the ordered samples from an input signal and also store the results of the fast Fourier transformation of the signal.

*Networks.* For more complex information, network representations are the most useful representation mechanism for static knowledge. Frames, as discussed previously, may be represented in network fashion. Nesting of dictionaries can be used to implement a network (i.e., the value in a dictionary contains another dictionary, etc.). A network could contain information that assists the user in understanding how to use an advice-giving system. Chapter 11, in fact, provides an example of using a network for this purpose.

*User Models.* In an advice-giving system, one object that is needed is a user model to keep track of what the user does while using the system. In order to make a system appear intelligent, this model would need to contain sufficient information to permit inferences to be made about what the user does and does not know. A dictionary would be useful for storing user models. Keys in the dictionary could be the name of each user and the value associated with each key would contain information about each user's level of knowledge.

*Algorithms.* Algorithms should also be included in the model of an advice-giving system. Algorithms are an essential element of the model because procedural evaluations are frequently needed to interpret and evaluate data. Algorithms are best implemented as methods in Smalltalk-80 or in procedures written in traditional languages that are coupled to Smalltalk-80 (see Chapter 12).

*Heuristics.* To give advice, heuristics may be a required part of the model. A heuristic is a rule of thumb, often used by humans to make inferences about a situation. Popularized in the field of expert systems (Hayes-Roth, Waterman, and Lenat, 1983), rule systems that code heuristics in the form of IF → THEN rules have become a standard part of many traditional engineering systems. The role of heuristics in an advice-giving system is to capture human reasoning about a domain. Heuristic reasoning is particularly useful in engineering design in which it may be difficult to specify all decisions algorithmically.

## Control Objects

*Controller.* A controller coordinates a view (i.e., what the user sees), a model (i.e., the data or information), and user actions. In Smalltalk-80 there is a
systemwide controller known as the **ControlManager** that coordinates all views that are presented on the screen. In addition, there are other controller classes that provide the capability of associating pop-up menus with the pressing of mouse buttons and permit the sensing of the location of the cursor on the screen.

For creating controllers for the example advice-giving system, the primary responsibility of the systems designer is to decide what actions should be taken in any view that is shown on the screen. The typical control methodology is to provide a pop-up menu in each view which, when activated by the mouse, permits the user to make selections, which subsequently causes some action to be taken that influences what is shown on the screen. An alternative to this method is to always display on the screen all possible control actions by using buttons, which when pressed cause the required action.

## View Objects

In a graphics user interface, most interactions of the system with the user are handled graphically. Smalltalk-80 views are displayed in windows of the host windowing system that permit opening, closing, resizing, moving, and collapsing of windows. Rectangular areas within a window, known as "views," may contain many different types of user interface mechanisms such as lists, buttons, settable dials, text, and so forth.

Considering the preceding description of objects in terms of the architecture given in Figure 1.2, objects implementing views and controllers for the views are contained in the top-level layer of the system labeled "graphics user interface," whereas the model is contained in the second layer. Knowledge attendant to the models is contained separately in a data/knowledge base that is conceptualized as a separate block at the bottom of this figure.

## Architecture of the Signal Analysis Advisory System

Figure 2.9 displays an architecture for a signal analysis advisory system constructed along the same lines discussed previously. The architecture is quite similar to the architecture of Figure 1.2 except that it contains the objects that are required for the specific application.

The goal of the signal analysis advice-giving system is to implement a system that provides advice to users about signals that they acquire. Advice in this simple example is fairly limited; for example, the advice might be limited to the interpretation of a signal that has been acquired.

The user interface shown in Figure 1.4 for a signal analysis system contained no advice feature. If a button were added on the right side of the
<figure><img src="image_24.png" /><figcaption>**Figure 2.9** An Architecture for an Advice-Giving Signal Processing System.</figcaption></figure>

view which, when pressed, would give an interpretation of the signal, the screen
might look like the rendition shown in Figure 2.10. The user would employ the
system to acquire signals, as described in Chapter 1; when done, the interpret
button would be pressed and a textual discussion of the signal on the screen
would be given.

Implementation of such an advice-giving system could be accom-
plished using the kinds of classes shown in Table 2.5. These classes are
commonly used for implementing the tasks described. In subsequent chapters,
<figure><img src="image_25.png" /><figcaption>**Figure 2.10** Addition of an Analysis View to the Signal Analysis System Shown in Figure 1.4.</figcaption></figure>

<table><caption>**Table 2.5** Classes Used for Creating an Advice-Giving Signal Analysis System</caption><thead><tr><th colspan="2">Model Classes</th></tr></thead><tbody><tr><td>OrderedCollection</td><td>Stores the signal</td></tr><tr><td>OrderedCollection</td><td>Stores the FFT</td></tr><tr><td>Dictionary</td><td>User model actions stored</td></tr><tr><td>Dictionary</td><td>Rules</td></tr></tbody><thead><tr><th colspan="2">Controller Classes</th></tr></thead><tbody><tr><td>ControllerWithMenu</td><td>Provides mouse and menu control</td></tr></tbody><thead><tr><th colspan="2">View Classes</th></tr></thead><tbody><tr><td>SignalView</td><td>Shows the signal</td></tr><tr><td>FFT View</td><td>Shows the FFT</td></tr><tr><td>Buttons</td><td>Initiates actions when the user presses a button</td></tr></tbody></table>
methods for implementing all the features of this type of user interface, along
with the associated controller and the model characteristics, will be discussed.

**2.8 Summary**

This chapter has given a basic introduction to common terms associ-
ated with objects and explained how to represent both structural information
and behavioral information using objects. Comparisons were made with similar
ways of representing information in different computer languages and in the
frame representation paradigm. Representing time and causality were described
and a concluding example presented that conceptually explained how to build
an object-based engineering system for analyzing signals.

References

Fikes, R., and T. Kehler (1985). The Role of Frame-Based Represen-
tation in Reasoning. *Communications of the ACM*, Vol. 28, No. 9,
September, 904–920.

Gentner, D., and A. L. Stevens (Eds.) (1983). *Mental Models*. Lawrence Erlbaum Associates, Hillsdale, NJ.

Hayes-Roth, F., D. A. Waterman, and D. B. Lenat (Eds.) (1983).
*Building Expert Systems*. Addison-Wesley, Reading, MA.

Morris, William (Ed.) (1981). *The American Heritage Dictionary of the English Language*. Houghton-Mifflin, Boston, MA.

Exercises

2.1 Pick a common object with which you are familiar and draw a class inheritance hierarchy which could be used to instantiate the object. Try to show the breadth of the tree created and be sure to pick an example with several levels of abstraction. The key to successful completion of this problem is the selection of an object that you completely understand. Common objects in the world are acceptable such as kinds of machines, computer systems, dishwashers, and so on.

2.2 For the same physical object considered in the previous problem, create a whole-part hierarchy.

2.3 Next, add instance variables to the hierarchy of Exercise 2.1 at each level created, showing how the more specialized classes can inherit and use the variables defined at more abstract levels.
2.4 Give an example, different from those presented in the chapter, of the basic object-oriented characteristics listed in Table 2.1. You may wish to use the same example that you picked for the preceding exercises.

2.5 In the architecture given for implementing a signal-processing advice-giving system, a hierarchical representation scheme was used. Pick another example and sketch the same type of hierarchy for your example. Other appropriate domains to consider for this task would be (1) a CAD system or (2) a control system.

2.6 How does modeling differ from simulation?

2.7 Explain the distinction between classes and instances of classes.
# Object-Oriented Analysis

## 3.1 Introduction

The dictionary definition of "analysis" is an appropriate starting point for understanding object-oriented analysis. *Analysis* is defined to mean "the separating of a material or abstract entity into its constituent elements" (Webster, 1989). Analysis is a key component of design, normally preceding the creation of new designs. In order to build a new entity or object, designers analyze various requirements for building a new object such as the technology needed, feasibility, cost, and analogy to previous designs. Object-oriented or not, design requires analysis as a precursor. In this chapter and the next, an attempt will be made to show that traditional engineering analysis and design can be closely matched to object-oriented analysis and design. This chapter will discuss analysis methodologies and provide an analytical methodology that can be used for object-oriented analysis. The analysis techniques discussed here are designed for use with Smalltalk-80, but have applicability for other object-oriented languages as well. There are many other approaches to object-oriented analysis that employ different but complementary approaches [see, e.g., Coad and Yourdon (1990) and Shlaer and Mellor (1988)]. Chapter 4 will map the analytical process described into a design methodology.

Analytical thinking about decomposition of both material and abstract entities is quite similar. For example, consider the following engineering systems: analyzing the requirements for building a car, simulating a traffic system, building a CAD system, and creating a signal analysis system. The process of analysis is similar for each case. Both material and conceptual entities can be usually subdivided into components. Indeed, the engineering methodology of breaking a problem into parts normally permits problem solving to follow this
paradigm. Separation of a physical object into parts is easily understood. For example, an automobile may be subdivided into its constituent elements: engine, body, transmission, interior accommodations, tires, and so on. Likewise, conceptual decomposition can be found in simulation and analysis systems. A traffic simulation system may be decomposed into various objects, such as simulated cars, simulated time, and so forth; a signal analysis system may be subdivided into algorithms, acquisition objects, and presentation objects.

The goal of this chapter is to describe and demonstrate analytical techniques that can be used for object-oriented problem solving. The techniques presented should work equally well with a variety of different problem types, for example: (1) object decomposition for information organization, (2) analysis of objects required for building an analysis system, (3) creation of simulation systems, and (4) organizing objects in a design.

The context in which the information in this chapter will be presented utilizes the same generic descriptive terms employed in Chapter 2 and in the Smalltalk-80 environment. The terms class, instance, class variables, instance variables, protocols, and methods, as explained in Chapter 2, will be used as a basis for describing the analytical methods.

## 3.2 Analytical Methodologies for Building Object-Oriented Systems

### General Concept

The purpose of an initial analysis of a problem is to provide an organizing structure or framework in which the problem can be further understood and decomposed. In general, the process is to identify all objects in the problem and their behaviors. At the outset, the global problem should be considered by describing the overall conceptualization of the problem. It is helpful to prepare a natural-language outline of the problem, roughly identifying all the possible objects that might "live" in the final system. This preliminary work will help organize one's initial thoughts about how to approach the problem. For example, if one is creating a system to simulate digital circuits, a name could be selected to identify the system, such as *DigitalCircuitSimulation*, which can be used subsequently to create a class named **DigitalCircuitSimulation**. This class ultimately would be used to create a DigitalCircuitSimulation object that would coordinate all objects in the application.

### Analyzing the Problem

Given an idea for creating a system, it is a short step to naming the organizing object. Preparing for the next task, understanding the constituent
<table><caption>**Table 3.1 Definition of System Description Terms**</caption><thead><tr><td>Concept</td><td>Explanation</td></tr></thead><tbody><tr><td>Teleology</td><td>The purpose of a design<br>The design intent<br>Specifications</td></tr><tr><td>Function</td><td>The designed activity of an object<br>The way something should work<br>Algorithmic or heuristic definitions</td></tr><tr><td>Behavior</td><td>Manner of behaving or acting<br>Relationship between input and output of<br>a system determined from measurement<br>The way something works</td></tr><tr><td>Structure</td><td>The way things are constructed or connected<br>Pertains to both material and abstract things</td></tr></tbody></table>

parts of the problem, requires more in-depth understanding of the problem domain and alternative solutions. Precisely "what is it that is to be accomplished?" with the system being created is a typical question that can be asked at the outset of designing any system. Most often, the answer to this question requires a consideration of a number of factors prior to proceeding with detailed design. Teleological, functional, behavioral, and structural specifications must be considered to provide a mental framework for a design. Table 3.1 summarizes some common definitions of these terms. Teleology refers to design intent, that is, what the design is supposed to accomplish. Although it is usually clear to a designer what the intention is in designing a system for some purpose, the system that is designed does not always exhibit the intended functionality. Function refers to the specification of what a system is intended to do according to design specifications. In principle, behavior should exactly mirror function; that is, the behavior of a system should implement the functionality of a system. In fact, this is often not the case. Hence, it may well be better to define behavior as the relationship between the inputs and outputs of a system; that is, what the system actually does. Physical specifications, in the case of physical entities, specify the structure of an object and how parts fit together. In the case of software, as in the specification of a user interface, for example, a structural specification would include how the system appears to the user and how the user interacts with the system.

Table 3.2 provides an example of the use of these terms for a simple amplifier system. In examining the way these terms are used, one should note clearly that behavior is the way something actually works, whereas function specifies the way something is designed to work. One can extend these concepts
<caption>**Table 3.2** Terminology Utilization for an Amplifier</caption>

**Definition:** An amplifier is an electronic device that changes (amplifies) small signals into large signals. A common example is an audio amplifier.

**Teleology:** The design intent for an amplifier is the specification of what the amplifier is supposed to do. A specific design will have a particular specification, e.g., amount of amplification, bandwidth, etc.

**Function:** The function of a particular amplifier is an algorithmic or heuristic definition of how the amplifier should work, i.e., what it should do to fulfill the design specifications.

**Behavior:** The behavior is the way the amplifier actually created works, which may differ somewhat from the functional specification. For any given input to an amplifier, there will be an output. This relationship, for all inputs and outputs, defines the behavior of the amplifier.

**Structure:** The structure of an amplifier is defined in terms of its constituent parts, e.g., resistors, integrated circuits, power supply, etc., which may be represented abstractly on a schematic.

to other domains as well. For example, consider designing an exit ramp for an interstate highway. The *teleology* (design intent) would consist of a set of specifications. *Function* could be represented in sets of equations that describe traffic flow. *Behavior* would be secured by taking actual data from the exit ramp (e.g., numbers and rate of cars using the ramp), and *structure* would be the physical location of guard rails, the width of the ramp, and so on. Note that behavior and function could be identically the same; however, in most real-world cases, behavior is normally somewhat different from what is predicted by the ideal function specification. Also, the design intent may define a function that does not cover all behaviors of an object.

**Object Identification: Physical and Abstract Representations**

Physical decomposition of objects into constituent parts is usually relatively straightforward because the subparts of an object are identifiable objects as well. The whole-part decomposition of an automobile given in the previous chapter is an example of a physical decomposition. Decomposition of abstract entities is more complex, however. The signal analysis system is a good example: A top-level object exists which coordinates all the remaining objects in the system, for example, objects that manage or implement algorithms, display objects, user interaction objects, data acquisition objects, and so forth. The conceptual mapping of real objects into object representations comes directly from an analysis of the teleology of the object. In this example, the teleology of a signal analysis system is to create a tool that provides the user the capability of understanding what is in a sampled signal. Functional specification provides a
listing of capabilities of the designed system. These capabilities often match the objects that are in the system. For example, one capability that a signal analysis system should have is to perform an FFT on a signal; this task will require an FFT analysis object. Similarly, if filtering is another task, a filter object will be needed. Hence, the analysis of which objects are needed proceeds directly from the evaluation of the function. Implementation of the objects includes a behavioral evaluation.

In the discussions that follow, the reader should remember (as discussed in the previous chapter) that classes define the characteristics of a general category (i.e., class) of object and that a specific object can be created by instantiating a class. For example, the specific objects *anAmplifier* or *amplifier-1-1992* could be created by instantiating the class **Amplifier**. The object *anAmplifier* is an instance of the class **Amplifier**.

As discussed in Chapter 2, inheritance plays a very significant role in object-oriented systems. Indeed, inheritance becomes a significant issue in analyzing a problem. In all object-oriented languages (see Chapter 5 for a discussion of different object-oriented languages), inheritance capabilities are provided. However, inheritance without preexisting classes that can be specialized provides only a small improvement above standard procedural programming practices. In other words, object-oriented languages that contain many preexisting classes provide a designer the most flexibility for rapidly building new applications because existing classes can be reused and specialized. Without these classes, problem analysis simply becomes a description of classes. The analysis problem is not very difficult in this case. In contrast, in object-oriented environments such as Smalltalk-80, which have many classes already in existence as part of the environment, the analytical task is much greater. The programmer must first evaluate the function of the object being designed and then determine if it is advantageous to create a subclass of any class that is already in the environment. Thus, to be effective, a programmer must understand, or at least have some acquaintance with, several hundred classes. This situation makes it extremely attractive for new object-oriented programmers to program without regard to existing classes because of the steep learning curve associated with understanding the class libraries. However, productivity suffers. Once the programmer learns many classes and creating subclasses of other existing classes begins to be a normal class definition modality, productivity markedly increases. Chapter 5 will address these considerations in detail.

## Steps in Object-Oriented Analysis

Table 3.3 displays the steps for object-oriented analysis. The first step is to consider the design intent for the system being analyzed. This step basically consists of trying to understand what the system being created is supposed to do
<table><caption>**Table 3.3 Steps in Object-Oriented Analysis**</caption><tr><td>1.</td><td>Define the design intent of the application.</td></tr><tr><td>2.</td><td>Determine the name of the organizing class. Write a definition, including the general categories of classes that the organizing class coordinates.</td></tr><tr><td>3.</td><td>Define and name constituent classes managed by the organizing class. Write a definition of the functionality of each class.</td></tr><tr><td>4.</td><td>For each class, determine the local state in terms of class and instance variables.</td></tr><tr><td>5.</td><td>For each class, define the functionality such that object functions can be coordinated by an instantiation of the organizing class.</td></tr><tr><td>6.</td><td>Create the specific objects in the application by instantiating the classes designed.</td></tr></table>

when it is completed. At this point, a set of specifications can be created that can assist in guiding the implementation of the system. Step 2 requires identifying the organizing class and providing a definition of the functionality of this class as well as identifying the types of classes in the application coordinated by the organizing class. Step 3 repeats the process for each specific class identified. Step 4 defines the state by identifying the class and instance variables needed to maintain information inside each class. In step 5, a description of the function of each class is created including producing descriptive names that identify what an object created from a class will do when sent various messages. Finally, the specific objects in the application can be created by instantiating the classes defined.

## State Definition

An object's state can be characterized as the collection of the values of various internal variables at any particular time. When an object's behavior is influenced by its history, as manifested in these variables, then an object is said to have a state. To capture state information in an object, class and instance variables for each class used to create an object should be defined. Class variables are those variables that are shared by all instances of a class. Separate copies of instance variables exist in each instantiation of a class. Hence, when analyzing each object, the programmer must discern (1) if there are any variables that are common to all instances of the class and (2) what are the variables that define the state for the instances.

## Behavioral Specification of Objects

For each object defined, the final task is specification of the behavior of each object. Consistent with the definitions given previously, *the behavior of*
an object is what the object does when a message is sent to it. The input to an object is a message; in response to a message, an object can change its internal state and/or it can send messages to other objects. Internal object behavior is best organized into protocols, or collections of methods that have similar or allied functions. Thus, it is useful to initially determine what the protocols are that an object should have. Examples of some types of protocol names are initializing, accessing, printing, drawing, activating, and so on. Names should be picked that have a clear meaning to the user so that there is no ambiguity about where methods will be located. Good selections for names of protocols will ultimately enhance understandability. Protocol names are not used in the actual code in the Smalltalk-80 examples to be given in upcoming chapters, but are simply employed as an organizing and self-documenting mechanism.

The overall behavior of a system created is defined by the collection of behaviors of the individual objects in the system. To make definition of system behavior more understandable, a top-level system object is normally defined that organizes the remaining objects in the system.

The information given previously is quite general; hence, a systematic methodology for analyzing applications and generating descriptions that can be used to produce actual object code for Smalltalk-80 is presented next.

### 3.3 Organizing Applications Using the Application/Class Organization Method (ACOM)

This section of the chapter presents a "pencil-and-paper" organizing technique for analyzing applications. The method is called the *application/class organization method* (ACOM). The purpose of the methodology is to provide a framework in which an initial set of classes, their variables, and methods can be specified for a new application. The utility of the method is the assistance it gives users in organizing their thoughts about how to structure an application. The "pencil-and-paper" technique is useful for initially learning how to analyze applications and for groups that are building large applications. Computerized organizing methods are actually available that accomplish the same aims as the "pencil-and-paper" methods. These organizational aids will be discussed in Part Two of this text.

ACOM is loosely based on an idea proposed by Beck and Cunningham (1989) and Cunningham and Beck (1986) that is known as the CRC (class-responsibility-collaborator) card method. Figure 3.1 shows an example of this method. The idea is to create 4-inch by 6-inch index cards with three main pieces of information on the card: (1) the name of the class, (2) the responsibilities of the class, and (3) the names of objects with which the class object communicates. As shown in the figure, there might be many CRC cards generated to describe an application; the list of collaborators would be the
<figure><img src="image_26.png" /><figcaption>**Figure 3.1 Class-Responsibility-Collaborator Card Concept.** [After Beck and Cunningham (1989).]</figcaption></figure>

names of objects that would be described by additional cards and so forth. The utility of the scheme is that one can analyze a problem by writing on cards the names of classes and how they relate to other classes. This kind of problem decomposition is a first step in understanding how a problem can be separated into parts. Typical use would be for an individual or team to create as many cards as possible. Team use of the technique can facilitate “brainstorming” and team members can even play the role of the objects created to try and discern their own responsibilities and collaborators.

ACOM differs from the CRC method in that there are four different classes of cards, each of which contains considerable additional information. ACOM cards were designed to permit a direct translation from analysis of an application to coding of the application, without losing any of the generality of the CRC method. Each ACOM card shown in this text can be reproduced and used for classroom or individual analysis sessions.

Figure 3.2 shows the first ACOM card—the *application organizer*. At the top of the card, a space for indicating the application name is provided; as indicated earlier in the chapter, this name will likely become a class name that describes the organization of the entire application. The box below the application name is provided to permit writing a description of the application. In the lines below the box, the names of objects in the application can be listed. At the end of each line is an oval in which one can jot down a cross reference to another card; sometimes it is useful to employ different colored pens to color code related class cards. Class cards and extension cards, to be discussed next, contain small boxes at the top left and right which can be used for color-coded coordination with the application organizer card. One benefit of the use of cards is that additional information can be put on the back of the card, as needed. In experiments conducted by the author in teaching students the use of the ACOM method, of 4-inch by 6-inch cards were found to be preferable to 3-inch by 5-inch cards.
<figure><img src="image_27.png" /><figcaption>**Figure 3.2** The Application Organizer Card.</figcaption></figure>

Figure 3.3a shows the class organizer card and Figure 3.3b shows an extension card that can be used, as needed, to capture additional information. The format of the card is very deliberate; it was specifically designed to mirror the syntax of creating classes in Smalltalk-80, with the intention that if cards are created by hand using this technique it is a very short step to producing actual code. Currently, it is difficult to work as a team using Smalltalk-80 because Smalltalk-80 provides an environment only for an individual. Hence, ACOM cards should provide a useful start-up accessory for the initial analysis of a problem by a team. Teams can come together and agree on most of the classes that should be in an application, try different organizations, discuss alternatives, and define behaviors prior to any coding actually taking place! Without an initial agreement about the basic organization, it would be difficult to share a team's work among individuals using their own separate Smalltalk-80 environments.

At the top of Figure 3.3a, the names superclass, class, and subclass are listed. The organization for naming a superclass and a class is an essential step in defining the code for an object, as will be shown in Part Two of this text. Space for indicating subclasses is provided to allow the user to indicate if the class can be used as a superclass for other classes. The bracket under "class" should be filled with the name of the class being created and its superclass should be indicated to the left. If there is no specific known superclass, simply write down **Object**, or leave it blank. There is a box at the top right which can be used to color-code link the class with the object specified in the application organizer card. Next, a description box is found on the card, followed by a space in which class variables and instance variables can be listed to define the state of the object. On the bottom half of the card, protocols and their methods are to
<figure><img src="image_28.png" /><figcaption>(a)</figcaption></figure>

<figure><img src="image_29.png" /><figcaption>(b)</figcaption></figure>

<caption>Figure 3.3 (a) The Class Organizer Card and (b) the Class Organizer Extension Card.</caption>
<figure><img src="image_30.png" /><figcaption>**Figure 3.4** The Method Description Card.</figcaption></figure>

organizer card. Next, a description box is found on the card, followed by a space in which class variables and instance variables can be listed to define the state of the object. On the bottom half of the card, protocols and their methods are to be listed. So far, no code has been generated, only the names of things and linkages to things. The card shown in Figure 3.3b is a simple extension card to the main class card in Figure 3.3a.

Figure 3.4 displays the final ACOM card—a method description card. Methods are listed in the class card under protocols by name. In the methods card, each name listed is indicated at the top of the card, along with its class. A box is provided to check whether the method is a class or instance method. Class methods are associated only with the class, whereas instance methods are used only in objects that are instantiations of the class. Following the mandatory description box is a place to indicate what the method should return and whether the method supersedes a method of the same name in a superclass.<fnref n="1" /> The bottom half of the card provides space for actually writing code for the method. Students using the ACOM method for learning to organize classes can, at this point, ignore the writing of any code. Hence, using the ACOM method, individuals or teams can proceed from a conceptual analysis of an application all the way to writing code. Figure 3.5 shows in diagrammatic form how the ACOM cards are linked to each other. The final section of this chapter will

<footnote n="1">¹Typically, methods defined in a subclass replace methods of the same name that are defined in a superclass.</footnote>
<figure><img src="image_31.png" /><figcaption>Figure 3.5 Illustration of ACOM Card Organization.</figcaption></figure>

present a complete example of the use of the ACOM methodology for a simple application.

## 3.4 Analysis Maxims

Listed next are a few analysis maxims along with their explanations. These maxims are divided into four categories: understanding the problem framework, object identification, object behavior specification, and class association, coordination, and examples.
## Understanding the Problem Framework

* Understand the general domain. If you are not expert in the domain of the application, work with someone who is. If you are creating a team to work on the application, be sure that the team includes knowledgeable people who represent different aspects of the problem.

* Secure as much background information as possible and organize the information.

* Analyze the nature of any constraints in the system being built; for example, does the application require representation of time, are there any direct or indirect causalities?

* Ascertain if the problem requires coordination between resources.

* Determine if the application requires any use of shared resources, for example, rule systems, databases, or other tools that might be shared between objects.

* Attempt to secure a sense of how large the problem is; for example, how many main objects might there be?

* If in a team, argue about the top-level concepts; if an individual, argue with yourself.

* Finally, complete the ACOM application organizer card.

## Object Identification

* First, look for autonomous entities in the application. These should be both concrete and abstract entities. Time, for example, might be an abstract object.

* Make an ACOM class card for each object.

* Look for classes that can be created by specializing known classes in the class hierarchy. If designing as a team, ask team members to make suggestions about superclasses of the class that you have specified.
* Describe the prospective state of each object you wish to ultimately create. You will want to list all the names of all the possible variables that you might use on the class card.

* Look for class variables to see if there are any that are required to persist across all instances of a class.

## Object Behavior Specification

* What are all the object behaviors? Consider object role playing. Think of yourself as an object and ask yourself questions about what "I" should be able to do?

* See if you can identify general protocols that can be used to organize the methods.

* Name the messages that cause an object to perform in each protocol identified.

* Finally, for each method associated with each message, write a description of the explicit things that each method should do.

## Class Association, Coordination, and Examples

* Once a first pass of object identification and associated methods has been completed, organize all the cards produced and put the cards on a large table or on the floor. See if there are any obvious problems that require that cards be added or removed, such as multiple cards that define classes that permit description of the same object.

* Review the cards you have created and critique them. The review should include determining if you have identified cards that can be used to describe each object in the application. Then, for each object, communication issues should be examined. Look for and name all objects with which each object communicates. Is it clear in thinking through the object definitions that you have made that all have a purpose in the system? Are all defined objects needed?

* Draw a class hierarchy. To accomplish this task, consider the classes that you have created such as **FFTobject**. Determine if any
of these classes can share any functionality; if so, rewrite the card class-subclass information.

* Draw a whole-part hierarchy, if used. For this activity consider if the physical system that you are working with can be broken down into parts and described by a number of communicating, interacting objects.

* Determine if any coordination among objects is required. When coordination is required, create another ACOM class card that will explicitly handle coordination. For example, one could create an ACOM card called **ResourceCoordination**.

* Write examples for testing the behavior of objects created from the classes defined. Examples, at this point, can be English descriptions of how to test an object created.

## 3.5 Example Analysis of a Digital Circuit Simulator

This example presents a simple digital circuit simulator constructed to be able to observe the behavior of a collection of interconnected digital gates. To give a concrete example, suppose that we wish to simulate the circuit redisplayed in Figure 3.6 (previously shown in Figure 2.7) and would ultimately like to create a simulation system similar to the top-level view of the system shown in Figure 1.3. First, we need to specify the design intent (teleology). Briefly stated, the design intent could be

> The purpose of this example is to create a digital circuit simulator that will permit users to observe how signals propagate in a simulated digital circuit.

<figure><img src="image_32.png" /><figcaption>**Figure 3.6 A Simple Digital Circuit: A Half-Adder.**</figcaption></figure>
Next, the simulator should be named and the types of constituent objects identified. For example, this information might be

> The name of the simulation is *DigitalCircuitSimulation* and the primary objects to be included in the simulation should be named the same as those found in physical digital circuits.

Now, a specification of the function of the system and constituent objects is required. For example,

> The functionality of the example Digital Circuit Simulator is (1) to permit creation of simulated digital circuits that behave in the same way as real digital circuits, (2) to permit users to interconnect circuits, and (3) to observe the behavior of interconnected components.

An initial decomposition of the figure shown would reveal that we need only four primary objects to describe the entire digital circuits world shown: **Wire**, **AndGate**, **OrGate**, and **NotGate**. In fact, we can immediately

<figure><img src="image_33.png" /><figcaption>**Figure 3.7** Example Digital Circuit in Figure 3.6 Represented as Objects and Messages. (C = carry, S = sum.)</figcaption></figure>
translate the physical representation into a representation using objects as shown in Figure 3.7. In this representation, a wire is a full-fledged object, containing the local state of a value and its input and output connections. The task of a wire is to take an input and transfer that input directly to its output. Similarly, for each of the other objects, the task is to transfer the input to the output, modified by the constraint specified between the input and output. The term *constraint* refers to the constraining relationship that exists between the input and output terminals of a device. For an **AndGate**, the constraint is simply that the output is 1 whenever both inputs are 1, and 0 otherwise.

The figure shown in Figure 3.6 is called a "half-adder" and has the functionality shown in Table 3.4. This circuit does nothing more than add up the signals (0 or 1) attached to inputs A and B and produce a sum and carry on the two output leads. The leader is encouraged to trace signals through this circuit to verify its function and to consider the behavior of each object while conducting the trace.

Figure 3.8 displays the ACOM application card created for this simulation system. As shown, there is a **DigitalCircuitSimulation** class, an **AndGate**, **OrGate**, **NotGate**, and a **Wire**. The first class in this list is simply an organizing class that contains a dictionary that contains all the objects in the simulation and a dictionary of all the wires. Each of these classes has its own separate class definition card.

To make the representation somewhat simpler, one can recognize that *and* gates and *or* gates are basically similar except that each contains a different constraint, or relationship that needs to be maintained between the input and output. The similarity between the two gate types is that both specify input and output connections. Hence, one can specify another, more abstract class—a **TwoInputGate**—to serve as a superclass for different types of gates with two inputs. Once the characteristics of this gate are defined, this gate can be subclassed to create both an **AndGate** and **OrGate** with only the addition of the specification of the constraining relationships between the inputs and output. Figure 3.9 shows the class hierarchy for this simple relationship as well as the remaining objects in the system. Constructing a diagram of this type is often quite useful when the number of objects becomes large.

Figure 3.10 displays the ACOM cards for the five basic classes created and Figure 3.11 shows an example method card for the **OrGate** constraint. Of course, the remaining cards need to be created to complete the ACOM description of the digital circuit simulator. The complete code for the digital circuit simulator is contained in Chapter 10, as well as a description of how to implement the constraint relationships. Additional implementation information using this example will be given in Chapter 10 and a user interface for the system will be constructed in Chapter 13.
<table><caption>**Table 3.4 Functionality of Example Digital Circuit**</caption><thead><tr><td>Signal A</td><td>Signal B</td><td>Sum</td><td>Carry</td></tr></thead><tbody><tr><td>0</td><td>0</td><td>0</td><td>0</td></tr><tr><td>1</td><td>0</td><td>1</td><td>0</td></tr><tr><td>0</td><td>1</td><td>1</td><td>0</td></tr><tr><td>1</td><td>1</td><td>0</td><td>1</td></tr></tbody></table>

<figure><img src="image_34.png" /><figcaption>**Figure 3.8 Application Organization Card for the Digital Circuit Simulation.**</figcaption></figure>

<figure><img src="image_35.png" /><figcaption>**Figure 3.9 Object Hierarchy for Digital Circuit Simulation.**</figcaption></figure>
<figure><img src="image_36.png" /></figure>

<figure><img src="image_37.png" /><figcaption>Figure 3.10 ACOM Card Examples for the Digital Circuit Simulation System.</figcaption></figure>
<figure><img src="image_38.png" /></figure>

<figure><img src="image_39.png" /><figcaption>**Figure 3.10** *Continued*</figcaption></figure>
<figure><img src="image_40.png" /></figure>

<figure><img src="image_41.png" /><figcaption>**Figure 3.10** *Continued*</figcaption></figure>
<figure><img src="image_42.png" /><figcaption>**Figure 3.10** *Continued*</figcaption></figure>

<figure><img src="image_43.png" /><figcaption>**Figure 3.11** Example Method Card for the OrGate.</figcaption></figure>
## References

Beck, K., and W. Cunningham (1989). A Laboratory for Teaching Object-Oriented Thinking. *Proceedings of the Object-Oriented Programming Systems, Languages and Applications Conference*, 1-6.

Coad, Peter, and Edward Yourdon (1990). *Object-Oriented Analysis*. Prentice-Hall, Englewood Cliffs, NJ.

Cunningham, W., and K. Beck (1986). A Diagram for Object-Oriented Programs. *Proceedings of the Object-Oriented Programming Systems, Languages and Applications Conference*, 361-367.

Schlaer, Sally, and Steve Mellor (1988). *Object-Oriented Systems Analysis*. Prentice-Hall, Englewood Cliffs, NJ.

*Webster's Unabridged Dictionary*, (1990). Dilitium Press, New York.

## Exercises

3.1 Consider the concepts defined in Table 3.1. Select an example of your choosing and explain the four concepts in the context of your example.

3.2 The ACOM card problems:

a. Make copies of the ACOM cards given or produce cards yourself in the same or similar format.

b. Pick a physical object that you understand for analysis and follow the steps given in the chapter to produce a complete ACOM description of the object. Do not worry about the method code at this time; simply indicate what the method should do. The following is a list of possible objects to consider:

<table><tr><td>a hot water heater</td><td>gas heater</td><td>electric heater</td><td>wood stove</td></tr><tr><td>disk brakes</td><td>the heart</td><td>circulatory system</td><td>lung</td></tr><tr><td>myoelectric arm</td><td>nuclear reactor</td><td>vending machine</td><td>robotic device</td></tr><tr><td>communications network</td><td>touchtone phone</td><td>floppy disk</td><td>city simulation</td></tr><tr><td>chemical reactor</td><td>chemical reaction</td><td>flush toilet</td><td>hot tub</td></tr><tr><td>oscilloscope</td><td>voltmeter</td><td>car wash</td><td>parking meter</td></tr><tr><td>flying birds</td><td>seismograph</td><td>traffic light</td><td>traffic light system</td></tr><tr><td>antilock braking</td><td>cruise control</td><td>parking meter</td><td>ear</td></tr><tr><td>pencil sharpener</td><td>induction motor</td><td>television</td><td>radio</td></tr><tr><td>broom balancer</td><td></td><td></td><td></td></tr></table>

c. Repeat the analysis procedure that you just conducted with a group of people. Use the ACOM method in this group and argue about the characteristics
<figure><img src="image_44.png" /><figcaption>**Figure 3.12** A Full-Adder.</figcaption></figure>

tics of each card created. When you are done, compare what the group has done with the results you came up with in the previous problem. Did working in a group for this exercise help or hinder your efforts?

3.3 After completing the preceding exercise, throw the cards away (or just temporarily hide them) and start over. After completing a new set, compare your result with your first attempt. Were there any changes?

3.4 The **OrGate** initialization specification was provided in Figure 3.11. Write a similar method description for an **AndGate** and for a **NotGate**.

3.5 Extend the digital circuit example given in the chapter by creating ACOM cards for a full-adder circuit. A full-adder is shown in Figure 3.12.
# Introduction to Object-Oriented Design for Smalltalk-80

## 4.1 Design and Analysis

Analysis is part of design. In Chapter 3, methodologies for analyzing problems in terms of object definitions were examined. Using the object-oriented methodology presented, analysis of a problem leads to the creation of object definitions that can be ultimately turned into code. Design can be cast in various flavors. For example, the terms *conceptual design*, *architectural design*, and *implementation design* all have somewhat different meanings. Conceptual design refers to a loose organization of ideas and concepts that ultimately leads to the creation of an object. Architectural design is more specific, referring to a framework for the design, and implementation design refers to the actual specifications required to fabricate something. For most designs, the overall classification of *design* includes analysis as well as these three different levels of design specificity. For physical systems, design includes the analysis phase and ultimately includes all specifications needed to actually create the artifact specified. For example, design of an automobile would be complete when all specifications were available to build the car. In contrast, for object-oriented design of software in Smalltalk-80, the distinction between definition and fabrication is somewhat blurred. When the design includes behavioral specifications of the objects, it actually becomes runnable, thus implementing the design itself. In this text, the position is taken that for design of software systems, this situation is a desirable one; that is, the designed system should be an actual implementation. For traditional procedurally coded software systems (i.e., software composed of a sequence of steps), this position would be unreasonable. For object-oriented systems implemented in Smalltalk-80, it is logical. The reason is that procedural coding requires many steps that are not very close to
the actual design. In contrast, objects in object-oriented software systems mimic
the actual objects specified in the conceptual design.

In Chapter 3, analysis revealed the characteristics of objects needed to
create a *model* of an object being designed. The model, however, was insuffi-
cient to describe a complete system. A method for providing the user a way to
control the system (*controller*) and means of viewing the output of the system
(*view*) are required, in addition to the basic representation of knowledge and
data associated with the problem (*model*). Applications can be systematically
factored into these three components to provide an organizational framework.

A framework is useful for organizing a design. Several different
approaches for organizing components in a framework have been discussed in
the literature<fnref n="1" />; many are similar to the model-view-controller (MVC) methodol-
ogy used in Smalltalk-80. The approach taken in this text follows the methodol-
ogy utilized by Smalltalk-80 to organize these three aspects of design activity.
Aspects of the MVC paradigm have been described elsewhere (Krasner and
Pope, 1989; *Objectworks\ Smalltalk User's Guide*, 1990). This chapter attempts
to cast the use of the MVC framework into a design activity; that is, how one
designs what the user sees (the view), how control is implemented between the
user and a system (the controller), and how these aspects of a system are linked
to the model provided by analysis of the problem. The descriptions given here
are incomplete and lacking in detail; the intention of this chapter is to provide
concepts without the details, which will be supplied in subsequent chapters.

## 4.2 Major Design Aspects: The Model, the View, and the Controller

Figure 4.1 displays the basic model-view-controller (MVC) triad of
Smalltalk-80. Considerable information about this framework will be given in
this text, because the MVC provides unique cohesive facilities for creation of
complete systems. This chapter will discuss concepts related to the MVC and
subsequent chapters, especially Chapter 8, will provide additional details and
discussion about actual utilization of the MVC. Table 4.1 presents a capsule
summary of the specific features of the MVC triad that are important for
understanding the functionality of the three main components of the MVC.

### Model

The model is used to represent the data or knowledge about the
application constructed. A very simple model might be a list of several items, a

<footnote n="1">¹See, for example, Barth (1986), MacApp (1987), and Serpent (1989).</footnote>
<figure><img src="image_45.png" /><figcaption>**Figure 4.1** The Model-View-Controller.</figcaption></figure>

<table><caption>**Table 4.1** Features of the Model-View-Controller</caption><tr><td>Model</td><td>Represents the data or knowledge in an application</td></tr><tr><td>View</td><td>What the user sees on the screen</td></tr><tr><td>Controller</td><td>Provides the interface between the user and the system</td></tr></table>

dictionary, or a collection of some kind. More complex models might be network representations of information, rules, or pictorial information to display.

## Controller

The controller serves as the connection between the user and the computer system. In most cases, the controller need only handle input from the keyboard and the mouse, although it is possible to consider control from other input modalities such as speech or signals.

## View

The view is the display on the screen of the computer's monitor. In direct-manipulation interfaces (i.e., those interfaces that provide the user with the capability of directly manipulating objects on the screen), the view often
consists of collections of icons and windows that display information and are sensitive to a mouse-driven cursor. Subsequent chapters will describe the characteristics of such interfaces in depth.

A major idea in the MVC is the isolation of the model from the view and controller. Because the model normally represents a set of data or knowledge, it has no need to know how the controller or the view operates. Hence, the view can communicate information to the controller, and vice versa. However, the model is connected to the view in the following special way. When any change in the model is made, for example, updating a data value, the model should send itself a message that indicates that it has changed (*self-changed*). The model contains the ability to recognize that for every designated change it should send the view a message that indicates that the view should update (i.e., redisplay) itself. Hence, if the view is presenting some data contained in the model, it can modify the display on the screen each time information in the model is changed. Furthermore, the model can indicate to its dependents (i.e., those objects dependent on the model) what aspects of itself are changed. To give an example, imagine that a view contains graphs of five different sets of data points. Each graph might be a collection of numbers that are contained in a dictionary in the model. If a single value is changed in one of the graphs, the screen should be updated to reflect the change in data. One solution to updating what the user sees is to simply redraw the entire screen; however, this is inefficient. Hence, the MVC methodology permits indicating what aspect of the model has been changed, and by passing this information to the view, the view can differentially update itself. In the MVC paradigm, any model has associated with itself a collection of *dependents*, those objects that are dependent on the information in the model. Because the view is dependent on the information in the model, it is a dependent of the model and should be updated when the model is changed in some way. In Chapter 8, additional information about these ideas and examples will be given.

## Alternatives to the MVC

As mentioned previously, there are various alternatives for factoring a design framework into logical parts, such as the model, view, and controller. For example, Serpent (1989) breaks a system into three parts: the presentation layer, the dialogue layer, and the application layer. The application layer is equivalent to the model of the MVC, the dialogue layer contains a mix of presentation and control functionality, and the presentation layer controls the screen layout (equivalent to the view). Serpent supports X-Windows (Schiefler, Gettys, and Newman, 1989) and may be used with applications written in C or Ada. Apple's MacApp implements Macintosh user interfaces. The names utilized for the
<table><caption>**Table 4.2** Examples of Representation Alternatives for Use in Model</caption><thead><tr><td>Class Name</td><td>Description</td></tr></thead><tbody><tr><td>Array</td><td>Sequenceable (i.e., having sequence) collection whose elements are any object</td></tr><tr><td>OrderedCollection</td><td>Ordered objects, e.g., a queue is an example of an ordered collection of objects</td></tr><tr><td>SortedCollection</td><td>Objects sorted by a criteria, e.g., alphabetic or numeric</td></tr><tr><td>Bag</td><td>Unordered collection with duplicate elements allowed</td></tr><tr><td>Set</td><td>Unordered collection with no duplicates</td></tr><tr><td>Dictionary</td><td>Unordered, hashed, using keys and values to associate objects</td></tr><tr><td>String</td><td>Text</td></tr></tbody></table>

framework are different from the MVC, but the functionality is essentially the same. Finally, InterViews is a graphics user interface tool kit (Linton, Vlisides, and Calder, 1989) that consists of a library of C++ (Stroustrup, 1986) classes for implementing user interfaces. InterViews employs three classes for building interfaces: interactive objects, such as buttons and menus, structured graphics objects, and structured text objects. These classes are combined with application code to produce an executable application. The concepts employed are not the same as the MVC methodology and represent an alternative methodology. In this text, the focus will be on the MVC methodology because it represents the oldest and probably best understood method for implementing application frameworks.

## 4.3 Model Design

Designing a model requires knowledge about possible types of knowledge or data structures that can be used for a model. Models can be of almost arbitrary complexity, ranging from an object that holds only one number to complex networks or rule systems. Table 4.2 shows some typical classes that can be used for model representation. These classes are among the most commonly used classes in Smalltalk-80 employed for representing information. Possibly the most useful are the collection classes, which include such classes as **Array**, **OrderedCollection**, and **SortedCollection** as shown in the table. Class **SequenceableCollection** is an abstract superclass of these classes, which each have a well-defined ordering of their elements. The naming of these classes follows almost-commonsense conventions; that is, an array is simply a sequence of elements with integer keys, an ordered collection is a sequence of elements that maintains an order, and a sorted collection maintains the collection in a sorted
order according to some type of sorting criterion. The primary design decision for determining the kind of model (or models) to use is based on what it is that you wish to represent. Lists of items are quite easily represented as an ordered collection, which is nothing more than a list of objects that are maintained in order. Note that in the object-oriented paradigm an object can be of arbitrary complexity. Hence, an ordered collection of objects might actually contain a great deal of information in the form of complex objects stored in order. Sorted collections are useful when one needs to sort items according to some scheme—time, for example. Other types of collection classes are frequently useful such as **Bags**, **Sets**, and particularly **Dictionaries**, as defined in the table. Dictionaries are frequently used for storing keyed associations between items.

More complex information representation may be used as a model. For example, a semantic network could serve as a model. A semantic network is a classical artificial-intelligence-based representation paradigm used for representing declarative knowledge. Consisting of nodes and links, a semantic net-

<figure><img src="image_46.png" /><figcaption>**Figure 4.2** A Semantic Network as a Representation Model. [After Bourne et al. (1989).]</figcaption></figure>
work is a labeled directed graph that attempts to capture meaning while describing objects. Consider Figure 4.2 as an example. This network represents inheritance information about electronic components. Information about electronic devices and semiconductors in general is stored at the top level. Arranged in a hierarchy, the objects in each node of this hierarchy inherit information from objects higher up in the hierarchy. At the lowest level, objects such as the BJT (bipolar junction transistor) inherit information from all the node above it. Circled with a bold line in this figure is 2N2222, which is a specific kind of transistor and is an instance of an NPN transistor. Networks of this type can be used to represent semantic information (i.e., meaning).

<figure><img src="image_47.png" /></figure>

<figure><img src="image_48.png" /><figcaption>**Figure 4.3** Using Dictionaries for Representation. (a) A Simple Dictionary with Keys and Text for Values and (b) Dictionary Inspectors Showing the Use of Dictionaries for Representing Tree Structures.</figcaption></figure>
Figure 4.3 shows how dictionaries can be employed as a model for a complicated information storage problem. Figure 4.3a shows the simplest possible use of a dictionary, using the keys to track information that is stored in the values associated with the keys. An address book is an easy example to understand; the keys would be the names of people, for example, and each value associated with a key would contain addresses and phone numbers. Because values can contain any object, it is a short step to extend the representation power of dictionaries to multiple levels. Figure 4.3b shows that the value associated with a particular key might contain an ordered collection of objects which are each dictionaries. In turn, each of these dictionaries might contain keys which have values that are dictionaries. This progression could go on to any level and provides an easy way to represent large hierarchies of information.

## 4.4 View Design

Views are what the user sees on the screen within host windows. Various software components can be employed to construct views. The most

<figure><img src="image_49.png" /><figcaption>**Figure 4.4** Tiled and Overlapping Views. View1 overlaps View2; the contents of each view is tiled.</figcaption></figure>
common types of elements are lists, buttons, icons, text windows, graphic representations of things, gauges, and so forth. In a windowing system, a view may consist of "tiled" and/or "overlapping" views. A tiled view refers to a window that has smaller pieces of the view placed like tiles of different sizes. In Chapter 1, several examples of tiled views were shown. Overlapping views are allowed to overlap, the top view obscuring the one below it. Typically, information about hidden parts of a view are stored so that if the top view is moved, collapsed, or closed, the view below can be seen. Figure 4.4 shows the way two tiled and overlapping views might appear on a computer screen.

Figure 4.5 presents a first look at a concept which will be described in detail in subsequent chapters. The concept is that one can have many different classes that represent different kinds of views which can be put together using a "view builder" system to build any kind of view with the desired characteristics for an application. At the top of the figure is shown a "view library," basically a

<figure><img src="image_50.png" /><figcaption>Figure 4.5 The ViewBuilder Concept.</figcaption></figure>
visual representation of the classes that are in a system which can be used to build specific application views. These classes are shown funneling into a "view compiler," with a graphics interface to the compiler shown to the right. Finally, at the bottom of the figure is shown the final completed tiled view, which includes several of the view types shown in the library at the top of the figure. The primary concept is to permit a user to build application views by simply "picking and placing" views at various parts of an empty canvas. The complier collects information about where the user wants to put things and then, using this information, generates the code needed to actually create the view. This technique is explained in later chapters and an example is presented for building an interface to a model.

The issue of what to put in a view depends entirely on the needs of the user. For example, if items are to be selected from a list, a list view should be selected. If text is to be portrayed or images shown, views that support the display of such things will be required.

## 4.5 Controller Design

Controllers provide the interface between the user and the view contained in a window. By continuously interpreting the location of the cursor within a window and monitoring which of the buttons on the mouse or keys on the keyboard are pressed, information about the intentions of the user can be passed to model and view of the MVC triad. Figure 4.6 displays the controller

<figure><img src="image_51.png" /><figcaption>Figure 4.6 Control Methodology Outline.</figcaption></figure>
methodology used in Smalltalk-80. In this figure only the controller is shown at the top of the figure and the dotted lines show links to the model and view of an application. Once a message called *startUp* is sent to a controller, the controller is initialized, goes into a control loop, and completes with a termination routine. In the *controlLoop*, polling is carried out to see if there has been any activity. If there has been no activity for a long time, a flag (semaphore) is set to indicate that polling can wait until a signal is received, indicating that there is activity. Next, when activity resumes, one default behavior is to check to see if the cursor is in a view and that a cursor button is not pressed. As long as these latter conditions are true, the controller associated with the view within which the cursor is located is active. When the cursor is moved to different views, the controller associated with the view that contains the cursor becomes active.

## 4.6 Maxims for Design of Systems Using the MVC Triad

### Model Maxims

If possible, choose a representation for the model that is easy to understand, for example, an instance of the **Dictionary** or **OrderedCollection** classes. Many other, more complex representations can be built from the common representation building blocks (i.e., classes) that are available in Smalltalk-80. For example, a tree can be built by using multiple dictionaries.

To ease viewing objects, choose a representation that is easily inspectable. Inspectors permit you to view graphically the contents of an object on the screen, a clear benefit for debugging and understanding. All basic objects in Smalltalk-80 can be inspected; however, complex models that you create may require creating inspectors that permit simple viewing of the parts of the model that need to be observed. A number of the common collection classes provide special capabilities. For example, in Smalltalk-80, both the **Dictionary** and **OrderedCollection** classes have inspectors.

Remember that the model is not directly connected to the view, but communicates with the view by sending *update* messages (details will be given in Chapter 8). Hence, in specifying the model, one only has to be concerned with the structure of the knowledge and data that are to be used in the design.

Complex models may be needed for various representations; models of any complexity can be employed and different aspects of a model can be assessed by the view or different views. This idea permits using a complicated model for different purposes. For example, a model of an automobile might be used for different purposes, such as determining performance or cost. It is useful to capture such multiple perspectives in a model of an entity, while retaining the ability for the model to be viewed from different perspectives.
## View Maxims

Views can be cluttered or uncluttered. For example, a view can have many buttons, lists, and pop-up or pull-down menus. Some applications may need to maximize drawing space on the screen (e.g., drawing schematics, etc.) and should use pop-up or pull-down menus.

A cluttered view with all the actions available to the user is easier to use than a view with pop-up or pull-down menus. An uncluttered view that employs pop-up or pull-down menus is more difficult for novices to use.

Pop-up and pull-down menus give more flexibility of control to the designer. This is especially true for hierarchical menus (i.e., menus that have selections which, when selected, produce other menus; see Chapter 8).

Views that scroll back and forth and up and down within a window or a part of a window are useful for presenting information in a small space.

Icons (small images that represent something) are useful for imparting visual information to the user of a system. The designer should consider if significant assistance in helping a user employ the system could be gained by using icons. See Chapter 7 for a discussion of user interface issues.

The size of the presentation for a screen view should be as large as needed to adequately represent what is to be shown. If the screen is too small, users will have a difficult time actually using the system. However, one solution is to permit windows to zoom in and out easily, a feature found in most windowing systems.

## Controller Maxims

Use default controllers; they will normally work for most things. Most views specify a default controller. If you wish to include special control features, these can be added as your system is refined. However, remember that some views will not need a controller; for example, views that present something, such as text, which does not require interaction with the user.

## 4.7 Example View Design Scenarios for Digital Circuits

Figures 4.7a, b, and c show a few alternatives for designing views for a digital circuit simulator system. The view shown in Figure 4.7a is the same as the view shown in Figure 1.3. The primary design feature of this view is that all actions that the user can take are observable on the screen, presented by labels in buttons that can be pressed to initiate the desired action. For example, pressing "load" will pop up a message asking for a file name so that the
<figure><img src="image_52.png" /></figure>

<figure><img src="image_53.png" /></figure>

<figure><img src="image_54.png" /><figcaption>**Figure 4.7** Different Interface methodologies for the Digital Circuit Simulator Example. (a) Design Using Push Buttons, (b) Design Using a Pop-up Menu, and (c) Design with Pull-Down Menus.</figcaption></figure>
specified file can then be loaded. Icons that can be used to create circuits are shown on the left side of the screen, also in buttons. When the user clicks on one of these icons, an icon with the same image moves with the cursor to the drawing canvas. The use of the icon representation lends some degree of schematic reality to the construction of circuits in this view design.

Figure 4.7b shows an alternative to Figure 4.7a. The area on which the user can construct a circuit is much larger, due to the lack of control buttons. Control is provided via a pop-up menu. The pop-up menu is activated by pressing a mouse button; by moving the cursor the user can then select an item in the menu and the appropriate action attached to the menu item will be carried out. A so-called "walking menu" or hierarchical menu is shown. The hierarchical menu is the same as a normal list-style menu but each item in the list, if selected, can produce yet another list, which, in turn, can pop up additional menus. Because each list is positioned to the right of the calling menu item, the lists appear to "walk" across the screen. Chapter 8 will provide information on how to use such menus.

Figure 4.7c shows how a pull-down menu would be used for this same application. Arrayed across the top of the view are items, each of which have submenus that "pull down" when selected. The pull-down menu is essentially the same as the hierarchical menu, except it is spatially rearranged. This type of menu has been popularized by the Macintosh computer and is found in many end-user application programs such as Pagemaker (Aldus, 1990).

Table 4.3 summarizes the different design considerations for the examples shown in Figure 4.7. Much more detailed information about views and coupling views to the user will be given in Chapter 7.

<table><caption>**Table 4.3** Design Decisions for View Interfaces Shown in Figure 4.7</caption><thead><tr><th></th><th></th></tr></thead><tbody><tr><td>Design A</td><td></td></tr><tr><td>Push-button model</td><td>Easily observable actions<br>Takes excessive screen space<br>Relatively cluttered view</td></tr><tr><td>Design B</td><td></td></tr><tr><td>Pop-up menu mode</td><td>Uncluttered view<br>Gives maximum screen space<br>User needs to recall how to pop up menu</td></tr><tr><td>Design C</td><td></td></tr><tr><td>Pull-down menu model</td><td>Uncluttered view<br>Covers view in fixed places</td></tr></tbody></table>
## 4.8 Summary

So, what is design? Design, as presented here, is the sequence of steps needed to produce a complete specification that can be used to create a system. Analysis is a precursor to and an integral part of design. Designs are facilitated by operating within a framework, such as the MVC triad, discussed previously. What are the steps that are taken to create a design? First, conceptual design organizes concepts about the object or class of objects being designed. Second, a rough idea about how to represent and display the designed object can be secured by casting the design requirements into an organizational framework. The MVC organizational framework is useful for this purpose, although other less specific techniques could work equally well. Third, data and knowledge structures are identified for the model and existing data structures selected or a new representation created. Fourth, control and presentation methods are specified and linked to the data/knowledge representation. These specific techniques represent the way that Smalltalk-80 is used for application software design. The ideas of factorization and the linking of a representation structure with what the user sees and how the user interacts with the system are general purpose. Indeed, these techniques can be used to understand many types of software interface design problems.

## References

Aldus (1990). *Pagemaker 3.01*. Aldus Corporation, Seattle, WA.

Apple Programmer's and Developer's Assoc. (1987). *MacApp: The Expandable Macintosh Application*. Renton, WA.

Barth, R. S. (1986). An Object-Oriented Approach to Graphical Interfaces. *ACM Transactions on Graphics*, Vol. 5, No. 2, April, 1986, pp. 142-172.

Bourne, John R., J. Cantwell, A. J. Brodersen, B. Antao, A. Koussis, and Y.-C. Huang (1989). Intelligent Hypertutoring in Engineering. *Academic Computing*, September, 1989, pp. 1-47.

Brown, J. R., and S. Cunningham (1989). *Programming the User Interface*. Wiley, New York.

Krasner, G. E., and S. T. Pope (1988). A Cookbook for Using the Model-View-Controller User Interface Paradigm in Smalltalk-80. *Journal of Object-Oriented Programming*, Vol. 1, No. 3, August-September, 1989, pp. 26-49.

Linton, M. A., J. M. Vlisides, and P. R. Calder (1989). Composing User Interfaces with InterViews. *Computer*, February, 1989, pp. 8-22.
Objectworks \ *Smalltalk User's Guide*, Release 4 (1990). ParcPlace Systems, Mountain View, CA.

*Serpent Overview* (1989). Software Engineering Institute, Carnegie Mellon University, CMU/SEI-89-UG-2, Pittsburgh, PA.

Schiefler, R. W., J. Gettys, and R. Newman (1989). *X Window Systems: C Library and Protocol Reference*. Digital Press, Maynard, MA.

Stroustrup, B. (1986). *The C++ Programming Language*. Addison-Wesley, Reading, MA.

## Exercises

4.1 The MVC paradigm appears to be a logical way of factoring the elements needed to create software systems of the type discussed in this and previous chapters. Are there any alternative ways to do the same thing? Investigate some other common methods and see if you agree or disagree that all problem factorization can be reduced to the MVC paradigm. (Hint: A good place to start looking for this information is in some of the references given; e.g., Schiefler, Gettys, and Newman and the Apple reference.)

4.2 A primary consideration in model design is the structure of the model. Explain how the collection classes allow programmers to concentrate more on the design of the model structure rather than the implementation code.

4.3 For each of the collection classes in Table 4.2, describe the particular features of each class and give an example of how each could be used in an application. (Hint: It will be helpful to examine the collection classes using the Smalltalk browser and to read examples in the tutorial manuals or other references given in Chapter 1.)

4.4 Given the description of a dictionary as a set of associations made up of keys and values, draw a diagram of how you could create a tree using dictionaries.

4.5 Select an example system to be created (or perhaps a system that you have seen somewhere else, e.g., Hypercard on the Macintosh). Discuss how to describe this problem in terms of the MVC.
# Part Two
# The Tools

Chapters 5 through 8 present tools that can be used for creating object-oriented systems. Although the focus of these chapters is on the use of the Smalltalk-80 language and environment, other alternative languages and environments will be mentioned. Chapter 5 briefly reviews conventional computer languages and examines object-oriented extensions to several languages, compares object-oriented languages, and briefly presents the syntax of Smalltalk. Chapter 6 examines the Smalltalk environment and classes. Chapter 7 provides a look at methods for user interface design, and finally Chapter 8 provides an in-depth examination of tools in Smalltalk-80 that can be used for building applications.
<figure><img src="image_55.png" /></figure>
# Object-Oriented Languages

This chapter begins by reviewing the characteristics of several common procedural languages that have been used in engineering during the last several decades. A number of these languages have been extended to include the object-oriented paradigm and new languages have emerged that support the object-oriented methodology.

## 5.1 Procedural Languages and Object-Oriented Enhancements

Table 5.1 presents a list of nine popular languages that have been used in engineering during the last three decades [see MacLennan (1983) for extensive descriptions of several of these languages]. The longevity of each language along with some notable features and a list of object-oriented extensions, if any, are given. Each language is discussed briefly next.

### Fortran

John Backus of IBM and three associates are credited with creating the specification for Fortran in 1954. Fortran (FORmula TRANslating System) was initially designed in the course of Backus' work on producing an efficient compiler. The language specification was almost a by-product of this work. Fortran is a compiled language in which source code is compiled, individual modules linked, and the linked code is loaded into memory and finally executed. With an emphasis on efficiency of implementation, Fortran has been very popular for production programs and is still widely used although its popularity
<table><caption>**Table 5.1** Principal Computer Languages and Object-Oriented Extensions</caption><thead><tr><th>Language</th><th>Year Initiated</th><th>Primary Features</th><th>Object Extensions</th></tr></thead><tbody><tr><td>Fortran</td><td>1954</td><td>Scientific programming applications; efficient implementations</td><td>None</td></tr><tr><td>Algol</td><td>1958</td><td>Similar to Fortran notation; strong typing</td><td>None</td></tr><tr><td>Lisp</td><td>1958</td><td>Functional notation; rich, large environment</td><td>Flavors, CLOS, Common Loops</td></tr><tr><td>APL</td><td>1962</td><td>Mathematical notation; dynamic binding</td><td>None</td></tr><tr><td>Pascal</td><td>1968</td><td>Simple syntax; strong typing</td><td>Object Pascal, Turbo Pascal</td></tr><tr><td>Smalltalk</td><td>1971</td><td>Object-oriented; large environment</td><td></td></tr><tr><td>C</td><td>1972</td><td>General purpose; weakly typed</td><td>C++, Objective-C</td></tr><tr><td>Prolog</td><td>1972</td><td>Logic-based; declarative</td><td></td></tr><tr><td>Ada</td><td>1979</td><td>Strong typing; rich, complex, and large</td><td>InnovAda</td></tr></tbody></table>

has eroded significantly during the last decade. Fortran is decidedly nonobject oriented, exhibiting virtually none of the characteristics that make a language object oriented, as described in Chapter 2. However, one can argue that Fortran has a very primitive form of support for encapsulation, as manifested in subroutines that permit multiple entry points.

## Algol

Algol was designed, beginning in 1957, in a quest to create a universal programming language. Simple, elegant, and general, Algol is a strongly typed<fnref n="1" /> language that was designed for scientific computation. A statically bound<fnref n="2" /> language, Algol uses declarative and imperative constructs similar to Fortran.

<footnote n="1">¹The term *type* refers to a group of expressions that share a common characteristic, for example, integer or floating-point numbers. *Strongly typed* means that the type of any expression in a language can be determined. Conversely, *untyped* means that there is no type. *Weakly typed* means that the type of an expression can sometimes be determined.</footnote>

<footnote n="2">²Binding refers to whether the attributes of expressions are determined at compile time. A computer language is said to be *statically bound* if its expressions are determined at compile time whereas a language is said to be *dynamically bound* if its expressions are not determined until run time.</footnote>
Although similar to Fortran, Algol never achieved widespread use in the United States and there are no object-oriented constructs in the language. Simula (Birtwistle et al., 1973), however, was designed to be an object-oriented extension of Algol.

## APL

APL (A Programming Language) was created in 1962 (Iverson, 1962) and enjoyed some popularity. APL provided a concise mathematics-like notation, dynamic binding, and provided some early experience with an operating environment for the language.

## Lisp

Lisp (List Processing) was designed in the late 1950s to support symbolic programming in artificial-intelligence applications. Lisp is an applicable language in contrast to the imperative languages described previously. Imperative languages rely on assignment and changeable memory to accomplish a programming task. In contrast, applicative languages work on the principle of applying a function to arguments. A principal goal of Lisp was to allow manipulation of symbols, often represented as lists. Originally, Lisp was an interpreted language; in the 1980s, most Lisp versions added compilation capabilities. Lisp is currently the language that is used most frequently for artificial-intelligence research and applications. There are numerous Lisp varieties and Lisp serves as the basis for many AI tools. Flavors (Moon, 1986) was one of the early object-oriented extensions to any language and still serves as a object-oriented programming vehicle in Lisp. Common Lisp Object System (CLOS; Bobrow et al., 1988) is an emerging standard for object-oriented methodologies in CommonLisp (Steele, 1984).

## Pascal

Pascal, a successor to the ideas in Fortran and Algol, was explicitly designed to teach programming. Initiated in 1968, Pascal remains a principal language for teaching high school and college students how to program. Strongly typed with basic Algol and Fortran-style primitive data types (reals, integers, Booleans, etc.), Pascal has been extended to include object-oriented constructs. For example, Object Pascal (Snyder, 1986) and Clascal (Schmucker, 1986) have
added object-oriented constructs. Popular Pascal packages such as Turbo Pascal (Borland, 1990) have also added object-oriented features.

## Smalltalk

Smalltalk grew from the vision of Alan Kay in the late 1960s (Kay, 1977). Based on concepts from Simula (Birtwistle, 1979) and Logo (Papert, 1980), Smalltalk began as a research effort about 1970. A wholly object-oriented language, Smalltalk has developed since the early 1970s into a combination programming language and environment. Smalltalk has served as a model for many modern object-oriented programming languages, yet still retains a significant position in the object-oriented programming environments market due, in part, to the robustness of its large class library. Smalltalk is suitable for use in many applications and is especially useful for rapid prototyping and creating graphics interfaces. Smalltalk is a "pure" object-oriented language exhibiting all four fundamental characteristics: abstraction, encapsulation, inheritance, and polymorphism.

## Prolog

Prolog (Clocksin and Mellish, 1984) is based on logic programming. Developed in France in the early 1970s, Prolog (Programming in Logic) has experienced wide acceptance in Japan and France, as well as limited success in the United States. Although it was once thought by some that Prolog could supplant Lisp as a leader in artificial-intelligence (AI) work, this promise did not materialize. Prolog is a declarative language in which logic statements are made according to a specified syntax. The Prolog interpreter attempts to unify declarations, that is, to find variables that, when substituted into terms (i.e., data objects), make the terms become identical. Prolog is essentially a backward-chaining rule system. If declarative rules can be written as a problem description, the internal control of a Prolog system can then attempt to unify the statements. An advantage to Prolog is that it is entirely declarative; there is no need to encode control information. For this reason, Prolog has been popular among AI programming novices.

## C

C is a programming language that is the native language used in implementing the UNIX operating system. C was developed in the early 1970s
by Dennis Ritchie at Bell Laboratories and has become in the following decades one of the most popular general-purpose programming languages. Some of the hallmarks of C are that it is a relatively small language, and it is terse, modular, and portable. It is a weakly typed language. Compilation of C produces machine code that approaches the efficiency of assembly-language coding. In applications in which time is a critical factor, C has become the language of choice in many industries. There are many flavors of C including object-oriented varieties such as Objective-C or C++, which will be discussed in the next section.

## Ada

In the mid-1970s, the United States Department of Defense supported the development of a next-generation programming language that would support top-down software design. A primary concern was to provide modularity and information hiding in order to reduce the amount of time needed to create large software systems. The language created was Ada, named in honor of Augusta Ada, Countess of Lovelace, said to be the world's first programmer. In the context of the definitions of object-oriented programming given in Chapter 2, Ada is not a true object-oriented language because it does not support inheritance, yet it has support for data abstraction and information hiding. There has been some work to add additional object-oriented features [see, e.g., Simonian and Crone (1988)].

## 5.2 Major Object-Oriented Languages

There are many object-oriented languages. Saunders (1989) reviewed some 88 object-oriented languages, most having academic roots and 16 of which were commercially available. A review of all these languages will not be attempted here; instead, only a handful of the most important languages, divided into four categories will be discussed. These categories are the C-oriented systems, the Lisp-related systems, the Smalltalk systems, and other types. The primary purpose of these descriptions is to convey the types and capabilities of object-oriented languages. An explicit attempt is made to compare the systems to the capabilities of Smalltalk.

Table 5.2 presents a summary of eight object-oriented languages, two from each category mentioned previously. The first two items are two Smalltalk versions: (1) Objectworks \ Smalltalk (ST-80) by ParcPlace Systems, which is used for most examples in this text, and (2) Smalltalk/V created by Digitalk. The C-oriented languages examined are C++ and Objective-C. Lisp entries are
<table><caption>**Table 5.2** Examples of Several Object-Oriented Programming Languages</caption><thead><tr><td>Name</td><td>Description</td></tr></thead><tbody><tr><td>Smalltalk-80</td><td>Commercial object-oriented system for workstations, PCs, Macintoshes. From ParcPlace Systems.</td></tr><tr><td>Smalltalk/V</td><td>Commercial object-oriented system for PCs and Macintoshes. From Digitalk.</td></tr><tr><td>Objective-C</td><td>Object-oriented extension of C with several class libraries. From Stepstone Corporation.</td></tr><tr><td>C++</td><td>Object-oriented enhancement to C. AT&T and others.</td></tr><tr><td>Flavors</td><td>Early MIT-developed object-oriented extension to Lisp Weinreb and Moon (1980).</td></tr><tr><td>CLOS</td><td>Common Lisp Object System — an extension to Common Lisp. Franz, Inc., Lucid, Inc., and others.</td></tr><tr><td>Eiffel</td><td>Object-oriented language emphasizing class structures. From Interactive Software Engineering, Goleta, CA.</td></tr><tr><td>Actor</td><td>A PC-based object-oriented system with strong similarities to Smalltalk. From The Whitewater Group.</td></tr></tbody></table>

Flavors and Common Lisp Object System (CLOS) and, in the miscellaneous language category, Eiffel and Actor are briefly reviewed.

## C-Oriented Systems

C++ was designed by B. Stroustrup in the early 1980s at Bell Laboratories. C++ adds support to C for data abstraction and provides various improvements to the C language, such as strong type checking. C++ is based on the C language (Kernighan and Ritchie, 1978, 1988), but adds inheritance.

C++ has achieved a wide following in the programming community, presumably because of the large number of C programmers who exist in this country. Most current versions of C++, however, have no built-in integrated programming environment and must use the features of whatever operating system with which they are used. Furthermore, no class libraries are part of the original C++, although efforts have been made to create libraries for use with C++ [see, e.g., InterViews by Linton, Vlisides, and Calder (1989)].

Objective-C, created in 1983 by Productivity Products International (PPI), now the Stepstone Company, has achieved a significant level of prominence in the object-oriented marketplace. Several features contribute to Objective-C's success. First, class libraries that implement easily understandable classes (e.g., **Dictionary**, **Array**, **Set**, etc.) are provided which give the user some reusability capability. Sixteen classes are provided with the basic system and
<table><caption>**Table 5.3** An Example of Flavors Programming [Concepts from Weinreb and Moon (1980)]</caption><tr><td>(defflavor moving-object (x y xVel yVel mass) () )</td></tr><tr><td>(defflavor ship (enginePower numberPassengers name) (moving-object))</td></tr><tr><td>(defflavor meteor (ironPercentage) (moving-object))</td></tr><tr><td>(defmethod (ship :speed) () (sqrt (+ (xVel 2) (yVel 2)))))</td></tr><tr><td>(defmethod (ship :direction) () (atan yVel xVel))</td></tr><tr><td>(setq myShip (make-instance 'ship ':engine-power 300 ':numberPassengers 2000 ':name Titanic))</td></tr></table>

more can be purchased for implementing user interface functions. The syntax of Objective-C is more easily understood than C++, and is perhaps closer on the phyloprogrammatic scale to Smalltalk than to C or C++.

## Lisp-Related Systems

Flavors was reported in 1980 (Weinreb and Moon, 1980) as an extension to Lisp for the Symbolics Lisp Machine. The name is said to come from an analogy to the creation of different flavors of ice cream confections that could be created by "mixing in" additional flavor components to a base flavor. The "mixing in" idea is equivalent to inheritance. Flavors simply extends Lisp by adding additional functions that permit defining and manipulating objects. Table 5.3 gives a simple example of some definitions in Flavors. Like the enhancements to C, Flavors is a language extension, not an object-oriented language in its own right.

The syntax for the code shown in Table 5.3 is somewhat simplified from the actual Flavors code, but the intent is the same. In the same way as inheritance was discussed in Chapter 2, Flavors provides in this example for the description of a ship as a subclass of a moving object. The definition syntax defines the name of the object, followed by an instance variable, then by the name of the superclass that is to be inherited ("mixed in"). In the case of the moving object, there is no object to inherit from; in the remaining definitions, inheritance is from the moving object. Methods are defined separately from the structure definition. In this example, two methods are defined, one for finding the speed and the other for finding the direction of a ship. Finally, an example of defining myShip as an instance of ship with explicitly defined variables is shown.

The Common Lisp Object System (CLOS) (Keene, 1989) is similar to Flavors in that the system is an extension to a Lisp language. CLOS differs from Flavors in that it is much better developed, containing numerous features
that Flavors does not have. CLOS is emerging as an object-oriented standard for use with CommonLisp. There are a number of other Lisp extensions [see, e.g., Saunders (1989)].

## Smalltalk Systems

ParcPlace Systems' Smalltalk-80 is the oldest and most complete object-oriented programming language and environment. ST-80 is available for a variety of different computer platforms including the PC, Macintosh, HP/Apollo workstation, Sun, and DEC workstations. An outstanding feature of this system is the ability to run transparently across the different platforms. In other words, code generated on one system will run without change on all the other hardware platforms. ST-80 was marketed by Xerox and other licensees (e.g., Tektronix, Fuji) until the late 1980s. ParcPlace Systems was created in 1986 as a separate business unit associated with Xerox Palo Alto Research Center (PARC). In 1988, ParcPlace Systems became an independent corporation and now distributes Smalltalk-80 as one of several software products.

Smalltalk/V (V stands for Virtual) is the principal competitor to Smalltalk-80. Marketed by Digitalk, ST/V runs on PC and Macintosh systems. ST/V has a smaller number of classes than ST-80, and requires less memory to run. In 1989, Digitalk introduced a version of ST/V that runs with OS/2 and can produce standalone applications, a feature that stirred some excitement in the object-oriented community at the time.

## Other Object-Oriented Languages

There are a number of object-oriented languages that do not easily fit into either of the three categories listed previously. For example, Eiffel (Meyer, 1988) is a basic object-oriented language that features strong typing to help programmers ensure correctness and robustness of their software. Eiffel runs on various versions of UNIX and uses C as intermediate code, making Eiffel potentially portable to any machine that will run C. Actor (1989) is a software product that runs on PC-class machines and has many of the attributes of Smalltalk in a personal computer environment. Actor, however, should not be confused with research on "actor languages" which is concerned with the study of multiple independent computational agents.

## General Observations and Comparisons

Object-oriented languages, having become increasingly popular during recent years, can be found in many different varieties. Naturally, there is
considerable controversy about which features are best and, of course, the answer to this normally is linked to one's perspective. For example, a person learning about object-oriented methods who has a strong C programming background will naturally gravitate to one of the object-oriented extensions to C. Similarly, Lisp aficionados will prefer Flavors or CLOS to other language varieties. People who have a preference for Smalltalk are likely to be less efficient conscious but have a high interest in reusability and productivity.

In terms of size of memory usage and speed, the C-related languages have a distinct advantage because C code will normally produce compact and fast code—a clear advantage in many situations. However, almost none of the C-related languages have robust environments that support debugging, editing, and understanding programs, features that are supported much better by both the Lisp and Smalltalk environments.

In terms of facilities, both Lisp and Smalltalk have excellent environmental support, including excellent debugging facilities. Smalltalk-80 has an incremental compilation facility that compiles methods as they are defined; this capability makes it appear to the programmer that the compilation phase of programming is avoided. Both Lisp and Smalltalk have automatic garbage collection facilities, a capability not found as a standard feature in other languages surveyed. In brief, garbage collection refers to the system capability for automatic reclamation of memory space occupied by lists (Lisp) or objects (Smalltalk) which are no longer in use.

For reusability, the different Smalltalk systems are markedly better than any of the other languages that have been discussed. A large number of classes makes it possible for the programmer to reuse facilities that come with the system without reprogramming, an often huge savings in time.

## 5.3 The Syntax of the Smalltalk Language

The Smalltalk language is small, simple, and easy to use to write programs. This statement contrasts with a common perception that Smalltalk is difficult to understand and use. Both the first statement and the perception are correct. The explanation is that, indeed, the *language* part of Smalltalk is small, simple, and easy to use. However, the *environment* part of Smalltalk, including all the classes that exist, is large and requires a considerable effort to learn. This section will examine some features of the language and Chapter 6 will explore the environment, including a description of the tools and classes that are part of the ST-80 environment. The reader is referred to texts that review Smalltalk syntax in depth [see, e.g., LaLonde, Wilf, and Pugh (1990); Goldberg and Robson (1989), and Pinson and Wiener (1988) for more details].

Tables 5.4 and 5.5 summarize some of the main syntax features for Smalltalk-80. Language syntax for other varieties of Smalltalk, for example,
<table><caption>**Table 5.4** The Syntax of Smalltalk-80: Literals</caption><thead><tr><td>Types</td><td>Examples</td></tr></thead><tbody><tr><td>Numbers</td><td>35 8r177 16rFE 2r0100010 1.5e6 3.14</td></tr><tr><td>Character</td><td>$b</td></tr><tr><td>String</td><td>'This is a string'</td></tr><tr><td>Symbol</td><td>#book #update</td></tr><tr><td>Array</td><td>#(1 2 3) #(#(1 2 3) 'a string' #aSymbol)</td></tr></tbody></table>

Smalltalk/V, is little different. Different types of literals are shown in Table 5.4: numbers, characters, strings, symbols, and array representation. Numbers are quite simple. As shown in Table 5.4, any number from integer through floating point can be represented simply. The notation employed for using different radixes is: Rrnnnnnn, where R is the radix value, r is a placeholder, and nnnnnn is the value of the number in the radix indicated. Note that numbers in arithmetic expressions are automatically coerced, for example, 3.14*2 is equal to 6.28, because the number 2 is coerced to be of the same type as the number 3.14. Characters are preceded by a dollar sign and strings are delimited by single quotes. Symbols are designated by a preceding pound sign as are arrays. Arrays, however, have leading and trailing parentheses. Arrays may be nested, as shown, and may contain any object as an element.

Table 5.5 displays examples of several Smalltalk-80 syntactic constructions. Smalltalk follows the convention that instance variable names begin with lowercase and global and class variables names begin with uppercase. Global variables, such as the system dictionary "Smalltalk," may be accessed by simply

<table><caption>**Table 5.5** The Syntax of Smalltalk: Syntactic Constructions</caption><thead><tr><td>Concepts</td><td>Examples</td></tr></thead><tbody><tr><td>Variable names</td><td>numberHolder dictionaryOfLanguageTypes<br/>Smalltalk GlobalVariable</td></tr><tr><td>Assignment</td><td>year := 1993. salary := 2000.</td></tr><tr><td>Messages</td><td>ClassObject message<br/>instanceObject message<br/>Smalltalk inspect<br/>myToyota drive: north at: 55</td></tr><tr><td>Blocks</td><td>[r | 3.14 * r * r]</td></tr><tr><td>Conditionals</td><td>input < 65<br/>ifTrue: [Transcript show: 'turn up the heat']<br/>ifFalse: [Transcript show: 'have a good day']<br/>[fileStreamPointer atEnd] whileFalse:<br/>[characterPointer increment]</td></tr><tr><td>Iteration</td><td>#(1 2 3) do: [:x | x * x]<br/>'The Quick Brown Fox' select: [:c | c isUppercase]</td></tr></tbody></table>
sending the dictionary the message "inspect" (i.e., *Smalltalk inspect*). Assignment is direct and simple, for example, assigning a variable to an expression as shown in Table 5.5. In the examples given, the expressions shown are simply numeric values. The " := " operator is an assignment standard for Smalltalk; for many years, the assignment operator was a back arrow. The " := " operator is, however, more compatible with standard keyboards than the back arrow.

Objects respond only to messages. As shown in Table 5.5, there may be class objects that respond to messages and instances of classes that respond to messages. The distinction is important! In subsequent chapters, it will be pointed out how class and instance messages are kept separate from each other. Novice Smalltalk programmers often confuse the two types of messages. In the example given, there is one class indicated by a capital letter: *ClassObject*, an instance object *instanceObject*, a global variable, and an instance of a class (myToyota). In each case, the object to which the message is sent is shown in italics. Note the last example: *"myToyota drive: north at: 55."* *myToyota* is an instance of the Toyota class (recall the example in Chapter 2) and *drive:at:* is the message! *drive:at:* takes two arguments shown here as *north* and *55*. This syntax makes it possible to construct fairly readable messages.

Messages sent to objects can be categorized into four groups: unary, binary, keyword, and parenthesized expressions. In parsing a Smalltalk expression, parenthesized expressions take precedence over unary expressions, unary expressions take precedence over binary expressions, and binary expressions take precedence over keyword expressions. Binary and unary expressions parse left to right. Parenthesized expressions are those expressions enclosed by parentheses. Unary expressions are expressions that do not have arguments, for example: *Time now*. Binary expressions take a single argument, for example, 3 + 4 or *total* - 2. Binary expressions tend to be arithmetic. Keyword expressions contain messages with one or more arguments, for example, *index max: limit* or *HighwayContract spend: $1000 for: "testing."* Consider the parsing of the following expression:

5 factorial between: 52 + 45 and: 'good morning' size * 11

Because there are no parentheses in this expression, a unary reduction is made first, followed by a binary reduction, and finally the keyword reduction:

120 between: 52 + 45 and: 12 * 11 (unary reduction)
120 between: 97 and: 132 (binary reduction)
true (keyword reduction)

In this example, sending *factorial* to the number 5 returns 120 and sending *size*
to the string 'good morning' returns 12. To evaluate the preceding expression, simply type it into a workspace in ST-80, highlight the expression, and select "printit" from the pop-up window. After execution, "true" will appear immediately after the expression.

Blocks are Smalltalk constructs that permit execution of a deferred sequence of actions. Delimited by a set of square brackets, blocks are used in many control structures in Smalltalk. In the example in Table 5.5, the block contains an argument *r*, indicated to be an argument by the preceding colon "::" The block contains code to be executed at some later time. When sent the message *value*: 10 the block would return, in this case, 314. If you try out this example, note that spacing between the elements in the block is important. The * is a message sent to 3.14; hence, there must be a space between the items to permit interpretation of messages and arguments. A block may have either no arguments passed or multiple arguments passed. In the first case, a block is simply sent the message *value* to cause it to execute. For two arguments, the message *value:value*: including appropriate arguments will cause execution (e.g., aBlock *value*: 10 *value*: 20). Blocks are also used in conditionals, as shown in the two examples in Table 5.5. In the first case, the expression "*input* < 65" is evaluated; ifTrue, one block is executed, and ifFalse, the alternative block is executed. Similarly, in the following example, a pointer to a fileStream is tested and although the file is not at the end of the stream, the code in the following block is executed to increment a character pointer.

Iteration appears in many ways in Smalltalk. Two ideas are shown in Table 5.5. One is the "do:" construct which simply iterates through collections of objects. In this example, three numbers in an array are passed to a block for execution. Each number, in turn, will be passed to the code inside the block, and the number will be squared. For the second example, a string is passed through the iterator "select" which tests each element in the string to see if it is uppercase or not. If the character tested is uppercase, it is retained, else it is discarded. There are a number of iterators of this type that are useful, for example, collect, reject, and detect that provide useful collection filtering capabilities.

The brief comments given previously about the syntax of the Smalltalk-80 language are not, in any way, intended to be a substitute for study of the language. The student is referred to the basic references on the Smalltalk-80 referenced in Chapter 1 and encouraged to become proficient in the language syntax before proceeding to study the material in subsequent chapters. A knowledge of the Smalltalk-80 language will be needed to understand the examples given. Perhaps the most useful material that the student can use to learn the details of the language is the introductory material presented in the *User's Guide* that is delivered with Smalltalk-80 (*User's Guide*, ParcPlace Systems, 1991).