Метода - верификация
Cтраница 1
Методы верификации позволяют проектировщику и разработчику операционной систем-ы гарантировать правильность создаваемого программного изделия. Правильные программы могут оказаться слабыми программами, если в них допущены просчеты, которые приводят к нарушению защиты от несанкционированного доступа. [1]
Методы верификации используются как для проверки соответствия проектов программного обеспечения спецификациям алгоритмов или программ, так и для проверки соответствия создаваемых программ исходным проектам. Если ошибки в спецификациях отсутствуют, то процедура верификации должна подтвердить, что проект и его программная реализация соответствуют исходным спецификациям. [2]
Инварианты, если они известны, можно использовать как альтернативу методам верификации, описанным в теореме правильности. Инвариантное отношение, помещаемое между ключевым словом while и while - тестом, является условием, которое должно удовлетворяться независимо от того, какое значение - истинно или ложно - принимает while - тест. [3]
Поскольку операционная система обычно представляет собой очень сложное программное изделие, а методы верификации приводят к длительным процедурам доказательства, полная проверка правильности операционной системы оказывается невозможной и даже нежелательной. Поэтому обычно предполагают, что из операционной системы можно выделить несколько элементарных частей, которые являются наиболее важными для обеспечения защиты операционной системы в целом. [4]
Другое направление сокращения времени на проверку корректности решений, принимаемых при функционально-логическом проектировании, связано с методами формальной верификации. [5]
Другое направление сокращения времени на проверку корректности решений, принимаемых при функционально-логическом проектировании, связано с методами формальной верификации. В этих методах вместо многократного моделирования схемы при различных тестовых воздействиях выполняют сопоставление проектного решения с некоторым эталоном методами, развиваемыми в теории дедуктивных систем. [6]
Описаны результаты выполнения проекта большой операционной системы Multics, в которой применены технология ядра защиты, принципы управления информационным потоком и методы верификации программ. Поскольку программа центрального супервизора содержит 54 000 операторов ( в основном на языке ПЛ / 1), а механизмы защиты предусмотрены лишь частично, при реализации было решено упростить супервизор и разработать ряд механизмов защиты, которые можно было бы описать простыми, легкодоступными для понимания моделями. Затем была выполнена программная реализация супервизора и проведена его верификация. [7]
Верификация нетривиальных программ - дело трудное и утомительное; большие программы, возможно, вообще не будут верифицированы до тех пор, пока не появятся методы автоматической верификации. [8]
Поэтому проектировщики должны предлагать алгоритмы с четким указанием требований и свойств, а программисты - писать программы, реализующие эти алгоритмы на ЭВМ. Методы верификации необходимы для того, чтобы убедиться в том, что программы реализуют заданные требования и свойства. [9]
Во второй главе рассматривается обобщенное необходимое условие равновесия по Нэшу в форме двухуровневой структуры Пао. Обсуждаются методы верификации, которые позволяют сформировать необходимое и достаточное условие получения равновесных оптимальных управлений. Представлен иерархический метод Пао-Нэш - оптимизации параметризованного программно-корректируемого закона управления. Обсуждается двухэтапная процедура реализации метода с введением третьего этапа для повышения быстродействия в окрестности равновесного решения и первого этапа выбора начальных приближений на основе сетевых подходов. Для быстрого получения оптимальных программных реализаций третий этап комбинируется со спектральным методом. Данный метод находит применение во всех указанных приложениях. В главе приведен иллюстрирующий пример. [10]
Проектирование программного обеспечения состоит прежде всего в разработке варианта разбиения программного обеспечения на модули на основе языка проектирования. В этой же главе описываются методы верификации правильности описания программного обеспечения на языке проектирования до того, как оно будет конвертировано в программы на языке программирования микрокомпьютера. [11]
Может возникнуть вопрос: для чего нужны развитые средства тестирования и отладки, если используем этап формального анализа исходной спецификации, а реализацию получаем автоматически. Дело в том, что, во-первых, принципиально невозможно создать такие методы верификации, которые давали бы полную гарантию правильности, и, во-вторых, при реальном исполнении начинают работать механизмы операционной системы, процедуры ввода / вывода, накладываются характеристики аппаратных средств - факторы, которые нельзя учесть на этапе формального анализа. В то же время этап формального анализа остается одним из самых важных, потому что любая ошибка, заложенная при проектировании в исходной спецификации, имеет распределенный характер и на этапе исполнения локализуется и исправляется чрезвычайно тяжело. [12]
Контроль перфорации методом верификации заключается в повторном переносе реквизитов с первичных документов на перфокарту с помощью кон-трольника. Разница в переносе информации заключается в том, что при перфорации пробиваются отверстия, а при верификации с помощью специального прощупывающего устройства контролируется их расположение на перфокартах. Методам верификации обнаруживается до 93 % ошибок. [13]
Перечень задач управления технологическим процессом на ГЭС сформирован на основании задач технологического управления станцией и как самостоятельным элементом, и как составной части энергосистемы. При этом группы задач Контроль и Обмен являются элементами информационного обеспечения, включая сюда и простейший вид управления по отклонению параметров от заданных. Последнее включается в информационное обеспечение по причине сходства с методами верификации ( проверки на достоверность) текущей информации, а также вследствие характера использования результатов контроля, которые в основном предназначены для отображения оперативному персоналу станции. [14]
 |
Последовательность подготовки носителей информации. [15] |
Страницы: 1 2