Ващенко Г.В., Добронец Б.С. Надежность информационных систем

Подождите немного. Документ загружается.

Надежность информационных систем 71

1. Методы, позволяющие справиться со сложностью, свести ее к мини-

муму, так как это главная причина ошибок перевода.

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

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

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

направлены на обнаружение ошибок на каждом шаге перевода, а не во время

тестирования программы после ее написания.

Очевидно, что предупреждение ошибок — оптимальный путь к дости-

жению надежности программного обеспечения. Лучший способ обеспечить

надежность — не допустить возникновения ошибок. Гарантировать отсут-

ствие ошибок, однако, невозможно. Другие три группы методов опираются

на предположение, что ошибки все-таки будут.

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

Если предположить, что в программном обеспечении какие-то ошибки

все же будут, то лучшая (после предупреждения ошибок) стратегия — вклю-

чить средства обнаружения ошибок в само программное обеспечение.

Большинство методов направлено по возможности на незамедлитель-

ное обнаружение сбоев. Немедленное обнаружение имеет два преимущества:

можно минимизировать как влияние ошибки, так и последующие затрудне-

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

находить ее место и исправлять.

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

Следующий шаг — методы исправления ошибок; после того как ошибка

обнаружена, либо она сама, либо ее последствия должны быть исправлены

программным обеспечением. Исправление ошибок самой системой — плодо-

творный метод проектирования надежных систем аппаратного обеспечения.

Некоторые устройства способны обнаружить неисправные компоненты и пе-

рейти к использованию идентичных запасных. Аналогичные методы непри-

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

личий между сбоями аппаратуры и ошибками в программах. Если некоторый

программный модуль содержит ошибку, идентичные “запасные” модули так-

же будут содержать ту же ошибку.

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

шения, вызванные ошибками, например искажения записей в базе данных

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

ями ограниченна, поскольку предполагается, что разработчик заранее преду-

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

реализуемые функции для их устранения. Это похоже на парадокс, посколь-

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

72 Проектирование надежного программного обеспечения

дополнительные меры по их предупреждению. Если методы ликвидации по-

следствий сбоев не могут быть обобщены для работы со многими типами

искажений, лучше всего направлять силы и средства на предупреждение

ошибок. Вместо того чтобы, разрабатывая операционную систему, оснащать

ее средствами обнаружения и восстановления цепочки искаженных таблиц

или управляющих блоков, следовало бы лучше спроектировать систему так,

чтобы только один модуль имел доступ к этой цепочке, а затем настойчиво

пытаться убедиться в правильности этого модуля.

Устойчивость к ошибкам

Методы этой группы ставят своей целью обеспечить функционирование

программной системы при наличии в ней ошибок. Их разбивают на три под-

группы: динамическая избыточность, методы отступления и методы изоля-

ции ошибок.

1. Истоки концепции динамической избыточности лежат в проектирова-

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

сти — метод голосования. Данные обрабатываются независимо несколькими

идентичными устройствами, и результаты сравниваются. Если большинство

устройств выработало одинаковый результат, этот результат и считается пра-

вильным. Вследствие особой природы ошибок в программном обеспечении

ошибка, имеющаяся в копии программного модуля, будет также присутство-

вать во всех других его копиях, поэтому идея голосования здесь, видимо,

неприемлема. Предлагаемый иногда подход к решению этой проблемы состо-

ит в том, чтобы иметь несколько неидентичных копий модуля. Это значит, что

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

алгоритмы, либо созданы разными разработчиками. Этот подход бесперспек-

тивен по следующим причинам. Часто трудно получить существенно разные

версии модуля, выполняющие одинаковые функции. Кроме того, возникает

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

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

зультатов. Это дополнительное программное обеспечение повышает уровень

сложности системы, что, конечно, противоречит основной идее предупрежде-

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

Второй подход к динамической избыточности — выполнять эти запасные

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

пии, признаны неправильными. Если это происходит, система автоматически

вызывает запасную копию. Если и ее результаты неправильны, вызывается

другая запасная копия и т. д. Этот подход страдает большинством перечис-

ленных ранее недостатков. Кроме того, вполне вероятно, что если ресурсы

