TMPA-2013 Conference Proceedings

Министерство образования и науки РФ
Костромской государственный технологический университет
Санкт-Петербургский государственный политехнический университет
Российская академия наук
Институт проблем информатики
ООО «Инновационные Трейдинговые Системы»

ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
TOOLS & METHODS OF PROGRAM ANALYSIS
TMPA-2013
Материалы
Международной научно-практической конференции
10—12 октября 2013

Кострома

2013

УДК 004.413.5
И726
Печатается по решению научно-технического совета КГТУ
Редакционная коллегия:
Председатель: Киселев М.В.
Члены редколлегии:
Захаров В.Н., Ицыксон В.М.,

Лустгартен Ю.Л., Иткин И.Л.,

Ходченко А.С., Загоруйко К.В.,
Аввакумова Е.С., Зверев А.В.,
Рудовский П.Н

И726 Инструменты и методы анализа программ Tools & Methods
of Program Analysis TMPA-2013: материалы Международной науч.практ. конф.- Кострома: Из-во Костромского гос. технол. ун-та, 2013.
- 348 с.
ISBN 978-5-8285-0666-8
В сборнике публикуются доклады участников Международной
научно-практической конференции «Инструменты и методы
анализа программ / Tools & Methods of Program Analysis (TMPA2013)», состоявшейся 10-12 октября 2013 г.
в Костромском
государственном технологическом университете.
Для широкого круга читателей.

ISBN 978-5-8285-0666-8

16+

УДК 004.413.5
© Костромской государственный
технологический университет, 2013

Содержание:
ВЕРИФИКАЦИЯ:
• Пакулин Н.

Динамическая верификация гибридных систем

19

Институт системного программирования РАН

• Подымов В., Попеско У.

36

Верификация программно-конфигурируемых сетей при помощи
системы UPPAAL
МГУ имени М.В. Ломоносова

• Кузьмин Е., Рябухин Д., Шипов А.

Построение и верификация ПЛК-программ по LTL-спецификации

48

Ярославский государственный университет им. П.Г. Демидова

• Ануреев И.

На пути к технологии разработки стредств дедуктивной
верификации программ

66

Институт систем информатики имени А.П. Ершова

• Лукин М., Шалыто А.

Верификация распределенных автоматных программ с
использованием инструментального средства Spin

78

СПб НИУ ИТМО

АППАРАТНЫЙ ТРЕК:
• Иванников В., Камкин А., Чупилко М.

Проверка корректности поведения HDL-моделей цифровой
аппаратуры на основе динамического сопоставления трасс

94

Институт системного программирования Российской академии наук
(ИСП РАН)

• Шипин А., Соколов В., Чалый Д.

Использование контрольных точек для верификации SystemCпрограмм

106

Ярославский государственный университет

6

Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ

• Френкель С., Захаров В., Ушаков В.

Унифицированная высокоуровневая модель программноаппаратной системы для верификации свойств надежности
функционирования

118

Институт проблем информатики РАН, Московский гос. университет
им. М.В. Ломоносова

• Смирнов М., Олоничев В., Староверов Б.

Особенности разработки программного обеспечения для Linuxконтроллеров

130


ТЕСТИРОВАНИЕ:
• Басок Б., Гречин А.

Об усовершенствовании статистического метода оценки полноты
тестов программ и устройств

138

Московский государственный технический университет радиотехники,
электроники и автоматики

• Сартаков В., Тарасиков А.

Анализ производительности сетевой подсистемы микроядерного
окружения Genode

146

ksys labs

• Журавлев М., Полозов В.

Подход к верификации корректности миграции данных между СУБД
с использованием криптографических хэш-функций

158

Санкт-Петербургский Государственный Университет

• Никешин А., Пакулин Н., Шнитман В.

Автоматизация тестирования соответствия протокола безопасности
транспортного уровня TLS

167

Институт системного программирования РАН


7

• Сенов А.

Применение технологий OLAP и MapReduce для обработки
результатов нагрузочного тестирования

179


ТРЕЙДИНГОВЫЕ СИСТЕМЫ:
• Матвеева А., Антонов Н., Иткин И.

Особенности инструментов для тестирования, применимых при
промышленной эксплуатации трейдинговых систем

191

ООО «Инновационные Трейдинговые Системы», Костромской
государственный технологический университет, Exactpro Systems LLC

• Алексеенко А., Проценко П., Матвеева А., Иткин И.,
Шаров Д.

203

Тестирование совместимости протокольных подключений клиентов
биржевых и брокерских систем
ООО «Инновационные Трейдинговые Системы»,
Exactpro Systems LLC

• Буянова О., Булда А, Зверев А.

Применение симуляторов рынка ценных бумаг для тестирования
систем агрегации и распределения информации о котировках
(Ticker Plant)

215

ООО «Инновационные Трейдинговые Системы»,
Костромской государственный технологический университет,
Exactpro Systems LLC

• Гурьев Д., Гай М., Иткин И., Терентьев А.

Высокопроизводительный генератор нагрузки для тестирования
систем автоматизированной торговли

242

ООО «Инновационные Трейдинговые Системы», Саратовский
государственный технический университет имени Гагарина Ю.А.

8


• Прядкина Н., Крюков А.

Использование MBT-подхода для верификации систем мониторинга
и контроля на фондовых биржах

254


• Бобров И., Зверев А.

Тестирование графического интерфейса трейдинговых терминалов
в условиях высокочастотной торговли

264

ООО «Инновационные Трейдинговые Системы»

АНАЛИЗ ПРОГРАММ:
• Цителов Д., Трифанов В.

Динамический поиск гонок в Java-программах на основе
синхронизационных контрактов

273

Devexperts LLC, СПбГУ

• Верт Т., Крикун Т., Глухих М.

Обнаружение дефектов работы с указателями в программах С и С++
с использованием статического анализа и логического вывода

286

Санкт-Петербургский государственный политехнический университет,
Технический университет Клаусталя

• Андрианова А., Ицыксон В.

Автоматизированный синтез тестов для Java-программ на основе
анализа программ и учета контрактов

298

Санкт-Петербургский государственный политехнический университет

•

Буй Д., Компан С.

Диаграммы классов ООП: формализация и анализ

311

Киевский национальный университет имени Тараса Шевченко


9

Конференция TMPA-2013

10


