Business Process and Software Architecture Model Co-evolution Patterns

1,228 views

Published on

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

  • Be the first to like this

No Downloads
Views
Total views
1,228
On SlideShare
0
From Embeds
0
Number of Embeds
18
Actions
Shares
0
Downloads
22
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • •How the architecture develops over time•The tradeoffs among the different ways of getting from point A to point B•Stages of development, release points, etc.•Constraints over evolution pathsHow should we execute the evolution to achieve our goals, given limited resources?How can we be certain that intermediate releases do not break existing architectural constraints?How can we make tradeoffs between time, cost, development effort, risk, etc.?How can we represent and communicate an architecture evolution plan?
  • this type graph should also include the concepts required to describe how the concepts evolve over time: the evolution tags.
  • Business Process and Software Architecture Model Co-evolution Patterns

    1. 1. Business Process and Software Architecture Model Co-evolution Patterns Pooyan Jamshidi, Claus Pahl Lero - The Irish Software Engineering Research Centre, School of Computing, Dublin City University Modeling in Software Engineering (MiSE) @ ICSE 2012 Zurich, SwitzerlandLero© 2012
    2. 2. Overview• Context: models at different levels P LP P’ A2 may evolve dependently or A1 A2 A3 A1 A3 independently. T A4 d1 d1• Problem: architecture-based Ɵ Λ software evolution mechanisms are F F’ not executed in controllable manner. T’• Objective: How the architecture model can be adapted to the A LA A’ changes raised by process models with an emphasis on preserving Software architecture co-evolution conceptual model initial architectural decisions. P, P, A, A: Model; T, T, F, F: Model• Outcome: A set of recurrent co- Evolution (Transformation); evolution patterns, A graph-based Λ: Transformation Evolution; Ɵ: Change formalism to enable automated Impact change. 2Lero© 2012
    3. 3. Agenda  Motivations  Co-evolution Patterns  Formalization of the Co-Evolution Process  Case Study  Summary 3Lero© 2012
    4. 4. Architecture Evolution History Graph [David Garlan et al.] 4Lero© 2012
    5. 5. Why Evolution Patterns? • History graph of architecture evolution can be extremely large. • Architecture evolution appear to follow certain common patterns [Evolution Style by Garlan et al.] [Evolution Shelf by Tamzalit et al.]. • Reusable source of knowledge. Drivers are characterized via a change scenario (the problem). Consequential change provides mechanism how to transform the companion (the solution). • Automated assistance for capturing and reusing knowledge about architectural evolution. 5Lero© 2012
    6. 6. Evolution in model-driven context P FL A Patch ∆P F1 ∆A Patch P F A P F A Diff ∆P ΛF ∆A Patch F2 ∆P ∆A P F A F P A Delta transformation Live transformation 6Lero© 2012
    7. 7. Agenda  Motivations  Co-evolution Patterns  Formalization of the Co-Evolution Process  Case Study  Summary 7Lero© 2012
    8. 8. Change Impact Patterns P P’ A2 A1 A2 A3 A1 A3 A4 T d1 d1 F Ɵ F’ T’ A A’ Mostly inspired by the work of [Weber et al. 2008] 8Lero© 2012
    9. 9. 1. Insert an activity between two private activities Problem: an activity has to be accomplished which has not been modeled in the process schema so far. Op (A1) CP C P’ A1 A2 A3 A4 CIP1 Op (A1) Op (A5) A1 A2 A5 A3 A4 Op (A4) BP change Op (A4)Constraints (Invariants):A2 and A3 are mapped to SA behavior protocol changedifferent component thanA1 and A4 Consequence: a new operation has to be inserted into the SA behavior protocol. 9Lero© 2012
    10. 10. 2. Move an activity (serially, parallel, conditionally) A1 A2 A3 Op (A1) Op (A1) CIP2 Op (A2) Op (A2) Op (A3) A2 A1 Op (A3) A3 10Lero© 2012
    11. 11. 3. Insert an activity (serially, parallel, conditionally) A1 A3 CIP3 A1 A2 A3 11Lero© 2012
    12. 12. 4. Replace activity Op (A1) Op (A1) A1 A2 A3 CIP4 Op (A2) Op (A2’) A1 A2’ A3 Op (A3) Op (A3) 12Lero© 2012
    13. 13. 5. Update a condition Op (A1) Op (A1) CP C P’ A1 A2 A3 Op (A2) CIP5 Op (A2) A1 A2 A3 Op (A3) Op (A3) 13Lero© 2012
    14. 14. 6. Embed activity in a loop Op (A1) Op (A1) A1 A2 A3 CIP6 Op (A2) Op (A2) A1 A2 A3 Op (A3) Op (A3) 14Lero© 2012
    15. 15. 7. Embed activity in conditional branch Op (A1) Op (A1) A1 A2 A3 Op (A2) Op (A2) A1 A2 A3 Op (A3) Op (A3) A1 A2 A3 A1 A2 A3 15Lero© 2012
    16. 16. Transformation Evolution P P’ A2 A1 A2 A3 A1 A3 A4 T d1 d1 Λ F F’ T’ A A’ Mostly inspired by the work of [Erdogmus] 16Lero© 2012
    17. 17. Mapping Change Patterns MCP2. extension Initial configuration MCP1. abstraction MCP3. refinement MCP5. flatten (wrap) MCP6. rewire MCP7. replacement 17Lero© 2012
    18. 18. Agenda  Motivations  Co-evolution Patterns  Formalization of the Co-Evolution Process  Case Study  Summary 18Lero© 2012
    19. 19. Formalization of the Co-Evolution Process BPMM Conforms TMMBPM P P’ T Ɵ ADMM-B A A’ T’ TMMADM-S TMMADM-B ADMM-S 19Lero© 2012
    20. 20. Graph-Based Abstract Description of the Evolution Semantics Pre-condition: Change Post-condition: Change Op (A1) CP C P’ A1 A2 A3 A4 CIP1 Op (A1) Op (A5) A1 A2 A5 A3 A4 Op (A4) Op (A4)Invariants: NACs andattributed condition 20Lero© 2012
    21. 21. Why typed graph transformations? • BP and SA models can be easily formalized as graphs. • Graph transformation rules are self-contained and independent of each other; each rule can be applied when its preconditions are satisfied and reused several times to make the required changes. • Typed graphs capture the relation among business process and architecture types. 21Lero© 2012
    22. 22. Type graph of business process model evolution 22Lero© 2012
    23. 23. Type graph of software architecture structural model evolution 23Lero© 2012
    24. 24. Type graph of software architecture behavioral model evolution 24Lero© 2012
    25. 25. Type graph of change impact transformation 25Lero© 2012
    26. 26. Co-evolution History Graph Tbi2 BPM1 BPM7 Tbi1 Tbi5 Tbi3 BPM0 BPM2 Tbi6 BPM4 Tbi4 BPM3 BPM5 BPM6 Tbi7 Tai2 Tai3 Tai4 ADM1 ADM3 ADM4 ADM7 Tai1 Tai8 ADM0 Tai6 ADM5 Tai5 ADM2 Tai7 ADM6 26Lero© 2012
    27. 27. Change Primitives vs. Change Patterns Extending architecture by inserting a component and connector into its configuration Change Primitives: New component (C3); New connector (Conn1); Change Patterns: Add port (C3, p1); Add port (C2, p2); Extend (ADM0, C3, Conn1); Add port (Conn1, p3); Add port (Conn1, p4); Specification complexity = 1 Bind (p1, p3); Bind (p2, p4); Specification complexity = 8 27Lero© 2012
    28. 28. Change Primitives vs. Change Patterns Op (A1) Op (A1) Op (A2) Change behavior protocol of a component by moving an Op (A2) Op (A3) operation parallel to another Op (A3) Change Primitives: Add control-node (OR-Split); Add control-node (OR-Join); Change Patterns: Move control-transition ((Op (A1), Op (A2)), Parallel-move (BS, Op (A2), Op (A3)); (Op (A1), OR-Split)); Add control-transition (OR-Split, Op (A1)); Specification complexity = 1 Add control-transition (OR-Split, Op (A3)); Move control-transition ((Op (A1), Op (A3)), (Op (A1), OR-Join)); Add control-transition (Op (A3), OR-Join); Specification complexity = 7 28Lero© 2012
    29. 29. Agenda  Motivations  Co-evolution Patterns  Formalization of the Co-Evolution Process  Case Study  Summary 29Lero© 2012
    30. 30. Case StudyThe initial LM process modelEmbed an activity in conditionalbranch Move activity 30Lero© 2012
    31. 31. Case StudyInitial LM architecture model Rewire Replacement, rewire, abstraction, and refinement Flatten and extension 31Lero© 2012
    32. 32. Recap P LP P’ A2 A1 A2 A3 A3 • A1 Overview and Positioning A4 T d1 d1 Ɵ Λ F F’ T’ • Motivation P A LA F A A’ • Background Diff ∆P ΛF ∆A Patch P F A • Change Pattern (Change Impact, Mapping Change) • Formalization and Implications Extending architecture by inserting a component and connector into its • A Case Study configuration Change Primitives: Change Patterns: New component (C3); Extend (ADM0, C3, New connector (Conn1); Conn1); Add port (C3, p1); Add port (C2, p2); Edit distance= 1 Add port (Conn1, p3); Add port (Conn1, p4); Bind (p1, p3); Bind (p2, p4); Edit distance= 8 32Lero© 2012

    ×