при работе над проектом фиксированы, то при реализации “запасных” вер-

Надежность информационных систем 73

сий проектированию и тестированию будет уделено меньше внимания, чем

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

мическая избыточность не использовалась.

2. Вторая подгруппа методов обеспечения устойчивости к ошибкам назы-

вается методами отступления или сокращенного обслуживания. Эти методы

приемлемы обычно лишь тогда, когда для системы программного обеспече-

ния существенно важно благопристойно закончить работу. Например, если

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

и в результате эта система выходит из строя, то может быть загружен и

выполнен особый фрагмент программы, призванный подстраховать систему

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

сов. Аналогичные средства часто необходимы в операционных системах. Если

операционная система обнаруживает, что она вот-вот выйдет из строя, она

может загрузить аварийный фрагмент, ответственный за оповещение пользо-

вателей у терминалов о предстоящем сбое и за сохранение всех критических

для системы данных.

3. Последняя подгруппа — методы изоляции ошибок. Основная их цель

— не дать последствиям ошибки выйти за пределы как можно меньшей ча-

сти системы программного обеспечения, так чтобы если ошибка возникнет, то

не вся система оказалась неработоспособной; отключаются лишь отдельные

функции в системе либо некоторые ее пользователи. Например, во многих

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

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

целом продолжает функционировать. В телефонных переключательных си-

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

строя всей системы, просто разрывают телефонную связь. Другие методы

изоляции ошибок связаны с защитой каждой из программ в системе от оши-

бок других программ. Ошибка в прикладной программе, выполняемой под

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

эту программу. Она не должна сказываться на операционной системе или

других программах, функционирующих в этой системе.

Из этих трех подгрупп методов обеспечения устойчивости к ошибкам

только третья, изоляция ошибок, применима для большинства систем про-

граммного обеспечения.

Важное обстоятельство, касающееся всех четырех подходов, состоит в

том, что обнаружение, исправление ошибок и устойчивость к ошибкам в

некотором отношении противоположны методам предупреждения ошибок.

В частности, обнаружение, исправление и устойчивость требуют дополни-

тельных функций от самого программного обеспечения. Тем самым не толь-

74 Проектирование надежного программного обеспечения

ко увеличивается сложность готовой системы, но и появляется возможность

внести новые ошибки при реализации этих функций. Как правило, все рас-

сматриваемые методы предупреждения и многие методы обнаружения оши-

бок применимы к любому программному проекту. Методы исправления оши-

бок и обеспечения устойчивости применяются не очень широко. Это, однако,

зависит от области приложения. Если рассматривается, скажем, система ре-

ального времени, то ясно, что она должна сохранить работоспособность и

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

правления и обеспечения устойчивости. К системам такого типа относятся

телефонные переключательные системы, системы управления технологиче-

скими процессами, аэрокосмические и авиационные диспетчерские системы

и операционные системы широкого назначения.

Принципы — это независимые от области приложения стратегии обеспе-

чения надежности программных систем. Рассматриваются принципы проек-

тирования системы, программы, модуля, направленные на предупреждение

ошибок. Для остальных трех категорий принципы неизвестны. Методы — это

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

ства.

4.2. Процессы проектирования

Проектирование любого программного продукта включает несколько раз-

личных процессов. При хорошо поставленном руководстве проектом эти про-

цессы явно выражены, так что могут быть установлены контрольные сро-

ки, выбрана методология и по завершении каждого процесса можно прове-

рить “доброкачественность” его результатов. При плохом руководстве неко-

торые из этих процессов или все они не выделяются явно: каждый процесс

по-прежнему присутствует в каком-то виде, но некоторые из них проходят

неявно, вследствие чего контрольные сроки, методология и оценки никогда

не устанавливаются.

Рассмотрим модель процессов проектирования типичной крупной про-

граммной системы.

Требования → цели → предварительный внешний проект →

детальный внешний проект → проект архитектуры программы →

внешние проекты модулей → проекты логики модулей

Отметим, что модель не зависит от методологии. Все указанные в ней

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

ке, независимо от того, какой язык программирования был принят, писал

Надежность информационных систем 75

ли пользователь исходные требования, использовалось ли “структурное про-

граммирование” и т. д.