Международная научно-практическая
конференция: Tools & Methods of Program Analysis
(Инструменты и методы анализа программ, TMPA-2013)
10-12 октября 2013, г. Кострома, РФ
Конференция посвящена одному из наиболее актуальных и важных направлений программной инженерии – анализу качества программного обеспечения.
Вопросы эффективности и корректности функционирования программного обеспечения являются ключевыми для большинства наукоемких отраслей
современной экономики, включая ИТ-индустрию, финансовый сектор, транспорт, медицину, высокотехнологическую промышленность и многие другие.
Разработка новых и усовершенствование существующих инструментов и методов анализа программ – одно из необходимых условий внедрения инноваций
в этих отраслях.
Конференция нацелена на развитие индустрии разработки программного обеспечения и внедрение новейших разработок в области тестирования, анализа
и верификации.
В рамках конференции планируются пленарные доклады и лекционные мини-курсы экспертов; доклады участников, отобранные программным комитетом из числа поступивших заявок; презентации открытых проектов, короткие
сообщения, представляющие новые идеи, незавершенные исследования или
новые инструменты.
Темы, рассматриваемые на конференции, включают (но не ограничиваются):
• автоматизация тестирования программного обеспечения;
• статический анализ программ;
• верификация;
• динамические методы анализа программ;
• тестирование и анализ параллельных и распределенных систем;
• тестирование и анализ высоконагруженных систем и систем высокой доступности;
• анализ и верификация программно-аппаратных систем;
• методы создания качественного программного обеспечения;
• инструментальные средства анализа, тестирования и верификации


11

Программный комитет конференции
• Захаров Виктор Николаевич, д.т.н., ИПИ РАН, сопредседатель
• Ицыксон Владимир Михайлович, к.т.н., доцент кафедры
компьютерных систем и программных технологий СПбГПУ,
сопредседатель

• Лустгартен Юрий Леонидович, к.т.н., декан ФАСТ КГТУ,
сопредседатель

• Петренко Александр Константинович, д.ф.-м.н., зав. отделом
Технологий программирования Института системного
программирования РАН, профессор кафедры Системного
программирования ВМиК МГУ им. М.В.Ломоносова

• Басок Борис Моисеевич, к.т.н., доцент МИРЭА
• Глухих Михаил Игоревич, к.т.н., доцент, СПбГПУ, приглашенный
исследователь в Clausthal University of Technology

• Евтушенко Нина Владимировна, д.т.н., профессор, зав. кафедры
Информационных технологий в исследовании дискретных структур,
Радиофизический факультет, Национальный исследовательский
Томский государственный университет (ТГУ)

• Зайцев Дмитрий Анатольевич, д.т.н., профессор, Международный
гуманитарный университет, Одесса, Украина

• Захаров Владимир Анатольевич, д.ф.-м.н., доцент кафедры МК,
зав. лабораторией МПКБ

• Иванов Александр Николаевич, к.ф.-м.н.,
ведущий разработчик ООО «КоФиТе»

• Иткин Иосиф Леонидович, компания Exactpro Systems, координатор
• Камкин Александр Сергеевич, к.ф.-м.н., с.н.с. ИСП РАН;
• Климов Андрей Валентинович, зав. сектором методов анализа и
преобразования программ ИПМ им. М.В.Келдыша РАН
12


• Кириленко Яков Александрович, старший преподаватель,
МатМех СПбГУ

• Кулямин Виктор Вячеславович, к.ф.-м.н., с.н.с. ИСП РАН,
доцент ВМК МГУ

• Моисеев Михаил Юрьевич, к.т.н., доцент, СПбГПУ
• Пакулин Николай Витальевич, к.ф.-м.н., старший научный сотрудник
ИСП РАН

• Павлова Елена Анатольевна, к.т.н., координатор программ, Microsoft
• Прохоров Сергей Петрович, к.ф.-м.н., ИСП РАН, доцент МФТИ
• Соколов Валерий Анатольевич, д.ф.-м.н.,
проф., зав. каф. теоретической информатики ЯГУ им. П.Г. Демидова

• Федосеев Андрей Алексеевич, к.т.н., в.н.с. ИПИ РАН
• Филиппов Станислав Александрович, к.т.н., с.н.с. ИПИ РАН
• Христочевский Сергей Александрович, к.ф.-м.н., зав. лаб. ИПИ РАН
• Цесько Вадим Александрович, старший разработчик, Яндекс


13

Программа конференции
TMPA-2013

14


10 октября
8:30

Регистрация

9:30

Открытие

10:15
11:15

Карпов Ю.
Верификация параллельных программ: современный этап и перспективы

Кофе-брейк
ВЕРИФИКАЦИЯ

11:45

Пакулин Н.
Динамическая верификация гибридных систем

12:15

Подымов В., Попеско У.
Верификация программно-конфигурируемых сетей при помощи системы
UPPAAL

12:45

Кузьмин Е., Рябухин Д., Шипов А.
Построение и верификация ПЛК-программ по LTL-спецификации

13:15

Ануреев И.
На пути к технологии разработки средств дедуктивной верификации
программ

13:45

Лукин М., Шалыто А.
Верификация распределенных автоматных программ с использованием
инструментального средства Spin

14:00

Обед

15:30

Зайцев Д.
Эффективная универсальная сеть Слепцова
АППАРАТНЫЙ ТРЕК

16:00

Иванников В., Камкин А., Чупилко М.
Проверка корректности поведения HDL-моделей цифровой аппаратуры
на основе динамического сопоставления трасс

17:00

Шипин А., Соколов В., Чалый Д.
Использование контрольных точек для верификации SystemC-программ

17:30

Френкель С., Захаров В., Ушаков В.
Унифицированная высокоуровневая модель программно-аппаратной
системы для верификации свойств надежности функционирования

17:45

Смирнов М., Олоничев В., Староверов Б.
Особенности разработки программного обеспечения для Linuxконтроллеров


15

11 октября
8:30


9:30

Петренко А. К.
Технические решения и нетехнические проблемы автоматизации
тестирования

10:30

ISTQB
ТЕСТИРОВАНИЕ

11:00
11:30

Басок Б., Гречин А.
Об усовершенствовании статистического метода оценки полноты тестов
программ и устройств

Кофе-брейк

12:00

Никешин А., Пакулин Н., Шнитман В.
Автоматизация тестирования соответствия реализаций стандарту протокола безопасности транспортного уровня TLS

12:30

Сартаков В., Тарасиков А.
Анализ производительности сетевой подсистемы микроядерного
окружения Genode

13:00

Журавлев М., Полозов В.
Подход к верификации корректности миграции данных между СУБД с
использованием криптографических хэш-функций

13:15

Сенов А.
Применение технологий OLAP и MapReduce для обработки результатов
нагрузочного тестирования
ТРЕЙДИНГОВЫЕ СИСТЕМЫ

13:30
14:00
15:30

Матвеева А., Антонов Н., Иткин И.
Особенности инструментов для тестирования, применимых при
промышленной эксплуатации трейдинговых систем

Обед

Алексеенко А., Проценко П., Матвеева А., Иткин И., Шаров Д.
Тестирование совместимости протокольных подключений клиентов
биржевых и брокерских систем

15:50
16:10

Гурьев Д., Гай М., Иткин И., Терентьев А.
Высокопроизводительный генератор нагрузки для тестирования систем
автоматизированной торговли

16:30

16

Буянова О., Булда А, Зверев А.
Применение симуляторов рынка ценных бумаг для тестирования систем
агрегации и распределения информации о котировках (Ticker Plant)

Прядкина Н., Крюков А.
Использование MBT-подхода для верификации систем мониторинга и
контроля на фондовых биржах


