Software Architecture & Quality

Software Architecture and Quality

Muhammad Nasir
[email protected]
Agenda
 Software Quality
 Quality attribute vs. requirement
 Why Quality in a Software Architecture?
 Attributes of Software
 Relations between Quality Attributes
 What to do about the conflicts?
Understanding the Quality
Attributes
 Systems are frequently redesigned not
because they are functionally deficient
 The replacements are often
functionally identical
 but because they are difficult to
maintain, port, or scale, or are too
slow, or have been compromised by
network hackers…
Understanding the Quality
Attributes
 Architecture is the first stage in
software creation in which quality
requirements could be addressed.
 It is the mapping of a system’s
functionality onto software
structures that determines the
architecture's support for qualities.
Functionality and Architecture
 Functionality and quality attributes are
orthogonal
 This statement sounds rather bold at first,
but when you think about it, you would
realize that it cannot be otherwise
 If functionality and quality attributes were
not orthogonal, the choice of function
would dictate the level of security or
performance or availability or usability
 Functionality and Architecture
 Now, this is not to say that any level of any quality
attribute is achievable with any function.
 Manipulating complex graphical images or
sorting an enormous database might be inherently
complex, making lightning-fast performance
impossible.
 But what is possible is that, for any of these
functions your choices as an architect will
determine the relative level of quality.
 Some architectural choices will lead to higher
performance; some will lead in the other direction.
What is Software Architecture?

 ”The software architecture of a program or

computing system is the structure or
structures of the system, which comprise
software elements, the externally visible
properties of those elements, and the
relationships among them.” (Bass, Clements, Kazman)
 For more (much more),
http://www.sei.cmu.edu/architecture/definitions.html
Software Quality
 Quality
 A degree or grade of excellence or worth - the
totality of characteristics of an entity that bear on
its ability to satisfy stated or implied needs.
 Quality requirement
 A requirement that does not concern
functionality.
 Quality attribute
 An attribute that does not concern functionality.
 Non-functional Requirement
 Same as quality requirement
Quality attribute vs. requirement

 An attribute is always present!

 Performance (high/low)
 Maintainability
 Security etc.
 A requirement puts a constraint on an
attribute:
 “The system should be able to handle at
least 50 concurrent connections.”
 A quality requirement describes not what the
system will do, but how it will do it.
Why in a Software Architecture?
 Functional requirements describe what a
system will do.
 Impact on algorithms
 Impact on software execution
 Quality requirements describe how the
system will do it.
 Sometimes impact on implementation (e.g.
performance)
 Impact on software structure = software
architecture
Attributes of Software
 More than Functionality
 Quality Attributes
 How the system works, as opposed to what it
does.
 Affects the success as much as having the right
functionality
 Affects
 What you build (e.g. Architecture)
 How you build (e.g. Development Process)
 Different attributes are relevant for different
products
Example - Buildings
 Museum
 Bright
 Easy access
 Resting areas
 Impression of space
 Home
 Comfortable
 Pivot around living room
Development Quality Attributes
 Concerned with Software Development…
 Modifiability
The ease with which a software system can accommodate changes
to its software
 Portability
The ability of a system to run under different computing
environments. The environment types can be either hardware or
software but is usually a combination of the two.
 Reusability
The degree to which existing applications can be reused in new
applications.
 Integrability
The ability to make the separately developed components of the
system work correctly together.
 Testability
The ease with which software can be made to demonstrate its faults
Operational Quality Attribute
Concerned with Usage of the system…
 Performance
The response time, utilization, and throughput behavior of the system.
 Security
A measure of system’s ability to resist unauthorized attempts at usage or behavior
modification, while still providing service to legitimate users.
 Availability (Reliability quality attributes falls under this category)
The measure of time that the system is up and running correctly; the length of time
between failures and the length of time needed to resume operation after a failure.
 Usability
The ease of use and of training the end users of the system. Sub qualities:
learnability, efficiency, affect, helpfulness, control.
 Interoperability
The ability of two or more systems to cooperate at runtime
Quality Attributes
 System Quality Attributes
 Availability, Modifiability, Performance…
 Business Quality Attributes
 Time to Market, Cost and Benefit …
 Architectural Quality Attributes
 Conceptual Integrity, Completeness…
System Quality Attributes
1. Availability
2. Modifiability
3. Performance
4. Security
5. Testability
6. Usability
1. Availability – What is failure?
 Availability is concerned with system
failure and its associated
consequences.
 A system failure occurs when the
system no longer delivers a service
consistent with its specification.
 Such a failure is observable by the
system's users either humans or other
systems.
1. Availability – Fault vs Failure
 We need to differentiate between
