Sparx Systems Forum

Discussion => Uml Process => Topic started by: jepessen on December 07, 2016, 07:15:42 pm

Title: Use case with optional steps
Post by: jepessen on December 07, 2016, 07:15:42 pm
I want to draw an use case for closing a program.

If I select the close button, the program shows a dialog ask for confirmation and if confirmed closes. This happens when no documents are opened.

But if one or more documents are opened, I want to show before the dialog for closing the program, dialogs for saving and discarding opened documents.

Do I need to create different use cases (one for closing programs with no document opened and another one for closing program with opened document), or there's a way to define optional steps in an use case?
Title: Re: Use case with optional steps
Post by: qwerty on December 07, 2016, 08:38:20 pm
No. A use case is not a sequence of actions. It is some unique added value brought to its actor. Place any sequence of actions you construct in activities representing scenarios inside a use case.

Title: Re: Use case with optional steps
Post by: Geert Bellekens on December 07, 2016, 08:54:45 pm
you could make it an alternate scenario, or simply write as step:
"If there are any opened documents the system will ask the user for permission to close them"

Use cases in general are pretty much free format.

Title: Re: Use case with optional steps
Post by: jepessen on December 09, 2016, 08:26:40 am
Ok thanks for your replies.
Title: Re: Use case with optional steps
Post by: Uffe on December 09, 2016, 06:07:37 pm

The thing to be careful with when you're writing use cases is not to get into the design of a solution. A (good) use case describes the interaction between a user and the system under analysis, and is expressed from the user's perspective.

If you're concerned with overlap between use cases, don't be. Use cases are part of requirements analysis, and requirement overlap is perfectly fine. It's the design, not the requirements analysis, that takes care of those overlaps. (In fact, the number of times a requirement recurs can be used as an indicator of which requirements should be prioritized in the design.)

The key factor when determining whether to split a use case into two is whether or not the two use cases describe interactions which are distinct in terms of what they achieve for the user.

In this case, the user wants to exit a program. Would the user think that closing a program with save confirmations is fundamentally different from closing a program without save confirmations?

In most cases, the user would not. But in some cases, they would. So that's when you get into user analysis: who is the user? For whom are you designing the system?
Without that information, no one else can tell you whether it should be one or two use cases.

I think that's essentially what qwerty was saying, just with fewer words. ;)

Now, in order to describe the imagined flow through a use case (which is nothing to do with the designed flow through a GUI), you can use activity or sequence diagrams. I've seen state diagrams used for this purpose as well, which is sometimes a good fit. Each allows branching, loops and conditions.

EA also allows you to create scenarios in the properties dialogs of the use case elements. You can set up different whole scenarios, as well as branches and joins between paths. I prefer not to use these, diagrams are clearer and give you a far wider range of expression.


Title: Re: Use case with optional steps
Post by: jepessen on December 10, 2016, 10:12:45 am
This explains a lot, thanks.