Software Engineering COMP 201

1. Software EngineeringCOMP 201 Lecturer: Sebastian Coope Ashton Building, Room G.18 E-mail: coopes@liverpool.ac.uk COMP 201 web-page: http://www.csc.liv.ac.uk/~coopes/comp201 Lecture 22 – Essentials of State and Activity Diagrams COMP201 - Software Engineering

2. So far we have discussed: • How to describe the requirements of a system using use cases • How to model the static structure of a system using a class model • How to model the way objects interact to satisfy the requirements using interaction diagrams Today we shall look in more detail how to model an object’s “decision” about what to do when it receives a message in an object-oriented system. COMP201 - Software Engineering

3. Lecture Outline • State Diagrams • Designing classes with state diagrams • Activity diagrams COMP201 - Software Engineering

4. State Diagrams • Let us start with a very simple example in which an object receives a message and what it does depends on the values of its attributes and links. • In our library system, an object of classCopy may have a Boolean attributeonShelf • which is intended to record whether the object describes a copy of a book • which is currently in the library, • or one which is currently on loan. • The interface of a classCopy specifies that the object should be willing to accept the message borrow(). COMP201 - Software Engineering

5. State Diagram of Class Copy • The value of the attribute onShelfin Copy is important for understanding the behaviour of the object, • We can name two significantly different states of a Copy object • “on the shelf” and “on loan” • We can record the messages that cause it to move between the states as the events that cause transitions between states. COMP201 - Software Engineering

6. Unexpected Messages • In the previous figure, we have not shown arrows to represent • the receipt of message borrow() in state “on loan” or • the message return() in state “on shelf” • Under normal circumstances, such messages should not arrive: if they do it’s a bug. COMP201 - Software Engineering

7. Unexpected Messages • So the code of class Copy will have to do something if these “wrong” messages do arrive, this would be an architectural decision which should be made and documented once (such as throw an exception, write to an error log, etc.). In fact, our convention is a departure from UML, which specifies that an event, such as the arrival of message, that does not trigger a transition is simply ignored COMP201 - Software Engineering

8. States, Transitions and Events The most important elements of a state diagram, namely: • States • Shown as boxes with rounded corners • Transitions between states • Shown as arrows • Events that cause transitions between states • Shown by writing the message on the transition arrow • Start marker • Shown as a (filled) black circle with an (unlabeled) arrow into the initial state of the diagram • Stop marker • Shown by a (filled) black circle with a ring round it and denotes that the object has reached the end of its life. COMP201 - Software Engineering

9. Actions • State diagrams are useful for understanding how an object’s reaction to a message depends on its current state. • An object sending a message in response to being sent one itself is an example of an action being an object’s reaction to an event. • An event is something done to the object • such as it being sent a message • An action is something that the object does • such as it sending a message COMP201 - Software Engineering

10. State Diagram of Class Copy with Action • Analysing the notation: • The slash (/) shows that what follows is an action • book followed by a dot identifies the object to which a message is being sent (i.e. book is an attribute of class Copy to give an association between these two classes) • returned(self) is an example of a message including a parameter, where self is a reference to the same object COMP201 - Software Engineering

11. State Diagram of Class Copy with Action • We can show our intention directly, by writing the action inside the state, as a reaction to the special event (e.gentry or exit) • This can be useful for example if we can enter/exit a state from many others and always need to perform the same task when entering/exiting.. COMP201 - Software Engineering

