Выбор языка имитационного моделирования, или не заколачивайте гвозди микроскопом

Один мой приятель не любил стричь газон у себя на даче. Раньше он обходился использованием триммера. Для тех, кто не знает, триммер – это газонокосилка, электрический аналог косы, который надо держать на весу в обеих руках. Этот девайс удобен для скашивания газона в труднодоступных местах и на неровных поверхностях. Его большой минус в том, что он очень сильно вибрирует во время работы. Проблемы начались, когда мой приятель засадил газоном большую лужайку. После скашивания этой лужайки его руки от этой вибрации тряслись так, что он не мог налить воды в стакан, не промахнувшись. Тогда кто-то посоветовал ему купить газонокосилку на колесах, которая идеально подходит для скашивания большой ровной площади. Мой друг долго жалел денег, но в конце концов терпение лопнуло, и он сдался и раскошелился на такую косилку. С тех пор процесс скашивания газона стал проходить легче и занимать меньше времени. А дрожь в руках осталась (шутка).

К чему я все это рассказал? Дело в том, что для решения каждой проблемы нужно правильно выбирать инструменты. Скашивать четыре «сотки» газона триммером, который для этого не предназначен – все равно, что заколачивать гвозди микроскопом. С тем же успехом можно было бы стричь этот газон ножницами. По возможности всегда нужно выбирать тот инструмент, который создан для решения проблемы соответствующего масштаба. В имитационном моделировании – та же самая ситуация.

Случается, что разработчик модели знаком только с каким-то одним методом или языком, либо его софт поддерживает только один метод. В таких случаях бывает, что из-за того, что имитируемые процессы из реальной жизни не очень хорошо «ложатся» на термины этого языка, разработчик вынужден совершать много лишних действий, усложняющих модель. Ему приходится вводить в модель большое количество неестественных элементов – переменных, блоков, состояний, сильно затрудняющих и процесс разработки, и понимание модели другими людьми, и даже ее понимание самим создателем. Более того, части этой модели вряд ли потом можно будет использовать в других похожих проектах. Разработчик усложняет себе жизнь там, где можно было бы справиться быстрее и легче с использованием другого метода.

В выступлении Андрея Борщева на конференции ИММОД-2013 рассматривается пример того, что случается, если разработчик не решился применить другие методы моделирования или просто не имел инструментария, позволяющего ему свободно выбирать метод моделирования.

Такие ситуации нередки. Вы спросите: что мешает освоению других языков моделирования? Ответ прост: лень и страх перед новизной.

Опираясь на наш широкий опыт построения больших моделей, мы можем ответственно заявить: в большинстве случаев следует пробовать другой способ. Если вы видите, что ваша модель начинает приобретать неестественную сложность, и внутри нее начинают громоздиться неуклюжие колоссы на глиняных ногах, лучшее решение – посмотреть на систему, которую вы моделируете, по-другому. Можно ли передать это другими, более простыми, способами? Может быть, дело в том, что выбранный вами язык ограничивает ваши возможности? Если да, то нужно либо вернуться на несколько шагов назад и выбрать другой метод моделирования, либо ввести его элементы на текущем этапе разработки. Разумеется, чтобы свободно выбирать язык, нужно иметь программное обеспечение, позволяющее делать это.

Зачастую вносить такого рода изменения в процессе работы над моделью – сложная задача. Скорее всего, вам придется откатиться назад на несколько этапов, и, возможно, пересмотреть архитектурные решения, принятые ранее. Поменять часть диаграммы процесса на диаграмму состояний или, к примеру, заменить системную динамику агентным моделированием в определенной части модели будет страшно. Можно придумать много причин, почему не нужно этого делать: жалко терять то, на что было потрачено много сил и времени; поджимают сроки сдачи проекта; чтобы переделать модель, придется чему-то учиться, а это сложно, не факт, что получится, да и лень, в конце концов! Но если вы хотите построить модель полезную и понятную, другого пути нет. Чем дальше вы будете продвигаться с использованием излишне усложненной методики, тем сложнее будет работать с нагромождением неестественных конструкций, и тем сложнее будет откатиться назад. Поэтому не тяните и смело отсекайте неуместные части модели и принимайтесь за рефакторинг оставшейся части. Будьте уверены: подобные итерации не удлиняют, а сокращают время выполнения проекта.

Разумеется, везде могут быть исключения. Реальный мир сложнее, чем кажется – например, иногда, чтобы смоделировать какой-то особый случай, приходится писать количество кода, непропорциональное количеству случаев, когда эта ситуация случается в жизни. Однако, в каждом таком случае хороший разработчик должен подумать дважды: «Тот ли метод я выбрал?».

Правильный выбор инструмента – основа успеха любого дела, от стрижки газона до проекта по имитационному моделированию. А чтобы иметь возможность выбирать любой современный метод имитационного моделирования и не платить дополнительных денег, нужно сразу остановиться на программном обеспечении, дающем возможность использовать их все.

Кстати, обзор всех методов имитационного моделирования можно услышать и увидеть в том же выступлении Андрея Борщева на ИММОДе: