Лекция 7: Формальные спецификации, доказательство и верификация программ

6.3. Верификация и валидация программ

Верификация и валидация - это методы анализа, проверки спецификаций и правильности выполнения программ в соответствии с заданными требованиями и формальным описанием программы [6.19, 6.20].

Верификация помогает сделать заключение о корректности созданной программной системы после завершения ее разработки. Валидация позволяет установить выполнимость заданных требований путем их просмотра, инспекции и оценки результатов проектирования на этапах ЖЦ для подтверждения того, что проводится корректная реализация требований, соблюдение заданных условий и ограничений к системе. Верификация и валидация обеспечивают проверку полноты, непротиворечивости и однозначности спецификации и правильности выполнения функций системы в соответствии с требованиями.

Верификации и валидации подвергаются:

• тесты, тестовые процедуры и входные наборы данных.
• компоненты системы и их интерфейсы (программные, технические и информационные) и взаимодействия объектов (протоколы, сообщения) в распределенных средах;
• описание доступа к БД, средства защиты от несанкционированного доступа к данным разных пользователей;
• документация на систему.

Иными словами, основные систематические методы обеспечения правильности программ - верификация компонентов и валидация требований путем инспектирования для установления соответствия программы заданным спецификациями и требованиям.

6.3.1. Подходы к верификации моделей

Объектная модель и модель распределенного приложения отражают специфику предметной области и принципы взаимодействияобъектов со средой функционирования. Их верификации посвящен ряд работ, в том числе [6.22]. Эта область верификации требует дальнейшего развития и в рамках международного проекта на ближайшие десятилетия будет одним из главных ее направлений.

Верификация объектных моделей основывается на спецификации следующих элементов:

1. Базовых (простых) объектов ОМ, атрибутами которых являются данные и операции объектфункции над этими данными.
2. Проверенных объектов с помощью операций (функции), используемых в качестве теорем, а все операции, которые применяются над их подобъектами, не выводят их из множества состояний объектов.
3. Верифицированных интерфейсов объектов путем доказа тельства правильности передачи типов и количества данных в пара метрах сообщений, заданных в языке IDL. Интерфейс состоит из операций обращения к объекту, который посылает данные другому объекту через сообщение.

Для доказательства правильности спецификации сообщения создается набор утверждений, доказывающий, что для любой пары элементов сообщения, например, и , переход от к проходит за один шаг. Действие, выполняемое в промежутке между и , приводит к . При этом часть утвердждений проверяет входной параметр и его поступление на вход другого объекта в целях подтверждения его на выходе. Если доказано, что объект, инициированный сообщением, формирует правильный выходной результат - выходной параметр, то сообщение считается правильным.

Доказательство правильности построения ОМ для некоторой ПрО состоит в следующем:

• вводятся дополнительные и/или удаляются лишние атрибуты объекта и его интерфейсов в ОМ, доказывается правильность объекта ОМ после изменений спецификации интерфейсов и взаимодействий с другими объектами;
• доказывается правильность задания типов для атрибутов объекта, т.е. подтверждения того, что выбранный тип реализует операцию, а множество его значений определено на множестве состояний этого объекта;
• доказывается правильность спецификации объектов ОМ и параметров интерфейсов, которые передаются другим объектам.Этим заканчивается заключительное доказательство проверки правильности ОМ.

Верификация модели распределенного приложения - это спецификация процессов SDL (Spesification Description Language), задание модели проверки (model-checking) и индуктивных утверждений. Метод предложен новосибирской школой программирования в [6.12, 6.13]. В нем проверки состоит в редукции системы с бесконечным числом состояний к системе с конечным числом состояний, а также в доказательстве распределенных приложений с помощью индуктивных рассуждений и системы переходов конечного автомата.

Связь между процессами распределенного приложения осуществляется через специальный канал, который передает сообщение с параметрами или без них в качестве сигнала. В него поступает запись после освобождения или чтения очередного сигнала. Процесс задается последовательностью действий, приводящих к изменению переменных, чтению сигнала из канала, записи в канал и очистке канала. Проверка спецификации ограничивается условиями справедливости.

Основные типы данных спецификации в SDL - предопределенные и конструируемые типы данных (массив, последовательность и т.д.). Формулы описываются с помощью предикатов, булевых операций, кванторов, переменных и модальностей. Семантика их определения зависит от последовательных действий (поведений), спецификацией процесса и от момента времени их выполнения.

В предикатах используются локаторы управляющих состояний процессов, контроллеры заполнения каналов (пусто/заполнен канал), а также отношения между переменными и параметрами сигналов. Спецификация процесса состоит из заголовка, контекста, схемы и подспецификации. В заголовке указывается имя и вид процесса, формулы или предикаты.

Контекст - это описание типов, переменных и каналов. Переменная принадлежит процессу, если в ее описании указано место и имя процесса (через точку), которому эта переменная принадлежит. При ее использовании указывается имя переменной с расширением. Если указывается параметр, то в расширенное имя входит имя канала, сигнал и имена параметров, разделенных точками.

В логических условиях используются кванторы всеобщности и существования.

Схема спецификации процесса - это описание условий выполнения и диаграмм процессов. Она инициируется посылкой сообщения во входной канал, который передает сообщение внешней среде для выполнения.

