Software Arkitektur - Flash cards - 2024

The practice of documenting the structures

An architectural view that focuses on the static structure of the system

An architectural view that illustrates the runtime behavior of the system

An architectural view that maps software components to physical devices and deployment environments

Design patterns that abstract the instantiation process

Design patterns concerned with how classes and objects are composed to form larger structures. Examples include Composite and Adapter.

Design patterns that focus on algorithms

A unified

An architectural style where the application is composed of loosely coupled

A UML diagram that represents the interactions between users (actors) and the system to capture functional requirements.

A UML diagram that shows how objects interact in a particular sequence

A UML diagram that illustrates the states of an object and the transitions between those states

Documentation using sketches

Documentation using standardized notations like UML or SysML

Documentation with precise

Characteristics that determine the non-functional properties of a system

Formal languages used to describe the architecture of a software system

A creational design pattern where a method in a class creates an object

A structural design pattern that allows you to compose objects into tree structures to represent part-whole hierarchies

A behavioral design pattern that allows an object to alter its behavior when its internal state changes

Ease of changing the system's structure or behavior.

Detailed

Interaction description between users and system to achieve goals.

Recurring design solution in a specific context.

Design primitive for achieving a quality attribute response.

Separates clients and servers

Groups modules into layers

Publishers send events to subscribers via an event bus.

Ensure module elements are closely related.

Minimize dependencies between modules.

Delay value assignment to increase flexibility.

Condition requiring a system response.

Entity generating the stimulus.

Criteria for evaluating the response.

Circumstances under which the scenario occurs.

Part of the system targeted by the stimulus.

Core with extensible plug-ins for added functionality.

Ability to handle increased load by adding resources.

Capability to support system variants and features.

Ease of running software on different platforms.

Probability that a system will be operational when needed.

Ability of a system to meet timing requirements.

Methods to identify system faults

System's ability to continue operating despite faults.

Average time between system failures.

Average time to repair a system after a failure.

Amount of work done in a given time period.

Time taken to respond to a request.

Duplicate components to take over if primary fails.

Dealing with errors by reporting or masking them.

Revert to a previous state if a deployment fails.

Reattempting an operation after a transient failure.

Reassigning responsibilities to functioning resources.

Reducing work requests to manage system load.

Adding faster processors or more memory.

Processing requests in parallel to reduce wait time.

Reducing contention by having multiple data copies.

Distributing load across multiple resources.

Prevents repeated failed service calls.

Ease with which software can be tested to ensure it functions correctly.

Protecting data from unauthorized access while ensuring authorized access.

Using specialized interfaces to manage variable values during testing.

Recording system state to recreate faults for testing.

Storing state in a single place to start components in an arbitrary state.

Controlling input data to facilitate easier testing.

Isolating system instances for experimentation without real-world consequences.

Hand-coded checks indicating faulty states in a program.

Reducing dependencies and nondeterminism in the system.

Comparing network traffic to known malicious patterns.

Using checksums or hash values to ensure message integrity.

Identifying sources of external input to the system.

Ensuring actors are who they claim to be.

Ensuring authenticated actors have the right permissions.

Encoding information to protect it from unauthorized access.

Locking access to resources during an attack.

Keeping records of user and system actions for tracing attacks.

Ensuring message senders cannot deny sending messages.

Separating dependencies from behavior for better testability.

Identify and refactor duplicated logic.

Store configuration values outside of the source code.

Dynamically enable/disable features without redeployment.

Duplicate components to provide backup.

Switch to a standby system upon failure.

Distribute workloads across multiple resources.

Sequence of tools/activities for code deployment.

Gradually roll out changes to a small user subset.

Tools like Git for managing code changes.

Tools like Jenkins for automating build and deployment.

Tools like Docker for managing containerized environments.

Tools like Prometheus for monitoring system performance.

Tools like Ansible for managing deployments.

Tools like LaunchDarkly for managing feature toggles.

Requirements profoundly affecting the architecture.

Top-down representation of ASRs

Method to identify and prioritize quality attributes early.

Describes how an organization creates

Describes business problems

Generating scenarios that address stakeholder concerns.

Merging similar scenarios to avoid redundancy.

Voting to determine the importance of scenarios.

Developing detailed quality attribute scenarios.

Key requirements influencing architectural decisions.

Presenting business concerns and requirements.

Presenting system descriptions and current architecture.

A characteristic determining the system's performance.

Specific behaviors or functions a system must support.

Potential technical issues affecting project success.

The importance of a requirement to business success.

Involving stakeholders in decision-making processes.

Tracking and managing requirements throughout the project.

Tool for creating utility trees and diagrams.

Tool for analyzing strengths

Systematic method for designing software architecture in iterations.

Assessing initial requirements

Specific objective for a design iteration

Architectural solutions or patterns addressing specific drivers and requirements.

Creating architectural components

Visual representations of architectural decisions and structures.

Evaluating design against iteration goal and overall design purpose.

Detailed descriptions of quality attributes and their impacts.

Limitations or restrictions affecting architectural decisions.

Key factors guiding the architectural design process.

Choosing system parts to improve based on drivers and goals.

Assigning duties to architectural elements.

Specifying how components interact and exchange information.

Repeated cycle of reviewing

Essential system functionalities driving the design.

Issues or considerations affecting architectural decisions.

The main objective guiding a design iteration.

An initial model used to test design concepts and decisions.

Method for evaluating software architectures by identifying tradeoffs and risks.

Requirements profoundly impacting the architecture.

Architectural decisions significantly affecting a quality attribute.

Improving one quality attribute degrades another.

Architectural decisions that may lead to undesirable outcomes.

Architectural decisions deemed safe after analysis