1. Documenting Stepwise Model Refinement using
Executable Design Decisions
Matthias Biehl
Embedded Control Systems
Royal Institute of Technology
Stockholm, Sweden
Matthias Biehl 1

2. • What kind of models are considered?
• Implementation: EMF-based models, independent of metamodel
• Case study: models of the HW and SW architecture of automotive embedded
systems
• What kind of evolution challenges are addressed?
• Documentation of design decisions for models
• Linking documentation to the affected model elements
• Consistency between design decision documentation and model
Matthias Biehl 2

3. Example: Documentation of
Design Decisions for Models
Double redundancy to
improve the reliability of a
safety critical component
Matthias Biehl 3

4. Requirements for Documentation of
Design Decisions for Models
• Explicit documentation of the design decision, for example by a
textual description.
• Applicable for an arbitrary metamodel: it should not be necessary
to change existing metamodels to document design decisions.
• Link between the design decision documentation and the model: a
link between the design decision documentation, the context of the
design decision and the model elements affected by the design
decision
• Low capture overhead: the effort for linking to the documentation
to the model should be low.
• Consistency between the design decision documentation and the
model: the change described by the design decision should be
actually be realized in the model.
Matthias Biehl 4

5. Stepwise Refinement
M0
d1
M1
Explanation
Model
M
d Design Decision
Matthias Biehl 5

6. Lack of Design Decision Documentation
M0
d1
M1
d2
…
dn
Explanation
Mn
Artifact
M
d Design Decision
Matthias Biehl 6

7. Design Decision Capture Problem
• Additional cost and effort for documenting design
decisions, no immediate benefit [10]
• Documentation is not always performed in practice [18]
• Knowledge vaporization
• Model inconsistencies, erosion, aging, architectural drift
• Problems during maintenance
Matthias Biehl 7

8. How to deal with the
design decision capture problem?
(a) M0 (b) M0 (c) M0
d1 d1
M1 M1 M1
artifact based, artifact based executable
e.g. SVN, CVS + design decision design decisions
documentation
Red = needs to be specified and changed manually
Matthias Biehl 8

9. Formalization: Stepwise Model Refinement
with Executable Design Decisions
• Design Decisions as executable specification is both
• descriptive documentation
• constructive tool for creation of the artifact
M0 M0 initial architecture, can be empty
d1
M1 M1 = d1(M0)
d2
…
dn
Mn Mn = (dn dn-1 … d1 )(M0)
Matthias Biehl 9

10. Mapping between
Design Decisions and Model Transformations
Model Mi maps to Source Model Mi
maps to
Context LHS
Design maps to Model
Decision Transformation
Outcome maps to RHS
Model Mi+1 maps to Target Model Mi+1
• Requirements for Model Transformation Language/Engine
• Model-to-Model: input and output of the transformation are models
• Endogeneous: metamodels of source and target are identical
• In-Place: create the target model by modifying specific parts in the source model
Matthias Biehl 10

11. Which part of the design decision
can be described by a Model Transformation?
• Basis: Design Decision Ontology [9]
• Context/Scope, Outcome
• Author, Timestamp, Risk, Cost, Design Decision Rationale
• Relation between design decisions
• Model Transformation
• Context/Scope, Outcome, Trace link to the model elements
• Additional Information: Design Decision Management Container
• Author, Timestamp, Risk, Cost, Design Decision Rationale
• Relation between design decisions
• Link to the Model Transformation
Matthias Biehl 11

12. Capturing Design Decisions
• Steps for manual capturing
1. Performing an update of the model, so it reflects the new design decision
2. Documenting where in the model the change applies and what is changed
3. Linking the documentation to the model elements affected by the change
4. Documenting the rationale of the change
• Executable Design Decisions use intrinsic relation of steps 1, 2 and 3
1. Update of the model = outcome of executing the Executable Design Decision
2. Where and What = LHS and RHS of Executable Design Decision
3. Traces of Executable Design Decision link the design decision to the model
Matthias Biehl 12

13. Simplified Brake-by-wire Model
Matthias Biehl 13

14. Brake-by-wire Architecture
with Double Redundancy
Matthias Biehl 14

15. Design Decision Documentation using
Triple Graph Grammars (TGG)
Left-Hand-Side Right-Hand-Side
Matthias Biehl 15

16. Design Decision Patterns
• Executable design decisions are reusable
• Reuse design decision in a different context
• adapt LHS
• Change the outcome of the design decision
• adapt RHS
Matthias Biehl 16

17. Design Decision Patterns:
Reuse design decision in a different context
• Apply design decision on WheelSpeedSensor instead of PedalSensor
• Same RHS
• Adapt LHS
„WheelSpeedSensor“ LHS
Matthias Biehl 17

18. Design Decision Patterns:
Change the outcome of the design decision
• Design decision: use triple redundancy + voter
• Same LHS as for double redundancy
• Adapt RHS
New RHS
Matthias Biehl 18

