More Related Content More from Pooyan Jamshidi More from Pooyan Jamshidi (20) Business Process and Software Architecture Model Co-evolution Patterns1. 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, Switzerland
Lero© 2012
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.
2
Lero© 2012
3. Agenda
Motivations
Co-evolution Patterns
Formalization of the Co-Evolution Process
Case Study
Summary
3
Lero© 2012
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.
5
Lero© 2012
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
6
Lero© 2012
7. Agenda
Motivations
Co-evolution Patterns
Formalization of the Co-Evolution Process
Case Study
Summary
7
Lero© 2012
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]
8
Lero© 2012
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 change
different component than
A1 and A4 Consequence: a new operation has to be inserted into the
SA behavior protocol.
9
Lero© 2012
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
10
Lero© 2012
11. 3. Insert an activity (serially, parallel, conditionally)
A1 A3
CIP3
A1 A2 A3
11
Lero© 2012
12. 4. Replace activity
Op (A1) Op (A1)
A1 A2 A3
CIP4
Op (A2) Op (A2’)
A1 A2’ A3
Op (A3) Op (A3)
12
Lero© 2012
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)
13
Lero© 2012
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)
14
Lero© 2012
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
15
Lero© 2012
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]
16
Lero© 2012
17. Mapping Change Patterns
MCP2. extension
Initial configuration MCP1. abstraction
MCP3. refinement
MCP5. flatten (wrap)
MCP6. rewire
MCP7. replacement
17
Lero© 2012
18. Agenda
Motivations
Co-evolution Patterns
Formalization of the Co-Evolution Process
Case Study
Summary
18
Lero© 2012
19. Formalization of the Co-Evolution Process
BPMM
Conforms TMMBPM
P P’
T
Ɵ
ADMM-B
A A’
T’
TMMADM-S TMMADM-B
ADMM-S
19
Lero© 2012
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 and
attributed condition
20
Lero© 2012
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.
21
Lero© 2012
23. Type graph of software architecture structural
model evolution
23
Lero© 2012
24. Type graph of software architecture behavioral
model evolution
24
Lero© 2012
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
26
Lero© 2012
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
27
Lero© 2012
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
28
Lero© 2012
29. Agenda
Motivations
Co-evolution Patterns
Formalization of the Co-Evolution Process
Case Study
Summary
29
Lero© 2012
30. Case Study
The initial LM process model
Embed an activity in conditional
branch
Move activity
30
Lero© 2012
31. Case Study
Initial LM architecture model
Rewire
Replacement, rewire, abstraction,
and refinement
Flatten and extension
31
Lero© 2012
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
32
Lero© 2012
Editor's Notes •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.