На первом шаге составляется перечень требований, т. е. четкое опреде-

ление того, что пользователь ожидает от готового продукта. Следующий шаг

касается постановки целей — задач, которые ставятся перед окончательным

результатом и самим проектом. Затем выполняется внешний проект высоко-

го уровня. На этом шаге определяется взаимодействие с пользователем, но

не рассматриваются многие его детали, такие, как форматы ввода-вывода.

Исходный внешний проект приводит к двум параллельным процессам.

В процессе детального внешнего проектирования завершается определение

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

В процессе разработки архитектуры системы выполняется разложение ее на

множество программ, подсистем или компонент и определяются сопряже-

ния между ними. Эти два шага ведут к процессу проектирования структуры

программы, в котором проектируются модули, их сопряжения и взаимосвязи

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

— внешнее проектирование модуля — это точное определение всех сопряже-

нии модуля. Последний шаг — проектирование логики модуля — состоит в

разработке внутренней логики каждого модуля системы, он включает также

выражение этой логики текстом конкретной программы.

Следует также помнить, что в работе над любым проектом последова-

тельность процессов проектирования отнюдь не так проста. Есть существен-

ная обратная связь между процессами. Например, во время одного из шагов

внешнего проектирования могут быть обнаружены погрешности в формули-

ровке целей, тогда нужно немедленно вернуться и исправить их. При про-

ектировании структуры программы можно внезапно обнаружить, что ука-

занная во внешних спецификациях функция неосуществима или обойдется

слишком дорого, тогда может понадобиться принять компромиссное реше-

ние и изменить внешние спецификации.

4.3. Сложность

Сложность — это основная причина ошибок перевода и, следовательно,

одна из главных причин ненадежности программного обеспечения. Слож-

ность почти не поддается ни точному определению, ни измерению. Однако

можно сказать, что мерой сложности объекта является количество интеллек-

туальных усилий, необходимых для понимания этого объекта.

В общем случае сложность объекта является функцией взаимодействия

между его компонентами. Например, сложность внешнего проекта программ-

76 Проектирование надежного программного обеспечения

ной системы в некоторой степени определяется связями между всеми ее внеш-

ними сопряжениями, например между командами пользователя и соотно-

шениями между входной и выходной информацией системы. Сложность ар-

хитектуры системы определяется связями между подсистемами. Сложность

проекта программы — функция связей между модулями. Сложность отдель-

ного модуля — функция связей между его командами.

В борьбе со сложностью программного обеспечения можно привлечь две

концепции из общей теории систем. Первая — независимость. В соответствии

с этой концепцией для минимизации сложности необходимо максимально уси-

лить независимость компонент системы. По существу это означает такое раз-

биение системы, чтобы высокочастотная динамика ее была заключена в еди-

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

низкочастотную динамику системы.

Вторая концепция — иерархическая структура. Иерархия позволяет стра-

тифицировать систему по уровням понимания. Каждый уровень представля-

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

уровней. Концепция уровня позволяет понять систему, скрывая несуществен-

ные уровни детализации. Например, система, которую мы называем “чело-

век”, представляется иерархией. Социолог может интересоваться взаимоотно-

шениями людей, не заботясь об их внутреннем устройстве. Психолог работает

на более низком уровне иерархии. Он может исследовать различные логиче-

ские и физические процессы в мозге, не рассматривая внутреннего строения

областей мозга. Еще ниже в этой иерархии находится нейролог — он имеет де-

ло со структурой основных компонент мозга. Однако он может изучать мозг

на этом уровне, не заботясь о молекулярной структуре отдельных белков в

нейроне. Химик-органик интересуется построением сложных аминокислот из

таких компонент, как атомы углерода, водорода, кислорода и хлора. Наконец,

физик-ядерщик изучает систему на уровне элементарных частиц в атоме и

взаимодействия между ними.

Иерархия позволяет проектировать, описывать и понимать сложные си-

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

социологу пришлось бы рассматривать его как необъятное и сложное множе-

ство субатомных частиц. Очевидно, что такое количество деталей подавило

бы его, так что невозможны были бы даже те ограниченные знания о чело-

веке, которыми мы располагаем.

