architecture knowledge

THE IRISH SOFTWARE ENGINEERING RESEARCH CENTRE

Welcome Presentation Title

Graph-based Implicit Knowledge Discovery

from Architecture Change Logs

Aakash Ahmad, Pooyan Jamshidi, Muteer Arshad and Claus Pahl

[email protected]

Software and System Engineering group

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

School of Computing, Dublin City University, Ireland


Agenda

- Architecture Change Mining and Change Execution

- Log-based Analysis of Architecture Change Instances

- Change Instance Formalisation

- Discovering Operationalisation, Dependencies and Patterns

- Change Pattern Graph

- Conclusions & Outlook

LERO© 2010 2

THE IRISH SOFTWARE ENGINEERING RESEARCH CENTRE LERO© 2011 3

Architecture Change Mining & Change Execution

How to exploit the architecture evolution history that allows us to foster potentially

reusable operationalisation and patterns to guide architecture evolution?


Log-based Analysis of Architecture Change

LERO© 2010 4

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

- Empirical Analysis of Change Instances

EBPP and TRS case studies


Graph-based Formalisation of Change Instances

LERO© 2010 5

- Formal analysis and effiecient processing of significantly large data size

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


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


Towards a System-of-Evolution-Patterns?

LERO© 2011 7

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


Pattern-based Architecture Evolution

LERO© 2010 8

Step 1: Architecture Change Specification.

Step 2: Change Pattern Retrieval

Step 3: Change Pattern Instantiation


Graph-based Change Pattern Notation

LERO© 2011 11

Pattern Specification – as an attributed typed Graph (.GML) notation.

Pattern Storage – Graph databse using Neo4j graph tuples.


Step 2: Change Pattern Retrieval

LERO© 2010 12

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


Experimental Analysis & Evaluation

LERO© 2010 13

1 Scenario-based Evaluation - EBPP & TRS Evolution Cases

- Pattern Types & Adequacy

2 Prototype-based Validation - Automated Pattern-based Evolution

- Survey & Usability Analysis

architecture knowledge

Technology