1. Checking and validation Chapter 9

2. Checking and validation

3. All parts match and everything is included Validate that stakeholders are happy Where are the major risks? Quality product = meet the spec?

4. A good requirement Correct; reflects a need Complete; all necessary requirements included Unambiguous; all parties agree on meaning Consistent; all parts match (E/R and event list) Ranked for importance

5. A good requirement Modifiable; easy to change Verifiable; possible to see whether requirement is met Traceable; to goals/purposes, to design/code Understandable; by customer and developer

6. Checking the spec in isolation When a check reveals a problem; –Simple – fix it –Important info missing – more elicitation work required –Important info missing but not important – ignore or comment that intentionally left out –Two parts of the spec mismatch – look into simple mistake or more important

7. Contents check Introduction System goals Data requirements Functional requirements Handling of special cases Quality requirements Other deliverables Glossary

8. Contents check

9. Structure check ID for each requirement Verifiable requirements Purpose Examples of ways to meet requirement Explanation of diagrams Importance and stability Cross references Index Electronic version

10. Structure check

11. Consistency checks and CRUD CRUD; can each entity class in the data model be created and deleted by an event or function or user task? Can each field in the data model be Read and Updated by an event or function or user task? Event check; are all events handled by a function or user task?

12. Consistency checks and CRUD Information needs; are the necessary data for each task or message flow available in the data model? Virtual windows checks; –are all data in the virtual windows available in the data model an vice versa? –Are all tasks conveniently supported through a few virtual windows?

13. Consistency checks

14. CRUD matrix

15. Checks against surroundings Review of the specification –Many issues are usually found –Not all lead to problems in development –Difficult to know which ones cause problems –Resolving earlier saves a lot of time later on

16. Checks against surroundings Goal-requirements tracing –Are all goals and critical issues covered by requirements? –Are all requirements justified by meaningful purposes?

17. Checks against surroundings

18. Risk assessment A requirement that is risky to the customer is often low risk for the developer and vice versa Customer risk; doesn’t get what is needed even if this is what is specified Developer risk; cannot fulfill requirement within reasonable cost

19. Unacceptable risk Choose another requirement style with lower risk Elicit more precise requirements Isolate the risk Keep the risk under observation

20. Validation via testing Tests Simulation/walkthrough Prototype test Pilot test

21. Checklist forms Convenient to plan and record the checks by means of a form

22. Checklists at work

27. Z(ed)

28. Zed Based on set theory, functions and discrete mathematics Standard symbols Special symbols Four sections –Given sets, data types, and constants –State definition –Initial state –Operations

29. Zed Set theory provides foundation to construct an abstract structure of software product First-order predicate logic used to express behavior of the product Strongly typed; every object must be associated with a unique type –easier to develop tools to type check –interpreted as maximal sets (subset relations)

30. Schema Encapsulated structure Associated with some properties Can specify parts of a system separately and compose larger systems –types –state spaces –operations

31. Abstraction Representational abstraction –type definitions –global constants –state space declaration Operational abstraction –operation definitions –function definitions

32. Representational Abstraction Schema –unique name –structure described by a set of declarations –property described by a set of predicates express invariant relationships among the structure components Allows specification to be split into manageable pieces for modular specifications

33. Types Interpreted as sets Carrier set; set of values associated with a type –describes the collection of values an object of that type can assume Every variable, constant, and expression must be associated with a type –easier to spot errors in the spec –enforces discipline in writing good specs

34. Simple types Primitive types; already defined in Z –integer type is only primitive type in Z Basic types; user defined –used in current spec and not further elaborated –users of an automated teller machine can be modeled as a basic type [USERS] [USERS, STAFF, CLIENTS]

35. Set operators in Z

36. Abbreviation New names can be used for complex expressions Title X Author X CallNumber X Year Book == Title X Author X CallNumber X Year Room numbers between 100 and 199 r: RoomNumber 100 <= r <= 199 

37. Operators on Sequences

38. Examples of sequences

39. Format of Z schema (constraints)

40. Elevator Problem Given sets –do not need to be defined in detail –[Button] ; the set of all buttons floor buttons elevator buttons buttons (set of all buttons in the elevator problem) pushed (all buttons that have been pushed) –P –P; power set (set of all subsets of a given set)

41. Z schema Button_State

42. Initial State Abstract initial state; state when the system is first tuned on Vertical schema vs horizontal schema When elevator is first turned on the set pushed is initially empty (all buttons off)  Button_Init = [Button_State’ | pushed’ = ] ^

