CEN 4065 - Lecture 6: Integrability, Modifiability, Performance

Flashcards covering key vocabulary from lectures on Integrability, Modifiability, and Performance in Software Architecture and Design.

Integrability

Software architects' concern with the costs and technical risks of integration tasks for separately developed components.

Integration Difficulty

A function of the size (number of potential dependencies) and distance (difficulty of resolving differences at dependencies) between component interfaces and the system.

Online Order

A digital record of a permanent transaction, often involving upfront or guaranteed payment.

Restaurant Kitchen Order

A temporary request to the kitchen that creates food and drink, not a permanent record of payment.

Payment (Restaurant)

The permanent transaction that typically occurs at the end of a meal.

Purchase Order

A buyer's request to a seller, initiating a transaction.

Invoice

A seller's bill to the buyer for goods or services already provided, requesting payment.

Receipt

Proof of payment for an invoice, confirming payment was received.

Goal of Integrability Tactics

To reduce the costs and risks of adding new components, reintegrating changed components, and integrating sets of components to fulfill evolutionary requirements.

Encapsulate (Integrability Tactic)

Introduces an explicit interface to an element, ensuring all dependencies flow through it, eliminating reliance on element internals.

Use an Intermediary (Integrability Tactic)

Used for breaking dependencies between a set of components or between components and the system.

Restrict Communication Paths (Integrability Tactic)

Limits the set of elements that a given element can communicate with.

Adhere to Standards (Integrability Tactic)

Standardization in system implementations that enables integrability and interoperability across platforms and vendors.

Abstract Common Services (Integrability Tactic)

Hides similar services behind a common abstraction, such as a common interface implemented by both.

Discover (Integrability Tactic)

A discovery service is the mechanism by which applications and services locate each other.

Tailor Interface (Integrability Tactic)

Adding or hiding capabilities in an existing interface without changing the API or implementation.

Configure Behavior (Integrability Tactic)

Modifying a component's behavior during build, system initialization, or runtime (e.g., recompiling, reading configuration files, specifying protocol versions).

Orchestrate (Integrability Tactic)

Uses a control mechanism to coordinate and manage service invocations, allowing services to remain unaware of each other.

Manage Resources (Integrability Tactic)

A resource manager, a form of intermediary, governs access to computing resources, restricting which elements can communicate with a given element.

Wrapper (Integrability Pattern)

A form of encapsulation where a component is encased within an alternative abstraction, transforming data or control information without changing the original component's interface or class.

Bridge (Integrability Pattern)

Translates 'requires' assumptions of one component to 'provides' assumptions of another, independent of any particular component, with translation established at construction time.

Mediator (Integrability Pattern)

Exhibits properties of both bridges and wrappers but incorporates a planning function for runtime determination of translation.

Service-Oriented Architecture (SOA) Pattern

A collection of distributed components that provide and consume services with specified Quality Attributes (QAs) via interfaces.

Mashup

A web page or application that combines content from more than one source to create a single new service in one graphical interface.

Dynamic Discovery Pattern

Applies the discover tactic to enable runtime discovery of service providers, allowing flexibility in binding services based on criteria like pricing or availability.

Modifiability

Concerned with the cost and risk associated with making changes to a software system.

Goal of Modifiability Tactics

To control the complexity, time, and cost of making changes to a system.

Split Module (Modifiability Tactic)

Refactoring a module that includes non-cohesive responsibilities into separate, more cohesive modules to reduce modification costs.

Redistribute Responsibilities (Modifiability Tactic)

Moving responsibilities that are scattered across several modules into a new or existing module to increase cohesion.

Defer Binding (Modifiability Tactic)

Tactics used to bind values at various times, such as compile time, build time, deployment time, and runtime.

Client-Server Pattern (Modifiability)

Consists of a server providing services simultaneously to multiple distributed clients, characterized by low coupling and independent evolution of clients and servers.

Plug-in (Microkernel) Pattern (Modifiability)

Has core elements providing core functionality and plug-ins that add functionality via fixed interfaces, typically bound at build time or later.

Performance

Refers to a software system's ability to meet timing requirements, often linked to scalability.

Goal of Performance Tactics

To generate a response to events arriving at the system under some time-based or resource-based constraint.

Manage Work Requests (Performance Tactic)

Reducing the number of requests coming into the system to decrease work.

Limit Event Response (Performance Tactic)

When events arrive too rapidly, they are queued or discarded until processed.

Prioritize Events (Performance Tactic)

A scheme that ranks events based on importance for servicing.

Bound Execution Times (Performance Tactic)

Placing a limit on how much execution time is used to respond to an event.

Reduce Computational Overhead (Performance Tactic)

Approaches like reducing indirection, co-locating communicating resources, and periodic cleaning to decrease work per event.

Increase Efficiency (Performance Tactic)

Improving the efficiency of algorithms in critical areas to decrease latency and improve throughput and resource consumption.

Increase Resources (Performance Tactic)

Improving performance by using faster or additional processors, memory, or networks.

Introduce Concurrency (Performance Tactic)

Processing requests in parallel to reduce blocked time, typically by using different threads for event streams or activities.

Maintain Multiple Copies of Computations (Performance Tactic)

Reduces contention by allocating requests for service across multiple instances.

Maintain Multiple Copies of Data (Performance Tactic)

Examples include data replication and caching to improve performance.

Bound Queue Sizes (Performance Tactic)

Controls the maximum number of queued arrivals and the resources used, requiring a policy for overflow.

Schedule Resources (Performance Tactic)

Choosing a scheduling strategy (e.g., FCFS, SJN, Round Robin, Priority) when contention for a resource occurs, compatible with its use characteristics.

Service Mesh Pattern (Performance)

Used in microservice architectures, featuring sidecar proxies that accompany each microservice to handle interservice communications, monitoring, and security, deployed together to reduce latency.

Sidecar Design Concept

Consists of a main application container plus a second container running a service to support, enhance, or extend the main container, attached like a motorcycle sidecar.

Load Balancer Pattern (Performance)

An intermediary that handles messages from clients and determines which instance of a service should respond, balancing the load across a pool of providers.