1 / 21

Forges: Synthesizing Verified Generators

Forges: Synthesizing Verified Generators. Kestrel Institute PIs: Cordell Green, John Anton CSs: Lindsay Errington, Doug Smith, Alessandro Coglio, Stephen Westfold, Jim McDonald. Objective: synthesize model-based generators!. Produce generators quicker! Produce generators that are verified!.

lotta
Télécharger la présentation

Forges: Synthesizing Verified Generators

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Forges: Synthesizing Verified Generators Kestrel Institute PIs: Cordell Green, John Anton CSs: Lindsay Errington, Doug Smith, Alessandro Coglio, Stephen Westfold, Jim McDonald

  2. Objective: synthesize model-based generators! • Produce generators quicker! • Produce generators that are verified!

  3. Stateflow model Stateflow meta-model Meta Generator Generator translation specification C meta-model C code Overview design knowledge

  4. Taxonomy of Algorithm Theories Problem Theory (D|I  R|O) generate-and-test Constraint Satisfaction (R = set of maps) Global Structure (R = set + recursive partition) global search binary search backtrack branch-and-bound Problem Reduction Structure Local Structure (R = set + relation) genetic algorithms Linear Programming simplex method interior point primal dual Complement Reduction sieves Integer Linear Programming 0-1 methods Local Structure (R = set + relation) local search hill climbing simulated annealing tabu search Divide-and-Conquer divide-and-conquer GS-CSP (R = recursively partitioned set of maps) Problem Reduction Generators dynamic programming branch-and-bound game tree search Network Flow specialized simplex Ford-Fulkerson Local Poset Structure (R = set + partial order) GS-Horn-CSP (Horn-like Constraints) constraint propagation Monotone Deflationary Function fixed point iteration Transportation NW algorithm Local Semilattice Structure (R = semilattice) Assignment Problem Hungarian method

  5. What’s a meta-model? • A language specification! • Static semantics • What are well formed programs in the language • Dynamic semantics • How programs behave

  6. Elements of a Static Semantics • Abstract syntax • Characterization of well-formed terms • Type theory • Vanderbilt has a static-semantics UML meta-model for Stateflow • We translate UML into specifications in logic

  7. Stateflow static semantics sort Event, State, Transition, Action, … op src : Transition State op dst : Transition  State op event : Transition  Event op action : Transition  Action op children : State  Or [State] | And [State] | None op parent : State  State

  8. Static semantics (cont’d) op active : State Bool active(s)  parent(s) ≠undefactive(parent(s)) “the ancestors of an active state are active”

  9. Dynamic Semantics • Many formalisms to choose from • Denotational, axiomatic, … • Action Semantics (Mosses) • Structural Operational Semantics (Plotkin) • Natural Semantics (Kahn) (used in Centaur) • Our choice: • Abstract State Machines (ASMs) aka Evolving Algebras (Gurevich)

  10. What are Abstract State Machines? • Algebraic theories. • Sorts, operators, axioms • Rules for conditionally rewriting theories. • if b then f(t1,…,tn) := t

  11. ASM Example sort Node op left : Node Node op right : Node Node op node : Node if left(node)  undefthen left(node) := left(left(node)) right(node) := right(left(node))

  12. Why ASMs? • ASMs support: • abstraction • refinement • composition • Comprehensible • To be shared with other MoBIES participants.

  13. a/b b entry: f(); entry: g(); Stateflow dynamic semantics • Stateflow is event driven

  14. Dynamic semantics (cont’d) • Event handling can be pre-empted • Need a stack! sort Frame = ExecAction | EndTransTransition | … sort Stack = [Frame] op stack : Stack startTrans(s : State, t : Transition) = active(s) := false stack := (Execaction(t)) :: (EndTranst) :: (tail stack)

  15. Verifiability: when is the translation correct? • Conventional notion: • Program p denotes a function or relation [p] • Translation correct when the denotation is preserved: [p] = [trans(p)] • Conventional notion doesn’t work: • Stateflow diagrams are reactive – not functional – they may never terminate!

  16. Bisimulation! • A run of a machine on a program p is a sequence of states. • We observe only the events. • p and trans(p) are equivalent when we observe the same behaviour • Formally we define a bisimulation relation between the states of p and trans(p)

  17. C Stateflow p trans(p) e e q q’ Bisimulation … and vice versa

  18. Bisimulation • What we won’t do: • Exhibit the bisimulation relation • What we will do: • Ensure that the translation preserves bisimulation

  19. Status • Meta-modeling • Translation theories – getting started

  20. Conclusions • Produce generators quicker! • By reuse of language meta-models • By capturing and exploiting design knowledge • Produce generators that are verified! • Translation preserves bisumulation

  21. Tasks ahead • Completion of meta-models • Validation of meta-models • Abstraction of design theories

More Related