|
 |
|
| This is
the letters to the editor section. A collection of e-mail
correspondence updated periodically. |
|
| Letters
Index |
|
|
|
|
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,

|
|