Use Cases Scenario

[maneuver]

Hello , is there any way to put an alternate flow within a use case scenario, within another alternate flow ?

example:

1a . Customer or Manager indicates the resumption of a suspended sale.
   1. Cash performs the recovery operation and inserts the identity to retrieve the sale.
   2. System displays the status of the resumption sale, with subtotal.
     2a . Sale not found     (alternative flow inside another alternative flow )
           1. System signals box over error.
           2. Cashier probably starts new sale and reinsert all items.
   3. Cash continues to sale ( probably entering more items or where the payment.

The buttons "Add Alternate Path and Path Add Exception " are disabled, in an alternative flow.

Is there a way to do this in EA?

[qwerty]

Not with the structured scenarios. For that simple reason I encourage users to write scenarios with notes and numbered lists (according to Cockburn).

q.

[Eve]

We've discouraged people from doing that since we introduced the structured scenarios.

[qwerty]

Sure, but YMMV. I'd recommend it if you could describe all scenarios that way, but you can't.

q.

[Geert Bellekens]

I think it's a best practice to only have alternate/exception scenario's branching from the main scenario, but I don't think EA should enforce that.
Enforcing a best practice like that is inconsistent with the rest of the behavior, where EA never restricts anything at all.

Ideally there should be a setting somewhere to turn this check on or off. (I would leave it on)

Geert

[jfzouain]

I also agree with Simon.
When creating Use Case the alternate or exception should be complete, in other words no alternate out of alternate.
The reason I say this, when creating the test cases you should have complete and individual test cases for each alternate or exception.

I know is not ideal, dissagreen with q and Geert, but it has proven is better for QA to test each path.
My 2 cents

[qwerty]

I don't know why you think alternates from alternates or exception in alternates are incomplete. Any control flow has some start and end. It will not lead into the void. It's an illusion to think that use cases have a simple straight path with max one alternate path. In my world life is simply difficult.

q.

[Doubled]

The lack of the possibility to define an alternate within an alternate is indeed a problem when using alternate scenario's. It forces me now to define scenario's with overlapping steps.
I can understand that generating activty diagrams with alternates within an alternate will get complicated for Ea, but for me it would have a lot of added value.

[jfzouain]

qwerty

I am not saying that is incomplete, but best pratices dominates.
You can have one basic (Happy) path and as many alternates needed, same for exceptions.

Hopelly in the near future Sparx (EA) can introduce that feature and make our world easier, so when the path is generated it will pick up that alternate from the alternate branch.

[qwerty]

Jose, if you read Cockburn you'll find that sunny day scenario too. And that's fine. But you will not find any mentioning of limiting alternatives to just on branch. That would simply be silly and impracticable. I concur that most of the scenarios can be described by the simple way EA supports in its structured scenarios. But if you got a single UC that is not supported you're pissed. Then you have to find an awkward work around. So my recommendation: stick to Cockburn style and use numbered lists.

q.

[AndyJ]

My apologies qwerty, but I don't ever recommend Cockburn's approach.

Whenever I encounter someone shouting about "useless cases" they're commenting on that style of use case.

May I humbly recommend "Use Case Modeling" by Kurt Bittner and Ian Spence...

While, I would also like to be able to launch alternative flows from within alernative flows, it only seems to turn up when the use case is already too complex.

Perhaps you would like to meet my two friends:

<<include>> and <<extend>>

 

[qwerty]

Weil, I have that in my shelf (actually before reading Cockburn) and I like it. So if you read on p. 247 (Alternative Flows...) they tell exactly what I said above. Cockburn is more formal but basically telling the same thing. The principle is the same, though Cockburn's style might not be everyones friend.

I concur that too many alternative nesting is a sign of a wrong cut. But not at the first level.

Ah - and don't get me started with include/extend. Their over-use is clearly a sign of use case analysis rather than use case synthesis (see Bittner for that, it's my favorite!).

q.

[Geert Bellekens]

While, I would also like to be able to launch alternative flows from within alernative flows, it only seems to turn up when the use case is already too complex.

Perhaps you would like to meet my two friends:

<<include>> and <<extend>>

I tend to agree with Andy and of course you should be cautious not not over-use includes, and definitely not extends.

In my team I have even forbidden extends. Our analyst may only use include. The reason for this is that there is way to many confusion about what an extend really should be, and (almost) nobody in my organisation has a good idea of what an extend actually is.
I have yet to encounter a case that cannot be solved by using includes alone.

Geert

PS. More fun discussion about this on Stackoverflow

[qwerty]

PS. More fun discussion about this on Stackoverflow

Yeah. One of the spider's web examples

q.