Методология построения защищенных АС

 

Рассмотрим методы построения защищенных АС- Эти методы ус­ловно можно разделить на две группы:

1) относящиеся к произвольному ПО АС:

• иерархический метод разработки;

• исследование корректности и верификация.

2) специфичные только для систем защиты (теория безопасных систем).

 

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

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

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

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

• необходимость с самого начала принимать решение о выборе способа реализации компонентов АС - с помощью аппаратуры, микропрограмм или программ, что сделать очень трудно;

• возможность проектирования АС только после разработки аппаратуры;

• расхождение между реальной АС и определённой в ТЗ.

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

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

• функциональный блок;

• конструкция обобщенного цикла;

• конструкция принятия двоичного решения.

Функциональный блок можно представить как отдельный вычисли­тельный оператор или как любую другую реальную последовательность вычислений с единственным входом и единственным выходом, как в под­программе. Организация цикла в литературе часто упоминается как эле­мент DO-WHILE. Конструкция принятия двоичного решения называется IF-THEN-ELSE.

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

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

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

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

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

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