11 октября
16:45

Бобров И., Зверев А.
Тестирование графического интерфейса трейдинговых терминалов в
условиях высокочастотной торговли

17:00

Кофе-брейк

17:30 Круглый стол: Нешаблонные методы тестирования программного
обеспечения для электронных торговых платформ

12 октября
9:00


9:30

Захаров В. А.
Математические аспекты задачи обфускации программ
АНАЛИЗ ПРОГРАММ

10:30

Цителов Д., Трифанов В.
Динамический поиск гонок в Java-программах на основе
синхронизационных контрактов

11:00

Верт Т., Крикун Т. и Глухих М.
Обнаружение дефектов работы с указателями в программах С и С++
с использованием статического анализа и логического вывода

11:30

Кофе-брейк

12:30

Андрианова А., Ицыксон В.
Автоматизированный синтез тестов для Java-программ на основе анализа
программ и учета контрактов

12:45

Буй Д., Компан С.
Диаграммы классов ООП: формализация и анализ

13:00

Круглый стол: Как написать хорошую научную статью

13:30

Закрытие конференции

14:00 Завершающий обед


17

Cекционные доклады
TMPA-2013

18



19

20



21

𝑑𝑑𝑑𝑑
𝑑𝑑𝑑𝑑

= 𝑘𝑘(100 − 𝑇𝑇 )

𝑘𝑘1 <

𝑑𝑑𝑑𝑑
𝑑𝑑𝑑𝑑

𝑘𝑘

< 𝑘𝑘2
𝑇𝑇

𝑇 70

𝑇𝑇 𝑇 68

22



23

𝑀𝑀
𝐼𝐼

𝑆𝑆

𝐼𝐼

24


𝜑𝜑
𝐼𝐼

𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑 = 𝑓𝑓 (𝑥𝑥)
𝑙𝑙 ≤ 𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑 ≤ 𝑚𝑚
𝑙𝑙 𝑚𝑚


25

26



27

28



29

30



31

32



33

34



35

Верификация программно-конфигурируемых
сетей при помощи системы UPPAAL
Владислав Подымов, Ульяна Попеско
МГУ имени М.В. Ломоносова
valdus@yandex.ru, ulya_kiber@mail.ru

Аннотация В последние несколько лет активное развитие получили программно-конфигурируемые сети (ПКС) – особый вид компьютерных сетей, в которых все коммутирующие устройства имеют централизованное управление. В статье исследуются задачи формального описания и верификации ПКС. Для описания ПКС используется
библиотека элементов UML в редакторе диаграмм Dia. Для верификации ПКС используется программно-инструментальное средство
UPPAAL. Основной результат исследований - разработка транслятора, позволяющего по диаграмме сети получить её модель для верификации в виде сети конечных временных автоматов. Корректность
алгоритма трансляции строго обоснована. Проведен ряд экспериментов, которые показывают применимость предложенного метода верификации для проверки свойств поведения ПКС, специфицированных
посредством формул темпоральной логики реального времени.
Keywords: программно-конфигурируемая сеть, верификация, временные автоматы, темпоральная логика, UPPAAL

1

Введение

Идея программно-конфигурируемых сетей (ПКС) сформулирована специалистами университетов Стэнфорда и Беркли в 2006 году [1]. В таких сетях
уровень управления отделен от устройств передачи данных: коммутаторы
не участвуют в определении маршрутов для пакетов, а только реализуют
программу контроллера. Наиболее широко применяемым стандартом для
построения ПКС является протокол OpenFlow [2].
Сеть OpenFlow состоит из коммутаторов, управляемых централизованным контроллером. Пакет, передаваемый по сети, обрабатывается контроллером существенно медленнее, нежели коммутатором, поэтому одной из основных функций контроллера является организация работы коммутаторов
так, чтобы они обрабатывали большую часть пакетов, и лишь в исключительных случаях пакеты обрабатывались бы на контроллере.
Организация работы коммутаторов заключается в установке правил в
таблицы коммутации (ﬂow tables), определяющих, как будут обрабатываться те или иные пакеты. Правило состоит из шаблона, идентифицирующего
вид пакетов, целочисленного приоритета, устраняющего неоднозначность в

36


2


случае наложения шаблонов, целочисленного лимита времени, указывающего число секунд до истечения срока активности правила, и списка действий, описывающих обработку пакета. Также для каждого правила в этих
таблицах коммутатор содержит счетчики для учета количества и размера
обрабатываемых пакетов.
Коммутатор обрабатывает приходящий пакет в 3 этапа. Сначала он выбирает правило из своей таблицы коммутации так, чтобы заголовок пакета
соответствовал шаблону этого правила. Если такового не найдено, коммутатор отправляет пакет контроллеру для дальнейшей обработки. Иначе выбирается совпадающее по шаблону правило с наибольшим приоритетом. На
втором шаге обновляются счетчики для выбранного правила. И наконец,
к пакету поочередно применяются все действия, записанные в правиле. К
допустимым действиям относятся output(op) и modif y(h,n). По действию
output(op) пакет отправляется на порт op. Действие modif y(h,n) предписывает переписать заголовочное поле h на n.
Контроллер устанавливает правила в таблицы коммутации, реагируя на
события в сети. Такими событиями являются подключение нового коммутатора к сети, удаление ранее действующего коммутатора из сети, события для
сбора статистики, истечение лимита времени правила коммутатора. Также
контроллер оперирует функциями отправки сообщений коммутаторам: установкой правил в таблицу коммутации, удалением всех правил с заданным
шаблоном из таблицы коммутации, отправкой пакета и действия для его
обработки коммутатором.
В статье исследуется возможность верификации ПКС как распределенных систем реального времени. Для этого потребовалось решить следующие
задачи: 1) выбрать адекватное средство для построения сетей; 2) выбрать
подходящее средство для верификации сетей как систем реального времени;
3) построить корректный транслятор из выбранного средства построения
сетей во входной язык нужной системы верификации; 4) провести экспериментальное исследование возможности применения выбранного средства
верификации для проверки спецификаций ПКС.
Стандарт OpenFlow включает в себя большое количество свойств и предписаний для коммутации пакетов в сети. Производители компонентов компьютерных сетей используют лишь часть из них. Мы также ограничимся в
рассматриваемых вариантах. При моделировании правил таблиц коммутации не будем уделять внимание приоритетам и счетчикам, а из всех допустимых действий будем рассматривать только действия типа output(op). Сбор
статистических данных в сети также не будет нас интересовать. С другой
стороны, в нашу модель будут добавлены временные характеристики, описывающие работу физических объектов сети. Посредством этого мы будем
учитывать не только предписания стандарта OpenFlow, но и технические
возможности коммутаторов и каналов.

37

Верификация ПКС при помощи системы UPPAAL

2

3

Схема верификации

