7.12. Сравнительный анализ интегрированных CAD/CAM-систем

i i

7.13. Проектирование надежных систем

Надежность информационных систем в основном определяется на­ дежностью программного обеспечения.

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

Таким образом, надежность 110 является функцией воздействия оиги.:

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

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

Рис. 7.16. Макромодельперевода

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

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

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

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

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

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

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

4Четвертый шаг представляет собой несколько процессов перевода -

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

чрезвычайно высокой.

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

На этом шаге осуществляется и другой процесс трансляции: перевод представления программы на языке программирования в объектный (выпол­ няемый машиной) код. Обычно этот перевод выполняется специальной про­ граммой - компилятором. Конечно, иногда и компиляторы содержат ошибки, вследствие чего ошибки Moiyr появиться и в объектной программе. Однако это ошибки неподвластны нам (если только программа, которая создается, сама не является компилятором).

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

Публикации определенным образом влияют на надежность ПО. Если ошибка возникает при их подготовке, они не будут точно описывать поведе­ ние программы (если только на шагах 4 и 6 не сделаны идентичные ошибки). Прочитав руководство, пользователь начинает работать с программой и об­ наружит, что она ведет себя не так, как он ожидал —это и является, по опре­ делению, ошибкой в программе. Конечно, даже если программа и публика­ ции согласуются между собой, в программе тем не менее могут присутство­ вать ошибки (например, если они возникли при переводе на шагах J, 2 или 3,

атакже если одинаковые ошибки совершены на шагах 4 и 6).

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

то нужно знать характеристики терминалов и линий связи. Неправильное ис­ толкование этих материалов может привести к ошибкам в ПО.

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

9.Готовая программа состоит из предложений, по крайней мере, од­ ного языка программирования. Непонимание синтаксиса и семантики языка также является причиной ошибок в тексте программы и, следовательно, в ПО.

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

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

11.Эгот шаг представляет собой непосредственное взаимодействие пользователя с ПО, например, при вводе данных с терминала и при анализе выходных данных. Если человеческие факторы учтены слабо (т.е. диалог че­ ловек - машина разработан плохо), вероятность ошибки пользователя увели­ чивается. Ошибки пользователя часто ставят систему в новые, непредвиден­ ные обстоятельства, увеличивая, таким образом, шансы проявления остав­ шихся в программе ошибок.

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

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

Макромодель перевода описывает происхождение большинства оши­ бок в ПО и причины, лежащие в основе ненадежности.

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

Рис .7.17. Микромодель перевода

форму В. Для этого он совершает четыре основных шага:

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

2.Запоминает информацию в своей памяти М.

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

4.Распространяет информацию с помощью письма, печати на терми­ нале или речи.

Даже такая упрощенная модель перевода позволяет исследовать воз­ никающие на каждом из этапов ошибки;

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

новить недостающие факты или просто не замечает существенной информа­ ции.

Эти же способности часто оказываются полезными при обнаружении ошибок. Если ошибки уже присутствуют в самом документе А, мы способны обнаружить их, осознавая несоответствие с нашим прежним жизненным опытом. Это, однако, полезно лишь тогда, когда мы отправляемся к создате­ лю документа А и выясняем с ним возникшие вопросы. Но чаще делается не так: мы разрешаем конфликт самостоятельно, иногда верно, иногда нет, и продолжаем работу дальше.

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

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

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

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

7.13.3.Методы обеспечения надежности

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

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

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

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

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

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

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

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

Меры обнаружения ошибок можно разбить на две подгруппы: пас­ сивные попытки обнаружить симптомы ошибки в процессе «обычной» рабо­ ты ПО и активные попытки программной системы периодически обследовать свое состояние в поисках признаков ошибок.

Конкретные меры обнаружения зависят от специфики предметной об­ ласти. Однако можно назвать следующие общие пассивные меры:

1.Проверку атрибутов любого элемента входных данных (тип, знак, пределы значения, длину данных).

2.Сравнение согласованности входных данных с какими-либо внут­

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

Пассивные меры обнаруживают ошибку лишь тогда, когда ее симпто­ мы подвергаются проверке. Можно делать дополнительные проверки, если спроектировать специальные средства активного обнаружения ошибок. Эти средства объединяются в диагностический монитор (в данном случае имеет­ ся в виду второе значение монитора - контролирующая и регулирующая про­ грамма): параллельный процесс, который периодически анализирует состоя­ ние системы с целью обнаружить ошибку.

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

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