This document discusses quality attributes and tactics for software architecture. It describes key quality attributes like availability, modifiability, performance, security, testability and usability. For each attribute, it provides general scenarios and possible values. It also outlines tactics that can be used to achieve each quality attribute at the architectural level. Finally, it briefly introduces the Attribute-Driven Design method for designing software architectures to meet both functional and quality requirements.

1. Quality attributes for SA
Prof. Sadhana Ghalsasi

2. Quality Attributes
• Availability
• Modifiability
• Performance
• Security
• Testability
• Usability

3. Availability General Scenario
Portion of scenario Possible values
Source Internal/external to the system
Stimulus Fault, emission, crash, timing, response
Artifact System’s processors, communication channels, persistent
storage, processes
Environment Normal operation, degraded mode
Response System should detect event and dod one or more of the
following:
Record it, notify appropriate parties, disable sources of
events, be unavailable for a specified interval, continue to
operate in normal or degraded mode
Response measure Time interval when the system must be available, availability
time, time interval in which the system can be in degraded
mode, Repair time

4. Modifiability general scenario
Portion of scenario Possible values
Source End user, developer, system administrator
Stimulus Wishes to add, delete, modify, vary functionality, quality
attribute, capacity
Artifact System user interface, platform, environment, system that
operates with larger systems
Environment At runtime, compile time, build time, design time
Response Locates places in architecture to be modified, makes
modification without affecting other functionality, tests
modification, deploys modification
Response measure Cost in terms of number of elements affected, effort, money,
extent to which it affects other functions or quality attributes

5. Performance general scenario
Portion of scenario Possible Values
Source One of a number of independent sources, possibly from
within the system
Stimulus Periodic events arrive, sporadic events arrive, stochastic
event arrive
Artifact System
Environment Normal mode, overload mode
Response Processes stimuli, changes level of service
Response measure Latency, deadline, throughput, jitter, miss rate, data loss

6. Security general scenario
Portion of scenario Possible values
Source Individual or system that is correctly identified, identified
incorrectly, of unknown identity who is internal/external,
authorized or unauthorized with access to limited
resources, vast resources
Stimulus Tries to display data, change/delete data, access system
services, reduce availability to system services
Artifact System services, data within system
Environment Either online or offline, connected or disconnected,
firewalled or open
Response Authenticates user, hides identity of the user, blocks access
to data or services, grants or withdraws permission

7. Testability general scenario
Portion of scenario Possible values
Source Unit developer, increment integrator, system verifier, client
acceptance tester, system user
Stimulus Analysis, architecture, design, class, sub system integration
completed, system delivered
Artifact Piece of design, piece of code, complete application
Environment At design time, at development time, at compile time, at
deployment time
Response Provides access to state values, provides computed values, prepares
test environment
Response measure Percent executable statements executed, probability of failure if fault
exists, time to perform tests, length of longest dependency chain in
a test

8. Usability general scenario
Portion of scenario Possible values
Source End user
Stimulus Wants to learn system features, uses system efficiently, minimize impact of
errors, adapt system, feel comfortable
Artifact System
Environment At runtime or configure time
Response System provides one or more of the following responses:
Help system to sensitize to context, interface is familiar to user, interface is
usable in an unfamiliar context
Reuse already entered data, distinct views with consistent operations,
multiple simultaneous activities
Undo, cancel, recover from system failure, retrieve forgotten password
Customizability, internationalization
Display system state, work at the users pace
Response measure Task time, number of errors, number of problems solved, user satisfaction,
gain of user knowledge, ratio of successful operations to total operations,
amount of time/data lost

9. Other system quality attributes
• Scalability
• Portability
• Interoperability
• Etc……

10. Business qualities
• Time to market
• Cost and benefit
• Projected lifetime of the system
• Targeted market
• Rollout schedule
• Integration with legacy systems

11. Availability tactics
Availability
Recovery – preparation Recovery –
Fault detection Prevention
and repair reintroduction
Voting
Ping/Echo Shadow Removal from service
Active Redundancy
Heartbeat State Resynchronization Transactions
Passive redundancy
Exception Rollback Process monitor
Spare

12. Modifiability tactics
Modifiability
Prevention of ripple
Localize changes Defer binding time
effects
Semantic coherence Runtime registration
Hide information
Anticipate expected change Configuration files
Maintain existing interface
Generalize module Polymorphism
Restrict communication paths
Limit possible options Component replacement
Use an intermediary
Abstract common services Adherence to defined protocols

13. Performance tactics
Performance
Resource demand Resource management Resource arbitration
Increase computation efficiency
Introduce concurrency
Reduce computational overhead
Maintain multiple copies Scheduling policy
Manage event rate
Increase available resources
Control frequency of sampling

14. Security tactics
Security
Recovering from
Resisting attacks Detecting attacks
an attack
Authenticate users
Authorize users
Maintain data confidentiality Intrusion
Restoration Identification
Maintain integrity
Limit exposure
detection
Limit access
See availability Audit trail

15. Testability tactics
Testability
Manage input/output Internal monitoring
Record/playback
Separate interface from
implementation Built in monitors
Specialized access
routines/interfces

16. Usability tactics
Usability
Separate user Support user Support system
interface initiative initiative
Cancel User model
Undo System model
aggregate Task model

17. Architectural patterns
Data flow systems
• Batch sequential
• Pipes and filters
Call-and-return systems
• Main program & subroutines
• Hierarchical layers
• OO systems
Virtual machines
• Interpreters
• Rule-based systems
Independent components
• Communicating processes
• Event systems
Data-centered systems (repositories)
• Databases
• Blackboards

18. ADD Method
Attribute-Driven Design (ADD)method
Method to design architecture so that both functional and quality
requirements are met
Defines SA by decomposing based on the quality attributes
Recursive decomposition process; at each stage
– Tactics and architectural patterns are chosen to satisfy some
qualities
– Functionality is added to instantiate the module types provided
by the pattern
Input: the set of quality scenarios for drivers
Key drivers may change during design, due to
Better understanding or changing of requirements

19. ADD steps
1.Choose the module (initially whole system) to
decompose
Required input available for that module
2. Refine the module according to following steps
– Choose architectural drivers
– Choose architectural pattern that satisfies the drivers
– Instantiate modules and allocate functionality
– Define interfaces of child modules
– Verify and refine use cases and quality scenarios and make
them constraints for child modules
3. Repeat steps above for every module that needs further
decomposition