23rd, March 2000 
 
 
  
David facilitating a UI Design Session
This is the letters to the editor section. A collection of e-mail correspondence updated periodically.
Letters Index
Modal vs A-Modal
How is the big question
Wiley website review
Intelligence Advantage
Use Cases
Mediator Pattern
Visual Proxy
Herding the User

Finding his own work referenced, Ben Kovitz wrote...

Hi David,

I just read your latest wonderful critique of use cases! I wish I'd known about your February IMHO when I posted to Usenet about use cases a while back. Here's one other thought, that crystallized for me when I read your relation of use cases to premature Interaction Design. There's a chapter in _Tog on Interface_ in which Tog says that where the old style of menu- and command-oriented UI design led the user by the nose, giving him as few choices as possible, a good GUI gives a lot more freedom to the user--more freedom than many programmers are comfortable with. To that I'd add many business analysts. "Use-case thinking" leads to exactly that kind of UI design: a small, constrained set of paths down which to herd the user, as opposed to a world that reflects the problem domain in all its variation and complexity.

Ben

Warnier & Orr had solved it all

Whilst working an "all nighter", Phil Bradley found time for this...

Hi David,

Use cases are just re-cycled Data Flow Diagrams. Use cases are problematic today for the same reason DFDs were problematic 15 years ago. They document existing processes (in a laborious and time consuming way). The basic problem is most people can't abstract. And of those who can, most are not very good at it. The Anti-Patterns book goes on about people not being able to abstract in a different context. Hence for most people a detailed exposition of a possible system solution becomes THE SYSTEM.

The issue is how do we document the requirements of a system independant of any system solution. This problem was solved a long time ago by a Frenchman called Jean-Dominique Warnier, and subsequently refined by Ken Orr. Execution of the methodology is just too hard for most people. I mastered the notation, and became quite good at it, before one day I 'got it'. Any idiot can do DFDs/Use Cases. Incidentally, The Warnier/Orr methodology automatically solves your interaction design problem. It comes automatically out of it.

One day when I have the time and inclination I will put up a web site as a homage to JDW. I did a search a few weeks back on his name and it came up with one hit which was an out of print book of his at Amazon. IMHO, JDW is the most important person in the history of constructing automated business systems. The fact almost no one has heard of him is a telling comment on our business.

If you want to be famous, then recycle his ideas in the context of human interaction design. Although, if you are doing design, in the context of Warnier/Orr, then you have missed the point. It goes straight from analysis to construction. I guess that's why its so superior, it doesn't allow for design and results in a solution, that is tightly coupled to the requirements. OO doesn't even come close. I suspect most of the GUI point and click paradigm will eventually be recognised as a mistake. But for another day.

Phil

UIDesign.net reply ...

Phil,

I had to look up "Software Engineering - A Practitioner's Approach" by Roger Pressman to get some detail on this.

The Warnier stuff is data structure analysis from what I can see. The diagram uses a large { type notation. Actually, I can't see much from the notes in the book that cannot today be expressed using a UML Class Diagram. Interestingly, the technique seems to be used to analyse the required output, i.e. a Warnier diagram is derived from the screen and not from the Domain. Perhaps this is a reflection of the very 2 tiered approach to software development in the 70s. The original work is commented as 1974 and was updated in 1981.

The Warnier Diagrams are advocated as an Analysis tool as part of a DSSD (Data Structure Systems Development) process.

The Warnier-Orr stuff documented as 1977 and 1981 is advocated as a design level tool and involves the Warnier Diagram with overlaid psuedo code inside the brackets - in other words, data and behaviour, quite OO really. Again its based on the screen output rather than underlying problem domain analysis.

As such, I can see why this died out. It was screen based rather than Domain based. Perhaps it was also seen to have been superceded by newer notations e.g. ERDs and ultimately by the move to OO which doubtless Warnier-Orr were partly responsible for. If you combine Warnier-Orr with the Yourdon-Constantine work, Functional Design, you get OO as a fall out.

Regards,

Signature

Feedbackdavid@uidesign.net

      
 
Copyright uidesign.net, 1999 - 2000