Vakgroep Informatietechnologie – IBCN Software Architecture Prof.Dr.ir. F. Gielen Quality Attributes & Tactics (1)

Slides:



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

Configuration management
Chapter 19: Network Management Business Data Communications, 5e.
Vakgroep Informatietechnologie – IBCN Software Architecture Prof.Dr.ir. F. Gielen Quality Attributes & Tactics (2) Performance.
Software Architecture in Practice (3 rd Ed) Understanding Quality Attributes Understanding the following: How to express the qualities we want our architecture.
Software Architecture Prof.Dr.ir. F. Gielen
ITIL: Service Transition
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.
Management of IT Environment (5) LS 2012/ Martin Sarnovský Department of Cybernetics and AI, FEI TU Košice ITIL:Service Design IT Services Management.
Snejina Lazarova Senior QA Engineer, Team Lead CRMTeam Dimo Mitev Senior QA Engineer, Team Lead SystemIntegrationTeam Telerik QA Academy Telerik QA Academy.
Chapter 19: Network Management Business Data Communications, 4e.
Instructor: Tasneem Darwish
CS 582 / CMPE 481 Distributed Systems Fault Tolerance.
1 CSSE 377 – Intro to Availability & Reliability Part 2 Steve Chenoweth Tuesday, 9/13/11 Week 2, Day 2 Right – Pictorial view of how to achieve high availability.
The Architecture Design Process
1 ITC242 – Introduction to Data Communications Week 12 Topic 18 Chapter 19 Network Management.
CS-550 (M.Soneru): Recovery [SaS] 1 Recovery. CS-550 (M.Soneru): Recovery [SaS] 2 Recovery Computer system recovery: –Restore the system to a normal operational.
Evaluating Software Architectures RiSE’s Seminars Clement’s book :: Chapters 05 Eduardo Cruz.
Vakgroep Informatietechnologie – IBCN Software Architecture Prof.Dr.ir. F. Gielen Quality Attributes & Tactics (4) Modifiability.
Lesson 1: Configuring Network Load Balancing
Principles of Software Architecture Evaluation and Design
11 MAINTAINING THE OPERATING SYSTEM Chapter 5. Chapter 5: MAINTAINING THE OPERATING SYSTEM2 CHAPTER OVERVIEW Understand the difference between service.
Introduction to Databases Transparencies 1. ©Pearson Education 2009 Objectives Common uses of database systems. Meaning of the term database. Meaning.
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.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 18 Slide 1 Software Reuse.
Chapter 9 Database Planning, Design, and Administration Sungchul Hong.
Business Continuity and Disaster Recovery Chapter 8 Part 2 Pages 914 to 945.
FMEA-technique of Web Services Analysis and Dependability Ensuring Anatoliy Gorbenko Vyacheslav Kharchenko Olga Tarasyuk National Aerospace University.
1 Computer Systems & Architecture Lesson 2 3. Understanding Quality Attributes.
Version 4.0. Objectives Describe how networks impact our daily lives. Describe the role of data networking in the human network. Identify the key components.
An Introduction to Software Architecture
Chapter Fourteen Windows XP Professional Fault Tolerance.
Chapter 8 Implementing Disaster Recovery and High Availability Hands-On Virtual Computing.
Quality Attributes Often know as “–ilities” …
Chapter 2: Non functional Attributes.  It infrastructure provides services to applications  Many of these services can be defined as functions such.
Event Management & ITIL V3
SOFTWARE SYSTEMS DEVELOPMENT 4: System Design. Simplified view on software product development process 2 Product Planning System Design Project Planning.
Mark A. Magumba Storage Management. What is storage An electronic place where computer may store data and instructions for retrieval The objective of.
Advanced Computer Networks Topic 2: Characterization of Distributed Systems.
Business Data Communications, Fourth Edition Chapter 11: Network Management.
Software System Architecture Software System Architecture Chapter 6:Air Traffic Control: A Case Study in Designing for High Availability. Chapter 6:Air.
Early Availability Requirements Modeling using Use Case Maps KAMARUL ZAMAN BIN PANATIK MAN
Air Traffic Control Guy Mark Lifshitz Sevan Hanssian.
INTRUSION DETECTION SYSYTEM. CONTENT Basically this presentation contains, What is TripWire? How does TripWire work? Where is TripWire used? Tripwire.
1 Software Architecture in Practice Quality attributes (The amputated version)
Cloud Computing and Architecture Architectural Tactics (Tonight’s guest star: Availability)
1 Advanced Software Architecture Muhammad Bilal Bashir PhD Scholar (Computer Science) Mohammad Ali Jinnah University.
Network management Network management refers to the activities, methods, procedures, and tools that pertain to the operation, administration, maintenance,
Teknologi Pusat Data 12 Data Center Site Infrastructure Tier Standard: Topology Ida Nurhaida, ST., MT. FASILKOM Teknik Informatika.
1 Software Architecture in Practice Architectural Design (Again, the amputated version)
Dr. Awais Majeed Achieving Quality CSE 861- Software System Design & Architecture.
Chapter 9 Database Planning, Design, and Administration Transparencies © Pearson Education Limited 1995, 2005.
Lecture 11. Switch Hardware Nowadays switches are very high performance computers with high hardware specifications Switches usually consist of a chassis.
1 Advanced Software Architecture Muhammad Bilal Bashir PhD Scholar (Computer Science) Mohammad Ali Jinnah University.
Chapter 5: Availability © Len Bass, Paul Clements, Rick Kazman, distributed under Creative Commons Attribution License.
ITIL: Service Transition
Chapter 19: Network Management
Software Architecture in Practice
Managing Multi-User Databases
CSCE 742 Software Architectures
ITIL:Service Design IT Services Management Martin Sarnovský
QNX Technology Overview
Quality Attributes Or, what’s wrong with this:
Fault Tolerance Distributed Web-based Systems
Quality Attributes Or, what’s wrong with this:
An Introduction to Software Architecture
Abstractions for Fault Tolerance
Quality Attributes Or, what’s wrong with this:
Presentation transcript:

