steX bv

About me

¨  software composition ¤  objects & aspects ¤  Language engineering ¤  (architecture) design ¤ Models

¨  Industry-as-a-laboratory ¤ ASML, Oce, Siemens, ..

¨  Independent consultant (1994-1997, 2008-) ¤  teach & mentor SE ¤  software architecture ¤  Scalable design

¨  e.g. Philips Medical Systems, Ernst & Young MC, Ordina Panfox

¨  Ericsson Mobile Communications (Lund)

Research Industry

Scientific background: ufology

¨  ‘Close encounters’ (Hynek, 1972): n  Observations within 500 feet

1.  Sighting of UFO 2.  Observation including physical effects of UFO 3.  Observation of animate beings 4.  Abduction by UFO (occupants) 5.  Bilateral contacts 6.  UFO causes harm (≈2.) 7.  Mating that produces a

‘human-alien hybridisation’

1.  work at higher abstraction levels 2.  static reasoning about models 3.  generation of repeating code

Why Model Driven Development

1. Work at higher abstraction levels

¨  This is better because: ¤ Able to express solutions in a form that is closer to

problem domain ¤ Able to ignore (low-level) details

¨  However: ¤ This requires abstracting from some details!

n E.g. platform specifics, implementation details

¨  Works best: ¤ For models that are optimized for a small domain

2. Static reasoning about models

¨  This is better because: ¤ Get better, more precise, feedback early in the process

n E.g. on inconsistencies, deadlocks, resource usage (scheduling)

¨  However: ¤  It only works for domain-specific models with limited

expressiveness.

¨  Works best: ¤ For models that represent a particular concern

3. Generation of repeating code

¨  This is better because: ¤  ‘boilerplate code’ is still error-prone and maintenance-

intensive. ¤  Encapsulate domain knowledge in a code generator

¨  However: ¤  Transformation-based approaches have shortcomings ¤ Maintaining code generators can be critical (key

differentiator) but cumbersome. ¨  Works best:

¤  Platform- & domain-specifics; common solution patterns ¤ when easy to parameterize for specific application

An MDD Example

Physical models for Oce printer Sw.

xADL

Component Model (MO2)

Transform

20SimSpecification

20SimSpecification

20SimSpecification

References

Dependency Graph

ConsistencyCheck

AnalysisReport

C(++)/JavaImplementation

Implement/Generate

OptimizationComponent

Impl.

Generate OptimizationAlgorithm

WeaveMonitors

MOO Control Implementation

SimulinkHardware Model

Work by Arjan de Roo et.al., for the ESI project Octopus (with Océ)

Manage complexity in (adaptive) control software ¨  Make physical models explicit

¤  à clean up control software from crosscutting concerns ¤  Use domain-specific models (20sim) for expressing these

¨  MO2 architecture description language for combining software and physical models

¤  Can perform design-time consistency checks (for the integrated model)

¤  Can generate (multi-objective) optimizer ¤  Can weave in monitoring and control ‘hooks’ in the control

software automatically.

How to make the model and the code meet

Risks of transformation-based MDD

From model to code – 1

¨  Generate all code from the model ¤ Model the complete

system (?) ¤ Requires models that can

scale n Decompose into modules

¨  Requires expressive (meta-)models ¤ Can we keep MDD

advantages?

Transform model to code

From model to code – 2

¨  If the meta-model has limited expressiveness:

¨  Option 1: ¤  Add code fragments to model

elements

¤  ‘weave’ these in to the generated code

¤  Issues: n  what language/formalism

n  Model-code dependencies n  Support for managing the code

n  May invalidate static reasoning

From model to code – 3

¨  If the meta-model has limited expressiveness:

¨  Option 2: ¤  Combine generated and

manual code. ¤  Issues:

n Granularity n Dependencies n Co-evolution n  Inconsistencies n May invalidate static

reasoning

From model to code – 4

¨  Combine different (meta-)models ¤  Each optimized for a domain

