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