Graph Pattern Identification

Graph-based Pattern Identification
Welcome
from Architecture Change Logs
Presentation Title
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

THE IRISH SOFTWARE ENGINEERING RESEARCH CENTRE

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.

2
LERO© 2011 THE IRISH SOFTWARE ENGINEERING RESEARCH CENTRE

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]

3

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.
Pattern-based Evolution Benefits for Pattern-based Reuse

4

Related Research - Patterns and Evolution
Evolution in SOAs? Patterns in Architectural Abstractions?
Evolution 1Patterns Process Change Patterns
Repository Paths Process-centric Evolution

Evolution Shelf Evolution Styles Process Change Patterns Process Mining and Evolution

MESOA’07’08’09’10

Maintenance, Evolution, Adaptation
Reuse of Evolution in SOAs
5

Log-based Analysis of Architecture Change
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 ACL =< AC1,AC2, . . . ,ACN >
Completeness, Granularity of Change, etc.

- Log Data Classification
Change Data & Auxiliary Data

- Architecture Change Instances
EBPP and TRS case studies

6

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

7

Solution Overview

1. The Pre-processing Approach
- Capturing Change Instances
- Log Data Classification
- Change Instance Formalisation

2. Log Data Analysis
- Change Operationalisation
- Operational Dependencies
- Pattern Identification

8

Graph-based Formalisation of Change Instances
- 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

9

A
XML Schema

B
Graph Metadata
C
Graph Instance

D
Attributed Nodes

E
Attributed Edges

10

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
11
THE IRISH SOFTWARE ENGINEERING RESEARCH CENTRE

Operationalisation and Dependencies in Change Logs
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

Architecture Change Sequencing

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

13

Overview of Pattern Identification Process

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

Graph Objects

Sequence Length

Sequence Frequencies

14

Step 1 : Candidate Generation
candidateGeneration()
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)

15

Step 2 : Candidate Validation
candidateValidation()
1. Input(s)
- Pattern Candidate cp ⊆ GC,

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

16

Step 3 : Pattern Matching
patternMatch()
1. Input(s)
- Change Graph GC,

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)

17

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

18

An Identified Pattern Instance : Co-related Inclusion

Name, Intent, Context

Operationalisation
Architecture Elements

19

Algorithmic Analysis

- Linear Growth, Pattern Instances ∝ 1/Frequency
- Parameterisations Vital for Frequency Threshold, Graph Size, Minimum and Maximum Pattern Lengths.

20

Tool Support
G-Pride Pat-Lib

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

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

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.

22

Thank you for your attention.

23

Graph Pattern Identification

Recomendados

Recomendados

Mais conteúdo relacionado

Semelhante a Graph Pattern Identification

Semelhante a Graph Pattern Identification (20)

Último

Último (20)

Graph Pattern Identification