Полная версия

Главная arrow Информатика arrow Имитационное моделирование

  • Увеличить шрифт
  • Уменьшить шрифт


<<   СОДЕРЖАНИЕ ПОСМОТРЕТЬ ОРИГИНАЛ   >>

Проверка и отладка программ имитационных моделей

Проверку и отладку имитационных программ можно представить в виде последовательности следующих действий [15, 21]:

  • 1) проверка соответствия блок-схемы программы логической блок-схеме модели;
  • 2) проверка соответствия программы блок-схеме программы;
  • 3) проверка правильности задания, описания и обработки входной информации при известных характеристиках и диапазонах ее изменения;
  • 4) проверка синтаксической правильности программы;
  • 5) проверка семантической правильности программы;
  • 6) проверка правильности динамики функционирования структуры модели (порождение и уничтожение процессов);
  • 7) численная проверка правильности работы всей модели на упрощенном варианте представления данных и характеристик процессов;
  • 8) автономная проверка правильности частей программы;
  • 9) комплексная проверка всей программы при решении логических и численных тестовых задач;
  • 10) проверка правильности работы полной модели сравнением результатов с результатами работы других моделей данной системы или с результатами натурных экспериментов.

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

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

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

Определим виды работ, которые необходимо выполнить при проверке и отладке имитационных программ в соответствии с указанным выше перечнем. Первые три из указанных этапов осуществляются еще до выхода на ЭВМ [15, 21].

1. Для проверки соответствия блок-схемы программы логической блок-схеме модели производится обратный последовательный перевод блок-схемы программы в логическую блок-схему. Желательно, чтобы эта проверка осуществлялась как минимум двумя лицами. Так как указанное обратное преобразование не является однозначным по отношению к прямому, то данная проверка осуществляется на непротиворечивость. Чтение и логическая трактовка действий производятся по блок-схеме программы одним из проверяющих (но не автором). Программист модели следит за логической блок-схемой и оценивает тождественность.

2. При проверке соответствия программы блок-схеме модели так же, как и на предыдущем этапе, выполняется обратная проверка — построение по программе блок-схемы модели.

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

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

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

При возникновении рассогласования выясняется его причина. Разрабатывается вариант ее устранения, который затем реализуется.

3. Задание исходных данных для модели, диапазоны их изменения должны соответствовать используемым типам данных программы в описании переменных и констант и типам операций.

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

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

  • 4. После указанных проверок программа вводится в ЭВМ. При использовании высокоуровневых языков и даже некоторых машинно-ориентированных языков синтаксическая проверка программы практически полностью осуществляется автоматически во время компиляции. Компиляторы вылавливают почти все не найденные синтаксические ошибки и выдают сообщение программисту для их нахождения и исправления.
  • 5. Семантическая правильность, или правильность применения отдельных операторов (или блоков) языка, частично проверялась на этапах 2 и 3. Некоторые семантические проверки выполняются в процессе компиляции. Однако значительная доля семантических ошибок обнаруживается в ходе отладки программы на числовых примерах. Правда, современные мощные языки позволяют контролировать ход работы программы и обнаруживать некоторые семантические ошибки.

Семантическая правильность в имитационных программах, где собственно вычислительная мощность алгоритмов не столь велика по сравнению с логической частью модели, в значительной степени обеспечивается тщательным выполнением пп. 2 и 3.

6. Как уже отмечалось, особенностью моделирующих алгоритмов является необходимость синхронизации во времени работы отдельных частей (процессов) программной модели. Поэтому правильность структурной организации модели, проверенная на этапе 1, должна быть проверена еще и в динамике функционирования. Для проверки правильности запуска, порождения, уничтожения и взаимодействия процессов нужно подобрать такие тестирующие сочетания входных параметров, чтобы можно было проследить за работой отдельных процессов. Особое внимание необходимо обратить на правильность порядка «захвата» и «освобождения» ресурсов. После «захвата» в некоторой последовательности группы ресурсов их освобождение должно выполняться в том же порядке. Это позволит исключить тупиковую ситуацию, когда первое сообщение прерывает работу (ввиду занятости требуемого ему ресурса) и не освобождает занятых им ресурсов, а второе, занимающее требуемый ресурс, не может его освободить, так как нужные ему ресурсы заняты первым сообщением.

На этапе этой проверки «тела» программ самих процессов могут быть существенно упрощены. Нужно оставить только те операторы, от которых зависит взаимодействие процессов и существование каждого процесса.

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

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

Успешно проверив изменения основных параметров модели, переходят к следующим этапам.

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