Vakgroep Informatietechnologie – IBCN Software Architecture Prof.Dr.ir. F. Gielen Quality Attributes & Tactics (1)

Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 2 Quality Attributes Software Architecture and... Quality Attributes. Quality Attribute Tactics. Architecture Patterns Quality is ‘value as perceived by the customer’. Over and above the definition of customer features, quality attributes clarify which items are most important to the customer's perception of the product's quality and performance.

Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 3 Architecture and Functionality Functionality is about features, capabilities, services and behaviour. can be achieved through any number of structures. often the ONLY consideration at the start of a project and leads to redesign, project cancelation,…  to slow  not portable  hard to maintain The mapping of the system’s functionality onto software structures is critical for the support of quality.

Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 4 The origins of complexity Functionality needs to be mapped to software structures in order to support the quality. This mapping requires the collaboration, communication, synchronisation of these software elements in order to provide the functionality.

Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 5 Qualities in Software Architecture System Qualities Functionality Business Qualities Architectural Qualities Software Architecture Modifiability Performance Testability Availability Security Usability Scalability Interoperability Portability Capabilities Functions Services Behaviour Cost Margins Time-to-market Target market System lifetime Conceptual Integrity Correctness Completeness Buildability

System Qualities in practice: SLA : Service Level Agreement A service-level agreement (SLA) is a contract between a (network) service provider and a customer that specifies, usually in measurable terms, what services provider will furnish. SLA’s may specify :  What percentage of the time services will be available  The number of users that can be served simultaneously  Specific performance benchmarks to which actual performance will be periodically compared.  Help desk response time  Usage statistics that will be provided. Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 6

SLA terms (1) Guaranteed uptime The User is able to access the service through different devices. The expected availability of the Platform is 99.8% or with periods of unavailability of maximum 2 (two) hours per month. Recovery In case of system failure, the application and all data shall be restored within 4 hours after problem fixation. Backup tapes will be stored to a separate building or at least to a separate and secure room. Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 7

