Graph Pattern Identification

388 views
261 views

Published on

Graph-based Pattern Identification from Architecture Change Logs.

Published in: Technology, Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
388
On SlideShare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
6
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Graph Pattern Identification

  1. 1. 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
  2. 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. 2LERO© 2011 THE IRISH SOFTWARE ENGINEERING RESEARCH CENTRE
  3. 3. 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] 3LERO© 2011 THE IRISH SOFTWARE ENGINEERING RESEARCH CENTRE
  4. 4. Change Patterns to guide Architecture EvolutionCentral 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 LERO© 2011 THE IRISH SOFTWARE ENGINEERING RESEARCH CENTRE
  5. 5. 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 5LERO© 2011 THE IRISH SOFTWARE ENGINEERING RESEARCH CENTRE
  6. 6. Log-based Analysis of Architecture ChangeArchitecture Change Logs (ACL) as a knowledge base provide us with a transparent and centrallymanageable 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 LERO© 2010 THE IRISH SOFTWARE ENGINEERING RESEARCH CENTRE
  7. 7. 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 7LERO© 2011 THE IRISH SOFTWARE ENGINEERING RESEARCH CENTRE
  8. 8. 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 8LERO© 2010 THE IRISH SOFTWARE ENGINEERING RESEARCH CENTRE
  9. 9. 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 9LERO© 2010 THE IRISH SOFTWARE ENGINEERING RESEARCH CENTRE
  10. 10. A XML Schema B Graph Metadata C Graph Instance D Attributed Nodes E Attributed Edges 10LERO© 2010 THE IRISH SOFTWARE ENGINEERING RESEARCH CENTRE
  11. 11. 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
  12. 12. 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 & InorderedLERO© 2011 THE IRISH SOFTWARE ENGINEERING RESEARCH CENTRE
  13. 13. Architecture Change Sequencing Matching Functions - TypeEquv (Sx.77, Sy.313)  return < true > - TypeEquv (Sx, Sy)  return < 1 > - OrdEquv(Sx, Sy)  return < false > 13LERO© 2011 THE IRISH SOFTWARE ENGINEERING RESEARCH CENTRE
  14. 14. Overview of Pattern Identification ProcessApriori-based approach - Breadth First Searchstrategy 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 LengthSequence Frequencies 14LERO© 2011 THE IRISH SOFTWARE ENGINEERING RESEARCH CENTRE
  15. 15. 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) 15LERO© 2011 THE IRISH SOFTWARE ENGINEERING RESEARCH CENTRE
  16. 16. Step 2 : Candidate Validation candidateValidation()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/invalidcandidate 16 LERO© 2011 THE IRISH SOFTWARE ENGINEERING RESEARCH CENTRE
  17. 17. Step 3 : Pattern Matching patternMatch()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.ae3. Output(s) A list of generated candidates List(CP) 17LERO© 2011 THE IRISH SOFTWARE ENGINEERING RESEARCH CENTRE
  18. 18. Identified Pattern Types A pre-defined Pattern Classification types CLS =< Inclusion, Exclusion, Replacement > 18LERO© 2011 THE IRISH SOFTWARE ENGINEERING RESEARCH CENTRE
  19. 19. An Identified Pattern Instance : Co-related Inclusion Name, Intent, ContextOperationalisation Architecture Elements 19 LERO© 2010 THE IRISH SOFTWARE ENGINEERING RESEARCH CENTRE
  20. 20. Algorithmic Analysis - Linear Growth, Pattern Instances ∝ 1/Frequency - Parameterisations Vital for Frequency Threshold, Graph Size, Minimum and Maximum Pattern Lengths. 20LERO© 2011 THE IRISH SOFTWARE ENGINEERING RESEARCH CENTRE
  21. 21. 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. 21LERO© 2011 THE IRISH SOFTWARE ENGINEERING RESEARCH CENTRE
  22. 22. Future WorkThe 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 LERO© 2011 THE IRISH SOFTWARE ENGINEERING RESEARCH CENTRE
  23. 23. Thank you for your attention. 23LERO© 2011 THE IRISH SOFTWARE ENGINEERING RESEARCH CENTRE

×