Технология программирования (стр. 1 )

Технология программирования.

Технология программирования. 1

Вопрос №1 Методы проектирования программного обеспечения (программных продуктов) 1

Вопрос №2 Принципы проектирования информационного обеспечения программного комплекса. 3

Вопрос №3 Показатели качества программного обеспечения. 3

Вопрос №4. Методы создания надежного программного обеспечения. 6

Вопрос № 5. Принципы построения интегрированной среды BC++Builder (ВС++) 9

Вопрос № 6. Динамически распределяемая память (ДРП). Типы организации данных в ДРП (списки). 11

Вопрос №7. Основы традиционного программирования. Определение подпрограммы-функции. Рекурсии. 13

Вопрос № 8. Основы объектно-ориентированного программирования (ООП). Определение класса. 15

Вопрос № 9. Трансляторы. Этапы трансляции. Генерация кода. 17

Вопрос № 10. Лексический, синтаксический и семантический анализаторы транслятора. 19

Вопрос №11. Языки программирования. Определение. Классификация. Формальные грамматики. 21

Вопрос №1 Методы проектирования программного обеспечения (программных продуктов)

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

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

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

1. Структурных подход

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

Базовыми принципами структурного подхода являются:

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

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

Основными из этих принципов являются:

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

Принципиальное различие между структурным и объектно-ориентированным подходом заключается в способе декомпозиции системы.

2. Объектно-ориентированный подход

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

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

абстрагирование инкапсуляция модульность иерархия

Кроме основных имеются еще три дополнительных элемента, не являющихся в отличие от основных строго обязательными:

типизация параллелизм устойчивость

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

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

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

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

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

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

Параллелизм – свойство объектов находиться в активном или пассивном состоянии и различать активные и пассивные объекты между собой.

Устойчивость – свойство объекта существовать во времени (вне зависимости от процесса, породившего данный объект) и/или в пространстве (при перемещении объекта из адресного пространства, в котором он был создан).

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

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

В объектно-ориентированном подходе основная категория объектной модели – класс – объединяет в себе на элементарной уровне, как данные, так и операции, которые над ними выполняются (методы).

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

Вопрос №2 Принципы проектирования информационного обеспечения программного комплекса.

С точки зрения готового решения система должна удовлетворять следующим требованиям:

1.  Соответствие уставу проекта/техническому заданию.

2.  Адекватность отображения предметной области. Для соблюдения этого очевидного принципа необходимо тесное взаимодействие проблемного пользователя и программиста. Оценить адекватность может только квалифицированный специалист в данной проблемной области.

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

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

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

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

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

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

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

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

При разработке системы необходимо учитывать следующие принципы:

1. Оптимизация времени на тестирование и отладку.

Тестирование и отладка программы – необходимый этап в процессе решения задачи на ЭВМ. Он занимает от трети до половины всего времени разработки программы, поэтому очень важно уменьшить время, затрачиваемое на тестирование и отладку.

Тестирование и отладка программы облегчается, если программа просто анализируется и снабжена необходимыми комментариями, облегчающими ее понимание. Хорошие комментарии могут ускорить процесс отладки. Еще один важный принцип – использование мнемонических обозначений для переменных. Языки программирования представляют здесь вполне достаточные возможности. Для лучшего понимания программы необходимо использовать мнемонику, отражающую физический (математический, экономический и т. д.) смысл переменной (например, SPEED - скорость).

2. Простота и "понятность" кода.

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

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

3. Гибкость системы.

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

4. Эффективность.

Эффективность программы считается одной из главных ее характеристик. Поэтому часто в ущерб другим качествам программы разработчики прибегают к сложным ухищрениям, чтобы уменьшить объем используемой памяти или сократить время выполнения программы. Во многих случаях затрачиваемые на это усилия не оправдывают себя. Разумный подход к повышению эффективности программы состоит в том, чтобы выявить наиболее "узкие" места и постараться их улучшить.

Вопрос №3 Показатели качества программного обеспечения

Мы можем выделить следующие специфические для ПО показатели качества:

- функциональная полнота

- удобство

- надежность

- техническая эффективность

- адаптивность

- стоимость

функциональная полнота

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

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

удобство

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

Удобство использования ПО характеризуют следующие показатели:

-  время реакции системы

-  количество информации, предъявляемой системой, которое необходимо переработать пользователю

-  количество действий, предпринимаемых пользователем при работе с ПО

-  эстетика оформления результатов работы

-  время освоения приемов работы с ПО

1. Время реакции системы

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

2. Количество информации, предъявляемое системой, которое необходимо переработать пользователю

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

3. Количество действий, предпринимаемых пользователем при работе с ПО

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

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

