Software Architecture – Core Vocabulary

32 vocabulary flashcards covering fundamental terms and concepts from the lecture on software architecture, its decisions, decomposition, views, and well-known architecture styles.

Software Architecture

A set of high-level decisions that determine a system’s parts and their relationships, made early and hard to change later.

Architectural Decision

A principal choice affecting large portions of a system, taken within the current scope and aligned with business strategy.

Scope (in architecture)

The system level considered when making a decision; a decision is architectural only if it cannot be made from a narrower, local perspective.

Divide-and-Conquer

The practice of breaking a complex system into smaller parts to manage complexity and enable reuse.

Separation of Concerns

Decoupling unrelated parts so each can evolve independently, improving flexibility and maintainability.

Subsystem (Module)

A cohesive unit of functionality within a larger system, identified during system decomposition.

Component

A processing element that performs work and exposes provided/required interfaces.

Connector

A communication mechanism that enables interaction among components (e.g., pipes, procedure calls, HTTP).

Interface

A defined point on a component or connector where data can enter or exit; specifies provided or required services.

Configuration

A specific arrangement of components and connectors forming an architecture.

Cross-Cutting Concern

A broad-scoped system property (e.g., security, performance) that impacts multiple parts of the architecture.

Conceptual Integrity

The consistency and coherence of architectural decisions across the whole system.

Architecture Style

A reusable pattern that defines a family of architectures with common structure and rules.

Pipe-and-Filter Style

An architecture style where filters transform data and pipes stream data between filters (e.g., Unix shell).

Layered (Tiered) Style

A hierarchical organization where each layer offers services to the layer above and uses services of the layer below.

Client/Server Style

A model with triggering clients that send requests and reactive servers that process them and return responses.

REST (Representational State Transfer)

A Web architecture style using stateless client-server interactions, standard methods (GET, POST, etc.) and hypermedia links.

HATEOAS

Hypermedia As The Engine Of Application State; REST concept where clients navigate application state via hyperlinks provided in responses.

Microservices

An architectural approach that structures an application as a suite of independently deployable, small services.

Repository Style

An architecture where subsystems share data through a central database or data store.

Shared Database Connector

A connector that allows multiple components to access a common data repository via a unified data model.

Module Decomposition View

A structural view showing top-down refinement of modules or subsystems.

Dependency View

A view that documents how parts of the system depend on one another.

Layered View

A specialized dependency view illustrating layers and allowed directions of use.

Process (Concurrency) View

A representation of the system as a set of communicating, possibly concurrent, processes.

Component & Connector View

A view focusing on runtime components and the connectors that link them.

Call-and-Return Architecture

A control-flow structure organized as nested subroutine calls forming a tree of modules.

Model-View-Controller (MVC)

An architecture style separating application state (Model), presentation (View), and user interaction logic (Controller).

Session State (REST)

State held on the client side; servers remain stateless and rely on each request to contain all necessary information.

HTTP CRUD Methods

Standard REST verbs: POST (create), GET (read), PUT (update), DELETE (remove) resources.

Problem Structure vs. Solution Structure

The distinction between how requirements identify problem-domain elements and how architecture organizes solution components.

Reuse

Leveraging existing components or subsystems to avoid reinventing functionality and accelerate development.