business process and software architecture model co-evolution patterns
DESCRIPTION
TRANSCRIPT
Lero© 2012
Business Process and Software Architecture Model Co-evolution Patterns
Pooyan Jamshidi, Claus PahlLero - The Irish Software Engineering Research Centre,
School of Computing, Dublin City University
Modeling in Software Engineering (MiSE) @ ICSE 2012Zurich, Switzerland
Lero© 2012
Overview• Context: models at different levels
may evolve dependently or independently.
• Problem: architecture-based software evolution mechanisms are not executed in controllable manner.
• Objective: How the architecture model can be adapted to the changes raised by process models with an emphasis on preserving initial architectural decisions.
• Outcome: A set of recurrent co-evolution patterns, A graph-based formalism to enable automated change.
2
A1 A2 A3
d1
A1 A3
A2
d1
P P’
A
F F’
T’
T
LP
LA
Λ
Ɵ
A’
A4
Software architecture co-evolution conceptual model P, P', A, A': Model; T, T', F, F': Model Evolution (Transformation); Λ: Transformation Evolution; Ɵ: Change Impact
Lero© 2012
Agenda Motivations Co-evolution Patterns Formalization of the Co-Evolution Process Case Study Summary
3
Lero© 2012
Architecture Evolution History Graph
4
[David Garlan et al.]
Lero© 2012
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
Evolution in model-driven context
6
P A
P' A'
∆P ∆A
F
F
Diff ΛF Patch
P A
P' A'
∆P ∆A
FL
F
Patch F1 Patch
∆P' ∆A'F2
P'' A''F
Delta transformation
Live transformation
Lero© 2012
Agenda Motivations Co-evolution Patterns Formalization of the Co-Evolution Process Case Study Summary
7
Lero© 2012
Change Impact Patterns
8
A1 A2 A3
d1
A1 A3
A2
d1
P P’
A
F F’
T’
T
Ɵ
A’
A4
Mostly inspired by the work of [Weber et al. 2008]
Lero© 2012
1. Insert an activity between two private activities
9
A2 A3
A5
A1 A4
A2 A3A1 A4
Op (A1)
Op (A4)
Op (A1)
Op (A5)
Op (A4)
BP change
SA behavior protocol change
CIP1
Problem: an activity has to be accomplished which has not been modeled in the process schema so far.
Consequence: a new operation has to be inserted into the SA behavior protocol.
Constraints (Invariants): A2 and A3 are mapped to different component than A1 and A4
CP
C P’
Lero© 2012
2. Move an activity (serially, parallel, conditionally)
10
A1 A2 A3
A1
A2
A3
Op (A1)
Op (A2)
Op (A3)
Op (A1)
Op (A2) Op (A3)
CIP2
Lero© 2012
3. Insert an activity (serially, parallel, conditionally)
11
A1 A3
A1 A2 A3
CIP3
Lero© 2012
4. Replace activity
12
A1 A2 A3
A1 A2’ A3
Op (A1)
Op (A2)
Op (A3)
Op (A1)
Op (A2’)
Op (A3)
CIP4
Lero© 2012
5. Update a condition
13
A1 A2 A3
Op (A1)
Op (A2)
Op (A3)
A1 A2 A3
Op (A1)
Op (A2)
Op (A3)
CPC P’
CIP5
Lero© 2012
6. Embed activity in a loop
14
A1 A2 A3
A1 A2 A3
Op (A1)
Op (A2)
Op (A3)
Op (A1)
Op (A2)
Op (A3)
CIP6
Lero© 2012
7. Embed activity in conditional branch
15
A1 A2 A3
A1 A2 A3
Op (A1)
Op (A2)
Op (A3)
Op (A1)
Op (A2)
Op (A3)
A1 A2
A1 A2 A3
A3
Lero© 2012
Transformation Evolution
16
A1 A2 A3
d1
A1 A3
A2
d1
P P’
A
F F’
T’
T
Λ
A’
A4
Mostly inspired by the work of [Erdogmus]
Lero© 2012
Mapping Change Patterns
17
Initial configuration MCP1. abstraction
MCP2. extension
MCP3. refinement
MCP5. flatten (wrap)
MCP6. rewire
MCP7. replacement
Lero© 2012
Agenda Motivations Co-evolution Patterns Formalization of the Co-Evolution Process Case Study Summary
18
Lero© 2012
Formalization of the Co-Evolution Process
19
P P’
A A’
T’
T
TMMBPM
TMMADM-S
Ɵ
Conforms
TMMADM-B
ADMM-B
ADMM-S
BPMM
Lero© 2012
Graph-Based Abstract Description of the Evolution Semantics
20
A2 A3
A5
A1 A4
A2 A3A1 A4
Op (A1)
Op (A4)
Op (A1)
Op (A5)
Op (A4)
CIP1
Pre-condition: ChangePost-condition: Change
Invariants: NACs and attributed condition
CP
C P’
Lero© 2012
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
Type graph of business process model evolution
22
Lero© 2012
Type graph of software architecture structural model evolution
23
Lero© 2012
Type graph of software architecture behavioral model evolution
24
Lero© 2012
25
Type graph of change impact transformation
Lero© 2012
Co-evolution History Graph
26
ADM0
ADM1
ADM2
ADM3 ADM4
ADM5
ADM6
ADM7
Tai1
Tai2 Ta
i3Ta
i4
Tai5
Tai6
Tai7
Tai8
BPM0
BPM1
BPM2
BPM3
BPM4
BPM5
BPM6
BPM7
Tbi1
Tbi2
Tbi3
Tbi4
Tbi6
Tbi7
Tbi5
Lero© 2012
Change Primitives vs. Change Patterns
27
Change Patterns:Extend (ADM0, C3, Conn1);
Specification complexity = 1
Change Primitives:New component (C3);New connector (Conn1);Add port (C3, p1);Add port (C2, p2);Add port (Conn1, p3);Add port (Conn1, p4);Bind (p1, p3);Bind (p2, p4); Specification complexity = 8
Extending architecture by inserting a component and connector into its configuration
Lero© 2012
Change Primitives vs. Change Patterns
28
Op (A1)
Op (A2)
Op (A3)
Op (A1)
Op (A2) Op (A3)
Change Patterns:Parallel-move (BS, Op (A2), Op (A3));
Specification complexity = 1
Change Primitives:Add control-node (OR-Split);Add control-node (OR-Join);Move control-transition ((Op (A1), Op (A2)),
(Op (A1), OR-Split));
Add control-transition (OR-Split, Op (A1));
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
Change behavior protocol of a component by moving an operation parallel to another
Lero© 2012
Agenda Motivations Co-evolution Patterns Formalization of the Co-Evolution Process Case Study Summary
29
Lero© 2012
Case Study
30
The initial LM process model
Move activity
Embed an activity in conditional branch
Lero© 2012
Case Study
31
Initial LM architecture model
Rewire
Flatten and extension
Replacement, rewire, abstraction, and refinement
Lero© 2012
Recap
• Overview and Positioning• Motivation• Background• Change Pattern (Change Impact, Mapping
Change)• Formalization and Implications• A Case Study
32
A1 A2 A3
d1
A1 A3
A2
d1
P P’
A
F F’
T’
T
LP
LA
Λ
Ɵ
A’
A4
P A
P' A'
∆P ∆A
F
F
Diff ΛF Patch
Change Patterns:Extend (ADM0, C3,
Conn1); Edit distance= 1
Change Primitives:New component (C3);New connector (Conn1);Add port (C3, p1);Add port (C2, p2);Add port (Conn1, p3);Add port (Conn1, p4);Bind (p1, p3);Bind (p2, p4); Edit distance= 8
Extending architecture by inserting a component and connector into its configuration