Close Encounters in MDD: when models meet code
-
Upload
lbergmans -
Category
Technology
-
view
214 -
download
0
description
Transcript of Close Encounters in MDD: when models meet code
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?