Re: More on the dreaded optionality problem....

[Philip Goatly <philip.goatly@bolero.net>]

William,

   I would agree with you that, when analysing the needs of a business user
if one 'plays back' the business requirements as
understood by the analyst, in UML - The user is bound to ask what planet the
analyst comes from.

As to the question of optionality - by which I take you mean a cardinality
of 0..n where n may be 1 - conditionality may be
expressed in OCL - Object Constraint Language - again far too complex for
the business user, with the disadvantage that
the 'well formedness' of the OCL can only be checked outside Rational Rose
and other tools. OCL, anyway, is not even for business analysts and business
modellers, since to get to grips with it one needs some acquaintance with
programming.

UML is very good for modelling software systems, object and classes etc.

The best way to model for the Business User is to employ UML Use Cases but
these allow state diagrams and sequence diagrams to be associated with them,
which are, in many environments, outside the experience of a business user .

The answer is not simplwe I am afraid.

Cheers, Phil Goatly.


----- Original Message -----
From: "William J. Kammerer" <wkammerer@foresightcorp.com>
To: "ebXML Core" <ebxml-core@lists.ebxml.org>
Sent: Monday, March 12, 2001 12:51 PM
Subject: More on the dreaded optionality problem....


> While reading up on UML - as I am still not convinced that it brings
> much value to modeling external business processes - I came across our
> own Christian Huemer of the University of Vienna and the ebXML BP group
> in the IEEE Proceedings of the 34th Hawaii International Conference on
> System Sciences - 2001.  Sheesh! I've never been to Hawaii - maybe I
> ought to get in on this UML modeling bandwagon.  See "Defining
> Electronic Data Interchange Transactions with UML," (0-7695-0981-9/01),
> at http://www.computer.org/proceedings/hicss/0981/0981toc.htm under
> Track 7: Internet and the Digital Economy Track within E-Commerce
> Systems Development Methodologies.
>
> Well, I'm still not a believer in UML, but Huemer has a salient quote
> that buttresses what I said last Friday regarding optionality causing
> complexity:
>
>    ...people not directly involved in message development...
>    may not understand the complexity included in the [EDI
>    standard] messages. This is made worse by the fact that
>    standard messages include optionality without explaining
>    under which conditions these options are to be used.
>
> William J. Kammerer
> FORESIGHT Corp.
> 4950 Blazer Pkwy.
> Dublin, OH USA 43017-3305
> +1 614 791-1600
>
> Visit FORESIGHT Corp. at http://www.foresightcorp.com/
> "accelerating time-to-trade"
>
>
>
> ------------------------------------------------------------------
> To unsubscribe from this elist send a message with the single word
> "unsubscribe" in the body to: ebxml-core-request@lists.ebxml.org
>