Wk3

The set of structures (elements, relationships, properties) needed to judge whether a system can meet key requirements

Yes, whether designed or "just grown"

Structure determines qualities beyond functionality, like ease of change and bug rate

The effort required to meet the client's needs over the long term

Its structures achieve the qualities considered important, possibly at the expense of less important ones

How easily developers can understand the software while working on it

How easily the software can be added to or changed

Understandability and modifiability

Performance

Ease of applying test inputs and observing outputs to verify the software

Ease of transferring software to a different hardware or software platform

Ease of understanding, modifying and testing code

Confidentiality, integrity and availability

The software being usable when needed

Ease of extending the software to handle larger loads

Ability to respond well to abnormal conditions or edge cases

Ability to avoid incorrect outputs or actions

Which abstractions or data structures the system uses

How functionality is split into subsystems and modules

How activities map to tasks or threads, and how those map to modules

Whether and how parts of the system communicate

How memory, peripherals and computing time are managed

When in the lifecycle (build, run time, later) other decisions take effect

Which qualities matter, what structures achieve them, and how to communicate the decisions

From the requirements

Timing performance

Resource performance

Safety, robustness, testability or availability

No design can support every possible change equally

Components share as little information as possible; changeable decisions are hidden behind stable interfaces

Components communicate with as few others as possible through the smallest interfaces

Components map clearly to problem-domain concepts

Each component is responsible to one stakeholder, so has one source of reasons to change

Components are open for extension but closed for modification

Components should depend on stable abstractions rather than concrete details

Information Hiding and Minimal Communications

Single Responsibility, Open-Closed and Dependency Inversion (among others)

A recurring structural template that is a good starting point for a design

Yes, they can be used together or nested

Software split into layers, each serving the layer above through a defined interface and only talking to adjacent layers

A Hardware Abstraction Layer (HAL)

Portability and modifiability

No, layering is just one pattern

Core logic talks to the outside only through abstract ports; adapters convert each external device to a port interface

Separating external interactions from internal logic

Portability, testability and modifiability

A core of common services with problem-specific components plugged in

An RTOS with tasks running on it

Open-Closed

Data-transforming components (filters) connected by possibly buffered pipes

Signal processing systems

Modifiability (loose coupling) and performance (parallelism)

A terse one-page document of purpose, key structure, driving requirements, trade-offs and rationale

An incremental record of a decision: the concern, options considered and reasons

Context, Decision, Consequences

Proposed, Accepted, Rejected, Superseded

A lightweight approach to diagramming software architecture

They show structure but need extra documentation to explain why

By assessing it against scenarios that capture quality requirements

Check whether the architecture handles the scenario without changes

Assess the number and scope of changes needed

Quantitative estimates of magnitude, complexity or cost of the changes

User stories

Individual design decisions that influence quality attributes; patterns combine them

Strength of relationships between elements in different modules

Strength of relationships between elements within the same module

Increase cohesion, decrease coupling

Defer binding or configuration until later in the lifecycle

Control demand and manage resources

Bounding execution time

Eliminating intermediaries to reduce overhead

Keep state in one place, sandbox the system, replay recorded interactions

It needs indirection, which adds overhead

It needs indirection, which adds overhead

Speed versus memory

Responding fast may mean avoiding sleep wake-up latency

Deterministic timing may require polling instead of reacting immediately to events

Arduino digitalWrite() is about 20× slower than direct port writes

Assess existing structures, list quality requirements, evaluate existing architecture, apply patterns/tactics and re-evaluate

A collection of elements and relationships between them

Static, dynamic and allocation

Conceptual abstractions a developer works with (decomposition, dependency, class)

Relationships in executing software (collaboration, data-flow, task)

Mapping of software to external things (memory map, implementation, deployment)

"Submodule of"

"Depends on"

Inheritance and association

Processes and stores, connected by flows of data

Tasks and objects, connected by interactions

Data and addresses

Software and hardware

Decomposition or class views

Dependency/layer and memory map views

Data-flow and collaboration views

Task view

Data-flow diagrams

Safety, liveness and responsiveness

Nothing bad ever happens; no incorrect state is reached

Something useful eventually happens; the program makes progress

