Опубликован: 24.09.2008 | Уровень: специалист | Доступ: платный | ВУЗ: Московский физико-технический институт

Лекция 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 - предопределенные и конструируемые типы данных (массив, последовательность и т.д.). Формулы описываются с помощью предикатов, булевых операций, кванторов, переменных и модальностей. Семантика их определения зависит от последовательных действий (поведений), спецификацией процесса и от момента времени их выполнения.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Каждое свойство - это пара (p, А(p)), проверяемая на множестве E, где p - свойство компонента С в Е, А(p) - множество временных формул из свойств, определенных на множествах I и V. Свойства компонента С включается в абстракцию P только тогда, когда оно проверено в среде этого компонента.

Композиция компонентов - это совокупность более простых компонентов: (E_{0}, I_{0}, V_{0}, P_{0}), \dots, (E_{n - i} , I_{n - i} , V_{n - i}, P_{n - i}), определенных на модели компонента С следующим образом. E создается из множества представлений E_{0}, E _{1}, \dots, E_{n - 1}, связанных между собой интерфейсами из набора интерфейсов I = \{I_{0}, \dots, I_{n - 1}\}, операций связи Ih (0 < h < n) для взаимодействия с другими компонентами;

P - множество временных свойств, определенных на I и V, и проверенных на компонентах E с использованием отдельных свойств Р_{0} , \dots, P_{n - 1} ;

V - подмножество \bigcup_{i=0}^{n-1}{V_i}, где V_{i} - ссылка на свойство i -компонента из С, заданное в Р.

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

Р = (Х, \sum, Q, \nabla),

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

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

Каждое из состояний переходов - кортеж (r, t, m), где r и t - состояния в Ф и m - тип сообщения во множестве сообщений М.

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

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

Александр Медов
Александр Медов

Здравствуйте,при покупке печатной формы сертификата,будут ли выданы обе печатные сторны?

Александр Медов
Александр Медов

Здравствуйте, прошел курс МБА Управление ИТ-проектами и направил документы на получение диплома почтой. Подскажите, сроки получения оного в бумажной форме?

:

Татьяна Невокшонова
Татьяна Невокшонова
Россия
Кристина Языкова
Кристина Языкова
Россия, Москва, 1171, 2012