MS_glavy_123 (1086515), страница 14
Текст из файла (страница 14)
2) проверка соответствия программы блок-схеме программы;
3) проверка правильности задания, описания и обработки входной информации при известных 4) характеристиках и диапазонах ее изменения;
5) проверка синтаксической правильности программы;
6) проверка семантической правильности программы;
7) проверка правильности динамики функционирования структуры модели (порождение и уничтожение процессов);
8) численная проверка правильности работы всей модели на упрощенном варианте представления данных и характеристик процессов;
автономная проверка правильности частей программы;
9) комплексная проверка всей программы при решении логических и численных тестовых задач;
10) проверка правильности работы полной модели сравнением
результатов с результатами работы других моделей данной системы или с результатами натурных экспериментов.
Переход к каждому из последующих этапов проверки можно осуществлять только после успешного завершения текущего этапа. Получение отрицательных результатов на любом из этапов проверки требует тщательного анализа причин обнаруженных нарушений, возможных путей их устранения, выбора целесообразного пути их устранения и, при необходимости, его программной реализации.
При выполнении необходимых исправлений в программе следует иметь в виду, что с ростом сложности и объема изменений увеличивается вероятность внесения в программу новых ошибок. По
этому при внесении любых изменений (в существенно меньшей степени это касается устранения синтаксических ошибок) требуется повторное выполнение всех проверок.
Только после их успешного завершения можно приступать к работе с моделью с целью получения реальных результатов.
Определим виды работ, которые необходимо выполнить при проверке и отладке имитационных программ в соответствии с указанным выше перечнем. Первые три из указанных этапов осуществляются еще до выхода на ЭВМ.
1. Для проверки соответствия блок-схемы программы логической блок-схеме модели производится обратный последовательный перевод блок-схемы программы в логическую блок-схему. Желательно, чтобы эта проверка осуществлялась как минимум двумя лицами. Так как указанное обратное преобразование не является однозначным по отношению к прямому, то данная проверка осуществляется на непротиворечивость. Чтение и логическая трактовка действий производится по блок-схеме программы одним из проверяющих (но не автором). Программист модели следит за логической блок-схемой и оценивает тождественность.
2. При проверке соответствия программы блок-схеме модели так же, как и на предыдущем этапе, выполняется обратная проверка — построение по программе блок-схемы модели.
Текст программ перед проверкой должен быть разбит на блоки, которые соответствуют блокам, отображенным на блок-схеме программы. Блоки в программе модели и в блок-схеме должны иметь идентичную нумерацию. Проверку желательно проводить вдвоем.
Один читает программу — это достаточно легко, если программа составлена на языке высокого уровня, например на одном из языков, ориентированных на моделирование. Читающий делает вывод о функциях, выполняемых данным блоком, об условиях окончания работы блока, о блоках, куда будет передано управление и по каким условиям, указывает — какие переменные использует блок и какие изменяет. Проверяется правильность описания всех глобальных и локальных переменных.
Второй программист, следящий за блок-схемой, оценивает, насколько действия, которые описывает читающий программу, соответствуют описанным в блок-схеме.
При возникновении рассогласования выясняется его причина. Разрабатывается вариант ее устранения, который затем реализуется.
3. Задание исходных данных для модели, диапазоны их изменения должны соответствовать используемым типам данных программы в описании переменных и констант и типам операций.
Такой же анализ должен быть выполнен и для информации, передаваемой между блоками модели. Многие из этих проблем упрощаются при использовании языка высокого уровня. В нем слежение за правильным использованием операций возлагается на компилятор, действия которого определяются описанием типов и видов используемых данных. В этом случае программист должен проверить соответствие описаний и исходных данных.
Для того чтобы быть уверенным в правильном задании числовых данных и законов их поступления, необходимо также оценивать правильность работы датчиков случайных чисел, генерирующих заданные распределения.
4. После указанных проверок программа вводится в ЭВМ. При использовании высокоуровневых языков и даже некоторых машинно-ориентированных языков синтаксическая проверка про
граммы практически полностью осуществляется автоматически во время компиляции. Компиляторы вылавливают почти все не найденные синтаксические ошибки и выдают сообщение программисту для их нахождения и исправления.
Семантическая правильность, или правильность применения отдельных операторов (или блоков) языка, частично проверялась на этапах 2 и 3. Некоторые семантические проверки выполняются в
процессе компиляции. Однако значительная доля семантических ошибок обнаруживается в ходе отладки программы на числовых примерах. Правда, современные мощные языки позволяют контролировать ход работы программы и обнаруживать некоторые семантические ошибки.
5. Семантическая правильность в имитационных программах, где собственно вычислительная мощность алгоритмов не столь велика по сравнению с логической частью модели, в значительной степени обеспечивается тщательным выполнением пп.2 и 3.
6. Как уже отмечалось, особенностью моделирующих алгоритмов является необходимость синхронизации во времени работы отдельных частей (процессов) программной модели. Поэтому правильность структурной организации модели, проверенная на этапе 1, должна быть проверена еще и в динамике функционирования.
Для проверки правильности запуска, порождения, уничтожения и взаимодействия процессов нужно подобрать такие тестирующие сочетания входных параметров, чтобы можно было проследить за
работой отдельных процессов. Особое внимание необходимо обратить на правильность порядка «захвата» и «освобождения» ресурсов. После «захвата» в некоторой последовательности группы ресурсов их освобождение должно выполняться в том же порядке. Это позволит исключить тупиковую ситуацию, когда первое сообщение прерывает работу (ввиду занятости требуемого ему ресурса) и не освобождает занятых им ресурсов, а второе, занимающее требуемый ресурс, не может его освободить, так как нужные ему ресурсы заняты первым сообщением.
На этапе этой проверки «тела» программ самих процессов могут быть существенно упрощены. Нужно оставить только те операторы, от которых зависит взаимодействие процессов и существование каждого процесса.
Программист должен использовать имеющиеся в его распоряжении языковые средства для получения информации о ходе процессов в системе.
7. Задача этого типа – численная проверка работы всей модели с упрощенными исходными данными при упрощенном представлении всех процессов, для которых можно заранее предсказать результаты моделирования. Например, из программы исключаются случайные переменные и заменяются определенными константами, которые могут соответствовать в зависимости от требований теста одному из трех значений переменных – среднему, минимальному или максимальному. Полученные результаты при данном сочетании параметров проверяются на непротиворечивость, после чего планируется и выполняется следующий эксперимент.
Успешно проверив изменения основных параметров модели, переходят к следующим этапам.
8. В модели желательно последовательно по процессам (если позволяет машинное время) усложнять их внутреннее алгоритмическое описание, выполняя автономную отладку и доводя процессы до требуемой степени детализации. При этом остальные процессы могут остаться в прежнем отлаженном ранее упрощенном варианте или, если это не мешает работе модели, могут быть заблокированы или изъяты. Проверяется правильность работы используемых датчиков случайных чисел и их законов распределения.
Таким образом, на этой стадии каждый процесс проходит полную отладку.
9. Выполняется комплексная проверка работы — в модели присутствуют все программы, реализующие процессы с требуемой степенью детализации. Проверка осуществляется путем прогона
модели для упрощенных исходных данных (минимальные, максимальные, нулевые значения), для которых оценка поведения системы может быть сделана вручную.
10. Последний этап проверки — работа с моделью для получения значений критерия интерпретации результатов при таких исходных данных, для которых либо могут быть выполнены аналитические оценки, либо существуют другие модели, с результатами работы которых можно произвести сопоставление, либо доступно сравнение с результатами натурных экспериментов.
В заключение рассмотрим средства, часто используемые при отладке программ.
Одно из мощных, универсальных, но чрезвычайно дорогих средств — распечатка динамики работы всей модели (или ее частей). В этом случае выдается информация об изменениях, происходящих в системе в ходе работы модели (например, оператор TRACE в языке GPSS-360). Зоны блоков (или операторов), динамика работы которых представляет интерес, могут задаваться в операторах языка (например, для GPSS-360 двумя операторами: TRACE в начале зоны и UNTRACE — в конце).
Кроме того, в программу можно вставлять команды прямой печати (PRINT), в которых указана информация, подлежащая выводу при каждом входе сообщений в оператор PRINT.
В ходе отладок программы желательно помечать все точки ветвлений алгоритмов таким образом, чтобы по полученной информации можно было установить, куда ушло сообщение и откуда оно пришло (знать для каждой ситуации обе точки) при ветвлении.
По распечаткам, получаемым в результате работы модели при правильной ее организации, можно определить, сколько прошло сообщений и через какие блоки, сколько из них обслужено, сколько стоит в очереди и т.д. Все это помогает оценить правильность функционирования модели. При использовании более новой версии языка GPSS (например, PSS-PC) появились новые возможности управления средствами отладки в режиме диалога с использованием оконного интерфейса и некоторых графических возможностей. Можно следить за динамикой и направлением движения транзактов (сообщений), за количеством прошедших сообщений по каждому блоку, работать в пошаговом режиме, задавать места и условия приостановов работы модели, следить за значениями переменных и собираемой статистикой в процессе моделирования и пр.
В конце этапа реализации модели должны быть составлены следующие документы:
анализ и обоснование достоверности логической блок-схемы и математических выражений;
полная логическая блок-схема, куда включены подробные математические выражения;
описание программы с указанием системы программирования и принятых обозначений;
полная блок-схема программы;
полная запись всех команд и кодов программ;
анализ и обоснование достоверности программы вычислений;
перечень входных и выходных величин с пояснениями (размерности, масштабы, диапазоны изменения величин, обозначения);
инструкция по работе с программой; оценка затрат машинного времени на один цикл.
Контрольные вопросы и задания
1. Докажите, что приведенный выше метод моделирования случайных событий действительно удовлетворяет условиям задачи.
2. Докажите, что метод моделирования по жребию действительно обеспечивает получение событий с заданными вероятностями.
3. Имеет ли значение при моделировании по жребию последовательность задания вероятностей?
4. Используя формулу (3.11), получите соотношения для формирования: а) чисел, равномерно распределенных в интервале [а, b]; б) чисел, имеющих экспоненциальное распределение.
СПИСОК ЛИТЕРАТУРЫ
-
Бусленко Н.П. Моделирование сложных систем. М.: Наука, 1968.
-
Поляк Ю.Г. Вероятностное моделирование на электронных вычислительных машинах. М.: Сов. Радио, 1972.
-
Мартин Ф. Моделирование на вычислительных машинах. М.: Сов. Радио, 1972.
-
Шеннон Р. Имитационное моделирование систем: искусство и наука. М.: Мир, 1978.
-
Киндлер Е. Языки моделирования. М.: Энергоатомиздат, 1985.
-
Питерсон Дж. Теория сетей Петри и моделирование систем/ Пер. с англ. М.: Мир, 1984.
-
Прицкер А. Введение в имитационное моделирование и язык СЛАМ- II. М.: Мир, 1987.
-
Альянах И.Н. Моделирование вычислительных систем. Л.: Машиностроение. Ленинградское отделение, 1988.
-
Максимей И.В. Имитационное моделирование на ЭВМ. М.: Радио и связь, 1988.
-
Технология системного моделирования/Под ред. С.В. Емельянова, В.В. Калашникова и др. М.: Машиностроение; Берлин: Техник, 1988.
-
Советов Б.Я., Яковлев С.А. Моделирование систем. 2-е издание, перераб. и доп. М.: Высшая школа, 1998.
-
Бережной Г. Проблемы создания больших информационных систем. Мир ПК, август, 1998.
-
Шварц М. Сети ЭВМ. Анализ и проектирование/ Пер. с англ.; Под ред. В.А. Жожикашвили. М.: Радио и связь, 1981.
-
Фредерик В. Шолл. Азбука планирования нагрузки LAN// Журнал сетевых решений. № 08.96.
-
Рувинская В.М., Шапорин Р.О. Инженерный опыт использования современных систем моделирования для анализа вычислительных сетей// Открытые системы, 1999, №1.
-
Коуд П., Норт Д., Мейфилд М. Объектные модели: стратегии, шаблоны, приложения. М.: Изд-во ЛОРИ, 1999.
-
Ферапонтов М.М., Крицына Н.В., Деев Д.Л. Моделирование случайных воздействий на ЭВМ. М.: МИФИ, 1995.
-
Новицкий П.В., Зограф И.А. Оценка погрешностей результатов измерений. Л.: Энергоатомиздат, 1991.
63