Use Cases non-sequential

Anja wrote:

> This annoys me for some time:
> OO-development is event-driven: each event can possibly occur at any
> given time.
> OO-design takes notice of that, and only specifies sequences within
> one event (e.g. in sequence diagrams); normally never across several
> events.
> But in Use Case specifications, one HAS to specify the UC details in a
> sequence?!

It is quite acceptable for a use case to state that given some
preconditions (system state, particular inputs etc) that the use case
performs some actions X/Y/Z to produce some particular effect
(post-conditions, outputs etc) .

Sequences only have to be defined when sequence is important (X must be
performed before Y before Z etc) .

I do OTOH understand your possible frustration at being forced by the UML
diagrams to then subsequently elaborate a use case as a sequence (sequence
diagrams etc) . This is much akin to inferior methods that force you to
use state models (a highly sequential scheme) to represent things
(work-flows etc) better realised in other notations (petri nets etc) .


Regards,
Steven Perryman

Steven,

> It is quite acceptable for a use case to state that given some
> preconditions (system state, particular inputs etc) that the use case
> performs some actions X/Y/Z to produce some particular effect
> (post-conditions, outputs etc) .

Sure.
Although I'd like to see a version where
- the effect is clearly described when de preconditions are not (all)
met
- several different post-conditions are clearly linked to different
flows within the Use Case.

> Sequences only have to be defined when sequence is important (X must be
> performed before Y before Z etc) .

Different steps in a Use Case are always numbered. e.g.
1. do this
2. do that
etc.
This is always interpreted as a sequence.
How do you define steps which must not be performed in a sequence?
e.g. do this and then that, or, do that and then do this

Anja.

"Anja" <anjasmedts@hotmail.com> wrote in message
news:a2ef3516-891a-4f66-bc4b-1416cf9e64a8@p25g2000hsf.googlegroups.com...

>> It is quite acceptable for a use case to state that given some
>> preconditions (system state, particular inputs etc) that the use case
>> performs some actions X/Y/Z to produce some particular effect
>> (post-conditions, outputs etc) .

> Although I'd like to see a version where
> - the effect is clearly described when de preconditions are not (all) met

When you look at any component from a black box view, the convention is
that if the pre-conditions to some function/service are not met, then the
post-conditions, and the component invariants are undefined.

What that means is that some of the conditions may hold, some may
not. The one thing we would like to ensure is that you have *deterministic*
post/invariant conditions. IOW, if the pre-conditions are not met, there
is no way that *all* of the post/invariant conditions should hold.

There is an argument for attempting to maximise the extent to which
the post/invariant conditions will hold for incorrect pre-conditions
(known as robustness analysis) . The degree to which you want to do
this depends on the component granularity (a system-level component
would need far more effort than your typical module/class etc) .


> - several different post-conditions are clearly linked to different
> flows within the Use Case.

The post-conditions (outputs etc) are linked to the inputs you gave, and the
state of
the component at the end. If the component state is linked to activity flow,
then you
have what you need.

Bear in mind, that Use Cases are really only meant to represent system-level
activities at/within the system boundary. So you shouldn't really have an N
page
list of post-conditions for each Use Case.


>> Sequences only have to be defined when sequence is important (X must be
>> performed before Y before Z etc) .

> Different steps in a Use Case are always numbered. e.g.
> 1. do this
> 2. do that
> etc.
> This is always interpreted as a sequence.
> How do you define steps which must not be performed in a sequence?
> e.g. do this and then that, or, do that and then do this

x. Do the following : A/B/C (the order is discretionary) .
x+1. Then do these : X/Y/Z (the order is discretionary) .

A/B/C are done before X/Y/Z. That is an imposed sequence (ie A+B+C
is the pre-condition for x+1) .
But in observability terms, an impl that does A,B,C, X,Y,Z is as equally
correct as an impl that does A,C, B, X, Z, Y.

What I want to emphasise to you is the following :

- Define (within reason) as much observable behaviour (conditions
etc) as possible.
- Do not dictate detail (sequence etc) where it is not necessary.


Regards,
Steven Perryman

Anja escribió:
> Hi all,
>
> This annoys me for some time:
> OO-development is event-driven: each event can possibly occur at any
> given time.
> OO-design takes notice of that, and only specifies sequences within
> one event (e.g. in sequence diagrams); normally never across several
> events.
> But in Use Case specifications, one HAS to specify the UC details in a
> sequence?!
> E.g. 1. User puts credit card into ATM
> 2. ATM asks pincode
> 3. User enters pincode
> etc.
>
> Would it not be logical to specify Use Cases non-sequential?
> E.g.
> Rule A. If user puts credit card into the ATM, the ATM asks the
> pincode ad switches into 'pincode'-mode.
> Rule B. If user enters a pincode when the ATM is in 'pincode'-mode, it
> checks the pincode, warns the user he entered a wrong pincode, or puts
> itself into 'operational'-mode.
>
> Here, it is never said *when* the ATM can be in 'pincode'-mode. It
> could be at step 2, step 37 or whatever in the *classic* Use Case.
>
> A good understanders sees this can evolve quickly to a state diagram,
> which can be used to check the completeness of the Use Case.
>
> I have never seen such a way to describe Use Cases, and I wonder why.
>
> Anja.
Maybe a different view on Use Cases helps here:
All Use Cases are forms of dialogs in a way. One actor starts with an
action and other actors or system components react in a defined manner.
This results in a chain of things that happen which are sequential by
nature. The reason why you think they are sometimes not is
simplification. An example:

Joe Foo wants to meet Fred Bar in a meeting at Fred's office at 6pm.
Considering the meeting is already planned and confirmed, the simple use
case at the specified time from Joe's point of view is this:
Joe goes to Fred's office and talks to the secretary. The secretary
authorizes the appointment and lets Joe enter the office. Fred greets
Joe, Joe greets Fred, the meeting begins.

Not so fast. Joe could have to take a taxi, so "going to the meeting"
could depend on when the taxi arrives. This could leave Joe late or
early at the meeting. Likewise, Fred could return late from another
appointment, which would cause the meeting to delay, Joe would have to
wait. Here is where things become event driven.

Events atomically are sequential too, you just can't always _know_ of
the exact sequence of events beforehand. You could define every
alternative sequence with a lot of sub-use cases until you drown in too
much information.

If you want to avoid just ignoring where a UC gets complicated, you
would have to choose another approach and define UC for the Events
instead of the actors.

The bottom line is: For most user interaction Use Cases are sequential
on the outside. I think it's a bad idea to try to formalize the process
of modeling regardless of the problem to solve at hand, a good system
engineer should consider all the tools at hand to get the information
across and use them wisely and with experience.
As Mr. Lahmann already pointed out, that's why system engineers exist.

Regards,
Stefan