CC BY
69
S. A. Yareschenko
SYSTEM CONNECTIONS ANALYSIS OF SUBWAYS BASIC TECHNICAL AND ECONOMICAL INDEXES
The system connections analysis method of subway quality exploiting indexes with the aim to ensure scientifically grounded power saving graphic of Krasnoyarsk future subway traffic.
УЦК 629.78.051:681.3
А. В. Еремин, О. С. Иноземцева, А. А. Колташев, К. А. Кондратьев, К. Г. Львов
СРЕДСТВА ИЗМЕРЕНИЯ БОРТОВОГО ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
Рассмотрены средства измерения бортового программного обеспечения (БПО), являющиеся частью технологии разработки и верификации БПО спутников связи и навигации и предназначенные для повышения качества и надежности бортовых программ.
Создание качественного и надежного бортового программного обеспечения (БПО) спутников связи и навигации всегда было и остается актуальной технологической задачей. Цействующая в ФГУП «Научно-производственное объединение прикладной механики имени академика М. Ф. Решетнева» (НПО ПМ) технология разработки и верификации бортового программного обеспечения описана в [1; 2]. Частью этой технологии являются средства измерения программ БПО, применяемые для повышения качества и надежности бортовых программ.
Средства измерения программ БПО встроены в кросссистему его программирования и применяются для бортовых компьютеров трех вычислительных платформ: С-32 (архитектура УАХ 11/750), ОВС-1750 (архитектура MIL-STD-1750А) и БИВК (архитектура MIPS-Ш). Эти средства позволяют получить набор мер сложности исходного текста, эксплуатационные характеристики программы, выполнить профилирование, определить уровень тестирования программы, проверить выполнение проектных соглашений.
Средства измерения решают следующие функциональные задачи:
1) измерения исходного текста модулей с получением набора мер сложности бортовой программы на языке Модула-2 [3];
2) получение оценочных формул, величин стека и времен исполнения бортовых программ в пакетном режиме тестирования, а также итогового отчета по стеку и временами исполнения бортовых программ;
3) получение отчета по объемам памяти бортовой программы;
4) построение процедурных профилей, построчных профилей, профилирование переменных бортовых программ:
- в пакетном режиме отладки: для всего пакета тестирования, для каждого варианта пакета тестирования, для каждого варианта пакета тестирования с сохранением истории предыдущих вариантов;
- в диалоговом режиме отладки.
Профили предоставляются для просмотра как в текстовом виде, так и в графических окнах в виде круговых и линейных гистограмм;
5) получение полноты тестирования бортовой программы по критериям С1и С, создание html-отчетов о полноте тестирования, с просмотром через Internet Explorer;
6) проверка проектных соглашений с генерацией итогового html-отчета со ссылками на другие html-отчеты средств измерения и просмотр html-отчетов в Internet Explorer.
Средства измерения состоят из набора компонентов, интегрированных оболочкой средств измерения, которая запускается через меню кросс-системы программирования, предназначенной для разработки БПО.
Набор компонентов средств измерения включает следующие элементы:
- интегрирующую оболочку средств измерения ОСИ-М;
- метрический компилятор;
- профилировщик, встроенный в систему тестирования и отладки и работающий в двух режимах - пакетном и диалоговом;
- инструментирующий кросс-компилятор;
- генератор отчетов о полноте тестирования;
- компоненты контроля выполнения проектных соглашений (КВПС): программу проверки комментариев и версий модулей; программу проверки структуры проекта; проверку уровня тестирования; проверку мер на критерии; создание отчета по временам и стекам; создание отчета по характеристикам памяти.
Кроме перечисленных выше компонентов, средства измерения используют компилятор и компоновщик из кросс-системы программирования Модула-2 для перекомпилирования программы БПО перед получением эксплуатационных характеристик программы или профилированием.
Компоненты контроля тестирования, метрический компилятор и профилировщик разработаны ООО «Эк-сельсиор» (Новосибирск) на основе работы [3], выпол-
ненной в Институте систем информатики Сибирского отделения Российской академии наук. Оболочка средств измерения ОСИ-М, компоненты КВПС, создание отчетов по временам, стекам и характеристикам памяти разработаны в НПО ПМ.
Оболочка средств измерения. Оболочка средств измерения ОСИ-М имеет меню команд для выполнения функциональных задач средств измерения и просмотра результатов. Выполнение одной функциональной задачи измерения обеспечивается последовательным исполнением нескольких дочерних процессов (компонентов) с ожиданием их завершения. ОСИ-М подготавливает входные данные для компонентов, контролирует успешность завершения процессов и получение результатов и представляет результаты для просмотра.
Меры сложности исходного текста программ. В [3] были определены наборы мер для языков программирования Модула-2 и разработана первая версия метрического компилятора. В набор мер Модула-2 включены меры длины, меры описания и использования объектов, использований внешних объектов, меры сложности МакКейба, меры вложенности, меры комментируемости. Определены наборы мер: для модулей реализации -21 мера, для процедур - 27 мер, для инициализирующей части - 22 меры. Позднее был добавлен небольшой набор из шести мер для модулей определений.
Правильное определение величин простых и комплексных критериев мер сталкивается с трудностями, связанными со статистическими исследованиями характеристик программ в процессе разработки, прогнозированием остаточного числа ошибок при передаче программы в эксплуатацию, экспертными оценками. Определенная работа в этом направлении уже проведена, и сообщения о неудовлетворении мер критериям сложности, поступающие в средства измерения, носят рекомендательный характер.
Оценки времени и стека. Оценки времени и стека программы важны для организации вычислительного процесса операционной системой бортового компьютера. Разработка модулей бортовых программ ведется разными программистами параллельно, и часть вызываемых программных компонентов моделируется. Профилировщик строит формулы для оценки времен и стеков программы при условии, что времена и стеки моделируемых компонентов не известны либо оценены некоторыми величинами, указанными в конфигурационной таблице. Время и стек оцениваются профилировщиком в пакетном режиме тестирования. Оценочные формулы и значения получаются для каждого варианта тестирования, и в конце пакета подводится итог, в котором выбирается максимальное и минимальное время исполнения и максимальный стек программы, и приводится соответствующая оценочная формула.
Оценочная формула стека представляет собой максимум из списка элементов вида
Оценочная формула времени представляет собой формулу для варианта тестирования:
(2)
S = max
S0 S1
прог5 прог
Si + Si Sn + Sn
прог мод ’ ■ ■ ' ’ прог мод
(1)
где £'рог - стек программы в г-й точке экстремума стека для исполнения ветви программы, оканчивающейся вызовом г-й модели; ^ - стек г-го моделируемого компонента.
где T0 - время исполнения программы без учета моделей; гмод - время исполнения i-го моделируемого компонента; N - число вызовов i-й модели.
Одна бортовая программа может иметь много пакетов тестирования. Для облегчения задачи выбора оценочных формул и приведения их в сопроводительной документации была разработана программа «Время-стек», которая формирует в итоговый отчет в Microsoft Word с таблицей оценочных формул стеков и времен программы БПО. Входными данными для программы «Время-стек» являются протоколы профилировщика всех пакетов тестирования. Программа «Время-стек» строит итоговую формулу (1) по всем протоколам профилировщика от исполнения разных пакетов тестирования и формирует таблицу времен, которая содержит формулы (2) и значение времени для вариантов из всех протоколов тестирования. Таблица времен сортирована по оценочному значению времени.
Характеристики памяти. Объемы памяти программы необходимы для распределения и подтверждения использования ресурсов бортового компьютера, они приведены в документации на программу БПО. Данные о размещении программы в памяти сохраняются компоновщиком в выходном файле карты памяти. С целью автоматизации подсчета объемов памяти для секций кода и данных разработана программа «Характеристики памяти», которая в Microsoft Word по файлу карты памяти формирует таблицу объемов памяти бортовой программы, готовую для представления в документе на программу.
Профилирование. Профилировщик средств измерения встроен в систему тестирования и отладки (отладчик), собран с отладчиком в один исполнимый файл, который применяется только в средствах измерения. Отладчик, используемый отдельно в кросс-системе программирования, собран без функций профилирования.
Встроенный профилировщик работает как в режиме пакетного тестирования, так и в режиме диалогового тестирования. В язык пакетной отладки добавлены операторы начала профилирования с заданием его режимов, конца профилирования, чтения и сохранения файла профиля. В диалоговом режиме отладчика добавлено меню команд профилирования. Профилировщик позволяет строить динамический построчный профиль модулей или фрагментов программы, получить процедурный профиль (времена исполнения процедур с вызовами, без вызовов, максимальное, минимальное, в процентах), выполнить профилирование переменных (получить число чтений, число изменений в глобальных переменных).
Отладчик построен на основе программного интерпретатора команд бортового компьютера [4]. Подсчет времени выполняется профилировщиком с получением от интерпретатора времен исполнения машинных команд бортового компьютера, которое задается в файле конфигурации интерпретатора, составляемого по результатам испытаний бортовой вычислительной машины.
i=1
Определенную трудность представляет вычисление времени исполнения одной строки на языке Модула-2 в режиме оптимизации, потому что компилятор оптимизирует программу таким образом, что однозначно сопоставить машинный код бортового компьютера строкам исходного текста программы можно далеко не всегда. Профилировщик может вычислить время исполнения строки не для всех строк оптимизированной программы Модула-2, но время исполнения всей процедуры всегда вычисляется точно. Однако именно построчные профили весьма наглядно отражают динамику вычислительного процесса.
Профилировщик сохраняет результаты профилирования в текстовых файлах профилей.
Оболочка ОСИ-М в режиме профилирования выполняет препроцессорную обработку пакетов тестирования, которая заключается в добавлении операторов профилирования в пакет, и представляет профили в графическом виде.
Профилировщик применяется для выявления проблемных мест при оптимизации по времени исполнения бортовой программы.
Полнота тестирования. В средствах измерения применяются методы определения полноты тестирования программы по критериям С1 и С:
- покрытие по критерию С1 определяется как обязательное прохождение всех веток управляющего графа программы не менее 1 раза;
- покрытие по критерию С есть покрытие по критерию С1, дополненное проверкой исполнения условий и подусловий в логических выражениях, исполнения циклов 1 раз, более 1 раза и 0 раз, проверкой рекурсивных вызовов процедур.
Проверка полноты тестирования обеспечивается инструментированием бортовой программы так, что в соответствующих местах программы автоматически вставляются вызовы процедур, выполняющих регистрацию выполнения тестового условия, например прохождение данной ветки программы. Информация о прохождении тестовых условий сохраняется в файле во время исполнения тестируемой программы. После окончания тестирования создается отчет о полноте тестирования, содержащий итоговые проценты полноты покрытия тестами программы по критериям С1и С и подробную информацию об исполнении различных участков тестируемой программы.
Первоначально была разработана система ОСТ [3], в которой инструментирование выполнялось на уровне исходного текста программы. Отчет о полноте тестирования сохранялся в виде текстового файла, содержащего исходный текст программы, дополненный сообщениями о невыполнении тестовых условий и количестве выполненных тестовых условий, однако чтение отчета по тестированию для неопытного пользователя было затруднено. Система ОСТ была внедрена в НПО ПМ в составе средств измерения и несколько лет эффективно использовалась для повышения уровня тестирования бортовых программ для компьютеров типа С-32и OBC-1750.
В настоящее время система ОСТ заменена более совершенной системой Test Coverage System (TCS), разработанной ООО «Эксельсиор». В этой системе инструментирование выполняется инструментирующим компилятором на уровне генерации кода, а отчеты о полноте тестирования создаются в виде html-файлов, удобных для просмотра и понятных даже неопытному пользователю (рис. 1).
Отчет о покрытии тестами: MUSrFile.mod
Покрытие модуля
Критерий Покрыто Всего Соотношение
С1 8 10 80%
С 18 23 78.26%
Легенда
- покрытый код
- код, не покрытый по критерию С
- код, не покрытый по критерию С1
- код, не покрытый по критериям С и С1
Покрытие по процедурам
Строка Процедура C1 С
50 WrFrazaVD 1 0/1 0.00% 0/1 0.00%
62 Read 4/4 100.00% 11/12 91.67%
75 Read FDesk 3/4 75.00% 3/5 60.00%
92 Check File 1/1 100.00% 4/5 80.00%
BEGIN
69 IE ((n=0) AND (2P0 IN TM)) OR
((n—1) AND (ZP1 IN TM)) THEM
RETURN (FALSE);
72 END;
73 RETURN RdVZU(n,vzu_a
74 END Read;
75 PROCEDURE Read_FDesk (
76 n FileName
78 VAR FDesk : FileD;
7 9 NumFunc : CARD16
8 0 ):BOOLEAN;
81 VAR
70 С: Выражение было FALSE 1 раз
70 С: Выражение ни разу не было TRUE
69 С1 Условие IF было FALSE 2 раза
69 С1 Условие IF было TRUE 1 раз
62 С1 Процедура ReadQ вызывалась 3 раза
Рис. 1. Пример отчета системы TCS о полноте тестирования
Система контроля полноты тестирования зарекомендовала себя очень эффективным средством повышения уровня отлаженности бортовых программ, тестируемых в пакетном режиме. Кроме того, при достижении максимального покрытия по критерию С1 выявляются участки программы с избыточным кодом, которые ни при каких условиях не могут быть покрыты. Это указывает программисту на необходимость оптимизации своей программы, что способствует к экономии ресурсов бортового компьютера.
Контроль выполнения проектных соглашений. Под
проектными соглашениями понимается заданная структура проекта программы, оформление стандартных блоков комментариев, поддержка версии и истории изменений модулей, уровень покрытия тестирования и граничные значения мер сложности исходного текста программ.
Компоненты КВПС выполняют следующие задачи:
- контроль структуры проекта;
- проверку стандартных комментариев и версий модулей проекта программы;
- проверку уровня тестирования на достижение максимальной границы;
- проверку мер сложности на простые и комплексные критерии.
Программа «Контроль структуры проекта» проверяет структуру и состав папки проекта программы БПО на наличие заданных поддиректорий и файлов. Условия для проверки задаются в файле конфигурации проверок.
Программа «Проверка модулей проекта программы» проверяет наличие и состав обязательных блоков ком-
ментариев для модуля и процедур, наличие комментариев к параметрам и возвращаемому значению процедуры, историю изменений в блоке комментариев, версию модуля. Программа создает Ыт1-отчеты с сообщениями
об ошибках, в которых помечает узнанные блоки комментариев и ключевые слова по аналогии с отчетами системы ТС^ (рис. 2).
Программа «Контроль тестирования» проверяет наличие Ьт1-отчетов системы TCS, их соответствие текущим модулям проекта, достижение 100%-го покрытия по критерию С1и некоторой установленной границы по критерию С. Программа создает Ьт1-отчет с сообщениями об ошибках.
Проверка мер сложности на критерии выполняется оболочкой ОСИ-М. Условия для проверки задаются в файле конфигурации критериев мер сложности как в виде минимальных и максимальных границ для простой меры, так и в виде формулы для вычисления комплексной меры и границ комплексной меры. По результатам этой проверки создается Ьт1-отчет с сообщениями о выходе за границы критериев.
Результатом контроля выполнения проектных соглашений является итоговый Ьт1-отчет об успешности выполнения проектных соглашений с гиперссылками на все Ьт1-отчеты, полученные средствами измерения.
В заключение отметим, что средства измерения применяются в разработке бортового программного обеспечения спутников связи и навигации, в том числе «ГЛОНАСС-М», «Экспресс-АМ» и др. Эти средства обеспечивают стандартизацию проекта программы, сниже-
Модуль bku_dtvi.def Вер. Error!.
Всего ошибок: 1;
из них в заголовках: О в версии:1
Легенда
- правильный заголовок
- ошибка в строке заголовка
- ошибка в слове заголовка
Заголовки модуля и процедур
Строка Тип заголовка Имя компоненты Имя мод./проц. Число ошибок
5 Модуль Программа ФОНОВЫЙ ТЕСТ ВИ БИВК-Э BKU dTVI 0
Исходный текст
1 <* version=тver. 9.0
2 <* +ui2extensions *>
3 <* + nomodule in it
*>
ОШ: Версия в опции Version=,ver.9.0‘ не соответсвует версии '1.0' в истории изменений модуля
5 DEFINITION MODULE BKUdTVI;
6
* ПО БКУ
* Программа ФОНОВЫЙ ТЕСТ ВИ БИВК-Э
* Входные данные программы.
темы БИВК-Э
* Содержит константы, инициализированные переменные.
■к_____________________________________________________________
* Версия 1.0 27.08.07 Клюкина JI.B.
13
14 FROM SYSTEM IMPORT CARD8, ADR, ADDRESS, CARD16, CARD32, CARD64, CAST,
15 SET 8, SET 16;
16 FROM BKU_oTVI IMPORT OzuTVI;
17 (*----------------------------------------------------------------------------------
18 ОПИСАНИЕ ИМПОРТА
19 ---------------------------------------------------------------------------------*)
20 FROM BKU_TVI1 IMPORT TestVCPZU; (* ЧТ ВЦПЗУ *)
21 FROM BKU TVI2 IMPORT TestVCOZU; f* ЧТ ВП03У *1
Рис. 2. Примет отчета программы «Проверка модулей проекта программы»
ние избыточной сложности исходного текста, повышение показателей комментируемости, что приводит к улучшению взаимозаменяемости программистов в процессе подготовки программ БПО.
Наиболее значимым результатом применения средств измерения является повышение качества тестирования программ: обеспечивается 100%-е покрытие тестами программ БПО по критерию С1 и приближение к максимально достижимой величине покрытия тестами по критерию С.
Библиографический список
1. Колташев, А. А. Технологические аспекты создания бортового программного обеспечения спутников связи / А. А. Колташев, А. Н. Антамошкин // Вестн. Сиб. гос. аэрокосмич. ун-та им. акад. М. Ф. Решетнева : сб. науч.
тр. / Сиб. гос. аэрокосмич. ун-т. Вып. 6. Красноярск, 2005. С. 93-95.
2. Технология разработки и верификации компонентов бортового программного обеспечения спутников связи и навигации / О.С. Иноземцева, Л.В. Клюкина, А. А. Колташев [и др.] // Материалы: Всерос. науч.-практ. конф., 10-14 окт. 2007, г. Железногорск / Сиб. гос. аэрокосмический ун-т. Красноярск, 2007. С. 165-167.
3. Черноножкин, С. К. Методы и инструменты метрической поддержки разработки качественных программ [Электронный ресурс] : автореф. дис. ... канд. физ.-мат. наук / С. К. Черноножкин. Электрон. дан. Режим доступа: http:/ www.uran.donetsk.ua/~masters/2004/kita/ukrainsky/ library/consist.htm. Загл. с экрана.
4. Еремин, А. В. Архитектура настраиваемой среды отладки / А. В. Еремин // Проблемы программирования. Киев, 2000.
A. V. Yeryomin, O. S. Inozemtseva, A. A. Koltashev, K. A. Kondratev, K. G. Lvov MEASUREMENT TOOLS FOR THE ON-BOARD SOFTWARE
Considered in this article the measurement tools are a part of the on-board software design and verification technology for the communication and navigation satellites and intend to improve quality and reliability of the on-board programs.
УЦК 004.056.53
А. М. Кукарцев, И. А. Лубкин
МЕТОДИКА ЗАЩИТЫ ПРОГРАММНОГО КОДА ОТ НЕСАНКЦИОНИРОВАННОЙ МОДИФИКАЦИИ И ИССЛЕДОВАНИЯ ПОСРЕДСТВОМ ЕГО ХЕШИРОВАНИЯ
Рассмотрено использование самомодифицирующихся кодов для защиты программ от несанкционированной модификации. Предложена новая система защиты, в которой в качестве средств контроля целостности используются хеш-функции.
В современном мире большую актуальность получила проблема защиты авторских прав. В сети Интернет можно найти множество так называемых «взломанных» программ. Большая часть из них является программами с отключенной или модифицированной системой защиты (СЗ). И это связано с тем, что большинство систем защиты от несанкционированного использования уязвимы к отключению посредством модификации, поскольку любая программа (в том числе и с установленной системой защиты) должна выполняться на центральном процессоре ЭВМ, а исполнимый код программы на момент выполнения должен существовать в оперативном запоминающем устройстве (ОЗУ) в открытом, пригодном для исполнения виде. Все это и создает основную проблему при построении системы защиты программ от модификации.
Изучение набора существующих средств защиты от модификации показало, что подавляющее большинство решений основано на техническом аспекте преодоления такой защиты. В случае решения технической проблемы или
раскрытия принципа работы, на котором основана система защиты, появляется возможность ее быстрого преодоления.
Авторами была создана методика защиты программного кода, основанная на использовании хеш-функции для контроля целостности. Предлагаемая система защиты основана на решении как алгоритмической, так и технической проблемы, что увеличивает ресурсы, затрачиваемые на ее деактивацию.
Система защиты от модификации должна обладать следующими свойствами:
- защитой программы от модификации до и после загрузки в ОЗУ;
- распределенностью кода, реализующего защиту, по программе, что усложняет процесс его обнаружения и удаления;
- неотделимостью кода, реализующего защиту, от защищаемой программы;
- сокрытием логики работы программы;
- алгоритмической сложностью задачи деактивации системы;
