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

Slides:



Advertisements
Similar presentations
Computer Systems & Architecture Lesson 2 4. Achieving Qualities.
Advertisements

Quality Attributes Or, what’s wrong with this: Exterminator kit – place bug on block, strike with mallet.
Lecture 13 Enterprise Systems Development ( CSC447 ) COMSATS Islamabad Muhammad Usman, Assistant Professor.
Incorporating Fault Tolerance and Reliability in Software Architectures Ingrid Buckley 01/15/09.
Lecturer: Sebastian Coope Ashton Building, Room G.18 COMP 201 web-page: Lecture.
© 2005 Prentice Hall7-1 Stumpf and Teague Object-Oriented Systems Analysis and Design with UML.
Lecture 23: Software Architectures
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 11 Slide 1 Architectural Design.
Architectural Design Principles. Outline  Architectural level of design The design of the system in terms of components and connectors and their arrangements.
1 CS115 Class 7: Architecture Due today –Requirements –Read Architecture paper pages 1-15 Next Tuesday –Read Practical UML.
Principles of Software Architecture Evaluation and Design
1 FM Overview of Adaptation. 2 FM RAPIDware: Component-Based Design of Adaptive and Dependable Middleware Project Investigators: Philip McKinley, Kurt.
Course Instructor: Aisha Azeem
Chapter 2 Client Server Architecture
Architectural Design Establishing the overall structure of a software system Objectives To introduce architectural design and to discuss its importance.
Chapter 6: Architectural Design
System Design & Software Architecture
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 11 Slide 1 Architectural Design.
Instructor: Tasneem Darwish1 University of Palestine Faculty of Applied Engineering and Urban Planning Software Engineering Department Software Systems.
Achieving Qualities 1 Võ Đình Hiếu. Contents Architecture tactics Availability tactics Security tactics Modifiability tactics 2.
Chapter 10 Architectural Design
© Drexel University Software Engineering Research Group (SERG) 1 Based on the paper by Philippe Kruchten from Rational Software.
Chapter 7: Architecture Design Omar Meqdadi SE 273 Lecture 7 Department of Computer Science and Software Engineering University of Wisconsin-Platteville.
Architectural Design portions ©Ian Sommerville 1995 Establishing the overall structure of a software system.
An Introduction to Design Patterns. Introduction Promote reuse. Use the experiences of software developers. A shared library/lingo used by developers.
Architectural Design To explain the advantages and disadvantages of different distributed systems architectures To discuss client-server and distributed.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 1 Architectural Design l Establishing the overall structure of a software system.
SAMANVITHA RAMAYANAM 18 TH FEBRUARY 2010 CPE 691 LAYERED APPLICATION.
Architecture styles Pipes and filters Object-oriented design Implicit invocation Layering Repositories.
© 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 1 Architectural Styles.
To achieve a level 3 your work must show that: With some help you can gather information to help with designing your project You can draw suitable ideas.
Architectural Design lecture 10. Topics covered Architectural design decisions System organisation Control styles Reference architectures.
Software Architectural Styles Andrew Midwinter, Mark Mullen, Kevin Wong, Matt Jones 1.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 1 Architectural Design l Establishing the overall structure of a software system.
Architectural Design Yonsei University 2 nd Semester, 2014 Sanghyun Park.
Advanced Computer Networks Topic 2: Characterization of Distributed Systems.
SOFTWARE DESIGN AND ARCHITECTURE LECTURE 05. Review Software design methods Design Paradigms Typical Design Trade-offs.
Design Process for Architecture. Architectural Lifecycle Not all lifecycle plans support Architecture! It is hard to achieve architecture based design.
| 1 › Matthias Galster, University of Groningen, NL › Armin Eberlein, American University of Sharjah, UAE Facilitating Software Architecting by.
Early Availability Requirements Modeling using Use Case Maps KAMARUL ZAMAN BIN PANATIK MAN
Unit 2 Architectural Styles and Case Studies | Website for Students | VTU NOTES | QUESTION PAPERS | NEWS | RESULTS 1.
John D. McGregor Class 4 – Initial decomposition
James Martin CpE 691 February 4,  Problem Overview  The pattern solution  Comparing patterns and decision  The pattern-decision relationship.
Software Architecture Evaluation Methodologies Presented By: Anthony Register.
1 Software Engineering: A Practitioner’s Approach, 6/e Chapter 10a: Architectural Design Software Engineering: A Practitioner’s Approach, 6/e Chapter 10a:
Project 2 Presentations CS554 – Designs for Software and Systems Team HAND – Seokin Hong, Gieil Lee, Jesung Kim, Yebin Lee Department of Computer Science,
Chapter 7: Architectural Design Chapter 11 in textbook 1.
©Ian Sommerville, Robin Abraham 2004CS 361, Summer 2004 Slide 1 Architectural Design.
Distributed System Architectures Yonsei University 2 nd Semester, 2014 Woo-Cheol Kim.
1 5/18/2007ã 2007, Spencer Rugaber Architectural Styles and Non- Functional Requirements Jan Bosch. Design and Use of Software Architectures. Addison-Wesley,
Software Architecture Transformation Jan Bosch Professor of Software Engineering University of Groningen, Netherlands
CS223: Software Engineering Lecture 14: Architectural Patterns.
Slide 1 Chapter 8 Architectural Design. Slide 2 Topics covered l System structuring l Control models l Modular decomposition l Domain-specific architectures.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 1 Chapter 5:Architectural Design l Establishing the overall structure of a software.
Dr D. Greer, Queens University Belfast ) Software Engineering Chapter 7 Software Architectural Design Learning Outcomes Understand.
Architecture Brief Pepper
Software Engineering Architectural Design Chapter 6 Dr.Doaa Sami
Software Design and Architecture
CHAPTER 2 CREATING AN ARCHITECTURAL DESIGN.
Ch > 28.4.
Design Process for Architecture
Chapter 5 Designing the Architecture Shari L. Pfleeger Joanne M. Atlee
Quality Attributes Or, what’s wrong with this:
A Pattern Language for Software Architecture
Fault Tolerance Distributed Web-based Systems
Software Architecture
Quality Attributes Or, what’s wrong with this:
Design Process for Architecture
Design Process for Architecture
Quality Attributes Or, what’s wrong with this:
Presentation transcript:

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

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

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

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

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

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

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

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

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

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- + +~

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

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

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

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