Presentation is loading. Please wait.

Presentation is loading. Please wait.

9/2/2015 | 1 Neil B. Harrison Paris Avgeriou University of Groningen Groningen, The Netherlands Incorporating Fault Tolerance Tactics in Software Architecture.

Similar presentations


Presentation on theme: "9/2/2015 | 1 Neil B. Harrison Paris Avgeriou University of Groningen Groningen, The Netherlands Incorporating Fault Tolerance Tactics in Software Architecture."— Presentation transcript:

1 9/2/2015 | 1 Neil B. Harrison Paris Avgeriou University of Groningen Groningen, The Netherlands Incorporating Fault Tolerance Tactics in Software Architecture Patterns

2 9/2/2015 | 2 Background: Architecture Patterns ›Commonly used system-level designs ›Well-known, use common names: Layers Pipes and Filters Model-View Controller ›Most systems have architecture patterns Even if they weren’t intentionally used

3 9/2/2015 | 3 Fault Tolerance Tactics ›Tactics – ways to implement aspects of fault tolerance ›Fault Tolerance Tactic categories (as defined by SEI): Fault Detection Fault Recovery: Preparation and Repair Fault Recovery: Reintroduction Prevention ›Tactics and Architecture Patterns: Tactics are implemented within the architecture pattern structure

4 9/2/2015 | 4 Implementing FT Tactics ›Implementing a tactic affects the system’s architecture A little or a lot! Making it easy or hard to implement fault tolerance correctly ›Therefore, we studied the impact of tactics on architecture patterns In detail! So we can make better architecture decisions, e.g.: Which patterns to use Which tactics to use

5 9/2/2015 | 5 Details: Why and What? ›Why: Patterns often indicate high level suitability for fault tolerance But impact is different, depending on the tactic So more granularity is needed ›What kind of details? Focus on how much must the pattern change Structure and behavior

6 9/2/2015 | 6 Changes to Pattern Components Type of changeDescriptionImpact on Pattern Implemented inTactic at least partly implemented in existing component No change to pattern structure ReplicatesDuplicates a component Small changes; easy to implement Add, In PatternAdd component without changing basic pattern structure Moderately easy to implement Add, Not in PatternAdd component that changes pattern form Major changes; much work ModifyBehavior of component changes Impact varies; easy to hard

7 9/2/2015 | 7 Changes to Pattern Connectors Change to a ComponentCorresponding change to connectors Implemented inNo change ReplicatesAdd connectors to/from replicated components Add, in the patternAdd connectors, similar to existing connectors Add, out of the patternNew connectors, outside existing pattern structure ModifyMay add new or change existing connectors

8 9/2/2015 | 8 Quantifying Impact on Patterns ›Create a relative scale of difficulty ›Every Pattern/Tactic implementation must be considered individually, but guidelines are: + None or very minor modifications needed; implemented in +Small structural or behavioral changes ~Pattern and tactic basically independent -Substantial behavioral or structural changes - Pattern may become hard to recognize

9 9/2/2015 | 9 Ease of Tactic Implementation (Sample) Recovery – Reintroduction Tactics + +~-- Voting25400 Active Redundancy45110 Passive Redundancy25220 Spare12521

10 9/2/2015 | 10 Patterns and Implementing Tactics Pattern+ +~-- Broker102100 State Transition82300 Layers37300 Client-Server28300 Shared Repository60610 Microkernel42700 Model-View Controller02920 Presentation-Abstraction C.02920 Blackboard03622 Reflection01831 Pipes and Filters22135

11 9/2/2015 | 11 Tactic Groups, Best Case Pattern Fault Detection Recovery: preparation Recovery: reintroduction Prevention Broker+ State Transition+ Layers+ + Client-Server+++ Shared Repository+ Microkernel+ ~ MVC~++~ PAC~+++ Blackboard+++- Reflection~-~+ Pipes and Filters- + +~

12 9/2/2015 | 12 Using the Data ›Deciding which architecture pattern to use Consider alternatives (e.g., Broker vs. Client- Server) Only one of many factors ›Deciding which tactics to implement Consider alternative tactics ›Understand implementation implications For tradeoffs (above) For implementing the tactics

13 9/2/2015 | 13 Sample Tactic Implementation Details ›Tactic: Ping/Echo (Fault Detection) ›Pipes and Filters: (rating: - -) A central monitoring process must be added to communicate with each filter. Each filter must be modified to respond quickly to the ping messages. Affects the structure of the pattern and may conflict with realtime performance. (summary) Add out of the Pattern, along with moderate changes to each filter component

14 9/2/2015 | 14 Future Work ›More patterns and tactics Other Architecture patterns Other Fault Tolerance tactics ›Interactions of combinations of: Multiple Tactics Multiple Patterns Multiple Quality Attributes ›Investigate behavior in more depth E.g., Ping-echo has time-sensitive messages

15 9/2/2015 | 15 Thank you for your attention


Download ppt "9/2/2015 | 1 Neil B. Harrison Paris Avgeriou University of Groningen Groningen, The Netherlands Incorporating Fault Tolerance Tactics in Software Architecture."

Similar presentations


Ads by Google