Applying SOS to MDE

Semantics SOS DSL’s SOS for a DSL Conclusions

Applying
Structural Operational Semantics
to MDE
Deﬁne the Semantics of your DSL

Tjerk Wolterink

University of Twente

March 30, 2009

Applying , Structural Operational Semantics , to MDE
1 / 45


Outline

Semantics
1

2

Domain Speciﬁc Languages
3

Structural Operational Semantics for a DSL in MDE
4

Conclusions
5

2 / 45


Introduction

Observation MDE, generally, lacks formal semantics
Problem Statement Can Structural Operational Semantics (SOS)
be successfully applied to MDE?
Research Objectives Make SOS useful for MDE
Providing a semantic language named SemLang
Proof by example: apply SemLang
Build a tool, the Semantic Engine to simulate models

3 / 45


Outline

Semantics
1

2

3

4

Conclusions
5

4 / 45


Language Definition

Abstract Syntax Determines the form and structure of programs
Textual languages, Iconic languages, Diagrammic
languages
Specification for parsers
Semantics Models the computational meaning of each program
Specification for compilers/interpreters
Dimension: Informal vs Formal
Dimension: Static vs Dynamic

5 / 45


Informal Semantics

Meaning of a language is described using human readable text

Example:”’Semantics of Java && operator:
The && operator perform Conditional-AND operations on two
boolean expressions. This operator exhibit ”short-circuiting”
behaviour, which means that the second operand is evaluated only
if needed.

Advantages easy to read, easy to understand, easy to create
Disadvantages imprecise, ambiguous, not computer-readable, not
useful for mathematical techniques (like proofs,
model checking etc.)

6 / 45


Formal Semantics
Semantic mapping from syntax L to a semantic domain S.
M:L→S
Semantic domain: well known mathematical domain: natural
numbers, graphs, labelled transition systems etc.
Semantic mapping: describes how the syntax relates to the
semantic domain
Approaches: Axiomatic, Denotational, Graph Transformations,

Advantages precise, computer-readable, useful for mathematical
techniques (like proofs,system validation, simulation
etc.)
Disadvantages often diﬃcult to read, understand, create. Requires
understanding of the semantic domain.
7 / 45


Static vs Dynamic Semantics
Static semantics models compile-time checks
Checks that can be performed before running
Well formedness
Type checking

Example: Type checking a type cast
(TypeA)new TypeB()
Check that TypeA is a subclass of TypeB

Dynamic semantics models run-time behaviour
Concerned with the observable behaviour of a running program
Description of computational steps

Example: Evaluation of If-Expressions
if(a) then b
if a evaluates to true then evaluate b
8 / 45


Outline

Semantics
1

2

3

4

Conclusions
5

9 / 45


Overview of Structural Operational Semantics
(SOS & MSOS)

MSOS is Modular SOS
Semantic domain of SOS is a labelled terminal transition system
(LTTS)

Definition
A LTTS is a quadruple (Q, T , A, →) with Q as set of states, a set A of
labels α. A relation →⊆ Q × A × Q of labelled transitions ((s, α, s‘) is
α
written as s −→ s‘), and a set T ⊆ Q of terminal configurations such
α
that s −→ s‘ implies s ∈ T
/

SOS Specification consists of
Definitions of the sets Q, A and the end states T
A set of rules that specify the transition relation →

10 / 45


Overview of SOS

States are sentences that conform to an extension of the abstract
syntax: value-added syntax
Transitions are speciﬁed inductively by rules
A single transition can be proven by a set of rules
Rules alter the structure of the states

Graphics from Structural Operational Semantics 1981 by G.D. Plotkin

11 / 45


Rules in SOS
t‘
A rule consist of transition assertions t −→ t“
The terms t, t‘, t“ are language sentences that may contain
meta-variables
Rule Deﬁnition
c1 , · · · , cn
c
A rule has zero or more conditions c1 , · · · , cn and a conclusion c
t‘
c1 , · · · , cn , c are transition assertions (t −→ t“)
c1 , · · · , cn can also be simple assertions (equations)
Informal meaning: if c1 , · · · , cn then c
Example if rule for a pseudo language
e1 → e1 ‘
if e1 then e2 → if e1 ‘ then e2
12 / 45


Rules define the Transition Relation →

