Thank
you for your most excellent and thought-provoking review of my
book. I believe it is the most complete review to date, and I
very much appreciated your commentary.
Events: It's ironic that I'm the first to publish a
large body of work on Event Modeling since McMenamin &
Palmer's original work in 1984. I didn't invent the work in this
chapter. Meilir Page-Jones, Steven Weiss and Larry Constantine
devised this brand of event modeling in a very early OO
methodology called "Synthesis." I was steeped in the
technique in the late 1980s and found it immensely useful.
Unfortunately, their work went unpublished - and the world
suffered greatly. James Martin was at the pinnacle of his
success back then - and KnowledgeWare ruled the CASE tool world.
We fought fervently to convice projects that an understanding of
events was crucial to good interface design (or even finding out
what data crossed the boundary).
The
most spectacular Information Engineering failure we encountered
was a Child Welfare System in the State of Washington in the
early 1990s. The project team had used data modeling almost
exclusively to conduct requirements analysis. When it came time
to design the interface, they were completely lost . . . so they
made a single ADD-CHANGE-DELETE screen for each of the 100
tables in their system. The screen was accessible only by giving
a cryptic command on the command line. The system had utterly no
menu. When users cried "foul," the IT department
issued a cheat-sheet booklet of the 300 commands needed to run
the system. I would have loved to write an entire volume on the
topic of events - but the charter of this book was to cover the
spectrum from start to coding . . . a challenge that often
yields coverage that is a mile wide and a quarter inch deep.
Your commentary is very fair in this assessment.
The
original target audience for this book (especially the GUI
parts) were experienced main-framers - who were familiar with
SA/SD techniques but were utterly baffled as to how to
transition their skills to client/server and beyond. In the
early 1990s we saw whole IT shops paralyzed with this issue.
Unfortunately, I didn't have the foresight to realize that all
of the mainframers would be called back to the "mother ship"
to do Year-2000 mitigation (until retirement)! If I dwelt
unduely on the object-action point - it was mainly for
that audience. It's hard to overcome one's biases - based on the
types of systems you're building.
|
|
As you
pointed out so clearly . . . my perspective comes from building
very large PowerBuilder / Oracle sales planning and order entry,
transportation and export invoicing systems for Weyerhaeuser. In
these systems, the user community very much appreciated object-action
over their old command-driven systems.
Today - we'd undoubtedly give them more of a browser concept.
Later I worked on an emergency-response system and found myself
favoring action-object. With a highly-skilled 9-1-1 operator at
the controls, there is no time to pick from a drop down list
when a caller's life hangs in the balance. I'd love to hear your
biases and opinions about this topic.
Glad
you like the "window cohesion section." It's
rare that a reader draws the proper correlations to the original
SD references. I'll admit to having a bit of a brain wave when I
saw those patterns emerge in my own designs. I felt that window
navigation was really obvious. We'd been doing it on the white
board for years this way. I've seen several authors alight upon
this idea at the same time . . . it was a huge short-coming in
the UML body of work. Speaking of UML - I purposely
avoided it in this book. At the time this text was written
(1995-1996), the OO notation debate was in full hot rage. I was
very, very concerned about having this publication dragged into
the partisan bickering - which threatened to overshadow some of
the more basic messages I was trying to convey. That's why I
chose a relatively benign OO notation and spoke in rather
general terms.
The
same went for Use Cases. Jacobson's writings on the
subject touched on many of the event modeling concepts - but
failed to provide the rigor required for serious analysis.
Subsequent authors have steered his work much closer to event
modeling today. You may have noticed that the "event levels"
I provided in Chapter 4 have a correlation to Use Cases...The
dialogue level (when you declare the User/Actor and technology)
is really the level at which Use Cases were devised.
Unfortunately for projects which focused solely on this
technique - it fails to adequately model the business problem
prior to designing the interface.
I'm
glad you picked up on the point about testing in reverse order.
It's the bane of our existence!!
Thanks again for your review. I'd very much appreciate hearing
your further thoughts.
Very
best regards,
Dave Ruble |
|
