Quality Attributes Or, what’s wrong with this:

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.
Intraship Integration Control Instructor: TV Prabakar.
Software Architecture for DSD DSD Team. Overview What is software architecture and why is it so important? The role of architecture in determining system.
Software Connectors. Attach adapter to A Maintain multiple versions of A or B Make B multilingual Role and Challenge of Software Connectors Change A’s.
The Architecture Design Process
1 Exercise a short summary of you so your professor can get to know you better: Name, company, job/role/title, most interesting SE area, any architecting.
An Introduction to Software Architecture Pejman Salehi
Architectural Design Principles. Outline  Architectural level of design The design of the system in terms of components and connectors and their arrangements.
Vakgroep Informatietechnologie – IBCN Software Architecture Prof.Dr.ir. F. Gielen Quality Attributes & Tactics (4) Modifiability.
Architectural Design Establishing the overall structure of a software system Objectives To introduce architectural design and to discuss its importance.
Oracle High Availability Doug Smith CIS 764 Fall Semester 2007.
Achieving Qualities. Architectural Tactics  A tactic is a design decision that influences the control of a quality attribute response.  A collection.
9/2/2015 | 1 Neil B. Harrison Paris Avgeriou University of Groningen Groningen, The Netherlands Incorporating Fault Tolerance Tactics in Software Architecture.
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.
© Drexel University Software Engineering Research Group (SERG) 1 Based on the paper by Philippe Kruchten from Rational Software.
SOFTWARE DESIGN AND ARCHITECTURE LECTURE 07. Review Architectural Representation – Using UML – Using ADL.
SOFTWARE SYSTEMS DEVELOPMENT 4: System Design. Simplified view on software product development process 2 Product Planning System Design Project Planning.
An Introduction to Software Architecture Software Engineering Lab.
Design Process for Architecture. Architectural Lifecycle Not all lifecycle plans support Architecture! It is hard to achieve architecture based design.
Agenda – week 4 6:00 – 6:05Questions, announcements, intro 6:05 – 6:35Case study – air traffic control 6:35 – 7:20Lecture: architecture in the development.
Software System Architecture Software System Architecture Chapter 6:Air Traffic Control: A Case Study in Designing for High Availability. Chapter 6:Air.
John D. McGregor Class 4 – Initial decomposition
CS551 - Lecture 5 1 CS551 Lecture 5: Quality Attributes Yugi Lee FH #555 (816)
ECE450 - Software Engineering II1 ECE450 – Software Engineering II Today: Introduction to Software Architecture.
Architecture View Models A model is a complete, simplified description of a system from a particular perspective or viewpoint. There is no single view.
1 Software Architecture in Practice Quality attributes (The amputated version)
Cloud Computing and Architecture Architectural Tactics (Tonight’s guest star: Availability)
ANU comp2110 Software Design lecture 8 COMP2110 Software Design in 2004 lecture 8 Software Architecture 1 of 2 (design, lecture 3 of 6) Goal of this small.
1 Advanced Software Architecture Muhammad Bilal Bashir PhD Scholar (Computer Science) Mohammad Ali Jinnah University.
OOD OO Design. OOD-2 OO Development Requirements Use case analysis OO Analysis –Models from the domain and application OO Design –Mapping of model.
1 Software Architecture in Practice Architectural Design (Again, the amputated version)
Vakgroep Informatietechnologie – IBCN Software Architecture Prof.Dr.ir. F. Gielen Quality Attributes & Tactics (1)
1 Advanced Software Architecture Muhammad Bilal Bashir PhD Scholar (Computer Science) Mohammad Ali Jinnah University.
Chapter 7: Modifiability
Software Architecture in Practice
Lecture 9z Case Study ADD: Garage Door
Software Architecture and Quality BY
Outline Types of Databases and Database Applications Basic Definitions
Achieving Qualities.
Presented by Munezero Immaculee Joselyne PhD in Software Engineering
Software Design and Architecture
Design Process for Architecture
Chapter 2 Database Environment Pearson Education © 2009.
Service-centric Software Engineering
Chapter 5 Designing the Architecture Shari L. Pfleeger Joanne M. Atlee
Quality Attributes Or, what’s wrong with this:
Software Architecture in Practice
Introduction to Databases Transparencies
Database Environment Transparencies
Chapter 20 Object-Oriented Analysis and Design
Design Model Like a Pyramid Component Level Design i n t e r f a c d s
Quality Attributes Or, what’s wrong with this:
Architectures of distributed systems Fundamental Models
Architectures of distributed systems Fundamental Models
Design Process for Architecture
Agenda – week 4 6:00 – 6:05 Questions, announcements, intro
PPT and video are due no later than February 15, 2019
Architectures of distributed systems
Software Architecture Lecture 7
Software Architecture Lecture 7
Agenda – week 3 6:00 – 6:30 Documenting an Architecture Project discussion 6:30 – 7:40 Lecture: Qualities vs functionality 7:40 – 8:00 Break 8:00 – 8:20.
Design Yaodong Bi.
Architectures of distributed systems Fundamental Models
Database System Architectures
Software Architecture Lecture 7
Design Process for Architecture
Architectural Mismatch: Why reuse is so hard?
Presentation transcript:

Quality Attributes Or, what’s wrong with this: Exterminator kit – place bug on block, strike with mallet

Functionality vs Quality Attributes

Some Qualities Usability Modifiability Performance Security Testability Availability Time to market Cost and benefit Projected System lifetime Targeted Market Rollout Schedule Integration / Legacy

Architectural Qualities Conceptual Integrity Correctness and Completeness Buildability

Qualities & Trade-offs The qualities are all good The qualities value is project specific The qualities are not independent

Quality Attribute Scenarios Source of stimulus Stimulus Environment Artifact Response Response measure (see inside front cover) In the environment, the source throws the stimulus and hits the system in the artifact

Example from cars Response Measure: Deflection < N% Artifact: Noise < M dB … Artifact: Tires Stimulus: Bumps Environment: Highway driving Source of stimulus: Road Response: Control maintained Smooth ride Low noise

Remember One stimulus per scenario One environment per scenario One artifact per scenario Multiple response measures are OK

Measure: No unauthorized Example from software Response Measure: No unauthorized users, login < 1 min Artifact: User interface Stimulus: Dozens of simultaneous logins Environment: Normal operation Response: Security maintained Acceptable delays Source of stimulus: Shift change

If you remember one thing … To be effective, quality attribute scenarios must be testable (just like any other requirement) Therefore, the Stimulus Artifact Environment Response measure(s) must be clear and specific

Activity: define quality attribute scenarios

Next step Assume some of the critical quality attribute scenarios have been defined What next?

Tactics: how to accomplish a quality attribute scenario Air-filled tires Big old springs Shock absorbers … (I’m no auto engineer)

Tactics for shift change Separate authentication+authorization from environment setup Show progress indicator(s) Precompute expensive structures Defer at-login-time processing to background Thin clients + shared services Deploy workstations Minimize other load on the system at shift change times What BC&K tactics are these?

Tactics for Qualities Tactics are a guide to design! Tactics are design choices oriented toward achieving qualities Tactics can refine other tactics Patterns package tactics Tactics can interfere! Next week: a way to use quality attribute scenarios and tactics to drive module decomposition

Tactics are ways to get the desired response in a scenario Artifact Response Stimulus Environment

Tactics example: performance Introduce concurrency Max delay < 2 sec Database Prompt results 25 req/sec Normal ops

Qualities categorize tactics Fault Masked or Repair Made Fault Detected (not enough by itself) Availability Fault

Availability Recovery Prep and Repeat Fault Detection Recovery- Reintroduction Prevention Removal from service Transactions Process Monitor Voting Active Redundancy Passive Spare Shadow State ReSync Rollback Echo Ping Exception

Tactics can interfere with each other Modifiability: use an intermediary Performance: reduce computational overhead Modifiability/Performance conflicts are common

Patterns package tactics An architectural pattern usually applies a set of compatible tactics Better yet, mutually reinforcing tactics Or at least, the pattern may give advice on balancing tactics that tend to conflict

Example 1: tactics in Money (488) This is one of Fowler’s Base Patterns Modifiability tactics used include m1. Semantic coherence m2. Anticipate changes m3. Generalize module m5. Abstract common services

Example 2: Reactor includes Modifiability: m3. Generalize module m5. Abstract common services m6. Hide information Performance: p3. Manage event rate p2. Reduce computational overhead p5. Introduce concurrency p8. Scheduling policy

Styles Styles (Shaw and Garlan) are recurring partial architectures Styles are sometimes also called “patterns” Like patterns, they package tactics But they’re not usually linked with a problem A style consists of Set of element types Element topology Set of semantic constraints Set of interaction mechanisms

Style example: pipes and filters Tactics include: m2. anticipate expected changes m5. abstract common services m6. hide information m7. maintain existing interface m8. restrict communication paths m12. polymorphism m13. component replacement p3. manage event rate

Style example: Service-Oriented Architecture (SOA) Tactics include: m2. anticipate expected changes m5. abstract common services m6. hide information m7. maintain existing interface m8. restrict communication paths m12. polymorphism m13. component replacement m14. adherence to defined protocols t2. separate interface from implementation app app service service service service

Tools of the architect’s trade Quality attribute scenarios … A way of defining testable quality requirements Tactics … Bags of tricks you can apply Patterns and styles … Sets of tactics that usually fit together well and are often applied together