Для построения ПКС был выбран кроссплатформенный редактор диаграмм
Dia1 . Сеть из рассматриваемого нами подкласса описывается с помощью
объектов библиотеки элементов UML, предоставляемых редактором, следующим образом (см. рисунок 1). Каждый коммутатор изображается в виде
прямоугольника с тремя секциями. В верхней секции обозначается имя коммутатора, в нижней содержатся правила таблицы коммутации, в средней —
физические характеристики коммутатора. Каждое правило таблицы коммутации имеет четыре поля: имя порта, на который поступил пакет, заголовок поступившего пакета, лимит времени жизни правила и порт, на который необходимо отправить пакет. Описываются следующие характеристики коммутатора: port — множество портов коммутатора, соединяющих его
с другими коммутаторами и внешней средой; rule_imp — задержка поиска
и выполнения правила на коммутаторе (временной интервал); rule_def —
задержка установки в коммутатор правила от контроллера; rule_ar — интенсивность поступления пакетов из внешней среды; rule_con — задержка
доставки необработанного пакета контроллеру; tab — объем таблицы коммутации, то есть максимальное число правил таблицы.

Рис. 1. Пример описания ПКС диаграммами Dia.

Для отображения топологии сети коммутаторы соединяются линиями,
моделирующими дуплексные каналы сети. Каналы также имеют временную
характеристику — задержку доставки пакета. Поведение контроллера опре1

38

Руководство пользователя редактора Dia доступно по адресу http://diainstaller.de/doc/en/dia-manual.pdf

4


деляется политикой коммутации пакетов в сети, которая для нашего класса задач представима в виде таблицы, отображающей соответствие между
заголовком поступившего на контроллер пакета и правилом, которое необходимо установить на коммутатор, приславший этот пакет. Также отдельно
описывается множество всех возможных заголовков пакетов.
Для проверки спецификаций построенных таким образом ПКС было выбрано программно-инструментальное средство UPPAAL [3], использующее
метод проверки свойств на моделях. Данный метод предполагает наличие
модели, описывающей систему на определенном уровне абстракции, и позволяет проверить, удовлетворяет ли заданная модель системы формальным
спецификациям. В средстве верификации UPPAAL в качестве модели используются сети конечных временных автоматов (параллельные композиции временных автоматов) [4], а формальные спецификации задаются формулами темпоральной логики TCTL [3].
Временные автоматы представляют собой конечные автоматы, работающие в реальном времени и осуществляющие синхронизацию посредством передачи сигналов через каналы связи. Особенностью таких автоматов является возможность использования таймеров. Значения таймеров можно указывать во временных ограничениях условий переходов между состояниями.
Показания всех таймеров изменяются на одинаковые величины с течением
времени.
Для верификации ПКС, описанных в терминах диаграмм Dia, средством
UPPAAL, нами предложен алгоритм трансляции диаграмм в сети временных автоматов. Сеть, получаемая при трансляции, состоит из автоматов,
моделирующих коммутаторы, контроллер, внешнюю среду и каналы сети.
Таким образом, в результате трансляции диаграмм мы получаем сеть, пригодную для верификации средством UPPAAL. Подобный подход к верификации распределенных систем реального времени был применен в работе
[5].

3

Формальный синтаксис ПКС

Перед описанием алгоритма трансляции необходимо ввести формальную
модель ПКС. С учетом выбранных нами ограничений ПКС может быть описана системой (H, con, Com, Chan), где H — множество заголовков пакетов
сети, con — контроллер, Com = (com1 , . . . , comn ) — набор коммутаторов
сети и Chan = (c1 , . . . , cm ) — набор каналов сети. Заметим, что во введенной формальной модели ПКС вместо пакетов рассматриваются только их
заголовки, при этом содержащиеся в пакетах сообщения опускаются. Для
простоты восприятия далее под пакетами в формальной модели будут подразумеваться их заголовки.
Коммутатор comi включает в себя множество портов P orti , начальную
таблицу коммутации Rulei ⊆ P orti × H × Real × P orti объема tab и временimp
def
ar
con
ные характеристики Limp , Ri , Ldef , Ri , Lar , Ri , Lcon , Ri , естественi
i
i
i
ным образом соотносящиеся с характеристиками коммутатора, описанными

39


5

в диаграмме (см., например, рисунок 1). Правило (p, h, x, p ) таблицы коммутации означает, что пакет h, пришедший на порт p, перенаправляется на
порт p . При этом x — время жизни правила; если x ≥ 0, то правило назовем
активным, иначе истекшим. Шаблоном правила (p, h, x, p ) будем называть
пару (p, h).
Контроллер con представляет собой множество пар вида (i, r), означающих, что правило r может быть выслано коммутатору comi . Канал c описывается тем, из какого порта какого коммутатора он исходит, в какой порт
какого коммутатора он входит и временными характеристиками L, R — минимальное и максимальное время задержки при доставке пакета. Заметим,
что в предложенной модели каналы являются однонаправленными. Такое
ограничение несущественно, т.к. дуплексный канал моделируется двумя однонаправленными.

4

Формальная семантика ПКС

Для доказательства корректности алгоритма трансляции необходимо ввести формальное описание работы ПКС. Данное описание является формализацией поведения ПКС в рамках стандарта OpenFlow с учетом введенных
нами ограничений.
Состояние ПКС складывается из состояний контроллера и всех коммутаторов и каналов. Для удобства описания предполагаем, что каждый коммутатор comi располагает следующими каналами: канал car входного потока
i
ar
с временными характеристиками L = Lar , R = Ri , ведущий в специально
i
выделенный под него порт; канал cto con , ведущий в контроллер из другого
i
con
специально выделенного порта, с характеристиками L = Lcon , R = Ri ;
i
f rom con
, ведущий от контроллера в третий специально выделенный
канал ci
порт коммутатора, с характеристиками L = R = 0. Таким образом, состояние S ПКС включает в себя состояния scon контроллера, scom , . . . , scom комn
1
мутаторов и sch , . . . , sch , sar , . . . , sar , stocon , . . . , stocon , sf romcon , . . . , sf romcon
m
n
n
n
1
1
1
1
каналов ch между коммутаторами, ar от входного потока, to con к и f rom con
от контроллера соответственно.
Коммутатор comi может находиться в состояниях (start, Rule), (select,
t, Rule, h, p), (hit, Rule, h, p), (miss, Rule, h, p), (mod, t, Rule). В состоянии
start коммутатор прослушивает входящие каналы на предмет поступивших
пакетов. В состоянии select коммутатор, получив на порт p пакет h, просматривает таблицу коммутации для принятия решения о перенаправлении
пакета. В состоянии hit пакет засылается в канал, исходящий из порта p. В
состоянии miss шаблон, состоящий из пакета h и порта p, на который он пришел, засылается в канал к контроллеру. Вообще говоря, коммутатор также
должен посылать контроллеру свой идентификатор, однако в построенной
формальной модели идентификатор может быть восстановлен по номеру
порта, входящего в коммутатор. В состоянии mod происходит запись в таблицу коммутации правила, присланного контроллером. Во всех состояниях

40


6


