ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 20.11.2019
Просмотров: 9516
Скачиваний: 184
методы
эквивалентного
разбиения
и
граничных
значений
(
см
. § 9.4).
Обнаружить
и
устранить
ошибки
перезаписи
можно
только
,
если
пользователь
вводит
избыточные
данные
,
например
контрольные
суммы
.
Если
ввод
избыточных
данных
по
каким
-
либо
причинам
нежелателен
,
то
следует
по
возможности
проверять
вводимые
данные
,
хотя
бы
контролировать
интервалы
возможных
значений
,
которые
обычно
определены
в
техническом
задании
,
и
выводить
введенные
данные
для
проверки
пользователю
.
Неверные
данные
обычно
может
обнаружить
только
пользователь
.
Проверка
допустимости
промежуточных
результатов
.
Проверки
промежуточных
результатов
позволяют
снизить
вероятность
позднего
проявления
не
только
ошибок
неверного
определения
данных
,
но
и
некоторых
ошибок
кодирования
и
проектирования
.
Для
того
чтобы
такая
проверка
была
возможной
,
необходимо
,
чтобы
в
программе
использовались
переменные
,
для
которых
существуют
ограничения
любого
происхождения
,
например
,
связанные
с
сущностью
моделируемых
процессов
.
Однако
следует
также
иметь
в
виду
,
что
любые
дополнительные
операции
в
программе
требуют
использования
дополнительных
ресурсов
(
времени
,
памяти
и
т
.
п
.)
и
могут
также
содержать
ошибки
.
Поэтому
имеет
смысл
проверять
не
все
промежуточные
результаты
,
а
только
те
,
проверка
которых
целесообразна
,
т
.
е
.
возможно
позволит
обнаружить
ошибку
,
и
не
сложна
.
Например
:
•
если
каким
-
либо
образом
вычисляется
индекс
элемента
массива
,
то
следует
проверить
,
что
этот
индекс
является
допустимым
;
•
если
строится
цикл
,
количество
повторений
которого
определяется
значением
переменной
,
то
целесообразно
убедиться
,
что
значение
этой
переменной
не
отрицательно
;
•
если
определяется
вероятность
какого
-
либо
события
,
то
целесообразно
проверить
,
что
полученное
значение
не
более
1.
а
сумма
вероятностей
всех
возможных
независимых
событий
равна
1
и
т
.
д
.
Предотвращение
накопления
погрешностей
.
Чтобы
снизить
погрешности
результатов
вычислений
,
необходимо
соблюдать
следующие
рекомендации
:
•
избегать
вычитания
близких
чисел
(
машинный
ноль
);
•
избегать
деления
больших
чисел
на
малые
;
•
сложение
длинной
последовательности
чисел
начинать
с
меньших
по
абсолютной
величине
;
•
стремиться
по
возможности
уменьшать
количество
операций
;
•
использовать
методы
с
известными
оценками
погрешностей
;
•
не
использовать
условие
равенства
вещественных
чисел
;
•
вычисления
производить
с
двойной
точностью
,
а
результат
выдавать
с
одинарной
.
Обработка
исключений
.
Поскольку
полный
контроль
данных
на
входе
и
в
процессе
вычислений
,
как
правило
,
невозможен
,
следует
предусматривать
перехват
обработки
аварийных
ситуаций
.
Для
перехвата
и
обработки
аппаратно
и
программно
фиксируемых
o
шибок
в
некоторых
языках
программирования
,
например
, Delphi Pascal, C++ Java,
предусмотрены
средства
обработки
исключений
.
Использование
эти
средств
позволяет
не
допустить
выдачи
пользователю
сообщения
об
аварийном
завершении
программы
,
ничего
ему
не
говорящего
.
Вместо
этого
программист
получает
возможность
предусмотреть
действия
,
которые
позволяют
исправить
эту
ошибку
или
,
если
это
невозможно
,
выдать
пользователю
сообщение
с
точным
описанием
ситуации
и
продолжить
работу
.
2.8.
Сквозной
структурный
контроль
Сквозной
структурный
контроль
представляет
собой
совокупность
технологических
операций
контроля
,
позволяющих
обеспечить
как
можно
более
раннее
обнаружение
ошибок
в
процессе
разработки
.
Термин
«
сквозной
в
названии
отражает
выполнение
контроля
на
всех
этапах
разработки
.
Термин
«
структурный
»
означает
наличие
четких
рекомендаций
по
выполнена
контролирующих
операций
на
каждом
этапе
.
Сквозной
структурный
контроль
должен
выполняться
на
специальных
контрольных
сессиях
,
в
которых
,
помимо
разработчиков
,
могут
участвовал
специально
приглашенные
эксперты
.
Время
между
сессиями
определяет
объем
материала
,
который
выносится
на
сессию
:
при
частых
сессиях
матер
!
ал
рассматривают
небольшими
порциями
,
при
редких
-
существенным
фрагментами
.
Материалы
для
очередной
сессии
должны
выдаваться
участникам
заранее
,
чтобы
они
могли
их
обдумать
.
Одна
из
первых
сессий
должна
быть
организована
на
этапе
определения
спецификаций
.
На
этой
сессии
проверяют
полноту
и
точность
спецификаций
,
при
этом
целесообразно
присутствие
заказчика
или
специалиста
по
предметной
области
,
которые
смогут
определить
,
насколько
правильно
полно
определены
спецификации
программного
обеспечения
.
На
этапе
проектирования
вручную
по
частям
проверяют
алгоритмы
разрабатываемого
программного
обеспечения
на
конкретных
наборах
данных
и
сверяют
полученные
результаты
с
соответствующими
спецификациями
.
Основная
задача
-
убедиться
в
правильности
понимания
спецификаций
и
проанализировать
достоинства
и
недостатки
концептуальных
решений
,
закла
-
дываемых
в
проект
.
На
этапе
реализации
проверяют
план
(
последовательность
)
реализации
модулей
,
набор
тестов
,
а
также
тексты
отдельных
модулей
.
Для
всех
этапов
целесообразно
иметь
списки
наиболее
часто
встречающихся
ошибок
,
которые
формируют
по
литературным
источникам
и
исходя
из
опыта
предыдущих
разработок
.
Такие
списки
позволяют
сконцентрировать
усилия
на
конкретных
моментах
,
а
не
проверять
все
подряд
.
При
этом
все
найденные
ошибки
фиксируют
в
специальном
документе
,
но
не
исправляют
их
(
более
подробно
см
. § 9.2).
Помимо
раннего
обнаружения
ошибок
,
сквозной
структурный
контроль
обеспечивает
своевременную
подготовку
качественной
документации
по
проекту
.
Контрольные
вопросы
и
задания
1.
Что
понимают
под
технологичностью
программного
обеспечения
?
Почему
?
2.
Дайте
определение
модуля
.
Чем
вызвано
изменение
этого
понятия
?
Как
изменились
требования
к
модулям
в
настоящее
время
и
почему
?
3.
Что
понимают
под
связностью
и
сцеплением
модулей
?
Какие
типы
связности
и
сцепления
считаются
допустимыми
и
почему
?
В
чем
особенность
библиотек
ресурсов
?
4.
Чем
нисходящий
подход
к
разработке
отличается
от
восходящего
?
Перечислите
достоинства
и
недостатки
этих
подходов
?
5.
Что
называют
структурным
программированием
и
почему
?
Назовите
основные
и
дополнительные
структуры
.
Объясните
,
в
чем
сложность
использования
схем
алгоритмов
при
проектировании
структурных
программ
?
Какие
способы
описания
структурных
алгоритмов
существуют
?
6.
Предложите
структурный
алгоритм
перевода
чисел
в
16-
ричную
систему
счисления
.
Опишите
его
с
использованием
схемы
алгоритма
,
псевдокода
,
диаграмм
Насси
-
Шнейдермана
и
flow-
форм
.
В
чем
,
по
вашему
,
основной
недостаток
двух
последних
нотаций
,
который
препятствует
их
широкому
применению
?
7.
Что
называют
«
хорошим
стилем
»
оформления
программ
и
почему
?
Реализуйте
решение
предыдущего
задания
на
любом
языке
программирования
.
Подумайте
,
как
следует
назвать
переменные
,
и
какие
комментарии
необходимы
.
8.
От
каких
ошибок
защищает
«
программирование
с
защитой
от
ошибок
»
и
почему
?
Что
понимают
под
термином
«
исключение
»?
В
каких
случаях
«
исключения
»
используют
?
9.
Почему
«
сквозной
структурный
контроль
»
так
назван
?
Что
значит
«
сквозной
»
контроль
?
В
чем
заключается
его
«
структурность
»?
3.
ОПРЕДЕЛЕНИЕ
ТРЕБОВАНИЙ
К
ПРОГРАММНОМУ
ОБЕСПЕЧЕНИЮ
И
ИСХОДНЫХ
ДАННЫХ
ДЛЯ
ЕГО
ПРОЕКТИРОВАНИЯ
Этап
постановки
задачи
-
один
из
наиболее
ответственных
этапов
создания
программного
продукта
.
На
этом
этапе
формулируют
основные
требования
к
разрабатываемому
программному
обеспечению
.
Оттого
,
насколько
полно
определены
функции
и
эксплуатационные
требования
,
насколько
правильно
приняты
принципиальные
решения
,
определяющие
процесс
проектирования
,
во
многом
зависит
стоимость
разработки
и
ее
качество
.
3.1.
Классификация
программных
продуктов
по
функциональному
признаку
Каждый
программный
продукт
предназначен
для
выполнения
определенных
функций
.
По
назначению
все
программные
продукты
можно
разделить
натри
группы
:
системные
,
прикладные
и
гибридные
(
рис
. 3.1).
К
с
и
с
т
е
м
н
ы
м
обычно
относят
программные
продукты
,
обеспечивающие
функционирование
вычислительных
систем
(
как
отдельных
компьютеров
,
так
и
сетей
).
Это
-
операционные
системы
,
оболочки
и
другие
служебные
программы
(
утилиты
).
Операционные
системы
,
как
правило
,
управляют
ресурсами
(
процессором
и
памятью
),
процессами
(
задачами
и
потоками
)
и
устройствами
.
Сложность
организации
операционных
систем
обуславливается
степенью
автоматизации
и
достигаемой
эффективности
процессов
управления
.
Так
мультипрограммные
операционные
системы
существенно
сложнее
однопрограммных
,
что
хорошо
видно
на
примере
MS DOS
и
WINDOWS.
Оболочки
(
например
, NORTON COMMANDER)
в
свое
время
появились
для
организации
более
удобного
интерфейса
пользователя
с
файловой
системой
MS DOS.
Современные
оболочки
,
такие
,
как
FAR,
используют
для
обеспечения
пользователю
привычной
среды
при
работе
с
файловой
системой
.
К
утилитам
принято
относить
программы
и
системы
,
непосредственно
не
входящие
в
состав
операционной
системы
,
но
обеспечивающие
выполнение
определенных
функций
,
таких
как
архивация
файлов
,
проверка
компьютера
на
заражение
вирусами
,
осуществление
удаленного
доступа
к
информации
и
др
.
П
р
и
к
л
а
д
н
ы
е
программы
и
системы
ориентированы
на
решение
конкретных
пользовательских
задач
.
Различают
пользователей
:
•
разработчиков
программ
;
•
непрограммистов
,
использующих
компьютерные
системы
для
достижения
своих
целей
.
Разработчики
программ
используют
специальные
инструментальные
средства
,
такие
как
компиляторы
,
компоновщики
,
отладчики
,
которые
последнее
время
обычно
интегрируют
в
системы
программирования
и
среды
разработки
.
Современные
среды
программирования
,
например
, Delphi, Visual C++,
реализуют
визуальную
технологию
разработки
программных
продуктов
и
предоставляют
программистам
огромные
библиотеки
компонентов
,
которые
можно
включать
в
свою
разработку
.
К
этой
же
группе
относят
инструментальные
комплексы
создания
баз
данных
,
такие
как
Access, FoxPro, Oracle,
средства
создания
интеллектуальных
систем
,
например
,
экспертных
,
обучающих
,
систем
контроля
знаний
и
т
.
д
.
Последнее
достижение
в
этом
направлении
- CASE-
средства
разработки
программного
обеспечения
,
такие
как
ERwin, BPwin,
Paradigm Plus, Rational Rose
и
др
.
Пользователи
-
непрограммисты
в
соответствии
с
современными
требованиями
не
должны
быть
профессионалами
в
проблемах
создания
программных
продуктов
и
специфике
их
взаимодействия
с
операционной
системой
,
Для
них
разрабатывают
специальные
программные
продукты
,
ориентированные
на
определенную
предметную
область
.
Такие
продукты
условно
можно
разделить
па
продукты
общего
назначения
,
профессиональные
среды
или
пакеты
,
обучающие
системы
,
развлекающие
программы
и
т
.
д
.
Продукты
общего
назначения
используют
разные
группы
пользователей
.
К
ним
можно
отнести
текстовые
редакторы
,
например
, WinWord,
электронные
таблицы
типа
Excel,
графические
редакторы
,
информационные
системы
общего
назначения
,
например
,
карта
Москвы
,
программы
-
переводчики
,
и
т
.
п
.
Профессиональные
продукты
предназначены
для
специалистов
в
различных
областях
,
например
,
к
ним
можно
отнести
:
•
системы
автоматизации
проектирования
,
ориентированные
на
различные
технические
области
;
•
системы
-
тренажеры
,
например
,
тренажер
для
отработки
действий
пилотов
в
аварийной
ситуации
;
•
бухгалтерские
системы
,
например
. 1C;
•
издательские
системы
,
например
, PageMaker, QuarkXpress;
•
профессиональные
графические
системы
,
например
, Adobe Illustrator, PhotoShop, CorelDraw
и
т
.
п
.;
•
экспертные
системы
и
т
.
д
.
Системы
автоматизации
производственных
процессов
отличаются
от
профессиональных
тем
,
что
они
ориентированы
на
пользователей
разных
профессий
,
связанных
единым
производственным
процессом
.
Обучающие
программы
и
системы
в
соответствии
со
своим
названием
предназначены
для
обучения
,
например
,
иностранным
языкам
,
правилам
дорожного
движения
и
т
.
п
.
К
развлекающим
относят
игровые
программы
,
музыкальные
программы
,
опять
же
информационные
системы
,
но
с
тестами
развлекающего
характера
,
например
гороскопы
и
т
.
п
.
Г
и
б
р
и
д
н
ы
е
системы
сочетают
в
себе
признаки
системного
и
прикладного
программного
обеспечения
.
Как
правило
,
это
большие
,
но
узкоспециализированные
системы
,
предназначенные
для
управления
технологическими
процессами
различных
типов
в
режиме
реального
времени
.
Для
повышения
надежности
и
снижения
времени
обработки
в
такие
системы
обычно
включают
программы
,
обеспечивающие
выполнение
функций
операционных
систем
.
К
каждому
из
перечисленных
выше
типов
программного
обеспечения
при
разработке
,
помимо
функциональных
,
обычно
предъявляют
еще
и
определенные
эксплуатационные
требования
.
3.2.
Основные
эксплуатационные
требования
к
программным
продуктам
Как
уже
упоминалось
в
§ 1.4,
эксплуатационные
требования
определяют
некоторые
характеристики
разрабатываемого
программного
обеспечения
,
проявляемые
в
процессе
его
функционирования
.
К
таким
характеристикам
относят
:
•
правильность
-
функционирование
в
соответствии
с
техническим
заданием
;
•
универсальность
-
обеспечение
правильной
работы
при
любых
допустимых
данных
и
защиты
от
неправильных
данных
;
•
надежность
(
помехозащищенность
) -
обеспечение
полной
повторяемости
результатов
,
т
.
е
.
обеспечение
их
правильности
при
наличии
различного
рода
сбоев
;
•
проверяем
ость
-
возможность
проверки
получаемых
результатов
;
•
точность
результатов
-
обеспечение
погрешности
результатов
не
выше
заданной
;
•
защищенность
-
обеспечение
конфиденциальности
информации
;
•
программная
совместимость
-
возможность
совместного
функционирования
с
другим
программным
обеспечением
;
•
аппаратная
совместимость
-
возможность
совместного
функционирования
с
некоторым
оборудованием
;
•
эффективность
-
использование
минимально
возможного
количества
ресурсов
технических
средств
,
например
,
времени
микропроцессора
или
объема
оперативной
памяти
;
•
адаптируемость
-
возможность
быстрой
модификации
с
целью
приспособления
к
изменяющимся
условиям
функционирования
;
•
повторная
входимость
-
возможность
повторного
выполнения
без
перезагрузки
с
диска
;
•
реентерабельность
-
возможность
«
параллельного
»
использования
несколькими
процессами
.
Правильность
является
обязательным
требованием
для
любого
программного
обеспечения
:
все
,
что
указано
в
техническом
задании
,
непременно
должно
быть
реализовано
.
Однако
следует
понимать
,
что
ни
тестирование
(
см
.
гл
. 9),
ни
верификация
не
доказывают
правильности
созданного
программного
продукта
.
В
этой
связи
обычно
говорят
об
определенной
вероятности
наличия
ошибок
.
Естественно
,
чем
большая
ответственность
перекладывается
на
компьютерную
систему
,
тем
меньше
должна
быть
вероятность
как
программного
,
так
и
аппаратного
сбоя
.
Например
,
очевидно
,
что
вероятность
неправильной
работы
для
системы
управления
атомной
электростанцией
должна
быть
близка
к
нулю
.
Требование
универсальности
также
обычно
входит
в
группу
обязательных
.
Ничего
хорошего
нет
в
том
,
что
разработанная
система
выдает
результат
для
некорректных
данных
или
аварийно
завершает
свою
работу
на
некоторых
наборах
данных
.
Однако
,
как
уже
упоминалось
выше
,
доказать
универсальность
сравнительно
сложной
программы
,
так
же
,
как
ее
правильность
,
невозможно
,
поэтому
имеет
смысл
говорить
о
степени
универсальности
программы
.
Практически
,
чем
выше
требования
к
правильности
и
универсальности
программного
обеспечения
,
тем
выше
и
требования
к
его
надежности
.
Источниками
помех
могут
являться
все
участники
вычислительного
процесса
:
технические
средства
,
программные
средства
и
люди
.
Технические
средства
подвержены
сбоям
,
например
,
из
-
за
резких
скачков
напряжения
питания
или
помех
при
передаче
информации
по
сетям
.
Программное
обеспечение
может
содержать
ошибки
.
А
люди
могут
ошибаться
при
вводе
исходных
данных
.
Современные
вычислительные
устройства
уже
достаточно
надежны
.
Сбои
технических
средств
,
как
правило
,
регистрируются
аппаратно
,
соответственно
результаты
вычислений
в
этом
случае
восстанавливаются
.
В
случае
длительных
вычислений
,
как
правило
,
промежуточные
результаты
сохраняют
(
прием
получил
название
«
создание
контрольных
точек
»),
что
позволяет