Two-Level Systems (Overview)

Part 5.Permission Rules for Two-Level SystemsControlling access (visibility or scope) of static references. Analogous to “private” in C/C++/Java.

Two-Level Systems (Overview) • Two levels (not counting root) • “Modules” contain resources • Leaves are “resources”, e.g., functions, variables • An example system • Some example permission rulesets system m n Modules: m, n Resources: x, y, z … z x y Modules could be files. Resources could be functions and variables.

system I m n U z x U y Example Two-Level System: Three Representations Top level: Modules (m, n) Bottom level: Resources (x, y, z) system c c I m n c c c U x y z U C = contain, U = use, I = import Think of U (use) as “call”, “access variable”, etc. Think of I (import) as permission to use. “Import” is sometimes called “Transport”

“Import” Ruleset (2-Levels) • x can use y if x and y are siblings, or if x’s parent imports y’s parent • x U y  (x S y or  m,n  x P m I n C y) • U  S  P o I o C, I S I m n U z x U y C = contain, P = parent, S = sibling, U = use, I = import Constraint: Modules import only modules and resources use only resources

“Export” Ruleset (2-Levels) • x can use y if x and y are siblings, or if x’s parent’s sibling exports y • x U y  x S y or  j,k  x P j S k E y • U  S  P o S o E, E C m n E U z x U y “Export” is much like “public” in Java/C++. Constraint: Resources use only resources

“Import-Export” Ruleset (2-Levels) • x can use y if x and y are siblings, or if x’s parent imports y’s parent, who exports y • x U y  x S y or  m,n  x P m I n E y • U  S  P o I o E , I S , E C I m n E U z x U y Constraint: Modules import only modules and resources use only resources

“Buy” Ruleset (2-Levels) • x can use y if x and y are siblings, or if x buys for its parent, whose sibling is y’s parent • x U y  x S y or  m,n  x B m S n C y • U  S B o S o C , B P m n B U z x U y Determines which resources can “buy” or “reach” outside their modules.

Variation of “Import” Ruleset (2-Levels) • x can use y if x and y are siblings, or if x imports y’s parent • w can import n if w and n are siblings, or if w’s parent imports n • U  S I o C, I S  P o I I m n I z x U U y Rules much like this are used in Euclid and Turing languages.

Using ID (Self-Loop) Relations • Predefine: Mod = id(setOfModules) • Constraint: Modules import only sibling modules • x I y  x Mod o S o Mod y • I  Mod o S o Mod Mod Mod I m n z x y Many other possible rules, e.g., “Import-Buy”

Various Two-Level Rulesets Constraints: Leaf2Leaf(U), Mod2Mod(I)

Part 5b.Permission Rules for Multi-Level SystemsTrees not necessarily balanced“Use” edges not necessarily from leaf to leaf

Example Ruleset: “Whole Import-Export” • A node may export its children. • A node may import its siblings. Also, it may import what its parents import. • A node may use its siblings and what they export recursively. Also, it may use what its parents import, as well as what they export recursively. Similar to permission rules used in Turing and Euclid languages

Whole Import-Export Ruleset I a c E b d I E x U y • Use U S o E*  P o I o E* • Import I S  P o I • Export E C Each permitting edge is a tube of the permitted edge

Selective Buy-Export Ruleset a c b E d v B w B x E U y C P C B P E Selective Buy-Export U B* o S o E* B B* o P E C o E* S B E U “Tubular Permission”: Each permitting edge is a tube of the permitted edge

Example Multi-Level Rulesets Selective Import-Export ruleset E  C o E* I  S o E*  P o I o E* U  S o E* P o I o E* Tube ruleset T  S  P o T  P o T o C  T o C Whole Buy-Sell ruleset E  C B  P U  B* o S o E* [Holt tech report 345 ‘96, Mancoridis thesis ‘96] ?

Violating, Conforming & Gratuitous Edges Iactual = I (these actually occur in graph) Iallowed = S o E*  P o I o E* (these are computed) Iconforming= I Ç Iallowed Iviolation = I - Iallowed Igratuitous = Iallowed - I Iactual = I Iallowed Iviolating Igratuitous Iconforming • To satisfy requirement: IactualIallowed • Bottom up: Increase parent’s Iactual • Top Down: Decrease childrens’ Iactual [See also Murphy’s “reflexion” model ‘95]

Part 6.Sum-of-Products (SoP) Permission Rules

SoP: Example Ruleset • Example ruleset has • Three variables (LHS’s): I, E and U • Three constants: S, P and C • Three rules (one for each variable I, E and U) • The right hand side for rule 1 (S  P o I) is the “sum” (union) of two “products” (S and P o I) • Rule 2 uses reflexive transitive closure (*) Rule 1: I  S  P o I Rule 2: E  C Rule 3: U  S o E*  P o I o E*

SoP: Basic Vocabulary • The RHS of each SoP rule is a “sum” of “products”, e.g., in I SP o I • RHS is the “sum” of S and P o I • P o I is a “product” • In other words: • Each RHS is a set of simple “path expressions” • SoP = Sum-of-Products = Set-of-Paths