Given a set of rules, a triple (s, α, s‘) is in the transition relation if
and only if a finite branching tree can be formed that follows
satisfies the following conditions:
All nodes are labelled by elements of Q × A × Q
1

the root nodes is labelled by (s, α, s‘)
2

c1 ,··· ,cn
for each node with n child nodes there is a rule and an
3
c
interpretation of the meta-variables such that/
the label of the node is the interpretation of c
the labels of the child nodes are the interpretations of c1 , · · · , cn .

Concrete examples will be given to make it easier to understand

13 / 45


Example: Simple Expression Lang
First deﬁne the valid structure of a program, the syntax:
Abstract syntax
Numbers: n ∈ N = {0, 1, 2, · · · }
Binary Operators: bop ∈ Bop = {+, −, ∗, · · · }
Expressions: e ∈ Exp = n | e0 bop e1

Example program
Exp
Exp Bop N
(2 + 3) ∗ 8
N Bop N * 8
2 + 3

14 / 45


Simple Expressions Lang Semantics

The states Q are sentences of the language
Numbers N = {0, 1, 2, · · · } are end states T
No labels are used A = ∅

15 / 45



The transition relation → is speciﬁed by a set of rules:
Evaluate lhs Rule
e0 → e0 ‘
(1)
e0 bop e1 → e0 ‘ bop e1
Evaluate rhs Rule
e1 → e1 ‘
(2)
n0 bop e1 → n0 bop e1 ‘

15 / 45



Evaluate plus Rule
bop = + n = n0 + n1
(1)
n0 bop n1 → n

Evaluate multiply Rule
bop = ∗ n = n0 ∗ n1
(2)
n0 bop n1 → n

15 / 45


Computation trace

First transition
(2 + 3) ∗ 8 → 5 ∗ 8

Transition proof
Initial state
(2 + 3) ∗ 8

16 / 45


Computation trace

First transition
(2 + 3) ∗ 8 → 5 ∗ 8

Transition proof
2 + 3 → e0 ‘
(2 + 3) ∗ 8 → e0 ‘ ∗ 8
By applying the lhs evaluation rule:
e0 → e0 ‘
e0 bop e1 → e0 ‘ bop e1

16 / 45


Computation trace

First transition
(2 + 3) ∗ 8 → 5 ∗ 8

Transition proof
bop = + e0 ‘ = n0 + n1
2 + 3 → e0 ‘
(2 + 3) ∗ 8 → e0 ‘ ∗ 8
By applying the evaluate plus rule:
bop = + n = n0 + n1
n0 bop n1 → n

16 / 45


Computation trace

First transition
(2 + 3) ∗ 8 → 5 ∗ 8

Transition proof
+ = + e0 ‘ = 2 + 3
2 + 3 → e0 ‘
2 + 3 ∗ 8 → e0 ‘ ∗ 8
By substituting the meta variables

bop = + n0 = 2 n1 = 3

16 / 45


Computation trace

First transition
(2 + 3) ∗ 8 → 5 ∗ 8

Transition proof
Full proof
+ = + e0 ‘ = 5
2 + 3→5
2+3 ∗ 8→5 ∗ 8
by substituting e0 ‘
e0 ‘ = 2 + 3 = 5

16 / 45


Outline

Semantics
1

2

3

4

Conclusions
5

17 / 45


Generic vs Speciﬁc Languages

DSL Domain Speciﬁc
GPL General Purpose Language
Language
Small ( often extensions of
Large GPLs (embedded))
Gap between language Closer to problem domain:
domain and problem domain captures domain knowledge
Users: software-engineers, Users: Same as DSL plus
programmers domain-experts, end-users

Examples Examples
C++, Java, Fortran, Lisp SQL, BNF, HTML, RegExp,
XSLT

18 / 45


Defining a DSL

Executable vs Static DSL’s
Define domain concepts and relations in a
metamodel
Plays the role of an abstract syntax
Captures domain knowledge
Define concrete syntax (optionally)
Textually or visual
Provides easier editing
Define semantics
Informally using code generation to a GPL
Formally both dynamic and static semantics

19 / 45


Outline

Semantics
1

2

3

4

Conclusions
5

20 / 45


