Software eng midterm 2

0.0(0)
Studied by 0 people
call kaiCall Kai
learnLearn
examPractice Test
spaced repetitionSpaced Repetition
heart puzzleMatch
flashcardsFlashcards
GameKnowt Play
Card Sorting

1/70

encourage image

There's no tags or description

Looks like no tags are added yet.

71 Terms

1
New cards

The high-level structure of the software, concerned with the overall organization of the software and how the components interact

Software Architecture

2
New cards

 The low-level structure of the software, concerned with the implementation of the individual components and how they interact.

Software Design

3
New cards

 The principle of dividing the issues involved in the program into different modules or classes, each of which is responsible for a specific aspect of the program.

Separation of Concerns 

4
New cards

    The principle that a module or class should have only one reason to change, or only one responsibility

Single Responsibility Principle 

5
New cards

     The idea that a module or class should conceal its internal state and behavior, exposing only the interfaces that are necessary for other modules or classes to interact with it

Information hiding 

6
New cards

The idea that a program should be divided into separate modules or classes, each of which is responsible for a specific aspect of the program

Modularity  

7
New cards

The idea that modules should interact with each other as little as possible, to make the program more maintainable and flexible

Loose Coupling    

8
New cards

    The idea that a module is focused on a single aspect of the program, making the program more maintainable and understandable.

High Cohesion 

9
New cards

  A standardized visual language for describing the structure and behavior of software systems through diagrams.

Unified Modeling Language (UML)   

10
New cards

  A UML diagram that describes a system from the outside, showing the actors that use it and the use cases (things they can do with it)

Use Case Diagram

11
New cards

  A UML diagram that describes the static structure of a system, showing its classes, their attributes and methods, and the relationships between them

Class Diagram   

12
New cards

 Common solutions to common problems in software design, such as the Singleton pattern, the Observer pattern, and the Strategy pattern.

Design Patterns  

13
New cards

A design pattern that ensures that only one instance of a class is created, and provides a way to access that instance.

Singleton Pattern 

14
New cards

A design pattern that allows multiple objects to listen for events and respond to them in a flexible way

Observer Pattern  

15
New cards

A design pattern that allows a class to change its behavior at runtime, by using different strategies.

Strategy Pattern  

16
New cards

   A design strategy that allows you to inject dependencies into a class, rather than creating them inside the class.

Dependency Injection 

17
New cards

The actual instructions that the computer executes to perform the desired functions

Code  

18
New cards

  The information that the software processes and manipulates

Data

19
New cards

The information that helps users understand and use the software.

Documentation     

20
New cards

The programs that install the software on a computer, mobile device, or server

Installers  

21
New cards

 How far removed a programming language is from the machine code that the computer executes

Level of abstraction   

22
New cards

  The style of programming that a programming language encourages

Paradigm  

23
New cards

How a programming language classifies values and expressions

Type system 

24
New cards

  A type system in which the types of values and expressions are known at compile time

Static typing   

25
New cards

 A type system in which the types of values and expressions are known at runtime

Dynamic Typing   

26
New cards

A type system in which the types of values and expressions are enforced by the language

Strong Typing     

27
New cards

A type system in which the types of values and expressions are not enforced by the language.

Weak Typing 

28
New cards

 Code that is easy to read, understand, and maintain

Clean Code 

29
New cards

 Code that is easy to modify, extend, and debug

Maintainable Code

30
New cards

 A set of rules that developers follow to ensure that code is written in a consistent style

Coding standards 

31
New cards

Software tools that help developers manage changes to source code over time

Version Control Systems 

32
New cards

  A collection of files and directories that make up a project.

Repository

33
New cards

 A snapshot of the code at a particular point in time

Commit     

34
New cards

A unique identifier for a commit

Commit Hash 

35
New cards

The sequence of changes that have been made to the code over time

Commit History    

36
New cards

   The main repository for a project.

Upstream Repository  

37
New cards

 Create a local copy of the code by copying the upstream repository.

Clone

38
New cards

 Share changes with other developers by sending them to the upstream repository

Push 

39
New cards

Update the local repository with changes from the upstream repository

Pull  

40
New cards

   A conflict that occurs when two or more developers make changes to the same code in an interleaved manner

Merge Conflict 

41
New cards

  A separate line of development that diverges from the main line of development

Branch    

42
New cards

a markup language for encoding documents in a format that is both human-readable and machine-readable

eXtensible Markup Language (XML)

43
New cards

 JavaScript Object Notation, a lightweight data-interchange format that is easy for humans to read and write and easy for machines to parse and generate

JSON 

44
New cards

a human-readable data serialization format that is commonly used for configuration files and data exchange

YAML Ain't Markup Language (YAML)

45
New cards

The process of making a software system available for use

Deployment  

46
New cards

 The context in which something exists or operates

Environment

47
New cards

 The context in which a system is deployed

Production Environment 

48
New cards

 The context in which a system is developed.

Development Environment

49
New cards

    A copy of the production environment that is used for testing before deploying to production.

Staging Environment 

50
New cards

  The way that a system's components are distributed across physical and virtual machines

Physical Architecture 

51
New cards

The way that a system's components are organized and interact with each other

Logical Architecture   

52
New cards

 The process of transforming source code into an executable program

Build

53
New cards

A package that includes the runnable application, as well as an installer program that guides the user through the installation process.

Installer   

54
New cards

A lightweight, standalone, executable package that includes everything needed to run a piece of software.

Container   

55
New cards

The methods, protocols, and data formats that components use to communicate with each other

Application Programming Interface (API)

56
New cards

 A computer or other device connected to a network allowing access to files, programs, or other resources

Host 

57
New cards

  Hosting that serves only static files (HTML, CSS, JavaScript)

Static Hosting  

58
New cards

  A virtual server that is hosted on a physical server, and that can be used to host web applications

Virtual Private Server (VPS)

59
New cards

  A cloud computing service that provides a platform for developing, running, and managing applications without the complexity of building and maintaining the infrastructure

Platform as a Service (PaaS)

60
New cards

The process of automating the deployment, scaling, and management of containerized applications.

Container Orchestration 

61
New cards

 The process of writing scripts (small programs) that perform the necessary tasks for deployment

Scripting  

62
New cards

   The process of defining the desired state of the production environment in code, and then automatically configuring the environment to match that state

Configuration Management   

63
New cards

The practice of automatically building and testing code whenever changes are made to the code repository

Continuous Integration (CI)  

64
New cards

   The process of managing the software artifacts that are produced during the build process

Artifact Management  

65
New cards

 A repository that stores software artifacts in a secure and reliable way

Artifact Repository    

66
New cards

A type of testing in which individual units or components of a software product are tested in isolation from the rest of the product

Unit Testing      

67
New cards

 A set of unit tests that cover all the important cases for a unit of the software

Test Suite 

68
New cards

A software development process that emphasizes writing tests before writing code

Test-Driven Development (TDD) 

69
New cards

   A software tool that helps developers write and run tests

Test Framework 

70
New cards

 A type of testing in which individual units or components of a software product are combined and tested as a group

Integration Testing    

71
New cards

 A software development practice in which developers integrate code into a shared repository frequently, often multiple times a day

Continuous Integration (CI)