1. A Generative Approach to Model Interpreter Evolution Jing Zhang, Jeff Gray, and Yuehua Lin {zhangj, gray, liny} @ cis.uab.edu Dept. of Computer & Information Sciences University of Alabama at Birmingham http://www.cis.uab.edu/softcom/ Funded by the DARPA Information Exploitation Office (DARPA/IXO), under the Program Composition for Embedded Systems (PCES) program

2. Evolution of models and interpreters in terms of meta-model changes ∆ MM : The changes made to the meta-models ∆ M : The changes reflected in the domain models ∆ I : The changes reflected in the model interpreters Interpreter 1 Model 1 Meta-model 1 Define Interpret Interpreter n Model n Meta-model n Define Interpret Interpreter 0 Model 0 Meta-model 0 Define Interpret ∆ M 1 ∆ MM 1 ∆ I 1 ∆ M 2 ∆ MM 2 ∆ I 2 ∆ M n ∆ MM n ∆ I n …… Based on

3. Example: Old/New Metamodel and model

4. Example: Old/New Interpreter CBuilderAtom *GetStartState( CBuilderModel *StateDiagram) { CBuilderAtom *startstate = null; const CBuilderAtomList *states = StateDiagram->GetAtoms("State"); POSITION pos=states->GetHeadPosition(); while(pos) { CBuilderAtom *st = states->GetNext(pos); CBuilderConnectionList *cons = st->GetInConnections("Transition"); if ( cons == null ) if ( startstate == null) startstate = st; else > } ASSERT ( startstate !=null ); return startstate; } CBuilderAtom *GetStartState( CBuilderModel *StateDiagram) { const CBuilderAtomList *startstates = StateDiagram->GetAtoms("StartState"); ASSERT(startstates->GetCount()==1); CBuilderAtom *startstate = startstates->GetHead(); return startstate; }

5. Technical Challenges Lack of formally-written model interpreter  Different developers may program interpreters in various ways  Hard to maintain and evolve such subjective realizations of model interpreters Lack of formal specification for metamodel transformation  Metamodel transformation specifications must include the entire knowledge for the underlying interpreter evolution  ∆ MM ∆ I Lack of support for parsing and invasively transforming program source code from higher-level models. Utilize a mature program transformation engine: The Design Maintenance System (DMS) ?

6. Model Interpreter Evolution Architecture (MIEA) void CComponent::InvokeEx(CBuilder &builder) { Interpreter aInterpreter; CString fileName; char *specFile=new char[fileName.GetLength()]; strcpy(specFile, fileName); …. } Interpreters’ void CComponent::InvokeEx(CBuilder &builder) { Interpreter aInterpreter; CString fileName; if(!aInterpreter.selectSpecAspects(fileName)) { return; } … } Interpreters Metamodel’Metamodel model Models Model Xform Engine Model Xform Specification Models’ model Modeling API’Modeling API

7. DMS rewriting rules for evolving intepreter(1) rule ChangeName (id:identifier): expression_statement -> expression_statement = "\id -> GetModels(\“State\");" -> "\id -> GetModels(\“StartState\");". Differences of names for any model entities, relationships and attributes

8. rule ChangeModelType (id:identifier): expression_statement -> expression_statement = “\id -> GetAtoms(\“State\”);” -> “\id -> GetModels(\“State\”);”. Differences of model types DMS rewriting rules for evolving intepreter(2)

9. rule ChangeAttrType (): declaration_statement -> declaration _statement = “CString State_Text;” -> “int State_Text;”. DMS rewriting rules for evolving intepreter(3) Differences of attribute types

10. Conclusion Ideal Goal:  Support the (semi)-automation of model interpreter evolution in terms of metamodel changes and modeling API changes Proposed Solution:  Model Interpreter Evolution Architecture Obstacles:  Informal model interpreter  Hard to maintain the fidelity mapping of high-level abstract models to the low-level source code  Possible solution approaches to be investigated:  Attach program rewriting rules to the existing model transformation specification  Develop a new high-level specification for model transformation that can generate the rewriting rules  Investigate an intelligent model comparison technique to generate the rules through human interactions