The document discusses software architecture, including quality attributes, architectural patterns and styles, tactics to achieve qualities, and designing architecture. It covers key topics like quality attribute scenarios, tactics for qualities like availability and modifiability, and how architectural patterns implement tactics. It emphasizes that architecture provides the foundation for achieving quality attributes through appropriate design decisions and tactics.

1. Unit 1-2

2. 1. Understanding quality attributes
2.Achieving qualities
3. Architectural patterns and styles
4.Designing the Architecture
5.Documenting software Architecture
6.Reconstructing software Architecture

3. 1.1 Functionality and Architecture
1.2 Architecture and Quality Attributes
1.3 System quality Attributes
1.4 Quality Attribute Scenarios in practice
1.5 Business Qualities
1.6 Architecture Qualities

4. Quality
“a characteristic or attribute of something”
Attribute of an item , quality refers to
measurable characteristics

5.  Functionality and quality are orthogonal
 Functionality-it is the ability of the system to
do the work for which it was intended.
 It can be achieved through the use of any of a
number of possible structures.
 Software architecture constraints its
allocation to structure when other quality
attributes are important.

6. The message of this section is twofold:
1.Architecture is critical to the realization of
many qualities of interest in a system, and
these qualities should be designed in and can
be evaluated at the architectural level.
2.Architecture, by itself, is unable to achieve
qualities. It provides the foundation for
achieving quality, but this foundation will be
to no avail if attention is not paid to the
details.

7. Quality attributes are examined in three
classes:
1.Qualities of the system. we will focus on
availability, modifiability, performance,
security, testability and usability.
2.Business qualities(such as time to market)
that are affected by the architecture.
3.Qualities such as conceptual integrity, that
are about the architecture itself although they
indirectly affect other qualities, such as
modifiability.

8. A solution to the problems of the system
quality attributes is to use Quality attribute
scenarios
- as a means of characterizing quality
attributes.
-a quality attribute is a quality-attribute-
specific requirement.
-it consists of six parts.

9. 1)Source of stimulus: this is some entity(a
human, a computer system, or any other
actuator) that generated the stimulus.
2)Stimulus: the Stimulus is a condition that
needs to be considered when it arrives at a
system.
3)Environment: the Stimulus occurs within
certain conditions. The system may be in an
overload condition or may be running when
the stimulus occurs, or some other condition
may be true.

10. 4) Artifact: some artifact is stimulated. This may
be the whole system or some pieces of it.
5)Response: the response is the activity
undertaken after the arrival of the stimulus.
6)Response measure: when the response
occurs, it should be measurable in some
fashion so that the requirement can be
tested.

13. Availability scenario
 An example availability scenario is derived
from the general scenario of fig 4.2 by
instantiating each of the parts, is “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.” fig 4.3 shows the pieces of the
derived scenario

15. Modifiability Scenario
a sample modifiability scenario is “ A
developer wishes to change the user interface
to make a screen’s background color blue.
This change will be made to the code at
design time. It will take less than 3 hrs to
make and test the change and no side effects
changes will occur in the behavior.” fig 4.4
illustrates this sample scenario(omitting a few
minor details for brevity)

17. Quality Attribute Scenario Generation
-To help the architect generate meaningful
quality attribute requirements for a system.
-in theory this is done in a project’s
requirement elicitation, but in practice this is
is seldom rigorously enforced.

18.  To make the general scenarios useful for a
particular system, you must make them
system specific.
 The six most common and important system
quality attributes, with the twin goals of
identifying the concepts used by the attribute
community and providing a way to generate
general scenarios for that attribute.

19.  Availability- is concerned with system failure
and its associated consequences.
 The availability of a system is the probability
that it will be operational when it is needed.
This is typically defined as

21. Modifiability- is about the cost of change. It
brings up two concerns.
1. what can change(the artifact)?
2.when is the change made and who makes it
(the environment)?

23.  Performance- is about timing. Events
(interrupts, messages, requests from users,
or the passage of to time) occur, and the
system must respond to them.
 A performance scenario begins with a request
