Week 2 ONLY Flashcards
Generalisation
solving a more general problem than initially required to improve reusability and insightcan be carried out via parameters as they hide the identity of the data operated on
Mistakes vs Defects/Faults vs Failures vs Errors in Engineering
Humans can make a mistake in engineering, which then causes a defect/fault in their creation.
This defect/fault is an anomaly in the system that causes a system failure.
The failure occurs when the product deviates from its requirements in operation, leading to an error.
Error is the difference between actual and expected result.
Some properties of defects:
the longer a defect is undiscovered, the higher its cost
defects decrease the predictability of a project
defects create risks
defects are increasingly likely for increasingly large systems
Some engineering mistakes:
mistunderstanding the customer
misinterpreting a written requirement
overlooking a case in analysing the requirements
adopting an incorrect algorithm
making an unwanted assumption when implementing a method
making a typing error when entering code
How to deal with mistakes:
admit that people make mistakes and inject defects (awareness)
prevent them as much as possible
minimise consequences (defensive programming, fault tolerance)
detect presence of defects as early as possible
localise defects
repair defects
trace defects
learn from defects
Fault tolerance
the system’s ability to continue functioning properly and reliably in the presence of errors or failures, often achieved through techniques like error detection, recovery mechanisms, and redundancy
Reviewing vs testing
Reviewing: examining an artefact with the intent of finding defects- often localises the defects as well- can be done early in the development process
Testing: using a product systematically with the intent of finding defects- does not localise underlying defects- requires a working product
Limitations of testing:
does not create quality, only measures it
can show the presence of bugs, but unlikely their abscence
Debugging
process of localising, diagnosing and correct detected defects
Techniques for constructing test cases
Boundary analysis
Equivalence classes
Statement, branch and path coverage
Random input
Objects not listed in @modifies not modified
Testing for precondition violations
Boundary analysis
picking values near and on the boundaries
Equivalence classes
picking elements from every equivalence class
Statement, branch and path coverage
Statement coverage: measures the percentage of executable code statements that have been executed during a particular test; focuses on ensuring that each line of code has been executed at least once during testing
Branch coverage: evaluates the execution of different branches (decision points) in the code; aims to test both the true and false outcomes of decision points (if statements, loops, etc.).
Path coverage: measures the percentage of unique paths through the code that have been executed; goes beyond statement and branch coverage by considering the specific combinations of branches and decision points taken during execution
Methods of deciding on pass vs fail:
Selecting trivial or highly structured input with known output
Manually determining expected output
Checking correctness of output via inverse method
Using alternate implementation to compute expected output
Dealing with violated preconditions
Do nothing, leave it up to the caller
Return special result that conveys wrong input
Use exceptions (recommended)
Robustness
A method is called robust when its behaviour under a violated precondition is well-specified
Advantages and disadvantages of robustness
Advantages of robustness:
Conveys where to put the blame
Without an explicit signal that a precondition was violated, it may appear that the problem is located inside the method With an explicit signal, it is clear that the problem is located outside the method
Disadvantages of robustness:
Overhead in writing the precondition checks and in testing them
More code to read and understand during maintenance/evolution
Runtime overhead in checking the precondition, even if satisfied
Runtime overhead in throwing, propagating, catching exceptions
Approaches for selecting input for test cases:
- Black-box, or test-to-specifications, or functional:concerned only with external behavior of software, no knowledge of internal implementation detailstest cases designed based on software’s specifications, requirements, and functionality without considering internal code structuresoftware tested from user’s perspecctive
- Glass-box, or test-to-code, or structural:tester has knowledge of internal code structure, logic, and implementation details of the softwareTest cases designed with an understanding of the internal code paths, branches, and logical conditions to ensure thorough coverage of the codeaims to verify the correctness of the internal logic, error handling, and code structure
Rules for Java Exceptions
if a method throws an error that it does not catch and deal with, method header should include throws clause and @throws tag should be included in javadoc
exceptions can be created in java by creating your own classes that extend the Exception class
when throwing an error, always include a message that conveys what went wrong and wheremultiple catch blocks can be used for the same try to catch different exceptions nested try statements are possible
catch blocks can list supertypes of an exception so that it catches multiple exceptions that are subclasses
Errors vs Exceptions in Java
exceptions can be caught whilst errors stop the program altogether
When to throw exceptions?
to make methods robust to signal special, usually erroneous, situations to guarantee that detected failures cannot be ignored
When not to throw exceptions
when context of use is local when precondition is too expensive or impossible to check
Exception type hierarchy
Throwables are a type of object.
Errors and Exceptions are types of Throwables.
Checked Exceptions and RuntimeExceptions are types of exceptions.
Unchecked exceptions are a type of RuntimeExceptions
RuntimeExceptions/Unchecked Exceptions
unexpected errors thrown during the execution of a program that are not checked at compile time (developer not required to consider them)
e.g., NullPointerExceptions, ArrayIndexOutOfBoundsException, ArithmeticException, IllegalArgumentException
Checked Exceptions
category of exceptions in programming that are checked by the compiler, requiring explicit handling through try-catch blocks or declaration in the method signature, ensuring that potential issues are addressed at compile time
How to handle thrown exceptions?
Handle specifically - create a separate catch block for each exception
Handle generically - care a catch for each supertype exception
Reflect the exception - exception is passed onto calling method
Mask the exception - exception is caught but nothing is done about it
Defensive programming
the attitude to include run-time checks for bad situations that should never occur but could still occur due to unforeseen circumstances
Assert statements
used to test assumptions about the program’s state by checking specified conditions, and if the condition is false, an AssertionError is thrown, helping identify and debug logical errors during development
What is a design pattern
a reusable and general solution to a recurring problem or challenge encountered in software design, providing a template or guideline for structuring code to achieve best practices in a particular context
Three development stages of software? Software patterns classified according to development stages:
Analysis, design, and implementation
Analysis patterns linked to analysis stage
Design patterns and Architectural patterns linked to design stage
Programming idioms linked to implementation stage
Analysis patterns:
patterns that help developers understand the problem domain
Architectural patterns
High-level plan for organising the top-level components of a program or software system
Design patterns
Address mid-level design problems whose solutions are defined by a small number of classes and/or objects
Programming idioms
Low-level, language-specific pattern that explains how to accomplish a simple task using a specific programming language or technology
Are algorithms patterns?
No since they are created with the purpose of solving a specific problem in a computationally efficient way in terms of time and space complexity.In contrast, the purpose of a design pattern is to organise code in a developmentally efficient way.
Are one-off designs patterns?
No since patterns must be reusable and well-proven, which you can’t know for sure a one-off design will be.
Relevant components when defining design patterns:
Pattern NameIntroduction (context for problem)Intent (design problem)SolutionSample Code (example)Discussion (info)Related Patterns
