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

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

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

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

моментами проверки и реального их использования операционной системой.

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

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

мы.

8. Прикладные программы не должны иметь возможности в обход опера-

ционной системы прямо использовать управляемые ею аппаратные ресурсы.

Прикладные программы не должны прямо вызывать компоненты операцион-

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

9. Компоненты операционной системы должны быть изолированы друг

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

компонент или их данных.

10. Если операционная система обнаруживает ошибку в себе самой, она

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

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

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

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

оговорочно прекращать их выполнение.

Задания

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

ния и устранения ошибок для следующих модулей.

1. Решение квадратного уравнения.

2. Площадь треугольника.

3. Интерполяционный полином Лагранжа.

4. Сортировка списка.

5. Интегрирование функции.

6. Редактор строки.

7. Сумма ряда.

Лабораторная работа № 4.

Проектирование модулей

Цель работы: Закрепление знаний по теме “Надёжное программное обес-

печение. Основные показатели. Проектирование” и приобретение навыков

проектирования модульного ПО.

Самостоятельная работа студента под контролем преподавателя. Вы-

полнение лабораторной работы студентом состоит из следующих этапов:

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

Внешнее проектирование модуля - определение его внешних характери-

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

торые содержат все сведения, необходимые вызывающим его модулям. Необ-

ходимо указать: имя, функция, список параметров (входные и выходные),

внешние эффекты.

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

(кодирования) внутренней логики каждого модуля.

Выбор алгоритма и структуры данных. Для этой цели используются

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

Проверка правильности работы модуля до компиляции на ЭВМ.

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

ных модулей, ее иерархическая структура,

Проектирование и программирование модуля

Этапы проектирования и программирования каждого модуля — заклю-

чительные в общем цикле проектирования. На этих этапах выполняются про-

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

дого модуля) и проектирования логики модуля (т. е. ряд шагов, включающих

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

граммирование). Для многих эти процессы олицетворяют сущность програм-

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

часть полного цикла разработки программного обеспечения.

В данной главе рассматриваются принципы и методы проектирования

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

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

главах. Такие вопросы, как нисходящая и восходящая разработка программ,

рассматриваются далее вследствие их тесной связи с проблемами тестирова-

ния.

Внешнее проектирование модуля

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

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

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

его модулям, и ничего больше. В частности, внешние спецификации модуля

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

нем представлении данных. Кроме того, спецификации не должны включать

каких бы то ни было ссылок на вызывающие модули или на контексты, в

которых этот модуль используется.

Внешние спецификации модуля должны содержать сведения следующих

шести типов:

1. Имя модуля. Указывается имя, применяемое для вызова модуля. Для

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

входа имеются отдельные спецификации).

2. Функция. Дается определение функции или функций, выполняемых

модулем.

3. Список параметров. Определяется число и порядок параметров, пе-

редаваемых модулю.

4. Входные параметры. Дается точное описание всех входных парамет-

ров. Сюда включается определение формата, размеров, атрибутов, единиц из-

мерения (например, морские мили) и допустимых диапазонов значений всех

входных параметров.

5. Выходные параметры. Дается точное описание всех данных, возвра-

щаемых модулем. Сюда должно входить определение формата, размеров, ат-

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

ных данных. Должна быть описана функциональная связь между входными

и выходными данными, т. е. следует показать, какие выходные данные ка-

кими входными порождаются. Должны быть также определены выходные

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

ся. Для того чтобы можно было считать модуль специфицированным полно-

стью, должно быть определено его поведение при любых входных условиях.

6. Внешние эффекты. Дается описание всех внешних для программы или

системы событий, происходящих при работе модуля. Примерами внешних

эффектов являются печать сообщения, чтение запроса с терминала, чтение

из файла заказов, вывод сообщения об ошибке. Внешние эффекты модуля

включают все внешние эффекты подчиненных ему модулей. Например, если

модуль А вызывает модуль В и В печатает сообщение, этот внешний эффект

должен включачься во внешние спецификации как модуля А, так и модуля

В.

Важно отделить внешние спецификации модуля от другой документации

(например, описания его логики), потому что изменение логики может никак

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

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

Проектирование логики модуля

Последним в длинной цепи процессов проектирования программного обес-

печения является процесс проектирования и собственно программирования

