The Artima Developer Community
Sponsored Link

Thinking Upside Down
Solution Based Modelling - Lost OO Wisdom
by Andy Dent
April 29, 2006
Summary
Goldstein & Alger developed an OO design method that was clearer than UML or Booch and better founded in theory. It was a standard in EDS but has vanished into obscurity. Maybe it's time to look backwards for some insight or at least pick up an old copy of their book for the pleasure of a clear read of what OO development is all about.

Advertisement

Developing Object-Oriented Software for the Macintosh is not exactly the kind of book title that makes your average non-Mac OO developer grab a book off the shelf.

More than anything else, that book titling decision by Addison Wesley may have killed off a very promising OO design method that is still worth studying, if you can find an out-of-print copy.

Amongst its many other virtues, it has a single chapter summary of Lakoff's seminal work on category theory and how we categorise things - Women, Fire and Dangerous Things that I have lent to multiple people as a well-received alternative to wading through the full philosophical tome.

Five Characteristics of a Good Methodology

Remember this was published by 1992, I don't think we've learned anything to better this list in the last 15 years.

  1. It Has to Work

The methodology has to work. It should consistently provide high quality software that is on time, within budget, and meets the needs of the users of the software. No other measure of success matters.

  1. It Must Allow for Continual Evolution

Since we know that it is futile to try to develop fixed specifications, let's not try. Instead, our methodology should correspond to the way people think and businesses operate: by cyclical refinement. There will be no fixed ending point. Rather, there will be an on-going evolution that never ends, but with points of equilibrium along the way. Release of software will be based on utility of the "intermediate" result, not any notions of finality.

  1. There Must be Rapid Turnaround
We know that the software itself will change the need, it is doubly important to start reaping results quickly. No siz-month to two-year turnaround here: initial results should be available in days or weeks.
  1. It Must Minimze Distortion

.. popular childhood game called "Telephone," in which a person at one end of a long line of people whispers some complicated story into the next person's ear. That person quickly turns to the next one in line and repeats the story, and so on until the last one in the line tells the story - or such of it as has survived - to the prolonged laughter of the group. Seldom does the end result even resemble the initial story.

This game illustrates an important point: The more people we have involved in developing the software, the more important smooth communication becomes. ... Ideally, everybody involved should be able to explain perceptions and needs in ways that translate directly into software, and should be able to understand the structure of the resulting software without knowing much about computers. Put another way, we need a common lexicon and structure throughout the process of creating software, from analysis to code.

  1. The Process Must Be Stable

We should be free to roam through the needs and design of the software, confident that short-term mistakes will be picked up and corrected in due course. It should matter little the order in which we explore the relevant topics. If the methodology is stable, comparable results wil be produced regardless. In particular, we should be able to focus first on central issues. Stability also implies - assuming that the right people are brought into the team - that the oder or manner in which we talk to various participants will at wors affect the time it takes to produce results, not the accuracy of the results. The methodology should not present a canvas on which we paint, but a chalkboard, portions of which can be erased and modified at any time. [GoldsteinAlger1992a]

The Right Way to Design a Graphic Notation

Notations have a long history in computer software, starting with flowcharts and proceeding through structure charts, data flow diagrams...various ways of visualizing objects and classes. However helpful these notations have been, they are quite crude by graphic design industry standards. The authors know this first-hand. They enlisted the help of a professional design firm to help develop a notational scheme for use with SBM, only to endure their amazement and, at times, benevolent laughter over our early, two-dimensional attempts at graphic symbols. [GoldsteinAlger1992b]

I got myself kicked off the early UML design discussion mailing list (OTUG) for taking Booch et al to task for their refusal to consider that they might not be the world's best graphic communicators and should consult some specialists. Sorry, UML users, I tried and a lot of more important people than I agreed but we were stuck with boxes and lines.

Visual Design Language

Unfortunately, I have been unable to find any copies of Goldstein & Alger's Visual Design Language online, other than a couple of figures in [Mattson1994].

The specific graphics are rather moot in this UML-dominated world, however some of their principles can still be applied (note these are Western-oriented visual cues):

  1. Centre the most important elements on the diagram.
  2. Use size for emphasis - larger is more important in the context of the diagram.
  3. Left to right implies time sequence.
  4. Foreground-background implies ancestry or time-sequence (note that the concept of foreground only starts to become significant when you have enough 3D-hinting in the diagram shapes).

For a modern, UML-centric guide to such principles, see The Elements of UML Style which as a version 2.0 is recent enough that you can still buy a copy.

Examining the Process

If there's interest, I'll spend a bit more time in another blog entry summarising important points from their process, which is based on:

  1. Form Scenarios
  2. Calibrate the model - overlapping views of different aspects of the problem and solution space should be made consistent.
  3. Centre-Periphery-Calibrate
  • Choose a central topic
  • blanket it with scenarios
  • expand to less central, or peripheral topics

[GoldsteinAlger1992c]

Talk Back!

Have an opinion? Readers have already posted 6 comments about this weblog entry. Why not add yours?

RSS Feed

If you'd like to be notified whenever Andy Dent adds a new entry to his weblog, subscribe to his RSS feed.

About the Blogger

Andy is a free-lance developer in C++, REALbasic, Python, AJAX and other XML technologies. He works out of Perth, Western Australia for a local and international clients on cross-platform projects with a focus on usability for naive and infrequent users. Included in his range of interests are generative solutions, software usability and small-team software processes. He still bleeds six colors, even though Apple stopped, and uses migration projects from legacy Mac OS to justify the hardware collection.

This weblog entry is Copyright © 2006 Andy Dent. All rights reserved.

Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use