Разработка структурной схемы программы

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

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

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

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

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

Лекция 7. Схемы — обзор. Электрические структурная и схема соединений.

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

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

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

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

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

Занятие 2. Проектирование базы данных. Таблицы и связи. Схема базы данных

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Разбиение на модули при данном виде проектирования выполняется эвристически, исходя из рекомендуемых размеров модулей (20-60 строк) и сложности структуры (две-три вложенных управляющих конструкции). В принципе в качестве модуля (подпрограммы) можно реализовать решение подзадач, сформулированных на любом шаге процесса детализации, однако

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

Источник: studfile.net

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

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

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

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

Рисунок — 10. — Пример схем программного комплекса: а) структурной; б) функциональной

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

Рисунок — 11. – Пример схем программной системы: а) структурной; б) функциональной

Более полное представление о проектируемом ПО с точки зрения взаимодействия его компонентов между собой и с внеш­ней средой дает функциональная схема. Функциональная схема (схема данных, ГОСТ 19.701-90) — схема взаимодействия компонентов ПО с описанием информационных потоков, состава данных в потоках и указанием используемых файлов и устройств.

Для изображения функцио­нальных схем используют специальные обозначения, установленные стан­дартом. Основные обозначения схем данных приведены в таблице Г.1. Функциональные схемы более информативны, чем структурные. На рисунках 11.1б и 11.2б приведены функциональные схемы программных комплексов и систем. Все компоненты структурных и функциональных схем должны быть описаны.

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

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

Тот же метод позволяет получить структурные схемы с большим количеством уровней. Разбиение на модули выполняется эв­ристически, исходя из рекомендуемых размеров модулей (20-60 строк) и сложности структуры (2-3 вложенных управляющих конструкции). Для анализа технологичности иерархии модулей используют методики Константайна или Джексона.

На структурной карте Константайна отношения между модулями представляют в виде графа, вершинам которого соответствуют модули и общие области данных, а дугам — межмодульные вызовы и обращения к общим областям данных. Различают четыре типа вершин: модуль – подпрограмма; подсистема – программа; библиотека — совокупность подпрограмм, размещенных в отдельном модуле; область данных — специальным образом оформленная совокупность данных, к которой возможно обращение извне. При этом отдельные части программной системы могут вызываться последовательно, параллельно или как сопро­граммы.

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

Методика Джексона основана на поиске соответствий структур исходных данных и результатов. Однако при ее применении возможны ситуации, когда на ка­ких-то уровнях соответствия отсутствуют. Например, записи исходного фай­ла сортированы не в том порядке, в котором соответствующие строки долж­ны появляться в отчете. Такие ситуации были названы «столкновениями».

Методика Варнье-Орра базируется на том же положении, что и методика Джексона, но основными при построении про­граммы считаются структуры выходных данных и, если структуры входных данных не соответствуют структурам выходных, то их допускается менять. Таким образом, ликвидируется основная причина столкновений. Однако на практике не всегда существует возможность пересмотра структур входных данных: эти структуры уже могут быть строго заданы, на­пример, если данные получены при выполнении других программ, поэтому эту методику применяют реже.

Под проектированием структур данных понимают разработку их пред­ставлений в памяти. Основными параметрами, которые необходимо учиты­вать при проектировании структур данных, являются:

1. вид хранимой информации каждого элемента данных — определяет тип соответствующего поля па­мяти;

2. связи элементов данных и вложенных структур, а также совокупность операций над ними — определя­ют структуры памяти, используемые для представления данных;

3. время хранения данных структуры («время жизни») — учитывается при размещении данных в статической или динамической па­мяти, а также во внешней памяти.

Различают две базо­вые структуры организации данных в оперативной памяти: векторную и списковую. Векторная структура — последовательность байт памяти, которые исполь­зуются для размещения полей данных.

Последовательное размещение организованных структур данных позволяет осуществлять прямой доступ к элементам: по индексу (в массивах или строках) или по имени поля (в записях или объектах). Однако выполнение операций добавления и удаления элементов для размещения элементов массивов требует осуществления многократных сдви­гов элементов.

Расположение векторных пред­ставлений в динамической памяти позволяет существенно увеличить эффективность использования оперативной памяти. Списковые структуры строят из специальных элементов, включающих помимо информационной части один или несколько указателей — адре­сов элементов или вложенных структур, связанных с этим элементом. Раз­мещая их в динамической памяти, организуют различные внутренние структуры. Обычно векторное представление используют для хранения статичес­ких множеств, таблиц (одномерных и многомерных: матриц, строк, записей), а также графов, представленных матрицей смежности, мат­рицей инцидентности или аналитически. Списковое представление удобно для хранения динамических (изменяемых) структур и структур со сложными связями.

Современные операци­онные системы поддерживают два способа организации данных во внешней памяти: последовательный и с прямым доступом.При последовательном доступе к данным возможно выполнение только последовательного чтения элементов данных или последовательная их за­пись (работа с клавиатурой или дисплеем, обработка текстовых файлов или файлов, формат записей которых меняется в процессе работы). Прямойдоступ возможен только для дисковых файлов, обмен информа­цией с которыми осуществляется записями фиксированной длины (двоичные файлы С или типизированные файлы Pascal). Адрес записи такого файла можно определить по ее номеру, что и позволяет напрямую обращаться к нужной записи. В оперативной памяти размещают данные, к которым необходим быс­трый доступ как для чтения, так и для их изменения; во внешней — данные, которые должны сохраняться после завершения программы.

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

Дата добавления: 2018-02-28 ; просмотров: 1478 ; Мы поможем в написании вашей работы!

Источник: studopedia.net

Расчетная часть

Структурная схема программы демонстрирует взаимосвязь отдельных модулей программы. Связь между подпрограммами, написанными на HTML, осуществляется с помощью тега …. Для того чтобы осуществить связь с другими файлами, содержащими модули программы, написанные не на HTML(в данном случае это Видео.ppt и Тест.exe) используется следующий синтаксис этого тега….

Пример скрипта, написанного на HTML