К этим двум концепциям сокращения сложности (независимость и иерар-

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

они возникают. Основная проблема многих больших программных систем —

огромное количество независимых побочных эффектов, создаваемых компо-

Надежность информационных систем 77

нентами системы. Из-за этих побочных эффектов систему невозможно по-

нять. И можно быть уверенным, что систему, в которой нельзя разобраться,

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

ности.

Проектное решение любого уровня имеет некоторую внутреннюю орга-

низацию, или форму. Для минимизации сложности нам нужен метод прояв-

ления этой внутренней формы, с тем чтобы в соответствии с нею разбить

проект на части. При внешнем проектировании, например, разбиение систе-

мы в соответствии с ее внутренней формой называется концептуальной це-

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

проектированию структуры программы, рассматриваются методы определе-

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

жество компонент с высокой степенью независимости. При проектировании

логики программы дисциплина, называемая структурным программирова-

нием, имеет целью, помимо всего прочего, привести эту логику в соответствие

с несколькими базовыми стандартными формами.

4.4. Решение задачи

Большинство процессов разработки программного обеспечения — это

процессы решения некоторых задач. Внешнее проектирование сводится к ре-

шению такой задачи: “Переведите множество целей системы во внешние спе-

цификации”, где цели — данные, а внешние спецификации — неизвестные. В

задаче проектирования логики модуля даны внешние спецификации модуля,

а неизвестное — текст его программы. Отладка — это задача на построение

исправления ошибки (неизвестное) по описанию ее симптомов (данные).

Одно из лучших руководств по решению задач — книга Пойа “Как ре-

шать задачу”. Хотя речь идет в основном о решении геометрических задач

и математических головоломок, большинство изложенных в ней соображе-

ний применимы и к проектированию программного обеспечения. Поскольку

проблемы программного обеспечения в отличие от большинства математиче-

ских задач не имеют единственного “правильного” решения, следует слегка

изменить метод Пойа. Схема метода рассматривается ниже.

Алгоритм решения задачи

1. Поймите задачу

Изучите данные. Изучите неизвестные.

Достаточно ли данных для решения? Не противоречивы ли они?

2. Составьте план

Чего вы должны добиваться?

78 Проектирование надежного программного обеспечения

Какие методы проектирования будут использоваться?

Встречалась ли вам уже такая задача?

Не знаете ли вы близкой задачи? Можете ли вы воспользоваться ее резуль-

татом?

Можете ли Вы решить более специализированную или аналогичную задачу?

Можете ли вы решить часть задачи?

3. Выполните план

Следуйте своему плану решения задачи. Проверяйте правильность каждого

шага.

4. Проанализируйте решение

Все ли данные вы использовали? Проверьте правильность решения.

Можете ли вы воспользоваться полученным результатом или примененным

методом при решении других задач?

1. Поймите задачу

Худшая из ошибок, которые могут быть сделаны при решении задачи,—

не вполне разобраться в ее постановке. Понять задачу — это значит понять

два ее компонента: данные и неизвестное. Данные — это все элементарные

факты, касающиеся задачи, и связи между фактами и неизвестным. Усвоение

всех данных о сложной задаче — большая, но абсолютно неизбежная работа.

При этом в первую очередь необходимо хорошо охватить “общую картину”

данных без деталей, которые, однако, также запоминаются “в сторонке”, что-

бы их можно было легко вспомнить позже. Есть много способов добиться

этого. Например, кое-кто физически разрезает спецификации на куски, ко-

торые затем расклеиваются на стене в определенном порядке. Это позволяет

увидеть “общую картину” и при этом определить место для каждой детали.

Вторая часть задачи — неизвестное. Проектировщику следует понимать,

какую форму должно иметь решение. Если, например, задача — детальное

внешнее проектирование программы, то проектировщик должен ясно пред-

ставлять назначение внешних спецификаций, их потенциальных читателей,

формат и т. д.

Исследуя задачу, проектировщик должен также исследовать данные,

чтобы убедиться, что их достаточно для решения задачи и они не проти-

воречат друг другу.

2. Составьте план

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

сутствие плана — очень распространенная ошибка. Например, проектиров-

щики программной системы, которые потратили время на то, чтобы понять

задачу, но затем немедленно приступили к ее решению, не пожелав тратить

время на планирование своих усилий, в конце концов могут прийти к хоро-

Надежность информационных систем 79

шему решению, но не раньше, чем после нескольких ненужных фальстартов.

Прежде всего в плане нужно определить, чего вы хотите добиться. Де-

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

го” ответа на задачу проектирования; проектировщик должен предусмотреть

те конкретные аспекты решения, которые требуют наибольшего внимания.

К сожалению, в большинстве проектов разработчики имеют слишком много

свободы в этом отношении: каждый проектировщик принимает компромисс-

ные решения, основываясь исключительно на своем собственном мнении, что

приводит к несогласованности многих решений в системе. Суть идеи состо-

ит в том, что на уровне всего проекта определяются общие цели, которыми

следует руководствоваться во всех решениях при проектировании.

Ключевой компонентой успешного проектирования является методоло-

гия. Выбор подходящей методологии для каждого конкретного процесса про-

ектирования должен быть зафиксирован в качестве одной из составляющих

плана.

Накопленный опыт, образование и имеющиеся решения проблем также

существенно влияют на успех дела. Обработка данных в своей эволюции до-

стигла такой точки, когда проектировщик крайне редко сталкивается с за-

дачей, которая уже не была бы решена частично или полностью. Напри-

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

созданы сотни операционных систем и на эту тему написан не один учебник.

Проектировщик, столкнувшись с задачей сортировки, должен знать, что уже

придумано и проанализировано множество алгоритмов сортировки. При ра-

зумном подходе к решению задач начинать следует с анализа своего опыта и

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

Даже если готовое решение найти не удается, вероятно, когда-то была

решена близкая задача. Проектировщик системы резервирования авиабиле-

тов может сообразить, что у нее есть много сходства с другими системами

резервирования, например с системой резервирования мест в гостинице. То-

гда ему, возможно, удастся выделить и применить у себя элементы решения

задачи о резервировании мест в гостинице.

Если все эти методы не приносят успеха, может оказаться эффективным

решение более специализированной задачи или — части задачи. Если коли-

чество деталей в постановке задачи слишком велико, разработчику следует

посмотреть, нельзя ли упростить ее, отбросив часть деталей. В результате

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

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

что можно будет прекратить заниматься упрощенным вариантом и начать

сначала.

80 Проектирование надежного программного обеспечения

3. Выполните план

Следующий шаг — действительно решить задачу в соответствии с запла-

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

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

проверить правильность каждого шага.

4. Проанализируйте решение

После того как результат получен, нужно еще его проверить. Разработ-

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

имеет отношение к делу. Полезно для этого еще раз перечитать букваль-

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

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

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

ность решения задачи.

4.5. Правильность проектирования

Явно выделенным этапом всякого процесса проектирования должна быть

проверка правильности результатов, т. е. попытка найти ошибки перевода,

возникшие в этом процессе. Дело не только в том, что стоимость исправле-

ния ошибки тем ниже, чем раньше она будет обнаружена, но и в том, что

вероятность правильно исправить ошибку на ранней стадии работы над про-

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

поздних этапах, например при тестировании системы.

Хотя проверка правильности каждого отдельного процесса проектиро-

вания обсуждается в последующих главах, можно сформулировать общую

философию проверки в виде правила n плюс-минус один.

Вопросом первостепенной важности при проверке правильности проек-

та является привлечение к этому делу подходящих людей. “Наиболее подхо-

дящие” люди — это те, в чьих интересах обнаружить все ошибки. Правило

“плюс-минус один” состоит в следующем: проверка правильности фазы n про-

екта должна осуществляться проектировщиками фаз n + 1 и n − 1.

Пусть, например, мы закончили фазу проектирования архитектуры си-

стемы и видим, что проектировщики фазы n−1 — это авторы исходных внеш-

них спецификаций, пректировщики фазы n + 1 — это разработчики структу-

ры программы. Именно им и следует доверить “тестирование” архитектуры

системы.

В основе нашей философии лежит предположение, что всякий процесс

проверки правильности (тестирование) должен иметь разрушительный, даже

садистский характер. Цель должна состоять в том, чтобы обнаружить лю-