коммутатора Rule — текущая таблица коммутации, t — время нахождения
в текущем управляющем состоянии, h и p — хранимые пакет и порт.
Каналы могут могут находиться в состояниях (empty), (f ull, t, o) и (sent,
o), где o — пакет для обычных и поточных каналов, шаблон для каналов
к контроллеру либо правило для каналов от контроллера. Компонента t ∈
Real — время обработки сообщения каналом.
Контроллер может находиться только в состояниях (idle) (ожидание запросов от коммутаторов) и (send, i, r) (послать i-му коммутатору новое
правило r).
Начальное состояние S0 системы строится из начальных состояний коммутаторов, контроллера и каналов. Начальное состояние i-го коммутатора
— (start, Rulei ), контроллера — (idle), каналов — (empty).
Работа ПКС характеризуется последовательностью состояний, начинающейся в S0 и строящейся по описанным далее правилам. Запись s → s
означает, что следующее состояние может быть получено из предыдущего
заменой компоненты s на s . Запись s1 , s2 → s1 , s2 означает то же самое для
пары компонент. Построение вычисления ПКС происходит по следующим
правилам.
1. Получение пакета: scom , sar = (start, Rule), (sent, h) → (select, 0, Rule,
i
i
h, p), (empty).
2. Применение активного правила r = (p, h, x, p ): scom = (select, Rule, t,
i
imp
h, p) → (hit, Rule, h, p ), если t ∈ [Limp , Ri ], r ∈ Rule.
i
3. Обработка истекшего правила r = (p, h, x, p ): scom = (select, Rule, t, h, p)
i
imp
→ (miss, Rule , h, p), если t ∈ [Limp , Ri ], r ∈ Rule и Rule = Rule {r}.
i
4. Сброс пакета: scom = (select, Rule, t, h, p) → (start, Rule), если t ∈
i
imp
[Limp , Ri ], |Rule| = tabi , все правила из Rule активны и ни одно из
i
них не имеет шаблона (p, h).
5. Несоответствие шаблонов: scom = (select, Rule, t, h, p) → (miss, Rule ,
i
h, p), где Rule получается из Rule удалением всех истекших правил.
6. Начало перезаписи таблицы: scom , sf rom con = (start, Rule), (sent, rule)
i
i
→ (mod, 0, Rule), (sent, rule).
7. Успешная перезапись таблицы: scom , sf rom con = (mod, t, Rule), (sent, (p,
i
i
def
h, x, p )) → (hit, Rule , h, p ), (empty), если t ∈ [Ldef , Ri ], |Rule| < tabi
i
и Rule = Rule ∪ {(p, h, x, p )}.
8. Неуспешная перезапись таблицы: scom , sf rom con = (mod, t, Rule), (sent,
i
i
def
rule) → (start, Rule), (empty), если t ∈ [Ldef , Ri ] и |Rule| = tab.
i
com
ch
9. Пересылка пакета коммутатору: si , sj = (hit, Rule, h, p), (empty) →
(start, Rule), (f ull, 0, h), если канал cj исходит из порта p коммутатора
i.
10. Пересылка шаблона контроллеру: scom , sto con = (miss, Rule, h, p), (empty)
i
i
→ (start, Rule), (f ull, 0, (p, h)).
11. Успешная обработка шаблона контроллером: scon , sto con = (idle), (sent,
i
(p, h)) → (send, i, r), (empty), если (i, (p, h, x, p )) ∈ con.
12. Неуспешная обработка шаблона контроллером: scon , sto con = (idle), (sent,
i
/
(p, h)) → (idle), (empty), если (i, (p, h, x, p )) ∈ con.

41


7

13. Пересылка правила от контроллера: scon , sf rom con = (send, i, r), (empty)
i
→ (idle), (f ull, 0, r).
14. Появление пакета в сети: sar = (empty) → (f ull, 0, h), если h ∈ H.
i
15. Сброс пакета в окружение: scom = (hit, Rule, h, p) → (start, Rule), если
i
ни один канал cj не исходит из порта p коммутатора comi .
16. Доставка в канале: (f ull, t, o) → (sent, o), если t ∈ [L, R] для характеристик L, R соответствующего канала.
17. Продвижение времени: таймеры всех коммутаторов и каналов увеличиваются на одну и ту же положительную величину d, времена жизни
правил уменьшаются на эту же величину, и при этом:
– если какой-либо канал находится в состоянии (f ull, t, o), то t + d ≤ R
для характеристики R этого канала;
imp
– если scom = (select, Rule, t, h, p), то t + d ≤ Ri ;
i
def
com
– если si
= (mod, Rule, t), то t + d ≤ Ri .

5

Алгоритм трансляции

Алгоритм Alg переводит ПКС в эквивалентную ей сеть временных автоматов. Понятие эквивалентности обсуждается в следующем разделе.
Сеть N , получаемая в результате трансляции ПКС ((com1 , . . . , comn ),
con, (c1 , . . . , cm ), H), содержит автоматы Hurry, Env, Stream, Chan, Acon
и Ai , i ∈ {1, . . . , n}.
Каждый канал ci моделируется булевыми переменными f ull[ci ] (пакет
послан), ready[ci ] (пакет доставлен), таймером t[ci ] и переменными для хранения объектов, пересылаемых через канал. Сброс пакетов в окружение моделируется с помощью особого канала cenv . Также в сеть добавляются все
каналы car , cto con , cf rom con .
i
i
i
Автомат Hurry обеспечивает срочные дуги (т.е. дуги, выполняющиеся
немедленно по выполнении их предусловий) и состоит из одной вершины
и петли, принимающей сигнал по срочному каналу hurry. К срочным дугам по умолчанию добавляется посылка сигнала по каналу hurry. Автомат Env удаляет пакеты из канала cenv и состоит из одной вершины и
срочной петли с записью в переменную f ull[cenv ] значения f alse. Автомат
Stream генерирует пакеты, состоит из одной вершины и содержит набор
срочных петель, недетерминированно засылающий пакеты в каналы car .
i
Автомат Chan обеспечивает доставку пакетов каналами, состоит из одной
вершины и содержит петлю для каждого канала c, помеченную предусловием f ull[c] && !ready[c] && (t[c] ≥ L(c)) и записью в переменную ready[c]
значения true, где L(c) — характеристика L канала c. Сама вершина автомата Chan при этом помечена инвариантом — конъюнкцией неравенств
t[c] ≤ R(c).
Автомат Acon имеет два обычных состояния — idle и send — и одно срочное состояние l. Срочная дуга idle → l записывает в локальные переменные
автомата шаблон, присланный коммутатором, и номер этого коммутатора и
в зависимости от наличия отправляемого обратно правила переходит либо

42


8