12. A Possible Interface for Copy • We could have something similar to the following code for the class interface in C++: Class Copy { public: Copy(String copyName); // constructor void borrow(); // method void return(); // method private: boollastCopy; // Attribute }; COMP201 - Software Engineering

13. A Possible Interface for Copy • Or indeed in Java (as below). Note the use of a static variable: public class Copy { public Copy(String copyName); // constructor public void borrow(); // method public void return(); // method private static intnumCopies; // Attribute } COMP201 - Software Engineering

14. Entry, Exit and Transition Functions • We can also record entry, exit and transition functions all on the same diagram Several actions in one diagram. Question: In what order will the methods foo(), bar() and baz() be executed when moving from aState to anotherState? COMP201 - Software Engineering

15. Guards • Sometimes the occurrence of the same event in the same state may or may not cause a change of state, it depends upon the exact values of the object’s attributes • This means we cannot simply look at the system state to determine the next transition because the state may encompass several different possible states for a given level of abstraction • We can show this using the same conditional notation that is used in generic interaction diagrams and the idea of an action guard • These are also called preconditions. We can show any postconditionsafter the slash. COMP201 - Software Engineering

16. State Diagram for Class Book • The borrowed() message cause a state change out of state borrowable • only if this is the last copy on the shelf; • otherwise, the book object remains borrowable. COMP201 - Software Engineering

17. State Diagrams and Classes • The state diagram for a class should be as simple as possible for several reasons: • The code for a class with a complex state diagram is more difficult to code and understand, often containing many conditional statements (if-statements) • It may be harder to test the class since we need to ensure adequate testing from each of the possible states in the state diagram • It is harder for external code to use the class correctly if its behaviour heavily depends upon its current state; we may have to determine the state of the object first.. COMP201 - Software Engineering

18. State Diagrams and Classes • Given a complex state diagram, it can sometimes be an indication that we should split the class into several subclasses • Let us consider the case of a Copy object, should we identify two classes CopyOnShelf and CopyOnLoan? • For some complex classes, decomposing into smaller subclasses with a simpler state diagram would make sense but this is a design decision COMP201 - Software Engineering

19. Activity Diagrams • Activity diagrams describe how activities are coordinated. • For example, an activity diagram may be used (like an interaction diagram) to show how an operation could be implemented • An activity diagram is particularly useful • when you know that an operation has to achieve a number of different things, and • you want to model what the essential dependencies between them are, before you decide in what order to do them • Activity diagrams are much better at showing this clearly than interaction diagrams. COMP201 - Software Engineering

20. Activity Diagrams • We may identify different use-cases for example but some must be completed before others can begin. Recording the order in which we must complete these use-cases can be aided by using an activity diagram • Activity diagrams record the dependencies between activities, such as which things can happen in parallel and which must occur sequentially. COMP201 - Software Engineering

21. Activity Diagrams • At the UML semantics level, activity diagrams are state diagrams extended for convenience with some extra notation • Elements of activity diagrams • Activity • Transition • Synchronization bar • Decision diamond • Start and stop markers COMP201 - Software Engineering

22. Activity Diagrams • Activity – An activity is recorded like the notation for a state. However, we do not have transitions as a result of event, rather as the finishing of an activity. • Activity edge – an arrow to indicate where to move in the diagram after an activity finishes. These can be labelled with a guard condition. • Synchronisation bar – a thick horizontal bar describing the co-ordination of activities which must all be completed before the activity edges leading from the bar are fired. COMP201 - Software Engineering

23. Activity Diagrams • Decision Diamond– can be used to show decisions as an alternative to guards on separate states leaving the same activity. • Stop/Start markers – are used in the same way as in a state diagram (initial/final states). • Let’s see an example of an activity diagram for a library system (note that we partition the diagram to activities involving a library member and those also involving the librarian).. COMP201 - Software Engineering

24. Business Level Activity Diagram of a Library COMP201 - Software Engineering

25. Activity Diagrams and State Diagrams: • We can see several differences between activity diagrams and state diagrams: • Activity diagrams do not normally include events • Activity is intended to proceed, following the flow described by diagram, without getting stuck. Thus usually one of the guards of an edge leaving an activity should be satisfied • Concurrent activities can be modelled by using the synchronisation bar notation. COMP201 - Software Engineering

26. Lecture Key Points • During this lecture we have seen some more advanced state diagrams and their notation and uses • We also considered activity diagrams to model the flow of activities to perform a particular task. • This concludes our discussion of UML modeling but it is useful to try to develop models for your different scenarios using some of the diagrams we have discussed. • Next lectures: Verification, validation and software testing. COMP201 - Software Engineering