4.1. Стадии процесса моделирования

Весь процесс моделирования можно разбить на несколько этапов:

Формулировка проблемы.
Определение границ системы.
Сбор и анализ данных.
Составление модели.
Отладка и поверка модели.
Экспериментирование с моделью.
Документирование результатов моделирования.
Презентация и представление отчёта заказчику.

Обычно эти этапы не выполняются строго последовательно, а происходит постоянное обращение от последующих стадий к предыдущим, чтобы уточнить или исправить модель.

Особенностью первой стадии является то, что в ней на первый план выступают организационные моменты. Всякую задачу моделирования нужно рассматривать как проект, направленный либо на изменение существующей системы, либо на создание новой. Управление проектами − это особый раздел менеджмента, в котором имеются свои разработанные средства организации процессов, на которых мы не будем подробно останавливаться. Отметим лишь, что успех первой стадии проекта во многом основан на умении находить общий язык с заказчиком. Часто заказчик сам до конца не понимает, чего он хочет достичь, и это нормальное положение вещей. От исполнителя требуется выяснить каковы приоритеты заказчика: снижение стоимости, увеличение прибыли, сокращение сроков, уменьшение риска, улучшение имиджа или что-то другое. Необходимо понять и разъяснить заказчику, каковы возможности математического моделирования в решении его задачи. Завершается первая стадия подписанием контракта, в котором должны быть чётко изложены поставленные задачи, установлены критерии оценки результатов моделирования, оговорены ресурсы и ответственность сторон.

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

Сбор и анализ данных является трудоёмким занятием, в значительной мере определяющим качество результатов всей работы. Все данные можно условно разделить на две категории: 1) накопленные ранее, процедура сбора которых не контролируется разработчиком модели, 2) полученные разработчиком целенаправленно для построения модели. Прежде чем приступать к сбору данных, полезно тщательно продумать свои возможности и составить план действий. Надо определить, какие данные нужны и в каком объёме, из каких источников можно и нужно их получить, когда лучше провести сбор необходимой информации, какие средства для этого подходят полученные данные, в конечном счёте, должны удовлетворять двум требованиям: они должны быть полными и репрезентативными. Последнее означает, что сделанная выборка должна правильно отражать статистические закономерности полной совокупности значений изучаемых параметров. Типичными проблемами на данном этапе могут быть искажение результатов, возникающее при вмешательстве наблюдателя в процесс, и искажения, обусловленные ограничением наблюдений по времени, месту или способу получения данных.

Что касается полноты данных, то здесь надо сделать оговорку, что добиться этого не всегда возможно. Во Введении уже отмечалось, что сама задача моделирования часто возникает вследствие неполноты данных, то есть это ограничение может быть принципиальным. Тем не менее, нужно стремиться к возможно большей полноте данных. Часто оказывается, что при сборе информации что-то важное было упущено и приходится проводить дополнительные исследования. Это требует привлечения значительно больших ресурсов по сравнению с тем случаем, когда сразу проводится сбор всей информации, которая может в самом начале казаться избыточной. Мы не будем подробно останавливаться на этих вопросах. Наша задача сейчас заключается в том, чтобы в общих чертах дать представление о существующей проблеме.

Составление модели это, несомненно, основной этап работы, который можно разбить на несколько составляющих. Начинать создание модели следует прежде, чем приступить к сбору данных о системе. Предварительная модель как раз и показывает, какие данные нужно собрать для её дальнейшей разработки. Некоторое время нелишне уделить выбору наиболее подходящей среды программирования. Создание и отладку программного кода в случае сложных моделей целесообразно проводить по частям, разбивая программу на небольшие блоки. Облегчает работу структурирование программы, использование примечаний, поясняющих назначение и работу её частей, а также обозначение элементов, отражающих их функции.

Отладка и поверка модели неразрывно связаны с процессом составления модели. Сначала они выполняются на уровне отдельных блоков, а потом на уровне всей программы в целом. Прежде всего, устраняются ошибки, приводящие к незапланированному прерыванию выполнения программы. Затем проверяется, работают ли программные блоки так, как это было задумано. В заключение производится поверка модели в целом и её компонентов по отдельности. Arena, как и другие системы программирования, имеет встроенные средства отладки программ, которые можно найти в меню Run. Среди них − пошаговое выполнение программы, трассировка, прерывание программы по условию и др. Средства анимации также могут служить для отладки программ.

Обычный метод поверки состоит в том, чтобы при некоторых входных параметрах получался предсказуемый результат. Наблюдая реальную систему, мы можем экспериментально установить, как она реагирует на определённые воздействия. Затем мы должны проверить, имеется ли подобная взаимосвязь в модели. Другой разновидностью поверки является так называемый тест Тьюринга. Он заключается в том, что группе экспертов предъявляются два набора данных: один − полученный в результате моделирования, а другой − в результате наблюдения реальной системы. Если эксперты не смогут отличить, каким способом получен каждый набор, то можно считать, что модель правильно представляет реальную систему, в противном случае надо продолжить её отладку.

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

Среди наиболее распространённых ошибок, допускаемых при создании модели, можно указать следующие.

Ошибка входных данных.
Неправильно установленные начальные значения переменных и атрибутов.
Неправильное движение объектов. Эта ошибка часто возникает из-за неправильной установки параметров в блоке Decide или неправильного соединения блоков.
Использование разных единиц измерения, например, часов и минут в разных блоках или неправильная установка единиц измерения.
Ошибки записи арифметических выражений.
Ненамеренное изменение значений переменных или атрибутов в программе.
Неправильное использование процедур сбора выводимой информации.
Синтаксические ошибки (с точки зрения синтаксиса языка программирования).
Грамматические ошибки.
Нарушение логической последовательности действий.

Когда модель отлажена, начинается её использование согласно назначению: для анализа системы и внесения предложений по её изменению, а в случае создания новой системы − для её конструирования. Обычный способ использования модели заключается в переборе всех возможных результатов её работы при всех возможных значениях внешних и внутренних параметров. Целью является отыскание оптимального набора внутренних параметров системы, т.е. тех, которые мы можем задавать для реальной системы.

Даже для математической модели задача перебора всех возможных вариантов часто является непосильной. Поэтому разработаны методы ограничения числа испытаний модели. В Arena, например, есть соответствующее средство оптимизации – Optquest for Arena, которое можно вызвать одноимённой командой из меню Tools.

Документирование тесно связано с презентацией результатов. После завершения проекта заказчик вправе получить исчерпывающую информацию о проделанной работе. Этой цели и служит документирование. Правильно составленная документация позволяет исполнителю или стороннему эксперту восстановить логику работы модели.

Особое искусство заключается в презентации модели заказчику. Модель должна выглядеть убедительно для человека, не разбирающегося в программировании. Важным средством достижения этой цели служит анимация, позволяющая представить результаты моделирования наглядным образом. Но, разумеется, хорошая анимация не может компенсировать недостатки в модели или слабую подготовку презентации. Чтобы презентация была убедительной, необходимо предвидеть вопросы заказчика, уметь посмотреть на задачу его глазами. Для этого важно постоянно поддерживать связь с заказчиком, держать его в курсе хода проекта, своевременно вносить в проект коррективы, диктуемые заказчиком.

Содержание