Use Cases non-sequential

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.

Anja wrote:

> This annoys me for some time:
> OO-development is event-driven: each event can possibly occur at any
> given time.

Not necessarily. If a given routine needs to be sequential, you code it like that.

OO just makes event-driven easier. So - allegedly - does functional programming!

> OO-design takes notice of that, and only specifies sequences within
> one event (e.g. in sequence diagrams); normally never across several
> events.

"OO design" is the shape of your real objects in real code. You are confusing
"modeling", which is techniques to draw pictures of the real objects.

> But in Use Case specifications, one HAS to specify the UC details in a
> sequence?!

Use Cases are almost never about objects. They are about the sequence of events
between major entities. User <-> Application <-> Webservice. Etc.

> 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.

Because not all models are for all things. Use Cases are not for low level
details. And, yes, you rapidly get to state tables if you must specify
stochastic input events like that!

Now, how are your unit tests?

--
Phlip

On 5 aug, 13:20, Phlip <phlip2...@gmail.com> wrote:
> Anja wrote:
> > This annoys me for some time:
> > OO-development is event-driven: each event can possibly occur at any
> > given time.
>
> Not necessarily. If a given routine needs to be sequential, you code it like that.
>

Good event-programming should not rely on the sequence they're used
in.They should work in any sequence they are used.

<snip>

> > I have never seen such a way to describe Use Cases, and I wonder why.
>
> Because not all models are for all things. Use Cases are not for low level
> details. And, yes, you rapidly get to state tables if you must specify
> stochastic input events like that!

Use Cases can be used on many levels, there is to my knowledge no
limit on the level of detail on a Use Case. But it seems to me that
the higher the level, the more useful a Use Case is.
Wouldn't it be better to model interactions between "major
entities" (as you call it), objects, actors, etc. *not* sequentially?



> Now, how are your unit tests?

Fine, thank you.
They are for low level tests of units, not for testing use case
scenario's.

Anja.

Anja wrote:

> Good event-programming should not rely on the sequence they're used
> in.They should work in any sequence they are used.

That's a definition of event-driven.

You can get that with an object-based system, so OO makes it easier than, say,
BASIC or Fortran.

Yet you can't say "my design is more OO, and therefor better, because it's more
event-driven". Some algorithms don't require event driving, and they still need
OO to do things like polymorph methods.

>> Because not all models are for all things. Use Cases are not for low level
>> details. And, yes, you rapidly get to state tables if you must specify
>> stochastic input events like that!
>
> Use Cases can be used on many levels, there is to my knowledge no
> limit on the level of detail on a Use Case. But it seems to me that
> the higher the level, the more useful a Use Case is.
> Wouldn't it be better to model interactions between "major
> entities" (as you call it), objects, actors, etc. *not* sequentially?

I always thought use cases were for specifying a system's input, processing, and
output.

>> Now, how are your unit tests?
>
> Fine, thank you.
> They are for low level tests of units, not for testing use case
> scenario's.

They are also for making your modeling less important. If your design is easy to
refactor, then you don't need to put so much effort into getting its design
right before coding it.

--
Phlip

Responding to Anja...

> 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.

First, within a Sequence Diagram, each collaboration (line) is triggered
by an event. So I don't understand what the last sentence is saying. Do
you mean that the responding state machine action might include multiple
use case steps? If so, that would be unusual since state machine actions
are supposed to be logically indivisible and most use case steps imply
complex software processing. IOW, individual use case steps more
commonly involve multiple events and actions in the software. (I have
worked with applications where an entire subsystem was needed to
implement a single use case step.)

Second, OO development is not inherently event-based. For example, all
knowledge access is *always* synchronous. In OOA/D it is common to use
object state machines and an asynchronous model for behavior
communications because that happens to be the most general model of
behavior. [An OOA/D model constructed with asynchronous behavior
communications can always be implemented in any computing environment
without change. However, an OOA/D model constructed with synchronous
behavior communication cannot always be implemented correctly in an
asynchronous environment without change.] But the developer is not
required to use an asynchronous behavior communication model in the OOA/D.

> 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.

