Файл: Lektsii_TP.doc

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

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

Абстрактные структуры данных (АСД)

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

В третьем случае существенным являются и связи элементов данных между собой.

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

Различают (в зависимости от описываемых типов отношений) иерархические и сетевые модели структур данных.

Иерархические модели позволяют описывать упорядоченные или неупорядоченные отношения вхождения элементов данных компонент более высокого уровня. К этим моделям относятся модель Джексона-Орра, для графического представления которых можно использовать:

• диаграммы Джексона.

• скобочные диаграммы Орра.

Нотация Джексона:

а). б). в).

Скобочная нотация Орра:

а). б). в).

а – последовательность,

б – выбор,

в – повторение.

Пример:

Описание структуры электронной ведомости.

“Электронная ведомость”

4.5. Сетевая модель данных.

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

1). нотация П.Чена;

2). нотация Р.Баркера;

3). нотация IDEF1. Более современный вариант этой нотации используется вcase-системах.

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

5. Проектирование программного обеспечения при структурном подходе

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

5. 1. Разработка структурной и функциональной схем.

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

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

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

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

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

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

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

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

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

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

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

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

Функциональная схема

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

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

а).

б).

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

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

5.2. Использование метода пошаговой детализации для проектирования структуры программного обеспечения.

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

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

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

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

Кроме этого, целесообразно придерживаться следующих рекомендаций:

• не отделять операции инициализации и завершения от соответствующей обработки, так как модули инициализации и завершения имеют плохую связность (временную) и сильное сцепление (по управлению);

• не проектировать слишком специализированных или слишком универсальных модулей, так как проектирование излишне специальных модулей увеличивает их количество, а проектирование излишне универсальных модулей повышает их сложность;