Defining the Semantics of a DSL
Take an MDE approach: everything is a model
Define a DSL SemLang for defining semantics of other DSL’s
SemLang: The Semantic Language DSL
Builds upon SOS and MSOS

21 / 45


SOS vs SemLang

SemLang
SOS & MSOS

MetaModel deﬁnes DSL
Abstract Syntax deﬁnes
structure
Language Structure
Models are states
Sentences are states
→ states are graphs
→ States are trees
Rules contain object
Rules contain syntax
patterns

SOS Rule
e1 → e1 ‘
if e1 then e2 → if e1 ‘ then e2

22 / 45


SOS vs SemLang

SemLang Rule
C → C‘
IfExp(e1 = C, e2 = E) → IfExp(e1 = C‘, e2 = E)

22 / 45


Understanding SemLang

Understanding SemLang by example
For each DSL we deﬁne
MetaModel
Sample model (sample program)
Semantics in SemLang
The sample model will be executed.
The DSL’s:
Simple Imperative Language
Activity Diagram Language

23 / 45


Simple Imperative Language: MetaModel

24 / 45


Simple Imperative Language: Sample Model
Seq

c1 c0

Seq Assign

c0 c1 e name

Assign Assign Number a

e name e name val

BinaryExp b BinaryExp a Integer:10

lhs rhs bop lhs rhs bop

Number Var Plus Var Number Minus

val name name val

Integer:10 a b Integer:3
25 / 45


Binary Expressions Rule

Computes = {Nil, Number}

L→NL
(3)
BinExp(lhs=L,bop=O,rhs=R)→BinExp(lhs=NL,bop=O,rhs=R)

R→NR
(4)
BinExp(lhs=L,bop=O,rhs=R)→BinExp(lhs=L,bop=O,rhs=NR)

26 / 45


Binary Expressions Rule

O∈Plus
(3)
BinExp(lhs=L,bop=O,rhs=R)→Number(val=(L.val+R.val))

O∈Minus
(4)
BinExp(lhs=L,bop=O,rhs=R)→Number(val=(L.val−R.val))

26 / 45


Rules for Seq commands

C0 → NC
(5)
Seq (c0 = C0, c1 = C1) → Seq (c0 = NC, c1 = C1)

Seq (c0 = C0 , c1 = C1) → C1 (6)

27 / 45


Imperative Language requires a Store

In order to evaluate both a Var and a Assignment we need a store.
A store is defined as a function
Definition
A function is defined as:

functionName : DomainClass → RangeClass

A function contains zero or more tuples k → v

{k1 → v1 , k2 → v2 , . . . , kn−1 → vn−1 , kn → vn }

28 / 45


Operations over Functions

Deﬁnition
Function invocation: If a is a function then a(k) equals:

,k → v ∈ a
v
a(k) =
Nil , k → v ∈ a
/

Deﬁnition
Override expression: If a and b are functions then a [b] equals:

, k → vb ∈ b
vb
a [b] (k) =
, k → va ∈ ab
va

29 / 45


Including Stores in SemLang

A state is now a tuple M, F where:
M is the current model
1

F is a set of functions
2

The functions in F represent the store
Rules can read and update functions in F
t‘
The transition relation t −→ t“ is extended:
Function invocations are allowed in the terms t, t‘ and t“
1

The label t‘ can now contain function assignments
2

Function assignment format
storeName ′ =<functionexpression>
t − − − − − − − − − − → t“
−−−−−−−−−−

30 / 45


Store deﬁnition and rules

store : String → Number (7)

Var (name = N) → store (N) (8)

E → NE
(9)
Assign (name = N, e = E) → Assign (name = N, e = NE)

store ′ =store[{N→E }]
Assign (name = N, e = E ) − − − − − − − Nil
− − − − − −→ (10)

31 / 45


Simulation

Model Simulation
Simulating the model using the tool: Semantic Engine

32 / 45


First Transition: Proof

C0 → NC

33 / 45



Assign (name = N, e = E ) − − − − − − − Nil
− − − − − −→

33 / 45



Assign (”a” = N, Number(val = 10) = E ) − − − − − − − Nil
− − − − − −→

33 / 45



Assign (”a” = N, Number(val = 10) = E )
store ′ =store[{”a”→Number(val=10)}]
− − − − − − − − − − − − Nil
− − − − − − − − − − −→
33 / 45



