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.