The chapter discusses tactics for achieving qualities like availability and modifiability in software architectures. It defines tactics as design decisions that influence quality attribute responses. For availability, common tactics include redundancy, fault detection using techniques like heartbeat monitoring, and fault recovery through approaches such as voting and state synchronization. Modifiability tactics aim to control the time and cost of changes and include localizing modifications, limiting ripple effects, and techniques for managing dependencies between modules. Performance tactics focus on generating responses to events within time constraints.

1. Part Two:
Creating an Architecture
2nd Ed.
Len Bass, Paul Clements, Rick
Kazman

2. Chapter 5:
Achieving Qualities
 The tactics used by the architect to create a design
using design patterns, architectural patterns, or
architectural strategies.
 An architectural pattern or strategy implements a
collection of tactics.
2

3. Introducing Tactics
 A tactic is a design decision that influences the
control of a quality attribute response.
 A collection of tactics is an architectural strategy
(more in Ch. 12).
 Tactics can refine other tactics: redundancy can be
refined into data or computational redundancy.
 Patterns package tactics: an availability pattern
uses both redundancy & synchronization tactics.
3

4. Availability Tactics
 Recall: A failure occurs when the system no longer
delivers a service that is consistent with its
specification;
 Possibly a fault or a combination of faults has/have the
potential to cause a failure
 Recall: also that Recovery and Repair are also an
important aspect of availability.
 The tactics we discuss in this section will keep faults
from becoming failures or at least bound the effect of
faults and make repair possible
4

5. Approaches to maintaining
availability
 It may involve some type of
 Redundancy
 Health monitoring to detect a failure
 Recovery when a fault is detected
 In some cases the monitoring and recovery is
 Automatic
 And in others it is
 Manual
5

6. Goal of availability tactics
 Fig 5.2
6

7. Availability Tactics
7
Fig 5.3 Summary of availability tactics

8. Availability Tactics: Fault
Detection
 Ping/Echo:
 One component issues a ping and expects to receive
back an echo within a predefined time
 May be used with a single or group of components
 Clients use it to ensure that server object and
communication path to server are operating within
expected performance bounds
 Organized in hierarchy (higher level fault detector pings
lower levels ones and vice versa)
8

9. Availability Tactics: Fault
Detection
 Heartbeat(dead man timer)
 One component emits a heartbeat message periodically
and other component listens for it.
 If heartbeat fails, the originating component assumed to
have failed and a fault correction component is notified
 A heartbeat can also carry data e.g. ATM
 Exception
 Raised when one of the faults classes execute
 The exception handler typically executes in the same
process that introduced exception
9

10. Availability Tactics: Fault
Detection
 The ping/echo and heartbeat tactics operate among
distinct processes
 Exception tactics operate within a single process.
 The exception handler will usually perform a semantic
information of the fault into a form that can be
processed
10

11. Availability Tactics
11
Fig 5.3 Summary of availability tactics

12. Availability Tactics: Fault
Recovery(preparation & repair)
 Voting
 Processes running on redundant processors
 Each take equivalent input and a simple output value
that is sent to the voter
 If the voter detects the deviate behavior from a single
processor, it fails it
 The voting algorithm can be
 Majority rules
 Preferred component
 Or some other
 This method is used to correct
 Faulty operation of algorithm
 Failure of processor
12
• Same algorithm-redundancy
detects only processor fault
• Extreme diversity(different
developers-dissimilar
platforms)
• Less extreme (single
component-dissimilar
platform)

13. Availability Tactics: Fault
Recovery(preparation & repair)
 Active redundancy (Hot restart)
 All redundant components respond to events in parallel
 Passive redundancy (Warm restart/ dual redundancy/
triple redundancy)
 One component (the primary ) responds to events and inform the
other components (the standbys) of state updates they must make
 Spare
 A standby spare computing platform is configured to replace many
different failed components
 It must be rebooted to appropriate s/w configuration and have its
state initialized when a failure occurs.
 Making a checkpoint of the system state to a persistent device
periodically- resume to that persistent state afterwards 13

14. Availability Tactics
14
Fig 5.3 Summary of availability tactics

15. Availability Tactics: Fault
Recovery(Recovery-reintroduction)
 Shadow operation
 A previously failed component may be run in “shadow-mode” for a
short time.
 It mimics the behavior of working components before actual restore
 State Synchronization
 Passive and active redundancy tactics require the component being
