Software Architecture Session5

UNDERSTANDING QUALITY ATTRIBUTES

Session - 5

Quality and Architecture

• “ The mapping of functionality on software structures determines the architecture's support for quality ”

• Alternative mappings are possible but are not equally good

• Architecture decomposition by itself enables (or hinders) quality

01:43 PM 2SEPS ZG651 Software Architectures

Architecture influence

• Architecture is critical to the realization of many qualities (design and evaluation)

• Architecture by itself is unable to achieve qualities

• Qualities are never achieved in isolation


Problems with quality attributes

• QA's have non-operational definitions• The concerns of QA's overlap• Each QA community develops its own

vocabulary


Quality attributes

• Quality of the system• Quality of the architecture• Quality of the business environment [Bass]• Product quality requirements• Organizational quality requirements• External quality requirements [Sommerville]


Quality Attribute Scenarios

• Quality Attribute Scenario is a quality-attribute-specific requirement.

• There are 6 parts (Figure 4.1):1. Source of stimulus2. Stimulus – a condition that needs to be considered3. Environment - what are the conditions when the stimulus occurs?4. Artifact – what elements of the system are stimulated5. Response6. Response measure – when the response occurs it should be measurable so that the requirement can be tested


QA scenarios

• General scenario for availability


QA scenario example: availability

• (sample) concrete scenario for availability


QA-specific tables

• Availability-specific tableScenario Portion Possible Values

Source Internal to system; external to system

Stimulus Crash, timing, no response, incorrect response

Artifact System’s processors, communication channels,persistent storage, processes

Environment Normal operation; degraded (failsafe) mode

Response Detect event and: log the failure| notify users/operators| be unavailable| continue in normal/degraded mode

Response Measure Time interval when system must be available,availability/response time, unavailability time interval


Quality Attribute ScenarioGeneration• Architect’s Goal: generate meaningful quality

attribute requirements for the system

Quality-attribute-specific tables->General scenarios -> System specific scenarios


Scenarios in Practice: Usability

• Usability is how easy is it for the user to accomplish tasks and what support the system provides for the user to accomplish this.

• Dimensions:– Learning system features– Using the system efficiently– Minimizing the impact of errors– Adapting the system to the user’s needs– Increasing confidence and satisfaction


General Scenario Generation:UsabilityScenario Portion Possible Values

Source End user

Stimulus Wants to: learn system, use system, recover from errors, adapt system, feel comfortable

Artifact System

Environment At runtime, or configure time, install-time

Response Measure Task time, number of errors, number of tasksaccomplished, user satisfaction, gain of user knowledge,amount of time. data lost


Usability Scenarios in Practice : Responses• System responses to stimuli:• To learn system

– Help system is context sensitive– Interface familiar, consistent

• To use system efficiently– Reuse of command or data already entered– Navigation support, comprehensive searching

• To recover from errors– Undo, cancel, recover from system failures– Forgotten passwords

• To adapt system: customize the system to user liking; internationalization– To feel comfortable:– Display system state– Undo, cancel, recover from system failures


Communicating concepts usinggeneral scenarios: Stimuli

Attribute Stimulus

Availability Unexpected event, non-occurrence of expected event

Modifiability Request to add/delete/modify functionality, platform,quality-attribute or capacity

Performance Periodic, stochastic or sporadic

Security Attempt to access/display/modify information orresources; reduce availability of system

Testability Completion of phase of system development

Usability User wants to: learn, use, minimize impact or errors,adapt the system, feel comfortable


Achieving quality attributes

• Achieving quality attributes– Tactics: guidance for the architect on how to achieve

them (fundamental design decisions)– Given a QA, tactics help the architect to design using

design patterns and architectural strategies or patterns• E.g. given the business goal “time-to-market,” the architectural

solution would be to decompose the system to ease parallel development by multiple teams

• Quality Attribute Requirements -> Architectural Decisions


Example Tactic

• An example tactic is:– – “introduce redundancy” to increase availability

• This would require “synchronization” also.Thus note:

– Tactics can influence/refine other tactics.– Tactics will be grouped into “patterns”

• A pattern to support availability would include a

– Redundancy-tactic and a synchronization-tactic– Tactics are going to be grouped hierarchically (trees)


Availability Tactics• Recall the availability quality attribute from last time

– Def: when the system fails to deliver a service …– Failure vs fault – a collection of faults “may” cause a failure– Availability Scenario generation table (Tab. 4.1)

• Availability tactics– Will keep faults from becoming failures– Or at least limit the effects of a fault– Approaches to maintain include:

• Some type of redundancy; some type of monitoring to detect failures; some type of recovery


Hierarchy of tactics: availability


Patterns’ role


An example: Modifiability

• Goal: Control the time and cost to implement, test, and deploy changes– Localize modifications– Prevent the ripple

effect– Defer binding time


Patterns’ role: modifiability example


Summary

• Quality requirements must be characterized in a disciplined way to control the extent to which they are fulfilled in the software architectural.

• Tactics define how to achieve a quality attribute, and architectural patterns provide ready-to-use architectural solutions to realize them.


Software Architecture Session5

Software

Transcript of Software Architecture Session5