Week 2 ONLY

Question 1

Generalisation

Answer 1

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

Question 2

Mistakes vs Defects/Faults vs Failures vs Errors in Engineering

Answer 2

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.

Question 3

Some properties of defects:

Answer 3

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

Question 4

Some engineering mistakes:

Answer 4

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

Question 5

How to deal with mistakes:

Answer 5

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

Question 6

Fault tolerance

Answer 6

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

Question 7

Reviewing vs testing

Answer 7

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

Question 8

Limitations of testing:

Answer 8

does not create quality, only measures it
can show the presence of bugs, but unlikely their abscence

Question 9

Debugging

Answer 9

process of localising, diagnosing and correct detected defects

Question 10

Techniques for constructing test cases

Answer 10

Boundary analysis
Equivalence classes
Statement, branch and path coverage
Random input
Objects not listed in @modifies not modified
Testing for precondition violations

Question 11

Boundary analysis

Answer 11

picking values near and on the boundaries

Question 12

Equivalence classes

Answer 12

picking elements from every equivalence class

Question 13

Statement, branch and path coverage

Answer 13

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

Question 14

Methods of deciding on pass vs fail:

Answer 14

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

Question 15

Dealing with violated preconditions

Answer 15

Do nothing, leave it up to the caller
Return special result that conveys wrong input
Use exceptions (recommended)

Question 16

Robustness

Answer 16

A method is called robust when its behaviour under a violated precondition is well-specified

Question 17

Advantages and disadvantages of robustness

Answer 17

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

Question 18

Approaches for selecting input for test cases:

Answer 18

1. 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
2. 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

Question 19

Rules for Java Exceptions

Answer 19

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

Question 20

Errors vs Exceptions in Java

Answer 20

exceptions can be caught whilst errors stop the program altogether

Question 21

When to throw exceptions?

Answer 21

to make methods robust to signal special, usually erroneous, situations to guarantee that detected failures cannot be ignored

Question 22

When not to throw exceptions

Answer 22

when context of use is local when precondition is too expensive or impossible to check

Question 23

Exception type hierarchy

Answer 23

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

Question 24

RuntimeExceptions/Unchecked Exceptions

Answer 24

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

Question 25

Checked Exceptions

Answer 25

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

Question 26

How to handle thrown exceptions?

Answer 26

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

Question 27

Defensive programming

Answer 27

the attitude to include run-time checks for bad situations that should never occur but could still occur due to unforeseen circumstances

Question 28

Assert statements

Answer 28

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

Question 29

What is a design pattern

Answer 29

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

Question 30

Three development stages of software? Software patterns classified according to development stages:

Answer 30

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

Question 31

Analysis patterns:

Answer 31

patterns that help developers understand the problem domain

Question 32

Architectural patterns

Answer 32

High-level plan for organising the top-level components of a program or software system

Question 33

Design patterns

Answer 33

Address mid-level design problems whose solutions are defined by a small number of classes and/or objects

Question 34

Programming idioms

Answer 34

Low-level, language-specific pattern that explains how to accomplish a simple task using a specific programming language or technology

Question 35

Are algorithms patterns?

Answer 35

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.

Question 36

Are one-off designs patterns?

Answer 36

No since patterns must be reusable and well-proven, which you can’t know for sure a one-off design will be.

Question 37

Relevant components when defining design patterns:

Answer 37

Pattern NameIntroduction (context for problem)Intent (design problem)SolutionSample Code (example)Discussion (info)Related Patterns