1
1
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
Шаг 1. Написать спецификацию
Открыто соединение, данные переданы, соединение закрыто.
16
Шаг 1. Написать спецификацию
Открыто соединение, данные переданы, соединение закрыто, или выполнена отмена в любое время.
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
Runtime Reflection Pattern
Монитор ->• Реализован с помощью RV• Обнаруживает ошибки и• Оповещает о них
24
Runtime Reflection Pattern
Диагностика ->• Собирает вердикты монитора• Объясняет текущее состояние
25
Runtime Reflection Pattern
Смягчение ->• Пытается смягчить последствия• Сохраняет детальную
диагностическую информацию
26
Конференция (2001––2015)
• 22-25 сентября, Вена, Австрия
• Билеты по 759/550€
27
Куда двигаться дальше?
• Уменьшение накладных расходов
• Упрощение спецификаций
• Изменение поведения
• Почему так долго?
28