📖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.

• 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)

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

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

1. source of stimulus
2. stimulus
3. environment
4. artifact (system or element affected)
5. response
6. response measure

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)

• 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))

• 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.

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?

• 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

• periodic = regular time intervals
• stochastic = probabilistic distribution
• sporadic = neither periodic, nor stochastic (still could be described)

• latency
• deadlines in processing
• throughput
• jitter = allowable variability in latency
• number of events not processed

• 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

• 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

• 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

• 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)

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

• 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

• “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.

• 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

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

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

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

1. documentation roadmap
2. how a view is documented
3. system overview
4. mapping between views
5. rationale
6. directory index, glossary, acronym list

1. raw view extraction
2. database construction
3. view fusion
4. architecture analysis