This document discusses using patterns to guide architecture evolution in service-driven systems. It proposes identifying recurring architecture change patterns from logs, formally specifying patterns in a catalogue, and reusing patterns to support evolution. An example evolution case integrating a new component is presented. A pattern-based evolution process involves specifying changes, retrieving relevant patterns, and instantiating patterns to implement the changes. The approach is experimentally analyzed using evaluation scenarios and a prototype for automated pattern-based evolution. Maintaining a pattern library could help discover, specify and reuse patterns to guide architecture-centric software evolution.

1. Pattern-driven Reuse in Architecture-centric
Welcome
Evolution for Service Software
Aakash Ahmad, Pooyan Jamshidi and Claus Pahl
Presentation Title
[ahmad.aakash|pooyan.jamshidi|claus.pahl]@computing.dcu.ie
Software and System Engineering group
http://www.computing.dcu.ie/~cpahl/sse-group.htm
School of Computing, Dublin City University, Ireland
THE IRISH SOFTWARE ENGINEERING RESEARCH CENTRE

2. Agenda
- Evolution in Service-driven Architectures
- Related Research - Patterns and Evolution
- Change Pattern to guide Architecture Evolution
- Architecture Evolution-case for EBPP
- Pattern-based Architecture Evolution
- Experimental Analysis & Evaluation
- Conclusions & Outlook
2
LERO© 2010 THE IRISH SOFTWARE ENGINEERING RESEARCH CENTRE

3. Evolution in Service-driven Architectures
Service-Oriented Architecture (SOA) is a business-centric, architectural approach to model
business processes as technical software services to develop enterprise software.
- Service components as the core computational entities (atomic or composite)
- Connectors to establish service-level interconnections (association, composition etc.)
- Configurations to allow topological configuration of components and connectors
Evolution in an SOA goes beyond a more conventional addition or removal of individual
components and connectors.
- Process-centric change in terms of integration, replacement, decomposition etc.
- Process aspects of change management requires an explicit specification of source
and evolved architecture model with appropriate steps to complete the transition.
3
LERO© 2011 THE IRISH SOFTWARE ENGINEERING RESEARCH CENTRE

4. The needs for Reuse in Service Architecture Evolution
A continuous change in business and technical requirements lead towards frequent
maintenance and evolution cycles in service software.
…community wide efforts are required to develop processes, framework and
patterns etc., to enable systematic maintenance an explicit evolution for SOAs …
[MESOA 07, 08, 09, 10]
4
LERO© 2011 THE IRISH SOFTWARE ENGINEERING RESEARCH CENTRE

5. Related Research - Patterns and Evolution
Evolution in SOAs? Patterns in Architectural Abstractions?
Evolution1Patterns Process Change Patterns
Repository Paths Process-centric Evolution
Evolution Shelf Evolution Styles Process Change Process Mining
MESOA’07’08’09’10
Maintenance, Evolution, Adaptation
Reuse of Evolution in SOAs
5
LERO© 2011 THE IRISH SOFTWARE ENGINEERING RESEARCH CENTRE

6. Change Patterns to guide Architecture Evolution
Central Hypothesis: The application of change patterns to architectural transformation supports potential
reuse in architecture-centric software evolution.
Pattern Identification – recurring sequences from Architecture Change Logs [IWSSA’12]
Pattern Specification – once-off formal specification in Pattern Catalogue [SHARK’12]
Pattern Instantiation – multiple instantiations to support pattern-based reuse in evolution.
Pattern-based Evolution Benefits for Pattern-based Reuse
6
LERO© 2011 THE IRISH SOFTWARE ENGINEERING RESEARCH CENTRE

7. The Anatomy of Pattern-based Architecture Evolution
Change pattern provides a generic, first class abstraction (that can be operationalised
and parameterised) to support potential reuse in architectural change execution.
𝐼𝑁𝑉(𝑂𝑃𝑅𝑛(𝑎𝑒𝑚∈𝐴𝐸))
PAT<name, intent>: PRE(aem ∈ AE) POST(ae′m ∈ AE).
LERO© 2011
7
THE IRISH SOFTWARE ENGINEERING RESEARCH CENTRE

