Semantic Anchoring January 30, 2008 Matt McGill Semantic Anchoring at a Glance... • Problem: Formally specifying the behavioral semantics of DSMLs from scratch is costly • Cost is only justified for domains with many users • Users working in narrow domains are unsupported • Proposed solution: Give new DSMLs a translational specification with respect to semantic units. • A semantic unit (SU) is a formal modeling language with pre-defined semantics • Reliance on SU specification simplifies creation of new DSMLs • Validation • Defined semantics of IF, UPPAAL and Kronos languages in terms of Timed Automata Semantic Unit (TASU) • Defined a reusable HFSM semantic unit Presentation Overview Motivation and applicability • Benefits of DSMEs/DSMLs • Obstacles to widespread use • Objectives of Semantic Anchoring • Applicability to this course Preliminaries Semantic anchoring in depth Evaluation (there will be a quiz...) DSMLs and DSMEs... bring the solution space closer to the problem space save time and money through automation reduce “accidental complexity” manage “inherent complexity” lower production costs and development time Benefits of DSMLs/DSMEs (Simulink) Obstacles to DSMLs/DSMEs DSMLs and DSMEs... are (by definition) domain-specific are themselves very costly to build are only available in domains with many users (VHDL) Semantic Anchoring Objectives Reduce the cost of developing DSMLs with precise, formally defined semantics Enable formal analysis capabilities for DSMLs Bring DSMLs and DSMEs to previously excluded domains Highlight the semantic differences between similar DSMLs
Transcript
Semantic Anchoring
January 30, 2008Matt McGill
Semantic Anchoring at a Glance...
• Problem: Formally specifying the behavioral semantics of DSMLs from scratch is costly
• Cost is only justified for domains with many users
• Users working in narrow domains are unsupported
• Proposed solution: Give new DSMLs a translational specification with respect to semantic units.
• A semantic unit (SU) is a formal modeling language with pre-defined semantics
• Reliance on SU specification simplifies creation of new DSMLs
• Validation
• Defined semantics of IF, UPPAAL and Kronos languages in terms of Timed Automata Semantic Unit (TASU)
• Defined a reusable HFSM semantic unit
Presentation Overview
Motivation and applicability• Benefits of DSMEs/DSMLs
• Obstacles to widespread use
• Objectives of Semantic Anchoring
• Applicability to this course
Preliminaries
Semantic anchoring in depth
Evaluation (there will be a quiz...)
DSMLs and DSMEs...bring the solution space closer to the problem space
save time and money through automation
reduce “accidental complexity”
manage “inherent complexity”
lower production costs and development time
Benefits of DSMLs/DSMEs
(Simulink)
Obstacles to DSMLs/DSMEs
DSMLs and DSMEs...are (by definition) domain-specific
are themselves very costly to build
are only available in domains with many users
(VHDL)
Semantic Anchoring Objectives
Reduce the cost of developing DSMLs with precise, formally defined semantics
Enable formal analysis capabilities for DSMLs
Bring DSMLs and DSMEs to previously excluded domains
Highlight the semantic differences between similar DSMLs
Applicability
DSMLs are developed in a model-driven fashion
DSMLs are themselves used in MDE
Technique enables the (cost-effective) creation of analyzable DSMLs for use in High-Assurance Systems
Presentation Overview
Motivation and applicability
Preliminaries• Review: Specifying traditional programming languages
• Modeling and meta-modeling
• The Generic Modeling Environment (GME)
Semantic anchoring in depth
Evaluation
Programming LanguagesHow are programming languages specified?
Syntax: What do programs look like?• Concrete syntax deals with parsing of actual program sentences such as
lexical issues, operator precedence, etc.
• Abstract syntax represents the structure of programs while abstracting away details about the actual parsing
• Both often specified in some form of BNF notation
Semantics: What does a program mean?• Many ways of specifying the meanings of programs, from informal to
rigorously formal
• Translational semantics: rules for translating programs into some other language
Program(P) => Model(P)• A computer program is a model
!(Model(P) => Program(P))• A model is not necessarily a program
That’s why we like models!
The Four-Layer Architecture
define
Runtime executions
Programs Models
define
Instances
define
Grammars
defines
EBNF
define
Meta-meta-models
What about concrete syntax?
Meta-models
define
(abstract syntax)
M3
M2
M1
M0
An Example
Instance Model
An ExampleModel Meta-model
An Example
Meta-model Meta-meta-model
An Example
Meta-meta-model Meta-meta-model
The GME
A truly generic modeling environment
GME must be configured with a Paradigm (essentially, information about the abstract and concrete syntax of a DSML)
GME publishes an API, can be extended with interpreters, etc.
The meta-modeling paradigm is just another DSML (used to model DSMLs)
Presentation Overview
Motivation and applicability
Preliminaries
Semantic anchoring in depth• Specifying Semantic Units
• Specifying DSMLs
• Modeling and analysis
Preliminary evaluation
Bird’s Eye View - 3 Parts
1. Semantic Unit definition• Describe configurations with meta-model
• Specify behavior with Abstract State Machine
2. DSML specification• Describe DSML with meta-model
• Define rules for translating a model into a configuration of the semantic unit
3. Modeling and analysis• Construct models in DSML
• Use translator to produce ASMs for analysis
Running example: GREGEXP
• A graphical DSML for simple regular expressions, anchored to a finite-state automata semantic unit
• Regexps are built from nodes and links
• Each Nodes contain a letter (except the start node)
• Node cardinalities:
Match oneMatch oneor more
Match zeroor more
Semantic Units (SUs)
• Self-contained, formally specified DSMLs that can be re-used in the specification of other DSMLs
• 3 parts1. Meta-model (abstract/concrete syntax)
2. Behavioral specification (Abstract State Machine template)
3. Model ! ASM translator
SU meta-model
• Created with GME meta-modeling paradigm
• Needs to be mapped to Abstract State Machine template (more on this in a bit)
• May or may not need a concrete (i.e. graphical) syntax
FSA meta-model
• Domain concepts: states, transitions, and assertions about accepted (or not accepted) strings
StateAccepting
statePositive
assertionNegativeassertion
FSA meta-model
FSA example model Specifying behavior with ASMs
AsmL: Microsoft’s implementation of Abstract State Machines
• Formal language for specifying algorithms
• Operational in nature
• Program state is represented with well-defined mathematical structures (Sets, Integers, etc.)
• Designed to look like pseudocode
• SpecExplorer can be used to run simulations, explore the state space
Really simple AsmL example
var i as Integer = 0
Add(x as Integer) require (i+x<5) i := i + x
Sub(x as Integer) require (i-x >= 0) i := i - x
Really simple AsmL Example
An AsmL template for FSA
type State = Integer
type Label = String
const R as Set of (State, Label, State) = {... }
const A as Set of State = {... }
var a as State = 0
procedure NextState(i as Label)
require (exists (s, l, _) in R where s=a and l=i)
choose unique (s, l, s') in R where s=a and l=i
a := s'
Instantiating our model
• SU developer would implement translator that instantiates AsmL template from SU model
type State = Integertype Label = String
const R as Set of (State, Label, State) = { (0, "a", 1), (1, "b", 1), (1, "a", 2)}const A as Set of State = {1, 2 }
var a as State = 0
procedure NextState(i as Label) require (exists (s, l, _) in R where s=a and l=i) choose unique (s, l, s') in R where s=a and l=i a := s'
Bird’s Eye View - 3 Parts
Semantic Unit definition• Describe configurations with meta-model
• Specify behavior with Abstract State Machine
2. DSML specification• Describe DSML with meta-model
• Define rules for translating a model into a configuration of the semantic unit
3. Modeling and analysis• Construct models in DSML
• Use translator to produce ASMs for analysis
A quick review: GREGEXP
• A graphical DSML for simple regular expressions, anchored to a finite-state automata semantic unit
• Regexps are built from nodes and links
• Each Nodes contain a letter (except the start node)
• Node cardinalities:
Match oneMatch oneor more
Match zeroor more
Gregexp meta-model Anchoring the DSML to a SU
• DSMLs are “anchored” to SUs via model transformation
• Transformations are specified in GReAT, another GME-based DSML
• Transformation rules are pattern-based, patterns refer to source and target meta-models
• Basic actions: Create, Bind, Delete
Returning to the House DSML GReAT Transformations
• Transformations may be run by an interpreter inside GME
• Transformations may also be compiled into C++ code, and loaded as plug-ins
Bird’s Eye View - 3 Parts
Semantic Unit definition• Describe configurations with meta-model
• Specify behavior with Abstract State Machine
DSML specification• Describe DSML with meta-model
• Define rules for translating a model into a configuration of the semantic unit
3. Modeling and analysis• Construct models in DSML
• Use translator to produce ASMs for analysis
Modeling and Analysis
• User creates models in the DSML using the GME
• User generates AsmL specifications from the models using the semantic anchoring transformation
• User analyses AsmL specification, runs simulations
• SpecExplorer can also be used for automated testing and automatic test case generation
Modeling and Analysis
• Note: The papers I have read do not describe in detail the types of analysis and testing a user might perform
Analyzing a model
Semanticanchoring
transformation
type State = Integertype Label = String
const R as Set of (State, Label, State) = { (0, "a", 1), (1, "b", 1), (1, "a", 2)}const A as Set of State = {1 }
var a as State = 0
procedure NextState(i as Label) require (exists (s, l, _) in R where s=a and l=i) choose unique (s, l, s') in R where s=a and l=i a := s'
SU translation
Analyzing a model
• SpecExplorer appears to be a powerful tool, but it’s also poorly documented
• I’ve got more “archeology” to do before I can check properties...
Analyzing a model
• ...But at least our state space is right.
type State = Integertype Label = String
const R as Set of (State, Label, State) = { (0, "a", 1), (1, "b", 1), (1, "a", 2)}const A as Set of State = {1}
var a as State = 0
procedure NextState(i as Label) require (exists (s, l, _) in R where s=a and l=i) choose unique (s, l, s') in R where s=a and l=i
Presentation Overview
Motivation and applicability
Preliminaries
Semantic anchoring in depth
Initial evaluation
Preliminary Evaluation
Your thoughts?
My reaction
This approach to specifying semantics is feasible
At the moment, this particular tool-chain makes it complicated
Major drawback: Where’s the “round-trip engineering”?• Can a DSML user really be expected to check properties in a twice-
translated version of her model?
• The unidirectional nature of the model transformations poses a significant problem, but there are languages for specifying bidirectional transformations
