Föreläsning 4 - Quality Characteristics of IoT-Based Systems Flashcards

(21 cards)

1
Q

What does functionality mean in software architecture? -

A
  • Functionality means what the system is supposed to do — its main tasks or purpose.
  • It doesn’t control or determine the architecture. → You can build many different architectures to support the same functionality.
  • Functionality and quality attributes (like performance, security, etc.) are separate ideas — they don’t affect each other directly.
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
2
Q

What are quality attribute considerations? -

A

If a functional requirement is “when the user is home, → thermostat should heat the apartment if temp is below…”. Quality attribute:

  • Performance – How fast it heats.
  • Availability – How often it fails & how fast it’s fixed.
  • Usability – How easy it is to learn user preferences.
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
3
Q

Three problems with quality attributes and solutions -

A
  • Definitions aren’t testable (saying a system is “modifiable” means little without specifics).
  • Overlapping concerns (It’s unclear which attribute an issue belongs to (e.g., system failure from an attack)).
  • Different vocabularies (each quality attribute area uses its own terms).

Solutions: Use quality attribute scenarios to make attributes clear and testable. Discuss each attribute’s core concerns to unify understanding.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
4
Q

Six parts of a quality attribute scenario -

A
  • Stimulus (what triggers the system).
  • Stimulus source (who/what causes the stimulus).
  • Environment (situation/context the system is in when it responds).
  • Artifact (system/components that react).
  • Response (what system does after being triggered).
  • Response measures (how we judge if the response was good).
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
5
Q

Name four IoT systems quality attributes -

A

Availability, performance, security and usability.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
6
Q

Availability -

A

The system is ready and working when needed. It includes the ability to handle and recover from faults within a time limit. Related to:

  • Security (e.g. denial-of-service attacks).
  • Performance (slow response may look like failure).
  • Safety (recovering from hazardous states).
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
7
Q

Detect faults key tactics -

A

discover when something in the system doesn’t work as intended.

  • Monitor (central concept for health checking on other parts of the system).
  • Heartbeat (common in real-time/IoT systems to show a process is alive).
  • Ping/Echo (periodic message exchange occurs between a monitor and a process being monitored).
  • Exception Detection (detection of a system condition that alters the normal flow of execution).
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
8
Q

Recover from faults, key tactics -

A

Tactics used to recover when a fault occurs.

  • Rollback (returning to the previous working state).
  • Retry (try the failed operation again).
  • Graceful degradation (system continues to function, even with reduced capabilities).
  • Redundant spare (use backup components).
  • Exception handling (dealing with errors as they occur).
  • Reconfiguration (adjusting the system to work around the fault).
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
9
Q

Prevent faults, key tactics -

A
  • Removal from service (temporarily place a system component in an out-of-service state to mitigate potential system failure).
  • Predictive model (use performance metrics to predict the onset fault).
  • Exception prevention (Using methods to avoid errors (exceptions) before they happen - instead of just reacting to them.).
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
10
Q

Performance -

A

is about timing. Events occur, and the system must respond to them.

  • Event arrival patterns: periodic, stochastic and sporadic.
  • Event servicing:
    • Latency - the time taken between arrival and response.
    • Jitter - variation in latency.
    • Throughput - number of requests processed per second.
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
11
Q

Performance scenarios -

A
  • source of stimulus (internal/external).
  • Stimulus (event arrival, based on patterns).
  • Artifact (system).
  • Environment (normal mode; overload mode).
  • Response (changes level of service, processes stimuli).
  • Response measures (latency, jitter, miss rate, data loss).
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
12
Q

Control resource demand, tactics -

A

tactics to ensure that the system performs efficiently by controlling and managing resource usage and the demand placed on the system.

  • Manage work requests (reduce the number of requests coming into the system).
  • Limit event response (cap the number of events processed, policies for ignoring events).
  • Prioritise events (ensure important events are processed rapidly).
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
13
Q

Tactics to meet performance requirements -

A

methods to improve system performance.

  • Caching (store frequently used data for quick access, reducing slow data fetching).
  • Load Balancing (distribute traffic across servers to optimize resources and speed up responses).
  • Parallelism/Concurrency (perform multiple tasks at once to maximize resource use and reduce response time).
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
14
Q

Attribute-Driven design -

A

is a methodology for designing software architecture based on quality attributes (e.g., performance, scalability, security). Instead of focusing solely on functional requirements, ADD emphasises the architectural drivers that shape the system’s structure.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
15
Q

Key concepts of ADD -

A
  • Identify drivers: Consider quality attributes, constraints, and functional requirements.
  • Decompose system: Break the architecture into subsystems and components based on drivers.
  • Apply tactics/patterns: Use design patterns (e.g., microservices) to meet goals.
  • Evaluate design: Assess the architecture for effectiveness.
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
16
Q

Why use ADD? -

A

Ensures architectural decisions align with business goals. Helps prioritise trade-offs between competing quality attributes. Provides a structured approach to designing complex systems.

17
Q

Two data Processing Paradigms

A

Real-time processing and batch processing

18
Q

Batch processing

A
  • Definition: Processing data in large blocks at scheduled times.
  • Tools: Apache NiFi, Apache Spark.
  • Use Case: Ideal for non-time-sensitive tasks and large-scale data analytics.
  • Benefits: Cost-effective for large volumes of data, efficient in resource use when real-time analysis is not required.
19
Q

Real-Time Processing

A
  • Definition: Continuous input and processing of data to provide immediate output and insights.
  • Tools: Apache Kafka, Apache Storm, AWS Kinesis.
  • Use Case: Essential for applications requiring instant decision-making, such as fraud detection, live monitoring systems.
  • Benefits: Enables timely insights and actions, critical for applications where delay can result in significant consequences
20
Q

Interoperability as quality attribute

A

Interoperability is the ability to usefully exchange information between two software components. It’s not just about sending and receiving messages, but also about ensuring that both systems understand the structure (format) and meaning (semantics) of the data — even if the components are from different manufacturers.

One key tactic:

  • Use of a Message Bus - A message bus (MQTT) allows different components to publish and subscribe to messages using standardized topics.
21
Q

Modifiability as a quality attribute

A

Modifiability is the ability to make a change to the behavior of a system. These changes can occur at various stages like:

  • Compile time (code changes)
  • Build time (dependency changes)
  • Initialization time (configuration)
  • Runtime (dynamic reconfiguration or input)

One key tactic:

  • Use of Configuration Parameters. Let the system’s behavior be controlled by values stored outside the code (like in files or environment variables). You can change how the system behaves without changing or recompiling the code.