Thursday 12 December 2019

Rational Rhapsody Tip #71 - Use case diagrams in Rational Rhapsody (Simple)

This is the 3rd in a series of videos I'm created showing Rational Rhapsody's implementation of diagrams in the Unified and Systems Modeling Languages (UML/SysML). This video, which includes narration, covers the use case diagram. Use case diagrams are a core notation in both UML and SysML. However, I often find them one of the notations that is both simple but easy to get wrong, particularly when engineers forget that the use case isn't actually described in the diagram, just its relations. In this 10 minute video I show the creation of a use case diagram, explain the concept of actors, and then explore 3 relations that you might use on a use case diagram; generalization, include and extend. At the end of the video I highlight the importance of understanding the scope, or subject, of the use case and hint on the complementary relationship between use cases and textual requirements. As an expert in Rhapsody, I work with clients across the world to help them extract increased value from modeling by speeding up and directing modeling tasks using profiles and different model-based methods for systems and software engineering.

















Here's the transcript:

Hello, in this third in a series of videos about different UML and SysML diagrams in Rhapsody, I'm going to cover use case diagrams.

Use case diagrams are a type of behaviour diagram, and they go right back to the origins of the Unified Modeling Language in 1996.

Use cases came from a methodologist called Ivar Jacobson, whose Object Orientated methodology at the time focused on understand the usage of a system as a series of steps called use cases, and using these to identify objects that might be realised in an object orientated design.

If I was going to build an air traffic control system, for example, I might write the use case of how an air traffic controller performing a series of steps to control a flight, and then using these steps to identify candidate classes that might exist in the design, such as aircraft, aircraft routes, flight plans, and airspace's such as special use air spaces.

I'll show you this with Rhapsody 8.4 and I'm going to quickly use one of helper profiles I've created called the ExecutableMBSEProfile, because it has a method based on use cases.

So let's create a project called UseCasesExample.

Essentially the Profile helper here uses Rhapsody's Java API to automate steps to bootstrap the model with the SysML profile and a package structure that includes a use case diagram and a shared actors package.

Let's create a use case diagram for a Dancer. A Dancer is system that exhibits emergent behaviour based on a combination of components that includes legs, arms, hands and a torso.

The use case diagram essentially gives a functional context diagram, where the use cases are stories about how the system is used, and actors represent roles played by elements outside the system that interact with it.

If this system represents a dancer, then outside the system interacting with the system, or getting value from the system, might be the audience. Another actor that the system interacts with, or participates in the use case, might be the dance floor.

A use case for the dancer system, where the audience gets value, might be to Perform a dance.  Use cases define the offered behaviours without reference to the internal structure of the system. These behaviours, involving interactions between the Actors and the subject, may result in changes to the state of the system.

If we work our way through some of the elements in the toolbar, an association between an actor and a use case tells us that the actor participates in the use case.

The main thing for me is that the use case diagram doesn't tell us the steps in the story, just that the use case exists. The diagram is therefore a 30,000 ft view of the system, and it's a bit like the index of a library where each use case here represents a book describing a story of how the system is used.

Actors by convention are always outside the system, however, we can add a boundary or subject box here to make the subject of the use case clearer. In this case I'm saying the subject for the use case is the dancer. It's important that you don';t put the system or anything inside the system as an actor.

Of course, it's possible for the system to interact with another dancer.

The role that that dancer might play with respect to the system in this case is as a dance partner. The same person may also play other roles, for example, as a Spouse but the use cases would be different.

A use case is an end-to-end use of the system to perform something of value with respect to an actor, and we should try keep the use cases as big as possible. It's very easy with use cases to turn a steak into mincemeat.

Let's look at these three different types of relationship we might use between use cases; generalisation, include and extend.

Suppose that there are different types of dances and that each type of dance has a fundamentally different set of steps, but they all involve an audience and a dance floor.

Well, I could call each of these dances out as a separate use case, and then use a Generalisation relationship to say that they are all types of a Perform a dance use case.

Gangnam style, and performing a Waltz are both types of Performing a dance. However, the steps are very different, and the Perform a Waltz involves a partner.

Note how the Generalization means that the specialised use cases inherit the relations of the base use case. If we didn't use generalisation then we'd need to draw associations to both the Perform Gangnam Style and Perform a waltz for both the Dance Floor and Audience actors. We'd lose some of the meaning conveyed by the generalisation relation and we'd end up with lot's of crossing lines, making the diagram less easy to understand.

