This document provides an overview of software design and architecture topics including quality attributes, scenarios, and specific attributes like availability, modifiability, performance, security, testability, and usability. It discusses how quality attributes are considered during design, implementation, and deployment phases and how architecture impacts many non-functional qualities. General scenarios are presented for various quality attributes.

1. Ms. Rabia Iftikhar
rabia.iftikhar@faculty.muet.edu.pk
SOFTWARE DESIGN AND ARCHITECTURE
LECTURE 6-9
Disclaimer: The contents of this
presentation have been taken from
multiple sources, i.e. Books,
Research articles, Thesis
publications, and websites.

2. The material used in this presentation i.e., pictures/graphs/text, etc. is solely
intended for educational/teaching purpose, offered free of cost to the students for
use under special circumstances of Online Education due to COVID-19 Lockdown
situation and may include copyrighted material - the use of which may not have
been specifically authorised by Copyright Owners. It’s application constitutes Fair
Use of any such copyrighted material as provided in globally accepted law of many
countries. The contents of presentations are intended only for the attendees of the
class being conducted by the presenter.
Fair Use Notice

3. Outlines
Understanding Quality Attributes
Business considerations
Architecture and Quality Attributes
Quality Attributes
QA Scenario
QA Scenario Generation
Availability
Modifiability
Performance
Security
Testability
Usability

4. Business Considerations
Determine qualities to be part of the system’s architecture
Quality attributes
Such qualities are non-functional
Functionality
Basic statement of the system’s capabilities, services, behaviour
Sometimes the only development concern
Systems often need to be redesigned for
Maintainability
Portability
Scalability
Speed
Security etc

5. Business Considerations
Functionality and quality attributes: orthogonal
We therefore need to separate concerns
Functionality: the ability of the system to do the work for which it was intended
Functionality can be achieved by using various possible structures
System can exist also as a monolithic module with no structure

6. Architecture And Quality Attributes
Quality attributes considered during
 Design, implementation, deployment
No attribute is dependent only on one phase
Architecture critical for realizing many quality attributes
These qualities designed and evaluated at architectural level
Architecture does not achieve these qualities
They are achieved via details (implementation)

7. Quality Attributes
System qualities
 Availability, modifiability, performance, security, testability, usability
Of interest to software people since 70s
Many definitions, own communities
Problems
Non-operational definitions
Aspects belong to which quality (e.g. system failure? )
Distinct vocabularies
Business qualities
Time-to-market, etc
Architecture qualities
Conceptual integrity, etc

8. Quality Attributes Scenarios
Quality-attribute-specific requirement, containing
Source of stimulus
Human/computer system/other actuator generating the stimulus
Stimulus
Condition that needs to be evaluated when arrives at the system
Environment
The conditions the system is in (overload/running/failed etc)
Artifact
Something that is stimulated (whole system/ certain system part)
Response
Activity undertaken upon stimulus arrival
Response measure
Response should be measurable in some manner so that the requirement can be tested

9. Quality Attributes Scenarios

10. Quality Attributes Scenarios
Draw a sample availability scenario
An unanticipated external message is received by a process during normal operation. The process
informs the operator of the receipt of the message and continues to operate with no downtime.

11. Quality Attributes Scenarios
General QA scenarios
System independent
Can potentially pertain to any system
Example
"A request arrives for a change in functionality, and the change must be made at a particular time within the development process
within a specified time.”
Concrete QA scenarios
Specific to the particular system under consideration
Same role as use cases for specifying functional requirements
Not every system-specific scenario has all of the six parts. (only necessary for testing)
Example
“A request arrives to add support for a new browser to a Web-based system, and the change must be made within two weeks”

12. QA Scenario Generation
We need to generate meaningful QA requirements for a system.
Requirements gathering phase
Starting point, but not disciplined enough recording
We generate concrete QA scenarios
First create general scenarios from tables
From them derive system-specific scenarios
Redundancy corrected

13. Availability
Readiness of usage
Concerned with system failures and consequences
Failure
Deviation from intended functional behaviour
Observable by system users
Failure vs fault
Fault: event which may cause an error
Failure

14. Availability
Availability Concerns
How system failure is detected
How frequently system failure may occur
What happens when a failure occurs
How long is a system allowed to be inoperable
How to prevent failures
What kind of notifications are required when a failure occurs

