Надежность ПО и runtime verification

2

Кирилл ИгнатьевSoftware Developer in Test

Надежность ПОRuntime Verification

3

О чем поговорим

• Необходимость надежности ПО• Тестирование и его недостатки• Что такое верификация• Формальное определение• Инструменты Runtime Verification• Практическое применение

4

Ariane V88 Crash (1996) P_M_DERIVE(T_ALG.E_BH) := UC_16S_EN_16NS (TDB.T_ENTIER_16S ((1.0/C_M_LSB_BH) * G_M_INFO_DERIVE(T_ALG.E_BH)))

direct cost 500.000.000 € indirect cost 2.000.000.000 €

5

Важность проверки ПО

• Разработчики тратят от 50% до 70% времени тестируя и проверяя код

• Тем не менее, низкая надежность – все еще основная проблема ПО

• Недавнее исследование показывает, что баги отнимают от 60 миллиардов долларов ежегодно

6

Что у нас есть: тестирование

Тестирование – это проверка подмножества сценариев использования продукта.

Тестирование может обнаружить ошибки, но не может доказать их отсутствие.

Большинство программ могут принимать неограниченное множество входных данных.

7

Верификация

Верификация: Соответствует ли программа спецификации?

Спецификация также может содержать ошибки.

8

Верификация во время выполнения(Runtime Verification)

Runtime verification – техники верификации, которые позволяют проверить, удовлетворяет ли выполнение (a run) системы определенному условию корректности (correctness property).

9

Прогон и выполнение

Выполнение – возможно, бесконечная последовательность состояний системы.

Прогон – конечный префикс выполнения (trace).

Монитор проверяет, удовлетворяет ли прогон определенному условию корректности.

10

Добавляем монитор

11

Testing Runtime Verification

Удовлетворяет ли входным/выходным данным? Удовлетворяет ли система монитору?

Входные/выходные данные задаются вручную Монитор генерируется из условий корректности

Проблема: создание входных/выходных данных Проблема: генерация монитора

Проверяется текущее выполнение Проверяется текущее выполнение

Сравнение

13

Кому нужен Runtime Verification?• Когда цена ошибки высока (ракеты, самолеты,

процессоры, безопасность, репутация)

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

• Когда поведение приложения сильно зависит от окружения

• Для доказательства корректности системы (ИИ?)

14

Шаг 1. Написать спецификацию

Для этого есть языки: LTL (Linear Temporal Logic), SALT и др.

Это регулярные языки, но включающие еще и время:

15


Открыто соединение, данные переданы, соединение закрыто.

16


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

18

Шаг 2. Определить события (jUnitrv)

private static Event con_open = returned ( dataService , ”connect"); private static Event data = called ( dataService , ”transmit_data"); private static Event con_close = called ( dataService , "disconnect");private static Event reset = called ( dataService , ”reset");

@Test @Monitors ({”transmitData"}) public void test1 () {

// ... }

19

Готово!

20

Фреймворки

21

time Reflection Pattern

Паттерн разработки надежных систем

22

Runtime Reflection Pattern

Логирование ->

23


Монитор ->• Реализован с помощью RV• Обнаруживает ошибки и• Оповещает о них

24


Диагностика ->• Собирает вердикты монитора• Объясняет текущее состояние

25


Смягчение ->• Пытается смягчить последствия• Сохраняет детальную

диагностическую информацию

26

Конференция (2001––2015)

• 22-25 сентября, Вена, Австрия

• Билеты по 759/550€

27

Куда двигаться дальше?

• Уменьшение накладных расходов

• Упрощение спецификаций

• Изменение поведения

• Почему так долго?

Надежность ПО и runtime verification

Engineering