By pulling them out I can say that Performing Gangnam style is associated with a YouTube video camera actor, whereas Performing a waltz needs a dance partner.

The include and extend relations are also ways in which we can show relationships across use cases.

If we define a use case as a set of steps including alternate steps that yield an observable result to an actor, then we sometimes want to write some extensions to a set of steps without polluting the original use case.

We can do this by adding an extends use case. For example, dealing with sprain might include quite a lot of steps such as icing the limb and elevating to reduce circulation, but we don't really want to write these steps as part of the perform a dance use case, so we've factored them out, and we're going to draw an Extend relation from the use case defining the extension steps to the use case it extends. Note the direction of the dependency here, the Perform dance use case is not dependent on dealing with a sprain.

Let's make a little more room. In Rhapsody if I hold down the alt key then I can resize a container element without re-sizing it's inner elements.

It's important to remember that a use case is defined as a set of steps including alternate flows that yield an observable result of value to an actor. It's essentially a story that shows the use of the system. The use case diagram does not describe the steps of the story, and hence really just tells us that the story exists.

We can describe the use cases in many ways. I often like to use activity diagrams. My free helper here, conveyed by my profile, works on the double-click hook and creates a new diagram from a template.

I might say that the trigger for the use case is dance partner taking the dancer by the hand.

And, as you all know, to dance the waltz you need to

Step forward with the left foot
Right foot step sideways to the right
Bring your left foot next to your right foot
Step back with the right foot
Step back sideways with the left foot
Bring your right foot next to your left foot

Of course, you might not have known this, or you may have got them wrong, and hence it helps to write them down and review them with experts.

This is only if you are the lead, of course, if you're the follower then you do something different. This is where an alternative flow might come in.

When playing the female, the dancer would start by putting their right foot backwards (or do we?).

Let's return to the use case diagram.

Now sometimes we have a set of steps that get reused in more than one other use case, which is where the include relation comes in.

I'm not saying I would do it like this, nor would I recommend using include relations if you can get away without them. However, suppose that I determine both gangnam style and performing a waltz need to start with a warm up. Well I could write the steps for a warm up separately, and then include them from the use cases that require them.

My tips are really that you should on;y do an include when you've written steps that you think need to be factored out, and when you have identified that two or more use cases need them. Resist the erge, if you can.

Secondly, make sure that the included use case is 'chunkey' enough to factor out the steps. As soon as I start to use relations, then I make my diagram less clearer, and more esoteric. This works against the original goal of the use case diagram which is to work with customers and users to understand how the system will be used, before you start to build it.

So that's it, the use case diagram, a high level functional context diagram giving a 30,000ft view about what the system does for whom.

I particularly like the idea that use cases are very complementary to requirements. I often put the goals of the system as textual requirements, e.g. The dancer shall be capable of leading a Waltz.

Also, I like the idea that use case diagrams should be created collectively, and are a good requirements elicitation vehicle if done well, particularly as they focus on clearly understanding the system boundary.

If I changed the system boundary then it could quite dramatically change the actors and the use case. As the dance partner would no longer be external to the system. And Perform Gangnam style would not be a use case of the system, as it's not an emergent behaviour realized by a dance couple.

Hopefully that helps. If you feel inclined then feel free to go away and try the steps yourself, or with a partner. My name is Fraser Chadburn. I specialise in tool-based training and consulting in IBM products, and in particular setting up Rhapsody using domain specific profiles. My other area of expertise is easing modelling by using Java automation and profiles to speed up and simplify modelling tasks so that users can focus on creative and fun systems and software engineering. If you do have any questions then feel free to contact me on my email address.

Automotive features and functions

Over the last couple of weeks I've been working with a US-based client on feature and function modeling, a common theme for automotive customers. A key question is often what is the best underlying UML/SysML model for capturing these kinds of concepts, and how much domain-specific language (DSL) to exploit within the tool. Having tried to convince automotive clients of conventional UML/SysML approaches in the past, I've begun to err on the side of creating function and feature concepts as first level elements. It's interesting because it breaks down the barriers to consumption of the models, and also means that you have the flexibility to build profiles that directly fit the customers needs and wants.