15. Availability
Repair and maintenance
Time to repair: time until failure is no longer observable
Automatic repair (no failure, not observable)
Maintenance: scheduled downtimes
The availability of a system is the probability that it will be operational when it is needed
Typically defined as:
Mean time to fail/(mean time to fail+mean time to repair)

16. Availability General Scenarios

17. Modifiability
Concerns cost of change
It brings up following two concerns
What can change (the artifact)?
Any aspect of a system: add/ delete/ modify
The functions the system computes
The platform the system exists on (=> portability)
HW, OS, MW
System environment
Systems to interoperate with, communication protocols
System qualities
Reliability, performance, future modifiability
Capacity
Number of users supported, of supported operations

18. Modifiability
It brings up following two concerns
When and by whom is the change made?
Implementation
Modifying source code
Compile-time
Build
Configuration setup
Execution
By
developers, end users, system administrator
Upon specifying a change
New implementation must be designed, implemented, tested, deployed
All these cost time and money
Time and money can be measured

19. Modifiability General Scenarios

20. Performance
Concerned with timing
how long it takes a system to respond when an event occurs
Events
Interrupts, messages, requests from users, passage of time
Complication
Number of event sources and arrival patterns

21. Performance
Arrival patterns for events
Periodic
E.g., every 10 ms
Most often seen in real-time systems
Stochastic
Events arrive according to some probabilistic distribution
Sporadical

22. Performance
System Response Measures
Latency
Time between stimulus arrival and system’s response to it
Deadlines in processing
Throughput in the system
Number of transactions system can process in a second
Jitter of the response
Variation in latency
Number of events not processed
Because system too busy to respond
Lost data
Because system too busy

23. Performance General Scenarios

24. Security
Measure of system’s ability
to resist unauthorized usage
to provide services to legitimate users
Attack: attempt to breach security
Unauthorized attempt to access data/services
Unauthorized attempt to modify data
Attempt to deny services to legitimate users
Example attacks
Theft of money by electronic means
Theft of credit card numbers
Destruction of files on computer systems
Denial-of-service attacks by worms, viruses

25. Security
Security components
Nonrepudiation: Transaction cannot be denied by any of its parties
Confidentiality: Data/service protected from unauthorized access
Integrity: Data/services delivered as intended
Assurance: Parties in a transactions are who they say they are
Availability: System ready for legitimate use
Auditing: System tracks activities within it to be able to reconstruct them

26. Security General Scenarios

27. Sample Security Scenario

28. Security
Security scenario response
Authenticates user
Hides identity of user
Blocks/allows access to data/services
Grants/withdraws permission to access data/services
Records access/modification or attempts
Stores data in certain formats
Recognizes access/usage roles
Informs users on other systems
Restricts availability of services

29. Security
Security scenario response measure
Time/effort/resources for circumventing security measures successfully
Probability of detecting attack, identifying attacker
Percentage of services still available under DoS attack
Restored data/services
Extent to which data/services damaged or legitimate access denied

30. Testability
Easiness with which SW can demonstrate its faults through testing
Testing: 40% costs of developing good systems
Probability that SW will fail on its next test execution
Assuming the software has at least one fault
Response measures
Effectiveness of tests (in finding faults)
How long do satisfiable tests last
Testable system
It must be possible
 to control each component’s internal state and inputs
 To observe the outputs
Test harness
 Specialized software designed for exercising the SW under test

31. Testability
Who does it
Various developers, testers, verifiers, users
Last step of SW development cycle
What to test
Portions of code
Design
Complete system

32. Testability general scenarios

33. Usability
Concerned with
How easy it is for the user to accomplish a desired task
User support type the system provides
Usability problems are usually discovered during prototype building and user testing
Later in process and deeper in architecture the repair needs to go: the more expensive
Usability areas
Learning system features
Using a system efficiently
Minimizing the impact of errors
Adapting system to user needs
Increasing confidence and satisfaction

34. Usability General Scenarios

35. Usability
Usability Scenario Response
System provides responses to support
learn system features
use system efficiently
minimize impact of errors
adapt system
feel comfortable

36. Stimuli

37. Communicating Concepts
General scenarios
Need to make stakeholders communicate
Each attribute community has own vocabulary
Different terms can mean the same thing
Stimuli can occur during runtime or before
Architect’s job: understand which stimuli
Represent the same occurrence
Are aggregates of other stimuli
Are independent
When stimuli relations are clear
Communicate them to stakeholders
Use appropriate language for each stakeholder category

38. Architecture Qualities
Conceptual Integrity
Completeness and Correctness
Build ability