К основному содержимому
#Architecture

Residuality Theory, random simulation, and attractor networks (Рубрика Architecture)

#Architecture #Software #SystemDesign #Engineering #DistributedSystems

Недавно прочитал этот whitepaper Barry O'Reilly, который он написал еще в 2022 году. Я решил изучить этот whitepaper после двух выступлений автора, о которых я уже рассказывал ранее

  1. An Introduction to Residuality Theory
  2. The Philosophy of Architecture Мне показались его выступления на тему его resudiality theory интересными и я прочитал paper, про который хочу рассказать кратко ниже
  3. Барри придумал новый подход к архитектуре софта, который фокусируется на создании систем, способных адаптироваться к непредвиденным вызовам и сложностям.
  4. Предыдущие подходы в основном основывались на requirements management и risk management, которые должны были конвертировать неизвестные неизвестные во что-то более управляемое, но конечно не могли это сделать
  5. Подход автора включает в себя random simulation как ключевой компонент для выявления и решения потенциальных проблем заранее.
  6. Random simulation включает в себя моделирование различных случайных стрессоров для наблюдения за паттернами и прогнозирования потенциальных "residues" или новых состояний, возникающих из этих стрессоров (метод Монте-Карло)
  7. Анализ стрессоров выглядит примерно так: инженеры выявляют и анализируют случайные стрессоры, с которыми софт может столкнуться в предполагаемой среде. Это помогает в проектировании систем, способных справляться с неожиданными событиями или ситуациями.
  8. Под влиянием различных стрессоров система стремится к устойчивым состояниям, аттракторам. Выявление этих аттракторов помогает понять, как система будет вести себя в различных условиях.
  9. Гиперлиминальность описывает как упорядоченная система (софт) живет внутри неупорядоченной (бизнес-среда). Эта концепция включает в себя понимание перехода от текущего состояния к новому состоянию (residue) из-за стрессора. Одновременно, автор определяет hyperliminality coupling так

If two nodes in a network each have a relationship with a third node, then those two nodes are very likely to have a relationship. Therefore, if a stressor in the wider hyperliminal system interacts with two software components, then those two components can be considered coupled. 8 ) Если кратко описывать основные утверждения теории автора, то они выглядят так

  1. Enterprise software systems are ordered systems that live in disordered environments - hyperliminal systems.
  2. These systems will experience stress that they have not been designed for because the disorderedenvironment is by definition unpredictable.
  3. The system’s future is a function of residue, whatever is left over after it is stressed.
  1. Архитектуру Барри описывает, используя Boolean Networks (Kauffman Networks), где есть три параметра NKP (N - количество нод, K - наибольшее количество связей ноды в сети, P - bias в сторону конкретного результата при обработке сигнала). Барри матчит это на архитектуру софта так
  • N - относится к программным компонентам
  • K - описывает связи или вызовы между компонентами
  • P - увеличивается при использовании контрактов, схем, политик или уменьшении сложности кода (количества ветвлений в нем) Собственно, эти параметры определяют какие аттракторы будут в сети и сколько их будет. Для описания всего это добра нужны adjacency matrices для маппинга компонентов одного типа между собой, а также incidence matrices, где описывается маппинг стрессоров на компоненты
  1. Процесс использования подхода выглядит так
  • Сначала надо спроектировать наивную архитектуру и провести random simulation для нее
  • Дальше надо использовать incidence matrices для отображения стрессоров относительно residues, процессов, потоков и компонентов программного обеспечения.
  • Стоит разделять стрессоров на обучающие и тестовые наборы для валидации процесса проектирования и расчета индекса остаточности (Ri).

В общем, residuality theory направлена на создание более устойчивого софта путем предвидения и решения будущих проблем в дополнение к учету функциональных требований.

#Architecture #Software #SystemDesign #Engineering #DistributedSystems