SLA Terms (2) Performance The target response time to any request should be respected in 90% of all requests. Mobile internet browsing: full page download time inferior to 3 seconds Capacity The installation will be planned for a maximum of requests per day. Maintainability The servers are monitored on a 24x7 schedule. If a major failure is detected the Provider will send an automatic alarm (SNMP trap) to the network management centre, so that the alarm can be included in the existing monitoring system. Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 8

Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 9 Business Qualities that shape architecture Time to Market: Build or buy Re-use existing elements from previous projects COTS/OSS :Time to market is often reduced by using prebuilt elements such as commercial off-the-shelf or open source components. Deploy a subset : The ability to insert or deploy a subset of the system depends on the decomposition of the system into elements. (roll-out schedule)

Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 10 Business Qualities that shape architecture Cost and Benefit: The development budget must not be exceeded. Different architectures will yield different development costs.  An architecture that relies on new technology will be more expensive  Flexible architecture cost more to build but will be less costly to maintain and modify System lifetime: If the system is intended to have a long lifetime, modifiability, scalability, and portability become important. ( = more revenue) Building in the additional infrastructure (such as a layer to support portability) will usually compromise time to market.

Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 11 The Quality state-of-mind Quality is not the privilege of Architects: it needs to be considered throughout the entire lifecycle (design, implementation, deployment) But: Architecture is critical to the realisation of many qualities. And Architecture cannot achieve quality by itself. Qualities can never be achieved in isolation.

Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 12 Quality Attribute Scenarios Qualities are abstract and non-operational:  What does it mean for a system to be modifiable ? Quality attribute requirements are captured with quality scenarios.  Generic scenarios (system independent) need to be translated into specific scenarios

Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 13 Example: Modifiability scenario

Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 14 System Quality Attributes Availability Modifiability Performance Testability Security Usability

Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 15 Availability Faults & Failures : Faults become failures if not corrected or masked. A failure is observable by the system user; a fault not. Areas of concern: Fault detection and frequency Reduced operations Recovery and Prevention Availability is about system failure and its consequences. Availability = MTBF MTBF + MTTR

Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 16 Availability Generic Scenario

Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 17 Availability scenario generation (1/3) Source of stimulus: We differentiate between internal and external indications of faults or failure since the desired system response may be different. Stimulus: A fault of one of the following classes occurs. Omission. A component fails to respond to an input. Crash. The component repeatedly suffers omission faults. Timing. A component responds but the response is early or late. Bad response. A component responds with an incorrect value. Artifact: This specifies the resource that is required to be highly available Processor, Communication channel, Process, Storage.

Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 18 Availability scenario generation (2/3) Environment. The state of the system affects the desired system response. Normal mode: if this is the first fault observed, some degradation of response time or function may be preferred Degraded mode: if the system has already seen some faults it may be desirable to shut it down totally.

Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 19 Availability scenario generation (3/3) Response. The System should detect the event : Record it Notify appropriate parties, including the user and other systems Disable sources of events that cause fault or failure according to defined rules be unavailable for a specified interval, where interval depends on criticality of system Continue to operate in normal or degraded mode

Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 20 Availability scenario generation (2/2) Response measure: Time interval when the system must be available Availability time Time interval in which system can be in degraded mode Repair time

Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 21 Availability Specific Scenario “An unanticipated external message is received by a process during normal operation. The process logs the receipt of the message, notifies the operator and continues with no downtime”

Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 22 Architectural Tactics & Strategies Tactics to Control Response Stimulus Response Tactics are design decisions A tactic is an architectural design decision which influences the control of a quality attribute. Architectural Strategy A collection of tactics that are used in order to meet the system quality requirements. Architecture Pattern A package of tactics

Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 23 Availability Tactics Tactics to Control Availability Fault Fault Masked or Repaired Fault Detection Echo Heartbeat Exceptions Fault Recovery Preparing for recovery Accomplishing the recovery Fault Prevention

Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 24 Fault Recovery Tactics (1/4) Voting Tactic: Processes running on redundant processors each take the input, compute and report the results to the “vote-counter.”  Majority rules  Preferred Component Preferred component:  This corrects faulty operation of components, algorithms or processors.  The more severe the consequences of failures the more stringent the effort to ensure that the redundancy is independent. –Separate processors, separate implementation teams, … dissimilar platforms

Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 25 Fault Recovery Tactics (2/4) Active redundancy (hot restart): All redundant components respond to events in parallel Redundant components synchronized at start then first to return is the answer. This covers some faults. A faulty processor will be slower to respond. When a failure occurs the downtime is usually only milliseconds (switching to another component). Often used in client-server applications involving back- end Databases. In high availability for LANs the redundancy may be separate paths so that failure of a bridge or router is not fatal. Note the synchronization demands here.

Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 26 Fault Recovery Tactics (3/4) Passive Redundancy: One component responds to events and informs the standbys of state updates. Upon failure the system must: Ensure that the backup is sufficiently fresh. Restart points, checkpoints, log points ??? Remap the system to switch which system is the active component. Often used in control systems Example : Air traffic Control

Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 27 Fault Recovery Tactics (4/4) Switchovers Upon failure or Periodic Synchronization: is the responsibility of the primary component, broadcasting synchronization signals to the redundant components.

Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 28 Other tactics... Spare: a standby system configured to replace many different failed components. (maybe everything but network) Shadow operation: when a previously failed component is run in “shadow mode” comparing its results with a trusted system before restoring it to service State synchronization: failed systems need their state restored Checkpoint/rollback

Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 29 Fault Prevention Tactics Removal from service To perform some preventive actions, e.g., rebooting to prevent slow memory leaks from causing problems Transactions the bundling of a sequence of steps so that they can be done all at once Process monitor Once a fault in a process is detected;  remove–reinstantiate-reinitialize state

Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 30 Availability Tactics Hierarchy Availability Ping/echo Heartbeat Exception Voting Active red. Passive red. Spare Removal from Service Transactions Process Monitor Shadow State resync. Rollback Recovery Preparation and repair Fault detection Recovery Reintroduction Prevention Fault Masked or Repaired Fault Arrives