Quality

Background-Fkt Use-Case2 C0184

This use case is a proxy for use cases that can be delayed if resources are sparse,
e.g. polling for software updates or performing data backups.

Dynamic-Fkt Use-Case C0185

This use case is a proxy for use cases that allow to produce degraded or no results if memory gets low.
E.g. A list of search results may be truncated, an undo-history may have limited size, the number of simultaneously open windows may be limited by the available memory.

Reliable-Fkt Use-Case C0186

This use case is a proxy for use cases that shall always work (available and reliable).

Bounded-Fkt Use-Case C0187

This use case is a proxy for use cases that allow to produce degraded results if memory gets low or an upper boundary of resource-consumption is reached.
This is use-ful e.g. to enhance security when processing input data of unknown size or to prevent stealing resources from higher-priority dynamic functions.

Quality expectations depend on use cases C0188

A program/application typically solves several use cases with different quality expectations.

Sufficient Memory C0203

For dedicated use cases and functions, the software shall be able to access sufficient memory.

--> Reliable-Fkt Use-Case R0240

Access Memory immediately C0202

For dedicated use cases and functions, the software shall access required memory within 1 usec.

--> Reliable-Fkt Use-Case R0239

Stop and Restart Later C0206

In case of insufficient amount of memory, the software shall stop operating and be started again at a later point in time.

--> Dynamic-Fkt Use-Case R0244

Delay Function C0204

For dedicated use cases and functions, the software shall delay processing till enough memory is available.

--> Background-Fkt Use-Case2 R0243

Degrade Result C0205

For dedicated use cases and functions, the software shall calculate a result where accuracy may degrade if memory is sparse.

--> Bounded-Fkt Use-Case R0242

--> Dynamic-Fkt Use-Case R0246

Abort Function C0207

In case of insufficient memory, the software shall abort the function.

--> Bounded-Fkt Use-Case R0241

--> Dynamic-Fkt Use-Case R0245

Schedule tasks C0148

- Schedule tasks that require memory to prevent contention
E.g. only one memory-intensive task may run at a time

Region based Memory Management C0149

A region/arena/stack is valid while performing one operation/thread. It provides single-threaded access only. It is either used stack-like or cleaned up when the operation/thread is finished.
This concept allows to fast allocate and completely release memory arenas. It prevents fragementation within the stack. It supports NUMA architectures. It may be faster than concurrent access to single heap. It allows to reserve appropriate memory arenas for more important tasks
see https://en.wikipedia.org/wiki /Region-based_memory_management
Implementation support by e.g. polymorphic_allocator and memory_resource(C++17/20) rust allocator: https://rust-lang.github.io/rfcs/1398-kinds-of-allocators.html

Static Allocation C0150

All memory is statically allocated except for stacks. The number of threads is static.
Example implementations:
- classic AUTOSAR, MISRA-C, MISRA-C++,
- Ada-Spark,
- NASA Power-of-Ten
- crystal_facet_uml (except gtk3+sqlite3)
- GPSd deamon (see the_architecture_of _open_source_applications__volume_ii.pdf)

Object Pools C0151

Pools of same-type objects are pre-allocated.
This concept guarantees a predefined amount of memory and prevents fragmentation
Examples: synchronized_pool_resource(C++17) unsynchronized_pool_resource(C++17)

Static Size Buffering C0194

Windowing Concept Streaming/Buffering

Concepts to plan and control memory usage C0197

--> Stacks R0228

--> Static Allocation R0215

--> Static Size Buffering R0216

--> Schedule tasks R0217

--> Object Pools R0218

--> Region based Memory Management R0219

--> Control Resource Command R0227

Control Resource Command C0169

For detailed tactics, see Memory Controlling Patterns/Tactics.
Source: Software Architecture in Practice (C0165) in Bibliography.

Stacks C0199

A stack deallocates memory only in the reverse order as it was allocated before.
Variant: monotonic_buffer_resource(C++17)

Dynamic Allocation accepting controlled death C0123

- Accept memory fragmentation (physical pages as well as virtual addresses)
- Swap memory pages to flash
- End a process if no memory available

