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

Evolution of models and interpreters in terms of meta-model changes Define Interpret Interpretern Modeln Meta-modeln Interpreter0 Model0 Meta-model0 ∆M 1 ∆MM 1 ∆I 1 ∆M 2 ∆MM 2 ∆I 2 ∆M n ∆MM n ∆I n …… Based on ∆MM: The changes made to the meta-models ∆M: The changes reflected in the domain models ∆I: The changes reflected in the model interpreters

Example: Old/New Metamodel and model

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 <<ERROR: more than one state has no InConnections>> } 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; }

Technical Challenges ∆MM ∆I 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)

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

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

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

DMS rewriting rules for evolving intepreter(3) Differences of attribute types Problems: 2 ways: comparison to infer the rules or attach them to model transformation specifications rule ChangeAttrType (): declaration_statement -> declaration _statement = “CString Text;” -> “int Text;”.

Conclusion Ideal Goal: Proposed Solution: Obstacles: 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

Thank You !! Questions ??