Part 5.
This presentation is the property of its rightful owner.
Sponsored Links
1 / 30

Two-Level Systems (Overview) PowerPoint PPT Presentation


  • 47 Views
  • Uploaded on
  • Presentation posted in: General

Part 5. Permission Rules for Two-Level Systems Controlling 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

Download Presentation

Two-Level Systems (Overview)

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


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-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.


Example two level system three representations

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

“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

“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

“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

“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

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

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

Various Two-Level Rulesets

Constraints: Leaf2Leaf(U), Mod2Mod(I)


Two level systems overview

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


Example ruleset whole import export

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

Whole Import-Export Ruleset

I

a

c

E

b

d

I

E

x

U

y

  • UseU S o E*  P o I o E*

  • ImportI S  P o I

  • ExportE C

Each permitting edge is a tube of the permitted edge


Selective buy export ruleset

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

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

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

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


Sop example ruleset

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

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

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

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

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

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

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

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

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: 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

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

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

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??


  • Login