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. 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 23 – Verification and Validation COMP201 - Software Engineering

27. Verification and Validation Ensuring that a software system meets a user's needs COMP201 - Software Engineering

28. Objectives • To introduce software verification and validation and to discuss the distinction between them • To describe the program inspection process and its role in V & V • To explain static analysis as a verification technique • To describe the Cleanroom software development process COMP201 - Software Engineering

29. Verification vsValidation • Verification: "Are we building the product right" • The software should conform to its specification • Validation:"Are we building the right product" • The software should do what the user really requires COMP201 - Software Engineering

30. Verification vsValidation • Verification should check the program meets its specification as written in the requirements document for example. • This may involve checking that it meets it functional and non-functional requirements • Validation ensures that the product meets the customers expectations • This goes beyond checking it meets its specification; as we have seen, system specifications don’t always accurately reflect the real needs of users COMP201 - Software Engineering

31. Static and Dynamic Verification • Software inspections Concerned with analysis of the static system representation to discover problems(static verification) • May be supplement by tool-based document and code analysis • Software testing Concerned with exercising and observing product behaviour (dynamic verification) • The system is executed with test data and its operational behaviour is observed COMP201 - Software Engineering

32. An Example of Bad Code public class Temperature { // constructor public Temperature(double initTemp) { x = initTemp; } // calcTGrd function to calc. the value of a T gradiant public double calcTGrd(float ZVAL) { float a = x * x; a = a * ZVAL * 3.8883; return a; } public double x; } COMP201 - Software Engineering

33. Static and Dynamic Verification • System testing is only possible when an executable version of the program is available • This is therefore an advantage of incremental development since a testable version of the system is available at a fairly early stage • New functionality can be checked as it is added to the system and we can perform regression testing (we will talk about this in a few slides time) • Real data can be used as input to the system and we try to observe any anomalies in the output COMP201 - Software Engineering

34. Program Testing • Can reveal the presence of errors NOT their absence !!! • A successful test is a test which discovers one or more errors • Program testing is the only validation technique for non-functional requirements • Should be used in conjunction with static verification to provide full V&V coverage COMP201 - Software Engineering

35. Types of Testing • Defect testing • Tests designed to discover system defects. • A successful defect test is one which reveals the presence of defects in a system. • Statistical testing • Tests designed to reflect the frequency of user inputs. Used for reliability estimation. COMP201 - Software Engineering

36. Verification & Validation Goals Verification and validation should establish a degree of confidence that the software is fit for purpose • This does NOT mean completely free of defects • The degree of confidence required depends upon several different factors as we see on the next slide COMP201 - Software Engineering

37. Verification & Validation Goals • Software function – A much higher level of confidence that the system is fit for purpose is required for safety critical systems that for prototype systems for example • User expectations – Users sometimes have a low expectation of software and are willing to tolerate some system failures (although this is decreasing) • Marketing environment – Competing programs must be taken into account and the required schedule for introducing the product to market. Cheaper products may be expected to have more faults. COMP201 - Software Engineering

38. Testing and Debugging Defect testing and debugging are distinct processes • (!) Verification and validation is concerned with establishing the existence of defects in a program Debugging is concerned with - locating and - repairing these errors • (!!) Debugging involves • formulating a hypothesis about program behaviour • then testing these hypotheses to find the system error COMP201 - Software Engineering

39. Testing and Debugging • There is no simple process for debugging and it often involves looking for patterns in test outputs with defects and using a programmers skill to locate the error • Question: Recall the programs you have written in Java for example so far. Were there errors in early versions? How did you discover them and fix them? Were they syntactic or semantic errors? • Interactive debuggers provide a special run-time environment with access to the symbol table and program variables to aid error location. You can also “step-through” the program line by line COMP201 - Software Engineering

40. More Incorrect Code! public class Temperature { // calcTGrd function to calc. the value of a T gradient public double calcTGrd(float ZVAL) { int a = (int) x * x if(a = 1) x = ZVAL * 3.8883; return a; } public double x; } Syntax error (missing semicolon) Semantic error (should use double equals) COMP201 - Software Engineering

41. Syntax and Semantic Errors • A syntax error should be caught by the compiler which will (usually) indicate the location the error occurred in and the type of error. • A semantic error (also called a logical error) can occur in a program which compiles and runs, but produces incorrect output on some (or all) input (e.g. An incorrect algorithm or mistake in a formulae etc.) • Semantic errors are often harder to detect since the compiler may not be able to indicate where/what the problem is. COMP201 - Software Engineering

42. Testing and Debugging • Once errors are located, it is necessary to correct the program code and re-test the program • Regression testing – after fixing a defect, it is advisable to retest the program with all previous test data to make sure the “fix” has not introduced new problems • This is not always feasible due to costs • Experience has shown that a large proportion of fault repairs introduce new errors or are incomplete COMP201 - Software Engineering

43. The Debugging Process COMP201 - Software Engineering

44. The V-model of Development This diagram shows how test plans should be derived from the system specification and design. COMP201 - Software Engineering

45. Software Inspections • Involve peopleexamining the source representation with the aim of discovering anomalies and defects • Does not require executionof a system so it may be used before the implementation phase • May be applied to any representationof the system (requirements, design, test data, etc.) • Very effective technique for discovering errors COMP201 - Software Engineering

46. Software Inspections • Incomplete versions of the system can be inspected without additional costs – specialised test harnesses that work on only a part of the program are not required • As well as program defects, inspections can consider broader quality attributes such as compliance with standards, portability and maintainability • Poor programming style and inefficiencies can be found which could make the system difficult to maintain and update COMP201 - Software Engineering

47. Inspection Success • Many different defects may be discovered in a single inspection, there is no “interaction” between errors to be concerned with. In testing, one defect, may mask another, so several executions are required • They reuse domain and programming knowledge so reviewers are likely to have seen the types of error that commonly arise COMP201 - Software Engineering

48. Inspections and Testing • Inspections and testingare complementary and not opposing verification techniques • Both should be used during the V & V process • Inspections can check conformance with a specification but not conformance with the customer’s real requirements • Also inspections cannot check non-functional characteristics such as performance, usability, etc. (Emergent properties). COMP201 - Software Engineering

49. Lecture Key Points • Verification and validation are not the same thing. • Verification shows conformance with specification; • Validation shows that the program meets the customer’s needs • Test plans should be drawn up to guide the testing process. • Program inspections are very effective in discovering errors • Different types of systems and software development processes require different levels of verification and validation COMP201 - Software Engineering