Your SlideShare is downloading. ×
Pattern-based Evolution
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Introducing the official SlideShare app

Stunning, full-screen experience for iPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Pattern-based Evolution

132
views

Published on

Pattern-driven Reuse in Architecture-centric Evolution for Service Software. (ICSOFT'12)

Pattern-driven Reuse in Architecture-centric Evolution for Service Software. (ICSOFT'12)

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
132
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
2
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 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 2LERO© 2010 THE IRISH SOFTWARE ENGINEERING RESEARCH CENTRE
  • 3. Evolution in Service-driven ArchitecturesService-Oriented Architecture (SOA) is a business-centric, architectural approach to modelbusiness 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 connectorsEvolution in an SOA goes beyond a more conventional addition or removal of individualcomponents 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. 3LERO© 2011 THE IRISH SOFTWARE ENGINEERING RESEARCH CENTRE
  • 4. The needs for Reuse in Service Architecture EvolutionA continuous change in business and technical requirements lead towards frequentmaintenance 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] 4LERO© 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 5LERO© 2011 THE IRISH SOFTWARE ENGINEERING RESEARCH CENTRE
  • 6. Change Patterns to guide Architecture EvolutionCentral 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 9LERO© 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 10LERO© 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 11LERO© 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. 12LERO© 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  GIAdd<getType ∈ CON>- Removal Rem<billingData ∈ CON>. GS S GI T GT   13LERO© 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 14LERO© 2010 THE IRISH SOFTWARE ENGINEERING RESEARCH CENTRE
  • 15. RecapDiscover Evolution Pattern- prototype: G-Pride Pat-Evol ProjectMaintain Pattern Library- prototype: Pat-LibReuse Change Execution- prototype: Pat-Evol THE IRISH SOFTWARE ENGINEERING RESEARCH CENTRE
  • 16. Thank you for your attention. 16LERO© 2011 THE IRISH SOFTWARE ENGINEERING RESEARCH CENTRE