SIGIA-L Mail Archives: RE: SIGIA-L: IA notation
RE: SIGIA-L: IA notation
From: chuck.lutz_at_telelogic.com
Date: Thu Jun 29 2000 - 12:09:34 EDT
Hi,
Wow, this discussion gets more interesting with each bounce of the
conversational tennis ball...!
Andrew Gent wrote (first quoting Jesse James Garrett):
>>While I agree that some aspects of UML might find valuable
>>application in modeling information architectures that are strongly
>>dependent upon data models, I have reservations about the
>>practicality of UML in the broader area of modeling user experience.
>>
>>The UML component that seems most applicable, the use case diagram,
>>seems insufficiently holistic to capture the complexities of
>>contemporary architectures in which hypertextual information spaces
>>and interactive functionality are intermingled.
> I am so glad you said that. I was running into the problem that
>whenever I mentioned "user scenarios" to engineers as a mechanism for
>communicating the intended or expected use of a system they would say "oh
>yes, use cases." As a result, for one project, I took a crash course
Could there be a "cultural rift" here between "engineers" and "others"?
>(figuratively speaking) in UML and delivered a requirements document for a
>fairly simple KM system using use cases. Although it was an interesting
>experiment, the resulting spec did a very poor job of communicating the
>"meaning" of the expected transactions. Use cases also provide little or no
Andrew, could you give an example in which "meaning" slipped though the
cracks? This point seems to be the tip of the iceberg, which seems to me
to be the problem of grasping _exactly_ what kind of information we are
trying to capture.
"Use Cases" _do_ tend to concentrate on "data flow", in the sense of an
example like:
Textual UC description: "Next the user specifies their choice of snack
or beverage by supplying a product ID consisting of one letter and one
number, chosen on a keypad with one row of letters and one of numbers."
This would manifest itself as one or two input messages to the UI of
the system. In the case of the former, it would assume the future creation
of some sort of "productID" datatype which would be a composite of a
"character" and an "integer", common fundamental types in most implemen-
tation programming languages. In the latter case, the user sends in two
messages, one containing a letter, and one a a number. The latter case
more closely models the user experience, since they first press e.g. the
"A" button and then the "5" button. Funny, I just realized that I think
most folks "know" to press the letter first. I wonder what happens if
they press the number first. I'll have to try that sometime!
No matter how it's modeled, the goal, _in_the_s/w_engineering_context_,
is to capture the "data" in anticipation of having to represent it in
programming language code in the final implementation.
>mechanism for identifying the relative emphasis on one data flow over
>another.
How do you mean, the "relative emphasis of one data flow over another".
Do you mean likelihood? True the notation doesn't say anything about which,
out of a handful of scenarios, is most likely to occur, other than dividing
them into "main" cases and "exception" (usually error) cases.
The crux lies in what kind of information we want to capture. I wonder
if insight can be had from other uses of UML such as in business or
organizational modeling. I've just started to read a book on the former.
When the end goal isn't software, maybe the vision from the start influ-
ences the modeling in radically different ways; I don't know.
> A standard notation for describing the structure of a design would
>be useful and UML as a notation (minus the current semantics of a
>representation such as use cases) could serve as a good starting point.
As I mentioned in another email, it might be useful as a notation for
capturing high-level, static architectures and high-level "behavioral"
schemes.
It may very well be that models in UML of web sites don't map directly
to implementation as networks of HTML docuements, Javascript functions,
etc. There may be greater resistance in going from the analysis to the
detailed design.
> However, in the meantime I have gone back to representative (as
>opposed to complete) written usage scenarios for capturing requirements;
and
>paper prototypes (of page layouts and the first 2-3 levels of structure)
for
>communicating designs. Other than with professinal writers and designers,
>paper mockups seem to have far more communicative impact than detailed
>"maps". They also tend to avoid bickering arguments over nits and tend to
>elicit "big" questions about the design.
If this works well, by all means, use it. Besides, using UML to communicate
with the customer, in the intent on agreeing on a proposed design, is ob-
viously a bad idea, unless you work only with UML-saavy clients.
That might kill the whole UML argument, although the problem of agreeing on
the requirements for the site design still remains. The requirements defin-
ition starts with natural language and must eventually be formalized in
order
to get an unambiguous design definition.
Perhaps, then, UML (or something like it or any formal notation that needs
to
be learned and mastered) could be used in-house. Internally, communications
with the customer are translated into the notation.
But how, then, do you get the customer to agree that the design is
"correct"?
My brain just popped...
Chuck
This archive was generated by hypermail 2.1.2
: Sun Nov 23 2003 - 22:54:20 EST
|