for some service arriving at the system.
Satisfying the request requires resources to
be consumed. While this is happening the
system may be simultaneously servicing other
requests.

26.  Security- is a measure of the system’s ability
to resist unauthorized usage while still
providing its services to legitimate users.
 Security can be characterized as a system
providing nonrepudiation, confidentiality,
integrity, assurance and auditing.
 Each of these security categories gives rise to
a collection of general scenarios.

29.  Testability – software testability refers to the
ease with which software can be made to
demonstrate its faults through(typically
execution-based) testing.
 In particular testability refers to the
probability, assuming that the software has at
least one fault, that it will fail on its next test
execution.

32.  Usability – is concerned with how easy it is for
the user to accomplish a desired task and the
kind of user support the system provides. it
can be broken into following areas:
 Learning system features- if the user is
unfamiliar with a particular system or a
particular aspect of it, what can the system
do to make the task of learning easier?
 Using a system efficiently- what can the
system do to make the user more efficient in
its operation.

33.  Minimizing the impact of errors- what can
the system do so that a user error has
minimal impact?
 Adapting the system to user needs- how can
the user(or the system itself) adapt to make
the user’s task easier?
 Increasing confidence and satisfaction-what
does the system do to give the user
confidence that the correct action is being
taken?

37. Communicating concepts using general scenarios
 One of the uses of general scenarios is to enable
stakeholders to communicate.
 Table 4.7 gives the stimuli possible for each of
the attributes and shows a no.of different
concepts.
 For example, it may occur with an exchange of
several messages b/w a client and server each of
which is an atomic event from a performance
perspective.

39.  A no.of other attributes can be found in the
attribute taxonomies in the research
literature.
 For example, scalability is often an important
attribute, it is captured by modifying system
capacity- the no.of users supported.
 Portability is captured as a platform
modification.
 Interoperability- is important to your
organization, it is reasonable to create your
own general scenario for it.

40.  In addition to the qualities that apply directly
to a system, a number of business quality
goals frequently shape a system’s
architecture. These goals center on cost,
schedule, market, and marketing
considerations.
 Time to market: if there is competitive
pressure or a short window opportunity for a
system or product, development time
becomes important.

41.  Cost and benefit: the development effort will
naturally have a budget that must not be
exceeded.
 Projected lifetime of the system: if the system is
intended to have a long lifetime, modifiability,
scalability and portability become important.
 Targeted market: for general-purpose(mass-
market) software, the platforms on which a
system runs as well as its features set will
determine the size of the potential market. Thus
portability and functionality are key to market
share.

42.  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.
 Integration with legacy systems: if the new
system has to integrate with existing
systems, care must be taken to define
appropriate integration mechanisms.

43.  In addition to qualities of the system and
qualities related to the business environment
in which the system is being developed, there
are also qualities directly related to the
architecture itself that are important to
achieve.
 Conceptual integrity is the underlying theme
or vision that unifies the design of the system
at all levels.

44.  Correctness and completeness are essential
for the architecture to allow for all the
system’s requirements and runtime resource
constraints to ne met.
 Buildability allows the system to be
completed by the available team in a timely
manner and to be open to certain changes as
development progress.

45. 2.1 Introducing Tactics
2.2 Availability Tactics
2.3 Modifiability Tactics
2.4 Performance Tactics
2.5 Security Tactics
2.6 Testability Tactics
2.7 Usability Tactics
2.8 Relationship of Tactics to Architectural
Patterns

46.  A Tactic is a design decision that influences
the control of a quality attribute response.
 We call a collection of tactics an architectural
strategy
 Each tactic is a design option for the architect
 Usually achieving a high availability through
redundancy implies a concomitant need for
synchronization.
 We see two immediate ramifications of this
example.

47. 1. Tactics can refine other tactics
2. pattern package tactics
Fig5.1 the tactics are those that architects have
been using for years, and we isolate and
describe them. we are not inventing tactics
here, just capturing what architects do in
practice.

