Reliable Programming

0.0(0)
studied byStudied by 0 people
learnLearn
examPractice Test
spaced repetitionSpaced Repetition
heart puzzleMatch
flashcardsFlashcards
Card Sorting

1/111

flashcard set

Earn XP

Description and Tags

Flashcards generated from lecture notes on Reliable Programming, focusing on vocabulary terms and definitions.

Study Analytics
Name
Mastery
Learn
Test
Matching
Spaced

No study sessions yet.

112 Terms

1
New cards

Software Quality

Creating a high-quality product with useful features that people want to use, is reliable, and user-friendly.

2
New cards

Reliability

A product quality attribute ensuring the software does not crash or lose information.

3
New cards

Security

A product quality attribute focused on protecting the software and data from unauthorized access and threats.

4
New cards

Usability

A product quality attribute ensuring users can learn to use the software quickly and without mistakes.

5
New cards

Maintainability

A product quality attribute related to the ease with which software can be modified, updated, or repaired.

6
New cards

Responsiveness

A product quality attribute measuring how quickly the software reacts to user input.

7
New cards

Availability

A product quality attribute indicating the degree to which software is accessible and operational when required.

8
New cards

Resilience

A product quality attribute that describes a system ability to recover quickly from difficulties.

9
New cards

Fault Avoidance

A technique for reliability improvement by programming in such a way to avoid introducing faults into the program.

10
New cards

Input Validation

A technique for reliability improvement by defining the expected format for user inputs and validating that all inputs conform to that format.

11
New cards

Failure Management

A technique for reliability improvement by implementing software so that program failures have minimal impact on product users.

12
New cards

Coupling

The number of relationships between entities in a program. Higher coupling indicates a more complex system.

13
New cards

Static Relationship

A relationship between program components that is stable and does not depend on program execution.

14
New cards

Dynamic Relationship

A relationship between program components that changes over time and is more complex than static relationships.

15
New cards

Reading Complexity

Reflects how hard it is to read and understand the program.

16
New cards

Structural Complexity

Reflects the number and types of relationships between the structures (classes, objects, methods or functions) in a program.

17
New cards

Data Complexity

Reflects the representations of data used and relationships between the data elements in a program.

18
New cards

Decision Complexity

Reflects the complexity of the decisions in a program.

19
New cards

Single Responsibility Principle

Each class should have only one reason to change.

20
New cards

Abstraction

A simplified representation of something more complex, hiding unnecessary details.

21
New cards

Deeply Nested Conditional Statements

Conditional (if) statements that are nested within each other, making code harder to read and understand.

22
New cards

Inheritance

A feature of object-oriented programming where a class inherits attributes and methods from a superclass.

23
New cards

Design Pattern

A general reusable solution to a commonly-occurring problem within a given context in software design.

24
New cards

Separation of Concerns

Each abstraction in a program (class, method, etc.) should address a separate concern, and all aspects of that concern should be covered there.

25
New cards

Creational Patterns

Design patterns concerned with class and object creation.

26
New cards

Structural Patterns

Design patterns concerned with class and object composition.

27
New cards

Behavioral Patterns

Design patterns concerned with class and object communication.

28
New cards

Adapter Pattern

A structural design pattern used to match semantically-compatible interfaces of different classes.

29
New cards

Factory Pattern

A creational design pattern used to create objects when slightly different variants of the object may be created.

30
New cards

Prototype Pattern

A creational design pattern used to create an object clone, i.e. a new object with exactly the same attribute values as the object being cloned.

31
New cards

Facade Pattern

A structural design pattern used to provide a single interface to a group of classes in which each class implements some functionality accessed through the interface.

32
New cards

Mediator Pattern

A behavioral design pattern used to reduce the number of direct interactions between objects; all object communications are handled through the mediator.

33
New cards

State Pattern

A behavioral design pattern used to implement a state machine where the behavior of an object changes when its internal state changes.

34
New cards

Observer Pattern

A design pattern that separates the display of an object from the object itself, allowing multiple displays associated with the object.

35
New cards

Refactoring

Changing a program to reduce its complexity without changing the external behavior of that program.

36
New cards

Code Smell

Indicators in the code that there might be a deeper problem.

37
New cards

Input Validation

Checking that a user’s input is in the correct format and that its value is within the range defined by input rules.

38
New cards

Type Coercion

Using functions such as int() in Python to convert the input string into the desired type.

39
New cards

Regular Expressions (REs)

A way of defining patterns for searching and validating text.

40
New cards

Exception Handling

A mechanism in programming languages to handle events that disrupt the normal flow of processing in a program.

41
New cards

Activity Logging

Keeping a log of what the user has done and providing a way to replay that against their data.

42
New cards

Auto-Save

Automatically saving the user’s data at set intervals to prevent data loss.

43
New cards

Data Failures

Situations where the outputs of a computation are incorrect.

44
New cards

Program Exceptions

Situations where the program enters a state where normal continuation is impossible.

45
New cards

Timing Failures

Situations where interacting components fail to respond on time or where the responses of concurrently-executing components are not properly synchronized.

46
New cards

Secure Failure

Ensuring that confidential data is not left in a state where an attacker can gain access to it during a failure.

