Model Evolution Workshop at MODELS 2010

172 views
144 views

Published on

Published in: Technology, Education
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
172
On SlideShare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • We know how to document design decisions for source code.But how do we for models?
  • Any intermediate version can be created
  • Model Evolution Workshop at MODELS 2010

    1. 1. Documenting Stepwise Model Refinement using Executable Design Decisions Matthias Biehl Embedded Control Systems Royal Institute of Technology Stockholm, SwedenMatthias Biehl 1
    2. 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 modelMatthias Biehl 2
    3. 3. Example: Documentation of Design Decisions for Models Double redundancy to improve the reliability of a safety critical componentMatthias Biehl 3
    4. 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. 5. Stepwise Refinement M0 d1 M1 Explanation Model M d Design DecisionMatthias Biehl 5
    6. 6. Lack of Design Decision Documentation M0 d1 M1 d2 … dn Explanation Mn Artifact M d Design DecisionMatthias Biehl 6
    7. 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 maintenanceMatthias Biehl 7
    8. 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 manuallyMatthias Biehl 8
    9. 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. 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 modelMatthias Biehl 10
    11. 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 TransformationMatthias Biehl 11
    12. 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 modelMatthias Biehl 12
    13. 13. Simplified Brake-by-wire ModelMatthias Biehl 13
    14. 14. Brake-by-wire Architecture with Double RedundancyMatthias Biehl 14
    15. 15. Design Decision Documentation using Triple Graph Grammars (TGG) Left-Hand-Side Right-Hand-SideMatthias Biehl 15
    16. 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 RHSMatthias Biehl 16
    17. 17. Design Decision Patterns: Reuse design decision in a different context • Apply design decision on WheelSpeedSensor instead of PedalSensor • Same RHS • Adapt LHS „WheelSpeedSensor“ LHSMatthias Biehl 17
    18. 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 RHSMatthias Biehl 18
    19. 19. Brake-by-wire Architecture with Triple Redundancy + Voter instead of Double RedundancyMatthias Biehl 19
    20. 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 tracesMatthias Biehl 20
    21. 21. Matthias Biehl 21
    22. 22. Question for Brainstorming • What is an appropriate classification scheme for model evolution problems and approaches?Matthias Biehl 22
    23. 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 RHSMatthias Biehl 23
    24. 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 tracesMatthias Biehl 24
    25. 25. Design Decision Documentation using ATLMatthias Biehl 25
    26. 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 rationaleMatthias Biehl 26
    27. 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 DecisionMatthias Biehl 27
    28. 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 artifactMatthias Biehl 28
    29. 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. 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-analysisMatthias Biehl 30
    31. 31. Use Model Transformations • Additional Information captured separately • Author, Timestamp, Risk, Cost, Design Decision RationaleMatthias Biehl 31
    32. 32. Context corresponds to LHS Design corresponds to Model Decision Transformation Outcome corresponds to RHSMatthias Biehl 32
    33. 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 maintenanceMatthias Biehl 33
    34. 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, toolsMatthias Biehl 34
    35. 35. Issue A0 d1 A1 x x x x x AlternativesMatthias Biehl 35

    ×