Таким образом, на этой стадии каждый процесс проходит полную отладку.

  • 9. Выполняется комплексная проверка работы — в модели присутствуют все программы, реализующие процессы с требуемой степенью детализации. Проверка осуществляется путем прогона модели для упрощенных исходных данных (минимальные, максимальные, нулевые значения), для которых оценка поведения системы может быть сделана вручную.
  • 10. Последний этап проверки— работа с моделью для получения значений критерия интерпретации результатов при таких исходных данных, для которых либо могут быть выполнены аналитические оценки, либо существуют другие модели, с результатами работы которых можно произвести сопоставление, либо доступно сравнение с результатами натурных экспериментов.

Полное представление об ошибках в программе моделирования, а также о ее функционировании можно получить, применяя специальные инструменты. Так, например, в системе

Simulink таким средством является отладчик блок-диаграмм Simulink Debugger.

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

Мощными средствами проверки программы в системе GPSS WORLD служат такие следующие инструменты:

  • Журнал Journal;
  • Стандартный отчет Standard Report;
  • Окна моделирования Simulation Windows;
  • Снимки моделирования Simulation Snapshot.

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

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

QUEUE — имя или номер объекта типа «очередь»;

МАХ — максимальное содержимое объекта типа «очередь» в течение периода моделирования, который начинается с начала работы или с последней команды RESET или CLEAR;

CONT — текущее содержимое объекта типа «очередь» в момент завершения моделирования;

ENTRIES — общее количество входов в очередь в течение периода моделирования (счетчик входов);

ENTRIES (О) — общее количество входов в очередь с нулевым временем ожидания (счетчик «нулевых» входов);

AVE.CONT — среднее значение длины очереди;

AVE.TIME — среднее время, проведенное транзактом в очереди с учетом всех входов в очередь;

AVE.(-O) — среднее время, проведенное транзактом в очереди без учета «нулевых» входов в очередь;

RETRY - количество транзактов, ожидающих специальных условий, зависящих от состояния объекта типа «очередь».

Окна моделирования предназначены для вывода информации в числовой или графической формах о переменных, имеющихся в программе.

Динамические окна модифицируются в процессе моделирования. Можно открыть интерактивное представление следующих динамических окон:

  • • блочной структуры модели;
  • • произвольного списка выражений;
  • • каналов обслуживания;
  • • логических переключателей;
  • • любого перекрестного раздела матричного объекта;
  • • графиков выражений;
  • • объектов очереди;
  • • объектов сохраняемых величин;
  • • объектов накопителей;
  • • любого объекта таблицы.

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

Снимок — это отдельное изображение, которое делается в заданный момент времени в процессе моделирования системы.

Можно получить снимок следующих объектов:

  • • любого требования в системе;
  • • цепи текущих событий;
  • • цепи будущих событий;
  • • числовых групп;

юо

  • • цепей пользователя;
  • • группы требований.

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

  • — анализ и обоснование достоверности логической блок- схемы и математических выражений;
  • — полная логическая блок-схема, куда включены подробные математические выражения;
  • — описание программы с указанием системы программирования и принятых обозначений;
  • — полная блок-схема программы;
  • — полная запись всех команд и кодов программ;
  • — анализ и обоснование достоверности программы вычислений;
  • — перечень входных и выходных величин с пояснениями (размерности, масштабы, диапазоны изменения величин, обозначения);
  • — инструкция по работе с программой;
  • — оценка затрат машинного времени на один цикл.

Контрольные вопросы и задания

  • 1. Докажите, что приведенный в главе метод моделирования случайных событий действительно удовлетворяет условиям задачи.
  • 2. Докажите, что метод моделирования по жребию действительно обеспечивает получение событий с заданными вероятностями.
  • 3. Имеет ли значение при моделировании по жребию последовательность задания вероятностей?
  • 4. Используя формулу (3.6), получите соотношения для формирования: а) чисел, равномерно распределенных в интервале [а, Ь]; б) чисел, имеющих экспоненциальное распределение.
  • 5. Какая мажорирующая функция наиболее эффективна для моделирования распределения с выраженным максимумом по методу исключения? Какие недостатки при практической реализации предложенной функции имеют место?
  • 6. Каков закон распределения случайного вектора, полученного методом моделирования в рамках корреляционной теории?
  • 7. Какие статистические методы можно использовать в качестве тестов при проверке качества моделей случайных событий и величин?
 
<<   СОДЕРЖАНИЕ ПОСМОТРЕТЬ ОРИГИНАЛ   >>