Sponsored Link •
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.
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 TurnaroundWe 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):
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.
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:
- Choose a central topic
- blanket it with scenarios
- expand to less central, or peripheral topics
|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.|