Use cases are a form of requirements specification, not solution design.
In particular, they describe how a user interacts with the software. The
sequence may or may not be mandatory and determining whether it is
mandatory or not often requires addition domain knolwedge. In your
example, the requirements define a specific cause/effect dialog between
user and software, so the sequence must be honored. But that is not
always necessary.

When the use case sequence must be honored, the most common way to deal
with that is with the notion of a protocol between user and software.
Protocols essentially require participants in the protocol to wait for
an announcement that the other participant is ready to continue.
Protocols are easiest to define if one uses object state machines so
that the state machine transitions enforce the sequence requirements and
each message is an event that announces the sender participant is done
with its task and is waiting for something to do. The event receiver
does something in response to that announcement, sends an event back to
the other participant to announce its completion, and waits for
something to do. In effect the event queue serializes the asynchronous
processing so that everything gets done in the right sequence because
each object state machine responds to only one event at a time and those
responses are triggered by the other participant.

The point here is that the use case specifies the protocol sequence when
the sequence is important. The software just uses events and object
state machines (among other approaches) to implement the protocol.

> 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.

Since all the use case needs to define is the required protocol sequence
in this example, this sort of specification would be overkill.

There are situations (e.g., common in telecomms) where the most
convenient way to describe complex sequencing is directly with a state
machine. In that case, the use case will include an explicit reference
to the state machine. (In UML such state machines are special and are
quaintly called "protocol state machines".) However, the software is not
obligated to implement exactly that state machine (and usually doesn't
because protocol state machines are usually Mealy models while OO
software works better with Moore models). In fact, the software doesn't
need to use a state machine at all to implement the protocol. The
software just needs to ensure that it will behave as if that state
machine were used.


--
There is nothing wrong with me that could
not be cured by a capful of Drano.

H. S. Lahman
hsl@pathfindermda.com
Pathfinder Solutions
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
"Model-Based Translation: The Next Step in Agile Development". Email
info@pathfindermda.com for your copy.
Pathfinder is hiring:
http://www.pathfindermda.com/about_us/careers_pos3.php.
(888)OOA-PATH

The point is that *all* Use Cases I've seen described a sequence,
wheras, to my opinion, interactions between systems and between actors
and systems should be described as asynchronous as possible.
Is there a good way to describe asynchronous processes in Use Cases?

Anja.

Anja wrote:

> The point is that *all* Use Cases I've seen described a sequence,
> wheras, to my opinion, interactions between systems and between actors
> and systems should be described as asynchronous as possible.
> Is there a good way to describe asynchronous processes in Use Cases?

Use cases describe external scenarios - synchronous by nature. Event-driven is
an internal consideration, so other notations should describe it.

--
Phlip

Responding to Anja...

> The point is that *all* Use Cases I've seen described a sequence,
> wheras, to my opinion, interactions between systems and between actors
> and systems should be described as asynchronous as possible.
> Is there a good way to describe asynchronous processes in Use Cases?

I suspect the problem here is that since asynchronous communication is
the most general way of describing behavior, you want to use that mode
in the use case. But the use case is not describing software behavior;
it is specifying requirements in the form of a set of inherently
sequential interactions between the actor and the software.

There are actually three different concerns involved: specifying the
requirements in the use case; a communication mechanism between Actor
and software; and the software resolution of the requirements. The last
two are an issue for software design and one can choose either
synchronous or asynchronous implementations. But requirements are not
supposed to care how the solution is implemented so that choice doesn't
matter since the use case is not designing the solution behavior.

So I think it's unnecessary to use an asynchronous description in the
use case. The use case defines a sequence of steps, by definition. Those
steps are of two kinds: (A) direct interactions between Actor and
Software and (B) discrete activities the software must perform.

The interactions are inherently synchronous because each participant
responds directly to something the other participant does (e.g., the
software requests a PIN, the user types it in response, then the
software displays a starter page in response, the user makes a choice in
response, etc.). On the software side one may cast those interactions
into a protocol for object state machines. Then the software
*implementation* of the communication mechanism is an event-driven
solution where FSM transitions capture the sequencing rules. But from
the Actor's perspective there is nothing asynchronous about it; every
response is in a predefined sequence.

The discrete activities the software must perform may or may not need to
be done in the use case predefined sequence. That is resolved by
dependencies among the activities in the software solution. All the
software needs to ensure is that the results are always what would occur
if they were executed in the use case's sequence. Whether that sequence
of activities is executed synchronously or asynchronously is a pure
software design issue and has nothing to do with the use case.