43. Operations  operation changes the state of a variable input variable output variable ` new value of a variable / set difference such that

44. Z specification of operation Push_Button

45. Z specification of operation Floor_Arrival

46. Users of a computer system Simple schema - no additional constraints Schema with constraints

47. Users of a computer system Schema represented in horizontal style

48. Analysis of Z Z successfully applied on many projects –easy to find faults in the specification –specifier must be very precise which leads to less ambiguity –developers can prove specification correct –requires no formal mathematical background –decreases the cost of software development –can be rewritten in natural language

49. Summary of Specification Methods

50. Summary Summarize your present understanding of the problem and all your findings in a concise, complete, well-organized and polished statement (processing narrative ) Important that this step is well done, since this first informal document will serve as anchor for your further work

51. Petri Nets

52. Concurrent Systems FSM not good at coping with timing –synchronization problems –race conditions –deadlock Poor specifications can cause timing related problems Petri Nets good at specifying systems with potential timing problems

53. Petri Nets Carl Adam Petri (automata theory) Now used in other areas –performance evaluation –operating systems –software engineering Use to specify concurrent interrelated activities

54. Components of a Petri Net Four parts –set of places, P –set of transitions, T –input function, I –output function, O Formally; C = (P, T, I, O) –P = {p1,p2,…,pn}, n >= 0 –T = {t1,t2,…,tm}, m >= 0 (P and T disjoint) –I: T --> P is the input function –O: T --> P is the output function

55. Petri net example Petri net on next page –P = {p1, p2, p3, p4} –T = {t1, t2} –I(t1) = {p2, p4} –I(t2) = {p2} –O(t1) = {p1} –O(t2) = {p3, p3}

56. Petri Nets p1 p3 p4 p2 t1 t2

57. Marking Marking is an assignment of tokens to the Petri net Represented by a vector (1,2,0,1) Transition is ready to fire (enabled) if each of its input places has as many tokens in it as there are arcs from the place to that transition –number of tokens not conserved –marking before t1 fires is (1,2,0,1) –marking after t1 fires is (2,1,0,0) –marking after t2 fires is (2,0,2,0)

58. Marked Petri Net p1 p3 p4 p2 t1 t2....

59. Petri Net after firing transition 1 p1 p3 p4 p2 t1 t2...

60. Petri Net after firing transition 2 p1 p3 p4 p2 t1 t2....

61. More on Marking Petri nets are nondeterministic –if more than one transition is ready to fire, any one of them may be fired Formally; C = (P,T,I,O) is a function from the set of places P to the set of nonnegative integers M: P --> {0,1,2,…} A marked Petri net is a 5 tuple (P,T,I,O,M)

62. Inhibitor Arc Small circle instead of an arrow head A transition is enabled if there is at least one token on each of its normal input arcs and no tokens on any of its inhibitor input arcs –Transition t1 is enabled because there is a token in p3 but no token in p2

63. Petri Net with Inhibitor Arc p1 p3 p2 t1.

64. Petri Net Summary Abstract virtual machine (like FSM) Very well defined behavior Circles are “places” Lines are “transitions” Arrows (directed arcs) interconnect places and transitions

65. Petri Net Summary Transition is enabled when all transition arcs entering that transition emanate from places containing tokens (dots within places) “Enabled” is when the external stimulus associated with that transition occurs –tokens that enabled the transition are consumed –new tokens created at the ends of the arcs exiting from the transition node

66. Token merging in Petri Nets - Before and After

67. Fan-out in Petri Nets; Before, After T2, after T3

68. Petri Net example Starting configuration Only one transition is enabled (T1) If stimulus T1 occurs –token at P2 moves to P1 –only one transition enabled (T4) If stimulus T4 occurs –tokens at P1 and P5 are consumed –two tokens created at the ends of the arcs exiting T4

69. Petri Net Example - Initial configuration

70. Petri Net Example - After first firing

71. Petri Net Example - After second firing

72. Petri Net Example - After T2 occurs

74. Petri Net Example (e) is identical to (a) Petri Net with a cycle of length 4 So how does this help us write a SRS? –assume that T1 - T4 are all associated with the same 1 second clock –P2 and P3 are lights –Petri Net could be used to unambiguously define the requirements for this 2 light system

75. Petri Net for a 2 light system 1. There are two light bulbs 2. Every other second, there shall be no lights on 3. Every other second, there shall be exactly one light on 4. Each time a light comes on, the lights alternate

76. Petri Net for a 2 light system Places P2 and P3 in the preceding Petri Net do just that Petri Net contains no ambiguity The English sentences may be misunderstood Same behavior shown on next page - but its simpler!

77. Another Petri Net to do the same thing

78. Another set of specifications 1. There are two light bulbs 2. For the first two seconds one light is on 3. For the next two seconds, that light goes off and the other light goes on 4. From then on every 2 seconds the lights alternate

79. Use the same Petri Net! Associate the two light bulbs with places P4 and P5

80. Or use a simpler one! Use a two second clock pulse...

81. Petri Nets Response-stimulus timing constraints can also be stated in Petri Nets

82. Response-stimulus timing constraint in equivalent Petri Net

83. How to analyze this Petri Net Initially a token at P0 User is asked to do x Once the user arrives a timer token proceeds to P1 and arrives at P2 in exactly 15 seconds A token also sits at P3 waiting for either the 15 seconds to elapse (P3 token consumed by firing transition T1) or for the user to complete x (P3 token consumed by firing transition T2)

84. How to analyze this Petri Net If 15 seconds elapses P4 is fired activating the alternative system response (warning message perhaps) If the user completes x before 15 seconds, P5 is fired for the normal system response If the user completes x in precisely15 seconds the normal system response happens (benefit of the doubt)

85. How to analyze this Petri Net lo and hi priorities places on arcs from P3 to remove any doubt associated with nondeterminism Normal response spawns a timer token at P2 –may force an alternative system response to the next user that comes along –Place P6 added to remove these –Mission at T3 is to remove all “renegade” timer tokens that reach P2

86. How to analyze this Petri Net –arc connecting P2 and T3 is higher priority than arc connecting P2 and T1 ensures that the timer token is removed if there is a token at P6 and never has a chance to give a subsequent user at P3 an alternative system response through T1 accidentally

87. Petri Net Extension Stimulus-response and response- response constraints required a Petri Net extension –required execution time recorded above each Place –specified the maximum allowable time for the system to perform the operations

88. A Petri Net showing execution times