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.
Remember this was published by 1992, I don't think we've learned anything to better this list in the last 15 years.
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.
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.
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.
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.
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]
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.
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):
Centre the most important elements on the diagram.
Use size for emphasis - larger is more important in the context of the diagram.
Left to right implies time sequence.
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.
> <p>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):</p> > <ol class="arabic simple"> > <li>Centre the most important elements on the > diagram.</li> > <li>Use size for emphasis - larger is more important > <em>in the context of the diagram.</em></li> > <li>Left to right implies time sequence.</li> > <li>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).</li> > </ol>
"Use size for emphasis" was my "learned something new and useful" for the day. A good "duh, of course" idea. I'll try to remember this for my next visit with a whiteboard or Visio. Thanks!
It's occurred to me often that UML is fairly ineffective tool (basically every time I waste a few hours drawing a sequence diagrams.)
The most useful part of UML is the class diagram. The rest of it, in my estimation, doesn't provide adequate efficiency in terms of time in -> information out.
My main complain abut UML is that it dissects a design into 2D cross-sections. You cannot get a clear understanding of the high level design from any one UML drawing and it's too much info to pull together to 'see' the whole design. I't kind on like trying to look at the crossections (http://www.anatomyatlases.org/HumanAnatomy/3Section/01.shtml) of a human body and determine what the person looked like.
What I think we need is to take basic idea of the class diagram and enhance it to be a more holistic view of a design and eliminate the 'code' from it. Really, do I need to see the attributes of a class in the class diagram? That's just stupid. I'll look at the code if I need that level of detail. I want to see how classes and objects interact with each other in a graphical way.
James Watson wrote > My main complain abut UML is that it dissects a design > into 2D cross-sections. You cannot get a clear > understanding of the high level design from any one UML > drawing and it's too much info to pull together to 'see' > the whole design.
The BON method, about which I blogged a few days ago, had some interesting ideas on diagram compression.
It is great to see this methodology brought to light again. At the company I was with in 1992 we brought in Jeff Alger to work with us, and it was a fresh breeze of reality. And you are right that the SBM principles are as relevant today as ever. The agile approaches may couch things a little differently, but the important emphasis is the same: results are the only thing that matter, and effective communication is the enabler of it all.
As for VDL, I'm glad to know that someone held the UML folks feet to the flames at least briefly. I'm curious to know what their responses were to your (and others) suggestions on the topic.
But while I wish that SBM and VDL had gotten a little more traction, I'm glad to see that the agile folks have been able to explore these principles further. There is still a lot we don't know about how to develop software, and I take my hat off to those who are pushing us out of entrenched (and ineffective) comfort zones.
I have used VDL for years in m informal sketchings. I also attempted to contact Goldstein and Alger in order to discuss tool support back in 1995, to no avail.
Anyhow I found these two references which reader might find interesteing, no diagrams though.
Just stumbled across this thread while googling something unrelated. Still alive and kicking if anyone has questions about SBM or VDL. Not actively doing anything with them since the mid-90s but the concepts have continued to rattle around. I can be reached at jeffalger@msn.com.
Previous Topic
