The Artima Developer Community
Sponsored Link

Weblogs Forum
Solution Based Modelling - Lost OO Wisdom

6 replies on 1 page. Most recent reply: Oct 21, 2009 10:12 PM by Jeff Alger

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 6 replies on 1 page
Andy Dent

Posts: 165
Nickname: andydent
Registered: Nov, 2005

Solution Based Modelling - Lost OO Wisdom (View in Weblogs)
Posted: Apr 29, 2006 2:24 PM
Reply to this message Reply
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]


Andrew GJ Fung

Posts: 4
Nickname: relgar
Registered: Oct, 2003

Re: Solution Based Modelling - Lost OO Wisdom Posted: Apr 30, 2006 2:26 AM
Reply to this message Reply
> <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!

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Solution Based Modelling - Lost OO Wisdom Posted: May 1, 2006 1:37 PM
Reply to this message Reply
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.

Andy Dent

Posts: 165
Nickname: andydent
Registered: Nov, 2005

Re: Solution Based Modelling - Lost OO Wisdom Posted: May 8, 2006 9:30 AM
Reply to this message Reply
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.

http://www.artima.com/forums/flat.jsp?forum=106&thread=158340

John Brugge

Posts: 1
Nickname: jbrugge
Registered: Dec, 2006

Re: Solution Based Modelling - Lost OO Wisdom Posted: Dec 7, 2006 1:27 PM
Reply to this message Reply
Andy,

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.

Thanks again,
John

keith hodges

Posts: 1
Nickname: keithy
Registered: Apr, 2007

Re: Solution Based Modelling - Lost OO Wisdom Posted: Apr 5, 2007 10:09 PM
Reply to this message Reply
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.

Book review:

http://www.mactech.com/articles/frameworks/6_2/OOSD_Becker.html

Articles by Goldstein and Alger
http://www.mactech.com/articles/frameworks/7_2/SBM_Overview_Part_I.html
http://www.mactech.com/articles/frameworks/7_3/SBM_Overview_Part_II.html

Jeff Alger

Posts: 1
Nickname: jeffalger
Registered: Oct, 2009

Re: Solution Based Modelling - Lost OO Wisdom Posted: Oct 21, 2009 10:12 PM
Reply to this message Reply
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.

Flat View: This topic has 6 replies on 1 page
Topic: Myths About Indentation in Python Previous Topic   Next Topic Topic: Two Conferences and a Workshop


Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2014 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use - Advertise with Us