(кодирования) внутренней логики каждого модуля. Очень часто идея тща-

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

модуль более или менее хаотично. Однако процесс разработки модуля мо-

жет и должен тщательно планироваться. Следующие 11 шагов составляют

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

1. Выберите язык. Выбор языка обычно диктуется требованиями кон-

тракта или принятыми в организации стандартами. Хотя выбор языка и

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

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

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

средств тестирования).

2. Спроектируйте внешние спецификации модуля. Это процесс опреде-

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

дущем параграфе.

3. Проверьте правильность внешних спецификаций. Правильность спе-

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

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

мы, и анализом их всеми программистами, разрабатывающими вызывающие

модули.

4. Выберите алгоритм и структуры данных. Жизненно важным ша-

гом в процессе проектирования логики является выбор алгоритма и соответ-

ствующих структур данных. Сегодня лишь немногие алгоритмы создаются

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

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

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

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

нечисленных алгоритмах (т. е. о большинстве видов обработки данных), луч-

ше всего начать с книги Д. Кнута о фундаментальных алгоритмах [14] и

последующих томов этой серии. В случае численных алгоритмов начните с

издаваемых АСМ “Избранных алгоритмов из САСМ” (Collected Algorithms

from САСМ). Другим источником алгоритмов обоих типов являются учебни-

ки, технические статьи и существующие программы. Более подробно о выборе

алгоритмов и структур данных смотрите книгу Н. Вирта [7].

Обычно проектировщик обнаруживает несколько функционально экви-

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

из них. Поскольку многие современные вычислительные системы имеют мно-

гоуровневую память (обычно это основная память, виртуальная память, быст-

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

к истинной эффективности,— назад, к простейшим алгоритмам и структурам

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

жет оказаться не намного быстрее, чем более простой последовательный).

Это пример того, как эффективность и простота становятся не противоречи-

выми, а согласованными требованиями!

5. Напишите первое и последнее предложения. Следующий шаг — на-

писать предложения PROCEDURE и END будущего модуля (или их эквива-

ленты, в зависимости от избранного языка программирования). Если модуль

имеет несколько входов, сразу же пишутся и предложения ENTRY. Отметим,

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

ны этого будут рассмотрены ниже.

6. Объявите все данные из сопряжения. Следующий шаг состоит в на-

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

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

7. Объявите остальные данные. Напишите предложения, которые опре-

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

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

крывается со следующим.

8. Детализируйте текст программы. Следующий шаг — итеративный,

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

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

граммы. На этом шаге используются методы пошаговой детализации и струк-

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

фе.

9. Отшлифуйте текст программы. Теперь модуль нужно отшлифовать

для достижения “ясности” и снабдить его дополнительными комментариями,

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

10. Проверьте правильность программы. Вручную проверяется правиль-

ность модуля. Соответствующие процедуры описаны в последнем параграфе

этой главы.

11. Компилируйте модуль. Последний шаг — компиляция модуля. Этот

шаг отмечает переход от проектирования к тестированию; компиляцией, по

существу, начинается тестирование программного обеспечения.

Структурное программирование и пошаговая детализация

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

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

она, вероятно, войдет в историю как одно из крупнейших достижений в тех-

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

высокого уровня). Далее рассматриваются основные свойства структурных

программ, а также некоторые интересные моменты, которые часто остаются

без внимания.

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

ентированное на общение с людьми, а не с машиной. Чтобы соответствовать

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

щим основным требованиям:

1. Текст программы представляет собой композицию трех основных эле-

ментов: последовательное соединение (следование), условное предложение

(развилка) и повторение (цикл).

2. Употребления GO TO избегают всюду, где это возможно.

3. Программа написана в приемлемом стиле.

4. Текст программы напечатан с правильными сдвигами, так что раз-

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

для предложения DO легко найти предложение, заканчивающее группу, без

труда устанавливается соответствие между конструкциями THEN и ELSE и

т. д.).

5. Каждый модуль имеет ровно один вход и один выход. Отметим, что

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

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

6. Текст программы физически разбит на части, чтобы облегчить чтение.

Выполняемые предложения каждого модуля должны умещаться на одной

странице печатающего устройства.

7. Программа представляет собой простое и ясное решение задачи.

Эти семь требований четко выражают цели структурного программиро-

вания: писать программы минимальной сложности, заставить программиста

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

