Структурное проектирование программ

В этом методе разбиение сложной системы на несколько подсистем получило название «разделяй и властвуй» (divide et impera), иерархическая или функциональная декомпозиция и др. При этом базовыми принципами являются:

a) «разделяй и властвуй»;

b) Проектирование «сверху вниз» - от общей постановки задачи к отдельным подзадачам и т.д.;

c) принцип иерархического упорядочения, который предполагает объединение со ставных частей системы в иерархические древовидные структуры с добавлением новых деталей на каждом уровне.

Процесс проектирования сложного программного обеспечения начинают с уточнения его структуры, т. е. определения структурных компонентов и связей между ними. Результат уточнения структуры может быть представлен в виде структурной и/или функциональной схем и описания (спецификаций) компонентов.

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

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

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

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

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

Так схема программного комплекса демонстрирует передачу управления от программы-диспетчера соответствующей программе (рис. 4.1).

Рис. 4.1. Пример структурной схемы программного комплекса.

Структурная схема программной системы, как правило, показывает наличие подсистем или других структурных компонентов. В отличие от комплекса отдельные части (подсистемы) программной системы интенсивно обмениваются данными между собой и, возможно, с основной программой. Структурная же схема программной системы этого обычно не показывает (рис. 4.2).

Рис. 4.2

Обычно она представляет собой многоуровневую иерархическую схему взаимодействия подпрограмм по управлению. На начальном этапе схема отображает два уровня иерархии, т. е. показывает общую структуру программы. Однако тот же метод позволяет получить структурные схемы с большим количеством уровней.

Метод пошаговой детализации реализует нисходящий подход и базируется на основных конструкциях структурного программирования. Он предполагает пошаговую разработку алгоритма, как показано на рисунке 4.3. Каждый шаг при этом включает разложение функции на подфункции. Так на первом этапе описывают решение поставленной задачи, выделяя общие подзадачи. На следующем аналогично описывают подзадачи, формулируя при этом элементы следующего уровня. Таким образом, на каждом шаге происходит уточнение функций проектируемого программного обеспечения. Процесс продолжают, пока не доходят до подзадач, алгоритмы, решения которых очевидны.

Рис. 4.3

При этом необходимо в первую очередь детализировать управляющие процессы, оставляя уточнение операций с данными напоследок. Это связано с тем, что приоритетная детализация управляющих процессов существенно упрощает структуру компонентов всех уровней иерархии и позволяет не отделять процесс принятия решения от его выполнения. Определив условие выбора некоторой альтернативы, сразу же вызывают модуль, ее реализующий.

Функциональная схема или схема данных (ГОСТ 19. 701-90) - схема взаимодействия компонентов программного обеспечения с описанием информационных потоков, состава данных в потоках и указанием используемых файлов и устройств. Для изображения этих схем используют специальные обозначения, установленные стандартом.

Функциональные схемы более информативны, чем структурные. На рис. 4.4 для сравнения приведены функциональные схемы программных комплексов и систем.

а)

б)

Рис. 4.4. Примеры функциональных схем: а - комплекс программ, б - программная система.

Все компоненты структурных и функциональных схем должны быть описаны. При структурном подходе особенно тщательно необходимо прорабатывать спецификации межпрограммных интерфейсов, так как от них зависят самые дорогостоящие ошибки.

Структурное проектирование использует три основных вида моделей (диаграмм):

1) SADT (Structured Analysis and Design Technique — метод структурного анализа и проектирования) — модели и соответствующие функциональные диаграммы;

2) DFD (Data Flow Diagrams) - диаграммы потоков данных;

3) ERD (Entity-Relationship Diagrams) — диаграммы «сущность-связь».

Функциональная модель SADT отображает функциональную структуру объекта, т.е. производимые им действия и связи между этим действиями.

Главным компонентом модели является диаграмма. На ней все функции и интерфейсы представлены в виде блоков и дуг соответственно. Место соединения дуги с блоком определяет тип интерфейса. Управляющая информация входит в блок сверху. Входная информация, которая подвергается обработке, показана с левой стороны блока, а результат (выход) - с правой. Механизм (человек или автоматизированная система), который осуществляет операцию, представляется дугой, входящей в блок снизу (рис. 4.5).

Рис.4.5

Построение SADT-модели начинается с представления всей системы в виде простейшего компонента — одного блока и дуг, изображающих интерфейс с функциями вне системы. Затем этот блок детализируется на другой диаграмме с помощью нескольких блоков, соединенных интерфейсным дугами. Новые блоки определяют основные подфункции исходной функции, которые, в свою очередь, могут быть детализировании и т.д. (см. рис. 4.6).

Диаграммы потоков данных (DFD) являются основным средством моделирования функциональных требований к проектируемой системе. С их помощью эти требования представляются в вид иерархий функциональных компонентов (процессов), связанных потоками данных. Главная цель такого представления — продемонстрировать, как каждый процесс преобразует свои входные данные выходные, а также выявить отношения между этими процессами.

Рис. 4.6

Основными компонентами диаграмм потоков данных являются:

a) внешние сущности;

b) системы и подсистемы;

c) процессы;

d) накопители данных;

e) поток данных.

Внешняя сущность представляет собой материальный объект или физическое лицо, являющийся источником или приемником информации. Она изображается объемным прямоугольником с надписью, как показано на рисунке 4.7.

Рис. 4.7

Подсистема (см. рис. 4.8) или процесс (рис. 4.9) представляются прямоугольником с закругленными краями. Он содержит три поля:

a) Номера;

b) Имени;

c) Физической реализации.

Подсистема и процесс отличаются именем. В первой записывается название подсистемы, а во втором – глагол, определяющий, что делает процесс.

Рис. 4.8. ГНИ – Государственная налоговая инспекция

Рис. 4.9

Накопитель данных - это абстрактное устройство для хранения информации. Он изображается, как показано на рис. 4.10. Его обозначение начинается с буквы D.

Рис. 4.10

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

Пример диаграммы потоков данных приведен на рис. 4.11.

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

ER-диаграммы будут рассмотрены позднее.

В курсовом проекте, кроме функциональной диаграммы, необходимо представить схемы алгоритмов наиболее сложных функций (например, сортировки и поиска).

Рис. 4.11

Рис. 4.12