1. Slide 1 Introduction to the Z Formal Specifications Language

2. Slide 2 Z as a specification language u A formal specification notation based on set theory u Has been developed at the Programming Research Group at the Oxford University Computing Laboratory since the late 1970s. u Probably now the most widely-used specification language u An international standard for the Z notation is being developed under the guidance of ISO.

3. Slide 3 Z as a specification language u Specification are built from components called schemas. u Schemas are specification building blocks u Graphical presentation of schemas make Z specifications easier to understand u Mathematical notation of schemas allows the building of formal completeness and consistency proofs to validate the specifications

4. Slide 4 Z schemas u Introduce specification entities and defines invariant predicates over these entities u A predicate is a Boolean expression u Some predicates can have side-effects that change the state of the entities involved u Schemas can be included in other schemas and may act as type definitions u Names are local to schemas u In many respects, Z schemas are akin to objects.

5. Slide 5 Problem: storage tank monitoring u A storage tank is monitored by a control system. u The system consists of a container which holds something and a indicator panel which shows the current fill level and the danger level. u If the storage tank goes over the danger level, a warning light must be lighted on the indicator panel. u Fill operations must be specified as to ensure the tank to be refilled but never overfilled.

6. Slide 6 A container specification contents <= capacity Container contents: N capacity: N Schema variable declarations Schema predicates Schema name Container  [contents: N; capacity: N | contents <= capacity] 

7. Slide 7 The Z Notation u A schema includes u A name identifying the schema u A signature introducing entities and their types u A predicate part defining relationships between the entities in the signature by stating a logical expression which must always be true (an invariant).

8. Slide 8 An indicator specification light = on  reading >= dangerLevel Indicator light: {off, on} reading: N dangerLevel: N u If the storage tank goes over the danger level, a warning light must be lighted on the indicator panel.

9. Slide 9 Specification of a storage tank reading = contents capacity = 250000 danger_level = 245000 StorageTank Container Indicator

10. Slide 10 Specification of a storage tank contents <= capacity light = on  reading >= dangerLevel reading = contents capacity = 250000 danger_level = 245000 StorageTank contents: N capacity: N reading: N dangerLevel: N light: {off, on}

11. Slide 11 A partial spec. of a fill operation contents + amount? <= capacity contents’ = contents + amount? FillOK  StorageTank amount?: N

12. Slide 12 Z conventions  A schema name prefixed by the Greek letter Delta (  ) means that the operation changes some or all of the state variables introduced in that schema u A variable name decorated with a ? represents an input u A variable name decorated with a quote mark (N’) represents the value of the state variable N after an operation

13. Slide 13 Z conventions  A schema name prefixed by the Greek letter Xi (  ) means that the defined operation does not change the values of state variables u A variable name decorated with a ! represents an output

14. Slide 14 A partial spec. of a fill operation contents + amount? <= capacity contents’ = contents + amount? FillOK  StorageTank amount?: N

15. Slide 15 Storage tank fill operation capacity < contents + amount? r! =“Insufficient tank capacity – Fill cancelled” OverFill  S torageTank amount?: N r!:seq CHAR Fill FillOK  OverFill

