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

Part I

Basic Model Integrated Computing

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

Demo

Part II

Selected Research Directions

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

“Standard” representation

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

Part III

Brief Discussion of Applying MIC to Signal

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

Questions

Thank You