Основные подходы к обеспечению качества программного обеспечения

Рассмотрим  перечисленные вопросы подробно.

Иерархический метод разработки ПО

    В соответствии с принципом абстракции при проектировании программ разработчики могут идти по меньшей мере двумя путями: от аппаратуры «вверх» ¾ к виртуальной машине, или от виртуальной машины «вниз» ¾ к реальному оборудованию. Это и есть два основных метода проектирования ¾ метод снизу вверх и метод сверху вниз. Остальные описываемые методы по своей сути сводятся к этим двум или являются их сочетанием.

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

    К недостаткам метода проектирования снизу вверх относят:

• необходимость с самого начала принимать решение о выборе способа реализации компонент ПО ¾ с помощью аппаратуры, микропрограмм или программ, что сделать очень трудно;
• возможность проектирования ПО только после разработки аппаратуры;
• расхождение между реальным ПО и определённым в ТЗ.

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

    При использовании метода проектирования сверху вниз (иерархический метод) исходят от виртуальной машины, представляющей ПО, с требуемыми свойствами и последовательно разрабатывают слои виртуальной системы вплоть до аппаратуры. В этом случае процесс проектирования заключается в следующей последовательности.

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

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

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

    Преимущества  использования модульного принципа состоят в следующем:

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

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

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

    Функциональный  блок можно представить как отдельный  вычислительный оператор или как  любую другую реальную последовательность вычислений с единственным входом и  единственным выходом, как в подпрограмме.

    Организация цикла в литературе часто упоминается  как элемент DO-WHILE. Конструкция принятия двоичного решения называется IF-THEN-ELSЕ.

    Заметим, что эти конструкции могут  сами рассматриваться как функциональные блоки, поскольку они обладают только одним входом и одним выходом. Таким образом, можно ввести преобразование операции цикла в функциональный блок и в последующем рассматривать всякий такой оператор цикла эквивалентом (несколько более сложного) функционального блока. Аналогично можно ввести преобразование конструкции принятия решения к функциональному блоку. Наконец, можно привести всякую последовательность функциональных элементов к одному функциональному элементу. В то же время обратная последовательность преобразований может быть использована в процессе проектирования программы по нисходящей схеме, т. е. исходя из единственного функционального блока, который постепенно раскладывается в сложную структуру основных элементов.

Исследование  корректности реализации и верификация

    Понятие корректности или правильности подразумевает  соответствие проверяемого объекта  некоторому эталонному объекту или  совокупности формализованных эталонных  характеристик и правил. Корректность ПО при разработке наиболее полно определяется степенью соответствия предъявляемым к ней формализованным требованиям программной спецификации. В спецификациях отражается совокупность эталонных характеристик, свойств и условий, которым должна соответствовать программа. Основную часть спецификации составляют функциональные критерии и характеристики. Исходной спецификацией, которой должна соответствовать программа, является ТЗ или, в нашем случае, криптографический алгоритм.

    Традиционный  взгляд на спецификацию требований заключается  в том, что она представляет собой  документ на естественном языке, который  является интерфейсом между заказчиком и изготовителем. Хотя подготовке документа  и может предшествовать некоторое  взаимодействие, именно этот документ в значительной степени выступает  как «отправная точка» для изготовителя программ.

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

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

    Существует  несколько подходов к определению  спецификаций требований.

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

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

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

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

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

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

    Рассмотрение  программ в качестве некоего «преобразователя предикатов» позволяет прямо  определить связь между начальными и конечными состояниями без  каких-либо ссылок на промежуточные  состояния, которые могут возникнуть во время выполнения программы.

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

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

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

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

    Рассмотрим  формальный метод разработки программ более подробно.

Основы  преобразования предикатов и язык формальной разработки

    Введем  обозначение

      Q {S} R,

где Q и R - предикаты, а S - алгоритм (последовательность команд), которая имеет следующую интерпретацию: если выполнение S началось в состоянии, удовлетворяющем Q, т.е. при таком соотношении входных условий, что Q истинно, то имеется гарантия завершения S через конечное время в состоянии, удовлетворяющем R. Здесь Q называется предусловием, а R - постусловием.

Основные  свойства преобразователей предикатов

    Для детерминированной конструкции  S и некоторого постусловия R всякое начальное состояние попадет в одно из трех непересекающихся множеств в соответствии со следующими взаимно исключающими возможностями:

    а) Запуск конструкции S приведет к конечному состоянию, удовлетворяющему R.

    б) Запуск конструкции S приведет к конечному состоянию, удовлетворяющему non R.

    в) Запуск конструкции не приведет к какому бы то ни было конечному состоянию, т.е. работа не может завершиться.