Weak Pointers / Caches C0125

- There are managed data structures (hashmaps, caches) that hold data as long as much memory is available and that drop data when memory becomes sparse
Example implementations: Java Weak Hashmap, sqlite, OS file system caches
Challenge: The cache needs to know when memory is needed elsewhere.

Moving Memory Objects C0126

Some instance manages memory (e.g. OS) while another instance uses it (e.g. App).
This mamagement may reduce/fix fragmentation issues.
Examples:
- The java virtual machine can move objects while a java application runs
- The classic MacOS7-9 could move memory while the application holds a handle (pointer to a pointer)
- Todays processors convert virtual to physical addresses on the fly (reallocations via e.g. sbrk, mmap)

Dynamic Allocation accepting degradation C0155

Continue working, accept that some requested functionality
- cannot be performed at current point in time
- with expected precision
- within expected timeframe

Remote Execution C0195

Required memory may be provided on a different hardware, e.g. Cloud

Dynamic Allocation accepting sudden death C0196

- Linux overcommit
- Compress memory pages
- End any process if page-fault by r/w operation to overcommitted memory
Example Implementations: Android App Management (see low memory killer daemon: lmkd) Linux OOM-Killer

--> Dynamic Allocation accepting controlled death R0214

Concepts to manage memory on the fly C0198

--> Memory Estimation R0229

--> Weak Pointers / Caches R0220

--> Dynamic Allocation accepting degradation R0221

--> Remote Execution R0222

--> Moving Memory Objects R0223

--> Dynamic Allocation accepting controlled death R0224

--> Dynamic Allocation accepting sudden death R0225

--> Manage Resources R0226

Manage Resources C0170

For detailed tactics, see Memory Management Patterns/Tactics.
Source: Software Architecture in Practice (C0165) in Bibliography.

Memory Estimation C0200

Estimate required memory, expected fragmentation overhead and additional buffer to prevent out-of-memory situations.

Simplicity C0098

--> KISS R0106

--> YAGNI R0107

--> Occam's razor R0108

KISS C0094

Keep it simple and stupid

Occam's razor C0097

Among competing hypotheses, the one with the fewest assumptions should be selected

YAGNI C0095

You aren't gonna need it

SOLID C0096

--> Interface Segregation R0101

--> Liskov Substitution R0102

--> Dependency Inversion R0103

--> Open/Closed R0104

--> Single Responsability R0105

Single Responsability C0089

A software component shall be responsible for one topic only

Open/Closed C0090

Open for extension, closed for modification

Interface Segregation C0092

Avoid general purpose interfaces, design multiple interfaces specific to the needs of different users/clients

Liskov Substitution C0091

An implementation of an interface can be replaced by another implementation of the same interface. In object oriented design, types can be replaced by subtypes.

Dependency Inversion C0093

A software component shall depend on abstractions, not on concrete implementations

use Abstractions: F0046

Maturity C0035

Coding Guidelines C0062

Coding guidelines define how to get reproducible behavior of software. Managing system resources is a key factor.

static thread model: F0010

Execution threads shall not be started/stopped dynamically

no endless loops: F0008

Every loop shall have a counter to ensures that after a predefined maximum value the loop is definitely quit

consistent error handling: F0009

Inconsistencies in error handling make bugs in error handling more likely

valid Memory Addresses: F0007

Only valid memory addresses may be read/written.

- Java solves this by prohibiting pointers,
- In C, check pointers and array indices before usage,
- In C++, use std::shared_ptr and std::vector,
- Kotlin even distinguishes between nullable references and non-null references.

no dynamic Memory: F0006

When the program is running,
- it must not fail due to - memory fragmentation (virtual addresses/physical pages) - out of memory situations
- it shall have a defined timing (which new/malloc cannot provide)

no recursion: avoid Stack overflow: F0005

lock critical sections: F0024

Always lock critical sections.

single point of return: simple control flow: F0023

Simple control flow is key to understandable code

improves --> Maturity R0040

Example Guidelines C0176

Spark/ADA: Avionics: F0076