49.  Recovery or repair is an important aspect of
availability.
 In some cases the monitoring or recovery is
automatic and in others it is manual.
 We first consider fault detection. We then
consider fault recovery and finally fault
prevention.
 The tactics we discuss in this section will
keep faults from becoming failures or at least
bound the effects of the fault and make
repair possible. This will shown in the foll fig.

52.  Three widely used tactics for recognizing faults
are ping/echo, heartbeat and exceptions.
 Ping/echo-one component issues a ping and
expects to receive back an echo within a
predefined time, from the component under
scrutiny.
 Heartbeat(dead man timer)- in this case one
component emits a heartbeat message
periodically and another component listens for it.
 Exceptions- one method for recognizing faults is
to encounter an exception which is raised when
one of the fault classes recognized.

53.  Fault recovery consists of preparing for
recovery and making the system repair. Some
preparation and repair tactics follow.
 Voting
 Active redundancy(hot restrat)
 Passive redundancy(warm restrat/dual
redundancy/triple redundancy)
 Spare
 Shadow operation
 State resynchronization
 Checkpoint/rollback

54.  The following are some fault prevention tactics
 Removal from service- this tactic removes a
component of the system from operation
undergo some activities to prevent anticipated
failures.
 Transactions- a transaction is the bundling of
several sequential steps such that the entire
bundle can be undone at once.
 Process monitor- once a fault in a process has
been detected, a monitoring process can delete
the nonperforming process and create a new
instance of it, initialized to some appropriate
state as in the spare tactic.

55.  Tactics to control modifiability have as their
goal controlling the time and cost to
implement, test and deploy changes.fig 5.4
shows this relationship.

56.  We organize the tactics for modifiability in sets
according to their goals.
 One set has as its goal reducing the no.of
modules that are directly affected by a change.
We call this set “localize modifications.”
 a second set has as its goal limiting
modifications to the localized modules. We use
this set of tactics to “prevent the ripple effect.”
 A third set of tactics has its goal controlling
deployment time and cost. We call this set “defer
binding time.”

58.  Performance tactics control the time within
the which a response is generated. This is
shown in fig 5.6

60.  Tactics for achieving security can be divided
into those concerned with resisting attacks,
those concerned with detecting attacks, and
those concerned with recovering from
attacks. All three categories are important.
 Fig 5.8 shows the goals of a security tactics

63.  The goal of tactics for testability is to allow
for easier testing when an increment of s/w
development is completed.
 Fig 5.10 displays the use of tactics for
testability.

65.  Usability is concerned with how easy it is for the
user to accomplish a desired task and the kind of
support the system provides to the users.
 Two types of tactics support usability, each
intended for two categories of “users”.
 The first category, “runtime” , includes those
that support the user during system execution.
 The second category is based on the iterative
nature of user interface developer at design time.

68. usability
Separate
user
interface
Support
user
initiative
Support
system
initiative
Cancel
Undo
aggregate
User model
System model
Task model
User
request
User
Given
appropriate
feedback and
assistance
Fig 5.13 summary of runtime usability tactics

69.  An architect usually chooses a pattern or a
collection of patterns designed to realize one
or more tactics.
 The pattern consists of six elements.
 A proxy which provides an interface that
allows clients to invoke publicly accessible
methods on an active object
 A method request which defines an interface
for executing the methods of an active
object.

70.  An activation list which maintains a buffer of
pending method requests
 A scheduler which decides what method
requests to execute next
 A servant which defines the behavior and
state modeled as an active object
 A future which allows the client to obtain the
result of the method invocation

71.  The other tactics this pattern involves
 Information hiding(modifiability)- each element
chooses the responsibilities it will achieve and
hides their achievement behind an interface
 Intermediary(modifiability)- the proxy acts as an
intermediary that will buffer changes to the
method invocation
 Binding time(modifiability)- the active object
pattern assumes the requests for the object
arrive at the object at runtime.
 Scheduling policy(performance)- the scheduler
implements some scheduling policy

