Все мы так или иначе проектируем и реализуем системы. Будь то программные комплексы, инфраструктурные или платформенные решения. И в рамках этой работы мы постоянно сталкиваемся с понятием "сложной системы". В рамках этой заметки я хочу поделиться своим видением на сложность систем и "борьбу" с ней.
Начнем с определения системы. Мне нравится определение данное в книге System Architecture. Strategy and Product Development for Complex Systems. Перевод звучит примерно так:
Система, это набор компонентов и их связей. Функциональность всей системы больше, чем сумма функциональностей отдельных ее составляющих.
Это очень важное определение. Оно говорит о том, что система должна генерировать "полезность". Если система не дает прироста "полезности", в сравнении с компонентами, ее составляющими, то, вероятно, такая система не очень нужна.
Следующий вопрос, который можно себе задать — а что же такое "сложная система". Можно много рассуждать на этот счет, но на мой взгляд сложной можно назвать систему, которую сложно оценить умом, с которой сложно работать, сложно понять, сложно держать в голове все взаимодействия, которые происходят в этой системе.
И тут для нас, как инженеров, важно иметь механизм, какой-то способ, позволяющий эту сложность измерить. В качестве базы для этого механизма ребята из MIT предлагают использовать широко известное "магическое число семь плюс минус два". На эту тему есть оригинальное исследование, а так же статьи на хабре и презентации TED. В двух словах, идея всех этих исследований состоит в том, что "рабочая память" человека может одновременно удерживать и работать с ограниченным числом различных объектов. Тут очень важно понятие "различных" объектов, поскольку мозг борется со сложностью группируя объекты. Например, связи между объектами одинакового вида или типа можно держать в голове как одну связь. Или, более наглядно — не надо представлять себе систему из кучи перемешанных шариков разных цветов. Достаточно просто сгруппировать их в голове, сказать, что есть, скажем, пять красных шариков, семь желтых и три синих. Это упрощает работу с системой, уменьшая количество объектов с пятнадцати до трех. Поэтому в контексте оценки сложности мы говорим именно о разных объектах, атомарных, которые невозможно сгруппировать.
В конечном итоге есть разные оценки емкости рабочей памяти. Кто-то говорит о четырех объектах, кто-то — о пяти, кто-то — о семи. В своих рассуждениях я буду придерживаться классического подхода — "семь плюс минус два".
Исходя из этих оценок можно сказать, что если с системой становится сложно работать, удерживать ее компоненты и связи в памяти, то, видимо, она превышает тот самый предел емкости в "семь плюс минус два". Это в свою очередь означает, что это самое "магической число семь" можно использовать как базовую оценку сложности системы. Я думаю, что следующее, пока, промежуточное определение, имеет право на жизнь:
Сложная система, это система состоящая из 7+-2 атомарных компонентов и их связей в различных соотношениях.
Классические способы борьбы со сложностью
Теперь давайте вкратце вспомним классические способы или инструменты борьбы со сложностью на этапе проектирования. Их немного: абстракция, декомпозиция, иерархия и иерархическая декомпозиция.
- Абстракция — способ, который позволяет выделить основную функцию системы или подсистемы и скрыть содержимое
- Декомпозиция — способ разбиения системы на блоки меньшего размера или составляющие
- Иерархия — способ разбиения системы на уровни, где уровни имеют определенное место в структуре и располагаются одни над другими
- Иерархическая декомпозиция — способ, объединяющий иерархию и декомпозицию
Все эти средства в конечном итоге призваны упростить отдельные подсистемы нашей системы таким образом, чтобы при работе с каждым отдельным блоком он "влезал в голову" целиком.
О чем это все в конце концов
Что же все эти вещи нам дают? Попросту говоря, идея состоит в том, чтобы, используя различные методы, преобразовать неструктурированный набор компонентов системы, к некоему структурному виду. При этом, памятуя о магической семерке, можно сказать, что каждый блок в декомпозиции не должен содержать больше чем семь плюс/минус два элемента. Иначе, при детальном рассмотрении такого блока, его будет сложно контролировать.
С другой стороны, если мы имеем систему с большим количеством блоков, разбитых на иерархические уровни, то количество таких уровней, желательно, не должно превышать семи (плюс/минус два). В качестве иллюстрации хочу привести слайд из Fundamentals of Systems Engineering. Как видно из слайда, сложность системы растет с ростом количества уровней декомпозиции.
Таким образом правильный процесс проектирования системы можно описать примерно следующим тезисом:
Не стройте сложные системы. Стройте системы с необходимым уровнем сложности.