IT-312: Systems Integration and Architecture Midterm Review

Comprehensive vocabulary flashcards covering architectural patterns, system modeling types, integration strategies, and API and middleware concepts for the IT-312 midterm examination.

Service-Oriented Architecture (SOA)

An architectural pattern that organizes functionality as services with defined interfaces, with an emphasis on reusability, allowing services to be accessed by other parts of a system when needed.

Layered Architecture

An architectural pattern in which a system is organized into hierarchical layers, each with a defined responsibility to make the structure easier to understand and maintain.

Repository Architecture

An architectural pattern where components access a shared, central repository for data, supporting data sharing while potentially making components dependent on the central store.

Client–Server Architecture

An architecture where clients request data or services while servers process requests and provide responses, giving the two sides distinct responsibilities within the system.

Pipe-and-Filter Architecture

An architecture where data passes through a sequence of independent filters connected by pipes, with each filter executing a processing step before passing its output onward.

Event-Driven Architecture

An architecture where components produce and respond to events to trigger actions or communicate occurrences, reducing the need for components to directly call one another for every interaction.

Microservices Architecture

An approach in which an application is divided into relatively independent services that can be developed, deployed, and scaled separately, improving flexibility while introducing communication and maintenance considerations.

Model–View–Controller (MVC)

An architectural pattern that separates responsibilities among the Model, View, and Controller to keep application data, presentation, and input-handling logic organized.

Architectural Patterns

Reusable guidance for recurring system-design problems, selected based on system requirements and associated trade-offs.

Context Model

A system model that gives an overview of the system boundary and the external people, organizations, or systems that interact with it, clarifying what belongs inside and outside the system.

Data Flow Model

A system model that represents how information moves through processes, data stores, and external entities, useful for analyzing inputs, transformations, storage, and outputs.

Class Model

A system model representing the static structure of object-oriented software through classes, attributes, methods, and relationships.

Activity Model

A system model that represents actions and the flow of work within a process, helping explain workflow steps and possible paths.

Sequence Model

A system model showing messages exchanged between objects or components in time order, emphasizing the order of interactions rather than an object's changing states.

State Machine Model

A system model representing the states an object can occupy and the events triggering transitions between them when behavior depends on conditions or events.

Deployment Model

A system model showing where software artifacts are placed on hardware nodes or runtime environments, focusing on physical or execution arrangement.

Component Model

A system model describing software components, their organization, and their interactions through interfaces, representing the system's software building blocks.

Entity-Relationship (ER) Model

A system model that represents data entities, their attributes, and relationships between them, commonly used to plan or communicate data structure.

Top-Down Integration

An integration approach starting with high-level architecture before addressing subsystems and details, supporting overall design alignment but requiring time-consuming upfront planning that may be rigid against changes.

Bottom-Up Integration

An integration approach that starts with individual components or subsystems, tests them, and combines them gradually to reveal component-level issues early while requiring coordination to maintain architectural alignment.

Middleware-Based Integration

An integration strategy where middleware acts as an intermediary to help systems communicate and potentially transform data formats or protocols, providing centralized communication management at the cost of added complexity.

API-Based Integration

An integration strategy where systems communicate through defined API endpoints and service interfaces, enabling standardized access while requiring consideration of endpoint compatibility, security, and maintenance.

Application Programming Interface (API)

A definition of how one software component can request data or functionality from another, enabling systems to communicate through agreed interfaces.

REST

An approach used to design web APIs around resources and standardized web interactions, commonly utilized for web or mobile access to services.

API Gateway

A centralized entry point for requests to APIs that can route requests and apply shared policies, though it does not automatically eliminate security risks.

OAuth

An authorization framework used to grant limited access to resources while still requiring proper security configuration and access controls.

API Security

The application of suitable authentication and authorization controls to protect services and data exposed through API endpoints.

Middleware

Software that helps separate applications or systems communicate by managing messages, coordinating interactions, or transforming data depending on its type.

Message Broker

A component that receives and routes messages between applications or services, assisting in decoupling senders from receivers.

Message-Oriented Middleware (MOM)

Middleware supporting message-based communication, including asynchronous messaging where the sender and receiver do not need to process messages at the same time.