Ubiquitous computing (вездесущие вычисления) ИТ проникли во все сферы жизни современного общества. Раньше компьютер был компьютером, а телефон – телефоном, и любой мог отличить одно от другого. Cейчас и компьютер – не только компьютер, и телефон – не только телефон … (A.Tanenbaum) Эра параллельного программирования Последовательные программы имеют очень узкое применение. Встроенные системы программного управления обычно параллельны. Многоядерные чипы, встроенные бортовые СУ -> требуются технологии разработки параллельного ПО, чтобы оно выполняло нужные функции “multicore processors are bringing parallelism to mainstream of computing” Параллельные программы полны ошибок Параллельные программы непостижимы для человеческого мозга: даже простейшие программы трудно понять. Как следствие - они очень часто неправильны, содержат ошибки
но тотально некорректна Параллельная программа разделения множеств (Э. Дейкстра) все наименьшие собираются в 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 строк
… Ю.Г.Карпов ТМРА 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 Тестированием найти ошибку невозможно!!
программного управления строятся из параллельных взаимодействующих модулей. Ошибки в них часто являются критическими Некорректные параллельные программы работают правильно “почти всегда”. Они могут годами сохранять ошибки, проявляющиеся после долгой эксплуатации как реакция на возникшую специфическую комбинацию многочисленных факторов, в частности, непредсказуемых скоростей выполнения отдельных процессов в параллельных программах “Существует обширный печальный опыт того, что параллельные программы упорно сопротивляются серьезным усилиям по выявлению в них ошибок” S. Owicki, L. Lamport “Proving liveness properties of concurrent programs”, ACM TOPLAS, N4, 1982
Майкрософта, в ОС Windows остаются тысячи ошибок! Июнь 2013: Microsoft анонсировала программу премирования пользователей, отыскавших уязвимости в предварительной версии операционной системы Windows 8.1. Тем, кто обнаружит ошибку или уязвимость, обещано выплатить до $100 000. Ю.Г.Карпов ТМРА 2013 Кострома 6 Можно ли поставить ОС Windows на спец компьютер, управляющий атомной электростанцией? 70 млн документов об ошибках в Windows
каждый день Апрель, 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" прервалась из-за ошибочной команды, посланной с Земли. АМС потеряна, где-то летает сама по себе
автомобильной индустрии 2010. Toyota отозвала с рынков >8 млн проданных автомобилей из-за неисправности педали газа и дефекта ПО тормозной системы. Это обойдется ей в $2 млрд. Глюк автомобилей Toyota стал причиной не менее 5 смертей. Акио Тойда, президент компании Тойота, 24.02.2010 выступил в Конгрессе США и принес извинения за проблемы, связанные с качеством автомобилей Эксперты: проблемы возникли из-за перехода автомобильной индустрии на программные системы в критически важных функциональных узлах “Основная проблема именно в компьютерной системе управления, в которой не было предусмотрено экстренное торможение: педаль тормоза просто не срабатывала, когда сенсор акселератора командовал автомобилю разгоняться В 2009 г. В США производителями отозвано 19 млн автомобилей из-за ошибок в программах и электронике
США (август 2003 г.): из-за ошибки в многозадачной программе мониторинга возникло переполнение буферной памяти. Система попала в бесконечный цикл. Операторы остались без актуальной информации о состоянии энергосистемы. Если бы оперативная информация о состоянии энергосистемы была доступна, оператор смог бы предотвратить каскадные сбои и минимизировать убытки. Сброс 4% нагрузки мог спасти ситуацию. Ущерб ~ 10$ млрд www.icfi.com/Markets/Energy/doc_files/blackout-economic-costs.pdf Ю.Г.Карпов ТМРА 2013 Кострома 9
в пустыне”: ошибка в системе управления Patriot помешал перехватить иракскую ракету Scud, выпущенную по военной базе Дахран в Саудовской Аравии. Ракета достигла цели, в результате чего погибли 28 американских солдат и еще около 100 человек получили ранения (www.fas.org/spp/starwars/gao/im92026.htm). (Patriot - мобильная система противоракетной обороны США , оснащаемая ракетами класса «земля-воздух» и предназначенная для защиты от самолетов, крылатых ракет и баллистических ракет ближнего радиуса действия) Ю.Г.Карпов ТМРА 2013 Кострома 10
связи с Deep Impact состоялся 8 августа 2013, после чего контакт с зондом был потерян. По оценкам инженеров NASA, причиной обрыва связи стали ошибки в ПО, из-за чего зонд потерял ориентацию в пространстве Deep Impact был запущен в январе 2005 года. Его основная миссия заключалась в исследовании кометы Темпеля; она успешно была завершена спустя полгода после запуска Ю.Г.Карпов ТМРА 2013 Кострома 11 21.09.2013. Специалисты NASA объявили о прекращении попыток восстановить связь с исследовательским зондом Deep Impact
в том, что собеседник является тем, за кого он себя выдает? Только если он продемонстрирует знание СЕКРЕТА, известного только ему 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 как общий секрет и уверен, что установил связь с А
потери человеческих жизней? Программирование является единственной областью инженерной деятельности, где разработчик не отвечает за качество своей работы Обычно ПО имеет 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 Ужасы из-за ошибок ПО - в Интернете:
Москвы” 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 Параллельная композиция процессов:
метод повышения качества программ Процедура проверки Спецификация системы (формальная модель) Спецификация требований (на формальном языке) Верификация - формальное доказательство того, что программная система удовлетворяет формально определенным требованиям Формально доказать можно только нечто формально определенн ое
произведение К=mn с помощью сложений НАЧАЛО КОНЕЦ i = m да нет K := 0; i := 0; K:= K + n; i := i + 1; Т1: [ m,nN m>0 K=0 i=0 ] [ K = i n ] Т3: [ ( K-n = (i -1)n ) (i -1 m) ] [ K = i n ] Т2: [ ( K=in) (i= m) ] [ K= mn ] Доказательство корректности программы требует доказательства трех теорем { A :: K = in } Инвариант цикла: при каждом попадании в эту точку К=in {R:: K=mn} В конце программы должны получить желаемый результат {I:: m,nN; m0} В начале программы - ограничения на исходные данные Ю.Г.Карпов ТМРА 2013 Кострома
ОС Сообщение СМИ 01.10.2009 Research Centre of Excellence компании NISTA (Australia) объявил о завершении работы по формальному доказательству корректности ядра ОС с помощью интерактивной системы доказательства теорем Isabelle Руководитель работы Dr. Klein: “Этот экстраординарный результат открывает путь к разработке нового поколения ПО с беспрецедентным уровнем надежности. Это одно из самых длинных из когда-либо выполненных формальных доказательств с помощью формальных средств theorem-proving”
Embedded L4 microkernel дедуктивным методом Построение доказательства ядра ОС L4 ~ 60 человеко-лет работы Проверка 10 строк кода – 1 чел-месяц работы верификатора Cложность доказательства в 30 раз выше сложности кода; одна строка кода - ~ 1 страница доказательства Аллен Эмерсон о дедуктивной верификации: “мы писали 15-страничный отчет о том, что программа на полстраницы корректна” Трудозатраты: 4 года работы группы из 12 исследователей, PhD студентов и нескольких других работников Объем: доказанная ОС содержит 7,500 строк C code. Сложность доказательства: 10,000 промежуточных теорем, 200,000 строк доказательства
применены для доказательства корректности только “toy examples” нотация сложна и неясна, ошибки встречались и в доказательствах методы не масштабируемы (not scalable), требовали огромных усилий программные инструменты неадекватны и трудны в использовании; верификация проводилась интерактивно требовалась высокая квалификация для выполнения и спецификации, и анализа Ю.Г.Карпов ТМРА 2013 Кострома
верификации ~ 20 лет назад – качественный прорыв в области верификации дискретных систем Разработан метод model checking, основанный на изящных формальных моделях
в будущем 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
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)
Amir Pnueli (1977) Логика LTL – темпоральная логика линейного времени – утверждения о свойствах бесконечных вычислений Формула LTL это : атомарное утверждение (атомарный предикат) p, q, ..., или Формулы, связанные логическими операторами , или Формулы, связанные темпоральными операторами U, X • Модальностей прошлого в LTL нет Выводимые темпоральные операторы : F = true U Грамматика: ::= p | | | X | U LTL к логике высказываний добавлены только два модальных оператора: Until и NextTime Базис LTL = {¬, , U, X } s0 p, q q, r r s1 s2 ... r sn ...
систем 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 – не выполняется на вычислении
b,а c d а c d b,а b,а Cтруктура Крипке – система переходов с помеченным и состояниям и и непомеченн ыми переходами Развертка структуры Крипке определяе т бесконечн ые цепочки состояний - возможные ВЫЧИСЛЕНИ Я Каждое состояние может иметь не одну, а множество цепочек – продолжений, и является корнем своего дерева историй (вычислений) Но как понимать формулы LTL: Gp, pUq, … в состоянии? Для какого пути? Ввести “кванторы пути” Е “существует такой путь из данного состояния, на котором истинна” А “для всех путей из данного состояния формула пути истинна” Очевидно, А Е Как конечным образом задать бесконечные вычисления? cUb?
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 Темпоральные логики: прорыв в формализации и понимании требований к поведению параллельных систем
CTL Любой грешник всегда имеет шанс вернуться на путь истинной веры Всегда, куда бы мы ни попали в нашей жизни (AG), существует такой путь, что на нем в конце концов обязательно попадем (ЕF) в состояние, с которого идет путь (EG) ‘истинной веры’ AG EF EG ‘истинная_вера ’
памятью Переходы выполняются в каждом такте Задержка: логическая схема - 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 1 0 p=1, r=1, q=1 1 0 1 0 0 1 q=(pr) q p r p, r, q Структура Крипке:
с конечным числом состояний Состояние программы – вектор значений ее переменных И метки (рс) Переходы – изменение операторами значений переменных программы Пусть атомарные утверждения, ИНТЕРЕСУЮЩИЕ НАС: а=х>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 х:=-2; у:=1; b a b b a b Если все переменные могут принимать конечное число значений, то граф конечен
ема Общая схема верификации Model checking Спецификация системы (формальная модель) Процедура проверки Спецификация требований (формальный язык) Формула темпоральной логики Структура Крипке Формально доказать можно только нечто формально определенн ое Да, система удовлетворяет спецификации Нет, система НЕ удовлетворяет спецификации КОНТРПРИМЕР Model checker
является ли данная структура Крипке моделью темпоральной формулы Логика высказываний 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 – проверка того, является ли К моделью Ф
ring protocol IЕЕЕ Logical Link Control protocol, LLC 802.2 фрагменты больших протоколов XTP и TCP/IP отказоустойчивые системы, протоколы доступа к шинам, протоколы контроля ошибок в аппаратуре, ... ... криптографические протоколы протокол Ethernet Сollision Avoidance DeepSpace1 (NASA) - после тщательного тестирования и сдачи системы были найдены критические ошибки, которые, по мнению экспертов, обязательно привели бы к аварии в полете С помощью Model checking были найдены ошибки во многих критических программных системах
процессов P1 || P2 || P3 || P4 || P5 Проверка свойства : “За Путина не могут проголосовать 300%” A G (p п < 300) Верификация ПО голосования с помощью верификатора SPIN
гидрофизического судна “Вайгач” Функции системы управления: контроль состояния судовых электростанций и обработка критических ситуаций автоматическая балансировка нагрузки между двумя судовыми электростанциями обработка команд вахтенного капитана 50 дизель генератор ГА пульт управления Управление двигателями Engine Система управления В оттестированной и сданной заказчику системе найдено несколько критических ошибок, которые проявились при ходовых испытаниях корабля на Белом море Проект научной группы Петербургского Политеха
он говорит с 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 Bob Intruder Ю.Г.Карпов ТМРА 2013 Кострома
5 6 1. А начинает взаимодействовать с I как с партнером, посылая ему <A, N A > PK(I) 2. I получает N А – секрет А. Он маскируется под А, используя секрет, полученный от А: посылает сообщение <A, N A > PK(B) к В. В его дешифрирует и считает, что это сообщение пришло от А 3. В считая, что говорит с А, посылает в ответ сообщение <N A , N B > PK(A) , которое зашифровано открытым ключом А. I получает это сообщение. Поскольку оно закодировано открытым ключом А, I не может декодировать это сообщение сам, но может переслать его А как бы от себя 4. Получив это сообщение, А видит свой N A , считает, что обмен закончился успешно, и посылает секрет В - <NB >PK(I) - своему партнеру, агенту I, полагая, что им установлена связь с I 5. Это сообщение закодировано ключом для I и содержит N B . Поэтому агент I может его декодировать, получив секрет В - nonceB 6. I посылает этот N В агенту В, который тоже удовлетворен, считая, что установил связь с А, но в действительности – связь с I 1: 2: 3: 4: 5: 6: ТМРА 2013 Кострома
многоядерных процессорах Транзакционная память – один из способов, позволяющих избежать проблем синхронизации процессов над общей памятью Многоядерные процессоры вывели параллельное программирование и связанные с ним проблемы ошибок в параллельных программах “в народные массы” Как решать проблемы ошибок синхронизации параллельных программ в многоядерных процессорах? ядро 2 ядро 1 ядро n память ... ядро 2 ядро 1 ядро n память ... протокол транзакционной памяти
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).
протоколе Imbs D.; Raynal M. Software Transactional Memories: an Approach for Multicore Programming. LNCS, 5698, 2009 Эта работа была дана студенту 4 курса Петербургского Политеха Алексею Беляеву для проверки протокола в рамках его НИРС Студент – построил модель протокола транзакционной памяти, - описал требования к протоколу формулой темпоральной логики, - использовал систему верификации SPIN - нашел в протоколе ошибку
могут допустить ошибки в разрабатываемых ими параллельных программах Нельзя полагаться на доказательства корректности параллельных программ на основе рассуждений, как это было сделано в работе проф. М.Райнала Даже студент, используя технику Model checking, может найти ошибки в достаточно сложной параллельной программе, разработанной профессионалами
Никаких доказательств и логического вывода Эффективность Контрпримеры, выдаваемые верификатором при нахождении ошибки, можно использовать для диагностики ошибок TL легко выражают многие проблемы параллельных процессов В ведущих фирмах методы верификации аппаратуры и программ на основе Model checking разработаны до индустриальной технологии
2008 г премия Тьюринга была вручена трем создателям техники MODEL CHECKING, внесшим наиболее существенный вклад Edmund M. Clarke (CMU), E. Allen Emerson (U Texas, Austin), Joseph Sifakis (Verimag, France) “за их роль в превращении метода Model checking в высокоэффективную технологию верификации, широко используемую в индустрии разработки ПО и аппаратных средств” ACM President Stuart Feldman : “Это великий пример того, как технология, изменившая промышленность, родилась из чисто теоретических исследований”
теорию, алгоритмы, элементы технологии, инструментарий с помощью которых он может проверять корректность нетривиальных параллельных и распределенных программ Ю.Г.Карпов ТМРА 2013 Кострома
на которых основан метод Model Checking: темпоральные логики линейное и ветвящееся время структуры Крипке недетерминированные автоматы Бюхи бесконечные множества бесконечных цепочек (-языки) синхронная и асинхронная композиция автоматов неподвижные точки операторов на решетках предикатов ... Все эти абстракции, которые и представить себе нельзя, привели к разработке мощной техники верификации, которая стала частью промышленной технологии разработки критического ПО и аппаратуры
должны стать частью образования каждого исследователя в области информатики и каждого разработчика ПО так же, как другие ветви прикладной математики являются необходимой частью образования в других инженерных областях. NASA Report 4673, “Formal Methods and Their Role in Digital System Validation for Airborne Systems” В области разработки ПО необходимые разделы прикладной математики – это формальные методы, на которых основывается верификация: формальная логика, теория автоматов, теория алгоритмов
программные системы из десятков миллионов строк кода могут быть полностью верифицированы прямо сейчас, непосредственным механическим применением существующих техник и технологий
на основе свойств отдельных компонент системы Одно из направлений: Rely - Guarantee Композициональность: метод определения свойств сложных структур через свойства составляющих их подструктур и правил их композиции
checking vs. Correctness by construction Эдсгер Дейкстра: вместо того, чтобы программу СНАЧАЛА разрабатывать, а ПОТОМ пытаться доказать ее правильность, программу нужно сразу строить корректной Программа должна выводиться строго логически из точно сформулированной спецификации, а не только исходя из опыта и общих соображений В книге “Дисциплина программирования” Э.Дейкстры приведено множество изящных примеров такого подхода к разработке “Этот труд, несомненно, будет признан одним из выдающихся достижений в разработке новой интеллектуальной дисциплины – программирования” Антони Чарльз Хоар
национальный флаг” – построить программу сортировки массива из трех типов объектов – “красных”, “белых” и “синих”, которые должны в результате стоять именно в этом порядке. Программа должна справляться со всеми случаями вырождения: отсутствием одного или нескольких цветов Как подойти к разработке программы? Выбрать ИНВАРИАНТ! неотсортированные исходный массив результирующий массив промежуточный массив Крайними состояниями инварианта являются исходный и результирующий массивы
i: (1i<к) ] M[i] - красный & [ i: (б<iс) ] M[i] - белый & [ i: (с<iN) ] M[i] - синий & [ i: (кiб) ] M[i] - неотсортированный & (к1) & (бс) & (сN) Очевидно, что: A & (к>б) массив M отсортирован (массив неотсортированных пуст) Разработка программы сводится к построению цикла, который уменьшает зону неотсортированных элементов, но при этом сохраняет инвариант begin I = { [i: (1iN) ] M[i] - неотсортированные} к,б,с:=1,N,N; /* инвариант цикла A */ do <пока зона не отсортированных непуста> <уменьшить зону не отсортированных, не изменяя A> od { R массив M отсортирован } end Программа частично корректна, если 1) из I, преобразованного оператором k,б,с := 1,N,N следует А, 2) A – инвариант цикла, 3) из А следует R по завершении цикла Программа тотально корректна, если при этом зона неотсортированных уменьшается на каждом шаге цикла б к 1 с N
begin { [i: (1iN)] 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&GR, т.е. A&(к<б) R 3 -5. sp( Si, A&G&Gi) A или Awp(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: (1i<к) ] M[i] - красный & [ i: (б<iс) ] M[i] - белый & [ i: (с<iN) ] M[i] - синий & [ i: (кiб) ] M[i] - неотсортированный & (к1) & (бс) & (сN)
(Model Driven Development. MDD) Модель Верификация Программа Спецификация требований Имитационное моделирование Техническое задание Высокоуровневая документация Разработка тестов Бортовое ПО для Airbus А-340: более 70% кода сгенерировано Абсурдно ставить проблему доказательства программы после того, как программа написана (Н.Н.Непейвода) Разумно ли СНАЧАЛА построить самолет, а ПОТОМ проводить анализ, чтобы увидеть, полетит ли он?
Hoare, Jayadev Misra, Gary T. Leavens, and Natarajan Shankar (2007) Предлагают международный амбициозный исследовательский долговременный проект по разработке основ конструирования error-free программных систем Попытка в течение следующих 15 лет: Разработать обстоятельную Теорию программирования, покрывающую формализмы и методики, необходимые для построения практических надежных программ (error-free software) Разработать программные инструменты для анализа ПО индустриального масштаба Построить библиотеки надежных программных компонент, которые могут быть использованы в реальных проектах
Frederic Brooks (1986 г., “No Silver Bullet”) - об иллюзиях и надеждах в разработке ПО. Ни одна из предлагаемых в то время идей не является “серебряной пулей”, которая спасет нас от ужасов, связанных с разработкой больших комплексов ПО. Весьма пессимистический взгляд David Harel, IEEE Computer, 1992 David Harel (1992): хотя единственного средства (“серебряной пули”) нет, но интегральное использование новых идей может внести существенный вклад в разработку сложных программных систем
верификации ПО на ранних стадиях разработки Среди наиболее обещающих направлений: разработка более тонких формализмов спецификации требований объединение статического анализа кода и верификации композициональная разработка и верификация Model Driven Development: проверяемая модель – в центре разработки, генерация кода из отлаженной и верифицированной модели синтез СУ непосредственно из спецификации (синтез супервизоров) Д. Харел (1992): “Текущая ситуация и перспективы значительных улучшений показывают, что мы находимся на пороге новой, удивительной эры” Сегодняшние успехи формальной верификации показывают: “БУДУЩЕЕ НАЧИНАЕТСЯ СЕГОДНЯ” Верификация достигла уровня зрелости, но требует интеллектуальных усилий в ее применении и дальнейшем развитии
crdoo
denniskardys
jcasabona
carmenintech
tenderlove
malarkey
eileencodes
kneath
sonatard
garrettdimon
keavy
smashingmag
mojombo
