Schema and Schema Calculus

Schema and Schema Calculus • Schemas allowed us to: • Specify (Represent) the states of the system • Specify (Represent) the change of states of the system • Multiple simple schemas may be used to represent multiple simple components of a system. • How do we tie all these simple schemas together into a complex or more complete schema? • Manipulating Schemas : • Inclusion • Extension • Combining Schemas via: • Schema Calculus

Z-schemas as “Objects” • Similarity of schemas with: • Set specification • Predicate specification • Functional, lambda specification • Set Specification: • { p : Programs I p db_Programs } • DB_Access p : IP Programs p db_Programs In set form In schema form Programs & db_Programs needs to be defined somewhere

Predicate Specification • p: Programs MS(p) -> has_bug(p) Buggy_Programs p : IP Programs p MS(p) -> has_bug(p) Note that: MS & has_bug is not defined What do you think? Should we waive at hand at this

Lambda Specification • p : db_Programs I size(p) < 10 meg p Small_Program p : IP db_Programs size (p) < 10 meg - size is a fucntion? - Do we need to say that size = #(p_memory) ? - Need to define p_memory?

Manipulating Schema Objects • Previous Schema may be represented with brackets: • [DB_Access] , [Small_Program] • But, if we use braces {Small_Program}, then we mean the set representation of the schema called Small_Program • Schemas may be quantified : • [Small_Program] /\ has_bug (p) • This is similar to Ξp : db_programs (size(p) < 10 meg) Λhas_bug(p) (Small_Program from previous slide) • (there exists a program p such that size(p) <10 megand it has bugs)

Manipulating Schema Object (cont.) • Consider the following Schema: All_Programs user_p , sys_p : F Programs user_p∩sys_p = { } size(user_p) > 0 size(sys_p) > 0 • All_Programs # user_p • All_Programssys_p “F“ stands for finite subset Gives the number of user_p Will “project” all sys_p’s

Incorporating and Extending Schemas • We have discussed Schema Inclusion before (see note). A schema may be incorporated into another schema by including the former schema name into the signature component of the latter schema. • The result of the inclusion is to form a new schema whose signature is the union of the signatures of the 2 schemas. • The predicate of the new schema is the logical AND of the predicates of the 2 schemas. • Note that one needs to look out for duplicate namesto ensure that they are really the same data type, because duplicate names of the same data type are combined and reduced to one name. • Schema may also be primed, ‘. • Priming a Schema name would be equivalent to priming all the variable names in the signature and in the predicate of the schema is primed. • Thus it really represents the system state after some operation.

Delta Symbols • Delta Symbol, , used in front of the schema name represents both the before and after states (the states may change, but not the constraints). • Let Editor be a schema specifying an editor before the change of states, and Editor’ be the schema specifying the same editor after the changes of the state. • Then Editor may just be inclusion of Editor and Editor’: Editor Editor Editor lstring, rstring : TEXT Editor’ # (lstring Con rstring) < max Editor’ lstring’, rstring’ : TEXT # (lstring’ Con rstring’) < max where More meaningful if we do something with lstring and rstring ?

Xi Symbol • The Xi, , symbol represents that the schema operation will not change any of the variable (data) state. • Thus it is an invariant schema • e.g. Editor strLen ! : N Editor strLen ! = # (lstring) This schema specifies an Editor whose left and right strings do not change; it outputs the length of left string. The output operation leaves all the variables alone.

Adding to Schema • Adding to the signature of the schema is done with a semicolonsymbol • e.g. Adding a variable to All_Programs • More_P = [ All_Programs; new_p : F Programs ] • Adding to the predicate of the schema is done with I symbol • e.g. Adding a predicate to More_P of above • N_Programs = [ More_P I # new_p < # user_p ]

Schema Calculus (with logical operators) • Z schemas can be logically operated on: • logical conjunction, /\ : (like inclusion) • The signature parts are merged (with duplicates reduced to one ) • The predicates are joined logically with logical conjunction, /\ . • Logical disjunction, \/ : • The signature parts are merged (with duplicates reduced to one) • The predicates are joined logically with logical disjunction, \/ • Logical negation, ~ : • The signature part of the schema stays the same • The predicates are negated

Example of Conjunction • Consider a simple division example from ( the way of Z by Jacky) Quotient num, div, quo, rem : N Division = [Quotient] /\ [ Remainder] div = 0 num = (quo * div ) + rem OR Division num, div, quo, rem : N Remainder remember predicates are logically conjoined rem, div : N div = 0 num = (quo * div ) + rem rem < div rem < div Remainder schema is included to ensure that 12 = 0 * 5 + 12 doesn’t happen. That would trivialize the predicate in Quotient because we can always set quotient to be zero by setting num = rem

Example of Disjunction • Continue the example from ( the way of Z – Jacky) • Furthermore let’s include the situation when the divisor is zero DividebyZero Complete_Div = [Division] \/ [ DividebyZero ] div, quo, rem : N OR div = 0 /\ quo =0 /\ rem=0 Complete_Div num, div, quo, rem : N ( div = 0 /\ num = (quo * div ) + rem /\ rem < div ) \/ ( div=0 /\ quo=0 /\ rem =0)

Example of Negation • Negation of a schema is negating the predicates Division ~ [Division] will result in the following num, div, quo, rem : N Not_Division div = 0 num = (quo * div ) + rem rem < div num, div, quo, rem : N (div = 0) \/ (num = (quo * div ) + rem) \/ (rem >= div) Applying DeMorgan’s law

Schema and Schema Calculus