March 92 - Book Review - Developing Object-Oriented Software for the Mac
Book Review - Developing Object-Oriented Software for
the Mac
Tom Becker
Developing Object-Oriented Software for the Macintosh
Neal Goldstein and Jeff Alger
Addison-Wesley, January, 1992
347 pages
Neal Goldstein and Jeff Alger have taken something complex and difficult-software
engineering-and made it accessible and useful. Their book, Developing Object-Oriented
Software for the Macintosh (DOOSM), and its methodology, Solution Based Modeling
(SBM), shows a thorough understanding of the problems in developing software and
the software engineering technology that can be applied to those problems.
SBM has a well designed graphic interface, called Visual Design Language (VDL). Most
important, SBM is designed around the way people think. This is a real breakthrough.
Of all the methodologies I've seen, SBM is the first practical one; it has a chance to
improve how programmers do their work.
THE MACINTOSH AND SOFTWARE ENGINEERING
Software development methodologies tend to focus on difficult tasks like analysis and
design, since there isn't much value in organizing something already straightforward,
such as coding.
A methodology has a language for analysis and design concepts, and rules for ensuring
the concepts are correct, or at least consistent. A good methodology is easy to use and
understand, consistent, complete, flexible, and reliable. It helps diverse people work
together, helps you create realistic schedules and budgets and avoid surprises, and
helps you create software that meets the users' needs.
Most Macintosh software has been developed without using a formal methodology.
Paradoxically, the primary reason for this is the innovation and high standards of the
Macintosh. Methodologies, no matter what theories they use, are based on practical
experience. The state of the art in methodology has had to catch up with graphic
interfaces, event driven architectures, object-oriented programming, and application
frameworks. This has meant that methodology is weakest in meeting the challenge of
new technologies when it is needed the most.
In spite of the lack of methodology, Macintosh developers have managed to create a lot
of excellent software. But there are also many applications that didn't make it, because
of technical flaws, schedule problems, or not having the right features. The well
educated, demanding users, and the intense competition in Macintosh software means
that you can't just write better software. You have to continue to write ever better
software, ever faster. The easiest computer to use is still hard to program.
Object programming and application frameworks such as MacApp promised to make
Macintosh programming easier by making code more reusable and eliminating the need
to deal directly with the Toolbox. It turns out that making code reusable, even with an
OBJECT PROGRAMMING language, is harder than just hacking something out. Also,
MacApp is well designed and well written, but can be hard to learn. Programming has
been made easier, but only for those who manage to become MacApp experts. Making it
easier to use object programming and MacApp is the challenge now.
It's interesting to see how object programming and MacApp affect the development
process. MacApp frees you from writing a lot of boilerplate code such as main event
loops. It separates the user interface from the rest of the program, and provides a
fairly rich framework for adaptation. What's left to do is the analysis, interface
design, and object design. In other words, MacApp eliminates most of the mindless
parts of writing a Macintosh application, leaving only the hard parts. Meanwhile,
object programming languages such as Object Pascal and C++ separate software design
(class structure, object relationships and interfaces) from implementation (method
code).
With object programming and MacApp, the analysis and design work that used to be
mushed in with coding is forced into the open. This is good because it gets us closer to
the heart of programming [1]. The next step in making programming easier is to come
up with a better way to do analysis and design. In other words, a software development
methodology.
ABOUT THE BOOK
The book, Developing Object-Oriented Software for the Macintosh, is divided into two
parts. The first part establishes the need for SBM and goes into its theoretical
background. The second part describes the details of the Visual Design Language (VDL)
and SBM. The book also includes a brief appendix on a simple index card system for
facilitating SBM.
Object-oriented software development
The first part of the book is written as a tutorial. It explains, in painstaking detail, the
theoretical and practical considerations that went into SBM. I could tell this book was
written by real engineers. It has structure. Concepts are introduced, described, and
summarized. Each section depends on the previous one and leads to the next. Not a
sentence was wasted.
This part of the book is well written, even entertaining. The authors present concepts
with a clarity and confidence that comes from practical experience and repeated
refinement. The examples are good and humor is used appropriately.
The first chapter establishes the need for improvement in how we develop software. It
demolishes the standard myths of software development, then defines the
characteristics of a good methodology and introduces object-oriented software
development, more of which is covered in the following chapters.
The second chapter explains object programming, including inheritance,
polymorphism, and class libraries.
The primary purpose of chapter 3, the Folklore of Object-Oriented Software
Development, is the debunking of objectivism, the belief that objects in a computer
program work the same way as real objects in the real world (and vice versa). The
attractiveness of objectivism is easy to understand when you consider that a major
early use of object-oriented programming was for simulation, where the purpose is to
model real world objects. Real-time control is another application where there is a
strong resemblance between the objects inside and the ones outside the computer. For
most applications, however, objectivism really doesn't work. Real world objects have
identity and structure, and may be similar to other objects in different ways, but real
world objects are too complicated to be organized into hierarchies, even with multiple
inheritance. Computer objects are an organization of code and data for the convenience
of the programmer. Objects allow you to write software that has minimal side effects
when it runs. Objects make it easier to modify the software because interfaces between
objects are well defined and dependencies can be minimized. Class hierarchies are
simply another convenience that allow code and data definitions for similar objects to
be consolidated.
Chapter 4, Sample Applications (Why Aren't They Easy), is one of the best parts of the
book. It shows how the classic object-oriented design approaches fall apart for
non-trivial examples. It describes the messes you can get into. Object programmers
will recognize them. It looks at how an expert might approach the problem, the
principles behind that approach, and the characteristics of a good object-oriented
design.
Chapter 5 is a short primer on cognitive science. It describes how people think in
terms of cognitive categories, and the difference between overlapping categories (how
people think), and hierarchical classes (how people think they think). This is a little
subtle, but important because it is the primary justification for using planes,
scenarios, and calibration in SBM, instead of using a top-down or linear approach.
Solution based modeling
The second part of the book is written as a reference. It gets down to brass tacks and
describes how to use SBM.
Chapter 6 describes the Visual Design Language, which is used to communicate design
information throughout the rest of the book. This is human interface design at its best.
The authors worked with a graphic design firm to create VDL, and it shows. VDL simply
looks better than the symbols for other methodologies. Perspective is used to make
symbols easier to recognize, while packing more meaningful information into
diagrams. The symbols are not hard to draw. This lets non-programmers participate
more fully in analysis and design.
Chapter 7 is an overview of SBM. Chapters 8 through 11 describe the Business,
Technology, Execution, and Program planes in a Solution Based Model.
The fundamental unit in a Solution Based Model is the scenario, a description in VDL of
a single topic or concept. Scenarios are supposed to be simple-something that can be
easily drawn on an index card. There is no fixed structure that the scenarios have to fit
into. Instead, a calibration process is used to find inconsistencies among overlapping
scenarios.
This is another great thing about SBM. It's hard for people to be simultaneously
creative and critical; it always works better if you can separate the two dynamics. The
different levels of abstraction in a project, such as requirements, specification,
design, and implementation, are handled in SBM as planes. The relationships between
planes are described using scenarios, just like everything else. The calibration
process ensures that the model is valid from top to bottom. The same methodology is
used for the whole software life cycle.
The Business plane is where you do requirements analysis. You describe how things
are done now (the reference model), and how they will be done with the new system
(the solution model). SBM can do an impact analysis by looking at the differences
between the reference and solution models. This has enormous value for justifying a
system proposal, marketing, planning, and training.
The Technology plane is where you do the system specification, in the form of a user
interface model, content model, and environment model. The separation between the
Business and Technology planes is a key factor. The Business plane focuses on people
and how they do their work. The Technology plane focuses on the computer system and
how it appears to the user.
The Execution plane contains the user interface, content, and environment
architectures. This is where you design the objects and interfaces and figure out how
library building blocks will be used in the system. The Business and Technology planes
describe real-world objects (such as people, forms, reports, screens and keyboards)
while the Execution plane describes software objects (such as views, documents, and
commands). This is where you apply the theory on the failures of the classic
object-oriented design approaches. If objectivism were true, the contents of the
Execution plane would look just like the Business and Technology planes, when actually
it takes real work to design the run-time objects. In practice, the principles of good
object design are the same as those for good software design: well defined modules with
minimal interdependencies.
The Program plane is where you design the types and classes for implementing the
system. There is an important distinction between the Execution plane, which
describes how the run-time objects are organized, and the Program plane, which
describes how the source code is organized. This helps you avoid a common pitfall:
confusing objects and classes.
The second part of the book is not as easy to understand as the first part. Because it's
written as a reference, there isn't as much continuity between sections. I needed to
read through it twice to fit everything together. For example, I got confused because I
couldn't tell the difference between the "reference frame" and the "reference model" in
the business plane. That was cleared up in the last chapter, which talks about looping
around to the next iteration in the software life-cycle.
The concepts that I had the most difficulty with were how dangling threads are managed
and how calibration is performed. The theory is clear, but the details are skimpy. It
would help to have a worked out example-such as for the Payroll sample
application-that goes through the whole SBM process, showing overlapping scenarios,
dangling threads, calibration, and scenario revision. Of course, that might double the
size of the book.
EVALUATION
SBM could clearly use a CASE (Computer Aided Software Engineering) tool. The tool
would have a VDL drawing module for creating and editing scenarios that would be
stored in a database. The database would make it easy to navigate through overlapping
scenarios, and calibration could be automated. If a CASE tool came out soon enough and
weren't too expensive, it could become a useful standard for communicating design
information.
It would help to have more worked out examples and diagrams; they would be even
more useful on-line. The ultimate test would be a diagram of SBM, done using its own
Visual Design Language.
DOOSM is the result of two years of work by Neal Goldstein and Jeff Alger. In some
respects the book has the feel of a version 1.0.0, but the authors' experience and hard
work shows through. To quote James Plamondon, "MacApp is not just a bunch of user
interface code, it is a library of accumulated wisdom on Macintosh programming." The
real value of SBM is its accumulated wisdom. Get a copy, and study it carefully. And
have your manager and any non-programmers on your team read the first part, at
least. Any one of the many insights in the book will make it worthwhile.