restored to have its state upgraded before its return to service.
 State updating may depends on
 Down time, size of update, number of messages to update
 Single message to state-update is preferable
 Incremental state upgrades with periods of service may lead to
complicated s/w
 Checkpoint/ roll back
 It is a recording of consistent state created either periodically
or in response to specific events. 15

16. Availability Tactics
16
Fig 5.3 Summary of availability tactics

17. Availability Tactics(Fault prevention)
 Removal from service
 Removes a component of the system from operation to undergo
some activities to prevent anticipated failures e.g. Rebooting (to
prevent memory leaks)
 May be automatic/ manual
 Transaction
 It is the bundling of several sequential steps such that the entire
bundle can be undone at once.
 If one process fails other data is prevented from taking effect
 Also prevent collisions among several simultaneous threads
accessing the same data
 Process monitor
 Once a fault in a process has been detected, a monitoring process
delete the nonperforming process and create a new instance of it,
17

18. Modifiability Tactics
18
Fig. 5.4 Goal of modifiability tactics

19. Modifiability Tactics
 Tactics to control modifiability have as their goal
controlling the time and cost to implement, test and
deploy changes.
19

20. Modifiability Tactics
20
Fig. 5.5 Summary of modifiability tactics
Reducing the number
of modules that are
directly affected by a
change.

21. Modifiability Tactics
21
Fig. 5.5 Summary of modifiability tactics
Limiting modifications to the
localized modules or prevent
indirect change to occur (i.e.
dependent classes/modules)

22. Modifiability Tactics
22
Fig. 5.5 Summary of modifiability tactics
Deals with controlling
deployment time and
cost

23. Modifiability Tactics
23
Fig. 5.5 Summary of modifiability tactics

24. Modifiability Tactics
 Localize modifications
 Maintain semantic coherence
 Refers to the relationships among responsibilities in a module
 Goal is to ensure that all of these responsibilities work together without
excessive reliance on other modules.
 Achievement of this goal comes from choosing responsibilities that have
semantic coherence
 One sub-tactic is to abstract common services (also supports modifiability)
 Example: use of application frameworks and other middleware software
 Anticipate expected changes
 For each change, does the proposed decomposition limit the set of modules
that needs to be modified to accomplish it? Or
 Do fundamentally different changes affect the same module?
 In practice, it is difficult to use by itself , it is usually used in conjunction with
semantic coherence
24

25. Modifiability Tactics
Localize modifications…
 Generalize the module
 Making a module general allows it to compute a broader range of
functions based on input
 Limit possible options
 Modifications, especially within a product line may be far ranging
and hence affect many modules.
 Restricting the possible options will reduce the effect of these
modifications
25

26. Modifiability Tactics
26
Fig. 5.5 Summary of modifiability tactics

27. Modifiability, con’t
 Prevent Ripple Effects
 It is the necessity of making changes to modules not directly
affected by it.
 E.g. If module A is changed to accomplish a particular modification,
then module B is changed only because of the change to module A. B
has to be modified because it depends, in some sense, on A.
 There are eight types of dependencies:
1. Syntax of data and service
2. Semantics of data and service
3. Sequence of data and control(timing)
4. Identity of an interface of A
5. Location of A (runtime)
6. Quality of service/data provided by A
7. Existence of A
8. Resource behavior of A
27

28. Ripple Effects, con’t
 Hide information
 Information hiding is the decomposition of responsibilities for an entity
into smaller pieces and choosing to make private/ public
 The goal is to isolate changes within one module and prevent changes from
propagating to others.
 Oldest technique
 Strongly related to “anticipate expected changes”
 Maintain existing interfaces
 Adding interfaces
 Adding adapter
 Providing a stub A
28

29.  Restrict communication paths
 Restrict the modules with which a given module shares data
 Use an intermediary
 Data (syntax) repositories i.e. MVC , PAC
 Service (syntax) i.e. façade, bridge, mediator, strategy, proxy, factory
 Identity of an interface of A i.e. broker pattern can be used to mask changes
 Location of A (runtime)
 Resource behavior of A or Resource controlled by A
 Existence of A i.e. factory pattern has the ability to create instances as
needed
29
Ripple Effects, con’t

30. Modifiability Tactics
30
Fig. 5.5 Summary of modifiability tactics

