An Examination of DSLs for Concisely Representing Model Traversals and Transformations

1
An Examination of DSLs for Concisely
Representing Model Traversals and Transformations

• Jeff Gray
• University of Alabama at Birmingham
• Gábor Karsai
• Vanderbilt University/ISIS
• HICSS-36

• This work is supported by the DARPA IXO, under
  the Program Composition forEmbedded Systems
  (PCES) program, Contract Number F33615-00-C-1695
• Support for this project was also provided by
  Boeing.

2
Overview

• Three DSLs in two different applications
• Applications Tool integration and
  aspect-oriented domain modeling (AODM)
• Focus of DSLs
• Generation of complex data structures from
  high-level specifications
• Synthesis of iterative processes
• Generation of API wrappers from high-level specs
• Quantitative description of generated code

3
Tool Integration
4
Tool Integration
Tool-X
Tool-Y
LRU
MM
LRU
VAR
FR
FDE
MSG
UNIT
OBS
ALR
Integrated Model
5
Integrated Model Server (IMS)
AEFR
FMECA
ADO
Excel (csv)
Text
ADO
IMS
RELEX
ADVISE
CORBA
COM
Browser
GME
6
Tool Integration Framework (TIF)
Legacy tools require a bi-directional tool adapter
IMS models can be viewed in a web browser
New tools can access the IMS directly through
the CMI
CORBA
The CMI is specified in CORBA IDL and defines
rules and data structures for accessing the IMS
MS Repository sits on top of an ODBC database
currently Access or SQL Server
7
Tool Integration Framework (TIF)
Legacy tools require a bi-directional tool adapter
IMS models can be viewed in a web browser
Focus of this portion of the talk
New tools can access the IMS directly through
the CMI
DSLs for representing model translation as
traversal/visitor specifications
DSLs for representing tool models as stored in
the CMI
CORBA
The CMI is specified in CORBA IDL and defines
rules and data structures for accessing the IMS
8
Pieces of the Translation

• Structure of the models Objects to be traversed
• What are the possible paths for traversals?
• Traversal sequences How to traverse?
• What are the desired paths for traversals?
• Visitors Actions to be taken
• What to do?
• Phases of processing
• Multiple passes over the structure

9
Tool Specification (Structure)

• paradigm Foo
• model Top_Model
• ...
• part Component components
• model Component
• ...
• part Entity_1 ent_1
• part Entity_2 ent_2
• part Component subComponents
• rel Rel aRel
• entity Entity_1 ...
• entity Entity_2 ...
• relation Rel
• Entity_1 src 1lt-gtEntity_2 dst

