Week 2 ONLY Flashcards

1
Q

Generalisation

A

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

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
2
Q

Mistakes vs Defects/Faults vs Failures vs Errors in Engineering

A

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.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
3
Q

Some properties of defects:

A

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

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
4
Q

Some engineering mistakes:

A

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 well did you know this?
1
Not at all
2
3
4
5
Perfectly
5
Q

How to deal with mistakes:

A

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

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
6
Q

Fault tolerance

A

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

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
7
Q

Reviewing vs testing

A

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

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
8
Q

Limitations of testing:

A

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

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
9
Q

Debugging

A

process of localising, diagnosing and correct detected defects

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
10
Q

Techniques for constructing test cases

A

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

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
11
Q

Boundary analysis

A

picking values near and on the boundaries

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
12
Q

Equivalence classes

A

picking elements from every equivalence class

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
13
Q

Statement, branch and path coverage

A

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

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
14
Q

Methods of deciding on pass vs fail:

A

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

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
15
Q

Dealing with violated preconditions

A

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

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
16
Q

Robustness

A

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

17
Q

Advantages and disadvantages of robustness

A

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

18
Q

Approaches for selecting input for test cases:

A
  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
19
Q

Rules for Java Exceptions

A

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

20
Q

Errors vs Exceptions in Java

A

exceptions can be caught whilst errors stop the program altogether

21
Q

When to throw exceptions?

A

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

22
Q

When not to throw exceptions

A

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

23
Q

Exception type hierarchy

A

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

24
Q

RuntimeExceptions/Unchecked Exceptions

A

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

25
Q

Checked Exceptions

A

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

26
Q

How to handle thrown exceptions?

A

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

27
Q

Defensive programming

A

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

28
Q

Assert statements

A

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

29
Q

What is a design pattern

A

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

30
Q

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

A

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

31
Q

Analysis patterns:

A

patterns that help developers understand the problem domain

32
Q

Architectural patterns

A

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

33
Q

Design patterns

A

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

34
Q

Programming idioms

A

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

35
Q

Are algorithms patterns?

A

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.

36
Q

Are one-off designs patterns?

A

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

37
Q

Relevant components when defining design patterns:

A

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