31. Modifiability, con’t
 Defer Binding Time
 Runtime registration
 Supports plug-and-play operation at the cost of additional overhead to
manage the registration . Publish/ subscribe registration for example, can be
implemented at either runtime or load time
 Configuration files
 Are intended to set parameters at startup
 Polymorphism
 Allows late binding of method calls
 Component replacement
 Allows load time binding
 Adherence to defined protocols
 Allows runtime binding of independent processes.
31

32. General Definition &
Performance
32
Definition of tactics
Performance tactics (p. 111)

33. Performance Tactics
 The goal is to generate a response to an arriving
event within some time constraint.
 Event: single or stream; message, expiration of a time
interval, detection of a state change, etc.
 Performance tactics control the time within which
a response is generated.
 Latency is the time between the arrival of an event
& the generation of a response.
33

34. Response Time
 Two basic contributors:
1. resource consumption
 CPU, data stores, network communication bandwidth, memory,
buffers, etc.
 Events can be of varying types and each goes through varying
sequence.
 E.g. A message is generated by one component, is placed on the
network, and arrives at another component .
 It is then placed in a buffer, transformed in some
fashion,(Marshalling term used by OMG uses for this
transformation) processed according to some algorithm… output
buffer…output…
34

35. Response Time
2. blocked time
 contention for resources
 Multiple streams vying for same resources or
 Different events in the same stream vying for the same resources
contribute to latency.
 availability of resources
 Even in the absence of contention, computation cannot proceed if
a resource is unavailable may be caused by
 An offline resource
 Failure or any other reason
In any case an architect ,must identify places where resources
unavailability might cause a significant contribution to latency
 dependency on other computation
 A computation may have to wait because it must synchronize with
the results of another computation
 With this background , we turn to our three tactic categories 35

36. Performance Tactics
36
Fig. 5.7: Summary of performance tactics

37. Resource Demand
 Event streams are the source of resource demand.
 Two characteristics:
 time between events in a stream
 how much of a resource is consumed by each request
 Tactic: reduce resources required to process an
event stream
 increase computational efficiency
 reduce computational overhead
37

38. Resource Demand, con’t
 Tactic: reduce the number of events processed
 manage event rate
 control frequency of sampling
 Tactic: control use of resources
 bound execution times
 bound queue lengths
38

39. Resource Management
 If the demand for resources isn’t controllable, they
might be managed by these tactics:
 introduce concurrency
 maintain multiple copies of either data or computations
 increase available resources
39

40. Resource Arbitration
 When there is contention for a resource, the
resource must be scheduled:
 processors, buffers, networks are all scheduled
 A scheduling policy has two parts:
 a priority assignment
 Dispatching
 Give a read to page 114, 115
40

41. Common Scheduling Policies
 First-in/First-out all requests are equal
 Fixed-priority scheduling are prioritized based on:
 semantic importance - statically assigned based on
domain characteristics (mainframes)
 deadline monotonic - statically assigned with higher
priority to streams with shorter deadlines (real-time)
 rate monotonic - statically assigned with higher priority
to streams with shorter periods (real-time)
41

42. Scheduling Policies, con’t
 Dynamic priority scheduling
 round robin
 earliest deadline first
 Static scheduling - cyclic executive schedule with
pre-emption points & sequence determined offline
42

43. Additional Tactics
 Security
 Resisting attacks
 Authenticate users, Authorize users,
 maintain data confidentiality, Maintain integrity
 , limit exposure, limit access
 Detecting attacks
 Recovering from attacks
 Testability
 Input/Output
 Record playback,
 separate interface from implementation,
 specialize access routes/ interfaces
 Internal monitoring
 Built-in monitors
43
•Usability
•Runtime
•Design-time

44. Tactics & Patterns
 An architect usually chooses a pattern or collection of
patterns, but any pattern implements several tactics.
 Each of these is often concerned with different quality
attributes, & any implementation of the pattern makes
choices about tactics.
 So, the analysis process involves understanding all tactics
embedded in an implementation.
 The design process involves making a judicious choice of
what combination of tactics will achieve the system’s
desired goals.
44

45. Patterns & Styles
 Key features & rules for combining them to preserve
architectural integrity:
 a set of element types
 a topological layout indicating their relationships
 a set of semantic constraints
 a set of interaction mechanisms that determine
coordination
45

46. Categorized Patterns
46