1 of 10

Dynamical System Modeling and Stability Investigation�DSMSI-2025

May 08-10, 2025, Kyiv, Ukraine

ARCHITECTURAL PRINCIPLES FOR IMPLEMENTING ADAPTIVE SOFTWARE BEHAVIOR STRATEGIES

​

Bychkov O., Taras Shevchenko National University of Kyiv

Moroz M., Taras Shevchenko National University of Kyiv

�

2 of 10

Introduction

Dynamical System Modeling and Stability Investigation, DSMSI-2025

  • Stability in engineering: a system is stable if, after a disturbance, it returns to a bounded region in finite time;
  • In software: programs should keep performing their main functions even when the operating context shifts
  • Disturbances in software are discrete: unexpected user behavior, traffic spikes, crashes of cooperating services
  • Unique opportunity: unlike physical systems, software modules can be reconfigured or replaced at run time
  • Design challenge: ensure coordination, consistency, and low overhead while adapting dynamically

3 of 10

Problem Statement

Dynamical System Modeling and Stability Investigation, DSMSI-2025

  • Software stability requirement: each function must remain within a stable region despite diverse and unforeseen disturbances
  • Challenge: disturbances in software are unpredictable and discrete → achieving bounded recovery is non-trivial
  • Limitations of existing approaches:
    • Control-loop frameworks: global reasoning, but high latency and costly knowledge bases;
    • Pattern catalogues: flexible but fragmented, designer must combine them;
    • Reconfiguration frameworks: focus on structural changes, neglect fine-grained behavior;
  • Architectural goal: design a lightweight enabling pattern that provides runtime adaptation, modular growth, and fallback handling of unforeseen conditions

​

4 of 10

UML class diagram of the proposed pattern

Dynamical System Modeling and Stability Investigation, DSMSI-2025

5 of 10

UML sequence diagram of the proposed pattern

Dynamical System Modeling and Stability Investigation, DSMSI-2025

6 of 10

Static design metrics

Dynamical System Modeling and Stability Investigation, DSMSI-2025

Metric

Direct-call (baseline)

Event-driven (our design)

Coupling Between Objects (CBO)

14

4

Lack of Cohesion of Methods (LCOM)

0.78

0.19

Response For Class (RFC)

43

36

Depth of Inheritance Tree (DIT, max)

2

3

The pattern eliminates most direct dependencies because publishers never name subscribers; responsibility is narrowed to well-defined strategy classes, raising cohesion and lowering communication complexity. The single extra inheritance level stems from interface extraction and does not materially influence understandability.

7 of 10

Change-impact comparison

Dynamical System Modeling and Stability Investigation, DSMSI-2025

Across scenarios the pattern confines edits to extension points and avoids cross-cutting refactors, confirming superior ease of extension and maintenance.

Scenario description

Changes in baseline

Relative impact on baseline

Changes in our design

Relative impact on our design

1. New event type

Modify detector, tracker, controller logic; refactor conditional branches

high

Add enumeration constant, implement one strategy, register in selector

low

2. Replace tracker algorithm

Alter tracker class

low

Insert new strategy; legacy strategy remains intact

low

3. Introduce a monitoring module for logging events

Add logging calls into existing classes

moderate

Implement subscriber, subscribe to events; zero changes elsewhere

low

8 of 10

Comparison of our pattern and other approaches/frameworks

Dynamical System Modeling and Stability Investigation, DSMSI-2025

Criterion

Proposed pattern

Self-healing loops (MAPE-K) [3,4]

Self-adaptive pattern catalogues [8,12,13]

Dynamic reconfiguration taxonomies [14,15]

Traditional fault-tolerant recovery technics [17]

Adaptation trigger

Typed in-process events

External monitors & analysers

Explicit monitors or embedded sensors

Architectural state-machine guards

Error detectors, watchdogs

Granularity of change

Strategy swap inside module

Component or service restarts

Varies (algorithm/service)

Component, connector, configuration

Whole module rollback

Coupling level

Moderate (pub-sub decoupling)

Moderate (shared knowledge base)

Mixed; often direct callback links

Moderate (coordination controllers)

High (static bindings)

Ease of extension

Moderate: add new strategy or event

Moderate: update knowledge rules

Moderate: integrate new pattern

Low-moderate: new states + guards

Low: code recompilation

Stability guarantee

Strategy switch when event triggered; default fallback strategy; relies on designer

Rule-based; depends on plan quality

Heuristic – no formal bound

Often informal; relies on designer

Formal if recovery block correct

9 of 10

Conclusions

Dynamical System Modeling and Stability Investigation, DSMSI-2025

Strengths of the proposed pattern:

  • Fast local adaptation: in-process event handling avoids external monitoring latency;
  • Structural simplicity: coordination through a single EventManager, no heavy global reasoning layer;
  • High extensibility: new events or strategies added with local changes only.

​

Weaknesses and trade-offs:

  • No global optimisation: decisions optimised per module, not across system;
  • No built-in redundancy: relies on strategy switching, not failover components;
  • Sensitive to event storms: high event rates may overwhelm subscribers;
  • Single-process assumption: a fatal exception can terminate the entire application.

10 of 10

Thank you for your attention