Architectures

System Design

Design steps

Given requirements, must design a system to meet them
- System architecture
- User experience
- Program design
Ideal: requirements are independent of design (avoid implementation bias)
Reality: working on design clarifies requirements
- Methodology should allow feedback (strength of iterative & agile methods)

Design principles

Design is an especially creative part of the software development process
- More a “craft” than a science
- Many tools are available; must select appropriate ones for a given project
Strive for simplicity
- Use modeling, abstraction to (hopefully) find simple ways to achieve complex requirements
- Designs should be easy to implement, test, and maintain
Easy to use correctly, hard to use incorrectly
Low coupling, high cohesion

What is architecture

Brooks: Conceptual integrity is key to usability and maintainability; architect maintains conceptual integrity
Johnson: The shared understanding that expert developers have of the system / The decisions you wish you could get right early in a project
Sommerville: Dominant influence on non-functional system characteristics
Highest level organization of system

Levels of abstraction

Requirements
- High level what
Architecture
- High-level how
- Mid-level what
Program design
- Mid-level how
- Low-level what
Code
- Low-level how
Documentation for each step should respect its level of abstraction
- Avoid biasing later steps
- Avoid redundancy

Example

Code

   def lpf(x1, y0, a):
      """exp filter w/ smoothing factor a"""
      return a*x1 + (1-a)*y0
 

Architectural considerations

Architectural models

Diagram and supporting specification
- Be specific with notation
Multiple perspectives
- Conceptual
- Static (subsystems)
- Dynamic (data flow)
- Physical (deployment)
Appropriate level of detail
- A single diagram should fit cleanly on one page
Distinct from program models
- Inheritance diagrams don’t show interactions

Subsystems

Improve comprehensibility of system by decomposing into subsystems
Group elements into subsystems to minimize coupling while maintaining cohesion
Coupling: Dependencies between two subsystems
- If coupling is high, can’t change one without affecting the other
Cohesion: Dependencies within a subsystem
- High cohesion implies closely-related functionality

UML: Package

UML: Component

Replaceable part of a system
- Conforms to and realizes a set of interfaces
- An implementation of a subsystem
- Could be replaced by another component that realizes the same interfaces, and system would still function
Distinct from classes
- Classes may have fields, are assembled into programs
- Components realize interfaces, are assembled into systems

Interface diagram

UML: Node

Physical element that exists at runtime, provides a computational resource
- Computer
- Smartphone
- Network router
Components live on nodes

Example: deployment diagram

Deployment environments

Client/sever

Layered

Partition subsystems into stack of layers
- Layer provides services to layer directly above
- Layer relies on services to layer directly below
Advantage: constrains coupling
Danger: leaky abstractions
- May need services of multiple lower layers

Pipe and filter

Transformation components process inputs to produce outputs
- Subsystems coupled via data exchange
- Good match for data flow models
- May be dynamically assembled
Applications:
- Streaming media
- Graphics shaders
- Signal processing
Caveats:
- Awkward to handle events (interactive systems)
- Rate mismatches if branches merge

Example: Oscillatory

Problem statements:
- develop a reusable system architecture for oscilloscopes.
- An oscilloscope is an instrumentation system that
  - samples electrical signals and displays pictures (called traces) of them on a screen,
  - perform measurements on the signals, and
  - display these on the screen.
- Modern oscilloscopes rely primarily on digital technology and have quite complex software:
  - perform dozens of measurements,
  - supply megabytes of internal storage,
  - interface to a network of workstations and other instruments,
  - provide sophisticated user interface including a touch panel screen with menus, built-in help facilities, and color displays.
- Problem 1: there was little reuse across different oscilloscope products.
- Problem 2: there were increasing performance problems because the software was not rapidly configurable within the instrument.
User requirements:
- develop an architectural framework for oscilloscopes that would address these problems.
- a domain-specific software architecture that formed the basis of the next generation of Tektronix oscilloscopes.

Oscillatory: layered model

Oscillatory: pipe and filter

Repository

Couple subsystems via shared data
- Repository may need to support atomic transactions
Advantages:
- Components are independent (low coupling)
- Centralized state storage (good for backups)
Dangers:
- Bottleneck / single point of failure

Repository: flexibility through indirection

Repository is highly coupled – difficult to change data store
By defining higher-level storage access interface, data store is now lightly coupled