7 ACTIVITY DIAGRAMS  10/11/97

7 Activity Diagrams

Activity diagrams can be useful in broadly the same ways as interaction diagrams:

• to show how an object reacts to a message being sent to it, or

• to show how a system provides the functionality required by a use case.

They can also be useful for describing how use cases depend on one another, for example, when it’s the case that one must be carried out before another can be started. In this context, you might use an activity diagram during analysis to document the overall workflow of an area of the customer’s activities.

Rose does not support activity diagrams. (In very simple cases, not involving synchronisation or decision diamonds, you might be able to draw them as though they were statecharts – see Relationship between activity diagrams and statecharts at the end of the next section.)

Activity diagrams

Useful as an alternative to interaction (sequence or collaboration) diagrams for:

• detailing a use case

• explaining an an object’s reaction to a message

Also useful for showing the dependencies between use cases: e.g. workflow of an organisation.

Main advantage: can show parallel activities, so make dependencies and non-dependencies explicit.

Main disadvantage: correspondence with objects in the system may not automatically be clear. (Swimlanes, which for reasons of time we leave out, can help.)

Slide 61

Activity diagram

Slide 62

Elements of activity diagrams

activity: the rounded box showing something that happens

synchronisation bar: arrows out of here can’t be taken until all the arrows into it have been taken

transition: from an activity to the next thing (an activity, a synchronisation bar or a decision diamond)

decision diamond: used to show nested decisions. How you use them is to some extent a matter of style: e.g. in the example we could have shown three arrows out of the Find Beverage activity, with guards [found coffee], [no coffee AND no cola] and [no coffee AND found cola], but it’s probably clearer the way it is.

start marker: optional, but usual: as for state charts, see below.

end marker: ditto

guard: e.g. [found coffee]: shows under what circumstances the transition can be take. If it’s omitted, the transition can always be taken.

event: e.g. light goes out. Something that happens to trigger the transition. Usually not shown, because the transition is just triggered by the completion of the preceding activity; a matter of style.

action: e.g. ^coffeePot.turnOn. Something the system should do when the transition is taken, e.g. send a message (the message turnOn to the object coffeePot. Sometimes as here, the sending of a message is really all that an activity represents.)

8 STATECHARTS  10/11/97

Advantages of activity diagrams They aren’t sequential. In the interaction diagrams, you describe a particular sequence of messages that get sent. Even if two messages could be sent in either order, you still have to specify one order or the other in the diagram. This represents our old enemy, the premature design decision. Even in in the end you will implement the system in single-threaded code, it’s a good idea not to decide on the order of events until you must. Some orderings will be essential (e.g. check payment before deliver goods), others inessential (e.g. it doesn’t matter whether we check payment before or after we check whether the goods ordered are available). In order to keep the design as flexible as possible, so as to have leeway to change things at a late stage if necessary, it’s a good idea to maintain the distinction between essential and inessential orderings.

Of course, if your system will not be implemented by single-threaded code, your incentive to use a notation like activity diagrams, which can represent several things happening at once with specified synchronisation points, is overwhelming, particularly since multi-threaded applications are notoriously hard to understand just from code.

Disadvantage of activity diagrams Like use cases, they aren’t object oriented. The items shown are pieces of functionality, not objects. A box in an activity diagram won’t necessarily even be something that can be implemented by a single method. All the same caveats that we put on use case diagrams apply: relying too heavily on them might make you tend to ignore and compromise the object oriented structure of your system.

8 Statecharts

You’ve probably all seen state diagrams before. They are useful for describing individual objects in detail. You can describe the states an object can get into and the messages that cause it to move from one state into another. This is likely to be a useful thing to do when an object has complicated behaviour, and particularly when how it reacts to a message depends in a qualitative way on what state it was in.

What do we mean by qualitative in this context? Well, for example, perhaps a bank has a policy that customers can withdraw money, even if it makes them overdrawn, unless a stop has explicitly been put on the customer’s account. Then perhaps objects of class Account have two states, Normal and Stopped, and reacts differently to a message withdrawMoney(amount) depending on the state it’s in. On the other hand, it will send back different answers to the message getBalance depending on what the balance is, but this isn’t different behaviour in the sense we want to consider. There’s no hard and fast distinction, because ultimately all the object’s data is its state, so in the extreme you can argue that an object changes state every time any part of its data changes at all. A state diagram should show the interesting ways in which an object’s behaviour (including which messages it makes sense to send it) depends on its state, and you decide what’s interesting in the current context. (In particular, the number of states that there are in an object’s state diagram, even if we specify the object completely, is usually somewhat subjective, because two designers can legitimately make different decisions about what’s interesting.)

More formally, you can think of states as shown in a state diagram as equivalence classes of “real” states of the object, where two states are equivalent if the object “behaves qualitatively the same way” in both states. I haven’t managed to come up with a formal definition of “qualitatively” that isn’t obviously useless! Let me know if you think you have one.

