Файл: Системы автоматизированного проектирования технологических процессов..pdf

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

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

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