📖Software Architecture in Practice

p.3

The architecture is a bridge between […] (often abstract) business goals and the final (concrete) resulting system.

p.7

System architecture is concerned with a total system, including hardware, software, and humans.

p.8

Enterprise architecture is a description of the structure and behavior of an organization’s processes, information flow, personnel, and organizational subunits aligned with organization’s core goals and strategic direction.

_

Architects design structures. They document views of those structures.

“Useful architectural structures” table on p.15

Structures (p.22):

• module structures - as a set of code or data units, that have to be constructed or produced

• component-and-connector - how structured as a set of elements that have runtime behavior (components) and interactions (connectors)

• allocation - how system relates to non-software structures (CPUs, file systems, networks, development teams)

Software architecture allows:

1. enabling a system’s quality attributes

2. reasoning about and managing change

3. predicting system qualities

4. enhancing communication among stakeholders

5. carrying early design decisions

6. defining constraints on an implementation → Constraints as guide rails (e.g., architecture may set performance budget for each element)

7. influencing the organizational structure

8. enabling evolutionary prototyping

9. improving const and schedule estimates

10. supplying a transferable, reusable model

11. allowing incorporation of independently developed components

12. restricting the vocabulary of design alternatives

13. providing a basis for training

Architecture is mostly driven by quality attributes rather than functionality. → Functional requirements do not drive architecture

… the architecture mainly provides containers into which the architect places functionality. Functionality is not so much a driver for the architecture as it is a consequence of it. ---p.41

architecture steps:

1. making a business case for the system (why the business wants to pursue an opportunity. expected cost/benefit)

2. understanding architecturally significant requirements

3. creating or selecting the architecture

4. documenting and communicating the architecture

5. analyzing or evaluating the architecture

6. implementing and testing the system based on the architecture

7. ensuring that the implementation conforms to the architecture

Systems are usually redesigned not because they fail functional requirements, but because they lack quality attributes (too slow, insecure, etc.)

Quality attribute requirements (structure):

1. source of stimulus

2. stimulus

3. environment

4. artifact (system or element affected)

5. response

6. response measure

Requirements:

1. functional

2. quality attributes

3. constraints (design decisions with zero degree of freedom. i.e., already made)

_

Dependability is the ability to avoid failures that are more frequent and more severe than is acceptable. ---Avizienis (p.79)

A failure’s cause is called a fault.

availability = MTBF / (MTBF + MTTR)

Availability tactics:

• Detect faults:

  • ping/echo

  • monitor

  • heartbeat (e.g., watchdog) (like ping/echo but component initiates (instead of monitor))

  • time stamp

  • sanity checking

  • condition monitoring

  • voting

  • replication

  • function redundancy (like voting, but copies of component are independently designed or implemented)

  • analytic redundancy (copies of component have different input or use different method to calculate output. e.g. aircraft altitude by GPS, barometer, etc.)

  • exception detection

  • self-test

• Recover from faults:

  • preparation and repair

    • active redundancy (how spare) (two copies of the component handle every requests in parallel)

    • passive redundancy (warm spare) (only one copy of the component handles requests. second copy syncs state)

    • spare (cold spare) (second copy starts when first one fails)

    • exception handling

    • rollback

    • software upgrade

    • retry

    • ignore faulty behavior

    • degradation

    • reconfiguration

  • reintroduction

    • shadow

    • state re-synchronization

    • escalating restart

    • non-stop forwarding (NSF)

• Prevent faults:

  • removal from service (software rejuvenation)

  • transactions (ACID, 2-phase commit 2PC)

  • predictive model

  • exception prevention (smart pointers, semaphores, etc.)

  • increase competence set (handle more cases (instead of throwing exceptions or failing))

availability checklist p.96

Interoperability tactics:

• Locate:

  • discover service

• Manage interfaces;

  • orchestrate

  • tailor interface

q

We cannot let standards drive our architectures. We need to architect systems first and the decide which standards can support desired system requirements and qualities. ---p.113

The nice thing about standards is that there are so many to choose from.

Questions to consider for modifiability

1. What can change?

2. What is the likelihood of the change?

3. When is the change made and who makes it?

4. What is the cost of the change?

Modifiability tactics:

• Reduce the size of a module

  • split module

• Increase cohesion

  • increase semantic coherance

• Reduce coupling

  • encapsulate

  • use an intermediary

  • restrict dependencies

  • refactor

  • abstract common services

