Reusable specification templates for defining dynamic semantics of DSLs Ulyana Tikhonova ulyana.tikhonova@constelle.net Tim Willemse Mark van den Brand
Domain Specific Languages (DSLs) 2
3
• To understand the dynamic semantics • To analyze the dynamic semantics DSL developer • To validate the dynamic semantics • To understand and debug DSL programs DSL user Precise and executable definition Why to define dynamic semantics? 4
What is dynamic semantics? 6
1 2 3 4 5 What is dynamic semantics? 7
1 2 3 4 5 • To understand the dynamic semantics • To analyze the dynamic semantics • To validate the dynamic semantics • To understand and debug DSL programs What is dynamic semantics? 8
• To understand the dynamic semantics • To analyze the dynamic semantics • To validate the dynamic semantics • To understand and debug DSL programs Dynamic semantics as requirements vs. dynamic semantics as an actual implementation 9
Specification templates 10
Language constructs (statements) Semantic mapping • Variables/memory • Control flow Semantic domain • Branching Defining dynamic semantics of programming languages 11
DSL constructs (statements) Semantic mapping • Variables/memory • Control flow Semantic domain • Branching Defining dynamic semantics of domain specific languages 12
DSL constructs (statements) Semantic mapping • Architecture layers Specification • Design patterns Semantic domain templates • Synchronization protocols Semantic mapping • Variables/memory • Control flow Semantic domain • Branching Defining dynamic semantics of domain specific languages 13
DSL constructs (statements) Semantic mapping • Architecture layers Specification • Design patterns Semantic domain templates • Synchronization protocols Semantic mapping • Variables/memory • Control flow Semantic domain • Branching Defining dynamic semantics of domain specific languages 14
MACHINE queue_machine SEES queue_context VARIABLES queue INVARIANTS MyType inv1: queue ∈ ℕ ⇸ ElementType EVENTS dequeue ≙ ANY element, index INITIALISATION ≙ WHERE act1: queue ≔ ∅ MyType grd1: element ∈ ElementType END grd2: index ∈ ℕ grd3: queue ≠ ∅ ⇒ enqueue ≙ ( ∀ i·i ∈ dom(queue) ⇒ index > i) ANY element, index grd4: {index ↦ element} ∈ ℕ ⇸ ElementType MyType WHERE grd5: index ∉ dom(queue) MyType grd1: element ∈ ElementType THEN grd2: index ↦ element ∈ queue act2: queue ≔ queue ∪ {index ↦ element} grd3: ∀ i·i ∈ dom(queue) ⇒ index ≤ i END THEN act1: queue ≔ queue ∖ {index ↦ element} END END 16
Data * Scan Transformation DSL 0. .1 metamodel * Order * Dataflow t fro 1. o m t fro 1 1 o m .* 1 1 Subsystem Subsystem typ bo Logical * action Data Node e dy action action 1 occurrence * inp * * * * * ut 1 typ 1 typ output e e inp ut Subsystem Data type output Structural interface Constelle Substitution Structural interface Event-B enqueue ≙ dequeue ≙ MACHINE queue_machine specification SEES queue_context ANY element, index ANY element, index VARIABLES queue WHERE WHERE MyType MyType INVARIANTS grd1: element ∈ ElementType grd1: element ∈ ElementType MyType inv1: queue ∈ ℕ ⇸ ElementType grd2: index ↦ element ∈ queue grd2: index ∈ ℕ grd3: ∀ i·i ∈ dom(queue) ⇒ index ≤ i grd3: queue ≠ ∅ ⇒ ( ∀ i·i ∈ dom(queue) ⇒ index > i) EVENTS MyType INITIALISATION ≙ THEN grd4: {index ↦ element} ∈ ℕ ⇸ ElementType act1: queue ≔ ∅ act1: queue ≔ queue ∖ {index ↦ element} grd5: index ∉ dom(queue) END END THEN 17 act2: queue ≔ queue ∪ {index ↦ element}
DSL constructs (statements) Semantic mapping • Architecture layers Specification • Design patterns Semantic domain templates • Synchronization protocols Semantic mapping • Variables/memory • Control flow Semantic domain • Branching Defining dynamic semantics of domain specific languages 18
1 2 3 4 5 Mapping DSL constructs to specification templates 19
VARIABLES curr_job, curr_la, la_input, ssa_output request_ssa (ssaction, occurence) INVARIANTS where la_input ∈ ℕ ⇸ LogicalActions occurence ∈ curr_job ssa_output ∈ ℕ ⇸ SSActions occurence ↦ ssaction ∈ LALabelDef (curr_la) curr_job ∈ ℙ (SSAOccurences) then curr_la ∈ LogicalActions curr_job ≔ curr_job \ {occurence} EVENTS Initialisation execute_ssa (ssaction, n) curr_la : ∈ LogicalActions where curr_job ≔ ssaction ∈ SSActions la_input ≔ n ∈ ℕ ssa_output ≔ ssa_output ≠ ⇒ ∀ i · i ∈ dom(ssa_output) ⇒ n > i request_la (la, n) then where ssa_output ≔ ssa_output ∪ { n ↦ ssaction } la ∈ LogicalActions curr_job = END n ∈ ℕ la_input ≠ ⇒ ∀ i · i ∈ dom(la_input) ⇒ n > i then curr_job ≔ dom(LALabelDef(la)) curr_la ≔ la la_input ≔ la_input ∪ { n ↦ la } 20
operation1 Queue subscribe enqueue Listener init_partial_order dequeue subscribe operation2 notify notify enqueue is_max_element Partial Order operation3 init_partial_order dequeue is_max_element remove_element remove_element Aspect Oriented Programming: cross cutting concerns 21
Listener Queue Partial Order operation1 subscribe init_partial_order operation2 notify enqueue is_max_element operation3 dequeue remove_element Specializations of specification templates from the library Aspect Oriented Programming: composing cross cutting concerns 22
Aspects = specification templates Operations of the DSL dynamic semantics Substitution of template (static) parameters with DSL types Constelle 23
Event-B/Rodin Specification Event-B templates specification templates DSL/Ecore Constelle Meta-model definition Constelle-to-Event-B Event-B DSL model specification Constelle 24
• Scalability and applicability of the proposed method – Validated on three different DSLs • A library of specification templates – State machine, communication channels, data typing, design patterns (Listener), data structures (Queue) • Specification templates for bridging technological diversity – Source code, visualization templates, formal notations Future work 25
More details: SoSyM paper & PhD thesis 26
Recommend
More recommend