Create Presentation
Download Presentation

Download

Download Presentation

Full LOTOS Department of Computer Science University of Regina, Regina SK, Canada

168 Views
Download Presentation

Download Presentation
## Full LOTOS Department of Computer Science University of Regina, Regina SK, Canada

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

**Full LOTOSDepartment of Computer ScienceUniversity of**Regina, ReginaSK, Canada November 18, 2002 Yashu Bither Amrudee Sukpan Tetyana Manuylenko Chakka Sreenivasulu**Outline**• Introduction. • Full LOTOS. • Difference from Basic LOTOS. • Spec(s) in Full LOTOS. • Facts of Full LOTOS. • Value Expression - Value and variable declaration. • Scope and binding of Variables. • Inter Process Communication. • Example.**Introduction**• Basic LOTOS only describes process synchronization. • Data exchange is an important feature in telecommunication and distributed systems.**Full LOTOS**• Full LOTOS enhances the expressive power of Basic • LOTOS by providing the finer structure to observable • actions and enrich process synchronization with value • passing thus providing inter process value communication. • Full LOTOS includes data description (ACT ONE) and • control components (enriched basic LOTOS). • Full LOTOS introduces value communication and data • types to the process algebraic concepts of Basic LOTOS.**Difference from Basic LOTOS**• An observable gate = a gate name + a list of values ( or value expression). event attributes Structured event Basic LOTOS For example: g<true> g<29, false> Contd...**Difference from Basic LOTOS .. 2**• The representations of data values and value expressions • in full LOTOS are derived from the specification language • for abstract data types - ACT ONE. • As a major advantage, in full LOTOS we will be able to • enrich synchronization with value passing, thus providing • interprocess communication. • In basic LOTOS an observable action coincides with a gate • name, in full LOTOS it is formed by a gate name followed • by a list of zero or more values offered at that gate: • g <v 1 ... v n >. For example: g <TRUE, "tree", 3>**Spec(s) in Full LOTOS**Specification typical_spec [gate list] (parameter list) : functionality type definitions behavior behavior expression where type definitions process definitions end spec process typical_proc [gate list] (parameter list) : functionality := behavior expression where type definitions process definitions end proc**Facts of Full LOTOS**• Values can be offered at gates and exchanged between • processes (enrichment of the action prefix operator). • New Construct of guarding and selection predicates. • Values can be used to generalize choice operator. • Values can be used to instantiate parametric process • definitions; let construct. • InterProcess Communication (Sequential composition…).**Value declarations**• The general format for the value declaration is: • !E • where E is a LOTOS expression or (value expression) or ( an • expression describing a data value). • For example: !(3+5) !(x+1) !max(x,y) • In Basic LOTOS: g; B g B` • B is a process that offers g and then behaves like B`. • In Full LOTOS: g!E; B g<value(E)> B` • B is a process that offers g<value(E)> and then behaves like B`.**Value declarations … contd**For example: if x =3 and y =5 then g!max(x,y) = g!max(3,5) describes g<5>.**Variable declarations**• The general format for the variable declaration is: • g?x: t;B • where x is a variable name • and • t is a sort identifier.It indicates the domain of values over which x ranges. • For example: ?x:integer ?text:string ?x:nat • So g?x: t;B(x) is a process that offers all events g<v> where v • is any value in the domain of sort t and then behaves like B(v).**Scope of**?y:nat Scope of ?x:nat Binding occurrence of x Binding occurrence of y Scope and binding of Variables For example: a?x:nat; b?y:nat; c!max(x,y); stop Usual rules for nested scopes apply.**Inter Process Communication (IPC)**• IPC may occur when two processes composed in parallel • are offering the same structure action i.e. same gate and • same values. • g1!sap1 ?x:cep_sort !”test”; g2!x; stop • || • g1!sap1 !cep_3 ?y:string; g3!y; stop • The processes if synchronize, are able to offer action • g1<sap1, cep-3, “test”> • Once the interaction has taken place, the exp. obtained is: • g2 !cep_3; stop • | | • g3 !”test”; stop • where the proper substitutions have been carried out.**Forms of IPC**• VALUE MATCHING: The synchronization actions are combined • with value declarations. If the provided values are equal, • the synchronization is possible. • VALUE PASSING: Combination of value declaration and variable • declaration results in value passing. The effect is that a value is • transmitted from one process to the other. • VALUE GENERATION: The only remaining case is the one where • actions are combined with the variable declarations of the same type • attached to them. Superposing another process in parallel that offers • a value of the required type yields a form of multicast communication.**Forms of IPC … contd**Process A Process B Synchron type effect condition of interaction Synchronization Value(E1) = value(E2) Value matching g!E1 g!E2 Value(E) is of sort t After Synchron. X = value(E) Value passing g!E g!x:t g!x:t g!y:u t = u Value generation After sync. x=y=v where v is in domain of t.**Example in Full LOTOS**Specification Max3 [in1, in2, in3, out]:noexit type natural is sorts nat opns zero: nat succ: nat nat largest: nat, nat nat eqns ofsort nat forall x:nat largest(zero, x) = x largest(x, y) = largest(y, x) largest(succ(x), succ(y)) = succ(largest(x, y)) endtype (* natural *) behaviour hide mid in (Max2[in1, in2, mid] |[mid]| Max2[mid, in3, out]) where process Max2[a, b, c] : noexit := a ?x:nat; b ?y:nat; c !largest(x,y); stop [] b ?y:nat; a ?x:nat; c !largest(x,y); stop endproc (*Max2*) endspec (*Max3*)**Conditional Constructs in Full LOTOS**• Selection Predicate • Guarded Expression**Selection Predicates**Format: action denotation [equation]; Examples: [X=4] [X<0]**Selection Predicate**• A selection predicate can be associated with an action denotation • It imposes restrictions on the values that may be bound to these variables. • Selection predicate may contain variables that occur in the variable declarations (?x:t)**Example:G1?x:nat [x<3]**G1!0 G1!1 G1!2 G1?x:nat G1!0 G1!1 G1!2 G1!3 G1!4 G1!5 ... G1 G1 G1!0 [] G1!1[]G1!2**g1<0>**g1<2> g1<1> g2!1 g2!2 g2!0 Scope of variable declarations g1?x:nat[x<3];g2!x;stop • has the following three possible transitions • g1<0> -> g2!0;stop • g1<1> -> g2!1;stop • g1<2> -> g2!2;stop • be considered as part of the scope of the variable declarations in that action denotation.**Selection Predicate**• Synchronization • 2 processes negotiate the value of a parameter in an interaction which each one imposing its own condition P P**Selection Predication**Hide sap in sap?x:nat[x<max];B1(x) |[sap]| sap?y:nat[y>min];B2(y) Ex:max=10 and min=5 x=0,…,9 y=6,…,n possible values = 6,7,8,9 B1 B2 sap sap**Selection Predicate**Hide sap in B1(n) |[sap]|B2(n) * min<n<max Synchronization can occur with the environment on one of two actions.**Conditional Constructs**• Selection predicates • Guarded expressions**Guarded expression**• Any behaviour expression may be preceded by a predicate and an arrow if (expression) then Behaviour Format: [expression]->Behaviour**Guarded Expression**• if the predicate holds, then the behaviour described by the behaviour expression is possible, otherwise the whole expression is equivalent with stop**Example**[X>0]->sap!X;P[...](x,…) [] [X<=0]->sap!-X;P[...](x,…) * if x=1 then sap!1;P[...](1,…) * if x=-3 then sap!3;P[…](-3,…)**Guarded expression**[cond1]->process1 [] [cond2]->process2 [] ... [condn]->processn**Guarded expression**• The conditions in the guards need not be exclusive [x>0] -> process1 [] [x=5] -> process2 [] [x<9] -> process 3 *if X=10 then process1 *if X=5 then process1[]process2[]process3 *if X= 2 then process1[]process3**g?x:Nat[x<=5];( [X=2 or X=3]-> g!X!0;stop [] [X<3] ->**g!X!1;stop) Example g!0;g!0!1;stop [] g!1;g!1!1;stop [] g!2;(g!2!0;stop[]g!2!1;stop) [] g!3;g!3!0;stop [] g!4;stop [] g!5;stop**Generalized Choice in Full LOTOS**• Choice operator “[]” can only express a finite number of alternatives. • Generalized Choice specify the choice among all possible value expressions of a sort.**Generalized Choice**Choice X:S[]B(X) if t1,…,tn are all possible value expressions of sort S. The resulting behavior by substitution ti for X in B.**Generalized Choice**• Let B(x) be a behaviour expression, depends on a variable X of sort nat. • Specify the choice among the processes B(v) for all nat-values v • choice x:nat [] B(X) B(0) [] B(1) [] B(2) [] B(3) []…[] B(n)**Generalized Choice**• The generalized choice construct allows an alternative representation for the action prefix construct, when this include a variable declaration a?x:t;B(x) = choice x:t[]a!x;B(x)**Example**g!0;stop [] g!2;stop [] g!4;stop [] … ... Choice x:Nat[] [x mod 2=0]->g!x;stop**Generalized Choice**• choice x:t [] i;B(X) • choice x:t[] a;B(x) • more than one variables • choice x1:t1,…,xn:tn[] B(x1,…,xn) • sets of gate identifiers may be used for indexing • choice g in [a1,…,an] [] Process_X[g](…)**Generalized Choice**• sets of gate identifiers may be used for indexing • choice g in [a1,…,an] [] Process_X[g](…) • expressed among n instances of Process_X • formal gate g is actualized with a different element of the gatelist [a1,…,an]**Full LOTOS**• Interprocess communication • Conditional constructs • Selection Predicates • Guarded Expressions • Generalized Choice • Parametric processes**Parametric Processes**Full LOTOS offers the possibility to parameterize process definition in terms of a parameter list. process typical_proc[gate list](x1:t1, ..., xn:tn):functionality := … endproc Parameter list is a list of variable declarations.**Specifications can be parametric as well as process**definitions. process typical_proc[gate list](x1:t1, ..., xn:tn):functionality := … endproc Instantiation typical_proc[actual gate list] (E1, …, En) value expressions**Example:**process compare[inp, out] (min, max: int) : noexit := inp ?x:int; ( [min<x<max] -> out !x; compare[inp, out] (min, max) [] [x<=min] -> out !min; compare[inp, out] (x, max) [] [x>=max] -> out !max; compare[inp, out] (min, x) )endproc behaviour expression**Instantiation:**compare[one, two] (x, 2*x) one ?y:int; ( [x<y<2*x] ->two !y; compare [one, two] (x, 2*x) [] [y <=x] -> two !x; compare [one, two] (y, 2*x) [] [y>=2*x] -> two !2*x; compare [one, two] (x, y) ) actual parameters**A more direct way to associate value expressions E1, …, En**to the free variables x1, …, xn of a behaviour expressions B(x1, …xn) is offered by the ‘let’ construct: let x1:t1 = E1, …, xn:tn = Enin B(x1, …, xn) compare[one, two] (x, 2*x) one ?y:int;let z:int = x*2 in ( [x<y<z] ->two !y; compare [one, two] (x, z) [] [y <=x] -> two !x; compare [one, two] (y, z) [] [y>=z] -> two !z; compare [one, two] (x, y) )**Sequential Composition with Value Passing**• Connection-Phase[...] >> Data-Phase[...] • Data-Phase depends on parameters that are established in Connection-Phase. • Data-Phase is called Parametric Process. • Need a mechanism for passing these parameters. • Generalize the notion of Successful Termination. • Add some static constraints to the Full Lotos Language.**Successful termination with value offers**• In Full LOTOS, the exit process has a finite list of value expressions. The values expressed are those that are passed on to the subsequent process. For example, • a ?x:nat; b ?y:nat; exit(largest(x, y)) • tsap !cei ?quality-of-service : quality-parameter-sort ?expedited-data-option : bool; exit(quality-of-service, expedited-data-option) Functionality of the Termination**Rules determining Functionality of Behaviour Expressions**• The list of the sorts of the values offered at successful termination is called the functionality of that termination. • Functionality and Actual Termination are two different things. • The functionality is a sort of static typing mechanism, which is only meant to guarantee the predictability of the list of sorts offered at successful termination, in case, such termination occur.**Rules determining Functionality of Behaviour Expressions**(Cont…) • The actual occurrence of a successful termination, in general, cannot be decided statically, nor dynamically. “Halting Problem” for Turing Machines. • The functionality typing scheme helps in avoiding constructions however, of which the absence of successful terminations can be decided statically. • 'func(B)' to denote the functionality of expression B**Stop**• The functionality of processes that do not terminate successfully at all, like stop, is indicated with noexit.**Exit**• The Simple successful termination without value passing has a functionality that is indicated by the same name: func(exit) = exit.