• Defer binding

  • compile/build time

    • component replacement

    • compile-time parameterization

    • aspects

  • deployment time

    • configuration-time binding

  • startup/initialization

    • resource files

  • runtime

    • runtime registration

    • dynamic lookup

    • interpret parameters

    • startup time binding

    • name servers

    • plug-ins

    • publish-subscribe

    • shared repositories

    • polymorphism

Performance events:

• periodic = regular time intervals

• stochastic = probabilistic distribution

• sporadic = neither periodic, nor stochastic (still could be described)

Response characteristics:

• latency

• deadlines in processing

• throughput

• jitter = allowable variability in latency

• number of events not processed

Tactics for Performance:

• Control resource demand

  • manage sampling rate

  • limit event response (add a bounded queue and process event up to a set maximum rate)

  • prioritize events

  • reduce overhead

  • bound execution times

  • increase resource efficiency

• Manage resources

  • increase resources

  • introduce concurrency

  • maintain multiple copies of computations (replicas + load balancer)

  • maintain multiple copies of data (caching, data replication, predictive processing)

  • bound queues sizes

  • schedule resources

Pattern-Oriented Software Architecture (book recommendation)

Tactics for Security:

• Detect attacks

  • detect intrusion (track internal network traffic, detect anomalies, require signatures)

  • detect service denial (compare incoming traffic for previous DoS attack patterns)

  • verify message integrity

  • detect message delay (possibly detects MitM attacks)

• Resist attacks

  • identify actors

  • authenticate actors

  • authorize actors

  • limit access

  • limit exposure (security by obscurity, or distribute critical resources)

  • encrypt data

  • separate entities

  • change default settings

• React to attacks

  • revoke access

  • lock computer

  • inform actors

• Recover from attacks

  • audit trail

  • restore = see availability

Testability tactics:

• Control and Observe System State

  • specialized interfaces (special methods for testing that expose internal state. might break incapsulation)

  • record/playback

  • localize state storage

  • abstract data sources (easier mocking)

  • sandbox

  • executable assertions

• Limit complexity

  • limit structural complexity

  • limit nondeterminism

Tactics for Usability

• Support user initiative

  • cancel

  • undo

  • pause/resume

• Support system initiative

  • maintain task model

  • maintain user model (customization. e.g., control amount of assistance user needs)

  • maintain system model (progress bars estimate time required)

X-ability (how to add own)

1. capture scenarios

2. assemble design approaches

3. model

4. assemble a set of tactics

5. construct design checklist

_

Tactics are atoms and patterns are molecules. ---p.204

Patterns:

• Module patterns:

  • Layered

  • other

• component and connector patterns

  • broker pattern

  • MVC (MVVM, MVP)

  • pipe and filters

  • client-server

  • peer-to-peer

  • service-oriented

  • publish-subscribe

  • shared-data

• allocation patterns

  • map-reduce

  • multi-tier

“Pattern-Oriented Software Architecture” by Buschmann #book

Patterns can be further refined with tactics

Decision trees for examining tactics and trade-offs (p.243)

To avoid analysis paralysis:

• “time boxing” discussions

• do not spend more cost on analyzing a problem, compared to a probable problem cost. i.e., do not spend too much time discussing minor or unlikely issues.

Fairbanks₂₀₁₀

Quality attribute workshop (p.294)

Gathering ASRs (Architecturally Significant Requirements):

• from requirement documents

• interview stakeholders

• from business goals

  Every quality attribute requirement should originate from some higher purpose that can be described in terms of added value. ---p.296

PALM method for capturing business goals --- p.305

Attribute-Driven Design (ADD) p.318

1. choose an element of the system to design

2. identify ASRs for the chosen element

3. generate a design solution for the chosen element (generate and test)

4. inventory remaining requirements and select the input for the next iteration

5. repeat steps 1-4 until all the ASRs have been satisfied

add legends to drawings

views:

• module

• component and connectors (components have interfaces --- ports)

• allocation

documentation for a view:

1. the primary presentation (usually, a diagram or a table)

2. the element catalog

   1. elements and their properties

   2. relations and their properties

   3. element interfaces

   4. element behavior

3. context diagram

4. variability guide

5. rationale

documentation beyond views:

1. documentation roadmap

2. how a view is documented

3. system overview

4. mapping between views

5. rationale

6. directory index, glossary, acronym list

Documenting Software Architectures by Clements #book

Software Architecture reconstruction: (ch. 20)

1. raw view extraction

2. database construction

3. view fusion

4. architecture analysis

manager takes care of communicating with external entities, architect handles internal issues

cross-functional teams are only one of possibilities in resource allocation