47
New cards

External Service Failure

Failures that occur outside of the system.

48
New cards

Abstraction

A way to manage complexity by hiding unnecessary implementation details.

49
New cards

Cohesion

The degree to which the elements inside a module belong together.

50
New cards

Module

A self-contained component of a larger system.

51
New cards

Interface

A shared boundary across which two or more separate components exchange information.

52
New cards

Data Alias

Two or more variables that refer to the same memory location.

53
New cards

Data Type

A classification identifying one of various types of data, such as integer, floating-point, character, etc.

54
New cards

Assertion

A statement in the code that expresses a belief about the program's state.

55
New cards

Anomalies

Unexpected or unusual occurrences.

56
New cards

Buffer overflow

An anomaly where a program writes data beyond the boundaries of an allocated buffer.

57
New cards

SQL injection

A code injection technique used to attack data-driven applications.

58
New cards

Code Injection

The exploitation of a computer bug that is caused by processing invalid data.

59
New cards

Pollute Database

Corrupt the integrity of the data.

60
New cards

Linting

The automated checking of the source code.

61
New cards

Code Review

A systematic examination (often peer review) of computer source code.

62
New cards

Unit Testing

A software testing method by which individual units of source code.

63
New cards

Integration Testing

The phase in software testing in which individual software modules are combined and tested as a group.

64
New cards

Concurrency

The ability of a program to execute multiple tasks seemingly at the same time.

65
New cards

Parallelism

The actual simultaneous execution of multiple tasks.

66
New cards

Object-Oriented Programming

A programming paradigm based on 'objects', which contain data, in the form of fields.

67
New cards

Abstraction

Representing essential features without including background details or explanations.

68
New cards

Data Structure

A particular way of organizing data in a computer so that it can be used efficiently.

69
New cards

Algorithm

A process or set of rules to be followed in calculations or other problem-solving operations, especially by a computer.

70
New cards

Database Schema

The structure of a database. It defines how the data is organized within a database.

71
New cards

Code Management System

A system to manage changes to computer programs, documents, large web sites, or other collections of information.

72
New cards

Functional Programming

A programming paradigm where programs are constructed by applying and composing functions.

73
New cards

Imperative Programming

A programming paradigm that uses statements that change a program's state.

74
New cards

Declarative Programming

A programming paradigm that expresses the logic of a computation without describing its control flow.

75
New cards

Side-effect

A function or expression is said to have a side effect if it modifies some state outside its scope or has an observable interaction

76
New cards

Code Coverage

A measurement used to describe the degree to which the source code of a program is tested.

77
New cards

API(Application Programming Interface)

A way for two or more computer programs to communicate with each other.

78
New cards

Data Invariants

Conditions that are always true at a particular point in a program.

79
New cards

Deadlock

A situation in which two or more computing tasks are each waiting for the other to finish.

80
New cards

Race condition

Occurs when two or more threads can access shared data and they try to change it at the same time.

81
New cards

Fuzzing

An automated software testing technique that involves providing invalid, unexpected, or random data as inputs to a program.

82
New cards

Regression Testing

Reteesting software after modifications, to ensure that any defects introduced during development or testing have been fixed and that no other previously working functions have failed as a result of the alterations.

83
New cards

Fail Secure

Design principle that dictates that if a system fails, it should fail in a way that prevents sensitive information from being exposed.

84
New cards

Cross-site scripting (XSS)

A type of computer security vulnerability typically found in web applications.

85
New cards

Directory traversal

An HTTP attack that enables attackers to access restricted directories and execute commands outside of the web server's root directory.

86
New cards

Remote code execution

The capability to execute arbitrary commands or code on a remote device or server.

87
New cards

Denial-of-service attack.

An attack meant to shut down a machine or network, making it inaccessible to its intended users.

88
New cards

Backdoor

A means of bypassing normal authentication, used for securing remote access to a computer system.

89
New cards

Compiled language

A programming language whose implementations are typically compilers.

90
New cards

Interpreted language

A type of programming language for which most of its implementations execute instructions directly, without previously compiling a program into machine-language instructions.

91
New cards

Syntax

The set of rules that define the combinations of symbols that are considered to be correctly structured programs in that language.

92
New cards

Semantics

The field concerned with the rigorous mathematical study of the meaning of programming languages.

93
New cards

Robustness

The ability of a computer system to cope with errors during execution and cope with erroneous input.

94
New cards

Error Handling

The process of responding to and recovering from error conditions in a software application.

95
New cards

Code Debt

The implied cost of rework caused by choosing an easy solution now instead of using a better approach that would take longer.

96
New cards

Technical Debt

The implied cost of rework caused by choosing an easy solution instead of taking a better approach which would take longer.

97
New cards

Idempotent

An operation that can be applied multiple times without changing the result beyond the initial application.

98
New cards

Threadsafe

Computer code that can be safely executed by multiple concurrent threads without causing unintended data corruption or other race conditions.

99
New cards

Data race

Occurs when multiple threads access the same memory location concurrently, and at least one of the threads is writing to the memory location, and the threads are not using any synchronization mechanisms.

100
New cards

API versioning

The process of managing changes to an application programming interface while ensuring that it remains compatible with existing clients.