institute for software integrated systems vanderbilt university applications of model integrated...
Post on 20-Dec-2015
213 views
TRANSCRIPT
Institute For Software Integrated SystemsVanderbilt University
Applications ofModel Integrated Computing
toThe Synchronous Language Signal
Ethan Jackson
Outline
Modeling Metamodeling and the four-level
hierarchy Library of canonical metamodels Metamodel patterns and composition Accessible Properties Short discussion of Signal
a
b
c d
Models A model relates to an execution in the way an interface
relates to an implementation Models have are presented in some way, i.e. they have a
concrete syntax. They are stored, parsed, represented with an abstract syntax Mathematical Interpretation
d = a+b+c b = d – a – c
Discrete Event Interpretation
2
4
1
3 7 4
CMOS Interpretation• Area• Capacitance• Resistance• Transients
?
?
?
Well-formedness rules capture properties of all the desired models and are properties that hold for all of the targeted interpretations
Modeling Languages
A modeling language is the 5-tuple:
A model is a well-formed instance of the abstract syntax
n1
n2 n3
Abstract and Concrete Syntax
Notice that the abstract syntax is the concrete syntax of some other language
The concrete syntax used to describe the abstract syntax of FSMs comes from a language that is more expressive than the modeling language of FSMs.
Traditional modeling approaches take for granted the language in which they express their abstract syntax
Instance of
Traditional Approach: UML
A single universal modeling language where all modeling is done in the concrete syntax of UML.
12 standard diagram types
?
Expressive enough for all modeling needs
• Class • Object• Component• Deployment
• Use-case• Activity• Sequence• Collaboration• Statechart
• Packages• Subsystems• Models
Structural Diagrams Behavioral Diagrams Model Management Diagrams
MIC Approach: Metamodeling
Build modeling languages for specific domains. These languages contain only concepts needed for modeling in that domain.
Create these modeling languages in a formal way that exploits the “chain” of modeling languages.
Well-formed instance
DS Metamodel
Well-formed instance
DS ModelInterpretation
of Model
Meta-MetamodelMeta-circular
Four Level HierarchyMIC uses a four level hierarchy and a set valued-
semantics to specify domain specific modeling languages.
Self-describing Meta-Metamodel
Metamodel describes domainconcepts
Model instantiates domain concepts
Assignment of model data
MMMM3:
M2:
M1:
M0:
MMM MM
MMM MMM
MMM MMM
Model + Data
MetaGME
Concrete Syntax is UML class diagrams extended with stereotypes + object constraint language (OCL)
Stereotypes extend UML notation in an acceptable manner while affixing concrete syntax information.
Basic Tool Set GME, the MetaGME Paradigm, partial interpreter
generators (BON, MON, UDM, Java BON), model transformers (UDM, GREAT)
Interpreter Generation GME exports a COM interface and there are several
meta-interpreters that can be used to generate an interpreter skeleton from a metamodel: MON, BON, Java BON
UDM dynamically loads a metamodel and can build, modify models in memory, and read from/write to various repositories.
GME Custom Interpreter
GetFirstAtom();GetNextAtom ();
GME UDM Interpreter
Interpretation as Graph Transformations
The Graph Rewriting And Transformation (GReAT) language is language for translating between metamodels.
A formal way to describe interpreters
GReAT metamodel
GReAT model
GReAT interpreter
transformerSource Model
Target Model
Library of Canonical Metamodels
Meta-metamodel
Metamodel
Semantic Domain
Semantic Mapping
MetaFSM
FSM
MetaDE
DE
MetaSignal
Signal
…
Metaa Metab
GReAT GReAT
Library of Canonical Metamodels
• These metamodels along with their semantic mappings become standard semantic units.
• The interface to these semantic units, a transformation of metamodels, is grounded in the MIC methodology.
• Used when a DSML has an interpretation in a standard semantic unit, but is not naturally represented with the concepts of that unit.
Example: Boldstroke to Timed-Automata
Metamodel Design Patterns and Composition
Mapping to canonical metamodels is one approach to utilize an already existing semantic domain. However, one may wish to build DSMLs by composing well-understood metamodel design patterns, or by specializing already existing metamodels.
MMHierarchy
SDHierarchy
Semantic Mapping MMscoping
SDscoping
Semantic Mapping
MMDSML
SDhierarchy
Mhierarchy MDSML Mscoping
SDDSML SDscoping
Metamodel Design Patterns and Composition
• Build standard metamodel patterns that come with a semantic mapping
• Create new metamodels by composing existing design patterns with specialization, class equivalence, package import
• Guarantee that if this composition adheres to certain rules, then the semantic mappings of the constituent metamodels can be reused.
• Used when DSML directly instantiates standard concepts in the abstract syntax
Example: Add hierarchy to a FSM
Important Points
A “good” metamodel (abstract syntax) is important for a canonical metamodel because the metamodel is an essential part of the interface to the semantic unit.
int statevar = 0;
switch (statevar) {
case 0:
…
statevar = 1;
case 1:
…
statevar = 2;
case 2:
…
statevar = 0;
}
int statevar = 0;
switch (statevar) {
case 0:
…
statevar = 1;
case 1:
…
statevar = 2;
case 2:
…
statevar = 0;
}
Bad Example
Translation from this DSML to an executable model is trivial, however this metamodel seems to “muddle” key aspects of the FSM semantic domain. Consider:
• What is the start state?• What is the topology of the FSM• Is there are directed path between two states?
These issues of abstract syntax design are only magnified when creating metamodel design patterns: Reuse of a poor design pattern will only perpetuate poor metamodel designs.
Development CycleWe need a definition that articulates the important properties of an abstract syntax.This definition follows naturally if one considers the hard part of model development
MMM MM
Semantic Domain
Error
Well-formed1. Consider intended
behavior in semantic domain
2. Mentally map backward to a modified model of the system
3. Check well-formedness rules and map back into semantic domain
Debug Cycle
Need to be able to correlate well-formedness rules to semantic properties
Accessible Properties
An accessible property allows a modeler to formally reason about semantic issues with out interpretation
A property is accessible iff:
for every well-formed model that has an error in property p, a semantically equivalent model can be found where that model is not well-formed.
Well-formedness RulesWell-formedness Rules
Computable PropertiesComputable Properties
Abstract Syntax
Semantic Domain
Simple Example
Consider the well-formedness rules:1) Length of state name < 402) There must be a start state
Rule 1 is an idiosyncrasy of the abstract syntax while Rule 2 is a property of FSM semantic domains
Multiple Aspect Modeling
Claim: An abstract syntax should be designed carefully so that accessible properties exist
Then a multiple aspect approach so not just partition abstract syntax, but should simultaneously partition accessible properties
Claim: A multiple aspect approach modularizes reasoning about the system
Bad Aspects
These are bad aspects because an important accessible property is not modularized w.r.t the aspects
Consider the generative constraint that every data element causes the production of a memory element in the storage aspect.
Data IssuesData
IssuesStorage Issues
Storage Issues
Is enough?
Data Aspect Storage Aspect
Data IssuesData
IssuesStorage Issues
Storage Issues
Is enough?
Data Aspect
Is enough?
Storage Aspect
Application of MIC to Signal
Signal has already been described as a DSML in GME with an interpreter for generating Signal code.
Binding sub-process result to local
Sub-process invocation
Passing result up hierarchy
Sub-process invocation with local
Passing constant parameters
Instantiating parameters
Can only check properties relating to hierarchy and interconnects
Two Orthogonal Aspects
start := true when go default start$
start := true when go default start$
Equations like this are stored in the model, but the static semantics does not give them any meaning during design time.
The structure aspect shows all AS having to do with program structure.
The implementation aspect shows the equations that implement the process
Interpretation is Easy
Interpretation is an simple DFS traversal of the model that collects all of the equations and process interface definitions
Interpretation is done on an AST build from these nodes
Problems
The concepts contained in the dataflow equations are not modeled, hence no accessible properties for program behavior
Not a suitable abstract syntax for a canonical metamodel; metamodel translation equivalent to generating Signal code
Does not capture behavioral concepts that could be used as metamodel design patterns
Developing new abstract syntax and operational semantics that may have behavioral accessible properties
Tool set: TinyModes, SigVerify, SigGen, uModeCharts
Current Work