YOU ARE DOWNLOADING DOCUMENT

Please tick the box to continue:

Transcript
Page 1: TMPA-2013 Conference Proceedings
Page 2: TMPA-2013 Conference Proceedings

Министерство образования и науки РФКостромской государственный технологический университет

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

Российская академия наукИнститут проблем информатики

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

ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММTOOLS & METHODS OF PROGRAM ANALYSIS

TMPA-2013

МатериалыМеждународной научно-практической конференции

10—12 октября 2013

Кострома

2013

Page 3: TMPA-2013 Conference Proceedings

УДК 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 (TMPA-2013)», состоявшейся 10-12 октября 2013 г. в Костромском государственном технологическом университете.

Для широкого круга читателей.УДК 004.413.5

ISBN 978-5-8285-0666-8© Костромской государственный

технологический университет, 2013

16+

Page 4: TMPA-2013 Conference Proceedings
Page 5: TMPA-2013 Conference Proceedings
Page 6: TMPA-2013 Conference Proceedings

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

Содержание:

ВЕРИФИКАЦИЯ:

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

• ПодымовВ.,ПопескоУ.Верификацияпрограммно-конфигурируемыхсетейприпомощисистемыUPPAALМГУ имени М.В. Ломоносова• КузьминЕ.,РябухинД.,ШиповА.ПостроениеиверификацияПЛК-программпоLTL-спецификацииЯрославский государственный университет им. П.Г. Демидова

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

• ЛукинМ.,ШалытоА.ВерификацияраспределенныхавтоматныхпрограммсиспользованиеминструментальногосредстваSpinСПб НИУ ИТМО

АППАРАТНЫЙТРЕК:

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

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

19

48

66

78

94

36

106

Page 7: TMPA-2013 Conference Proceedings

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

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

• СмирновМ.,ОлоничевВ.,СтароверовБ.ОсобенностиразработкипрограммногообеспечениядляLinux-контроллеровКостромской государственный технологический университет

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

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

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

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

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

118

138

146

158

130

167

Page 8: TMPA-2013 Conference Proceedings

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

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

ТРЕЙДИНГОВЫЕСИСТЕМЫ:

• МатвееваА.,АнтоновН.,ИткинИ.Особенностиинструментовдлятестирования,применимыхприпромышленнойэксплуатациитрейдинговыхсистемООО «Инновационные Трейдинговые Системы», Костромской государственный технологический университет, Exactpro Systems LLC

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

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

• БуяноваО.,БулдаА,ЗверевА.Применениесимулятороврынкаценныхбумагдлятестированиясистемагрегацииираспределенияинформацииокотировках(TickerPlant)ООО «Инновационные Трейдинговые Системы», Костромской государственный технологический университет, Exactpro Systems LLC

• ГурьевД.,ГайМ.,ИткинИ.,ТерентьевА.ВысокопроизводительныйгенераторнагрузкидлятестированиясистемавтоматизированнойторговлиООО «Инновационные Трейдинговые Системы», Саратовский государственный технический университет имени Гагарина Ю.А.

179

203

215

191

242

Page 9: TMPA-2013 Conference Proceedings

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

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

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

АНАЛИЗПРОГРАММ:

• ЦителовД.,ТрифановВ.ДинамическийпоискгоноквJava-программахнаосновесинхронизационныхконтрактовDevexperts LLC, СПбГУ

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

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

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

311

254

273

286

264

298

Page 10: TMPA-2013 Conference Proceedings

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

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

Page 11: TMPA-2013 Conference Proceedings

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

Международная научно-практическая конференция: Tools & Methods of Program Analysis (Инструменты и методы анализа программ, TMPA-2013) 10-12 октября 2013, г. Кострома, РФ

Конференция посвящена одному из наиболее актуальных и важных направле-ний программной инженерии – анализу качества программного обеспечения.Вопросы эффективности и корректности функционирования программно-го обеспечения являются ключевыми для большинства наукоемких отраслей современной экономики, включая ИТ-индустрию, финансовый сектор, транс-порт, медицину, высокотехнологическую промышленность и многие другие. Разработка новых и усовершенствование существующих инструментов и мето-дов анализа программ – одно из необходимых условий внедрения инноваций в этих отраслях.Конференция нацелена на развитие индустрии разработки программного обе-спечения и внедрение новейших разработок в области тестирования, анализа и верификации.В рамках конференции планируются пленарные доклады и лекционные ми-ни-курсы экспертов; доклады участников, отобранные программным комите-том из числа поступивших заявок; презентации открытых проектов, короткие сообщения, представляющие новые идеи, незавершенные исследования или новые инструменты.Темы, рассматриваемые на конференции, включают (но не ограничиваются):• автоматизация тестирования программного обеспечения;• статический анализ программ;• верификация;• динамические методы анализа программ;• тестирование и анализ параллельных и распределенных систем;• тестирование и анализ высоконагруженных систем и систем высокой до-

ступности;• анализ и верификация программно-аппаратных систем;• методы создания качественного программного обеспечения;• инструментальные средства анализа, тестирования и верификации

Page 12: TMPA-2013 Conference Proceedings

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

Программный комитет конференции

• Захаров Виктор Николаевич, д.т.н., ИПИ РАН, сопредседатель

• Ицыксон Владимир Михайлович, к.т.н., доцент кафедры

компьютерных систем и программных технологий СПбГПУ,

сопредседатель

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

сопредседатель

• Петренко Александр Константинович, д.ф.-м.н., зав. отделом

Технологий программирования Института системного

программирования РАН, профессор кафедры Системного

программирования ВМиК МГУ им. М.В.Ломоносова

• Басок Борис Моисеевич, к.т.н., доцент МИРЭА

• Глухих Михаил Игоревич, к.т.н., доцент, СПбГПУ, приглашенный

исследователь в Clausthal University of Technology

• Евтушенко Нина Владимировна, д.т.н., профессор, зав. кафедры

Информационных технологий в исследовании дискретных структур,

Радиофизический факультет, Национальный исследовательский

Томский государственный университет (ТГУ)

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

гуманитарный университет, Одесса, Украина

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

зав. лабораторией МПКБ

• Иванов Александр Николаевич, к.ф.-м.н.,

ведущий разработчик ООО «КоФиТе»

• Иткин Иосиф Леонидович, компания Exactpro Systems, координатор

• Камкин Александр Сергеевич, к.ф.-м.н., с.н.с. ИСП РАН;

• Климов Андрей Валентинович, зав. сектором методов анализа и

преобразования программ ИПМ им. М.В.Келдыша РАН

Page 13: TMPA-2013 Conference Proceedings

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

• Кириленко Яков Александрович, старший преподаватель,

МатМех СПбГУ

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

доцент ВМК МГУ

• Моисеев Михаил Юрьевич, к.т.н., доцент, СПбГПУ

• Пакулин Николай Витальевич, к.ф.-м.н., старший научный сотрудник

ИСП РАН

• Павлова Елена Анатольевна, к.т.н., координатор программ, Microsoft

• Прохоров Сергей Петрович, к.ф.-м.н., ИСП РАН, доцент МФТИ

• Соколов Валерий Анатольевич, д.ф.-м.н.,

проф., зав. каф. теоретической информатики ЯГУ им. П.Г. Демидова

• Федосеев Андрей Алексеевич, к.т.н., в.н.с. ИПИ РАН

• Филиппов Станислав Александрович, к.т.н., с.н.с. ИПИ РАН

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

• Цесько Вадим Александрович, старший разработчик, Яндекс

Page 14: TMPA-2013 Conference Proceedings

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

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

Page 15: TMPA-2013 Conference Proceedings

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

Регистрация

Открытие

Кофе-брейк

Обед

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

10 октября

Пакулин Н.

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

Ануреев И.

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

Иванников В., Камкин А., Чупилко М.

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

8:309:3010:15

11:15

11:45

12:15

12:45

13:15

13:45

14:00

16:00

17:00

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

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

17:45

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

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

ВЕРИФИКАЦИЯ

АППАРАТНЫЙ ТРЕК

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

Зайцев Д.15:30Эффективная универсальная сеть Слепцова

Page 16: TMPA-2013 Conference Proceedings

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

11 октября

Регистрация

ISTQB

Кофе-брейк

Обед

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

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

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

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

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

8:309:30

10:30

11:00

12:00

12:30

13:00

13:15

14:00

13:30

15:30

15:50

16:10 Гурьев Д., Гай М., Иткин И., Терентьев А.Высокопроизводительный генератор нагрузки для тестирования систем автоматизированной торговлиПрядкина Н., Крюков А.Использование MBT-подхода для верификации систем мониторинга и контроля на фондовых биржах

16:30

Тестирование совместимости протокольных подключений клиентов биржевых и брокерских систем

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

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

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

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

ТРЕЙДИНГОВЫЕ СИСТЕМЫ

Page 17: TMPA-2013 Conference Proceedings

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

Регистрация

Захаров В. А. Математические аспекты задачи обфускации программ

12 октября

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

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

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

9:00

9:30

10:30

11:00

12:30

12:45

13:30

14:00

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

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

16:45

17:00 Кофе-брейк

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

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

11:30 Кофе-брейк

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

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

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

11 октября

АНАЛИЗ ПРОГРАММ

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

Page 18: TMPA-2013 Conference Proceedings

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

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

Page 19: TMPA-2013 Conference Proceedings

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

Page 20: TMPA-2013 Conference Proceedings

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

Page 21: TMPA-2013 Conference Proceedings

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

Page 22: TMPA-2013 Conference Proceedings

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

𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑 = 𝑘𝑘(100 − 𝑇𝑇 ) 𝑘𝑘

𝑘𝑘1 < 𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑 < 𝑘𝑘2

𝑇𝑇 𝑇 70

𝑇𝑇 < 68

Page 23: TMPA-2013 Conference Proceedings

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

Page 24: TMPA-2013 Conference Proceedings

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

𝑀𝑀𝐼𝐼 𝑆𝑆

𝐼𝐼

Page 25: TMPA-2013 Conference Proceedings

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

𝜑𝜑𝐼𝐼

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

Page 26: TMPA-2013 Conference Proceedings

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

Page 27: TMPA-2013 Conference Proceedings

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

Page 28: TMPA-2013 Conference Proceedings

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

Page 29: TMPA-2013 Conference Proceedings

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

Page 30: TMPA-2013 Conference Proceedings

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

Page 31: TMPA-2013 Conference Proceedings

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

Page 32: TMPA-2013 Conference Proceedings

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

Page 33: TMPA-2013 Conference Proceedings

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

Page 34: TMPA-2013 Conference Proceedings

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

Page 35: TMPA-2013 Conference Proceedings

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

Page 36: TMPA-2013 Conference Proceedings

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

Верификация программно-конфигурируемыхсетей при помощи системы UPPAAL

Владислав Подымов, Ульяна Попеско

МГУ имени М.В. Ломоносова[email protected], [email protected]

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

Keywords: программно-конфигурируемая сеть, верификация, вре-менные автоматы, темпоральная логика, UPPAAL

1 Введение

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

Сеть OpenFlow состоит из коммутаторов, управляемых централизован-ным контроллером. Пакет, передаваемый по сети, обрабатывается контрол-лером существенно медленнее, нежели коммутатором, поэтому одной из ос-новных функций контроллера является организация работы коммутаторовтак, чтобы они обрабатывали большую часть пакетов, и лишь в исключи-тельных случаях пакеты обрабатывались бы на контроллере.

Организация работы коммутаторов заключается в установке правил втаблицы коммутации (flow tables), определяющих, как будут обрабатывать-ся те или иные пакеты. Правило состоит из шаблона, идентифицирующеговид пакетов, целочисленного приоритета, устраняющего неоднозначность в

Page 37: TMPA-2013 Conference Proceedings

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

2 Владислав Подымов, Ульяна Попеско

случае наложения шаблонов, целочисленного лимита времени, указываю-щего число секунд до истечения срока активности правила, и списка дей-ствий, описывающих обработку пакета. Также для каждого правила в этихтаблицах коммутатор содержит счетчики для учета количества и размераобрабатываемых пакетов.

Коммутатор обрабатывает приходящий пакет в 3 этапа. Сначала он вы-бирает правило из своей таблицы коммутации так, чтобы заголовок пакетасоответствовал шаблону этого правила. Если такового не найдено, комму-татор отправляет пакет контроллеру для дальнейшей обработки. Иначе вы-бирается совпадающее по шаблону правило с наибольшим приоритетом. Навтором шаге обновляются счетчики для выбранного правила. И наконец,к пакету поочередно применяются все действия, записанные в правиле. Кдопустимым действиям относятся output(op) и modify(h,n). По действиюoutput(op) пакет отправляется на порт op. Действие modify(h,n) предписы-вает переписать заголовочное поле h на n.

Контроллер устанавливает правила в таблицы коммутации, реагируя насобытия в сети. Такими событиями являются подключение нового коммута-тора к сети, удаление ранее действующего коммутатора из сети, события длясбора статистики, истечение лимита времени правила коммутатора. Такжеконтроллер оперирует функциями отправки сообщений коммутаторам: уста-новкой правил в таблицу коммутации, удалением всех правил с заданнымшаблоном из таблицы коммутации, отправкой пакета и действия для егообработки коммутатором.

В статье исследуется возможность верификации ПКС как распределен-ных систем реального времени. Для этого потребовалось решить следующиезадачи: 1) выбрать адекватное средство для построения сетей; 2) выбратьподходящее средство для верификации сетей как систем реального времени;3) построить корректный транслятор из выбранного средства построениясетей во входной язык нужной системы верификации; 4) провести экспе-риментальное исследование возможности применения выбранного средстваверификации для проверки спецификаций ПКС.

Стандарт OpenFlow включает в себя большое количество свойств и пред-писаний для коммутации пакетов в сети. Производители компонентов ком-пьютерных сетей используют лишь часть из них. Мы также ограничимся врассматриваемых вариантах. При моделировании правил таблиц коммута-ции не будем уделять внимание приоритетам и счетчикам, а из всех допусти-мых действий будем рассматривать только действия типа output(op). Сборстатистических данных в сети также не будет нас интересовать. С другойстороны, в нашу модель будут добавлены временные характеристики, опи-сывающие работу физических объектов сети. Посредством этого мы будемучитывать не только предписания стандарта OpenFlow, но и техническиевозможности коммутаторов и каналов.

Page 38: TMPA-2013 Conference Proceedings

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

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

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

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

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

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

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

Page 39: TMPA-2013 Conference Proceedings

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

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 включает в себя множество портов Porti, начальнуютаблицу коммутации Rulei ⊆ Porti ×H ×Real×Porti объема tab и времен-ные характеристики Limp

i , Rimpi , Ldef

i , Rdefi , Lar

i , Rari , Lcon

i , Rconi , естествен-

ным образом соотносящиеся с характеристиками коммутатора, описанными

Page 40: TMPA-2013 Conference Proceedings

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

Верификация ПКС при помощи системы UPPAAL 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 располагает следующими каналами: канал cari входного потокас временными характеристиками L = Lar

i , R = Rari , ведущий в специально

выделенный под него порт; канал cto coni , ведущий в контроллер из другого

специально выделенного порта, с характеристиками L = Lconi , R = Rcon

i ;канал cfrom con

i , ведущий от контроллера в третий специально выделенныйпорт коммутатора, с характеристиками L = R = 0. Таким образом, состоя-ние S ПКС включает в себя состояния scon контроллера, scom1 , . . . , scomn ком-мутаторов и sch1 , . . . , schm , sar1 , . . . , sarn , stocon1 , . . . , stoconn , sfromcon

1 , . . . , sfromconn

каналов ch между коммутаторами, ar от входного потока, to con к и from 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 происходит запись в таб-лицу коммутации правила, присланного контроллером. Во всех состояниях

Page 41: TMPA-2013 Conference Proceedings

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

6 Владислав Подымов, Ульяна Попеско

коммутатора Rule — текущая таблица коммутации, t — время нахожденияв текущем управляющем состоянии, h и p — хранимые пакет и порт.

Каналы могут могут находиться в состояниях (empty), (full, 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 → s′1, s

′2 означает то же самое для

пары компонент. Построение вычисления ПКС происходит по следующимправилам.

1. Получение пакета: scomi , sari = (start, Rule), (sent, h) → (select, 0, Rule,h, p), (empty).

2. Применение активного правила r = (p, h, x, p′): scomi = (select, Rule, t,h, p) → (hit, Rule, h, p′), если t ∈ [Limp

i , Rimpi ], r ∈ Rule.

3. Обработка истекшего правила r = (p, h, x, p′): scomi = (select, Rule, t, h, p)→ (miss, Rule′, h, p), если t ∈ [Limp

i , Rimpi ], r ∈ Rule и Rule′ = Rule\r.

4. Сброс пакета: scomi = (select, Rule, t, h, p) → (start, Rule), если t ∈[Limp

i , Rimpi ], |Rule| = tabi, все правила из Rule активны и ни одно из

них не имеет шаблона (p, h).5. Несоответствие шаблонов: scomi = (select, Rule, t, h, p) → (miss, Rule′,

h, p), где Rule′ получается из Rule удалением всех истекших правил.6. Начало перезаписи таблицы: scomi , sfrom con

i = (start, Rule), (sent, rule)→ (mod, 0, Rule), (sent, rule).

7. Успешная перезапись таблицы: scomi , sfrom coni = (mod, t, Rule), (sent, (p,

h, x, p′)) → (hit, Rule′, h, p′), (empty), если t ∈ [Ldefi , Rdef

i ], |Rule| < tabiи Rule′ = Rule ∪ (p, h, x, p′).

8. Неуспешная перезапись таблицы: scomi , sfrom coni = (mod, t, Rule), (sent,

rule) → (start, Rule), (empty), если t ∈ [Ldefi , Rdef

i ] и |Rule| = tab.9. Пересылка пакета коммутатору: scomi , schj = (hit, Rule, h, p), (empty) →

(start, Rule), (full, 0, h), если канал cj исходит из порта p коммутатораi.

10. Пересылка шаблона контроллеру: scomi , sto coni = (miss, Rule, h, p), (empty)

→ (start, Rule), (full, 0, (p, h)).11. Успешная обработка шаблона контроллером: scon, sto con

i = (idle), (sent,(p, h)) → (send, i, r), (empty), если (i, (p, h, x, p′)) ∈ con.

12. Неуспешная обработка шаблона контроллером: scon, sto coni = (idle), (sent,

(p, h)) → (idle), (empty), если (i, (p, h, x, p′)) /∈ con.

Page 42: TMPA-2013 Conference Proceedings

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

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

13. Пересылка правила от контроллера: scon, sfrom coni = (send, i, r), (empty)

→ (idle), (full, 0, r).14. Появление пакета в сети: sari = (empty) → (full, 0, h), если h ∈ H.15. Сброс пакета в окружение: scomi = (hit, Rule, h, p) → (start, Rule), если

ни один канал cj не исходит из порта p коммутатора comi.16. Доставка в канале: (full, t, o) → (sent, o), если t ∈ [L,R] для характе-

ристик L, R соответствующего канала.17. Продвижение времени: таймеры всех коммутаторов и каналов увеличи-

ваются на одну и ту же положительную величину d, времена жизниправил уменьшаются на эту же величину, и при этом:– если какой-либо канал находится в состоянии (full, t, o), то t+d ≤ R

для характеристики R этого канала;– если scomi = (select, Rule, t, h, p), то t+ d ≤ Rimp

i ;– если scomi = (mod, Rule, t), то t+ d ≤ Rdef

i .

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

Алгоритм Alg переводит ПКС в эквивалентную ей сеть временных автома-тов. Понятие эквивалентности обсуждается в следующем разделе.

Сеть N , получаемая в результате трансляции ПКС ((com1, . . . , comn),con, (c1, . . . , cm), H), содержит автоматы Hurry, Env, Stream, Chan, Acon

и Ai, i ∈ 1, . . . , n.Каждый канал ci моделируется булевыми переменными full[ci] (пакет

послан), ready[ci] (пакет доставлен), таймером t[ci] и переменными для хра-нения объектов, пересылаемых через канал. Сброс пакетов в окружение мо-делируется с помощью особого канала cenv. Также в сеть добавляются всеканалы cari , cto con

i , cfrom coni .

Автомат Hurry обеспечивает срочные дуги (т.е. дуги, выполняющиесянемедленно по выполнении их предусловий) и состоит из одной вершиныи петли, принимающей сигнал по срочному каналу hurry. К срочным ду-гам по умолчанию добавляется посылка сигнала по каналу hurry. Авто-мат Env удаляет пакеты из канала cenv и состоит из одной вершины исрочной петли с записью в переменную full[cenv] значения false. АвтоматStream генерирует пакеты, состоит из одной вершины и содержит наборсрочных петель, недетерминированно засылающий пакеты в каналы cari .Автомат Chan обеспечивает доставку пакетов каналами, состоит из однойвершины и содержит петлю для каждого канала c, помеченную предусло-вием full[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 записывает в локальные переменныеавтомата шаблон, присланный коммутатором, и номер этого коммутатора ив зависимости от наличия отправляемого обратно правила переходит либо

Page 43: TMPA-2013 Conference Proceedings

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

8 Владислав Подымов, Ульяна Попеско

обратно в idle, либо в send. Срочная дуга send → idle присваивает пере-менной full[c] значение true и записывает в переменную канала выбранноеправило.

Автомат Ai моделирует работу коммутатора comi и состоит из обычныхсостояний start, select, hit, miss, mod, соединенных через срочные вершины.Срочная дуга start → select записывает в локальные переменные автоматадоставленный через канал c пакет и порт, на который он пришел, и запи-сывает в переменную full[c] значение false. Состояние select, помеченноеинвариантом t ≤ Rimp

i , имеет одну исходяющую дугу в срочное состояниеl, помеченную предусловием t ≥ Limp

i . Здесь t — локальный таймер ком-мутатора. Из состояния l в зависимости от наличия шаблона происходитпереход в состояния hit и miss с модификацией таблицы согласно правилам2-5 семантики ПКС. Удаление многих правил из таблицы коммутации обес-печивается срочной вершиной l′ с петлей, удаляющей из таблицы истекшиеправила, и исходящей дугой, помеченной предусловием, утверждающим, чтоиз таблицы удалены все истекшие правила. Срочная дуга start → mod запи-сывает в локальные переменные автомата правило, доставленное каналомcfrom coni . Состояние mod помечено инвариантом t ≤ Rdef

i , исходящие из негодуги — предусловием r ≥ Ldef

i . В зависимости от того, заполнена ли табли-ца коммутации, из состояния mod автомат может либо перейти в состояниеstart, либо перейти в состояние hit с записью правила в таблицу.

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

Под корректностью алгоритма Alg понимается равновыполнимость формул,используемых в средстве UPPAAL, для исходной ПКС N и результирующейсети Alg(N). Ключевым понятием в доказательстве корректности алгорит-ма Alg является эквивалентность по прореживанию (stuttering equivalence)для систем переходов [6]. Неформально, такая эквивалентность означает,что если в каждом вычислении двух данных систем склеить все одинако-вые состояния, то мы получим одинаковые множества вычислений. Одина-ковыми полагаются состояния с совпадающими множествами выполнимыхформул. В работе [7] сформулирована следующая теорема.

Теорема 1 Если системы переходов M1, M2 эквивалентны по прорежива-нию и формула Φ логики LTL−X истинна для M1, то она также истиннадля M2.

Следующая теорема позволяет применить только что сформулирован-ную к системам переходов, описывающим поведение ПКС N и сети Alg(N).Система переходов, описывающая поведение сети временных автоматов, об-суждается, например, в [4]. Пусть TSA — система переходов, описывающаяповедение системы A.

Теорема 2 Пусть N — произвольная ПКС. Тогда системы переходов TSN

и TSAlg(N) эквивалентны по прореживанию.

Page 44: TMPA-2013 Conference Proceedings

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

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

Теорему обосновывают следующие рассуждения. Состояниям контрол-лера и коммутаторов ставятся в соответствие одноименные состояния полу-чающихся из них автоматов вместе с необходимыми значениями локальныхпеременных. Состояниям каналов ставятся в соответствие наборы значе-ний переменных full, ready и переменных для хранения данных. Одномуприменению семантических правил 1-17 соответствует последовательностьпереходов в сети временных автоматов через срочные состояния, и сменазначений переменных происходит только в одном месте последовательно-сти. В результате применения правила в ПКС и построенной по нему после-довательности переходов в сети соответствующие состояния переводятся всоответствующие.

Корректность алгоритма напрямую следует из приведенных теорем сучетом того, что формулы, проверяемые средством UPPAAL, могут бытьпереформулированы в терминах логики LTL−X .

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

В приложении приведена сеть автоматов, построенная транслятором по опи-санию сети на рисунке 1. Ниже приведены проверенные с помощью средстваUPPAAL свойства и их запись на языке запросов UPPAAL [3].

1. В работе системы не возникает блокировки:

A[] not deadlock

2. В сеть всегда будут поступать пакеты из внешней среды:

A <> forall(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 не выполняется. Это свидетельствует отом, что функционирование полученной сети временных автоматов соот-ветствует нашим ожиданиям и что предложенная схема верификации ПКС

Page 45: TMPA-2013 Conference Proceedings

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

10 Владислав Подымов, Ульяна Попеско

с помощью средства UPPAAL позволяет проверять свойства поведения ПКСкак системы реального времени.

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

Таблица 1. Время проверки свойств ПКС.

Свойство номер:1 2 3 4 5

Модель 1 - 1 секунда 1 секунда 7 секунд 1 секундаМодель 2 - 1 секунда 1 секунда 1 минута 2 секунды 1 минута 25 секундМодель 3 - 1 секунда 1 секунда 1 минута 1 минута 19 секундМодель 4 27 часов 1 секунда 1 секунда 1 секунда 1 секунда

8 Заключение

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

Список литературы

1. Casado M., Garfinkel T., Akella A., Fredman M., Boneh D., McKeown N.,Shenker S. SANE: A Protection Architecture for Enterprise Networks // 15-thUsenix Security Symposium, Vancouver, Canada, August 2006.

Page 46: TMPA-2013 Conference Proceedings

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

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

2. McKeown N., Anderson T., Balakrishnan H., Parulkar G., Peterson L., Rexford J.,Shenker S., Turner J. Openflow: 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 inComputer 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 finite Kripke structuresin 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 = false. Функция send(c, o) копиру-ет o в содержимое канала и выполняет присваивания c = true, c_ready =false, 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 только номерами задействованных каналов иконстантами, определяемыми количеством портов и объемом таблицы, и поэтой причие опущены.

Page 47: TMPA-2013 Conference Proceedings

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

12 Владислав Подымов, Ульяна Попеско

send

idle

!con_in[c]hurry!send(from_con[c], rule[r])

i = 0..2 -> !hit(rule[i], (c, p, h))

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

r = i

(i = 0..2) to_con_ready[i]hurry! get(to_con[i]), c = i

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

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

select

t <= 5 miss

hit

rewrite

t <= 3

start

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

t >= 3

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

i = 0..3!active[i]

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

hurry!send(to_con[0], (p, h))

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

(i = 0..3)active[i] && (rule_t[i] > rule_max[i])active[i] = false

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

i = 0..3 -> !hit(rule[i])

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

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

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

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

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

hurry?

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

s1

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

(i = 1..9 -> ok(c[i]))

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

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

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

Page 48: TMPA-2013 Conference Proceedings

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

Page 49: TMPA-2013 Conference Proceedings

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

P

S = (S, s0,→, L) S

s0 ∈ S →⊆ S×S

L : S → 2P

s0π = s0s1s2 . . . ∀ i ≥ 0 si → si+1

Page 50: TMPA-2013 Conference Proceedings

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

pi ∈ P

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

X F G U Xϕ

ϕ Fϕ ϕ

Gϕ ϕ

ψ U ϕ

ϕ

ψ F G

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

ϕ

ϕ s0

Page 51: TMPA-2013 Conference Proceedings

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

V

V

GX(V > V ⇒ OldValCond ∧ FiringCond ∧ V =NewValExpr) (1)

V

V

V

OldValCond

FiringCond V

NewValExpr

V

V

X

FiringCond OldValCond

FiringCond

V

OldValCond NewValExpr

V (1) ⇒

OldValCond i∧FiringCondi∧V =NewValExpr

i

V

GX(V < V ⇒ OldValCond ′∧ FiringCond ′

∧ V =NewValExpr ′ ) (1′)

Page 52: TMPA-2013 Conference Proceedings

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

(1) (1′)

V

GX(¬ V ∧ V ⇒ FiringCond ) (2)

V

GX( V ∧ ¬V ⇒ FiringCond ′ ) (2′)

(1) (1′)V FiringCond = FiringCond ′ = 1 NewValExpr = NewValExpr ′

OldValCond = ( V <NewValExpr) OldValCond ′ = ( V >NewValExpr )

GX(V > V ⇒ V <NewValExpr ∧ V =NewValExpr )

GX(V < V ⇒ V >NewValExpr ∧ V =NewValExpr )

GX(V =NewValExpr ) (3)

V (1) (1′)(2) (2′)

V (3)(3) NewValExpr

V

Page 53: TMPA-2013 Conference Proceedings

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

(V ) = 1V

V

V+ (1) V− (1′)

OldValCond FiringCond V :=NewValExpr V+

OldValCond ′ FiringCond ′V :=NewValExpr ′

V−

V

OldValCond i ∧ FiringCond i ∧ V =NewValExpr i

V V+ (2) V− (2′)

V FiringCond V := 1 V+

V FiringCond ′V := 0 V−

V (3)

V :=NewValExpr V

V

V V :=V

Page 54: TMPA-2013 Conference Proceedings

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

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

Page 55: TMPA-2013 Conference Proceedings

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

OldValCond FiringCond V := NewValExpr

OldValCond ′ FiringCond ′V := NewValExpr ′

V := V

V (2) (2′)

∼V FiringCond V := 1

V FiringCond ′V := 0

V :=V

V (3)V := NewValExpr

V NewValExpr

V XG(V =NewValExpr )

V =NewValExpr

G(V =NewValExpr )XG(V =NewValExpr )

V

V :=NewValExpr

Page 56: TMPA-2013 Conference Proceedings

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

Page 57: TMPA-2013 Conference Proceedings

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

Старт 1 2 3 4 5 6

40 0 44444

Ход

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

Игрок ПЛК

Победа

Игрок ПЛК

Page 58: TMPA-2013 Conference Proceedings

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

Лампы

Кнопки

ПЛК ВыходыВходы

Кнопка 1

PB1

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

ход по цифре 1 Лампа 1

Out1

ход по цифре 21

1

2

Лампа 2

Out2

Кнопка 2

PB2

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

2

Кнопка 3

PB3

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

3

Кнопка 4

PB4

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

4

Кнопка 5

PB5

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

5

Кнопка 6

PB6

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

6

Старт

PBStart

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

7

ход по цифре 3

3

Лампа 3

Out3

ход по цифре 4

4

Лампа 4

Out4

ход по цифре 5

5

Лампа 5

Out5

ход по цифре 6

6

Лампа 6

Out6

право хода у игрока

7

Ход

игрока

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

8

Игрок

ManWin

победил ПЛК

9

ПЛК

PLCWin

право хода у ПЛК

7

Ход ПЛК

Turn

Page 59: TMPA-2013 Conference Proceedings

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

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 ∧ ¬(PLCWin ∨ManWin) ∧ 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)))

Page 60: TMPA-2013 Conference Proceedings

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

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

G(Mv3 ∧ Sum =3 ⇒ ((¬ManWin ∧ ¬PLCWin)UPLCWin))

G(F(Mv)) ∧G(¬PBStart ∧X(PBStart) ⇒ (PLCWin ∨ManWin)) ⇒G(Mv4 ∧ Sum =4 ⇒ ((¬ManWin ∧ ¬PLCWin)UPLCWin))

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

G(Mv6 ∧ Sum =6 ⇒ ((¬ManWin ∧ ¬PLCWin)UPLCWin))

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

Page 61: TMPA-2013 Conference Proceedings

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

Page 62: TMPA-2013 Conference Proceedings

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

Page 63: TMPA-2013 Conference Proceedings

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

Page 64: TMPA-2013 Conference Proceedings

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

Page 65: TMPA-2013 Conference Proceedings

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

Page 66: TMPA-2013 Conference Proceedings

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

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

Игорь Ануреев

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

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

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

1 Введение

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

Дедуктивный верификатор применяется к аннотированной программена некотором целевом языке программирования. Аннотированная програм-ма на этом языке — это текст, построенный по определенным правилам⋆ Работа частично поддержана грантом РФФИ 11-01-00028-а и междисциплинар-

ным интеграционным проектом СО РАН 3 «Принципы построения онтологиина основе концептуализаций средствами логических дескриптивных языков».

Page 67: TMPA-2013 Conference Proceedings

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

из конструкций целевого языка и аннотаций. Аннотации описывают свой-ства программы на целевом языке. Аннотированная программа называет-ся корректной, если эти свойства выполняются. Обычно в качестве языкааннотаций используется некоторый логический язык. Задача дедуктивно-го верификатора — доказать корректность аннотированной программы илиуказать условия, при которых выполнение этой программы некорректно.

Дедуктивный верификатор рассматривает аннотированную программукак формулу некоторого логического исчисления (называемого аксиомати-ческой семантикой в контексте дедуктивной верификации) и преобразует еев наборы формул некоторого логического языка в соответствии с определен-ной стратегией логического вывода в этом исчислении таким образом, чтоиз истинности полученных в результате преобразования формул (называе-мых условиями корректности этой программы) следует корректность самойпрограммы.

Для доказательства условий корректности дедуктивный верификаторприменяет разного рода средства автоматической поддержки доказатель-ства (универсальные средства автоматического или интерактивного доказа-тельства такие, как, например, PVS или HOL; SAT-решате-ли, SMT-решатели и др.). Применительно к задаче дедуктивной верифи-кации будем называть эти средства решателями условий корректности.

В качестве логического исчисления в дедуктивных верификаторах обыч-но используется логика Хоара или ее расширения. Инструменты, базиру-ющиеся на логике отделимости (separation logic) и исчислении синонимов(alias calculus), также можно отнести к дедуктивным верификаторам в слу-чае, если эти инструменты базируются на некотором виде аксиоматическойсемантики.

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

В первом подходе дедуктивный верификатор разрабатывается напрямуюна некотором языке программирования общего назначения. Единственнымдостоинством этого подхода является большая степень свободы в оптимиза-ции разрабатываемого верификатора. Эта степень ограничена только уров-нем компетенций разработчика. Отметим недостатки подхода. Во-первых,при этом подходе высока сложность разработки, поскольку снижается уро-вень абстракции при переходе от концепта к реализации. Во-вторых, по тойже причине, обоснование корректности верификатора представляет слож-ную проблему. В-третьих, верификатор не является гибким, поскольку ори-ентирован на конкретные целевой язык, язык аннотаций и аксиоматическуюсемантику.

Во втором подходе аннотированная программа транслируется в програм-му на промежуточном языке, для которого уже имеются дедуктивные ве-

Page 68: TMPA-2013 Conference Proceedings

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

рификаторы. Дополнительно к разработке транслятора из целевого языкав промежуточный язык, также разрабатываются средства обратной связи,которые интерпретируют результаты, полученные при верификации про-граммы на промежуточном языке, в контексте исходной аннотированнойпрограммы. Как и в первом подходе, транслятор и средства обратной свя-зи реализуются на некотором языке программирования общего назначения.Примерами промежуточных языков, ориентированных на дедуктивную ве-рификацию, являются Boogie [1] и WhyML [2]. Этот подход имеет сле-дующие преимущества. При его реализации знания конкретной аксиома-тической семантики не требуется или требуется лишь в малой степени науровне пользования дедуктивными верификаторами, имеющимися для про-межуточного языка. Фактически разработка дедуктивного верификаторадля целевого языка состоит в разработке транслятора и требует лишь зна-ния операционной семантики целевого и промежуточного языков и (стати-ческой) семантики используемого языка аннотаций. Недостатки второгоподхода проявляются прежде всего в случае, когда промежуточный языксильно отличается от целевого языка. Во-первых, обоснование корректно-сти трансляции становится сложной задачей. Во-вторых, усложняется раз-работка средств обратной связи. В-третьих, при трансляции теряется струк-турная и семантическая информация, которая могла бы оптимизироватьгенерацию условий корректности. Эта потеря, например, может быть ре-зультатом трансляции структур данных целевого языка в структуры дан-ных промежуточного языка или результатом моделирования конструкцийцелевого языка конструкциями промежуточного языка. Помимо этого, раз-рабатываемый верификатор не является гибким, поскольку ориентированна конкретные целевой язык, язык аннотаций и дедуктивные верификато-ры, имеющиеся для промежуточного языка. Формат обратных связей, какправило, также не гибок.

В третьем подходе аннотированная программа транслируется в модельили теорию системы машинной поддержки доказательства (далее доказате-ля). К доказателям, используемым в дедуктивном подходе, относятся PVS,HOL, LCF2 и др. Можно выделить следующие преимущества этого под-хода. Во-первых, доказатели, как правило, основаны на логиках высшегопорядка, что позволяет использовать выразительные языки аннотаций вдедуктивных верификаторах. Во-вторых, доказатели используют продви-нутые техники доказательства для формул этих логик. В-третьих, эти тех-ники можно применять не только к доказательству условий корректности,но и при порождении условий корректности, таким образом оптимизируяих вывод. Отметим недостатки третьего подхода. Во-первых, доказателисложны в освоении. Во-вторых, разработка модели или теории также слож-на. В-третьих, доказательство условий корректности ограничено конкрет-ным доказателем, в который вкладываются аннотированные программы.В-четвертых, возникает непростая проблема доказательства соответствиямодели аннотированной программе. В-пятых, модель аннотированной про-граммы, как правило, не использует дополнительную информацию, доступ-

Page 69: TMPA-2013 Conference Proceedings

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

ную при компиляции этой программы, так как учитывание этой информа-ции усложнило бы модель и сделала бы ее непригодной на практике.

Предлагаемый нами подход нивелирует недостатки описанных подходов,сохраняя их преимущества, и может быть в дальнейшем развит в техно-логию разработки дедуктивных верификаторов. Он заключается в исполь-зовании предметно-ориентированного языка (далее ПОЯ) для разработкидедуктивных верификаторов.

2 Требования к предметно-ориентированному языку

Опишем требования, которые должны выполняться для ПОЯ. Набор этихтребований не претендует на полноту и скорее является квинтэссенцией опы-та, накопленного авторами в области дедуктивной верификации.

Требование 1. ПОЯ должен описывать объекты, которыми обычно опе-рирует дедуктивный верификатор. К ним относятся аннотированные про-граммы, состояния программ, правила дедуктивного вывода (аксиомати-ческой семантики) и стратегии их применения, условия корректности, ин-терфейсы к решателям условий корректности. Далее будем называть этиобъекты объектами верификации.

Требование 2. Форматы описания объектов верификации на ПОЯдолжны быть унифицированными для каждого типа объектов, т. е. не за-висеть от конкретных используемых в дедуктивном верификаторе языковпрограмм, аннотаций, правил и стратегий дедуктивного вывода, условийкорректности и решателей условий корректности. Тем самым, обеспечива-ются перечисленные выше преимущества второго и третьего подходов, обу-словленные трансляцией. Будем называть результаты трансляции объектовверификации в ПОЯ представлениями или образами этих объектов.

Требование 3. Представления объектов верификации на ПОЯ должныбыть структурно эквивалентными соответствующим им объектам. Струк-турная эквивалентность означает существование взаимно-однозначногоотображения между объектами и их представлениями на уровне структурыобъектов и, соответственно, структуры представлений. Тем самым нивели-руются недостатки второго и третьего подходов, обусловленные трансляци-ей. Во-первых, упрощается разработка транслятора объектов конкретногоязыка в их представления на ПОЯ. Во-вторых, при такой трансляции нетеряется информация. В-третьих, упрощается разработка средств обратнойсвязи (перехода от представлений объектов к самим объектам).

Требование 4. Для текстовых объектов верификации (объектов, явля-ющихся текстами) представления объектов на ПОЯ должны быть тексту-ально близкими к соответствующим им объектам. Текстуальная близостьозначает, что представления объектов по возможности должны выглядетьпохожими на сами объекты. В частности, они должны использовать такиеже ключевые слова и размещать их в том же самом порядке. В этом случаедостигается читабельность и понимание представлений объектов, сравни-мые с читабельностью и пониманием самих текстовых объектов. Это требо-

Page 70: TMPA-2013 Conference Proceedings

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

вание конфликтует с требованием 2, поэтому должен быть найден разумныйкомпромисс.

Требование 5. Представления объектов верификации на ПОЯ должныбыть концептуально близкими к соответствующим им объектам. Концеп-туальная близость означает, что представления используют ту же самуюконцептуальную структуру (понятия, атрибуты понятий, отношения междупонятиями), что и объекты. Так семантические сущности, описывающие со-стояния программ на современных языках программирования, имеют слож-ную концептуальную структуру, которую важно точно отражать на уровнепредставлений соответствующих объектов.

Требование 6. ПОЯ должен описывать средства оперирования с пред-ставлениями объектов, сооветствующие средствам, которые дедуктивныйверификатор использует для оперирования объектами верификации. Ихможно разделить на базовые и дополнительные.

К базовым относятся средства, необходимые для выполнения дедуктив-ной верификации, к дополнительным — средства, которые оптимизируютэтот процесс. Базовые средства включают средства взаимодействия с объ-ектами через их представления и средства выполнения правил и страте-гий дедуктивного вывода на представлениях объектов. Средства взаимо-действия включают трансляторы аннотированных программ конкретныхцелевых языков в их представления на ПОЯ, средства построения обрат-ных связей, средства взаимодействия с решателями условий корректностии т. д. Средства выполнения (интерпретации) правил и стратегий дедуктив-ного вывода, задаваемых в унифицированном формате на ПОЯ, позволя-ют реализовывать дедуктивные верификаторы, для которых эти правила истратегии являются параметрами.

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

Page 71: TMPA-2013 Conference Proceedings

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

могут быть использовано непосредственно для реализации простых реша-телей.

Требование 7. ПОЯ должен содержать развитый механизм сопоставле-ния с образцом как на уровне синтаксической структуры (требования 3 и 4),так и на уровне концептуальной структуры (требование 5) представленийобъектов. Сопоставление такого рода характерны для большинства средствоперирования представлениями объектов, перечисленных в требовании 6.

Требование 8. ПОЯ должен обеспечивать средства описания смыслаконструкций целевого языка (операционной семантики целевого языка). Этотребование необходимо для формального обоснования корректности разра-батываемого дедуктивного верификатора.

3 Использование языка Atoment в качестве ПОЯ

Язык Atoment [3] — результат наших исследований по автоматизации созда-ния операционной и аксиоматической семантик языков программирования.В процессе его разработки возникла концепция предметно-ориентированно-го подхода к дедуктивной верификации и были сформулированы требованияк ПОЯ для этой предметной области. Он не является идеальным кандида-том на роль ПОЯ, но обеспечивает компромиссные показатели по всем тре-бованиям к ПОЯ и при отсутствии на данный момент других подходящихязыков мы планируем использовать его для апробации этого подхода.

Язык Atoment обеспечивает описание объектов верификации (требова-ние 1). Он использует два унифицированных формата для представленийобъектов (требование 2), соответствующих текстовых и нетекстовым объек-там.

Текстовые объекты представляются выражениями языка Atoment. Вы-ражения — это унифицированная форма записи конструкций языкаAtoment, подобная спискам языка Лисп. Выражения строятся из атомовс помощью специальных символов, к которым относятся пробельные сим-волы и круглые скобки. Например, ab и (ab (cd ef) gh) — выражения.Атомом может быть любая последовательность Unicode символов, не со-держащая специальных символов и символа кавычек ("). Специальный видатомов — строки позволяют использовать в атоме специальные символы.Например, ab и "ab (\"ss)" — атомы. Требование 3 для текстовых объек-тов обеспечивается взаимно-однозначным соответствием между их структу-рой и структурой выражений, представляющих эти объекты. Рассмотрим,как обеспечивается выполнение требования 4 для текстовых объектов напримере представления конструкций целевого языка и языка условий кор-ректности. Ключевые слова целевого языка представляются атомами. Дляусловного оператора if A then B else C ключевые слова представляютсяатомами if, then и else. Сам оператор представляется выражением (if A′

then B′ else C′), где A′, B′, C′ — представления конструкций A, B, C целевогоязыка. Условия корректности, как и любые другие формулы, также пред-ставляются выражениями. Так наиболее близким представлением формулы

Page 72: TMPA-2013 Conference Proceedings

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

∀x((a ≤ x) ∧ (y ≤ b)) является выражение (∀ x ((a ≤ x) ∧ (y ≤ b))).Обычно для удобства ввода вместо этого выражения используется выраже-ние (forall x ((a <= x) and (x <= b))).

Нетекстовые объекты представляются конечными наборами символовязыка Atoment, а их (как правило, концептуальная) структура — состоя-ниями в языке Atoment. Символы в языке Atoment — это выражения вида(A), где A — последовательность атомов. Состояние в языке Atoment — этоотображение, которое сопоставляет символам их интерпретацию (значение).Значением символа в состоянии являются функции заданной местности, со-поставляющие кортежу элементов элемент (Подобно тому, как атом являет-ся наименьшей синтаксической единицей языка Atoment, элемент являетсяего наименьшей семантической единицей. Название Atoment является объ-единением двух слов — атом и элемент.). Местность этих функций совпадаетс числом спецификаторов аргументов, входящих в символ. Спецификатораргумента — это атом одного из видов +v или -v. Символы позволяют адек-ватно описывать концептуальную структуру (требование 5) семантическихсущностей целевого языка. Например, переменная может быть представленасимволами (-v is variable), (value of -v) и (type of -v). При такомпредставлении s(-v is variable)(x) = true, s(type of -v)(x) = int иs(value of -v)(x) = 2 означает, что переменная с именем x имеет тип intи значение 2 в состоянии s.

Средства оперирования с представлениями объектов (требование 6), ме-ханизм сопоставления с образцом (требование 7) и средства описания опера-ционной семантики целевого языка (требование 8) реализуются с помощьюпредметно-ориентированных правил перехода и контекстов их применения.Правило перехода — это выражение вида (if A var B P then C), где A, B,C — последовательности выражений, называемые образцом, спецификациейпеременных образца и телом правила, соответственно, необязательная по-следовательность выражений P обозначает дополнительные параметры пра-вила. Правила перехода суть средства трансформации конфигураций. Кон-фигурация на языке Atoment — это пара, состоящая из последовательностивыражений (далее программы на языке Atoment) и состояния. Правило (ifA var B P then C) применимо к конфигурации (D, s), если D имеет видE A′ F и A′ удовлетворяет образцу A, т. е. получается из A заменой пере-менных образца из B на некоторые выражения или последовательности вы-ражений (значения переменных образца). Результатом применения правилабудет конфигурация (E C′ F, s′), где C′ — результат замены в C перемен-ных образца их значениями. Контекст применения определяет, как получа-ется s′, может дополнительно модифицировать C′ и накладывать дополни-тельные условие на применимость правила. Контекст определяется видомправил перехода (операционные, дедуктивные, условные, онтологические ит. д.). Так средства выполнения (интерпретации) правил и стратегий де-дуктивного вывода применительно к некоторой аннотированной программеописываются дедуктивными правилами перехода, а операционная семанти-ка целевых языков — операционными правилами перехода.

Рассмотрим пример применения правила. Операционное правило

Page 73: TMPA-2013 Conference Proceedings

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

(if (jump E) (break) var (+s E) then (jump E))

применимо к программе (jump goto L) (break) (x := 3) и преобразуетее в программу (jump goto L) (x := 3). Состояние при этом не меняется.Спецификатор +s перед переменной образца E, означает, что ее значениемможет быть (возможно пустая) последовательность выражений. Если бы егоне было, значением E могло бы быть только выражение.

Предметно-ориентированные системы переходов определяют операцион-ную семантику выражений. Операционная семантика выражения U опреде-ляется множеством правил, образец которых включает выражение U′ такое,что U получается из U′ означиванием переменных образца. Таким образом,операционная семантика выражения определяется в контексте окружающихего выражений в программе на языке Atoment. Например, операционная се-мантика выражения (break) из примера выше определяется в контексте,когда этому выражению предшествует выражение (jump E′), где E′ — про-извольная последовательность выражений.

Комбинирование дедуктивных верификаторов и решателей условий кор-ректности осуществляется за счет предопределенных выражений языкаAtoment, описывающих основные структуры управления (последовательноевыполнение, разбор случаев, бэктрекинг и др.). Операционная семантикапредопределенных выражений задается напрямую, а не определяется пра-вилами перехода.

Для спецификации семантики формул (например, условий корректно-сти) используется денотационная семантика выражений. Денотационная се-мантика выражений — это отображение, которое сопоставляет выражениямих значения, принадлежащие множеству элементов языка Atoment (денота-ту). Значением атома является сам атом. Значение выражения, отличногоот атома, определяется семантикой символа, который является шаблономдля этого выражения. Так символ (+v + +v), интерпретируемый как опе-рация сложения чисел, является шаблоном для выражения (2 + (3 + 4))относительно сопоставленных аргументам выражений 2 и (3 + 4). Специ-фикатор аргумента +v означает, что в качестве значения аргумента беретсязначение сопоставленного выражения. Таким образом, значением выраже-ния (2 + (3 + 4)) будет 9. Спецификатор аргумента -v означает, что вкачестве значения аргумента берется само выражение. Этот спецификаториспользуется, например, в символе (forall -v -v), интерпретируемом какквантор всеобщности.

4 Применение предметно-ориентированного подхода

Рассмотрим применение предметно-ориентированного подхода на примереразработки дедуктивного верификатора для целевого языка, включающегопростые типовые конструкции языков программирования. Из-за недостаткаместа мы ограничимся только вопросами разработки операционной семанти-ки и логики безопасности (варианта аксиоматической семантики) для этихконструкций. Несмотря на свою простоту, пример иллюстрирует несколько

Page 74: TMPA-2013 Conference Proceedings

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

ключевых особенностей, лежащих в его основе: инкрементальность разра-ботки, использование вспомогательных конструкций, гибкость разработки,разрешение на месте побочных эффектов при дедуктивном выводе. Будемразрабатывать верификатор сразу для выражений, представляющих кон-струкции целевого языка, считая, что требования структурной эквивалент-ности и текстуальной и концептуальной близости удовлетворены.

Рассмотрим оператор блока ( A ), где A — последовательность опера-торов. Заметим, что такое представление близко к представлению этого опе-ратора на ряде императивных языков программирования. Опишем сначалаего операционную семантику. Первую версию семантики зададим правилом

(if ( A ) var (+s A) then A)

В соответствии с этой семантикой выполнение оператора ( A ) сводитсяк выполнению последовательности операторов A.

Предположим теперь, что целевой язык содержит средства передачиуправления (операторы посылки исключений, операторы break, continue,return и т. п.). В этом случае, такая семантика уже не подходит, посколькуоператор блока не должен выполняться, если перед ним произошла передачауправления. Для описания этой ситуации введем понятие выражения пере-хода и концепцию просачивания выражения переходов. Выражение перехо-да имеет вид (jump E), где E — последовательность выражений, которыекодируют информацию о том, какой оператор перехода сработал, и какуюинформацию он передал. Например, для оператора (break) соответствую-щее выражение перехода может иметь вид (jump break). Зададим вторуюверсию семантики блока правилами

(if ( A ) var (+s A) then A)

(if (jump E) ( A ) var (+s E) (+s A) then A)

Дополнительное второе правило обеспечивает просачивание выражения пе-рехода через оператор блока. Последовательность выражений E хранит ин-формацию, которая передается при переходе. Таким образом, мы фактиче-ски «программируем» операционную семантику конструкций целевого язы-ка на специализированном языке высокого уровня, уточняя ее на каждомшаге итерации. Как будет показано ниже, аналогичным образом «програм-мируются» правила и стратегии дедуктивного вывода. В этом заключаетсяинкрементальность разработки верификатора.

Эта версия, однако, не учитывает ситуацию, когда целевой язык включа-ет операторы перехода по метке (goto L) и пустые помеченные операторы(label L), оператор (label L) входит в A и в результате выполнения блокапорождается выражение перехода (jump goto L). В этом случае, выполне-ние должно быть продолжено с оператора (label L) последовательностиA, а в соответствии с текущей семантикой блока выражение перехода (jumpgoto L) будет просачиваться дальше за блок. Третья версия семантики бло-ка определяется правилами

(if ( A ) var (+s A) then A (gotoStop A))

(if (jump E) ( A ) var (+s E) (+s A) then A)

Page 75: TMPA-2013 Conference Proceedings

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

Вспомогательное выражение (gotoStop A) обрабатывает выражение пере-хода (jump goto L) в случае, когда оператор (label L) принадлежит A:

(if (gotoStop A) var A then)

(if (jump E) (gotoStop A) var (+s E) (+s A) then (matchCases (jump E)(if (jump goto L) var L then (matchCases (A)(if (B (label L) C) var (+s B) (+s C) then C (gotoStop A))(else (jump E))))

(else (jump E))))

Предопределенное выражение matchCases выполняет разбор случаев в соот-ветствии с образцом. Сначала оно формирует сопоставляемое выражение. Вправиле выше это выражения (jump E) и (A) для первого и второго вхожде-ния matchCases, соответственно. Затем для каждой ветви (if U var V thenW) оно выполняет сопоставление сформированного выражения с образцомU для спецификации переменных образца V таким же образом, как для пра-вила перехода. Первая подходящая ветвь выполняется таким же образом,как правило перехода. Если ни одна из ветвей не подошла, и matchCasesсодержит выражение (else W), то выполняется последовательность W. Впротивном случае, с помощью механизма бектрекинга выполняется откат кпредыдущей точке ветвления.

Эта версия операционной семантики для оператора блока иллюстрируетиспользование вспомогательных конструкций. Чтобы адаптировать правилаоперационной семантики, мы не меняем их, а добавляем вспомогательнуюконструкцию, которая специфицирует требуемую адаптацию, и для нее опи-сываем операционную семантику. Соответствующие вспомогательные кон-струкции используются и при описании аксиоматической семантики.

Рассмотрим теперь, как с помощью правил перехода описываются пра-вила и стратегии дедуктивного вывода. Особенностью нашего подхода яв-ляется то, что вместо логики Хоара используется ее расширение — логикабезопасности, предложенная в [4].

В логике Хоара ключевыми понятиями являются точки входа и выхода,которым соответствуют пред- и пост-условия. В ряде расширений логикиХоара допускается несколько точек входа и выхода.

В логике безопасности точек входа и выхода нет, и, соответственно, нетпредусловия и постусловия. Вместо этого ряд точек программы снабжаютсятак называемыми условиями безопасности. Программа корректна в логикебезопасности (безопасна), если при любом исполнении программы, если до-стигнута точка программы с условием безопасности, то это условие долж-но быть истинно. Таким образом, логику безопасности можно применять кпрограммам без явных точек входа или выхода, например операционнымсистемам или телекоммуникационным протоколам.

Важное свойство нашего подхода, являющееся одним из его преиму-ществ, заключается в том, что для многих конструкций целевого языкаправила логики безопасности структурно не отличаются от правил опера-ционной семантики. Таким образом, разработав операционную семантику

Page 76: TMPA-2013 Conference Proceedings

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

целевого языка, мы автоматически получаем большую часть правил логикибезопасности этого языка. Также в силу идентичности правил логики без-опасности и операционной семантики доказательство корректности правиллогики безопасности становится более простой задачей.

Рассмотрим правила логики безопасности для блока, соответствующиепоследней третьей версии операционной семантики:

(if ( A ) var (+s A) then A (gotoStop A))

(if (jump E) ( A ) var (+s E) (+s A) then A)

Таким образом, правила логики безопасности и операционной семантикидля блока совпадают. Однако логика безопасности для вспомогательноговыражения (gotoStop A) меняется, поскольку в ней используется, как и влогике Хоара, инвариант метки:

(if (gotoStop A) var A then)

(if (jump E) (gotoStop A) var (+s E) (+s A) then (matchCases (jump E)(if (jump goto L) var L then (matchCases (A)(if (B (label L inv I) C) var (+s B) (+s C) I then (assert I))(else (jump E))))

(else (jump E))))

Выражение I в помеченном операторе (label L inv I) соответствует ин-варианту метки L, т. е. I — условие безопасности, которое должно бытьистинным при любом достижении этого оператора. Предопределенное вы-ражение (assert I) добавляет условие безопасности I в соответствующуюточку.

Побочные эффекты затрудняют применение логики Хоара. Например,чтобы применить классическое правило логики Хоара к условному опера-тору (if A then B else C), требуется, чтобы условие A не имело побочныхэффектов (не меняло состояние программы). В нашем подходе такой про-блемы не возникает и условие A может иметь побочные эффекты, посколькупобочные эффекты не только в операционной семантике, но и в логике без-опасности, разрешаются на месте.

Правила операционной семантики для условного оператора имеют вид:

(if (if A then B else C) var A (+s B) (+s C) then A (cases(if ((val) = true) then B)(else C)))

(if (jump E) (if A) var (+s E) (+s A) then (jump E))

Предопределенное выражение cases выполняет разбор случаев. Выполня-ется первая ветвь (if U then V), для которой значение (денотационная се-мантика) выражения U равна true. Выполнение ветви заключается в вы-полнении последовательности выражений V. Если ни одна из ветвей не вы-полняется и cases содержит выражение (else W), то выполняется после-довательность W. В противном случае, с помощью механизма бектрекингавыполняется выполняется откат к предыдущей точке ветвления.

Page 77: TMPA-2013 Conference Proceedings

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

Как видно из первого правила, сначала вычисляется выражение A. Еслипри его вычислении происходят побочные эффекты, то они описываютсяправилами для соответствующих подвыражений выражения A. Результатвычисления выражения A сохраняется в нульместном символе (val). Затемвыполняется сравнение значения этого символа с true или false. Второеправило просачивает выражение перехода через условный оператор.

Правила логики безопасности для условного оператора совпадают с пра-вилами операционной семантики. Однако операционная семантика рядапредопределенных выражений, например cases, отличается для контекстовприменения, соответствующих операционным и дедуктивным правилам пе-рехода [3].

5 Заключение

В заключение, ответим на вопрос, зачем разрабатывать универсальный по-ход к созданию верификаторов, когда существующие дедуктивные вери-фикаторы для конкретных языков программирования нуждаются в суще-ственном улучшении. Во-первых, предлагаемый подход является предметно-ориентированным, что означает, что он предоставляет средства, позволя-ющие в полной мере учитывать особенности целевых языков программи-рования и используемых методов и техник дедуктивной верификации. Во-вторых, технология быстрой предметно-ориентированной разработки де-дуктивных верификаторов может оказаться востребованной, когда для це-левого языка не существует средств дедуктивной верификации. В-третьих,существующие дедуктивные верификаторы представляют собой черныеящики, что не позволяет, например, улучшить реализованную аксиоматиче-скую семантику или стратегию ее применения или скомбинировать опера-ционный, аксиоматический и дедуктивный подходы при генерации условийкорректности. В-четвертых, подход может быть применен для апробацииновых методов дедуктивной верификации специалистами в этой области.В-пятых, применение подхода к специально разработанным учебным язы-кам программирования позволяет использовать его в сфере образования.

Список литературы

1. Barnett M., Chang B.-Y.E., DeLine R., Jacobs B., Leino K.R.M. Boogie: A modularreusable verifier for object-oriented programs // Proc. of Conf. "Formal Methods forComponents and Objects Springer-Verlaf, Berlin, LNCS. 2006. Vol. 4111. P. 364–387.

2. Filliatre J.-C., Paskevich A. Why3 – where programs meet provers // Proc. of the22nd European Symposium on Programming, Springer-Verlaf, Berlin, LNCS. 2013.Vol. 7792. P. 125–128.

3. Ануреев И.C. Предметно-ориентированные системы переходов: объектная мо-дель и язык // Системная информатика. 2013. 1. С. 1–34.

4. Ануреев И.С. Дедуктивная верификация телекоммуникационных систем, пред-ставленных на языке Си // Моделирование и анализ информационных систем.2012. Т. 19. 6. С. 34–44.

Page 78: TMPA-2013 Conference Proceedings

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

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

средства Spin

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

СПб НИУ ИТМО [email protected], [email protected]

Аннотация. В данной статье рассмотрен комплексный подход к разработке и верификации распределенных автоматных программ, в которых иерархические автоматы могут реализовываться в разных потоках и взаимодействовать друг с другом. Предложен интерактивный подход к верификации распределенных автоматных программ при помощи инструмента Spin, который включает в себя автоматическое построение модели на языке Promela, приведение LTL-формулы в формат, определяемый инструментом Spin и построение контрпримера в терминах автоматов. На основе этого подхода создано инструментальное средство Stater, позволяющее создавать распределенную систему конечных автоматов, генерировать на ее основе программный код на целевых языках программирования и верифицировать ее при помощи верификатора Spin. Автоматы могут быть созданы в инструменте Stater, а также импортированы из Stateflow.

Ключевые слова: верификация, системы конечных автоматов, model checking, распределенные автоматные программы, Spin, LTL.

1 Введение

Формальные методы набирают все большую популярность при проверке программного обеспечения. При этом они не конкурируют с традиционным тестированием, а гармонично дополняют его. В данной работе рассматривается верификация методом проверки моделей (model checking) [1 – 3] при помощи верификатора Spin [4]. Метод проверки моделей характеризуется высокой степенью автоматизации [1]. По данной теме проводятся исследования в России и за рубежом [5 – 30]. Настоящая работа является продолжением работ [16, 22, 26].

Page 79: TMPA-2013 Conference Proceedings

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

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

2 Описание метода

2.1 Описание автоматной модели

В методе используется распределенная система взаимодействующих иерархических конечных автоматов [31 – 33]. При этом каждый иерархический автомат в системе работает в отдельном потоке. Под иерархическим автоматом в данной работе понимается система вложенных автоматов.

При этом каждый граф переходов задает не конкретный автомат, а тип автоматов (по аналогии с типом данных или классом в ООП). Назовем его автоматным типом. У каждого автоматного типа может быть несколько экземпляров (по аналогии с объектом в ООП). Назовем эти объекты автоматными объектами. Каждый автоматный объект имеет уникальное имя. В дальнейшем, если не указано иное, автоматные объекты будут называться просто автоматами.

Переходы автоматов осуществляются по событиям. Также на переходе могут быть охранные условия [34]. Однако что делать, если встретилось событие, по которому нет перехода? Традиционно в теории языков и вычислений детерминированный конечный автомат в таком случае переходит в недопускающее состояние. Но такое поведение не всегда удобно. Альтернативой переходу в недопускающее состояние может быть игнорирование таких событий, которое реализуется как неявное добавление пустых (без выходных воздействий) петель по всем событиям, переходы по которым не были добавлены пользователем. Таким образом, в предлагаемом методе автомат может работать в одном из двух режимов:

при появлении события, по которому нет перехода, это событие игнорируется (добавляются пустые петли по всем событиям);

при появлении события, по которому нет перехода, автомат переходит в недопускающее состояние.

Есть специальное событие «*», которое означает переход по любому событию, кроме тех, которые есть на других переходах из этого состояния (аналог default в блоках switch для C-подобных языков или else в условных конструкциях).

Автомат может иметь конечное число переменных целочисленных типов (включая массивы). Для переменных есть следующие модификаторы:

volatile – переменная может быть использована в любом месте программы; external – переменная может быть использована другим автоматом; param – переменная является параметром автомата. По умолчанию считается, что переменная не используется нигде, кроме как

на диаграмме переходов автомата. Все события общие для всей системы автоматов. Выходные воздействия автомата бывают двух типов:

Page 80: TMPA-2013 Conference Proceedings

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

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

1. На переходах и в состояниях может быть выполнен любой код. Однако верификатор и генератор кода перенесут его без изменений, поэтому код должен быть допустимым в целевом языке.

2. Запуск на переходах и в состояниях функций, определяемых пользователем на целевом языке программирования (после того, как сгенерирован код).

Автомат может иметь вложенные автоматы любого типа, кроме собственного, иначе будет бесконечная рекурсия. Циклическая рекурсия также запрещена.

Автомат может запускать поток с новым автоматом любого типа. Задается тип автомата <StateMachine> и имя <concreteStateMachine>. Нельзя запускать несколько автоматов с одним именем. Нельзя запускать автоматы своего типа.

Автомат может взаимодействовать с другим автоматом, выступая источником событий для него. Сообщения с событиями отправляются асинхронно.

Автомат может использовать отмеченные специальным модификатором переменные другого автомата.

Таким образом, в системе могут быть несколько автоматов с одинаковым графом переходов, более того, часть этих автоматов могут быть вложенными, а часть нет.

Все запреты проверяются при помощи верификации.

2.2 Описание процесса верификации

Для того чтобы провести верификацию программы методом проверки моделей, требуется составить модель программы и формализовать требуемые свойства (спецификацию) на языке темпоральной логики [1]. Так как в данной работе используется верификатор Spin, то языком темпоральной логики является LTL [1]. При этом модель автоматной программы строится автоматически и построение модели описано в разделе «Генерация кода на Promela».

Обозначим автоматный тип через AType, автоматный объект через aObject. Пусть состояния AType называются s0, s1 и т. д., в автомат поступают события e0, e1 и т. д., а переменные называются x0, x1 и т. д., внешние воздействия второго типа z0, z1 и т. д. Пусть автоматный тип AType имеет вложенный автомат, назовем его nested. Пусть AType запускает автомат, назовем его fork.

Процесс верификации состоит из следующих этапов:

1. Генерация кода на языке Promela [4]. В нашем случае она происходит автоматически.

2. Преобразование LTL-формул (переход от нотации автоматной программы в нотацию Spin).

3. Запуск верификатора Spin. 4. Преобразование контрпримера в термины исходной системы автоматов. В

нашем случае преобразование происходит автоматически.

Page 81: TMPA-2013 Conference Proceedings

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

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

Этапы процесса верификации будут описаны ниже. Эти этапы похожи на этапы ручной верификации при помощи Spin. Основным отличием является их максимальная автоматизированность и бо льшая приближенность модели к реализации, чем при верификации неавтоматных программ.

Интерактивность Одна из главных проблем в верификации методом проверки моделей – это

размер модели Крипке. Для того чтобы уменьшить модель (отсечь лишние подробности), мы будем ее строить интерактивно. Для обеспечения интерактивности вводится возможность выбирать, какие уровни абстракции автоматной системы входят в модель, а какие нет. Кроме того, модель структурируется понятным для человека образом для того, чтобы пользователь мог самостоятельно модифицировать построенную модель.

Переменные Для переменных введем следующие уровни абстракции:

1. Переменные в модели не учитываются. 2. Переменные в модель включены, но модель абстрагируется от их значения.

Недетерминированно выбирается, какое охранное условие будет верно. 3. Модель вычисляет значения переменных. При этом переменные могут быть

следующих видов: a. Локальные. Эти переменные могут быть изменены только

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

b. Параметры. Извне изменяются только один раз, при запуске автомата. В остальном они подобны локальным.

c. Публичные. Такие переменные могут быть изменены извне автоматной системы. В модели перед каждым переходом автомата таким переменным недетерминированно присваивается произвольное значение.

d. Совместно используемые. К таким переменным данного автомата имеют доступ другие автоматы, параллельно работающие с данным.

Параметры и публичные переменные могут быть также одновременно и совместно используемыми.

Параллелизм Вводятся два уровня: параллелизм включен либо выключен. Если нет, то в

модель не вводятся взаимодействия параллельных автоматов. Остаются только взаимодействия по вложенности.

Page 82: TMPA-2013 Conference Proceedings

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

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

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

внешняя среда и другие автоматы. Внешняя среда как источник событий для каждого автомата может работать в одном из трех режимов:

внешняя среда не взаимодействует с автоматом (события от внешней среды не приходят);

внешняя среда отправляет только те события, которые автомат может в данный момент обработать;

внешняя среда отправляет любые события. Другие автоматы как источники событий можно отключить, если отключить

параллелизм.

Процесс верификации Интерактивность процесса верификации основывается на возможностях

верификатора Spin и описана в разделе «Запуск верификатора Spin».

Генерация кода на языке Promela Все состояния каждого автоматного типа перенумеровываются и для них

создаются константы. Для каждого автоматного типа состояния нумеруются отдельно. Имя константы состоит из имени автоматного типа и имени состояния, разделенных знаком подчеркивания. Это сделано для того, чтобы состояния разных автоматов с одинаковыми именами не конфликтовали друг с другом. Пример:

#define AType_s0 0 #define AType_s1 1

Все события перенумеровываются и для них создаются константы. Для событий применяется сквозная нумерация. Пример:

#define e0 1 #define e1 1

Все внешние воздействия второго типа (вызываемые функции) перенумеровываются и для них создаются константы аналогично состояниям.

Все вызовы вложенных и запуски параллельных автоматов перенумеровываются аналогично состояниям.

Для каждого типа автоматов создается структура. Элементы структуры: byte state – номер текущего состояния; byte curEvent – номер последнего пришедшего события; byte ID – номер автомата; byte functionCall – номер последней запущенной функции, если

такая есть; byte nestedMachine – номер активного вложенного автомата, если

такой есть; byte forkMachine – номер запущенного автомата, если такой есть;

Page 83: TMPA-2013 Conference Proceedings

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

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

Все переменные автомата. Каждый тип автоматов записывается в inline-функцию переходов, которая

моделирует один шаг автомата. Переходы записываются при помощи охранных команд Дейкстры [34]. Эта функция в качестве параметров принимает структуру с данными автомата и событие и имеет следующий вид (листинг 1):

Листинг 1. Функция переходов.

inline Mnemo(machine, evt) atomic printf("machine%d. event_happened: %d \n", evt); machine.curevent = evt; if //Определение текущего состояния. ::(machine.state == AType_s0) -> printf("machine%d.state = AType.state0 \n", machine.ID); if //Выбор перехода. ::((evt == e1) && cond_1) -> machine.state = AType_s1; //Действия внутри состояния. ::((evt == e2) && cond_2) -> machine.state = AType_s2; //Действия внутри состояния. //Остальные переходы. :: else -> //Действия в случае, если не найден переход //по событию evt. fi; //Остальные состояния. fi;

Функция состоит из двух условий: внешнего и внутреннего. Внешнее условие определяет состояние, в котором находится автомат. Внутренне условие определяет переход в следующее состояние. Каждый вариант внутреннего условия соответствует одному из переходов из текущего состояния автомата и состоит из двух частей: проверка события и проверка условия на переходе. Условия на переходах в листинге 1 обозначены как cond_1, cond_2 и т. д.

Для каждого экземпляра автомата создается экземпляр структуры и канал, по которому происходит передача событий.

Page 84: TMPA-2013 Conference Proceedings

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

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

Для каждого экземпляра автомата, кроме вложенных, создается процесс, который извлекает из канала событие и запускает функцию переходов автомата с этим событием.

Для каждого экземпляра автомата, кроме вложенных, создается процесс, который недетерминированно выбирает событие и отправляет его в канал автомата. Этот процесс эмулирует внешнюю среду. В зависимости от уровня абстракции по источникам событий этот процесс выбирает событие из всего списка событий (внешняя среда отправляет любые события), из списка переходов текущего автомата (внешняя среда отправляет только те события, которые автомат может в данный момент обработать) либо не активен и удален из модели (внешняя среда не взаимодействует с автоматом).

Для публичных переменных перед каждым шагом автомата вызывается специальная функция, которая эти переменные недетерминированно изменяет.

Для переменных-параметров такая функция вызывается один раз – при запуске автомата.

Если по данному событию нет перехода, и в текущем состоянии есть вложенный автомат, то запускается вложенный автомат (запускается встраиваемая функция автомата).

Если в текущем состоянии автомат запускает другой автомат, то запускается заранее созданный процесс запускаемого автомата, а также .

Если автомат отправляет сообщение с событием другому автомату, то он записывает номер события в канал этого автомата.

Преобразование LTL-формул Расширим нотацию LTL-формул верификатора Spin. В фигурных скобках

будем записывать высказывания в терминах рассматриваемой автоматной модели. Добавим следующие высказывания:

1. aObject.si, которое означает, что автомат aObject перешел в состояние si.

2. aObject.ei, которое означает, что в автомат aObject пришло событие ei. 3. aObject.zi, которое означает, что автомат aObject вызвал функцию

(внешнее воздействие) zi. 4. aObject->nested, которое означает, что в автомате aObject управление

передано вложенному автомату nested. 5. aObject || fork, которое означает, что автомат aObject запустил

автомат fork. 6. Бинарные логические операции с переменными автоматов, например, aObject.x0 >= fork.x0[fork.x1].

Пример LTL-формулы в расширенной нотации:

[] (aObject.x0 <= 5 U aObject.s1) (1)

Алгоритм преобразования формулы в нотацию Spin следующий:

1. Все высказывания в фигурных скобках перенумеровываются.

Page 85: TMPA-2013 Conference Proceedings

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

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

2. Каждое такое высказывание преобразовывается в терминах модели на Promela и записывается в макрос.

3. Макросы подставляются в исходную LTL-формулу.

Макросы записываются следующим образом:

1. Автомат aObject перешел в состояние si: (aObject.state == si). 2. В автомат aObject пришло событие ei: (aObject. curEvent == ei). 3. Автомат aObject вызвал функцию (внешнее воздействие) zi: (aObject. functionCall == zi).

4. В автомате aObject управление передано вложенному автомату nested: (aObject. nestedMachine == nested).

5. Автомат aObject запустил автомат fork: (aObject. forkMachine == fork).

Формула (1) будет преобразована алгоритмом в следующий вид:

#define p0 (aObject.x0 <= 5) #define p1 (aObject.state == AType_s1) ltl f0 [] (p0 U p1)

Spin поддерживает несколько LTL-формул в одной модели, поэтому формулы нумеруются f0, f1, и т. д.

Запуск верификатора Spin Верификация построенной нами модели при помощи инструмента Spin

состоит из следующих этапов:

1. Построение верификатора pan. При запуске к ключом -a по модели на языке Promela Spin генерирует верификатор pan на языке C.

2. Компиляция верификатора pan. При компиляции можно определить константы, которые влияют на то, как в памяти будет храниться модель Крипке [1]. Наиболее компактный вариант задается константой BITSTATE, однако в этом случае происходит аппроксимация, и верификация может быть не точна.

3. Запуск верификатора pan. Верификатор pan также может быть запущен с разными ключами, важнейший из которых является –a (поиск допускающих циклов).

4. Анализ контрпримера. Описан в разделе «Преобразование контрпримера».

Интерактивность достигается за счет предоставления пользователю возможности использования вышеперечисленных вариантов работы на этапах верификации.

Преобразование контрпримера

Page 86: TMPA-2013 Conference Proceedings

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

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

Для того чтобы было удобнее понимать контрпример, приведем метод автоматической трансляции контрпримера, который получается на выходе верификатора Spin, в термины используемой автоматной модели.

Для каждого действия автомата создается пометка при помощи функции printf. На языке Promela функция printf работает аналогично функции printf из языка C [35]. Во время случайной симуляции [4] она выводит текст на экран, а во время верификации этот текст появляется в контрпримере. Остается его считать и вывести пользователю. Подробнее преобразование контрпримера описано в работе [26].

Корректность построения модели Построенная функция переходов автомата в модели на Promela соответствует

его графу переходов, так как содержит в себе ровно все его состояния и ровно все переходы для каждого состояния. Состояние каждого автомата хранится в его поле state, и в модели на Promela это поле не изменяется нигде, кроме функции переходов. Поэтому, атомарные высказывания о состояниях автомата тождественны соответствующим атомарным высказываниям в модели.

Номер события передается в функцию переходов в качестве параметра. В функции перехода этот номер присваивается полю curEvent. Других присваиваний полю curEvent нет. Поэтому, атомарные высказывания о событиях, пришедших в автомат, эквивалентны соответствующим атомарным высказываниям в модели.

Выходные воздействия второго типа перенумерованы и в момент вызова их номер присваивается полю functionCall. Поэтому, атомарные высказывания о выходных воздействиях второго типа эквивалентны соответствующим атомарным высказываниям в модели.

Выходные воздействия первого типа, которые могут являться любым кодом, записываются в модель без изменения за исключением добавления названия структуры автомата.

Аналогично с остальными вариантами атомарных высказываний. На основе изложенного можно сделать вывод о том, что LTL спецификация

равновыполнима на исходной системе автоматов и в модели на Promela.

2.3 Генерация программного кода

Метод разработан для объектно-ориентированных языков, но может быть расширен и для прочих языков. Однако это выходит за рамки данного исследования.

В отличие от таких инструментов, как Unimod [36] и Stateflow [37] в данном подходе предлагается генерировать не самостоятельную программу, а подпрограмму. Для объектно-ориентированных языков это набор классов, который пользователь может включить в свою программу. Для того, чтобы обеспечить удобство использования сгенерированного кода, делаются следующие шаги (ограничение на размер статьи не позволяет подробно описать алгоритмы первичной и повторной генерации кода, отметим лишь, что они

Page 87: TMPA-2013 Conference Proceedings

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

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

используют конечные автоматы и были разработаны при помощи самого инструментального средства Stater):

Для каждого автоматного типа генерируется отдельный класс в отдельном файле. Такой класс называется автоматизированным классом [33].

Сгенерированный класс содержит функцию переходов для автомата, перечисление, содержащее события, необходимые переменные для переходов и определения функций (выходных воздействий второго типа), в которые пользователь может дописать собственный код, и этот код не исчезнет при повторной генерации кода.

В коде специальными комментариями помечаются места, которые полностью переписываются, и в которые не следует писать пользовательский код. Пользовательский код из остальных мест будет полностью сохранен.

Если пользователь добавит новые выходные воздействия второго типа, то их определения будут добавлены к сгенерированному коду.

Пользователь может задать пространство имен (или пакет в языке Java), в котором будет находиться сгенерированный код. Если между генерациями кода пространство имен было удалено, то оно будет восстановлено.

Если пользователь добавит к автоматизированному классу наследование от базового класса или интерфейса, то повторная генерация кода сохранит это наследование.

Генерируются вспомогательные классы, включая менеджер потоков, которые обеспечивают взаимодействие автоматов, находящихся в разных потоках. Если многопоточность не требуется, их генерацию можно отключить.

Пользователь может ввести произвольное количество автоматных объектов, которые будут запущены при запуске менеджера потоков.

2.4 Хранение диаграмм

При совместной разработке программы несколькими разработчиками существует проблема объединения программного кода, когда один файл редактируется несколькими разработчиками одновременно. Для обычных программ эта проблема решается при помощи систем контроля версий (SVN [38], Git [39], Mercurial [40] и т. д.). Однако системы контроля версий хорошо объединяют только текстовые файлы. Диаграммы графов переходов конечных автоматов у популярных инструментов плохо приспособлены для совместной разработки. Для того чтобы облегчить объединение диаграмм, в данной работе предлагаются следующие свойства, которыми должен обладать формат хранения диаграмм:

1. Формат должен быть текстовым. 2. Каждая диаграмма должна быть в отдельном файле или в отдельном

множестве файлов.

Page 88: TMPA-2013 Conference Proceedings

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

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

3. Структура диаграммы хранится в отдельных файлах от информации, которая нужна для отображения диаграммы.

3 Описание инструментального средства Stater

Для поддержки предложенного метода было разработано инструментальное средство Stater. Оно позволяет следующее:

создавать распределенную систему конечных иерархических автоматов; импортировать конечные автоматы из Stateflow; верифицировать созданную систему конечных автоматов при помощи

верификатора Spin; генерировать программный код по созданной системе конечных

автоматов. Инструментальное средство Stater использовалось при разработке самого

себя, а именно модулей загрузки диаграмм из файла и преобразования LTL-формул, а также модуля генерации кода.

Ни предложенный метод, ни разработанное на его основе инструментальное средство Stater не претендуют на полноту верификации систем, разработанных в Stateflow. Это связано, в первую очередь, с тем, что спецификация к Stateflow имеет более 1300 страниц [41].

4 Пример

Продемонстрируем работу метода на примере прототипа программы управления гусеничным шасси для робота. В шасси два двигателя: по одному на левую гусеницу и на правую. Прототип программы состоит из двух автоматных типов: AEngine и AManager. Автомат manager типа AManager Два автомата left и right типа AEngine (рис. 1) управляют соответственно левым и правым двигателями.

Page 89: TMPA-2013 Conference Proceedings

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

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

Рис. 1. Диаграмма переходов автоматного типа AEngine

Автомат типа AManager (рис. 2) отправляет команды на управление двигателями в зависимости от команд для шасси. При входе в состояния он отправляет следующие события автоматам AEngine (слева от стрелки написано имя автомата, справа – событие):

Stopped: left ← stop, right ← stop. MoveForward: left ← forward, right ← forward. MoveBackward: left ← backward, right ← backward. TurnRight: left ← backward, right ← forward. TurnLeft: left ← forward, right ← backward. ForwardRight: left ← stop, right ← forward. ForwardLeft: left ← forward, right ← stop. BackwardRight: left ← backward, right ← stop. BackwardLeft: left ← stop, right ← backward.

Page 90: TMPA-2013 Conference Proceedings

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

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

Рис. 2. Диаграмма переходов автоматного типа AManager

Проверим свойство: «В любой момент если поступила команда «стоп», то будет подана команда остановки левого двигателя». Мы не можем проверить, что остановился, так как это утверждение относится к аппаратной части. Формализуем это свойство. Высказывание «Поступила команда «стоп» означает, что в автомат manager пришло событие stop. В нотации Stater оно записывается следующим образом: manager.stop. Высказывание «подана команда остановки левого двигателя» означает, что автомат left вызвал функцию EngineStop. В нотации Stater оно записывается следующим образом: left.EngineStop. Поэтому, свойство переписывается так: в любой момент в автомат manager пришло событие stop, следовательно, в будущем автомат left вызовет функцию EngineStop:

G (manager.stop => (F left.EngineStop)) (2)

В итоге получаем следующий вид:

[] ( manager.stop -> (<> left.EngineStop )) (3)

Запускаем верификацию и получаем ответ, который означает, что свойство выполняется в построенной системе:

0. [] ( manager.stop -> (<> left.EngineStop )) Verification successful!

Page 91: TMPA-2013 Conference Proceedings

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

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

Источники

1. Кларк Э., Грамберг О., Пелед Д. Верификация моделей программ: Model Checking. М.: МЦНМО, 2002.

2. Вельдер С. Э., Лукин М. А., Шалыто А. А., Яминов Б. Р. Верификация автоматных программ. СПб.: Наука, 2011.

3. Карпов Ю. Г. Model Checking: верификация параллельных и распределенных программных систем. СПб.: БХВ-Петербург, 2010.

4. Официальный сайт инструмента Spin. http://spinroot.com 5. Mikk E., Lakhnech Y., Siegel M. , Holzmann G. J. “Implementing Stateacharts in

Promela/SPIN” in Proc. of WIFT'98, 1998 6. Latella D., Majzik I., Massink M. Automatic verification of a behavioral subset

UML stetechart diagrams using the SPIN model-checker // Formal Aspects of Computing 11:637–664, 1999.

7. Lilius, J., Paltor I. P. Formalising UML State Machines for Model Checking, in: R. B. France and B. Rumpe, editors, Proc. 2nd Int. Conf. UML, Lect. Notes Comp. Sci. 1723 (1999), pp. 430–445.

8. Eschbah R. A verification approach for distributed abstract state machines. // PSI '02 109-115, 2001. http://dl.acm.org/citation.cfm?id=705973

9. Shaffer T., Knapp A., Merz S. Model checking UML state machines and collaborations. //Electronic notes in theoretical computer science 47:1-13, 2001.

10. Tiwari A.. Formal semantics and analysis methods for Simulink Stateow models. Technical report, SRI International, 2002. http://www.csl.sri.com/~tiwari/~stateflow.html

11. Roux C., Encrenaz E. CTL May Be Ambiguous when Model Checking Moore Machines. UPMC LIP6 ASIM, CHARME, 2003. http://sed.free.fr/cr/charme2003.ps

12. Gnesi S., Mazzanti F. On the fly model checking of communicating UML state machines. 2004. http://fmt.isti.cnr.it/WEBPAPER/onthefly-SERA04.pdf

13. Gnesi S., Mazzanti F. A model checking verification environment for UML statecharts / Proceedings of XLIII Congresso Annuale AICA, 2005. http://fmt.isti.cnr.it/~gnesi/matdid/aica.pdf

14. Виноградов Р. А., Кузьмин Е. В., Соколов В. А. Верификация автоматных программ средствами CPN/Tools // Моделирование и анализ информационных систем. 2006. 2, с. 4–15. http://is.ifmo.ru/verification/_cpnverif.pdf

15. Васильева К. А., Кузьмин Е. В. Верификация автоматных программ с использованием LTL // Моделирование и анализ информационных систем. 2007. 1, с. 3–14. http://is.ifmo.ru/verification/_LTL_for_Spin.pdf

16. Лукин М. А. Верификация автоматный программ. Бакалаврская работа. СПбГУ ИТМО, 2007. http://is.ifmo.ru/papers/_lukin_bachelor.pdf

17. Яминов Б. Р. Автоматизация верификации автоматных UniMod-моделей на основе инструментального средства Bogor. Бакалаврская работа. СПбГУ

Page 92: TMPA-2013 Conference Proceedings

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

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

ИТМО, 2007. http://is.ifmo.ru/papers/_jaminov_bachelor.pdf

18. Ma G. Model checking support for CoreASM: model checking distributed abstract state machines using Spin. 2007. http://summit.sfu.ca/item/8056

19. David A., Moller O., Yi W. Formal Verification of UML Statecharts with Real-time Extensions. / Formal Methods 2006

20. Егоров К. В., Шалыто А. А. Методика верификации автоматных программ // Информационно-управляющие системы. 2008. 5, с. 15–21. http://is.ifmo.ru/works/_egorov.pdf

21. Курбацкий Е. А. Верификация программ, построенных на основе автоматного подхода с использованием программного средства SMV // Научно-технический вестник СПбГУ ИТМО. Вып. 53. Автоматное программирование. 2008, с. 137–144. http://books.ifmo.ru/ntv/ntv/53/ntv_53.pdf

22. Лукин М. А., Шалыто А. А. Верификация автоматных программ с использованием верификатора SPIN // Научно-технический вестник СПбГУ ИТМО. Вып. 53. Автоматное программирование. 2008, с. 145–162. http://books.ifmo.ru/ntv/ntv/53/ntv_53.pdf

23. Гуров В. С., Яминов Б. Р. Верификация автоматных программ при помощи верификатора UNIMOD.VERIFIER // Научно-технический вестник СПбГУ ИТМО. Вып. 53. Автоматное программирование. 2008, с. 162–176. http://books.ifmo.ru/ntv/ntv/53/ntv_53.pdf

24. Егоров К. В., Шалыто А. А. Разработка верификатора автоматных программ // Научно-технический вестник СПбГУ ИТМО. Вып. 53. Автоматное программирование. 2008, с. 177–188. http://books.ifmo.ru/ntv/ntv/53/ntv_53.pdf

25. Prashanth C.M., Shet K. C. Efficient Algorithms for Verification of UML Statechart Models. // Journal of Software. 2009. Issue 3 pp 175-182.

26. Лукин М. А. Верификация визуальных автоматных программ с использованием инструментального средства SPIN. СПбГУ ИТМО, 2009. http://is.ifmo.ru/papers/_lukin_master.pdf

27. Ремизов А. О., Шалыто А. А. Верификация автоматных программ / Сборник докладов научно-технической конференции «Состояние, проблемы и перспективы создания корабельных информационно-управляющих комплексов. ОАО «Концерн Моринформсистема Агат». М.: 2010, с. 90–98. http://is.ifmo.ru/works/_2010_05_25_verific.pdf

28. Клебанов А. А., Степанов О. Г., Шалыто А. А. Применение шаблонов требований к формальной спецификации и верификации автоматных программ / Труды семинара «Семантика, спецификация и верификация программ: теория и приложения». Казань, 2010, с. 124–130. http://is.ifmo.ru/works/_2010-10-01_klebanov.pdf

29. Вельдер С. Э., Шалыто А. А. Верификация автоматных моделей методом редуцированного графа переходов // Научно-технический вестник СПбГУ ИТМО. 2009. Вып. 6(64), с. 66–77. http://is.ifmo.ru/works/_2010_01_29_velder.pdf

Page 93: TMPA-2013 Conference Proceedings

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

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

30. Chen C., Sun J., Liu Y., Dong J., Zheng M. Formal modeling and validation of Stateflow diagrams // International Journal on Software Tools for Technology Transfer. 2012. Issue 6, pp 653 – 671.

31. Шалыто А. А. Switch-технология. Алгоритмизация и программирование задач логического управления. СПб.: Наука, 1998. http://is.ifmo.ru/books/switch/1

32. I. Cardei, R. Jha, M. Cardei. Hierarchical architecture for real-time adaptive resource management. Secaucus, NJ, USA: Springer-Verlag, 2000.

33. Поликарпова Н. И., Шалыто А. А. Автоматное программирование. СПб.: Питер, 2010. http://is.ifmo.ru/books/_book.pdf

34. Dijkstra E.W. Guarded commands, non-determinacy and formal derivation of programs // CACM. 18. 1975. 8.

35. Последний черновик спецификации языка C. http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf

36. Официальный сайт проекта UniMod. http://unimod.sf.net 37. Официальный сайт продукта Stateflow. http://www.mathworks.com/products/stateflow/

38. Официальный сайт проекта SVN. http://subversion.apache.org

39. Официальный сайт проекта Git. http://git-scm.com/ 40. Официальный сайт проекта Mercurial. http://mercurial.selenic.com/

41. The MathWorks. Stateflow and Stateflow coder – User's Guide. 2009.

Page 94: TMPA-2013 Conference Proceedings

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

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

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

В.П. Иванников, А.С. Камкин, М.М. Чупилко

Федеральное государственное бюджетное учреждение наукиИнститут системного программирования Российской академии наук (ИСП РАН),

109004, г. Москва, ул. Александра Солженицына, д. 25.ivan,kamkin,[email protected]

Аннотация Проверка корректности поведения HDL-моделей явля-ется неотъемлемой частью динамической верификации аппаратуры.Как правило, она основана на сравнении поведения HDL-модели споведением эталонной модели, разработанной на языке программи-рования. В процессе верификации на обе модели подается одна и таже последовательность стимулов; реакции перехватываются и срав-ниваются друг с другом. Из-за абстрактности эталонной модели со-поставление трасс не является тривиальной задачей: порядок собы-тий может не совпадать, а некоторые события одной трассы могутотсутствовать в другой. В работе рассматривается метод динамиче-ского сопоставления трасс для моделей аппаратуры разного уровняабстракции. Метод был успешно применен в нескольких промышлен-ных проектах по верификации модулей микропроцессоров.

1 Введение

Несмотря на развитие формальных методов, динамическая верификацияостается основным методом проверки сложной цифровой аппаратуры [1].Объектом верификации выступают не сами устройства, а их модели, раз-работанные на специальных языках описания аппаратуры (HDL, HardwareDescription Languages), например, на Verilog или VHDL (такие модели на-зываются HDL-моделями) [2]. С одной стороны, HDL-модели представляютоснову для автоматизированного производства интегральных схем; с другойстороны, это имитационные модели, поведение которых можно анализиро-вать в специальных средах (симуляторах). Для автоматизации проверкикорректности поведения HDL-моделей разрабатываются мониторы, кото-рые перехватывают события на входах и выходах (стимулы и реакции) ипроверяют допустимость получаемой трассы [3].

Существует множество подходов к формальному описанию поведения,позволяющих автоматизировать создание мониторов: расширенные регуляр-ные выражения [4], контрактные спецификации [5], системы правил [6],

Page 95: TMPA-2013 Conference Proceedings

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

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

темпоральные утверждения [7], однако указанные формализмы не покры-вают всех потребностей индустрии. Большинство компаний, проектирую-щих аппаратуру, для оценки проектных решений используют исполнимыемодели, разработанные на языках программирования (прежде всего, на C иC++) [8]. Экономически целесообразно использовать эти модели и для вери-фикации создаваемой аппаратуры, в частности, для проверки корректностиповедения HDL-моделей.

При наличии исполнимой модели применяют следующую схему провер-ки корректности поведения: эталонная модель (по терминологии тестиро-вания соответствия, спецификация) выполняется совместно с проверяемойHDL-моделью (реализацией); на спецификацию поступает та же последова-тельность стимулов, что и на реализацию; реакции обеих моделей перехва-тываются монитором и сравниваются. Основная проблема указанной схемысвязана с обобщенным характером спецификации, из-за чего порядок реак-ций, выдаваемых спецификацией и реализацией, а также их состав могутразличаться. Перед тем как использовать эталонную модель для монито-ринга, необходимо понять, насколько она абстрактна и насколько можнодоверять производимым ею трассам.

В работе предлагается способ построения мониторов для HDL-моделейаппаратуры, адаптируемый для эталонных моделей разного уровня абстрак-ции. Рассматриваемый подход может быть формализован на основе моделичастично упорядоченных мультимножеств [9]. Поведение спецификации иреализации описывается временными трассами над общим алфавитом. Све-дения об абстрактности спецификации позволяют обобщать последователь-ности выдаваемых реакций в частично упорядоченные мультимножества,в которых для каждой реакции задан допустимый временной интервал.Монитор проверяет, что трасса реализации является линеаризацией обоб-щенной трассы спецификации (или ее подмножества) и реакции реализацииудовлетворяют ограничениям, заданными временными интервалами.

Оставшаяся часть статьи организована следующим образом. В разделе 2вводятся основные понятия и обозначения. Раздел 3 описывает предлагае-мый метод динамического сопоставления трасс: в этом разделе определяетсяотношение соответствия между реализацией и спецификацией и рассматри-вается устройство монитора, проверяющего соответствие. В разделе 4 опи-сывается опыт использования предлагаемого подхода для верификации мо-дулей микропроцессоров. Раздел 5 содержит краткий обзор работ близкихк нашей. В разделе 6 дается заключение и указываются направления даль-нейших исследований.

2 Основные понятия и обозначения

В дальнейшем будем использовать следующие обозначения: Σ — конечныйалфавит событий, T — временная область (для определенности, N). По-следовательности событий называются словами. Σ∗ обозначает множествовсех (конечных) слов над алфавитом Σ. Если u и v — два слова над одним

Page 96: TMPA-2013 Conference Proceedings

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

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

алфавитом и u конечно, то uv обозначает их конкатенацию. Для w = uvговорят, что w является продолжением u с помощью v.

В контексте динамической верификации HDL-моделей удобно структу-рировать алфавит событий, разбив его на два множества: множество вход-ных событий (стимулов) I и множество выходных событий (реакций) O,а также сопоставив каждому событию его порт: port : Σ → 1, 2, ..., k.На содержательном уровне стимул представляет собой посылку запроса кустройству, а реакция — выдачу ответа. При этом события на разных портахмогут происходить параллельно.

Определение 1 (Временное слово [10]) Временным словом (timed word)w над алфавитом Σ и временной областью T называется последователь-ность (a0, t0)(a1, t1)... временных событий (ai, ti) ∈ Σ × T, удовлетворяю-щая следующим ограничениям:

1. для каждого i ≥ 0 выполняется неравенство ti ≤ ti+1;2. для любого T ∈ T найдется i ≥ 0, такой что ti > T (если w бесконечна);3. для всех i, j ≥ 0, таких что i = j и ti = tj, port(ei) = port(ej).

В параллельных системах, к которым относится аппаратура, использу-ется концепция независимости событий: два события считаются независи-мыми, если между ними нет причинно-следственной связи (для таких со-бытий не накладываются ограничения на их относительный порядок). Этаидея лежит в основе двух формальных моделей параллельных вычислений:(1) трасс Мазуркевича (Mazurkiewicz) [11] и (2) частично упорядоченныхмультимножеств [9]. В настоящей статье мы будем придерживаться болееобщей второй модели.

Определение 2 (Частично упорядоченное мультимножество [9]) Σ-размеченным частичным порядком называется кортеж 〈V,, λ〉, где V —конечное множество вершин и λ : V → Σ — функция разметки. Два Σ-размеченных частичных порядка называются эквивалентными, если ониизоморфны относительно и λ (совпадают или отличаются названиемвершин). Частично упорядоченным мультимножеством (pomset, partiallyordered multiset) над алфавитом Σ называется класс эквивалентности Σ-размеченных частичных порядков.

Для удобства мы будем использовать конкретного представителя (кон-кретный размеченный частичный порядок) для обозначения частично упо-рядоченного мультимножества. Линеаризацией частично упорядоченного муль-тимножества 〈V,, λ〉 называется размеченный полный порядок 〈V,≤, λ〉,где ⊆≤.

Определение 3 (Временная трасса [12]) Временной трассой над алфа-витом Σ и временной областью T называется четверка 〈V,, λ, θ〉, где〈V,, λ〉 — частично упорядоченное мультимножество, а θ : V → T —функция времени, удовлетворяющая следующим условиям:

Page 97: TMPA-2013 Conference Proceedings

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

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

1. для всех x, y ∈ V , из x ≺ y вытекает θ(x) < θ(y);2. для любого t ∈ T существует срез C ⊆ V , такой что minx∈Cθ(x) ≥ t

(если V бесконечно).

Множество всех трасс над алфавитом Σ и временной областью T обозна-чается Mθ(Σ, T). Заметим, что временные слова являются частным случаемвременных трасс. Для заданной непустой трассы σ = 〈V,, λ, θ〉 введем обо-значения: begin(σ) = minx∈V θ(x) и end(σ) = maxx∈V θ(x) (если σ беско-нечна, end(σ) = ∞); σ[t,t+∆t] — подтрасса трассы σ, состоящая из тех x ∈ V ,для которых θ(x) ∈ [t, t + ∆t]. Пусть TI(T) — множество временных интер-валов во временной области T (то есть TI(T) = [t, t + ∆t] | t, t + ∆t ∈ T).

Определение 4 (Интервальная трасса) Интервальной трассой над ал-фавитом Σ и временной областью T называется четверка σ = 〈V,, λ, δ〉,где 〈V,, λ〉 — частично упорядоченное мультимножество, а δ : V →TI(T) — функция, ассоциирующая с каждой вершиной временной интер-вал. Языком интервальной трассы σ является множество L(σ) = 〈V,, λ, θ〉 ∈ Mθ(Σ, T) | ∀x ∈ V . θ(x) ∈ δ(x).

Множество всех интервальных трасс над алфавитом Σ и временной обла-стью T обозначается Mδ(Σ, T). В дальнейшем мы будем иметь дело с парамитрасс 〈σθ, σδ〉, где σθ — временная трасса, а σδ — интервальная трасса, та-кие что σθ ∈ L(σδ). Каждая такая пара описывается пятеркой 〈V,, λ, θ, δ〉и называется расширенной интервальной трассой. Множество всех расши-ренных интервальных трасс обозначается Mθδ(Σ, T).

3 Динамическая верификация на основе исполнимыхмоделей

Временное слово (временная трасса с тривиальным частичным порядком)описывает конкретное выполнение HDL-модели (реализации), в то времякак расширенная интервальная трасса описывает поведение эталонной мо-дели (спецификации). Наша цель — проверить в динамике (on-the-fly), чтотрасса реализации wI ∈ (Σ × T)∗ соответствует трассе спецификации σS ∈Mθδ(Σ, T). Поясним, откуда берется расширенная интервальная трасса σS . Впроцессе выполнения спецификация порождает конкретную трассу wS , опи-сываемую временным словом. Прямое сравнение двух временных слов, wI иwS , на равенство возможно только для потактово точной спецификации.Как правило, спецификация абстрактнее реализации, особенно в отноше-нии временных свойств. Сведения о степени абстрактности спецификациипозволяют обобщить конкретное временное слово wS до расширенной ин-тервальной трассы σS , смягчая тем самым проверку соответствия междуреализацией и спецификацией (см. Рисунок 1).

Page 98: TMPA-2013 Conference Proceedings

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

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

Рис. 1. Схема проверки соответствия между реализацией и спецификацией

3.1 Отношение соответствия

В дальнейшем мы будем называть трассы с тривиальным частичным по-рядком (порядком, заданным отношением равенства) трассами выполне-ния. Если Σ = I ∪ O, то трассы выполнения над алфавитом I будем на-зывать входными последовательностями, а трассы выполнения над алфа-витом O — выходными последовательностями. Отметим, что тривиальныйчастичный порядок в трассах выполнения отражает тот факт, что реали-зация рассматривается как “черный ящик”, и причинно-следственные связимежду ее событиями если и известны, то не от самой реализации. Мно-жества входных и выходных последовательностей обозначаются Iθ(Σ, T) иOθ(Σ, T) соответственно. Для краткости будем использовать сокрашенныеобозначения: I = Iθ(Σ, T) и O = Oθ(Σ, T).

Определение 5 (Поведение) Детерминированным поведением над алфа-витом Σ = I ∪ O и временной областью T называется (частичное) отоб-ражение B : I × T → O, удовлетворяющее следующим ограничениям:

- для всех w ∈ I и t ∈ T выполняется неравенство end(B(w, t)

)≤ t;

- для всех w ∈ I и t ∈ T справедливо равенство B(w, t) = B(w[0,t], t);- для всех w ∈ I и t ∈ T существует wv ∈ I, продолжение w, и ∆t ≥ 0,

такие что end(B(wv, t + ∆t)

)≥ t.

Поведение описывает, каким образом входная последовательность пре-образуется в выходную последовательность, принимая во внимание моментвремени, в которое производится наблюдение. Предположим, что у нас естьисполнимая спецификация. Рассмотрим, как ее можно использовать длядинамической проверки поведения реализации. Расширим определение по-ведения, позволив спецификации возвращать расширенные интервальныетрассы, а не конкретные последовательности, как это требуется. Обозначиммножество всех таких трасс символом Oθδ.

Для заданной выходной трассы 〈V,, λ, θ, δ〉 ∈ Oθδ, определим две функ-ции, ∆t±, такие что для всех x ∈ V , δ(x) = [θ(x)−∆t−(x), θ(x)+∆t+(x)]. Бу-дем полагать, что функции ∆t± ограничены (существуют константы ∆T± >0, такие что |∆t±(x)| ≤ ∆T± для всех x ∈ V ). Также положим, что значения

Page 99: TMPA-2013 Conference Proceedings

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

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

∆t±(x) зависят от события, а не от вершины: ∆t±(x) = ∆t±(λ(x)). ПустьI и S — поведение реализации и поведение спецификации соответственно.Для заданной входной последовательности w ∈ I и момента времени t ∈ Tрассмотрим выход реализации и спецификации: I(w, t) = 〈VI, ∅, λI, θI〉 иS(w, t) = 〈VS,S, λS, θS, δS〉. Введем обозначения:

past∆tI (w, t) = y ∈ I(w, t) | θI(y) ≤

(t − ∆t−(y)

);

pastI(w, t) = y ∈ I(w, t) | θI(y) ≤ t;past∆t

S (w, t) = x ∈ S(w, t) | θS(x) ≤(t − ∆t+(x)

);

pastS(w, t) = x ∈ S(w, t) | θS(x) ≤ t;match(x, y) =

(λI(y) = λS(x)

)∧

(θI(y) ∈ δS(x)

).

Определение 6 (Отношение соответствия) Говорят, что поведение ре-ализации I соответствует поведению спецификации S, если domI = domS

и для всех w ∈ domS и t ∈ T существует бинарное отношение M(w, t) ⊆(x, y) ∈ pastS(w, t)×pastI(w, t) | match(x, y) (называемое сопоставлением),такое что:

1. M(w, t) взаимно однозначно;2. для каждой реакции спецификации x ∈ past∆t

S (w, t) существует реакцияреализации y ∈ pastI(w, t), такая что (x, y) ∈ M(w, t);

3. для каждой реакции реализации y ∈ past∆tI (w, t) существует реакция

спецификации x ∈ pastS(w, t), такая что (x, y) ∈ M(w, t);4. для всех (x, y), (x′, y′) ∈ M(w, t) если x ≺ x′, то θI(y) ≤ θI(y′).

Если для некоторых w ∈ I и t ∈ T вышеуказанные свойства нарушают-ся, то говорят, что I не соответствует S, при этом w[0,t] называетсяконтрпримером.

Рисунок 2 иллюстрирует определение отношения соответствия для неко-торой входной последовательности (будучи неважной, она на рисунке непоказана) и момента времени (t = 4). Верхняя часть рисунка показываетреакции реализации (черные кружки с белыми надписями: b, a и c), ниж-няя — реакции спецификации (белые кружки с черными надписями: a, b, cи d). Будем обозначать вершины трассы (собственно, кружки) символамиyb, ya и yc (для реализации) и xa, xb, xc и xd (для спецификации). Междувершинами реализационной трассы нет причинно-следственных связей. Вер-шины спецификационной трассы частично упорядочены (предшествованиесобытий показано стрелками: xa ≺ xc, xb ≺ xc, xa ≺ xd и xb ≺ xd) и по-мечены временными интервалами (δ(xa) = [0, 2], δ(xb) = [1, 3], δ(xc) = [0, 4]и δ(xd) = [1, 5]). Сопоставление реакций отмечено пунктирными линиями((xa, ya), (xb, yb) и (xc, yc)). Легко видеть, что изображенное отношение яв-ляется сопоставлением (в смысле данного выше определения): (1) оно вза-имно однозначно; (2 и 3) оно включает все реакции с истекшим “време-нем жизни”; (4) оно сохраняет спецификационный порядок: (a) xa ≺ xc иθ(ya) = 2 ≤ 3 = θ(yc); (b) xb ≺ xc и θ(yb) = 1 ≤ 3 = θ(yc). Безусловно, каж-дая пара этого отношения удовлетворяет условию сопоставления реакций:(a) λ(xa) = λ(ya) = a и θ(ya) = 2 ∈ [0, 2] = δ(xa); (b) λ(xb) = λ(yb) = b иθ(yb) = 1 ∈ [1, 3] = δ(xb); (c) λ(xc) = λ(yc) = c и θ(yc) = 3 ∈ [0, 4] = δ(xc).

Page 100: TMPA-2013 Conference Proceedings

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

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

Рис. 2. Соответствие между реализацией и спецификацией

3.2 Динамическое сопоставление трасс

Монитор, осуществляющий сопоставление трасс реализации и специфика-ции, может быть представлен как временной автомат [10] с двумя типамивходных портов: (1) порты для получения спецификационных реакций и (2)порты для получения реализационных реакций. Когда автомат обнаружи-вает расхождение в трассах реализации и спецификации, он переходит вопределенное состояние, информируя, тем самым, что реализация не соот-ветствует спецификации.

Ниже представлено формальное описание монитора в виде системы дей-ствий с условиями (guarded actions). Каждое действие атомарно и выполня-ется, как только соответствующее условие становится истинным. Действияи условия зависят от внешней переменной t, отражающей текущее время, иреакций, выдаваемых реализацией и спецификацией в ответ на одну и ту жепоследовательность стимулов (S и I соответственно). Значение t монотон-но возрастает в процессе верификации. Запись y ∈ I[t] (x ∈ S[t]) означает,что в момент времени t реализация (спецификация) выдает реакцию y (x).Описание базируется на двух функциях: (1) первичный арбитр (arbiterS) и(2) вторичный арбитр (arbiterI), определенных ниже:

arbiterS(X) =

min(X) если X = ∅,φ иначе (φ /∈ Σ);

arbiterI(y,X) =

arg minx∈X.match(x,y)θS(x) если ∃x ∈ X . match(x, y),φ иначе.

Page 101: TMPA-2013 Conference Proceedings

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

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

Действие 1 onSpecOut[x], x ∈ S[t]Если: trueВход: x

pastS ⇐ pastS ∪ xif x ∈ arbiterS(pastS) then

for all y ∈ pastI [↑ θI(y)] doif x = arbiterI(y, x) then

pastS ⇐ pastS \ xpastI ⇐ pastI \ ymatch ⇐ match ∪ 〈x, y〉break

end ifend for

end if

Действие 2 onImplOut[y], y ∈ I[t]Если: trueВход: y

pastI ⇐ pastI ∪ yx ⇐ arbiterI(y, arbiterS(pastS))if x = φ then

pastS ⇐ pastS \ xpastI ⇐ pastI \ ymatch ⇐ match ∪ 〈x, y〉

end if

Действие 3 onSpecT ime[x], x ∈ pastS

Если:`θS(x) + ∆t+(x)

´≤ t

Вход: xpastS ⇐ pastS \ xverdict ⇐ false‘trace(“Missing output”)terminate

Действие 4 onImplT ime[y], y ∈ pastI

Если:`θI(y) + ∆t−(y)

´≤ t

Вход: ypastI ⇐ pastI \ yverdict ⇐ falsetrace(“Unexpected output”)terminate

Действие 5 onInitialize

Если: t = 0Вход: ∅

pastS ⇐ ∅pastI ⇐ ∅match ⇐ ∅

Действие 6 onFinalize

Если:max

`end(S)+∆T+, end(I)+∆T−´

≤ tВход: ∅

verdict ⇐ trueterminate

Ниже приведен порядок проверки условий и запуска действий внутриодного временного слота t (при несоблюдении этого порядка возможны лож-ные сообщения об ошибках):

1. инициализация (onInitialize);2. прием реакции (onSpecOut, onImplOut);3. превышение лимита времени (onSpecT ime, onImplT ime);4. завершение (onFinalize).

Когда говорят, что некоторое свойство ϕ выполняется в момент времениt, имеется в виду, что ϕ выполняется после завершения всех действий, ак-тивированных в момент t. Для многопортовых систем (что типично дляаппаратуры) монитор можно разбить на слабо связанные компоненты, па-раллельно обслуживающие отдельные порты.

Page 102: TMPA-2013 Conference Proceedings

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

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

Утверждение 1 (Корректность) Входная последовательность являет-ся контрпримером тогда и только тогда, когда монитор завершается сverdict = false.

На практике встречается аппаратура, в которой операции в некоторыхситуациях отменяют другие операции (конфликтующие с ними и имею-щие более низкий приоритет). Например, операция записи может быть от-менена другой операцией записи, адресующейся к той же ячейке памятии запущенной сразу после рассматриваемой операции. Из-за абстрактно-сти спецификации в ее терминах не всегда возможно выразить условия,при которых происходит отмена операций и соответствующие реакции непосылаются наружу. Принимая во внимание вышесказанное, определениеспецификационного поведения может быть расширено: каждая специфика-ционная реакция дополнительно помечается признаком возможной отмены.Предложенный подход к организации мониторов может быть перенесен ина этот случай. Следует, однако, учесть, что если некоторое событие отме-няется, то также отменяются все зависимые от него события.

4 Инструментальная поддержка и опыт применения

Предложенный метод к проверке корректности поведения HDL-моделей былреализован в инструменте C++TESK [13]. Библиотека инструмента содер-жит классы и макросы для создания компонентов систем динамической ве-рификации аппаратуры (эталонных моделей, мониторов, генераторов сти-мулов и других). Возможности C++TESK для разработки эталонных мо-делей аппаратуры (и, соответственно, мониторов) включают средства дляпосылки и приема пакетов данных (примитивы send и receive), ветвленияи объединения параллельных процессов (fork и join), моделирования вре-менных задержек (delay) и задания зависимостей между пакетами (depends).

Инструмент позволяет создавать модели аппаратуры на разных уров-нях абстракции (относительно точности моделирования времени): (1) моде-ли без учета времени (описывающие общие причинно-следственные связимежду пакетами данных без моделирования временных задержек междуними: ∆t± = ∞), (2) модели с приближенным учетом времени (частичноспецифицирующие внутренние схемы арбитража пакетов, но учитывающиевремя лишь примерно: ∆t± ≤ T , где T имеет значение нескольких десятковтактов) и (3) потактовые модели (реализующие точное или почти точноемоделирование времени: ∆t± ≤ 1).

Инструмент C++TESK был использован для динамической верифика-ции модулей промышленных микропроцессоров, разрабатываемых в НИИ-СИ РАН и ЗАО “МЦСТ”. Наш опыт уже был представлен в [14], но с техпор он был расширен. Последняя информацию о применении инструмен-та и заложенного в нем метода представлена в Таблице 1. Как видно изтаблицы, подход поддерживает верификацию как с помощью абстрактныхэталонных моделей (доступных на ранних стадиях проектирования), так и

Page 103: TMPA-2013 Conference Proceedings

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

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

с помощью потактово точных моделей (доступных на заключительных эта-пах). Что важно, подход позволяет использовать для верификации C++-модели, изначально создаваемые для других целей (в частности, компонен-ты системного симулятора микропроцессора). Таким способом, например,был проверен модуль поиска по таблице страниц.

Название модуля Стадия разработки Точность моделирования

от до

Буфер трансляции адресов Поздняя / завершающая Приближенная Потактовая

Модуль арифметики (FPU) Поздняя / завершающая Без учета времени —

Кэш-память 2-ого уровня (L2) Промежуточная / поздняя Приближенная —

Коммутатор северного моста Промежуточная / завершающая Прилиженная Потактовая

Модуль доступа к памяти Ранняя / промежуточная Без учета времени Потактовая

Контроллер прерываний Ранняя / промежуточная Без учета времени Приближенная

Модуль поиска по таблице страниц Поздняя Приближенная —

Контроллер банка кэш-памяти L2 Поздняя Потактовая —

Буфер команд Поздняя / завершающая Потактовая —

Кэш-память 3-его уровня (L3) Промежуточная Приближенная —

Таблица 1. Опыт применения предложенного метода

5 Обзор существующих работ

В работе [15] используется модель автомата с частично упорядоченны-ми входными/выходными событиями (POIOA, Partial Order Input/OutputAutomaton) для представления поведения спецификации и реализации. Встатье предлагается метод построения тестового набора, гарантирующегообнаружение ошибок определенного типа. Если (1) реализация сообщает оприеме неподдерживаемых стимулов, (2) можно установить порядок выда-чи реакций, (3) время ответа реализации ограничено, и (4) каждый единич-ный переход в спецификации соответствует единичному переходу в реализа-ции, можно определить соответствие между реализацией и спецификацией.Реализация соответствует спецификации, если она принимает допускаемыеспецификацией стимулы и выдает описываемые спецификацией реакции вдопустимом порядке. Определение отношения соответствия, данное в этойстатье, близко к используемому нами. Главными отличиями нашего под-хода являются поддержка необязательных реакций и контроль временныхинтервалов.

Статья [16] описывает подход к проверке поведения временных систем,основанный на инвариантах трассы. Рассматриваются два типа инвариан-

Page 104: TMPA-2013 Conference Proceedings

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

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

тов: (1) инварианты ожидания, выражающие то свойство, что после задан-ной трассы всегда ожидается определенное событие (в определенном вре-менном интервале) и (2) инварианты наблюдения, утверждающие, что меж-ду двумя заданными событиями всегда наблюдается определенная последо-вательность событий. Корректность поведения реализации проверяется вдва этапа: (1) проверка соответствия инвариантов спецификации, выражен-ной в форме временного конечного автомата (TFSM, Timed Finite StateMachine); (2) проверка выполнимости инвариантов для трассы реализации.Подход представляет теоретический интерес, однако его промышленное ис-пользование может быть затруднено необходимостью постоянного согласо-вания проверяемых инвариантов со спецификацией.

В работе [17] рассматривается метод тестирования параллельных системс помощью неявно заданных асинхронных конечных автоматов (AFSM,Asynchronous Finite State Machines). Поведение реализации проверяется толь-ко в стационарных состояниях, в которых не ожидается выдача реакций.Используется следующая процедура: (1) собираются все события и опреде-ляется их частичный порядок; (2) строятся и проверяются все возможныелинеаризации множества событий (проверка базируется на пред- и посту-словиях, определенных для каждого события). Считается, что реализациясоответствует спецификации, если допускается хотя бы одна из построен-ных линеаризаций. Применение подхода возможно только для ограничен-ного класса входных последовательностей: требуется, чтобы регулярно воз-никали стационарные состояния. В нашем случае такого ограничения нет.

6 Заключение

Работа сфокусирована на использовании исполнимых моделей для динами-ческой верификации HDL-моделей. Проблема не так проста, как кажетсяна первый взгляд. Проверка того, что реализация и спецификация выдаютодинаковые реакции в одинаковые моменты времени в большинстве случаевне является адекватной. Спецификация в силу своей абстрактности можетне учитывать многих особенностей реализации, таких как упорядочиваниесобытий и их распределение во времени. В работе предложены механизмы,позволяющие настраивать точность проверки поведения, учитывая степеньабстрактности спецификации. К ним относятся: (1) описание отношения за-висимости событий, (2) расширение временных меток событий до временныхинтервалов и (3) пометка некоторых событий как необязательных. Основы-ваясь на предложенных механизмах, разработан метод проверки поведенияHDL-моделей. Метод был реализован в инструменте C++TESK и приме-нялся в более чем 10 проектах по верификации модулей микропроцессоров.Наши дальнейшие исследования связаны с диагностикой ошибочного пове-дения HDL-моделей на основе более глубокого анализа трасс, выполняемогопосле сеанса верификации. Целью такого анализа является упрощение лока-лизации ошибок путем определения характера расхождений наблюдаемогоповедения HDL-модели от эталонного.

Page 105: TMPA-2013 Conference Proceedings

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

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

Список литературы

1. Wile, B., Goss, J., Roesner, W.: Comprehensive Functional Verification: TheComplete Industry Cycle. Morgan Kaufmann (2005)

2. Bergeron, J.: Writing Testbenches: Functional Verification of HDL Models. KluwerAcademic (2000)

3. Glasser, M.: Open Verification Methodology Cookbook. Springer (2009)4. Sen, K., Rosu, G.: Generating Optimal Monitors for Extended Regular

Expressions. Electronic Notes in Theoretical Computer Science 89(2) (2003) 162–181

5. Ivannikov, V., Kamkin, A., Kossatchev, A., Kuliamin, V., Petrenko, A.: The Use ofContract Specifications for Representing Requirements and for Functional Testingof Hardware Models. Programming and Computer Software 33(5) (2007) 272–282

6. Barringer, H., Rydeheard, D., Havelund, K.: Rule Systems for Run-TimeMonitoring: From Eagle to RuleR. In: Proceedings of 7th International Workshopon Runtime Verification. Revised Selected Papers. (2007) 111–125

7. Bauer, A., Leucker, M., Schallhart, C.: Runtime Verification for LTL and TLTL.ACM Transactions on Software Engineering and Methodology 20(4) (2011) 14:1–14:64

8. Mintz, M., Ekendahl, R.: Hardware Verification with C++: A Practitioner’sHandbook. Springer Science+Business Media, LLC (2006)

9. Pratt, V.: The Pomset Model of Parallel Processes: Unifying the Temporal andthe Spatial. In: Seminar on Concurrency. (1984) 180–196

10. Alur, R., Dill, D.: A Theory of Timed Automata. Theoretical Computer Science126(2) (1994) 183–235

11. Mazurkiewicz, A.: Trace Theory. In: Advances in Petri Nets 1986, Part II on PetriNets: Applications and Relationships to Other Models of Concurrency, New York,NY, USA, Springer-Verlag New York, Inc. (1987) 279–324

12. Chieu, D., Hung, D.: Timed Traces and Their Applications in Specificationand Verification of Distributed Real-time Systems. In: Proceedings of the ThirdSymposium on Information and Communication Technology. (2012) 31–40

13. ISPRAS: C++TESK Homepage. http://forge.ispras.ru/projects/cpptesk-toolkit/14. Chupilko, M., Kamkin, A.: A TLM-Based Approach to Functional Verification of

Hardware Components at Different Abstraction Levels. In: Proceedings of the 12th

Latin-American Test Workshop. (2011) 1–615. von Bochmann, G., S.Haar, C.Jard, Jourdan, G.V.: Testing Systems Specified

as Partial Order Input/Output Automata. In: Proceedings of the 20th IFIP TC6/WG 6.1 International Conference on Testing of Software and CommunicatingSystems: 8th International Workshop. TestCom ’08 / FATES ’08 (2008) 169–183

16. Andres, C., Merayo, M., Nunez, M.: Formal Passive Testing of Timed Systems:Theory and Tools. Software Testing, Verification & Reliability 22(6) (2012) 365–405

17. Kuliamin, V., Petrenko, A., Pakoulin, N., Kossatchev, A., Bourdonov, I.:Integration of Functional and Timed Testing of Real-Time and ConcurrentSystems. In: Perspectives of System Informatics. (2003) 450–461

Page 106: TMPA-2013 Conference Proceedings

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

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

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

Ярославский государственный университет150000, Ярославль, Советская, 14

[email protected], [email protected], [email protected]

Аннотация Верификатор, работающий с использованием методапроверки модели (model checking), должен иметь возможность обхо-да множества достижимых состояний системы. Для SystemC-моделейгенерация этого множества является нетривиальной задачей, так какSystemC представляет собой набор классов, расширяющих язык C++.В результате SystemC-модель системы компилируется в виде испол-няемого файла, который позволяет проводить только имитационноемоделирование или тестирование. В работе представлен подход, ос-нованный на использовании контрольных точек, реализующий ис-черпывающее построение множества достижимых состояний моде-лируемой системы.

Keywords: SystemC, model checking, верификация, контрольная точ-ка

1 Введение

SystemC (IEEE Standard 1666-2005) [4,10] открытый промышленный языкдля проектирования и верификации моделей системного уровня, реализо-ванный в виде C++-библиотеки с открытым исходным кодом. Основнойобластью применения языка являются встраиваемые системы, системы накристалле, где важной является задача обеспечения корректной работы. Вбиблиотеку включено ядро моделирования событий, что позволяет получитьисполняемую модель устройства, а при разработке можно использовать всесредства языка C/C++.

Модель на языке SystemC это набор компонентов и соединений меж-ду ними. Многие компоненты аппаратного обеспечения, такие как, напри-мер, модули, каналы, сигналы, порты, имеют соответствующие аналоги вSystemC. Язык применяется в основном для построения транзакционных иповеденческих моделей. Поведенческая модель описывает взаимодействие? работа поддержана грантом РФФИ, проект 11-07-00549-а

?? работа поддержана программой ФЦП Научные и научно-педагогические кад-ры инновационной России на 2009–2013 годы, соглашение 14.B37.21.0392 от06.08.2012

Page 107: TMPA-2013 Conference Proceedings

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

2

компонент системы между собой, информационные процессы в системе, по-ведение системы. Если функциональная модель позволяет ответить на во-прос что делает система?, то поведенческая модель отвечает на вопроскак система это делает?. В ней фигурируют такие категории как состоя-ние системы, события, переход из одного состояния в другое, условия пере-хода, последовательность событий.

Моделирование на уровне транзакций это подход к моделированиюсистем, в котором детали связи между модулями отделены от деталей реа-лизации модулей. Механизмы связи моделируются в виде каналов, и исполь-зуются модулями с помощью специальных интерфейсов. Запрос транзакцииначинается с вызова функции интерфейса этих каналов, которая заключаетв себе детали обмена информацией. На уровне транзакций обмен информа-цией более выразителен и понятен [4].

К основным расширениям SystemC, отсутствующим в C++, относятся:понятие модельного времени; возможности описания параллельно выполня-ющихся вычислений; дополнительные типы данных, отражающие специфи-ку проектирования аппаратуры.

SystemC был разработан для достижения возможности использовать еди-ный язык программирования с общим окружением для описания системы отсамых высокоуровневых моделей на C++ до структурных синтезируемыхмоделей уровня RTL (Register Transfer Level). Это позволяет постепеннодетализировать описание системы в процессе проектирования. С помощьюSystemC можно добиться модели взаимодействия программной и аппарат-ной частей системы, как если бы это было реальное устройство, но на высо-ком уровне абстракции. За счет этого можно выявить многие проблемы наранних стадиях разработки [10].

В [21] отмечается, что средства верификации SystemC-моделей находят-ся в зачаточном состоянии. Стандартная поставка позволяет лишь прово-дить имитационное моделирование и тестирование. Там же, в [21], ставитсязадача разработки средств верификации, в частности таких, которые исчер-пывающе исследуют множество достижимых состояний модели.

2 Обзор существующих подходов к верификацииSystemC-моделей

Основными методами верификации систем являются имитационное модели-рование, тестирование, дедуктивный анализ и проверка модели [1].

Обычно SystemC-модели верифицируются с помощью тестирования. Про-веряемая модель выполняется в рамках заранее подготовленных сценари-ев. Тестирование сопровождается созданием контролируемой среды модели,обеспечивающей получение результатов ее работы и измерение различныххарактеристик, а также оценка этих результатов и характеристик [1].

Испытательный стенд (test bench) это среда, используемая для про-верки свойств или проверки на безошибочность системы или ее модели.

Page 108: TMPA-2013 Conference Proceedings

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

3

Стенды, разрабатывающиеся для SystemC-моделей, как правило, содер-жат проверяемую систему (device under test тестируемое устройство), свя-зующие элементы и элементы, необходимые для проверки (тесты). В такихстендах могут использоваться специальные высокоуровневые модели, пред-назначенные для различных целей: генерации входных сигналов, постобра-ботки данных, создания эталонных моделей, схем обеспечения безопасности(верификаторов свойств, мониторов, наблюдателей) [10]. Создание хорошихстендов довольно трудоемкий процесс, требующий хорошего знания C++.

Для верификации SystemC-моделей предусмотрена специальная библио-тека SCV (SystemC Verification Library). SCV предоставляет средства, по-могающие разработчику эффективно проводить комплексные испытания си-стемы [19]. С помощью SCV создаются испытательные стенды и случайнымобразом генерируются тесты, которые используются средой в качестве вход-ных данных. Существуют разные виды и приемы генерации тестов.

Архитектурой модели назовем набор компонентов и соединение междуними, а также механизмы синхронизации и коммуникации, такие как, на-пример, события, сигналы, запись в порты и чтение из них.

Лучшие верификаторы SystemC на данный момент переводят код наSystemC в формальную модель с помощью предварительных обработчиков(front-end). Они формализуют семантику языка так, чтобы можно было ис-пользовать полученный код как входную информацию для верификаторов.

Так как SystemC является библиотекой C++, все особенности C++ долж-ны поддерживаться предварительным обработчиком. Этого можно достичь,написав свой парсер, удовлетворяющий этим условиям, либо использоватьсуществующий предварительный обработчик для C++ (GCC, LLVM, EDGи т.д.). Обычный предварительный обработчик C++ не в состоянии уловитьспецифику языка SystemC, поэтому предварительные обработчики SystemCдолжны уметь определять специфичные конструкции языка и помечать ихв промежуточном представлении особым образом.

В случае создания предварительного обработчика со своим парсеромSystemC воспринимается как язык программирования, а не библиотека дляC++. Создание полноценного парсера является сложной задачей, поэто-му, как правило, не все конструкции C++ поддерживаются такими пред-варительными обработчиками. Представителями такого подхода являются:ParSyc [9], KaSCPar [11], sc2v [8], BSSC based [17], SystemPerl [20].

К проектам, использующим существующие предварительные обработчи-ки C++, относятся: SystemCXML [3], Quiny [18], Pinapa [15], PinaVM [13],Scoot [5], Dust [12], SystemCASS [7].

Предварительные обработчики для SystemC делятся на статические, ди-намические и гибридные.

Статический анализ позволяет распознавать конструкции языка. Стати-ческим анализом кода можно построить архитектуру модели, но статиче-ский анализ позволяет работать только с моделями с относительно простойархитектурой. К проектам, основанным на статическом подходе, относятся

Page 109: TMPA-2013 Conference Proceedings

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

4

все проекты со своим собственным парсером языка, а также SystemCXMLи Scoot.

Динамический подход основан на выполнении откомпилированной про-граммы, в частности на выполнении фазы разработки модели. С помощью еевыполнения также можно получить архитектуру модели. При выполнениипрограммы собираются данные, которые генерируются во время выполне-ния. Так как некоторым инструментам требуется только архитектура, онимогут использовать динамический подход. Такие инструменты позволяютискать информацию в архитектуре, но не знают ничего о поведении процес-сов. К проектам, основанным на динамическом подходе, относятся Quiny,Dust, SystemCASS.

Перед предварительным обработчиком SystemC стоит задача построитьархитектуру системы, а также распознать происходящие в архитектуре вза-имодействия между модулями и процессами. Причем необходимо организо-вать связь между архитектурой и этими взаимодействиями. С этой задачейдостаточно успешно справляется гибридный подход, являющийся комбина-цией статического и динамического подходов.

Существуют проприетарные решения, предлагаемые компаниями Synopsysи Semantic Designs. Эти решения основаны на статическом анализе и отлич-но распознают конструкции языка SystemC. Так как их разработка являетсязакрытой, они здесь не рассматриваются.

В [14,13] был проведен сравнительный обзор функциональности несколь-ких предварительных обработчиков, которые были доступны на тот момент.Сравнение производилось на ряде тестовых примеров. В таблице 1 приве-дены полученные результаты, которые показывают, что на данный моментне существует универсального средства верификации SystemC-моделей.

3 Предлагаемый подход для верификацииSystemC-моделей

Как мы уже видели, использование предварительных обработчиков не поз-воляет учитывать все нюансы SystemC-моделей. Это по-видимому являетсяврожденным недостатком всех методов, которые основаны на парсинге ис-ходного кода SystemC-программы с целью получения формальной модели,пригодной для верификации. Наш подход основывается на методе CMC (CModel Checking) [16], который при помощи внесения изменений, не влияю-щих на семантику SystemC-программы, позволяет строить эту формальнуюмодель во время ее выполнения.

3.1 Метод верификации CMC

Метод CMC [16] позволяет автоматически создавать формальную модель изC/C++ кода, которую можно верифицировать с помощью метода проверкимодели (model checking). Так как SystemC это библиотека для языка C++,то можно использовать средства, разработанные для анализа кода на C++.

Page 110: TMPA-2013 Conference Proceedings

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

5

Pin

aVM

Pin

apa

Syst

emC

XM

LK

aSC

Par

Qui

nySc

oot

Syst

emPer

lsc

2v

elab-only 6 6 6 6 5 6 0 5elab-easy 6 6 6 1 5 6 0 2

elab-easy-int 6 6 6 1 3 6 0 2elab-easy-uint 6 6 6 1 3 6 0 2elab-easy-array 6 6 0 1 2 1 0 0

elab-easy-sc_stop 6 6 6 1 3 3 0 3elab-port-bool 6 6 0 1 2 2 0 0elab-pointer 4 4 0 0 2 0 0 0

elab-instances 6 5 0 1 2 3 0 0elab-clock 6 3 6 1 3 5 0 3

signal 6 4 0 0 0 5 0 0event 6 6 6 1 2 6 0 2fifo 3 0 0 0 0 0 0 0

RAM 6 2 6 0 0 3 0 0

Таблица 1. Сравнительный анализ функциональности нескольких предваритель-ных обработчиков SystemC-моделей. Обозначения: 6 пример может быть про-анализирован; 5 пример может быть проанализирован, но с небольшим измене-нием теста; 4 пример проанализирован лишь частично; 3 пример не можетбыть проанализирован, но требуется незначительная доработка проекта; 2 при-мер не может быть проанализирован и требуется значительная доработка проекта;1 пример не может быть проанализирован по неизвестной причине; 0 примерне может быть проанализирован из-за ограничений подхода.

Так как исходный код Стэндфордской реализации метода CMC являетсязакрытым, нам пришлось написать свою реализацию с учетом спецификиSystemC-моделей.

Каждая система в CMC моделируется в виде взаимодействующих про-цессов. Такие процессы выполняют код реализации системы в контекстеверификации модели. Программа, реализующая метод CMC и содержащаявсе процессы, работает в операционной системе как единый процесс. Много-поточные объекты могут моделироваться как процессы, содержащие любоеколичество потоков выполнения.

Поток имеет доступ к глобальным переменным и куче процесса, в ко-тором он выполняется. Процессы могут обмениваться информацией черезспециальную общую память, выделенную для всех процессов одновременно.Состояние потока состоит из его стека и содержимого регистров процессо-ра. Состояние процесса состоит из копии своих глобальных переменных,содержимого кучи и состояния всех его потоков. Состояние системы этосовокупность состояний процессов и общей памяти.

Page 111: TMPA-2013 Conference Proceedings

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

6

CMC позволяет настраивать график запуска потоков, что, в свою оче-редь, позволяет получать разное поведение системы.

Переход системы это выполнение детерминированного, атомарногошага, который изменяет состояние системы. Переход выполняется с переда-чи контроля потоку и до вызова специально определенной в CMC функцииcmc_yield(), которая внедряется в исходный код исследуемой программысогласно решению разработчика и его пониманию этой программы. Так какпереходы являются атомарным шагом, они определяют степень чередова-ния выполнения параллельных потоков, и разработчик должен решить, какдолжны выполняться потоки, чтобы желаемые свойства были проверены.

После того, как реализация будет представлена в виде процессов и пото-ков и определятся соответствующие системе переходы, в реализацию необхо-димо добавить модель среды. Под средой здесь подразумеваются все внеш-ние объекты, с которыми взаимодействует система (человек, сеть, файло-вая система и так далее). Важной частью среды являются входные данные.Обычно система объединяется с другими компонентами в более сложнуюсистему. Чтобы минимизировать затраты на моделирование среды ряд ком-понентов предлагается сделать универсальными, чтобы использовать в раз-ных задачах.

Поведение системы является недетерминированным. Оно может зави-сеть, например, от следующих факторов среды: порядок получения систе-мой входных данных, различные значения входных данных, порядок за-планированного запуска потоков. Чтобы смоделировать недетерминирован-ность поведения, в CMC используется функция cmc_choose(int n), кото-рая внедряется разработчиком в части кода, где есть необходимость про-верки недетерминированного поведения. Она возвращает случайное числов диапозоне от 0 до n - 1. Использовать эту функцию можно, предоста-вив каждому значению возвращаемого значения уникальное поведение си-стемы. При реализации метода CMC каждое из поведений будет рассмотре-но. Например, удобно написать функцию динамического выделения памяти,которая будет либо выделять, либо не выделять память в зависимости отзначения cmc_choose(). Таким образом, будет рассмотрено оба случая: по-ведение системы при корректном выделении памяти и поведение системы,при котором происходит ошибка при выделении по каким-либо причинам.

Важной причиной недетерминированного поведения является параллель-ное выполнение процессов в системе (параллельность системы). Выполне-ние потоков в системе может произвольно чередоваться. CMC реализуетэтот недетерминизм контролем за расписанием запуска потоков в модели.Многократные чередования CMC исследует, задавая различные расписаниязапуска потоков.

Модель, построенная из реализации системы, вместе с моделью средыдоступна для соединения с CMC. CMC начинает контролировать выполне-ние этой модели, исследуя по мере выполнения состояния на выполнение вних заданной спецификации.

Page 112: TMPA-2013 Conference Proceedings

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

7

СМС это метод верификации модели, который создает пространствосостояний посредством прямого исполнения реализации системы (на языкеС/С++). СМС генерирует граф достижимых состояний системы при по-мощи его обхода в глубину или в ширину. Если граф обходится в ширину,интересным развитием алгоритма является эвристический анализ предпо-чтительности состояний в очереди. Выбирая из очереди наиболее интерес-ные состояния, мы добьемся большей эффективности процесса верифика-ции, особенно если исчерпывающее построение множества достижимых со-стояний не представляется возможным.

Для того чтобы производить обход графа состояний, необходимо уметьсохранять состояния модели и возвращаться к ним. Чтобы выполнять этидействия, необходимо уметь их выполнять со всеми составными частями со-стояния модели. Во время верификации системы методом CMC граф состо-яний может начинать экспоненциально расти. Количество состояний можетстановится чрезмерно большим (или даже являться бесконечным) для обра-ботки. Эта проблема известна как проблема взрыва состояний. Чем большеграф, тем быстрее кончатся ресурсы компьютера, необходимые для процес-са верификации. Несмотря на разные подходы к ее решению, она остаетсядовольно серьезной проблемой. СМС использует различные подходы эф-фективного обхода пространства состояний.

CMC может проверять свойства безопасности (safety), но не может про-верять свойства живости (liveness). Свойства безопасности составляют боль-шой класс интересных для верификации свойств, к тому же свойства жи-вости в графах с конечным количеством состояний могут быть выраженыв виде свойств безопасности.

Специализированные свойства отслеживаются с помощью вызовов функ-ции assert(). Разработчик вставляет функции проверки так, чтобы каждоеновое состояние было проверено на свойства.

3.2 Верификация SystemC-моделей c использованием методаCMC

Модель, написанная на языке SystemC, представляется в CMC в качествепроцесса. Если для верификации необходимо взаимодействие несколькихмоделей, все они представляются в качестве отдельных процессов. SystemC-процессы (SC_METHOD и SC_THREAD) выполняют роль CMC-потоков, то естьпри обходе графа достижимости они будут выполнять переходы между со-стояниями. Переходы выполняются с момента передачи управления SystemC-процессу и до момента его окончания, или, в случае SystemC-потока, домомента его откладывания.

Во время фазы инициализации производится формирование начальногосостояния графа. Далее выполняется алгоритм обхода с начального состо-яния, пошагово исполняя код программы. Если какая-то из ветвей графаприведет к завершению фазы вычислений, то осуществляется фаза постоб-работки и завершение выполнения этой ветви.

Page 113: TMPA-2013 Conference Proceedings

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

8

Состояние графа должно хранить состояние всей модели, в том числезначение времени, состояние SystemC-процессов и состояние других объек-тов библиотеки. Новые типы CMC сможет сохранять и восстанавливать,потому что эти типы представляют собой обычные классы языка C++.

Во время обхода графа для рассматриваемого состояния генерируютсяего состояния-потомки. В некоторых случаях генерируется только одно со-стояние: когда состояние системы может лишь детерминировано перейти вдругое, используя единственный доступный переход. В остальных случа-ях генерируется несколько состояний. Это происходит, когда CMC можетиспользовать более одного перехода, а именно: в случаях параллельноговыполнения SystemC-процессов, в случаях различного поведения среды мо-дели, в случаях какого-либо иного недетерминированного поведения моде-ли. Среда для SystemC-модели зависит от самой модели и разрабатываетсяточно так же, как и в случае немодифицированного C/C++ кода.

Для нашей реализации метода CMC ключевой задачей является способсохранения и восстановления состояния SystemC-модели. От этого зависиткорректность работы верификатора, скорость его работыа также насколькоэкономно будут расходоваться ресурсы компьютера. Для сохранения состо-яния программы можно использовать два способа. Первый способ предпо-лагает сериализацию значений переменных (сохранение состояния) внутрикода модели с последующей десериализацией (восстановление состояния).Второй способ напротив сохраняет снимок состояния модели как програм-мы с помощью сторонних средств.

В исходном коде SystemC существует класс sc_simcontext, отвечающийза хранение всех объектов, использующихся в SystemC-модели. Если со-хранить и восстановить объект этого класса в момент выполнения моделиперед запуском новой итерации фазы вычислений, теоретически можно до-стигнуть желаемого результата и добиться более быстрой работы, чем привтором способе. Важным моментом является то, что сохранение класса посути является глубоким копированием: копированием объекта с выделени-ем под него нового участка памяти, а не копированием лишь указателей напеременные. В C++ не существует ни стандартных средств глубокого копи-рования, ни сторонних библиотек, которые позволили бы выполнить такуюоперацию.

Другой подход к сохранению и восстановлению состояний основан наиспользовании контрольных точек. Контрольная точка снимок состоя-ния приложения, хранящий всю необходимую информацию для того, чтобыможно было восстановить работу приложения с сохраненного состояния.Чаще всего контрольные точки используются для резервного хранения со-стояний [6].

Существует ряд проектов для операционной системы Linux, позволяю-щих создавать контрольные точки приложений. Среди них: BLCR, DMTCP,CRIU, Cryopid, OpenVZ. Нами был выбран DMTCP [2], так как проект ста-билен и выполняет все необходимые функции. В частности, в отличие отBLCR, DMTCP поддерживает сокеты (программный интерфейс для обес-

Page 114: TMPA-2013 Conference Proceedings

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

9

печения информационного обмена между процессами). Это важно, так какразработанный верификатор взаимодействует с исследуемой моделью че-рез сокеты. Программный пакет DMTCP позволяет организовать прозрач-ное создание контрольных точек для многопоточных и распределенныхпрограмм. Пакет реализован на уровне системных библиотек операционнойсистемы Linux и не требует модификаций ядра этой ОС. DMTCP позволяетобеспечить формирование контрольных точек и восстановление из них длятаких программ, как: OpenMPI, MATLAB, Python, Perl. Он поддерживаетразличные языки программирования, включая скриптовые языки.

Нами было разработано программное средство SCMC (SystemC ModelChecker), которое представляет собой программу, позволяющую выполнятьSystemC-модель всеми возможными способами и оповещать пользователяо достижении определенных условий при выполнении. Она хранит графсостояний модели и выполняет направляющую роль. Для языка SystemCпредусмотрено дополнение, необходимое для указания в модели точек, вкоторых SCMC будет разветвлять выполнение модели.

После запуска SCMC происходит ожидание запуска SystemC-модели. Кактолько модель запустилась, SCMC ожидает от нее сообщения чтобы на-чать генерировать граф достижимых состояний. Интерфейс дополнения дляSystemC-моделей содержит ряд методов, которые разработчику необходимовнедрить в свою модель.

Метод SendCheckpointAndWait отправляет в SCMC сообщение о ме-сте разветвления выполнения. Каждая ветвь определяется целочисленнымзначением, которое возвращает метод. В зависимости от значения модельосуществляет ту или иную работу, это настраивается вручную сразу послевызова метода. Номер ветви лежит в диапазоне [0, N], где N максималь-ный номер ветви. Метод принимает аргументы: максимальный номер ветвии аннотацию состояния модели в данный момент в виде строки, которуюпользователь формирует по своему усмотрению вручную. Состояние мо-дели представляет из себя строку из значений переменных, совокупностькоторых точно определяет состояние. Важно учесть все необходимые пе-ременные, иначе может возникнуть ситуация, когда два разных состоянияSCMC примет за одинаковые и ошибочно отсечет целую ветку исполнения.После сохранения состояния модель завершает работу. SCMC восстанавли-вает новое состояние из очереди.

SendAssertMessage отправляет в SCMC сообщение о выполнении свой-ства. Аргументом метода является сопутствующее сообщение, которое будетвыведено в файле с результатами.

SendExitMessage отправляет в SCMC сообщение о завершении работымодели.Этот метод может быть вызван в конце работы модели, чтобы SCMCмог перейти к рассмотрению следующего в очереди состояния.

Для сохранения и восстановления состояния модели используется DMTCP.Физически на жесткий диск состояние сохраняется в момент отправлениясообщения о месте разветвления, причем для всего набора добавляемых со-

Page 115: TMPA-2013 Conference Proceedings

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

10

стояний с разными номерами ветви для восстановления используется одини тот же файл с состоянием программы, что экономит память.

В SCMC реализован в целом похожий на CMC алгоритм, граф достижи-мых состояний обходится в ширину.

В принципе реализация не ограничивает работу SCMC исключительноязыком SystemC, верификатор также может работать с любой другой про-граммой на языке C++, которая сохраняется и восстанавливается DMTCP.

4 Экспериментальные результаты

Эксперименты проводились с моделью, которая распространяется вместес пакетом SystemC. Она описывает передачу данных от отправителя по-лучателю через канал связи, представленный в виде очереди ограничен-ной длины. Канал связи допускает только потерю символов. Передаваемаястрока задается заранее. Получатель может принимать в один момент вре-мени только один символ, а остальные ожидают в канале. В экспериментепроверяется свойство, может ли получатель последовательно принять дваодинаковых символа подряд. Эксперименты проводились на компьютере спроцессором Intel Core i3-2310M.

В модель с помощью разветвления выполнения модели добавлена воз-можность потери любого символа при передаче. Метод, сообщающий о раз-ветвлении, срабатывает непосредственно перед передачей символа в канал.В сообщении передается максимальный номер ветви, равный единице, и ин-формация о состоянии, которая включает в себя историю переданных по-лучателю символов, номер следующего символа в очереди канала, списокхранящихся в канале символов и оставшаяся для передачи в канал строкана отправителе. Это тот минимальный набор информации, который позво-ляет идентифицировать состояние модели единственным образом для дан-ной задачи. Так как SystemC ведет себя детерминированно, нет опасностипропустить новые состояния при отсечении повторяющихся состояний.

Каждый новый принятый получателем символ сравнивается с предыду-щим. Если они совпадают, в SCMC отправляется сообщение о выполнениипроверяемого свойства.

В результате исследования модели можно заключить, что предложен-ный метод работоспособен. Каждое состояние модели занимает на жесткомдиске примерно 2 Мб, сохранение и восстановление занимает порядка 0.5секунды. Оперативная память на хранение информации о состояниях прак-тически не расходуется. В таблице 2 приведены результаты, показывающиескорость работы с различными входными данными. Длина очереди каналанесущественно влияет на подсчет затраченного времени, поэтому для нее вовсех тестах установлено значение 10. Время работы может варьироватьсяна одних и тех же входных данных из-за особенностей DMTCP.

Если вернуться к таблице 1 (предпоследняя строка), проверка моделейс очередями плохо поддается верификации среди известных подходов, но сописанным в данной работе методом такая проверка становится возможной.

Page 116: TMPA-2013 Conference Proceedings

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

11

Передаваемая строка Кол-во выполненных условий Кол-во состояний Затрачено (сек)aaa 3 14 7cac 1 16 7abc 0 16 6

aaaaa 5 26 12cabac 5 60 27abcde 0 64 28

aaaaaaa 7 38 19cababac 29 164 84abcdefg 0 256 121

aaaaaaaaa 9 50 28cabababac 69 332 193abcdefghi 0 1024 480

Таблица 2. Производительность метода SCMC

5 Заключение

Целью этой работы было создание формального верификатора для SystemC-моделей, который позволил бы проверять непосредственно саму SystemC-модель без ее трансляции в язык одного из существующих верификаторов.Для реализации такого верификатора был выбран метод CMC, исследую-щий программу перебором всех возможных путей ее выполнения. Методпредполагает необходимость сохранять и восстанавливать состояние про-граммы, что в данном случае делается с использованием пакета DMTCP.

В результате выполнения задачи был успешно создан желаемый фор-мальный верификатор, названный SCMC. В отличие от существующих ве-рификаторов SystemC используемый подход позволяет охватить все множе-ство SystemC-моделей. Для проведения верификации в исследуемой SystemC-модели должны быть указаны контрольные точки, где производится ветвле-ние модели, либо проверяется желаемое свойство. Пользователю будут вы-ведены все случаи выполнения заданного свойства модели, а также будутвыведены пути исполнения модели, приведшие к выполненному свойству.

Существует проблема взрыва состояний, частично решаемая исключе-нием одинаковых веток графа состояний. Для экономии памяти в будущемможно будет добавить инкрементное сжатие контрольных точек SystemC-моделей, также разработать алгоритмы, ускоряющие его работу.

Список литературы

1. Кулямин В.В. Методы верификации программного обеспечения // Всероссий-ский конкурсный отбор обзорно-аналитических статей по приоритетному на-правлению Информационно-телекоммуникационные системы, 2008, 117 с.

2. Ansel J., Arya K., Cooperman G. DMTCP: Transparent Checkpointing for ClusterComputations and the Desktop // 23rd IEEE International Parallel and DistributedProcessing Symposium (IPDPS’09). Rome, Italy. May, 2009.

11

Передаваемая строка Кол-во выполненных условий Кол-во состояний Затрачено (сек)aaa 3 14 7cac 1 16 7abc 0 16 6

aaaaa 5 26 12cabac 5 60 27abcde 0 64 28

aaaaaaa 7 38 19cababac 29 164 84abcdefg 0 256 121

aaaaaaaaa 9 50 28cabababac 69 332 193abcdefghi 0 1024 480

Таблица 2. Производительность метода SCMC

5 Заключение

Целью этой работы было создание формального верификатора для SystemC-моделей, который позволил бы проверять непосредственно саму SystemC-модель без ее трансляции в язык одного из существующих верификаторов.Для реализации такого верификатора был выбран метод CMC, исследую-щий программу перебором всех возможных путей ее выполнения. Методпредполагает необходимость сохранять и восстанавливать состояние про-граммы, что в данном случае делается с использованием пакета DMTCP.

В результате выполнения задачи был успешно создан желаемый фор-мальный верификатор, названный SCMC. В отличие от существующих ве-рификаторов SystemC используемый подход позволяет охватить все множе-ство SystemC-моделей. Для проведения верификации в исследуемой SystemC-модели должны быть указаны контрольные точки, где производится ветвле-ние модели, либо проверяется желаемое свойство. Пользователю будут вы-ведены все случаи выполнения заданного свойства модели, а также будутвыведены пути исполнения модели, приведшие к выполненному свойству.

Существует проблема взрыва состояний, частично решаемая исключе-нием одинаковых веток графа состояний. Для экономии памяти в будущемможно будет добавить инкрементное сжатие контрольных точек SystemC-моделей, также разработать алгоритмы, ускоряющие его работу.

Список литературы

1. Кулямин В.В. Методы верификации программного обеспечения // Всероссий-ский конкурсный отбор обзорно-аналитических статей по приоритетному на-правлению Информационно-телекоммуникационные системы, 2008, 117 с.

2. Ansel J., Arya K., Cooperman G. DMTCP: Transparent Checkpointing for ClusterComputations and the Desktop // 23rd IEEE International Parallel and DistributedProcessing Symposium (IPDPS’09). Rome, Italy. May, 2009.

Page 117: TMPA-2013 Conference Proceedings

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

12

3. Berner D., Talpin J.-P., Patel H., Mathaikutty D.A., Shukla E. SystemCXML: anextensible SystemC front end using XML // Proc. of the Forum on specificationand design languages (FDL), 2005.

4. Black D.C., Donovan J. SystemC: from the ground up // Kluwer AcademicPublishers 2004. 263 p.

5. Blanc N., Kroening D., Sharygina N. Scoot: A tool for the analysis of SystemCmodels // Proc. of TACAS, 2008, pp. 467–470

6. Bronevetsky G., Marques D., Pingali K., Szwed P., Schulz M. Application-levelCheckpointing for Shared Memory Programs // Proc. of the 11th internationalconference on Architectural support for programming languages and operatingsystems, 2004. pp. 235–247..

7. Buchmann R., Petrot F., Greiner A. Fast cycle accurate simulator to simulate event-driven behavior // Proc. of Electrical, Electronic and Computer Engineering, 2004.ICEEC ’04. 2004, Cairo, Egypt. pp. 35–38

8. Castillo J., Huerta P., Martinez J.I. An open-source tool for SystemC to Verilogautomatic translation // Lat. Am. appl. res. v.37 n.1. 2007. p. 53-58.

9. Fey G., Große D., Cassens T., Genz C., Warode T., Drechsler R. Parsyc: Anefficient SystemC parser // Workshop on Synthesis And System Integration of MixedInformation technologies (SASIMI), 2004, pp. 148–154.

10. Grotker T., Liao S., Martin G., Swan S. System design with SystemC // KluwerAcademic Publishers 2002. 219 p.

11. KaSCPar. http://forge.greensocs.com/ja/Projects/KaSCPar12. Klingauf W., Geffken M. Design structure analysis and transaction recording in

SystemC // Proc. of FDL, 2006, pp. 169–17713. Marquet K., Moy M. PinaVM: a SystemC front-end based on an executable

intermediate representation // International Conference on Embedded Software,Scottsdale, USA, 2010. pp. 79–88

14. Marquet K., Moy M., Karkare B. A theoretical and experimental review of SystemCfront-ends // Verimag Research Report TR-2010-4. 2010. 14 p.

15. Moy M., Maraninchi F., Maillet-Contoz L. Pinapa: an extraction tool for SystemCdescriptions of systems-on-a-chip // EMSOFT ’05: Proceedings of the 5th ACMinternational conference on Embedded software. New York, NY, USA: ACM, 2005,pp. 317–324.

16. Musuvathi M., D.Y.W. Park, A. Chou, D.R. Engler, D.L. Dill CMC: a pragmaticapproach to model checking real code // Proc. of OSDI 02: Fifth Symposium onOperating Systems Design and Implementation, 2002. pp. 75–88

17. Scarpazza D.P., Brandolese C., Pomante L., Felice P.D. Parsing SystemC: anopen-source, easy-to-extend parser // IADIS International Conference on AppliedComputing, 2006, pp. 25–28

18. Schubert T., Nebel W. The Quiny SystemC front end: self-synthesising designs //Proc. of FDL. ECSI, 2006, pp. 135–143.

19. Singh L., Drucker L., Khan N. Advanced verification techniques: a SystemC basedapproach for successful tapeout / Kluwer Academic Publishers, 2004. 373 p.

20. SystemPerl. http://www.veripool.org/wiki/systemperl.21. Vardi M. Formal techniques for SystemC verification // Design Automation

Conference (DAC) 2007. San Diego, California. June 4–8, 2007. p. 188–192.

Page 118: TMPA-2013 Conference Proceedings

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

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

свойств надежности функционирования

С.Л. Френкель1 , В.Н.Захаров1, В.Г. Ушаков2

1 Институт проблем информатики РАН, Вавилова 44, корп. 2, Москва, РФ

([email protected], [email protected]) 2Московский гос. университет им. М.В. Ломоносова, Институт проблем

информатики РАН ( [email protected] ).

Аннотация. В статье приводятся некоторые результаты исследования и разработки алгоритмов и программ, позволяющих комбинировать решение различных задач функциональной верификации с анализом вероятностей проявления и компенсации сбоев в системе, представленной автоматной моделью, получаемой в результате синтеза системного уровня по ASM-спецификации проекта.

Ключевые слова: Верификация, отказоустойчивость

1. Введение

Разработчику программно-аппаратных систем на ранних этапах проектирования приходится сталкиваться с такими разными задачами как функциональная верификация проекта для проверки возможности реализации системой специфицированных (требуемой исходной спецификацией) функций, помехоустойчивости относительно определенных классов помех, производительности. Все эти задачи требуют различных подходов к их решению, с использованием разных математических моделей и проектных инструментов. В целом эти задачи трудоемки, требуют привлечения высококвалифицированного персонала и дорогостоящих средств проектирования. Ввиду крайне большого объема данных, необходимых для исчерпывающего решения указанных задач через моделирование (simulation) проектируемых объектов, большие усилия прилагаются для использования формальных методов верификации.

Общим требованием к формальной модели является ее способность использовать различные уровни абстракции, возможность добавлять постепенно те или иные аспекты реализации (например, микроархитектуру), то есть иметь возможность использовать иерархический стиль проектирования.

1 Работа выполнена при частичной поддержке грантов РФФИ 12-07-00109 и 13-07-00579.

Page 119: TMPA-2013 Conference Proceedings

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

При этом одним из путей снижения трудовых и финансовых затрат на верификацию может быть интеграция различных подходов и методов, позволяющих использовать одни и те же инструменты и исходные формализованные описания (input) для возможно большего числа задач. В статье излагается возможный интеграционный подход.

2. Унифицирующие свойства моделей цифровых систем

С точки зрения унификации подходов к различным задачам верификации для нас представляют интерес два способа описания систем на высоком уровне абстракции, для которых в литературе используют одну и ту же аббревиатуру, но разные названия и смысл, а именно Abstract State Machine [1,2] и Algorithmic State Machine [3]. Для удобства изложения мы будем использовать AbSM в первом случае и ASM во втором. Abstract State Machine, рассматриваемая в настоящее время как унифицированная модель вычислений, представляет собой систему переходов, реализующих конечное множество т.н. правил переходов (transition rules) вида if Condition then Updates, где Condition - некоторый предикат на указанном множестве, Updates - конечное множество операторов (assignments) вида f (t1, . . . , tn) := t, чье выполнение приводит к параллельному изменению значений аргументов функции f и получению ее значения на данном измененном наборе аргументов. Благодаря тому, что AbSM позволяет описывать изменения (переходы) абстрактных данных для произвольных множеств и функций, они могут быть использованы на различных иерархических уровнях описания проектируемой системы, что соответствует различным этапам проектирования. Ввиду возможности задания времени переходов [4], данная модель может быть использована как для функциональной спецификации, так и для получения временных характеристик выполнения задач, т.е. для анализа производительности. Это, очевидно, означает, что AbSM можно рассматривать как соответствующее средство интеграции различных задач проектирования. Однако указанная абстрактность означает необходимость использовать различные конверторы данных для перехода с уровня на уровень. Поэтому в наших работах мы использовали также другой формализм, основанный на “алгоритмических машинах состояний” (ASM) [3]. В самом общем виде ASM можно определить как направленный связанный граф, вершины которого соответствуют операциям, выполняемым на каждом шаге описываемого алгоритма, или условным переходам, а дуги задают последовательности выполнения операций. Пример и все необходимые пояснения приводятся в разделе 3.2. Подробное описание можно найти в [5]. Предложенная нами унификация спецификаций различных аспектов функционирования цифровой системы основана на использовании ASM-спецификаций, по которым выполняется высокоуровневый синтез цифровых схем, для более широкого круга задач проектирования. Например, такая спецификация может быть использована для формальной верификации функциональной корректности, для оценки временной корректности на уровне взаимодействий и протоколов, для оценки помехоустойчивости разрабатываемых архитектур. Показано, что ASM-спецификация, при

Page 120: TMPA-2013 Conference Proceedings

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

использовании разработанных в ИПИРАН программ генерации SMV и Spin-кодов и программ моделирования цепей Маркова [7], может выполнять интегрирующую (унифицирующую) функцию при высокоуровневом синтезе [7]. Программы SMV (Symbolic Model Verifier) [18] и Spin [19] предназначены для верификации проектов методом Model Checking аппаратных (SMV) и программных (Spin) систем.

Эта возможность обеспечивается тем, что для обоих классов задач верификации (функциональной и отказоустойчивости) используются одни и те же автоматные модели [7]. Существенным является также то, что при использовании для трансляции ASM-диаграмм программы синтеза цифровых систем Abelite [3] мы получаем структуру Крипке [5], позволяющую перебирать все возможные варианты работы верифицируемой системы, т.е. описывать недетерминированность ее поведения. Получаемое из ASM автоматное представление моделируемой системы выглядит следующим образом: am, fms(xi1,,…,xik), as, Y, (1) где am, as - текущее и следующее состояние автомата, fms(xi1,,…,xik) - функция возбуждения автомата (булевы выражения относительно входных переменных, определяющие условия переходов), и Y - вектор выходов. Это представление совместно со структурой Крипке позволяют осуществлять интерпретацию системных элементов на любых уровнях абстракции [5]. 3. Интеграция моделей и инструментов, предназначенных для решения задач функциональной верификации и оценки помехоустойчивости цифровых систем на ранних этапах проектирования

В настоящее время мы имеем определенный опыт использования ASM спецификаций для верификации различных проектируемых объектов, причем не только самих проектируемых систем, но и их верификационных тестов. Например, ASM использовалась для описания тестов верификации (через моделирование) проекта некоторого процессора. Неформально говоря, тесты представляют собой набор некоторых команд и данных, которые могут выполняться либо строго поочередно (очередную операцию можно подавать на выполнение только после того, как полностью завершена предыдущая), либо, в случае конвейерного выполнения операций, операции можно подавать последовательно друг за другом, не дожидаясь завершения предыдущей операции, либо одновременно могут подаваться несколько операций. Так как число операций может быть достаточно велико (несколько сотен), тест должен быть верифицирован на выполнение указанных условий упорядоченности, т.е. тестовое множество должно быть организовано таким образом, чтобы выполняемые операции не вступали в конфликты друг с другом, при том, что возможно взаимное влияние операций (например, ввиду использования одного и того же буфера данных).

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

Page 121: TMPA-2013 Conference Proceedings

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

Checking [8], состоящий в формальной проверке выполнения логической формулы, выражающей некоторое свойство “правильного” поведения модели системы. Автоматы Мили, необходимые для построения соответствующей модели системы, могут быть получены из ASM диаграмм выполнения множества тестов с использованием свойств декомпозируемости и иерархичности ASM-описаний (из-за ограниченного объема статьи детали здесь не приводятся).

В качестве другой задачи, решаемой на основе высокоуровневой ASM-спецификации проекта, рассмотрим возможность учета требований помехоустойчивости на ранних этапах проектирования.

3.1 Проблема верификации помехоустойчивости проектируемых цифровых систем на ранних этапах проектирования

По сути современное проектирование цифровых систем состоит в поиске компромисса между надежностью выполнения функциональных задач, производительностью и потреблением энергии. Причем существенной составляющей данной проблемы является обеспечение правильной и эффективной работы в условиях действия переходных помех, прямое действие которых ограниченно лишь сравнительно небольшим интервалом времени. Поэтому ошибки функционирования, вызываемые помехами, называются “мягкими” (soft) [8]. Важным примером является воздействие ионизированных частиц, порождаемых космическими лучами.

В настоящее время известно много способов защиты цифровых схем от действия различных внешних помех. Однако их применение связано с дополнительными аппаратурными и энергетическими затратами (повышением потребления электроэнергии), а также с возможным снижением производительности, как за счет увеличения суммарных задержек в дополнительных элементах (вентилях, элементах памяти), так и за счет необходимости ограничений скорости работы процессорных элементов. Дело в том, что энергопотребление растет примерно как квадрат частоты переключений, и это может лимитировать объем резервирования, например, из-за роста энергозатрат резервирующего оборудования. Все эти обстоятельства делают актуальной задачу выбора минимально необходимого числа элементов, защита (protection) которых необходима для обеспечения требуемого уровня надежности в присутствии т.н. SEU (single event upset, одиночных сбоев, то есть кратковременных событий, представляющих собой ошибочное изменение значения логического сигнала (переменной) в некоторой точке системы), возникающих под действием указанных выше внешних факторов (лучей, частиц и т.д. ).

В настоящее время предложен и активно развивается подход к определению критичных к действию помех элементов, которые необходимо обеспечить той или иной аппаратной защитой, с использованием формальных методов, Model Checking прежде всего [8]. Этот метод используется совместно с инжектированием в модель проектируемой системы возможных мутаций внутренних состояний. Этим способом определяют триггеры–защелки [8],

Page 122: TMPA-2013 Conference Proceedings

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

которые могут эффективно влиять на результат вычислений, и которые поэтому следует защищать от ошибок (ошибочного изменения состояний).

Преимущества Model Checking по сравнению с просто моделированием (симуляцией) модели устройства в присутствии инжектированных неисправностей состоит в том, что устраняется проблема обеспечения репрезентативности выбираемых входов (команд и данных), которые могут отобразить все возможные рабочие ситуации. Model Checking выполняет исчерпывающий анализ всех состояний системы, начиная с множества возможных начальных состояний.

Этот подход рассматривают и пытаются использовать не только как дополнение к известным процедурам формальной верификации функциональных свойств проектов цифровых устройств, но и как средство оценки полноты анализа надежностных свойств, и как средство анализа результатов с точки зрения снижения избыточности при обеспечении помехоустойчивых решений [11].

Хотя указанные выше помехи (лучи, частицы) непосредственно влияют на те или иные элементы оборудования (оперативную память, шины кэш), вызывая SEU, они приводят и к программным ошибкам. С программно-аппаратной (архитектурной) точки зрения эти ошибки в программе могут распространяться по управлению (control flow) и данным (data flow). Очевидно, что непосредственную связь указанных аппаратных сбоев реально можно установить (описать) только со сравнительно низкоуровневым представлением программ, например, на уровне машинных кодов или ассемблера. Существенным, однако, является то, что указанные формальные подходы к верификации устойчивости проектируемой системы к конкретному SEU [8] указывают лишь на потенциальную возможность того, что в данной точке может быть нарушено правильное функционирование проектируемого устройства, но реальное нарушение функционирования может зависеть от статистических свойств обрабатываемой информации, например, переменных fms(xi1,,…,xik) в функции, представленной в структуре ASM (1). При этом переходные ошибки, индуцированные SEU на некотором такте работы устройства, не обязательно запоминаются в элементах памяти на следующих тактах, что можно интерпретировать как самовосстановление устройства (self-healing). Поэтому желательно было бы дополнить формальную верификацию вычислением вероятностей такого самовосстановления.

Рассмотрим для этой цели вероятностную модель, предложенную в [6,9], важным свойством которой является возможность ее использования для уточнения выводов о рисках, связанных с SEU для конкретных переменных программы, полученных формальными методами, используя Model Checking [8].

3.2 Вероятностная модель

Разработана следующая модель для вычисления распределения вероятностей времени до самовосстановления после действия SEU. Пусть в начальный момент 0 под действием помехи (разовой) автомат X (называемый исправным, fault-free) переходит в состояние Y0 вместо состояния X0 (при этом предполагается, что действие помехи в выходном сигнале не проявилось).

Page 123: TMPA-2013 Conference Proceedings

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

Будем называть автомат, подвергшийся действию помехи, “неисправным” (faulty), и обозначать его как Y. Неисправный автомат Y действует на тех же входных сигналах с теми же переходами и выходными сигналами в зависимости от текущих состояний и входных сигналов. Так происходит до того момента, когда либо выходной сигнал неисправного автомата окажется отличным от выходного сигнала исправного автомата (проявилось действие помехи в выходном сигнале), либо состояния обоих автоматов совпадут. Считая входные сигналы автоматов независимыми случайными двоичными переменными, на произведении этих автоматов (автомата, состояния которого равны различным парам состояний указанных двух автоматов) определяется Цепь Маркова (ЦМ) Zt=(Xt, Yt), описывающая совместное функционирование ЦМ Xt и Yt до момента, когда либо выходной сигнал неисправного автомата окажется отличным от выходного сигнала исправного автомата (проявилось действие помехи в выходном сигнале), либо состояния обоих автоматов совпадут. Множества состояний S1,2, |S1,2| = n, обеих ЦМ одинаковы, начальные состояния X0, Y0, Y0 ≠ X0 детерминированы. Множество состояний ЦМ Zt представляет собой S = (i,j), i,j = 1,…,n, j ≠ i A0 A1, где состояние (i,j) означает, что исправный автомат находится в состоянии i, а неисправный – в состоянии j (отличном от состояния i исправного автомата), состояние A1 – неправильное функционирование (в результате действия помехи) уже проявилась в выходном сигнале), и A0 – произошло восстановление траектории функционирования автомата до проявления эффекта помехи на выходе. Число состояний этой ЦМ равно n(n – 1) + 2. Состояния A0 и A1 представляют собой поглощающие состояния двумерной цепи Маркова Zt.

Матрица P* переходных вероятностей ЦМ Zt вычисляется следующим образом. Пусть Zt находится в состоянии (i1,j1) и поступает входной сигнал x, переводящий ЦМ исправного автомата в состояние i2, а автомата, подвергшегося действию помехи, – в состояние j2, причем выходные сигналы автоматов y0 и y1. Тогда, возможны следующие ситуации: - если выходы y0 и y1 не совпадают, то ЦМ Zt попадает в поглощающее состояние A1; - если выходы y0 и y1 совпадают и совпадают состояния i2 и j2,то ЦМ Zt попадает в поглощающее состояние A0; - если выходные сигналы y0 и y1 совпадают, но не совпадают состояния i2 и j2 (в которые произошел переход обоих автоматом по действием входа x), то ЦМ Zt попадает в (i2,j2). Вероятности переходов вычисляются по известным вероятностям булевых значений независимых входных последовательностей, по известной булевой функции переходов f(xi1,…xin) (1). Подробнее алгоритм вычисления изложен в статье [6]. Введем обозначения: p(1)(t) – вероятность, того, что неисправное поведение автомата Y будет обнаружено (по выходу) не позже t-го шага (при этом до момента обнаружения неисправности автомат не восстановится);

Page 124: TMPA-2013 Conference Proceedings

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

p(0)(t) – вероятность того, что автомат Y восстановит свое правильное поведение не позже t-го шага (до момента восстановления неисправность не проявится по выходу, т.е. выходы обоих автоматов будут полностью совпадать); pi,j(t) – вероятность попадания ЦМ Zt в состояние (i,j) (т.е. исправного автомата X в состояние i, неисправного автомата Y в состояние j ≠ i, при этом до момента t состояния исправного и неисправного автоматов будут различными, но выходные сигналы совпадать). В терминах ЦМ Zt вероятность p(0)(t) представляет собой вероятность нахождения в момент t в поглощающем состоянии A0, вероятность p(1)(t) – в поглощающем состоянии A1, вероятность pi,j(t) - в непоглощающем состоянии (i,j) (j ≠ i). Начальное распределение (0)p определяется начальными состояниями исправного и неисправного автоматов. Если исправный автомат в начальный момент 0 находится в состоянии i0, а неисправный – в состоянии j0 ≠ i0, то p(i0,j0)(0) = 1, а остальные координаты вектора (0)p равны нулю. Распределение ЦМ Zt в момент t может быть вычислено из уравнения:

( ) ( 1) * (0)( *) .tp t p t P p P

Заметим, что мы считаем, что действие помех не приводят к появлению новых состояний в моделирующем автомате. Это предположение используется во многих работах по верификации устойчивости к действию помех [8,10, 11].

Рассмотрим применение данной модели к верификации устойчивости к сбоям конвейеризированного микропроцессора на стадии выборки инструкций из памяти. На рисунке 1 представлена соответствующая ASM-диаграмма режима, представляющая собой направленный граф с начальной вершиной Begin, финальной End, вершинами, соответствующими выполнению операций (прямоугольники) и условными вершинами (ромбы). Заметим, что “серые” вершины соответствуют вложенным ASM. Инструкции считываются в регистры IR1 (короткие инструкции) и IR2 (длинные), адреса инструкций – в PC (Program Counter). Сгенерированный программой Abelite соответствующий данной диаграмме конечный автомат (FSM) в форме Mealy имеет вид таблицы 1, входы, состояния и выходы в которой интерпретируются таблицей 2. Заметим, что строки "Logical conditions", относящиеся к условным переходам, определяют входные переменные FSM.

Page 125: TMPA-2013 Conference Proceedings

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

Рис. 1 ASM диаграмма фазы выборки конвейеризированного процессора Таблица 1. Таблица переходов автомата, формирующего операции выборки инструкций

am as X(am, as ) Y

a1 a1 x8x4 y8 a1 a7 x8~x4 y6 a1 a1 ~x8 --

a2 a1 x1 y5 a2 a1 ~x1 y7 a3 a2 x3 y1

a3 a5 ~x3x2 y4 a3 a1 ~x3~x2x1 y5 a3 a1 ~x3~x2~x1 y7

a4 a3 1 y2 a5 a6 x7x5 y4 a5 a1 x7~x5 --

a5 a6 ~x7x6 y4 a5 a1 ~x7~x6 -- a6 a1 1 y4 a7 a4 1 y3

Page 126: TMPA-2013 Conference Proceedings

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

Таблица 2. Структура переменных автомата в терминах микроопераций процессора

: Micro Operations

y1 : Fetch2 y2 : Fetch1

y3 : Int y4 : PCf:=PCf+1 y5 : Fetch2Oper2 y6 : CheckBranch y7 : Fetch2Oper1

y8 : DMACycle Logical Conditions

x1 : ShLodInpBran_in_F x2 : bool2std(IR1f(0to3)="1100")

x3 : IR1f(5) x4 : DMA x5 : FGO x6 : FGI

)x7 : IR1f(4 x8 : S

Пусть функциональную верификацию процессора планируется выполнить с помощью Model Checking, сравнивая поведение на уровне инструкций с поведением автомата в терминах микроопераций таблицы 2. Рассмотрим, например, выполнение следующего свойства: всегда, пока выполняется операция с DMA ((DirectMemory Access), фаза выборки ожидает ее окончания, чтобы избежать конфликтов. Как видно из таблиц 1 и 2, эти свойства связаны с выполнениями условий, задаваемых входными переменными x4, x8, и состояниями a1,a2. Тогда опасность (потенциальная возможность) неверного функционирования в результате SEU, приводящего к переключению того или иного бита, соответствующего переходу к неправильному состояния автомата, может быть также верифицирована с использованием стандартных средств верификации (SMV, Spin), задавая свойства, подлежащие верификации на том или ином языке CTL или LTL-типа (подробно этот вопрос рассматривается в [8]).

Учитывая что описанный выше алгоритм построения цепи Маркова для переходов автомата под действием SEU использует целочисленное кодирование состояний, присвоим каждому состоянию ak, k=1,2..7, таблицы 2 значение его индекса. Конкретный SEU, приводящий к сбою на время такта, мы можем описать, как указано выше, задавая единичную вероятность в векторе начальных состояний 2-мерной цепи Маркова Zt. Тогда, назначив вероятности единичных значений переменным x1, ... x8, мы можем оценить вероятность перехода в состояние, при котором на начальном такте работы системы (t=0) выполняется операция DMAcycle до команды “S” (Start), представляющей собой начало вычислений. В предложенной выше нотации этот сбой представляется как (1,2). При распределении входных переменныхx1=0.9, x2=0.8, x3=0.45, x4=0.7, x5=0.65, x6=0.5, x7=0.7, x8=0.7), модель дает следующие значения вероятностей возвращения к правильному функционированию автомата таблицы 2 за соответствующее число тактов после

Page 127: TMPA-2013 Conference Proceedings

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

прекращения действия причины сбоя: SH = (0.0, 0.034, 0.46, 0.55, 0.64, 0.68). Скажем, через 4 такта вероятность будет 0.64, что, разумеется не позволяет считать этот сбой несущественным. Однако для сбоя (5,2) (ошибка заполнения программного счетчика) получаем SH = (0.00, 0.79, 0.79, 0,85, 0.89, 0.92, 0.93), что в ряде случаев (в зависимости от требований к быстродействию и надежности проектируемой системы) может быть приемлемым. Соответственно, у разработчика есть некоторая свобода выбора - пытаться ли ввести дополнительную аппаратную защиту данных переменных (например, используя Triple Modular Redundancy (TMR –защиту [17]) или же нет. Заметим, что мы используем для верификации те же средства Abelite, что и для синтеза реальных ASIC или FPGA, и поэтому каждый сбой, описанный на высоком уровне (сбой перехода автоматной переменной), можно связать с аппаратным блоком проектируемой системы, реализующим данный переход. 4. Направление дальнейших исследований

Выше мы рассмотрели модель оценки помехоустойчивости для одного конкретного сбоя, специфицированного как (i,j) - ошибочный переход автомата в новое состояние j вместо i, определяемого спецификацией системы.

Чтобы построить модель учета действия различных сбоев можно рассмотреть семейство марковских цепей с данной матрицей вероятностей переходов P, Zt,F =< Pi, F, P> для данного списка возможных сбоев F, задаваемых единицей (единичной начальной вероятностью) в ячейке (i,j) в векторе начального распределения вероятностей P0

i , i=1,2,..,F, тогда как остальные ячейки – нулевые, как это описано в параграфе 3.2. Тогда [9] мы можем, используя формулу полной вероятности [13], выразить вероятность того, что за время t ни один из сбоев не приведет к ошибке функционирования автомата. Эта вероятность представляет собой характеристику устойчивости автомата, моделирующего проектируемое устройство, к указанному классу сбоев. При этом мы неявно предполагаем, что сбои наступают достаточно редко, и к началу некоторого сбоя (i,j), эффект действия предыдущего (k,l) полностью прекратился. Поэтому для учета вероятности (частоты) возникновения сбоев в настоящее время разрабатывается более общая модель. С методологической точки зрения предложенный нами подход представляет собой дополнение формальной верификации функциональных свойств вычислительной вероятностной моделью отказоустойчивости. При этом, хотя оба подхода используют общее входное описание в виде ASM, ряд данных приходится вводить независимо для каждой из моделей, а именно, свойства (property) на LTL или CTL для формальной верификации (хотя и с возможностью использования некоторых языковых конверторов, упрощающих для разработчика описание указанных свойств), и некоторые распределения вероятностей для оценки вероятности самовосстановления (раздел 3.2). Хотя соответствие (интерпретация) переменных автомата и элементов архитектуры проектируемой системы задается таблицами, подобными 1 и 2, для достаточно сложных систем, особенно для систем с конкуренцией вычислений за ресурсы, может возникнуть проблема непротиворечивости обеих

Page 128: TMPA-2013 Conference Proceedings

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

групп описании. В настоящее время предложено несколько формальных языков (моделей) совместного описания задач функциональной верификации и оценки производительности (Performance evaluation) [14,15]. В этих работах предполагается, что работа системы может моделироваться в терминах теории очередей, т.е. поведение проектируемой системы представляется в терминах обработки запросов некоторым сервером (или несколькими серверами) [15]. При этом функциональная спецификация дополняется вероятностным распределением времени обслуживания “заявок”, что представляется в языках типа PCTL (probability computation tree logic) [16]. Однако, для таких аспектов анализа производительности как отказоустойчивость, подобные модели не вполне естественны. Разработка этого вопроса представляется весьма перспективной.

5. Заключение На ранних этапах разработки программно-аппаратных систем перед

инженером – разработчиком часто встает проблема выбора наилучшей программной архитектуры (для данной среды), обеспечивающей максимальную вероятность корректного выполнения данного приложения в данной рабочей среде при заданном уровне случайных ошибок (soft-error rate). Мы выражаем отказоустойчивость (fault-tolerance) работы системы в терминах вероятностей переходов в конечном автомате, моделирующем работу системы. Существенно, что описания автоматов могут быть получены из ASM-диаграмм, используемых для спецификации проектируемой системы, что также позволяет сократить суммарную трудоемкость проектирования. Более того, различные аспекты проектирования устройства, такие, как функционально-временная корректность, устойчивость к сбоям (fault toleranсe), и даже оптимизация потребления электроэнергии системой (low power design) могут быть учтены, поскольку все эти задачи требуют использования FSM модели проектируемой системы, и эта модель автоматически строится по ASM-спецификации системы.

При этом вычислительная сложность оценки вероятностей самовосстановления O(n4) для рассматриваемой марковской цепи размера n(n-1)+2 существенно ниже вычислительной сложности реализации алгоритмов Model Checking [12], что определяется квадратичной вычислительной сложностью решения линейных уравнений Колмогорова-Чапмена. Литература 1. Egon Börger, Abstract State Machines: a unifying view of models of abstract state machines capture sequential algorithms // Annals of Pure and Applied Logic, 133, (2005), p. 149–171. 2. A. Blass, Y. Gurevich, Abstract state machines capture parallel algorithms // ACM Transactions on Computational Logic, 3, (2002). 3. S. Baranov, ASMs in high-level synthesis of EDA tool Abelite // in Proc. DESD’09 Int. IFAC Workshop, Valensia, Spain, 2009, pp. 195-200. Available: http://www.dcud.uz.zgora.pl/shw/dCUD-Baranov.pdf.

Page 129: TMPA-2013 Conference Proceedings

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

4. Васильев П.К. Расширение языка машин абстрактных состояний Гуревича рациональным временем // Вестник Санкт-Петербургского университета, Серия 10 «Прикладная математика информатика процессы управления», 2007, с. 90-100. 5. S.Baranov, S. Frenkel, V.Zakharov, Semi-formal verification for pipelined digital design based on Algorithmic State Machines // Информатика и ее применения, vol. 4, issue 4, 2010, p. 49- 60. 6. S. L. Frenkel, A. V. Pechinkin, Estimation of self-healing time for digital system under transient faults // Информатика и ее применения, vol. 4, issue 3, 2010, p. 2- 8. 7. S. Frenkel, Some probabilistic and formal techniques for fault tolerant design // Proceedings of 5th IEEE International workshop on Impact of Low Power Designs on Test and Reliability, Annecy, France, Jun. 2012, p. 16-17. 8. S.A. Seshia, W. Li, S. Mitra, Verification - guided soft error resilience // Proceedings of the Conference on Design, Automation and Test, DATE07, 2007, p.1442-1447,. 9. S. Frenkel, Some measures of self-repairing ability for fault-tolerant circuits design // Second Workshop on Manufacturable and Dependable Multicore Architectures at Nanoscale (MEDIAN'13), Avignon, France, May 30-31, 2013, p. 57-60. 10. U.Krautz, M. Pflanz, et al, Evaluating coverage of error detection logic for soft errors using formal methods // Proceedings of the Conference on Design, Automation and Test in Europe, vol. 1, 2006, pp. 1–6. 11. Souheib Baarir et al, Complementary Formal Approaches for Dependability Analysis // 24th IEEE International Symposium on Defect and Fault Tolerance in VLSI Systems, 2009. 12. S. Demri, F. Laroussinie, and Ph. Schnoebelen, A parametric analysis of the state explosion problem in model checking // Proc. 19th Ann. Symp. Theoretical Aspects of Computer Science (STACS'2002), vol. 2285 of Lect. Notes in Comp. Sci., Springer, 2002, p. 620-631.. 13. W. Feller, Introduction to Probability Theory and its Applications // vol. 1, Wiley, 1968. 14. Hermanns H., Herzog U., Katoen J.-P. Process algebra for performance evaluation // Theor. Comp. Sci. 274 (2002), p. 43–87. 15. Coste, et al, Quantitative evaluation in embedded system design: Validation of multiprocessor multithreaded architectures // In: DATE. IEEE (2008), p. 88–89. 16. Hansson H. and Jonsson B. A logic for reasoning about time and reliability // Formal Aspects of Comp. 6, 5 (1994), p. 512–535. 17. O. Ruano, J. A. Maestro, P. Reviriego, A fast and efficient technique to apply Selective TMR through optimization // Microelectronics Reliability, 51, 2011, p. 2388–2401. 18. K.L. McMillan, The SMV language // CadenceBerkey Lab, 1998. 19. G.J. Holzmann, The Model checker SPIN // IEEE Transaction on Software Engineering, vol.23, 1997, p. 76-95.

Page 130: TMPA-2013 Conference Proceedings

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

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

для Linux-контроллеров

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

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

[email protected]

Аннотация. В статье рассмотрены некоторые особенности разработки

программного обеспечения для современных встраиваемых систем,

работающих под управлением операционной системы Linux. Описанный

подход является альтернативой для средств проектирования стандарта

МЭК и предназначен для реализации эффективных алгоритмов цифрового

управления технологическими установками.

Ключевые слова. Программируемый логический контроллер,

операционная система Linux, процессор ARM, кросс-компиляция,

toolchain, реализация на языке Си, цифровое адаптивное управление, ssh-

протокол, научная библиотека GNU GSL, средства межпроцессного

взаимодействия.

1 Введение

На сегодняшний день ведущие производители промышленных компьютеров

(JetBox, Atmel, Techbase и др.) и программируемых логических контроллеров

(WAGO, ICP DAS, NPE и др.) предоставляют пользователям возможность

реализовывать гибкие и эффективные алгоритмы цифрового управления на

языках высокого уровня благодаря поддержке многозадачной операционной

системы (ОС) Linux [1].

В современном ядре ОС Linux большинство системных вызовов являются

вытесняемыми и имеются таймеры высокого разрешения. Вследствие этого

Linux начинает занимать области, ранее принадлежащие классическим ОС

реального времени, таким как QNX, OS-9 и VxWorks [2–4]. Поддержка

спецификации POSIX данными ОС позволяет сравнительно легко переносить

программы между ними.

К преимуществам Linux-устройств можно отнести также низкую цену (в

своем сегменте средств автоматизации), открытую архитектуру, низкие

требования к аппаратным ресурсам [5].

В связи с высокими требованиями, предъявляемыми сегодня к качеству

выпускаемой продукции, разработка программного обеспечения (ПО) под

описываемые вычислительные системы весьма актуальна [6–8]. В то же время,

Page 131: TMPA-2013 Conference Proceedings

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

как показывает практика работы с Linux-контроллерами отечественного

производства (например, ПЛК серии 304/308 фирмы «Овен»), пользователь по

причине отсутствия универсальных пошаговых инструкций сталкивается с

серьезными не для профессионала проблемами. К ним можно отнести

следующие [9]:

необходимость модификации и конфигурирования ядра Linux;

необходимость поиска и построения инструментального пакета (toolchain);

необходимость интеграции дополнительных драйверов, приложений,

библиотек;

необходимость тестирования, отладки и масштабирования проекта.

Указанные причины, по мнению авторов, сдерживают широкое применение Lin-

ux-контроллеров и заставляют разработчиков использовать ограниченные

возможности языков стандарта МЭК (язык структурированного текста,

функциональных блоков, релейных схем и др.).

Изложенный далее материал позволяет ликвидировать проблему

масштабирования и быстрого реконфигурирования встраиваемого

программного обеспечения. Что касается переноса исполняемых файлов с

персонального компьютера (ПК) на целевую платформу, то рассмотрено

конкретное решение для процессора ARM AT91RM9200 фирмы ATMEL, на

базе которого работает большое количество отечественных и зарубежных

контроллеров, в частности ПЛК304/308 «ОВЕН». Наиболее важные

рекомендации по общему порядку действий даны в работах [9, 10].

2 Мультипроцессный комплекс управления

технологическими установками

Для класса апериодических объектов с одной доминирующей постоянной

времени, подверженных за технологический цикл девиации параметров в

широких пределах, что в свою очередь требует перенастройки коэффициентов

регулятора, разработана адаптивная многопроцессная управляющая система,

функциональная схема которой представлена на рис. 1 [11]. За основу принята

классическая САУ с регулятором состояния и наблюдателем [12].

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

технологического объекта управления, которые в свою очередь используются

для расчета коэффициентов настройки динамического регулятора.

В состав мультипрограммного продукта входят следующие процессы [13]:

«диспетчер», «регулятор состояния», «наблюдатель полного порядка»,

«адаптатор», «задающее устройство эталонного сигнала», «цифровая модель

объекта управления», «связь с реальным объектом», «идентификаторы»

(«пассивный идентификатор», «идентификатор однократного действия»,

«идентификатор многократного действия»). Данный комплекс реализован на

Page 132: TMPA-2013 Conference Proceedings

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

языке Си с помощью GNU Scientific Library (GSL) v1.3 – библиотеки для

научных расчетов. В качестве средств межпроцессного взаимодействия

используется разделяемая память и семафоры System V.

Рис. 1. Цифровая адаптивная самонастраивающаяся система управления: ОУ – объект

управления; И – идентификатор; А – адаптатор; Н – наблюдатель; РС – регулятор

состояния

Главное преимущество мультипроцессной организации цифровой системы

управления заключается в том, что на основе небольших

узкоспециализированных программ можно собирать целые комплексы

произвольной конфигурации и теоретически неограниченной сложности

(именно такой подход отвечает идеологии ОС UNIX [14]). В частности, в

зависимости от требований технологического процесса «идентификаторы»

реализованы в трех вариантах: «пассивный идентификатор», «идентификатор

однократного действия», «идентификатор многократного действия» [11].

Процесс «диспетчер» призван координировать работу всех остальных

программ. При запуске он получает два параметра: первый задает режим работы

(0 – асинхронный, 1 – синхронный), второй – имя конфигурационного файла.

При асинхронном режиме обмен данными между процессами осуществляется

по их готовности и происходит с максимально возможной для данной

вычислительной системы скоростью. Данный способ взаимодействия

применяется для моделирования поведения системы управления и может быть

использован при отладке и тестировании программ на ПК.

При синхронном режиме все вычисления и межпроцессная коммуникация

происходят по команде от источника синхросигнала, которым является таймер

реального времени. Он генерирует импульсы с заданным пользователем

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

управления работой технологической установки в режиме реального времени.

Конфигурационный файл содержит следующую информацию: количество

регуляторов в системе управления, количество процессов-участников, не

Page 133: TMPA-2013 Conference Proceedings

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

включая «диспетчер», количество семафоров, а также порядок объекта

управления и период квантования.

Структурная схема установки, на которой была развернута мультипроцессная

система адаптивного управления представлена на рис. 2. Она включает в себя

персональный компьютер, сетевой коммутатор, ПЛК308 фирмы «Овен», модуль

аналогового ввода МВА8 фирмы «Овен», модуль дискретного ввода-вывода

МДВВ фирмы «Овен», твердотельное реле фирмы «Fotek», электрическую печь

(объект управления) и датчик температуры.

Рис. 2. Структурная схема САУ: 1 – кабель Ethernet; 2 – кабель RS-485; 3 – широтно-

импульсный сигнал (ШИМ); 4 – сигнал обратной связи

В ходе своей работы программный комплекс считывает по RS-485 c МВА8

сигнал с датчика (датчиков) температуры и выдает в соответствии с

заложенным алгоритмом управляющее воздействие в виде процентного

изменения мощности на модуль МДВВ, тот в свою очередь формирует на

выходе ШИМ сигнал, а твердотельное реле коммутирует нагрузку

(электрический нагреватель). Контролируемые параметры могут быть переданы

на персональный компьютер или панель оператора. Для этого целесообразно

использовать сетевые сокеты.

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

представлены на рис. 3 на примере решения задачи стабилизации температуры

печи при уменьшении напряжения питания с 220 В до 120 В, начиная с 4000 с.

Как видно из рис. 3 а, применение традиционного ПИД-регулятора не позволяет

оперативно отреагировать на возмущение и приводит к недопустимому

снижению температуры, в то время как адаптивная система (рис. 3 б)

обеспечивает высокие статические и динамические показатели.

Page 134: TMPA-2013 Conference Proceedings

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

а) б)

Рис. 3. Исследование работы мультипроцессной системы управления на незагруженной

печи при внесении возмущающего воздействия: а) работает неадаптивная система; б)

работает адаптивная система

3 Подготовка и запись исполняемых файлов в контроллер

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

(ПЛК308), работающей под управлением процессора ARM9, на ПК с ОС Linux

(uCLinux v 2.6), установлен и сконфигурирован набор необходимых программ –

toolchain фирмы «Ronetix» – ronetix-arm-linux-uclibc-4.1.2 [15], благодаря

которому можно осуществить кросс-компиляцию исходных кодов. Диаграмма

развертывания описываемой системы представлена на рис. 4.

Page 135: TMPA-2013 Conference Proceedings

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

Рис. 4. Диаграмма развертывания мультипрограммной системы управления

При выборе toolchain необходимо знать процессор целевой платформы.

Также следует проверить корректное выполнение собранных вместе со

специальными библиотеками программ на ОС, установленной на ПЛК.

Для сборки программ можно использовать следующий скрипт, получающий

имя исходного файла в качестве параметра командной строки:

F=$1

Fo=$F.o

Fc=$F.c

Fa=$F.arm

arm-linux-gcc -I/usr/local/include -o $Fo -c $Fc

arm-linux-gcc -o $Fa $Fo

Для сборки программы вместе со специальными библиотеками (в нашем

случае использовались статические библиотеки gsl) их следует указать явно:

Page 136: TMPA-2013 Conference Proceedings

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

F=$1

Fo=$F.o

Fc=$F.c

Fa=$F.arm

arm-linux-gcc -I/usr/local/include -o $Fo -c $Fc

arm-linux-gcc -o $Fa $Fo ./lib/libgsl.a./lib/libgslcblas.a

Для копирования исполняемых файлов на ПЛК можно воспользоваться

различными приемами, а именно:

Применяем команду scp, использующую безопасный шифрованный протокол

ssh. Например: scp ./myprog root@plc308:/home/arm/myprog. При

необходимости можно составить пакетный файл, копирующий за один прием

несколько файлов.

Если важна наглядность, можно использовать консольный файловый

менеджер mc, настроив одну из его панелей на удаленное подключение по

тому же протоколу ssh: /#sh:root@plc308/home/arm.

Представленная технология разработки и способ переноса программ прошли

испытание на реально работающем оборудовании и подтвердили свою

эффективность.

4 Выводы

В статье рассмотрены особенности разработки программного обеспечения для

ПЛК-Linux и способ переноса программ на целевую платформу. Описанный

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

для встраиваемых Unix-систем.

Библиографический список

1. Все для автоматизации. Встраиваемые компьютеры, АСУ ТП, коммуникации,

http://empc.ru/e-store/compact_pc_ark/

2. VxWorks, http://www.windriver.com/products/vxworks/

3. QNX, http://www.qnx.com

4. OS-9, http://www.radisys.com/products/microware-os-9/

5. Горбунов Н. О выборе встраиваемой ОС для проекта // СТА. – 2011. – 2. – С. 22-28

6. Ицкович Э.Л. Проблемы развития контроллеров российских производителей //

Промышленные АСУ и контроллеры. – 2007. – 2

Page 137: TMPA-2013 Conference Proceedings

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

7. Ицкович Э.Л. Методы совершенствования систем регулирования технологических

процессов // Промышленные АСУ и контроллеры. – 2011. – 1. – С. 3-9

8. Колесников А.А. Промышленный компьютер на базе Linux со встроенным GSM-

модулем // ИСУП. – 2009. – 1

9. Даммер С. О реальной стоимости «доморощенной» Linux // СТА. – 2010. – 4. – С.

20-26

10. Zimmerly B. Install the GNU ARM toolchain under Linux // EN, developerWorks, May,

2009

11. Староверов Б.А., Олоничев В.В., Смирнов М.А. Реализация законов адаптивного

управления технологическими установками на Linux-контроллерах //

Промышленные АСУ и контроллеры. – 2012. – 7. – С. 48-53

12. Изерман Р. Цифровые системы управления. М.: Мир, 1984. – 541 с.

13. Олоничев В.В., Смирнов М.А., Староверов Б.А. Мультипроцессный комплекс

цифрового управления технологическими установками. Свидетельство о

государственной регистрации программы для ЭВМ 2011611749. © М.:

РОСПАТЕНТ, 2011

14. Реймонд Э. Искусство программирования для Unix. – М.: Издательский дом

«Вильямс», 2005

15. Toolchain ronetix, http://www.ronetix.at

Page 138: TMPA-2013 Conference Proceedings

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

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

Басок Б. М., Гречин А.А.1

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

119454, Россия, г. Москва, Проспект Вернадского, 78 [email protected]

Aннотация. Рассматривается статистический метод проверки полноты тестов, основывающийся на анализе результатов работы программ и математических моделей дискретных устройств с внесѐнными дефектами. В работе предлагается существенно сократить временные затраты при оценке качества тестов данным методом, с одной стороны, путѐм внесения кратных дефектов, с другой, – путѐм взаимного использования результатов анализа тестов объекта тестирования и отдельных его компонентов. Приводятся экспериментальные данные, подтверждающие эффективность предлагаемых подходов. Ключевые слова: полнота тестов, анализ тестов, кратные отказы, мутации.

1 Введение. Постановка задачи Важнейшей характеристикой тестов программных систем (ПС) и дискретных устройств (ДУ) является их полнота. Под полнотой теста или его проверяющей способностью принято понимать [1,2] выраженное в процентах отношение выявляемых данным тестом отказов заданного класса к общему их числу. От полноты тестов напрямую зависит качество контролируемого объекта. Поэтому задача синтеза тестов высокой полноты является одной из важнейших задач контроля любого продукта на всех этапах его разработки и эксплуатации. При этом следует отметить, что, как правило, тесты ПС и существенная часть тестов ДУ создаются и отлаживаются вручную, и разработка новых дополнительных тестов для повышения полноты контроля требует больших затрат времени и средств.

Обычно при проверке полноты функциональных тестов ПС используются методы, основывающиеся на покрытии кода программы или методы, базирующиеся на оценке количества охваченных тестом отдельных функций ПС [3].

Наряду с данными методами для проверки полноты тестов используется метод, основывающийся на анализе результатов выполнения тестов для ПС с искусственно введенными одиночными постоянными дефектами из списка отказов заданного класса и исходной ПС. При этом предполагается, что данный метод применяется после того, когда все собственные дефекты, обнаруженные данными тестами, исправлены, и влияние не обнаруженных ими собственных

Page 139: TMPA-2013 Conference Proceedings

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

дефектов ПС невелико. Указанный метод является некоторым аналогом классического метода, применяемого при анализе тестов ДУ и основывающегося на сравнении результатов моделирования исправной и неисправной ДУ[4].

Известны два подхода при реализации данного метода. Первый из них [5,6] основывается на внесении дефектов непосредственно в объектный код ПС. Такими дефектами могут быть, например, инверсия бита или байта объектного кода программы.

Второй подход, получивший название мутационного анализа [7-10], основывается на внесении в исходный текст программы незначительных дефектов (мутантов). По определению [7] мутант – это одиночное синтаксически корректное изменение подлежащей тестированию ПС. Специальные программы – генераторы мутантов - формируют их списки. Мутанты, входящие в список, осуществляют либо замещение констант, либо замещение переменных, либо замещение операторов. Генераторы мутантов строятся на основе синтаксического анализа исходного кода ПС[7].

Первый подход применим, в первую очередь, при анализе тестов ПС, для которых отсутствует доступ к исходному коду.В то же время, для обеспечения безопасности работы эксплуатируемых ПС необходимо убедиться в высокой степени их надежности. Поэтому в любой момент может возникнуть необходимость в оценке качества предоставленных пользователю функциональных тестов, поскольку в редких случаях технологии разработки ПС, применяемые разработчиками включают обязательный этап тестирования безопасности [6].

Второй метод особенно полезен, поскольку с его помощью можно точно установить место внесенного дефекта и разрабатывать дополнительные тесты для выявления дефектов, не обнаруженных анализируемыми тестами. Кроме того, при реализации второго подхода, в отличие от первого, отсутствует опасность того, что внесение искусственного дефекта в ПС исказит операционную среду. Впрочем, данный недостаток можно преодолеть путем запуска ПС в системе виртуальных машин. При этом отказ, внесение которого приводит к искажению операционной среды, можно считать выявляемым.

Описанные подходы применимы и при тестировании поведенческой модели ДУ на языке описания аппаратуры HDL, в частности на VHDLи Verilog,и анализе собственно тестов ДУ, представленных этой моделью [9,11].Например, в [9] описаны принципы разработки генератора мутаций для ПС на VHDL.

Главным недостатком, как первой, так и второй реализации рассматриваемого метода оценки полноты тестов ПС являются чрезвычайно большие затраты времени, как следствие наличия большого количества мутантов или возможных искажений разрядов объектного кода ПС. Даже при тестировании сравнительно небольших ПС их количество может достигать многих десятков тысяч. При тестировании программ, содержащих несколько тысяч операторов, это число может многократно увеличиться. Например, при тестировании программы, реализующей метод Монте-Карло, генератор выдал более девятисот тысяч мутантов [10].

В некоторых работах [7] были рассмотрены методы сокращения множества

Page 140: TMPA-2013 Conference Proceedings

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

рассматриваемых мутантов путем выделения групп эквивалентных мутантов и при оценке полноты тестов анализировать только одиночных представителей этих групп. Однако, как показано в [7], список анализируемых отказов сокращается не более чем на 8% - 10%. Другой подход, основывается на замене общего списка мутантов некоторой его выборкой, как правило, это некоторая часть общего списка, например, в [7] случайным образом выбирается 10% общего списка дефектов. Тем не менее, выбранный список оказывается достаточно большим. Кроме того в подобных работах отсутствует обоснование размеров выборки. В этом случае обычно полагаются на накопленный в данной области опыт. Для существенного сокращения времени при реализации метода оценки полноты в работе [12] предложен и обоснован способ, известный как статистический. В соответствии с этим способом при анализе тестов используется не полное множество отказов, а некоторая небольшая случайная выборка. Согласно [12] для случайной выборки из 400 отказов заданного класса можно гарантировать, что полнота тестового набора для всей совокупности отказов заданного класса отличается не более чем на 5% от истинного значения с достоверностью 0,95. Величина выборки не зависит от сложности и размеров объекта тестирования. Таким образом, количество модифицированных неисправных копий анализируемого объекта (ПС или ДУ) оказывается фиксированным и сравнительно небольшим.

Статистический способ оценки полноты был программно реализован и показал свою эффективность при многолетней эксплуатации программного комплекса моделирования, синтеза и анализа тестов, разработанного в ИНЭУМ и внедренного в ряде организаций, а также при анализе полноты тестов СБИС повышенной сложности с помощью первого в Советском Союзе многопроцессорного программно-аппаратного комплекса-ускорителя логического моделирования, разработанного в ИНЭУМ [13].

В работах [5,11] обсуждаются возможности применения статистического способа оценки полноты при мутационном подходе и искажении объектного кода программы.

Однако, несмотря на ряд преимуществ статистического способа проверки полноты абсолютная величина временных затрат при его использовании остается весьма значительной. В первую очередь, это касается затрат времени при анализе тестов программ с невысокой проверяющей способностью. Так при анализе пяти тестов программы размер исполнительного модуля которой составляет 18 кбайт, понадобилось 1708 прогонов данной программы. Если предположить, что время выполнения программы составляет одну минуту, то временные затраты составят более 28 часов. При этом несмотря на то, что имеется такой источник сокращения времени, как возможность распараллеливания процесса оценки полноты, к примеру на нескольких компьютерах, величина временных затрат остается существенной.

В данной работе рассматриваются два подхода к сокращению времени оценки статистической полноты тестов. Первый подход основывается на анализе тестов в классе одиночных константных отказов путѐм внесения кратных дефектов из данного класса. Второй подход базируется на совместном

Page 141: TMPA-2013 Conference Proceedings

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

анализе интеграционных тестов объекта контроля и тестов отдельных его частей.

2 Метод внесения кратных отказов

В работе одного из авторов данной статьи [14] был предложен метод анализа тестов ДУ, называемый методом моделирования кратных отказов. В соответствии с этим методом процесс проверки полноты тестов можно ускорить, если вносить не одиночные, а кратные отказы. Последние можно получить путѐм случайного разбиения списка невыявленных предыдущими тестами отказов на небольшие непересекающиеся группы одного размера (возможно последняя из групп окажется меньше). Отказы объединяются в группы случайным образом. При этом в соответствии с гипотезой о редкой компенсации кратных отказов [1,11] считается, если тестом не выявляется полученный таким образом кратный отказ, то не выявится и не один из одиночных дефектов, входящих в данную группу. В том случае, если состояния выходов модели объекта тестирования с внесѐнным кратным отказом отличаются от состояний одноименных выходов модели исправного объекта, следует проверить возможность выявления тестом дефектов, образующих кратный отказ по одному.

В работе [14] обосновывается близкий к оптимальному размер групп для списка дефектов, оставшихся не выявленными после анализа группы первых тестов и относящихся к классу трудно проверяемых отказов. В соответствии с приводимыми в работе [14] оценками применение указанного метода повысит скорость анализа качества тестов в несколько раз.

В докладе применяется подход, использующий, с одной стороны, статистический способ проверки полноты тестов, с другой, – метод кратных отказов. Этот подход применим как для ПС, так и для ДУ. В соответствии с данным подходом не выявленные очередным тестом отказы из выборки [5,12] разбиваются на группы. Размер группы определяется исходя из минимизации математического ожидания случайной величины количества прогонов теста [14]. Общее количество прогонов теста определяется как сумма двух слагаемых: количества прогонов равных количеству полученных групп отказов и количества прогонов равного количеству одиночных дефектов, образующих обнаруженные кратные дефекты.

Таким образом, величина группы при анализе полноты теста i может быть определена путем минимизации функции, имеющей следующий вид:

Gi

j i

ii

ii jN

jLNG

GF1

1

1111)( (1)

где 1iL - количество выявленных дефектов на предыдущем (i-1)-ом тесте, iN – количество дефектов заданного класса, оставшихся невыявленными после анализа предыдущих (i-1) тестов.

Размер группы для анализа качества первого теста можно принять равным единице, учитывая тот факт, что первые тесты обычно обладают хорошими

Page 142: TMPA-2013 Conference Proceedings

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

проверяющими свойствами. С другой стороны, как показали эксперименты, эту величину можно увеличить до трѐх.

Если очередной тест не выявил ни одного отказа, то переменной в функции (1) можно присвоить не равное нулю значение аналогичной переменной, определенное ранее для ближайшего из предыдущих тестов.

Данный подход был апробирован при анализе тестов группы промышленных консольных приложений (консольный тип был выбран для удобства автоматизации процесса проверки полноты), работающих в операционной среде Windows. В качестве моделей отказов использовались постоянные дефекты типа инверсии бита/байта. Результаты анализа тестов методами одиночных и кратных отказов с использованием статистической выборки моделируемых отказов показали, что количество прогонов после первых пяти тестов при реализации метода кратных отказов сокращается в три раза, а при анализе полноты десяти тестов выигрыш во времени может достигнуть одного порядка.

В Таблицах 1 и 2 приведены некоторые экспериментальные данные. Испытания проводились для пяти тестов, проверяющих работу программы, исполнительный модуль которой занимает примерно 18 килобайт.

Таблица 1. Статистика прогонов тестов для одиночных отказов.

Номер теста

Кол-во отказов

Размер группы

Кол-во групп

Кол-во выявл. групп

Кол-во выявл. отказов

Всего прогонов

1 400 1 400 66 66 400

2 334 1 334 5 5 334

3 329 1 329 2 2 329

4 327 1 326 1 1 327

5 318 1 318 9 9 318

Итого 1708

Таблица 2. Статистика прогонов тестов для кратных отказов.

Номер теста

Кол-во отказов

Размер группы

Кол-во групп

Кол-во выявл. групп

Кол-во выявл. отказов

Всего прогонов

1 400 3 134 55 66 299

2 334 3 112 5 5 127

3 329 9 37 2 2 55

4 327 10 33 1 1 43

5 318 10 33 8 9 113

Итого 637

Средняя статистическая полнота тестов - 21%.

Page 143: TMPA-2013 Conference Proceedings

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

Увеличение выигрыша во времени от теста к тесту объясняется резким сокращением количества выявляемых отказов и тем, что в списке не выявленных отказов остаются отказы, относящиеся к подмножеству так называемых «трудно проверяемых».

Данные, помещенные в Таблицы 1 и 2, наглядно показывают выигрыш во времени при использовании метода кратных отказов по сравнению с методом внесения одиночных отказов примерно в 2,7 раза.

Кроме того, проведенные эксперименты продемонстрировали, что эффективность метода кратных отказов тем выше, чем меньше полнота тестов. При этом экспериментально установлено, что существует некоторый порог полноты анализируемого теста (30%-40%), при превышении которого использование кратных отказов нецелесообразно. Однако следует заметить, что, как правило, полнота отдельных тестов в классе рассматриваемых отказов не превышает 25%.

Полученные результаты показали, что отказы из случайной выборки, объединенные в группу, мало влияют друг на друга. Это позволяет предполагать, что подобный алгоритм будет особенно полезен при реализации мутационного подхода.

3 Совместный анализ интеграционных тестов объекта контроля и тестов его отдельных частей

Как правило, полнота анализируемых тестов не является удовлетворительной, и для выявления не обнаруженных отказов следует разрабатывать дополнительные тесты. Это весьма трудоѐмкий процесс. Поэтому в данной работе предлагается, прежде чем приступить к синтезу дополнительных тестов, использовать для повышения полноты интеграционных тестов системы возможности тестов компонентов, и наоборот: использовать результаты оценки полноты интеграционных тестов для повышения качества проверки отдельных компонентов. Использование такого подхода сократит количество не выявляемых указанными тестами дефектов и, следовательно, сократит время для разработки дополнительных тестов.

Следует отметить, что в работе [15] предлагался оригинальный метод компонентного тестирования информационных систем, позволяющий на основе выделения наиболее часто встречающихся типов ошибок в программе выявлять их на уровне компонентов программ.

Суть предлагаемого в настоящей работе подхода заключается в следующем. Вначале осуществляется синтез тестов компонентов, поиск и исправление дефектов обнаруженных с их помощью в этих компонентах. После завершения данного этапа контроля аналогичные процедуры выполняются для системы с применением интеграционных тестов системы.

Теперь, после выявления и исправления всех обнаруженных тестами компонентов и тестами системы отказов можно приступить к оценке статистической полноты данных тестов в классе одиночных отказов (например, мутантов). Очевидно, что как дефекты, не выявляемые тестами системы, могут

Page 144: TMPA-2013 Conference Proceedings

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

быть выявлены тестами компонентов, так и невыявленные отказы компонентов могут быть обнаружены тестами системы.

Поэтому следует проанализировать возможность выявления непроверенных отказов интеграционных тестов системы тестами компонентов, которым эти отказы принадлежат. Для этого предлагается взять список непроверенных отказов после определения статистической полноты и путѐм последовательного внесения этих отказов в соответствующие компоненты определить, выявляют тесты компонентов эти отказы или нет.

Аналогичную процедуру можно применить для анализа списка непроверенных отказов компонентов. В этом случае непроверенные отказы компонентов последовательно вносятся в компонент, собирается версия системы и выполняются интеграционные тесты.

Как показали эксперименты, интеграционные тесты выявляют не менее 10% из невыявленных тестами компонентов отказов-мутантов.

Заключение

В работе рассматривался статистический метод оценки полноты тестов ПС и ДУ, обсуждались его достоинства и недостатки. Для модификации данного метода были предложены два подхода. Первый из них основывается на использовании кратных отказов вместо одиночных. Его применение позволит сократить время проверки полноты тестов в несколько раз. При этом показано, что в отличие от предложенного в [14] метода данный подход можно применять, начиная с первого теста. Второй подход использует пересечение множеств отказов контролируемого объекта и его отдельных компонентов. Благодаря этому удается повысить полноту, как интеграционных тестов, так и тестов отдельных компонентов ПС и ДУ и сократить время разработки дополнительных тестов. В качестве дальнейших исследований в области оценки качества тестов нам представляется актуальным продолжать работы в области сокращения временных затрат. Одним из путей здесь видится сокращение выборки из множества отказов за счет некоторой потери точности как это предлагается, например, в [5,16]. Перспективным направлением является применение статистических методов для оценки качества и отказоустойчивости встроенных систем, когда имитация отказов сводится к внесению искусственных неисправностей в программное обеспечение этих систем [17].

Литература

1. Гробман Д.М. Программный контроль и диагностика неисправностей ЦВМ. // Диагностика неисправностей вычислительных машин. М.: Наука. 1965 г. С. 7 – 22.

Page 145: TMPA-2013 Conference Proceedings

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

2. Скобцов Ю. А., Сперанский Д. В., Скобцов В.Ю.Моделирование, тестирование и диагностика цифровых устройств. // Учебное пособие. М.: ИНТУИТ. 2012 г. 440 с. 3. Синицин С.В., Налютин Н.Ю. Верификация программного обеспечения. // Учебное пособие. М.: Бином. 2008 г. 307 с. 4. Seshu S. On an Improved Diagnosis Program // IEEE Trans. on Elec. Com-puters. 1965. Vol. 12, February, p. 76-79. 5. Корчемный Д.И. Оценка полноты тестирования методом последовательного анализа. // Вопросы радиоэлектроники. Сер. ЭВТ. 1980 г. Вып.17. С. 68 – 74. 6. Благодаренко А.В. Статистический и динамический анализ программного обеспечения без исходных текстов. // Проблемы информационной безопасности в системе высшей школы: труды XIV всероссийской научной конференции.–М.:МИФИ, 2007г. С. 33-34. 7. Mattias Bybro. A Mutation Testing Tool for Java Programs, Ett verktyg för mutationstestning av Javaprogram Examensarbete i Datalogi, 2003, 20p., http://www.nada.kth.se/~karlm/a_mutation_testing_tool_for_java.pdf. 8. Harman M., YueJia, Langdon W.B. A Manifesto for Higher Order Mutation Testing, Software Testing, Verification, and Validation Workshops (ICSTW), 2010 Third International Conference on, 2010, 6-10 April, p.80-89. 9. Lorez C., RiesgoT.,De la Torre E.,Useda J. A method to perform error simulation in VHDL // Desing of Circuits and Integrated Systems Conference. Madrid (Spain), 1998. p. 495-500. 10. Offutt A.J., Untch R.H. Mutation 2000: Uniting the Orthogonal // Mutation Testing in the Twentieth and the Twenty First Centuries San Jose, 2000. p. 45-55. 11. Басок Б.М., Гречин А.А. О едином подходе при анализе тестов дискретных устройств и программ. // Вопросы радиоэлектроники. Сер. ЭВТ. 2010 г. Вып.3. С. 140 – 145. 12. Гробман Д.М. Статистический способ определения полноты тестов. // Тезисы докладов IV Всесоюзного совещания по технической диагностике. Черкассы. 1979 г. С. 9 – 11. 13. Сергеев Б.Г., Басок Б.М., Бродский М.А. Использование аппаратных средств моделирования в САПР СБИС. // Автоматизация логического проектирования средств вычислительной техники: труды первой международной конференции «САПР СВТ 89» - Л., 1989 г. С. 25-31. 14. Басок Б.М. Об одном методе оценки качества тестов дискретных компонентов вычислительных сетей. // Автоматика и вычислительная техника. 1985 г. 1. С. 56 – 58. 15. Кораблин Ю.П., Куликова Н.Л., Чумакова Е.В. Компонентное тестирование и его реализация. // Учебное пособие. М.: Союз, 2009 г. 23 с. 16. Рабинович Ю.Г. Ускорение статистического метода проверки полноты теста с использованием специализированных средств моделирования.// Труды Всесоюзного семинара «Специализированные процессоры в САПР». Тез.докл. - Москва, 1989. С. 17-18. 17. Thorhuus R. Software Fault Injection Testing. // Master of Science Thesis in Electronic System Design. Stockholm, Sweden: KungligaTekniskaHögskolan, 2000, 58 с.

Page 146: TMPA-2013 Conference Proceedings

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

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

Василий Сартаков and Александр Тарасиков

ksys labs

Аннотация Микроядерные операционные системы имеют долгуюисторию развития, однако на сегодняшний день большинство из нихостаётся экспериментальными исследовательскими проектами. В дан-ной работе представлен опыт использования микроядра L4 Fiasco.OCи окружения Genode для построения сетевой инфраструктуры, при-веден анализ ее производительности, а так же рассмотрены архитек-турные особенности микроядра и программного окружения влияю-щие на пропускную способность сетевой подсистемы.

Page 147: TMPA-2013 Conference Proceedings

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

2

1 Введение

Современное сетевое оборудование обладает большим функционалом, реа-лизация которого уже давно не возможна только на аппаратном уровне. Какследствие, такое оборудование содержит в себе специализированный процес-сор, на котором исполняется операционная система и прикладное программ-ное обеспечение.

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

Микроядерные операционные системы - это такие операционные систе-мы, в которых большая часть функциональности ядра реализована в видеотдельных сервисов. Подобные системы находятся в разработке с 1970-х го-дов; некоторые проекты достигли коммерческого успеха и применяются впромышленности. Однако, особенности архитектуры микроядра могут на-кладывать ограничения на производительность и границы применимоститаких систем [5].

Основные механизмы обеспечения безопасности в микроядерной среде -выполнение всех процесов в депривелигированном (пользовательском) ре-жиме и использование системы межпроцессного взаимодействия вместо пря-мого обращения к памяти другого процесса[6]. Большая часть функциональ-ности, такой как драйвера устройств, файловые системы, управление па-мятью, реализуется в виде независимых процессов, выполняющихся в про-странстве пользователя. Компрометация одной из подсистем ядра не даетатакующему доступ в привелигированный режим, в то время, как в полу-чивших большее распространение монолитных ОС, где все системные ком-поненты выполняются в пространстве ядра (режиме супервизора), такаяугроза есть.

В данной статье представлен опыт создания сетевого оборудования наоснове экспериментального микроядра Fiasco.OC в окружении Genode. Ис-пользуемое микроядро, с одной стороны, обладает высоким потенциаломс точки зрения безопасности, поскольку вынесение критического функци-онала из ядра в пространство пользователя, а так же жесткая изоляциякомпонентов 1 уменьшают количество векторов атак и повышает отказо-устойчивость. С другой стороны, изоляция компонентов ядра приводит кинтенсивному межпроцессному обмену, что может негативно влиять на про-изводительность сетевого оборудования.

Для оценки производительности такого оборудования был разработанпрототип аппаратно-программного комплекса, решающего задачу изоляциисетевый сервисов при помощи паравиртуализации. В качестве гипервизора

1 Под изоляцией подразумевают использование раздельных адресных про-странств и использование принципа наименьших привилегий в выделении ре-сурсов

Page 148: TMPA-2013 Conference Proceedings

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

3

было использовано экспериментальное микроядро Fiasco.OC, виртуальныемашины реализованы на основе паравиртулизированного ядра L4Linux[4].

Результирующие тесты производительности системы показали деграда-цию пропускной способности сети в сравнении с системами построеннымина монолитно-модульном ядре Linux. Для выявления причин деградациибыл разработан набор программного обеспечения для профилирования яд-ра и окружения. Этот набор инструментов позволил выявить компонентыпрограммного окружения, вносящие наибольший вклад в падение произво-дительности сетевой подсистемы, а также отличия в поведении микроядраFiasco.OC на одно- и многопроцессорных системах.

Статья имеет следующую структуру: В первой главе представлена архи-тектура экспериментального аппаратно-программного комплекса, а так жерезультаты нагрузочного тестирования. Во второй главе описана методоло-гия профилирования и ее результаты. В третьей главе представлен анализпрофилирования, а в четвертой главе приведены рассуждения о методах по-вышения производительности. В заключительной, пятой главе, подводятсяитоги работы и формулируются планы на дальнейшую работу.

2 Аппаратано-программный комплекс «Шлюз»

2.1 Функциональное назначение

Гарантированное разделение ресурсов в вычислительных системах - однаиз основных задач информационной безопасности. При этом есть необхо-димость как ограничить доступ к вычислительным ресурсам внутри одноймашины, так и контролировать потоки данных между различными сетевы-ми устройствами.

При проектировании корпоративной локальной сети, необходимо изоли-ровать безопасный сегмент сети (сетевое хранилище и автоматизирован-ные рабочие места работников, обрабатывающих внутрикорпоративные до-кументы) и сетевые устройства, имеющие доступ в интернет или другиепубличные сети. Возникает задача контроля входящих сетевые соединениядля того, чтобы блокировать трафик от недоверенных узлов. Кроме то-го, требуется производить мониторинг сетевого трафика для обнаруженияспециальным образом сформированных сетевых пакетов, направленных наповышение привелегий злоумышленника путем эксплуатации уязвимостейв программном и аппаратном обеспечении.

Зачастую требуется предоставить доступ к части внутрисетевых ресур-сов. Например, внутри безопасной локальной сети пользователям могут бытьдоступен сервис сетевого хранения данных, реализованный в виде сетево-го диска. Если определенные файлы необходимо сделать доступными извнешней сети, может использоваться веб-сервер для выдачи индивидуаль-ных файлов. Помимо возможности проведения дополнительной авториза-ции пользователей средствами веб-интерфейса, такое решение скрывает отпотенциальных злоумышленников физическую топологию внутрикорпора-тивной сети.

Page 149: TMPA-2013 Conference Proceedings

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

4

Ряд приложений требует передачи конфиденциальных данных по неза-щищенному (публичному) каналу. Для организации безопасного обмена дан-ными используются туннели с шифрованием трафика. При этом требу-ется гарантировать, что ключи, использующиеся для шифрования, не бу-дут скомпрометированы. Поэтому необходим механизм разделения вычис-лительных процессов внутри узла сети, реализующего туннель.

Рассмотренные выше задачи решаются использованием сетевого шлюза,то есть, сетевого устройства, имеющего связь с безопасным и небезопаснымсегментами сети, и ограничивающего обмен данными между ними. Схематопологии сети с применением сетевого шлюза приведена на рисунке 1. Да-лее представлена реализация сетевого шлюза с использованием микроядераFiasco.OC.

Рис. 1. Схема сети с использованием шлюза

2.2 Реализация

Рассмотрим одну из возможных реализаций описанного выше сетевого шлю-за. В качестве аппаратной части комплекса используется сервер с двумя се-тевыми интерфейсами, один из которых обеспечивает связь с безопасными,а другой - с небезопасными сегментами сети. Задачи фильтрации и маршру-тизации трафика решаются при помощи виртуальных машин. Для обменаданными между виртуальными машинами может использоваться как вир-туальный сетевой интерфейс, так и криптографический сервис, обеспечива-ющий конфиденциальность передаваемых по незащищенному сегменту сетиданных. Программная часть реализована при помощи микроядра Fiasco.OC,программной среды Genode и паравиртуализованного ядра L4Linux.

Page 150: TMPA-2013 Conference Proceedings

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

5

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

– Открытый исходный код, так как предполагалась доработка системы ипоследующее распространение изменений.

– Поддержка микропроцессорной архитектуры X86 и многопроцессорных(SMP) систем.

– Поддержка современного оборудования, в частности, наиболее распро-странённых моделей сетевых карт.

Этим требованиям удовлетворяют микроядра семейства L4, такие, как OKL4,Fiasco, Fiasco.OC. Было использовано ядро Fiasco.OC, как наиболее активноразвиваемое (новые версии выходят раз в несколько месяцев, в то время какпоследний публичный релиз OKL4 был несколько лет назад) и официальноподдерживаемое окружением Genode.

Рис. 2. Архитектура сетевого шлюза с использованием микроядра

Программная среда Genode - это набор системных сервисов (драйверовустройств и файловых систем) и библиотек, предназначенных для разра-ботки программного обеспечения для микроядерной ОС. Ряд библиотек ре-ализуют программный интерфейс POSIX, позволяя переносить некоторыеприложения из ОС Linux посредством перекомпиляции. Кроме того, Genodeсодержит библиотеку DDEKit[7], позволяющую использовать ряд драйве-ров устройств из других ОС (таких, как Linux и iPXE). Одним из серви-сов, использующих библиотеку DDEkit, является DDE_ipxe, реализующийфункциональность драйвера сетевого интерфейса. Таким образом, драйвер

Page 151: TMPA-2013 Conference Proceedings

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

6

сетевого интерфейса представляет собой программу, выполняющуюся в про-странстве пользователя, тем самым изолированную от других сервисов. Вслучае, если будет обнаружена уязвимость в этом драйвере, позволяющаязлоумышленнику внедрить свой код в сервис, не произойдет компрометациидругих программ, в частности, приложений, выполняющихся в виртуальныхмашинах.

Виртуальные машины реализованы при помощи L4Linux. L4Linux - этоадаптированное ядро Linux для работы в депривилегированном режиме(пространстве пользователя) в качестве сервиса среды Genode. L4Linux поз-воляет использовать программы для ОС Linux без модификации за счетдвоичной совместимости. Помимо сокращения затрат времени на адапта-цию программного обеспечения для работы в микроядерной среде, это поз-воляет использовать программы, которые невозможно адаптировать ввидуотсутствия исходных кодов, например, значительная часть коммерческогопрограммного обеспечения.

2.3 Модель угроз

Основной вектор атаки на сетевые устройства под управлением монолит-ных ОС типа Linux и FreeBSD - это эксплуатация уязвимостей в одном изсервисов, доступных извне (например, HTTP сервер, используемый для кон-фигурации или вывода информации) для повышения привилегий. Ряд атакпозволяет злоумышленнику повысить уровень доступа в пределах одногосервиса, другие направлены на получение полного доступа к ядру ОС (rootexpoits). Большое количество атак для повышения привилегий используетошибки в ПО, связанные с переполнением буфера [3]. Атака с переполнени-ем буфера заключается в возможности перезаписи переменных в программеиз-за ошибок обработки пользовательского ввода. Данный класс уязвимо-стей возможен в связи с тем, что для хранения кода программ и пользова-тельских данных используется одна и та же область памяти. Кроме того,для передачи параметров в системные вызовы зачастую используется разде-ляемый между пространством ядра и пространством пользователя регионпамяти, что позволяет получить доступ к структурам ядра, если в кодеобработки системного вызова отсутствуют или некорректно реализованыпроверки размера передаваемых данных.

В микроядре Fiasco.OC взаимодействие между процессами реализованочерез систему обмена сообщениями. Сообщения передаются через специ-альный регион памяти фиксированного размера (UTCB, Userspace ThreadControl Block). При передаче данных от процесса к процессу данные копи-руются из UTCB первого процесса в UTCB второго, что, с одной сторо-ны, защищает от утечек данных через указатели на структуры ядра, а сдругой, может увеличить время затрачиваемое на системные вызовы. Важ-но заметить, что эта мера поддерживающая целостность данных при осу-ществлении межпроцессных вызовов, тем самым не позволяя злоумышлен-нику, получившему контроль над каким-либо сервисом, атаковать сервисы,

Page 152: TMPA-2013 Conference Proceedings

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

7

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

Одной из угроз вляется атака через устройства, поддерживающих DMA.Технология DMA (Direct Memory Access) позволяет устройству обращатьсяк произвольной области физической памяти. Защища от таких атак не зави-сит от типа ядра и реализуется при помощи IOMMU (Input/Output MemoryManagement Unit) - аппаратного блока виртулизирующего физическую па-мять с которой работает DMA устройство.

Другим типом угроз является атака на драйвер устройства. Выявление ииспользование уязвимости в сетевой подсистеме не дает доступа злоумыш-леннику к структурам ядра поскольку сетевая подсистема исполняется врежиме пользователя и изолированная от других компонентов.

2.4 Анализ производительности

Ключевой характеристикой аппратно-программного комплекса являлась про-изводительность. Как упоминалось ранее, микроядерная архитектура спо-собствует повышению защищенности системы, но, в то же время, можетспособствовать деградации производительности. При анализе производи-тельности мы использовали ОС Linux в качестве эталонной, исполняемойна таком же оборудовании без использования гипервизора.

Для измерения производительности сети были использованы два ком-пьютера - рабочая станция разработчика (далее - PC Host) и сервер, пред-ставляющий собой аппаратную часть разрабатываемого комплекса (далееSRV). Оба компьютера оснащены сетевым контроллером Intel 82579LM спропускной способностью 1Гб/с. Для проведения тестов использовалась про-грамма netperf [1].

Были проведены тесты приема и передачи данных. В первом случае одинэкземпляр программы netperf запускался в режиме сервера внутри средыL4Linux, а другой - в режиме клиента на рабочей станции под управлени-ем Linux (на графике данная конфигурация обозначена как «SRV Host -PC Client»). Во втором случае («PC Host - SRV Client») в L4Linux netperfзапускался в режиме клиента. Для рабочей станции использовался дистри-бутив Fedora Linux 18 с версией ядра Linux 3.8; при запуске на сервере всреде Genode использовалось ядро L4Linux версии 3.5, в качестве корневойфайловой системы также использовался образ дистрибутива Fedora.

Результаты тестирования приведены на графике ниже (Рис. 3). Можновыделить следующие особенности:

– Максимальная пропускная способность сети с использованием системыL4Linux в среде Genode в 1.75 раз ниже, чем без использования пара-виртуализации

– Показатели скорости передачи данных отличаются для входящего и ис-ходящего трафика. Скорость приёма данных почти в 10 раз ниже, чембез использования паравиртуализации.

Page 153: TMPA-2013 Conference Proceedings

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

8

Linux Genode0

200

400

600

800

1,000

704

402

703

89Ско

рост

ьпе

реда

чи(M

bps)

PC Host - SRV ClientSRV Host - PC Client

Рис. 3. Сравнение производительности сетевой подсистемы

3 Профилирование сетевого стека

Высокая деградация производительности полученной системы говорит онедостатках архитектуры. Дальнейшие эксперименты по анализу произво-дительности системы осуществлялись на одном экземпляре L4Linux кото-рый непосредственно обращался к драйверу сетевого адаптера DDE_iPXE.

3.1 Инструментарий профилирования

Программная среда Genode не предоставляет средств для профилированиякода. Была рассмотрена возможность портирования инструментов, исполь-зуемых в других ОС, таких, как gprof или DTrace. Одним из препятствийк портированию данных утилит стало отсутствие в библиотеках, реализу-ющих уровень совместимости со стандартом POSIX, некоторых системныхвызовов, например, profil и mcount, необходимых для реализации инстру-ментирующего профилировщика. Кроме того, сложность представляет ор-ганизация доступа из профилировщика к объектам ядра ОС и аппарат-ным счётчикам производительности без внесения изменений в конфигура-цию сервисов и нарушения принципа изоляции процессов в микроядерномокружении.

Ввиду отсутствия средств измерения производительности, в участки ко-да драйвера сетевого интерфейса были вручную расставлены счетчики ти-ков системного таймера (получаемых инструкцией rdtsc), затрачиваемых навыполнение интересующей нас процедуры. Сообщения выводились в жур-нал, который передавался на компьютер разработчика через последователь-ный порт UART.

При использовании пакетов большего размера было обнаружено, что из-за низкой скорости вывода данных через UART, добавление отладочных

Page 154: TMPA-2013 Conference Proceedings

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

9

сообщений замедляет работу исследуемой программы. Для решения этойзадачи был реализован сервис, сохраняющий отладочный журнал в опера-тивную память. Был использован существующий драйвер ram_fs в средеGenode, который реализует файловую систему в оперативной памяти. Поокончании тестирования журнал копировался с тестового компьютера черезHTTP интерфейс, предоставляемый сервером lighttpd, запущенным в средеGenode.

В приведенной ниже таблице 1 представлено среднее время выполненияфункций сетевого стека (в тиках процессора).

Процедура Количество тиков Файл

dde_kit_sem_up 13 lib/nic.c [dde_ipxe]dde_kit_sem_down 59 lib/nic.c [dde_ipxe]

memcpy 23 lib/nic.c [dde_ipxe]

get_acked 46 nic/component.h [Nic]submit_packet 190-160K nic/component.h [Nic]

packed_descriptor 10 nic/component.h [Nic]

get_packet 8 lib/l4lx/genode_net.cc [L4Linux]acknowledge_packet 254 lib/l4lx/genode_net.cc [L4Linux]

submit_packet 65 lib/l4lx/genode_net.cc [L4Linux]memcpy 25 lib/l4lx/genode_net.cc [L4Linux]Таблица 1. Время выполнения процедур сетевого стека

3.2 Анализ результатов профилирования

Как следует из таблицы 1, наиболее затратная операция - submit_packet,которая помещает пакет в циклический буфер и делает IPC запрос к друго-му процессу. При тестировании программой netperf было обнаружено, чтопри длительной передаче данных время выполнения операции submit_packetспорадически увеличивается на несколько порядков. Было сделано предпо-ложение, что причинами такого поведения могут быть как особенности ре-ализации драйверов устройств, так и алгоритмов управления процессами ипамятью в ядре ОС.

Драйвера устройствОдной из причин несимеетричной производительности сетевой подсисте-

мы при приеме и передаче данных может являться реализация обработкиаппаратных прерываний в микроядре Fiasco.OC. В Genode не реализова-на поддержка прерываний, инициируемых сообщениями (MSI-X) для шиныPCI. Это не позволяет назначить обработчик для прерывания, сигнализи-рующего о наличии входных данных на сетевом интерфейсе, и приходится

Page 155: TMPA-2013 Conference Proceedings

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

10

использовать прерывание от шины PCI, которое может быть разделено сдругими устройствами, что может приводить к увеличению времени обра-ботки входящего трафика. Кроме того, драйвер контроллера прерыванийIO APIC на некоторых системах, оставляет контроллер в состоянии, в кото-ром тот остался на момент загрузки, не реализуя включение/выключениеисточника прерываний, что осложняет отладку программного комплекса.

Управление памятью

В процессе тестирования программа netperf последовательно увеличи-вает размер сетевых пакетов. При длительном тестировании наблюдаетсябольшой разброс времени выполнения операции submit_packet, в связи счем было сделано предположение, что драйвер сетевого интерфейса тратитмного времени в ожидании выделения памяти для очередного пакета. Сцелью проверки этого предположения были увеличены в 8 раз размеры бу-феров для входящих и исходящих данных. Поскольку увеличение размеровбуферов не внесло изменений в поведение системы, необходимо было прове-сти исследование поведения алгоритма выделения памяти. Для управленияпамятью в сетевой подсистеме Genode используется алгоритм SLAB[2], ко-торый содержит несколько списков блоков памяти фиксированного размера(1Кб, 2Кб, 16Кб и т.д.). Память для пакетов с данными организована в видекольцевого буфера, где пакет, освобожденный одним из сервисов (например,драйвером сетевого адаптера DDE_ipxe), попадает в очередь свободных па-кетов другого сервиса (драйвер виртуального сетевого интерфейса L4Linux).При передаче региона памяти в процесс другого сервиса выполняется опера-ция освобождения региона (unmap), и операция выделения памяти в новомпроцессе. При конфигурации микроядра Fiasco.OC для поддержки много-процессорного режима (SMP), реализация многих алгоритмов и структурданных, в том числе примитивов синхронизации (мьютексов), отличаетсяот однопроцессорной версии. Кроме того, при использовании несколькихпроцессоров потоки, выполняющие системные функции (обработку преры-ваний, ввод-вывод) и пользовательские задачи выполняются одновременно.Для определения влияния данных различий на производительность систе-мы, было проведено тестирование в двух режимах: при включении всех ядерпроцессора поддержки SMP в Fiasco.OC (время выполнения теста составило24929000 мкс), и при использовании одного ядра и отключения SMP (146000мкс). При использовании одного ядра процессора, разница между скоростьюприема и передачи данных уменьшается. В многопроцессорном режиме пла-нировщик проводит значительную часть времени (до 30%) в режиме простоя(idle thread) вместо того, чтобы передавать управление потокам приложе-ний. Изучение причин такого поведения планировщика и сравнение с дру-гими микроядрами, поддерживаемыми средой Genode является задачей длядальнейших исследований.

Page 156: TMPA-2013 Conference Proceedings

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

11

4 Предлагаемые решения

Для минимизации задержек при обработке сетевых данных были предло-жены несколько способов доработки сетевой подсистемы:

– Использовать регион разделяемой памяти (Dataspace в терминологииL4/Genode) вместо буферизации в каждом процессе. Но такое решениепротиворечит принципам безопасности микроядерных систем, так какв случае компрометаци драйвера сетевого интерфейса злоумышленникпотенциально получает доступ к памяти всех процессов, использующихсеть.

– Предоставить паравиртуализированным экземплярам L4Linux доступ кфизическому сетевому адаптеру. Для обеспечения доступа к памяти ирегистрам PCI устройств был реализован драйвер виртуальной PCI ши-ны для L4Linux, однако проблема обработки прерываний в ACPI систе-мах не позволяет провести полноценное тестирование решения. Крометого, очевидные минусы - невозможность использования одного сетевогоинтерфейса различными сервисами.

– Минимизировать количество потоков выполнения (threads), занимаю-щихся обработкой данных. Синхронизация доступа к критическим сек-циям может занимать значительную часть времени обработки сетевогопакета, как можно видеть в таблице 1. Некоторые подсистемы средыGenode (в частности, DDE_kit) переделаны для выполнения в однопо-точным режиме. Для задач, производительность которых ограниченаоперациями ввода-вывода, использование многопоточной архитектурызачастую увеличивает латентность.

– Реализовать поддержку прерываний MSI-X и контроллера IO APIC ипровести анализ влияния используемого источника прерываний (от устрой-ства посредством MSI-X и через шину PCI) на время обработки входя-щих данных.

5 Заключение

Был разработан рабочий прототип доверенного сервера, обеспечивающегоизоляцию приложений при помощи паравиртуализации в среде Genode/L4Linux.В ходе тестирования было обнаружено падение производительности сетевойподсистемы, не позволяющее использовать полученное программное реше-ние в качестве непосредственной замены ОС Linux. Детальный анализ про-хождения нагрузочных тестов выявил ряд недостатков в дизайне системы,связанных с драйверами устройств и механизмом выделения памяти в мно-гопроцессорной системе. Дальнейшая работа будет посвящена оптимизациидрайверов и реорганизации многозадачности.

Список литературы

1. Netperf homepage. http://netperf.org.

Page 157: TMPA-2013 Conference Proceedings

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

12

2. Jeff Bonwick et al. The slab allocator: An object-caching kernel memory allocator.In USENIX summer, volume 16. Boston, MA, USA, 1994.

3. Crispin COwan. Buffer overflows: Attacks and defenses for the vulnerability of thedecade. 2000.

4. TU Dresden. L4linux-running linux on top of l4.5. Hermann Haertig et al. The performance of u-kernel-based systems. In ACM

Simposum on Operating Systems Principles, volume 16. Saint-Malo, France, 1997.6. Jochen Liedtke. Toward real microkernels. Communications of the ACM, 39(9):70–

77, 1996.7. Hannes Weisbach. Ddekit approach for linux user space drivers. 2011.

Page 158: TMPA-2013 Conference Proceedings

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

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

хэш-функцийМаксим Журавлев, Виктор Полозов

Кафедра системного программирования,Санкт-Петербургский государственный университет

24 сентября 2013 г.

АннотацияВ данной статье описывается автоматизированный подход к сравне-

нию содержимого баз данных в промышленном проекте по миграцииБД из СУБД MS SQL Server 2005 в Oracle 11gR2. Целевая БД должнасодержать те же данные, что и исходная с точностью до ограничений,налагаемых используемыми СУБД, и быть функционально эквивалент-ной. Размер данных в исходной базе составляет порядка 6 терабайт,размер кода - 2.5 миллиона строк кода в хранимых процедурах. Разра-ботан метод сравнения содержимого БД независимый от порядка про-смотра записей, использующий коммутативные и криптографическиехэш-функции. Показана применимость данного метода для практиче-ского использования.

Ключевые слова - базы данных, миграция данных, тестирование,реинжиниринг, обеспечение качества, хэширование

1. ВведениеПеред коллективом, в котором имеют честь работать авторы, была по-ставлена задача произвести миграцию промышленной БД из Microsoft SQLServer 2005 в Oracle Database 11g Release 2.

Проект условно можно разделить на следующие части: миграцию кодахранимых процедур, представлений (VIEW) и триггеров, миграция данныхи обеспечение качества.

При миграции производилась доработка кода с учётом специфики целе-вой СУБД, новых требований к системе, удалялся мёртвый код, и проводи-лись другие согласованные с заказчиком изменения. При миграции схемыБД проводились такие изменения, как переименование процедур, таблиц иколонок, в основном связанные с ограничением СУБД Oracle в 30 байт наимя, и согласованные изменения в схеме, такие как разбиение по схемам иудаление не используемых объектов.

Миграция данных проводилась без наличия прямого подключения меж-ду базами, через временные файлы с использованием инструментов Microsoft

1

Page 159: TMPA-2013 Conference Proceedings

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

SQL Server BCP и Oracle SQL*Plus. Конвертация данных проводилась в триэтапа: часть данных конвертировалась при выгрузке, часть при загрузке,оставшиеся конвертации проводились как отдельный шаг после загрузки.

В настоящей статье даётся более технически подробное описание ре-ализованного авторами этапа тестирования – верификации корректностимиграции путем сравнения набора хэшей.

2. Связанные работыМетодологии миграции баз данных описаны в нескольких статьях. В статье[7] представлен пример методологии миграции данных. Процесс миграциимежду базами данных с отличающимися моделями данных, сопутствующиериски и проблемы описаны в [9] и [1]. Методологии миграции legacy-системпредставлены в [15].

Проекты миграции баз данных сталкиваются со специфичными рискамии проблемами. Типичные риски и подходы к тестированию и обеспечениюкачества описываются в [11]. Разновидности тестирования, применяемыев течение жизненного цикла проекта миграции, рассматриваются в [12].Общая схема организации обеспечения качества нашего проекта описана встатье [8].

Вопросы хэширования неупорядоченных коллекций (множеств и муль-тимножеств) рассматриваются в [4]. В этой же работе впервые вводит-ся определение устойчивости хэш-функции множества (мультимножества)к коллизиям. Хэширование неупорядоченных коллекций тесно связано синкрементальным хэшированием. Результаты с использованием операцииXOR получены в работах [10] и [3]. Подход к хэшированию таблиц, исполь-зованный в нашем проекте, напоминает MSet-XOR-Hash из статьи [4].

Схожие подходы используются в похожей задаче поддержания конси-стентности реплицированных баз данных. К таким работам относятся: ста-тьи [5], [6] и доклад [2]. В данных статьях не рассматривается сравнениеБД, находящихся под управлением разных СУБД.

3. Требования к методуНа этапе планирования проекта было решено, что совпадение данных висходной и целевой БД должно быть проверено отдельным инструментом.Были сформулированы требования к инструменту:

1. Сравнение БД, находящихся в разных СУБД. Все используемые ме-тоды должны быть реализованы в MS SQL Server 2005 и Oracle 11gR2.

2. Настраиваемая процедура сравнения.

3. Независимость результата сравнения от порядка записей в выборках.Это требование связано с тем, что СУБД не гарантируют порядок вы-дачи результатов для выборки без явной директивы ORDER BY. Отдобавления явной директивы для упорядочивания отказались по двумпричинам: отсутствие первичного ключа или уникального индекса участи таблиц, и существенное увеличение времени работы при упоря-дочивании без использования индекса.

2

Page 160: TMPA-2013 Conference Proceedings

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

4. Эффективность работы. Сюда включается возможность достаточноэффективной реализации и возможность распараллеливания в обеихСУБД. Приемлемым считалось время сравнимое со временем работыпроцедуры перегрузки данных.

От требования определения места расхождения было решено отказаться,т.к. основной сценарий предусматривал использование верификации каксредства доказательства корректности процедуры перекачки данных, а некак средства диагностики.

Обзор как доступных для приобретения, так и бесплатных инструментовне выявил удовлетворяющих всем вышеперечисленным требованиям.

4. Реализация4.1. Контролируемые параметрыВерификация данных выполняется по следующим параметрам:

1. По метаданным контроль наличия всех необходимых объектов ис-ходной БД в целевой БД и нахождения их в корректном статусе (про-цедуры успешно откомпилированы, триггеры установлены).

2. Контроль числа строк в таблицах.

3. Хэши столбцов таблиц и таблиц целиком.

Первый из вышеперечисленных пунктов реализуется анализом кодов за-вершения и других записей в log-файлах, описывающих процесс выгрузки-загрузки. Остальные – сравнением результатов выполнения скриптов под-счета хэшей в исходной и целевой БД.

4.2. Этапы верификации миграции1. Выполнение скриптов расчета хэшей в исходной БД. Хэши сохраня-

ются в новую таблицу исходной БД.

2. Выгрузка таблицы с хэшами в промежуточный файл.

3. Загрузка результатов из промежуточного файла в целевую БД.

4. Выполнение скриптов расчета хэшей в целевой БД. Результаты по-полняют таблицу с хэшами исходной БД.

5. Генерация отчета о расхождениях или полном совпадении набора хэ-шей.

Шаги, относящиеся к целевой БД, выполняются до включения в журнали-рующих триггеров.

3

Page 161: TMPA-2013 Conference Proceedings

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

4.3. Расчет хэшейДля каждой таблицы вычисляются n+2 хэша, где n – количество столбцов.Первый - количество записей в таблице. Несовпадение количества записейпозволяет выявить грубые ошибки перегрузки, но совпадение возможно приискажениях в значениях данных, что является большим недостатком, осо-бенно для таблиц, содержащих типы данных, трансформирующиеся примиграции.

Остальные хэши предназначены для устранения этого недостатка. Онирассчитываются следующим образом: записи таблицы обрабатываются од-на за одной в произвольном порядке – выполняется запрос SELECT COLUMN1,COLUMN2,· · ·, COLUMNN FROM TABLE.

Значение каждого поля преобразуется в массив байтов, например, datetimeпреобразуется в количество миллисекунд с 01.01.1970 00:00:00 (POSIX time)как bigint. Получившееся число интерпретируется как массив байтов. Мас-сивы конкатенируются. Получившийся массив подается на вход хэш-функции.Может быть использована любая, реализация которой доступна в обеихСУБД. Авторами была выбрана MD5 [13]. Возвращенное значение пред-ставляет собой хэш записи. Данная операция может интерпретироватьсякак создание дополнительного столбца в таблице. Набор хэшей таблицы недолжен зависеть от порядка обхода записей, поэтому было принято решениеиспользовать коммутативную операцию XOR (исключающее или) для по-лучения итоговых хэшей из хэшей записей: для каждого столбца, включая“виртуальный” столбец хэшей записей, вычисляется XOR всех элементов.

MD5 – криптографическая хэш-функция, поэтому возвращаемое зна-чение можно рассматривать как равномерно распределенную случайнуювеличину из интервала [0; 2128 − 1]. XOR таких величин не меняет распре-деление, поэтому XOR “виртуального” столбца хэшей записей можно рас-сматривать как равномерно распределенную случайную величину из ин-тервала [0; 2128 − 1]. В исходной БД количество записей в каждой таблицене превышает 1013. Вероятность обнаружения не менее одной коллизии непревышает 10−12 [14]. Четное количество идентичных записей из-за свой-ства XOR(x, x) ≡ 0 может скрыть ошибку в миграции какого-либо типаданных, но отладка метода производилась с использованием таблиц, содер-жащих уникальные записи. Вероятность же нескольких аппаратных сбоев,не попавших в журнал, и, повлиявших только на четное количество иден-тичных записей в одной таблице, оценивается как пренебрежимо малая.

Таблицу БД с первичным ключом можно рассматривать как множе-ство. Изложенный выше метод отличается от MSet-XOR-Hash [4] для хэ-ширования (мульти)множеств отсутствием рандомизации – хэш-функцияфиксирована, а не выбирается из некоторого семейства. Это делает методуязвимым для целенаправленной атаки. Однако во время разработки онпозволил выявить ряд ошибок в процессе перегрузки.

Остальные хэши вычисляются не криптографическими хэш-функциями,но на этапе отладки они облегчали процесс поиска источников ошибок.

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

4

Page 162: TMPA-2013 Conference Proceedings

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

таблице 1.

4.4. Генерация скриптовСкрипты, не зависящие от схемы БД, – командные файлы для утилитзагрузки-выгрузки данных обеих СУБД, SQL-запросы для создания таблицс результатами и генерации отчета, вспомогательные функции для хэширо-вания отдельных типов данных в исходной СУБД, Java-функция хэширо-вания в целевой СУБД, написаны вручную. Скрипты, зависящие от схемы,генерируются разработанной утилитой (язык реализации F#) на основанииактуальной схемы исходной БД (используется экземпляр класса Server) идополнительных параметров, перечисленных в конфигурационном файле.

Скрипт для исходной БД – код на Transact-SQL определяет три вспомо-гательных функции: для конвертации DATETIME в BIGINT, вычисленияхэша BINARY, вычисления хэша VARCHAR, затем для каждой таблицывычисляются хэши по схеме, описанной выше.

Скрипт для целевой БД – код на PL/SQL создаёт для каждой таблицыобъект CURSOR, передаёт его в Java-функцию вычисления хэшей, сохра-няет возвращенный результат в таблицу. Данный подход обусловлен недо-статочной производительностью хэширования, реализованного средствамиPL/SQL. Как сказано выше, в качестве коммутативной операции, обеспе-чивающей независимость итоговых хэшей от порядка просмотра записей,выбрана операция XOR, которую в данной версии PL/SQL можно выра-зить только посредством нескольких вызовов встроенных функций.

Получившийся объем разработанного кода составил 1,5KLOC на F#,0,3KLOC на cmd/shell, 0,4KLOC на Java. Объем сгенерированного кода длямигрируемой БД, содержащей 2410 таблиц, – 144КLOC на PL/SQL (8,4Mb)и 215KLOC на T-SQL (18,3Mb).

4.5. Показания производительностиСравнение БД описанным методом требует значительных вычислительныхресурсов. В отличие от загрузки-выгрузки “узким местом” является не про-изводительность системы ввода-вывода, а скорость вычисления хэшей. За-траты времени на сравнение стали сравнимы с временем перегрузки БД,после того как утилита генерации скриптов была доработана для генерациискриптов, вычисляющих наборы хэшей для нескольких таблиц параллель-но.

Для MS SQL Server 2005 генерируются несколько файлов с кодом наTransact-SQL для обработки набора таблиц сопоставимого суммарного раз-мера. Каждый скрипт передаётся для исполнения экземпляру служебнойутилиты Microsoft ® SQL Server Command Line Tool средствами ОС.

Для Oracle 11gR2 генерируется один файл с кодом на PL/SQL, использу-ющий пользовательские функции реализованные на встроенном языке Javaдля обработки переданного ResultSet. Скрипт передаётся для исполненияслужебной утилите Oracle SQL*Pus. Средствами СУБД Oracle устанавлива-ется количество потоков, обрабатывающих задания из очереди, заполняет-ся очередь заданий. Каждое задание в очереди обрабатывает одну таблицуили часть таблицы, имеющей численный первичный ключ.

5

Page 163: TMPA-2013 Conference Proceedings

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

Тип в исходной БД Тип в целевой БД ПреобразованиеBIT NUMBER(1) 4 байта little-endianTINYINT NUMBER(18) 4 байта little-endianSMALLINT NUMBER(18) 4 байта little-endianINT NUMBER(18) 4 байта little-endianBIGINT NUMBER(19) 8 байтов little-endianFLOAT FLOAT 8 байтов little-endianDECIMAL(n, m),n−m ≤ 18 иm ≤ 18

NUMBER(n, m) по 4 байта целой и дробной частей, рассматрива-емых как INT, little-endian

DECIMAL(n, m),остальные

NUMBER(n, m) результат вычисления хэш-функции(MD5) от зна-чения поля, преобразованного в строку

NUMERIC(n, m) NUMBER(n, m) аналогично DECIMAL(n, m)MONEY NUMBER(19, 4) аналогично DECIMAL(19, 4)DATETIME DATE аналогично BIGINT после конвертации в Unix

timeSMALLDATETIME DATE аналогично BIGINT после конвертации в Unix

timeBINARY BLOB результат вычисления хэш-функции (MD5) от

значения поляIMAGE BLOB результат вычисления хэш-функции (MD5) от

значения поляVARBINARY BLOB результат вычисления хэш-функции (MD5) от

значения поляCHAR(n), n ≤ 4000 VARCHAR2(n) удаляются ведущие и замыкающие пробелы, сим-

волы переноса строки (при загрузке в целе-вую БД происходит нормализация); получившая-ся строка конвертируется в набор байтов с учетомкодовой страницы; вычисляется значение хэш-функции(MD5)

CHAR(n), пустаястрока или NULL

VARCHAR2(n) СУБД Oracle рассматривает пустую строку какNULL; набор байтов совпадающий со значениемхэш-функции при аргументе – пустой строке

NCHAR(n),n ≤ 4000

VARCHAR2(n) аналогично CHAR

SYSNAME VARCHAR2(128) аналогично NCHAR(128)VARCHAR(n),n ≤ 4000

VARCHAR2(n) аналогично CHAR

NVARCHAR(n),n ≤ 4000

VARCHAR2(n) аналогично CHAR

CHAR(n), n > 4000 CLOB аналогично CHARNCHAR(n), n > 4000 CLOB аналогично CHARVARCHAR(n),n > 4000;VARCHAR(MAX)

CLOB аналогично CHAR

NVARCHAR(n),n > 4000;NVARCHAR(MAX)

CLOB аналогично CHAR

TEXT; NTEXT CLOB аналогично CHAR

Таблица 1: Преобразование полей записей в набор байтов6

Page 164: TMPA-2013 Conference Proceedings

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

При выборе подхода к реализации были рассмотрены различные подхо-ды к реализации и проведено сравнение их производительности:

• Код на Transact-SQL в целом удовлетворял требованиям по произво-дительности.

• Реализация хэширования на PL/SQL, – через проход циклом по курсо-ру, с подсчётом хэшей, и их объединение через операцию XOR, реали-зованную через встроенную функцию BitAND, – проигрывал в произ-водительности TSQL-коду в 5-10 раз. Поэтому было принято решениео его оптимизации.

• Реализация на языке Java, встроенном в Oracle, на разных таблицахпоказала или сходный результат с PL/SQL-реализацией, или улучше-ние производительности.Дополнительным аргументом, в пользу реализации на Java, так жеможно назвать относительною простоту реализации, что позволилобыстрее получить как первые, так и окончательные результаты.

• Реализация на языке Java, запущенная в несколько потоков, показалапочти линейный рост производительности до достижения насыщения.

На следующем графике представлены сравнение времени работы раз-личных реализаций хэширования для одной из основных таблиц. В умень-шенной для целей тестирования базе в этой таблице 4 миллиона записейобщим объемом порядка 2.5 гигабайт. Тестирование производилось на сер-вере с 8-ядерным процессором.

294SQLServer

22311 потокPL/SQL15101 потокJava

10472 потокаJava6154 потокаJava

3958Java39616Java

0 300 600 900 1200 1500 1800 2100График 1: влияние реализации на время расчета (сек.)

По результатам тестирования для Oracle было принято решение в пользуJava-реализации с запуском несколько потоков.

Итоговые составляющие времени перегрузки тестовой базы, содержащей21Гб в 1.5К не пустых таблицах даны в таблице 2.

Таким образом, время хэширования сопоставимо со временем перегруз-ки, что позволяет утверждать, что поставленные требования были удовле-творены.

5. РезультатыОписанным методом сравнивались исходная и целевая БД при каждом ноч-ном тестировании очередной сборки, что позволило выявить и исправить

7

Page 165: TMPA-2013 Conference Proceedings

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

Этап Время (сек.)Выгрузка из MSSQL 1109Хэширование в MSSQL 799Загрузка в Oracle 2134Хэширование в Oracle 2279

Таблица 2: Время этапа миграции тестового набора данных

ошибки в процедуре перегрузки и процедуре вычисления хэшей.Для доказательства эквивалентности изменений, совершаемых в исход-

ной и целевой БД, при воспроизведении трасс типичных действий пользова-теля были сгенерированы журналирующие триггеры, вычисляющие хэшиперехваченных наборов записей по описанной выше схеме.

6. ЗаключениеПримененный метод сравнения содержимого баз данных путем подсчёта ис-пользующий коммутативные и криптографические хэш-функции позволилуспешно решить поставленную перед авторами задачу: было реализованоавтоматизированное тестирование корректности миграции данных междуразличными СУБД путем сравнения набора хэшей, что позволило устра-нить ряд методических ошибок перегрузки. Разработанный метод возможнопереиспользовать, при необходимости пополнив поддержкой типов данных,не встретившихся в схеме исходной БД, и поддержкой СУБД, отличных отMS SQL Server 2005 и Oracle 11gR2.

Список литературы[1] Maatuk A. Migrating Relational Databases into Object-Based and XML

Databases. Northumbria University, 2009.

[2] Ulrich Arndt. How to compare tables between td systems in a dual activeenvironment. In The 2012 Teradata PARTNERS Conference, 2012.

[3] Mihir Bellare, Oded Goldreich, and Shafi Goldwasser. Incrementalcryptography: The case of hashing and signing. In In CRYPTO, 1994.

[4] Dwaine Clarke, Srinivas Devadas, Marten van Dijk, Blaise Gassend, andG. Edward Suh. Incremental multiset hash functions and their applicationto memory integrity checking. In In Advances in Cryptology - Asiacrypt2003 Proceedings, volume 2894 of LNCS, pages 188–207. Springer-Verlag,2003.

[5] Fabien Coelho. Remote comparison of database tables technical reporta/375/cri, 2006.

[6] Fabien Coelho. Remote comparison of database tables. In DBKDA 2011 :The Third International Conference on Advances in Databases, Knowledge,and Data Applications, 2011.

8

Page 166: TMPA-2013 Conference Proceedings

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

[7] Hudicka J. The Complete Data Migration Methodology. Dulcian Inc., 2000.

[8] I. Kirilenko and E. Baranov. Automation of QA in the project ofDB migration from SQL Server into Oracle. In Proceedings of the 6thSpring/Summer Young Researchers’ Colloquium on Software Engineering(SYRCoSE 2012), pages 178–181. Perm, Russia, May 30-31, 2012.

[9] Chang-Yang Lin. Migrating to relational systems: Problems, methods, andstrategies. 4(4):369–380, 2008.

[10] R. Guerin M. Bellare and P. Rogaway. Xor macs: New methods for messageauthentication using finite pseudorandom functions. In In CRYPTO, 1994.

[11] Haller K. Matthes F., Schulz C. Testing & quality assurance in datamigration projects. In 2011 27th IEEE International Conference, 2011.

[12] Augustinez J. Redlichx A. Lodha S. Vin H. Deshpande A. Gharote M.Mehrotrak A. Patil S., Royy S. Minimizing testing overheads in databasemigration lifecycle. In The 16th International Conference on Managementof Data (COMAD), 2010.

[13] Ronald L. Rivest. The md5 message-digest algorithm. Internet RFC 1321,April 1992.

[14] Bruce Schneier. Applied Cryptography, Second Edition. John Wiley & Sons,1996.

[15] Bisbal J. Grimson J. Wade V. O’Sullivan D. Richardson R. Wu B.,Lawless D. Legacy system migration : A legacy data migration engine.In Proccedings of the 17th International Database Conference, pages 129–138. Springer-Verlag, 1997.

9

Page 167: TMPA-2013 Conference Proceedings

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

Page 168: TMPA-2013 Conference Proceedings

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

Page 169: TMPA-2013 Conference Proceedings

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

Page 170: TMPA-2013 Conference Proceedings

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

𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶 𝑆𝑆𝐶𝐶𝑆𝑆𝑆𝑆𝐶𝐶𝑆𝑆𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶

Page 171: TMPA-2013 Conference Proceedings

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

Page 172: TMPA-2013 Conference Proceedings

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

Page 173: TMPA-2013 Conference Proceedings

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

Page 174: TMPA-2013 Conference Proceedings

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

Page 175: TMPA-2013 Conference Proceedings

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

𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶

𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶 𝐶𝐶𝐶𝐶𝐶𝐶𝐸𝐸𝐶𝐶

Page 176: TMPA-2013 Conference Proceedings

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

Page 177: TMPA-2013 Conference Proceedings

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

Page 178: TMPA-2013 Conference Proceedings

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

Page 179: TMPA-2013 Conference Proceedings

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

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

Сенов А.А.

Костромской государственный технологический университет г. Кострома, ул. Дзержинского, 17

[email protected]

Аннотация. Современные трейдинговые платформы представляют собой сложные распределённые системы, обслуживающие большое число пользователей по различным протоколам передачи данных. При нагрузочном тестировании таких систем возникает существенный объём информации, которая может быть проанализирована QA-специалистами с целью обнаружения дефектов. Для этого часто требуется выявлять зависимости между значениями показателей, полученными в ходе тестирования, путём проведения многофакторного анализа, что при большом объёме данных является трудоёмкой задачей, требующей специализированного ПО, в частности, систем интерактивной аналитической обработки OLAP. В данной статье описывается оригинальный алгоритм многомерного анализа результатов нагрузочного тестирования на стороне клиента. С помощью технологии MapReduce предложенный алгоритм оптимизирован для работы под управлением многоядерных процессоров. Ключевые слова: OLAP, MapReduce, нагрузочное тестирование, анализ данных

1 Введение

Анализ результатов нагрузочного тестирования трейдинговых платформ в большинстве случаев связан с обработкой существенных объёмов информации. Это обусловлено тем, что современные платформы являются сложными распределёнными системами, обрабатывающими свыше 40 тысяч заявок в секунду при среднем времени отклика менее 300 микросекунд. С другой стороны, аппаратная инфраструктура тестовых инструментов по производительности на несколько порядков уступает биржевой. Это неизбежно влечёт необходимость разрабатывать инструменты как можно более простые, не перегруженные функциональностью, для достижения высокой эффективности при решении основных задач[1]. В связи с этим при анализе данных, полученных в ходе нагрузочного тестирования, чтобы быстро ответить на

Page 180: TMPA-2013 Conference Proceedings

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

поставленные вопросы, возникает потребность в использовании специализированного ПО, к какому можно отнести большой класс продуктов бизнес-аналитики BI (англ. Business Intelligence). Среди программных решений BI-класса можно выделить системы интерактивной аналитической обработки OLAP (англ. Online Analytical Processing), предназначенные для построения обобщённой информации на основе данных, имеющих многомерное представление. При нагрузочном тестировании такие системы помогают QA-аналитикам (англ. Quality Assurance) качественно осуществить многофакторный анализ зависимостей между значениями показателей, полученными в ходе тестирования, с целью обнаружения дефектов платформы.

2 Существующие Решения

В основе любой OLAP-системы лежит многомерная модель данных, называемая многомерным кубом, гиперкубом или просто кубом. По месту нахождения машины, рассчитывающей многомерные кубы, современные OLAP-системы можно разделить на две группы: клиентские и серверные. В случае клиентской системы сервер отправляет клиенту исходные данные, клиент производит расчет многомерных кубов и выдает результат пользователю. В случае серверной системы сервер рассчитывает многомерные кубы и отправляет результат клиенту, клиент выдает результат пользователю[2].

На сегодняшний день обе группы представлены на рынке широким спектром продуктов. Для серверных систем это, например, такие решения, как Microsoft SQL Server Analysis Services[3], OLAP Option to Oracle Database[4] или Palo[5]. Серверные решения являются наиболее быстрыми, надежными и имеют ряд других преимуществ: например, техническую поддержку от производителей. Как следствие, такие системы являются дорогостоящими. Можно принять во внимание наличие open-source версии Palo, но она имеет существенные ограничения по сравнению с коммерческой: например, отсутствие возможности использования более чем одного ядра процессора[6].

Среди клиентских решений популярными остаются электронные таблицы MS Office Excel, позволяющие выполнять многомерный анализ с помощью механизма Pivot table[7]. Pivot table удобно использовать, когда исходные данные изначально заносятся в электронную таблицу, что при серьёзных задачах, таких как нагрузочное тестирование, исключено. Поэтому пользователь обязательно сталкивается со сложностью конфигурации подключения к внешним источникам данных.

Факт наличия на рынке разнообразных продуктов, обладающих своими достоинствами и недостатками, говорит о том, что для OLAP, как и для многих сложных задач, до сих пор нет единого решения, одинаково подходящего для всех. В рамках статьи предлагается рассмотреть оригинальный алгоритм многомерного анализа результатов нагрузочного тестирования на стороне клиента. Решение главным образом направлено на сокращение затрат на тестовые и аналитические инструменты.

Page 181: TMPA-2013 Conference Proceedings

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

3 Предлагаемое Решение

В случае тестирования биржевых платформ существует несколько основных источников, из которых можно получить информацию для анализа: 1. Данные, которыми оперируют непосредственно тестовые инструменты; 2. Статистическая информация из внутренней базы данных платформы, а

также записи журналов активности её компонентов и пользователей; 3. Независимые данные, полученные напрямую от сетевых устройств, через

которые происходит общение клиентов с платформой. Опыт показывает, что наиболее достоверным является источник под номером

3, но для полноты картины поведения тестируемой системы данные обычно собираются изо всех трёх источников и складываются в общую базу. Данные, как правило, представляют собой разнообразные сведения о типах сообщений, значениях полей сообщений, клиентах, разного рода настройках и, конечно, временных отметках. Опираясь на весь этот массив информации, аналитики оценивают такие параметры, как время отклика, количество сообщений, пропускную способность, используемую память, загрузку процессоров и прочее[8].

При создании алгоритма основным принципом служила простота, и вся его суть сводится к выполнению операций над generic-контейнерами в оперативной памяти клиентской машины. Перенос вычислений на сторону клиента обусловлен высокой производительностью современных настольных ПК, сочетающейся с их низкой стоимостью. Так, например, в настоящее время конфигурация среднего рабочего места это: процессор с 2-4 ядрами и 4-8 ГБ оперативной памяти. Такие характеристики в сочетании с гигабитными сетями, использующимися уже повсеместно, позволяют решить задачу многомерного анализа без привлечения дополнительных ресурсов.

Алгоритм написан на языке C++ с применением Qt Framework, что даёт такие преимущества, как высокое быстродействие, кроссплатформенность, а также возможность использования настольной реализации технологии MapReduce[9] с целью получения масштабируемого решения для работы под управлением многоядерных процессоров.

Как было сказано выше, в основе любой OLAP-системы лежит гиперкуб. И первая проблема, которую необходимо решить, – это представление гиперкуба с точки зрения кода. Для этого сначала необходимо определиться, как информация будет попадать из базы данных в гиперкуб. Ответ очевиден – нужно выполнить SQL-запрос SELECT. Запросы предлагается писать по правилам, которые отражены в листинге 1.

Page 182: TMPA-2013 Conference Proceedings

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

Листинг 1. Общий вид SQL-запроса выборки данных; где dimension0 … dimensionN – значения измерений гиперкуба, measure – мера, значение ячейки гиперкуба, образуемое

при уникальном сочетании значений измерений.

select dimension0, dimension1, dimension2, …, dimensionN, measure from … inner join … on … … where <condition> … Проще говоря, запросы должны возвращать кортежи, состоящие из

различных сочетаний измерений и соответствующие этим сочетаниям числовые значения анализируемой величины. Таким образом, правила помогают подготовить данные и передать их клиенту уже в структурированном виде.

Атрибуты кортежей, описывающие значения измерений, могут иметь самые разнообразные типы, а последний атрибут measure в общем случае, является числом с плавающей точкой. Так как на этом этапе задача состоит не только в создании универсального способа хранения данных в ОЗУ, но и обеспечении возможности построения простых и составных ключей по значениям измерений на осях гиперкуба, которые будут необходимы для упорядочивания и поиска информации, все измерения следует привести к одному типу ещё до размещения в ОЗУ. В качестве такого типа подходят строки. Это объясняется тем, что большинство измерений изначально имеют строковые значения: названия протоколов, сообщений, финансовых инструментов, имена пользователей и т.п., а все другие типы при необходимости всегда можно привести к строковому, используя SQL-функцию cast. Что касается дат, то при переводе их в строковый тип они приобретают ISO-формат YYYY-MM-DD, и упорядочивание таких строк напрямую соответствует упорядочиванию дат.

Таким образом, кортежи запроса можно описать следующим классом:

Листинг 2. Представление кортежей запроса, где поле класса _keys содержит атрибуты, представляющие значения измерений, приведённые к строковому типу; поле _measure –

последний атрибут кортежа, представляющий ячейку гиперкуба. class Tuple public: Tuple(const QStringList & keys, double measure); const QStringList & keys() const; void setKeys(const QStringList & keys); double measure() const; void setMeasure(double measure); private: QStringList _keys; double _measure; ;

Page 183: TMPA-2013 Conference Proceedings

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

Собственно гиперкуб является generic-контейнером QList, содержащим множество экземпляров класса Tuple, описанного в листинге 2, и представляет собой мгновенный снимок данных.

Следующая проблема – выбор осей гиперкуба для формирования отчёта и передача этой информации коду, который будет его формировать. Для пользователя естественным представлением осей гиперкуба являются два списка их названий: один для строк отчёта, второй – для столбцов, допускающие множественный выбор и перемещение элементов списка относительно друг друга. С точки зрения кода, названия измерений использовать неудобно, т.к. значения измерений хранятся в QStringList, который позволяет обращаться к элементам по индексам. Когда пользователь меняет измерения местами с целью получения в отчёте необходимой детализации и агрегации, их порядок уже не будет соответствовать тому, который был задан при написании запроса, поэтому для соответствия названий измерений их порядковым индексам предлагается использовать словарь QMap<QString, int>, в котором в качестве ключей хранятся названия измерений, в качестве значений – их порядковые индексы.

Отчёт, который строится алгоритмом, представлен в виде вектора векторов. Для удобства вектор инкапсулирован в класс Projection, который показан в листинге 3.

Листинг 3. Представление отчёта, где поле класса _data является вектором векторов: двумерным массивом, содержащим ячейки отчета.

class Projection public: Projection(int width = 0, int height = 0); Projection(const QSize & size); void resize(int width, int height); void resize(const QSize & size); void clear(); int width(); int height(); QVector<Cell> & operator[](int i); private: QVector< QVector<Cell> > _data; ;

Page 184: TMPA-2013 Conference Proceedings

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

Листинг 4. Представление ячейки отчёта, где поле _value аккумулирует значения, прибавляемые к ячейке; _min, _max содержат минимальное и максимальное значения

ячейки соответственно; _count считает количество слагаемых для расчёта среднего значения ячейки.

class Cell public: Cell(); Cell(int x, int y, double value); double value() const; void setValue(double value); int x() const; void setX(int x); int y() const; void setY(int y); double max() const; double min() const; double avg() const; Cell operator+=(double value); const Cell operator+(const Cell & other); bool isEmpty(); void clear(); private: int _x; int _y; double _value; double _max; double _min; int _count; ; В листинге 4 можно увидеть, что алгоритм даёт возможность выбора величин

отчёта, которые будут показаны пользователю в конечном счёте: сумма, минимум, максимум, среднее. Формирование самого отчёта выполняется в три этапа: 1. Сканирование гиперкуба (generic-контейнера QList) с целью формирования

словарей с полными уникальными ключами (заголовки колонок и строк отчёта);

2. Сканирование полученных словарей с целью задания монотонно возрастающих целочисленных значений с шагом 1 (номера колонок и строк отчёта по порядку);

3. Сканирование гиперкуба с целью восстановления полученных ранее ключей и получения по ним координат ячеек отчёта из сформированных словарей, заполнение отчёта;

В первых реализациях все три пункта выполнялись в одном потоке, что при наличии многоядерных процессоров являлось само по себе не эффективным. Поэтому, с целью оптимизации быстродействия алгоритма, было решено

Page 185: TMPA-2013 Conference Proceedings

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

провести распараллеливание с помощью технологии MapReduce. Предварительный анализ затрат времени показал, что на пункты 1 и 3 алгоритма приходится свыше 95% общих затрат времени, поэтому пункт 2 распараллеливать нецелесообразно.

Рис. 1. Диаграмма деятельности. Пункты 1 и 3, предложенные к распараллеливанию, не являются потоково-

безопасными – в них осуществляется модификация глобальных объектов: словари с полными ключами и ячейки отчёта. Но одним из плюсов MapReduce является возможность абстрагирования от использования низкоуровневых примитивов синхронизации, поэтому приведенные ниже фрагменты кода не содержат ни мьютексов, ни семафоров, ни блокировок на чтение-запись.

Так, пункт 1 реализован следующим образом:

Листинг 5. Функции Map и Reduce для формирования словарей с полными ключами. QMap<QString, int> _dimensions; QMap<QString, int> _xCoordinates, _yCoordinates; QStringList _xDimensions, _yDimensions; QPair<QString, QString> mapFullKeys(const Tuple & tuple) QPair<QString, QString> keys;

Page 186: TMPA-2013 Conference Proceedings

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

QString key; int i = 0; foreach (const QString & dimension, _xDimensions) i = _dimensions[dimension]; key += tuple.keys()[i]; keys.first = key; key.clear(); foreach (const QString & dimension, _yDimensions) i = _dimensions[dimension]; key += tuple.keys()[i]; keys.second = key; return keys; void reduceFullKeys(int & /*i*/, const QPair<QString,

QString> & keys) _xCoordinates[keys.first] = -1; _yCoordinates[keys.second] = -1; Функция mapFullKeys в листинге 5 вызывается для каждого элемента

гиперкуба параллельно. Имена выбранных для отчёта измерений представлены в виде двух списков: _xDimensions, _yDimensions. С помощью словаря _dimensions восстанавливаются индексы измерений и уже по индексам извлекаются их значения. В случае если на строки отчёта отображаются несколько измерений гиперкуба, то ключ будет представлять собой конкатенацию значений измерений. То же самое справедливо и для столбцов. В итоге функция возвращает пару ключей, которая автоматически передается функции reduceFullKeys, которая, в свою очередь, помещает ключи в формируемые словари _xCoordinates и _yCoordinates. В итоге словари будут состоять из уникальных ключей, автоматически отсортированных в порядке возрастания.

На втором шаге оба словаря перебираются по порядку и ключам присваиваются возрастающие значения: 0, 1, 2, 3 и т.д. Таким образом, словари в качестве ключей содержат заголовки столбцов и строк будущего отчёта, а в качестве значений – их порядковые индексы.

Реализация третьего шага отображена ниже:

Листинг 6. Функции Map и Reduce для заполнения отчёта. QMap<QString, int> _dimensions; QMap<QString, int> _xCoordinates, _yCoordinates; QStringList _xDimensions, _yDimensions; Projection _projection; Cell mapProjection(const Tuple & tuple)

Page 187: TMPA-2013 Conference Proceedings

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

QString key; foreach (const QString & dimension, _xDimensions) int i = _dimensions[dimension]; key += tuple.keys()[i]; int x = _xCoordinates[key]; key.clear(); foreach (const QString & dimension, _yDimensions) int i = _dimensions[dimension]; key += tuple.keys()[i]; int y = _yCoordinates[key]; return Cell(x, y, tuple.measure()); void reduceProjection(int & /*i*/, const Cell & cell) _projection[cell.x()][cell.y()] += cell.value(); Функция mapProjection в листинге 6 строит уникальные ключи по той же

схеме, что и mapFullKeys в листинге 5. По ключам из сформированных ранее словарей _xCoordinates и _yCoordinates извлекаются координаты ячеек отчёта, а из текущего кортежа гиперкуба извлекается величина _measure. Все три значения передаются в функцию reduceProjection в виде экземпляра класса Cell. В свою очередь, reduceProjection по указанным координатам получает ячейку отчёта и к её значению прибавляет величину _measure.

После распараллеливания алгоритма была проведена экспериментальная оценка затрат времени на построение отчета по различным сочетаниям измерений гиперкуба. Для того чтобы наглядно убедиться в эффективности MapReduce, описанная выше реализация сравнивается с тестовой реализацией, выполненной по технологии PTHREAD[10] с использованием примитивов синхронизации.

Априори известно, что затраты времени зависят от ряда как контролируемых, так и неконтролируемых факторов, таких как: 1. объём выборки из базы данных, т. е. размер гиперкуба; 2. количество и длины полных ключей измерений гиперкуба, выбранных для построения отчёта; 3. количество параллельных потоков; 4. тип процессора: архитектура, количество ядер, частота, объём кэш; 5. объём и частота основной памяти; 6. тип, разрядность и версия операционной системы, частота системного таймера; 7. версия Qt Framework.

Из перечисленных факторов, факторы с 4 по 7 являются неконтролируемыми и, более того, все они быстро меняются с течением времени, поэтому их влияние можно оценить только качественно.

Page 188: TMPA-2013 Conference Proceedings

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

Первый фактор, пока объём выборки не превышает объем доступной оперативной памяти, соответствует линейной зависимости затрат времени от размера выборки; при этом соотношение затрат времени для различных вариантов реализации параллельного кода должно оставаться постоянным, поэтому в эксперименте рассматривается достаточно малый объём данных: тестовый гиперкуб имеет 9 измерений и состоит из 66 354 кортежей.

Для оценки количества и размеров составных ключей предлагается использовать обобщённый параметр K, для определения которого используется следующее соотношение, основанное на том, что среднее время поиска в дереве пропорционально его глубине, а среднее время сравнения двух строк пропорционально их длине[11]:

K= log2(N)*L . (1)

где: K– обобщённый параметр; N– количество ключей; L– средняя длина

ключа. Так как отчёт является двумерным массивом, то результирующий показатель

будет равен сумме показателей для колонок и строк:

K = Kx + Ky = log2(X)*Lx + log2(Y)*Ly . (2)

где: K – результирующий параметр; Kx,y – обобщённые параметры для колонок и строк; X, Y – количество ключей; Lx,y – средние длины ключей.

Для проведения экспериментов использовался компьютер с 6-ядерным процессором AMD Phenom II X6 1100T и 4 Гб ОЗУ; операционная система Linux KUbuntu 12.04 LTS 64-bit с версией ядра 3.2; Qt Framework версии 4.8.4. Данные снимались в 10-кратной повторности. Для определения затрат времени на формирование словарей с ключами и заполнение отчёта использовался системный вызов clock_gettime.

На рисунке 2 представлены общие затраты времени для сравниваемых технологий: однопоточного варианта, многопоточного варианта на MapReduce и многопоточных вариантов на PTHREAD - в зависимости от значений предлагаемого обобщенного параметра K.

Page 189: TMPA-2013 Conference Proceedings

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

Рис. 2. Затраты времени на формирование ключей и заполнение отчета в зависимости от обобщенного параметра для 6-ядерного процессора AMD Phenom II X6 1100T, частота

ядер 3.3 ГГц, кэш 6144 Кб, 64-разрядная ОС Linux 3.2, Qt 4.8.4. Из графиков видно, что гипотеза о линейной зависимости затрат времени от

обобщённого параметра K подтвердилась. Общие затраты времени для варианта с 6 потоками PTHREAD и для варианта с использованием MapReduce очень близки между собой. Однако с увеличением значения обобщенного параметра, MapReduce демонстрирует лучшую эффективность. Поскольку для конечного пользователя, QA-специалиста, важны общие затраты времени, а для разработчиков - кроссплатформенность и масштабируемость, MapReduce является верным выбором при оптимизации задачи многофакторного анализа на стороне клиента.

4 Заключение

Описанная методика анализа данных, обладая высокой эффективностью, кроссплатформенностью и масштабируемостью, является подходящей альтернативой существующим решениям при обработке результатов нагрузочного тестирования трейдинговых платформ. Алгоритм прост в использовании, т.к. его конфигурация заключается лишь в написании стандартного SQL-запроса выборки SELECT, придерживаясь указанных правил; а применение технологии MapReduce позволяет использовать доступную мощь многоядерных процессоров, которые в настоящее время устанавливаются на абсолютное большинство компьютеров. Данное решение апробируется в ряде проектов по нагрузочному тестированию компании «Exactpro Systems», LLC.

Page 190: TMPA-2013 Conference Proceedings

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

Литература

1. Иткин И.Л.: Тестирование биржевых систем в условиях высокочастотного трейдинга // SQA Days #10: [Электронный ресурс]. Режим доступа: http://sqadays.com/talk.sdf/sqadays/11151/talks/12196

2. Каширин И.Ю., Семченков С.Ю.: Интерактивная аналитическая обработка данных в современных OLAP-системах // Бизнес-информатика. 2009. Вып. 2(8).

3. SQL Server Analysis Services - Multidimensional Data // MSDN: [Электронный ресурс]. Режим доступа: http://msdn.microsoft.com/en-us/library/bb522607(v=sql.105).aspx

4. Oracle OLAP // Oracle: [Электронный ресурс]. Режим доступа: http://www.oracle.com/technetwork/database/options/olap/index.html

5. Palo by Jedox // Palo: [Электронный ресурс]. Режим доступа: http://palo.net/ 6. Comparison - Palo (Open Source) / Jedox (Premium) // Palo: [Электронный ресурс].

Режим доступа: http://www.palo.net/index.php?id=13 7. Jelen Bill, Alexander Mike. Pivot table data crunching. Pearson Education: 2011. 8. Alexey Zverev: Technical Testing // EXTENT February 2011: [Электронный ресурс].

Режим доступа: http://www.slideshare.net/IosifItkin/technical-testing-introduction 9. Qt 4.8: Concurrent Programming // Qt Reference Documentation: [Электронный ресурс].

Режим доступа: http://doc-snapshot.qt-project.org/4.8/threads-qtconcurrent.html 10. Blaise Barney: POSIX Threads Programming // Lawrence Livermore National Laboratory:

[Электронный ресурс]. Режим доступа: https://computing.llnl.gov/tutorials/pthreads/ 11. Кнут Д. Э.: Искусство программирования, том 3. Сортировка и поиск, 2-е издание. –

М.: Издательский дом «Вильямс», 2003.

Page 191: TMPA-2013 Conference Proceedings

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

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

трейдинговых систем

Aнастасия Матвеева1, Николай Антонов2, Иосиф Иткин3

1 ООО «Инновационные Трейдинговые Системы», Россия, 156013, г. Кострома, ул. Ленина, 20, [email protected]

2 Костромской государственный технологический университет, г. Кострома, ул. Дзержинского, 17, [email protected]

3 Exactpro Systems LLC, 4040 Civic Center Drive, Suite 200, San Rafael, CA 94903, USA [email protected]

Aннотация. В статье рассматриваются основные требования к инструментам, разработанным для верификации корректной работы электронных трейдинговых систем с использованием методов большого объема автоматизированного тестирования (НiVAT); анализируется применимость подобных инструментов при промышленной эксплуатации трейдинговых систем. Ключевые слова: автоматизация тестирования, трейдинговые системы, HiVAT.

1 Введение Ускоренное развитие технологий, используемых в электронных

трейдинговых системах, признается одним из наиболее существенных факторов, влияющих на изменения в структуре и стабильности функционирования международных финансовых рынков [1]. Решения, обеспечивающие качество программных и архитектурных компонентов, становятся все более востребованными участниками рынка и организациями, регулирующими финансовый сектор [2; 3].

С технологической точки зрения трейдинговые системы в большинстве случаев являются сложными адаптивными распределенными программно-аппаратными комплексами, осуществляющими параллельное выполнение большого количества транзакций в режиме реального времени [4]. Современные системы обеспечивают время отклика, измеряемое долями миллисекунды, и при своей работе генерируют значительные объемы данных [5].

В связи с возрастающей долей финансовых транзакций, осуществляемых посредством автоматизированных компьютерных систем [6], основные взаимодействия в трейдинговых системах базируются на различных открытых и закрытых сетевых протоколах и программных интерфейсах доступа [7]. Специфика автоматизированных рабочих мест пользователя трейдинговой системы состоит, в частности, в высокой частоте обновления данных о

Page 192: TMPA-2013 Conference Proceedings

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

котировках, статусе выполнения финансовых транзакций, текущих позициях и рисках [8].

Рассмотрим несколько ключевых аспектов обеспечения качества трейдинговых систем: Как и другие сложные многопоточные системы, трейдинговые платформы предрасположены к появлению в них трудновоспроизводимых сбоев [9], которые проявляются, исключительно когда система находится под нагрузкой. Часто речь идет о функциональных проблемах, не связанных с исчерпанием ресурсов системы, но вызванных ситуацией конфликтующих друг с другом по времени условий (race conditions) при обработке параллельных транзакций или проявлением статистически маловероятных внутренних нарушений целостности [10]. Нахождение таких проблем требует проведения верификации на границе между функциональным и нагрузочным тестированием [11]; Обеспечение полноты покрытия тестами функциональности трейдинговой системы требует большого количества сценариев в библиотеке автоматизированных тестов [12]. Количество нуждающихся в проверке комбинаций особенно велико для производных и составных финансовых инструментов [13]. Даже однократный прогон сценариев такой библиотеки тестов через систему приводит к продолжительному исполнению последовательности автоматических тестов. Многократный запуск позволяет выделить скрытые проблемы с внутренними состояниями системы; Регулирующие органы, акционеры и участники торгов ожидают высокой устойчивости биржевых и брокерских систем к непредусмотренным внешним воздействиям [3]. В научной литературе детально проработаны методы тестирования устойчивости, основанные на прогоне большого количества случайно созданных данных через систему — фаззинге (fuzzing) [14].

Описанные выше свойства приводят к необходимости отправки большого количества созданных для тестирования сообщений в систему в течение продолжительного периода времени. Для обнаружения дефектов, связанных с обработкой потоков сообщений, необходима доскональная функциональная верификация выходящих сообщений и внутренних состояний системы.

Применимые для этого методы известны под аббревиатурой HiVAT – большие объемы автоматизированного тестирования (High Volume Automated Testing) [15; 16; 17]. Эти методы направлены на выявление проблем, которые с большой долей вероятности могут остаться незамеченными при использовании других подходов, требующих ручного создания сценариев для автоматического тестирования и приводящих к статистически недостаточному количеству выходных данных.

Опыт авторов показывает, что для высоконагруженных трейдинговых систем использование HiVAT-методов служит не столько возможным способом расширения покрытия тестированием, сколько обязательным методом их тестирования в условиях, приближенных к использованию в режиме промышленной эксплуатации.

Продолжительное применение HiVAT-методов позволило выявить основные требования к инструментам тестирования. Эти требования перечисляются во второй части данной статьи. Третья часть посвящена сравнению инструментов тестирования с трейдинговыми системами, используемыми в промышленной

Page 193: TMPA-2013 Conference Proceedings

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

эксплуатации. В последней части приведены возможные расширения созданных средств и направления дальнейших исследований.

2 Требования к инструментам тестирования

По влиянию на тестируемую систему инструменты тестирования можно разделить на два типа: пассивные и активные [18]. Пассивное тестирование — это процесс обнаружения неисправностей в тестируемой системе путем исследования ее поведения без оказания воздействий на нормальный процесс работы. Активные инструменты непосредственно воздействуют на трейдинговую систему и используются для обмена сообщениями, анализа полученных от системы откликов, нагрузочного тестирования.

2.1 Пассивные инструменты тестирования

Пассивные инструменты тестирования используются для автоматизированного сбора логов, структурирования данных, мониторинга и анализа поведения системы, сертификации пользователей. Инструменты тестирования позволяют оперативно исследовать большой объем данных, реагировать на отклонения в поведении системы от установленных требований, локализировать неполадки.

Инструмент тестирования позволяет эффективно решать эти задачи, если выполнены следующие требования: обеспечена полнота сбора данных обо всех событиях в системе; минимизировано влияние на систему; обеспечено оповещение в реальном режиме времени о нестандартных ситуациях; реализованы гибко настраиваемые критерии распознавания образов; обеспечено хранение и предоставление доступа к историческим данным; предоставлена возможность отслеживать последовательность событий и внутренние состояния системы на определенный момент времени.

Нахождение первопричины сбоя, произошедшего при использовании HiVAT-методов, зачастую является более сложным процессом по сравнению с обычными методиками ручного и автоматизированного тестирования. Эта сложность обусловлена, в основном, двумя факторами: автоматическим созданием сценариев тестирования и большим объемом разнородных данных, пропущенных через систему. Тестировщику необходимы удобные инструменты, информирующие его о возникновении проблем и позволяющие детально исследовать состояние системы до и после возникновения сбоев.

Недетерминированный характер входного потока сообщений, являющийся отличительной чертой использования HiVAT-методов, подразумевает необходимость в гибкости сценариев распознавания проблем и предоставление тестировщику возможностей по их настройке.

Невозможно обеспечить полноту сбора информации без присутствия эффекта измерения для высоконагруженной системы. Задача инструмента тестирования

Page 194: TMPA-2013 Conference Proceedings

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

состоит в том, чтобы минимизировать влияние самого инструмента на функциональность и производительность тестируемой системы.

Инструмент дожен предоставлять доступ к детальным и аггрегированным данным, полученным в результате выполнения текущей и предыдущих итераций тестирования. Диаграмма на рис. 1 показывает компоненты необходимые для реализации перечисленных требований к пассивным инструментам тестирования.

Рис. 1. Высокоуровневая схема основных компонентов инструмента для пассивного тестирования трейдинговых систем

2.2 Активные инструменты тестирования

Инструмент для активного тестирования должен обладать универсальностью, то есть способностью подключаться к различным тестируемым окружениям, используя разнообразные протоколы. Применение фаззинга для распределенных трейдинговых систем накладывает ограничения на создаваемые сообщения [25] с целью обеспечить их прохождение к ядру и другим внутренним компонентам без блокирования их на внешних шлюзах протокольных подключений или на начальных ступенях защиты модулей контроля рисков. Автоматический характер создания сценариев тестирования и их значительный объем требует сохранения информации об отправленных сообщениях и внутренних состояниях инструмента тестирования, его настройках. При использовании сложных техник необходима также сверка данных между инструментом и тестируемой системой. Использование HiVAT-методов для высоконагруженных трейдинговых систем требует создания масштабной инфраструктуры для тестирования.

Page 195: TMPA-2013 Conference Proceedings

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

Эффективность использования такой инфраструктуры может быть обеспечена только в случае одновременной доступности ее для выполнения различных задач тестирования. Инструменты для тестирования должны позволять выполнять вручную и ставить в расписание прогонов наборы автоматизированных сценариев даже в случаях, когда параллельно многократно выполняются сценарии библиотеки регрессионного тестирования или тесты, основанные на техниках случайной генерации тестов.

Для создания полноценных функциональных тестов инструмент должен предоставить удобные программируемые возможности для управления процессом генерации автоматизированных сценариев тестирования. Диаграмма на рис. 2 показывает компоненты, необходимые для реализации перечисленных требований к активным инструментам тестирования.

Рис. 2. Высокоуровневая схема основных компонентов инструмента для активного тестирования трейдинговых систем

2.3 Общие требования к инструментам для тестирования трейдинговых систем

Следующие характеристики являются обязательными как для пассивных, так и для активных инструментов при использовании HiVAT-методов: масштабируемость и высокая пропускная способность; устойчивость; адаптивность;

Page 196: TMPA-2013 Conference Proceedings

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

удобность и интерактивность. Эти обязательные характеристики совпадают с требованиями,

предъявляемыми к промышленным трейдинговым системам.

3 Использование инструментов тестирования в промышленной эксплуатации трейдинговых систем

В этой части статьи мы сопоставим требования, предъявляемые к инструментам для тестирования трейдинговых систем с использованием методов HiVAT, с требованиями к трейдинговым системам и системам мониторинга, используемым в промышленной эксплуатации.

Таблица 1. Требования к системам мониторинга и контроля финансовых рисков

Требование Использование в промышленной эксплуатации

Полнота сбора данных обо всех событиях в системе

Основная задача системы мониторинга и контроля финансовых рынков — поддерживать аналитическую работу отделов, отвечающих за выявление возможных манипуляций [19]. Система мониторинга должна собирать информацию обо всех входящих заявках, ответах системы, данных, поступающих из внешних источников, а также о релевантных внутренних состояниях трейдинговой платформы.

Минимизация влияния на трейдинговую систему

Сбор большого объема информации невозможен без масштабируемой мониторинговой инфраструктуры. Наблюдение за рынком исключительно важный процесс, являющийся обязательным в абсолютном большинстве финансовых юрисдикций. Тем не менее, для обеспечения минимальных времен отклика на приходящие в реальном режиме времени сообщения операторы трейдинговых систем стараются избегать негативного влияния эффекта измерения на основную функциональность трейдинговой платформы.

Оповещение в реальном режиме времени о нестандартных ситуациях

Операторы системы должны быть немедленно уведомлены при возникновении технических проблем или подозрительных транзакций. Такие уведомления называются оповещениями системы мониторинга (surveillance alerts). Эффективно работающая система оповещения — ключевой компонент системы мониторинга и контроля рисков.

Гибко настраиваемые критерии распознавания образов

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

Page 197: TMPA-2013 Conference Proceedings

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

аналитические заключения на основе нечеткой логики, параметры которой приходится непрерывно адаптировать под новые трейдинговые ситуации и схемы поведения участников торгов [20].

Хранение и предоставление доступа к историческим данным

По запросам аудита или регулирующих органов операторы трейдинговых систем обязаны предоставлять исторические данные и результаты их обработки

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

Формальные критерии сами по себе не являются достаточным доказательством наличия манипуляции. Операторы системы нуждаются в возможности восстанавливать последовательность событий относящихся к конкретным эпизодам, вызвавшим оповещение о проблеме. Данная функция называется проигрыванием книги заявок (order book replay). Удобная реализация позволяет операторам исследовать большее количество событий и делать выводы о правильности работы механизмов распознания образов.

Рис. 3. Высокоуровневая схема основных компонентов системы мониторига и контроля финансовых рисков создаваемой в компании «Exactpro Systems», LLC.

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

Page 198: TMPA-2013 Conference Proceedings

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

Таблица 2. Требования к системам выполнения биржевых и алгоритмических заявок

Требование Использование в промышленной эксплуатации

Универсальность. Подключение ко множеству других систем и поддержка используемых ими протоколов

В условиях фрагментации финансовых рынков брокерские системы должны обеспечивать возможность подключения к разным биржевым системам и сторонним брокерам [21].

Предоставление одновременного доступа

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

Возможность выполнения сложных сценариев

Основная функция систем алгоритмической торговли — предоставление пользователям возможности задавать стратегию посылки заявок на выполнение финансовых транзакций в зависимости от состояния рынка, портфеля, параметров риска, информационных сообщений и т.д.

Хранение информации обо всех отправленных сообщениях и внутренних состояниях. Возможность сверки этих данных с данными, поступающими из внешних систем, включая клиринг и депозитарии

Оператор трейдинговой системы, предоставляющий доступ своим клиентам на финансовые рынки, обязан хранить информацию обо всех совершенных финансовых транзакциях [22] и производить сверку этих данных с данными клиентов и контрагентов, а также с информацией из пост-торговых систем.

Page 199: TMPA-2013 Conference Proceedings

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

Рис. 4. Высокоуровневая схема основных компонентов системы выполнения биржевых и алгоритмических заявок, создаваемой в компании «Exactpro Systems», LLC.

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

4 Направление дальнейших исследований

Сравнение требований и концептуальных схем инструментов для тестирования с соответствующими промышленными системами позволяет утверждать, что, начиная с определенного уровня зрелости инструменты для тестирования могут использоваться как подсистема трейдинговой платформы. Но основной задачей тестирования является не нахождение правильно работающих подсистем, а выявление проблем и недостатков в исследуемом приложении. Превращение инструментов для тестирования в промышленные трейдинговые системы может потенциально привести к концентрации взаимодействия на корректно работающих участках, снижению покрытия тестами и избыточному фокусу на позитивных сценариях. Основное направление дальнейшей работы — это нахождение методов преодоления этой тенденции.

Если инструменты для тестирования становятся частью промышленной инфраструктуры, то внесение небольших изменений в их код и настройки, является по сути изменением содержащей их трейдинговой платформы. Таким образом, предложенный подход открывает новые возможности по применению методов мутационного тестирования на системном уровне к исследованию

Page 200: TMPA-2013 Conference Proceedings

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

сложных интегрированных трейдинговых систем [23]. Внесенные изменения называются мутациями и основываются на мутационных операторах [24], которые имитируют типичные ошибки или нежелательные воздействия. Мутации также позволяют оценить эффективность существующего набора тестов и качество инструментов для тестирования.

Операторами мутации трейдинговой системы для проверки нефункциональных свойств могут стать следующие изменения: введение случайных задержек во внутренние компоненты, логические алгоритмы и в функционирование внешних подключений; замена оптимизированных TCP/IP потоков данных на множество параметризованных библиотек на различных языках; заполнение памяти или дискового пространства на компьютере с исследуемой системой большим количеством логов; загрузка сети паразитными сообщениями или внедрение ошибок в структуры данных.

Второе направление дальнейших исследований - это изучение методов фаззинга, совместимых со структурой и консистентностью промышленных систем [25].

5 Заключение

На основе обобщения опыта по верификации корректной работы высоконагруженных электронных трейдинговых систем с функциональной и нефункциональной точек зрения в статье проанализированы методы обеспечения их качества, основанные на большом объеме автоматизированного тестирования (НiVAT).

Практическое использование этих методов авторами позволило определить набор основных требований к инструментам пассивного и активного тестирования, применяемым для верификации подобного рода систем. В статье сделан вывод, что инструмент для тестирования, соответствующий определенному набору требований, является по своей сути системой, применимой при промышленной эксплуатации трейдинговых систем.

Полученные авторами результаты обосновали оправданность финансирования создания инструментов для тестирования, основанных на описанных выше методах и принципах. В рамках проектов компании «Exactpro Systems», LLC разрабатываются: система мониторинга и контроля финансовых рынков и система поддержки алгоритмической торговли. Обе системы имеют двойное назначение и могут использоваться и как инструмент для тестирования, и как самостоятельный элемент промышленной трейдинговой инфраструктуры [26].

Выше были рассмотрены также дополнительные возможности по использованию методов мутационного тестирования на системном уровне для анализа и расширения полноты покрытия функциональными и нефункциональными тестами. Указанные возможности открываются при включении инструментов тестирования в состав трейдинговой платформы.

Page 201: TMPA-2013 Conference Proceedings

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

Литература

1. The Future of Computer Trading in Financial Markets. Final Project Report. / Foresight. The Government Office for Science, London. // [Электронный ресурс]. – Режим доступа http://www.bis.gov.uk/assets/foresight/docs/computer-trading/12-1086-future-of-computer-trading-in-financial-markets-report.pdf

2. Bloomfield,R., Wetherilt,A.: Computer trading and systemic risk: a nuclear perspective. / Foresight. The Government Office for Science, London // [Электронный ресурс]. – Режим доступа http://www.bis.gov.uk/assets/foresight/docs/computer-trading/12-1059-dr26-computer-trading-and-systemic-risk-nuclear-perspective.pdf

3. Commission Roundtable on Technology and Trading: Promoting Stability in Today's Markets. / U.S. Securities and Exchange, October 2, 2012 // [Электронный ресурс]. – Режим доступа http://www.sec.gov/news/otherwebcasts/2012/ttr100212-transcript.pdf

4. Иткин И.Л.: Высоконагруженные трейдинговые системы и их тестирование. / Конференция разработчиков высоконагруженных систем HighLoad++ // [Электронный ресурс]. – Режим доступа http://www.highload.ru/2012/abstracts/388.html

5. Penhaligan,P.: Equity Trading: Performance, Latency & Throughput. / ExTENT Conference // [Электронный ресурс]. – Режим доступа http://www.slideshare.net/extentconf/extent3-turquoise-equitytrading2012

6. Avellaneda,M.: Algorithmic and High-frequency trading: an overview / New York University & Finance Concepts LLC Quant Congress USA 2011. // [Электронный ресурс]. – Режим доступа http://www.math.nyu.edu/faculty/avellane/QuantCongressUSA2011AlgoTradingLAST.pdf

7. Millennium Exchange Technical Specifications / Официальный сайт London Stock Exhcange // [Электронный ресурс]. – Режим доступа http://www.londonstockexchange.com/products-and-services/technical-library/millennium-exchange-technical-specifications/millennium-exchange-technical-specifications.htm

8. Zverev,A., Bobrov,I, Pryadkina,N..: Testing of HFT GUI. / ExTENT conference // [Электронный ресурс]. – Режим доступа http://www.slideshare.net/extentconf/extent3-exactpro-testingofhftgui-12944204

9. Yu,T.: An observable and controllable testing framework for modern systems. // ICSE '13: Proceedings of the 2013 International Conference on Software Engineering Publisher: IEEE Press, May 2013

10. Netzer,R.H.B, Miller,B.P.: What are race conditions?: Some issues and formalizations // Letters on Programming Languages and Systems (LOPLAS) , Volume 1 Issue 1, March 1992

11. Zverev,A., Bulda,A., Bobrov,I.: Trading Systems: Testing at the Confluence of FT&NFT. / ExTENT conference // [Электронный ресурс]. – Режим доступа http://www.slideshare.net/extentconf/extent-2013-obninsk-trading-systems-testing-at-the-confluence-of-ft-nft-17082512

12. Heider,W., Rabiser,R., Grünbacher,P., Lettner,D.: Using regression testing to analyze the impact of changes to variability models on products. // SPLC '12: Proceedings of the 16th International Software Product Line Conference - Volume 1, September 2012

13. Eurodollars on CME Globex: Implied Price Functionality // [Электронный ресурс]. – Режим доступа http://www.cmegroup.com/trading/interest-rates/files/Butterflies.pdf

14. Sutton,M., Greene,A., Amini,P.: Fuzzing: Brute Force Vulnerability Discovery. // Addison- Wesley Professional, 2007

15. McGee,P., Kaner,C.: Experiments with high volume test automation. // SIGSOFT Software Engineering Notes, September 2004

16. Kaner,C: An Overview of High Volume Automated Testing. // [Электронный ресурс]. – Режим доступа http://kaner.com/?p=278

Page 202: TMPA-2013 Conference Proceedings

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

17. Teaching High Volume Automated Testing (HiVAT). //12th Workshop on Teaching Software Testing (WTST 2013), January 25-27, 2013, Melbourne, Florida, at the Harris Institute for Assured Information. // [Электронный ресурс]. – Режим доступа http://wtst.org/

18. Cavalli,R., Montes de Oca,E., Mallouli,W., Lallali,M.: Two Complementary Tools for the Formal Testing of Distributed Systems with Time Constraints. //12th 2008 IEEE/ACM International Symposium on Distributed Simulation and Real-Time Applications.

19. Diaz,D., Zaki,M., Theodoulidis,B., Sampaio,P.: A Systematic Framework for the Analysis and Development of Financial Market Monitoring Systems. // 2011 Annual SRII Global Conference

20. Иткин И., Прядкина Н., Крюков А.: Анализ данных в высоконагруженных трейдинговых системах. / Конференция АИСТ-2013. // [Электронный ресурс]. – Режим доступа http://clubqa.ru/blogs/?p=436

21. Официальный сайт Fidessa Fragmentation Index // [Электронный ресурс]. – Режим доступа http://fragmentation.fidessa.com/

22. OATS Reporting Technical Specifications. // [Электронный ресурс]. – Режим доступа http://www.finra.org/web/groups/industry/@ip/@comp/@regis/documents/appsupportdocs/p197473.pdf

23. Mateo,P.R., Usaola,M.P., Alema´n,J.L.F.:Validating Second-Order Mutation at System Level. // IEEE Transactions on softvare engineering, vol. 39, No. 4, April 2013

24. Mateo,P.R., Usaola,M.P., Offutt,J.: Mutation at System and Functional Levels. // Third International Conference on Software Testing, Verification, and Validation Workshops

25. Wang,T., Wei,T., Gu,G., Zou,W.: Checksum-Aware Fuzzing Combined with Dynamic Taint Analysis and Symbolic Execution. // ACM Transactions on Information and System Security, Vol. 14, No. 2, Article 15, Publication date: September 2011

26. Itkin,I., Matveeva,A., Barch,A.: Test Tools evolution. / ExTENT conference // [Электронный ресурс]. – Режим доступа http://www.slideshare.net/extentconf/extent-2013-obninsk-test-tools-for-trading-systems-evolution-theory-17007184

Page 203: TMPA-2013 Conference Proceedings

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

Тестирование совместимости протокольных подключений клиентов биржевых и брокерских

систем Андрей Алексеенко1, Анастасия Матвеева1, Даниил Шаров1, Павел

Проценко2, Иосиф Иткин3

1 ООО «Инновационные Трейдинговые Системы», Россия, 1156088, г. Москва, 2-й

Южнопортовый проезд, 20А/4 [email protected], [email protected],

[email protected]

2 Exactpro Systems UK, 10 Paternoster Square, London, EC4M 7LSl, UK [email protected]

3 Exactpro Systems LLC, 4040 Civic Center Drive, Suite 200, San Rafael, CA 94903, USA [email protected]

Aннотация. Жизненный цикл разработки биржевого и брокерского программного обеспечения, помимо проверки функциональных и технических характеристик системы, включает в себя обязательный этап интеграционного тестирования, называемый сертификацией клиентов. Этот этап призван обеспечить совместимость систем автоматизированной торговли, подключаемых к бирже или брокеру посредством финансовых протоколов (таких как FIX/FAST, ITCH или специализированные бинарные интерфейсы доступа). В статье представлен оригинальный инструмент, разработанный для проверки совместимости торговых систем. Отличительная особенность разработанного инструмента - унифицированный способ поддержки множества протоколов. Приведены примеры его использования при самостоятельной сертификации участников торгов, а также при масштабных миграциях трейдинговых платформ. Ключевые слова: финансовые протоколы, FIX-протокол, тестирование совместимости, самостоятельная сертификация, торговый брокер, биржа.

1 Введение Адаптация новых клиентов к трейдинговой платформе и их поддержка при обновлениях программного обеспечения - это один из ключевых бизнес- процессов биржевых и брокерских организаций [1; 2; 3]. Существенной составляющей этого процесса служит тестирование, проводимое для выявления проблем с совместимостью трейдинговой платформы с системами, принадлежащими подключаемым к бирже или брокеру участникам торгов, называемое сертификацией клиентов [4]. Сертификация клиентов обязательна для любого оператора биржевой или брокерской платформы, предоставляющей возможность осуществлять финансовые транзакции, и в настоящее время широко используется в

Page 204: TMPA-2013 Conference Proceedings

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

финансовой индустрии [5]. Ссылки на правила сертификации клиентов и соответствующую документацию можно найти на официальных сайтах соответствующих организаций [6; 7; 8; 9]. Программное обеспечение, ранее успешно прошедшее внутреннее интеграционное тестирование, проходит после этого через завершающий тест - интеграцию с клиентами (обычно юридическими лицами). Общепринятой практикой является ситуация, когда клиенты и оператор трейдинговой платформы задают временной интервал для выполнения активного тестирования и оценивают его результаты с обеих сторон. В связи с тем, что в процесс сертификационного тестирования вовлечены люди, представляющие разные компании, данный процесс требует значительной степени координации и слаженности работы. Это чрезвычайно важно как с финансовой, так и с репутационной точек зрения. Любой дефект программного обеспечения, обнаруженный на этапе сертификационного тестирования, является достаточно дорогостоящим с точки зрения его устранения, поскольку все стадии жизненного цикла программного обеспечения уже пройдены [10], а любая задержка с обнаружением проблем совместимости вносит существенные дополнительные затраты. К характерным проблемам, с которыми приходится сталкиваться при проведении сертификации клиентов, относятся:

наличие часовых поясов и возникающие в связи с этим сложности в планировании и координации проведения тестирования командами профессионалов, находящимися физически в разных частях земного шара;

производительность: сертификация может требоваться несколькими клиентами одновременно из-за бизнес- или технических событий, таких как выход новых версий программного обеспечения, изменений нормативных или технических требований;

компетентность: специалист по обеспечению качества программного обеспечения, проводящий сертификацию, обязан обладать должным уровнем технических и бизнес-знаний;

покрытие: сертификационные тесты должны быть основаны на типичных сценариях и обеспечивать значимые результаты.

В трейдинговой индустрии начинает формироваться понимание того, что одним из способов преодоления этих проблем может стать создание более совершенных решений по автоматизации сертификационного тестирования и анализу его результатов [11]. Несмотря на актуальность автоматизации процесса сертификации биржевых/брокерских клиентов, данная проблематика пока практически не освещена в отечественной и зарубежной научной литературе. На рынке присутствует несколько коммерческих инструментов тестирования, созданных для ускорения процесса сертификации клиентов:

FIX Conductor от компании Lasalletech [12]; FACTS от B2BITS, EPAM Systems [13]; CertiFIX от Greenline [14]; Catalys Studio от Cameron [15];

Page 205: TMPA-2013 Conference Proceedings

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

Ignition от FIXFlyer [16]; VegaFABS от Pravega Financial Technologies [17]; Certpoint от Tradepoint Systems [18]; Certification Platform от FixSpec.com [19].

Биржевые платформы используют два основных подхода к сертификации: Предоставление клиентам специализированного симулятора для

проведения сертификации [20; 21; 22]. Клиенты проводят тестирование, используя предоставленный инструмент, и предоставляют логи сертификации;

Предоставление доступа к специализированному тестовому окружению, которое является уменьшенной копией промышленной системы; документирование процедуры; совместное проведение сертификации с клиентом либо использование самостоятельной сертификации [23]; использование пассивных методов, таких как перехват трафика сетевых подключений или данные из лог-файлов, для анализа успешности и полноты проведенной процедуры сертификации.

Оба подхода в той или иной степени реализованы в существующих коммерческих решениях. Основное достоинство метода, основанного на использовании симуляторов, - это снижение нагрузки на сертифицирующую организацию и клиентов, обеспечиваемое возможностью проводить сертификацию в любое время суток, а не только в период открытого торгового дня. Проблема, специфичная для всех симуляторов, - отсутствие гарантии, что фактическое сообщение, отправленное с его помощью, идентично сообщениям, отправляемым реальным программным обеспечением [24]. Пассивное тестирование является, на наш взгляд, наиболее корректным методом проведения сертификации клиентов. Общая концепция пассивного тестирования и её преимущества описаны в [25], различные алгоритмы пассивного тестирования предложены в [26; 27]. Основным преимуществом пассивного тестирования является то, что инструмент для тестирования не оказывает влияния на тестируемую систему и не приводит к созданию потоков дополнительных сообщений. Данное преимущество, однако, одновременно является и недостатком: для успешного проведения пассивного тестирования необходимые сообщения должны быть кем-то созданы. В случае сертификации клиентов требуется привлекать представителей другой компании для создания входящего потока сообщений. Данная практика неизбежна при первичной сертификации. Однако с целью снижения временных затрат сторонних организаций требуется использовать более эффективные методы: например, предложенный в [28] подход. Используя данные первичной сертификации для автоматизированного создания новых сценариев тестирования, при сохранении неизменной спецификации протокола доступа, оператор трейдинговой платформы получает возможность провести повторную сертификацию клиента самостоятельно. Присутствующие на рынке инструменты для сертификации клиентов обладают следующими ограничениями:

специализация на одном фиксированном протоколе, например FIX [29];

Page 206: TMPA-2013 Conference Proceedings

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

интерактивные инструменты анализа данных и создания новых сценариев малопригодны для обработки действительно больших объемов данных о гетерогенных клиентских подключениях.

Авторы принимают участие в разработке и использовании программного решения компании Exactpro Systems LLC, направленного на преодоление указанных ограничений [30; 31]. Созданный инструмент описывается во второй части данной статьи. Третья часть содержит описание практического использования созданного инструмента для самостоятельной сертификации участников биржевых торгов. Четвертая часть описывает использование разработанного инструмента при масштабных миграциях брокерских систем.

2 Многопротокольное решение для пассивного тестировання трейдинговых систем Инструмент для пассивного тестирования сетевых подключений к трейдинговым системам разработан с использованием языка Java и системы управления базами данных MySQL. В основе подхода - унифицированное описание структуры протокольных сообщений - система словарей. Для каждого протокола создается словарь. Для групп протоколов может потребоваться написание специальных модулей, приводящих сетевые потоки данных к унифицированному внутреннему формату на основе словарей. Концепция близка к логике Complex Events Processing [32]. Для создания шаблона словаря был взят и доработан для большей общности шаблон словарей, используемый в системе QuickFIX/J [33]. Разработанный инструмент может получать на входящие данные о перехваченных сетевых сообщениях, полученных с использованием tcpdump [34] или различных прокси-серверов [35]. Пользователю также предоставлена возможность загружать лог-файлы, содержащие массив сообщений, в настраиваемом формате. Основная таблица в базе данных содержит информацию о каждом перехваченном пакете, включая повторную пересылку TCP-данных. Если трейдинговая система находится под нагрузкой, сетевой пакет может содержать несколько сообщений или же сообщение может быть разбито между несколькими TCP-пакетами. Выделив сообщения из сетевых пакетов, инструмент делает попытку конвертации в унифицированный формат на основе словарей. Информация о сетевых пакетах и сообщениях, не прошедших проверку посредством словарей, заносится в отдельную таблицу, по сути содержащую список проблем сертификации первого уровня. Детали перехваченных и успешно обработанных сообщений могут быть сохранены в реляционную базу данных посредством двух основных методов:

использования общей таблицы, содержащей идентификаторы сообщения, имя параметра и его значение;

использования индивидуальной таблицы для каждого типа сообщения, размещая параметры сообщения в соответствующих колонках, с именами, произведенными от имени параметров.

Page 207: TMPA-2013 Conference Proceedings

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

Преимущество первого подхода – это большая общность. Преимущество второго подхода – удобство работы с SQL-запросами к базе данных. В разработанном инструменте используется комбинация обоих подходов: для каждого типа сообщений создана индивидуальная таблица, а данные из повторяющихся групп хранятся в общей таблице. Рисунок 1 содержит схему использования разработанного инструмента для перехвата и хранения сетевых сообщений.

Рис.1. Процесс обработки сообщений в инструменте тестирования и сертификации.

Перехваченные сообщения декодируются и складываются в базу данных инструмента. Все отчеты по сертификации хранятся в виде SQL запросов. При добавлении нового вида отчетов или иного требования, нет необходимости менять код самого инструмента. С помощью SQL запроса есть возможность найти сообщения по списку и их статус, и выделить их цветом с помощью пользовательского интерфейса для лучшего зрительного восприятия. SQL запросы так же могут быть использованы для нахождения необходимой статистики по сообщениям, количества заходов в приложения, синтаксически непроанализированные сообщения и т.д. Графический интерфейс пользователя разработанного инструмента позволяет аналитику, отвечающему за сертификацию или обеспечение качества трейдинговой платформы, просматривать сообщения и события в реальном режиме времени, включая детали сетевых пакетов, результаты верификации посредством системы словарей, значения индивидуальных полей и исходные бинарные данные.

Page 208: TMPA-2013 Conference Proceedings

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

Сертификационные тесты и сверки данных могут быть реализованы посредством обычных SQL-запросов. Инструмент предоставляет возможность подсветки и анализа сообщений, полученных в результате выполнения того или иного запроса. На рисунке 2 представлен пример окна графического интерфейса разработанного инструмента.

Рис.2. Графический пользовательский интерфейс инструмента тестирования и сертификации.

3 Самостоятельная сертификация участников биржевых торгов Регулирующие органы требуют от операторов биржевой системы предоставления эквивалентного доступа всем участникам торгов [36]. При внесении изменений в технологическую платформу биржи ее оператор обязан провести сертификацию всех подключенных торговых систем в короткий промежуток времени. Данная особенность процесса создает существенную нагрузку на отделы организации-оператора биржевой площадки, отвечающие за поддержку клиентов. Для снижения этой нагрузки биржевые площадки используют метод самостоятельной сертификации. Клиентам предоставляется доступ к тестовому окружению и сценарий выполнения сертификационных тестов. После выполнения шагов предоставленного сценария клиент высылает логи процесса в сертифицирующую организацию, где они проходят дополнительную проверку. Пассивное тестирование значительно упрощает процесс сертификации для участников торгов. При данном подходе от них требуется только подключиться

Page 209: TMPA-2013 Conference Proceedings

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

к тестовому окружению и отправить заявки, обозначенные в тестовом сценарии. Таким образом, участники торгов избавлены от выполнения любых шагов (таких как установка дополнительного программного обеспечения, сбор логов и т.д.), кроме тех, которые непосредственно необходимы для подключения к технологической платформе биржи. Разработанный инструмент перехватывает все сообщения, переданные от клиента к бирже или в обратную сторону, разбирает структуру и содержимое каждого сообщения и сохраняет всё в реляционную базу данных. Используя SQL-запросы, аналитик сертифицирующей организации может получить статистику по попыткам выполнения шагов тестового сценария и их успешности для каждого из участников торгов. Данные о сетевых пакетах позволяют также обнаружить дополнительные проблемы, такие как разрывы соединений или проблемы с буферизацией сообщений. Приведем пример сертификационного SQL-сценария, проверяющего успешность размещения клиентом агрессивной рыночной заявки, в результате появления которой по исполнении её против заявок, размещенных на противоположной стороне стакана заявок, образовались две и более сделки:

insert into t_native_testcases (user,sourceip,sourceport,testcase,timestamp,clordid,orderid,otherid) select distinct n.user, n.sourceip, n.sourceport, 'MEx-012.2 Agg. MO' as testcase, n.timestamp, n.clordid, e.orderid, '' from t_lsenative_neworder n , t_lsenative_executionreport e , t_lsenative_executionreport e2 where n.user=e.user and n.sourceip=e.destinationip and n.sourceport=e.destinationport and n.clordid=e.clordid and n.user=e2.user and n.sourceip=e2.destinationip and n.sourceport=e2.destinationport and n.clordid=e2.clordid and n.ordertype=1 and e.ordstatus=1 and e.tradeliquidityindicator='R' and e2.typeoftrade='2' and e2.ordstatus in (1,2) and e2.tradeliquidityindicator='R' and e2.typeoftrade='2' and e.execid <> e2.execid order by user, clordid, orderid;

Для нескольких биржевых платформ были разработаны совокупности SQL-сценариев, покрывающие все требования по сертификации клиентских соединений, опубликованные организатором торгов [9].

4 Миграция брокерской платформы с большим количеством гетерогенных клиентских подключений В сравнении с биржевыми платформами брокерские системы обычно предоставляют существенно более широкие возможности по настройке

Page 210: TMPA-2013 Conference Proceedings

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

протокола взаимодействия с системами клиентов: например, используя возможности таких систем, как UL Bridge [37]. Один и тот же клиент может использовать одновременно несколько брокеров для получения доступа на биржу. Часто брокеры стараются снизить количество изменений в протоколах коммуникации, которые конкретный клиент вынужден имплементировать со своей стороны. Облегчая взаимодействие с клиентом, этот подход одновременно приводит к появлению большого количесва гетерогенных конфигураций со стороны брокерской трейдинговой платформы. При внутренних изменениях брокерской платформы возникает необходимость в регрессионном тесте на совместимость с клиентскими системами. Разработанный инструмент позволяет обработать имеющиеся данные из тестовых и промышленных окружений и создать необходимый набор активных тестовых сценариев. Выполнив эти сценарии против тестового окружения без привлечения конечных клиентов тестовый инструмент запускает SQL-сценарии, выполняющие сверку ответов брокерской платформы до и после изменений. Особенность созданного авторами инструмента состоит в том, что он позволяет проводить этот процесс одновременно для большого количества клиентов, подключений, рынков и типов сообщений. Гибкость при создании сверяющих SQL-запросов позволяет не только исключить из сравнения поля, про которые заранее известно, что их значения должны различаться (например, sequence numbers, timestamps и другие), но и задать требования по обработке более сложных расхождений. Подход доказал свою жизнеспособность и эффективность при миграции трейдинговой платформы одного из крупнейших международных брокеров, предоставляющего доступ к торговле производными финансовыми инструментами. Последовательность шагов отображена на схеме на рисунке 3.

Page 211: TMPA-2013 Conference Proceedings

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

Рис.3. Схематичный пример реализации предлагаемого решения.

Логи из промышленной системы загружаются в базу данных инструмента для тестирования и сертификации. Генератор скриптов использует данную базу для создания совокупности тестовых сценариев, исполняемых активным инструментом для функционального тестирования. Логи выполнения тестовых сценариев загружаются в базу данных для сравнения с данными полученными из промышленной системы.

4 Заключение С ростом объёмов автоматизированной электронной торговли стабильность и устойчивость финансовых рынков будут во все большей степени зависеть от корректной совместной работы платформ, обеспечивающих инфраструктуру рынков, и подключенных к ним автоматизированных трейдинговых систем. Стоимость процессов подключения новых клиентов, их сертификации и сохранения совместимости при регулярно вносимых изменениях существенно влияет на общую стоимость функционирования биржевых и брокерских систем. Представленный в статье инструмент используется с целью повышения эффективности и экономичности указанных процессов. Имеется позитивный опыт его применения в рамках проектов компании Exactpro Systems LLC на заключительных этапах выпуска в промышленную эксплуатацию

Page 212: TMPA-2013 Conference Proceedings

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

крупномасштабных трейдинговых систем для торговли финансовыми инструментами разных классов. В статье описаны используемые в индустрии методы сертификации клиентских подключений и сделаны выводы о преимуществах подхода, основанного на использовании многопротокольного пассивного инструмента, сохраняющего данные в реляционную СУБД. Рассмотрен также вариант использования данного инструмента с целью создания активных тестов и сокращения затрат при масштабных миграциях систем с множеством гетерогенных клиентских подключений. Дальнейшие исследования будут направлены на оптимизацию структуры базы данных: в частности, в вопросе распространения разработанных методов на трейдинговые протоколы, основанные не на сетевых взаимодействиях, а на программных интерфейсах доступа (API).

Источники 1. Markit Magazine Issue 10 - Focus: Client Onboarding – Markit.com // [Электронный

ресурс]. – Режим доступа http://www.markit.com/assets/en/docs/markit-magazine/issue-10/mm10_focus5-onboardingroundtable.pdf

2. Fenergo 2013, Client Onboarding: Solving the Challenges, Maximizing the Opportunities. // [Электронный ресурс]. – Режим доступа http://www.fenergo.com/industry-knowledge/whitepapers/client-onboarding-solving-challenges-maximizing-opportunities.html

3. Axel Pierron, Anshuman Jaswal: Institutional Client On-Boarding in the Financial Industry Time to Move to the Industrialization Phase. // Celent Report, October 2012 //

[Электронный ресурс]. – Режим доступа http://www.celent.com/reports/institutional-client-boarding-financial-industry

4. Challenges and Solutions to Onboarding Trading Clients. // [Электронный ресурс]. – Режим доступа http://www.trdpnt.com/blog/bid/294222/Challenges-and-Solutions-to-Onboarding-Trading-Clients

5. FIA Market Access Risk Management Recommendations April 2010. // [Электронный ресурс]. – Режим доступа http://www.futuresindustry.org/downloads/Market_Access-6.pdf

6. Moscow Exchange. // [Электронный ресурс]. – Режим доступа http://fs.moex.com/files/4531

7. BOX Options Exchange. // [Электронный ресурс]. – Режим доступа http://boxexchange.com/what-you-need-to-know/software-certification/

8. Eris Exchange. // [Электронный ресурс]. – Режим доступа http://www.erisfutures.com/sites/default/files/Electronic_Trading_Certification_Process.pdf

9. TQ 601 - Technical Specification Turquoise Equities Guide to Certification. // [Электронный ресурс]. – Режим доступа http://www.lseg.com/sites/default/files/content/documents/TQ601%20-%20Guide%20To%20Application%20Certifcation.pdf

10. Forrest Shull, Vic Basili, Barry Boehm, A. Winsor Brown, Patricia Costa, Mikael Lindvall,Dan Port, Ioana Rus, Roseanne Tesoriero, Marvin Zelkowitz: What We Have Learned About Fighting Defects // METRICS '02 Proceedings of the 8th International Symposium on Software Metrics, IEEE Computer Society Washington, DC, USA 2002

Page 213: TMPA-2013 Conference Proceedings

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

11. Candyce Edelen: Making the Case for Automated FIX Certification. // [Электронный ресурс]. – Режим доступа http://www.advancedtrading.com/high-frequency/making-the-case-for-automated-fix-certif/240155554

12. FIX Conductor™ от компании Lasalletech. // [Электронный ресурс]. – Режим доступа http://www.lasalletech.com/products/fix-automated-onboarding

13. FACTS от B2BITS, EPAM Systems. // [Электронный ресурс]. – Режим доступа http://www.b2bits.com/trading_solutions/fix_testing_facts.html

14. CertiFIX® от Greenline. // [Электронный ресурс]. – Режим доступа http://www.greenlinetech.com/products/certifix.php

15. Catalys Studio от Cameron. // [Электронный ресурс]. – Режим доступа http://www.camerontec.com/products/catalys/catalys-studio/

16. Ignition от FIXFlyer. // [Электронный ресурс]. – Режим доступа http://fixflyer.com/materials/software/Ki/FlyerIgnition.pdf

17. VegaFABS от Pravega® Financial Technologies. // [Электронный ресурс]. – Режим доступа http://www.pravegatech.com/index.php?option=com_content&view=article&id=64&Itemid=65

18. Certpoint от Tradepoint Systems. // [Электронный ресурс]. – Режим доступа http://www.trdpnt.com/certpoint/

19. Certification Platform от FixSpec.com // [Электронный ресурс]. – Режим доступа http://forexmagnates.com/fixspec-launches-innovative-multi-venue-certification-utility-to-streamline-connectivity/

20. The Stock Exchange of Hong Kong Limited. // [Электронный ресурс]. – Режим доступаhttp://www.hkex.com.hk/eng/market/partcir/sehk/2012/Documents/CTMO06612E.pdf

21. MyCTC (Certification and Testing Center) от BM&FBOVESPA. // [Электронный ресурс]. – Режим доступа http://www.bmfbovespa.com.br/en-us/services/download/MyCTC-User-Guide.pdf

22. CME Group. // [Электронный ресурс]. – Режим доступа -http://www.cmegroup.com/confluence/display/EPICSANDBOX/Client+System+Certification

23. The London Stock Exchange. // [Электронный ресурс]. – Режим доступа http://www.lseg.com/areas-expertise/technology/market-connectivity/customer-certification-and-testing-services

24. Zverev A., Bulda A.: Exchange Simulators for SOR/Algo Testing: Advantages vs. Shortcomings. / ExTENT conference. // [Электронный ресурс]. – Режим доступа

http://www.slideshare.net/IosifItkin/exchange-simulators-for-sor-algo-testing-advantages-vs-shortcomings

25. K. M. Brzezinski: Towards the Methodological Harmonisation of Passive Testing Across ICT Communities // Engineering the Computer Science and IT, October 2009

26. David Lee, Dongluo Chen, Ruibing Hao, Raymond E. Miller, Jianping Wu and Xia Yin: Network Protocol System Monitoring – A Formal Approach With Passive Testing // IEEE/ACM Transactions on Networking, Vol. 14, No. 2, April 2006

27. Ana Cavalli, Stephane Maag, Edgardo Montes de Oca: A passive conformance testing approach for a MANET routing protocol // Proceedings of the 2009 ACM symposium on Applied Computing March 2009, SAC '09

28. James Newsome, David Brumley, Jason Franklin, Dawn Song: Replayer: Automatic Protocol Replay by Binary Analysis // CCS '06: Proceedings of the 13th ACM conference on Computer and communications security, October 2006

29. FIX Protocol. // [Электронный ресурс]. – Режим доступа http://fixprotocol.org

Page 214: TMPA-2013 Conference Proceedings

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

30. Zverev A., Moskaleva O., Kudryavtseva M., Doronichev D., Bulda A.: Four Houses – Test Tools presentation. / ExTENT conference // [Электронный ресурс]. – Режим доступа http://www.slideshare.net/extentconf/extent3-exactpro-fourhousestesttools2012-1

31. Zaitseva N., Popovchuk N.: Next Step in Reconciliation Testing. / ExTENT conference // [Электронный ресурс]. – Режим доступа http://www.slideshare.net/extentconf/extent3-exactpro-thenextstepinreconciliationtesting

32. G. Cugola and A. Margara: Processing flows of information: From data stream to complex event processing // ACM Computing Surveys, 2011.

33. QuickFIX/J . // [Электронный ресурс]. – Режим доступа http://quickfixj.org 34. Felix Fuentes, Dulal C. Kar: Ethereal vs. Tcpdump: a comparative study on packet sniffing

tools for educational purpose // Journal of Computing Sciences in Colleges , Volume 20 Issue 4, April 2005

35. The Grinder TCP Proxy. // [Электронный ресурс]. – Режим доступа http://grinder.sourceforge.net/g3/tcpproxy.html

36. Investment Services Directive – Markets in Financial Instruments Directive (MiFID) 37. UL Bridge. // [Электронный ресурс]. – Режим доступа http://www.ullink.com/fix-

solutions.php

Page 215: TMPA-2013 Conference Proceedings

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

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

Ольга Буянова1, Алёна Булда1, Алексей Зверев2 1 ООО «Инновационные Трейдинговые Системы», Россия, 156013, г. Кострома, ул.

Ленина, 20 [email protected], [email protected]

2 Exactpro Systems LLC, 4040 Civic Center Drive, Suite 200, San Rafael, CA 94903, USA [email protected]

Aннотация. Системы агрегации и распределения информации о котировках широко применяются в современном трейдинге. Они позволяют собирать в реальном времени котировки с нескольких рынков, представлять данные о них в едином формате и распространять их в электронном виде в зависимости от запросов и целей внешних клиентов, трейдеров. В данной статье рассмотрена возможность применения симуляторов рынка к тестированию таких систем. Проведён анализ основных тестовых сценариев для систем распределения информации о котировках. Выделен набор основных функциональных и нефункциональных сценариев тестирования, необходимых для контроля качества распределения информации о котировках. Произведена сравнительная оценка симуляторов рынка и реальных тестовых площадок. Ключевые слова: система агрегации и распределения информации о котировках (Ticker Plant, Market Data), биржа, тестовая платформа, симулятор рынка, функциональное тестирование, нефункциональное тестирование.

1 Введение Современный электронный трейдинг невозможно представить себе без актуальных сведений о финансовых инструментах, заявках и сделках на них. Высоконагруженные биржевые и брокерские системы предоставляют рыночные данные о торгуемых на них финансовых инструментах через собственные специальные компоненты, называющиеся каналами распространения рыночных данных (или Market Data Feeds). Каждый финансовый инструмент - это значительное количество информации, генерирующейся ежесекундно, поэтому способность распространять весь поток рыночных данных и скорость распространения информации о котировках и финансовых сделках для каждого

Page 216: TMPA-2013 Conference Proceedings

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

финансового инструмента являются основными характеристиками для такого рода компонентов высоконагруженных систем.

1.1 Рыночная информация (Market Data) и ее основные представления

Обычно рыночная информация включает в себя следующий набор параметров, специфичных для определённого финансового инструмента: краткое название инструмента (ticker symbol), цена последней сделки (last trade price), текущие лучшие цены спроса и предложения (Best Bid & Offer), идентификационный номер инструмента (ISIN), биржа, на которой произошла сделка (exсhange code), время последней сделки (Trade Time), цена сделки при закрытии торговой сессии на инструменте (Close Price). В зависимости от сложности высоконагруженных биржевых систем, рыночная информация о котировках может обрабатываться внутренними компонентами электронных бирж и обогащаться дополнительной информацией: например, об общем объёме сделок в течение биржевого дня (Turnover), о средневзвешенной цене по общему объему и количеству сделок (VWAP), а так же более детальной информацией об акции или деривативе – справочные данные, такие как параметры трейдеров, рынка, торговых сессий, инструментов (или Reference Data). Справочные данные (Reference Data или Static Data) представляют собой информацию об инструменте, которая не меняется в режиме реального времени: например, международный идентификационный код ценной бумаги (ISIN), цена сделки при закрытии трейдинговой сессии за предыдущий день (Close Price), валюта, в которой данный финансовый инструмент торгуется на бирже (Currency), параметры так называемых «прерывателей торгов», которые чаще указываются в процентных соотношениях к цене последней сделки (Dynamic or Static Circuit Breaker Tolerances (%)), и так далее[1].

Для предоставления перечисленной выше информации существует ряд стандартных протоколов распространения котировок (например, FIX/FAST [2]), так называемых протоколов распространенния котировок с фиксированной длинной сообщений (например, ITCH [3]), или кодированные протоколы передачи данных (например, HTTPS (HyperText Transfer Protocol Secure) [4] [5]).

Многие электронные биржи распространяют информацию о котировках как через стандартные протоколы, так и через специальные. Трейдеры часто не могут позволить себе дорогостоящую разработку программ, которые бы собирали необходимую им для работы информацию о котировках. Таким образом, возникает необходимость создания систем сбора и агрегации рыночных данных с различных бирж и по различным финансовым протоколам передачи данных.

Page 217: TMPA-2013 Conference Proceedings

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

1.2 Cистема агрегации информации (Ticker Plant) и ее основные функции

Ticker Plant - это система агрегации информации о котировках с различных электронных торговых площадок (или бирж) и её распределения. Данная система предоставляет рыночные данные трейдерам в нормализованном или унифицированном виде [6]. Зачастую Ticker Plant рассчитывает дополнительные параметры на основе предоставленных рыночных данных, то есть обогащает статистическую информацию об акциях и деривативах. Кроме того, для таких систем характерна способность объединять однородные величины распространяемых котировок: ценовые уровни (Price Levels), предоставление котировок согласно запросам клиентов (например, широко распространены такие сервисы, как Level 1, Level 2, Index, T&S, News) в режиме реального времени, а так же хранение переданной рыночной информации.

Указанные выше типы сервисов по предоставлению рыночной информации достаточно распространены в электронной торговле финансовыми инструментами. Рассмотрим каждый из них подробнее:

• Level1 - информация о последних Bid/Ask, OHLC (Open, High, Low, Close), Volume;

• Level2 - информация о Level1 + Order Book (5-10 уровней глубины торговой книжки, Bid/Ask Px&Qty). Level2 может содержать атрибутированные или анонимные заявки), и использовать модели MBO (Market by Order, т.е. индивидуальное отображение всех заявок в пределах отдельно взятого ценового уровня) и MBP (Market by Price, т.е. агрегированное отображение заявок в пределах отдельно взятого ценового уровня). [7];

• Level2 - Total View - более полная информация по сравнению с Level2; • News - последние новости о компании [8]; • Index - данные об индексах [9]. Схематичное представление системы агрегации и распределения

информации о котировках (Ticker Plant) показано на рисунке 1.

Page 218: TMPA-2013 Conference Proceedings

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

Рис. 1. Схема системы Ticker Plant.

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

Исходя из описания системы агрегации и распределения информации о котировках (Ticker Plant) и основных её характеристик, выделенных выше, мы определяем набор требований, которым такая система должна соответствовать. При тестировании такой системы мы будем обращаться к этому набору характеристик. Для того, чтобы было удобно оценивать каждую характеристику, мы распределили их на функциональные и нефункциональные.

Итак, система агрегации и распределения информации о котировках (Ticker Plant) должна решать следующие задачи:

• с функциональной точки зрения: 1. собирать рыночную информацию о котировках из нескольких источников

(поставщиков рыночной информации: бирж, банков); 2. обрабатывать справочные данные (reference data), предоставляемые

биржами; 3. обрабатывать информацию о котировках, предоставляемую по различным

протоколам передачи данных, в режиме реального времени; 4. преобразовывать полученную информацию в один формат; 5. агрегировать данные о котировках согласно различным методам,

описанным выше;

Page 219: TMPA-2013 Conference Proceedings

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

6. обрабатывать эти данные с целью расширить функциональность системы: например, предоставлять статистику (VWAP, Turnover, Trade High/Low, 52 week Trade High/Low);

7. предоставлять данные согласно запросам клиентов: Level1, Level2, T&S, News, Index, Option chains и другое;

8. предоставлять записанную историческую информацию о котировках. • с нефункциональной точки зрения: 1. быструю обработку потоков информации о котировках, поступающей в

режиме реального времени от электронных бирж; 2. быструю обработку запросов, поступающих от клиентов и предоставление

данных о котировках в зависимости от вида запроса клиента (например, отдельно на торгуемый инструмент, или на группу инструментов, или на весь рынок);

3. бесперебойную работоспособность системы; 4. управляемость системой (operability); 5. возможность мониторинга систем (наличие приложений, с помощью

которых можно наблюдать за системой или упралять её компонентами); 6. пропускную способность (throughput); 7. временную задержку (latency); 8. отказоустойчивость (fault tolerance). Определив набор функциональных и нефункциональных характеристик

системы агрегации и распределения информации о котировках (Ticker Plant), нам необходимо понять, как будет проходить процесс тестирования отдельно взятой характеристики. Очевидными становятся два пути тестирования такого рода систем.

Первый - это тестирование с реальными тестовыми площадками (CDS - customer development service [10]). Обычно биржи предоставляют своим клиентам тестовые окружения (test environments), аналогичные реальной электронной трейдинговой платформе. Чаще всего это делается с целью пройти сертификационный процесс или предоставить клиентам возможность для отладки своего клиентского программного обеспечения.

И второй - это тестирование с помощью симуляторов трейдинговых платформ, разработанных на основе данных о бирже, находящихся в публичном доступе.

3 «Тестовая» биржа: описание и основные возможности

“Тестовая” биржа - это своего рода полная копия реальной трейдинговой биржи [11]. Такой аналог трейдинговой биржи должен наиболее полно представлять реальную электронную платформу. Тестовые биржи

Page 220: TMPA-2013 Conference Proceedings

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

предоставляются клиентам, которым необходимо отладить разработанное ими трейдинговое и информационное программное обеспечение [12]. Заявки и сделки в таких тестовых биржах генерируются как следствие взаимодействия самих клиентов, тестирующих собственное программное обеспечение, друг с другом.

В идеале тестовая биржа состоит из тех же компонентов и частей, что и реальная биржевая система[13]. Торговые сессии, основные параметры торгуемых инструментов, правила трейдинга, графические приложения для управления настройками справочных данных (reference data) и т.д - все эти характеристики полностью аналогичны компонентам реальной системы. Поэтому такое тестовое окружение (test environment) позволяет проверять программное обеспечение, заведомо ориентируясь на аналогичные настройки в реальной системе.

Ниже приведена схема тестирования Ticker Plant с применением тестовой биржи.

Рис.2 Тестирование Ticker Plant с помощью тестовой биржи

Page 221: TMPA-2013 Conference Proceedings

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

4 Симулятор рынка ценных бумаг: описание и основные возможности

Симулятор рынка ценных бумаг (или биржевой симулятор) - это интерактивная программа, разработанная для имитации возможностей и свойств реальных моделей рынка[14]. Симулятор рынка должен уметь эмулировать реальные действия, происходящие на бирже: сам трейдинг (размещение заявок, генерацию сделок, изменения статусов инструментов и т.д), симуляцию мониторинга за ходом торгов на рынке и внесение изменений (market operations: отмена/изменение заявок и сделок, остановка торгов, и т.д.), режим работы рынка (переход рынка из одного статуса в другой - открытие рынка (Market Open), аукционы (Opening/Closing/ Periodic Auction Calls), вычисления цен аукционов и публикация цены закрытия, закрытие рынка и т.д. Биржевой симулятор рынка содержит API, аналогичный реальной бирже, с элементами контроля отсылаемых ответов клиенту[15]. Такие симуляторы рынков позволяют иметь более полный контроль над генерируемыми событиями для системы агрегации и распределения информации о котировках (Ticker Plant)[16], таким образом увеличивая покрытие тестирования системы. С помощью симуляторов можно создать необходимую нагрузку, сравнимую с потоками данных, свойственным реальным высоконагруженным биржевым и брокерским системам. Далее представлена схема верификации системы Ticker Plant при помощи симулятора.

Рис.3 Схема тестирования Ticker Plant с применением симулятора

Page 222: TMPA-2013 Conference Proceedings

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

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

Исходя из основных требований к системе Ticker Plant, мы разработали библиотеку сценариев тестирования, которыми можно проверить работоспособность такой системы. В таблице 1 приведены области тестирования системы Ticker Plant и дано их краткое описание. Таблица также показывает оценочную шкалу областей тестирования по приоритетам. Например, если напротив той или иной области указан приоритет 1, это означает, что при возникновении ошибок в этой области тестируемая система Ticker Plant не сможет полноценно выполнять свою основную задачу. Приоритет 3 означает, что при наличии ошибок в этой области, система может выполнять свою основную задачу, но с некоторыми отклонениями.

Табл. 1. Области тестирования Ticker Plant.

Область тестирования

Описание Приоритет

(1 - 3) 1

Техническое подключение к биржам - поток данных о котировках и сделках в режиме реального времени (streaming quotes - real time) UDP (User Datagram Protocol) TCP/IP (Transmission Control Protocol (TCP) и Internet Protocol (IP) HTTPS (HyperText Transfer Protocol Secure)

- возможности подключения к основным каналам (primary channel); - подключение к запасным каналам (secondary channels); - отказоустойчивость (fault tolerance); - тестирование аварийного восстановления данных (disaster recovery)

1

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

Исходя из основных требований к системе Ticker Plant, мы разработали библиотеку сценариев тестирования, которыми можно проверить работоспособность такой системы. В таблице 1 приведены области тестирования системы Ticker Plant и дано их краткое описание. Таблица также показывает оценочную шкалу областей тестирования по приоритетам. Например, если напротив той или иной области указан приоритет 1, это означает, что при возникновении ошибок в этой области тестируемая система Ticker Plant не сможет полноценно выполнять свою основную задачу. Приоритет 3 означает, что при наличии ошибок в этой области, система может выполнять свою основную задачу, но с некоторыми отклонениями.

Табл. 1. Области тестирования Ticker Plant.

Область тестирования

Описание Приоритет

(1 - 3) 1

Техническое подключение к биржам - поток данных о котировках и сделках в режиме реального времени (streaming quotes - real time) UDP (User Datagram Protocol) TCP/IP (Transmission Control Protocol (TCP) и Internet Protocol (IP) HTTPS (HyperText Transfer Protocol Secure)

- возможности подключения к основным каналам (primary channel); - подключение к запасным каналам (secondary channels); - отказоустойчивость (fault tolerance); - тестирование аварийного восстановления данных (disaster recovery)

1

Page 223: TMPA-2013 Conference Proceedings

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

Область тестирования

Описание Приоритет

(1 - 3) 2

Техническое подключение к биржам - каналы восстановления данных (Replay/Recovery channels)

- возможности подключения к основным каналам (primary channel); - подключение к запасным каналам (secondary channels); - отказоустойчивость (fault tolerance); - тестирование аварийного восстановления данных (disaster recovery)

1

3

Тестирование интерфейса протокола от биржи к системе Ticker Plant (real time + replay/recovery)

- проверка административных сообщений, инициируемых Ticker Plant (Administrative messages: Login Request, Replay Request, Snapshot Request, Logout Request); - проверка административных сообщений, инициируемых каналом (Administrative messages): Heartbeat, Login Response, Replay Response, Snapshot Response, Snapshot Complete); - проверка сообщений приложения (Application messages: Time, System Event, Symbol Directory, Symbol Status, Add Order, Add Attributed Order, Order Deleted, Order Modified, Order Book Clear, Order Executed, Order Executed with Price/Size, Trade, Auction Trade, Off-Book Trade, Trade Break, Auction Info, Statistics); - проверка обязательных полей (mandatory tags/values) и значений; - проверка необязательный полей и значений (optional tags/values); - проверка всевозможных вариантов и сочетаний значений тагов (Order Type, TIF и т.д); - проверка негативных значений (неподдерживаемые значения, отрицательные значения, специальные символы, и т.д)

1

4

Восстановление потери небольшого количества данных (Replay channel)

- возможности подключения к основному каналам (primary channel); - подключение к запасным каналу (secondary channels); - проверка последовательности полученных данных;

1

Page 224: TMPA-2013 Conference Proceedings

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

Область тестирования

Описание Приоритет

(1 - 3) - проверка полученных данных на правильность; - проверка объёма буферизации данных

5

Восстановление потери большого количества данных (Recovery channel)

- возможности подключения к основному каналу (primary channel); - подключение к запасным каналам (secondary channels); - проверка последовательности полученных данных; - проверка полученных данных на правильность; - проверка объёма переданных данных

1

6

Проверка справочных данных (Reference Data)

- возможность загрузить данные о финансовых инструментах, предоставляемых биржей; - правильность обработки данных; - использование справочных данных для подсчета различных показателей

1

7

Тестирование поведения системы Ticker Plant при отказе компонентов биржи (Failover при потоке данных с биржи)

- восстановление данных после отказа основного и/или запасного каналов; - возможность переподключения; - правильная последовательность сообщений; - возможность дальнейшей обработки данных после восстановления

1

8

Тестирование при отказе компонентов системы Ticker Plant (Failover при потоке данных из системы Ticker Plant)

- проверка работоспособности компонентов системы Ticker Plant при отказе основного/запасного каналов; - правильная последовательность сообщений; - возможность дальнейшей обработки данных после восстановления

2

9

Тестирование полного трейдингового дня (цикла) работы системы Ticker Plant (DLC – Daily Life Cycle)

- проверка правильной последовательности старта компонентов системы Ticker Plant; - проверка правильной последовательности выключения компонентов системы Ticker Plant

1

Page 225: TMPA-2013 Conference Proceedings

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

Область тестирования

Описание Приоритет

(1 - 3) 10

Тестирование полного трейдингового дня (цикла) на бирже (DLC – Daily Life Cycle)

- правильность последовательности приходящих сообщений в течение дня; - добавление нового инструмента, изменение его параметров, удаление; - изменение статусов инструментов; - переход заявок из одной трейдинговой фазы в другую; - переход заявок из одного дня в другой

1

11

Проверка всевозможных торговых статусов рынка

- проверка на присутствие данных видов статусов внутри системы Ticker Plant: например, Halt, Opening auction call, Pre-mandatory quote period, Continuous trading, End trade reporting, Closing auction call; - проверка обрабатывания переходов из одного статуса инструментов в другое; - проверка правильности обработки сообщений при массовой смене статусов на финансовых инструментах

1

12

Измерение ширины потребляемого канала передачи данных по сети (Bandwidth)

- проводятся нагрузочные тесты для измерения объёма передаваемых данных в единицу времени

1

13

Измерение пропускной способности каналов в единицу времени (Throughput)

- проводятся нагрузочные тесты для подсчёта среднего количества гарантировано доставленных сообщений через каналы передачи данных

1

14

Измерение задержек (латентности (Latency) системы)

- проверка компонентов системы на задержу передачи данных во времени

1

15

Проверка нагрузочной способности системы (Capacity) - нагрузка входным потоком данных

- проверка на работоспособность системы Ticker Plant при большом входном потоке данных

2

16

Проверка нагрузочной способности системы (Capacity) - нагрузка

- проверка на обработку системой Ticker Plant большого количества запросов

2

Page 226: TMPA-2013 Conference Proceedings

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

Область тестирования

Описание Приоритет

(1 - 3) с клиентской стороны системы Ticker Plant

17

Проверка системы Ticker Plant при неправильных запросах клиентов и ответная реакция на них для Replay/Recovery каналов

- попытки подключения клиента (CompID) с недостаточным кличеством прав; - попытки подключения с несуществующим пользователем; - проверки максимального количества подключений; - проверки максимального количества запросов

1

18

Проверка правильности обработки системой Ticker Plant некорректных сообщений от биржи

- отклик на несуществующие сообщения (messages types); - неправильное количество тагов; - неправильный порядок тагов; - неправильная контрольная сумма (checksum)

2

19

Проверка корректности работы системы в целом - от трейдингового клиента до системы Ticker Plant (E2E тестирование)

- добавление заявок; - изменение заявок; - удаление заявок; - добавление агрессивных заявок (приводящих к сделке)

1

20

Сложные сценарии на функциональность самой биржи

- проверка на то, как система обрабатывает очередность событий (например, многоуровневые сделки с айсберг заявками); - вычисления цены аукциона; - поведение Stop /Stop Limit ордеров в зависимости от фазы трейдингого дня; - проверка поведения GTC ордеров в течение нескольких дней

2

21

Реконсиляционное тестирование

- проверка при сравнении потоков, идущих к системе и от системы (детальная проверка на то, что каждое событие, поступившее на вход системы, обработалось и отобразилось на выходном потоке)

1

Page 227: TMPA-2013 Conference Proceedings

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

Область тестирования

Описание Приоритет

(1 - 3) 22

Тестирование MBO (market by order) и MBP (market by price) сервисов

- функциональна проверка сервисов, предоставляемых системой Ticker Plant

1

23

Проверки расчёта индексов

- проверка правильности расчетов индексов в зависимости от потока сделок

2

24

Правильность расчёта статистических данных

- проверка расчёта VWAP, Turnover, Trade High Low, 52 week Trade High Low и т.д.

2

25

Работа с историческими данными

- сбор исторических данных; - сортировка в зависимости от типа данных; - выдача результатов согласно запросам клиентов; - возможность проигрывать записанные исторические данные

2

26

Проверка получения и передачи новостных каналов от бирж

- тестирование новостей (News); - тестирование оповещений клиентов (Announcements)

3

27

Проверка действия биржевого оператора

- отмена сделок; - изменение параметров сделки

2

28

Проверка сложных запросов клиента

- выдача данных для деривативного инструмента (опционные цепочки - option chains) на запрашиваемый базовый инструмент

2

29

Мониторинг системы

- проверка приложений, с помощью которых можно наблюдать за системой или управлять её компонентами

1

Page 228: TMPA-2013 Conference Proceedings

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

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

Для того, чтобы оценить и проанализировать, насколько полно инструметы тестирования покрывают области функциональности системы Ticker Plant, которую необходимо протестировать, нами была разработана специальная методика. Она основывается на переборе сценариев в процентном отношении к всевозможным сценариям, относящимся к той или иной области. Основываясь на опыте тестирования, полученном в компании Exactpro Systems [17], была определена приоритетность областей системы Ticker Plant, обозначенной в правой колонке таблицы 1.

Следующий раздел рассказывает об опыте применения данной методики покрытия тестами для оценки полноты тестирования системы Ticker Plant, как с помощью реальных тестовых площадок, так и с помощью биржевых симуляторов.

6.1 Сравнительная характеристика оценочных данных при тестировании системы агрегации и распределения информации о котировках Ticker Plant с помощью реальной тестовой биржи и симулятора

В таблице 2 приведены сравнительные характеристики, включающие в себя оценочные данные, полученные в ходе тестирования системы Ticker Plant с помощью реальной тестовой биржи и симулятора, а так же детальное объяснение полученных данных.

Табл. 2. Сравнительные характеристики данных для тестовой биржи и симулятора.

Область

тестирования

Покрытие

функциональности при тестировании

с помощью реальной тестовой

биржей (%)

Покрытие

функциональности при тестировании

с помощью симулятора (%)

Детализация оценочных данных

1

Техническое подключение к биржам - поток данных о котировках и торгах в режиме реального времени

100

40

При данной оценке мы исходим из того что симулятор биржи, по своему определению, не способен полноценно воспроизвести все технические детали

Page 229: TMPA-2013 Conference Proceedings

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

Область

тестирования

Покрытие

функциональности при тестировании

с помощью реальной тестовой

биржей (%)

Покрытие

функциональности при тестировании

с помощью симулятора (%)

Детализация оценочных данных

(streaming quotes - real time) UDP (User Datagram Protocol); TCP/IP (Transmission Control Protocol (TCP) и Internet Protocol (IP); HTTPS (Hypertext Transfer Protocol Secure)

соединения с биржей. Мы оцениваем, что если есть стандартная спецификация, то эмулировать шлюз можно примерно на 40%, исходя из набора тестовых сценариев на соединение с биржей

2

Техническое подключение к биржам - каналы восстановления данных (Replay/Recovery channels)

100

40

При данной оценке мы исходим из того, что симулятор не может воспроизвести всех технических деталей соединения с биржей. Мы оцениваем, что если есть стандартная спецификация, то эмулировать шлюз можно примерно с 40% -м покрытием сценариев.

3

Тестирование интерфейса протокола от биржи к системе Ticker Plant (real time + replay/recovery)

100

100

Данная функциональность (тестирование внешнего шлюза) изолирована от биржи, поэтому мы считаем, что использование симулятора и тестовой биржи обеспечивают одинаковое покрытие набора тестовых сценариев.

Page 230: TMPA-2013 Conference Proceedings

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

Область

тестирования

Покрытие

функциональности при тестировании

с помощью реальной тестовой

биржей (%)

Покрытие

функциональности при тестировании

с помощью симулятора (%)

Детализация оценочных данных

4

Восстановление потери небольшого количества данных (Replay channel)

100

100

Данная функциональность (тестирование внешнего шлюза) изолирована от биржи, поэтому мы считаем, что использование симулятора и тестовой биржи обеспечивают одинаковое покрытие набора тестовых сценариев.

5

Восстановление потери большого количества данных (Recovery channel)

75

100

Несмотря на то, что данная функциональность изолирована от биржи, ee проверка требует значительного потока кортировок с биржи. Исходя из нашего опыта, такое возможно не всегда с тестовой биржей, и есть ряд значительных ограничений. Поток данных с тестовых плошадок обычно соответствует ожиданиям, однако его практически невозможно контролировать, чего не скажешь о симуляторе, контроль над которым находится в руках

Page 231: TMPA-2013 Conference Proceedings

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

Область

тестирования

Покрытие

функциональности при тестировании

с помощью реальной тестовой

биржей (%)

Покрытие

функциональности при тестировании

с помощью симулятора (%)

Детализация оценочных данных

тестировщиков. 6

Проверка справочных данных (Reference Data)

100

5

Данное тестирование сосредоточено на верификации настроек системы, настроек финансовых инструментов и т.д. Необходимо тестировать в связке с реальными рынками.

7

Тестирование поведения системы Ticker Plant при отказе компонентов биржи (Failover при потоке данных с биржи)

100

10

Тестирование с симулятором в данном случае возможно, но значительная часть тестов проверяет соединение между Ticker Plant и биржами. При данной оценке мы исходим из того, что симулятор не может воспроизвести всех технических деталей соединения с биржей. При наличии стандартной спецификации, эмулирование шлюза возможно с 40% -м покрытием сценариев.

8

Тестирование при отказе компонентов системы Ticker Plant (Failover при потоке данных из системы Ticker

100

40

Возможно тестирование с симулятором, но значительная часть тестов верифицирует соединение между Ticker Plant и рынками. При

Page 232: TMPA-2013 Conference Proceedings

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

Область

тестирования

Покрытие

функциональности при тестировании

с помощью реальной тестовой

биржей (%)

Покрытие

функциональности при тестировании

с помощью симулятора (%)

Детализация оценочных данных

Plant)

данной оценке мы исходим из того, что симулятор априори не может воспроизвести всех технических деталей соединения с биржей. Мы оцениваем, что если есть стандартная спецификация, то эмулировать шлюз можно примерно с 40% -м покрытием.

9

Тестирование полного трейдингового дня (цикла) работы системы Ticker Plant (DLC – Daily Life Cycle)

40

100

Всвязи с большими ограничениями в управлении торговым днем на тестовых площадках, симулятор предоставляет больше возможностей при воспроизведении подобных сценариев тестирования.

10

Тестирование полного трейдингового дня (цикла) на бирже (DLC – Daily Life Cycle)

100

40

Не смотря на то, что предыдущее обоснование применимо и в данном случае, в даном сценарии больший вес имеет понятие того, что входящие сообщения создаются при помощи тестового рынка, согласно настройкам справочных данных (Reference Data) самой биржи. При данной оценке мы

Page 233: TMPA-2013 Conference Proceedings

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

Область

тестирования

Покрытие

функциональности при тестировании

с помощью реальной тестовой

биржей (%)

Покрытие

функциональности при тестировании

с помощью симулятора (%)

Детализация оценочных данных

исходим из того, что симулятор априори не может воспроизвести всех технических деталей соединения с полного трейдингового дня (цикла) работы системы (DLC). Поэтому оценка покрытия составляет лишь 40%.

11

Проверка всевозможных торговых статусов рынка

50

100

В связи с ограничениями в управлении торговым днем на тестовых площадках, симулятор предоставляет больше возможностей при воспроизведении подобных сценариев.

12

Измерение ширины потребляемого канала передачи данных по сети (Bandwidth)

75

100

Тестирование с симулятором возможно; для тестовых площадок имеется значительная зависимость от аппаратных средств и настроек их производительности. В данном случае симулятор имеет преимущество.

13

Измерение пропускной способности каналов в единицу времени

75

100

Тестирование с симулятором возможно; для тестовых площадок имеется значительная

Page 234: TMPA-2013 Conference Proceedings

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

Область

тестирования

Покрытие

функциональности при тестировании

с помощью реальной тестовой

биржей (%)

Покрытие

функциональности при тестировании

с помощью симулятора (%)

Детализация оценочных данных

(Throughput)

зависимость от аппаратных средств и настроек их производительности. В данном случае симулятор имеет преимущество.

14

Измерение задержек (латентности (Latency) системы)

75

100

Тестирование с симулятором возможно; для тестовых площадок имеется значительная зависимость от аппаратных средств и настроек их производительности. В данном случае симулятор имеет преимущество.

15

Проверка нагрузочной способности системы (Capacity) - нагрузка входным потоком данных

75

100

Тестирование с симулятором возможно; для тестовых площадок имеется значительная зависимость от аппаратных средств и настроек их производительности. В данном случае симулятор имеет преимущество.

16

Проверка нагрузочной способности системы (Capacity) - нагрузка с клиентской стороны системы Ticker Plant

75

100

Тестирование с симулятором возможно; для тестовых площадок имеется значительная зависимость от аппаратных средств и настроек их производительности. В данном случае симулятор имеет

Page 235: TMPA-2013 Conference Proceedings

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

Область

тестирования

Покрытие

функциональности при тестировании

с помощью реальной тестовой

биржей (%)

Покрытие

функциональности при тестировании

с помощью симулятора (%)

Детализация оценочных данных

преимущество. 17

Проверка системы Ticker Plant при неправильных запросах клиентов и ответная реакция на них для Replay/Recovery каналов

100

100

Данная функциональность (тестирование внешнего шлюза) изолирована от биржи, поэтому мы считаем, что использование симулятора и тестовой биржи обеспечивают одинаковое покрытие.

18

Проверка правильности обработки системой Ticker Plant некорректных сообщений от биржи

25

100

В данном случае симулятор может отправлять на вход Ticker Plant достаточно гибкий набор негативных сценариев тестирования, что обеспечивает большее покрытие. Однако, с другой стороны, абсолютное число сценариев, с технической точки зрения, имея при этом только спецификацию биржи, невозможно воспроизвести.

19

Проверка корректности работы системы в целом - от трейдингового клиента до системы Ticker Plant (E2E тестирование)

90

85

Данное тестирование представляет собой набор всех трейдинговых сценариев тестирования. Это можно обеспечить как симулятором, так и тестовой площадкой. Поэтому

Page 236: TMPA-2013 Conference Proceedings

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

Область

тестирования

Покрытие

функциональности при тестировании

с помощью реальной тестовой

биржей (%)

Покрытие

функциональности при тестировании

с помощью симулятора (%)

Детализация оценочных данных

оценочная характеристика примерно одинаковая.

20

Сложные сценарии на функциональность самой биржи

50

100

Оба подхода предостовляют равные возможности при эмуляции сложных сценариев. Поскольку симулятор подконтролен тестировщикам, он дает больше возможностей при эмуляции по настоящему нетривиальных событий.

21

Реконсиляционное тестирование

100

50

В данном тесте происходит сравнение потока данных из биржи и из Ticker Plant. Тестирование с реальной тестовой площадкой предпочтитетельнее и является более правильным, поскольку она по умолчанию является независимым источником котировок.

22

Тестирование MBO (market by order) и MBP (market by price) сервисов

100

100

Данная функциональность (тестирование внешнего шлюза) изолирована от биржи, поэтому мы считаем, что использование

Page 237: TMPA-2013 Conference Proceedings

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

Область

тестирования

Покрытие

функциональности при тестировании

с помощью реальной тестовой

биржей (%)

Покрытие

функциональности при тестировании

с помощью симулятора (%)

Детализация оценочных данных

симулятора и тестовой биржи обеспечивают одинаковое покрытие.

23

Проверки расчета индексов

50

100

Данная функциональность должна проверятся при полном контроле над рынком. Симулятор имеет явное приемущество, с чем и связана такая оценка покрытия.

24

Правильность расчёта статистических данных

50

100

Данная функциональность должна проверятся при полном контроле над рынком. Симулятор имеет явное приемущество, с чем и связана такая оценка покрытия.

25

Работа с историческими данными

50

100

Необходима эмуляция искуственных исторических событий. Для повторяемости тестов необходим симулятор, а не тестовая площадка, на события в которой также могут влиять и другие её пользователи.

26

Проверка получения и передачи новостных каналов от бирж

50

100

В этом тесте необходима эмуляция искуственных новостей. Для повторяемости тестов и полного

Page 238: TMPA-2013 Conference Proceedings

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

Область

тестирования

Покрытие

функциональности при тестировании

с помощью реальной тестовой

биржей (%)

Покрытие

функциональности при тестировании

с помощью симулятора (%)

Детализация оценочных данных

контроля необходим симулятор.

27

Проверка действия биржевого оператора

100

30

Системы для управления рынками должны проверяться в связке с реальными системами, на которых будет впоследствии работать система. Приемущество у тестовой площадки.

28

Проверка сложных запросов клиента

100

100

Данная функциональность (тестирование внешнего шлюза) изолирована от биржи, поэтому мы считаем, что использование симулятора и тестовой биржи обеспечивают одинаковое покрытие.

29

Мониторинг системы

100

30

Системы для управления рынками должны проверяться в связке с реальными системами, с которыми будет впоследствии работать система. Преимущество у тестовой площадки.

Может сложится ощущение, что полное покрытие тестирования системы Ticker Plant возможно исключительно с использованием симуляторов (как видно из таблицы 2). Однако в реальности это не так. Основное препятствие состоит в том, что эмулировать торговую площадку со 100%-й точностью - невозможно. В особенности это касается непосредственного взаимодействия между Ticker

Page 239: TMPA-2013 Conference Proceedings

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

Plant системой и различными рынками. Причина этого в том, что любая спецификация о протоколе соединения с биржей содержит ограниченное описание поведения при различных ситуациях, поэтому даже если симулятор воспроизведет 100% спецификации с точностью до нюансов, всё равно останутся элементы, сделанные «на усмотрение» создателей симулятора. Для наглядности приведем пример. Предположим, на бирже происходит сделка, и биржа рассылает клиентам два события: первое событие содержит обьем и цену сделки; второе событие содержит изменение HIGH, LOW параметров цены на данном финансовом инструменте. Если какой-либо алгоритм при расчете индекса использует и первое, и второе события, то вполне вероятно, что для дальнейшей работы такого алгоритма будет важно, в каком порядке описанные выше события приходят. Маловероятно, что спецификация торговой площадки будет содержать требования к порядку сообщений и событий. Более того, - раз этого требования нет в спецификации, биржа может легко поменять этот порядок. Таким образом, у нас есть пример сценария, который невозможно симулировать точно. Всвязи с этим, существенный обьем тестирования должен осуществляться на тестовой площадке, которая наиболее близко соответствует поведению реального рынка. Данное заключение так же дано, опираясь на опыт в тестировании Ticker Plant систем.

Более наглядно сравнительный анализ покрытия тестами при помощи различных инструментов тестирования выглядит на рисунке 4.

Рис. 4. Сравнительный анализ покрытия тестами при помощи тестовой биржи и симулятора

Page 240: TMPA-2013 Conference Proceedings

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

Анализ данных, приведенных в таблице 2 и на рисунке 4, показывает, что

тестирование с помощью симуляторов и реальных тестовых бирж (в разумный временной период) имеет свои плюсы и минусы. В целом, мы имеем приблизительно одинаковые показатели по оценочной методике.

Общая формула покрытия всех функциональностей соответствующим

инструментом тестирования: Summ(CovN*(1/PriorN))/Summ(1/PriorN) . (1)

где Summ - сумма (Табл. 2), CovN* - относительное покрытие данной функциональности соответствующим инструментом тестирования (Табл. 2), PriorN - приоритет данной функциональности (Табл. 1).

Итоговый результат: тестирование при помощи симуляторов обеспечивает 76% покрытия; тестирование при помощи тестовой площадки - 83%.

7 Заключение

В данной статье приводится описание системы агрегации и распределения информации о котировках (Ticker Plant), перечислены его основные характеристики, составлена справочная библиотека скриптов для тестирования, максимально покрывающих функциональность обобщенной системы Ticker Plant. Также в статье даны определения биржевого симулятора и реальной тестовой биржи. При помощи разработанной методики оценки покрытия сценариями для тестирования системы агрегации и распределения информации о котировках (Ticker Plant) были проанализированы и обработаны два возможных пути тестирования: при помощи реальной тестовой биржи и симуляторов бирж. На основе двух сводных таблиц было выведено заключение о преимуществах тестирования как с реальной тестовой биржей, так и с биржевым симулятором.

Литература

1. Официальный сайт B2Bits <epam>. // [Электронный ресурс]. – Режим доступа http://www.b2bits.com/trading_solutions/market-data-solutions.html

2. Официальный сайт FIXprotocol. // [Электронный ресурс]. – Режим доступа http://www.fixprotocol.org/

3. Документация о Level1 Market Data / Официальный сайт Лондонской Фондовой Биржи – London Stock Exchange // [Электронный ресурс]. – Режим доступа

Page 241: TMPA-2013 Conference Proceedings

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

http://www.londonstockexchange.com/products-and-services/millennium-exchange/millennium-exchange-migration/mit303.pdf

4. P. Karlton, P. Kocher.: The Secure Sockets Layer (SSL) Protocol Version 3.0 // [Электронный ресурс]. – Режим доступа http://tools.ietf.org/html/rfc6101

5. Официальный сайт FTSE. // [Электронный ресурс]. – Режим доступа http://www.ftse.com/Indices/Data_Licenses/Real-time_Constituent_Data.jsp

6. Официальный сайт B2Bits <epam>. // [Электронный ресурс]. – Режим доступа http://www.b2bits.com/trading_solutions/market-data-solutions.html

7. Building the Book: A Full-Hardware Nasdaq Itch Ticker Plant on Solarflare’s AoE FPGA Board / Sherman,M., Sood,P., Wong,K., Iakovlev,A., Parashar,N. // [Электронный ресурс]. – Режим доступа http://www.cs.columbia.edu/~sedwards/classes/2013/4840/reports/Itch.pdf

8. Официальный сайт Tokyo Stock Exchange // [Электронный ресурс]. – Режим доступа http://www.tse.or.jp/english/market/mkinfo/mains.html

9. Day Trading. / Официальный сайт About.com // [Электронный ресурс]. – Режим доступа http://daytrading.about.com/od/daytradingmarketdata/a/MarketDataDefin.htm

10. Customer Development Service (CDS). / Официальный сайт Лондонской Фондовой Биржи – London Stock Exchange // [Электронный ресурс]. – Режим доступа http://www.londonstockexchange.com/products-and-services/technical-library/customer/customerdevelopmentservice/customerdevelopmentservice.htm

11. Trading Floor Architecture / Официальный сайт Cisco // [Электронный ресурс]. – Режим доступа http://www.cisco.com/en/US/docs/solutions/Verticals/Trading_Floor_Architecture-E.html

12. Официальный сайт BSE India // [Электронный ресурс]. – Режим доступа http://www.bseindia.com/markets/MarketInfo/DispNoticesNCirculars.aspx?page=20120531-22&pagecont=0,31/05/2012,31/05/2012,,All,All,All,Scrip%20Name%20/%20Code

13. Официальный сайт ММВБ // [Электронный ресурс]. – Режим доступа http://rts.micex.ru/s437

14. Статья К.В.Воронцов (ВЦ РАН), С.Б. Пшеничников (ММВБ): Имитационное моделирование торгов: новая технология биржевых тренажеров. / Журнал «Индикатор», 2 (42). М. 2002 год // [Электронный ресурс]. – Режим доступа http://www.forecsys.com/site/about/press/exchange_simulator/

15. Официальный сайт Oslo Bors Stock Exchange. // [Электронный ресурс]. – Режим доступа http://www.oslobors.no/ob_eng/Oslo-Boers/Trading/Delta/Millennium-Exchange/Guide-to-Testing-Services-updated-issue

16. Zverev,A., Bulda,A.: Exchange Simulators for SOR. Algo Testing: Advantages vs. Shortcomings. / Конференция ExTENT // [Электронный ресурс]. – Режим доступа http://www.slideshare.net/extentconf/exchsims-forsoralgotestingadvantagesvsshortcomings29102011111113011104phpapp02

17. Официальный сайт Exactpro Systems. // [Электронный ресурс]. – Режим доступа http://www.exactprosystems.com/

Page 242: TMPA-2013 Conference Proceedings

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

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

Дмитрий Гурьев1, Мария Гай1, Иосиф Иткин2, Александр Терентьев3

1 ООО «Инновационные Трейдинговые Системы», Россия, 115088, г. Москва, 2-й

Южнопортовый проезд, 20А/4 [email protected], [email protected]

2 Exactpro Systems LLC, 4040 Civic Center Drive, Suite 200, San Rafael, CA 94903, USA [email protected]

3 Саратовский государственный технический университет имени Гагарина Ю.А., Россия, 410054, Саратов, ул. Политехническая, 77

[email protected]

Aннотация. В связи с существенным ростом числа торговых заявок, вызванным развитием высокочастотной торговли, ставится задача тестирования биржевых и брокерских систем в режимах, приближенных к реальным. Для обеспечения качества высоконагруженных трейдинговых систем высокой доступности применяются специализированные инструменты тестирования. Основные требования к таким инструментам - это способность создавать высокие реалистичные нагрузки, используя ограниченную аппаратную базу. В данной статье описывается разработанный генератор нагрузки для тестирования систем автоматизированной торговли. Представлен подход, обеспечивающий высокую производительность.

Ключевые слова: нагрузочное тестирование, высокочастотная торговля (HFT), инструменты для тестирования.

1 Введение Высокочастотная электронная торговля финансовыми инструментами (HFT), позволяющая минимизировать временные задержки при совершении сделок, выросла в последние годы и составляет в настоящее время около 30% от всего объёма торговли акциями в Великобритании и, возможно, более 60% от всего объёма торговли акциями в США [1]. В результате этого брокерские и биржевые системы испытывают всё большую нагрузку от потока транзакций, генерируемого системами автоматизированной торговли. Операторы трейдинговых платформ, регулирующие органы и участники торгов должны быть уверены в надёжности программного обеспечения и инфраструктуры торговых площадок [2] в условиях постоянно растущих нагрузок.

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

Page 243: TMPA-2013 Conference Proceedings

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

элементов системы применяют методы нагрузочного тестирования. Под нагрузочным тестированием понимается процесс отправки системе большого количества запросов, проверка своевременности и корректности полученных от неё откликов, а также проверка внутреннего состояния системы.

В настоящее время для нагрузочного тестирования программного обеспечения широко используются различные коммерческие и свободно распространяемые генераторы нагрузки. В качестве примера можно привести следующие продукты: Apache JMeter, HP Load Runner, IBM Rational Performance Tester, Borland Silk Performer и другие [3-6]. Основной концепцией, используемой в этих продуктах, является создание множества виртуальных пользователей, эмулирующих поведение реальных пользователей для моделирования условий, при которых программа/система будет функционировать в реальности. При имитации и поддержке соединения с большим количеством пользователей и высокой нагрузке у инструментов тестирования могут возникать ограничения производительности, разобранные во второй части данной статьи.

В компании Exactpro Systems LLC разработан инструмент для тестирования высоконагруженных трейдинговых систем, обладающий необходимой производительностью и использованный на практике при проверке некоторых из крупнейших биржевых технологических инфраструктур в Западной Европе [7; 8]. Разработанный инструмент поддерживает протоколы: FIX (все версии), ITCH, LSE Native, SOLA SAIL & HSVF, HTTP, SOAP, а также различные бинарные протоколы трейдинговых систем. Многопротокольность является одной из архитектурных особенностей разработанного инструмента для тестирования, вследствие чего добавление новых протоколов и новых версий уже поддерживаемых протоколов представляет собой относительно малозатратную задачу. В третьей части статьи рассмотрены особенности подготовки данных для нагрузочного тестирования. В четвёртой части представлены возможности по настройке инструмента, включая задание профиля нагрузки.

2 Оптимизация процесса создания нагрузки

Общее представление о процессе создания нагрузки даётся в ряде работ, в частности в [9]. Генераторы нагрузки делят на основанные на измерениях (measurement-based) и основанные на моделях (model-based) [10]. Основанные на измерениях генераторы удобны для нахождения пропускной способности тестируемой системы и построения зависимостей времён отклика от нагрузки. Генераторы нагрузки, основанные на моделях, направлены на симуляцию распределения входных данных, максимально приближенную к реальному промышленному использованию системы. В разработанном авторами высокопроизводительном генераторе нагрузки поддерживаются оба описанных варианта. Данные модели используются при создании конфигурационных файлов перед запуском генератора. Таким образом, инструмент может не

Page 244: TMPA-2013 Conference Proceedings

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

тратить ресурсы на обработку информации, относящейся к модели непосредственно во время выполнения тестов.

Генераторы нагрузки подразделяются на работающие по принципам закрытого цикла (closed-cycle) и открытого цикла (open-cycle) [11]. После посылки сообщения исполняемый поток в генераторе закрытого типа дожидается ответа от системы, прежде чем приступить к посылке следующих запросов. Генератор открытого цикла продолжает посылку сообщений не дожидаясь ответа от тестируемой системы. Большинство инструментов для тестирования веб-приложений являются генераторами закрытого цикла. Это связано с использованием концепции виртуальных пользователей, каждый из которых последовательно выполняет шаги определённого сценария. Генератор закрытого цикла требует существенно большего количества потоков исполнения и переключений между ними в сравнении с генератором открытого цикла. В генераторах закрытого цикла часто обработка исходящих из системы ответов происходит в том же потоке, что и посылка входящих сообщений, дополнительно снижая производительность инструмента и иногда даже влияя на его аккуратность. Таким образом, генераторы открытого цикла требуют меньшей аппаратной базы для создания требуемого уровня нагрузки. Они также не требуют порождения лишних потоков и их синронизации для производства фиксированного уровня нагрузки. Представленный в статье инструмент работает как генератор открытого цикла.

При разработке инструмента для нагрузочного тестирования рассматривался вопрос о необходимости привязки исполняемых потоков к ядрам процессора для сглаживания распределения входящих в систему сообщений по времени [12]. Авторы пришли к выводу, что миллисекундное разрешение системных таймеров, присутствующее в большинстве современных Linux-системах, достаточно для создания реалистичной трейдинговой нагрузки, а отсутствие привязки к ядрам процессора освобождает некоторое дополнительное количество аппаратных ресурсов на генераторе нагрузки, позволяя централизованно запускать оптимальное количество потоков. Разработанный инструмент использует центральный контроллер, позволяя заранее задать в конфигурации количество и состав протокольных соединений, которые будут работать в каждом потоке. Наличие центрального контроллера также позволяет выдавать команду на выполнение скоординированных действий всеми потоками. Например, одновременный старт потока сообщений или одновременное отключение установленных соединений.

При тестировании трейдинговой системы генератор нагрузки заменяет большое количество систем автоматизированной торговли, использующих множество серверов. Однако аппаратная база, доступная для размещения инструментов тестирования, всегда ограничена соображениями экономии [13]. В условиях продолжающейся финансовой нестабильности даже крупнейшие финансовые институты работают в режиме максимально возможной оптимизации затрат. Требуется существенно облегчить процесс создания исходящих сообщений. Для оптимизации процесса создания нагрузки необходимо до выполнения теста заготовить шаблоны сообщений, сократив процессорное время на серверах, содержащих инструменты для тестирования. Сходные соображения заложены в генератор нагрузки, созданный

Page 245: TMPA-2013 Conference Proceedings

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

разработчиками крупнейшего российского поисковика «Яндекс». Инструмент для тестирования с открытым кодом «Яндекс.Танк» предназначен для генерации огромных объёмов сообщений по протоколу HTTP [14]. Высокая производительность «Яндекс.Танк» достигается концентрацией нагрузки в одной сессии и одном потоке, а также использованием заготовленного файла со статическими запросами. Генераторы нагрузки для трейдинговых систем не могут использовать статические данные и обладают рядом других ограничений, рассматриваемых в следующей части.

3 Особенности нагрузочного тестирования торговых систем

В [15] разобраны основные требования к моделированию нагрузки для систем высокочастотной торговли. Логика работы таких систем существенно затрудняет использование статичных, ранее записанных или предопределенных данных. В этой секции рассматриваются некоторые из особенностей создания нагрузки и подготовки входных данных для тестирования трейдинговых систем.

3.1. Создание сообщений из шаблонов

Вследствие того, что торговля не анонимна, для поддержания сессии сервер должен получать имена существующих пользователей, корректные порядковые номера сообщений, а также время отправки каждого сообщения. Наш анализ показал, что построение сообщений непосредственно перед отправкой с использованием словарей обходится очень дорого с точки зрения используемых системных ресурсов. Поэтому было решено использовать заготовки, в которых порядок полей и набор ключевых значений заданы до начала теста. Например, в FIX-сообщении NewOrderSingle перед моментом отправки будут изменяться всего несколько параметров, которые должны быть уникальны (например, ClOrdID(11) – номер клиентской заявки) и зависеть от текущего времени (ExpireTime(126) – время истечения срока заявки, ExpireDate(432) – день истечения срока заявки). Остальные параметры новой заявки не изменяются. Для поддержания сессии изменяются служебные параметры: BodyLength(9) – длина сообщения; SenderCompID(49) – название компании, которая отправила заявку; TargetCompID(56) – название компании, которой была отправлена заявка; MsgSeqNum(34) – уникальный номер сообщения; SendingTime(52) – текущее время; CheckSum(10) – проверочное число.

В сообщения OrderCancelReplaceRequest и OrderCancelRequest подставляются все необходимые параметры, взятые из сообщения NewOrderSingle, такие как: OrderID(37) – идентификатор заявки; Price(44) – цена заявки; Quantity(53) – размер заявки; Side(54) – сторона заявки (покупка или продажа); Symbol(55) – символическое обозначение инструмента.

Page 246: TMPA-2013 Conference Proceedings

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

Предположение, что все значения параметров верны, даёт возможность существенной экономии времени на проверку значений полей и правильности их последовательности в сообщении.

3.2. Воспроизведение ранее записанных данных

Отправка заранее подготовленных записанных данных приводит к искажению теста. При построении данных для тестирования необходимо придерживаться той же пропорции торговых событий, которую мы наблюдаем в реальной жизни. Анализ реальных торгов показывает, что на одну сделку может приходиться более 20 изменений заявок.

Записанные данные представляют собой совокупность новых заявок, их изменения и отмены. Так как заявки отправляются из разных потоков на одну и ту же книгу заявок, они могут приходить на рынок в порядке, отличном от того, каким он был при записи. Даже если время появления заявки на рынке будет отличаться незначительно, это может привести к нежелательным последствиям. Например, к моменту получения рынком заявки, другие заявки могут располагаться в книге заявок в порядке, отличном от того, который был при записи, и они могут проторговаться в другой последовательности. Из этого следует, что последующие изменения или отмена заявки будут невозможны, так как заявка проторговалась и была удалена из книги заявок. Такая ситуация влечёт за собой сбой в последовательности сценария тестирования, и в дальнейшем будет получен сценарий, отличный от записанного. Таким образом, на рынке будут происходить события, отличные от тех, что были при записи сценария. Например, рынок будет отправлять значительно больше отказов на изменение или отмену заявок. При этом отличия от первоначального сценария могут накапливаться, и реальная пропорция торговых событий может сильно отличаться от исходной.

3.3. Использование детерминированных сценариев

Другая возможность организовать тест заключается в подготовке двух групп заявок: к первой группе относятся заявки, о которых заранее известно, что они будут участвовать в сделках (активные заявки); вторая группа состоит из заявок, которые не должны торговаться (пассивные заявки). Однако в этом случае следует учитывать возможные осложнения со стороны системы мониторинга и контроля рынков (англ. Market Surveillance System). Одна из функций этого компонента заключается в том, что он должен в режиме реального времени отслеживать «договорные» заявки, т.е. как раз те заявки, которые должны проторговаться при проведении тестирования, и сообщать о таких событиях службе, следящей за манипулированием ценами на рынке. Очевидно, что такой вариант не подходит для создания сценария тестирования. В связи с этим, нашими специалистами был создан рандомизированный генератор нагрузки с использованием механизма обратной связи. Рандомизация используется для генерации новой цены при отправке изменения заявки. Для генерации используются три параметра: начальная цена, диапазон изменения цены и шаг изменения цены.

Page 247: TMPA-2013 Conference Proceedings

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

Начальная цена задается в массиве данных для каждого инструмента и для каждой стороны (покупки или продажи). Начальные цены должны удовлетворять следующим условиям: - цена покупки должна быть меньше цены продажи; - разница начальных цен продажи и покупки должна составлять около 2-3% от цены открытия рынка.

Диапазон изменения цены покупки и продажи выбирается таким образом, чтобы цены встречных предложений пересекались, обеспечивая торговлю, и чтобы цены предложений не выходили за 10%-й барьер - условие, при несоблюдении которого возможна остановка торговли на данном инструменте или на целом сегменте инструментов. Эти параметры позволяют гибко подбирать желаемое среднее соотношение количества сделок к количеству изменений, приходящихся в среднем на одну заявку. Чем меньше область пересечения цен покупки и продажи, тем меньше будет сделок, и заявка в среднем будет изменяться большее количество раз. Надо заметить, что это отношение нелинейно зависит от интервала пересечения цен. Поскольку цены задаются для каждого инструмента в отдельности, становится возможным настроить разное количество сделок на разных инструментах в одном тесте.

Шаг изменения цены задаётся исходя из конфигурации инструмента. Например, одни инструменты могут торговаться с шагом цены 0,05, другие - с шагом цены 0,10.

Механизм обратной связи необходим, чтобы отслеживать состояние заявки на рынке и обеспечивать возможность изменения или отмены заявки. Заявка может иметь следующие состояния: New – заявка еще не приняла участие в торговле; PartFilled – заявка выполнена частично; Filled – заявка выполнена полностью; Canceled – заявка отменена клиентом; Expired – заявка с истекшим сроком действия; Rejected – заявка отклонена биржей.

Только заявки в состояниях «New» и «PartFilled» могут участвовать в торговле. Как только заявка переходит в другое состояние, она перестает быть интересной, и информация о ней тут же удаляется.

4 Пример настройки разработанного генератора нагрузки

В этой части статьи подробнее остановимся на нескольких вариантах настройки разработанного авторами генератора нагрузки для тестирования трейдинговых систем на основе протокола FIX [16].

Настройка теста осуществляется посредством 4-х типов конфигурационных файлов, которые содержат:

настройку параметров нагрузки; конфигурацию сессий; заготовку сообщений; распределение по сообщениям.

Page 248: TMPA-2013 Conference Proceedings

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

4.1. Формат файла параметров нагрузки

Для настройки параметров нагрузки используется файл, имеющий следующий формат: #Конфигурационный файл с настройками сессий: CONNECTIONS_CONFIG = fixConnections.cfg #Указание используемых сессий из файла с сессиями: CONNECTIONS_RANGE = 1-3, 5, 7- #Файл с заготовками сообщений: MESSAGE_TEMPLATES = fixMessageTemplates.dat #Файл с распределением по сообщениям: MESSAGE_RATES = messageRates.cfg #Последовательность действий до начала теста: INIT_CONFIG = connect(100ms), logon(3s) #Конфигурация нагрузки: LOAD_CONFIG = const(1000,5m) #Задается постоянная нагрузка 1000 сообщений в секунду #на протяжении 5-и минут. #Количество повторений нагрузочного сценария, заданного #параметром LOAD_CONFIG: NUMBER_REPETITIONS = 10 #Последовательность действий после окончания теста: SHUTDOWN_CONFIG = logout(1s), disconnect(10ms) #Последовательность действий при внезапном обрыве #соединения ON_RECONNECT_CONFIG = connect(10ms), logon(3s) #Флаг на выполнение действий, указанных в #ON_RECONNECT_CONFIG при обрыве соединения: HOLD_CONNECTION = 1 #Если значение = 0, действия в ON_RECONNECT_CONFIG не #выполняются, и соединение не восстанавливается. #Время задержки между авторизацией сессий в миллисекундах LOGON_INTERVAL = 1000

Поскольку у клиентов есть возможность использовать собственные программы для торговли, существует вероятность того, что по какой-то причине, например, в случае отправки торговой системой большого объёма сообщений, клиентские программы не смогут вовремя прочитать эти данные. Это может негативным образом повлиять на поведение торговой системы. Для тестирования этой возможности в разработанном программном продукте существует специальное ограничение по количеству читаемых данных в секунду для эмуляции медленных клиентов.

4.2. Формат файла конфигурации сессий

Настройки параметров соединений задаются в файле следующего формата: В секции COMMON задаются общие параметры соединений: [COMMON] HOST = 10.10.10.10 PORT = 5555 TARGET_COMP_ID = FGW В секции [FIX] задаются уникальные параметры отдельного соединения: [FIX] SENDER_COMP_ID = LOAD_1 RESET_SEQ_NUM_AFTER_LOGOUT = 0

Page 249: TMPA-2013 Conference Proceedings

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

PARTY_ID = LOAD_1 Секция [FIX] должна повторяться столько раз, сколько предполагается

использовать соединений. При этом соединения, которым предстоит участвовать в тесте, задаются параметром CONNECTIONS_RANGE в файле с параметрами нагрузки.

4.3. Формат файла заготовок сообщений

Файл содержит массив именованных сообщений-заготовок. Эти заготовки имеют правильные формат и последовательность полей в сообщениях. Некоторые поля будут заменяться корректными данными непосредственно перед отправкой сообщения. Logon 8=FIXT.1.1|9=61|35=A|34=1|49=SenderCompID|56=TargetCompID|98=0|108=3600|554=password|1137=9|10=135|EOM NewOrderBuy 8=FIXT.1.1|9=199|35=D|34=1|49=SenderCompID|56=TargetCompID|1=CLIENT|11=ClOrdID|38=200|40=2|44=9.8|54=1|55=Symbol|59=6|60=20130728-13:34:03.194|432=20130730|528=P|581=3|1138=60000|9303=I|453=1|448=PartyID|447=D|452=76|10=047|EOM NewOrderSell 8=FIXT.1.1|9=199|35=D|34=1|49=SenderCompID|56=TargetCompID|1=CLIENT|11=ClOrdID|38=150|40=2|44=10.2|54=2|55=Symbol|59=6|60=20130728-13:34:03.194|432=20130730|528=P|581=3|1138=60000|9303=I|453=1|448=PartyID|447=D|452=76|10=047|EOM Cancel 8=FIXT.1.1|9=134|35=F|34=1|49=SenderCompID|56=TargetCompID|11=ClOrdID|41=OrigClOrdID|54=1|55=Symbol|60=20130728-13:34:03.178|9303=I|453=1|448=PartyID|447=D|452=76|10=050|EOM Replace 8=FIXT.1.1|9=179|35=G|34=1|49=SenderCompID|56=TargetCompID|1=CLIENT|11=ClOrdID|38=180|40=2|41=OrigClOrdID|54=1|55=Symbol|60=20130728-13:34:03.178|432=20130730|1138=70000|9303=I|453=1|448=PartyID|447=D|452=76|10=077|EOM Logout 8=FIXT.1.1|9=29|35=5|34=111|49=SenderCompID|56=TargetCompID|10=249|EOM

4.4. Формат файла распределения нагрузки по сообщениям Файл содержит соотношение количества сообщений, указанных в долях для каждого типа сообщения: NewOrderBuy = 15 Replace = 50 Cancel = 5

В зависимости от настройки, MESSAGE_SELECTION_ORDER = sequential или random, сообщения будут выбираться или последовательно, или случайным образом.

4.5. Упрощенная схема работы алгоритма

На рисунке 1 приведена блок-схема алгоритма по выбору и отправке сообщений. На первом этапе происходит чтение входящих данных. В случае, если данные есть, происходит анализ полученных ответов и изменение

Page 250: TMPA-2013 Conference Proceedings

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

состояния заявок или их параметров. После этого случайным методом или последовательным перебором выбирается новое сообщение. Если был выбран приказ на создание новой заявки, его параметры сохраняются в памяти для дальнейшего использования. В случае выбора сообщения для изменения или отмены заявки, выбирается заявка, для которой нет неотвеченного запроса. Её параметры подставляются в сообщение и посылаются в торговую систему. После этого вычисляется время, прошедшее с начала итерации. Оно сравнивается с расчётным средним временем на одну итерацию, и при необходимости делается пауза. Последовательность «читать-отправить-ждать» позволяет принимать во внимание все последние изменения внутри тестируемой системы и на их основе посылать корректные с функциональной точки зрения сообщения.

Рис. 1. Блок-схема получения и отправки сообщения.

Запуск теста с максимальной нагрузкой на Intel(R) Xeon(R) CPU X5570 @

2.93GHz даёт на выходе с одного ядра до 70 000 сообщений в секунду и линейно масштабируется при использовании большего количества ядер. Результаты были подтверждены при распределении генерирующих потоков по 8 ядрам и использовании промышленной биржевой системы в качестве мишени.

Page 251: TMPA-2013 Conference Proceedings

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

Указанный объем нагрузки, создаваемой с одного сервера, превышает пропускную способность существующих систем торговли акциями. Показатель 70,000 исходящих сообщений в секунду с одного ядра соответствует максимальным показателям инструментов для тестирования веб-инфраструктур с помощью статических запросов [17].

4.6. Настройка профиля нагрузки

В этой части статьи описывается настройка профиля нагрузки. Нагрузка задается параметром: LOAD_CONFIG = фаза1 [, фаза2, … фазаN]

Нагрузочная фаза может быть следующей: -const(freq, dur) – постоянная нагрузка c частотой freq и длительностью

dur. Возможно также использовать сокращенный формат – freq:dur; -step(freq, delta, steps, dur) – увеличивающаяся нагрузка с начальной частотой freq, шагом изменения частоты delta, количаством шагов steps и длительностью одного шага dur; - connect(dur) – все сессии должны установить соединение с задержкой dur; - disconnect(dur) – все сессии должны оборвать соединение с задержкой dur; - logon(dur) – все сессии должны послать сообщение с авторизацией с задержкой dur; - logout(dur) – все сессии должны послать сообщение о прекращении сессии с задержкой dur;

Обрыв соединения сам по себе не является критической проблемой. Например, все web-соединения, и особенно соединения в мобильных приложениях, рассчитаны на то, что они будут прерываться. Для финансовых протоколов это событие может означать потерю участником торговли контроля над его заявками, и многие системы настроены на отмену всех открытых заявок. Если клиент активно ведёт торговлю и выставляет много заявок, потеря соединения приведет к тому, что его заявки будут массово отменены системой, что вызовет повышенную нагрузку на ядро системы. Также необходимо знать, как поведёт себя система при восстановлении соединения и авторизации под нагрузкой. Очень важно иметь возможность воспроизводить внезапный обрыв и восстановление соединения под нагрузкой. Для этой цели были созданы выше описанные фазы: connect, disconnect, logon, logout.

На рисунке 2. Изображены различные нагрузочные профили const, step и micro burst. Последний профиль создается при помощи фазы const с малой длительностью и высокой нагрузкой.

Рис. 2. Простейшие варианты профилей нагрузки.

const: LOAD_CONFIG=const(1000, 20m)

Page 252: TMPA-2013 Conference Proceedings

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

step: LOAD_CONFIG=step(500, 500, 4, 4m) micro burst: LOAD_CONFIG=200:5m, 40000:10ms, 200:5m, 75000:10ms, 200:5m

Из опыта авторов, нагрузка в форме ступеней (step) в наибольшей степени подходит для определения максимальной производительности системы. Нагрузка в форме микро-всплекса в наибольшей степени воспроизводит поведение современных высоконагруженных трейдинговых систем.

5 Заключение

Созданный и описанный в данной статье инструмент тестирования используется при измерении пропускной способности и времён отклика крупномасштабных биржевых и брокерских платформ, обеспечивающих технологическую инфраструктуру финансовых рынков, в рамках проектов, осуществляемых при поддержке компании Exactpro Systems LLC. Достигнутые результаты подтверждают эффективность выбранных методов работы: управление исполняемыми потоками посредством центрального контроллера и использование заготовленных шаблонов при генерации потока сообщений.

Планируется дальнейшее расширение списка открытых и коммерческих протоколов коммуникаций, поддерживаемых данным инструментом для тестирования. Несмотря на то, что существующая производительность генератора нагрузки позволяет создать реалистичный поток данных, используя один сервер, достаточный для перегрузки любой из существующих торговых площадок, а также для обеспечения качества трейдиговых систем, которые появятся в ближайшие годы, планируется разработка масштабируемого модуля, позволяющего контролировать нагрузку, создаваемую с нескольких серверов.

Основным направлением исследовательской работы станет совершенствование механизмов обработки обратного потока данных для повышения сложности и реалистичности сценариев нагрузочного тестирования торговых платформ. При этом высокая экономичность и эффективность используемых для тестирования инструментов сохранятся.

Источники

1. The Future of Computer Trading in Financial Markets. Final Project Report. / Foresight. The Government Office for Science, London. // [Электронный ресурс]. – Режим доступа http://www.bis.gov.uk/assets/foresight/docs/computer-trading/12-1086-future-of-computer-trading-in-financial-markets-report.pdf 2. Commission Roundtable on Technology and Trading: Promoting Stability in Today's Markets. / U.S. Securities and Exchange, October 2, 2012 // [Электронный ресурс]. – Режим доступа http://www.sec.gov/news/otherwebcasts/2012/ttr100212-transcript.pdf 3. Apache JMeter manual // [Электронный ресурс]. – Режим доступа http://jmeter.apache.org/usermanual/jmeter_distributed_testing_step_by_step.pdf 4. HP LoadRunner manual // [Электронный ресурс]. – Режим доступа ftp://ftp.itrc.hp.com/applications/HPSoftware/ONLINE_HELP/LoadRunner11.50_User.pdf

Page 253: TMPA-2013 Conference Proceedings

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

5. Rational Performance Tester // [Электронный ресурс]. – Режим доступа http://www-03.ibm.com/software/products/ru/ru/performance/ 6. Silk Performer // [Электронный ресурс]. – Режим доступа http://www.borland.com/products/silkperformer/ 7. Penhaligan,P.: Equity Trading: Performance, Latency & Throughput. / ExTENT Conference // [Электронный ресурс]. – Режим доступа http://www.slideshare.net/extentconf/extent3-turquoise-equitytrading2012 8. Benedetti E., Zanetti L.: London Stock Exchange - "The Focus Beyond Low Latency". / ExTENT Conference // [Электронный ресурс]. – Режим доступа http://www.slideshare.net/extentconf/extent-2013-obninsk-lse-the-focus-beyond-low-latency 9. Cong, J.: Load Specification and Load Generation for Multimedia Traffic Loads in Computer Networks. // Ph.D. Dissertation, FB Informatik, Univ. Hamburg, 2006; also published at: Shaker-Verlag, Aachen 2006 10. Jing Cong, Bernd E. Wolfinger: A Unified Load Generator Based on Formal Load Specification and Load Transformation // valuetools '06: Proceedings of the 1st international conference on Performance evaluation methodolgies and tools 11. Bodík P., Fox A., Franklin M., Jordan M., Patterson D.: Characterizing, Modeling, and Generating Workload Spikes for Stateful Services // SoCC’10, June 10–11, 2010 12. David Mosberger, Tai Jin: httperf—a tool for measuring web server performance // SIGMETRICS Performance Evaluation Review , Volume 26 Issue 3, December 1998 13. Иткин И.Л.: Тестирование биржевых систем в условиях высокочастотного трейдинга // SQA Days #10: http://sqadays.com/talk.sdf/sqadays/11151/talks/12196 14. Yandex.Tank Documentation // [Электронный ресурс]. – Режим доступа https://media.readthedocs.org/pdf/yandextank/latest/yandextank.pdf 15. Itkin Iosif: Theory of High Frequency Trading systems testing // Software Development & Analysis Technologies Seminar http://sdat.ispras.ru/2011/09/20-октября-модели-тестирования-систем/ http://www.slideshare.net/IosifItkin/theory-of-high-frequency-trading-systems-testing 16. Официальный сайт FIXprotocol // [Электронный ресурс]. - Режим доступа http://www.fixprotocol.org/ 17. How to Generate Millions of HTTP Requests // [Электронный ресурс]. - Режим доступа http://dak1n1.com/blog/14-http-load-generate

Page 254: TMPA-2013 Conference Proceedings

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

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

Наталья Прядкина1, Антон Крюков1

1 Костромской государственный технологический университет 156005, г. Кострома, ул. Дзержинского, 17

[email protected], [email protected]

Аннотация. Данная статья описывает проблемы тестирования систем мо-ниторинга и контроля на фондовых биржах (СМКнФБ). На сегодняшний день такие системы представляют собой комплексные программные про-дукты, реализующие сложные математические алгоритмы и обрабатыва-ющие большой объём данных. Одной из их задач является уменьшение количества ложных срабатываний, что достигается за счёт наиболее пол-ного покрытия при тестировании. В работе определены подходы для адап-тации метода тестирования на основе модели (ТнОМ, MBT) к верифика-ции СМКнФБ. Построена структурная модель системы, дано формализо-ванное описание метода в нотации IDEF0. Определены требования к сте-пени абстракции функциональной модели СМКнФБ, необходимой для проведения тестирования. Ключевые слова: обеспечение качества; тести-рование на основе модели; автоматическое создание тестовых сценариев; система мониторинга на фондовых биржах.

1 Введение

В связи с тем, что манипуляции на фондовых биржах подрывают эффектив-ность финансовых рынков и доверие к ним, вплоть до снижения стабильности всей экономической системы, они являются одной из серьёзных проблем для финансовых организаций и участников торгов [1, 7].

В настоящее время законодательство обязывает финансовые институты при-менять системы мониторинга и контроля (СМКнФБ, surveillance system) с це-лью выявления и пресечения незаконных действий на рынке, таких как распро-странение недостоверной информации, манипулирование ценами или мошен-ничество за счёт использования информации, недоступной широкой публике (инсайдерская информация) [1, 2].

Современные СМКнФБ являются комплексными продуктами, интегрирован-ными в трейдинговые системы, и основываются на адаптивной логике. Они реализуют сложные математические алгоритмы, собирают статистическую ин-формацию о ситуации на рынке и обрабатывают большие объёмы данных в режиме реального времени. Одной из их задач является уменьшение количества

Page 255: TMPA-2013 Conference Proceedings

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

ложных срабатываний, т.е. сокращение количества ошибок первого и второго рода [2].

Такие системы требуют особого подхода к тестированию. Существует мно-жество методов, которые могут быть применимы для верификации работы ин-формационной системы. Выбранный метод – в идеале - должен обеспечивать достижение ряда целей:

1. универсальная теория всего; 2. моделирование на основе тестов (test-based modeling); 3. стопроцентная автоматизация тестирования; 4. максимально полное проектирование тестов [3]. Методологии тестирования исторически развиваются так, что каждая из них

делает ещё один шаг в этих направлениях. Метод тестирования на основе модели (ТнОМ, model-based testing, MBT)

нашёл широкое применение в проверке качества работы информационных си-стем. Данный подход имеет значительный потенциал для выполнения гибко-управляемого тестирования сложных систем, которые не могут быть протести-рованы в достаточной мере при помощи основных технологий с приемлемыми трудозатратами [11].

Во второй главе данной статьи будут рассмотрены особенности систем мони-торинга и контроля на фондовой бирже; в третьей – основные методологии, которые могут быть применены к тестированию таких систем, а также будет сделан вывод о наиболее эффективной из них; в четвертой главе будут опреде-лены основные подходы для адаптации метода тестирования на основе модели к верификации СМКнФБ.

2 Особенности систем мониторинга и контроля на фондовой бирже

СМКнФБ выполняет функцию мониторинга рынка с целью выявления нети-пичных ситуаций, которые могут служить идентификаторами незаконных фи-нансовых транзакций [8, 16]. Контролируют данный процесс такие регулирую-щие органы в сфере финансовых услуг, как: Департамент управления финансо-выми рынками Великобритании (Financial Conduct Authority, FCA), Комиссия по ценным бумагам и биржам США (Securities and Exchange Commission, SEC) и другие [5].

В таблице 1 отображены основные требования к СМКнФБ.

Табл. 1. Требования к системе мониторинга и контроля на фондовой бирже

Требование Описание Определение и предотвращение различных типов мошенниче-ства на бирже

На сегодняшний день существуют десятки типов поведения на рынке, которые могут быть расце-нены как мошенничество. СМКнФБ должны сигнализировать о потенциально нелегитимном

Page 256: TMPA-2013 Conference Proceedings

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

поведении с помощью сигнала тревоги (alert). Пусковые механизмы этих сигналов реализуют-ся с помощью математических алгоритмов

Гибко настраиваемые алгорит-мы распознавания образов (адаптивная логика)

Для эффективного выявления мошенничества необходимо непрерывно адаптировать суще-ствующие алгоритмы к новым ситуациям, воз-никающим в ходе торгов [6]

Обработка большого количества данных в режиме реального времени

СМКнФБ непрерывно получает информацию от трейдинговых и других внешних систем, обра-батывает её и выдаёт результат анализа (сигналы о потенциально нелегитимном поведении участ-ников торгов и статистика), информацию о со-стоянии рынка

Минимизация ложных (ложно-положительное / ложноотрица-тельное) срабатываний: избежа-ние ошибок первого и второго рода

Основной проблемой современных систем мо-ниторинга и контроля на фондовой бирже явля-ется разграничение нарушителей и механизмов биржи, отвечающих за ликвидность на рынке (market makers). Необходимо минимизировать ошибки первого рода (false positives) – ложная тревога – и ошибки второго рода (false negatives) – пропуск случаев манипулирования и иных нарушений на рынке

Интеграция с трейдинговой системой: поддержка различных протоколов

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

Сбор статистических данных за определенный период

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

Особенности, обозначенные в таблице 1, влекут за собой повышенные требо-

вания к тестированию таких систем. В процессе верификации СМКнФБ, как и любой системы, тестировщики

стремятся осуществить близкую к стопроцентной проверку работоспособности системы, что достигается за счёт большего покрытия и большего количества тестовых сценариев [14]. С другой стороны, с расширением библиотеки тестов увеличивается время, необходимое на верификацию работы СМКнФБ. Более того, незначительное изменение функциональности системы может повлечь за собой существенное преобразование библиотеки тестов.

Page 257: TMPA-2013 Conference Proceedings

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

Таким образом, проблема выбора оптимального метода для построения про-цесса тестирования СМКнФБ является актуальной.

На Рисунке 1 представлена, разработанная в рамках проектов компании Ex-actpro Systems, LLC, структурная модель системы мониторинга и контроля на фондовых биржах, определены главные компоненты и информационные пото-ки, типичные для такой системы.

Рис. 1. Структурная модель системы мониторинга и контроля на фондовой бирже, разра-ботанная в рамках проектов компании Exactpro Systems, LLC

Как видно из рисунка 1, СМКнФБ может получать информацию как по сете-вым протоколам TCP/IP и UDP, так и проводить анализ на основе файла. Ис-пользуются базы данных Level DB для сохранения обрабатываемых сообщений; Mongo DB – для сигналов тревоги о потенциальном случае манипулирования или иного нарушения (surveillance alerts) и статистики. Поток сообщений в си-стеме обрабатывается с помощью так называемых «акторов» (actors systems, akka) трансляции, хранения сообщений, сценариев и бизнес логики.

3 Выбор метода тестирования

Верификация работы программных продуктов охватывает широкий спектр деятельности: от тестировании, выполняемого разработчиками (unit testing), до приёмо-сдаточных испытаний (acceptance testing) [3, 9].

Page 258: TMPA-2013 Conference Proceedings

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

В этой главе была проанализирована возможность применения различных методологий к тестированию СМКнФБ.

3.1 Методы тестирования

3.1.1 Ручное тестирование (Manual Testing)

Несмотря на ряд ограничений, присущих ручному тестированию, оно широко используется при верификации определенного рода программных продуктов.

Тестировщик, используя тестовый план и спроектированные сценарии, воз-действует на систему и считывает результат своего воздействия с её графиче-ского интерфейса.

Хотя СМКнФБ и имеет свой интерфейс, с помощью которого пользователь может считывать информацию (окна приложения), для воспроизведения даже одного вида потенциальных нарушений, необходимо сделать десятки манипу-ляций. Более того, чем разнообразнее становится функциональность системы, тем сложнее делать повторный прогон тестов на новой версии (regression testing). К тому же, система обрабатывает огромный поток данных, за которым порой трудно уследить.

3.1.2 Тестирование на основе скриптов (Script Based Testing)

Тестирование на основе скриптов нашло широкое применение в процессе ве-рификации программных продуктов.

Данный метод предполагает использование тестового инструмента, который применяется для автоматического прогона тестовых сценариев, написанных на специальном языке. Сами же тесты пишутся вручную.

Пользователь СМКнФБ, применяя специальные инструменты, может отправ-лять данные, воздействуя на систему, а также получать ответ от системы и со-поставлять его с ожидаемым результатом.

3.1.3 Тестирование на основе модели (Model Based Testing)

Коротко данный вид тестирования можно охарактеризовать как автоматизи-рованное проектирование тестов черного ящика. Вместо того, чтобы вручную создавать тесты, основанные на документации, MBT подход подразумевает проектирование модели, отвечающей некоторым требованиям и имитирующей тестируемую систему [4].

Page 259: TMPA-2013 Conference Proceedings

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

3.2 Оценка методов тестирования систем мониторинга и контроля на фондовых биржах

Метод тестирования систем мониторинга и контроля на фондовых биржах должен отвечать следующим требованиям:

1. обеспечение наиболее полного покрытия тестами [15]; 2. высокая степень автоматизации сценариев тестирования; 3. возможность повторного выполнения сценариев (regression testing); 4. минимизация ошибок первого и второго рода (ложных срабатываний); 5. выполнение прогона библиотеки тестов за приемлемое время; 6. минимизация изменений сценариев тестирования при изменении функцио-нального поведения системы:

7. обеспечение возможности автоматизированного тестирования при недетер-минированном поведении системы.

MBT метод наиболее полно отвечает всем обозначенным выше требованиям.

4 Тестирование на основе модели (Model Based Testing)

Методология тестирования на основе модели предполагает автоматизацию процесса проектирования сценариев тестирования и матриц покрытия (traceabil-ity matrix) [4].

Данный подход позволяет существенно снизить затраты на создание библио-теки тестовых сценариев: вместо ручного написания тестировщиком сотен и тысяч сценариев, проектировщик создает абстрактную модель системы, затем с помощью инструмента MBT автоматически генерируется множество тестовых сценариев на основе этой модели. Таким образом, общее время проектирования тестов сокращается; кроме того, при использовании других критериев отбора, может быть создан новый тестовый набор на основе существующей модели [4, 12].

Модель должна представлять собой проекцию структуры и поведения систе-мы, причём может быть спроектирована как целая система, так и отдельные её функциональные части.

4.1 Этапы МВТ подхода

Формализованное описание тестирования на основе модели дано на рисунке 2. На первом этапе происходит проектирование модели системы. Здесь необхо-димо выбрать оптимальную степень абстракции, удовлетворяющую заданным требованиям.

На втором этапе на основе модели создаются абстрактные тестовые сцена-рии. Вследствие того, что количество всевозможных тестов стремится к беско-нечности, нам необходимо выбрать критерии отбора, которые ограничат мно-жество тестовых вариантов до требуемого. Выходными данными на этом этапе

Page 260: TMPA-2013 Conference Proceedings

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

служат абстрактные тесты, а также матрица покрытия, иллюстрирующая сте-пень покрытия функциональных требований созданными тестовыми сценария-ми.

Третий этап – преобразование абстрактных тестовых сценариев в исполняе-мые скрипты. Это достигается путём применения инструмента преобразования, который использует различные шаблоны и взаимосвязи для перевода каждого абстрактного теста в исполняемый скрипт.

Четвертый этап – выполнение тестов. На пятом этапе тестировщиком проводится анализ полученных результатов.

Рис. 2. Бизнес-процесс "Тестирование на основе модели" в нотации IDEF0

Page 261: TMPA-2013 Conference Proceedings

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

4.2 Применение MBT к тестированию систем мониторинга и контроля на фондовых биржах

Основной задачей и главной проблемой в случае применения метода являет-ся построение модели системы.

В качестве инструмента преобразования может быть использован инстру-мент, который будет перебирать всевозможные комбинации того или иного вида нарушений. В этом случае можно предположить, что более эффективным и дешёвым способом будет моделирование не всей системы, а лишь отдельных её частей, отвечающих за мониторинг определённого вида манипулирования на рынке.

Слабое место данного подхода – сложность организации взаимодействия компонентов системы между собой. Поскольку СМКнФБ являются комплекс-ными программными продуктами, метод не будет эффективен, так как остаются так называемые «мертвые зоны» – части системы, которые не будут смоделиро-ваны и покрыты сценариями тестирования. При построении модели мы получа-ем подобие реальной системы, предполагающее некоторую степень абстракции. Таким образом, требуется определить оптимальный уровень абстракции, с уче-том того, что часть функциональности не будет представлена в модели.

В случае, если система разбита на N локальных представлений (подсистем), модель i-го представления может быть задана как функция:

, (1)

где – входные данные i-го локального представления системы; – погрешность моделирования локального представления; ; в случае, если модель по параметрам приближается к реальной системе. При этом, модель всей системы может быть определена как:

(2) где – погрешность моделирования системы, возникающая за счёт выполнения

операций объединения локальных представлений, в случае, если : .

В связи с тем, что СМКнФБ обладают сложной структурой, и количество ло-кальных представлений N велико, для достижения требуемых результатов те-стирования при построении модели необходимо обеспечить минимальные зна-чения z и Z.

При построении модели требуется обеспечить максимальную приближён-ность к реальной системе, вплоть до разработки аналога. Чем ближе модель к реальной СМКнФБ, тем полнее покрытие тестируемой системы сценариями тестирования.

Page 262: TMPA-2013 Conference Proceedings

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

Таким образом, задачами дальнейшего исследования являются:

1. Оценка степени сложности системы методами системного анализа; 2. Определение возможности тестирования системы на моделях локальных

представлений (подсистем); 3. Оценка возможностей построения имитационной модели системы; 4. Определение целесообразности построения физической модели системы, с

учетом используемых методов.

В качестве начального исследования нами был проведен эксперимент на про-ектах компании Exactpro Systems, LLC. Осуществлялось тестирование системы мониторинга и контроля под названием T. В качестве контрольных методов тестирования были выбраны ручное и тестирование на основе скрипта. Так как компания Exactpro Systems, LLC начала разработку СМКнФБ под названием Д., эта создаваемая система была использована в качестве имитационной модели системы Т. при тестировании на основе метода MBT. В результате тестирования системы Т. было найдено на 9.8 % больше ошибок, по сравнению с контроль-ными методами тестирования.

5 Заключение

Системы мониторинга и контроля биржевых систем состоят из большого ко-личества модулей, что обусловливает необходимость большого объёма тесто-вых сценариев. Кроме того, цена ошибки в таких системах чрезвычайно высока.

Поэтому для обеспечения быстрого и полного автоматизированного тестиро-вания были рассмотрены и выделены наиболее подходящие подходы к верифи-кации СМКнФБ. Показано, что тенденцией в современной теории тестирования является переход к автоматическому режиму проверки программного обеспече-ния, и МВТ позволяет этого достичь.

Показано, что метод тестирования на основе модели позволяет автоматизи-ровать проектирование сценариев тестирования, сокращать затраты на под-держку имеющегося набора тестов, автоматизировать создание таблицы неис-правностей. Именно этого стремятся добиться инженеры по обеспечению каче-ства при тестировании какого-либо программного продукта.

В статье определены подходы для адаптации метода MBT к специфике СМКнФБ и проблемы построения модели системы, необходимой для её тести-рования. Также сделан вывод о том, что лучшим инструментом для тестирова-ния системы мониторинга и контроля на фондовой бирже является другая СМКнФБ.

Литература

1. R. K. Aggarwal, G. Wu: “Stock Market Manipulations,” Journal of Business, vol. 79, no. 4, pp. 1915-1953, 2006

Page 263: TMPA-2013 Conference Proceedings

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

2. Jens Wirén Farhad Kimanos: A Survey & Implementation of Financial Alarm Classification [Электронный ресурс] // Режим доступа – http://scila.se/wp-content/uploads/2013/07/AIforAlertClassification-ScilaReport.pdf

3. Antonia Bertolino Software Testing Research: Achievements, Challenges, Dreams [Элек-тронный ресурс] // Режим доступа – http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=4221614&url=http%3A%2F%2Fieeexplore.ieee.org%2Fxpls%2Fabs_all.jsp%3Farnumber%3D4221614

4. Mark Utting, Bruno Legeard: Practical Model-Based Testing a Tools Approach. Morgan Kaufmann Publishers, 2007

5. Michael J. Aitken: Strategic Surveillance in the Philippine Capital Markets and the expecta-tions of surveillance technology [Электронный ресурс] // Режим доступа – http://www.telchar.com/pdf/surveillance.pdf

6. Иосиф Иткин, Наталья Прядкина, Антон Крюков: «Анализ данных в высоконагружен-ных трейдинговых системах» [Электронный ресурс] // Режим доступа – http://clubqa.ru/blogs/?p=436

7. David Diaz, Mohamed Zaki, Babis Theodoulidis, Pedro Sampaio: A Systematic Framework for the Analysis and Development of Financial Market Monitoring Systems [Электронный ресурс] // Режим доступа – http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=5958083&url=http%3A%2F%2Fieeexplore.ieee.org%2Fxpls%2Fabs_all.jsp%3Farnumber%3D5958083

8. Johan Örtenblad, Vladimir Vlassov, Torkel Erhardsson, Håkan Carlbom, Johan Norén: Market Surveillance System [Электронный ресурс] // Режим доступа – http://web.it.kth.se/~maguire/DEGREE-PROJECT-REPORTS/020606-Johan-Ortenblad.pdf

9. Noah Höjeberg: Random Tests In A Trading System Using Simulations And A Test Oracle [Электронный ресурс] // Режим доступа – http://kiosk.nada.kth.se/utbildning/grukth/exjobb/rapportlistor/2008/rapporter08/hojeberg_noah_08037.pdf

10. Wolfgang Prenninger, Alexander Pretschner: Abstractions for Model-Based Testing [Элек-тронный ресурс] // Режим доступа – ftp://ftp.ira.uka.de/pub/ZVI/papers/tacos04.pdf

11. Victor V. Kuliamin: Model Based Testing of Large-scale Software: How Can Simple Models Help to Test Complex System [Электронный ресурс] // Режим доступа – http://panda.ispras.ru/~kuliamin/docs/ISOLA-2004-en.pdf

12.Mark Utting, Alexander Pretschner, Bruno Legeard: A Taxonomy Of Model-Based Testing [Электронный ресурс] // Режим доступа – http://www.cs.waikato.ac.nz/pubs/wp/2006/uow-cs-wp-2006-04.pdf

13. Learning from Financial Trading Bugs [Электронный ресурс] // Режим доступа – http://gaynwinters.wordpress.com/2012/10/26/learning-from-financial-trading-bugs/

14. NASA Software Safety Guidebook [Электронный ресурс] // Режим доступа – http://www.hq.nasa.gov/office/codeq/doctree/871913.pdf

15. Phyllis Franklt Dick Hamlet Bev Littlewood Lorenzo Strigini: Choosing a Testing Method to Deliver Reliability [Электронный ресурс] // Режим доступа – http://www.computer.org/csdl/proceedings/icse/1997/2162/00/21620068-abs.html

16. Afroditi Katika, Babis Theodoulidis, David Diaz: Investigating Financial Fraud In High Fre-quency Trading: Context And Drivers [Электронный ресурс] // Режим доступа – http://papers.ssrn.com/sol3/papers.cfm?abstract_id=1974911

Page 264: TMPA-2013 Conference Proceedings

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

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

высокочастотной торговли

Иван Бобров1, Алексей Зверев2

1 ООО «Инновационные Трейдинговые Системы», Россия, 156013, г. Кострома, ул.

Ленина, 20 [email protected]

2 Exactpro Systems LLC, 4040 Civic Center Drive, Suite 200, San Rafael, CA 94903, USA [email protected]

Aннотация. При работе систем высокочастотного трейдинга в состоянии максимальной нагрузки количество изменений котировок может достигать нескольких тысяч в секунду. Для слежения за рынком на экранах терминалов применяются специальные графические средства, реализованные в виде программного обеспечения. Тестирование такого программного обеспечения представляет собой специфическую задачу. В статье рассматривается метод проверки функциональности графического интерфейса трейдинговых систем. Для тестирования предлагается сохранять графическое представление областей интерфейса в момент их перерисовки операционной системой. Полученные таким образом данные в оцифрованном виде сравниваются с данными, полученными из независимого источника котировок. В статье описывается реализация предложенного метода и анализируются результаты с точки зрения применимости в условиях реальной торговли.

1 Введение В последние годы высокочастотная торговля занимает большую часть торгов на соответствующих электронных площадках. По данным РТС в 2010 году на долю торговых роботов в обороте на срочном рынке РТС FORBS приходилось примерно 50%, а их доля в общем количестве заявок в определенные моменты достигала 90% [1]. Системы, ориентированные на высокочастотную торговлю, многокомпоненты и строятся из расчёта максимальной отдачи и надежности. Основными компонентами, напрямую используемыми пользователями, являются торговые терминалы и шлюзы, находящиеся под управлением специализированных протоколов, таких как FIX, NATIVE [2]. За информацию, на базе которой эти компоненты формируют представление о рынке, отвечает компонент, являющийся важной составляющей любой торговой платформы и

Page 265: TMPA-2013 Conference Proceedings

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

отвечающий за поставку котировок [3]. Поставщик котировок предоставляет котировки и другую финансовую информацию в режиме реального времени, что позволяет получателям обрабатывать и представлять её конечному пользователю в том или ином виде.

2 Торговый терминал и шлюз

Торговый терминал – это программное обеспечение, позволяющее трейдеру в режиме реального времени получать всю необходимую информацию о ходе торгов на мировых биржевых и внебиржевых рынках, а также анализировать полученные данные посредством встроенных в торговый терминал инструментов и делать выводы, на основе которых совершать торговые сделки. [4].

Основным отличием торгового терминала является графическая оболочка, посредством которой происходит отображение данных на экран. В случае с подключением через шлюз, все данные, как правило, передаются в формате протокола, по которому совершено подключение (см. рисунок 1). В итоге сам торговый терминал может быть подключен непосредственно через подобный протокол к рынку.

И шлюз и терминал, получают данные, основанные на потоке, распространяемом компонентом поставщика котировок. В случае со шлюзом пользователь самостоятельно производит расшифровку полученного пакета данных, а в терминале вся информация представляется в удобочитаемом виде.

На сегодняшний день количество заявок, обрабатываемых биржей, в течение торговой сессии исчисляется миллионами. Особенностью же HFT логики является высокоскоростной обмен сообщениями с рынком в зависимости от модели торгового робота. В ходе эволюции средств связи и коммуникации скорость обработки запросов значительно возросла, а время ответа системы на запрос стало исчисляться в микросекундах [5].

Таким образом, в момент максимальной нагрузки рынка торговый терминал получает информацию со скоростью, с которой вывод на экран сделает невозможным попытки визуально отследить все изменения, происходящие в окне клиента, вследствие чего пользователь не сможет дать адекватную оценку корректности отображаемой информации.

При приёме данных через шлюз весь поток информации будет сохранен в виде сообщений, полученных в рамках установленной сессии и доступных для анализа, что позволяет выполнить их проверку на соответствие спецификации без каких-либо серьёзных потерь и в любой удобный для этого момент времени.

Page 266: TMPA-2013 Conference Proceedings

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

Рис. 1. Пример графического интерфейса трейдингового терминала.

3 Симуляция нагрузки

Для тестирования системы в состоянии высокочастотного трейдинга в первую очередь необходимо создать условия, совпадающие с представлениями о высокой нагрузке. Для создания подобных условий может быть использован инструмент «Генератор нагрузки» (англ. LoadInjector), разработанный компанией Exactpro Systems LLC. Инструмент позволяет согласно сконфигурированному сценарию создавать и поддерживать продолжительную отправку и приём большого количества сообщений, доводя таким образом торговую систему до необходимого уровня нагрузки.

Объектом тестирования выступает графическая оболочка торгового клиента, из которой необходимо получить поток данных для анализа. В качестве эталона для сравнения в ходе анализа может быть использован шлюз, подписка через который на мониторинг отправки котировок позволит получить достаточно надёжную картину происходящего на протяжении всего периода теста.

Для этого организуется подключение по протоколу шлюза с последующей подпиской на необходимые обновления, которые будут сохранены в виде набора сообщений в формате используемого протокола обмена данными. Тесты проводились при помощи симуляции исторической маркет даты, доступной для общего доступа на сайте histdata.com, воспроизводимой с различной скоростью.

4 Запись данных из графического интерфейса

Требуется сохранить аналогичный поток изменений в окне торгового терминала. Для осуществления этого есть несколько возможных способов.

Первый способ - запись области экрана в видеофайл посредством специальных утилит, таких как CamStudio [6], c последующей обработкой и

Page 267: TMPA-2013 Conference Proceedings

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

конвертацией в набор изображений, отражающих блок, относящийся к содержимому книги заявок. В этом случае потребуется дополнительно декодировать данные из полученных изображений, представив их в виде буквенно-числового представления содержимого каждой стороны книги заявок для возможности сравнения. Также ввиду ограничений скорости работы подобных программ и записи видео с конечной картинки экрана есть риск потери достаточно большого количества изменений. Программа снимает изображение непосредственно с экранной картинки, в то время как драйвер видеоустройства может послать гораздо большее количество кадров, которые в ходе наложения могут перекрыть изменения, произошедшие в предыдущем кадре. Таким образом, при записи видео со скоростью 200 кадров в секунду весь выход за пределы такой скорости со стороны видеодрайвера ведёт к потере потенциально пригодных для анализа данных.

Второй способ – это прямой доступ к объектам формы терминала. Для этого средствами операционной системы потребуется установить, какие объекты расположены в окне, как они упорядочены, какой имеют тип и какие параметры этих объектов позволят прочитать их текущее состояние и содержимое. Так с установленным интервалом можно будет считывать состояние нужных компонентов, а также сохранять состояния книги. Существенным минусом данного способа будет высокая нагрузка на процессор компьютера, на котором будет расположена такая программа и терминал, в результате чего снизится производительность самого терминала, что делает тест отдаленным от реальных условий.

Третьим способом является перехват всех попыток изменить внешнее представление окна терминала самой операционной системой. Таким образом мы сможем гарантировать, что все попытки перерисовки будут сохранены, а на выходе будет массив изображений, доступный для анализа и конвертирования в читаемый набор данных.

Суммируя все вышесказанное, мы видим, что первый способ наименее интересен ввиду присутствия риска потери данных, что не позволит сделать объективными результаты анализа. Второй способ весьма специфичен и может быть использован лишь в ограниченном наборе графических интерфейсов, и в виду того, что каждый из них может быть реализован по-разному и на разных платформах, возникает необходимость индивидуального подхода и индивидуального алгоритма. Также риск сокращения производительности самого приложения торгового терминала ввиду параллельной работы достаточно сложной реализации по считыванию изменяемых данных, делает недопустимым использование такого метода в текущем исследовании.

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

Page 268: TMPA-2013 Conference Proceedings

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

На данном этапе алгоритм применим для большинства торговых клиентов, содержимое книжки которых отражается на экране терминала. Однако стоит учитывать, что реализация отображения не одинакова в разных клиентах.

Объект тестирования и реализованный алгоритм узко специализированны относительно объекта тестирования и для применения алгоритма против другого клиента он потребует переработки в зависимости от того как будет представлена информация на экране терминала. Таким образом основных изменений потребует часть преобразования снятой графической информации.

5 Microsoft Detours

В качестве инструмента для реализации выбранного метода, используется библиотека Microsoft Detours [7]. Данная библиотека позволяет устанавливать перехватчики стандартных событий системы и использовать собственную процедуру, предваряющую дальнейшее выполнение (Рисунок 2.). В случае с торговым терминалом, перехватчик устанавливается на событие перерисовки любого графического элемента экранной формы торгового терминала.

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

Следующим шагом является преобразование графического представления в читаемый массив значений. На основании полученных значений, а также значений из подписки к шлюзу, строятся два набора книжек [8] с определенным шагом времени (t). Во внимание принимается максимальное количество заявок, отображаемых в торговом терминале.

Page 269: TMPA-2013 Conference Proceedings

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

Рис. 2. Схема работы перехватчика из библиотеки Microsoft Detours.

6 Сравнение данных

Полученные наборы состояний сравниваются между собой и оценивается разница между ними. Набор данных от шлюза:

GW() = GW(t1),GW(t2),GW(t3),...,GW(tN) (1) Набор данных от графического интерфейса: SC() = SC(t1),SC(t2),SC(t3),...,SC(tN) (2) Необходимо учесть, что количество данных на единицу времени со стороны

шлюза допустимо больше, чем со стороны графического интерфейса, ввиду того, что графический адаптер не способен отразить все изменения книжки, если они превышают его характеристики по записи в видеопамять в момент времени t.

Сравнение происходит по двум признакам: полное попадание и полное непопадание. Для каждого случая производится подсчёт разницы во времени между найденными соответствиями.

Нарушение порядка даже заявок на книжке принимается как полное несоответствие книжек. Таким образом, на выходе получаем график, подобный представленному на рисунке 3.

Page 270: TMPA-2013 Conference Proceedings

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

Рис. 3. Пример графика совпадений книжек на одной минуте теста.

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

соответствиями книжек от эталонного источника и графического интерфейса, а также оценить потери и корректность отображаемой информации. На основании такой оценки при детальном рассмотрении конкретных приложений можно модифицировать алгоритмы нагрузочного сценария, что даст возможность усилить обнаруженные негативные эффекты, будь то несовпадение книжек или серьёзная разница во времени между соответствиями.

Принимается во внимание, что основная фаза тестирования происходит на основании предзаписанного сценария нагрузки, который может быть заменен сконфигурированным тестом, в котором будут учтены типы сообщений и их частота на проблемных участках анализа. На графике отражена зависимость отставания книжки, отраженной в трейдинговом терминале, от информации, полученной через предоставляющий информацию о котировках (market data) шлюз. По оси абсцисс откладывается время наблюдения в секунду, а по оси ординат - задержка в миллисекундах между временем котировки и временем получения соответствующей книжки в трейдинговом терминале. При помощи искусственных точек с задержкой 1000 мс, мы отметили на этом графике точки полного непопадания.

По кривой с попаданием мы можем анализировать задержки между получением событий через электронные интерфейсы и отрисовкой их в пользовательском интерфейсе. Эта важная информация позволяет конечным пользователям оценивать актуальность и своевременность информации, отражаемой на экране. График с непопаданием показывают, насколько часто графический интерфейс отражает книжку, полностью не соответствующую реальности. Анализ этих графиков лучше проводить, рассматривая плотность точек на графике "непопадания". Например, если "непопадания" встречаются редко и длительность непопадания ограничена, это означает, что, если сразу после "непопадания" имеется "попадание", то, с точки зрения конечного пользователя, искаженная книжка будет незаметна, поскольку в течение

Page 271: TMPA-2013 Conference Proceedings

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

короткого интервала она будет перерисована другой, правильной, книжкой. Однако, с другой стороны, если плотность "непопаданий" велика, то возрастает вероятность того, что пользователь увидит некорректную книжку, и такое поведение следует считать существенным дефектом пользовательского интерфейса.

На основе предложенного подхода (Рисунок 4) был разработан инструмент, позволяющий перехватывать все изменения графического интерфейса, а также дополнительные инструменты для распознавания графических данных, построения книг заявок и сравнения двух наборов книг между собой [9].

Рис. 4. Графическая схема метода, разработанного на базе

библиотеки Microsoft Detours

7 Заключение

В данной статье мы показали, что имеется техническая возможность валидации активного потока котировок, демонстрируемого пользователю через элементы графического интерфейса. Мы разработали инструменты, реализующие представленную методику снятия данных. В результате построенный набор инструментов позволяет эффективно анализировать графическую выдачу и сравнивать её с независимым цифровым потоком, а также вычислять задержки и потенциальные несовпадения двух потоков.

Page 272: TMPA-2013 Conference Proceedings

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

Источники

1. Slon.ru - Деловые новости и блоги // [Электронный ресурс]. – Режим доступа http://slon.ru/economics/lyudi_luchshe_robotov-970172.xhtml 2. Официальный сайт FIXprotocol // [Электронный ресурс] - Режим доступа http://www.fixprotocol.org/ 3. Wikipedia // [Электронный ресурс]. - Режим доступа http://en.wikipedia.org/wiki/Market_data 4. Форекс журнал для трейдеров // [Электронный ресурс]. - http://fortrader.ru/forex-terminals/ 5. Leo King.: London Stock Exchange smashes world record treade speed with Linux. / Coputerworld UK // [Электронный ресурс]. http://www.computerworlduk.com/news/networking/3244936/london-stock-exchange-smashes-world-record-trade-speed-with-linux/ 6. Официальный сайт CamStudio // [Электронный ресурс]. - Режим доступа http://camstudio.org 7. Dejan Lukan.: API Hooking with Microsoft Detours / INFOSEC Institute Resources // [Электронный ресурс]. - Режим доступа http://resources.infosecinstitute.com/api-hooking-detours/ 8. Wikipedia // [Электронный ресурс]. - Режим доступа http://en.wikipedia.org/wiki/Order_book_%28trading%29 9. Zverev,A., Bobrov,I, Pryadkina,N..: Testing of HFT GUI. / ExTENT conference // [Электронный ресурс]. – Режим доступа http://www.slideshare.net/extentconf/extent3-exactpro-testingofhftgui-12944204

Page 273: TMPA-2013 Conference Proceedings

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

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

Дмитрий Цителов ([email protected]), Devexperts LLC

Виталий Трифанов ([email protected]), СПбГУ

Аннотация. Состояние гонки (data race) возникает в многопоточной программе, когда несколько потоков одновременно обращаются к одному и тому же разделяемому участку памяти, где хотя бы одно обращение – запись. Состояния гонки слабо локализованы и их сложно обнаружить вручную, поэтому исследования в области автоматического поиска гонок ведутся уже более 20 лет. В данной статье рассматриваются вопросы производительности и точности динамического поиска гонок в Java-программах и предлагается идея снижения накладных расходов обнаружения с помощью синхронизационных контрактов. Последние опираются на описания пар вызовов методов, обеспечивающих синхронизацию потоков, и помогают исключать из анализа части целевого приложения, не интересные с точки зрения поиска гонок – например, сторонние библиотеки. Приводится схема языка спецификации контрактов и некоторые технические детали реализации, рассматриваются преимущества и ограничения подхода.

Ключевые слова: многопоточность, состояние гонки, динамический анализ, автоматическое обнаружение ошибок.

1 Введение

С развитием многоядерных и многопроцессорных систем все большее количество программ создаются многопоточными. Использование нескольких потоков выполнения может приводить к дополнительным ошибкам, связанным с некорректной организацией взаимодействия этих потоков. Такие ошибки сложно искать вручную, поскольку чередование операций в потоках обладает высокой степенью неопределённости, и программисту нужно полностью просчитать все возможные ситуации. Одной из типичных ошибок многопоточных программ является наличие в них состояний гонки (data races). Они возникают, когда несколько потоков без должной синхронизации обращаются к одному и тому же разделяемому участку памяти, где хотя бы одно обращение – запись [14]. Дополнительная трудность с обнаружением гонок состоит в том, что они, как правило, не приводят к немедленному сбою и отказу программы. Напротив, приложение продолжает работать с

Page 274: TMPA-2013 Conference Proceedings

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

повреждёнными глобальными структурами данных, что приводит к труднообъяснимым эффектам впоследствии.

За несколько последних десятков лет было разработано несколько статических и динамических подходов к обнаружению гонок. Статические детекторы ([7,11,13]) анализируют все пути исполнения программы, не требуют её запуска, но обладают низкой точностью. Динамические ([3,4,6,8,15,16,17,18]) анализируют программу во время её работы, но ограничены лишь фактическим путём выполнения программы. Хотя динамические алгоритмы и обладают полной информацией о конкретном пути выполнения программы, на практике их точность ограничена накладными расходами, которые они вносят. Проблема достижения высокой точности обнаружения гонок и отсутствия ложных срабатываний (false positives) при сохранении приемлемого уровня потребления аппаратных ресурсов является краеугольной технической проблемой динамического анализа.

Данная работа предлагает способ понижения накладных расходов на динамическое обнаружение гонок в Java-программах без потери точности. Основная идея заключается в сокращении области программы, где отслеживаются все операции синхронизации. Чтобы это не привело к потере информации о синхронизации между потоками и, как следствие, к ложным срабатываниям, вводится понятие синхронизационного контракта, которое позволяет в достаточной степени описать поведение исключённого кода в многопоточной среде. Далее во время работы детектор распознает эти контракты и встретив методы, соответствующие им, обрабатывает эти методы как высокоуровневые синхронизационные события. Такой подход позволяет восполнить неотслеженные операции синхронизации и обеспечить высокую точность поиска.

Дальнейшая часть статьи организована следующим образом. Во второй главе описывается отношение happens-before и приводится формальное определение понятия гонки в терминах спецификации Java, после чего описывается точный алгоритм поиска гонок, основанный на отслеживании этого отношения. Третья глава акцентируется на проблеме обеспечения одновременно точности динамического поиска гонок и приемлемого уровня накладных расходов. В четвертой главе излагается концепция синхронизационных контрактов, в пятой главе – её реализация в разработанном нами динамическом детекторе гонок jDRD. Шестая глава посвящена преимуществам и недостаткам подхода и содержит некоторые экспериментальные результаты. В заключении мы подводим итог и указываем дальнейшие возможные направления работы. В приложении описан язык описания контрактов, используемый в jDRD.

2 Happens-before алгоритм поиска гонок

Отношение happens-before было предложено Лесли Лампортом в работе [10] для установления частичного порядка на множестве всех событий распределенной системы, в которой единственный способ взаимодействия

Page 275: TMPA-2013 Conference Proceedings

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

между участниками – это обмен сообщениями. Данный подход хорошо переносится на многопоточные системы, если рассматривать каждый поток как отдельного участника системы, а операции синхронизации – как передачу сообщений. Язык программирования Java был одним из первых языков с собственной архитектурно-независимой моделью памяти, определяющей семантику взаимодействия потоков через отношение happens-before, и распространяющей это отношение на все операции в программе.

Для этого в спецификации Java [9] сначала вводится отношение синхронизированности (synchronized-with) – полное отношение порядка на множестве всех операций синхронизации в программе. Так,

освобождение монитора синхронизировано с его последующими захватами; запись volatile-переменной синхронизирована с ее последующими чтениями; запуск потока синхронизирован с первым действием в потоке; последнее действие в потоке T1 синхронизировано с любым действием в

другом потоке, случившемся после того, как тот обнаружил, что T1 завершился;

прерывание потока T1 синхронизировано с любым действием в другом потоке, которое обнаружит, что T1 получил сигнал прерывания.

События слева (например, захват монитора) будем называть отправкой, а справа (отпускание монитора) – приёмом синхронизационного сообщения. Обратим внимание, что во всех случаях с синхронизационным сообщением естественным образом ассоциирован уникальный объект – монитор, volatile-переменная или объект потока. Поэтому далее будем считать, что с каждой парой синхронизированных событий связан некий уникальный синхронизационный объект.

Объединение отношения синхронизированности с естественным темпоральным отношением порядка в рамках операций одного потока даёт частичное отношение порядка – отношение предшествования (happens-before), определённое уже на множестве всех операций в программе. Факт «событие х произошло перед событием y» записывается как hb(x,y). Само отношение определяется следующим образом:

если x и y – операции в одном потоке, и x произошло раньше y, то hb(x,y); завершение конструктора объекта предшествует запуску его финализатора; если события x и y синхронизированы, то hb(x,y); транзитивность: если hb(x,y) и hb(y,z), то hb(x,z).

Отслеживание отношения happens-before позволяет определить, получил ли некоторый поток информацию о действиях другого потока – например, изменения в разделяемой памяти, новые значения переменных и т.д.

Наконец, спецификация Java формально определяет понятие гонки: два обращения x и y к разделяемой переменной из различных потоков, хотя бы одно из которых – запись, образуют гонку, если ни одно из них не предшествует другому:

Page 276: TMPA-2013 Conference Proceedings

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

DR(x,y) !hb(x,y) ˄ !hb(y,x).

Таким образом, для точного обнаружения гонок в программе достаточно отслеживать конфликтующие обращения различных потоков к разделяемым переменным, не упорядоченные отношением happens-before. Для этого традиционно используются векторные часы (vector clock)1, предложенные в работе [12]. Векторные часы представляют собой динамический массив неотрицательных чисел, равный по размеру количеству потоков в программе. Над векторными часами определена операция слияния:

merge(V1, V2): for each i ∈ [1..n] V1[i] := max(V1[i], V2[i])

Каждый поток хранит свои векторные часы, отражающие его знания о системе: i-я компонента его часов равна последней компоненте i-го потока, которые он наблюдал2. Компонента, соответствующая ему самому, называется собственной компонентой. Изначально собственная компонента часов потока проинициализирована единицей, а остальные – нулями. Перед каждой операцией синхронизации x в потоке T1, собственная компонента часов потока T1 увеличивается на единицу, а часы загружаются в часы соответствующего синхронизационного объекта. Когда в другом потоке T2 происходит событие y, такое что x синхронизированно с y, в часы потока T2 загружаются часы синхронизационного объекта. Это позволяет отследить отношение synchronized-with.

Для отслеживания отношения happens-before нужно проассоциировать векторные часы с каждой разделяемой переменной в программе. Когда поток T1 обращается к такой переменной, он покомпонентно сравнивает свои часы с часами переменной. Если есть компонента часов потока, которая не превосходит соответствующей компоненты часов переменной, обнаружена гонка. Далее поток загружает свои часы в часы переменной.

Если в программе N потоков, то хранение одних векторных часов требует O(N) памяти, и основные операции над ними также имеют сложность O(N). В работе [8] показано, что для отслеживания отношения happens-before вместо полных часов переменной достаточно хранить номер и собственную компоненту потока, который последним обращался к этой переменной. Таким образом, значительная часть операций будет требовать O(1) и снизится количество потребляемой памяти, что позволило алгоритму happens-before достичь уровня производительности менее точных динамических алгоритмов.

3 Точность поиска и накладные расходы

К сожалению, точечные оптимизации алгоритма, хотя и производят безусловный положительный эффект (что подтверждает множество исследований), не могут обеспечить приемлемый уровень накладных расходов 1 Эквивалентное название – логические часы (logical clocks). 2 Не умаляя общности, предполагается, что все потоки пронумерованы от 1 до n.

Page 277: TMPA-2013 Conference Proceedings

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

на приложениях, состоящих хотя бы из нескольких тысяч классов и использующих 10-20 потоков.3 Подавляющее большинство исследовательских работ останавливается на прототипе детектора и модельном тестировании. Подробный обзор состояния предметной области можно найти в работах [1,2]. Нам удалось обнаружить лишь два готовых к использованию детектора (IBM MSDK[16] и TSan[18]), но попытки использовать их на крупных приложениях приводили либо к немедленному отказу, либо к переполнению памяти. О схожих проблемах сообщают также авторы работы [15].

Для обеспечения точности поиска нужно отслеживать все операции обращения к разделяемым данным и все операции синхронизации. Первые можно ограничить путём отсечения областей кода, в которых нас не интересуют гонки – например, сторонние библиотеки или стандартные Java-классы. Для большинства разрабатываемых программных систем решения об использовании сторонних компонент принимаются на стадии проектирования, когда уже известны требования по надежности и безотказности системы, поэтому есть смысл считать, что сторонние компоненты обладают достаточной степенью надежности и концентрироваться на обнаружении ошибок в непосредственно разрабатываемом программном коде и проверке корректности использования сторонних компонент.

Однако исключить таким же образом операции синхронизации нельзя, поскольку их пропуск приведет к неполучению информации о передаче отношения happens-before и, как следствие, к ложным срабатываниям, – детектор будет сигнализировать о гонках, которых в действительности не произошло. Количество этих операций велико и экспоненциально растёт с увеличением количества потоков в программе, что в совокупности с необходимостью отслеживать операции обращения к разделяемым данным в итоге и приводит к описанным эффектам.

4 Синхронизационные контракты

Принцип инкапсуляции в объектно-ориентированном подходе к программированию, которому следует Java, предполагает, что использование объекта осуществляется посредством вызова его публичных методов. Поэтому, в идеале, достаточно иметь возможность описать правила использования методов исключённых классов в многопоточной среде. Возможны следующие варианты:

метод не потокобезопасен, то есть его одновременное использование несколькими потоками не предусмотрено и требует внешней синхронизации;

метод потокобезопасен; он может быть вызван (и в некотором смысле предназначен для этого) несколькими потоками одновременно без внешней синхронизации.

3 Обратим внимание, что характеристики многих промышленных программных систем

могут в десятки и тысячи раз превосходить указанные.

Page 278: TMPA-2013 Conference Proceedings

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

Вызовы методов первого типа необходимо отслеживать и обрабатывать по алгоритму happens-before как обращения к объекту-владельцу метода на чтение, если метод немодифицирующий, или на запись в противном случае. Разработанный нами детектор jDRD трактует по умолчанию все обращения как модифицирующие и предоставляет возможность на уровне конфигурации указать, что некоторые конкретные методы являются немодифицирующими.

С вызовами методов второго типа немного сложней. Вообще говоря, их можно игнорировать, поскольку они предназначены для многопоточного использования. Однако именно в эту группу методов попадают те, которые обеспечивают синхронизацию между потоками. Как правило, такие методы содержатся в классах, созданных как средство обеспечения корректного взаимодействия потоков, что чётко декларировано в их описании. Так, начиная с версии 1.5 в Java появились высокоуровневые средства синхронизации, отличные от захватов/блокировок мониторов и volatile-переменных. В основном они содержатся в пакете java.util.concurrent и его подпакетах.

Например, там есть потокобезопасная хеш-таблица ConcurrentHashMap, которая гарантирует, что вызов метода put по некоторому ключу предшествует последующему вызову метода get на том же объекте по тому же ключу [5].

Более формально, это означает, что между событиями вызова метода put в первом потоке и метода get во втором потоке есть цепочка событий, через которые передается отношение happens-before. Если детектор отслеживает все операции синхронизации, то он обнаружит эту цепочку и вычислит, что эти два вызова методов также упорядочены отношением happens-before.

Теперь предположим, что мы хотим исключить класс ConcurrentHashMap из области анализа – то есть, не отслеживать в нем операции синхронизации. В этом случае детектор не получит информации о том, что вызов put предшествует вызову get. Таким образом, ему её нужно явно сообщить. Отметим, что для этого не подходят аннотации, поскольку в случае библиотечных классов нет возможности модифицировать исходный код. Нами был разработан метод конфигурирования на базе языка xml.

Рассмотрим два метода: метод f(P11, … P1n) объекта O1 и метод g(P21, …, P2m) объекта O2, где n,m ≥ 0. Объект O1 будем называть объектом-владельцем метода f, а O2 – объектом-владельцем метода g. Между этими методами может быть примитивная явная связь одного из трёх типов:

1. связь «владелец-владелец»: O1 == O2, то есть методы принадлежат одному объекту;

2. связь «владелец-параметр»: n > 0, ∃i ∈ [1..n]: O2 == P1i или m > 0,∃j ∈ [1..m]: O1 == P2j, то есть параметр одного метода является объектом-владельцем другого метода;

3. связь «параметр-параметр»: n,m > 0, ∃i ∈ [1..n], j ∈ [1..m]: P1i == P2j, то есть i-й параметр метода f и j-й параметр метода g являются одним и тем же объектом.

Будем называть явной связью комбинацию любого количества примитивных связей.

Page 279: TMPA-2013 Conference Proceedings

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

Будем называть синхронизационным контрактом описание пары явно связанных методов, которые, будучи вызванными в определённом порядке, гарантируют синхронизацию потоков. Рассмотрим пример с классом ConcurrentHashMap. Синхронизационный контракт на методы put и get – это явная связь, образованная из связей первого (речь идёт о методах одной и той же map) и третьего (должен быть один и тот же ключ – первый параметр каждого метода) типа. Описание этого контракта на языке конфигурирования jDRD представлено ниже. Подробное описание языка см. в приложении.

<Sync> <Links> <Link send="owner" receive="owner"/> <Link send="param" send-number="0" receive="param" receive-number="0"/> </Links> <Send> <MethodCall owner="java.util.concurrent.ConcurrentMap" name="put" descriptor="(Ljava/lang/Object;Ljava/lang/Object;) Ljava/lang/Object;"/> </Send> <Receive> <MethodCall owner="java.util.concurrent.ConcurrentMap" name="get" descriptor="(Ljava/lang/Object;)Ljava/lang/Object;"/> </Receive> </Sync>

Рис. 1. Пример синхронизационного контракта.

В качестве примера примитивной связи второго типа можно привести контракт метода execute класса Executor, обеспечивающий асинхронное выполнение задачи. Он принимает в качестве параметра объект типа Runnable и впоследствии вызывает его метод run в другом потоке. Спецификация метода execute гарантирует, что его вызов предшествует последующему вызову метода run объекта, переданного в метод execute в качестве параметра.

В следующем разделе мы представим наш детектор jDRD и реализацию синхронизационных контрактов в нём.

5 Реализация

Для отслеживания различных операций в программе необходимо внедриться в ход её выполнения и перехватывать обращения к методам, переменным и т.д. В Java это традиционно реализуется на уровне байт-кода. Это удобно, поскольку он хорошо структурирован и вместе с тем достаточно просто организован. Кроме того, в отличие от исходного кода, байт-код классов доступен всегда.

Page 280: TMPA-2013 Conference Proceedings

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

JVM (виртуальная машина Java) позволяет подключить к ней компоненту, реализующую особый интерфейс java-aгента, который будет получать управление перед загрузкой очередного нового класса. Агенту передаётся массив байт, содержащий байт-код загружаемого класса, который агент может трансформировать. В jDRD реализован этот интерфейс в отдельной компоненте. jDRD-агент анализирует байт-код загружаемых классов с помощью библиотеки ASM, находит интересующие инструкции (захват/освобождение монитора, обращение к разделяемой переменной, запуск потока и т.д.) и вставляет после них соответствующие внутренние вызовы детектора.

Таким образом jDRD получает информацию об операциях синхронизации и обращениях к разделяемым данным в программе. Далее он обрабатывает их по алгоритму happens-before.

Остановимся подробней на обработке операций синхронизации. Когда jDRD встречает событие отправки синхронизационного сообщения, он должен увеличить собственную компоненту часов потока на единицу. После этого ему нужно сохранить свои часы так, чтобы они были доступны другому потоку, в котором произойдет соответствующее событие приёма синхронизационного сообщения. Как отмечалось выше, с каждым синхронизационным событием можно связать уникальный синхронизационный объект. jDRD пользуется этим фактом, и сохраняет часы потоков в хеш-таблице, ключами в которой являются те самые синхронизационные объекты. Для события освобождения монитора таким ключом будет ссылка на объект-владелец монитора, а для volatile-переменной – пара (название переменной, объект-владелец переменной). 4

Перейдем к отслеживанию синхронизационных контрактов. Их нужно трактовать как высокоуровневые операции синхронизации и ассоциировать с этими операциями искусственный синхронизационный объект. Поскольку описание контрактов содержится в отдельном xml-файле, они читаются и анализируются после запуска детектора. Далее для каждого контракта динамически генерируется класс, сущности которого впоследствии будут использоваться как синхронизационные объекты для данного контракта. Например, для контракта с рис. 1 будет создан следующий класс:

class CompositeKey1 Object o1; //для примитивной связи владелец-владелец Object o2; //для примитивной связи параметр-параметр

Когда jDRD встретит вызов метода ConcurrentMap.put, он обнаружит, что этот метод является частью синхронизационного контракта. В этот контракт входят две примитивные связи, каждая из которых опирается на Object. jDRD отыщет соответствующий класс-ключ (в данном случае это класс CompositeKey1) и

4 Для предотвращения утечек памяти в хеш-таблице используются не обычные

(сильные, strong reference) ссылки на ключи, а слабые (weak reference). Ключевое свойство последних заключается в том, что если на объект остаются только слабые ссылки, то он может быть удалён сборщиком мусора.

Page 281: TMPA-2013 Conference Proceedings

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

создаст новый объект этого типа, который и будет синхронизационным объектом для данного исполнения контракта. Далее часы потока будут увеличены на единицу и записаны в хеш-таблицу. После этого jDRD перестаёт отслеживать операции синхронизации до того момента, когда метод put завершится. Чтобы распространить информацию о том, что отслеживание операций синхронизации в данном потоке стоит приостановить, в векторных часах потока есть переменная-флаг, которая выставляется в true, когда поток входит внутрь контрактного метода и сбрасывается обратно в false при выходе из него. Если контрактный метод вызывается с уже установленным флагом, то флаг оставляется без изменений. Таким образом, сохраняется возможность корректной работы с контрактами различного уровня, часть из которых может быть использована при реализации других. При перехвате любой операции синхронизации jDRD в первую очередь проверяет состояние флага, и если оно равно true, он просто игнорирует эту операцию.

6 Преимущества и ограничения подхода

Алгоритм обнаружения гонок, применяемый в jDRD, базируется на учёте всех отношений happens-before для выяснения корректности производимой операции доступа к данным. Поскольку отношения happens-before при выполнении операций синхронизации, заданные моделью памяти Java, «тотальны» (устанавливают отношение со всеми операциями, предшествующими точке синхронизации), любое событие синхронизации в коде программы имеет неограниченное воздействие на все отслеживаемые переменные и взаимодействующие потоки.

Задача детектора в идеальном случае – проверить корректность исполняемого кода только с учётом явно обозначенных контрактов используемых библиотек. Построение отношения happens-before с учётом всех произошедших операций синхронизации для кода, контракт которого не задаёт явных условий синхронизации, может привести к тому, что код, который с формальной точки зрения недостаточно синхронизирован, будет считаться корректным при рассмотрении всех промежуточных операций. Например, вызов стандартного java-метода System.out.err.print (используется вывода сообщения об ошибке) содержит внутри себя критическую секцию. Если два потока вызывают этото метод поочередно, они синхронизируются между собой, но это является деталью реализации этого метода, побочным эффектом, а не декларированным свойством. Подобные синхронизационные события не только не представляют интереса, но и создают дополнительный «шум», затрудняющий обнаружение гонок.

Таким образом, производимые на основе описанных контрактов изъятия промежуточных синхронизационных событий позволяют не только уменьшить общий объём работы анализатора, но и увеличить вероятность обнаружения гонок в некорректно синхронизированном коде, т.е. повышают точность метода.

Page 282: TMPA-2013 Conference Proceedings

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

Это подтверждается нашими лабораторными экспериментами, которые проводились на трёх приложениях:

JTT – пользовательское клиентское приложение к системе отслеживания ошибок – порядка 400 классов, 10 потоков;

QDTest – нагрузочный тест системы распространения котировок – 700 классов, 15 потоков;

MARS – крупная многоцелевая мониторинговая система – 2000 классов, 30 потоков.

Мы запускали детектор jDRD на нескольких приложениях в двух режимах:

базовый режим – отслеживание операций синхронизации во всём коде программы без использования каких-либо синхронизационных контрактов;

juc-режим – описаны контракты для всех классов пакета java.util.concurrent и для класса sun.misc.Unsafe.

Краткие результаты этих запусков представлены в таблице 1, из которой видно, что использование контрактов снизило количество хранимых векторных часов и количество обрабатываемых операций синхронизации. Это, в свою очередь, снизило нагрузку на приложение и позволило обнаружить больше гонок. Все гонки, обнаруженные в базовом режиме, были также обнаружены и в juc-режиме, что свидетельствует о повышении точности поиска гонок.

JTT QDTest MARS Режим базовый juc базовый juc базовый juc Синхр. оп-ий/сек 115К 28К 7400К 4300К 1650K 800K Кол-во часов 13К 7К 85К 72К 15K 14K Найдено гонок 8 10 1 5 3 7

Таблица 1. Количество обрабатываемых синхронизационных операций в секунду и количество хранимых векторных часов в различных режимах работы jDRD.

C другой стороны, подход обладает рядом ограничений. Во-первых, с помощью предложенных синхронизационных контрактов

возможно описание лишь явно связанных методов. Можно представить себе и неявную связь, но это скорее исключение, чем правило. В пакете java.util.concurrent есть несколько таких методов, например метод newCondition объекта типа Lock. Этот метод возвращает объект типа Condition, внутренне связанный с исходным объектом типа Lock. В этом случае детектор просто «шагнет» внутрь этих классов и будет продолжать анализ.

Во-вторых, jDRD трактует методы, являющиеся частью синхронизационных контрактов, как атомарные, в то время как они таковыми не являются. Операция в программе, которая непосредственно обеспечивает синхронизацию потоков, обычно находится где-то внутри метода и может быть существенно отделена по времени от точек входа и выхода из него. Следовательно, на момент завершения

Page 283: TMPA-2013 Conference Proceedings

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

работы метода информация может быть устаревшей, что может привести к ложным срабатываниям.

7 Заключение

Одной из принципиальных проблем динамического анализа программ является обеспечение сочетания точности и глубины анализа и приемлемого уровня накладных расходов. В задаче автоматического поиска гонок эта проблема особенно актуальна, поскольку количество операций синхронизации и обращений к разделяемым данным очень велико. Если область программы, в которой необходимо отслеживать обращения к разделяемым переменным является скорее вопросом конфигурации и выделения наиболее «интересных» и опасных участков кода, то операции синхронизации нужно отслеживать во всем коде программы, чтобы не пропустить информацию о синхронизации потоков.

В данной работе мы предлагаем концепцию синхронизационных контрактов, в основе которой лежит идея отслеживания не всех операций синхронизации, происходящих в программе, а лишь явно декларированных. Мы вводим понятие синхронизационного контракта как пары явно связанных методов и предлагаем язык для их описания, основанный на xml-нотации. Поддержка и корректная обработка описанных таким образом контрактов была реализована нами в детекторе jDRD, который посредством трансформирования байт-кода внедряется в java-программу, отслеживает в ней важные события (в том числе и методы, описанные в контрактах) и обрабатывает их по алгоритму happens-before. Лабораторное тестирование показывает эффективность использования контрактов – сокращается как количество обрабатываемых операций синхронизации, так и количество векторных часов, которые необходимо хранить для отслеживания отношения happens-before.

Подход обладает рядом ограничений, над устранением которых мы планируем продолжить работу. Также мы проводим внедрение jDRD в процесс разработки ПО и промышленную апробацию, результаты которой надеемся опубликовать в дальнейшем.

Список литературы

1. Трифанов В.Ю., Цителов Д.И. Динамические средства обнаружения гонок в параллельных программах. Компьютерные инструменты в образовании, 5, 2011. С. 3-15.

2. Трифанов В.Ю., Цителов Д.И. Статические и post-mortem средства обнаружения гонок в параллельных программах. Компьютерные инструменты в образовании, 6, 2011. С. 3-13.

3. Choi J., Lee K., Loginov A., O’Callahan R., Sarkar V., Sridharan M. Efficient and precise datarace detection for multithreaded object-oriented programs. In Proceedings of the ACM SIGPLAN 2002 Conference on Programming language design and implementation, 2002. P. 258–269.

Page 284: TMPA-2013 Conference Proceedings

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

4. Christiaens M., Brosschere K. TRaDe: A topological approach to on-the-fly race detection in Java programs. In Proceedings of the 2001 Symposium on Java Virtual Machine Re-search and Technology Symposium, Vol. 1, 2001. P. 105–116.

5. Documentation of java.util.concurrent package, http://download.oracle.com/javase/6/docs/api/java/util/concurrent/package-summary.html

6. Elmas T., Qadeer S., Tasiran S. Goldilocks: A Race and Transaction-Aware Java Runtime. In Proceedings of The 2007 ACM SIGPLAN Conference on Programming Language Design and Implementation (PLDI'07), 2007. P. 245–255.

7. Engler D., Ashcraft K. RacerX: Effective, Static Detection of Race Conditions and Deadlocks. In Proceedings of The Nineteenth ACM Symposium on Operating Systems Principles, 2003. P. 237–252.

8. Flanagan C., Freund S. FastTrack: Efficient and Precise Dynamic Race Detection. In ACM Conference on Programming Language Design and Implementation, 2009. P. 121–133.

9. Java Language Specification, Third Edition. Threads and Locks. Happens-before Order. http://docs.oracle.com/javase/specs/jls/se7/html/jls-17.html#jls-17.4.5

10. Lamport L. Time, Clocks and the Ordering of Events in a Distributed System. Communications of the ACM, Vol. 21, Issue 7, 1978. P. 558–565.

11. Leino K., Nelson G., Saxe J. ESC/Java user’s manual. SRC Technical Note 2000–002, 2001.

12. Mattern, F. Virtual Time and Global States of Distributed Systems. In Cosnard, M., Proc. Workshop on Parallel and Distributed Algorithms, Chateau de Bonas, France: Elsevier, pp. 215–226, 1988.

13. Naik M., Aiken A., Whaley J. Effective Static Race Detection for Java. In Proceedings of The 2006 ACM SIGPLAN Conference on Programming Language Design and Implementation, 2006. P. 308–319.

14. Netzer R., Miller B. What Are Race Conditions? Some Issues and Formalizations. In ACM Letters On Programming Languages and Systems, 1(1), 1992. P. 74–88.

15. Pozniansky E., Schuster A. Efficient On-the-fly Data Race Detection in Multithreaded C++ Programs. In Proceedings of The Ninth ACM SIGPLAN Symposium on Principles and Practice of Parallel Programming, 2003. P. 179–190.

16. Qi Y., Das R., Luo Z., Trotter M. MulticoreSDK: a practical and efficient data race detector for real-world applications. In Proceedings Software Testing, Verification and Validation (ICST), IEEE, 21-25 March 2011. P. 309–318.

17. Savage S., Burrows M., Nelson G., Sobalvarro P., Anderson T. Eraser: A Dynamic Data Race Detector for Multithreaded Programs. In ACM Transactions on Computer Systems, Vol. 15, Issue 4. , 1997. P. 391–411.

18. ThreadSanitizer for Java: a run-time detector of data raceshttp://code.google.com/p/java-thread-sanitizer/

Приложение. Язык описания синхронизационных контрактов.

Для описания happens-before контрактов пар методов различных классов предназначен тег Syncs, содержащий несколько тегов Sync, - по одному на каждый контракт. В описании контракта указываются все примитивные связи, образующие связь между методами (тег Links, содержит по одному тегу на каждую примитивную связь), и описание вызовов методов, являющихся

Page 285: TMPA-2013 Conference Proceedings

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

отправкой и приёмкой отношения happens-before (теги Send и Receive, соответственно).

<!ELEMENT Syncs ( Sync+ ) > <!ELEMENT Sync ( Links, Send, Receive ) > <!ELEMENT Receive ( MethodCall ) > <!ELEMENT Send ( MethodCall ) > <!ELEMENT Links ( Link+ ) >

Вызов метода описывается в теге MethodCall: указывается класс-владелец метода, название метода и его дескриптор во внутренней нотации виртуальной Java-машины (JVM).

Примитивная связь описывается тегом Link:

<!ELEMENT Link EMPTY > <!ATTLIST Link receive (owner|param) #REQUIRED > receive-number CDATA #IMPLIED > send (owner|param) #REQUIRED > send-number CDATA #IMPLIED >

Атрибуты send и send-number соответствуют левой части примитивной связи, а receive и receive-number – правой. Обе они могут быть либо типа «владелец», либо типа «параметр». Если правая часть типа «владелец», то re-ceive имеет значение «owner», а receive-number не указывается. В другом случае receive имеет значение «param», а receive-number содержит номер параметра в сигнатуре метода (нумерация начинается с нуля). Аналогично для атрибутов send и send-number. Пример такого контракта приведён выше на рис.1.

Если нужно описать контракты нескольких пар методов одного и того же класса, это можно сделать с помощью тега Multiple-Syncs, состоящего из нескольких тегов Multiple-Sync, каждый из которых соответствует одному классу. Полное имя класса указывается в атрибуте owner, а связь между вызовами методов описывается в теге Multiple-Links:

<!ATTLIST Multiple-Sync owner ID #REQUIRED > <!ELEMENT Multiple-Syncs ( Multiple-Sync+ ) > <!ELEMENT Multiple-Sync ( Multiple-Links, Call+ ) > <!ELEMENT Multiple-Links ( Multiple-Link+ ) >

Пример такого контракта приведён на рис. 2.

<Multiple-Sync owner="java.util.concurrent.atomic.AtomicBoolean"> <Multiple-Links> <Multiple-Link type="owner"/> </Multiple-Links> <Call type="receive" name="get" descriptor="()Z"/>

Page 286: TMPA-2013 Conference Proceedings

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

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

использованием статического анализа илогического вывода

Татьяна Верт1, Татьяна Крикун1 и Михаил Глухих2

1 Санкт-Петербургский государственный политехнический университет, Россия,[email protected], [email protected],

2 Технический университет Клаусталя, Германия,[email protected]

Аннотация В статье рассматривается один из способов повышенияточности обнаружения дефектов при помощи статического анализа,а именно дополнение классических алгоритмов анализом зависимо-стей. Предлагается в процессе абстрактной интерпретации извлекатьинформацию как об известных статически значениях переменных,так и о зависимостях между неизвестными значениями, представля-емых предикатами логики первого порядка. Это позволяет при про-верке условий наличия дефектов, а также при анализе ветвлений,использовать готовые средства логического вывода для доказатель-ства истинности или ложности соответствующих условий. Основнойупор сделан на логику анализа указателей и на правила обнаружениядефектов работы с указателями. Приведены результаты исследова-ния программного прототипа, использующего Microsoft Z3 Solver вкачестве средства вывода. Показано значительное повышение точ-ности анализа, предложены пути снижения ресурсоёмкости данногометода.

Keywords: обнаружение дефектов работы с указателями, статиче-ский анализ, логический вывод

1 Введение

Проблема обеспечения надёжности программного обеспечения является од-ной из ключевых в современном мире. Известно [6], что даже в хорошоотлаженных программах содержится до 0.7 ошибок на 1000 строк исходно-го кода. Одним из наиболее распространённых классов ошибок являютсяошибки работы с указателями.

Основным методом проверки качества программного обеспечения по-прежнему является тестирование. Не умаляя достоинств данного метода,следует отметить, что тестирование не дает гарантий обнаружения всех

Page 287: TMPA-2013 Conference Proceedings

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

имеющихся в программе ошибок и поэтому в ряде случаев не может яв-ляться единственным методом проверки качества. Подобную гарантию мо-гут предоставить только статические методы, одним из которых являетсястатический анализ кода [23][20].

Ключевыми характеристиками методов обнаружения ошибок в программ-ном коде являются полнота, точность и ресурсоёмкость. Полнота анализавычисляется как доля обнаруженных истинных ошибок среди всех имею-щихся ошибок в программе, а точность —как доля обнаруженных истин-ных ошибок среди всех обнаруженных. Как правило, три данные характе-ристики находятся в противоречии друг с другом, и в средствах обнару-жения ошибок приходится выбирать разумный компромисс. В частности,промышленные средства статического анализа [11] обычно ориентированына высокую точность и низкую ресурсоёмкость, но не гарантируют полно-ту. Исследовательские средства анализа часто стремятся к обнаружениювсех имеющихся ошибок определенного класса, что приводит к понижениюточности и росту ресурсоёмкости; во многих случаях подобные характери-стики препятствуют широкому распространению средств статического ана-лиза [20].

Распространённым алгоритмом статического анализа является абстракт-ная интерпретация [13]. Данный алгоритм подобен обычной интерпретации.Однако, абстрактная интерпретация осуществляет анализ всех путей про-граммы, обеспечивая таким образом полноту анализа. При этом для хра-нения возможных значений переменных используются так называемые аб-страктные семантические домены — в частности, множество целочисленныхинтервалов, множество указателей и т.д. Абстрактная интерпретация допус-кает как раздельный анализ путей программы, имеющий высокую точностьи очень высокую ресурсоёмкость, так и совместный анализ путей, имею-щий приемлемую ресурсоёмкость, но низкую точность за счёт объединениявозможных значений переменных при слиянии путей.

Одним из способов повышения точности при совместном анализе путейявляется дополнение классических алгоритмов анализом зависимостей [19].Зависимостью здесь называется произвольная связь между значениямидвух и более переменных программы; математически, зависимость можетбыть представлена в виде предиката [22]. Анализ зависимостей позволяетполностью или частично компенсировать погрешность, вызванную слияни-ем путей в ходе статического анализа. Для реализации анализа зависимо-стей могут быть использованы готовые методы и средства логического выво-да, такие, как аппарат дизъюнктов Хорна и средства логического програм-мирования [18], логика первого и высших порядков [22], SMT-решатели [3].Подобная возможность позволяет, в числе прочего, упростить другие ис-пользуемые алгоритмы, в частности, использовать анализ точных значенийвместо интервального анализа. В [15] Патрик Кузо рассматривает одну извозможных математических моделей объединения абстрактной интерпрета-ции и логического вывода. Насколько известно авторам статьи, на данный

Page 288: TMPA-2013 Conference Proceedings

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

момент эта модель не реализована в рамках существующих средств стати-ческого анализа.

Ключевой идеей данной работы является использование сочетания ме-тодов статического анализа и логического вывода для обнаружения ошибокв исходном коде. В качестве основной группы ошибок была выбрана некор-ректная работа с указателями, однако предлагаемый подход может бытьрасширен и на другие группы ошибок. В разделе 2 приведён обзор суще-ствующих работ по рассматриваемой тематике. В разделе 3 рассматриваетсяпредлагаемый подход. Раздел 4 посвящен практической реализации подхо-да и проведённым экспериментальным исследованиям. Раздел 5 подводититоги и намечает направления дальнейшего развития подхода.

2 Обзор существующих работ

В настоящее время, известно ряд как коммерческих, так и исследователь-ских средств статического анализа [9]. Ведущим коммерческим средствомобнаружения дефектов методом статического анализа де-факто являетсяплатформа Coverity SAVE [8]. Концептуально данное средство ориентиро-вано на анализ программ произвольного размера и обеспечение высокойточности — от 80% до 90% по данным авторов. Средство не гарантируетполноты анализа, но тем не менее обнаруживает довольно большое количе-ство серьёзных ошибок — порядка 7 ошибок на 10000 строк кода — в реаль-ных программных проектах [11,6]. Подход средства Coverity SAVE основанна извлечении из исходного кода правил использования различных его объ-ектов [17], при этом извлекаются как точные правила вида «указатель P неNULL», так и статистические правила вида «mutex M, возможно, защищаетпеременную V». В дальнейшем эти правила проверяются на непротиворе-чивость с целью обнаружения ошибок в программе.

Исследовательское средство Astree [7] разработано под руководством Пат-рика Кузо. Средство ориентировано на поиск ошибок времени исполнения впрограммах на языке C и было использовано для анализа ряда промышлен-ных программных проектов среднего размера (порядка 100000 строк кода).Согласно [14], средство использует как общеизвестные абстрактные семан-тические домены (целочисленные интервалы, множества указателей), таки ряд доменов, позволяющих отследить зависимости между переменными(в частности, домен октагонов, домен линейных выражений). После разбо-ра исходного кода Astree вначале выполняет ряд простых видов анализа,позволяющих упростить основную задачу (в частности, выявление мёртвыхветвей и переменных), после чего выполняет основной анализ сверху вниз,начиная с точки входа в программу и кончая наиболее простыми функция-ми.

Исследовательское средство Saturn [4] построено на анализе программснизу вверх [10]. Информация, полученная при анализе конкретных функ-ций, используется в точках их вызова и анализ функций не повторяется.Тот же принцип может быть использован при анализе циклов. При ана-

Page 289: TMPA-2013 Conference Proceedings

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

лизе отдельных операторов используется вывод ограничений в различныхточках исполнения программы с последующим запуском SAT-решателя дляопределения логической разрешимости. Для описания правил анализа ис-пользуется язык логического программирования Calypso. Средство можетбыть использовано для анализа больших программных систем, однако, какследует из [16], имеет довольно низкую точность.

Средство PREfix также анализирует программы снизу вверх [21]. Ис-пользуются традиционные алгоритмы анализа потока данных, сопоставле-ния с образцом и некоторые другие. В частности, используется идея хране-ния состояния программы в виде множества точных значений, дополненныхмножеством предикатов [12].

Продукты PC-Lint (для MS Windows) и FlexeLint (для Unix, Linux, MacOS X, Solaris) компании Gimpel Software [5] предназначены для обнаружениядефектов в программах на языках C/C++. Система производит синтакси-ческий анализ исходного кода, анализ потока данных и управления, осу-ществляет межпроцедурный анализ. Используются специальные средствапроверки, в том числе: анализ значений, дополнительная строгая провер-ка типов, определяемая пользователем семантическая проверка аргументовфункции и возвращаемых значений.

Исследовательское средство Aegis [1] анализирует программы сверху вниз.Средство использует анализ указателей, интервальный анализ, ресурсныйанализ; для повышения точности используется также простой анализ зави-симостей [19].

3 Описание разработанного подхода

Предлагаемый подход ориентирован на использование средств верификациии логического вывода для доказательства различных утверждений в ходестатического анализа, в частности, утверждений о наличии либо отсутствиидефектов в отдельных операторах программы.

3.1 Архитектура

Первым этапом выполнения статического анализа является построение мо-дели по исходному коду программы. Наиболее удобной моделью для вы-полнения статического анализа является граф потока управления (ГПУ), внем присутствуют только узлы, соответствующие исполнимым операторампрограммы.

На следующем этапе происходит применение собственно алгоритмов ста-тического анализа с целью определить состояния программы во всех точкахеё исполнения. Алгоритмы, используя известную информацию о семантикеязыка, вычисляют возможные значения всех переменных программы.

На последнем этапе (выполняемым параллельно с предыдущим) рассчи-танные состояния используются алгоритмами обнаружения дефектов длявыявления и локализации имеющихся в программе ошибок.

Page 290: TMPA-2013 Conference Proceedings

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

Для того, чтобы использовать средства логического вывода в ходе аб-страктной интерпретации, необходимо предоставить им входные данные вподходящей для них форме. Один из вариантов подобного представления —хранение состояния программы в виде множества предикатов, с последую-щим использованием данного множества для формирования выводов.

Общая схема анализатора, отражающая структуру предлагаемого под-хода, представлена на рис.1.

Рис. 1. Структура предлагаемого подхода

Данный способ предполагает, что для некоторых переменных хранят-ся их точные на данный момент значения. Если значение данной перемен-ной вычислить статически невозможно, для неё могут храниться различныеусловия, связывающие её значение со значениями других переменных. Та-ким образом, происходит дополнение точных значений зависимостями меж-ду переменными.

Средство логического вывода отвечает за взаимодействие с внешним до-казателем. Предполагается решение двух задач — доказательства истин-ности определенных предикатов и упрощения множества предикатов длясокращения его объёма.

Анализатор, оперируя состоянием программы и результатами вывода,осуществляет поиск дефектов в конкретных операторах.

3.2 Извлечение предикатов

В ходе анализа отдельных операторов программы происходит извлечениеинформации о значениях переменных и связях между ними, представля-емых в виде логических утверждений — предикатов [22][18]. В наиболеепростом случае интерпретация одного оператора приводит к формирова-нию одного предиката, в точности описывающего семантическое преобразо-

Page 291: TMPA-2013 Conference Proceedings

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

вание, выполняемое данным оператором (например, интерпретация опера-торов присваивания).

Предикат в нашем случае представляется в виде формулы p(v1, v2, ..., vn),где p — функциональный символ, а vi, i = 1...n — предикатные переменные.Значение предикатной переменной в большинстве случае соответствует зна-чению одной из переменных программы; примерами подобных предикатовявляются:

– арифметические: сумма sum(a, b, c) (a = b+c), разность diff(a, b, c) (a =b− c);

– предикаты сравнения: равенство equals(a, b) (a = b), больше greater(a, b)(a > b), меньше или равно less_equals(a, b) (a ≤ b);

Допускаются также более сложные предикаты, переменными которыхявляются другие предикаты, в частности, oneof(p1, p2) (истинен хотя быодин из двух предикатов p1, p2), oppos(p) (предикат p ложен) и equiv(p1, p2)(предикаты p1 и p2 одновременно истинны или одновременно ложны). Дан-ные сложные предикаты также могут быть описаны в терминах логики пер-вого порядка (без использования предикатов в качестве аргументов), поэто-му их введение не увеличивает порядок используемой логики. Определениепредикатов, представленное выше, выбрано для простоты реализации.

Одной переменной программы могут соответствовать несколько преди-катных переменных, описывающих её значение в разные моменты выполне-ния. Это требование является важным, поскольку логика первого порядкане предполагает изменение значения задействованных переменных. Поэтомубыло принято решение о представлении переменных на базе статического од-нократного присваивания. Таким образом, при каждом прямом присваива-нии переменная программы, стоящая в левой части, употребляется в новомконтексте, и поэтому для нее создается новая предикатная переменная. На-пример, после интерпретации цепочки операторов вида a=b+c; d=a; a+=eобразуется набор предикатов sum(a1, b1, c1), equals(d1, a1), sum(a2, a1, e1).

Описание логических операций специфично для языка C, поскольку, со-гласно семантике данного языка, логические выражения представляютсяв виде целых чисел. При этом нуль соответствует лжи, а не нуль — ис-тине. Отсюда вытекают такие предикаты, как zero(v) и nonzero(v) (нуль-/ложь, не нуль/истина). Предикаты conj(a, b, c) (a = b && c), disj(a, b, c)(a = b || c) описывают логические операции C, а предикат equiv(p1, p2)может быть использован для связи логических переменных с арифметиче-скими. Например, после интерпретации цепочки g = (a>0); h = (b>=a);f = g && h образуется набор предикатов equiv(nonzero(g1), greater(a1, 0)),equiv(nonzero(h1), greater_equals(b1, a1)), conj(f1, g1, h1).

При интерпретации операторов ветвления if(cond), где cond — выра-жение, из входного состояния образуется два. Если cond не имеет точногозначения, то используется средство логического вывода, которое на основа-нии имеющихся предикатов позволит проверить истинность и/или ложностьусловия. Если какая-то ветвь оказалась мертвой (условие для нее никогдане выполняется), то дальнейший анализ для этой ветви не производится.

Page 292: TMPA-2013 Conference Proceedings

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

После проверки условия в состояние истинной ветви добавляется предикат,соответствующий истинности условия cond, а в состояние ложной ветви —предикат, соответствующий ложности условия cond. В частности, если condявляется переменной, используются предикаты nonzero(cond) и zero(cond)соответственно.

Для снижения количества анализируемых путей применяется объеди-нение состояний программы в точках слияния путей (так называемых фи-функциях) с последующим совместным анализом объединённых путей. Вотличие от других операторов оператор фи-функции имеет два и более вход-ных операторов и соответственно два или более предикатных состояния навходе. Основные правила слияния состояний:

• если одна и та же предикатная переменная vi имеет разные значенияво входных состояниях, то её возможные значения xj объединяются поИЛИ путём добавления предиката oneof(equals(vi, x1), equals(vi, x2));

• если некоторой переменной программы v соответствуют разные преди-катные переменные v1 и v2 во входных состояниях, то для неё создаетсяновая предикатная переменная v3, при этом в выходное состояние до-бавляется предикат oneof(equals(v3, v1), equals(v3, v2));

• все предикаты, входящие во входные состояния, необходимо добавить ввыходное состояние.

Для описания логики работы с составными переменными языка C (струк-турами, массивами) и с указателями на них, используется дополнительныйнабор предикатов:

• элемент сложного объекта arr(a, v, s) — массив (структура) a содержитзначение v по смещению s байт — a[s]=v в случае байтового массива;

• размер сложного объекта sizeof(a, s) — массив (структура) a имеет раз-мер s байт, или sizeof(a)=s;

• указатель на объект ptr(a, p, s) — указатель p указывает на массив (струк-туру, переменную) a со смещением s байт, или p=(void*)(&a)+s;

• разадресация указателя deref(p, v) — значение переменной v равно зна-чению по адресу p, или v=*p;

• корректность указателя correct_ptr(p), incorrect_ptr(p) — указатель pимеет корректное (указывающее на реально существующую перемен-ную) или некорректное (равное нулю, указывающее на несуществующуюпеременную) значение.

При слиянии ветвей в некоторых ситуациях важной является связь меж-ду значением указателей и выражением из условия. В общем случае, еслинекоторая переменная имеет разные значения в разных ветвях условногооператора, предикат, описывающий её значение, следует связать с условиемоператора if для повышения точности. Рассмотрим пример:

1 if(size > 0)2 q = malloc(size);3 else4 q = 0;

Page 293: TMPA-2013 Conference Proceedings

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

После интерпретации данной конструкции состояние в истинной ветви со-держит предикаты: greater(size1, 0), sizeof(dyn, size1), ptr(dyn, q1, 0), гдеdyn — созданный динамически массив. В состоянии ложной ветви имеютсяследующие предикаты: less_equals(size1, 0), equals(q2, 0).

При слиянии двух указанных состояний важна зависимость между зна-чением переменной size, значением указателя q и существованием динами-ческого массива. В дальнейшем при анализе оператора освобождения памя-ти необходимо знать, что динамический массив существует тогда и толькотогда, когда size > 0, или когда q не является нулевым указателем. Поэто-му в выходном состоянии следует учесть эту зависимость.

Таким образом, в момент слияния состояний в разных ветвях оператораусловия указателю q соответствуют разные предикатные переменные q1, q2.Согласно правилам слияния состояний создается новая переменная q3 и длянеё добавляется предикат oneof(equals(q3, q1), equals(q3, q2)). Чтобы учестьзависимость между переменными size и q, в состояние нужно добавитьтакже предикат equiv(less_equals(size1, 0), equals(q3, 0)).

3.3 Правила анализа указателей

Логический вывод осуществляется при помощи некоторого набора акси-ом, на основе которых делаются все логические заключения. В основе всехсредств логического вывода лежит базовый набор аксиом для распростра-нённых теорий, таких как теория целых чисел. Так как теория указателейне является стандартной для средств логического вывода, появляется необ-ходимость в расширении базового набора аксиом. Таким образом, для осу-ществления анализа указателей средствами логического вывода необходимоввести следующие правила:

• правило корректности указателя:

ptr(t, p, s), sizeof(t, v), greater_equals(s, 0), less(s, v)

correct_ptr(p)(1)

указатель p корректен, когда смещение s, с которым он указывает нацель t, не отрицательно и меньше размера v цели t;

• правила разадресации указателя:1)Указатель на простую переменную:

ptr(t, p, 0), deref(p, v)

equals(t, v)(2)

если p указывает на t со смещением 0, то значение v по адресу p равноt;2)Указатель на элемент составного объекта (массива или структуры):

ptr(a, p, s), arr(a, t, s), deref(p, v)

equals(t, v)(3)

если p указывает на a со смещением s, и t находится в a по смещению s,то значение v по адресу p равно значению t.

Page 294: TMPA-2013 Conference Proceedings

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

• правило сложения указателя с целочисленной константой:

ptr(a, p, s), sum(t, s, b), sum(q, p, b)

ptr(a, q, t)(4)

если указатель p указывает на a со смещением s, t равно сумме s и b, ауказатель q равен сумме p и b, то q указывает на a со смещением t.

Эти правила применяются для обнаружения программных дефектов,связанных с использованием указателей.

3.4 Правила обнаружения дефектов

В данной работе особое внимание уделено следующим типам дефектов:

• некорректное использование указателей;• переполнение буферов и выходы за границы массивов.

Некорректное использование указателей — группа дефектов, связанная сразадресацией некорректного или нулевого указателя. Некорректный указа-тель — это указатель, в результате разадресации которого возникает ошиб-ка. Примером некорректного указателя может служить указатель на осво-бождённую память. Процедура обнаружения дефектов при интерпретацииоператоров косвенной записи или косвенного чтения зависит от значенияуказателя. Если разадресуемый указатель имеет точное значение: нулевойуказатель или некорректное значение, то дефект считается обнаруженным.Если указатель не имеет точного значения, то присутствие дефекта в опе-раторе подтверждается путём доказательства разрешимости определённыхпредикатов относительно множества уже существующих предикатов. Таки-ми предикатами являются:

• нулевой указатель: equals(ptr, 0);• некорректный указатель: oppos(correct_ptr(ptr)).

Чтобы показать отсутствие дефекта, необходимо доказать неразрешимостьпротивоположных предикатов:

• ненулевой указатель: not_equals(ptr, 0);• корректный указатель: correct_ptr(ptr).

Обнаружение выхода за границу объекта производится при выполнении опе-рации разадресации *ptr и операции обращения по индексу ptr[i]. Длякаждого значения указателя (obj, shift) следует проверить, что смеще-ние shift ≥ 0 и shift < sizeof(obj). Если это условие доказуемо, то дефектотсутствует, в противном случае дефект считается обнаруженным.

Page 295: TMPA-2013 Conference Proceedings

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

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

Для проведения экспериментальных исследований описанного подхода бы-ло разработано средство-прототип. Для получения графа потока управле-ния из исходного кода программы был использован плагин к компиляторуgcc, в качестве ядра прототипа была использована библиотека статическогоанализатора Aegis [1]. В качестве средства логического вывода был выбранSMT-решатель Z3 [3]. Z3 —это свободно распространяемый SMT решательс открытым исходным кодом, разрабатываемый в Microsoft Research и име-ющий API доступа для множества языков программирования. В настоящеевремя Z3 считается самым мощным средством работы с SMT-предикатамипо данным соревнования SMT-COMP [2].

Исследование проводилось на различных тестовых программах (всегопорядка 30 программ, объем каждой программы 30-50 строк), содержащихи не содержащих дефекты. Данные программы также были протестированыс помощью средства FlexeLint компании Gimpel Software и базовым анализа-тором Aegis, не использующим механизм зависимостей. Сводные результатыанализа приведены в таблице 1.

Таблица 1. Результаты анализа

Средство анализа Точность Полнота Среднее время анализаПрототип 95% 95% 53 секFlexeLint 60% 45% 4 секAegis 68% 75% 5 сек

Приведенные результаты наглядно демонстрируют значительный выиг-рыш в точности анализа в результате ввода правил анализа зависимостей.Недостатком разработанного прототипа являются временные затраты наанализ, которые в зависимости от сложности программы составляли от од-ной секунды до десяти минут.

Наиболее ресурсоемким является анализ циклических участков программиз-за большого количества создаваемых предикатов на каждой итерациицикла. Для снижения ресурсоемкости анализа можно предложить несколь-ко решений. Одним из таких решений является применение алгоритмовсборки мусора. Этот подход подразумевает удаление из состояния програм-мы предикатов, значения которых не используются при проведении даль-нейшего анализа. Другим возможным решением является применение алго-ритмов упрощения состояния программы на основе правил трансформациипредикатов. Применение данного подхода позволит снизить количество вы-зовов внешнего решателя.

Page 296: TMPA-2013 Conference Proceedings

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

5 Заключение

В статье был рассмотрен подход к статическому анализу, основанный накомбинировании анализа точных значений и анализа предикатов с исполь-зованием средств логического вывода. Приведены правила извлечения пре-дикатов из различных операторов анализируемой программы. Разработанылогические правила вывода для анализа указателей и обнаружения дефек-тов работы с указателями. Приведённые алгоритмы анализа реализованыв исследовательском прототипе на базе анализатора Aegis и SMT-решателяMicrosoft Z3. Показано значительное повышение точности по сравнению сбазовым анализатором.

Направления дальнейшего развития данной работы в основном относят-ся к проработке и реализации методов снижения ресурсоёмкости анализа,что сделает возможным применение подхода для анализа промышленныхпрограмм.

Список литературы

1. Aegis static analysis framework. http://www.digiteklabs.ru/en/aegis/platform.2. Smt-comp 2012. http://smtcomp.sourceforge.net/2012/.3. Z3 SMT solver. http://z3.codeplex.com/.4. The saturn program analysis system. http://saturn.stanford.edu, 2006.5. PC-lint and Flexelint static analysis tools. http://www.gimpel.com/html/products.htm,

2011.6. Coverity scan: 2012 open-source report. http://scan.coverity.com, 2012.7. The astree static analyzer. http://www.astree.ens.fr, 2013.8. Coverity save. http://www.coverity.com/products/coverity-save.html, 2013.9. Static analysis tools for c code. http://spinroot.com/static, 2013.

10. A. Aiken, S. Burgara, I. Dillig, T. Dillig, B. Hackett, and P. Hawkins. An overviewof the saturn project. In Workshop on Program Analysis for Software Tools andEngineering, pages 43–48. ACM, 2007.

11. A. Bessey, K. Block, B. Chelf, A. Chou, B. Fulton, S. Hallem, C. Henri-Gros,A. Kamsky, S. McPeak, and D. Engler. A fex billion lines of code later: Using staticanalysis to find bugs in the real world. Communications of the ACM, 53(2):66–75,2010.

12. W. Bush, J. Pincus, and D. Sielaff. A static analyzer for finding dynamicprogramming errors. Software: Practice and Experience, 30:775–802, 2000.

13. P. Cousot. Abstract interpretation. ACM Computing Surveys, 28(2):324–328, 1996.14. P. Cousot, R. Cousot, J. Feret, L. Mauborgne, A. Mine, D. Monniax, and X. Rival.

Combination of abstractions in astree static analyzer. In Proceedings of the 11thAnnual Asian Computing Science Conference (ASIAN’06), pages 272–300, Berlin,2008.

15. P. Cousot, R. Cousot, and L. Mauborgne. Theories, solvers and static analysis byabstract interpretation. Journal of the ACM, 59(6), 2012.

16. I. Dillig, T. Dillig, and A. Aiken. Sound, complete and scalable path-sensitiveanalysis. ACM SIGPLAN notices, 43:270–280, 2008.

17. D. Engler, D. Chen, S. Hallem, A. Chou, and B. Chelf. Bugs as deviant behavior:A general approach to inferring errors in system code. In Symposium on OperatingSystem Principles, pages 57–72. ACM, 2001.

Page 297: TMPA-2013 Conference Proceedings

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

18. Jean H. Gallier. Logic for Computer Science. Foundation of Automatic TheoremProving. Philadelphia, PA, USA, 2003.

19. M. Glukhikh, V. Itsykson, and V. Tsesko. Using dependencies to improve precisionof code analysis. Automatic Control and Computer Science, 46(7):338–344, 2012.

20. B. Johnson, Y. Song, E. Murphy-Hill, and R. Bowdidge. Why don’t softwaredevelopers use static analysis tools to find bugs? In Proceedings of the 2013International Conference on Software Engineering, pages 672–681, 2013.

21. N. Nagappan and T. Ball. Static analysis tools as early indicators of pre-releasedefect density. In Proceedings of the 27th international conference of SoftwareEngineering, pages 580–586. ACM, 2005.

22. W. Rautenberg. A Concise Introduction to Mathematical Logic. New York, NY,USA, 2010.

23. В. Ицыксон и М. Глухих. Программная инженерия. Обеспечение качествапрограммных средств методами статического анализа. Изд-во Политехн.ун-та, СПб., 2011.

Page 298: TMPA-2013 Conference Proceedings

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

1

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

Алефтина Андрианова, Владимир Ицыксон

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

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

одной из основных проблем программной инженерии. Одним из путей, ис-пользуемых для повышения качества программ, является автоматизируемый синтез тестов. В статье предлагается технология автоматизированного созда-ния модульных тестов, комбинирующая подходы "белого" и черного" ящика. При этом для обеспечения покрытия тестами путей программы используется информация, извлекаемая из исходного программы, а для формирования те-стовых оракулов и распределения параметров тестов по области определения используются частичные спецификации, заданные в форме контрактов. Разра-ботанный подход реализован в виде инструментального средства, анализиру-ющего программы на языке Java, и формирующего тест-кейсы для методов классов в формате JUnit, используя COFOJA для задания контрактов. Тестиро-вание разработанного средства на ряде тестовых примеров показало работо-способность подхода.

Ключевые слова: Автоматизированное тестирование программ, синтез те-стов, контрактное программирование, анализ кода, SMT-solver

1 Введение

1.1 Автоматизация тестирования программного обеспечения

Проблема качества программного обеспечения является одной из самых острых в компьютерной индустрии. Огромные ресурсы вкладываются в различные меропри-ятия, направленные на повышение качества выпускаемых программных систем, так как потенциальный ущерб от сбоев программного обеспечения может быть очень велик. Одним из самых распространенных и легко реализуемых методов повыше-ния качества является тестирование. Различные технологии тестирования активно используются практически во всех компаниях, занимающихся разработкой про-

Page 299: TMPA-2013 Conference Proceedings

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

2

граммного обеспечения. Однако, эффективность проведения тестирования опреде-ляется не только количеством разработанных тестов, но и их качеством. Зачастую качество тестов зависит только от профессиональных навыков тестировщика, в то время как требуется, чтобы качество создаваемых тестов больше зависело от разра-ботанного программного обеспечения и спецификации требований. Поэтому в по-следнее время активно развивается направление программной инженерии, связан-ное с автоматизацией синтеза тестов на основе различных проектных артефактов. В качестве таких артефактов в разных исследованиях используются спецификации требований, аннотации, контракты, исходный код программного обеспечения и т.п.

При формировании тестов перед разработчиками встают следующие основные задачи:

обеспечение максимального покрытия тестами программы, при этом обычно рассматривается один следующих критериев покрытия: покрытие операторов, покрытие ветвлений или покрытие путей;

формирование тестов, покрывающих максимально возможный диапазон входных значений функций и методов;

проверка максимально возможного числа требований, предъявляемых к про-грамме.

В данной статье описывается разработанный авторами подход, целями которого было решение перечисленных выше задач. Подход основан на интеграции двух методов тестирования: структурного, базирующегося на анализе исходного кода программы, и функционального, использующего спецификации. Разработаны мето-ды автоматизации создания тестов, учитывающие как внутреннее устройство про-граммы, так и функциональные требования к ней. Для построения модели програм-мы и извлечения трасс выполнения используются методы статического анализа. В качестве спецификаций требований используются контракты, позволяющие описы-вать требования, предъявляемые к отдельным методам и классам. Совместный ана-лиз извлеченных трасс и контрактов позволяет синтезировать комплекты тестов, обеспечивающих покрытие путей программы. Подход реализован в виде инстру-ментального средства генерации тестов на основе анализа Java-программ и системы контрактов CoFoJa[1].

1.2 Результаты

В данной работе получены следующие теоретические и практические результаты:

разработаны принципы генерации тестов, форсирующих прохождения выбран-ной трассы программы;

разработаны методы комплексирования синтеза функционального и структурно-го тестирования, основанные на объединении анализа кода и контрактов;

Page 300: TMPA-2013 Conference Proceedings

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

3

предложены методы формирования множественных тестов для обеспечения по-крытия всей области определения;

разработано инструментальное средство генерации тестов для Java-программ.

1.3 Структура статьи

Оставшаяся часть работы организована следующим образом. Второй раздел содер-жит описание разработанного авторами подхода к генерации тестов. Подробно рас-сматривается построение модели программы, извлечение трасс исполнения и фор-мирование системы утверждений для SMT-солверов, а также генерация множе-ственных тестов. Третий раздел посвящен описанию созданного прототипа генера-тора тестов. В четвертом разделе приводится информация об апробации подхода. Пятый раздел содержит обзор текущего состояния дел в области автоматизирован-ного синтеза тестов на основе анализа программы и учета контрактов. В заключе-нии подводится итог проведенной работы, формулируются направления дальней-ших исследований.

2 Предлагаемый подход

В данной работе предлагается подход к автоматизации создания модульных тестов, обеспечивающий покрытие путей программы. Далее в этой работе не умаляя общ-ности мы будем рассматривать создание тестов для одного метода какого-либо класса. Для обеспечения покрытия путей метода необходимо для каждой возмож-ной трассы исполнения программы сгенерировать такой набор значений аргументов метода, который форсирует прохождение программой этой трассы. То есть необхо-димо так подобрать значения аргументов, чтобы при каждом возможном ветвлении выбиралась требуемая ветвь программы. Построение для заданных значений аргу-ментов соответствующих трасс исполнения является прямой задачей. Вычисление же требуемых значений аргументов метода для удовлетворения заданной трассы - это обратная задача. В общем случае обратная задача - сложная научная NP-полная проблема, требующая решения сложных систем уравнений. В данной статье описы-вается способ решения этой задачи с определенными ограничениями, позволяющий вычислить требуемые значения аргументов за приемлемое время. Если ограничить-ся формированием модульных тестов только на основе критерия покрытия, то по-лученные тесты никак не будут учитывать требования, предъявляемые ко всей про-грамме вообще или к конкретному методу в частности. Чтобы использовать инфор-мацию о требованиях, описанный способ формирования тестов на основе анализа программы может быть расширен с помощью учета спецификаций. Спецификация (или частичная спецификация) может быть задана с помощью контрактов [2]. Ана-лиз предусловий метода и инвариантов класса может сузить множество возможных

Page 301: TMPA-2013 Conference Proceedings

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

4

значений параметров тестов, исключив из них не соответствующие контракту. По-стусловия могут использоваться для формирования заготовки тестовых оракулов, упрощая тем самым работу разработчиков тестов.

Предлагаемый авторами подход подразумевает выполнение следующих шагов:

1. формирование модели программы; 2. формирование списка путей выполнения метода; 3. преобразование каждого пути в цепочку утверждений, верных для этого пути; 4. дополнение цепочки утверждений составляющими контрактов: предусловиями

метода и инвариантами класса; 5. разрешение системы утверждений относительно аргументов метода; 6. формирование экземпляра/экземпляров теста на основе решения системы утвер-

ждений; 7. формирование тестового оракула на основе постусловий метода и инвариантов

класса.

Рассмотрим перечисленные шаги подробнее.

2.1 Модель анализируемой программы

Для извлечения отдельных путей выполнения программы необходимо использовать такую модель, которая с одной стороны содержит все необходимые данные для построения трасс, а с другой стороны является довольно компактной. Так как тре-буется извлекать информацию о динамике программы, то в качестве модели не мо-гут использоваться структурные модели, (например, абстрактное синтаксическое дерево), не содержащие информации о последовательности выполнения операто-ров, использование же гибридных моделей (например, абстрактный семантический граф) неоправданно, так как такие модели слишком избыточны. Среди поведенче-ских моделей программ для решения задачи извлечения путей наиболее подходят модели, основанные на потоке управления, такие как граф потока управления (Con-trol Flow Graph, CFG) или модель статического однократного присваивания (Single Static Assignment, SSA). В данной работе на фазе построения мы ограничиваемся построением классического графа потока управления, элементы же однократного статического присваивания используются позже на этапе преобразования путей в цепочки утверждений.

2.2 Извлечение трасс исполнения

Извлечение трасс исполнения осуществляется с помощью анализа графа потока управления. Для этого применяется рекурсивный алгоритм поиска, выявляющий все возможные уникальные пути от начальной точки к конечной. При этом по-

Page 302: TMPA-2013 Conference Proceedings

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

5

разному обрабатываются узлы, соответствующие вычислительным операторам и операторам ветвления. Для вычислительных узлов в список элементов пути добав-ляются операторы, соответствующие этим узлам. Для узлов ветвления вида "if (con-dition) ..." в список добавляется условие "condition" или "~condition" в зависимости от выбранной при обходе графа ветви условного условного оператора. Таким обра-зом, для каждого пути графа будет собран список операторов и условий, которые должны выполниться для того, чтобы данный путь был пройден.

2.3 Формирование системы утверждений

Для того, чтобы по построенному пути вычислить подходящие значения аргумен-тов, форсирующих выполнение этого пути, необходимо решить обратную задачу. Для этого требуется преобразовать полученный путь в систему уравнений и разре-шить ее относительно аргументов метода. Для этого необходимо для каждого накопленного пути проделать следующие операции:

преобразовать путь в форму однократного статического присваивания (SSA); все присваивания преобразовать в утверждения "равенства"; все условия преобразовать в соответствующие утверждения.

Для того, чтобы построить такую систему уравнений необходимо каждой кон-струкции сохраненной трассы поставить в соответствие алгебраическое уравнение. Для этого все присваивания преобразуются в алгебраические равенства, а сохра-ненные условия веток ветвления в логические утверждения. Кроме того, необходи-мо перейти от переменных языка программирования, утверждения над которыми истинны только в определенном контексте выполнения, к алгебраическим перемен-ным, истинность утверждений над которыми не меняется во времени.

Пример простой программы:

x = 10; y = 20; if (z > 5) x = x + y;

Соответствующая система утверждений для пути, проходящего через ветку “then”:

1: x=10 2: y=20 3: z>5 4: x=x+y

Page 303: TMPA-2013 Conference Proceedings

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

6

Очевидно, что такая система утверждений неразрешима, так как с одной стороны x=10 (строка 1), а с другой стороны x=30 (строка 4). Такая коллизия обусловлена кардинальными семантическими отличиями переменных императивных языков программирования от переменных, используемых в логиках. Для разрешения этой коллизии используется известный подход, применяемый при построении модели SSA, основанный на введении дополнительных алгебраических переменных, отра-жающих состояния переменных языка программирования после выполнения при-сваивания. Такие переменные называются версиями исходной переменной, а сама операция - введением версионирования. Таким образом, после введения версиони-рования каждой верисонированной переменной в системе уравнений значение бу-дет присвоено только один раз. Для приведенного примера система уравнений бу-дет следующей:

1: x1=10 2: y1=20 3: z1>5 4: x2=x1+y1

Полученная таким образом система становится алгебраически разрешимой. Она относится к классу Satisfiability Modulo Theories (SMT) [3]. Как следствие, она мо-жет быть разрешена с помощью какого-либо SMT-солвера. Для этого необходимо:

преобразовать систему утверждений в формат, являющийся входным для SMT-солвера;

запустить SMT-солвер для решения системы уравнений; проинтерпретировать результаты работы солвера.

В случае успеха из результатов извлекаются значения аргументов метода, форси-рующие выполнение указанного пути. Если солвер не смог разрешить систему уравнений, то это свидетельствует либо о наличии в программе “мертвого” кода, либо о некорректности допущений, сделанных при построении модели программы, либо о недостаточной мощности математического аппарата логики первого поряд-ка, либо о недостаточной мощности самого солвера. Во всех случаях будет принято решение о невозможности создания теста для покрытия данного пути.

2.4 Расширение системы утверждений с помощью контрактов

Построенные тесты обеспечивают прохождение программой соответствующих трасс исполнения, при этом значения аргументов методов расположены в области допустимых значений произвольно, в соответствии с правилами вывода решений выбранного SMT-солвера [3]. То есть сгененрированные значения аргументов могут нарушать контракты методов, определяющиеся с помощью предусловий, постусло-

Page 304: TMPA-2013 Conference Proceedings

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

7

вий и инвариантов [2]. Конкретно в данном случае могут нарушаться предусловия методов или инварианты классов. Решение этой проблемы заключается в расшире-нии построенной системы утверждений с помощью инвариантов классов и пред-условий методов. Так как контракты уже задаются в форме утверждений логики первого порядка, то преобразование их в утверждения для SMT-солвера не пред-ставляет никакого труда.

В результате после решения расширенной системы утверждений будут находить-ся аргументы метода, удовлетворяющие контракту анализируемого метода.

2.5 Генерация тестовых оракулов

Для генерации полноценной системы тестов кроме значений аргументов методов необходимо также формировать тестовые оракулы, проверяющие корректность выполнения тестов. Постусловия, используемые в контрактном программировании, являются частью спецификаций методов и задают свойства, гарантируемые мето-дом после его завершения в случае выполнения предусловий. В данной работе мы предлагаем генерировать основу тестовых оракулов на базе постусловий методов и инвариантов классов, как это сделано в работе [4].

Заданные в форме логических утверждений постусловия и инварианты трансли-руются в эквивалентные конструкции на целевом языке программирования и инте-грируются в созданные тесты. При этом у тестировщика остается возможность расширить сгенерированные автоматически оракулы дополнительными проверка-ми.

2.6 Формирование множественных тестов

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

Для этого необходимо для каждого класса эквивалентности генерировать множе-ство тестов, обеспечивающих определенное покрытие области допустимых значе-ний аргументов в соответствии с выбранной эвристикой.

В данной работе реализован метод формирования множественных тестов, осно-ванный на последовательной генерации новых тестов для классов эквивалентности за счет вычисления области допустимых значений для аргументов метода. Исходя из количества тестов, которые должны быть сгененированы для каждого класса

Page 305: TMPA-2013 Conference Proceedings

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

8

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

В дальнейшем авторы предполагают использовать более сложные эвристики для формирования тестовых наборов, более чувствительных к стандартным ошибкам, встречающихся в программах.

3 Описание созданного прототипа

Разработанный подход был реализован в виде инструментального средства генера-ции тестов для языка Java. В качестве системы задания контрактов используется CoFoJa[1]. В качестве SMT-солвера применяется солвер Z3 [3], разработанный Mi-crosoft Research, тесты генерируются в формате JUnit. Общая архитектура системы вместе с артефактами изображена на рис.1. Блоками белого цвета изображены мо-дули, разработанные авторами, серым цветом отмечены сторонние компоненты.

Page 306: TMPA-2013 Conference Proceedings

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

9

Рис. 1. Общая схема системы генерации тестов

На вход системе передается файл, содержащий исходные коды исследуемой про-граммы на языке Java. Построитель AST формирует абстрактное синтаксическое дерево, которое является входом для построителя графа потока управления (CFG Builder). Абстрактное синтаксическое дерево анализируется и на основе семантики языка Java строится граф потока управления. Извлечение трасс исполнения (Path Extractor) осуществляется с помощью анализа графа потока управления. Получен-ные пути преобразуются к форме однократного статического присваивания постро-ителем SSA (SSA Builder). Приведение пути в форму SSA с версионированием поз-воляет рассматривать его как систему алгебраических уравнений. Полученная си-стема утверждений в совокупности с инвариантами класса и предусловиями метода преобразуется к формату SMT-LIB для внешнего SMT-солвера Z3 и передается ему для решения. Генерация тестов осуществляется модулем Test Generator, который использует результаты работы солвера, при этом генерация тестовых оракулов, проверяющих корректность выполнения тестов, осуществляется на основе анализа постусловий метода и инвариантов класса.

Результатом работы системы являются синтезированные модульные тесты, обес-печивающие определенный заданный уровень покрытия исходного кода.

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

Было проведено тестирование разработанного инструментального средства на те-стовом наборе программ. Набор состоял из искусственных тестов и нескольких реальных программ, содержащих различные конструкции языка Java: составные выражения, простые и сложные ветвления, циклы и т.п. Искусственные тесты были призваны проверить корректность функционирования разных возможностей, зало-женных в разработанном анализаторе. Реальные Java-программы использовались для проверки анализатора в реальных условиях функционирования.

На всех искусственных и реальных примерах были получены результаты, соот-ветствующие ожидаемым, а сгенерированные тесты действительно обеспечивали проверку всех путей исследуемых программ. Эксперименты с генерацией множественных тестов также показали работоспособность подхода.

5 Обзор существующих подходов в области синтеза тестов

Различные аспекты автоматизации тестирования программного обеспечения и под-ходы к организации статического и динамического анализа являются популярными направлениями исследований. Существует целый ряд коммерческих и свободно распространяемых средств автоматизации тестирования, фреймворков для органи-

Page 307: TMPA-2013 Conference Proceedings

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

10

зации разработки, систем для синтеза тестов. Многие из них используют в качестве основы подход синтетического структурного тестирования. В этом случае после первого случайно выбранного теста остальные тесты генерируются автоматически так, чтобы обеспечить покрытие еще не покрытых ранее элементов кода. Для выбо-ра подходящих тестовых данных используются решатели, учитывающие символи-ческую информацию об ограничениях на данные, отделяющие прошедшие тесты от еще не покрытого кода, а для построения нужных последовательностей воздействий — случайная генерация, направляемая как этой же символической информацией, так и некоторыми эвристическими абстракциями, уменьшающими пространство состояний проверяемой системы. В рамках этого подхода интегрируются статиче-ский анализ кода, символическое исполнение, структурное тестирование и дедук-тивный анализ, выполняемый решателями. Одними из представителей этого класса являются Microsoft Pex and Moles, два исследовательских проекта, направленных на повышение производительности тестировщиков и качества кода. Microsoft Pex [5,6] – набор инструментов, выполняющих анализ тестируемого кода и подбирающий параметры, которые позволяют покрыть максимально возможный объем кода. Microsoft Pex работает в петле обратной связи: код выполняется не-сколько раз, и производится анализ поведения программы на уровне промежуточ-ного языка .NET CIL (Common Intermediate Language) с помощью мониторинга по-тока управления и потока данных. После каждого запуска Pex выбирает ветвь, ко-торая не была покрыта ранее, создает систему ограничений, которая описывает, как достичь этой ветви, использует решатель Z3 для определения новых значений вход-ных данных, которые удовлетворяют ограничениям, если таковые существуют. Код выполняется снова с новым набором входных значений, и процесс повторяется. В результате работы создается отчет, который можно проанализировать вручную, и набор unit-тестов для дальнейшего использования. Microsoft Moles [6,7] – фрейм-ворк, также разработанный в лаборатории Microsoft Research и позволяющий разра-ботчикам создавать тестовые заглушки и избегать непосредственного вызовов ме-тодов в .NET. Moles расширяет Pex за счет формирования тестового окружения и гибкого манипулирования драйверами и заглушками. Существует ряд ограничений при использовании указанных инструментов. Во-первых, невозможно обнаружи-вать ошибки, которые вносятся при параллельном выполнении задач, во-вторых, указанные средства не могут справиться с недетерминизмом. Это приводит к раз-ным результатам при каждом запуске Pex. В-третьих, Pex и Moles не могут быть использованы для анализа кода, который не работает под управлением .NET. Мно-жество поддерживаемых языков ограничено только языком C#. Возможность ис-пользования внешнего солвера, отличного от Z3, также не предусмотрена. Еще один подход к автоматизации модульного тестирования был предложен C. Engel и R Hähnle. В работе [8] рассматривается метод автоматической генерации тестов для JAVA CARD, базирующийся на формальной проверке выполнения те-стируемого кода. В его основе лежат два подхода к тестированию: по методу “бело-

Page 308: TMPA-2013 Conference Proceedings

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

11

го” и “черного” ящика. Автономные модульные тесты в формате JUnit генерируют-ся автоматически. VBT (verification-based test generation) использует полную ин-формацию, содержащуюся в формальной спецификации и лежащую в основе реали-зацию тестируемого кода (implementation under test, IUT). В качестве языка описа-ния спецификации используется Java Modeling Language (JML). При этом полная функциональная спецификация тестируемого кода не требуется, поскольку генера-ция тестов реализуется на основе символического исполнения, а заданные в пред- и постусловиях ограничения требуются только для синтеза тестовых оракулов. Система Kiasan [9,13] представляет собой механизм символического исполнения для последовательных Java программ, основанный на фреймворке Bogor, использу-ющем технологию проверки модели (model checking). Предложенный подход был позднее расширен в фреймворке KUnit [9], который автоматически генерирует те-сты для контрактно-аннотированых методов и отображает множество объектов (heap objects), получаемых и возвращаемых методами, что может быть использова-но разработчиками для анализа сложных методов и диагностики причин ошибок в программе. Фреймворк KUnit использует тестирование по методу “черного ящика” с помощью генерации входных значений на основе символического исполнения, постусловия используются в качестве тестовых оракулов. При наличии формальной спецификации подход, используемый в KUnit, может реализовывать такие техники тестирования, как: разделение на классы эквивалентности, анализ граничных значе-ний. В общем случае традиционное тестирование обычно не основывается на фор-мальной спецификации, в то время, как KUnit требует формального описания тре-бований. Инструмент Unit Meister [10], разработанный компанией Microsoft, использует сим-волическое исполнение для анализа трасс программы. Подход во многом схож с Kiasan, однако существует ряд отличий. Unit Meister включает функциональные символы для композиционной проверки, в то время, как Kisan допускает только исходные символы, а композиционная проверка осуществляется с помощью специ-фикаций. В то время как Kiasan является полностью автоматическим, Unit Meister, зависимый от решателя системы ограничений, требует от пользователя указания области определения параметров. Symstra [11,12] – еще одно средство символического исполнения для создания ми-нимальной последовательности вызовов публичных методов для проверки класса. Symstra использует примитивные символические значения, конкретные структуры множеств и предполагаемые состояния для генерации неизоморфных конечных состояний. Для генерации подмножества возможных предварительных состояний в Symstra применяются последовательности вызовов публичных методов. В разрабо-танном прототипе предварительные состояния задаются предусловиями и инвари-антами. Пользователь может изменять предусловия и инварианты, более точно определяя их значения.

Page 309: TMPA-2013 Conference Proceedings

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

12

Одним из инструментов, ориентированных на использование контрактных специ-фикаций в процессе создания тестов, является AutoTest framework [4]. Он автомати-зирует процесс тестирования программного обеспечения, опираясь на программы, содержащие инструменты их собственной проверки, в форме контрактов для клас-сов и отдельных методов. Предусловия и инварианты позволяют ограничить мно-жество входных данных для тестирования, постусловия преобразуются в тестовые оракулы. Основная особенность AutoTest заключается в способе генерации тестов. Тестовые последовательность формируются случайно, опираясь только на предсу-ловия методов и инварианты классов. Успешность прохождения тестов анализиру-ется в тестовых оракулах. Отдельно стоит отметить механизм Test Extraction, кото-рый автоматически создает тесты по результатам отказов программы. Основными ограничениями подхода являются отсутствие гарантий покрытия путей (из-за сугу-бо случайной генерации тестов), а также поддержка только языка Eiffel и среды EiffelStudio. Все рассмотренные подходы подтверждают эффективность интеграции различных методологий процесса тестирования на практике. Тем не менее, несмотря на до-стигнутые успехи, каждый из имеющихся подходов использует лишь часть имею-щегося потенциала, ограничен анализом программ, написанных на каком-то опре-деленном языке программирования, и не предоставляет единой интеграционной платформы для всего многообразия различных техник верификации ПО. Кроме того, большинство из рассмотренных подходов являются академическими и непри-менимы для анализа сложных программных систем. [14,15].

6 Заключение

В результате проведенного исследования разработан подход к синтезу тестов для языка Java, обеспечивающих покрытие трасс исполнения методов. Разработанные методы с помощью применения SMT-солвера генерируют параметры модульных тестов, форсирующие реализацию заданных трасс исполнения. Учет контрактов методов позволяет с одной стороны с помощью постусловий частично автоматизи-ровать синтез тестовых оракулов, а с другой с помощью предусловий ограничивать генерацию параметров тестов. Применение разработанного на основе подхода про-тотипа на наборе тестовых примеров показало полную работоспособность предло-женных методов. Основными направлениями развития теоретических и практических исследований являются:

разработка новых алгоритмов генерации множественных тестов, более эффек-тивно распределяющих значения переменных по области определения;

совершенствование анализатора (прототипа) с целью обеспечения анализа более широкого класса Java-программ;

Page 310: TMPA-2013 Conference Proceedings

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

13

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

Литература

1. Contracts for Java. https://code.google.com/p/cofoja/ 2. Meyer, B.: Design by Contract, in Advances in Object-Oriented Software Engineering, eds. D.

Mandrioli and B. Meyer, Prentice Hall, 1991, pp. 1–50 3. Z3 An Efficient SMT Solver. http://z3.codeplex.com/ 4. B. Meyer, I. Ciupa, A. Leitner, A. Fiva, Yi Wei, E. Stapf: Programs that Test Themselves,

IEEE Computer, vol. 42, no. 9, pages 46-55, September 2009 5. Nikolai Tillmann and Jonathan De Halleux. Pex: white box test generation for .net. In Proceed-

ings of the 2nd international conference on Tests and proofs, TAP’08, pages 134–153, Berlin, Heidelberg, 2008. Springer-Verlag

6. Pex and Moles. http://research.microsoft.com/en-us/projects/pex/ 7. Unit Testing with Microsoft Moles. http://research.microsoft.com/en-

us/projects/pex/molestutorial.pdf 8. Engel, C., Hähnle, R.: Generating unit tests from formal proofs. In: Gurevich, Y. (ed.) Proceed-

ings, Testing and Proofs, Zürich, Switzerland. LNCS, Springer,Heidelberg, 2007 9. Deng, X., Robby, Hatcliff, J.: Kiasan/KUnit: Automatic Test Case Generation and Analysis

Feedback for Open Object-oriented Systems. In: Proceedings of the Testing: Academic and In-dustrial Conference Practice and Research Techniques, Washington, 2007

10. Nikolai Tillmann, and Wolfram Schulte. Parameterized unit tests with unit meister. ESEC/SIGSOFT FSE, page 241-244. ACM, 2005

11. T. Xie, D. Marinov, W. Schulte, and D. Notkin. Symstra: A framework for generating object-oriented unit tests using symbolic execution. In TACAS ’05: 11th International Conference on Tools and Algorithms for the Construction and Analysis of Systems, volume 3440 of LNCS, pages 365–381. Springer-Verlag, Apr. 2005

12. Symstra: A Framework for Generating Object-Oriented Unit Tests using Symbolic Execution. http://people.engr.ncsu.edu/txie/publications/tacas05.pdf

13. Robby: Bogor/Kiasan: Combining symbolic execution, model checking, and theorem proving. Presentation at European Science Foundation Exploratory Workshop on Challenges in Program Verification, University of Nijmegen (October 2006)

14. J. Henkel and A. Diwan. Discovering algebraic specifications from Java classes. In ECOOP ’03: European Conference on Object-Oriented Programming, pages 431–456, 2003

15. T. Robschink and G. Snelting. Efficient path conditions in dependence graphs. In ICSE ’02: Proceedings of the 24th International Conference on Software Engineering, pages 478–488, New York, NY, USA, 2002. ACM Press

Page 311: TMPA-2013 Conference Proceedings

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

ДИАГРАММЫ КЛАССОВ ООП:

ФОРМАЛИЗАЦИЯ И АНАЛИЗ

Дмитрий Буй1, Сергей Компан2

Киевский национальный университет имени Тараса Шевченка, Украина[email protected], [email protected]

Аннотация В статье приводится короткий сравнительный анализ ра-

бот, посвящённых формальным моделям объектно-ориентированного про-граммирования (ООП). Предмет исследования – модель диаграммы клас-сов (соответствующее частично упорядоченное множество). Модель клас-

са (спецификация класса) —- пара бинарных функциональных отноше-ний, одна компонента уточняет атрибуты, вторая — методы. Наследова-ние уточняется как включение графиков функций. Над классами вво-

дятся две операции –– пересечение и сочленение. Формальные резуль-таты: структура частично упорядоченного множества классов, свойстваоперации наложения, в терминах которой вводится операция сочле-

нения: идемпотентность, ассоциативность, критерий коммутативности.Модель диаграммы классов можно использовать для анализа структу-ры классов, который может помочь для выделения подсистем клонов и

оптимизации самой диаграммы.

Ключевые слова: формальные модели ООП, диаграммы классов, специфи-кация класса, операции над классами, клон

1. Вступление

Основы объектно-ориентированного подхода (ООП) были заложены в кон-це 60-х годов. В основе ООП лежит объектная модель данных (ОМД). По-явление ОМД связано с появлением абстрактных типов данных. В 1971 годуПарнас (D. L. Parnas) в работе [1] предложил идею инкапсуляции (сокрытияинформации). В 80-х годах ХХ столетия Г. Буч (G. Booch) в своей книге [2]предложил использовать идеи ООП для разработки программных продук-тов промышленного уровня. Благодаря ООП появилась потенциальная воз-можность выхода из кризиса, связанного с проектированием и реализациейсложных программных систем (ПС). Таким образом, ООП стало очереднойступенью к созданию методов разработки надежных ПС. В результате уско-рился процесс создания программных комплексов, в основе которого лежатпринципы ООП, а так же качественно снизился уровень сложности разра-ботки ПС.

Согласно ООП предметная область (ПрО) представляется как множествообъектов со свойствами, которые необходимы для определения и идентифи-кации объектов, а также описаниями их поведения в рамках выбранной си-стемы понятий на зафиксированном уровне абстракции. Предметная область,

Page 312: TMPA-2013 Conference Proceedings

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

которая моделируется объектами, сама является объектом и поэтому можетбыть отдельным объектом в составе другой ПрО. При моделировании объектПрО получает хотя бы одно свойство, необходимое для его идентификациив множестве объектов ПрО [3]. В основе ООП лежат: абстракция, инкапсу-ляция, наследование, полиморфизм. Язык программирования, в котором ре-ализованы эти понятия, является объектно-ориентированным и именно онипридают языку гибкость при программной реализации сущностей ПрО.

2. Краткий анализ современного состояния ООП

Сразу необходимо заметить, что в связи с популярностью ООП как сред-ства проектирования и разработки ПС существует достаточное количествосоответствующей литературы [2–11]. Следует отметить ряд работ заведу-ющей отделом Института программных систем НАН Украины, профессораЛаврищевой Е.М. [3,10,12], в которых уделяется большое внимание проекти-рованию и программированию систем, в основе которых лежит ООП. Авторпредлагает выделять четыре уровня абстрактного представления объектноймодели (ОМ): обобщающий, структурно-упорядоченный, характеристическийи поведенческий. На каждом из этих уровней применяется свой математиче-ский аппарат [10].

Отметим, что существует группа OMG (Object Management Group), воснове деятельности которой лежит пропагандирование и стандартизацияООП. Эта группа описала набор стандартов OMA (Object Management Archi-tecture). Самым известным и широко применяемым на сегодняшний деньявляется CORBA (Common Object Request Broker Architecture) —- специфи-кация взаимодействия разнотипных объектов в распределенной системе [13].В данной модели для описания понятий применяется декларативный языкопределения интерфейсов IDL (Interface Definition Language).

Для полной уверенности в том, что информационная система, построеннаяна основе ООП, будет удовлетворять исходным спецификациям и стабильноработать (будет гарантоустойчивой по терминологии [14]), необходимо выде-лить компоненты системы, формально их описать и верифицировать. В ре-зультате возникла необходимость формального определения понятий объек-та, класса, операций над объектами и т.д. Для ООП построены формальныемодели. Например, в работе [15] формально даётся определение основныхпонятий ООП: класса, объекта, наследования, инкапсуляции, полиморфизмас использованием математического аппарата теории множеств, функций, аб-страктных автоматов (в этой же работе приводится обширная библиографияпо ООП). В работе [16] авторы строят формальную модель для объектныхбаз данных (БД), в основе которой лежит теория категорий. В [17,18] даныформальное определение основных понятий ООП, в основе определения кото-рых лежит композиционное программирование, созданное академиком НАНУкраины В. Н. Редько [19–21].

Особое внимание следует уделить вопросу построения объектной моделидля объектных БД, так как в основе более-менее сложной информационной

Page 313: TMPA-2013 Conference Proceedings

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

системы лежит именно БД. Широкое распространение ООП резко обозна-чило проблему семантического разрыва между моделью языка программиро-вания и моделью представления данных в БД. Объектная модель позволяетоперировать сложными структурами данных. В результате системы управле-ния базами данных (СУБД) стали развиваться в трех направлениях. Пер-вое — это построение отображения объектов в традиционную реляционнуюмодель данных. Второе — включение понятий ООП в реляционные СУБД пу-тем расширения типов данных, используемых в БД. Третье направление -—создание принципиально новых, объектно-ориентированных СУБД, которыев своей работе следуют стандарту ODMG [22].

В [23] авторы формально строят модель данных, в которую входят: ко-нечное множество основных типов D, счетное множество объектных иден-тификаторов O, множество имен атрибутов A, множество имен методов M ,множество имен классов C. Так как объект может содержать в себе данные,то различают примитивные значения (atomic values) и сложные значения(structured values). После этого авторы приводят синтаксическое описаниекласса (неформальное). Даётся формальное определение метода, который яв-ляется функцией, отображающей сигнатуру в тело функции. Сигнатура фор-мально описывается следующим образом — c : m(τ1, τ2, . . . , τn) → τr , где c -–имя класса, которому принадлежит метод, m —- имя метода, τ1, τ2, . . . , τn —список типов параметров и τr — тип возвращаемого значения. Также в статьеупоминается простое наследование, которое формально не определено. При-водится формальное определение объекта, который задаётся тройкой (o, ν, c),где o ∈ O —- идентификатор объекта,v — значение объекта, c ∈ C — класс,которому принадлежит объект. Также приводится формальное определениеобъектной БД. БД содержит схему (Schema) и экземпляры схемы (Instances).Схема описывается тройкой (C, σ,G), где C — как и ранее множество именклассов БД, σ — функция, которая сопоставляет именам классов собственноклассы, G — множество глобальных переменных классов. Множества C и G

выступают в качестве точки входа в БД.

Экземпляры схемы БД содержат конечное множество объектов и четырефункции: πd — назначает объектам уникальные объектные идентификато-ры (oid), π -— функция, которая по объекту определяет идентификатор oid,присвоенный объекту функцией πd, υ — функция, которая сопоставляет объ-ектным идентификаторам значения всех находящихся в БД объектов, γ -—функция, которая присваивает значения глобальным переменным объектов.

Вкратце обсудим построение объектной алгебры. По аналогии с реля-ционной моделью данных, в основе которой лежит реляционная алгебраКодда, для ООП также рассматривают так называемую объектную алгеб-ру, носителем которой является множество объектов [23–25]. Различаютсяэти алгебры только сигнатурными операциями над объектами. В [26] авторывводят операции пересечения и сочленения (в работе она называлась объ-единением) над классами. В результате предлагается рассматривать вместообъектной алгебры алгебраическую систему. Формально ее можно описатькак < O,K;Ωobj ;Ωspec,≤>, где O -— множество объектов классов, K -—

Page 314: TMPA-2013 Conference Proceedings

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

множество классов (спецификаций классов), Ωobj — множество операцийнад объектами, Ωspec -— множество операций над классами, а отношение≤⊆ K × K —- отношение частичного порядка, которое уточняет отношениенаследования классов.

3. Постановка задачи

Рис. 1. Диаграмма классов ПрО “Школа”

Построение новой сложной системы, как правило, сопряжено с нетриви-альными усилиями. В результате для построения сложной системы можнопойти двумя путями. Первый предполагает реализацию системы с нуля. Притаком подходе одним из критериев успешного выполнения проекта являетсявремя реализации. Как правило, ограничение авторского коллектива во вре-мени приводит к тому, что для проверки правильности программ коллективвыбирает тестирование вместо построения формальной модели и доказатель-ства правильности работы такой формальной модели. Второй путь предпола-гает изучение уже реализованных подобных систем, с целью переноса рабо-тоспособной части функционала в новую систему. При таком подходе, еслион целесообразный, мы можем эффективно использовать уже работающиекомпоненты других систем, при этом мы можем столкнуться с ситуацией,

Page 315: TMPA-2013 Conference Proceedings

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

Рис. 2. Диаграмма классов ПрО “ВУЗ”

при которой в новую систему могут попасть “одинаковые” (в том или иномсмысле) части кода (атрибуты и методы) — т.н. клоны. Для уменьшения из-быточности кода (устранения клонов) в программе авторы статьи предлагаютвыносить общие части программы (атрибуты и методы) в новые классы, со-вокупность которых будет выступать аналогом FrameWork.

При моделировании ПрО авторы не берут смелость утверждать, что ПрОсмоделирована в полной мере. Главная цель данного моделирования — пока-зать идею использования операций над классами.

Пусть необходимо написать программу “Учебное заведение”, которая мо-жет использоваться как в школе, так и в ВУЗе. К примеру, пусть проведён-ный анализ созданного ПО по данной ПрО показал, что существуют готовыерешения для школы (рис. 1) и для ВУЗа (рис. 2), но которые реализовываюттолько часть нашей ПрО. Для реализации нашей задачи можно объединить(сочленить) функциональные части исходных программ в одну. В результа-

Page 316: TMPA-2013 Conference Proceedings

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

те получим новую диаграмму классов (рис. 3), относительно которой сделаемнесколько замечаний. Как указывается в обзоре [27] клоны могут быть удале-

Рис. 3. Диаграмма классов ПрО “Школа и ВУЗ”

ны с использованием операций “выделение метода” (Extract Method) и “Подъ-ем метода” (Pull Up Method), изложенных в монографии [28]. Выделениеметода (в русскоязычной литературе называемое процедурной абстракцией)заключается в выделении общего кода в новую функцию (или метод класса,если речь об ООП). Подъем метода заключается в перемещении общего мето-

Page 317: TMPA-2013 Conference Proceedings

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

да двух классов в их базовый класс. Если два класса не являются потомкамиодного базового класса, то перед операцией Подъема метода можно создатьновый базовый класс при помощи операции выделения родительского клас-са (Extract Superclass) [29]. В нашем подходе могут быть также выделеныи общие атрибуты. Фактически своими преобразованиями над спецификаци-ями классов мы изменяем внутреннюю структуру программ, не затрагиваяих поведения и в какой-то степени улучшаем понимание кода. Целью рабо-ты является разработка теории ООП при минимальных предположениях оэтой ПрО. Мы разделяем атрибуты и методы и рассматриваем функции, ко-торые присваивают атрибутам и методам семантику (пока не уточняя какуюименно семантику; это будет сделано при последующей конкретизации). Мынадеемся, что формальные результаты, представленные в следующем разделе,обосновывают право на существование выбранного нами уровня абстракции.По сути, в работе реализован принцип “разделяй и властвуй”.

4. Математические результаты

Приведем формальное уточнение класса (синоним — спецификации клас-са). Под классом будем понимать пару < s, µ >, где s —- функциональноебинарное отношение, которое атрибуту ставит в соответствие его тип (множе-ство значений из универсального домена D), а µ —- функциональное бинар-ное отношение (функция), которое сигнатуре метода ставит в соответствиеего реализацию (семантику, логику). Можно рассматривать µ как функцио-нальное бинарное отношение, которое сигнатуре метода ставит в соответствиеего тип; в этом случае получим определение интерфейса.1

Отношение наследования ≤ между классами уточняется так:< s, µ >≤< s′, µ′ >, если s ⊆ s′ и µ ⊆ µ′.

Приведем несколько определений, которые понадобятся в дальнейшем приизложении материала.

Определение 1. Пусть α,β — функциональные бинарные отношения, то-гда операция наложения определяется так: αβ = β

⋃α | (domα \ domβ),

где domα и domβ области определения соответственно функций α и β, аγ | X — ограничение функции γ по множеству X, т.е. γ | X = γ

⋂(X×π2

2γ)(π2

2γ — проекция отношения γ по второй компоненте).

Наложение иллюстрируется на рис. 4.

Уточним бинарную операцию сочленения∐

и пересечения ∩ классов.Обозначим K — множество классов, K ∈ K — класс. Операция сочлененияявляется операцией вида:

∐: K × K → K, где < s1, µ1 >

∐< s2, µ2 >=

=< s1s2, µ1µ2 >.

1 Несмотря на то, что тип метода входит в сигнатуру, нам для построения функци-онального бинарного отношения необходимо разделять (считать разными) методы,сигнатура которых отличается только типом возвращаемого значения. Такой подход

необходим для исследования интерфейсов.

Page 318: TMPA-2013 Conference Proceedings

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

dom dom

Рис. 4. Графическая интерпретация операции наложения αβ (β имеет прио-ритет

Операция сочленения классов∐

уточняет множественное наследованиеклассов. При сочленении классов K1 и K2 получим новый класс K3, длякоторого классы K1 и K2 будут базовыми (родительскими) классами, а классK3 будет играть роль производного. В производном классе K3 классы K1

и K2 являются дополнением (расширением) одного к другому. Рассмотримважнейшие частные случаи:

1) doms1⋂doms2 = ∅ и domµ1

⋂domµ2 = ∅ — т.е. в классах-аргументах

нет одинаковых атрибутов и методов. Тогда получим производный классвида K3 =< s1

⋃s2, µ1

⋃µ2 >;

2) doms1⋂doms2 = ∅ или (и) domµ1

⋂domµ2 = ∅. Тогда возникает кон-

фликт имен и нужно определить по определённому критерию (прави-лу), какой именно атрибут (метод) необходимо добавлять в производныйкласс; конфликт разрешается с помощью операции наложения.

Операция пересечения классов является операцией вида:∩ : K × K → K, где < s1, µ1 > ∩ < s2, µ2 >=< s1

⋂s2, µ1

⋂µ2 >, здесь

⋂—

обычное теоретико-множественное пересечение. При пересечении классов K1

и K2 получим новый класс K3, для которого классы K1 и K2 будут произ-водными, а класс K3 будет играть роль базового (суперкласса). Классы K1 иK2 являются дополнением (расширением) суперкласса.

Сделаем несколько замечаний по поводу введенного определения класса.Если первая компонента класса < s, µ > пуста (т.е. s = ε — пустое бинар-ное отношение), то получим определение библиотеки. Если же проекция повторой компоненте отношения µ (т.е. π2

2µ) является множеством множеств,которые интерпретируется как области значений функций-семантик методов,то получим определение интерфейса.

Определение 2. Бинарное отношение совместности ≈ в классе функцио-нальных бинарных отношений вводится так: α ≈ β ⇔ α | X = β | X, гдеX = domα

⋂domβ.

Содержательная интерпретация: функциональные отношения совместны, ес-ли они ведут себя одинаково на общих аргументах.

Page 319: TMPA-2013 Conference Proceedings

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

При доказательстве свойств операций над классами и установлении струк-туры семейства классов будут использоваться следующие абстрактные свой-ства ограничения [30]. Ниже U1, U2, . . . — произвольные бинарные отноше-ния, X,X1, . . . — произвольные множества, α, β, . . . — как и ранее, произ-вольные бинарные функциональные отношения. Параметрический операторU → U | X обозначен через ↑ X , — традиционная композиция бинарныхотношений, π2

iα — проекция бинарного отношения по i-той компоненте.

Предложение 1 (свойства ограничения). Ограничение имеет свойства:

1) U1 ⊆ U2 ∧ X1 ⊆ X2 ⇒ U1 | X1 ⊆ U2 | X2 (монотонность ограничения,монотонность оператора ↑ X);

2) π21(U | X) = π2

1U⋂X (проекция ограничения);

3) U | X = ε ⇔ π21U

⋂X = ∅ (критерий пустоты ограничения); в частно-

сти, ε | X = U | ∅ = ε (сохранение ограничением пустого отношенияи пустого множества);

4) U | X = U | (X⋂π21U), U = U | π2

1U ; в частности,π21U ⊆ X ⇒ U | X = U ;

5) (U | X) | Y = U | (X⋂Y ), в операторном виде ↑ Y ↑ X =↑ (X

⋂Y )

(композиция ограничений);в частности, ↑ X ↑ X =↑ X (идемпотентность оператора ↑ X);

6) U | X ⊆ U (оператор ↑ X убывающий);7) оператор ↑ X является оператором замыкания (т.е. монотонным,

убывающим и идемпотентным оператором) относительно теоретико-множественного включения ⊆;

8) (⋃i

Ui) | X =⋃i

(Ui | X), U |⋃i

Xi =⋃i

(U | Xi) (дистрибутивность

ограничения относительно объединений);9) (

⋂i

Ui) | X =⋂i

(Ui | X), U |⋂i

Xi =⋂i

(U | Xi) (дистрибутивность

ограничения относительно пересечений);10) α ⊆ β ∧ X ⊆ domα ⇒ α | X = β | X; в частности, α ⊆ β ⇒ α = β |

domα, α ⊆ β ∧ domα = domβ ⇒ α = β;

Очевидно, что операция наложения, вообще говоря, некоммутативная. Такимобразом, возникает вопрос о поиске соответствующего критерия. Ответ при-веден в следующем утверждении.

Предложение 2 (критерий коммутативности операции наложения). Дляпроизвольных функциональных бинарных отношений α и β выполняетсяэквивалентность α ≈ β ⇔ αβ = βα.

Следствие 1. Пусть α, β –– функциональные бинарные отношения. Тогдаимеют место следующие эквивалентности:αβ = βα ⇔ αβ = α

⋃β

αβ = βα ⇔ βα = β⋃α.

Следствие 2 (критерий совместности функций). Пусть α, β —- функци-ональные бинарные отношения. Тогда следующие утверждения эквива-лентны:

Page 320: TMPA-2013 Conference Proceedings

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

1) α ∪ β — функциональное бинарное отношение;

2) αβ = βα;

3) αβ = α ∪ β;

4) α ≈ β;

5) βα = β ∪ α.

Доказательство. Доказательство проводится с использованием свойства от-ношения совместности ≈ [31]: α ≈ β ⇔ α

⋃β функциональное бинарное

отношение.

Для проведения доказательств последующих утверждений важна следующаялемма.

Лемма 1. Пусть α, β —- функциональные бинарные отношения. Тогдаα

⋂β = (α

⋂β) | (domα

⋂domβ).

Следствие 3. Для функциональных бинарных отношений α, β выполняют-ся две эквивалентностиα ≈ β ⇔ dom(α

⋂β) = domα

⋂domβ,

α ≈ β ⇔ dom(α⋂β) ⊂ domα

⋂domβ.

Следствие 4. Для функциональных бинарных отношений α, β выполня-ются две эквивалентностиα ≈ β ⇔ α

⋂β = α | (domα

⋂domβ),

α ≈ β ⇔ α⋂β = β | (domα

⋂domβ).

Следующее следствие дополняет cледствие 2.

Следствие 5 (критерий совместности функций). Пусть α, β —- функци-ональные бинарные отношения. Тогда следующие утверждения эквива-лентны:

1) α ≈ β;

2) dom(α⋂β) = domα

⋂domβ;

3) α⋂β = α | (domα

⋂domβ);

4) α⋂β = β | (domα

⋂domβ). ;

Что касается самой операции наложения, то ее свойства приведены в следу-ющем утверждении.

Предложение 3 (свойства наложения). Пусть α, β —- функциональныебинарные отношения. Тогда имеют место следующие утверждения:

1) αα = α (идемпотентность);

2) αβ = βα, вообще говоря;

3) αβ = βα ⇔ α ≈ β (критерий коммутативности);

4) (αβ)γ = α(βγ) (ассоциативность).

Page 321: TMPA-2013 Conference Proceedings

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

Доказательство. Докажем только 4 пункт. Будем использовать очевидноеравенство dom(αβ) = domα

⋃domβ. Используя определение наложения и

свойства ограничения (предложение 1) имеем цепочку равенств:

(αβ)γ = (β ∪ α | (domα \ domβ))γ =

= γ ∪ (β ∪ α | (domα \ domβ)) | (domα ∪ domβ) \ domγ =

= γ ∪ (β ∪ α | (domα \ domβ)) | ((domα \ domγ) ∪ (domβ \ domγ)) =

= γ ∪ β | (domα \ domγ) ∪ β | (domβ \ domγ) ∪ α | (domα \ domβ) |

| (domα \ domγ) ∪ (α | (domα \ domβ)) | (domβ \ domγ) =

= γ ∪ β | (domα \ domγ) ∪ β | (domβ \ domγ) ∪ α |

| (domα \ domβ)∩ (domα \ domγ)∪α | (domα \ domβ)∩ (domβ \ domγ) =

= γ ∪ β | (domα \ domγ) ∪ β | (domβ \ domγ) ∪ α |

| domα \ (domβ ∪ domγ) ∪ ε = γ ∪ β | (domβ \ domγ) ∪ α |

| (domα \ (domβ ∪ domγ)) ∪ β | (domα \ domγ) =

= γ ∪ β | (domβ \ domγ) ∪ α | (domα \ (domβ ∪ domγ)). (1)

Прокомментируем неочевидные переходы. Переход от первого выраженияко второму и от второго к третьему сделали по определению наложения; припереходе от третьего к четвертому выражению воспользовались стандарт-ным теоретико-множественным свойством (A ∪ B) \ C = A \ C ∪ B \ C; припереходе от четвертого к пятому выражению — дистрибутивностью ограни-чения относительно объединений (предложение 1); при переходе от пятогок шестому — свойством ограничения (α | A) | B = α | (A ∩ B) (предложе-ние 1); при переходе от шестого к седьмому — теоретико-множественнымравенством (A \ B) ∩ (A \ C) = A \ (B ∪ C) и свойством ограничения α |((domα \ domβ) ∩ (domβ \ domγ)) = α | ∅ = ε (предложение 1); при переходеот восьмого к девятому — свойствами ограничения (предложение 1)α | B = α | (domα ∩ B),A ⊆ B ⇒ α | A ⊆ α | B иβ | domα \ domγ = β | domβ ∩ (domα \ domγ) ⊆ β | domβ \ domγ.Перейдем к правой части равенства:

α(βγ) = α(γ ∪ β | (domβ \ domγ)) =

= γ ∪ β | (domβ \ domγ) ∪ α | (domα \ (domβ ∪ domγ)). (2)

Из (1), (2) и вытекает доказываемое равенство.

Пусть F — класс всех функциональных бинарных отношений (на некото-ром зафиксированном универсуме D). Очевидно, что < F,⊆> — частичноупорядоченное множество (ч. у. м.). Перейдем к установлению его структу-ры. Здесь имеют место два следующих утверждения (для ч. у. м. используемтерминологию [32]).

Предложение 4. Ч. у. м. < F,⊆> есть нижняя полурешетка, причем inff, g =f ∩ g.

Page 322: TMPA-2013 Conference Proceedings

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

Доказательство. Доказательство следует из того, что < F,∩ > есть комму-тативная идемпотентная полугруппа, и хорошо известной связи между таки-ми полугруппами и нижними полурешетками,(см., например, [32]).

Таким образом, в терминах классов наибольшая общая часть двух классовсуществует всегда, но она может быть пустой. Более полную информацию оч. у. м. < F,⊆> даёт следующее утверждение.

Предложение 5 (структура ч. у. м. < F,⊆>). Выполняются следующие утвер-ждения:

1) Всюду неопределённая функция f∅ — наименьший элемент (“дно”)ч. у. м. < F,⊆>.

2) Наибольший элемент в ч. у. м. < F,⊆> существует тогда и толькотогда, когда универсум D — не больше чем одноэлементный.

3) Точная нижняя грань (инфимум) существует для любого непустогомножества F , причем inf F = ∩f∈Ff .

4) Точная верхняя грань множества F (супремум) существует тогдаи только тогда, когда множество F ограничено сверху, при этомsupF = ∪f∈Ff .

5) Элемент f является атомом тогда и только тогда, когда график f —одноэлементный, т.е. f есть функцией вида f : x → y.

6) Ч. у. м. < F,⊆> является условно полным ч. у. м. и полной (верхней)полурешеткой (complete semilattice).

Так как отношение наследования ≤ на классах вводится покомпонентно (эк-вивалентно: операцией прямого произведения порядков), то свойства ч. у. м.< F,⊆> переносятся на ч. у. м. < K,≤>: например, < f∅, f∅ > — наимень-ший элемент и т.д.

Приведем соответствующий классический результат (см., например, [33]).Пусть < D1,≤1>, < D2,≤2> — два ч. у. м. Их прямое произведение опре-деляется стандартно: < D1 × D2,>, где < d1, d2 >< d′1, d

2 >⇔ d1 ≤1

d′1 ∧ d2 ≤2 d′2. Для точных граней имеют место формулы:

sup LD1×D2

≃< supD1

π21L, sup

D2

π22L >, (3)

inf LD1×D2

≃< infD1

π21L, inf

D2

π22L >, (4)

L ⊆ D1 ×D2.

Здесь ≃ обобщенное равенство (сильное равенство Клини). Формулы (3) и(4) и позволяют переносить свойства ч. у. м. < F,⊆> на ч. у. м. < K,≤>.

Приведённые формальные результаты могут иметь практическое значениепри анализе диаграмм классов. Это во-первых, выделение компонент связно-сти в соответствующем графе (по терминологии [32] речь идет о разложе-нии ч. у. м. в кардинальную сумму). Выделение компонент соответствует де-композиции системы на подсистемы. Во-вторых, в диаграмме классов можно

Page 323: TMPA-2013 Conference Proceedings

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

проводить поиск клонов для их элиминации (по этой проблематике см. [29]).Наконец, в-третьих, диаграмму классов можно подвергнуть модификации спомощью операций сочленения и пересечения с целью оптимизации по соот-ветствующему критерию.

5. Результаты, выводы

В работе приведен короткий анализ доступной библиографии по ООП,уточняются классы ООП в виде пар функциональных бинарных отношений.Бинарное отношение, являющееся первой компонентой, атрибутам приписы-вает их типы (значения); отношение, являющееся второй компонентой, сиг-натурам методов приписывает их семантику (тип значений функции — се-мантики для интерфейса).

Над классами рассматриваются операции пересечения и сочленения. Пе-ресечение классов вводится на основе стандартного теоретико-множественногопересечения бинарных отношений, а сочленение — на основе специальнойоперации наложения, которая позволяет разрешить конфликт имен. Указан-ные операции над классами могут быть использованы при рефакторинге(refactoring) программ.

Наследование классов уточняется в виде стандартного теоретико-мно-жественного включения между соответствующими компонентами классов. Вработе получены следующие основные математические результаты:

– установлены основные свойства наложения (идемпотентность, ассоциа-тивность, критерий коммутативности в терминах отношения совместно-сти);

– структура ч. у. м. множества всех функциональных бинарных отношений,упорядоченного по включению (это ч. у. м. является нижней полурешет-кой; всюду неопределённая функция является наименьшим элементом;инфимумы непустых подмножеств существуют всегда, супремумы под-множеств существуют тогда и только тогда, когда подмножества ограни-чены с верху; для точных граней приведены формулы их нахождения).

Предложенная формальная модель может использоваться для анализа имодификации диаграмм классов:

– нахождения компонент связности, что соответствует декомпозиции систе-мы на подсистемы;

– поиска клонов;

– модификации диаграмм с помощью введенных операций пересечений исочленения.

Что касается дальнейших математических исследований, имеющих содержа-тельную интерпретацию, то это, например, установление взаимной дистрибу-тивности рассматриваемых операций.

Page 324: TMPA-2013 Conference Proceedings

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

Список литературы

1. Parnas, D. On the Criteria to Be Used in Decomposing Systems into Modules, inClassics in Software Engineering. Magazine Communications of the ACM, Volume

15, Issue 12, Dec. 1972, p. 1053–1058 (1972)

2. Буч Г. Объектно-ориентированный анализ и проектирование с примерами при-ложений, 3-е изд. : Пер. с англ. Москва: ООО “И.Д. Вильямс”, 2008. —- 720 с.(2008)

3. Лаврищева Е.М. Методы программирования: теория, инженерия, практика. Ки-ев: Наукова думка, 2006. —- 451 с. (2006)

4. Wirfs-Brock R. Designing Object-Oriented Software. Prentice Hall, New Jersey,

1990. —- 341 p. (1990)

5. Шлеер С. Объектно-ориентированный анализ: моделирование мира в состояниях.Киев: Диалектика, 1993. —- 238 с. (1993)

6. Бадд Т. Объектно-ориентированное программирование в действии. Питер,1997. — 464 с. (1997)

7. Гамма Э. Приемы объектно-ориентированного проектирования. Паттерны проек-

тирования. СПб: Питер, 2001. —- 368 с. (2001)

8. Мухортов В. В. Объектно-ориентированное программирование, анализ и дизайн.Методическое пособие. Новосибирск, 2002. — 108 с. (2002)

9. Грэхем И. Объектно-ориентированные методы. Принципы и практика. 3-е изда-ние. Москва: ООО “И.Д. Вильямс”, 2004. —- 880 с. (2004)

10. Лаврищева Е.М. Сборочное программирование. Основы индустрии программных

продуктов. Киев: Наукова думка, 2009. — 371 с. (2009)

11. Фридман А. Л. Основы объектно-ориентированной разработки программных си-стем. Москва: “Финансы и статистика”, 2000. — 192 с. (2000)

12. Лаврищева Е.М. Интерфейс в программировании. Киев: Проблеми програму-вання, 2, 2007. С. 126–139 (2007)

13. The Common Object Request Broker: Architecture and Specification -– OMG,

www.omg.org/spec/CORBA/3.3/

14. Безопасность критических инфраструктур: математические и инженерные ме-тоды анализа и обеспечения / под ред. Харченко В.С. – Министерство об-разования и науки Украины, Национальный аэрокосмический университет им.Н. Е. Жуковского “ХАИ”, 2011. — 641 с. (2011)

15. Пискунов А. Г. Формализация парадигмы объектно-ориентированного програм-

мирования, www.realcoding.net/dn/docs/machine.pdf

16. Richta, Karel,Toth, David. Formal Models of Object-Oriented Databases. In Objekty2008. Zilina: Zilinska univerzita v Ziline, Fakulta riadenia a informatiky, 2008,p. 204-217, www.ksi.mff.cuni.cz/ richta/publications/richta-toth-Objekty2008.pdf

17. Buy, Dmitriy, Kompan, Sergiy. The Concepts of Object, Class, Inheritance, Life

Cycle: Formalization. First International Workshop “Critical infrastructure safetyand security” (CrlSS-Dessert’11), Kirovograd, Ukraine, May 11-13, 2011, p. 236-244 (2011)

18. Буй Д.Б., Компан С. В. Уточнення множинного успадкування у виглядi операцiї

накладання. Вiсник Київського нацiонального унiверситету iменi Тараса Шев-ченка, Серiя: Фiзико-математичнi науки, випуск 4, 2012, c. 111-119 (2012) (наукраинском языке)

19. Редько В. Н. Композиции программ и композиционное программирование. Про-

граммирование. — 1978. — 5. С. 3-24 (1978)

Page 325: TMPA-2013 Conference Proceedings

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

20. Редько В. Н. Основания композиционного программирования. Программирова-ние. — 1979. — 3. С. 3-13. (1979)

21. Редько В.Н. Экзистенциальные основания композиционной парадигмы. Кибер-

нетика и системный анализ. — 2008. — 2. С. 3-12 (2008)22. Object Data Management Group. http://www.odbms.org/odmg/23. Sarkar, Manojit, Reiss, Steven P. A Data Model and A Query

Language for Object-Oriented Database. Island, Department ofComputer Science Brown University Providence, Rhode, December 1992,citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.34.4531&rep=rep1&type=pdf

(1992)24. ShawGailM., Zdonik Stanley B. A Query Algebra for Object-Oriented

Databases. Island, Department of Computer Science. Brown University

Providence, Rhode, March 1989, trac.common-lisp.net/elephant/raw-attachment/wiki/RelationalAlgebra/shaw89query.2.pdf

25. Suri, Pushpa R., Rani, Sudesh. Database Algebras. Journal of Theoretical andApplied Information Technology, 2005, p. 595-602, www.jatit.org/volumes/research-

papers/Vol4No7/7.pdf26. Буй Д.Б., Компан С.В. Операции объединения и пересечения спецификаций

классов в многосортной алгебраической системе для объектно-ориентированного

программирования. Сборник научных трудов SWorld. Материалы международнойнаучно-практической конференции “Современные проблемы и пути их решенияв науке, транспорте, производстве и образовании’2012”. — Выпуск 4. Том 3. —

Одесса: КУПРИЕНКО, 2012. —- ЦИТ: 412-1264, c. 45-49 (2012)27. Roy C.K. A survey on software clone detection research // SCHOOL OF

COMPUTING TR 2007-541, QUEEN’S UNIVERSITY. 2007. — Vol. –115. (2007)

28. Фаулер М. Рефакторинг. Улучшение существующего кода. — Символ-Плюс,2008. (2008)

29. Булычев П.Е. Алгоритмы вычислений подобия в задачах верификации и ре-

структуризации программ. Диссертация на соискание ученой степени кандида-та физико-математических наук: спец. 05.13.11 “Математическое и программ-ное обеспечение вычислительных машин, комплексов и компьютерных сетей” —

Москва: 2010. — 169 с. (2010)30. Буй Д. Б., Кахута Н.Д. Властивостi теоретико-множинних конструкцiй повного

образу та обмеження. — Вiсник Київського унiверситету iм. Т. Шевченка. Сер.

“Фiз.-мат. науки”, 2005. — Вип. 2. С. 157-170 (2005) (на украинском языке)31. Буй Д. Б. Властивостi вiдношення конфiнальностi та устрiй множини частко-

вих функцiй. / Д.Б. Буй, Н.Д. Кахута // Вiсник Київського унiверситету

iм. Т. Шевченка. Сер. “Фiз.-мат. науки”, 2006. — Вип. 2. С. 125-135 (2006) (наукраинском языке)

32. Скорняков Л.А. Элементы теории структур. — Москва: “Наука”, 1982. — 158 с.

(1982)33. Burbaki. N. Elements de Mathematique. Premiere Partie. Les Structures

Fondamentals de L’Analise. Livre 1. Theorie Des Ensembles. Chapter III, section 1.

1958 (1958)

Page 326: TMPA-2013 Conference Proceedings

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

Page 327: TMPA-2013 Conference Proceedings

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

Партнеры TMPA-2013

Page 328: TMPA-2013 Conference Proceedings
Page 329: TMPA-2013 Conference Proceedings
Page 330: TMPA-2013 Conference Proceedings

ISTQB. Наша миссия.

• Мы пропагандируем значимость тестирования программного обе-спечения как профессии среди частных лиц и организаций.

• Мы помогаем тестировщикам программного обеспечения быть бо-лее эффективными и результативными в своей работе за счет обуче-ния и сертификации компетенций.

• Мы предоставляем тестировщикам возможность карьерного роста за счет многоуровневой сертификации, которая дает навыки и знания, необходимые для выполнения возрастающих обязанностей, а также возможность достижения высшего профессионализма.

• Мы постоянно улучшаем Свод знаний по тестированию, опираясь на наилучшие практики в отрасли и самые инновационные исследова-ния, и мы делаем эти знания свободно доступными для всех.

• Мы устанавливаем критерии аккредитации образовательных учреж-дений для обеспечения полноценного предоставления Свода знаний во всем мире.

• Мы регулируем содержание и охват экзаменационных вопросов, процесс сдачи экзаменов и выдачу сертификатов официальными органами сертификации.

• Мы являемся открытым международным сообществом, стремимся к обмену знаниями, идеями и инновациями в тестировании программ-ного обеспечения.

• Мы поддерживаем отношения с научными кругами, правительства-ми, СМИ, профессиональными объединениями и другими заинтере-сованными сторонами.

Page 331: TMPA-2013 Conference Proceedings

ISTQB ® может рассчитывать на 45 коллегий-членов, представляющие 69 стран, которые обеспечивают более 90% всемирного ВВП

Российская Коллегия по Квалификации Тестировщиков Программного Обеспечения (RSTQB)

www.rstqb.org [email protected] www.fb.com/rstqb

Page 332: TMPA-2013 Conference Proceedings
Page 333: TMPA-2013 Conference Proceedings
Page 334: TMPA-2013 Conference Proceedings

В связи с развитием промышленного и жилищного строительства транспортные потоки через город Кострому в последние годы резко увеличились. Город расположен на обоих берегах реки Волги, которые связывает единственный автопешеходный 4-х по-лосный мост, построенный еще в 70-е годы прошлого столетия.Ближайшие мосты через реку Волга находятся в соседних субъектах Российской Федерации - городе Ярославле и городе Кинешме Ивановской области.Мост в Костроме имеет не только общегородское и региональное, но и федеральное значение, так как связывает крупнейшие города Центра России с Уралом и Сибирью по маршруту Москва – Ярославль – Кострома – Киров – Пермь – Екатеринбург и далее.Ежедневно через мост проходит свыше 43 000 единиц транспорта. В часы пик пробки на въезде на мост создают угрозу транс-портного коллапса. Кроме того, ограниченность пропускной способности моста, являющегося главной городской транспортной артерией, тормозит развитие жилищного и промышленного строительства в городе Костроме.В связи с ежегодно увеличивающейся нагрузкой и несвоевременным проведением ремонтов состояние моста в настоящее время близко к критическому.На проведение капитального ремонта, по оценкам специалистов, необходимо от 500 до 700 млн. рублей. Данные денежные сред-ства в городском и областном бюджетах отсутствуют. Вместе с тем проведение капитального ремонта моста не решит вопрос увеличения его пропускной способности.Решением данной транспортной проблемы может стать строительство в городе Костроме в дополнение к существующему второго 6-полосного автопешеходного моста через реку Волга с возможностью организации движения троллейбусов. Новый мост позволит перераспределить транспортные потоки, направив весь транзитный и грузовой транспорт на объездную автодорогу. Кроме того, наличие надежного транспортного сообщения будет способствовать экономическому развитию региона, откроет благоприятные перспективы для расширения инфраструктуры, сделает город удобным для граждан и привлекательным для бизнеса.Строительство нового моста предусмотрено генеральным планом развития города Костромы, с учетом его возведе-ния проектируется улично-дорожная сеть города. В то же время без выделения денежных средств из федерального бюджета строительство нового моста невозможно.

Практический результатСтроительство нового автопешеходного моста через реку Волга в городе Костроме позволит создать условия для бесперебойного свободного движения транспорта по трассе федерального значения Москва – Киров – Екатеринбург, а также будет способствовать развитию эко-номики Костромской области и города Костромы.

Page 335: TMPA-2013 Conference Proceedings
Page 336: TMPA-2013 Conference Proceedings
Page 337: TMPA-2013 Conference Proceedings
Page 338: TMPA-2013 Conference Proceedings
Page 339: TMPA-2013 Conference Proceedings
Page 340: TMPA-2013 Conference Proceedings

Они — больничные клоуны. Они приходят к тяжелобольным детям и проводят с ними время: играют, показывают фокусы, отвлекают, насколько это возможно, от ежедневной боли, которую они испытывают. Когда дети смеются, им проще пережить больничную атмосферу. Друзья! Они очень нуждаются в информационной поддержке своего проекта! Простой перепост новостей поможет в распро-странении информации и расскажет о больничной клоунаде все большему числу людей. А также, если у кого-то есть жела-ние и возможность разместить информацию о них или ссылку на их сайт www.medclown.ru на каком-либо интернет ресурсе - они будут вам очень благодарны! Вместе мы сможем сделать больше! Автономная некоммерческая организация помощи детям, оказавшимся в тяжелых жизненных обстоятельствах, «Больничные Клоуны» или сокращенно — АНО «Больничные Клоуны». Они помогают в реабилитации детей, находящихся на стационарном лечении. Помогаем средствами клоунады, арт-терапии и игротерапии: не лекарствами, а путем создания по-зитивных эмоций. АНО «Больничные Клоуны» является первой и единственной в России профессиональной организацией, практикующей регулярную и системную реабилитацию детей с помощью средств больничной клоунады. Данный вид реабилитации

Друзья!ПоддержимэтихЧеловеков!

Page 341: TMPA-2013 Conference Proceedings

детей с тяжелыми заболеваниями широко используются во всех странах мира, а так же имеет научно-доказанное положительное влияние на самочувствие детей. Присутствие больничных клоунов в детских отделениях в России одобрено ведущими медицинскими учреждениями страны, такими как: Российская детская клиническая больница, Федеральный научно-клинический центр им. Д.Рогачева, Центр трансплантации костного мозга им. Р.Горбачевой, — во всех этих, как и в других учреждениях 5 регионов России, АНО «Больничные Клоуны» ведет регулярную и эффективную работу в составе медицинской команды.

Сайт проекта: http://www.medclown.ru

Page 342: TMPA-2013 Conference Proceedings

Прогнозы развития отрасли информационных технологий указывают на взрывной рост сегмента робототехники к 2025 г. При этом речь идёт не столько о специальной и промышленной робототехнике, сколько о персональной и сервисной - роботы в быту, вокруг нас.

Преследуя стратегические цели, правительства многих государств (США, Германия, Южная Корея, Япония, Израиль, Иран и других) уже вкладывают средства в подготовку специалистов будущего через финансирование соответствующих образовательных программ и исследований в сфере робото-техники.

Кроме того, использование роботов на уроках в школе положительно зарекомендовало себя, поскольку позволяет противостоять мощной современной индустрии развлекательных гаджетов. Для школьников и студентов робототехника является наглядным и очень увлекательным способом изучения механики, математики, кибернетики (теории управления), программирования, технологии и даже физики. Поэтому использование элементов робототехники в образовании - набирающая обороты мировая тенденция, известная как «STEM Robotics».

Проект ТРИК: создавая будущее Я.А. Кириленко, Р.М.Лучин, КиберТех,

www.trikset.com

Page 343: TMPA-2013 Conference Proceedings

Как результат многолетнего использования робототехники в школах и вузах для преподавания и научных разработок, нам стало очевидно следующее.

В популярных наборах зачастую используется морально устаревшая электроника. Это не позволяет в вузе использовать недорогие робототехнические наборы для решения современных задач, а в школе приводит к быстрой потере школьниками интереса к работе с такими конструкторами (как только в руки попадает современный смартфон). Если говорить о подготовке специалистов будущего, то тем более преступно использовать технологии, которые уже сегодня устарели или близки к этому. Отдельной проблемой является отсутствие у многих наборов официального свободного ПО для программирования собранных моделей.

Цена лицензии ПО для школ и вузов у популярных производителей конструкторов иногда даже превышает стоимость комплектов.

Силами инициативной группы преподавателей СПбГУ при участии партнёров был создан проект ТРИК, направленный на создание новой унифициро-ванной робототехнической платформы широкого применения, построенной на следующих принципах:

Примеры студенческих моделей под управлением контроллера ТРИК.

Page 344: TMPA-2013 Conference Proceedings

• мощный контроллер, позволяющий подключать доступные в магазинах электроники моторы и датчики, обеспечивающий достаточную вычислительную мощность для современных задач, включая обработку видео;

• набор металлических деталей и механизмов,

позволяющих, с одной стороны, быстро собирать

базовые образовательные модели, а с другой стороны, заниматься полноценным техническим творчеством. Удобнее всего использовать стандарт 10мм, известный как «совметалконструктор», чтобы легко расширять элементную базу за счет обычных конструкторов, доступных в магазинах;

• среда программирования, позволяющая собирать программы из картинок (пиктограмм), проводить виртуальные эксперименты (имитационное моделирование) и программировать контроллер. Для образовательных целей в среде программирования должен быть предусмотрен поэтапный переход к

Page 345: TMPA-2013 Conference Proceedings

текстовому программированию. Желательна реализация инструментария, достаточного для подготовки к ЕГЭ. Среда обязательно должна быть свободно распространяемым ПО;

• методические материалы, позволяющие преподавателю начать вести занятия, буквально впервые получив коробку.

• Из разработанного нами набора ТРИК можно легко собрать и запрограммировать балансирующий робот-сегвей или тележку с манипулятором, снабдив их “интеллектом”: с голосовым управлением или распознаванием образов. Контроллер ТРИК позволяет конструировать даже автономные беспилотные летательные аппараты и создавать инновационные «умные» решения автоматизированного сервиса в различных областях: домашние теплицы, ав-томатические барные стойки, робот-швейцар и пр.

Простота и удобство сборки моделей и программирования делают конструктор ТРИК доступным даже для школьников. Использование сложных математических алгоритмов, например, определения лица человека, распознавания голосовых команд и пр., происходит с помощью готовых пикто-грамм в визуальной среде. Кроме того, при программировании моделей могут использоваться любые языки, а открытость платформы на всех уровнях позволяет специалистам модернизировать ПО под свои задачи по желанию.

ТРИК помогает школьникам приобщиться к самым передовым технологиям на увлекательных занятиях, вузам – проводить исследования на переднем крае прикладной науки, а творческим коллективам – реализовывать перспективные разработки. В результате уже сейчас можно утверждать, что разработанная нами унифицированная робототехническая платформа ТРИК получилась удобным инструментом, помогающим не только увлекательно учиться, но и непосредственно создавать наше общее будущее.

Page 346: TMPA-2013 Conference Proceedings
Page 347: TMPA-2013 Conference Proceedings

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

Научное издание

ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММTOOLS & METHODS OF PROGRAM ANALYSIS

TMPA-2013Материалы

Международной научно-практической конференции10—12 октября 2013

Подписано в печать 16.10.13 Формат бумаги 60×90Печать трафаретная. Печ. л. 11, 125. Заказ 50. Тираж 500.

Редакционно-издательский отделКостромского государственного технологического универси-

тета

Адрес редакции:156005, г.Кострома, ул. Дзержинского, 17.

31-15-21 E-mail: [email protected]

Page 348: TMPA-2013 Conference Proceedings

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

www.tmpaconf.org


Related Documents