The unprecedented use of computers in all areas of human activity makes the challenge of building errorless programs the central one of informatics.
The challenge is of utmost importance for developing built in program systems for managing critical applications where defects of programming can lead to catastrophic consequences. The cost of activities to ensure errorless behavior of built in software management systems amounts to more than a half of their development cost.
Modern day methods of software quality assurance include a variety of means, techniques, and approaches. Although testing and debugging stay the main method, verification, i.e. the formal proof of meeting a set of formal requirements by a formal program system model, has been gaining wider use recently. The method of Model checking has become a breakthrough trend in the area of formal verification.
The method of Model checking can be used for software and hardware systems that represent a model of transformations with a finite number of states. Therefore, the main problem of this method is the “state explosion problem”, i.e. the exponential growth of the number of states of a parallel programs system as the number of interacting components grows. The development of “symbol” algorithms based on economical methods of representing the final data structures has lead to a reduction of this method’s sensitivity to the “state explosion problem” and a significant increase in the efficiency of this method of verification. The “symbol” methods of verification have been successfully used in many practical development projects of building real program systems. Currently this technique is used as a technological phase in many large firms who develop built in systems for critical applications.
Model checking stays a “hot” area of informatics, as intensive research continues to be underway and as the means of this approach are being broadened.
A group of leading scientists in the area of applying formal software development methods has launched an ambitions international research project named “Verified Software Initiative”. The goal of the project is to bring the theoretical foundation, the instruments, and the elements of the verification technology to a state where they will allow developing errorless software systems.
Введение в тестирование программного обеспечения
ЕСЛИ ВЫ ЧТО-НИБУДЬ МОЖЕТЕ УЗНАТЬ ИЗ ЭТОГО,
ТО ЭТО -ПРОВЕРИТЬ СВОЙ КОД ТАК, КАК БУДТО ЖИЗНЬ ЗАВИСИТ ОТ НЕГО.
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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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 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
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: 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 dynamic Analysis of Executable Code in ELF Format Based on Sta...Iosif Itkin
The dynamic analysis of executable code in ELF format based on static binary instrumentation
Mikhail Yermakov,ISP RAS
12 - 14 November 2015
Tools and Methods of Program Analysis in St. Petersburg
TMPA-2015: Kotlin: From Null Dereference to Smart CastsIosif Itkin
This document discusses Kotlin, a statically typed programming language that targets the JVM and JavaScript. It was developed by JetBrains since 2011 and is now open-source. Kotlin is null-safe, object-oriented, and compatible with both Java and Scala. It provides features like type inference, higher-order functions, and extension functions while being simpler than Scala.
TMPA-2015: A Need To Specify and Verify Standard FunctionsIosif Itkin
This document discusses the need to formally specify and verify standard mathematical functions in programming languages like C. It uses examples of computing pi using Monte Carlo simulation and solving quadratic equations to show that functions like rand() and sqrt() are not precisely defined, which causes problems for formal verification. The document argues that alternative functions or interval analysis approaches could provide more rigorous specifications of functions like sqrt.
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
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: 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: 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: 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: 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: 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
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
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
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
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: 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 dynamic Analysis of Executable Code in ELF Format Based on Sta...Iosif Itkin
The dynamic analysis of executable code in ELF format based on static binary instrumentation
Mikhail Yermakov,ISP RAS
12 - 14 November 2015
Tools and Methods of Program Analysis in St. Petersburg
TMPA-2015: Kotlin: From Null Dereference to Smart CastsIosif Itkin
This document discusses Kotlin, a statically typed programming language that targets the JVM and JavaScript. It was developed by JetBrains since 2011 and is now open-source. Kotlin is null-safe, object-oriented, and compatible with both Java and Scala. It provides features like type inference, higher-order functions, and extension functions while being simpler than Scala.
TMPA-2015: A Need To Specify and Verify Standard FunctionsIosif Itkin
This document discusses the need to formally specify and verify standard mathematical functions in programming languages like C. It uses examples of computing pi using Monte Carlo simulation and solving quadratic equations to show that functions like rand() and sqrt() are not precisely defined, which causes problems for formal verification. The document argues that alternative functions or interval analysis approaches could provide more rigorous specifications of functions like sqrt.
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
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: 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: 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: 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: 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: 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
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
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
Портирование C++ приложений на FLASCC: опыт Unreal Engine 3. Павел Наказненко...Unigine Corp.
Павел Наказненко, разработчик, freelance (Красноярск)
На основе нашего опыта портирования Unreal Engine 3 и Free Heroes 2 на Flash, расскажу немного о технологии FLASCC, а также тонкостях портирования С++ игр с помощью нее.
Восток — дело тонкое, или Уязвимости медицинского и индустриального ПОPositive Hack Days
Ведущие: Эмиль Олейников и Юрий Гуркин
Как медицинские, так и SCADA-системы обладают возможностью удаленного управления, настройки и наблюдения. Зачастую их подключают к интернету. В докладе рассказывается об уязвимостях в специализированном ПО, используемом в медицине и промышленности, которые были исследованы с помощью отечественного пентест-фреймворка EAST (exploits and security tools). Аналогично Metasploit, он позволяет автоматизировать и облегчить поиск уязвимостей и иллюстрацию уровня риска.
Будут рассмотрены следующие основные вопросы:
• Оптимальный выбор компьютерной техники для решения офисных задач;
• Особенности совместимости программного обеспечения;
• Организация технического обслуживания компьютерной техники, предотвращение ее преждевременного выхода их строя;
• Операционные системы, особенности настройки и использования;
• Локальная компьютерная сеть и сеть Интернет;
• Борьба с компьютерными вирусами;
Аудит безопасности программного кода: Подходы, стандарты, технологии выявлени...Andrey Fadin
Семинар ставит целью познакомить технических специалистов как с теоретическими, так и с прикладными вопросами оценки безопасности кода приложений (ПО).
Затрагиваются вопросы нормативной базы, классификации уязвимостей и дефектов ПО, а также стандартизации терминов и методик аудита, рассматриваются различные методы статического и динамического анализа, менеджмент процесса, существующие инструменты в этой области.
Similar to TMPA-2013 Conference: Verification of Parallel Programs – Current Stage and Perspectives (20)
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
The document discusses test oracles, which are mechanisms for determining whether a test has passed or failed. It describes how oracles work by comparing the actual output of a system under test to the expected output determined by the oracle. Several types of oracles are discussed, including hand-crafted oracles, specification-based oracles, and independent implementation oracles. The document emphasizes that all oracles are partial, as it is impossible to create a perfect oracle that evaluates all possible outputs of a system.
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
The document summarizes the agenda for the QA Community Tbilisi event on April 20, 2019 in Tbilisi, Georgia. The agenda included presentations on topics like principles of deep testing, quality in space, behavior driven development, test automation, and obstacles of software testing in Georgia. There was also information provided about Exactpro and their history, tools and methods for testing financial systems, and test automation for distributed ledger technology. The document encouraged participants to provide feedback and announced an upcoming prize drawing for those who engaged on the event's Facebook page.
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
2. Ю.Г.Карпов ТМРА 2013 Кострома 2
Проблема
Компьютеры – повсюду Ubiquitous computing
(вездесущие вычисления)
ИТ проникли во все сферы жизни современного общества.
Раньше компьютер был компьютером, а телефон – телефоном, и
любой мог отличить одно от другого. Cейчас и компьютер – не только
компьютер, и телефон – не только телефон … (A.Tanenbaum)
Эра параллельного программирования
Последовательные программы имеют очень узкое применение.
Встроенные системы программного управления обычно параллельны.
Многоядерные чипы, встроенные бортовые СУ -> требуются
технологии разработки параллельного ПО, чтобы оно выполняло
нужные функции
“multicore processors are bringing parallelism to mainstream of computing”
Параллельные программы полны ошибок
Параллельные программы непостижимы для человеческого мозга:
даже простейшие программы трудно понять.
Как следствие - они очень часто неправильны, содержат ошибки
3. Ю.Г.Карпов ТМРА 2013 Кострома 3
Пример параллельной программы: частично
корректна, но тотально некорректна
Параллельная программа разделения множеств (Э. Дейкстра)
все наименьшие собираются в S, все наибольшие – в L:
Small::
mx := max(S); α! mх; S := S - { mx };
β? x; S := S ∪ { x }; mx := max(S);
while mx > x
do
α! mx; S := S - { mx };
β? x; S := S ∪ {x}; mx := max(S);
od
Large::
α?y; L := L ∪ { y }; mn := min( L );
β! mn; L := L - {mn}; mn:=min( L );
while mn < y
do
α? y; L:=L ∪ {y}; mn := min( L );
β! mn; L:=L - {mn}; mn := min( L )
od
8
14
9
7 146
23
15
134
54
9 46
6
66
Small:: Large::
S L
Network
α
β
Карпов Ю.Г. Анализ корректности параллельной программы разделения множеств //
Программирование, 1996, N6,
Найдите ошибку в || программе, содержащей 2 процесса по 5 строк
4. Программа подсчета числа автомашин на мосту
Process A::
…
N++
…
Ю.Г.Карпов ТМРА 2013 Кострома 4
Process B::
…
N--
…
Ошибка в || программе из одной строки???
A1. N -> RA
A2. RA+1 -> RA
A3. RA -> N
B1. N -> RB
B2. RB - 1-> RB
B3. RB -> N
Теоретически
может насчитать
все, что угодно
A1, A2, A3, B1, B2, B3
A1, A2, B1, B2, B3, A3
B1, B2, A1, A2, A3, B3
Тестированием найти
ошибку невозможно!!
5. Ю.Г.Карпов ТМРА 2013 Кострома 5
Ошибки параллельных программ
Системы программного управления строятся из параллельных
взаимодействующих модулей. Ошибки в них часто являются
критическими
Некорректные параллельные программы работают правильно “почти
всегда”. Они могут годами сохранять ошибки, проявляющиеся после
долгой эксплуатации как реакция на возникшую специфическую комбинацию
многочисленных факторов, в частности, непредсказуемых скоростей
выполнения отдельных процессов в параллельных программах
“Существует обширный печальный опыт того, что
параллельные программы упорно сопротивляются
серьезным усилиям по выявлению в них ошибок”
S. Owicki, L. Lamport “Proving liveness properties of concurrent programs”, ACM
TOPLAS, N4, 1982
6. Миллионы сообщений об ошибках в ОС Windows
По признанию Майкрософта, в ОС Windows остаются тысячи
ошибок!
Июнь 2013: Microsoft анонсировала программу премирования
пользователей, отыскавших уязвимости в предварительной версии
операционной системы Windows 8.1. Тем, кто обнаружит ошибку или
уязвимость, обещано выплатить до $100 000.
Ю.Г.Карпов ТМРА 2013 Кострома 6
Можно ли поставить ОС Windows на спец компьютер, управляющий
атомной электростанцией?
70 млн
документов об
ошибках в
Windows
7. Ю.Г.Карпов ТМРА 2013 Кострома 7
СМИ о программных ошибках – каждый день
Апрель, 2010. Авария в Мексиканском заливе: возможна ли программная
ошибка? Don Shafer, Phillip Laplante. The BP Oil Spill: Could Software be a Culprit?
IEEE IT Pro September/October 2010, IEEE, 2010. ... Не могла ли одной из причин
бедствия стать ошибка в программном обеспечении?
Вoing 757, 1995 г (рейс из Майами в Кали, Колумбия ). Ошибка в одном
символе в Flight Management System привела к катастрофе. Погибли 159 чел
08.12.2010 — Японский зонд «Акацуки» не смог выйти на орбиту Венеры
Из-за ошибки в бортовой СУ космический исследовательский аппарат «Акацуки»,
запущенный Японией для исследования Венеры, не смог выйти на орбиту планеты
06.12.2010. “Cпутники ГЛОНАСС и ракету “Протон-М” утопили программисты”.
Ракета-носитель «Протон-М» со спутниками «Глонасс-М» отклонились от заданного курса
из-за допущенных ошибок в математическом обеспечении (основная причина -
неправильно написанная формула в документации на заправку разгонного блока)
2.09.88 г. Связь с советской АМС "Фобос-1" прервалась из-за ошибочной
команды, посланной с Земли. АМС потеряна, где-то летает сама по себе
8. Ю.Г.Карпов ТМРА 2013 Кострома 8
Ошибки во встроенных программных системах
автомобильной индустрии
2010. Toyota отозвала с рынков >8 млн проданных автомобилей из-за
неисправности педали газа и дефекта ПО тормозной системы. Это обойдется
ей в $2 млрд. Глюк автомобилей Toyota стал причиной не менее 5 смертей.
Акио Тойда, президент компании Тойота, 24.02.2010 выступил в Конгрессе
США и принес извинения за проблемы, связанные с качеством автомобилей
Эксперты: проблемы возникли из-за перехода автомобильной индустрии на
программные системы в критически важных функциональных узлах
“Основная проблема именно в компьютерной системе управления, в
которой не было предусмотрено экстренное торможение: педаль тормоза
просто не срабатывала, когда сенсор акселератора командовал
автомобилю разгоняться
В 2009 г. В США производителями отозвано 19 млн автомобилей из-
за ошибок в программах и электронике
9. Ошибки в критических инфраструктурных системах
http://www.osp.ru/os/2009/03/8158133/
Блэкаут на северо-востоке США (август 2003 г.): из-за ошибки в
многозадачной программе мониторинга возникло переполнение буферной
памяти. Система попала в бесконечный цикл. Операторы остались без
актуальной информации о состоянии энергосистемы. Если бы
оперативная информация о состоянии энергосистемы была доступна,
оператор смог бы предотвратить каскадные сбои и минимизировать
убытки.
Сброс 4% нагрузки мог спасти ситуацию. Ущерб ~ 10$ млрд
www.icfi.com/Markets/Energy/doc_files/blackout-economic-costs.pdf
Ю.Г.Карпов ТМРА 2013 Кострома 9
10. Боевые потери США в Иракской войне
25.02.91. Операция “Буря в пустыне”: ошибка в системе управления Patriot
помешал перехватить иракскую ракету Scud, выпущенную по военной
базе Дахран в Саудовской Аравии. Ракета достигла цели, в результате
чего погибли 28 американских солдат и еще около 100 человек получили
ранения (www.fas.org/spp/starwars/gao/im92026.htm).
(Patriot - мобильная система противоракетной обороны США , оснащаемая ракетами
класса «земля-воздух» и предназначенная для защиты от самолетов, крылатых
ракет и баллистических ракет ближнего радиуса действия)
Ю.Г.Карпов ТМРА 2013 Кострома 10
11. В NASA признали потерю Deep Impact
Последний успешный сеанс связи с Deep Impact состоялся 8 августа
2013, после чего контакт с зондом был потерян. По оценкам
инженеров NASA, причиной обрыва связи стали ошибки в ПО, из-за
чего зонд потерял ориентацию в пространстве
Deep Impact был запущен в январе 2005 года. Его основная миссия
заключалась в исследовании кометы Темпеля; она успешно была
завершена спустя полгода после запуска
Ю.Г.Карпов ТМРА 2013 Кострома 11
21.09.2013. Специалисты NASA объявили о прекращении попыток
восстановить связь с исследовательским зондом Deep Impact
12. Ю.Г.Карпов Верификация 12
Needham-Schroeder протокол
аутентификации (1978)
КАК убедиться в том, что собеседник является тем, за кого он себя выдает?
Только если он продемонстрирует знание СЕКРЕТА, известного только ему
NS протокол решает эту проблему с исп публичного и секретного ключей. После
установления соединения и удостоверения, кто есть кто, собеседники могут установить
сессию с секретным ключом!! Широко использовался (Kerberos основан на нем)
1.〈 А, NA 〉PK(В)
2.〈 NA, NB 〉PK(А)
3.〈 NB 〉PK(В)
1. Alice генерирует nonce NA, шифрует
сообщение публичным ключом PK(B), и
посылает по открытому каналу.
NA - первая половина “секрета”,
А - идентификация отправителя
2. Только Bob может прочитать первое
сообщение. Он генерирует свой секрет -
nonce NB, шифрует сообщение ключом
PK(А), и посылает NA и NB.
То, что в сообщении присутствует NA,
убеждает Alice, что это Bob прислал –
только он мог дешифровать первое
сообщение. Она принимает NA, NB как
общий секрет и уверена, что установила
связь с В
3. Alice отсылает NB, зашифрованное
публичным ключом PK(В).
То, что в сообщении присутствует NB,
убеждает Bob, что это Alice прислала –
только она могла дешифровать второе
сообщение с его, Боба, nonce.
Поэтому Bob также принимает NA и NB
как общий секрет и уверен, что
установил связь с А
13. Ю.Г.Карпов ТМРА 2013 Кострома 13
Несет ли программист ответственность за потери
человеческих жизней?
Программирование является единственной областью
инженерной деятельности,
где разработчик не отвечает за качество своей работы
Обычно ПО имеет 10-15 ошибок на 1000 строк кода,
ПО высокого качества – 3 ошибки на 1000 строк кода
Современное ПО содержит миллионы строк кода,
уже сданные программы наполнены ошибками
SOFTWARE HORROR STORIES: http://www.cs.tau.ac.il/~nachumd/horror.html
Collection of Software Bugs: http://www5.in.tum.de/~huckle/bugse.html
Worst software defects in history:
http://cristianpocovnicu.wordpress.com/2011/03/22/worst-software-defects-in-history/
Википедия: http://en.wikipedia.org/wiki/List_of_software_bugs
Ужасы из-за ошибок ПО - в Интернете:
14. Ю.Г.Карпов ТМРА 2013 Кострома 14
Конфуз с голосованием на выборах в Думу
4 декабря 2011
Σ 146.47%
Прооиски
режима?
15. Ю.Г.Карпов ТМРА 2013 Кострома 15
Конфуз с голосованием на “Эхе Москвы” 24.09.2011
http://www.echo.msk.ru/programs/interception/814452-echo/
А.В.Венедиктов:
“Подвисает система голосования...
У меня возникает 111% ...”
За Путина
хП:=0;
while !Stop
do
wait call_1;
xП ++
od
За Путина:
111%
За Медведева
хМ:=0;
while !Stop
do
wait call_2;
xМ ++
od
Σ
while !Stop
do
xΣ :=xП+хМ
od
%П
while !Stop
do
PП :=xП / xΣ
od
%М
while !Stop
do
PМ :=xМ / xΣ
od
Параллельная композиция процессов:
Эта система параллельных процессов
может выдать любой процент!!
16. Ю.Г.Карпов ТМРА 2013 Кострома 16
Свойства
системы
Свойства
системыСистемаСистема
Верификация – метод повышения качества
программ
Процедура
проверки
Спецификация
системы
(формальная
модель)
Спецификация
требований
(на формальном
языке)
Верификация - формальное доказательство того, что программная
система удовлетворяет формально определенным требованиям
Формально доказать
можно только нечто
формально
определенное
17. Основные подходы к верификации программ
Алгебры процессов
Дедуктивная верификация - метод Флойда-Хоара
Ю.Г.Карпов ТМРА 2013 Кострома 17
18. 18
Algebra of Communicated Processes – ACSR Laws
Законы бисимуляции ACSR (Algebra of communicated shared resources, 1995)
Ю.Г.Карпов ТМРА 2013 Кострома
19. 19
Пример доказательства корректности дедуктивным
методом Флойда-Хоара
Программа находит произведение К=m×n с помощью сложений
НАЧАЛО
КОНЕЦ
i = m данет
K := 0;
i := 0;
K:= K + n;
i := i + 1;
Т1: [ m,n∈N ∧ m>0 ∧ K=0 ∧ i=0 ] ⇒ [ K = i × n ]
Т3: [ ( K-n = (i -1)×n ) ∧ (i -1 ≠ m) ] ⇒ [ K = i ×n ]
Т2: [ ( K=i×n) ∧ (i= m) ] ⇒ [ K= m×n ]
Доказательство
корректности программы
требует доказательства
трех теорем
{ A :: K = i×n }
Инвариант цикла:
при каждом попадании в эту точку
К=i×n
{R:: K=m×n}В конце программы должны получить
желаемый результат
{I:: m,n∈N; m≥0}В начале программы - ограничения
на исходные данные
Ю.Г.Карпов ТМРА 2013 Кострома
20. Ю.Г.Карпов ТМРА 2013 Кострома 20
Пример дедуктивной верификации ядра реальной
ОС
Сообщение СМИ 01.10.2009
Research Centre of Excellence компании NISTA (Australia) объявил о
завершении работы по формальному доказательству корректности
ядра ОС с помощью интерактивной системы доказательства теорем
Isabelle
Руководитель работы Dr. Klein:
“Этот экстраординарный результат открывает путь к разработке
нового поколения ПО с беспрецедентным уровнем надежности. Это
одно из самых длинных из когда-либо выполненных формальных
доказательств с помощью формальных средств theorem-proving”
21. Ю.Г.Карпов ТМРА 2013 Кострома 21
Оценка сложности доказательства ОС Secure
Embedded L4 microkernel дедуктивным методом
Построение доказательства ядра ОС L4
~ 60 человеко-лет работы
Проверка 10 строк кода – 1 чел-месяц работы верификатора
Cложность доказательства в 30 раз выше сложности кода;
одна строка кода - ~ 1 страница доказательства
Аллен Эмерсон о дедуктивной верификации: “мы писали 15-страничный
отчет о том, что программа на полстраницы корректна”
Трудозатраты: 4 года работы группы из 12 исследователей, PhD студентов
и нескольких других работников
Объем: доказанная ОС содержит
7,500 строк C code.
Сложность доказательства:
10,000 промежуточных теорем,
200,000 строк доказательства
22. 22
Выводы
• До последнего времени методы верификации могли быть
применены для доказательства корректности только “toy examples”
нотация сложна и неясна, ошибки встречались и в доказательствах
методы не масштабируемы (not scalable), требовали огромных усилий
программные инструменты неадекватны и трудны в использовании;
верификация проводилась интерактивно
требовалась высокая квалификация для выполнения и спецификации,
и анализа
Ю.Г.Карпов ТМРА 2013 Кострома
23. Ю.Г.Карпов ТМРА 2013 Кострома 23
"Практики! Опасайтесь фанатиков формальных методов"
R. L. Glass, САСМ, 2004 (редактор J. of Systems and Software)
24. Ю.Г.Карпов ТМРА 2013 Кострома 24
Model checking - прорыв в верификации
~ 20 лет назад – качественный прорыв в области
верификации дискретных систем
Разработан метод model checking, основанный на
изящных формальных моделях
26. Ю.Г.Карпов ТМРА 2013 Кострома 26
Fq – q случится когда-нибудь в будущем
t
q
t |= Fq
Gq – q всегда будет выполняться в будущем
t
q
t |= Gq
Формализация требований к программе.
Использование модальностей. Tense Logic (A.Prior 1950-
е)
pUq – q случится в будущем, а до него
непрерывно будет выполняться р
t |= pUq
t
p
q
Хq - q выполнится в следующий момент
t
q
t |= Xq
t |= Ф : формула Ф истинна в момент времени t
Рq – q случилось когда-то в прошлом
t
q
t |= Pq
27. Ю.Г.Карпов ТМРА 2013 Кострома 27
Примеры формализации высказываний в Tense
Logic
Мы придем к победе коммунистического труда!
F Коммунистический_труд_победил!
Ленин – жил, Ленин – жив, Ленин – будет жить (В.В.Маяковский)
P G Ленин_жив
Сегодня он играет джаз, а завтра Родину продаст (В.Бахнов)
G(Он_играет_джаз ⇒ FX Он_продает_Родину)
Я когда-нибудь умру ...
Я_жив ∧ F¬Я_жив ∧ G ( ¬Я_жив ⇒ G ¬ Я_жив )
Любой запрос к ресурсу будет висеть до его подтверждения либо отклонения
G(Request ⇒ Request U (Reject ⊕ Confirm ) )
Между моментом, когда процесс А изменяет значение переменной, и
моментом, когда процесс В читает это значение , оно должно быть
вытолкнуто из кэша процесса А:
G ( Update_A ∧ F Read_B ⇒ ¬Read_B U Flush_A)
28. Ю.Г.Карпов ТМРА 2013 Кострома 28
LTL в дискретном времени – А. Пнуэли (1977)
На всей цепочке выполняются формулы p, q, qU(r∧q), - они истинны в w0
Семантика “возможных миров” Лейбница, в каждом свое понимание истинности:
В каждом мире произвольная логическая формула истинна, либо нет:
Это же справедливо и для произвольной темпоральной формулы:
w0
р=true
q=true
r=false
w1
р=false
q=true
r=true
w2
р=false;
q=false;
r= true
...
wn
р=false;
q=false;
r= true
...
......
w0 w1 w2
p, q, ~r,
~(q⇒r),
~(r&~q)
wn
~p, q, r,
q->r,
~(r&~q)
~p, ~q, r,
q->r,
r&~q
~p, ~q, r,
q->r,
r&~q
......
w0 w1 w2
p, q
~(q->r),
~(r&~q),
qU(r ∧q),
FGr
wn
~p, q, r,
q->r,
~(r&~q),
qU(r ∧ q),
FGr
~p, ~q, r,
q->r,
r&~q,
~qU(r∧q),
FGr
~p, ~q, r,
q->r,
r&~q,
~qU(r ∧q),
FGr
Модель времени – последовательность целых (вчера, сегодня, завтра, …)Модель времени – последовательность целых (вчера, сегодня, завтра, …)
29. Ю.Г.Карпов ТМРА 2013 Кострома 29
Linear Temporal Logic (LTL) – Amir Pnueli (1977)
Логика LTL – темпоральная логика линейного времени –
утверждения о свойствах бесконечных вычислений
Формула ϕ LTL это :
атомарное утверждение (атомарный предикат) p, q, ...,
или Формулы, связанные логическими операторами ∨, ¬
или Формулы, связанные темпоральными операторами U, X
• Модальностей прошлого в LTL нет
Выводимые темпоральные операторы :
F ϕ = true U ϕ
G ϕ = ¬F ¬ ϕ
Грамматика: ϕ ::= p | ϕ ∨ ϕ | ¬ ϕ | X ϕ | ϕ U ϕ
LTL
к логике высказываний
добавлены только два
модальных оператора:
Until и NextTime
Базис LTL = {¬, ∨, U, X }
s0
p, q q, r r
s1 s2
... r
sn
...
30. Ю.Г.Карпов ТМРА 2013 Кострома 30
LTL и спецификация свойств дискретных систем
s0
t0
s1 s2
...
sn
...
t1 t2 tn
Формулы LTL интерпретируются на вычислениях - бесконечных
цепочках состояний системы с неделимыми переходами:
s0
p, q q, r r
s1 s2
... r
sn
...
Атомарные предикаты - базисные свойства процесса в состояниях:
p, q,
qUp
q, r
Gr
r,
Gr
... r
Gr
...
Производные темпоральные формулы в состояниях – это свойства
вычисления в будущем, определяющие динамику процесса:
qUp – выполняется на вычислении
Gr – не выполняется на вычислении
31. Ю.Г.Карпов ТМРА 2013 Кострома 31
Линейное и ветвящееся время
а
b,аc
d
а
c
d b,аb,а
Cтруктура Крипке –
система переходов с
помеченными
состояниями и
непомеченными
переходами
Развертка структуры
Крипке определяет
бесконечные
цепочки состояний -
возможные
ВЫЧИСЛЕНИЯ
Каждое состояние может иметь не одну, а множество цепочек – продолжений,
и является корнем своего дерева историй (вычислений)
Но как понимать формулы LTL: Gp, pUq, … в состоянии? Для какого пути?
Ввести “кванторы пути”
Е ϕ ≡ “существует такой путь из данного состояния, на котором ϕ истинна”
А ϕ ≡ “для всех путей из данного состояния формула пути ϕ истинна”
Очевидно, А ϕ ≡ ¬Е ¬ϕ
Как конечным образом задать бесконечные вычисления?Как конечным образом задать бесконечные вычисления?
cUb?
32. Ю.Г.Карпов ТМРА 2013 Кострома 32
Темпоральная логика ветвящегося времени
AGAF Restart
из любого состояния при любом функционировании системы
обязательно вернемся в состояние рестарта
¬EF( int >0.01)
не существует такого режима работы, при котором интенсивность
облучения пациента превысит 0.01 радиан в сек
AG ( req ⇒ (req U ack))
во всех режимах после того, как запрос req установится, он никогда не
будет снят, пока на него не придет подтверждение
E[ p U A [q U r] ]
cуществует режим, в котором условие p будет истинным с начала
вычисления до тех пор, пока q не станет непрерывно активным до
выполнения условия r
Темпоральные логики: прорыв в формализации и понимании
требований к поведению параллельных систем
33. Ю.Г.Карпов ТМРА 2013 Кострома 33
Пример свойства, выраженного формулой логики CTL
Любой грешник всегда имеет шанс вернуться на путь истинной веры
Всегда, куда бы мы ни попали в нашей жизни (AG), существует такой путь, что
на нем в конце концов обязательно попадем (ЕF) в состояние, с которого идет
путь (EG) ‘истинной веры’
AG EF EG ‘истинная_вера ’
34. Ю.Г.Карпов ТМРА 2013 Кострома 34
Спецификация свойств поведения дискретных
схем
σ0 ¬⊧ p
σ0 F ¬⊧ q
σ0 G(⊧ p→q)
σ0 q U p⊧
σ0 FG(¬p⊧ ∧q)
p,q p qq q …qp q qqq
σ:
σ:
35. Ю.Г.Карпов ТМРА 2013 Кострома 35
Структура Крипке синхронных схем c памятью
Переходы выполняются в каждом такте
Задержка: логическая схема - 0, память – 1
Два начальных состояния
XOR
OR
NOT
r
p
q
p
q
r
p=0,
r=0,
q=1
p=1,
r=0,
q=0
p=0,
r=1,
q=0
10
p=1,
r=1,
q=1
1
0
1
0
0 1
q=¬(p⊕r)
q p
r p, r,
q
Структура Крипке:
36. Ю.Г.Карпов ТМРА 2013 Кострома 36
Структура Крипке как модель программы с конечным
числом состояний
Состояние программы – вектор значений ее
переменных И метки (рс)
Переходы – изменение операторами значений
переменных программы
Пусть атомарные утверждения,
ИНТЕРЕСУЮЩИЕ НАС:
а=х>y; b=|x+y|<3
begin
х:=0; у:=1;
while x+z < 5 do
{ x:=5;
if z=1 then y:=x+1;
x:= -2; y:=1;
}
y:= x*y-5; x:=5;
end
х=0
У=1
х=5
У=-7 х=-2
У=1
х=5
У=6
х=5
У=1
х:=0; у:=1;
х:=5;
y:=x+1;
х:=-2;
у:=1;
b
a
b
ba
b
Если все переменные могут
принимать конечное число
значений, то граф конечен
37. Ю.Г.Карпов ТМРА 2013 Кострома 37
Свойства
системы
Свойства
системыСистемаСистема
Общая схема верификации Model checking
Спецификация системы
(формальная модель)
Процедура проверки
Спецификация требований
(формальный язык)
Формула темпоральной
логики
Структура Крипке
Формально доказать
можно только нечто
формально
определенное
Да, система удовлетворяетДа, система удовлетворяет
спецификацииспецификации
Нет, система НЕ удовлетворяетНет, система НЕ удовлетворяет
спецификацииспецификации
КОНТРПРИМЕРКОНТРПРИМЕР
Model checker
38. Ю.Г.Карпов ТМРА 2013 Кострома 38
Model checking – проверка того, является ли данная
структура Крипке моделью темпоральной формулы
Логика высказываний
F=(¬p ∨ q ) ⇒ r
И
Л
<И, И, Л>
<Л, И, Л>
<Л, Л, И>
Интерпретация <Л, Л, И> - модель формулы F
Темпоральная логика
Ф=AG[(p ⇒ E(¬q U r )]
И
Л
Интерпретации PL –
наборы значений
переменных <p, q, r>
К2
К1
К3
Интерпретации TL –
структуры Крипке,
в каждом состоянии
которых свой набор
значений
переменных <p, q, r>
Интерпретация К1 - модель формулы Ф
Model checking – проверка того,
является ли К моделью Ф
39. Ю.Г.Карпов ТМРА 2013 Кострома 39
Примеры использования подхода
Cambridge ring protocol
IЕЕЕ Logical Link Control protocol, LLC 802.2
фрагменты больших протоколов XTP и TCP/IP
отказоустойчивые системы, протоколы доступа к шинам,
протоколы контроля ошибок в аппаратуре, ... ...
криптографические протоколы
протокол Ethernet Сollision Avoidance
DeepSpace1 (NASA) - после тщательного тестирования и
сдачи системы были найдены критические ошибки, которые,
по мнению экспертов, обязательно привели бы к аварии в
полете
С помощью Model checking были найдены ошибки во
многих критических программных системах
49. Ю.Г.Карпов ТМРА 2013 Кострома 49
Контрпример:
ВОТ КАК ПРОГОЛОСУЮТ!
Система процессов P1 || P2 || P3 || P4 || P5
Проверка свойства :
“За Путина не могут проголосовать 300%”
A G (pп < 300)
Верификация ПО голосования с
помощью верификатора SPIN
50. Ю.Г.Карпов ТМРА 2013 Кострома 50
Пример: верификация системы управления
электродвижением гидрофизического судна “Вайгач”
Функции системы управления:
контроль состояния судовых электростанций
и обработка критических ситуаций
автоматическая балансировка нагрузки между
двумя судовыми электростанциями
обработка команд вахтенного капитана
50
дизель генератор ГА
пульт
управления
Управление
двигателями Engine
Система
управления
В оттестированной и сданной заказчику
системе найдено несколько критических
ошибок, которые проявились при ходовых
испытаниях корабля на Белом море
Проект научной группы
Петербургского Политеха
51. 51
Атака на криптопротокол аутентификации Needham-
Schreder
Bob думает, что он говорит с Alice, а он говорит с Intruder!
А В
1.〈 А, NA 〉PK(В)
2.〈 NA, NB 〉PK(А)
3.〈 NB 〉PK(В)
1:<A, NA>PK(I)
2:<A, NA>PK(B)
3:<NA, NB>PK(A)4:<NA, NB>PK(A)
5:<NB>PK(I)
6:<NB>PK(B)
Alice BobIntruder
Ю.Г.Карпов ТМРА 2013 Кострома
52. Ю.Г.Карпов 52
Найденная атака в A||B||I
1
2
3
4
5
6
1. А начинает взаимодействовать с I как с
партнером, посылая ему <A, NA>PK(I)
2. I получает NА – секрет А. Он маскируется под А,
используя секрет, полученный от А: посылает
сообщение <A, NA>PK(B) к В. В его дешифрирует и
считает, что это сообщение пришло от А
3. В считая, что говорит с А, посылает в ответ
сообщение <NA, NB>PK(A), которое зашифровано
открытым ключом А. I получает это сообщение.
Поскольку оно закодировано открытым ключом
А, I не может декодировать это сообщение
сам, но может переслать его А как бы от себя
4. Получив это сообщение, А видит свой NA,
считает, что обмен закончился успешно, и
посылает секрет В - <NB>PK(I) - своему партнеру,
агенту I, полагая, что им установлена связь с I
5. Это сообщение закодировано ключом для I и
содержит NB. Поэтому агент I может его
декодировать, получив секрет В - nonceB
6. I посылает этот NВ агенту В, который тоже
удовлетворен, считая, что установил связь с А,
но в действительности – связь с I
1: 2:
3:4:
5: 6:
ТМРА 2013 Кострома
53. Ю.Г.Карпов ТМРА 2013 Кострома 53
Success Story.
Транзакционная память в многоядерных процессорах
Транзакционная память – один из способов, позволяющих избежать
проблем синхронизации процессов над общей памятью
Многоядерные процессоры вывели параллельное
программирование и связанные с ним проблемы ошибок в
параллельных программах “в народные массы”
Как решать проблемы ошибок синхронизации параллельных
программ в многоядерных процессорах?
ядро 2ядро 1 ядро n
память
... ядро 2ядро 1 ядро n
память
...
протокол транзакционной памяти
54. Ю.Г.Карпов ТМРА 2013 Кострома 54
“Оконный” алгоритм транзакционной памяти
Damien Imbs, и Michel Raynal в 2009 г. предложили
оконный алгоритм транзакционной памяти вместе с
аналитическим доказательством его корректности
CV профессора Мишеля Райнала:
Michel Raynal - a professor of computer science since 1981.
At IRISA (CNRS-INRIA-University joint computing research
laboratory located in Rennes), he founded a research group on
Distributed Algorithms in 1983.
His research interests include distributed algorithms, distributed
computing systems and dependability. His main interest lies in
the fundamental principles that underlie the design and the
construction of distributed computing systems. He has been
Principal Investigator of a number of research grants in these
areas
Professor Michel Raynal has published more than 95 papers in
journals (JACM, Acta Informatica, Distributed Computing, etc.);
and more than 195 papers in conferences (ACM STOC, ACM
PODC, ACM SPAA, IEEE ICDCS, IEEE DSN, DISC, IEEE
IPDPS, etc.). He has also written seven books devoted to
parallelism, distributed algorithms and systems (MIT Press and
Wiley).
55. Ю.Г.Карпов ТМРА 2013 Кострома 55
Success Story. Ошибка в STM протоколе
Imbs D.; Raynal M. Software Transactional Memories: an Approach for
Multicore Programming. LNCS, 5698, 2009
Эта работа была дана студенту 4 курса Петербургского Политеха Алексею
Беляеву для проверки протокола в рамках его НИРС
Студент – построил модель протокола транзакционной памяти,
- описал требования к протоколу формулой темпоральной логики,
- использовал систему верификации SPIN
- нашел в протоколе ошибку
56. Ю.Г.Карпов ТМРА 2013 Кострома 56
Выводы
Даже опытные профессионалы могут допустить ошибки в
разрабатываемых ими параллельных программах
Нельзя полагаться на доказательства корректности параллельных
программ на основе рассуждений, как это было сделано в работе
проф. М.Райнала
Даже студент, используя технику Model checking, может найти
ошибки в достаточно сложной параллельной программе,
разработанной профессионалами
57. Ю.Г.Карпов ТМРА 2013 Кострома 57
Состояние области “Верификация управляющего
ПО”
Никаких доказательств и логического вывода
Эффективность
Контрпримеры, выдаваемые верификатором при нахождении
ошибки, можно использовать для диагностики ошибок
TL легко выражают многие проблемы параллельных процессов
В ведущих фирмах методы верификации аппаратуры и программ на
основе Model checking разработаны до индустриальной технологии
58. Ю.Г.Карпов ТМРА 2013 Кострома 58
Премия Тьюринга АСМ
21 июня 2008 г премия Тьюринга была вручена трем создателям
техники MODEL CHECKING, внесшим наиболее существенный вклад
Edmund M. Clarke (CMU),
E. Allen Emerson (U Texas, Austin),
Joseph Sifakis (Verimag, France)
“за их роль в превращении метода Model checking в
высокоэффективную технологию верификации, широко
используемую в индустрии разработки ПО и аппаратных средств”
ACM President Stuart Feldman :
“Это великий пример того, как технология, изменившая
промышленность, родилась из чисто теоретических исследований”
59. 59
Обучение верификации
Изучение верификации методом
Model checking даёт инженеру
теорию,
алгоритмы,
элементы технологии,
инструментарий
с помощью которых он может проверять
корректность нетривиальных
параллельных и распределенных программ
Ю.Г.Карпов ТМРА 2013 Кострома
60. Ю.Г.Карпов ТМРА 2013 Кострома 60
Материализация абстрактных понятий
Формализмы, на которых основан метод Model Checking:
темпоральные логики
линейное и ветвящееся время
структуры Крипке
недетерминированные автоматы Бюхи
бесконечные множества бесконечных цепочек (ω-языки)
синхронная и асинхронная композиция автоматов
неподвижные точки операторов на решетках предикатов ...
Все эти абстракции, которые и представить себе нельзя, привели к
разработке мощной техники верификации, которая стала частью
промышленной технологии разработки критического ПО и аппаратуры
Model checking - “реабилитация формальных методов”
61. Ю.Г.Карпов ТМРА 2013 Кострома 61
Необходимость формальных методов
“Формальные методы должны стать частью образования каждого
исследователя в области информатики и каждого разработчика
ПО так же, как другие ветви прикладной математики являются
необходимой частью образования в других инженерных областях.
NASA Report 4673, “Formal Methods and Their Role in Digital System Validation
for Airborne Systems”
В области разработки ПО необходимые разделы прикладной математики –
это формальные методы, на которых основывается верификация:
формальная логика,
теория автоматов,
теория алгоритмов
62. Ю.Г.Карпов ТМРА 2013 Кострома 62
Перспективы верификации
Нельзя надеяться, что программные системы
из десятков миллионов строк кода могут
быть полностью верифицированы прямо сейчас,
непосредственным механическим применением
существующих техник и технологий
63. Ю.Г.Карпов ТМРА 2013 Кострома 63
Композициональность: доказательство свойств всей системы
на основе свойств отдельных компонент системы
Одно из направлений: Rely - Guarantee
Композициональность: метод определения свойств сложных
структур через свойства составляющих их подструктур и правил их
композиции
64. Ю.Г.Карпов ТМРА 2013 Кострома 64
Идеи Эдсгера Дейкстры:
Correctness by checking vs. Correctness by construction
Эдсгер Дейкстра:
вместо того, чтобы программу СНАЧАЛА
разрабатывать, а ПОТОМ пытаться доказать ее
правильность,
программу нужно сразу строить корректной
Программа должна выводиться строго логически из
точно сформулированной спецификации, а не
только исходя из опыта и общих соображений
В книге “Дисциплина программирования” Э.Дейкстры приведено
множество изящных примеров такого подхода к разработке
“Этот труд, несомненно, будет признан одним из выдающихся достижений в
разработке новой интеллектуальной дисциплины – программирования”
Антони Чарльз Хоар
65. Ю.Г.Карпов Верификация. Model checking 65
Разработка корректных программ (Э.Дейкстра)
“Голландский национальный флаг” – построить программу сортировки
массива из трех типов объектов – “красных”, “белых” и “синих”, которые
должны в результате стоять именно в этом порядке. Программа должна
справляться со всеми случаями вырождения: отсутствием одного или
нескольких цветов
Как подойти к разработке программы?
Выбрать ИНВАРИАНТ!
неотсортированные
исходный массив
результирующий массив
промежуточный массив
Крайними состояниями инварианта являются исходный и результирующий массивы
66. Ю.Г.Карпов Верификация. Model checking 66
Формализация инварианта
A ≡ [ ∀i: (1≤i<к) ] M[i] - красный
& [ ∀i: (б<i≤с) ] M[i] - белый
& [ ∀i: (с<i≤N) ] M[i] - синий
& [ ∀i: (к≤i≤б) ] M[i] - неотсортированный
& (к≥1) & (б≤с) & (с≤N)
Очевидно, что:
A & (к>б) ⇒ массив M отсортирован
(массив неотсортированных пуст)
Разработка программы сводится к построению цикла, который уменьшает зону
неотсортированных элементов, но при этом сохраняет инвариант
begin
I = { [∀i: (1≤i≤N) ] M[i] - неотсортированные}
к,б,с:=1,N,N;
/* инвариант цикла A */
do
<пока зона не отсортированных непуста> →
<уменьшить зону не отсортированных, не изменяя A>
od
{ R≡ массив M отсортирован }
end
Программа частично корректна, если
1) из I, преобразованного оператором
k,б,с := 1,N,N следует А,
2) A – инвариант цикла,
3) из А следует R по завершении цикла
Программа тотально корректна, если
при этом зона неотсортированных
уменьшается на каждом шаге цикла
бк1 с N
67. Ю.Г.Карпов Верификация. Model checking 67
Разработка программы, корректной по построению
begin
{ [∀i: (1≤i≤N)] M[i] – неотсортированный }
к,б,с:=1,N,N;
{A ≡ инвариант цикла}
do
к ≤б →
if [ ] M[б] = белый → б:=б-1;
[ ] M[б] = красный → поменять местами (M[б], M[к]); к:=к+1;
[ ] M[б] = синий → поменять местами (M[б], M[с]); с, б:=с-1, б-1;
fi
od
{R≡массив M отсортирован}
end
Для верификации программы нужно доказать:
1. sp (S0, I) ⇒ A или I ⇒ wp(S0, A)
2. A&¬G⇒R, т.е. A&(к<б) ⇒ R
3 -5. sp( Si, A&G&Gi)⇒ A или A⇒wp(Si, A&G&Gi )
6. Завершение программы: нужно доказать,
что б-к уменьшается при каждом прохождении цикла
begin
{ I }
S0
{A}
do
G →
if [ ] G1 → S1;
[ ] G2 → S2;
[ ] G3 → S3
fi
od
{R}
end
бк1 с N
Охраняемые команды Дейкстры:
A ≡ [ ∀i: (1≤i<к) ] M[i] - красный
& [ ∀i: (б<i≤с) ] M[i] - белый
& [ ∀i: (с<i≤N) ] M[i] - синий
& [ ∀i: (к≤i≤б) ] M[i] - неотсортированный
& (к≥1) & (б≤с) & (с≤N)
68. Ю.Г.Карпов ТМРА 2013 Кострома 68
Проектирование ПО на основе моделей
(Model Driven Development. MDD)
Модель
Верификация
Программа
Спецификация
требований
Имитационное
моделирование
Техническое
задание
Высокоуровневая
документация
Разработка
тестов
Бортовое ПО для Airbus А-340: более 70% кода сгенерировано
Абсурдно
ставить
проблему
доказательства
программы
после того, как
программа
написана
(Н.Н.Непейвода)
Разумно ли
СНАЧАЛА построить
самолет, а
ПОТОМ проводить
анализ, чтобы
увидеть, полетит ли
он?
69. Ю.Г.Карпов ТМРА 2013 Кострома 69
Verified Software Initiative
Tony Hoare, Jayadev Misra, Gary T. Leavens, and Natarajan Shankar
(2007)
Предлагают международный амбициозный исследовательский
долговременный проект по разработке основ конструирования
error-free программных систем
Попытка в течение следующих 15 лет:
Разработать обстоятельную Теорию программирования,
покрывающую формализмы и методики, необходимые для построения
практических надежных программ (error-free software)
Разработать программные инструменты для анализа ПО
индустриального масштаба
Построить библиотеки надежных программных компонент, которые
могут быть использованы в реальных проектах
71. Ю.Г.Карпов ТМРА 2013 Кострома 71
Biting the Silver Bullet
Frederic Brooks (1986 г., “No Silver Bullet”) - об иллюзиях и надеждах в
разработке ПО. Ни одна из предлагаемых в то время идей не является
“серебряной пулей”, которая спасет нас от ужасов, связанных с разработкой
больших комплексов ПО. Весьма пессимистический взгляд
David Harel, IEEE Computer, 1992
David Harel (1992): хотя единственного средства (“серебряной пули”)
нет, но интегральное использование новых идей может внести
существенный вклад в разработку сложных программных систем
72. Ю.Г.Карпов ТМРА 2013 Кострома 72
Возрастающее использование формальных методов
для верификации ПО на ранних стадиях разработки
Среди наиболее обещающих направлений:
разработка более тонких формализмов спецификации требований
объединение статического анализа кода и верификации
композициональная разработка и верификация
Model Driven Development: проверяемая модель – в центре разработки,
генерация кода из отлаженной и верифицированной модели
синтез СУ непосредственно из спецификации (синтез супервизоров)
Д. Харел (1992):
“Текущая ситуация и перспективы значительных улучшений
показывают, что мы находимся на пороге новой, удивительной эры”
Сегодняшние успехи формальной верификации показывают:
“БУДУЩЕЕ НАЧИНАЕТСЯ СЕГОДНЯ”
Верификация достигла уровня зрелости, но требует интеллектуальных
усилий в ее применении и дальнейшем развитии