Презентации / Lecture05p

Пример неаккуратного переноса решения

•Космический корабль США для исследования Венеры Mariner 1, стоимость $18.5 M

•Запуск 27.08.1962

•На 93 с радиомаяк системы наведения не смог предоставить данные о режиме полета из-за слабого и зашумленного сигнала, автоматически была включена бортовая система управления полетом

•В какой-то момент она стала хаотично включать-выключать маневровые двигатели, из-за чего произошла потеря управления

•На 294.5 с полета с земли была подана команда на уничтожение

•Причины

•В одном из уравнений, учитывающих текущую скорость, было опущено усреднение по нескольким соседним измерениям (оно было нужно из-за низкой точности измерений)

•Колебания текущих измеряемых значений скорости стали рассматриваться как рывки, которые система попыталась компенсировать работой маневровых двигателей

•(часто упоминается, но недостоверно, есть свидетельства, что такая ошибка была в другом проекте, Project Mercury, и была вовремя исправлена)

Якобы в используемой FORTRAN-программе в одном месте запятая была заменена на точку

вместо цикла DO 5 K = 1,3 было DO 5 K = 1.3 что интерпретировалось как присваивание DO5K=1.3

Как защититься от ошибок

•Не делать ошибок – невозможно из-за высокой сложности ПО

•Три вида методов

•Предотвращение ошибок

•Обнаружение ошибок (контроль качества)

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

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

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

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

•Без третьей ошибки так и останутся

Методы предотвращения ошибок

•Стандартизация и полное, точное документирование интерфейсов и функций библиотек, платформ и протоколов

•Выглядит довольно скучно, весьма трудоемко, но приносит огромную пользу, применимо при разработке базового, системного и промежуточного ПО

•Использование стандартов кодирования, облегчающих понимание кода

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

•Регулярное применение в проектах методов контроля качества (экспертизы, статического анализа, тестирования) как можно раньше, как только появляются подходящие для их использования артефакты

•Скучновато, трудоемко, очень полезно, применимо во всех проектах

•Разработка и использование конструкций языков программирования, позволяющих эффективно проверять больше разных свойств корректности программ

•Выглядит эффектно, но получается довольно редко

Предотвращающие ошибки конструкции

•Замена goto с переходом на произвольное место на break и continue

•Резко повышает удобство анализа и понимание различных сценариев работы программы

•Устранение NullPointerException

- Наиболее часто встречающаяся ошибка при разработке на языках, где возможна

•Вводятся декларации not-nullable переменных

Type x = null;

Type! y = new Type();

•Компилятор сигнализирует об ошибке при вызове метода или обращении к полю у переменной, которая не not-nullable, вне блока, перед которым не было проверки на != null

•Компилятор сигнализирует об ошибке при попытке присваивания nullable выражения в notnullable переменную

Методы обнаружения ошибок

•Они же – методы контроля качества ПО

•Валидация

•Проверка правильности одного из артефактов разработки с точки зрения конечных целей проекта (удовлетворения потребностей пользователей и др. заинтересованных лиц)

•Невозможно без человека, понимающего эти цели (и одновременно артефакт) достаточно детально и полно

•Необходимо привлечение экспертов, представителей пользователей, заказчиков и пр.

•Верификация

•Проверка соответствия между двумя (редко более) артефактами проекта или артефактом и реальной работой создаваемой системы

•Часто: требования проект, требования код, требования тесты, проект код, проект тесты, требования реальная работа, проект реальная работа

•Возможно автоматизировать (хотя часто участвуют люди, но зависимость результатов от их квалификации в предметной области значительно ниже, чем при валидации)

•Используется гораздо шире и чаще, поскольку менее дорога

Выявление ошибок разных типов

•Неверное понимание задач

•Только валидация

•Просто переспрашивать экспертов обычно недостаточно – для выявления

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

•Некорректные решения для правильно понятых задач

•Верификация от точных формулировок требований

•Необходимо крайне тщательно продумывать различные возможные сценарии работы системы и окружения

•Неаккуратный перенос в код корректных решений

•Любые методы верификации кода

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

•Экспертиза

•Сопоставление артефактов выполняется человеком

•Требует участия очень опытных разработчиков

•Довольно трудоемко, но очень эффективно для поиска любых ошибок, можно использовать раньше

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

•Автоматический поиск определенных шаблонов часто встречающихся ошибок без попыток исполнения кода

•Довольно дешево за счет использования инструментов, но можно искать не все виды ошибок

•Часто человек просматривает сообщения о проблемах, выделяя из них реальные ошибки

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

•При достижении высокой эффективности техника статического анализа часто включается в компиляторы

•Динамический анализ

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

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

•Экспертиза

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

•Динамический анализ

•Поиск ошибок и несоответствий при реальной работе системы или отдельных ее компонентов

•Довольно дешево, можно искать все виды ошибок (при умении и дополнительных инструментах)

•Далеко не все ошибки в коде легко найти, некоторые проявляются крайне редко, в очень хитрых ситуациях

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

•Сопоставляемые артефакты преобразуются в формальные модели, выполняется формальная проверка их соответствия

•Очень трудоемко, нужны высококвалифицированные специалисты, но гарантии итогового качества наиболее высокие

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

•Приведена не строгая классификация, а типология

•Конкретный метод может относиться одновременно к разным типам по разным характеристикам

•Четкой грани между статическим и динамическим анализом нет

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

•Наиболее активно развиваются гибридные техники верификации, совмещающие элементы методов разных видов

•Статический анализ на основе формальных моделей

•Тестирование и мониторинг на основе формальных моделей

•Смешанный статико-динамический анализ

Пример техники экспертизы

Инспекция программ по Фагану (M. Fagan, 1976)

•Проверка соответствия первичного и вторичного артефактов

•Роли участников: ведущий, автор (лучше всех понимает первичный артефакт), интерпретатор (обычно создатель вторичного артефакта), инспектор (обычный участник); обычно в группе 3-6 человек

•Действия

•Планирование

Ведущий убеждается, что артефакты готовы к работе, выбирает участников, определяет даты собраний и общий план

•Первичный обзор – собрание (2-4 ч)

Ведущий представляет задачи и наиболее важные характеристики Автор представляет первичный артефакт – основные идеи и правила, отвечает на вопросы

•Подготовка (2-3 дня)

Каждый самостоятельно изучает оба артефакта, составляет списки вопросов и замечаний

•Совместная инспекция – собрание (3-6 ч)

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

•Доработка

Интерпретатор исправляет выявленные проблемы

•Контроль

Ведущий убеждается, что выявленные проблемы разрешены, при этом переработке должно подвергнуться не слишком много (5-10%), иначе нужно повторить