обратно в idle, либо в send. Срочная дуга send → idle присваивает переменной f ull[c] значение true и записывает в переменную канала выбранное
правило.
Автомат Ai моделирует работу коммутатора comi и состоит из обычных
состояний start, select, hit, miss, mod, соединенных через срочные вершины.
Срочная дуга start → select записывает в локальные переменные автомата
доставленный через канал c пакет и порт, на который он пришел, и записывает в переменную f ull[c] значение f alse. Состояние select, помеченное
imp
инвариантом t ≤ Ri , имеет одну исходяющую дугу в срочное состояние
l, помеченную предусловием t ≥ Limp . Здесь t — локальный таймер комi
мутатора. Из состояния l в зависимости от наличия шаблона происходит
переход в состояния hit и miss с модификацией таблицы согласно правилам
2-5 семантики ПКС. Удаление многих правил из таблицы коммутации обеспечивается срочной вершиной l с петлей, удаляющей из таблицы истекшие
правила, и исходящей дугой, помеченной предусловием, утверждающим, что
из таблицы удалены все истекшие правила. Срочная дуга start → mod записывает в локальные переменные автомата правило, доставленное каналом
def
cf rom con . Состояние mod помечено инвариантом t ≤ Ri , исходящие из него
i
def
дуги — предусловием r ≥ Li . В зависимости от того, заполнена ли таблица коммутации, из состояния mod автомат может либо перейти в состояние
start, либо перейти в состояние hit с записью правила в таблицу.

6

Корректность алгоритма трансляции

Под корректностью алгоритма Alg понимается равновыполнимость формул,
используемых в средстве UPPAAL, для исходной ПКС N и результирующей
сети Alg(N ). Ключевым понятием в доказательстве корректности алгоритма Alg является эквивалентность по прореживанию (stuttering equivalence)
для систем переходов [6]. Неформально, такая эквивалентность означает,
что если в каждом вычислении двух данных систем склеить все одинаковые состояния, то мы получим одинаковые множества вычислений. Одинаковыми полагаются состояния с совпадающими множествами выполнимых
формул. В работе [7] сформулирована следующая теорема.
Теорема 1 Если системы переходов M1 , M2 эквивалентны по прореживанию и формула Φ логики LT L−X истинна для M1 , то она также истинна
для M2 .
Следующая теорема позволяет применить только что сформулированную к системам переходов, описывающим поведение ПКС N и сети Alg(N ).
Система переходов, описывающая поведение сети временных автоматов, обсуждается, например, в [4]. Пусть T SA — система переходов, описывающая
поведение системы A.
Теорема 2 Пусть N — произвольная ПКС. Тогда системы переходов T SN
и T SAlg(N ) эквивалентны по прореживанию.

43


9

Теорему обосновывают следующие рассуждения. Состояниям контроллера и коммутаторов ставятся в соответствие одноименные состояния получающихся из них автоматов вместе с необходимыми значениями локальных
переменных. Состояниям каналов ставятся в соответствие наборы значений переменных f ull, ready и переменных для хранения данных. Одному
применению семантических правил 1-17 соответствует последовательность
переходов в сети временных автоматов через срочные состояния, и смена
значений переменных происходит только в одном месте последовательности. В результате применения правила в ПКС и построенной по нему последовательности переходов в сети соответствующие состояния переводятся в
соответствующие.
Корректность алгоритма напрямую следует из приведенных теорем с
учетом того, что формулы, проверяемые средством UPPAAL, могут быть
переформулированы в терминах логики LT L−X .

7

Экспериментальное исследование

В приложении приведена сеть автоматов, построенная транслятором по описанию сети на рисунке 1. Ниже приведены проверенные с помощью средства
UPPAAL свойства и их запись на языке запросов UPPAAL [3].
1. В работе системы не возникает блокировки:
A[] not deadlock
2. В сеть всегда будут поступать пакеты из внешней среды:
A <> f orall(num : int[0, 2]) (channel_h[stream.align[num]])
3. Допустим сценарий работы сети, в котором коммутатор не принимает
ни одного пакета:
E[] com1.start
4. При любом сценарии работы сети контроллер обработает хотя бы один
пакет:
E <> !con.idle
5. Хотя бы один пакет будет успешно перенаправлен коммутатором (т.е.
коммутатор выполняет свою главную функцию):
E <> com1.hit
Свойства 1,2,4,5 соответствуют спецификации сетей OpenFlow, в то время как свойство 3 является недопустимым. Проверка показала, что свойства
1,2,4,5 выполняются, а свойство 3 не выполняется. Это свидетельствует о
том, что функционирование полученной сети временных автоматов соответствует нашим ожиданиям и что предложенная схема верификации ПКС

44


10


с помощью средства UPPAAL позволяет проверять свойства поведения ПКС
как системы реального времени.
В ячейках таблицы 1 представлено время проверки описанных темпоральных свойств для некоторых моделей ПКС: 1 – три коммутатора в топологии кольца (рисунок 1); 2 – четыре коммутатора в топологии звезды;
3 – четыре коммутатора в произвольной топологии; 4 – два коммутатора с
изначально пустыми таблицами коммутации. Проверка проводилась на вычислительном устройстве со следующими характеристиками: INTEL Core i7
3820/1600 МГц/2Гб DDR3. Первое свойство не было проверено на моделях
1–3 в связи с нехваткой памяти.
Таблица 1. Время проверки свойств ПКС.

Модель
Модель
Модель
Модель

8

1
2
3
4

1
27 часов

1
1
1
1

2
секунда
секунда
секунда
секунда

1
1
1
1

Свойство номер:
3
4
5
секунда
7 секунд
1 секунда
секунда 1 минута 2 секунды 1 минута 25 секунд
секунда
1 минута
1 минута 19 секунд
секунда
1 секунда
1 секунда

Заключение

В результате проведенных исследований мы подтвердили практическую осуществимость подхода, предложенного в статье [5], для проверки выполнимости свойств поведения моделей программно-конфигурируемых сетей в
реальном времени. Предложенное нами средство анализа поведения ПКС
может быть использовано для наглядного описания конфигурации и коммутационной политики сети в виде диаграмм. Разработанный нами алгоритм трансляции преобразует диаграмму в сеть временных автоматов, подаваемую на вход системы верификации UPPAAL. Корректность алгоритма
трансляции строго обоснована, транслятор реализован на языке программирования Perl. Получаемая на выходе транслятора сеть временных автоматов позволяет проверять спецификации ПКС с помощью системы UPPAAL.
Особенностью такой верификации является возможность учитывать временной аспект поведения ПКС как распределённых систем реального времени.

Список литературы
1. Casado M., Garﬁnkel T., Akella A., Fredman M., Boneh D., McKeown N.,
Shenker S. SANE: A Protection Architecture for Enterprise Networks // 15-th
Usenix Security Symposium, Vancouver, Canada, August 2006.

45


11

