State Diagrams and Activity Diagrams-Development and Software Engineering-Lecture Slides, Slides of Software Engineering

Download State Diagrams and Activity Diagrams-Development and Software Engineering-Lecture Slides and more Slides Software Engineering in PDF only on Docsity! 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 1 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 docsity.com Lecture Outline  State Diagrams  Designing classes with state diagrams  Activity diagrams 2 COMP201 - Software Engineering docsity.com 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. 5 COMP201 - Software Engineering docsity.com 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.). 6 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 docsity.com 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. 7 COMP201 - Software Engineering docsity.com  We can show our intention directly, by writing the action inside the state, as a reaction to the special event (e.g entry 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.. 10 COMP201 - Software Engineering State Diagram of Class Copy with Action docsity.com 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: bool lastCopy; // Attribute }; COMP201 - Software Engineering 11 docsity.com 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 int numCopies; // Attribute } COMP201 - Software Engineering 12 docsity.com 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. 15 COMP201 - Software Engineering docsity.com 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 16 docsity.com 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 17 docsity.com 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 20 docsity.com 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 21 docsity.com 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 22 docsity.com