19. Brake-by-wire Architecture
with Triple Redundancy + Voter
instead of Double Redundancy
Matthias Biehl 19

20. Summary:
Documenting Model Refinement
• Problem: Double effort required for capturing design decisions
• Both the architecture needs to be adapted
• and the design decision needs to be documented
• Representation: Executable Design Decision
• Executable specification using model transformations
• Additional design decision rationale and „bookkeeping“ data
• Result
• Reduction of capture overhead: context and outcome calulated automatically
• Applicability with any metamodel
• Consistency between model and documentation through automation
• Link between documentation and model through automated traces
Matthias Biehl 20

21. Matthias Biehl 21

22. Question for Brainstorming
• What is an appropriate classification scheme for model evolution
problems and approaches?
Matthias Biehl 22

23. Automate Capturing Design Decisions
• Create snapshots of the model:
• Mi-1 = Snapshot of model before the design decision
• Mi = Snapshot of model after the design decision
• Calculate Model Transformation
• Calculate ∆i = diff(Mi, Mi-1), e.g. using EMF Compare
• Calculate Εi = all elements in Mi-with a direct connection to an element in ∆i
• LHS = Ei
• RHS = ∆i ∪ Εi
• Mapping graph calculated by a matching algorithm between LHS and RHS
Matthias Biehl 23

24. Summary:
Documenting Model Refinement
• Problem: Double effort required for capturing design decisions
• Both the architecture needs to be adapted
• … and the design decision needs to be documented in addition
• Representation: Executable Design Decision
• Executable specification using model transformations
• Additional design decision rationale and „bookkeeping“ data
• Result
• Reduction of capture overhead: context and outcome calulated automatically
• Applicability with any metamodel
• Consistency between model and documentation through automation
• Link between documentation and model through automated traces
Matthias Biehl 24

25. Design Decision Documentation using ATL
Matthias Biehl 25

26. Rationale Levels
• Levels of Justification/Explanation
• Similar to metalevels of OMG M0-M3
• Each new level :
• answers the question „Why?“
• R0: Artifact
Why? • Examples: Requirements, Models, Architecture, Implementation
• R1: Decision
• Link to Requirements
Why? • Link between Artifact Elements and Design Decisons
• R2: Decision Rationale
• Tradeoff
• Quantitative and qualitative rationale
Matthias Biehl 26

27. Stepwise Refinement
• Stepwise refinement by Dijkstra [6] and by Wirth [22]
• Refinement entails a change in the model M0
• A change entails a design decision d1
• Iterative refinement
M1
• Granularity of a “Step”?
• We use a design decision, which may contain
several refinement steps
• Attribute Driven Design [23] Explanation
Model
M
d Design Decision
Matthias Biehl 27

28. • Design Decisions as Executable Specification
• descriptive documentation
• constructive tool for creation of the artifact
• Analogy – furniture construction
• Construction plan instead of the finished artifact
• Construction plan can be executed automatically, yielding the finished artifact
• Construction plan serves as a rationale for the artifact and provides an explicit
record of the design decisions of constructing the artifact
• Executability of the construction plan ensures consistency between construction
plan and artifact
Matthias Biehl 28

29. We know how to document design decision in source code …
/* design decision */
How can we document
design decisions when
developing models?
Matthias Biehl 29

30. Future Work
• Reusable design decisons
• Design patterns
• Changing the LHS, provides new decision context
• Build catalogs of reusable design decisons
• Further reduce capturing effort
• The effect of the design decision on the architecture is used to
compare design decisions
• existing quality analyses can be used
• Use design decisons for
• Design space exploration
• Optimization
• Change impact analysis
• Tradeoff-analysis
Matthias Biehl 30

31. Use Model Transformations
• Additional Information captured separately
• Author, Timestamp, Risk, Cost, Design Decision Rationale
Matthias Biehl 31

32. Context corresponds to LHS
Design corresponds to Model
Decision Transformation
Outcome corresponds to RHS
Matthias Biehl 32

33. Challenge: Architectural knowledge vaporization
• knowledge vaporization
• important knowledge about the architecture is tacit and
seems self-evident during creation e.g.
assumptions, reasoning, alternative designs, trade-
offs, company policies
• tacit knowledge is easily lost over time
• tacit knowledge is needed during
construction, evolution and reuse of the architecture
• some implications of knowledge vaporization
• inappropriate reuse of components
• long time spent on understanding previous architecture
• expensive evolution and change
• Results in well-known software architecture problems: software
aging, design erosion, architectural drift, high cost of
change, high cost of maintenance
Matthias Biehl 33

34. Architectural Knowledge (AK)
• Especially relevant for intangible products, i.e.
software for embedded systems
• Most relevant knowledge for software:
knowledge about the software architecture
• Architectural Knowledge
• AK = architecture + rationale
• AK = design decisions and design
• AK = drivers, decisions, analysis
• AK = process, products, people, tools
Matthias Biehl 34

35. Issue
A0
d1
A1
x x x x x
Alternatives
Matthias Biehl 35