Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Upcoming SlideShare
Loading in …5
×

# use case diagrams Tips and Tricks

148 views

Published on

Most of the examples of use case diagrams that I see are frankly ridiculous. With missing bounding boxes (who is using what?), arrows on one or both ends of a connector (one more time "its not a data flow diagram") and a birds nest of crossing lines that totally obscures any possible meaning that the author had.

Here are some tips and trick to solve most of these problems.

Published in: Software
• Full Name
Comment goes here.

Are you sure you want to Yes No
Your message goes here
• Be the first to comment

• Be the first to like this

### use case diagrams Tips and Tricks

1. 1. Use Case Diagram Tips and Tricks © Lonsdale Systems Swiss Army Knife Swiss Army Soldier Remove cork Cut item Turn screw Open Bottle A use case diagram has three different components: a system boundary; the actors outside the system boundary who “use” the system; and the use cases inside the system boundary, which describe the behaviour of the system. The connector between an actor and a use case shows that the actor “uses” the behaviour defined by the use case. The diagram above can be read in the following way: The Swiss army soldier uses the Swiss army knife to remove cork. Swiss Army Knife Swiss Army Soldier Remove cork Cut item Turn screw Open Bottle Australian Army Soldier It is common to see use case diagrams with many crossing lines connecting actors to use cases. This often happens when more than one actor “uses” the same set of use cases. As well as their ugly appearance, diagrams with many crossing lines can be difficult to read. There are two approaches that can be used to solve the crossing lines problem. Swiss Army Knife Swiss Army Soldier Remov e cork Cut item Turn screw Open Bottle Australian Army Soldier Use tool The first approach to solving the crossing lines problem is to create an “abstract” use case to group the use cases that are used by multiple actors. The diagram above can be read in the following way: The Australian army soldier uses the Swiss army knife to use tool; remove cork is a type of use tool; therefore it is implied that the Australian army soldier also uses the Swiss army knife to remove cork. Swiss Army Knife Swiss Army Soldier Remov e cork Cut item Turn screw Open Bottle Soldier Australian Army Soldier The second approach to solving the of crossing lines problem is to is to create an “abstract” actor to group the actors that “uses” the same set of use cases. The diagram above can be read in the following way: A soldier uses the Swiss army knife to remove cork; an Australian army soldier is a type of soldier, therefore it is implied that the Australian army soldier also uses the Swiss army knife to remove cork.
2. 2. Use Case Diagram Tips and Tricks © Lonsdale Systems Swiss Army Knife Swiss Army Soldier Remove cork Cut item Turn screw Open Bottle Open tool «include» «include» «include» «include» Sometimes it is useful to show common behaviour that is shared by a number of use cases. This can be achieved by including the common behaviour in the use cases using an <<include>> connector. The diagram above can be read in the following way: Open tool is common behaviour in the cut item; turn screw; remove cork; and open bottle use cases. Note you should not use the <<include>> connector to decompose a use case into a number of more detailed “lower level” use cases or to show the steps of a use case on the use case diagram. Swiss Army Knife Swiss Army Soldier Remove cork Cut item Turn screw Open Bottle Close tool Open tool «include» «include» «include» «include» «include» «include» «include» «include» The crossing lines problem occurs again when a number of use cases share more than one type of common behaviour. Swiss Army Knife Swiss Army Soldier Remove cork Cut item Turn screw Open BottleOpen tool Use tool Close tool «include»«include» The solution to the crossing lines problem when a number of use cases share more than one type of common behaviour is to introduce an “abstract” use case. The diagram above can be read in the following way: Open tool and close tool are included in the behaviour of use tool; remove cork is a type of use tool; therefore it is implied that remove cork also includes the open tool and close tool behaviour. Swiss Army Knife Swiss Army Soldier Remove cork Cut item Turn screw Open Bottle Scrape item «extend» «extend» Use case behaviour should always be documented in a separate scenario describing its detailed steps, as well as any alternative scenarios and exception conditions. However, it can sometimes be useful to highlight any alternate or exception scenarios that are shared by a number of use cases on the use case diagram. For example, both a knife and a screwdriver can be used to “scrape” something. This can be achieved by extending the use case behaviour using an <<extend>> connector. The diagram above can be read in the following way. Scrape item is a common alternative scenario for the cut item and turn screw use cases.
3. 3. Use Case Diagram Tips and Tricks © Lonsdale Systems Accommodation Front Desk Clerk Enter Reservation Record Check In Record Check Out «actor,secondary» Smart Card Programmer Call Centre Operator Produce Bill Back Office Clerk Enter Guest Details Record Reservation Check In Record Walk-In Check In Upgrade Room «extend» «include» «used by» «extend» «include» The use case diagram above describes the behaviour of the Accommodation sub-system of a Hotel Management application. The first thing to notice about the diagram is that it introduces the “box” notation for actors. This notation is more appropriate that the stick figure for external applications and devices. The smart card programmer actor is a device for programming the smart cards that that guests use to unlock their rooms. It is also a “secondary” actor. Secondary actors are different to the primary actors that “use” the accommodation sub-system as they provide services to (or are “used by”) the accommodation sub-system. The diagram above can be read in the following way:  The call centre operator uses the accommodation sub-system to enter reservation  The front desk clerk uses the accommodation sub-system to record check in  Record reservation check in is a type of record check in  Record walk in check in is a type of record check in  The smart card programmer is used by the accommodation sub-system to record check in  Enter guest detail is common behaviour in the enter reservation and record walk in check in use cases  Upgrade room is a common alternative scenario for the record reservation check in and record walk in check in use cases  The front desk clerk uses the accommodation sub-system to record check out  The back office clerk uses the accommodation sub-system to produce bill It is important to remember that use case diagrams do not show the flow of information and resist the temptation to add arrows to the connectors between the actor and the use case.