Reasoning About Open Systems Project � Collaboration with Agha, Mason, Smith, Talcott Modular Reasoning for Actor Specification Diagrams � Rigorous reasoning for open distributed systems Scott F . Smith � General multi-language framework The Johns Hopkins University Carolyn L. Talcott � General with respect to data Stanford University February 17, 1999 � Proof principles � Applicability to real examples for FMOODS ’99 This talk: a new graphical language for high-level specifica- tion 1 Our approach Language Design Goals UML sequence diagram style with A language for specifying message-passing behavior that is � Significantly greater expressivity � Expressive � Usefulness across a wider portion of the design cycle (not just in initial design phases) � Intuitively understandable by non-experts � Rigorous underpinnings � With a rigorous underlying semantics � Algebra of composition, restriction Choice is a graphical format for ease of communication � Elements of programming logic added 2 3
Outline of the talk A peek at an example 1. Actor communication basics This simple cell holds a single value, which responds to ✄ ✂ 2. Diagram syntax ✁ and ✄ messages. ✂ ☎ 3. Examples Cell( a ) = new ( value ) 0.. ∞ [ 4. Actor Theory framework ( a set ( value )@ c a get @ c ∇ ∇ ∇ ∇ 5. Operational semantics of diagrams c reply ( value ) c ack ∇ ∇ ∇ ∇ ( 6. Example proofs of properties: function composer [ 7. Conclusions and Future Work 4 5 Actor Communication Basics � Actors each have a unique name , ✆ Open Systems Modeling � Actors may dynamically create other actors � System is open, interacting with (arbitrary) environment ✞ � Actors only communicate by passing messages, ✝ ✆ � External actors ✞ – ✆ is destination, is data are interacting outsiders ☞ ✌ ✆ � Receptionists ✡ ✞ ☛ � Acquaintance function, ✍ are locals interacting with outsiders ☞ ✟ ✠ ✆ ✆ ✞ – the actor names communicated in a message � Sets and ✍ evolve over time ✌ � Messages are sent asynchronously � All messages must eventually arrive (fair delivery) 6 7
Interaction Path Model ✡ ✞ ☛ is an input action ✝ � ✎ ✏ ✆ —data arriving from environment; ☞ ✍ ✆ ✡ ☛ is an output action ✞ ✄ � ✑ ✒ ✝ ✆ —data sent to environment; ☞ ✌ ✆ Diagram Syntax ✓ � An actor system “run” is a sequence of ✄ actions ✎ ✏ ✑ ✒ � Each such sequence is an interaction path � Actor systems modelled by their set of interaction paths —The model is a trace-style model but is semantically clean, unlike CSP traces. 8 9 Sequence Send D D a M ∇ ∇ D a M ∇ ∇ . . Receive Parallel D . . D Send-Receive D a M ∇ ∇ . . Choice ( ( D . . D Loop [ [ D 0 ..∞ Fork Scope { { D D Skip EOD 10 11
New new x fresh x Fresh Ancestry of Features Feature Source Constrain φ ? asynchrous messaging actors parallal and choice process algebra Assert constrain and assert Dijkstra program logic φ ! cross-edge messaging UML sequence diagrams arbitrary math. universe (programming logics) x := ψ Assign state and assignment (programming langauges) Recursion X D Rec. Var. 12 13 X Function Composer—Components General points about the language ✖ for composable func- A distributed method for computing ✕ ✔ . Components are F and FC ✖ and tions ✔ � Stateful; shared variables across threads possible � F computes a function ✖ � FC composes two functions � Mathematical domain of discourse is not fixed but can be ✖ and ✔ taken to be set theory FC( a,af,ag ) = � A grammatical notation also exists (see paper) { 0.. ∞ F( a,f ) = [ a compute ( x )@ xc ∇ ∇ fresh ( xf ) � Some diagrams not realizable as actor programs { 0.. ∞ af compute ( x )@ xf [ ∇ ∇ xf reply ( y ) ∇ ∇ a compute ( x )@ xc ∇ ∇ fresh ( xg ) xc reply ( f ( x ) ) ∇ ∇ � Can encode standard constructs: if-then; while-do; syn- ag compute ( y )@ xg ∇ ∇ [ chronous messaging xg reply ( z ) ∇ ∇ { xc reply ( z ) ∇ ∇ [ { 14 15
Function Composer—System Refined Function Composer XC( a,af,ag ) = C( a,af,ag ) = { 0.. ∞ [ a compute ( x )@ xc ∇ ∇ { { 0.. ∞ [ 0.. ∞ fresh ( xf ) [ a compute ( x )@ xc ∇ ∇ af compute ( x )@ xf ∇ ∇ fresh ( xf ) xf reply ( f ( x ) ) ∇ ∇ af compute ( x )@ xf ∇ ∇ { [ 0.. ∞ fresh ( xg ) xf reply ( y ) { ∇ ∇ [ { 0.. ∞ [ ag compute ( f ( x ))@ xg ∇ ∇ fresh ( xg ) af compute ( x )@ xc ∇ ∇ xg reply ( g ( f (( x )) ) ∇ ∇ xc reply ( f ( x ) ) xc reply ( g ( f (( x ))) ∇ ∇ ∇ ∇ [ [ { 0.. ∞ { [ ag compute ( y )@ xg ∇ ∇ [ { ag compute ( x )@ xc ∇ ∇ { xg reply ( z ) ∇ ∇ xc reply ( z ) ∇ ∇ xc reply ( g ( x )) ∇ ∇ [ [ { { Cross-edges assert sends and receives match up 1-1 16 17 Relating Specification Diagrams Need useful notions of how implementation ✘ satisfies spec- ✗ ification . ✙ ✗ Strong Satisfaction and the Function Composer First Notion: full and faithful satisfaction of a specification. Definition 1 (strong satisfaction): ✖ is F ✡ ✖ ☛ High-level specification for computing ✕ ✕ ✧ ✜ ✜ ✢ iff ✔ ✆ ✔ ✚ ✛ ✚ ✛ ✘ ✤ ✙ ✢ ✣ ✣ ✗ ✗ Theorem 2: ✜ ✜ ✥ ✥ ✚ ✛ ✦ ✦ ✥ ✥ ✚ ✛ ✦ ✦ ✘ ✤ ✙ ✢ ✢ ✗ ✗ C ✚ ✡ ✖ ★ ☛ ✛ ✪ ✩ / ✤ 0 ✣ ✣ ✧ ✧ ✧ ✧ ✆ ✔ ✆ ✆ XC ✚ ✡ ✖ ★ ☛ ✛ ✪ ✩ / ✤ 0 ✣ ✣ ✧ ✧ ✧ ✧ ✆ ✔ ✆ ✆ where F ✚ ✡ ✖ ☛ ✛ ✪ ✕ / 0 ✧ ✆ ✔ � a top-level specification diagram includes an interface, Proof will be sketched later in talk. ✜ ✚ ✛ notated ✢ ✗ ✜ ✜ ✥ ✥ ✚ ✛ ✦ ✦ is interaction path semantics of ✚ ✛ � ✢ ✢ ✗ ✗ 18 19
Running Example: Ticker A Ticker is a monotonically increasing counter Asserting Properties of Specifications Diagrammatically Ticker( a ) = { new ( count ∈ Nat ) � Safety and liveness properties can be asserted directly 0.. ∞ [ in the specification diagram language. 0..ω [ a time @ x ∇ ∇ x reply ( count ) ∇ ∇ � The ability to express assertions diagrammatically means [ there is less need to learn a specialized logic in which count := count + 1 assertions are written. [ { � More practical possibility of getting engineers to use. � Finite Inner loop 0 ✬ guarantees progress of ✰ . ✟ ✭ ✮ ✯ Three techniques for asserting properties now covered ✫ ✫ ✫ Ticker ✚ ✡ ☛ ✛ ✪ � A top-level ticker: 0 . ✱ / 20 21 Assertions I - Loose Satisfaction Assertions II - Environment-Based Assertions Specify an environment which fails when desired property Loose satisfaction is a standard notion of satisfaction: ✜ ✜ ✢ iff ✜ ✜ fails. ✚ ✛ ✚ ✛ ✥ ✥ ✚ ✛ ✦ ✦ ✲ ✥ ✥ ✚ ✛ ✦ ✦ . ✘ ✤ ✙ ✘ ✙ ✢ ✣ ✢ ✢ ✗ ✗ ✗ ✗ ✳ “Diagram has property D ” is expressed as LiveTickerEnvt( a ) = { ✗ ✴ ✜ ✜ ✚ ✳ ✛ ✚ ✛ fresh ( c ) ✤ ✢ ✣ ✢ ✗ ✗ 0.. ∞ [ Consider for instance the LiveTicker a time @ c ∇ ✡ ☛ ∇ ✆ LiveTicker( a ) = ( { 0.. ∞ [ c reply ( count ) ∇ ∇ a time @ c ∇ ∇ assert( false ) new ( count ) c reply ( count ) ∇ ∇ ( [ [ { { Ticker LiveTicker ✚ ✡ ☛ ✛ ✪ ✚ ✡ ☛ ✛ ✪ Assert: / 0 ✱ ✱ Ticker ✣ LiveTickerEnvt / 0 ✤ 0 / ✣ ✚ ✡ ☛ ✡ ☛ ✛ Assert: ✱ ✱ ✤ 0 / ✣ messages sent to the Ticker will receive a reply ✜ ✚ ✛ (Validity ✢ means no ✄ fail.) – all ✄ ✤ ✂ ✷ ✎ ✵ ✂ ✣ ✗ ✶ ✁ ✁ 22 23
Recommend
More recommend