2. McKeown N., Anderson T., Balakrishnan H., Parulkar G., Peterson L., Rexford J.,
Shenker S., Turner J. Openﬂow: Enabling innovation in campus network //
SIGCOMM Computer Communication Review, 2008, v.38, n.2, p.69-74.
3. Behrmann G., David A., Larsen K. A tutorial on Uppaal // Lecture Notes in
Computer Science, 2004, v.3185, p.200-236.
4. Alur R., Dill D. Automata for modeling real-time systems // Proc. of Int.
Colloquium on Algorithms, Languages, and Programming, LNCS, 1990, v.443,
p.322-335.
5. Волканов Д.Ю., Захаров В.А., Зорин Д.А., Коннов И.В., Подымов В.В. Как
разработать простое средство верификации систем реального времени // Моделирование и анализ информационных систем, 2012, Том 19, №6, с.45–56.
6. Browne M.C., Clarke E.M., Grumberg O. Characterizing ﬁnite Kripke structures
in propositional temporal logics // Theor. Comp. Sci., 1988, v.59(1-2), p.115-131.
7. Clarke E.M., Grumberg O., Peled D. Model Checking. The MIT Press. 1999.

Приложение
Сеть временных автоматов, полученная в результате трансляции из ПКС,
изображенной на рисунке 1, приведена на рисунках 2–4. В целях удобочитаемости выражения автоматов написаны в синтаксисе, отличном от синтаксиса UPPAAL и при этом более простом для восприятия.
Запись вида (i = 1..3, 5, 7) означает перебор всех i из заданного диапазона
и создание копий дуги для каждого значения i. Запись вида (i = 1..3 → Φ)
означает “для всех i из заданного диапазона верна формула Φ”.
Функция get(c) сохраняет содержимое канала c в локальные переменные
(h, p, . . .) и выполняет присваивание c = f alse. Функция send(c, o) копирует o в содержимое канала и выполняет присваивания c = true, c_ready =
f alse, c_t = 0. Функция set_rule(i) копирует локальные переменные коммутатора, отвечающие компонентам правила, в i-ю позицию таблицы.
Предикат to_deliver(c) описывается как c && !c_ready && (c_t ≥ c_L).
Предикат ok(c) описывается как !c || c_ready || (c_t ≤ c_R).
Канал c[0] выделен под окружение, каналы c[1], c[2], c[3] — под потоки, прикрепленные к соответствующим коммутаторам. Автоматы A2 , A3
отличаются от автомата A1 только номерами задействованных каналов и
константами, определяемыми количеством портов и объемом таблицы, и по
этой причие опущены.

46


12


(i = 0..2)
hurry!

idle

to_con_ready[i]
get(to_con[i]), c = i

i = 0..2 -> !hit(rule[i], (c, p, h))
!con_in[c]
hurry!
send(from_con[c],
rule[r])

(i = 0..2)
hit(r[i], (c, p, h))
r=i

s1

send

(i = 1..3, num = 1..3)
!c[num]
hurry!
send(c[num], i)

Рис. 2. Автоматы Acon (слева), Stream (справа).

from_con[0]
hurry!
get(from_con[0]),
t=0

(i = 0..3)
(t >= 2) && !active[i]
set_rule(i)

rewrite
t <= 3
i = 1..3 -> active[i]

!c[r]
hurry!
send(c[r], h)
hit

start

t >= 3

(i = 1,4,5)
select
c_ready[i]
t <= 5
hurry!
get(c[i]), p = i, t = 0

(i = 0..3)
hit(rule[i])
r=i

rule_t[r] < rule_max[r]
rule_t[r] >= rule_max[r]
active[r] = false
miss

i = 0..3 -> !hit(rule[i])
i = 0..3 -> !active[i]
|| (rule_t[i] <= rule_max[i] )
(i = 0..3)
active[i] && (rule_t[i] > rule_max[i])
active[i] = false

i = 0..3 -> active[i]

i = 0..3
!active[i]
hurry!
send(to_con[0],
(p, h))

Рис. 3. Автомат A1 .

s1

hurry?

c[0]
hurry!
c[0] = false

(i = 0..2)
to_deliver(to_con[i])
to_con_ready[i])

s1

(i = 1..9)
to_deliver(c[i])
c_ready[i]

(i = 0..2 -> ok(to_con[i])) &&
(i = 1..9 -> ok(c[i]))

Рис. 4. Автоматы Hurry (слева), Env (в центре), Chan (справа).


47

⋆

⋆

48


P
S = (S, s0 , →, L)
s0 ∈ S
L : S → 2P

S
→⊆ S × S

s0
π = s0 s1 s2 . . .

∀i≥0

si → si+1


49

pi ∈ P
ϕ, ψ ::= true | p0 | p1 | . . . | pn | ¬ ϕ | ψ ∧ ϕ | Xϕ | ψ U ϕ | F ϕ | G ϕ.

X F G
ϕ

U
Gϕ

Xϕ
Fϕ ϕ
ϕ
ψU ϕ

ϕ
ψ

F

G
F ϕ = true U ϕ G ϕ = ¬F ¬ϕ
∨
ϕ

ϕ

50

⇒
s0


V

V
(1)

G X( V > V ⇒ OldValCond ∧ FiringCond ∧ V = NewValExpr )

V
V
V
OldValCond
FiringCond
NewValExpr

V
V

V
X
FiringCond

OldValCond

FiringCond
V
NewValExpr

OldValCond

V

(1)

⇒

OldValCond i ∧ FiringCond i ∧ V = NewValExpr i
V
G X( V < V ⇒ OldValCond ′ ∧ FiringCond ′ ∧ V = NewValExpr ′ )

(1′ )


51

(1)

(1′ )

V
(2)

G X( ¬ V ∧ V ⇒ FiringCond )

V
(2′ )

G X( V ∧ ¬V ⇒ FiringCond ′ )
′

(1) (1 )
V
FiringCond = FiringCond ′ = 1 NewValExpr = NewValExpr ′
OldValCond = ( V < NewValExpr ) OldValCond ′ = ( V > NewValExpr )
G X( V > V ⇒

V < NewValExpr ∧ V = NewValExpr )

G X( V < V ⇒

V > NewValExpr ∧ V = NewValExpr )

(3)

G X( V = NewValExpr )

(1)

V
(2)

′

(1 )

(2′ )
(3)

V
(3)

NewValExpr

V

52


(V ) = 1
V

V+

(1)
OldValCond
OldValCond ′

V
(1′ )

V−

V := NewValExpr
V := NewValExpr ′

FiringCond
FiringCond ′

V+
V−

V
OldValCond i ∧ FiringCond i ∧ V = NewValExpr i

V
V
V

V + (2)

V − (2′ )

V := 1
V := 0

FiringCond
FiringCond ′

V+
V−

V (3)
V := NewValExpr

V

V
V

V := V


53

V
V

V
V =0

V =1

V (1)

∼

(1′ )

V + G( X(V > V ) ⇒ X(OldValCond ) ∧ X(FiringCond ) ∧ X(V = NewValExpr ))
V − G( X(V < V ) ⇒ X(OldValCond ′ ) ∧ X(FiringCond ′ ) ∧ X(V = NewValExpr ′ ))

X
V

54


OldValCond
OldValCond ′

FiringCond
FiringCond ′

V
∼V
V

FiringCond
FiringCond ′