IOW, the use case sequence is a matter of *specification* while the
employment of asynchronous or synchronous processing in the software
solution is a matter of *implementation*.


--
There is nothing wrong with me that could
not be cured by a capful of Drano.

H. S. Lahman
hsl@pathfindermda.com
Pathfinder Solutions
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
"Model-Based Translation: The Next Step in Agile Development". Email
info@pathfindermda.com for your copy.
Pathfinder is hiring:
http://www.pathfindermda.com/about_us/careers_pos3.php.
(888)OOA-PATH

Very good summary, H.S.!

> The interactions are inherently synchronous because each participant
> responds directly to something the other participant does (e.g., the
> software requests a PIN, the user types it in response, then the
> software displays a starter page in response, the user makes a choice in
> response, etc.).
That's the very point where I do not agree.
In some cases, I do not care in which order a user enters the
information.
E.g. 1. Enter order details; 2. Enter shipping address; 3. Enter
billing address
or 1. Enter billing address 2. Enter order details 3.Enter shipping
address
or ...

Systems should be able to function in ways where participants do not
react in a strict order. (I love complete chaos! ;-) )

But sadly, I cannot specify such requirements in Use Cases.

Anja.

Responding to Anja...

>> The interactions are inherently synchronous because each participant
>> responds directly to something the other participant does (e.g., the
>> software requests a PIN, the user types it in response, then the
>> software displays a starter page in response, the user makes a choice in
>> response, etc.).
> That's the very point where I do not agree.
> In some cases, I do not care in which order a user enters the
> information.
> E.g. 1. Enter order details; 2. Enter shipping address; 3. Enter
> billing address
> or 1. Enter billing address 2. Enter order details 3.Enter shipping
> address
> or ...
>
> Systems should be able to function in ways where participants do not
> react in a strict order. (I love complete chaos! ;-) )
>
> But sadly, I cannot specify such requirements in Use Cases.

Actually, you can for this example by using variant use cases. The
implied requirement is then that the software can handle each variant
sequence.

However, I think that is beside the point. The UI has to provide a form
for each case. How does that form get presented? Usually it will be as a
result of the user making a selection about which details to do next.
That selection should be part of the use case because it reflects the UI
design and it will implicitly indicate the user can select/enter them in
any order.

Alternatively, one could present a compound form with separate sections
for each set of details. If each section has its own Save control, the
data could be entered in any order. But, again, that is part of the UI
design. The UI design is part of the requirements specification just
like the use case and it provides context for the use case. That context
will resolve the sequencing issues for the software design that supports
the UI.

What about a programmatic interface with no user UI? That interface
still needs to be specified and it still provides a context for any use
cases. The interface documentation will have to specify dependencies
between the interface elements (e.g., in the telecoms the handshaking
dependencies would likely be specified with a protocol state machine
that is part of the interface specification). [The interface
requirements may not be customer requirements; they may be design
requirements from systems engineering in such cases. Nonetheless, from
the perspective of subsystem responding to the external input, they are
requirements.]

Bottom line: use cases do not exist in a vacuum; there is a body of
implied or indirect requirements that also apply. We usually don't
clutter use case with explicit references to requirements defined
elsewhere and there are often assumptions of domain knowledge. But the
requirements context still exists and it guides interpretation of the
individual use cases.

I suppose one could argue that if use cases were more rigorously
defined, there there would be no need for that peripheral context
information. IMO, though, use cases provide a valuable level of
abstraction where one can focus on particular concerns. IOW, they are an
organizational tool that provides a very useful "backplane" for more
detailed requirements specification. [Besides, once we have a single,
rigorous language for specifying requirements, it can be compiled
directly into an executable and we'll all be out of work. B-)]


--
There is nothing wrong with me that could
not be cured by a capful of Drano.

H. S. Lahman
hsl@pathfindermda.com
Pathfinder Solutions
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
"Model-Based Translation: The Next Step in Agile Development". Email
info@pathfindermda.com for your copy.
Pathfinder is hiring:
http://www.pathfindermda.com/about_us/careers_pos3.php.
(888)OOA-PATH