Dependability

From

Justify trust in a program.

• Prevent faults from being introduced during development.
• Design a program to tolerate faults.
• Find and remove faults from a program.
• Characterize failure modes and predict their occurrence.

Judge a computer system by ethical standards.

• Expect ethical, social impact, decolonizing, and anti-oppression goals in a system specification.
• Conceptualize unethical use as an attack, i.e. an oppression fault.
• Consider development-time ethical faults including programmer treatment and classism in the workplace (maintenance staff vs. programmers).
• Justify correctness through the frame of Aristotle’s ethos, pathos, logos.
• Identify Tussle relevant to a program and isolate it using modularity.
• Distinguish attackers by ethical categories as in the Byzantine/Altruistic/Rational model.
• Incorporate contributions by members of marginalized communities.

Craft specifications that define program correctness.

• Create specifications that thoughtfully reflect consideration of the purpose of a program.
• Discuss the intended utility of a program to humans.
• Predict ethical considerations of a program in use.
• Distinguish between correct and dependable code and systems.

Reason about a program and its possible executions.

• Use formal reasoning to create code that is correct by construction, or to verify aspects of existing code.
• Justify the way a program is decomposed, by analyzing an existing set of modules to describe its benefits and drawbacks, by arguing for why a decomposition was designed the way it was, and by improving a decomposition when warranted.
  • separation of concerns
  • Parnas
  • Tussle
• Distinguish safety and liveness properties (e.g. partial correctness, termination) and prove that a program satisfies a property.
• Apply formal methods of structured programming such as analyzing pre- and post-conditions and using predicate transformers.

Write a program that is secure against malicious attack

• Distinguish a system from its environment and identify their common plane, the system boundary.
• Compare the actual behavior of a system and its intended function.
• View the total state of a system as including internal state and external state.
• View a system as a structure of components, perhaps recursively structured, until it rests on components whose internal structure is unknown or uninteresting and are considered atomic.

Debug a program.

• Use static analysis tools, such as compilers and linters.
• Recognize common static errors, including syntax errors, and recall common solutions.
• Use dynamic analysis tools, such as interactive debuggers and profilers.
• Simulate a program’s steps mentally or in writing to peform snapshot analysis and predict behavior.
• Run a program under a debugger to observe computations and isolate unexpected behavior.
• Add assertions and logging to a program to observe computations and isolate unexpected behavior.

Test a program.

• Interact with a program in order to confirm expected behaviors and attempt to trigger faults.
• Write an automated test to confirm an expected behavior or correct handling of exceptional conditions.
• Combine automated tests into a test suite.
• Perform unit testing by writing automated tests that isolate each program module.
• Perform test-driven development by writing tests for requirements before modifying a program to satisfy those requirements.

Write a program that handles errors during execution gracefully.

• Recognize common runtime errors.
• Distinguish logic errors, such as a programmer’s mistake, from exceptional conditions, such as a file not existing.
• Detect and handle exceptional conditions within a program by return type, exceptions, etc.

Maintain a program.

• Modify a program’s source to add or subtract features.
• Modify a program to work in another environment.