mc lect 01konnov/mc/2011/astana/mc_lect_01.pdf10 Ценаошибки: Patriot • Февраль1991 года, Patriot промахнулсямиморакетыScud, • Ущерб–28

Верификация программна моделях

Константин Савенков,Игорь Коннов

2

План лекции

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

• Обзор курса• Практикум

3

Разработка программыАнализ Проектиро-

ваниеРеали-зация

Тестирование Эксплуа-тацияUnit System

Внесённыеошибки

Обнаруженныеошибки

Ценаошибки

4

Правильность программ

• Нет требований – нет правильности• Ошибка – несоответствие требованиям• Ошибки:

– в формулировке требований,

building the wrong system,– в соблюдении требований,

building the system wrong.

5

Правильность программ

• Валидация – исследование и обоснование того, что спецификация ПО и само ПО черезреализованную в нём функциональностьудовлетворяет требованиям пользователей,

• Верификация – исследование и обоснованиетого, что программа соответствует своейспецификации.

найти ошибки или доказать, что их нетNB: ошибки формализации требований

6




7

Цена ошибки

• В ряде приложений ошибки некритичны:– сводятся к лёгким моральным травмам,– возможность обнаружения сбоя ивосстановления,

– возможность быстрого исправленияошибки.

8

Цена ошибки• Системы с повышеннымитребованиями к надёжности (Safety-critical)

• Ошибки приводят к:– Гибели или травмам людей,– Крупным финансовым потерям– Ущербу окружающей среде– И т.д.

9

Цена ошибки: Ariane-5

• Июнь 1996 года, взрыв ракеты спустя40 сек. после старта,

• Ущерб – $500млн (разработка – $7 млрд.),

• Причина – 64bit float -> 16bit int.

10

Цена ошибки: Patriot

• Февраль 1991 года, Patriotпромахнулся мимо ракеты Scud,

• Ущерб – 28 убитых, >100 раненых,• Причина – ошибка округления из-за

24bit fixed, Scud успел пролететь500м.

11

Цена ошибки: Sleipner A• август 1991 года, Северное море, платформа

Sleipner A затонула после разрушенияоснования,

• Ущерб – $700 млн, землетрясение силой 3 балла,

• Причина – ошибка округления примоделировании платформы.

12

Кое-что посвежее (2010)• Ошибки в ПО автомобилей: Toyota Prius (нарушен директивный

интервал включения ABS), Chrysler (можно вытащить ключ, непереключившись в режим парковки)

• Ошибки в программе обработки заявлений доноров органов вUK (у 25 человек взяли не те органы)

• Ошибка в электронной системе налоговой службы США (необслуживались 64-летние люди)

• Ошибка в антивирусе McAfee (системный файл Windows распознан как вредоносный и удалён, бесконечнаяперезагрузка)

• Отключение Skype (вышла из строя одна из версий клиента, что привело к сбою всей P2P сети)

• Ошибка в апдейте NYSE Euronext (S&P упал на 10%)• 88 критических ошибок в Android Froyo (доступ к личным

данным)

13

Повышенные требования кнадежности

• Не только спутники, самолёты и АЭС!• Системы, в которых

– затруднено исправление ошибок (потребительскаяэлектроника)

– велик масштаб использования (та же электроника, важные веб-сервисы)

– высокая степень доверия человека (augmented reality)

• Критически важных систем становитсявсё больше, они становятся болеесложными и интероперабельными.

14




15

Выборочное тестированиеДейкстра:«Тестирование может продемонстрировать наличие

ошибок, но не их показать отсутствие».

безвредные

критические

Выявление ошибокчастые редкие

тести-рование

формальныеметоды

неважно

16

Верификация:старые плохие новости

• Задача останова: построить такую МТH, которая по коду любой МТ M и входуI на ленте определит, останавливается Mна входе I или нет.

• Тьюринг, 1936: задача останованеразрешима.

17

Верификация:старые плохие новости

• Свойство S называется тривиальным, если оновыполняется:– либо для любой частично вычислимой функции,– либо ни для одной частично вычислимой функции.

• Райс, 1953: для любого заданногонетривиального свойства S не существуеттакого общего алгоритма D, что:– По алгоритму A алгоритм D определяет, вычисляетли A частично вычислимую функцию f, удовлетворяющую свойству S.

18

Верификация: что же делать?• Результаты Тьюринга и Райса показывают, что нет универсального подхода ко всемалгоритмам.– Вспомним «серебряную пулю» Брукса.

• Для практически интересных классовпрограмм постоянно изобретаются новыеметоды верификации.– Немногие из них работают «из-коробки».

19

Reminder

ВЕРИФИКАЦИЯ ПРОГРАММЫВ ОБЩЕМ СЛУЧАЕ

АЛГОРИТМИЧЕСКИ НЕРАЗРЕШИМА

