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