72.  An architectural pattern in s/w, also known as
an architectural style, is analogous to an
architectural style in buildings, such as Gothic
or Greek Revival or Queen Anne.
 It consists of a few key features and rules for
combining them so that architectural integrity
is preserved.

73. An architectural pattern is determined by:
 A set of element types(such as a data
repository or a component that computes a
mathematical function).
 A topological layout of the elements
indicating their interrelationships.
 A set of semantic constraints.
 A set of interaction mechanisms.

74.  Mary Shaw and David Garlan’s influential
work attempted to catalog a set of
architectural patterns that they called
architectural Styles or idioms.
 This has been evolved by the SEC into what is
now more commonly known as architectural
patterns, analogous to design patterns and
code patterns.

76. 4.1 Architecture in the life cycle
4.2 Designing the architecture
4.3 Forming the team structure
4.4 Creating a skeletal system

77.  Any organization that embraces architecture
as a foundation for its software development
processes needs to understand its place in
the life cycle.
 The intent of this model is to get user and
customer feedback and iterate through
several releases before the final release.

79. Where can I begin designing?
 the life-cycle model shows the design of the
architecture as iterating with preliminary
requirement analysis.
 An architecture is “shaped” by some
collection of functionality, quality and
business requirements. We call these shaping
req’s architectural drivers.
 Once architectural drivers are known, the
architectural design can begin.

80.  A method for designing an architecture to
satisfy both quality req’s and functional req’s.
we call this method Attribute Driven
Design(ADD)
 ADD is an approach to defining a s/w
architecture that bases the decomposition
process on the quality attributes the s/w has
to fulfill.
 Sample Input: the input to ADD is a set of
req’s.

81.  Beginning ADD- the process can begin when
the driver req’s are known with some
assurance
 ADD steps
1.Choose the module to decompose
2.A) choose the architectural drivers
B)choose an architectural pattern
c)Instantiate modules and allocate
functionality using multiple views

84. 2. D)define interfaces of the child modules
E)verify and refine use cases and quality
scenarios as constraints for the child modules
3. Repeat the steps above for every module
that needs further decomposition.

85.  Once an architecture for the system under
construction has been agreed on , teams are
allocated to work on the major modules and a
work breakdown structure is created that
reflects those teams.
 Each team then creates its own internal work
practices.
 The teams within an organization work on
modules.

86.  Once an architecture is sufficiently designed
and teams are in place to begin building to it,
a skeletal system can be constructed.
 The idea at this stage is to provide an
underlying capability to implement a system’s
functionality in an order advantageous to the
project.
 Classical S.E practice recommends “stubbing
out” sections of code so that portions of the
systems can be added separately and tested
immediately

87. 5.1 Uses of Architectural Documentation
5.2 Views
5.3 Choosing the relevant views
5.4 Documenting a View
5.5 Documentation across Views
5.6 Unified Modeling Language

88.  The architecture for a system depends on the
req’s levied on it, so too does the
documentation for an architecture depend on
the it- i.e., how we expect it will be used.
 Architecture documentation is both
perspective and descriptive.
 All of this tells us that different stakeholders
for the documentation have different needs.

90.  The concept a view, which you can think of as
capturing a structure, provides us with the
basic principle of documenting software
architecture.
 Documenting an architecture is a matter of
documenting the relevant views and then
adding documentation that applies to more
than one view.
 This principle is useful because it breaks the
problem of architecture documentation into
more tractable parts.

91.  Different views support different goals and uses.
 Different views will highlight different system
elements and/or relationships.
 Table shows a representative population of
stakeholders and the kind if views they tend to
find useful.
 Table divided views into these three groups:
module, component-and-connector(C&C), and
allocation. This 3-way categorization reflects the
fact that architects need to think about their s/w
in at least 3 ways at once:

92. 1. how it is structured as a set of
implementation units
2. how it is structured as a set of elements that
have runtime behavior and interactions
3.How it relates to non-software structures in
its environment