failures and faults.
 A fault may become a failure if not
corrected or masked.
 That is, a failure is observable by the
system's user and a fault is not.
 When a fault does become
observable, it becomes a failure
1. Availability – Concerns
 How long a system is allowed to be out of
operation?
 When may failures occur safely?
 How failures can be prevented?
 What kinds of notifications are required when
a failure occurs?
 How is system failure detected?
 How frequently system failure may occur?
 What happens when a failure occurs?
Availability Nines
Availability in Different Systems
Availability - Architectural
Approaches
 The system must be available 99.999%
of the time:
 Downtime: less than 1 second per 24
hours!
 Downtime: at most 5 minutes per year!
 How do you support this in the
architecture?
Availability - Architectural
Approaches
 Approaches
 Redundant components
 Automatic upgrades without restart
 Graceful degradation in
service/performance
 Automatic restart in case of unrecoverable
error
Availability - Architectural
Approaches
 May need hardware support as well:
 Redundancy in Time and Space
 Space
 Redundant Hardware
 Redundant Software
 Time
 Time is taken for maintenance of
system where time is less important.
 But these require software support of
course...
Relations between Quality Attributes
What to do about conflicts?

 Quality attributes affect each other:

 Positively (e.g. maintainability and flexibility)
 Negatively (e.g. maintainability and
performance)
What to do about conflicts?
 You have to make trade-offs!
 Measure strengths and weaknesses of
different architectural structures.
 See which architectural structure is best
suited for a particular quality attribute.
 Quantify the quality requirements! Make
them measurable.
 Prioritize the quality requirements.
 Choose the appropriate architectural
structure!
Business Quality Attributes
 Time to market
 Cost and benefit
 Projected lifetime of the system
 Target market
 Rollout schedule
 Integration with legacy systems
Time to market
 If there is competitive pressure or a short
window of opportunity for a system or
product, development time becomes
important.
 This in turn leads to pressure to buy or
otherwise re-use existing elements.
 Time to market is often reduced by using
prebuilt elements such as commercial off-
the-shelf (COTS) products or elements re-
used from previous projects
Cost and benefit
 The development effort will naturally have a
budget that must not be exceeded.
 Different architectures will yield different
development costs. (Parallel Computing vs
Quantum Computing)
 For instance, an architecture that relies on
technology (or expertise with a technology)
not resident in the developing organization
will be more expensive to realize than one
that takes advantage of assets already
inhouse
Projected lifetime of the
system
 If the system is intended to have a long
lifetime, modifiability, scalability, and
portability become important.
 But building in the additional infrastructure
(such as a layer to support portability) will
usually compromise time to market. (MSA vs
Client Server)
 On the other hand, a modifiable, extensible
product is more likely to survive longer in the
marketplace, extending its lifetime
Rollout schedule
 If a product is to be introduced as
base functionality with many
features released later,
 the flexibility and customizability of
the architecture are important.
 Particularly, the system must be
constructed with ease of expansion
and contraction in mind.
Integration with legacy
systems
 If the new system has to integrate
with existing systems, care must be
taken to define appropriate
integration mechanisms.
 This property is clearly of marketing
importance but has substantial
architectural implications.
Architectural Quality Attributes
 Conceptual integrity
 Correctness and completeness
 Buildability
Conceptual integrity
 Conceptual integrity is the underlying
theme or vision that unifies the design
of the system at all levels.
 “It is better to have a system omit
certain anomalous features and
improvements, than to have a system
that contains many good but
independent and un-coordinated
ideas”, Fred Brook
Correctness and
Completeness
 Correctness and completeness are
essential for the architecture to allow
for all of the system's requirements
and runtime resource constraints to
be met.
Buildability
 It refers to the ease of constructing a
desired system and is achieved
architecturally by paying careful attention
to the decomposition into modules.
 limiting the dependencies between the
modules (and hence the teams). The
goal is to maximize the parallelism that
can occur in development
Buildability
 Buildability is usually measured in
terms of cost and time
 However, buildability is more
complex than what is usually covered
in cost models
 A system is created from certain
modules, and these modules are
created using a variety of tools.
Buildability
 For example, a user interface may be
constructed from items in a user
interface toolbox
 One aspect of buildability is the
match between the materials that are
to be used in the items and the tools
that are available to manipulate
them.
Buildability
 The rationale behind this aspect is to
speed time to market
 And not force potential suppliers to
invest in the understanding and
engineering of a new concepts.
 A design that casts a solution in terms
of well-understood concepts is thus
more buildable than one that
introduces new concepts.
The End
 Thanks for listening
 Questions would be appreciated.