ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 20.11.2019
Просмотров: 9518
Скачиваний: 184
3.
В
каких
случаях
целесообразно
использовать
диаграммы
переходов
состояний
?
Разработайте
диаграмму
переходов
для
калькулятора
,
техническое
задание
на
который
составлялось
вами
в
соответствии
заданием
к
предыдущей
главе
.
4.
В
чем
заключается
основное
различие
между
функциональными
диаграммами
и
диаграммами
потоков
данных
?
Постройте
оба
вида
диаграмм
для
выполнения
вычислений
с
использованием
внутренней
памяти
калькулятора
.
Проанализируйте
сходство
и
различие
.
В
каких
случаях
использование
диаграмм
потоков
данных
является
предпочтительным
?
5.
Что
называют
«
структурами
данных
»?
Какие
данные
имеются
в
виду
?
В
каких
случаях
структуры
данных
необходимо
описывать
?
Какие
модели
используют
для
описания
структур
данных
?
6.
Опишите
стек
и
очередь
с
использованием
предлагаемых
моделей
описания
данных
.
Какие
аспекты
этих
структур
остались
не
описанными
и
почему
?
7.
В
каких
случаях
используют
математические
модели
?
Что
понимают
под
адекватностью
модели
?
Зачем
необходимо
выполнять
доказательство
адекватности
и
как
строятся
подобные
доказательства
?
5.
ПРОЕКТИРОВАНИЕ
ПРОГРАММНОГО
ОБЕСПЕЧЕНИЯ
ПРИ
СТРУКТУРНОМ
ПОДХОДЕ
Как
уже
упоминалось
ранее
,
сущность
структурного
подхода
заключается
в
декомпозиции
программы
или
программной
системы
по
функциональному
принципу
.
Все
предлагаемые
методы
декомпозиции
используют
интерфейсы
простейшего
типа
:
примитивные
интерфейсы
и
традиционные
меню
,
и
рассчитаны
на
анализ
и
проектирование
как
структур
данных
,
так
и
обрабатывающих
их
программ
.
Причем
в
большинстве
случаев
первичным
считают
проектирование
обрабатывающих
компонентов
,
проектирование
же
структур
данных
выполняют
параллельно
.
Существует
и
альтернативный
подход
,
при
котором
первичным
считают
проектирование
данных
,
а
обрабатывающие
программы
получают
,
анализируя
полученные
структуры
данных
.
В
любом
случае
проектирование
программного
обеспечения
начинают
с
определения
его
структуры
.
5.1.
Разработка
структурной
и
функциональной
схем
Процесс
проектирования
сложного
программного
обеспечения
начинают
с
уточнения
его
структуры
,
т
.
е
.
определения
структурных
компонентов
и
связей
между
ними
.
Результат
уточнения
структуры
может
быть
представлен
в
виде
структурной
и
/
или
функциональной
схем
и
описания
(
спецификаций
)
компонентов
.
Структурная
схема
разрабатываемого
программного
обеспечения
.
Структурной
называют
схему
,
отражающую
состав
и
взаимодействие
по
управлению
частей
разрабатываемого
программного
обеспечения
.
Структурные
схемы
п
а
к
е
т
о
в
п
р
о
г
р
а
м
м
не
информативны
,
поскольку
организация
программ
в
пакеты
не
предусматривает
передачи
управления
между
ними
.
Поэтому
структурные
схемы
разрабатывают
для
каждой
программы
пакета
,
а
список
программ
пакета
определяют
,
анализируя
функции
,
указанные
в
техническом
задании
.
Самый
простой
вид
программного
обеспечения
-
программа
,
которая
в
качестве
структурных
компонентов
может
включать
только
подпрограммы
и
библиотеки
ресурсов
.
Разработку
структурной
схемы
программы
обычно
выполняют
методом
пошаговой
детализации
(
см
. § S.2).
Структурными
компонентами
программной
системы
или
программного
комплекса
могут
служить
программы
,
подсистемы
,
базы
данных
,
библиотеки
ресурсов
и
т
.
п
.
Структурная
схема
п
р
о
г
р
а
м
м
н
о
г
о
к
о
м
п
л
е
к
с
а
демонстрирует
передачу
управления
от
программы
-
диспетчера
соответствующей
программе
(
рис
. 5.1).
Структурная
схема
п
р
о
г
р
а
м
м
н
о
й
с
и
с
т
е
м
ы
,
как
правило
,
показывает
наличие
подсистем
или
других
структурных
компонентов
.
В
отличие
от
программного
комплекса
отдельные
части
(
подсистемы
)
программной
системы
интенсивно
обмениваются
данными
между
собой
и
,
возможно
,
с
основной
программой
.
Структурная
же
схема
программной
системы
этого
обычно
не
показывает
(
рис
. 5.2).
Более
полное
представление
о
проектируемом
программном
обеспечении
с
точки
зрения
взаимодействия
его
компонентов
между
собой
и
с
внешней
средой
дает
функциональная
схема
.
Функциональная
схема
.
Функциональная
схема
или
схема
данных
(
ГОСТ
19.701-90) -
схема
взаимодействия
компонентов
программного
обеспечения
с
описанием
информационных
потоков
,
состава
данных
в
потоках
и
указанием
используемых
файлов
и
устройств
.
Для
изображения
функциональных
схем
используют
специальные
обозначения
,
установленные
стандартом
.
Основные
обозначения
схем
данных
по
ГОСТ
19.701-90
приведены
в
табл
. 5.1.
Функциональные
схемы
,
более
информативны
,
чем
структурные
.
На
рис
. 5.3
для
сравнения
приведены
функциональные
схемы
программных
комплексов
и
систем
.
Все
компоненты
структурных
и
функциональных
схем
должны
быть
описаны
.
При
структурном
подходе
особенно
тщательно
необходимо
прорабатывать
спецификации
межпрограммных
интерфейсов
,
так
как
от
качества
их
описания
зависит
количество
самых
дорогостоящих
ошибок
.
К
самым
дорогим
относятся
ошибки
,
обнаруживаемые
при
комплексном
тестировании
,
так
как
для
их
устранения
могут
потребоваться
серьезные
изменения
уже
от
-
лаженных
текстов
.
5.2.
Использование
метода
пошаговой
детализации
для
проектирования
структуры
программного
обеспечения
Структурный
подход
к
программированию
в
том
виде
,
в
котором
он
был
сформулирован
в
70-
х
годах
XX
в
.,
предлагал
осуществлять
декомпозицию
программ
методом
пошаговой
детализации
.
Результатом
декомпозиции
является
структурная
схема
программы
,
которая
представляет
собой
многоуровневую
иерархическую
схему
взаимодействия
подпрограмм
по
управлению
.
Минимально
такая
схема
отображает
два
уровня
иерархии
,
т
.
е
.
показывает
общую
структуру
программы
.
Однако
тот
же
метод
позволяет
получить
структурные
схемы
с
большим
количеством
уровней
.
Метод
пошаговой
детализации
(
см
. § 1.3)
реализует
нисходящий
подход
(
см
. § 2.3)
и
базируется
на
основных
конструкциях
структурного
программирования
(
см
. § 2.4).
Он
предполагает
пошаговую
разработку
алгоритма
.
Каждый
шаг
при
этом
включает
разложение
функции
на
подфункции
.
Так
на
первом
этапе
описывают
решение
поставленной
задачи
,
выделяя
общие
подзадачи
,
на
следующем
аналогично
описывают
решение
подзадач
,
формулируя
при
этом
подзадачи
следующего
уровня
.
Таким
образом
,
на
каждом
шаге
происходит
уточнение
функций
проектируемого
программного
обеспечения
.
Процесс
продолжают
,
пока
не
доходят
до
подзадач
,
алгоритмы
решения
которых
очевидны
.
Декомпозируя
программу
методом
пошаговой
детализации
,
следует
придерживаться
о
с
н
о
в
н
о
г
о
п
р
а
в
и
л
а
структурной
декомпозиции
,
следующего
из
принципа
вертикального
управления
:
в
первую
очередь
детализировать
управляющие
процессы
декомпозируемого
компонента
,
оставляя
уточнение
операций
с
данными
напоследок
.
Это
связано
с
тем
,
что
приори
-
тетная
детализация
управляющих
процессов
существенно
упрощает
структуру
компонентов
всех
уровней
иерархии
и
позволяет
не
отделять
процесс
принятия
решения
от
его
выполнения
:
так
,
определив
условие
выбора
некоторой
альтернативы
, -
сразу
же
вызывают
модуль
,
ее
реализующий
.
Детализация
операций
со
структурами
в
последнюю
очередь
позволит
отложить
уточнение
их
спецификаций
и
обеспечит
возможность
относительно
безболезненной
модификации
этих
структур
за
счет
сокращения
количества
модулей
,
зависящих
от
этих
данных
.
Кроме
этого
,
целесообразно
.
Придерживаться
следующих
рекомендаций
:
•
не
отделять
операции
инициализации
и
завершения
от
соответствующей
обработки
,
так
как
модули
инициализации
и
завершения
имеют
плохую
связность
(
временную
)
и
сильное
сцепление
(
по
управлению
);
•
не
проектировать
слишком
специализированных
или
слишком
универсальных
модулей
,
так
как
проектирование
излишне
специальных
модулей
увеличивает
их
количество
,
а
проектирование
излишне
универсальных
модулей
повышает
их
сложность
;
•
избегать
дублирования
действий
в
различных
модулях
,
так
как
при
их
изменении
исправления
придется
вносить
во
все
фрагменты
программы
,
где
они
выполняются
-
в
этом
случае
целесообразно
просто
реализовать
эти
действия
в
отдельном
модуле
;
•
группировать
сообщения
об
ошибках
в
один
модуль
по
типу
библиотеки
ресурсов
,
тогда
будет
легче
согласовать
формулировки
,
избежать
дублирования
сообщений
,
а
также
перевести
сообщения
на
другой
язык
.
При
этом
,
описывая
решение
каждой
задачи
,
желательно
использовать
не
более
1—2-
х
структурных
управляющих
конструкций
,
таких
,
как
цикл
-
пока
или
ветвление
,
что
позволяет
четче
представить
себе
структуру
организуемого
вычислительного
процесса
.
Пример
5.1.
Разработать
алгоритм
программы
построения
графиков
функций
одной
переменной
на
заданном
интервале
изменения
аргумента
[
]
2
1
,
x
x
при
условии
непрерывности
функции
на
всем
интервале
определения
.
Примечание
.
Для
того
чтобы
программировать
построение
графиков
функций
с
точками
разрыва
первого
и
второго
рода
,
необходимо
аналитически
исследовать
заданные
функции
,
что