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, 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

4. Architecture Evolution History Graph
[David Garlan et al.]
4
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

22. Type graph of business process model
evolution
22
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

25. Type graph of change impact
transformation
25
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