On 10-12 October 2013, Kostroma, Russia, will host 2013 International Workshop-Conference “Tools & Methods of Program Analysis” (TMPA-2013).
Its general theme will be one of the most pertinent and important areas of software engineering: the analysis of software quality.
The issues of efficiency and correctness of software are key for the majority of knowledge-intensive industries in modern economy, including IT, financial sector, transportation, medicine, high-technology industries, and many others. The development of new instruments and methods of program analysis, as well as the modification of existing ones, is one of the necessary prerequisites for introducing innovation.
The purpose of the conference is to promote progress in the software development industry and the introduction of the latest achievements in the areas of testing, analysis and verification.
The conference program will include plenary reports and mini-courses delivered by experts; presentations selected by the Program Committee; presentations of on-going projects, short reports about new ideas, research that is still underway or new tools.
The program will include, and won’t be limited to, the following topics:
- software test automation;
static program analysis;
verification;
dynamic methods of program analysis;
testing and analysis of parallel and distributed systems;
testing and analysis of high-load and high-availability systems;
analysis and verification of hardware and software systems;
methods of building quality software;
tools for software analysis, testing and verification.
Презентация на конференции Software People 2009. Предлагается простой и практичный метод оценки трудозатрат в проектах разработки ПО, позволяющий количественно учесть риски в сроках работ, оперировать прогнозами в условиях высокой неопределенности, а также дающий инструменты проверки достоверности прогноза при помощи метрик.
Презентация на конференции Software People 2009. Предлагается простой и практичный метод оценки трудозатрат в проектах разработки ПО, позволяющий количественно учесть риски в сроках работ, оперировать прогнозами в условиях высокой неопределенности, а также дающий инструменты проверки достоверности прогноза при помощи метрик.
TMPA-2015: Lexical analysis of dynamically formed string expressionsIosif Itkin
Lexical analysis of dynamically formed string expressions
Marina Polubelova, Semyon Grigorev, Saint Petersburg State University, Saint Petersburg
12 - 14 November 2015
Tools and Methods of Program Analysis in St. Petersburg
TMPA-2015: Lexical analysis of dynamically formed string expressionsIosif Itkin
Lexical analysis of dynamically formed string expressions
Marina Polubelova, Semyon Grigorev, Saint Petersburg State University, Saint Petersburg
12 - 14 November 2015
Tools and Methods of Program Analysis in St. Petersburg
TMPA-2015: Implementing the MetaVCG Approach in the C-light SystemIosif Itkin
Alexei Promsky, Dmitry Kondtratyev, A.P. Ershov Institute of Informatics Systems, Novosibirsk
12 - 14 November 2015
Tools and Methods of Program Analysis in St. Petersburg
TMPA-2015: Information Support System for Autonomous Spacecraft Control Macro...Iosif Itkin
Information Support System for Autonomous Spacecraft Control Macro-Programming
Andrew Tyugashev, Anton Nasekin, Saint Petersburg State University of Information Technologies, Mechanics and Optics, Saint Petersburg
12 - 14 November 2015
Tools and Methods of Program Analysis in St. Petersburg
TMPA-2015: Standards and Standartization in Program Engineering. Why Would Yo...Iosif Itkin
Standards and Standartization in Program Engineering. Why Would You Care?
Nikolay Pakulin, ISP RAS, Moscow
12 - 14 November 2015
Tools and Methods of Program Analysis in St. Petersburg
TMPA-2015: Generation of Test Scenarios for Non Deterministic and Concurrent ...Iosif Itkin
Generation of Test Scenarios for Non Deterministic and Concurrent Telecommunication Applications
Pavel Drobintsev, Vsevolod Kotlyarov, Nikita Voinov, Peter The Great Saint Petersburg Polytechnic University, Saint Petersburg
TMPA-2015: Multi-Platform Approach to Reverse Debugging of Virtual MachinesIosif Itkin
Multi-Platform Approach to Reverse Debugging of Virtual Machines
Pavel Dovgalyuk, Maria Klimushenkova, Denis Dmitriev and Vladimir Makarov, Novgorod State University
12 - 14 November 2015
Tools and Methods of Program Analysis in St. Petersburg
Formal Methods in Robotics
Dmitry Mordvinov, Yury Litvinov, Saint Petersburg State University, Saint Petersburg
12 - 14 November 2015
Tools and Methods of Program Analysis in St. Petersburg
TMPA-2015: ClearTH: a Tool for Automated Testing of Post Trade SystemsIosif Itkin
ClearTH: a Tool for Automated Testing of Post Trade Systems
Anna Toropova, Ekaterina Dimova, Iosif Itkin, Exactpro Systems
12 - 14 November 2015
Tools and Methods of Program Analysis in St. Petersburg
TMPA-2015: The Verification of Functional Programs by Applying Statechart Dia...Iosif Itkin
The Verification of Functional Programs by Applying Statechart Diagrams Construction Method
Andrew Mironov, IPI, Moscow
12 - 14 November 2015
Tools and Methods of Program Analysis in St. Petersburg
TMPA-2015: Automated process of creating test scenarios for financial protoco...Iosif Itkin
Automated process of creating test scenarios for financial protocols and connectivity testing
Anna Toropova, Sergey Pavlov, Andrey Soloviev, Alexander Bormotin, Iosif Itkin, Exactpro Systems
12 - 14 November 2015
Tools and Methods of Program Analysis in St. Petersburg
TMPA-2015: Towards a Usable Defect Prediction Tool: Crossbreeding Machine Lea...Iosif Itkin
Towards a Usable Defect Prediction Tool: Crossbreeding Machine Learning and Heuristics
Vladimir Kovalenko, Galina Alperovich , JetBrains
12 - 14 November 2015
Tools and Methods of Program Analysis in St. Petersburg
TMPA-2015: Multi-Module Application Tracing in z/OS EnvironmentIosif Itkin
Multi-Module Application Tracing in z/OS Environment
Rostislav Efremov, Saint Petersburg State University, Saint Petersburg
12 - 14 November 2015
Tools and Methods of Program Analysis in St. Petersburg
TMPA-2015: Expanding the Meta-Generation of Correctness Conditions by Means o...Iosif Itkin
Expanding the Meta-Generation of Correctness Conditions by Means of Semantic Markup
Dmitry Kondratyev, A.P. Ershov Institute of Informatics Systems, Novosibirsk
12 - 14 November 2015
Tools and Methods of Program Analysis in St. Petersburg
TMPA-2015: A Need To Specify and Verify Standard FunctionsIosif Itkin
A Need To Specify and Verify Standard Functions
Nikolay Shilov, A.P. Ershov Institute of Informatics Systems, Novosibirsk
12 - 14 November 2015
Tools and Methods of Program Analysis in St. Petersburg
TMPA-2015: Automated Testing of Multi-thread Data Structures Solutions Lineri...Iosif Itkin
Automated Testing of Multi-thread Data Structures Solutions Linerializability
Anton Evdokimov, Dmitry Tsitelov, Roman Elizarov, Vitaly Trifanov, Saint Petersburg State University of Information Technologies, Mechanics and Optics, Saint Petersburg
12 - 14 November 2015
Tools and Methods of Program Analysis in St. Petersburg
TMPA-2015: Software Engineering Education: The Messir ApproachIosif Itkin
Software Engineering Education: The Messir Approach
Nicolas Guelfi , University of Luxembourg
12 - 14 November 2015
Tools and Methods of Program Analysis in St. Petersburg
TMPA-2015: The Application of Parameterized Hierarchy Templates for Automated...Iosif Itkin
The Application of Parameterized Hierarchy Templates for Automated Program Code Defect-Fixing
Artyom Aleksyuk, Vladimir Itsykson,Peter The Great Saint Petersburg Polytechnic University, Saint Petersburg
12 - 14 November 2015
Tools and Methods of Program Analysis in St. Petersburg
TMPA-2015: The Application of Static Analysis to Optimize the Dynamic Detecti...Iosif Itkin
The Application of Static Analysis to Optimize the Dynamic Detection of Race Conditions
Yakov Roskoshnyy, Dmitry Tsitelov, Vitaly Trifanov, Roman Elizarov,Saint Petersburg State University of Information Technologies, Mechanics and Optics, Saint Petersburg
12 - 14 November 2015
Tools and Methods of Program Analysis in St. Petersburg
FPGA-Based Low Latency Sponsored Access
Valery Florov, Pavel Garin, Pavel Smirnov, Maxim Metelkov, Exactpro Systems
12 - 14 November 2015
Tools and Methods of Program Analysis in St. Petersburg
Foundations of Software Testing Lecture 4Iosif Itkin
This lecture is a part of the online course on Software Testing for Complex Intelligent Systems and Autonomous Vehicles. The course lectures provide the theoretical basics of testing autonomous systems based on artificial intelligence.
The fourth lecture of the course entitled Foundations of Software Testing reviews the ‘absence-of-errors fallacy’ and other principles of software testing, as well as the types and levels of software testing. The lecture also provides a fuller picture of the understanding of test objectives and methodologies by different schools of thought within the software testing domain.
QA Financial Forum London 2021 - Automation in Software Testing. Humans and C...Iosif Itkin
Speaker: Iosif Itkin, co-CEO & co-founder, Exactpro Systems
9th November 2021
Hilton Canary Wharf
Exactpro is an independent software testing business focused on mission-critical financial market infrastructures, primarily exchanges and clearing houses. In his presentation, Iosif will give a brief overview of research on the concept of model-based testing and the principal challenges of its application while testing complex distributed systems. He will also outline the broader context of interaction between humans and complex computer models.
Exactpro FinTech Webinar - Global Exchanges Test OraclesIosif Itkin
Global Exchanges series webinar to discuss Test Oracles. A test oracle is a mechanism for determining whether a test has passed or failed. The use of oracles involves comparing the output(s) of the system under test for a given test-case input, to the output(s) that the oracle determines the product should have. We will review various types of test oracles using examples from Exactpro’s Global Exchanges division projects and protocol-based interactions in trading systems.
Exactpro FinTech Webinar - Global Exchanges FIX ProtocolIosif Itkin
Exactpro’s Global Exchanges Division training session on FIX Trading Protocol.
The essence of the FIX protocol and its place in the overall structure of network protocols, FIX message attributes and the internal data types of the protocol.
Operational Resilience in Financial Market InfrastructuresIosif Itkin
A4Q World Congress 13-16 April 2021
Iosif Itkin
Exactpro provides independent software testing services for mission critical technology that underpins global financial markets – exchanges and clearing houses. Half of the top 20 global exchange groups on all continents around the globe rely on processes, platforms and people from Exactpro to improve their quality and reliability. The company has spent the last 11 years studying operational resilience in this crucial sector. The presentation will outline the key principles for software testing of the systems that process hundreds of millions of orders per day with roundtrip latencies below one hundred microseconds.
20 Simple Questions from Exactpro for Your Enjoyment This Holiday SeasonIosif Itkin
Warmest wishes for a happy holiday season and a wonderful New Year!
We look forward to our continued collaboration in 2020. Thank you for your support.
QA-Financial Forum 2019 in New York
13 November
Iosif Itkin, CEO and co-founder
Elena Treshcheva, Business Development Manager and Researcher
An October 2019 survey by BoE and FCA found that ML in financial organizations has already passed an initial development phase, and the usage of live ML applications is about to dramatically increase over the next three years. Artificial Intelligence systems are used in market surveillance, they are providing intellectual analysis of news feeds, and they are an important part of the conversational agents facing users and helping them with their business needs from identity verification to trading and portfolio management. How to ensure that an AI-powered system is up to its task? And what would that mean from the software testing perspective?
EXTENT 2019: Exactpro Quality Assurance for Financial Market InfrastructuresIosif Itkin
On Complex Software Systems Testing — Alexey Zverev, co-CEO & co-founder, Exactpro
Software Testing and Machine Learning
Mind the Gap. Applying Process Mining
Learning from Failure is not just for Humans
Dancing with Whales. Adaptive Log Classification System
On Traceability and the Illusion of Control
Building Partnerships
Demystifying DLT Testing One Network at a Time
Get the MOST from FIX
Georgia on My Mind
Build Software to Test Software — Iosif Itkin, co-CEO & co-founder, Exactpro
ClearTH Test Automation Framework: Case Study in IRS & CDS Swaps Lifecycle Mo...Iosif Itkin
Synchronize Europe
18th June 2019
Iosif Itkin, co-CEO and co-founder, Exactpro
Using the ISDA CDM Swaps application, simultaneously execute multiple end-to-end scenarios for DAML applications in capital markets - validate with actual contract data on ledger.
EXTENT Talks 2019 Tbilisi: Failover and Recovery Test Automation - Ivan ShamraiIosif Itkin
Ivan Shamray, Senior NFT Analyst, Exactpro
20 April 2019 EXTENT Talks, Tbilisi, Georgia
Tbilisi QA Community
EXTENT Talks is a meeting place for IT specialists working in various industries and seeking professional growth, practitioners from IT firms, as well as Quality Assurance enthusiasts of all backgrounds interested in actively participating in local IT events.
EXTENT Talks QA Community Tbilisi 20 April 2019 - Conference OpenIosif Itkin
EXTENT Talks is a meeting place for IT specialists working in various industries and seeking professional growth, practitioners from IT firms, as well as Quality Assurance enthusiasts of all backgrounds interested in actively participating in local IT events. The first EXTENT Talks were held in Tbilisi on 22 February 2019, initiating the creation a QA Community in Tbilisi and laying a foundation for an international platform for exchanging experience and knowledge in the field of software testing, development and IT. The program of the inaugural event included presentations on ISTQB, Software Testing, and Agile methodology from senior specialists. The next EXTENT Talks in Tbilisi will take place on 20 April 2019.
User-Assisted Log Analysis for Quality Control of Distributed Fintech Applica...Iosif Itkin
The First IEEE International Conference On Artificial Intelligence Testing (2019 IEEE AITest)
Iosif Itkin, Anna Gromova, Anton Sitnikov, Elena Treshcheva, Rostislav Yavorskiy, Evgenii Tsymbalov, Andrey Novikov and Kirill Rudakov
1 Exactpro, UK, Georgia, USA, Russia
2 Skolkovo Institute of Science and Technology, Russia
3 Higher School of Economics, Russia
Speakers: Iosif Itkin, CEO and Co-Founder and Elena Treshcheva, Business Development Manager and Researcher - Exactpro
Exactpro provides software testing services for mission-critical technology that underpins global financial markets. Exactpro clients are regulated by FCA, Bank of England and their counterparts from other countries. During this session, Elena and Iosif will talk about end-to-end software testing for post-trade systems in financial market infrastructures. What are the key challenges in quality assurance at this scale? What kind of cognitive biases affect SDLC? How precise is the knowledge about the systems under test? What constitutes good test evidence? How to deal with complexity in regulated environments?
Behaviour Driven Development: Oltre i limiti del possibileIosif Itkin
The QA Financial Forum: Milan 2019
23 January at the Excelsior Hotel Gallia.
Anna-Maria Lukina, Exactpro Business Development Director
The QA Financial Forum: Milan is one of the leading fintech conferences in Italy. The event focuses on the latest achievements in software risk management and automation of software testing. The predominant theme of the Milan event will be Quality Assurance for the entire Software Development Life Cycle (SDLC).
The topics under discussion will feature:
- Technologies for Automation & AI
- DevOps & CI/CD
- Value Stream Management
- Test Data Management
- Regulatory Compliance
- App Security & DevSecOps
- Testing and quality assurance of Blockchain platforms
The official language of the event is Italian.
On 17th January 2018 Exactpro successfully completed a management buyout from London Stock Exchange Group (LSEG), signed a new multi-year master services agreement with LSEG, and opened its head office in London.
What else has happened in 2018?
I wanted to take the opportunity to reflect on what has been an unusual year for Exactpro.
Integration front to back - Mr. Custodian tear down that wall
The scope of the application level has been continuous extended over the years, albeit with a focus on the area of pre-trade and trade.
Recently, there has been an increased interest to move further into the area of post-trade which is predominantly driven by the ISO 20022 standard. Is there really a need for new FIX messages in areas such as payments and
what are the integration problems needing a resolution?
Panellists
- Iosif Itkin, CEO, Exactpro
- Jim Northey, Co-Chair Global Technical Committee, Americas Region, FIX Trading Community, Chair Elect, ISO TC68 Financial
Services Technical Committee, and Consultant and Industry Standards Liaison, Itiviti
- Barry Young, Director, Aladdin Product Manager, BlackRock
BDD. The Outer Limits. Iosif Itkin at Youcon (in Russian)Iosif Itkin
Exactpro is supporting the 3rd annual IT-conference YouCon to take place on 14th October in Saratov, Russia. Over 900 programmers, systems engineers and architects, software QA engineers, and marketing specialists will gather to discuss the latest trends in programming technology. It is the largest IT industry event in Saratov.
Iosif Itkin, CEO of Exactpro, part of London Stock Exchange Group, will deliver a "BDD. The Outer Limits" presentation named after Iosif's favorite Sci-Fi series.
The topics to be covered are:
Behavior Driven Development concepts
Applying BDD in trading and clearing systems
Specification by Example and using production data
Combining Model-based testing and BDD
The Outer Limits
There will be an opportunity to ask questions, share thoughts and expertise in BDD, or just chat with a representative at the Exactpro stand at any time during the event.
Don't miss out, stop by and ask how you can get your Exactpro souvenir :)
We look forward to meeting you there!
#Exactpro #Youconsaratov
BDD. The Outer Limits. Iosif Itkin at Youcon (in Russian)
TMPA-2013 Conference Proceedings
1.
2. Министерство образования и науки РФ
Костромской государственный технологический университет
Санкт-Петербургский государственный политехнический университет
Российская академия наук
Институт проблем информатики
ООО «Инновационные Трейдинговые Системы»
ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
TOOLS & METHODS OF PROGRAM ANALYSIS
TMPA-2013
Материалы
Международной научно-практической конференции
10—12 октября 2013
Кострома
2013
6. Содержание:
ВЕРИФИКАЦИЯ:
• Пакулин Н.
Динамическая верификация гибридных систем
19
Институт системного программирования РАН
• Подымов В., Попеско У.
36
Верификация программно-конфигурируемых сетей при помощи
системы UPPAAL
МГУ имени М.В. Ломоносова
• Кузьмин Е., Рябухин Д., Шипов А.
Построение и верификация ПЛК-программ по LTL-спецификации
48
Ярославский государственный университет им. П.Г. Демидова
• Ануреев И.
На пути к технологии разработки стредств дедуктивной
верификации программ
66
Институт систем информатики имени А.П. Ершова
• Лукин М., Шалыто А.
Верификация распределенных автоматных программ с
использованием инструментального средства Spin
78
СПб НИУ ИТМО
АППАРАТНЫЙ ТРЕК:
• Иванников В., Камкин А., Чупилко М.
Проверка корректности поведения HDL-моделей цифровой
аппаратуры на основе динамического сопоставления трасс
94
Институт системного программирования Российской академии наук
(ИСП РАН)
• Шипин А., Соколов В., Чалый Д.
Использование контрольных точек для верификации SystemCпрограмм
106
Ярославский государственный университет
6
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
7. • Френкель С., Захаров В., Ушаков В.
Унифицированная высокоуровневая модель программноаппаратной системы для верификации свойств надежности
функционирования
118
Институт проблем информатики РАН, Московский гос. университет
им. М.В. Ломоносова
• Смирнов М., Олоничев В., Староверов Б.
Особенности разработки программного обеспечения для Linuxконтроллеров
130
Костромской государственный технологический университет
ТЕСТИРОВАНИЕ:
• Басок Б., Гречин А.
Об усовершенствовании статистического метода оценки полноты
тестов программ и устройств
138
Московский государственный технический университет радиотехники,
электроники и автоматики
• Сартаков В., Тарасиков А.
Анализ производительности сетевой подсистемы микроядерного
окружения Genode
146
ksys labs
• Журавлев М., Полозов В.
Подход к верификации корректности миграции данных между СУБД
с использованием криптографических хэш-функций
158
Санкт-Петербургский Государственный Университет
• Никешин А., Пакулин Н., Шнитман В.
Автоматизация тестирования соответствия протокола безопасности
транспортного уровня TLS
167
Институт системного программирования РАН
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
7
8. • Сенов А.
Применение технологий OLAP и MapReduce для обработки
результатов нагрузочного тестирования
179
Костромской государственный технологический университет
ТРЕЙДИНГОВЫЕ СИСТЕМЫ:
• Матвеева А., Антонов Н., Иткин И.
Особенности инструментов для тестирования, применимых при
промышленной эксплуатации трейдинговых систем
191
ООО «Инновационные Трейдинговые Системы», Костромской
государственный технологический университет, Exactpro Systems LLC
• Алексеенко А., Проценко П., Матвеева А., Иткин И.,
Шаров Д.
203
Тестирование совместимости протокольных подключений клиентов
биржевых и брокерских систем
ООО «Инновационные Трейдинговые Системы»,
Exactpro Systems LLC
• Буянова О., Булда А, Зверев А.
Применение симуляторов рынка ценных бумаг для тестирования
систем агрегации и распределения информации о котировках
(Ticker Plant)
215
ООО «Инновационные Трейдинговые Системы»,
Костромской государственный технологический университет,
Exactpro Systems LLC
• Гурьев Д., Гай М., Иткин И., Терентьев А.
Высокопроизводительный генератор нагрузки для тестирования
систем автоматизированной торговли
242
ООО «Инновационные Трейдинговые Системы», Саратовский
государственный технический университет имени Гагарина Ю.А.
8
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
9. • Прядкина Н., Крюков А.
Использование MBT-подхода для верификации систем мониторинга
и контроля на фондовых биржах
254
Костромской государственный технологический университет
• Бобров И., Зверев А.
Тестирование графического интерфейса трейдинговых терминалов
в условиях высокочастотной торговли
264
ООО «Инновационные Трейдинговые Системы»
АНАЛИЗ ПРОГРАММ:
• Цителов Д., Трифанов В.
Динамический поиск гонок в Java-программах на основе
синхронизационных контрактов
273
Devexperts LLC, СПбГУ
• Верт Т., Крикун Т., Глухих М.
Обнаружение дефектов работы с указателями в программах С и С++
с использованием статического анализа и логического вывода
286
Санкт-Петербургский государственный политехнический университет,
Технический университет Клаусталя
• Андрианова А., Ицыксон В.
Автоматизированный синтез тестов для Java-программ на основе
анализа программ и учета контрактов
298
Санкт-Петербургский государственный политехнический университет
•
Буй Д., Компан С.
Диаграммы классов ООП: формализация и анализ
311
Киевский национальный университет имени Тараса Шевченко
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
9
11. Международная научно-практическая
конференция: Tools & Methods of Program Analysis
(Инструменты и методы анализа программ, TMPA-2013)
10-12 октября 2013, г. Кострома, РФ
Конференция посвящена одному из наиболее актуальных и важных направлений программной инженерии – анализу качества программного обеспечения.
Вопросы эффективности и корректности функционирования программного обеспечения являются ключевыми для большинства наукоемких отраслей
современной экономики, включая ИТ-индустрию, финансовый сектор, транспорт, медицину, высокотехнологическую промышленность и многие другие.
Разработка новых и усовершенствование существующих инструментов и методов анализа программ – одно из необходимых условий внедрения инноваций
в этих отраслях.
Конференция нацелена на развитие индустрии разработки программного обеспечения и внедрение новейших разработок в области тестирования, анализа
и верификации.
В рамках конференции планируются пленарные доклады и лекционные мини-курсы экспертов; доклады участников, отобранные программным комитетом из числа поступивших заявок; презентации открытых проектов, короткие
сообщения, представляющие новые идеи, незавершенные исследования или
новые инструменты.
Темы, рассматриваемые на конференции, включают (но не ограничиваются):
• автоматизация тестирования программного обеспечения;
• статический анализ программ;
• верификация;
• динамические методы анализа программ;
• тестирование и анализ параллельных и распределенных систем;
• тестирование и анализ высоконагруженных систем и систем высокой доступности;
• анализ и верификация программно-аппаратных систем;
• методы создания качественного программного обеспечения;
• инструментальные средства анализа, тестирования и верификации
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
11
12. Программный комитет конференции
• Захаров Виктор Николаевич, д.т.н., ИПИ РАН, сопредседатель
• Ицыксон Владимир Михайлович, к.т.н., доцент кафедры
компьютерных систем и программных технологий СПбГПУ,
сопредседатель
• Лустгартен Юрий Леонидович, к.т.н., декан ФАСТ КГТУ,
сопредседатель
• Петренко Александр Константинович, д.ф.-м.н., зав. отделом
Технологий программирования Института системного
программирования РАН, профессор кафедры Системного
программирования ВМиК МГУ им. М.В.Ломоносова
• Басок Борис Моисеевич, к.т.н., доцент МИРЭА
• Глухих Михаил Игоревич, к.т.н., доцент, СПбГПУ, приглашенный
исследователь в Clausthal University of Technology
• Евтушенко Нина Владимировна, д.т.н., профессор, зав. кафедры
Информационных технологий в исследовании дискретных структур,
Радиофизический факультет, Национальный исследовательский
Томский государственный университет (ТГУ)
• Зайцев Дмитрий Анатольевич, д.т.н., профессор, Международный
гуманитарный университет, Одесса, Украина
• Захаров Владимир Анатольевич, д.ф.-м.н., доцент кафедры МК,
зав. лабораторией МПКБ
• Иванов Александр Николаевич, к.ф.-м.н.,
ведущий разработчик ООО «КоФиТе»
• Иткин Иосиф Леонидович, компания Exactpro Systems, координатор
• Камкин Александр Сергеевич, к.ф.-м.н., с.н.с. ИСП РАН;
• Климов Андрей Валентинович, зав. сектором методов анализа и
преобразования программ ИПМ им. М.В.Келдыша РАН
12
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
13. • Кириленко Яков Александрович, старший преподаватель,
МатМех СПбГУ
• Кулямин Виктор Вячеславович, к.ф.-м.н., с.н.с. ИСП РАН,
доцент ВМК МГУ
• Моисеев Михаил Юрьевич, к.т.н., доцент, СПбГПУ
• Пакулин Николай Витальевич, к.ф.-м.н., старший научный сотрудник
ИСП РАН
• Павлова Елена Анатольевна, к.т.н., координатор программ, Microsoft
• Прохоров Сергей Петрович, к.ф.-м.н., ИСП РАН, доцент МФТИ
• Соколов Валерий Анатольевич, д.ф.-м.н.,
проф., зав. каф. теоретической информатики ЯГУ им. П.Г. Демидова
• Федосеев Андрей Алексеевич, к.т.н., в.н.с. ИПИ РАН
• Филиппов Станислав Александрович, к.т.н., с.н.с. ИПИ РАН
• Христочевский Сергей Александрович, к.ф.-м.н., зав. лаб. ИПИ РАН
• Цесько Вадим Александрович, старший разработчик, Яндекс
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
13
15. 10 октября
8:30
Регистрация
9:30
Открытие
10:15
11:15
Карпов Ю.
Верификация параллельных программ: современный этап и перспективы
Кофе-брейк
ВЕРИФИКАЦИЯ
11:45
Пакулин Н.
Динамическая верификация гибридных систем
12:15
Подымов В., Попеско У.
Верификация программно-конфигурируемых сетей при помощи системы
UPPAAL
12:45
Кузьмин Е., Рябухин Д., Шипов А.
Построение и верификация ПЛК-программ по LTL-спецификации
13:15
Ануреев И.
На пути к технологии разработки средств дедуктивной верификации
программ
13:45
Лукин М., Шалыто А.
Верификация распределенных автоматных программ с использованием
инструментального средства Spin
14:00
Обед
15:30
Зайцев Д.
Эффективная универсальная сеть Слепцова
АППАРАТНЫЙ ТРЕК
16:00
Иванников В., Камкин А., Чупилко М.
Проверка корректности поведения HDL-моделей цифровой аппаратуры
на основе динамического сопоставления трасс
17:00
Шипин А., Соколов В., Чалый Д.
Использование контрольных точек для верификации SystemC-программ
17:30
Френкель С., Захаров В., Ушаков В.
Унифицированная высокоуровневая модель программно-аппаратной
системы для верификации свойств надежности функционирования
17:45
Смирнов М., Олоничев В., Староверов Б.
Особенности разработки программного обеспечения для Linuxконтроллеров
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
15
16. 11 октября
8:30
Регистрация
9:30
Петренко А. К.
Технические решения и нетехнические проблемы автоматизации
тестирования
10:30
ISTQB
ТЕСТИРОВАНИЕ
11:00
11:30
Басок Б., Гречин А.
Об усовершенствовании статистического метода оценки полноты тестов
программ и устройств
Кофе-брейк
12:00
Никешин А., Пакулин Н., Шнитман В.
Автоматизация тестирования соответствия реализаций стандарту протокола безопасности транспортного уровня TLS
12:30
Сартаков В., Тарасиков А.
Анализ производительности сетевой подсистемы микроядерного
окружения Genode
13:00
Журавлев М., Полозов В.
Подход к верификации корректности миграции данных между СУБД с
использованием криптографических хэш-функций
13:15
Сенов А.
Применение технологий OLAP и MapReduce для обработки результатов
нагрузочного тестирования
ТРЕЙДИНГОВЫЕ СИСТЕМЫ
13:30
14:00
15:30
Матвеева А., Антонов Н., Иткин И.
Особенности инструментов для тестирования, применимых при
промышленной эксплуатации трейдинговых систем
Обед
Алексеенко А., Проценко П., Матвеева А., Иткин И., Шаров Д.
Тестирование совместимости протокольных подключений клиентов
биржевых и брокерских систем
15:50
16:10
Гурьев Д., Гай М., Иткин И., Терентьев А.
Высокопроизводительный генератор нагрузки для тестирования систем
автоматизированной торговли
16:30
16
Буянова О., Булда А, Зверев А.
Применение симуляторов рынка ценных бумаг для тестирования систем
агрегации и распределения информации о котировках (Ticker Plant)
Прядкина Н., Крюков А.
Использование MBT-подхода для верификации систем мониторинга и
контроля на фондовых биржах
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
17. 11 октября
16:45
Бобров И., Зверев А.
Тестирование графического интерфейса трейдинговых терминалов в
условиях высокочастотной торговли
17:00
Кофе-брейк
17:30 Круглый стол: Нешаблонные методы тестирования программного
обеспечения для электронных торговых платформ
12 октября
9:00
Регистрация
9:30
Захаров В. А.
Математические аспекты задачи обфускации программ
АНАЛИЗ ПРОГРАММ
10:30
Цителов Д., Трифанов В.
Динамический поиск гонок в Java-программах на основе
синхронизационных контрактов
11:00
Верт Т., Крикун Т. и Глухих М.
Обнаружение дефектов работы с указателями в программах С и С++
с использованием статического анализа и логического вывода
11:30
Кофе-брейк
12:30
Андрианова А., Ицыксон В.
Автоматизированный синтез тестов для Java-программ на основе анализа
программ и учета контрактов
12:45
Буй Д., Компан С.
Диаграммы классов ООП: формализация и анализ
13:00
Круглый стол: Как написать хорошую научную статью
13:30
Закрытие конференции
14:00 Завершающий обед
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
17
36. Верификация программно-конфигурируемых
сетей при помощи системы UPPAAL
Владислав Подымов, Ульяна Попеско
МГУ имени М.В. Ломоносова
valdus@yandex.ru, ulya_kiber@mail.ru
Аннотация В последние несколько лет активное развитие получили программно-конфигурируемые сети (ПКС) – особый вид компьютерных сетей, в которых все коммутирующие устройства имеют централизованное управление. В статье исследуются задачи формального описания и верификации ПКС. Для описания ПКС используется
библиотека элементов UML в редакторе диаграмм Dia. Для верификации ПКС используется программно-инструментальное средство
UPPAAL. Основной результат исследований - разработка транслятора, позволяющего по диаграмме сети получить её модель для верификации в виде сети конечных временных автоматов. Корректность
алгоритма трансляции строго обоснована. Проведен ряд экспериментов, которые показывают применимость предложенного метода верификации для проверки свойств поведения ПКС, специфицированных
посредством формул темпоральной логики реального времени.
Keywords: программно-конфигурируемая сеть, верификация, временные автоматы, темпоральная логика, UPPAAL
1
Введение
Идея программно-конфигурируемых сетей (ПКС) сформулирована специалистами университетов Стэнфорда и Беркли в 2006 году [1]. В таких сетях
уровень управления отделен от устройств передачи данных: коммутаторы
не участвуют в определении маршрутов для пакетов, а только реализуют
программу контроллера. Наиболее широко применяемым стандартом для
построения ПКС является протокол OpenFlow [2].
Сеть OpenFlow состоит из коммутаторов, управляемых централизованным контроллером. Пакет, передаваемый по сети, обрабатывается контроллером существенно медленнее, нежели коммутатором, поэтому одной из основных функций контроллера является организация работы коммутаторов
так, чтобы они обрабатывали большую часть пакетов, и лишь в исключительных случаях пакеты обрабатывались бы на контроллере.
Организация работы коммутаторов заключается в установке правил в
таблицы коммутации (flow tables), определяющих, как будут обрабатываться те или иные пакеты. Правило состоит из шаблона, идентифицирующего
вид пакетов, целочисленного приоритета, устраняющего неоднозначность в
36
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
37. 2
Владислав Подымов, Ульяна Попеско
случае наложения шаблонов, целочисленного лимита времени, указывающего число секунд до истечения срока активности правила, и списка действий, описывающих обработку пакета. Также для каждого правила в этих
таблицах коммутатор содержит счетчики для учета количества и размера
обрабатываемых пакетов.
Коммутатор обрабатывает приходящий пакет в 3 этапа. Сначала он выбирает правило из своей таблицы коммутации так, чтобы заголовок пакета
соответствовал шаблону этого правила. Если такового не найдено, коммутатор отправляет пакет контроллеру для дальнейшей обработки. Иначе выбирается совпадающее по шаблону правило с наибольшим приоритетом. На
втором шаге обновляются счетчики для выбранного правила. И наконец,
к пакету поочередно применяются все действия, записанные в правиле. К
допустимым действиям относятся output(op) и modif y(h,n). По действию
output(op) пакет отправляется на порт op. Действие modif y(h,n) предписывает переписать заголовочное поле h на n.
Контроллер устанавливает правила в таблицы коммутации, реагируя на
события в сети. Такими событиями являются подключение нового коммутатора к сети, удаление ранее действующего коммутатора из сети, события для
сбора статистики, истечение лимита времени правила коммутатора. Также
контроллер оперирует функциями отправки сообщений коммутаторам: установкой правил в таблицу коммутации, удалением всех правил с заданным
шаблоном из таблицы коммутации, отправкой пакета и действия для его
обработки коммутатором.
В статье исследуется возможность верификации ПКС как распределенных систем реального времени. Для этого потребовалось решить следующие
задачи: 1) выбрать адекватное средство для построения сетей; 2) выбрать
подходящее средство для верификации сетей как систем реального времени;
3) построить корректный транслятор из выбранного средства построения
сетей во входной язык нужной системы верификации; 4) провести экспериментальное исследование возможности применения выбранного средства
верификации для проверки спецификаций ПКС.
Стандарт OpenFlow включает в себя большое количество свойств и предписаний для коммутации пакетов в сети. Производители компонентов компьютерных сетей используют лишь часть из них. Мы также ограничимся в
рассматриваемых вариантах. При моделировании правил таблиц коммутации не будем уделять внимание приоритетам и счетчикам, а из всех допустимых действий будем рассматривать только действия типа output(op). Сбор
статистических данных в сети также не будет нас интересовать. С другой
стороны, в нашу модель будут добавлены временные характеристики, описывающие работу физических объектов сети. Посредством этого мы будем
учитывать не только предписания стандарта OpenFlow, но и технические
возможности коммутаторов и каналов.
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
37
38. Верификация ПКС при помощи системы UPPAAL
2
3
Схема верификации
Для построения ПКС был выбран кроссплатформенный редактор диаграмм
Dia1 . Сеть из рассматриваемого нами подкласса описывается с помощью
объектов библиотеки элементов UML, предоставляемых редактором, следующим образом (см. рисунок 1). Каждый коммутатор изображается в виде
прямоугольника с тремя секциями. В верхней секции обозначается имя коммутатора, в нижней содержатся правила таблицы коммутации, в средней —
физические характеристики коммутатора. Каждое правило таблицы коммутации имеет четыре поля: имя порта, на который поступил пакет, заголовок поступившего пакета, лимит времени жизни правила и порт, на который необходимо отправить пакет. Описываются следующие характеристики коммутатора: port — множество портов коммутатора, соединяющих его
с другими коммутаторами и внешней средой; rule_imp — задержка поиска
и выполнения правила на коммутаторе (временной интервал); rule_def —
задержка установки в коммутатор правила от контроллера; rule_ar — интенсивность поступления пакетов из внешней среды; rule_con — задержка
доставки необработанного пакета контроллеру; tab — объем таблицы коммутации, то есть максимальное число правил таблицы.
Рис. 1. Пример описания ПКС диаграммами Dia.
Для отображения топологии сети коммутаторы соединяются линиями,
моделирующими дуплексные каналы сети. Каналы также имеют временную
характеристику — задержку доставки пакета. Поведение контроллера опре1
38
Руководство пользователя редактора Dia доступно по адресу http://diainstaller.de/doc/en/dia-manual.pdf
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
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 включает в себя множество портов P orti , начальную
таблицу коммутации Rulei ⊆ P orti × H × Real × P orti объема tab и временimp
def
ar
con
ные характеристики Limp , Ri , Ldef , Ri , Lar , Ri , Lcon , Ri , естественi
i
i
i
ным образом соотносящиеся с характеристиками коммутатора, описанными
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
39
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 располагает следующими каналами: канал car входного потока
i
ar
с временными характеристиками L = Lar , R = Ri , ведущий в специально
i
выделенный под него порт; канал cto con , ведущий в контроллер из другого
i
con
специально выделенного порта, с характеристиками L = Lcon , R = Ri ;
i
f rom con
, ведущий от контроллера в третий специально выделенный
канал ci
порт коммутатора, с характеристиками L = R = 0. Таким образом, состояние S ПКС включает в себя состояния scon контроллера, scom , . . . , scom комn
1
мутаторов и sch , . . . , sch , sar , . . . , sar , stocon , . . . , stocon , sf romcon , . . . , sf romcon
m
n
n
n
1
1
1
1
каналов ch между коммутаторами, ar от входного потока, to con к и f rom con
от контроллера соответственно.
Коммутатор comi может находиться в состояниях (start, Rule), (select,
t, Rule, h, p), (hit, Rule, h, p), (miss, Rule, h, p), (mod, t, Rule). В состоянии
start коммутатор прослушивает входящие каналы на предмет поступивших
пакетов. В состоянии select коммутатор, получив на порт p пакет h, просматривает таблицу коммутации для принятия решения о перенаправлении
пакета. В состоянии hit пакет засылается в канал, исходящий из порта p. В
состоянии miss шаблон, состоящий из пакета h и порта p, на который он пришел, засылается в канал к контроллеру. Вообще говоря, коммутатор также
должен посылать контроллеру свой идентификатор, однако в построенной
формальной модели идентификатор может быть восстановлен по номеру
порта, входящего в коммутатор. В состоянии mod происходит запись в таблицу коммутации правила, присланного контроллером. Во всех состояниях
40
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
41. 6
Владислав Подымов, Ульяна Попеско
коммутатора Rule — текущая таблица коммутации, t — время нахождения
в текущем управляющем состоянии, h и p — хранимые пакет и порт.
Каналы могут могут находиться в состояниях (empty), (f ull, t, o) и (sent,
o), где o — пакет для обычных и поточных каналов, шаблон для каналов
к контроллеру либо правило для каналов от контроллера. Компонента t ∈
Real — время обработки сообщения каналом.
Контроллер может находиться только в состояниях (idle) (ожидание запросов от коммутаторов) и (send, i, r) (послать i-му коммутатору новое
правило r).
Начальное состояние S0 системы строится из начальных состояний коммутаторов, контроллера и каналов. Начальное состояние i-го коммутатора
— (start, Rulei ), контроллера — (idle), каналов — (empty).
Работа ПКС характеризуется последовательностью состояний, начинающейся в S0 и строящейся по описанным далее правилам. Запись s → s
означает, что следующее состояние может быть получено из предыдущего
заменой компоненты s на s . Запись s1 , s2 → s1 , s2 означает то же самое для
пары компонент. Построение вычисления ПКС происходит по следующим
правилам.
1. Получение пакета: scom , sar = (start, Rule), (sent, h) → (select, 0, Rule,
i
i
h, p), (empty).
2. Применение активного правила r = (p, h, x, p ): scom = (select, Rule, t,
i
imp
h, p) → (hit, Rule, h, p ), если t ∈ [Limp , Ri ], r ∈ Rule.
i
3. Обработка истекшего правила r = (p, h, x, p ): scom = (select, Rule, t, h, p)
i
imp
→ (miss, Rule , h, p), если t ∈ [Limp , Ri ], r ∈ Rule и Rule = Rule {r}.
i
4. Сброс пакета: scom = (select, Rule, t, h, p) → (start, Rule), если t ∈
i
imp
[Limp , Ri ], |Rule| = tabi , все правила из Rule активны и ни одно из
i
них не имеет шаблона (p, h).
5. Несоответствие шаблонов: scom = (select, Rule, t, h, p) → (miss, Rule ,
i
h, p), где Rule получается из Rule удалением всех истекших правил.
6. Начало перезаписи таблицы: scom , sf rom con = (start, Rule), (sent, rule)
i
i
→ (mod, 0, Rule), (sent, rule).
7. Успешная перезапись таблицы: scom , sf rom con = (mod, t, Rule), (sent, (p,
i
i
def
h, x, p )) → (hit, Rule , h, p ), (empty), если t ∈ [Ldef , Ri ], |Rule| < tabi
i
и Rule = Rule ∪ {(p, h, x, p )}.
8. Неуспешная перезапись таблицы: scom , sf rom con = (mod, t, Rule), (sent,
i
i
def
rule) → (start, Rule), (empty), если t ∈ [Ldef , Ri ] и |Rule| = tab.
i
com
ch
9. Пересылка пакета коммутатору: si , sj = (hit, Rule, h, p), (empty) →
(start, Rule), (f ull, 0, h), если канал cj исходит из порта p коммутатора
i.
10. Пересылка шаблона контроллеру: scom , sto con = (miss, Rule, h, p), (empty)
i
i
→ (start, Rule), (f ull, 0, (p, h)).
11. Успешная обработка шаблона контроллером: scon , sto con = (idle), (sent,
i
(p, h)) → (send, i, r), (empty), если (i, (p, h, x, p )) ∈ con.
12. Неуспешная обработка шаблона контроллером: scon , sto con = (idle), (sent,
i
/
(p, h)) → (idle), (empty), если (i, (p, h, x, p )) ∈ con.
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
41
42. Верификация ПКС при помощи системы UPPAAL
7
13. Пересылка правила от контроллера: scon , sf rom con = (send, i, r), (empty)
i
→ (idle), (f ull, 0, r).
14. Появление пакета в сети: sar = (empty) → (f ull, 0, h), если h ∈ H.
i
15. Сброс пакета в окружение: scom = (hit, Rule, h, p) → (start, Rule), если
i
ни один канал cj не исходит из порта p коммутатора comi .
16. Доставка в канале: (f ull, t, o) → (sent, o), если t ∈ [L, R] для характеристик L, R соответствующего канала.
17. Продвижение времени: таймеры всех коммутаторов и каналов увеличиваются на одну и ту же положительную величину d, времена жизни
правил уменьшаются на эту же величину, и при этом:
– если какой-либо канал находится в состоянии (f ull, t, o), то t + d ≤ R
для характеристики R этого канала;
imp
– если scom = (select, Rule, t, h, p), то t + d ≤ Ri ;
i
def
com
– если si
= (mod, Rule, t), то t + d ≤ Ri .
5
Алгоритм трансляции
Алгоритм Alg переводит ПКС в эквивалентную ей сеть временных автоматов. Понятие эквивалентности обсуждается в следующем разделе.
Сеть N , получаемая в результате трансляции ПКС ((com1 , . . . , comn ),
con, (c1 , . . . , cm ), H), содержит автоматы Hurry, Env, Stream, Chan, Acon
и Ai , i ∈ {1, . . . , n}.
Каждый канал ci моделируется булевыми переменными f ull[ci ] (пакет
послан), ready[ci ] (пакет доставлен), таймером t[ci ] и переменными для хранения объектов, пересылаемых через канал. Сброс пакетов в окружение моделируется с помощью особого канала cenv . Также в сеть добавляются все
каналы car , cto con , cf rom con .
i
i
i
Автомат Hurry обеспечивает срочные дуги (т.е. дуги, выполняющиеся
немедленно по выполнении их предусловий) и состоит из одной вершины
и петли, принимающей сигнал по срочному каналу hurry. К срочным дугам по умолчанию добавляется посылка сигнала по каналу hurry. Автомат Env удаляет пакеты из канала cenv и состоит из одной вершины и
срочной петли с записью в переменную f ull[cenv ] значения f alse. Автомат
Stream генерирует пакеты, состоит из одной вершины и содержит набор
срочных петель, недетерминированно засылающий пакеты в каналы car .
i
Автомат Chan обеспечивает доставку пакетов каналами, состоит из одной
вершины и содержит петлю для каждого канала c, помеченную предусловием f ull[c] && !ready[c] && (t[c] ≥ L(c)) и записью в переменную ready[c]
значения true, где L(c) — характеристика L канала c. Сама вершина автомата Chan при этом помечена инвариантом — конъюнкцией неравенств
t[c] ≤ R(c).
Автомат Acon имеет два обычных состояния — idle и send — и одно срочное состояние l. Срочная дуга idle → l записывает в локальные переменные
автомата шаблон, присланный коммутатором, и номер этого коммутатора и
в зависимости от наличия отправляемого обратно правила переходит либо
42
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
43. 8
Владислав Подымов, Ульяна Попеско
обратно в idle, либо в send. Срочная дуга send → idle присваивает переменной f ull[c] значение true и записывает в переменную канала выбранное
правило.
Автомат Ai моделирует работу коммутатора comi и состоит из обычных
состояний start, select, hit, miss, mod, соединенных через срочные вершины.
Срочная дуга start → select записывает в локальные переменные автомата
доставленный через канал c пакет и порт, на который он пришел, и записывает в переменную f ull[c] значение f alse. Состояние select, помеченное
imp
инвариантом t ≤ Ri , имеет одну исходяющую дугу в срочное состояние
l, помеченную предусловием t ≥ Limp . Здесь t — локальный таймер комi
мутатора. Из состояния l в зависимости от наличия шаблона происходит
переход в состояния hit и miss с модификацией таблицы согласно правилам
2-5 семантики ПКС. Удаление многих правил из таблицы коммутации обеспечивается срочной вершиной l с петлей, удаляющей из таблицы истекшие
правила, и исходящей дугой, помеченной предусловием, утверждающим, что
из таблицы удалены все истекшие правила. Срочная дуга start → mod записывает в локальные переменные автомата правило, доставленное каналом
def
cf rom con . Состояние mod помечено инвариантом t ≤ Ri , исходящие из него
i
def
дуги — предусловием r ≥ Li . В зависимости от того, заполнена ли таблица коммутации, из состояния mod автомат может либо перейти в состояние
start, либо перейти в состояние hit с записью правила в таблицу.
6
Корректность алгоритма трансляции
Под корректностью алгоритма Alg понимается равновыполнимость формул,
используемых в средстве UPPAAL, для исходной ПКС N и результирующей
сети Alg(N ). Ключевым понятием в доказательстве корректности алгоритма Alg является эквивалентность по прореживанию (stuttering equivalence)
для систем переходов [6]. Неформально, такая эквивалентность означает,
что если в каждом вычислении двух данных систем склеить все одинаковые состояния, то мы получим одинаковые множества вычислений. Одинаковыми полагаются состояния с совпадающими множествами выполнимых
формул. В работе [7] сформулирована следующая теорема.
Теорема 1 Если системы переходов M1 , M2 эквивалентны по прореживанию и формула Φ логики LT L−X истинна для M1 , то она также истинна
для M2 .
Следующая теорема позволяет применить только что сформулированную к системам переходов, описывающим поведение ПКС N и сети Alg(N ).
Система переходов, описывающая поведение сети временных автоматов, обсуждается, например, в [4]. Пусть T SA — система переходов, описывающая
поведение системы A.
Теорема 2 Пусть N — произвольная ПКС. Тогда системы переходов T SN
и T SAlg(N ) эквивалентны по прореживанию.
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
43
44. Верификация ПКС при помощи системы UPPAAL
9
Теорему обосновывают следующие рассуждения. Состояниям контроллера и коммутаторов ставятся в соответствие одноименные состояния получающихся из них автоматов вместе с необходимыми значениями локальных
переменных. Состояниям каналов ставятся в соответствие наборы значений переменных f ull, ready и переменных для хранения данных. Одному
применению семантических правил 1-17 соответствует последовательность
переходов в сети временных автоматов через срочные состояния, и смена
значений переменных происходит только в одном месте последовательности. В результате применения правила в ПКС и построенной по нему последовательности переходов в сети соответствующие состояния переводятся в
соответствующие.
Корректность алгоритма напрямую следует из приведенных теорем с
учетом того, что формулы, проверяемые средством UPPAAL, могут быть
переформулированы в терминах логики LT L−X .
7
Экспериментальное исследование
В приложении приведена сеть автоматов, построенная транслятором по описанию сети на рисунке 1. Ниже приведены проверенные с помощью средства
UPPAAL свойства и их запись на языке запросов UPPAAL [3].
1. В работе системы не возникает блокировки:
A[] not deadlock
2. В сеть всегда будут поступать пакеты из внешней среды:
A <> f orall(num : int[0, 2]) (channel_h[stream.align[num]])
3. Допустим сценарий работы сети, в котором коммутатор не принимает
ни одного пакета:
E[] com1.start
4. При любом сценарии работы сети контроллер обработает хотя бы один
пакет:
E <> !con.idle
5. Хотя бы один пакет будет успешно перенаправлен коммутатором (т.е.
коммутатор выполняет свою главную функцию):
E <> com1.hit
Свойства 1,2,4,5 соответствуют спецификации сетей OpenFlow, в то время как свойство 3 является недопустимым. Проверка показала, что свойства
1,2,4,5 выполняются, а свойство 3 не выполняется. Это свидетельствует о
том, что функционирование полученной сети временных автоматов соответствует нашим ожиданиям и что предложенная схема верификации ПКС
44
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
45. 10
Владислав Подымов, Ульяна Попеско
с помощью средства UPPAAL позволяет проверять свойства поведения ПКС
как системы реального времени.
В ячейках таблицы 1 представлено время проверки описанных темпоральных свойств для некоторых моделей ПКС: 1 – три коммутатора в топологии кольца (рисунок 1); 2 – четыре коммутатора в топологии звезды;
3 – четыре коммутатора в произвольной топологии; 4 – два коммутатора с
изначально пустыми таблицами коммутации. Проверка проводилась на вычислительном устройстве со следующими характеристиками: INTEL Core i7
3820/1600 МГц/2Гб DDR3. Первое свойство не было проверено на моделях
1–3 в связи с нехваткой памяти.
Таблица 1. Время проверки свойств ПКС.
Модель
Модель
Модель
Модель
8
1
2
3
4
1
27 часов
1
1
1
1
2
секунда
секунда
секунда
секунда
1
1
1
1
Свойство номер:
3
4
5
секунда
7 секунд
1 секунда
секунда 1 минута 2 секунды 1 минута 25 секунд
секунда
1 минута
1 минута 19 секунд
секунда
1 секунда
1 секунда
Заключение
В результате проведенных исследований мы подтвердили практическую осуществимость подхода, предложенного в статье [5], для проверки выполнимости свойств поведения моделей программно-конфигурируемых сетей в
реальном времени. Предложенное нами средство анализа поведения ПКС
может быть использовано для наглядного описания конфигурации и коммутационной политики сети в виде диаграмм. Разработанный нами алгоритм трансляции преобразует диаграмму в сеть временных автоматов, подаваемую на вход системы верификации UPPAAL. Корректность алгоритма
трансляции строго обоснована, транслятор реализован на языке программирования Perl. Получаемая на выходе транслятора сеть временных автоматов позволяет проверять спецификации ПКС с помощью системы UPPAAL.
Особенностью такой верификации является возможность учитывать временной аспект поведения ПКС как распределённых систем реального времени.
Список литературы
1. Casado M., Garfinkel T., Akella A., Fredman M., Boneh D., McKeown N.,
Shenker S. SANE: A Protection Architecture for Enterprise Networks // 15-th
Usenix Security Symposium, Vancouver, Canada, August 2006.
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
45
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 in
Computer Science, 2004, v.3185, p.200-236.
4. Alur R., Dill D. Automata for modeling real-time systems // Proc. of Int.
Colloquium on Algorithms, Languages, and Programming, LNCS, 1990, v.443,
p.322-335.
5. Волканов Д.Ю., Захаров В.А., Зорин Д.А., Коннов И.В., Подымов В.В. Как
разработать простое средство верификации систем реального времени // Моделирование и анализ информационных систем, 2012, Том 19, №6, с.45–56.
6. Browne M.C., Clarke E.M., Grumberg O. Characterizing finite Kripke structures
in propositional temporal logics // Theor. Comp. Sci., 1988, v.59(1-2), p.115-131.
7. Clarke E.M., Grumberg O., Peled D. Model Checking. The MIT Press. 1999.
Приложение
Сеть временных автоматов, полученная в результате трансляции из ПКС,
изображенной на рисунке 1, приведена на рисунках 2–4. В целях удобочитаемости выражения автоматов написаны в синтаксисе, отличном от синтаксиса UPPAAL и при этом более простом для восприятия.
Запись вида (i = 1..3, 5, 7) означает перебор всех i из заданного диапазона
и создание копий дуги для каждого значения i. Запись вида (i = 1..3 → Φ)
означает “для всех i из заданного диапазона верна формула Φ”.
Функция get(c) сохраняет содержимое канала c в локальные переменные
(h, p, . . .) и выполняет присваивание c = f alse. Функция send(c, o) копирует o в содержимое канала и выполняет присваивания c = true, c_ready =
f alse, c_t = 0. Функция set_rule(i) копирует локальные переменные коммутатора, отвечающие компонентам правила, в i-ю позицию таблицы.
Предикат to_deliver(c) описывается как c && !c_ready && (c_t ≥ c_L).
Предикат ok(c) описывается как !c || c_ready || (c_t ≤ c_R).
Канал c[0] выделен под окружение, каналы c[1], c[2], c[3] — под потоки, прикрепленные к соответствующим коммутаторам. Автоматы A2 , A3
отличаются от автомата A1 только номерами задействованных каналов и
константами, определяемыми количеством портов и объемом таблицы, и по
этой причие опущены.
46
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
47. 12
Владислав Подымов, Ульяна Попеско
(i = 0..2)
hurry!
idle
to_con_ready[i]
get(to_con[i]), c = i
i = 0..2 -> !hit(rule[i], (c, p, h))
!con_in[c]
hurry!
send(from_con[c],
rule[r])
(i = 0..2)
hit(r[i], (c, p, h))
r=i
s1
send
(i = 1..3, num = 1..3)
!c[num]
hurry!
send(c[num], i)
Рис. 2. Автоматы Acon (слева), Stream (справа).
from_con[0]
hurry!
get(from_con[0]),
t=0
(i = 0..3)
(t >= 2) && !active[i]
set_rule(i)
rewrite
t <= 3
i = 1..3 -> active[i]
!c[r]
hurry!
send(c[r], h)
hit
start
t >= 3
(i = 1,4,5)
select
c_ready[i]
t <= 5
hurry!
get(c[i]), p = i, t = 0
(i = 0..3)
hit(rule[i])
r=i
rule_t[r] < rule_max[r]
rule_t[r] >= rule_max[r]
active[r] = false
miss
i = 0..3 -> !hit(rule[i])
i = 0..3 -> !active[i]
|| (rule_t[i] <= rule_max[i] )
(i = 0..3)
active[i] && (rule_t[i] > rule_max[i])
active[i] = false
i = 0..3 -> active[i]
i = 0..3
!active[i]
hurry!
send(to_con[0],
(p, h))
Рис. 3. Автомат A1 .
s1
hurry?
c[0]
hurry!
c[0] = false
(i = 0..2)
to_deliver(to_con[i])
to_con_ready[i])
s1
(i = 1..9)
to_deliver(c[i])
c_ready[i]
(i = 0..2 -> ok(to_con[i])) &&
(i = 1..9 -> ok(c[i]))
Рис. 4. Автоматы Hurry (слева), Env (в центре), Chan (справа).
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
47
49. P
S = (S, s0 , →, L)
s0 ∈ S
L : S → 2P
S
→⊆ S × S
s0
π = s0 s1 s2 . . .
∀i≥0
si → si+1
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
49
50. pi ∈ P
ϕ, ψ ::= true | p0 | p1 | . . . | pn | ¬ ϕ | ψ ∧ ϕ | Xϕ | ψ U ϕ | F ϕ | G ϕ.
X F G
ϕ
U
Gϕ
Xϕ
Fϕ ϕ
ϕ
ψU ϕ
ϕ
ψ
F
G
F ϕ = true U ϕ G ϕ = ¬F ¬ϕ
∨
ϕ
ϕ
50
⇒
s0
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
51. V
V
(1)
G X( V > V ⇒ OldValCond ∧ FiringCond ∧ V = NewValExpr )
V
V
V
OldValCond
FiringCond
NewValExpr
V
V
V
X
FiringCond
OldValCond
FiringCond
V
NewValExpr
OldValCond
V
(1)
⇒
OldValCond i ∧ FiringCond i ∧ V = NewValExpr i
V
G X( V < V ⇒ OldValCond ′ ∧ FiringCond ′ ∧ V = NewValExpr ′ )
(1′ )
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
51
52. (1)
(1′ )
V
(2)
G X( ¬ V ∧ V ⇒ FiringCond )
V
(2′ )
G X( V ∧ ¬V ⇒ FiringCond ′ )
′
(1) (1 )
V
FiringCond = FiringCond ′ = 1 NewValExpr = NewValExpr ′
OldValCond = ( V < NewValExpr ) OldValCond ′ = ( V > NewValExpr )
G X( V > V ⇒
V < NewValExpr ∧ V = NewValExpr )
G X( V < V ⇒
V > NewValExpr ∧ V = NewValExpr )
(3)
G X( V = NewValExpr )
(1)
V
(2)
′
(1 )
(2′ )
(3)
V
(3)
NewValExpr
V
52
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
53. (V ) = 1
V
V+
(1)
OldValCond
OldValCond ′
V
(1′ )
V−
V := NewValExpr
V := NewValExpr ′
FiringCond
FiringCond ′
V+
V−
V
OldValCond i ∧ FiringCond i ∧ V = NewValExpr i
V
V
V
V + (2)
V − (2′ )
V := 1
V := 0
FiringCond
FiringCond ′
V+
V−
V (3)
V := NewValExpr
V
V
V
V := V
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
53
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
54
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
55. OldValCond
OldValCond ′
FiringCond
FiringCond ′
V
∼V
V
FiringCond
FiringCond ′
(2′ )
(2)
(3)
V :=
V
NewValExpr
NewValExpr ′
V := 1
V := 0
V := V
V
V
V :=
V :=
V := V
NewValExpr
NewValExpr
X G( V = NewValExpr )
V = NewValExpr
G( V = NewValExpr )
X G( V = NewValExpr )
V
V := NewValExpr
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
55
58. Входы
Кнопки
Кнопка 1
PB1
ПЛК
Выходы
ход по цифре 1
1
выбрана цифра 1
1
ход по цифре 2
2
Кнопка 2
PB2
выбрана цифра 2
Кнопка 3
PB3
выбрана цифра 3
ход по цифре 3
2
3
ход по цифре 4
4
3
ход по цифре 5
5
Кнопка 4
PB4
выбрана цифра 4
ход по цифре 6
4
6
Лампы
Лампа 1
Out1
Лампа 2
Out2
Лампа 3
Out3
Лампа 4
Out4
Лампа 5
Out5
Лампа 6
Out6
выбрана цифра 6
Старт
PBStart
Ход
игрока
Ход ПЛК
Turn
победил игрок
выбрана цифра 5
Кнопка 6
PB6
право хода у игрока
право хода у ПЛК
Кнопка 5
PB5
Игрок
ManWin
ПЛК
PLCWin
начать игру заново
5
7
7
6
8
победил ПЛК
7
9
58
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
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 ∧ ¬(P LCW in ∨ M anW in) ∧ Sum = 0)
G(F(Mv )) ⇒ G(F(PLCWin ∨ManWin ∨PBStart ))
PBStart
G(F(Mv )) ∧
G(¬PBStart ∧X(PBStart ) ⇒ (PLCWin ∨ManWin)) ⇒ G(PBStart ∧X(¬PBStart ) ⇒
X(¬PBStart U (PLCWin ∨ ManWin)))
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
59
60. G(F(Mv)) ∧ G(¬PBStart ∧ X(PBStart ) ⇒ (PLCWin ∨ ManWin)) ⇒
G(Mv3 ∧ Sum = 3 ⇒ ((¬ManWin ∧ ¬PLCWin) U PLCWin))
G(F(Mv)) ∧ G(¬PBStart ∧ X(PBStart ) ⇒ (PLCWin ∨ ManWin)) ⇒
G(Mv4 ∧ Sum = 4 ⇒ ((¬ManWin ∧ ¬PLCWin) U PLCWin))
G(F(Mv)) ∧ G(¬PBStart ∧ X(PBStart ) ⇒ (PLCWin ∨ ManWin)) ⇒
G(Mv6 ∧ Sum = 6 ⇒ ((¬ManWin ∧ ¬PLCWin) U PLCWin))
G(X(Mv1 ∧ Sum = 1 ∨ Mv2 ∧ Sum = 2 ∨ Mv3 ∧ Sum = 3 ∨ Mv4 ∧
Sum = 4 ∨ Mv5 ∧ Sum = 5 ∨ Mv6 ∧ Sum = 6) ⇒ ¬Turn)
60
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
66. На пути к технологии разработки средств
дедуктивной верификации программ⋆
Игорь Ануреев
Институт систем информатики имени А.П. Ершова
anureev@iis.nsk.su
Аннотация Статья представляет подход к разработке средств дедуктивной верификации программ. Основой подхода является предметно-ориентированный язык для данной предметной области.
Сформулированы требования к такому языку и дано обоснование использования языка спецификации предметно-ориентированных систем переходов Atoment в качестве возможного кандидата. Особенности применения подхода и принципы, на которых он основан, проиллюстрированы на простых примерах. На базе подхода предполагается создать технологию разработки средств дедуктивной верификации программ.
Ключевые слова: дедуктивная верификация программ, предметно-ориентированный язык, предметно-ориентированные системы переходов, операционная семантика, аксиоматическая семантика, денотационная семантика, логика безопасности, язык Atoment
1
Введение
В статье предлагается предметно-ориентированный подход к разработке
средств дедуктивной верификации программ (далее дедуктивных верификаторов). Термин «предметная ориентированность» применительно к подходу может иметь два значения. В первом случае, он означает ориентированность на предметную область, к которой применяется дедуктивная верификация. Во втором случае, он означает ориентированность на саму область
разработки средств дедуктивной верификации программ. Мы рассматриваем предметную ориентированность во втором значении. Прежде чем описывать подход, определим необходимые термины этой предметной области
и дадим классификацию существующих подходов к разработке средств дедуктивной верификации программ.
Дедуктивный верификатор применяется к аннотированной программе
на некотором целевом языке программирования. Аннотированная программа на этом языке — это текст, построенный по определенным правилам
⋆
66
Работа частично поддержана грантом РФФИ 11-01-00028-а и междисциплинарным интеграционным проектом СО РАН № 3 «Принципы построения онтологии
на основе концептуализаций средствами логических дескриптивных языков».
Международная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
67. из конструкций целевого языка и аннотаций. Аннотации описывают свойства программы на целевом языке. Аннотированная программа называется корректной, если эти свойства выполняются. Обычно в качестве языка
аннотаций используется некоторый логический язык. Задача дедуктивного верификатора — доказать корректность аннотированной программы или
указать условия, при которых выполнение этой программы некорректно.
Дедуктивный верификатор рассматривает аннотированную программу
как формулу некоторого логического исчисления (называемого аксиоматической семантикой в контексте дедуктивной верификации) и преобразует ее
в наборы формул некоторого логического языка в соответствии с определенной стратегией логического вывода в этом исчислении таким образом, что
из истинности полученных в результате преобразования формул (называемых условиями корректности этой программы) следует корректность самой
программы.
Для доказательства условий корректности дедуктивный верификатор
применяет разного рода средства автоматической поддержки доказательства (универсальные средства автоматического или интерактивного доказательства такие, как, например, PVS или HOL; SAT-решатели, SMT-решатели и др.). Применительно к задаче дедуктивной верификации будем называть эти средства решателями условий корректности.
В качестве логического исчисления в дедуктивных верификаторах обычно используется логика Хоара или ее расширения. Инструменты, базирующиеся на логике отделимости (separation logic) и исчислении синонимов
(alias calculus), также можно отнести к дедуктивным верификаторам в случае, если эти инструменты базируются на некотором виде аксиоматической
семантики.
Опишем, как выглядит процесс разработки дедуктивного верификатора.
Сначала разрабатывается концепт дедуктивного верификатора. Его разработка включает выбор целевого языка, языка аннотаций, аксиоматической
семантики, методов оптимизации условий корректности, решателя условий
корректности и т. д. После того, как он разработан, можно выделить три
подхода к его реализации.
В первом подходе дедуктивный верификатор разрабатывается напрямую
на некотором языке программирования общего назначения. Единственным
достоинством этого подхода является большая степень свободы в оптимизации разрабатываемого верификатора. Эта степень ограничена только уровнем компетенций разработчика. Отметим недостатки подхода. Во-первых,
при этом подходе высока сложность разработки, поскольку снижается уровень абстракции при переходе от концепта к реализации. Во-вторых, по той
же причине, обоснование корректности верификатора представляет сложную проблему. В-третьих, верификатор не является гибким, поскольку ориентирован на конкретные целевой язык, язык аннотаций и аксиоматическую
семантику.
Во втором подходе аннотированная программа транслируется в программу на промежуточном языке, для которого уже имеются дедуктивные веМеждународная научно-практическая конференция: ИНСТРУМЕНТЫ И МЕТОДЫ АНАЛИЗА ПРОГРАММ
67