94.  Other views are available
 Here is a simple three-step procedure for
choosing the views for your project
1.Produce a candidate view
2.Combine views
3.proritize

95.  There is no industry-standard template for
documenting a view, but the seven-part
standard organization that we suggest in this
section has worked well in practice.
1.Primary presentation
2.Element catalog
3.Context diagram
4.Variability guide
5.Architecture background
6.Glossary of terms
7.Other information

97. Documenting interfaces:
documenting an interface consists of naming
and identifying it and documenting its
syntactic and semantic information
A template for documenting interfaces
1.Interface identity
2.Resources provided
3.Datatype definitions
4.Exception definitions

98. 5.Variability provided by the interface
6.Quality attribute characteristics of the
interface
7.Element requirement
8.Rationale and design issues
9.Usage guide

100. cross-view documentation consists of just
three major aspects, which can summarize as
how-what-why:
1.How the documentation is
2.What the architecture is
3.Why the architecture is the way it is

102.  Uml has emerged as the de-facto standard
notation for documenting a software
architecture.
Module views- is an enumeration of modules
together with their interfaces and their
relations.
-interfaces
-modules
-aggregation
-generalization
-dependency

103.  Component-and-connector views
There is no single preferred to document
component-and-connector(C&C) views in
uml, but a no.of alternatives.
-components
-interfaces
-connectors
-systems

104.  Allocation views
in uml, a deployment diagram is a graph of
nodes connected by communication
associations
The nesting of symbols within the node symbol
signifies a composition association b/w a
node class and constituent classes or a
composition link b/w a node object and
constituent objects.

105. 6.1 introduction
6.2 information extraction
6.3 database construction
6.4 view fusion
6.5 reconstruction

106.  Reconstruction in which the “as-built”
architecture of an implemented system is
obtained from an existing system.
 Reconstruction activities
s/w architecture reconstruction comprises the
following activities, carried out iteratively:
1.Information extraction
2.Database construction
3.View fusion
4.Reconstruction

108.  Information extraction involves analyzing a
system’s existing design and implementation
artifacts to construct a model of it.
 Info obtained can be categorized as either static
or dynamic.
 To extract info a variety of tools are used,
including these:
-parsers
-abstract syntax trees
-lexical analyzers
-profilers
-code instrumentation tools
-ad hoc

109.  Guidelines
the following are some practical considerations
in applying this step of the method.
-use the “least effort” extraction
-validate the info you have extracted
-extract dynamic info where required

110. The extracted info is converted into a standard
format for storage in a database during database
construction. It is necessary to choose a database
model. When doing so, consider the following:
• It should be a well-known model
• It should allow for efficient queries
• It should support remote access of the database
• It supports view fusion
• It supports query language
• Check pointing should be supported by
implementations

112.  Guidelines
-build database tables from the extracted
relations
-as with any database construction, carefully
consider the database design before you get
started
-use simple lexical tools like perl and awk

113.  View fusion involves defining and
manipulating extracted info to reconcile,
augment, and establish connections b/w the
elements.
 improving a view
 Disambiguating function calls

114. Guidelines
The following are some practical
considerations in applying this step of the
method:
-fuse tables when no single extracted table
provides the needed info
-fuse tables when there is ambiguity within
one of them, and it is not possible to
disambiguate using a single table
-consider different extraction techniques to
extract different info.

115.  The view info has been extracted, stored, and
refined or augmented to improve its quality.
The reconstruction operates on view to reveal
broad, coarse-grained insights into the
architecture
 Reconstruction consists of two primary
activities:
-visualization and interaction
-pattern definition and recognization

116. Guidelines
The following are some practical
considerations in applying this step of the
method:
-be prepared to work with the architect closely
and to iterate several times on the
architectural abstraction that you create
-when developing code segments try to build
ones that are succinct and that do not list
every source element

117. -code segments can be based on naming
conventions
-code segments can be based on the directory
structure
-architecture reconstruction is the effort of
redetermining architectural decisions, given
only the result of these decisions in the actual
artifacts