1/31
32 vocabulary flashcards covering fundamental terms and concepts from the lecture on software architecture, its decisions, decomposition, views, and well-known architecture styles.
Name | Mastery | Learn | Test | Matching | Spaced |
---|
No study sessions yet.
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.