1. Institute For Software Integrated Systems Vanderbilt University Applications of Model Integrated Computing to The Synchronous Language Signal Ethan Jackson

2. Outline  Modeling  Metamodeling and the four-level hierarchy  Library of canonical metamodels  Metamodel patterns and composition  Accessible Properties  Short discussion of Signal

3. Part I Basic Model Integrated Computing

4. 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

5. Modeling Languages  A modeling language is the 5-tuple:  A model is a well-formed instance of the abstract syntax n1 n2 n3

6. 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

7. 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

8. 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 Model Interpretation of Model Meta-Metamodel Meta-circular

9. Four Level Hierarchy MIC uses a four level hierarchy and a set valued- semantics to specify domain specific modeling languages. Self-describing Meta-Metamodel Metamodel describes domain concepts Model instantiates domain concepts Assignment of model data MMM M3: M2: M1: M0: MMM MM MMM MM M MMM MM M Model + Data

10. 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.

11. Basic Tool Set  GME, the MetaGME Paradigm, partial interpreter generators (BON, MON, UDM, Java BON), model transformers (UDM, GREAT)

12. 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

13. 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 transformer Source Model Target Model

14. Demo

15. Part II Selected Research Directions

16. Library of Canonical Metamodels Meta-metamodel Metamodel Semantic Domain Semantic Mapping MetaFSM FSM MetaDE DE MetaSignal Signal … Meta a Meta b GReAT

17. 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

18. 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. MM Hierarchy SD Hierarchy Semantic Mapping MM scoping SD scoping Semantic Mapping MM DSML SD hierarchy M hierarchy M DSML M scoping SD DSML SD scoping

19. 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

20. 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; }

21. Bad Example “Standard” representation

22. 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.

23. 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 MMM MM Semantic Domain Error Well-formed 1. 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

24. 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 Rules Computable Properties Abstract Syntax Semantic Domain

25. 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

26. 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

27. 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 Issues Storage Issues Is enough? Data AspectStorage Aspect Data Issues Storage Issues Is enough? Data Aspect Is enough? Storage Aspect

28. Part III Brief Discussion of Applying MIC to Signal

29. 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

30. 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

31. 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

32. 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

33. Questions Thank You