States, Events, & Observations

1. States, Events, & Observations • Z specifications describe a system with logic and sets through 3 “notions”: • Event : an occurrence (e.g. some operation) of interest to the modeling of a system • Observation: an examination of the values of some variable that depicts an event (e.g. the value of a variable before and after the occurrence of the event). • State : a value associated with a mathematical structure ( e.g. sets, relation, or function) that models a system • Note that since state models a system status and a system status is represented by the values of the variables of a system, states may be considered as a set of observations. • Z specifications also utilize all the set, relation, function, and logic notations and concepts introduced earlier from propositional and predicate calculus.

2. Identifiers with special symbols • The special symbols, ?, ! and ‘ placed at the end of an identifier (e.g. variable name) carries special meanings: • ? indicates input • s? : Students (means s is an input variable of the type Students.) • ! indicates output • number_in_class ! : N (means number_in_class is an output variable of the type Natural numbers.) • number_in_type ! = # (enrolled) (means out put or print-out the variable number_in_type which is set to the cardinality or number of enrolled students) • ' indicates a postcondition • # (enrolled’) < class_limit(if enrolled is a variable representing the state of class enrollment process, then enrolled’ says that the class-limit is still preserved after enrolling students.)

3. Invariant Properties • In describing the properties (predicates) of a system, we often find that there are some predicates that will stay the same no matter what event occurs. These are called invariant. • From previous example of books in the library, we have: books = in_libUchecked_out. • This condition or predicate holds no matter how many books are checked out or placed on the shelf (assuming we don’t have any other book properties) • From the same example, we also have another invariant predicate: in_libchecked_out = Ø • This predicate is also true no matter how many book is checked out or placed on shelf.

4. Dynamic Properties • A system must contain some non-invariant properties or it is not very interesting. The properties that change are dynamic properties. These are observed through some variable(s) associated with an event. • Prior to the occurrence of the event, • After the occurrence of the event and • Predicate(s) which relates them • Again, using the example of library books • Let new_out represent newly checked out books. (So they come from the in_lib set.) • new_out, in_lib: IP Books (in the signature part of the schema) • new_outin_lib(in the predicate part of schema) • should the above line be new_outin_lib ? (what do you think?) • in_lib’ = in-lib \ {new_out} (in the predicate part of schema) • checked_out’ = checkedout U {new_out} ( in the predicate of schema) - new_out is newly checked out book, and in_lib are books still in the library - new_out also comes out of the books in the library; so it is from in_lib. - post condition of checked_out, checked_out’, is that it increases by new-out.

5. A somewhat detailed Example of Class_Enrollment • Let’s consider the following for Z-schema specifications: • A model of a system that keeps track of students enrolled ina class(state) • Class has a maximum enrollment (state) • Students can enroll if the class is not full (event/function) • Students can also drop from a class. (event/function) • Let’s call the initial Z-schema , Class_Enrollment. Class_Enrollment Signature part Predicate part

6. A detailed Example of Class_Enrollment (cont.) • Let’s consider the specifications that will be placed in the signature partand in the predicate partof the Class_Enrollment Z-schema • Signature Part : • declare a basic data type variable called Student: • [ Student ] • declare a built in data type variable called class_limit: • class-limit : N • declare a variable, enrolled, of type of power set of student to represent the state of the Class_Enrollment system: • enrolled : IP Student

7. A detailed Example of Class_Enrollment (cont.) • Predicate Part : • class has an invariant maximum enrollment condition • # (enrolled) =< class_limit • So far, we have the following Class_Enrollment schema : Class_Enrollment [ Student ] class_limit : N enrolled : IP Student #(enrolled) ≤ class_limit So far, we have portrayed only the “static” part of the system

8. A detailed Example of Class_Enrollment (cont.) • Class_Enrollment schema is not enough by itself until we add two more schemas to model the enroll and drop activities. • Let’s consider modeling the “enrolling” activity. Enrolling • Note that” • - Class_Enrollment is “included” • we are using the ? suffix to mean • input. • - #(enrolled) “less than” class_limit • We do not say “how” enrolling is • done except that s? becomes part of • the enrolled set. Class_Enrollment s? : Student s? enrolled # (enrolled) < class_limit enrolled’ = enrolled U { s?} This is one of the “dynamic” parts of the system

9. A detailed Example of Class_Enrollment (cont.) • Let’s now add to this model the “drop” activity schema Drop Class_Enrollment s? : Student s? enrolled enrolled’ = enrolled \ {s?}

10. Z-Schemas modeling class enrollment • With the 3 Z schemas, a) Class_Enrollment, b) Enrolling, and c) Drop, we have modeled a system that: • Keeps track of the class enrollment state with a maximum of class_limit • Add a previously non-enrolled student into a class if the limit is not already reached. • Drop a previously enrolled student from a class

11. Add one more to the model • To this previous model, we can add one more schema to model an inquiry. Class_Size_Query Note that we are using the ! suffix and declaring number_in_class! as an output variable. Also, note that inquiry keeps the enrollment unchanged Class_Enrollment number_in_class ! : N number_in_class ! = # (enrolled) enrolled’ = enrolled