См., например, задачу останова программы, теорему Райса, etc

20

Формальные методы

• Методы формальной спецификации.• Методы формальной верификации:

– доказательство теорем,– верификация моделей,– формальное тестирование,– статический анализ.

«Использование математического аппарата, реализованного в языках, методах и средствахспецификации и верификации программ»

21

Методы верификации

• «Полное» тестирование• Имитационное моделирование• Доказательство теорем• Статический анализ• Верификация на моделях• Динамическая верификация

22

Тестирование: терминология

• Для заданной программы P– Тест – вектор входных данных i ∈ D, состояние s программы и результат o, ожидаемый от программы P при подачеданных i в состоянии s.

– OK(o) верно тогда и только тогда, когдарезультат соответствует спецификации.

– Тестовый набор – набор тестовыхсценариев T={(i, s, o)}.

23

Тестирование: терминология

• Идеальный тестовый набор T={(i, s, o)}:– если для любого (i, s, o) ∈ T верно OK(o),– то для любого i’ ∈ D верно OK(P(i’)).

• Тестовый набор обеспечивает полноетестовое покрытие TC, если для любоговычисления π программы P найдётсятест (i, s, o) ∈ T, что π воспроизводитсяна (i, s, o).

24

Тестирование

• Обоснование полноты тестовогопокрытия,

• Метод «чёрного ящика» (ЧЯ) --полное покрытие входных данных,

• Метод «прозрачного ящика» (ПЯ) --полное покрытие кода программы.

25

Тестирование: плюсы

• Проверяется та программа, котораябудет использоваться.

• Понятно программистам!• Не требуется (знание) дополнительных инструментальныхсредств.

• Удобная локализация ошибки.

26

Тестирование: минусы• Не всегда есть условия длятестирования системы,

• Проблема с воспроизводимостьютестов (особенно в распределённойсреде).

частичное решение –имитационное моделирование

27

Тестирование: подводныекамни

• Полнота тестового покрытия:– ЧЯ: для последовательных программ сложноперебрать все входные данные,

– ЧЯ: для параллельных – очень сложно,– ЧЯ: для динамических структур данных, взаимодействия с окружением – невозможно.

– ПЯ: большой размер покрытия,– ПЯ: часто невозможно построить 100% покрытие,

– ПЯ: полное покрытие не гарантируетотсутствия ошибок.

28

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

• Поиск выигрышной стратегии вшашках:– 1014 тестов,– 18 лет,– постоянно работало от 50 до 200 десктопов.

29

Полное тестовое покрытие дляпрозрачного ящика

if (B1) {S1;

}

if (B1) {S1;

}if (B2) {

S2;}

- Два теста

- Четыре теста

…exp…

30

Полное покрытие строк кодадля прозрачного ящика

int x = 1;if (x == 1) {

std::cout << “Okay” << std::endl;} else {

std::cout << “Error” << std::endl;}

– полное покрытие строк кода невозможно

31

Полное покрытие строк кода –не панацея

int strlen(const char* p) {int len = 0;do {

++len;} while (*p++);return len;

}

«а», «bbb» -- полное покрытие кода,ошибка не найдена

32

Полнота покрытия: итоги

• Полный перебор входных данных –невозможен, плохой критерий.

• Полнота покрытия строк кода – негарантирует правильности, плохойкритерий.

• Ошибка – вычисление системы, несоответствующее спецификации.

• Полнота в терминах возможныхвычислений – хороший критерий.– Редко достижим на практике?

33

Кое-что о тестировании• Как правило, разработка критически важных системрегулируется каким-либо стандартом. Примеромслужит RTCA/DO-178B (авионика).

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