see C0173#name

Power of Ten: NASA: F0077

SecureC: F0078

MISRA-C/C++: automotive: F0079

implements --> Coding Guidelines R0174

Error Handling Concept C0220

An error handling concept
1) defines which and how faults and anomalies are detected,
2) which faults and anomalies are treated as errors,
3) how errors are propagated from the point of occurrence to a point where these are handled, e.g. throw/raise of exceptions or passing on error codes,
4) by which categories errors are classified,
5) which category is handled in which way,
6) who shall be informed on which way, e.g. a user by a popup-window, an operator by an error log,
7) if and how to resume operation.

supports --> Recover-ability R0267

Recover-ability C0037

Error Handling Example C0224

--> detect and interpret R0272

--> propagate and re-interpret R0273

--> detect multiple errors and interpret R0280

--> inform stakeholder R0276

--> abort, degrade, retry or continue R0278

example --> Error Handling Concept R0275

detect and interpret C0225

--> propagate and re-interpret R0274

propagate and re-interpret C0226

re-interpretation is necessary when higher-level functions know how to interpret errors reported by lower level functions. E.g. a search function may fail to find a record. The caller may be able to decide if this is intended or if this is a severe error.

--> inform stakeholder R0277

inform stakeholder C0227

stakeholders may be:
- developer
- operator
- user

--> abort, degrade, retry or continue R0279

abort, degrade, retry or continue C0228

detect multiple errors and interpret C0229

--> propagate and re-interpret R0281

Partitioning C0075

synonym for Compartments
see Tactics for Partitioning.

SoC HW Partitions C0121

The HW provides e.g.
- a trusted execution environment for cryptographic computations
- a separated monitoring CPU to supervise the functional CPUs

Monitoring CPU: F0071

Trusted Execution Environment: F0072

implements --> Partitioning R0141

Network Partitioniong C0076

Network Zones (VLANs): F0029

Gateways/Firewalls/Proxies: F0030

implements --> Partitioning R0087

SW Partitions C0077

Hypervisor Partitions: F0031

OS-Process Boundaries: F0032

Microkernel OS: F0033

for Device Driver Partitioning

Containers: F0034

Linux-Containers, QNX-Partitions, Address-space separation

implements --> Partitioning R0088

Trust Levels C0132

Create a Multi-Layer security, where elements of one layer mistrust these of other layers. If one layer is compromized, the next still holds up.
Examples:
1) Internet - DMZ - Intranet
2) OS-Process (user), root-acess, OS(kernel-space), Hypervisor, Trusted Execution Environment of SoC

require --> Partitioning R0144

TOCTOU C0223

Design and use interfaces in a way that time of check (TOC) (e.g. access rights, existance, ...) is not different from the time of use (TOU)

supports --> Non-Repudiation R0270

supports --> Integrity R0271

Non-Repudiation C0038

Integrity C0040

Functional Safety C0081

Monitoring C0084

Function Monitoring (L2): F0040

System Monitoring (L3): F0041

- alive Monitoring: F0059

- control flow supervision: F0060

may support a claim --> Functional Safety R0093

Input Signal Validation C0083

Precondition is a specification of valid input signals.
This can be implemented by different means, e.g.
- assert() statements as declared in assert.h
- if(COND) {...} else {...} statements where the else-path logs the error
For Security: Check input signals already at the gate, not later.

may support a claim --> Functional Safety R0095

Real Time Execution C0085

Guaranteed Calculation Time: F0044

Real Time Clock: F0045

may support a claim --> Functional Safety R0098

Trusted Data Paths C0082

Dual Data Paths: F0042

End to End Protection: F0043

may support a claim --> Functional Safety R0094

Cryptographic Signatures C0079

asymmetric: F0038

shared key (symmetric): F0039

may support --> Trusted Data Paths R0097

Partitioning C0075

synonym for Compartments
see Tactics for Partitioning.

may support a claim --> Functional Safety R0096

freedom from interference (FFI) C0233

temporal freedom from interference: F0085

spacial freedom from interference: F0086

supports --> Partitioning R0284