Week 1 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 costdefects decrease the predictability of a projectdefects create risksdefects are increasingly likely for increasingly large systems
Some engineering mistakes:
mistunderstanding the customermisinterpreting a written requirementoverlooking a case in analysing the requirementsadopting an incorrect algorithmmaking an unwanted assumption when implementing a methodmaking 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 possibleminimise consequences (defensive programming, fault tolerance)detect presence of defects as early as psosiblelocalise defectsrepair defectstrace defectslearn 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 processTesting: 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 itcan show the presence of bugs, but unlikely their abscence
Debugging
process of localising, diagnosing and correct detected defects
Techniques for constructing test cases
Boundary analysisEquivalence classesStatement, branch and path coverageRandom inputObjects not listed in @modifies not modifiedTesting 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 testingBranch 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 outputManually determining expected outputChecking correctness of output via inverse methodUsing alternate implementation to compute expected output
Dealing with violated preconditions
Do nothing, leave it up to the callerReturn special result that conveys wrong inputUse 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 blameWithout 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 methodDisadvantages of robustness:Overhead in writing the precondition checks and in testing themMore code to read and understand during maintenance/evolutionRuntime overhead in checking the precondition, even if satisfiedRuntime 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 perspecctive2. 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 javadocexceptions can be created in java by creating your own classes that extend the Exception classwhen 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 exceptionsnested try statements are possiblecatch 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 robustto signal special, usually erroneous, situationsto 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 exceptionHandle generically - care a catch for each supertype exceptionReflect 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 implementationAnalysis patterns linked to analysis stageDesign patterns and Architectural patterns linked to design stageProgramming 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
