State diagrams

Sequence diagrams give us information about how objects can interact with each other and collaborate to carry out a task. In UML, we specify the behaviour specified in individual classes through state diagrams which specify how an object reacts when one of its methods (operations) is called. They are based on extended finite state machines.

State diagrams
At any given time, a state diagram is in a certain state and can take part in an event such as having one of its methods called. As a consequence of that event, the object can: move to a new state, perform actions such as calling the methods of other objects, change the values of attributes. We say that the event triggers a transition. We label the transition with the name of the event.
1 2

Example
Let us look at this through the simple example of our Account class. The state of an Account object can change when we deposit or withdraw money.

State diagrams
The states that an Account object can go through can be shown in a state diagram.

State diagrams
The filled circle is the start marker. It means that when a new object of class Account is created, it starts in the nofunds state. Objects of class Account can accept calls of methods deposit and withdraw. The state diagram shows that when an object is in the nofunds state, the only method that can be called is deposit. When it receives a call of deposit, it moves to the funds state.
5

State diagrams
When in the funds state, it can receive more calls of deposit. These cause us to stay in the funds state. The effect of withdraw depends on the current state of the object. When we are in state nofunds, we cannot withdraw money. When we are in state funds, its effect depends on whether there are sufficient funds to satisfy the request.
6

State diagrams
There are three situations: sufficient funds: stay in funds state and decrement balance attribute. exactly correct funds: move to nofunds state and make balance attribute zero. insufficient funds: we can regard this as an error, i.e. we should never receive a withdraw message in this circumstance.

State diagrams
To keep things simple, we are only modelling correct situations, i.e. we are not showing error transitions in the diagram. They would greatly complicate the diagram. We distinguish between different correct behaviours by putting guards on events. Note the connection with pre- and postconditions.

State diagrams
If we take the Design by Contract view then when we have the pre-condition: amount<=balance on the withdraw operation, the Account class does not have to specify behaviour when the pre-condition is not met. It is the responsibility of the client to ensure that the pre-condition is satisfied.

State diagrams
We can associate actions with each event. An action can involve: calling a method, changing an attribute such as balance. However, in the early stages, we do not want to put too much detail into a state diagram; the emphasis is on getting the main structure right.

10

Library Example
Let us now model the Copy object that we had in the Library case study.

Copy object
When a Copy object is initially created it is in state onShelf and may receive a borrow message.

11

12

Copy object
As a result of receiving this message, the Copy object will (according to the sequence diagram) call the inform method of its associated Publication object and the borrow method of the Member object that is doing the borrowing. We show this action by putting these calls after a '/' and separating them by a semi-colon.

Copy object
The call of borrow has a reference to the borrowing Member object as the parameter m. When the Copy object was created, the association with a Publication object was set up. That is shown in an implementation by the Copy object having a reference to a Publication object as the attribute pub. We then use m and pub in the actions of calling other objects methods.
14

13

Copy object
Instead of writing the actions on the transitions, we can write the actions inside the state. There is an implicit entry event when a state is entered and an exit event when it is left. The state diagram for Copy can be shown in either of the two following ways.

Copy object

15

16

Actions

Class Publication
Let us now look at a possible state diagram for Publication:

UML does not indicate what the syntax of the actions should be. As well as message calls, we can have assignments to update the values of attributes.

17

18

Generating Code
The state diagrams have defined the behaviour of an object of class Copy. It is therefore possible to generate the corresponding Java or C++ code. As we are following the idea of Design by Contract, we have made the decision that an unexpected message is just ignored. Hence, if a Copy is in state onLoan and the borrow method is called, it is ignored.

Generating Code
class Copy { // define the possible states private final static int onShelf = 0; private final static int onLoan = 1; private int currentState; private Publication pub; public Copy(Publication p) { pub = p; currentState = onShelf; } // constructor
19 20

Generating Code
public void borrow(Member m) { if (currentState == onShelf) { [Link](this); [Link](this); currentState = onLoan; } } // borrow

Generating Code
public void returns(Member m) { if (currentState == onLoan) { [Link](this); [Link](this); currentState = onShelf; } } // returns } // Copy

21

22

Generating Code
We will know about the required parameters in the constructor from the sequence diagram in which a Copy object was created. Note that the information in the generated code comes from several different diagrams. A drawback of the code is that it is not really very readable by humans. However, we can regard the UML diagrams as our source program and the generated Java or C++ as machine code.
23

Generating Code
Idea is that the UML is at a higher more abstract level and so we are better able to reason about its effect. It should therefore be easier to prove that the code satisfies the requirements.

24

State v Sequence Diagrams

It should be emphasised that a state diagram defines the different states that an object can go through when it is being executed. It does show the possible method calls that are made to carry out its actions. However, we are concerned with the behaviour of one typical object of a class. Sequence diagrams, on the other hand, are concerned with the interaction between objects and how they collaborate with one another.
25

State diagrams
So far, in our state diagrams, transitions have been caused by a method of the object being called. The object can then, as an action, call the methods of other objects. Calling a method may result in information being returned that will be used to change the values of attributes. Some changes of attribute values will cause a new state to be entered. This is modelled by a transition labelled with an event of the form: when(x == 10) 26

Time
State diagrams can also include time events. Suppose that our Copy object became overdue after two weeks and so moved into the overdue state. Our diagram could become:

State diagrams
State diagrams can become very large (with lots of states) and hence difficult to read. This is especially true when we include error handling. There is also the case where the same transition can occur from many different states. That can cause a large number of arrows to be required.

27

28

ATM
Consider, for example, our ATM example.

ATM
The user may want to cancel a transaction at any time. This can be modelled by a having a cancel transition from the Validation, Selection and Processing states, i.e. an arrow from each of these states to the Idle state. In each case, we want the ejectCard action to be associated with the transition. That would greatly complicate the diagram.
29 30

Substates
The solution is to use substates.

Substates
The Working state has a series of substates. We enter Working through the insertCard transition. On entry to the Working state, the action readCard is executed. The initial substate is Validating. We move from one substate to another in the normal way and the finish transition will cause us to return to the Idle state. When that occurs, the action ejectCard is executed.
31 32

ATM
Showing a transition from the Working state, means that it can occur when we are in any of its substates. We therefore only have to show the cancel transition once. It causes the Working state to be left and we return to Idle. The exit action ejectCard action is executed when we leave Working. It does not matter what substate we are in or which transition caused us to leave.
33

Assignments
You are not asked for state diagrams in your first assignment, but will be in your group project. You should take a class with significant internal behaviour and show what causes it to move from one state to the next.

34

Use of state diagrams

As state diagrams are based on finite state automata, they are amenable to mathematical reasoning. It is therefore possible to prove that the object has certain properties. There is a specification language called SDL which is heavily dependent on state diagrams and has been traditionally used in the telecommunications industry to specify, design and implement systems. The latest versions of SDL are object-oriented.
35