Метод сквозного структурного контроля
Основная идея сквозного структурного контроля — регулярная взаимная проверка программных модулей на этапе программирования. Такой контроль необходим для обнаружения и исправления ошибок как можно раньше, пока стоимость исправления ошибок минимальна. При отладки написанных программ важно тщательно провести тестирование программного продукта. Цель тестирования состоит в том, чтобы убедиться, что программа решает действительно ту задачу, для которой предназначена, и выдает правильный результат при любых условиях.
6.5.2. Встроенный отладчик интегрированной среды разработки Microsoft Visual C++ 6.0
Встроенный отладчик предоставляет следующие возможности:
Возможность пошагового исполнения программы,
Возможность установки брейкпоинтов (точек останова программы) в необходимых местах,
Возможность просмотра и изменения значений переменных,
Возможность приостановки и запуска процессов и др.
С его помощью отслеживалась правильность выполнения различных функций в составе ПО, вложенных вызовов, достоверность передачи информации внутри сложных функций, правильность преобразования типов и т.п. Встроенный отладчик использовался на промежуточных этапах разработки ПО, главным образом для отладки отдельных модулей в составе модели ВС.
6.5.3. Встроенный отладчик интегрированной среды разработки Code Composer 3.0
Встроенный отладчик предоставляет следующие возможности:
Возможность пошагового исполнения программы,
Возможность установки брейкпоинтов;
просмотр состояния процессора (содержимое регистров и флагов, сегменты кода и данных);
просмотр значений локальных и глобальных переменных;
просмотр содержимого стека и истории вызовов;
возможность подключения в ключевых точках программы ввода-вывода с помощью текстовых файлов, таким образом симулируется трансфер данных через память процессора;
возможность подключения графического аппарата, представленного 4-мя различными вариантами диаграмм для построения графиков различной сложности и отслеживания сигналов реального времени;
наличие профайлера, позволяющего производить замер производительности процессора на критических участках кода и др.
С его помощью отслеживалась правильность выполнения модулей ОСРВ, переносимых на платформу TMS320C30, и процедуры аппаратно-зависимой диагностики.
Отладочная программа была написана для проверки работы модулей, обеспечивающих системе свойства отказоустойчивости, в комплексной форме, то есть при одновременной параллельной работе нескольких ПЭ вычислительной системы.
С помощью отладочной программы проводилось следующее тестирование:
проверка правильности реакции системы на отказ или сбой каналов связи;
проверка правильности реакции системы на отказ или сбой ПЭ;
проверка правильности перестройки (реконфигурации) системы после отказа;
проверка правильности выдаваемых системой результатов в условиях постоянной деградации системы.
6.5.5. Отладка и тестирование модулей ОСРВ
На первом этапе для всех модулей тестировались все разветвления на графе управления программой как с помощью встроенного отладчика (правильная обработка всех команд), так и стохастически, то есть с помощью генерации различной последовательности входных данных, и проверки результатов сравнением с эталонными значениями. Далее проверка производилась комплексно, исследовалась реакция и взаимодействие модулей.
Приведем описание процесса тестирования для некоторых модулей.
Модуль маршрутизации: Отладка и тестирование этого модуля проводилась сначала с помощью отладчика, на вход подавалась простейшая топология сети, при этом отслеживалось правильное выполнение статических команд и команд перехода и ветвления. После получения удовлетворительных результатов, тестирование продолжалось стохастически, проверкой модуля на различных входных топологиях. Дальнейшее тестирование проводилось комплексно, с подключением модуля реконфигурации.
Модуль реконфигурации: Проверка выполнения всех ветвей проводилась с помощью отладчика, на вход алгоритма подавались нужные значения и с помощью трассировки проверялась правильность выбора и выполнения нужной ветви. Дальнейшая стохастическая отладка модуля проводилась как с использованием отладчика, так и отладочной программы, с помощью генерации различного рода информации об отказах и проверкой результатов работы данного модуля сравнением с ожидаемым результатом.
Отладка и тестирование других модулей проводилась по той же схеме, причем особое внимание уделялось комплексной отладке программы.
Комплексная отладка модулей проводилась организацией взаимодействия модулей в соответствии с логикой работы ВС, отслеживались данные межзадачного взаимодействия, синхронизация, и последовательность действий с помощью специально вводимых текстовых сообщений в ключевых узлах программ.
1. Затуливетер Ю.С. Введение в проблему параметризованного синтеза программ для параллельных компьютеров. -М., 1993 (Препринт/Институт проблем управления).
2. Харченко В.С., Лысенко И.В., Мельников В.А. Оценка и обеспечение живучести информационно-вычислительных и управляющих систем технических комплексов критического использования. Зарубежная радиоэлектроника. 1996. №1.
3. Э.В. Евреинов. Однородные вычислительные системы и среды. –М. Радио и связь, 1981.
4. А. Вильямс. Системное программирование в Windows 2000. –СПб. Питер, 2001.
5. С. Кейслер. Проектирование операционных систем для малых ЭВМ,-М., Мир, 1986.
6. А. Шоу. Логическое проектирование операционных систем.-М.,Мир, 1981.
7. К.А. Иыуду, С.А. Кривощеков, Математические модели отказоустойчивых ВС. –М., МАИ, 1989.
8. К.А. Иыуду. Надежность, контроль и диагностика вычислительных машин и систем. -М., Высшая школа,1989.
9. Л.П. Глазунов и др. Основы теории надежности автоматических систем управления. -М.,Энергоатомиздат, 1984.
10. Р.Л. Лонер, Г.Н. Уилкинсон, Устойчивые статистические методы оценки данных: Москва, Машиностроение, 1984
11. Артамонов Г.Т., Тюрин В.Д. Топология сетей ЭВМ и многопроцессорных систем. — М.: Радио и связь, 1991.
12. Е.С. Вентцель, Теория вероятностей. М. НАУКА, 1969.
13. В.Н. Агафонов. Спецификация программ. –М., Наука, 1987.
14. А. Мешков, Ю. Тихомиров. Visual C++ и MFC. –СПб. БХВ-Санкт-Петербург, 2001.
15. Л.Б. Богуславский. Управление потоками данных в сетях ЭВМ. -М., Энергоатомиздат, 1984.
16. В.И. Матов и др. Теория проектирования вычислительных машин систем и сетей. –М., МАИ, 1999.
17. В.В. Липаев. Надежность программного обеспечения АСУ. -М., Энергоиздат, 1981.
17. Д.И. Козлов и др., Управление космическими аппаратами зондирования земли. – М.: Машиностроение, 1998.
18. Б. Страуструп. Язык программирования С++. – Киев. ДиаСофт, 1993.
19. А.Г. Додонов и др. Введение в теорию живучести вычислительных систем. – Киев, Наук. Думка, 1990.
20. Э.М. Мамедли, Р.Я. Самедов, Методы восстановления вычислительного процесса в отказоустойчивых цифровых систем управления реального времени, Препринт Института Проблем Управления Российской Академии Наук, Москва, 1998.
21. Гуляев В.А., Додонов А.Г. , Пелехов С.Л. Организация живучих вычислительных структур.- Киев.: Наукова Думка , 1987
22. Гришин Ю.П., Казаринов Ю.М. Динамические системы, устойчивые к отказам.- М.: Радио и связь, 1985.
23. Транспьютеры. Архитектура и программное обеспечение: Пер. с англ. Под ред. Г.Харпа.-М.: Радио и связь, 1993
24. TMS320C3x User’s Guide, Texas Instruments, Inc., Dallas, Texas, 1994
25. Дейтел Г., Введение в операционные системы. М, Мир, 1987.
26. Дансмур М., Дейвис Г. Операционная система UNIX и программирование на языке Си. М. «Радио и связь». 1989.
27. К.Ю. Богачев. Операционные системы реального времени. М. 2001.
28. Артамонов Г.Т. Топология регулярных вычислительных сетей и сред. — М.: Радио и связь, 1985.
29. Мартин Дж. Программирование для вычислительных систем реального времени. – М.: Наука, 1975.
Экономическое обоснование дипломных проектов. Методическое пособие. –М., МАИ, 1991.
Руководство Р2.2.013-94 Гигиенические критерии оценки условий труда по показателям вредности и опасности факторов производственной среды, тяжести и напряженности трудового процесса.
Юдин Е.Я., Белов С.В. и др. Охрана труда в машиностроении. М.: Машиностроение, 1983, 432с.
ГОСТ 27954 — 88 Видеомониторы персональных электронных вычислительных машины. Типы, основные параметры, общие технические требования.
СаНПин 2.2.2.542-96. Гигиенические требования к видеодисплейным терминалам (ВДТ). персональным электронно-вычислительным машинам (ПЭВМ) и организации работы. М.: Информационно-издательский центр Госкомэпиднадзора России, 1996. 65 с.
ГОСТ 12.1.006 — 84 Электромагнитные поля радиочастот. Допустимые уровни на рабочих местах и требования к проведению контроля. Изменение к ГОСТ.
ГОСТ 12.1.005-88. Воздух рабочей зоны. Общие санитарно — гигиенические требования. М.: Изд-во стандартов, 1990. 14 с.
СНиП 23-05-95 Естественное и искусственное освещение.
7. Сквозной структурный контроль
Сквозной структурный контроль представляет собой совокупность технологических операций контроля, позволяющих обеспечить как можно более раннее обнаружение ошибок в процессе разработки. Термин «сквозной в названии отражает выполнение контроля на всех этапах разработки. Термин «структурный» означает наличие четких рекомендаций по выполнена контролирующих операций на каждом этапе. Сквозной структурный контроль должен выполняться на специальных контрольных сессиях, в которых, помимо разработчиков, могут участвовал специально приглашенные эксперты. Время между сессиями определяет объем материала, который выносится на сессию: при частых сессиях материал рассматривают небольшими порциями, при редких — существенным фрагментами.
Материалы для очередной сессии должны выдаваться участникам заранее, чтобы они могли их обдумать.
Одна из первых сессий должна быть организована на этапе определения спецификаций. На этой сессии проверяют полноту и точность спецификаций, при этом целесообразно присутствие заказчика или специалиста по предметной области, которые смогут определить, насколько правильно полно определены спецификации программного обеспечения.
На этапе проектирования вручную по частям проверяют алгоритмы разрабатываемого программного обеспечения на конкретных наборах данных и сверяют полученные результаты с соответствующими спецификациями. Основная задача — убедиться в правильности понимания спецификаций и проанализировать достоинства и недостатки концептуальных решений, закладываемых в проект.
На этапе реализации проверяют план (последовательность) реализации модулей, набор тестов, а также тексты отдельных модулей.
Для всех этапов целесообразно иметь списки наиболее часто встречающихся ошибок, которые формируют по литературным источникам и исходя из опыта предыдущих разработок. Такие списки позволяют сконцентрировать усилия на конкретных моментах, а не проверять все подряд. При этом все найденные ошибки фиксируют в специальном документе, но не исправляют их.
Помимо раннего обнаружения ошибок, сквозной структурный контроль обеспечивает своевременную подготовку качественной документации по проекту.
Контрольные вопросы
1.Что понимают под технологичностью программного обеспечения? Почему?
2.Дайте определение модуля. Чем вызвано изменение этого понятия? Как изменились требования к модулям в настоящее время и почему?
3.Что понимают под связностью и сцеплением модулей? Какие типы связности и сцепления считаются допустимыми и почему? В чем особенность библиотек ресурсов?
4.Чем нисходящий подход к разработке отличается от восходящего? Перечислите достоинства и недостатки этих подходов?
5.Что называют структурным программированием и почему? Назовите основные и дополнительные структуры. Объясните, в чем сложность использования схем алгоритмов при проектировании структурных программ? Какие способы описания структурных алгоритмов существуют?
6.От каких ошибок защищает «программирование с защитой от ошибок» и почему? Что понимают под термином «исключение»? В каких случаях «исключения» используют?
7.Почему «сквозной структурный контроль» так назван? Что значит «сквозной» контроль? В чем заключается его «структурность»?