Use Cases - Why Narrative as Text.....

[SamJolly]

Dear All,

I am continuing my reading on Use Cases. However why do Use Cases need to be text. I have come across a couple of options:

a) Text as Story - can be long and involved, also can take a while to write.

b) Text as 'Flow of Events', using Numbering and indentation. Better, but need fresh 'flow of control' narrative for alternate scenario- therefore can also be long and hard to create.

Why can you not represent what goes in the Narrative as some form of flow diagram probably the 'Activity' diagram where you could potentially represent all alternate flows on one diagram. And if this is possible how would you do this in EA.

Thanks for any advice,

Sam

[thomaskilian]

Pls. read http://www.sparxsystems.com.au/cgi-bin/yabb/YaBB.cgi?board=UMLPRO;action=display;num=1078736293

[SamJolly]

Thomas,

a) Does this mean that Text is preferred?

b)How would you associate an activity diagram with a Use Case in EA.

Thanks,

Sam

[Bruno.Cossi]

Hi Sam,

the easiest way would be to create the Activity Diagram underneath the Use Case (as a child diagram).
If for any reason you wouldn't like that way, you could also link the Activity Diagram back to the Use Case, ideally by the <<realize>> relationship.

Bruno

[SamJolly]

Hi Bruno,

Thanks for the comment.  Yes I can see how creating a child diagram could work for me. However I am still unsure about why scenarios have been text based? It seems I am in the minority in using an Activity diagram to represent the scenarios. What are your views on this?

Thanks,

Sam

[Bruno.Cossi]

Hi Sam,

that is a good question for which there is not, I am afraid, a simple answer. Just by looking at this site (or at a number of Use Case models created in real life) you will see that the way different people use scenarios differs greatly.
Personally, I like the scenarios to be what used to be called "user stories". Description of the Use Case from the users point of view. As simple as this (I am just making up a "fake" Use Case now):

Use Case: Enter Purchase Order
1. User enters a purchase order
2. If the currency is not Canadian Dollar, user specified whether the monthly average exchange rate or the current exchange rate will be used
3. Order is saved, system prints out confirmation number.

Now, there is no doubt that you could build a scenario like this as a very simple Activity Diagram and it would work just fine. There are some advantages to the textual form though.

1. The text is written in the language of the business (using the terminology of the customer etc.). Thus, it is understandable by all of the future users (even if they do not understand UML), they can easily comment on it and ensure that your scenarios are correct.
2. The scenarios can be built very quickly and easily modified, should the need arise (and arise it will :-) )

Now, scenario written in this way reflects behaviour of the system from the user's prospective. It tells you WHAT the system does, not necessarily HOW. The HOW is described later using additional diagrams, that describe the Use Cases in more detail, be it Sequence (Interaction) diagrams, Activity Diagrams etc. etc.
The Order Entry screen, that will need to be created in order to accommodate the scenario I have described above, will likely make use of number of objects in your system - that would be described using a Sequence Diagram. The process flow would be described in detail using the Activity Diagram etc. etc.

In other words, the distinction between the textual scenario and the Activity Diagrams, the way I see it, reflects the distinction between the Users' and the System Analysts' view of the system.

Hope this helps!

By the way, you may be using your scenarios somewhat differently. I would be interested in hearing what you think of this.

Bruno

[sargasso]

Our "process" is something like this.

1. Make a list of named use cases. In EA this is add a bunch of footballs to a work-in-progress diagram, adding nothing but the name.
2. Rationalise the list.  In EA, sit with the SMEs and highlight (bold, colorise, rename, delele redundant, etc etc whatever) the list into the "significant use cases".
3. Describe each significant use case.  In EA, sit with the SME's and add one to two paragraphs to the use case Note field describing one or more (as you see fit) of the following:

• In one or two sentences, what does it achieve.
• In one sentence, what "makes it start".
• In one sentence "when is it finished".
• In a few sentences, generally how does it go about achieving what is does, what business things are involved, etc
• STOP NOW

4. Review the above against your system context and scope. Is everything still sensible? What questions are raised by the information? What DO we now understand about what we DONT know?  In EA, record  all these as element issues.
5. Consider each significant use case in turn and conceive possibilities that other outcomes may exist.  In EA note each one as a possible scenario - record the name only.
6. Go back to the SMEs and resolve these issues and for each use case explore and rationalise the scenarios. gather detailed information on the scenarios that require detailed documentation.
7. Do a first cut of the business object model and put it up as a "straw man" model.  In EA, pull out the nouns etc etc.

The time guideline for all the above - for a "medium system" = about 3 days.  That gives you an idea of the amount of detail expected.

Bruce