¨  Issues: ¤  Expressing interfaces ¤  How to compose these

n  Can we add new meta-models?

From model to code – 5

¨  Combine generated code with: ¤  Legacy code ¤  Custom libraries

¨  Issues: ¤  Expressing interfaces ¤  How to compose generated

with other code

Composing generated code

¨  The models that define a single system are never independent!

¨  Without a common base: ¤ Mutual dependencies (potentially) among all models ¤ These rise exponentially with # of models

¨  Model interference example: ¤ Model I generates some code “increment(logCnt)” for

every occurrence of “trace()” ¤ Model II generates some code “trace(..)” for every

occurrence of “increment()”.

A compositional approach

Bottom-up Model-driven Development

‘Bottom-up MDD’

¨  Focus on domain-specific abstractions ¨  Separation of concerns

¤ E.g. platform-specific and -independent software

¨  But: in a code-centric approach! ¤ The design & code are the models ¤ Code is continually refactored to be accurate

representation of the model (s) ¨  Cf: Agile MDD [Ambler], Domain-Driven design [Evans]

[goal] à the code is the design is the model

Enabling technology: composition

¨  Ability to separate models and compose them: ¤ Various, connected and interleaving, pieces of code

generated from models ¤ Separately designed models, expressed in code

¨  At UT we developed Co-op: ¤ a generic composition technology ¤ Enables clean separation of concerns ¤ Also usable as a target for generating composable

code from multiple models

Industrial  experience  (ASML/Ideals)  

¤ 4  concepts  ‘crosscut’  the  system  (-­‐30%  of  code)  ¤ error-­‐prone,  hard  to  maintain,  ...    

int get_kng(KNG_struct* KNG_ptr) { const char* func_name = "get_kng"; int result = OK; timing_handle timing_hdl = NULL; TIMING_IN; trace_in(mod_data.tr_handle, func_name); if (result == OK) { /* Retrieve current KNG */ *KNG_ptr = mod_data.KNG; } HE(result, "GET_KNG FAILED"); trace_out(mod_data.tr_handle, func_name, result); TIMING_OUT; return result; }

primary    funcConality  

error    handling  

21  

Industrial  case:  approach  

¨  capture  the  essence  of    the  4  concepts  ¤ separate  these  into  independent  abstracCons  ¤ Use  domain-­‐specific  specs  to  describe  abstracCons  

KNG_struct get_kng() {

return ( mod_data.KNG); }

note:  ASML  focused  first  on  only  one  aspect  

22  

Work carried out by Dürr, Nagy, van Engelen, for the ESI/Senter project Ideals (with ASML)

Limitations of bottom-up approach

¨  static analysis may not be available ¤ à perhaps adopt traditional MDD in such a case ¤ May be resolved by adding metadata (annotations) to

the code n But this requires discipline...

¨  Separation of concerns may be difficult to implement

¨  No graphical/visualization of model available ¤ & no domain-specific syntax (but Embedded DSLs can)

Conclusion

Close encounters between code and models

1.  Sighting of UFO n  models available before coding à at least core architecture

2.  Observation including physical effects of UFO n  code is an implementation of a design model à or: throw-away design

3.  Observation of animate beings n  code implemented after models have been analyzed and/or simulated.

4.  Abduction by UFO (occupants) n  (partial) code generation from models à reduces maintenance

5.  Bilateral contacts n  round-trip engineering à mostly in UML context

6.  UFO causes harm n  analysis paralysis n  generated code does not work (resources

7.  Mating that produces a human-alien hybridization’ n  the code *is* the model (and vice versa) à avoid gap

Wrapping up..

¨  MDD can have substantial benefits ¤ But not always easy to realize ¤ Key issues:

n partial code generation n  combinations of models

¨  Bottom-up MDD: avoid gap between models & code ¤  Interesting alternative unless static model analysis

available

¨  Composition is an enabling technology

Questions? Comments?