2

How are branching statements supposed to be written in UML use case descriptions? Here is the situation I am modelling -

An employee has to swipe a card through a card reader to clock into work. The system emits a sound signifying a read success or failure. If the read fails three times the user is given the option of entering their details manually into a PC.

Here is the use case description I have made, it seems very awkward and unclear with all the if/elses. Is this the way use case descriptions are supposed to be written or is there a better method?

enter image description here

sonicboom
  • 4,928
  • 10
  • 42
  • 60

5 Answers5

4

The UML specification does not specify any way to show branching within a use case specification. However, modelers have come up with a few suggestions one of which is very similar to what you already have. In the book UML 2 and The Unified Process (page 82) one such approach is introduced:

"Use the keywords 'If' and 'Else' to indicate a branch within a flow. You can clearly indicate the body of an 'If' statement by careful use of indentation and numbering."

n. If condition
    n.1 Do something
    n.2 Do something else
    ...
n+1. Else
    n+1.1 Do something
    n+1.2 Do something else
    ...
n+2. ...

Note that you may want to drop the 'end if' phrases. The book also introduces other keywords such as 'For' and 'While'.

From my personal experience however; flows of complicated use cases will not be read by anyone when they are expressed in text. The best approach I have seen in the industry is to use activity diagrams to show main flow of use cases. This is to have a use case specification with all the other parts (preconditions, post-conditions, name, description, primary and secondary actors and ...) but leave the flow part empty and refer to an activity diagram as completely explained by @javier. I would however mix the two diagrams and separate the user and system steps by activity partition (swim-lanes).

Sequence diagram is definitely not an option.

jurgenreza
  • 5,856
  • 2
  • 25
  • 37
0

For me, the best would be to create a UML usecase and describe it with a sequence diagram...

Red Beard
  • 3,436
  • 1
  • 14
  • 17
0

Use Case diagram is not intended to represent information you want. In your case I would use sequence diagram (and it looks like you already have swimlines ;)

trigras
  • 515
  • 6
  • 18
0

If you write the behavior of your use case as text, yes. Otherwise you could model it via an Activity Diagram with send and receive actions describing the interactions between user and system.

Activity diagram

I wouldn't choose a sequence diagram because it would look as "awkward" as the natural language description (due to nesting of alternatives and loops), but it is another option, as it was stated in the other answers.

Javier
  • 12,100
  • 5
  • 46
  • 57
  • +1 Explained a bit more in my answer but referred to yours which is the right approach. – jurgenreza Mar 16 '13 at 16:45
  • maybe i'm nit-picking - but isn't there a syntax error in the right activity diagram? There's a fork node implying that both succes tone and failure tone happens in parallel? Should be a decision node... – CBudtz Jan 18 '16 at 16:54
-1

Use cases UML don't use if/then/else statements. Use cases use Alternate flows:

Main flow

N action a

N+1 result a

N+2 action a1

Alternate flow

N action a

N+1 result b

N+2 action a2

This is the Use case specification of

If result of action a is result a then do a1

else if result of action a is result b then do a2

end if

Jackson
  • 1