Institute For Software Integrated Systems Vanderbilt University Applications

Institute For Software Integrated Systems Vanderbilt University Applications of Model Integrated Computing to The 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

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 a b d = a+b+c ? b=d–a–c Discrete Event Interpretation d c 3 4 7 1 4 §Well-formedness rules capture properties of all the desired models and are properties that hold for all of the targeted interpretations 2 ? CMOS Interpretation • • ? Area Capacitance Resistance Transients

Modeling Languages § A modeling language is the 5 -tuple: § A model is a well-formed instance of the abstract syntax n 1 n 2 n 3

Abstract and Concrete Syntax § Notice that the abstract syntax is the concrete syntax of some other language Instance of § 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

Traditional Approach: UML § A single universal modeling language where all modeling is done in the concrete syntax of UML. ? Expressive enough for all modeling needs § 12 standard diagram types Structural Diagrams • Class • Object • Component • Deployment Behavioral Diagrams • Use-case • Activity • Sequence • Collaboration • Statechart Model Management Diagrams • Packages • Subsystems • Models

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. Meta-Metamodel Meta-circular Well-formed instance DS Metamodel Well-formed instance DS Model Interpretation of Model

Four Level Hierarchy MIC uses a four level hierarchy and a set valuedsemantics to specify domain specific modeling languages. M 3: Self-describing Meta-Metamodel MMM M 2: Metamodel describes domain concepts MMM MM M 1: Model instantiates domain concepts MMM MM M Model + Data M 0: Assignment of model data MMM MM M

Meta. GME § 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 Meta. GME Paradigm, partial interpreter generators (BON, MON, UDM, Java BON), model transformers (UDM, GREAT)

Interpreter Generation § GME exports a COM interface and there are several metainterpreters that can be used to generate an interpreter skeleton from a metamodel: MON, BON, Java BON Get. First. Atom(); Get. Next. Atom (); GME Custom Interpreter GME UDM Interpreter § UDM dynamically loads a metamodel and can build, modify models in memory, and read from/write to various repositories.

Interpretation as Graph Transformations § The Graph Rewriting And Transformation (GRe. AT) language is language for translating between metamodels. GRe. AT metamodel GRe. AT interpreter Source Model transformer § A formal way to describe interpreters Target Model

Demo

Part II Selected Research Directions

Library of Canonical Metamodels Meta-metamodel Metaa Metab Metamodel GRe. AT Semantic Mapping Semantic Domain Meta. FSM Meta. DE FSM DE … Meta. Signal

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 wellunderstood metamodel design patterns, or by specializing already existing metamodels. Semantic Mapping MMHierarchy SDHierarchy MMscoping Semantic Mapping MMDSML Mhierarchy SDhierarchy MDSML SDscoping 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; }

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 Cycle We 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 Debug Cycle 1. Consider intended behavior in semantic domain MMM Well-formed MM 2. Mentally map backward to a modified model of the system 3. Check well-formedness rules and map back into semantic domain Error Semantic Domain 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 Abstract Syntax A property is accessible iff: Well-formedness Rules 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. Computable Properties Semantic Domain

Simple Example Consider the well-formedness rules: 1) Length of state name < 40 2) 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 Data Aspect Storage Aspect Data Is enough? Storage Issues § Consider the generative constraint that every data element causes the production of a memory element in the storage aspect. Storage Aspect Data Aspect Is enough? Data Issues Is enough? Storage Issues

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. Passing constant parameters Binding subprocess result to local Passing result up hierarchy Sub-process invocation with local Sub-process invocation Instantiating parameters Can only check properties relating to hierarchy and interconnects

Two Orthogonal Aspects § The structure aspect shows all AS having to do with program structure. Equations like this are stored in § the model, but the static semantics does not give them any meaning during design time. start : = true when go default start$ 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 Current Work § Developing new abstract syntax and operational semantics that may have behavioral accessible properties § Tool set: Tiny. Modes, Sig. Verify, Sig. Gen, u. Mode. Charts

Questions Thank You