Конструкции структурного программирования

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

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

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

конструкции ВЫБОР (CASE).

Относительно этих трех строительных блоков необходимо прежде всего

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

жать развилку, за которой идет цикл ПОКА, а цикл ПОКА может содержать

другой цикл ПОКА. Прямоугольник может представлять также любой от-

дельный “последовательный” оператор (например, оператор присваивания).

Пошаговая детализация

Структурное программирование до сих пор было у нас представлено как

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

еще один ключевой элемент — методологию, или особенности мыслительно-

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

турной программы. Этот мыслительный процесс, который мы будем сейчас

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

предложен Дейкстрой, а затем улучшен Виртом.

Пошаговая детализация представляет собой простой процесс, предпола-

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

ского языка “очень высокого уровня” с последующей детализацией каждого

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

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

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

ми структурного программирования.

Защитное программирование

Концепции обнаружения ошибок можно применять также на уровне от-

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

мированием. Защитное программирование напоминает поведение осторожно-

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

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

рием относиться к действиям других модулей).

Защитное программирование основано на важной предпосылке: худшее,

что может сделать модуль,— это принять неправильные входные данные и за-

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

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

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

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

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

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

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

Защитное программирование требует разумного подхода, ибо, доведен-

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

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

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

влияние на надежность (а также на эффективность) будет не позитивным, а

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

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

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

сделать. Для каждой из них оцените ее сложность, вероятность того, что

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

ки. После этого остается принять трудное компромиссное решение по опре-

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

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

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

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

ности его внутренней логики. Здесь рассматривается проверка правильности

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

ной.

Задания

Напишите проекты для следующих модулей.

1. Решение квадратного уравнения.

2. Площадь треугольника.

3. Интерполяционный полином Лагранжа.

4. Сортировка списка.

5. Интегрирование функции.

6. Редактор строки.

7. Сумма ряда.

Лабораторная работа № 5.

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

Цель работы: Закрепление знаний по теме “Тестирование программного

обеспечения” и приобретение навыков по разработке ПО для тестирования

модулей.

В данной работе используются результаты предыдущих лабораторных

работ.

Самостоятельная работа студента под контролем преподавателя. Сту-

денты пишут тесты для проверки правильности терминального модуля и

драйвер для тестирования модуля.

Форма отчетности: Разработанное программное обеспечение для тести-

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

Прежде чем перейти к техническим аспектам тестирования программно-

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

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

принципами тестирования.

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

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

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

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

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

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

не найденные ошибки.

Одна из самых сложных проблем при тестировании — решить, когда

нужно закончить. Как уже говорилось, исчерпывающее тестирование (т. е.

испытание всех входных значений) невозможно. Таким образом, при тести-

ровании мы сталкиваемся с экономической проблемой: как выбрать конечное

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

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

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

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

ми. Эта проблема обсуждается подробнее далее.

Невозможно тестировать свою собственную программу. Ни один про-

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

относится ко всем формам тестирования, как к тестированию системы, так и

к тестированию внешних функций и даже отдельных модулей. Многие из ле-

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

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

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

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

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

кий график) на отдельного программиста или весь коллектив разработчиков

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

ватное тестирование. Более того, если модуль содержит дефекты вследствие

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

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

рует спецификации) и при подготовке тестов. Все ошибки в его понимании

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

Необходимая часть всякого теста — описание ожидаемых выходных

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

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

до его выполнения. Ожидаемые результаты нужно определять заранее, что-

бы не возникла ситуация, когда “глаз видит то, что хочет увидеть”. Чтобы

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

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

автоматически сверять ожидаемые и фактические результаты.

Хотя эта аксиома чрезвычайно важна, иногда, например при тестирова-

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

ключения. Математическое программное обеспечение обладает тем свойством,

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

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

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

связанных с конечной точностью машинной арифметики и неточного пред-

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

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

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

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

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

входных данных, аппроксимирующего реальные входные данные. Поэтому

при тестировании математического программного обеспечения прогнозиро-

вание точных выходных данных затруднительно.

Следует Избегть невоспроизводимых тестов, не тестировать их “с ле-

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

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

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

или в виде файла тестовых данных. В условиях диалога программист слиш-

ком часто выполняет тестирование “с лету”, т. е., сидя за терминалом, задает

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