8. Graph-based Change Pattern Notation
Pattern Specification – as an attributed typed Graph (.GML) notation.
Pattern Storage – Graph databse using Neo4j graph tuples.
LERO© 2011
8
THE IRISH SOFTWARE ENGINEERING RESEARCH CENTRE

9. Architecture Evolution Case for EBPP
Evolution Use-case – Component Integration
Inclusion of Customer debt management in existing architecture
- Pre-conditions: architectural context before evolution
- Operationsliastion : individual change instances
- Postconditions : architectural context after evolution
9
LERO© 2011 THE IRISH SOFTWARE ENGINEERING RESEARCH CENTRE

10. Pattern-based Architecture Evolution
Step 1: Architecture Change Specification.
Step 2: Change Pattern Retrieval
Step 3: Change Pattern Instantiation
10
LERO© 2010 THE IRISH SOFTWARE ENGINEERING RESEARCH CENTRE

11. Step 1: Change Specification
A declarative specification allows syntactical context of architectural change:
i) Source Architecture Model (GS)
ii) Architectural Constraints as pre- and post-conditions (PRE, POST ∈ [CNS])
iii) Architecture Elements (AE) that need to evolved such that AE ∈ GS.
Context Constraints: Gs inv, pre, post -- Constraints specification on architecture model
-- Invarinats for structural integrity of component and connector
inv: Constraints.INV -> forAll(Component.hasPORT >= 1)
-- Preconditions to specify existence of architecture elements before evolution
pre: Constraints.PRE -> exists(Component = ‘BillerApp’)
pre: Constraints.PRE -> exists(Connector(BillerApp, custBill) | Connector = ‘billingData’)
-- Post to specify existence of architecture elements after evolution
post: Constraints.POST-> exists(Component = ‘BillerApp’)
post: Constraints.POST -> exists(Component = ‘custBill’)
post: Constraints.POST -> exists(Connector(billType, custBill) | Connector = ‘getType’)
OCL-based Constraints Specification on Architecture Models
11
LERO© 2010 THE IRISH SOFTWARE ENGINEERING RESEARCH CENTRE

12. Step 2: Change Pattern Retrieval
(Root) <relatesTo> [Nodes] :
(ChangePattern) <isComposedOf, ConstrainedBy, Evolves> [Operators | Constraints | ArchitectureModel]
Query - Which change pattern(s) allow integration of a mediator component among two directly connected
components?
01: START pattern = node(ChangePattern)
02: MATCH (pattern) – [:ConstrainedBy] - > (Constraints)
03: – [:Composedof] - > (Operators)
04: WHERE Operators IS NOT Null
05: RETURN ChangPattern.name, ChangePattern.intent, Operators.operatorType
Listing: Cypher Query to Retrieve Pattern Name, Intent and Operationalisation
START - command to set the primary node(s),
MATCH - based on user-specified change constraints respectively.
WHERE - allows for additional conditional checking, while
RETURN - provides the gathered results.
12
LERO© 2010 THE IRISH SOFTWARE ENGINEERING RESEARCH CENTRE

13. Step 3: Change Pattern Instantiation
   
 
 
 
- Pattern Instantiation  
- Addition ms : S  GS mt : T  GT
∈
Add<billType • CMP>;
Add<billingType ∈ CON>;
mI : I  GI
Add<getType ∈ CON>
- Removal
Rem<billingData ∈ CON>.
GS S GI T GT
 
13
LERO© 2010 THE IRISH SOFTWARE ENGINEERING RESEARCH CENTRE

14. Experimental Analysis & Evaluation
1 Scenario-based Evaluation
- EBPP & TRS Evolution Cases
- Pattern Types & Adequacy
2 Prototype-based Validation
- Automated Pattern-based Evolution
- Survey & Usability Analysis
14
LERO© 2010 THE IRISH SOFTWARE ENGINEERING RESEARCH CENTRE

15. Recap
Discover Evolution Pattern
- prototype: G-Pride
Pat-Evol Project
Maintain Pattern Library
- prototype: Pat-Lib
Reuse Change Execution
- prototype: Pat-Evol
THE IRISH SOFTWARE ENGINEERING RESEARCH CENTRE

16. Thank you for your attention.
16
LERO© 2011 THE IRISH SOFTWARE ENGINEERING RESEARCH CENTRE