4. Эстетика оформления результатов работы

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

5. Время освоения приемов работы с ПО

Время освоения пользователем ПО также является одним из важнейших показателей удобства ПО. Чем меньше это время, тем проще ПО для использования, сл-но, тем он лучше, удобнее. Рассмотрим пример двух диалоговых систем. В первой системе все приемы работы изложены в печатной инструкций; во второй - они выводятся в виде оперативных подсказок на экране. Очевидно, что вторая система удобнее: не нужно держать в памяти возможные варианты действий или рыться в инструкции, теряя время и отвлекаться от экрана.

Надежность

Можно выделить два основных аспекта надежности:

- отсутствие в готовой программе ошибок проектирования и программирования

- защищенность программы от непредусмотренных условий эксплуатации

1. Отсутствие в готовой программе ошибок проектирования и программирования

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

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

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

2. Защищенность программы от непредусмотренных условий эксплуатации

Другой аспект надежности заключается в степени защищенности ПО от:

- непредусмотренных действий пользователя

- недопустимых сочетаний исходных данных

- влияние операционного окружения

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

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

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

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

техническая эффективность

Этот показатель характеризует объемы требующихся ресурсов вычислительной системы:

объем оперативной памяти

объем внешней памяти

время работы процессора

привлекаемые компоненты операционной системы

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

Тем не менее, верно следующее: из двух программ с одинаковыми функциональными свойствами лучше та, которая потребляет меньше ресурсов. Но и в этом плане надо иметь в виду, что абсолютная величина ресурсов не дает достаточно полной информации. Например, если одна программа требует 30 килобайтов основной памяти, а другая – 60, то в случае работы на ПЭВМ, это различие не играет никакой роли. Хотя в то же время вторая программа потребует, по - видимому, большего объема внешней памяти и в этом плане ее показатели хуже.

Адаптивность

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

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

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

Наиболее сложные задачи адаптации возникают при переносе ПО с ЭВМ одного типа на другую. Естественно, такой перенос возможен только на уровне исходных текстов, так, что ПО представленный только загрузочным модулем заведомо непереносим.

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

Стоимость

С точки зрения потребителя следует различать два аспекта показателя: стоимость приобретения и стоимость эксплуатации.

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

Вопрос №4. Методы создания надежного программного обеспечения

Основные принципы проектирования

Разработка программы включает задачи двух типов: проектирование и тестирование.

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

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

четыре подхода к надежности

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

Предупреждение ошибок

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

1. Методы, позволяющие справиться со сложностью, свести ее к минимуму, так как это — главная причина ошибок перевода.

2. Методы достижения большей точности при переводе.

3. Методы улучшения обмена информацией.

4. Методы немедленного обнаружения и устранения ошибок. Эти методы направлены на обнаружение ошибок на каждом шаге перево­да, не откладывая до тестирования программы после ее написания.

Должно быть очевидно, что предупреждение ошибок — оптимальный путь к достижению надежности программного обеспечения. Лучший способ обеспечить надежность — прежде всего не допустить возникновения ошибок. Гарантировать отсутствие ошибок, однако, невозможно никогда. Другие три группы методов опираются на предположение, что ошибки все-таки будут.

Обнаружение ошибок

Если предполагать, что в программном обеспечении какие-то ошибки все же будут, то лучшая (после предупреждения ошибок) стратегия — включить средства обнаружения ошибок в само программное обеспечение. Эта идея нашла отражение в фильме «2001: Космическая Одиссея», правда на примере обнаружения сбоев в ап­паратуре.

Компьютер: «У меня затруднения в поддержании контакта с Землей. Поломка в устройстве АЕ-35. Мой центр прогнозирования сбоев сообщает, что оно может выйти из строя в течение 72 часов».

Большинство методов направлено по возможности на незамедли­тельное обнаружение сбоев. Немедленное обнаружение имеет два преимущества: можно минимизировать как влияние ошибки, так и последующие затруднения для человека, которому придется из­влекать информацию об этой ошибке, находить ее место и исправлять.

Исправление ошибок

Следующий шаг — методы исправления ошибок; после того как ошибка обнаружена, либо она сама, либо ее последствия должны быть исправлены программным обеспечением. Исправление ошибок самой системой — плодотворный метод проектирования надежных систем аппаратного обеспечения. Некоторые устройства способны обнаружить неисправные компоненты и перейти к использованию идентичных запасных. Аналогичные методы неприменимы к програм­мному обеспечению вследствие глубоких внутренних различий между сбоями аппаратуры и ошибками в программах. Если некоторый программный модуль содержит ошибку, идентичные «запасные» модули также будут содержать ту же ошибку.

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