Structured scenarios

[vjr]

I've just come back to using EA after a few years away from it.

I have some questions on structured scenarios.

I recently found this feature and immediately jumped at it as a way of writing my use cases (and generating their text for reports). That is, simple textual descriptions (numbered steps) of use cases and extending/included use cases as defined in the UML. (That is, as use-cases are defined; their representation isn't defined). Please tell me if there has already been a similar topic, but I haven't found one.

My concern is mainly regarding use cases vs. the term 'scenarios'. In my understanding of a scenario (not actually defined in the UML) is that it is one possible path through a use case. i.e. at 'run-time'. The use case and extensions define all possible such paths. Whereas a use case step has generic phrases such as "1. user enters password in appropriate area" a scenario step would say "user enters 'XYZ' in "Password:" field", or similar.

A use case basic path can have extension points, where the sequence of use-case steps can 'branch' off to extended/included use cases, after which it will return at the next step of the basic path (unless in error). In EA, a structured scenario has "Entry points" which appear to be extension points. However, we can choose a "Join" point where the basic path will continue after the 'alternate' or 'exception' scenario completes.

There are other differences, such as an Alternate scenario not being allowed to have Alternate scenarios of their own. So, this does not fit the definition of an extension use-case, which is allowed to have extensions.

So, I guess structured scenarios are in fact scenarios as I think of them. Especially as the EA docs state "A scenario is a real-world sequence of operations that you create to describe how an element works in real-time". However, other things confuse me, such as the option to link a step of a scenario to a use-case, either as Include, Extend or Invokes (can someone explain this?).

Having rambled on, I guess I'll ask if people use structured scenarios to document use-cases, or just scenarios (i.e. paths through use-cases) or both. If they are true scenarios, then I'm guessing you have 'actual data/values' in your scenario steps (Actions). I'd like to know how people use this feature, and if in fact people use it in different ways.

Thanks.

[AndyJ]

As far as I can tell the scenarios are just the basic flow, and alternative flows, written as you would normally write them for a use case.

However, we have not been successful with the structured scenario editor, because of the problem that you mentioned... an alternative flow cannot be launched from an alternative flow.

This forces the author to use "extend" use cases in circumstances where this is not appropriate.

The overall effect is to force use cases into "functional decomposition" which seriously impairs the effectiveness of use cases.

So...

Short term, we're using the unstructured approach, hoping that this limitation will be lifted soon. (I've sent in a feature request).

The structured scenario editor does have some good advantages like:

* being able to mark text up as a hyperlink to other objects in the model (particularly classes on the domain model)

* automatic generation of activity diagrams that show the logic of the use case.

Hopefully that's some help for your thinking.

[vjr]

Thanks for the feedback even though my post is a bit waffly. I was about to report back that the SS editor won't meet my needs, but I've taken another look and I can probably use it to generate at least the initial documentation, which still might need manual editing.

I agree it's nice generating an activity diagram from a use case (and vice-versa) although it has some quirks, but I might raise separate topics to discuss that. The hyperlinks/context feature is nice as well. I haven't found a use for the Uses/Results/State columns yet, but I know they relate to the different diagrams you can generate. And yes having alternate flows off alternate flows would be nice, and fit with the UML.

As far as I can tell the scenarios are just the basic flow, and alternative flows, written as you would normally write them for a use case.

However, we have not been successful with the structured scenario editor, because of the problem that you mentioned... an alternative flow cannot be launched from an alternative flow.

This forces the author to use "extend" use cases in circumstances where this is not appropriate.

The overall effect is to force use cases into "functional decomposition" which seriously impairs the effectiveness of use cases.

So...

Short term, we're using the unstructured approach, hoping that this limitation will be lifted soon. (I've sent in a feature request).

The structured scenario editor does have some good advantages like:

* being able to mark text up as a hyperlink to other objects in the model (particularly classes on the domain model)

* automatic generation of activity diagrams that show the logic of the use case.

Hopefully that's some help for your thinking.