10
Generation of Data Structures
paradigm RELEX model RELEX_Model attr
string Name part RELEX_Object objects
part Failure_Mode failure_Modes rel
RELEX_Failure_Mode rel_FM entity RELEX_Object
attr string Name attr string
Part_Number attr string User_Text attr
string Reference attr double
Failure_Rate entity Failure_Mode attr
string Failure_Mode attr string
Local_Effects attr string Next_Effects
attr string End_Effects attr string
Failure_Detection_Method attr long
Mode_Severity_Code attr double
Failure_Mode_Ratio attr double
Failure_Effect_Probability attr double
Failure_Rate relation RELEX_Failure_Mode
RELEX_Object Owner 1 lt-gt Failure_Mode
Failures
int RELEX_Model_Mget_objects(vectorltRELEX_Obj
ect_Egt _res) int count 0 MetaEntity
type MetaDataLookupEntity("RELEX","RELEX_Objec
t") vectorltInstEntitygtiterator itr
vectorltInstEntitygt list obj-gtparts()
for(itr list-gtbegin() itr ! list-gtend()
itr) if((itr)-gttype() type)
_res.push_back(RELEX_Object_E(itr)) count
return count
11
Structured Specification of Translators(Traversal
/Visitor)

• visitor Visitor
• at Component...
• ltlt...gtgt traverse...
• at Entity_1...
• ltlt...gtgt
• at Entity_2...
• ltlt...gtgt
• at Rel...
• traverse...

• traversal Traversal using Visitor
• from Top_Model -gt
• ltlt...gtgt to components... ltlt...gtgt
• from Component...
• to entity_1..., entity_2...,
• subComponents..., rel...
• from Rel...
• ltlt...gtgt to src..., dst... ltlt...gtgt

12
Generation of Traversal/Visitors
void Traversal_Ttraverse(GME_4_0Component_M
self,
IMSComponent_M parent)
vectorltGME_4_0FailureMode_Egt _lst
self.get_failureModes(_lst)
vectorltGME_4_0FailureMode_Egtiterator _itr
for(_itr _lst.begin() _itr ! _lst.end()
_itr) GME_4_0FailureMode_E
argGME_4_0FailureMode_E(_itr)
vis-gtvisit(arg,parent,fMap)
vectorltGME_4_0Discrepancy_Egt _lst
self.get_discrepancies(_lst)
vectorltGME_4_0Discrepancy_Egtiterator _itr
for(_itr _lst.begin() _itr ! _lst.end()
_itr) GME_4_0Discrepancy_E
argGME_4_0Discrepancy_E(_itr)
vis-gtvisit(arg,parent,dMap)
vectorltGME_4_0Monitor_Egt _lst
self.get_monitors(_lst) vectorltGME_4_0Monit
or_Egtiterator _itr for(_itr
_lst.begin() _itr ! _lst.end() _itr)
GME_4_0Monitor_E arg GME_4_0Monitor_E(_itr)
vis-gtvisit(arg,parent,mMap)
vectorltGME_4_0Fault_Report_Egt _lst
self.get_faultReports(_lst)
vectorltGME_4_0Fault_Report_Egtiterator _itr
for(_itr _lst.begin() _itr ! _lst.end()
_itr) GME_4_0Fault_Report_E
argGME_4_0Fault_Report_E(_itr)
vis-gtvisit(arg,parent)
vectorltGME_4_0Component_Mgt _lst
self.get_subComponents(_lst)
vectorltGME_4_0Component_Mgtiterator _itr
for(_itr _lst.begin() _itr ! _lst.end()
_itr) GME_4_0Component_M arg
GME_4_0Component_M(_itr)
vis-gtvisit(arg,parent,pcMap)
vectorltGME_4_0FMMonitor_Rgt _lst
self.get_fmMonitor(_lst) vectorltGME_4_0FMMo
nitor_Rgtiterator _itr for(_itr
_lst.begin() _itr ! _lst.end() _itr)
GME_4_0FMMonitor_R arg GME_4_0FMMonitor_R(_
itr) vis-gtvisit(arg,parent,fMap,mMap)
vectorltGME_4_0FMDiscrepancy_Rgt _lst
self.get_fmDiscrepancy(_lst)
vectorltGME_4_0FMDiscrepancy_Rgtiterator _itr
for(_itr _lst.begin() _itr ! _lst.end()
_itr) GME_4_0FMDiscrepancy_R
argGME_4_0FMDiscrepancy_R(_itr)
vis-gtvisit(arg,parent,fMap,dMap)
from ComponentIMSComponent_M parent
to failureModesparent,fMap,
discrepanciesparent,dMap,
monitorsparent,mMap,
faultReportsparent,
subComponentsparent,pcMap,
fmMonitorparent,fMap,mMap,
fmDiscrepancyparent,fMap,dMap
13
Achieved Goals - Tool Integration

• Using a DSL, the underlying CORBA data structures
  and service calls that are needed to perform the
  model integration are hidden.
• Using a DSL, the often tedious and repetitive
  code fragments that are needed for iteration and
  transformation can be more concisely/intuitively
  specified.
• Separation of concerns
• Cleaner solution by separating semantic
  (translator) and syntactic (adapter) issues

14
Aspect-OrientedDomain Modeling

• Please see October 2001 issue of Communications
  of the ACM

15
Model-Integrated Computing (MIC) with the Generic
Modeling Environment (GME)

• Generic Modeling Environment (GME) is a
  domain-specific modeling tool
• Grew out of over 14 years of research on
  computer-based systems in aerospace,
  instrumentation, manufacturing and robotics.
• It can be utilized in many different domains by
  providing a meta-level paradigm description.
  Paradigm describes all of the entities of the
  domain, as well as valid relationships
• A modeler first loads the domain paradigm and
  then constructs new models in that domain

Please see November 2001 issue of IEEE Computer
Available for download at http//www.isis.vanderbi
lt.edu
16
Difficulties in Managing Constraints
Change Maintenance???
Multiple Levels of Hierarchy
A
4
Replicated Structures
3
B
F
1
2
c
d
e
3'
B
B
4
1''
2''
1'
2'
c
d
e
c
d
e
Context Sensitive
17
Process of Using a Model Weaver
18
Quantification Over Base Code (AOP)

• Weavers instrument code with advice

after(Object o) throwing (Error e) pubIntf(o)
log.write(o, e)
pointcut pubIntf(Object o) call(public
com.borland..(..)) target(o)
19
Quantification Over a Domain Model (AODM)

• Apply AO Weaving concepts to Model-based systems
• Weavers Decorate Models with attributes
  constraints
• Weavers compose new model constructs

Strategy1 Strategy2 Strategy3 StrategyN
select(p p.name() Model
p.kind() StateFlow)-gtStrategy3()
20
The Metaweaver Framework
Specification Aspects
XML Parser
Strategies (C)
Aspect Parser
XML (Model Hierarchy)
Strategy Specifications
Strategy Code Generator
strategy ApplyConstraint(constraintName string,
expression string) addAtom("OCLConstraint",
"Constraint", constraintName).addAttribute("Expres
sion", expression)   strategy
RemoveConstraint(constraintName string)
findAtom(constraintName).removeChild()   strate
gy ReplaceConstraint(constraintName string,
expression string) RemoveConstraint(constrai
ntName) ApplyConstraint(constraintName,
expression)
21
Embedded Constraint Language
Included OCL Operators
22
Embedded Constraint Language (ECL)

• Traditional OCL has been strictly a declarative
  query language
• New uses require an imperative procedural style
• Addition of side effects into model
• Examples
• addAtom(), findAtom()
• addAttribute(), findAttribute()
• removeNode()
• Support for recursion
• Chaining of strategies (procedure calls)
• Inlined C code

23
Generation of ECL
components.models("")-gtselect(c c.id()
refID)-gtDetermineLaziness()
CComPtrltIXMLDOMNodeListgt modsXMLParsermodels(co
mponents,"") nodeTypeVector selectVec1
XMLParserConvertDomList(mods) nodeTypeVector
selectVecTrue1 new stdvectorltnodeTypegt vector
ltnodeTypegtiterator itrSelect1 for(itrSelect1
selectVec1-gtbegin() itrSelect1 !
selectVec1-gtend() itrSelect1)
nodeType selectNode1 (itrSelect1)
nodeType c c selectNode1 CComBSTR id0
XMLParserid(c) ClData varforward1(id0)
ClData varforward2(refID) bool varforward3
varforward1 varforward2 if(varforward3)
selectVecTrue1-gtpush_back(itrSelect1)
vectorltnodeTypegtiterator itrCollCall1 for(itr
CollCall1 selectVecTrue1-gtbegin() itrCollCall1
! selectVecTrue1-gtend() itrCollCall1)
DetermineLazinessapply()
24
Achieved Goals - AODM

• Using a DSL, the modeler is shielded from the
  details of the core XML Document Object Model
  (DOM) API calls.
• Using a DSL, the specification of the navigation
  within the domain models (while performing
  transformations) is raised to a higher level of
  abstraction

25
Analysis of Generated Code
26
MSF to Generated Code
27
TVL to Generated Code
28
ECL to Generated Code
29
Concluding Remarks-Benefits of DSL use in these
Two Projects

• The tedious and mundane parts of writing a
  program are automated in the translation from the
  DSL to a traditional programming language.
• Repetitive code sequences are generated
  automatically instead of the error-prone manual
  cut-and-paste method. The generation of such
  tedious code also has advantages in the
  maintenance phase of a projects lifecycle.
• Solutions can be constructed quickly because the
  programmer can more easily focus on the key
  abstractions. A DSL hides the underlying details
  of the solution space as implemented in a
  traditional programming language.

30
Concluding Quotes

• Niklaus Wirth We must recognize the strong and
  undeniable influence that our language exerts on
  our ways of thinking and, in fact, delimits the
  abstract space in which we can formulate give
  form to our thoughts.
• George Polya An important step in solving a
  problem is to choose the notation. It should be
  done carefully. The time we spend now on choosing
  the notation may be well repaid by the time we
  save later avoiding hesitation and confusion.
  Moreover, choosing the notation carefully, we
  have to think sharply of the elements of the
  problem which must be denoted. Thus, choosing a
  suitable notation may contribute essentially to
  understanding the problem.
• Ted Biggerstaff The first order term in the
  success equation of reuse is the amount of
  domain-specific content and the second order term
  is the specific technology chosen in which to
  represent that content.

31
Additional Slides
32
Evaluating Tool Integration Solutions

• How much time and effort does it cost to
  integrate a new tool?
• How scalable is the integration approach?
• How much expert knowledge is needed to realize an
  integration solution?
• What is the coupling between the individual tools
  and the integration technology?

33
Development Effort

• Translators can be written within a few man-days
• Average translator was 225 lines of
  traversal/visitor code
• Tool Adapter development depends on
• Complexity of tool
• Complexity of the tools data access mechanism
  (e.g., ADO, COM, comma separated values)
• Developer experience with previous Tool Adapters
• Our average development time for a bi-directional
  Tool Adapter is about 10 person-weeks

34
Lessons Learned

• Successful integration of 5 tools
• Separation of concerns
• Cleaner solution by separating semantic and
  syntactic issues
• Framework approach using software generators
• infrastructural elements
• tool-specific translators (componentized)
• traversal/visitor specification language