16. Slide 16 Full problem specification Container  [content: N; capacity: N | content <= capacity]  Indicator  [light:{off,on};reading: N; dangerLevel: N | light = on  reading >= dangerLevel] StorageTank  [  Container;  Indicator | reading=content; capacity=250000; dangerLevel = 245000] FillOK  [  StorageTank; amount?: N | contents + amount? <= capacity; content’ = content + amount? OverFill  [  StorageTank; amount?: N; r!: seq CHAR | capacity < contents + amount?; r! =“Insufficient tank capacity – Fill cancelled” Fill  [FillOK  OverFill]     

17. Slide 17 Operation specification u Define the “normal” operation as a schema u Define schemas for exceptional situations u Operations may be specified incrementally as separate schema then the schema combined to produce the complete specification u Combine all schemas using the disjunction (or) operator (written  )

18. Slide 18 Z Notations u A schema includes u A name identifying the schema u A signature introducing entities and their types u A predicate part defining invariants over these entities u Conventions u Marks before a schema,  Delta (  means changes  Xi  means no changes u Marks after a state variable, u ? means input u ! means output u ‘ represents the value of the variable after an operation

19. Slide 19 Z symbols Sets: S : P XS is a set of Xs S : F XS is a finite set of Xs x  Sx is a member of S x  Sx is not a member of S S  TS is a subset of T S  Tunion of S and T S  Tintersection of S and T S \ Tdifference of S and T  empty set N set of natural numbers : {0,1,2, …} Z set of integer numbers : {...-2,-1,0,1,2, …} max(S)maximum value of the (non-empty) set S min(S)minimum value of the (non-empty) set S #Scardinality of S

20. Slide 20 Z symbols Functions: f : X Yf is a partial function from X to Y f : X  Yf is a total function from X to Y dom fdomain of f ran frange of f f : {x 1 y 1, x 2 y 2 }extensional function definition f  {x 1 y 1 }extensional addition of mappings Logic:  Pnegation P  Qconjunction P  Qdisjunction P  Qequivalence P  Qimplication   

21. Slide 21 Key points u Z specifications are made up of a mathematical model of the system state and a definition of operations on that state u A Z specification is presented as a number of schemas u Schemas may be combined to make new schemas u Operations are specified by defining their effect on the system state. u Operations may be specified incrementally. Different schemas can be combined to complete the specification. u The notation used is very cryptic, though great effort is made toward understandability.

22. Slide 22 Z Specification Examples

23. Slide 23 Example 1 Specifications for a Data Dictionary

24. Slide 24 Data dictionary specification u A data dictionary is used as an example. This is part of a CASE system and is used to keep track of system names u Data dictionary structure u Item name u Description u Type. Assume in these examples that the allowed types are those used in semantic data models u Creation date u Operations for lookup, addition, replacing, and deletion of entries are to be formally specified. u An operation for extracting and sorting all entity, relation or attribute entries has to be specified.

25. Slide 25 Given sets u Z does not require everything to be defined at specification time u Some entities may be ‘given’ and defined later u The first stage in the specification process is to introduce these given sets u [NAME, DATE] u We don’t care about these representations at this stage

26. Slide 26 Type definitions u There are a number of built-in types (such as INTEGER) in Z u Other types may be defined by enumeration u SemModelTypes = { relation, entity, attribute } u Schemas may also be used for type definition. The predicates serve as constraints on the type

27. Slide 27 Specification using functions u A function is a mapping from an input value to an output value  SmallSquare = {1  1, 2  4, 3  9, 4  16, 5  25, 6  36, 7  49} u The domain of a function is the set of inputs over which the function has a defined result u dom SmallSquare = {1, 2, 3, 4, 5, 6, 7 } u The range of a function is the set of results which the function can produce u rng SmallSquare = {1, 4, 9, 16, 25, 36, 49 }

28. Slide 28 Data dictionary modeling u A data dictionary may be thought of as a mapping from a name (the key) to a value (the description in the dictionary) u Operations are u Add. Makes a new entry in the dictionary or replaces an existing entry u Lookup. Given a name, returns the description. u Delete. Deletes an entry from the dictionary u Replace. Replaces the information associated with an entry u Extract. Extract and sort by name all entries having a specified type

29. Slide 29 Data dictionary entry #description <= 2000 DataDictionaryEntry entry: NAME desc: seq char type: Sem_model_types creationDate: DATE

30. Slide 30 Data dictionary as a function DataDictionary DataDictionaryEntry ddict: NAME {DataDictionaryEntry}  ddict’ = Ø InitDataDictionary  DataDictionary

31. Slide 31 Add operation name?  dom ddict ddict’ = ddict  {name?  entry?} AddSuccess  DataDictionary name?: NAME entry?: DataDictionaryEntry name?  dom ddict error! =“Name already in dictionary” AddFailure  DataDictionary name?: NAME error!: seq char

32. Slide 32 Lookup operation name?  dom ddict error! =“Name not in dictionary” LookupNotFound  DataDictionary name?: NAME error!: seq char name?  dom ddict entry! = ddict (name?) LookupFound  DataDictionar y name?: NAME entry!: DataDictionaryEntry

33. Slide 33 Function over-riding operator  The replacing entry function uses the function overriding operator (written  ). This adds a new entry or replaces and existing entry.  phone = { Ian  3390, Ray  3392, Steve  3427} u The domain of phone is {Ian, Ray, Steve} and the range is {3390, 3392, 3427}.  newphone = {Steve  3386, Ron  3427}  phone  newphone = { Ian  3390, Ray  3392, Steve  3386, Ron  3427}

34. Slide 34 Replace operation ddict’ = ddict  {name?  entry} Replace  DataDictionary name?: NAME entry?: DataDictionaryEntry

35. Slide 35 Deleting an entry u Uses the domain subtraction operator (written ) which, given a name, removes that name from the domain of the function  phone = { Ian  3390, Ray  3392, Steve  3427}  {Ian} phone  {Ray  3392, Steve  3427}

36. Slide 36 Delete entry name?  dom ddict ddict’ = {name?} ddict DeleteFound  DataDictionary name?: NAME name?  dom ddict error = “entity specified for deletion does not exist in the dictionary” DeleteNotFound  DataDictionary name?: NAME error!: seq char

37. Slide 37 Extracting entities of specific type 1  n : dom ddict  ddict(n).type = inType?  ddict(n)  return! Extract  DataDictionary inType? : SemModelTypes return!: seq {DataDictionaryEntry} 2  i : 1 <= i <= #return!  return!(i).type = inType? 4  i,j : i,j  return!  (i<j)  return!.name(i) < NAME return!.name(j) 3  i : 1 <= i <= #return!  return!(i)  rng ddict 1. For all entries in ddict whose type is inType, there is an entry in return. This does not ensure that all elements of return are elements of ddict, hence the necessity of the next two constraints. 2. The type of all members of return is inType. 3. All members of return are members of the range of ddict. 4. return is sorted by its name attribute

38. Slide 38 Add, Lookup and Delete Add AddSuccess  AddFailure Lookup LookupFound  LookupNotFound Delete DeleteFound  DeleteNotFound

39. Slide 39 Data dictionary specification TheDataDictionary DataDictionary InitDataDictionary Add Lookup Delete Replace Extract

40. Slide 40 Example 2 Modular Specifications for a Birthday Book

41. Slide 41 Birthday book specification u A system which records people’s birthdays u Operations include addition and query of birthdays u The system must be able to give a list of birthdays occuring on any given day

42. Slide 42 Z schemas u Z schemas represent both the static and dynamic aspects of a system u Static u the states it can occupy u the invariant relationships (constraints) that are maintained on the state as its values are changed u Dynamic u the operations that are possible on the system state u the relationships between operations inputs and outputs u the changes of states that happen during the application of operations

43. Slide 43 Data dictionary modeling u The database is modeled as a function mapping persons’ names to their birthday dates u Operations are u Add. Makes a new entry {name  birthday} in the birthday book u Find. Given a name, returns the birthday u Remind. Returns a list of the persons having their birthday on a given date

44. Slide 44 known = dom birthday BirthdayBook P known : P NAME birthday : NAME DATE  Birthday book u birthday: is a function which, when applied to a name, gives the birthday associated with it u known: the set of names with birthdays recorded u Derived component of the state. u Might not be part of the implementation. u Gives clarity to the specifications.

45. Slide 45 Birthday book u Only one constraint is implied: u As birthday is defined as a function, each person can only have one birthday u Does not make any unnecessary assumptions on implementation constraints u maximum number of records u definition of NAME and DATE u ordering of records

46. Slide 46 Intitial system state known =  InitBirthdayBook  BirthdayBook  known = dom(birthday), hence if known is empty, birthday is empty.

47. Slide 47 name?  known AddBirthday  Birthday Book name? : NAME date? : DATE birthday’ = birthday  {name? date?}  Add operation u The schema does not say what happens if the precondition is not met u Complete specifications should take into account all state cases that can arise u Will be settled later in a modular way

48. Slide 48 Add operation u How does this ensure that:  known ’ = known  {name?}  A proof of it can be derived using the system invariant properties and the inherent properties of dom  The possibility to build such proofs is a major advantage of formal specification techniques known’ = dom birthday’[spec of BirthdayBook] = dom(birthday  {name?  date?})[spec. of AddBirthday] = dom birthday  dom {name?  date?}[dom distributivity] = dom birthday  {name?}[dom definition] = known  {name?}[spec. of BirthdayBook]

49. Slide 49 name?  known date! = birthday(name?) FindBirthday  BirthdayBook name? : NAME date! : DATE Find operation  Including  BirthdayBook is equivalent to include predicates known ’ = known and birthday ’ = birthday u What happens if the name looked for is not in the database? Again, this schema does not provide a complete specification.

50. Slide 50 Remind operation cards! = {n : known | birthday(n) = today?} Remind  BirthdayBook today? : DATE P cards! : P NAME u Specifies a definition of the output of the operation with regard with the system state u Does not specify how the search is implemented u Exactly specifies the problem to be solved, while leaving maximal freedom to designers and programmers

51. Slide 51 Specification completeness u The specification does not take into account special state cases leading to errors u Adding a new record for someone already in the system u Trying to find a person unknown to the system u Implementing such incomplete specifications will probably lead to a broken system u Designers/programmers will have to invent their own solutions to the problem, which might not be agreed by the client u System might lose some data u System might behave correctly, but without giving warnings to the user on faulty inputs, or give meaningful messages on empty output

52. Slide 52 Specification completeness u Solution: u Develop new schemas to enable the covering of special cases in all operations u Combine these new schemas with the existing ones to form a robust version of the system specification u Advantages: u Provides an incremental and modular description of the specifications u Specifications are easier to understand

53. Slide 53 Specification completeness  Add an extra output result! of type REPORT to each operation on the system that returns:  ok if the operation is successful  alreadyKnown or notKnown appropriately if an error happens  The type REPORT is defined as a free definition  Three schemas are defined to provide a definition of the states applying to the output of the appropriate REPORT value REPORT = {ok,alreadyKnown,notKnown}

54. Slide 54 Specification completeness result! = ok Success result! : REPORT name?  known result! = alreadyKnown AlreadyKnown  BirthdayBook today? : DATE result! : REPORT name?  known result! = notKnown NotKnown  BirthdayBook today? : DATE result! : REPORT

55. Slide 55 Complete addition operation RAddBirthday  BirthdayBook name? : NAME date? : DATE name?  known  birthday’ = birthday  {name? date?}  result! : REPORT result! = ok  name?  known  birthday’ = birthday  result! = alreadyKnown RAddBirthday (AddBirthday  Success)  AlreadyKnown

56. Slide 56 Complete find operation name?  known  date! = birthday(name?)  RFindBirthday  BirthdayBook name? : NAME date! : DATE result! : REPORT result! = ok  name?  known  birthday’ = birthday  result! = notKnown RFindBirthday (FindBirthday  Success)  NotKnown

57. Slide 57 Complete remind operation name?  known cards! = {n : known | birthday(n) = today?} RRemind  BirthdayBook today? : DATE P cards! : P NAME result! : REPORT result! = ok RRemind Remind  Success

58. Slide 58 Key Points u Z specifications provide a mathematical model of a system encompassing both static (state) and dynamic (operations) aspects u Specifications completeness is a key quality to achieve u Completeness can be achieved incrementally using modular schema composition u Incremental composition leads to more manageable and understandable specifications

59. Slide 59 Z specification examples (part II)

60. Slide 60 Example: DATE

61. Slide 61 Format of DATE u Date could have different formats: u November 7,2001 u 11/07/2001 u 7-11-2001 u … u Assume u using this format: dd mm yyyy, with which today is 7 11 2001 u do not care about zeroes

62. Slide 62 Initial suggestion DATE day: 1..31 month:1..12 year: 1900.. 9999 u Problems: invalid dates caused by u different days in different months u leap year u year overflow

63. Slide 63 Definition of leap_year leap_year: P ( N )  year:1990..9999  leap_year(year)  (year mod 4 = 0)  (year mod 100  0  year mod 400 = 0)

64. Slide 64 DATE day: 1..31 month:1..12 year: 1900.. 9999 month  {2,4,6,9,11}  month  {4,6,9,11}  day  30  month = 2   leap_year(year)  day  28  month = 2  leap_year(year)  day  29

65. Slide 65 Example: Radiation Safety interlock system

66. Slide 66 An Interlock System u A safety interlock system is designed to prevent people from being exposed to radiation. u An interlock system: u Ensures that all appropriate radiation areas are clear of personnel prior to the use of radiation sources u Prevents people from entering areas where radiation levels exceed certain limits u Ensures that anyone entering an area where there is significant radiation is exposed to a minimal dose of radiation. u Necessary to control access not only to the directly radiated areas, but also to adjoining areas due to leakage.

67. Slide 67 Radiation Safety Interlock System u Building a hypothetical system u Be able to determine whether rooms are clear of personnel before activating the radiation source u Prevent activation if they are not clear of personnel u Assume there is some way of determining when people enter or leave a room, such as using “magnetic badges”.

68. Slide 68 Plan of building 3 1 2 RS

69. Slide 69 Radiation Safety Interlock System u The radiation source goes through four phases: u Switched off: u RS is switched off u People are allowed to access any room u Powered up: u RS is powered up u Room 1 contains no people. and the door must be locked u Discharged u A beam is discharged into room 2 u Rooms 1 and 2 must contain no people u Door to room 2 locked u Full activated u Rooms 1 and 2 and the adjoining room 3 must contain no people.

70. Slide 70 Types definition u status of the radiation source u STATUS ::= SwitchOff | PowerUp | Discharge |Activated u status of the doors u DOORS ::= Open | Locked u number of rooms num_of_rooms: N 1 num_of_rooms = 3 1. Declared external to any schema 2. Global to any part of the specification declared after it 3. N 1 : positive natural number ( >0 )

71. Slide 71 The state of the system State num_in_room: seq 1 N doors: seq 1 DOORS status_of_system: STATUS #num_in_room = num_of_rooms #doors = num_of_rooms 1. num_in_room: the number of people in each room 2. doors: the number of doors associated with each room, either they are all open, or they are all locked. 3. seq 1: non-empty sequence

72. Slide 72 Initial State Init State ran num_in_room = {0} ran doors = {Open} status_of_system = SwitchOff u Initial state u All the rooms are empty u RS is switched off u All doors are open

73. Slide 73 Enter a room Enter_room  State N room_no?: N doors(room_no?) = Open num_in_room = num_in_room  {room_no?  num_in_room(room_no?) + 1} doors = doors status_of_system = status_of_system u If a person enters a room, the number of people in that room is incremented. u A person can only enter a room if the relevant doors are open. u The status of radiation source and doors are unaffected.

74. Slide 74 Leave a room Leave_room  State N room_no?: N num_in_room = num_in_room  {room_no?  num_in_room(room_no?) - 1} doors = doors status_of_system = status_of_system u If a person leaves a room, the number of people in that room is decremented.

75. Slide 75 Operation of Changing the status Phase 1  State status_of_system = SwitchOff  num_in_room(1) = 0 doors = doors  { 1  Locked} status_of_system = PowerUp u Phase 1: the RS goes from “switched off” to “powered up” u Room 1 must be clear of people u Its door is locked

76. Slide 76 Operation of Changing the status Phase 2  State status_of_system = PowerUp  num_in_room(2) = 0 doors = doors  { 2  Locked} status_of_system = Discharged u Phase2: the RS goes from “powered up” to “discharge” u Room 2 must be clear of personnel u The appropriate door(s) locked. What about room 1?

77. Slide 77 Operation of Changing the status Phase 3  State status_of_system = Discharged  num_in_room(3) = 0 doors = doors  { 3  Locked} status_of_system = Activated u Phase3: the RS goes from “discharge” to “full activated” u Room 3 must be clear of personnel u The appropriate door(s) locked.

78. Slide 78 Operation of Changing the status Deactive  State dom doors = dom doors  ran doors = {Open} status_of_system = SwitchOff u On switching off the system, we can make all rooms available.

79. Slide 79 Exceptions u What is the response of the system if we attempt to power up while someone is in room 1? u What happens if someone enters a room that is supposed to be locked? u …

80. Slide 80 Writing Specifications u Start from informal descriptions u Define the required types u Define the state variables u Define the relationships u Looking for verbs in the descriptions associated with the objects u If possible, build ER diagrams u Different levels of abstraction u Define the initial state u Identify the operations, define a reasonable system u Consider exception u Combine