ВУЗ: Томский государственный университет систем управления и радиоэлектроники
Категория: Учебное пособие
Дисциплина: Проектирование информационных систем
Добавлен: 21.10.2018
Просмотров: 16933
Скачиваний: 11
51
DRIVER: procedure;
Выполнить задачу A;
do while (
условие истинно);
Выполнить задачу B;
end;
Выполнить задачу C;
end DRIVER;
Затем
более
подробно
представляются
каждый
из
опера-
торов
псевдокода
и
разрабатываются
другие
модули.
Например,
если
задачи
A,
B,
C
достаточно
сложны,
их
можно
оформить
как
отдельные
процедуры.
В
этом
случае
проект
драйвера
мож-
но
представить
следующим
образом:
DRIVER: procedure;
Инициировать задачу A;
call A;
do while (
условие истинно);
Инициировать задачу B;
call B;
end;
Инициировать задачу C;
call C;
end DRIVER;
Затем,
таким
же
образом,
можно
определить
процедуры
A,
B
и
C.
Очевидно,
что
язык
PDL
хорошо
подходит
для
нис-
ходящего
проектирования.
Нисходящее
проектирование
также
называют
пошаговым
совершенствованием:
программы
иерархически
структуриру-
ются
и
разбиваются
путем
последовательного
уточнения.
На
каждом
шаге
функционирование
модуля
описывается
с
помо-
щью
ссылок
на
предыдущие
более
подробные
шаги.
При
восходящем
проектировании
вначале
проектируются
программы
нижнего
уровня.
Обычно
такой
подход
использует-
ся
при
проектировании
операционных
систем,
где
самым
ниж-
ним
уровнем
иерархии
являются
аппаратные
средства
(техноло-
гия
виртуальных
машин).
Например,
один
из
модулей
может
обеспечить
доступ
к
аппаратным
средствам
страничного
меха-
52
низма
ЭВМ
и
предоставить
виртуальную
память
для
всех
ос-
тальных
модулей.
Вследствие
этого
большинство
систем
реаль-
ного
времени
проектируется
снизу
вверх.
На
этапах
кодирования
и
тестирования
ситуация
проти-
воположная.
Хотя
большинство
систем
проектируется
сверху
вниз,
кодирование
и
тестирование
удобнее
осуществлять
снизу
вверх,
так
как
модули
ААА
и
ААВ
не
вызывают
других
компо-
нент,
их
кодируют
и
тестируют
(рис.
4.3).
Рис.
4.3
—
Восходящее
кодирование
и
тестирование
Когда
задача
хорошо
определена,
пользоваться
этим
под-
ходом
очень
удобно.
Однако
если
решаемая
задача
не
понятна
или
детально
не
определена,
то
тестирование
снизу
вверх
может
вызвать
серьез-
ные
проблемы.
Например,
пользователь
не
может
убедиться
в
правильности
функционирования
системы
согласно
специфика-
циям,
пока
не
будет
проверен
модуль
верхнего
уровня.
Однако
этого
нельзя
сделать
до
тех
пор,
пока
не
будет
проверена
вся
иерархическая
структура
системы,
т.е.
до
завершения
проекта.
А
внесение
изменений
на
этом
этапе
сопряжено
со
значитель-
ными
затратами
и
обходится
дорого.
Чтобы
избежать
этого,
можно
использовать
нисходящее
кодирование.
В
этом
случае
в
первую
очередь
проверяют
моду-
ли
управляющей
программы,
а
также
модули
A,
B,
C.
Пользо-
ватель
системы
проверяет
функционирование
верхнего
уровня
DRIVER
AAA
AAB
AA
AC
AB
A
B
C
53
на
начальном
этапе
разработки,
поэтому
сделать
любые
необ-
ходимые
изменения
в
спецификациях
гораздо
легче.
Единственное
неудобство
при
таком
методе
кодирования
заключается
в
том,
что
для
проверки
модулей
A,
B,
C
требуют-
ся
также
модули
АА,
АВ,
АС,
ВА,
ВВ
и
СА.
Для
этих
целей
служат
подыгрывающие
программы
—
заглушки.
Это
короткие
программы,
которые
составляются
специально
для
того,
чтобы
моделировать
ненаписанные
модули
и
передавать
управляю-
щим
программам
необходимые
тестовые
данные
(рис.
4.4).
Рис.
4.4
—
Нисходящее
тестирование
Подобные
средства
оказываются
полезными,
если
ими
пользоваться
достаточно
осторожно,
так
как
корректность
сис-
темы
не
может
быть
доказана,
пока
не
убрана
последняя
за-
глушка.
Нисходящее
проектирование
не
так
просто,
как
это
ка-
жется
на
первый
взгляд.
Это
связано
с
тем,
что
в
любой
про-
граммной
системе
имеется
три
вершины:
1)
начало
работ;
2)
управляющая
программа;
3)
программа
связи
пользователя
с
системой.
Основные
различия
между
этими
моментами
можно
пока-
зать
на
примере
компилятора.
Для
разработчика
аппаратных
средств
«вершиной»
системы
является
модуль,
инициирующий
работу
системы.
Этот
модуль
—
основное
средство
интерфейса
с
операционной
системой.
С
его
помощью
с
диска
считываются
фрагменты
программы,
реализующие
различные
этапы
компи-
лирования,
и
передается
управление
на
их
выполнение.
Все
ос-
DRIVER
AA
STUB
AC
STUB
AB
STUB
A
BA
STUB
BB
STUB
B
CA
STUB
C
54
тальные
части
системы
можно
рассматривать
как
подпрограм-
мы
этого
модуля.
Для
системного
программиста
«вершиной»
является
управляющая
программа.
В
компиляторе
«вершиной»
можно
считать
основной
цикл
анализа,
который
осуществляет
поиск
очередного
анализируемого
оператора
(лексемы).
Таким
обра-
зом,
логической
вершиной
является
цикл
вида:
do while
(
продолжить до конца
компилирования);
Чтение до начала следующего оператора;
Анализ введенного оператор;
end
;
Что
касается
пользователя,
то,
с
его
точки
зрения,
компи-
лятор
читает
операторы,
а
затем
их
транслирует.
Таким
обра-
зом,
для
него
«вершиной»
является
программа
ввода
данных.
От
искусства
и
квалификации
программиста
зависит
пра-
вильный
выбор
вершины
для
всей
системы.
Однако
для
при-
кладных
программ
всегда
целесообразно
«вершиной»
считать
управляющую
программу.
При
нисходящей
разработке
пользователь
видит
взаимо-
действие
верхних
уровней
системы
на
начальных
этапах.
Изме-
нения
в
этот
период
можно
вносить
относительно
легко.
Таки-
ми
же
свойствами
обладает
и
метод
последовательной
моди-
фикации
(модернизации).
При
использовании
этого
метода
вна-
чале
проектируется
и
реализуется
некоторый
вариант
системы.
Пользователь
очень
быстро
получает
работающую
систему.
Процесс
модернизации
с
последующим
расширением
функций
системы
продолжается
до
тех
пор,
пока
не
будет
получена
окончательная
версия.
4.2.2 Структурное проектирование
Одним
из
эффективных
методов
разработки
программ
яв-
ляется
метод
пошагового
совершенствования.
Использование
PDL
хорошо
согласуется
с
этим
методом.
Программист
обду-
мывает
проект
задачи
все
более
детально,
причем
каждый
шаг
является
«интеллектуально
управляемой»
компонентой
задачи.
55
Вначале
программист
представляет
задачу
как
набор
за-
дач:
do
task A;
do
task B;
do
task C;
Каждая
из
задач
определяется
и
детализируется
с
помо-
щью
спецификаций.
Каждую
небольшую
задачу
можно
пред-
ставить
в
виде
нескольких
предложений
PDL,
входящих
в
не-
которую
процедуру.
Если
задача
сложная,
ее
можно
предста-
вить
как
отдельную
процедуру.
При
детализации
каждой
задачи
можно
пользоваться
только
операторами
PDL.
Выбор
операторов
этого
языка
не
случаен
—
они
обеспечивают
управляемые
конструкции
проек-
тируемых
программ.
При
этом
программы
рассматриваются
как
функции.
Любой
оператор
можно
представить
в
виде
y = f(x).
(В
задачах
со
многими
переменными
x
и
y
—
векторы
с
соответст-
вующим
числом
компонент.)
Таким
образом,
оператор
при-
своения
А = В + С·D
можно
представить
в
виде
F(X, Y, Z) = X + Y·Z
и
заменить
его
следующим
оператором:
A = F(X, Y, Z).
Аналогичным
образом
можно
представить
оператор
лю-
бой
степени
сложности.
Таким
образом,
каждую
программу
можно
записать
как
функцию,
преобразующую
входные
пере-
менные
в
выходные.
Для
формализации
процесса
нисходящей
разработки
вво-
дится
понятие
«
простая
программа».
Простая
программа
опре-
деляется
как
программа,
которую
можно
представить
в
виде
структурной
схемы
со
следующими
свойствами:
1)
существуют
только
одна
входная
и
одна
выходная
ду-
ги;
2)
для
каждого
узла
существует
путь
от
входной
дуги
че-
рез
этот
узел
к
выходной
дуге
(рис.
4.5,
4.6).