Statecharts

Useful for showing the way that an object of a given class changes state, if it has qualitatively different internal states. May include:

• states

• events that cause transitions between states

• guards that must be true for a transition to take place

• actions that are caused by a given transition

• activities that take place when in a certain state

• start and end markers

States may be nested.

Most classes will not need statecharts drawn for them.

Slide 63

Most classes will, and should, have boring state transition diagrams (e.g. with one state) that aren’t worth drawing. One reason why they should is because an object which reacts in a qualitatively different way to a message depending on its state is harder for client code to interact with correctly than one that does not: there is a new class of possible errors, namely assuming the object’s in one state when it’s in another. Sometimes a complex state transition diagram is essential, but other times it’s a sign of not having found the right abstractions yet – maybe a class is trying to do the work of two, or maybe you have one operation where it would be better to have more than one.

\underline{Statechart}

Slide 64

Modelling the state changes of an object is the most common use of a UML statechart, but of course you can also use statecharts in other situations if it seems useful: e.g., to model the changes of local state internal to some complex method.

Elements of a statechart

Start: shown as a black disc. This is optional, but should usually be included. If I’d drawn the example diagram, I’d probably have put a start blob with an arrow to the Idle state, meaning that the initial state of the system is idle.

State shown as a named round-cornered box, e.g. the one named Idle. States may be nested: the example shows that states DialTone, etc., are substates of Active. Notice that a statechart nested inside a state, like the one nested inside the Active state, can have all the usual features of a statechart; here the nested state chart has its own start blob.

State compartment entry, e.g. do/play dial tone. This is an instance of a compartment entry with form do/activity, representing some activity that should be done when the object is in the associated state. The activity could be the name of another statechart.

Transition shown as a labelled arrow between states. The label has three parts, any of which can be missed out if irrelevant. (But if all three are irrelevant, there’s probably something wrong – are the states really different?). The full form is Event [Guard] /

Action. For example, in dial digit(n)[valid]/connect we have:

• an event, dial digit(n), which is what prompts the transition between two states.

• a guard, [valid], which says that this transition can only be taken if the condition [valid] is fulfilled – presumably in this case this means that the new digit n is a valid continuation of the number so far dialled. Notice that if the condition is not fulfilled, there is another transition with the opposite guard which can be taken. This condition – that if an action is possible from a given state at all, the guards on the transitions with that action OR up to true, as in this case (valid OR invalid) is equivalent to true – is very common, but UML doesn’t insist on it. That is, if we deleted the transition dial digit(n)[invalid] from the example we’d still have a legal statechart. However, it might not be clear what it meant – you should probably add an explanatory comment to a diagram in which an action is only sometimes possible from a state. It may be that the situations in which the action is possible actually correspond to something that ought for clarity to be shown as a state in its own right.

• an action connect which should be done when the transition happens.

Notice the difference between an event and an action. Basically, an event corresponds to something that happens to the object (probably the object receives a message) and an action corresponds to something the object does (probably sending a message).

End shown like a start state but with a circle drawn round it. Optional, and less important than the start symbol since any state with no outgoing transitions is obviously an end state. Use it if you think it makes the diagram clearer, perhaps to show finishing in an expected and orderly way.

Statecharts in Rose To create a statechart for a class, select the class in the class model, then choose State Diagram from the Browse menu – it’s greyed out unless you have a class selected, which seems like a bad user interface feature to me, but there you are! If you want to show an activity (or an entry, exit or upon action, which we haven’t discussed) in a state, you have to

1. get the state’s specification window up (e.g. double click on the state)

2. go to the detail tab

3. pick Insert from the shortcut menu up (right mouse button)

4. specify the activity in the Action Specification window

There may well be a shortcut that I haven’t found (let me know if you find it!)

Terminology State diagram, statechart, state transition diagram, and probably others, are all synonyms.

Relationship between activity diagrams and statecharts The UML documentation states that an activity diagram is a special case of a state diagram, namely the state diagram of a procedure. It says that the activities are the states of the procedure and the triggers are transitions.

At first sight this is very strange – if two activities are shown as happening in parallel, this interpretation says that the the procedure is in two states at once – scarcely intuitive, unless you’re into quantum mechanics, and even then the analogy is flawed!

Actually when you look into it more, you see that (although I haven’t told you about this feature) UML allows statecharts to describe multi-threaded behaviour – so even in a statechart, an object can be in more than one state at once, and this is to be interpreted as parts of the system being in the specified states. This feature could be useful if you’re describing a multi-threaded system, but is unlikely to be useful otherwise. However, it does mean that UML activity diagrams and statecharts aren’t as different as one might imagine without knowing about the extra features of UML statecharts: the concept of being in more than one “state” at once exists in both.

Accordingly the notation used by UML for statecharts and for activity diagrams is closely related. (So much so, that it’s a bit surprising Rose doesn’t support activity diagrams – you’d expect them to be able to do this easily by reusing some components :-)