(2′ )

(2)

(3)
V :=

V

NewValExpr
NewValExpr ′

V := 1
V := 0
V := V

V

V

V :=
V :=
V := V

NewValExpr

NewValExpr

X G( V = NewValExpr )

V = NewValExpr
G( V = NewValExpr )
X G( V = NewValExpr )
V

V := NewValExpr


55

56


Последний ход:
Ход
0

0

4

4

4

4

4

Старт

1

2

3

4

5

Победа

4

6

Игрок

ПЛК

Игрок

ПЛК


57

Входы
Кнопки
Кнопка 1
PB1

ПЛК

Выходы
ход по цифре 1
1

выбрана цифра 1
1

2

Кнопка 2
PB2


Кнопка 3
PB3


2

3
4

3
5

Кнопка 4
PB4


4
6

Лампы
Лампа 1
Out1
Лампа 2
Out2
Лампа 3
Out3
Лампа 4
Out4
Лампа 5
Out5
Лампа 6
Out6


Старт
PBStart

Ход
игрока
Ход ПЛК
Turn

победил игрок


Кнопка 6
PB6

право хода у игрока
право хода у ПЛК

Кнопка 5
PB5

Игрок
ManWin
ПЛК
PLCWin

начать игру заново

5

7
7

6
8
победил ПЛК

7
9

58


V1 V2 V3 V4 V5

V6
Sum

Mv1 Mv2 Mv3 Mv4 Mv5

Mv6

Mv

Lck
Rst
Skp

G(¬PLCWin ∨ ¬ManWin)

Sum

G(Sum ≤ 37)

G(Mv1 +Mv2 +Mv3 +Mv4 +Mv5 +Mv6 ≤ 1)

PBStart
G(PBStart ⇒ V1 = 4∧V2 = 4∧V3 = 4∧V4 = 4∧V5 = 4∧V6 = 4∧¬Mv ∧
¬Turn ∧ ¬(P LCW in ∨ M anW in) ∧ Sum = 0)

G(F(Mv )) ⇒ G(F(PLCWin ∨ManWin ∨PBStart ))

PBStart

G(F(Mv )) ∧
G(¬PBStart ∧X(PBStart ) ⇒ (PLCWin ∨ManWin)) ⇒ G(PBStart ∧X(¬PBStart ) ⇒
X(¬PBStart U (PLCWin ∨ ManWin)))

59

G(F(Mv)) ∧ G(¬PBStart ∧ X(PBStart ) ⇒ (PLCWin ∨ ManWin)) ⇒
G(Mv3 ∧ Sum = 3 ⇒ ((¬ManWin ∧ ¬PLCWin) U PLCWin))

G(X(Mv1 ∧ Sum = 1 ∨ Mv2 ∧ Sum = 2 ∨ Mv3 ∧ Sum = 3 ∨ Mv4 ∧
Sum = 4 ∨ Mv5 ∧ Sum = 5 ∨ Mv6 ∧ Sum = 6) ⇒ ¬Turn)

60



61

62



63

64



65

На пути к технологии разработки средств
дедуктивной верификации программ⋆
Игорь Ануреев
Институт систем информатики имени А.П. Ершова
anureev@iis.nsk.su

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

1

Введение

В статье предлагается предметно-ориентированный подход к разработке
средств дедуктивной верификации программ (далее дедуктивных верификаторов). Термин «предметная ориентированность» применительно к подходу может иметь два значения. В первом случае, он означает ориентированность на предметную область, к которой применяется дедуктивная верификация. Во втором случае, он означает ориентированность на саму область
разработки средств дедуктивной верификации программ. Мы рассматриваем предметную ориентированность во втором значении. Прежде чем описывать подход, определим необходимые термины этой предметной области
и дадим классификацию существующих подходов к разработке средств дедуктивной верификации программ.
Дедуктивный верификатор применяется к аннотированной программе
на некотором целевом языке программирования. Аннотированная программа на этом языке — это текст, построенный по определенным правилам
⋆

66

Работа частично поддержана грантом РФФИ 11-01-00028-а и междисциплинарным интеграционным проектом СО РАН № 3 «Принципы построения онтологии
на основе концептуализаций средствами логических дескриптивных языков».


из конструкций целевого языка и аннотаций. Аннотации описывают свойства программы на целевом языке. Аннотированная программа называется корректной, если эти свойства выполняются. Обычно в качестве языка
аннотаций используется некоторый логический язык. Задача дедуктивного верификатора — доказать корректность аннотированной программы или
указать условия, при которых выполнение этой программы некорректно.
Дедуктивный верификатор рассматривает аннотированную программу
как формулу некоторого логического исчисления (называемого аксиоматической семантикой в контексте дедуктивной верификации) и преобразует ее
в наборы формул некоторого логического языка в соответствии с определенной стратегией логического вывода в этом исчислении таким образом, что
из истинности полученных в результате преобразования формул (называемых условиями корректности этой программы) следует корректность самой
программы.
Для доказательства условий корректности дедуктивный верификатор
применяет разного рода средства автоматической поддержки доказательства (универсальные средства автоматического или интерактивного доказательства такие, как, например, PVS или HOL; SAT-решатели, SMT-решатели и др.). Применительно к задаче дедуктивной верификации будем называть эти средства решателями условий корректности.
В качестве логического исчисления в дедуктивных верификаторах обычно используется логика Хоара или ее расширения. Инструменты, базирующиеся на логике отделимости (separation logic) и исчислении синонимов
(alias calculus), также можно отнести к дедуктивным верификаторам в случае, если эти инструменты базируются на некотором виде аксиоматической
семантики.
Опишем, как выглядит процесс разработки дедуктивного верификатора.
Сначала разрабатывается концепт дедуктивного верификатора. Его разработка включает выбор целевого языка, языка аннотаций, аксиоматической
семантики, методов оптимизации условий корректности, решателя условий
корректности и т. д. После того, как он разработан, можно выделить три
подхода к его реализации.
В первом подходе дедуктивный верификатор разрабатывается напрямую
на некотором языке программирования общего назначения. Единственным
достоинством этого подхода является большая степень свободы в оптимизации разрабатываемого верификатора. Эта степень ограничена только уровнем компетенций разработчика. Отметим недостатки подхода. Во-первых,
при этом подходе высока сложность разработки, поскольку снижается уровень абстракции при переходе от концепта к реализации. Во-вторых, по той
же причине, обоснование корректности верификатора представляет сложную проблему. В-третьих, верификатор не является гибким, поскольку ориентирован на конкретные целевой язык, язык аннотаций и аксиоматическую
семантику.
Во втором подходе аннотированная программа транслируется в программу на промежуточном языке, для которого уже имеются дедуктивные веМеждународная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ

67

TMPA-2013 Conference Proceedings

TMPA-2013 Conference Proceedings

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Andere mochten auch

Andere mochten auch (20)

Mehr von Iosif Itkin

Mehr von Iosif Itkin (20)

TMPA-2013 Conference Proceedings