• Пример «достаточно хорошего» критерия тестовогопокрытия для критических систем – MC/DC(http://techreports.larc.nasa.gov/ltrs/PDF/2001/tm/NASA-2001-tm210876.pdf).

• В стандарт RTCA/DO-178C (2011г) включены model-driven development и верификация.

34

Дополнительные трудности:

Реактивные программы

• Традиционные программы:– Завершаются,– Описание «вход/выход»,– Число состояний зависит от входныхданных и переменных;

• Реактивные программы:– Работают в бесконечном цикле,– Взаимодействуют с окружением,– Описание «стимул/реакция»,– (Не обязательно параллельные),– Дополнительный источник сложности.

35


Параллельные программы

• Большое количество возможных вычислений,• Неочевидные ошибки,• Пример – системы с разделением ресурсов.• Исключительная ситуация:

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

36

Системы с разделениемресурсов

Примеры:• транспортные системы,• телефонные сети,• операционные системы,• …

37


Параллельные системы• Новый источник ошибок – совместнаяработа проверенных компонентов.

• Невоспроизводимость тестов.• Ограниченные возможности понаблюдению.

38



39

Доказательство теорем

• Система и свойства – формулы• Набор аксиом и правил вывода• Строится доказательство свойства-теоремы

• Качественный анализ системы

40


• Пример классического подхода, применяющегося до сих пор, логикаХоара.

• Подробно разбирался в курсематематической логики.

41

Логика Хоара: напоминание• Спецификации программы Π задаются в видетриплетов Хоара: {P}Π{Q}.

• Пред- и постусловие P и Q задаются припомощи формул логики первого порядка.

• Программа Π строится при помощиоператоров:– присваивания: x := e;– ветвления: if b then S1 else S2;– цикла: while b do S;– последовательной композиции: S1; S2

42

Логика Хоара: правила вывода

43


• Система:

• Свойство:• Правила вывода:

AbBBacA

•=••=

?ca •

31

3221

3211

322211 ,ss

ssssSaaS

SaSSaS•

•∨•••=

•=∨•=

44

Доказательство теорем• Достоинства:

– работа со сложными структурами данных ибесконечными пространствами состояний,

– даёт более глубокое понимание системы.

• Недостатки:– медленная скорость работы;– требует существенного участия человека

(построение инвариантов циклов);– требует очень высокой квалификации.

45


• Методы и средства: ESC/Java, Spec#• Примеры систем доказательства:

– Isabelle/HOL, Coq, PVS, Vampire, SPASS, ACL2, Simplify, Microsoft Z

• Что почитать:– ATP было в курсе «Математическая логика» В.А.Захарова– Xavier Leroy, Mechanized semantics with applications to

program proof and compiler verification, INRIA, France, 2009 (http://pauillac.inria.fr/~xleroy/courses/Marktoberdorf-2009/notes.pdf)

– Mike Barnett, Rob DeLine, Manuel Fähndrich, K. Rustan M. Leino, and Wolfram Schulte. JOT 3(6), 2004.

– О PVS расскажут на 5-м курсе

46



47

Статический анализ• Более грубый и прагматичный подход,• Анализ исходного текста программыбез её выполнения,

• В общем случае задача неразрешима(сводится к анализу достижимости операторапрограммы),

• Поиск компромисса междупотребностями и возможностями(точностью и скоростью).

48

Статический анализ• Абстрактная интерпретация: построениеабстрактной семантики языка программированияи интерпретация текста программы всоответствии с этой семантикой.

• В случае тестирования: проверяем, чтоконкретные вычисления программы не приводятеё в ошибочные состояния.

время

49

Статический анализ• Абстрактная интерпретация: построениеабстрактной семантики языка программирования иинтерпретация текста программы в соответствии сэтой семантикой,

• Статический анализ: аппроксимируем «сверху»множество вычислений программы,

• Возможны ложные сообщения о нарушении свойств!время

50

Статический анализ: пример

Проверка инициализированности переменной:int min(int* arr, int n) {int m;if (n > 0) {m = arr[0];

}int i = 0;while (i < n) {if (m > arr[i]) {m = arr[i];

}i++;

}return m;

}

dom(m) = Int + { ω }

NI = { ω }

I = Int

v: Expr -> {NI, I}

51

Статический анализ: пример

Проверка инициализированности переменной:int min(int* arr, int n) {int m; <v = { NI }>if (n > 0) <v = { NI }> {m = arr[0]; <v = { I }>

} <v = { NI, I }> (!)int i = 0; <v = { NI, I }>while (i < n) <v = { NI, I }> {if (m > arr[i]) <v = { NI, I }> {m = arr[i]; <v = { I }>

}i++; <v = { NI, I }>

}return m; <v = { NI, I }>

}

dom(m) = Int + { ω }

NI = { ω }

I = Int

v: Expr -> {NI, I}

52

Статический анализ

• Достоинства– Высокая скорость работы,– Если ответ дан, ему можно верить.

• Недостатки– Узкая область применения (оптимизацияв компиляторах, анализ похожести кода, анализ безопасности итп.),

– Ручная настройка при изменениипроверяемых свойств

53

Статический анализ• Примеры средств:

– ASTREE, FindBugs, CodeSonar, K7, Prevent. • Что почитать:

– Reps, T., Program analysis via graph reachability. Information and Software Technology 40, 11-12 (November/December 1998), pp. 701-726.

– P. Cousot & R. CousotA gentle introduction to formal verification of computer systems by abstract interpretation, Logics and Languages for Reliability and Security, 2010, NATO Science Series III: Computer and Systems Sciences, IOS Press, 29 pages.

54



55

Верификация программ намоделях (model checking)

• Проверка свойства на конечноймодели программы,

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

• Исчерпывающий поиск попространству состояний.

56

Верификация программ намоделях: пример

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

?

int count_lines(const char* filename) {int c, count = 0;FILE* f = fopen(filename, "r");if (f != NULL) {

c = fgetc(f);while (c != EOF) {

if (c == '\n') {++count;

}c = fgetc(f);

}if (ferror(f)) {

return -1;}fclose(f);return count;

} else {return -1;

}}

57

Верификация программ намоделях: пример

• Модель функции count_lines:

entry opened closed exitfopen fclose return

f = NULL

ferror(f) = 1

58

Процесс верификациипрограмм на моделях

• Моделирование– Построить адекватную и корректную модель,– Избежать «лишних» состояний;

• Спецификация свойств– Темпоральная логика,– Полнота свойств;

• Верификация– Построение контрпримера,– Анализ контрпримера.

59

Верификация программ намоделях

• Достоинства– Хорошо автоматизируем,– Если модель конечна, корректна иадекватна проверяемому свойству, тодаётся точный ответ,

– Выявляет редкие ошибки.• Недостатки

– Гарантированно работает только дляконечных моделей.

60

Динамическая верификация

• Иногда на этапе разработки системыневозможно гарантировать еёправильную работу в ходе эксплуатации:– Динамическое изменение конфигурациисистемы

пример: компьютерная сеть– Неполное описание компонентов системы

пример: мультивендорная система– Работа в сложном окружении

пример: взаимодействие с Интернет

61


• Т.е. невозможно составить достаточнодетальное конечное описание системы.

• Решение: в систему добавляетсякомпонент, выполняющий– мониторинг поведения системы,– анализ наблюдаемого поведения,– реакцию на обнаруженные нарушенияспецификации.

62


• Проверяется правильность не описанияпрограммы, а её наблюдаемогоповедения.

• Примеры:– Система контроля поведения приложений вОС.

– Система обнаружения атак.– Встроенная система контроля.

63




64

Программа курса:практические навыки

1. Оценка числа состояний программы.2. Построение простой программы

явного перебора состояний.3. Построение программы ограниченной

верификации моделей (BMC).4. Построение модели программы на

Promela.5. Спецификация свойств программы

(LTL).6. Верификация при помощи Spin.7. Анализ результатов верификации.

65

Программа курса:теоретические знания

• Математическая модель программы (системапереходов, структура Крипке, графпрограммы, состояние, вычисление).

• Построение модели (абстракция, корректность, адекватность).

• Спецификация свойств (достижимость, свойства линейного времени).

• Алгоритмы верификации (явный перебор, ограниченная проверка модели).

• Рассуждения о корректности распределённыхсистем и параллельных программ.

66

МатериалыСайт основного курса:

http://savenkov.lvk.cs.msu.su/mc.htmlСтраница курса в Астане, 2011:

http://lvk.cs.msu.su/~konnov/mc/2011/astana/

Материалы по SPIN:• Holzmann. The Spin Model Checker: Primer

and Reference Manual, Addison Wesley, 2003.

• Сайт Spin: http://www.spinroot.com.

67

Дополнительные материалы

68


Том 185, 2009

69


• Для понимания вводного материаларекомендуется прочитать:– Vijay D'Silva‚ Daniel Kroening and Georg

Weissenbacher. A Survey of Automated Techniques for Formal Software Verification. In IEEE Transactions on Computer−Aided Design of Integrated Circuits and Systems (TCAD). Vol. 27. No. 7. Pages 1165−1178. July, 2008.

70

Практикум

• Вариант 1: в лекционной аудитории сноутбуками.

• Вариант 2: в специальном классе.• Успешное прохождение практикумаподразумевает присутствие на занятиях иработу в соответствии с рекомендациями.

• Полностью самостоятельная работа займёт в2-3 раза больше времени.

71

Практикум

72

Оценка за практикум и курс• Курс ориентирован на получение знанийи навыков.

• Навыки не получится развить передэкзаменом и продемонстрировать за 20 минут.

• Оценка за курс:– Оценка за практикум (0..3 балла),– Оценка за экзамен (0..3 балла),– Оценка за «летучки» (-1..1 балл).

• Для АСВК оценка за практикум идёт вдиплом.

73

Оценка за практикум и курс• 5 задач: 50+100+50+80+100 = 380 очков

– [0,230) – 0 баллов (неуд по практикуму, недопуск наосновной экзамен),

– [230,300) – 1 балл,– [300,380) – 2 балла,– 380 – 3 балла (кандидат на «автомат»);

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

• Если решение задачи присылается по почте, оценка за него является окончательной;

• Сдача задания после дедлайна:– в течение двух недель, – только очная (на семинаре), – оценка умножается на 0.6.

74

Спасибо за внимание!

Documents

mc lect 01konnov/mc/2011/astana/mc_lect_01.pdf10 Ценаошибки: Patriot • Февраль1991 года, Patriot промахнулсямиморакетыScud, • Ущерб–28