Formal Definition: SoP Ruleset Def. A Sum-of-Products (SoP) ruleset R consists of a non-empty set of rules each of the form V  P1 P2 …  Pj where i ³ 0. Each Pi is a product and is of the form r1 o r2 o … rk where k ³ 1 About transitive closure TC. In much of the following, we disallow Transitive Closure (suffix + and *) on RHS to make our presentation simpler. In many cases below, transitive closure can occur in an RHS without changing the results. In many cases, algebraic expressions, involving parentheses, can be incorporated, as long as non-monotonic operators such as set subtraction and complement are not allowed.

Formal Definition: Symbols, Constants and Variables Def. Each symbol is a constant or a variable. Consider an arbitrary rule in an SoP ruleset: V  P1 P2 …  Pj where each Pi is a product of the form r1 o r2 o … rk Each ri and each V is called a symbol. If the symbol is directly defined in terms of the tree (e.g., C, ID, P, S), it is a constant. Otherwise the symbol is a variable. A variable is sometimes called a type. The left hand side (V) of a rule must not be a constant. Thus each left hand side (V) is a variable. Each variable V can appear on the left side of at most in one rule.

Formal Definition: Empty Sums A sum can be empty. In principle, a rule’s sum P1 P2 …  Pj can contain zero productions, which case the rule is taken to mean V  empty where empty is the set of zero edges. If a variable W appears in a product but not explicitly on the left hand side of a rule, then we assume that there is a rule of the form: W  empty We could disallow empty sums, with little change in results.

Formal Definition: Productions and Dependencies Def. Consider SoP ruleset R consisting of rules of the form V  P1 P2 …  Pj A particular Pi is: r1 o r2 o … o rk Each V with each of its products Pi is called a production, written V DR Pi Where Pi is: r1 o r2 o … o rk V DR (r1 r2 … rk) We say V depends on sequence (r1 r2 … rk) according to ruleset R V D (r1 r2 … rk) When R is clear from context we simply say V depends on the sequence. We also define (for each V and each ri) V dR ri We say V depends on symbol ri according to ruleset R V d ri When R is clear from context we say simply V depends on symbol ri We can give an SoP ruleset by giving a list of its productions.

Formal Definition: The Tree (The NBA Hierarchy) There is a hierarchy defined by tree T, which can be thought of as the containment tree of an NBA model. Def. The tree (hierarchy) T is defined by a set of nodes with directed edges called C: N = non-empty set of nodes (vertices) C N X N (C for Contain or for Child) T forms a directed tree, so: • There are no cycles formed by the C edges • There is a distinguished node called the root wuch that no node contains the root, i.e., the root has not parent • Each node except the root is contained by exactly one other node, i.e., each non-root node has a single parent There will be variable edges, e.g., V and W edges, added to the tree.

Formal Definition: States Def. Assume (1) tree T which defines node set N (2) ruleset R which defines a set of variables (relations) v = {v1, v2, …} Corresponding to each variable vi is a set of edges ei N X N, ei = (xi, yi) where xi and yi are nodes A state (or graph) s is the set of these named sets of edges s = {v1 : e1, v2 : e2, …} An alternate approach considers that s is a set of triples: s  N X v X N In the alternate approach: s = { (x1 v1 y1), (x2 v2 y2), … } where x1, x2, … , y1, y2, … are nodes and v1, v2, … are variables (relations). Each state is an NBA model

Legality of States in Terms of Ruleset R and Tree T Example ruleset R: Rule 1. I  S  P o I Rule 2. E  C Rule 3. U  S o E*  P o I o E* Assume there is a tree T that connects a set of nodes. State s consists of sets of directed edges each associated with a variable (I, E and U) from the ruleset. Each such edge connects two nodes in the tree. Def. State s is legal, written L(s), when all rules in the ruleset are satisfied (rules are interepreted using Tarski binary algebra). This example uses transitive closure, although SoP as defined disallows TC. However, most results given here can be generalized to allow TC.

Example: Two Alternate Representations of States Example ruleset: Has three variables: I, E and U. State s can be represented as either (a) n sets of pairs (one for each variable), e.g., s = { I : {(a,b), (b,c)}, E : {(a,d)}, U : {(a,d)} }, or (b) a single set of triples, e.g., s = { (a I b), (b I c), (a E d), (a U d) }

Legality of States in Terms of Permission Function f(s) Def. Permission function f(s) maps each state s (a set of triples) to a state f : Q  Q Q is the set of all states. Function f(s) is defined as the set of triples allowed by s. Example. In the ruleset with variables I, E and U, f(s) consists of I triples as computed by I’s products (S, P o I), E triples as computed by E’s products (one E tuple for each C tuple), U triples as computed by U’s products (U  S o E*, P o I o E*) Def. State s is legal, that is, L(s) is true, when s contains only triples allowed by f: L(s) =def s  f (s) Worry: This could be clearer??

Monotonic Permission Function Function f is monotonic: s  s’  f(s)  f(s’) This means: Adding triples to a graph (state) can make more triples legal and cannot make existing legal triples illegal. SoP rulesets are inherently monotonic, because each right hand side of a rule contains only monotonic operators, namely, “sum” (union) and “product” (composition).

Properties Common to Many Example SoP Rulesets • Graph is legal (Lf) if it is a prefixpoint of f Lf (s) =def s  f(s) Note: when s  f(s), s is called a prefixpoint. • Permission function f is monotonic • Legality is piecewise defined (graph is legal iff each triple in it is legal) • A graph maypermit more triples to be added to it • Legal graphs are constructive, i.e., can be built step-by-step from legal subgraphs What permission rules have these properties??

Two-Level Systems (Overview)