Software Architecture Overview

A general framework or approach used to build a software product, similar to a design pattern.

Smaller, reusable units of code that perform specific tasks, often within a larger component.

Larger, more complex units of code that combine multiple modules to provide a more comprehensive functionality.

A common architectural pattern that separates functionality into two distinct components, a centralized server and multiple clients.

Code that runs on the user's device, interacting directly with the user interface.

A software architecture where all code is bundled into a single application and deployed as one unit.

Code that runs on a remote server, handling tasks and processing data, then sending results back to the client.

A software architecture that breaks down an application into smaller, independent services that communicate over a network.

A popular architectural pattern that separates a software application into three distinct layers: Presentation, Business Logic, and Data.

Testing that verifies the interaction between different units of a system, such as modules or components.

A layered architecture that focuses on the user interface (View), data manipulation (Model), and user interactions (Controller).

A strategy of integration testing where all components are combined at once without a specific order.

A strategy of integration testing that starts with the top-level modules (e.g., UI) and gradually integrates lower-level components.

Testing that focuses on individual units of code, such as functions or classes.

Testing that verifies the functionality of the complete system, typically performed after integration testing.

The interaction between the user interface (UI) and the underlying logic of the application.

Mockito annotation to create mock objects as instance variables.

A function in Mockito for creating mock objects on the fly.

Mockito function for defining return values for mock object functions. Specifies the expected output for a given mock object function call.

Mockito function for verifying if a function was called.

Mockito function for verifying if a function wasn't called.

Mockito's lenient approach to handling unused when-then calls, useful for maps and sets with conditional execution.

Data stored and available between different program executions.

A standard format for representing structured data as key-value pairs. Used frequently in data exchange and storage.

A JSONArray is a structured collection of data where each element is a valid JSON type. Think of it as a list of items that can be numbers, strings, booleans, other JSONArrays, or JSONObjects.

JSON numbers can represent both integers and floating-point values. They are used to represent numerical data in a JSON document.

JSON strings are used to represent textual data. They are enclosed in double quotes and can include various characters, including letters, numbers, and special characters.

JSON booleans are used to represent truth values, either true or false. They are used to indicate logical conditions in a JSON document.

JSON objects can be built using Java by using the JSONObject class and its put method. When you put a list into a JSONObject, it is automatically converted to a JSONArray behind the scenes.

A testing approach where you start with low-level modules (e.g., database interactions) and gradually integrate them with higher-level modules, testing as you go.

A testing approach where you start with a middle layer, integrate modules above it using Bottom-Up, and integrate modules below it using Top-Down.

Modules that simulate the behavior of missing or incomplete modules during integration testing. They provide fake outputs without replicating internal states.

Modules that simulate parts of a higher-level module to enable testing of lower-level modules during integration testing.

A benefit of Bottom-Up integration testing is that it simplifies identifying the source of errors. If a test fails, you know the fault lies in the recently integrated module.

A drawback of Bottom-Up Integration testing is that it goes against the usual design pattern of starting with abstractions (interfaces) and then implementing them.

A benefit of Sandwich Integration testing is that it combines the advantages of both Bottom-Up and Top-Down approaches. It's flexible and well-suited for complex systems.

A drawback of Sandwich Integration testing is that choosing the 'middle' layer can be tricky, and implementing it requires a variety of skills.