MS_glavy_123 (Учебное пособие), страница 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]; б) чисел, имеющих экспоненциальное распределение.

СПИСОК ЛИТЕРАТУРЫ

1. Бусленко Н.П. Моделирование сложных систем. М.: Наука, 1968.

2. Поляк Ю.Г. Вероятностное моделирование на электронных вычислительных машинах. М.: Сов. Радио, 1972.

3. Мартин Ф. Моделирование на вычислительных машинах. М.: Сов. Радио, 1972.

4. Шеннон Р. Имитационное моделирование систем: искусство и наука. М.: Мир, 1978.

5. Киндлер Е. Языки моделирования. М.: Энергоатомиздат, 1985.

6. Питерсон Дж. Теория сетей Петри и моделирование систем/ Пер. с англ. М.: Мир, 1984.

7. Прицкер А. Введение в имитационное моделирование и язык СЛАМ- II. М.: Мир, 1987.

8. Альянах И.Н. Моделирование вычислительных систем. Л.: Машиностроение. Ленинградское отделение, 1988.

9. Максимей И.В. Имитационное моделирование на ЭВМ. М.: Радио и связь, 1988.

10. Технология системного моделирования/Под ред. С.В. Емельянова, В.В. Калашникова и др. М.: Машиностроение; Берлин: Техник, 1988.

11. Советов Б.Я., Яковлев С.А. Моделирование систем. 2-е издание, перераб. и доп. М.: Высшая школа, 1998.

12. Бережной Г. Проблемы создания больших информационных систем. Мир ПК, август, 1998.

13. Шварц М. Сети ЭВМ. Анализ и проектирование/ Пер. с англ.; Под ред. В.А. Жожикашвили. М.: Радио и связь, 1981.

14. Фредерик В. Шолл. Азбука планирования нагрузки LAN// Журнал сетевых решений. № 08.96.

15. Рувинская В.М., Шапорин Р.О. Инженерный опыт использования современных систем моделирования для анализа вычислительных сетей// Открытые системы, 1999, №1.

16. Коуд П., Норт Д., Мейфилд М. Объектные модели: стратегии, шаблоны, приложения. М.: Изд-во ЛОРИ, 1999.

17. Ферапонтов М.М., Крицына Н.В., Деев Д.Л. Моделирование случайных воздействий на ЭВМ. М.: МИФИ, 1995.

18. Новицкий П.В., Зограф И.А. Оценка погрешностей результатов измерений. Л.: Энергоатомиздат, 1991.

63