Model-Driven Development (MDD) promises a number of advantages, which include the ability to work at higher abstraction levels, static reasoning about models, and generation of platform-specific code. To achieve this, generally a transformation-based approach is adopted, which generates code from models. In this presentation we discuss –in addition to the potential advantages– a number of possible misunderstandings and risks of MDD. In particular, we address the risks of transformation-based software development, such as: • It is rarely possible to generate the full functionality of a (sub-)system from models; as a result, it is necessary to either do additional ‘manual coding’ –a challenge to integrate with the generated code– or annotate the model with small or larger fragments of executable code, which has several restrictions and practical consequences: for instance it mingles abstraction levels, and reduces maintainability of code and models. • MDD is particularly effective when various different models can be used, each optimized for a specific domain. However, when using transformation techniques, de combination of multiple models in an integrated application is far from trivial. In this talk we propose –as a low-threshold approach–, ‘bottom-up’ model-driven development. This means that the focus on domain-specific abstractions remains, as well as the separation of platform-specific and platform-independent software. This approach, which is related to Domain-Driven Design and domain-specific languages (DSLs), aims to exploit the advantages of modeling in terms of abstractions, while at the same time reducing the gap between models and code. This can be achieved by specifying the models in code, while separating platform-specific code from the model code. An important issue is the capability to combine several different models, without getting into technical difficulties: we discuss existing as well as a novel approach, entitled Co-op, which aim to address this problem.

1. steX bv

2. About me
Research Industry
¨ software composition ¨ Independent consultant
(1994-1997, 2008-)
¤ objects & aspects ¤ teach & mentor SE
¤ Language engineering ¤ software architecture
¤ (architecture) design ¤ Scalable design
¤ Models ¨ e.g. Philips Medical
Systems, Ernst & Young
¨ Industry-as-a-laboratory MC, Ordina Panfox
¤ ASML, Oce, Siemens, .. ¨ Ericsson Mobile
Communications (Lund)

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

4. Why Model Driven Development
1. work at higher abstraction levels
2. static reasoning about models
3. generation of repeating code

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

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

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

8. An MDD Example

9. Physical models for Oce printer Sw.
20Sim
20Sim
20Sim
Specification
Specification Analysis
Specification
Report
References
xADL
Dependency Consistency
Transform
Component Model Graph Check
(MO2)
Implement/ Optimization
Generate
Generate Algorithm
Optimization
C(++)/Java Weave
Component
Implementation Monitors
Impl.
Work by Arjan de Roo MOO Control
et.al., for the ESI project Implementation
Octopus (with Océ) Simulink
Hardware Model

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

11. Risks of transformation-based MDD
How to make the model and the code meet

12. From model to code – 1
¨ Generate all code from
the model
¤ Model the complete
system (?)
¤ Requires models that can Transform
scale model to
code
n Decompose into modules
¨ Requires expressive
(meta-)models
¤ Can
we keep MDD
advantages?

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

14. 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 Mayinvalidate static
reasoning

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

16. From model to code – 5
¨ Combine generated code with:
¤ Legacy code
¤ Custom libraries
¨ Issues:
¤ Expressing interfaces
¤ How to compose generated
with other code

17. 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()”.

18. Bottom-up Model-driven Development
A compositional approach

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

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

21. Industrial
experience
(ASML/Ideals)
21
¤ 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)
{
primary
funcConality
/* Retrieve current KNG */
*KNG_ptr = mod_data.KNG;
}
HE(result, "GET_KNG FAILED");
trace_out(mod_data.tr_handle, func_name, result);
TIMING_OUT; error
handling
return result;
}

22. Industrial
case:
approach
22
¨ 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
Work carried out by Dürr, Nagy,
van Engelen, for the ESI/Senter
project Ideals (with ASML)

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

24. Conclusion

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

26. Wrapping up..
¨ MDD can have substantial benefits
¤ Butnot 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

27. Questions? Comments?