The program makes progress within a deadline

To improve maintainability and responsiveness of independent activities

Safety

When tasks make uncoordinated changes to a shared resource

A possible mixed sequence of actions from concurrent tasks, each keeping its own order

An unpredictable outcome that depends on the interleaving of actions

Code sensitive to race conditions that must execute atomically

An action that executes as one uninterruptible unit

A single machine instruction

No, it compiles to several load/add/store instructions

A context switch mid-update can overwrite another task's change

Any interleaving could happen

Each task controls when others run, so it defines its own atomic sections

Immutability, atomic data, synchronization, containment

Never change shared values once created

Allow only one owner of a memory chunk at a time

Share only data that can be updated atomically

Force tasks to align at points so changes appear atomic

One task owns the resource; others interact only via messages

Synchronization and containment

Synchronization

Containment (plus immutability, atomic data and internal synchronization)

A lock that only one task can hold at a time; others block until it is released

Mutual exclusion

xSemaphoreCreateMutex

xSemaphoreTake

xSemaphoreGive

SemaphoreHandle_t

semphr.h

Liveness

Tasks waiting on each other so none make progress

A circular wait (cycle of ungranted requests)

Yes, e.g. by taking a mutex it already holds

A recursive mutex

Tasks aren't blocked but keep cycling without progress

Using timeouts to escape deadlock

Deadlock

Always acquire mutexes in the same order

Yes, if tasks block waiting for responses in a cycle

Mutex takeive are unbalanced, and the mutex is held during the delay

Restrict connection directionality and minimise circular dependencies

Data flows one way through a chain of tasks, each transforming it

It contains no cycle of tasks

Yes

A client initiates requests; a server passively waits and responds

The server only waits for requests and the client only waits for responses

Only one at a time

Yes, forming a tree with no cycles

No

A passive module that encapsulates a resource behind functions with internal synchronization

Monitor object

When a synchronous response is needed and blocking won't delay other tasks

Mutexes aren't scattered, clients can't touch them, and lock order is enforced in one module

No, it risks deadlock

A task that contains a resource and serves requests through a message interface

Active object

When background work is needed, or long critical sections shouldn't block callers, and async responses are acceptable

Event-driven

A high-priority task is blocked by a low-priority task holding a mutex, which is itself preempted by a medium task

The high-priority task may miss its deadline

A low-priority task blocking a higher one temporarily inherits the higher priority

Yes, for mutexes

Avoiding priority inversion altogether

Some tasks can't progress because they can't get resources or CPU time

When several share the same priority

Equal-priority tasks share CPU time round-robin

One that ensures every waiting task eventually acquires it, e.g. by queuing

No

A synchronization tool with an atomic count; decrementing below zero blocks the task

A semaphore whose count is only 0 or 1

A mutex starts released and should only be released by its holder; a semaphore can be given by any task

Mutex to protect shared resources; semaphore to signal between tasks

xSemaphoreCreateBinary

xSemaphoreTake

xSemaphoreGive

Task notifications

Code without tests

It adds to the mess and easily introduces bugs

It's time-consuming, means maintaining two versions, and brings new bugs

There's no guarantee functionality is preserved

Adding tests

Targeted, characterisation and strategic tests

Tests added where code needs to change

Test where change is needed, test-drive changes and new code, then refactor

Leave the code cleaner than you found it

Iterative, as-needed, and still allows feature delivery

Tests written to capture and verify understanding of existing behaviour

No, only to document actual behaviour

When the documentation is outdated

Tests added proactively to protect key functionality

A flight controller's control algorithm or a medical device's safety checks

Identify the area, find test points, break dependencies, write tests

A place in code where you can control the code under test and observe its effects

Function calls

Encapsulate them as soon as possible

They don't change during refactoring, so tests aren't fragile

One that must change whenever the code is refactored

Isolating the code under test from the rest of the application

Make the smallest refactoring to create test points, possibly a temporary global

Rigorous manual testing and a colleague's review

Rename it with a macro under a UNIT_TEST define

They introduce technical debt

Use a macro so the loop runs once under UNIT_TEST

Extract code into a separate module or function and cover the change with manual tests

Testability and clean design reinforce each other, together making code changeable