книги / Надежность программного обеспечения систем обработки данных
..pdfИспользование библиотек. Для улучшения построения программ, ускорения их отладки и тестирования важным средством является использование библиотек программ Одним из источников библиотечных программ является выполнение программистами требований универсальности разработки Универсальность — это независимость прог раммы от конкретного набора данных. Опытные програм мисты зиают, что придание программе универсальности позволяет в дальнейшем сохранить силы и сделает прог рамму более устойчивой по отношению к изменениям. Ре комеидуется всегда писать модули программ с таким рас четом, чтобы за счет незначительных изменений илн улучшений сделать программу полезной еще где-иибудь При таком исполнении универсальные программы могут быть каталогизированы в библиотеку программ для ис пользования в других программах.
Как только программист или организация возьмутся за эту работу, постепенно вырастет библиотека полезных, проверенных программ, что ликвидирует большую часть скучного и повторяющегося программирования.
Другой причиной для написания универсальных прог рамм является склонность программ претерпевать изме нения в ходе применения по назначению. Сделав програм му универсальной, можно предупредить многие изменения в программе. Кроме того, тщательная проверка, можно ли сделать программу универсальной, прояснит построение программы. Исследование на универсальность обычно по могает определить будущие изменения и ожидаемые Неприятности сопровождения программы.
Другим источником библиотечных программ являются книги по организации механизированной обработки экоио* мической информации, программированию и применению ЭВМ. Ряд книг содержит программы, полезные для биб лиотеки. После некоторых усилий можно адаптировать эти программы для своих нужд.
Структурное программирование. Структурное програм мирование — это метод, предполагающий создание улуч шенных программ. Его цель — организация и упорядо чение построения программ и процесса программирования для предотвращения большинства логических ошибок и обнаружения оставшихся ошибок. Структурное програм мирование имеет две важные характерные особенности проектирование «сверху вниз» и модульное програм мирование.
Метод построения программ «сверху вниз» аналогичен написанию доклада. Доклады иерархически структури рованы и написаны обычно, начиная с вершины иерархии, т. е. с краткого конспекта. Таким образом, сначала необ ходимо написать конспект того, что будет делать програм ма. Каждый модуль может быть описан одним предложе нием. Если описание модуля займет более одной строки или небольшого параграфа, переделайте его.
Далее должны быть описаны данные, отмечены основ ные структуры и лид обработки данных. Это описание должно содержать хорошо подобранные примеры, иллюст рирующие функции и наиболее важные их видоизмене ния, что будет в дальнейшем полезно при тестировании. Каждый модуль должен иметь тестовые данные, описы ваемые вместе с модулями.
Важное достоинство данного метода — в гарантии соз дания документации, что также ведет к получению надеж ной программы. Программист вынужден обычно думать о структуре данных и проверке своей программы более тщательно, чем об ее описании иа бумаге.
Большинство работ по структурному программирова нию, основываясь иа методе разработки программы, ут верждает, что доказательство корректности структуриро ванных программ более простое.
Начать программирование лучше с наброска плана программирования, который обеспечивает исследование размеров рассматриваемых модулей, сложности их взаи мосвязей. Некоторые из критических модулей должны быть в дальнейшем разукрупнены. Методика структурного программирования позволяет избежать больших затрат при переписывании. Например, большие программы после написания преимущественно модифицируются, когда появляются некоторые ограничения. Делая сначала набро сок программы, можно решить некоторые вопросы, не затрачивая больших усилий на программирование.
Для того чтобы структурное программирование достиг ло своей цели, программа должна иметь модульную струк туру. Модульное программирование заключается в раз биении программы иа логические части и в последова тельном программировании каждой части. После разделе ния большой монолитной задачи иа меньшие логические части, которые более удобны для работы, ее легче понять, прочитать и запрограммировать
Большая программа делится иа логические части ана логично тому, как делится книга иа главы, а главы —
162
на параграфы. Каждый логический модуль программы простой структуры имеет небольшую длину. Это помогает читателю понять, что делает каждый модуль. В каждом модуле только одни вход сверху и один выход внизу. Для того чтобы можно было читать программу подряд, без перепрыгивания с места на место, не рекомендуется использовать команды перехода.
Существует тесная связь между стилем программи* роваиия и используемым языком программирования, а также обеспечением надежности разрабатываемого про дукта ПО. Однако пока еще не удалось найти статисти чески приемлемых количественных оценок в силу слож ности организации эксперимента.
Вопросы к главе 7
1 |
Сформулируйте задачи внешнего проектирования модулей |
2 |
Дайте характеристику шагов проектирования модуля |
3 |
В чем сущность и задачи защитного программирования? |
4. Перечислите и охарактеризуйте основные принципы стиля програм мироваиия
i Чем определяются ясность и простота программы?
Г л а в а 8
ОБЕСПЕЧЕНИЕ НАДЕЖНОСТИ
ВПРОЦЕССЕ КОНТРОЛЯ
8.1.ЗАДАЧИ ПРОВЕДЕНИЯ КОНТРОЛЯ ПРОГРАММ
Основной целью контроля программ является нахожде ние еще не известных нам ошибок. В этом смысле конт роль и надежность не противоречивы. Несмотря на то что контроль оказывает определенное влияние на надежность, однако его значение для достижения заданного уровня надежности все же ограничено. Процедуры контроля не могут сами по себе повысить уровень надежности ПО, так как она должна обеспечиваться на стадии проектирования. Лучшим способом повышения надежности является исключение с самого начала возможности появления оши бок.
Однако вероятность безупречной разработки большой и достаточно сложной системы ПО бесконечно мала. Поэтому роль контроля заключается в выявлении того небольшого количества ошибок, которое может иметь место в тщательно разработанной программе. Попытки полагаться на контроль в целях повышения надежности
153
небрежно составленной программы практически безре зультатиы
Контроль является сложной проблемой еще и потому, что практически отсутствует теория его организации, а имеющие место интуитивные подходы к его выполнению ие могут быть оценены иначе, как первая проба сил по раз работке надежного ПО.
В настоящее время такие термины, как тестирование, отладка, проверка, верификация и обоснование програм мы, часто используются для определения одних и тех же процессов, но различные люди вкладывают различные по нятия в эти термины. Не существует устоявшихся опре делений этих терминов, однако для однозначного восприя тия материала приведем здесь хотя и не бесспорные, но конкретные определения.
Под контролем понимается процесс выполнения прог раммы с целью определения содержащихся в ней ошибок Проверка есть попытка обнаружить ошибки в программе без учета условий и режимов, в которых эта программа будет выполняться Технические приемы такой проверки включают формулирование утверждений о поведении программы при ее выполнении и определении правиль ности программы на основе этих сформулированных по ложений. Такую проверку можно считать одной из форм контроля, хотя она и не предполагает непосредственного выполнения программы. Многие исследователи рассматри вают проверку как альтернативу контроля, однако такой взгляд в значительной степени неверен.
Верификация попытка обнаружить ошибки в прог рамме в процессе ее выполнения в контрольных или смо делированных условиях, а обоснование есть попытка найтн ошибки в процессе выполнения программы в заданных реальных условиях Утверждение — авторитетное под тверждение правильности программы на основе аналити ческих данных. Контроль программ для нх утвержде ния не должен выполняться по каким-либо заранее опре деленным стандартам.
Отладка не является нормой контроля. Термины от ладка и контроль часто рассматриваются как однозначные действия. В то же время контроль — деятельность, нап равленная на обнаружение ошибок, а отладка — точное установление характера обнаруженной ошибки с после дующим ее исправлением.
Эти определения характеризуют контроль с учетом ус ловий его реализации Ниже приводится еще одна группа
определений, отражающих другой аспект проблемы конт ролятип ошибок, которые могут быть обнаружены в программе, и стандартный порядок, в соответствии с ко торым осуществляется контроль программ.
Модульный, или блочный, контроль — верификация от дельного программного модуля, обычно выполняемая в изолированных условиях, т. е вне связи испытываемого модуля со всеми другими частями программы. При вы полнении модульного контроля иногда осуществляется также и их математическая проверка
Интегрированный контроль — контроль взаимосвязей между различными частями системы (модулями, подсис темами), осуществляемый в процессе функционирования программы или системы в контрольных условиях
Контроль внешних факторов — проверка соответствия внешних функций системы техническим требованиям.
Системный контроль ■— проверка соответствия системы первоначально поставленным целям ее функционирования. Системный контроль выполняется как верификация, если он реализуется в контрольных условиях. Если же он вы полняется в реальных условиях функционирования сис темы, то он является обоснованием системы. Контроль при сдаче системы в эксплуатацию — обоснование соот ветствия системы или программы требованиям пользова теля.
Опытно-эксплуатационный контроль — обоснование системы, т е. эксплуатация в реальных условиях с целью Обнаружения ошибок, допущенных при наладке отдель ных ее частей
Взаимодействие между различными формами конт роля, проектной документацией и процессами проекти рования показано на рис. 8.1.
Далее рассмотрим некоторые очевидные принципы ор ганизации контроля, которые можно считать не более как
йроцедурами |
продолжения процесса проектирования. |
П е р в ы й |
п р и н ц и п контроля — принцип сегмен |
тации — основан на классическом подходе разделения сложной задачи на ряд небольших подзадач, которые в последующем рассматриваются как самостоятельные. Аргументы в пользу контроля программ по небольшим частям точно такие же, как и при кодировании модулей. При применении принципов модульного программирова ния модули кодируются и контролируются в отдельности, а затем выполняется интеграция модулей в систему.
Принцип сегментированного подхода к контролю доста-
1£5
НАЧАЛЬНЫЙ ЭТАП ПРОЕКТИ* РОВАНИЯ СИСТЕМЫ
ВНЕШНЕЕ ПРОЕКТИРОВАНИЕ СИСТЕМЫ
ФОРМУЛИРОВКА
ТРЕБОВАНИЙ
РАЗРАБОТКА ЦЕЛЕЙ 1
t разрабо тка ВНЕШНИХ СПЕЦИФИКАЦИЙ
ПРОЕКТИРОВАНИЕ И КО* ДИРОВДНИЕ МОДУЛЕЙ
ЭТАП ТЕСТИРОВАНИЯ
РАЗРАБОТКА АРХИТЕКТУРЫ СИСТЕМЫ
ПРОЕКТИРОВАНИЕ СТРУК* ТУРЫ ПРОГРАММ
>____________
ПРОЕКТИРОВАНИЕ
МОДУЛЕЙ
КОДИРОВАНИЕ
МОДУЛЕЙ
\ ------------------------
ТЕСТИРОВАНИЕ
МОДУЛЕЙ
ТЕСТИРОВАНИЕ
ИНТЕГРАЦИИ
ФУНКЦИОНАЛЬНОЕ
ТЕСТИРОВАНИЕ
СИСТЕМНОЕ
ТЕСТИРОВАНИЕ
ПРИЕМНО*СДАТОЧНОЕ ТЕСТИРОВАНИЕ
ТЕСТИРОВАНИЕ ПРИ УСТАНОВКЕ
Рис 8.1 Связь процессов проектирования и тестирования ПО
точно важен, так как обеспечивает более тщательную про верку модулей, обладающих хорошей обзорностью. Счи тается, что этот подход более экономичен и обеспечивает ускорение разработки системы ПО, организованной по мо дульному принципу.
В т о р о й п р и н ц и п состоит в проектировании конт роля. О контроле надо заботиться на всех этапах проекти рования. При рассмотрении вопросов проектирования обращалось внимание на необходимость организации контроля после каждого шага проектирования. Отдавая должное простоте идеи проектируемого контроля, нельзя не отметить, что в силу увеличивающихся расходов на проектирование и ограничений графика выполнения работ этот принцип в большей части не выдерживается.
Т р е т ь и м п р и н ц и п о м контроля является модели рование. В связи с тем, что системы ПО стали глубже прорабатываться при проектировании, а также с разви тием средств моделирования применение моделирования как средства контроля стало необходимостью. Основная «полезность» моделирования проверки — это возможность просмотреть программу без ее выполнения. Этот прием позволяет задержать проверку глобальных переменных до тех пор, пока они не будут проверены в иерархии, и облегчает создание и проведение относящихся к нему тестов.
В процессе организации моделирования возникают трудности, одной из которых является обеспечение пол ного соответствия моделируемого объекта и его модели. Это обстоятельство вынуждает заниматься проверкой полученных результатов. Вторая трудность состоит в том, что собственно проблема моделирования достаточно сложна так же, как и проверка программ. Эти проблемы делают использование моделирования достаточно доро гим, что может послужить решающим фактором при вы* боре.
Ч е т в е р т ы й п р и н ц и п — выборочный контроль.
Эта идея основана на широко распространенном в про мышленности выборочном контроле продукции. Нельзя утверждать, что выборочный контроль не используетсй в программировании. Так, для проверки некоторого моду-» ля, имеющего на входе несколько миллионов возмож ных комбинаций входных данных, совсем не обязательно просматривать все возможные комбинации. Достаточно определить набор критических ситуаций и проверить ра боту модуля именно на этих комбинациях.
157
К/почом к успеху выборочного контроля является нали чие алгоритмов отбора тестовых случаев, обеспечивающих наиболее чувствительные проверки. Выборка может сни зить важность систематической упорядоченной проверки, однако закон больших чисел просто не применим в данном случае, так как контроль в известной мере зависит от объекта проверки.
Существующие трудности не сдерживают стремления использовать аппарат выборочного контроля Например, известны подходы внутреннего анализа программ с целью определения наиболее напряженных ветвей, введение до полнительных ошибок перед началом процесса тестирова ния н т. Д . В целом принцип выборочного контроля важен в связи с экономичностью проведения тестирования и упрощением всей системы контроля ПО
П я т ы й п р и н ц и п — важный результат логического упрощения программы, или принцип логической редакции
Сущность логической редакции состоит в поиске и про ведении таких преобразований исходной программы, ко торые упрощают тестирование и повышают надежность программы. Обычные преобразования обеспечиваются на уровне блок-схем, граф-программ, табличных форм или некоторых простых алгебраических форм.
Втеории преобразований программ существует ряд интересных схем, однако практические результаты пока не позволяют надеяться на быстрое решение проблемы,
т.е. даже после интенсивной редакции в программе оста ется место для независимой информации, протестировать которую достаточно сложно.
Витоге видно, что большинство схем логической редакции еще недостаточно разработаны, чтобы быть успешно примененными при решении комплексных проб
лем. Высокая доля автоматизации и потенциальные воз можности логической редакции, побуждают дальнейшие поиски решения проблемы, т е возможности принципа остаются открытыми и требуют дальнейшего изучения
Ш е с т о й |
п р и н ц и п к о н т р о л я — принцип стан |
дартизации. |
Стандартизация облегчает автоматизацию |
работ такого комплексного плана, как контроль программ Одним из путей решения проблемы является получение стандартной кодовой структуры программы, что позволяет упростить анализ программы и облегчить достижение безопасности программ и данных
Стандартизация важна как средство для упрощения
15»
проблем тестирования и развития методологии получе ния надежных средств ПО
С е д ь м о й п р и н ц и п к о н т р о л я — принцип авто матизации Учитывая рутинность работ по контролю и и* достаточно большой объем, было бы простым решением поручить выполнять эту работу ЭВМ. Естественно, что для таких действий потребуются специальные средства автоматизацииспециальные генераторы тестовых слу чаев, проверочные устройства, контрольные оценщики программ, преобразователи и контрольные мониторы. Все эти средства существуют и в известной мере используют ся при тестировании Автоматизация позволяет повысить точность контроля, снизить временные и стоимостные затраты на контроль и ускорить процесс получения гото вого продукта ПО
8.2. МЕТОДЫ ВЫПОЛНЕНИЯ ИНТЕГРАЦИИ И КОНТРОЛЯ
Одной из завершающих стадий проектирования явля ется интеграция системы, включающая объединение раз работанных и проверенных модулей в систему В связи с тем, что к этому моменту каждый из объединяемых моду лей прошел тестовый контроль, было бы логично предпо ложить формирование комплексного теста при объедине нии, а также контроль объединения
Этой проблеме обычно уделяется недостаточное вни мание, и часто оиа рассматривается как второстепенная. Однако принятие решения о выборе последовательности объединения модулей имеет очень большое значение, так как порядок включения модулей в программу оказывает влияние на форму, в которой записываются тесты, на выбор средств контроля, порядок программирования моду лей, полноту и экономичность контроля. В связи с этим решение о порядке включения в систему должно прини маться с учетом основных целей всего проекта и на более ранней стадии его разработки
Известно большое число различных подходов к реше нию этой проблемы, однако большинство из них можно рассматривать в качестве вариантов одного из шести ос новных методов, излагаемых ниже
Контроль методом «Снизу вверх». При использовании данного метода объединение и контроль программы на чинаются с модулей самого низкого уровня Изолиро ванно контролируются только конечные модули, т. е моду ли, не вызывающие никаких других модулей Следующий
IS®
набор модулей, которые должны быть проверены,— это модули, непосредственно вызывающие уже проверенные сегменты программы. Этот процесс продолжается до тех пор, пока не будет проконтролирован модуль самого верхнего уровня структуры программ. При этом модули каждого следующего уровня испытываются не изолиро ванно, а вместе с предварительно проконтролирован ными модулями нижних уровней
При использовании данного метода контроля для каж дого испытываемого модуля требуется разрабатывать управляющий модуль, т. е. сегмент программы, который моделировал бы вызов контролируемого модуля и обеспе чивал передачу ему входных параметров. Одним из путей решения этой задачи является создание небольшой управ ляющей программы для каждого модуля. При этом тесты оформляются в виде входных данных, а управляющая программа, многократно вызывая испытываемый модуль, при каждом вызове передает ему различные тесты в ка честве входных параметров.
Контроль методом сСверху вниз». Этот метод не явля ется прямой противоположностью контролю методом «сни зу вверх». При использовании этого метода объединение и контроль модулей начинаются с блоков самого верх него уровня, который сначала проверяется независимо от других сегментов программы. Затем вызываемые им модули подключаются к программе, и полученная комби нация контролируется снова. Этот процесс повторяется до тех пор, пока все модули не будут объединены в еди ную программу.
При таком подходе к организации контроля необхо димо решить два вопроса:
1) что происходит, когда проверяемый блок вызывает модуль более низкого уровня, еще не подключенный к проверяемой комбинации?
2) каким образом тесты вводятся в программу? Первый вопрос решается посредством создания моду
лей, имитирующих функции, выполняемые отсутствующи ми модулями. В описаниях такого подхода часто встре чается фраза: «.. просто написать модуль-макет», однако в действительности эта задача оказывается весьма труд ной
Макет редко оказывается настолько простым, чтобы осуществлять лишь возврат управления в вызывающий модуль, так как последний, как правило, требует переда чи результатов работы вызванного модуля в качестве
160