Graph Pattern Identification

THE IRISH SOFTWARE ENGINEERING RESEARCH CENTRE

Welcome Presentation Title

Graph-based Pattern Identification from Architecture Change Logs

Aakash Ahmad, Pooyan Jamshidi and Claus Pahl

Software and System Engineering group

http://www.computing.dcu.ie/~cpahl/sse-group.htm School of Computing, Dublin City University, Ireland

http://www.computing.dcu.ie/~cpahl/sse-group.htm



THE IRISH SOFTWARE ENGINEERING RESEARCH CENTRE LERO© 2011 2

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 and data stores (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 attributes of change in terms of integration, replacement, decomposition etc.


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]


Change Patterns to guide Architecture Evolution

Central Hypothesis: A systematic investigation into the history of architectural changes enables discovery

of recurring operationalisation and patterns that guide architecture change management.

- Change Log: a transparent, centrally manageable repository maintaining traces of evolution over time

- Change Graph: formalising change instances for an automated analysis of operationalisation and dependencies.

LERO© 2011 4

Pattern-based Evolution Benefits for Pattern-based Reuse


Related Research - Patterns and Evolution

LERO© 2011 5

Evolution Patterns Process Change Patterns

Evolution Shelf

Repository Paths

1

Evolution in SOAs? Patterns in Architectural Abstractions?

Reuse of Evolution in SOAs

Evolution Styles Process Mining and Evolution Process Change Patterns

Process-centric Evolution

MESOA’07’08’09’10

Maintenance, Evolution, Adaptation


Log-based Analysis of Architecture Change

LERO© 2010 6

Architecture Change Logs (ACL) as a knowledge base provide us with a transparent and centrally

manageable repository by maintaining fine-granular instances of sequential change aggregating over time.

- Adequacy of Change Log Data

Completeness, Granularity of Change, etc.

- Log Data Classification

Change Data & Auxiliary Data

- Architecture Change Instances

EBPP and TRS case studies

ACL =< AC1,AC

2, . . . ,AC

N >


Architecture Evolution Case Study

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


Solution Overview

LERO© 2010 8

1. The Pre-processing Approach

- Capturing Change Instances

- Log Data Classification

- Change Instance Formalisation

2. Log Data Analysis

- Change Operationalisation

- Operational Dependencies

- Pattern Identification


Graph-based Formalisation of Change Instances

LERO© 2010 9

- Formalise Change Instances from Log as an Attributed Typed Graph

- Formal analysis and effiecient processing of significantly large data size

- Graph-mining as a formal approach to discover operationalisation and patterns


XML Schema

Graph Metadata

Graph Instance

Attributed Nodes

Attributed Edges

A

B

C

D

E


The Anatomy of Pattern-based Architecture Evolution

LERO© 2011 11

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).


An effective and potentially reusable solution to recurring architecture evolution problems is a

consequence of empirical discovery and not a mere invention.

A pattern can be i) identified as recurrent, ii) specified once and iii) instantiated multiple times

to support potential reuse in architecture evolution

1. Operationalisation

- Atomic

- Composite

- Sequential

2. Dependencies

- Hierarchical

- Sequential

- Order & Inordered

Operationalisation and Dependencies in Change Logs

LERO© 2011


Architecture Change Sequencing

LERO© 2011 13

- TypeEquv (Sx.77, Sy.313) return < true > - TypeEquv (Sx, Sy) return < 1 > - OrdEquv(Sx, Sy) return < false >

Matching Functions


Overview of Pattern Identification Process

LERO© 2011 14

Graph Objects

Apriori-based approach - Breadth First Search

strategy during each iteration to

i) Generate pattern candidates (CP)

ii) Validate pattern candidates from CP’

iii) Occurance frequency of CP’in G

C.

Sequence Length

Sequence Frequencies


Step 1 : Candidate Generation

LERO© 2011 15

1. Input(s) - Change Graph GC, - Min Length of Candidate minLen(CP), - Max Length of Candidate maxLen(CP) 2. Processing s1: start iteration at root ← GC .getRoot() s2: while minLen(CP) ≤ CandidateLength ≤ maxLen(CP) s3: get candidate list buff(CP ) ← < cp1(n1.n2); cp2(n2.n3);…; cp7(n3:n4:n5)> s4: allow node matching [TypeEquv(ni, nj)]

nodeMatching(ni, nj) : ni.opr 𝑚𝑎𝑡𝑐ℎ

nj.opr ^ ni.ae 𝑚𝑎𝑡𝑐ℎ

nj.ae 3. Output(s) A list of generated candidates List(CP)

candidateGeneration()


Step 2 : Candidate Validation

LERO© 2011 16

1. Input(s) - Pattern Candidate cp ⊆ GC, - Min Length of Candidate minLen(CP), - Max Length of Candidate maxLen(CP) 2. Processing s1: set isValid ← false s2: iterate while node ← 0 to node ≤ cp.length() s3: validate if lookUp(cp.node.AE) == true return <true> s4: otherwise return <false> 3. Output(s) - A boolean <true/false> value indicating a valid/invalid candidate

candidateValidation()


Step 3 : Pattern Matching

LERO© 2011 17

1. Input(s) - Change Graph GC, - Min Length of Candidate minLen(CP), - Max Length of Candidate maxLen(CP) 2. Processing s1: start iteration at root ← GC .getRoot() s2: while minLen(CP) ≤ CandidateLength ≤ maxLen(CP) s3: get candidate list buff(CP ) ← < cp1(n1.n2); cp2(n2.n3);…; cp7(n3:n4:n5)> s4: allow node matching [TypeEquv(ni, nj)]

nodeMatching(ni, nj) : ni.opr 𝑚𝑎𝑡𝑐ℎ

nj.opr ^ ni.ae 𝑚𝑎𝑡𝑐ℎ

nj.ae 3. Output(s) A list of generated candidates List(CP)

patternMatch()


Identified Pattern Types

LERO© 2011 18

A pre-defined Pattern Classification types CLS =< Inclusion, Exclusion, Replacement >


An Identified Pattern Instance : Co-related Inclusion

LERO© 2010 19

Name, Intent, Context

Architecture Elements

Operationalisation


Algorithmic Analysis

LERO© 2011 20

- Linear Growth, Pattern Instances ∝ 1/Frequency

- Parameterisations Vital for Frequency Threshold, Graph Size, Minimum and Maximum Pattern Lengths.


Tool Support

Possible Limitations

- Architecture Type: beyond a pre-defined architecture model is not evaluated yet.

- Change Anti-patterns: resulting from counter-productive pattern-based evolution.

G-Pride Pat-Lib


Future Work

The notion of a change pattern language

- Semantic relationships among patterns that exist in the catalogue

- Exploiting pattern-level vocabulary to address common evolution tasks.

Architectural transformation by means of instantiating change patterns.

- Allow architects to model and execute generic and potentially reusable solution to recurring architecture

evolution problems.

- A graph-transformation system to support architecture evolution guided by change patterns.

- A prototype (Pat-Evol) shall allow a experimental data to evaluate the adequacy and applicability of the

proposed solution in a practical context.


Thank you for your attention.

Technology

Graph Pattern Identification