Диаграмма процесса состоит из описаний переходов, состояний, набора операций процесса и перехода на следующее состояние. Набор операций - это действия типа: чтение сообщения из входного канала, запись его в выходной канал, очистка входного и выходного каналов, изменение значений переменных программы Рпроцесса.

Каждая операция определяет поведение процесса и создает некоторое событие. Логическая формула задает модальность поведения спецификации и моменты времени. Процесс, представленный формальной спецификацией, выполняется недетерминировано. Обмен с внешней средой производится через входные и выходные параметры сообщений.

Событие. В каждый момент времени выполнения процесс имеет некоторое состояние, которое может быть отражено в виде снимка, характеризующего это событие, и включает в себя значения переменных, которым соответствуют параметры и характеристики состояний процесса. К событиям процесса относятся:

• отправка сообщения в канал;
• получение сообщения из канала;
• чистка входных и выходных каналов;
• выполнение программ;
• анализ непредвиденного события (взлом канала и др.).

Семантика выполнения процесса определяется в терминах событий и правил с помощью следующего типа утверждения:

любой процесс вызывает событие при чтении или записи сообщения из/в канал, а также при выполнении процесса в узле распределенной системы.

6.3.2. Метод верификации композиции правильных компонентов

Метод верификации композиции компонентов базируется на спецификации функций и временных (temporal) свойствах готовых проверенных компонентов (типа reuse) [6.23]. Свойства составного компонента из компонентов повторного использования - reuse проверяются с помощью абстракции и общей компонентной модели (ОКМ). Эта модель состоит из совокупности проверенных компонентов, спецификаций их временных свойств и условий функционирования, которые проверяются с помощью аппарата асинхроннойпередачи сообщений (АПС). Его основу составляет модель проверки (Model Сhecking) [6.16, 6.23] временных свойств и обнаружения ошибок взаимодействия, возникающих при композиции компонентов.

Модель проверки включает в себя идентификацию правильных компонентов; композицию повторных компонентов по их спецификациям; формирование общей спецификации компонентной системы, составленной из правильных компонентов и др. При этом выполняются следующие условия:

• спецификация компонентов задается в языке диалекта UML [6.23] и содержит описание временных свойств;
• reuse-компоненты задают функции, спецификации интерфейса и временные свойства;
• композиционный аппарат проверяет свойства составных компонентов.

Модель ОКМ - это совокупность специфицированных компонентов и их временных свойств для обеспечения верификации. Свойство компонента определяется исходя из условий среды. Когда компонент многократно используется в составе составного компонента эти свойства должны учитывать возможности среды и связей с другими компонентами композиции. ОКМ проверяется на модели вычислений АПС.

Представители ОКМ-модели могут быть примитивными и составными. Описание свойств примитивных элементов модели проверяется непосредственно с помощью модели проверки, а свойство составного компонента - на абстракции компонента, составленной из примитива и проверенных свойств в интегрированной среде.

Если абстракция слишком громоздкая для проверки, то применяется композиционный подход для проверки сгруппированных свойств компонентов и включения проверенных свойств в абстракцию.

Данный подход может использоваться в распределенных приложениях, функционирующих на платформах CORBA, DCOM и EJB.

Формально каждый компонент в ОКМ-модели задается в виде , где - исходный код компонента; - интерфейс этого компонента с другими компонентами через передачу сообщений или вызовов процедур; - множество переменных, определенных в и связанных со свойствами множества временных свойств , отражающими особенности среды компонента.

Каждое свойство - это пара , проверяемая на множестве , где - свойство компонента в , - множество временных формул из свойств, определенных на множествах и . Свойства компонента включается в абстракцию только тогда, когда оно проверено в среде этого компонента.

Композиция компонентов - это совокупность более простых компонентов: , определенных на модели компонента следующим образом. создается из множества представлений , связанных между собой интерфейсами из набора интерфейсов , операций связи для взаимодействия с другими компонентами;

- множество временных свойств, определенных на и , и проверенных на компонентах с использованием отдельных свойств ;

- подмножество где - ссылка на свойство -компонента из , заданное в .

Модель вычислений АПС - это вычислительная модель системы, заданная на конечном множестве взаимодействующих процессов представленных кортежами:

где - множество переменных с типом; - расширенная модель состояния; - очередь сообщений в порядке их поступления; - множество начальных значений для каждой переменной из , и пустое для .

При выполнении в вычислительной среде создается модель состояния в виде кортежа , где - множество состояний, каждое из которых связано с ассоциативным действием; - множество типов сообщений; - набор переходов, определенных на множествах и

Каждое из состояний переходов - кортеж , где и - состояния в и - тип сообщения во множестве сообщений .

Семантически каждое действие определяется сегментом программы, составленным из операторов: пустой оператор, присваивания, передачи сообщений, условный и составной операторы и др.

Асинхронная передача сообщений АПС вызывает чередование переходов состояний и действий процессов. Для двух процессов и передача сообщения от к включает в себя: тип сообщения из множества для и соответствующие параметры. Когда оператор действия выполняется, сообщение с параметрами ставится вочередь к процессу . Более подробные сведения о верификации компонентов приведены в [6.23].