store ′ =∅[{”a”→Number(val=10)}]
− − − − − − − − − − − Nil
− − − − − − − − − −→
33 / 45



store ′ ={”a”→Number(val=10)}
− − − − − − − − − − Nil
− − − − − − − − −→
33 / 45



− − − − − − − − − − Nil
− − − − − − − − −→
Seq (c0 = C0, c1 = C1) → Seq (c0 = Nil, c1 = C1)
33 / 45



Seq (c0 = C0, c1 = C1)
−− − − − − − − − −
− − − − − − − − −→
Seq (c0 = Nil, c1 = C1)

33 / 45


Activity Diagram Lang: MetaModel

34 / 45


Activity Diagram Lang: Example Model

35 / 45


Activity Diagram Lang: Example Model
Diagram

nodes

StartNode
nodes

next name nodes

VarDec a
nodes nodes

e name varName next

Number b a Test

value next name e next alternative

StopNode Integer:1 test BinaryExp Assign

name lhs rhs bop e name varName

end Var Number Eq BinaryExp c a

name value rhs lhs bop

a Integer:5 Number Var Plus

value name

Integer:1 a

35 / 45


Activity Diagram Lang: Rules

Computes = {StopNode, Number, Bool} (11)

store : String → Object (12)

Diagram (nodes = NS ∃n ∈ StartNode ) → n (13)

StartNode (next = N) → N (14)

36 / 45


Activity Diagram Lang: Test Rules

C → NC
Test (name = N, e = C, next = NN, alternative = A)
→ Test (name = N, e = NC, next = NN, alternative = A)
(15)

C .value
Test (name = N, e = C , next = NN, alternative = A) → NN
(16)

¬C .value
Test (name = N, e = C , next = NN, alternative = A) → A
(17)

37 / 45


Activity Diagram Lang: VarDec

E → NE
(18)
VarDec (name = N, varName = VN, e = E, next = NN)
→ VarDec (name = N, name = VN, e = NE, next = NN)

VarDec (name = N, varName = VN, e = E , next = NN)
store ′ =storeρ [{VN→E }]
− − − − − − − → NN
−−−−−−− (19)

38 / 45


Activity Diagram Lang: Assign Rules

E → NE
Assign (name = N, varName = VN, e = E, next = NN)
→ Assign (name = N, varName = VN, e = NE, next = NN)
(20)

Assign (name = N, varName = VN, e = E , next = NN)
store ′ =storeρ [{VN→E }]
− − − − − − − → NN
−−−−−−− (21)

39 / 45


Simulation

Model Simulation
Simulating the model using the tool: Semantic Engine

40 / 45


Outline

Semantics
1

2

3

4

Conclusions
5

41 / 45


Conclusions

SOS can be applied to MDE!
With some adjustments
Proof of concept
Tool support for simulation
Future Research
Extend SemLang
Extend tool support
Model checking
Compiler Interpreter generation

42 / 45


Diﬀerences with Graph Transformations
Graph Transformations SemLang

Multiple rule for a transition
Single rule for a transition
Rule matching easy
Rule matching hard:
Theoretic basis work in
NP-complete
progress
Sound theoretic basis
Limited Expressiveness
Expressive
(future research)
Better graph awareness
Locally tree oriented
Less use of metamodel
Uses metamodel knowledge
Not easy to map to
Related to interpreter design
interpreters
pattern
Modularity may be
MSOS aimed at modularity
problematic
(future research)
43 / 45


Any Questions?

44 / 45


References I

D. Harel and B. Rumpe. Semantic of semantics Springer LNCS,
2004.
Peter D. Mosses. Formal semantics of programming languages,
an overview. Electronic Notes in Theoretical Computer Science
148, pages 41–73, 2006.
Gordon D. Plotkin. A structural approach to operational
semantics. Technical report, University of Aarhus, Denmark, 1981.
Peter D. Mosses. Modular structural operational semantics.
Journal of Logic and Algebraic Programming 60-61, pages 195–228,
2004.

45 / 45

Applying SOS to MDE

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (9)

Destaque

Destaque (11)

Semelhante a Applying SOS to MDE

Semelhante a Applying SOS to MDE (20)

Último

Último (20)

Applying SOS to MDE