Проектирование структуры программы это

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

Цель лекции: ознакомиться с проектированием ПО при структурном подходе.

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

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

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

Топ шаблонов проектирования которые должен знать программист(старая версия)

Рисунок 11.1 — Пример схем программного комплекса: а) структурной;

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

Рисунок 11.2 – Пример схем программной системы: а) структурной;

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

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

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

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

Что такое UML за 7 минут: Диаграмма классов, последовательностей, состояний и деятельности

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Дополнительную информацию по теме можно получить в [1, 4, 6, 8, 10].

Понравилась статья? Добавь ее в закладку (CTRL+D) и не забудь поделиться с друзьями:

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

2.2.2. Внешнее представление данных

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

Для графа, например, можно рекомендовать внешнее представление в виде перечня ребер (дуг), перед которым указывается количество вершин [9]. Каждое ребро задается парой номеров вершин (см. рис. 2.1, б). При необходимости указывается вес ребра или дуги.

Граф Количество вершин Матрица смежности

и перечень ребер

———T—4 б 4 2 в 0¦0 1 1 0 0¦

L——— 1 0 4¦0 0 1 1 0¦

Рис. 2.1. Примеры внешнего представления графа

а) граф б) количество вершин и перечень ребер(Ctrl-Z — конец файла) в) матрица смежности

Другое внешнее представление графа — матрица смежности, вводимая по строкам или по столбцам (рис. 2.1, в). Она более удобна при большом количестве ребер.

После внешнего проектирования полезно методами черного ящика разработать тесты для отладки программы (см. раздел 3.2). Это позволит лучше понять задачу, уточнить ее постановку и проверить полноту и качество внешнего проекта программы. Если возникают затруднения при определении реакции программы на входные данные какого-либо теста, необходимо соответствующим образом уточнить описание архитектуры программы.

2.3. Проектирование структуры программы

Проектирование (модульной) структуры — это разбиение программы на небольшие независимые модули (подпрограммы) с целью ее упрощения. В этом состоит основная идея модульного программирования [16].

Модуль представляет собой часть программы, хранимую в отдельном файле и транслируемую отдельно от других ее частей. Модуль имеет три основных атрибута: он выполняет одну или несколько функций, обладает некоторой логикой и используется в разных контекстах. Функция — это внешнее описание модуля (что он делает, но не как это делается).

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

Желательно, чтобы разработанные в программе модули, имеющие самостоятельное значение, можно было использовать как библиотечные программы в других задачах. Поэтому модули преобразования данных обычно сами не занимаются их вводом-выводом: входные и выходные данные передаются в виде параметров.

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

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

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

На рис. 2.2 приведен первоначальный вариант структуры программы поиска в заданном графе цикла минимальной длины.

1 ¦ main — главная ¦ 3

¦ vvodg ¦ ¦ pminc — поиск ¦ ¦ vyvodp — вывод¦

¦ — ввод графа ¦ ¦ кратчайшего цикла¦ ¦ цикла (пути) ¦

Рис. 2.2. Модульная структура программы

Соответствующий каждому сопряжению набор входных и выходных данных вызываемого модуля указывается в таблице сопряжений. Сопряжения модулей программы из рис. 2.2 показаны в табл. 2.1. Выходные данные сопряжений 1 и 2 содержат код завершения (успеха), т. к. при вводе графа возможны ошибки (например, отсутствие входного файла), а поиск закончится неудачно, если в графе отсутствуют циклы.

¦ 1 ¦ ¦ Граф, код успеха ¦

¦ 2 ¦ Граф ¦ Номера вершин цикла, код ¦

¦ 3 ¦ Номера вершин цикла (пути)¦ ¦

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

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

Наилучшим по прочности является функционально-прочный модуль, выполняющий одну четко определенную функцию.

Не желательно возлагать на модуль несколько различных функций, кроме случая информационно-прочного модуля, который выполняет все функции (операции) над некоторой структурой данных и соответствует объекту в объектно-ориентированном программировании. На языках C и Pascal информационно-прочный модуль реализуется в виде набора определений функций и данных, объединенных в отдельно транслируемый файл.

Второй способ достижения независимости модулей — ослабление сцепления между ними. В зависимости от характера данных и способа их передачи между модулями можно выделить следующие виды сцепления модулей (перечислены от лучшего к худшему) [16]:

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

2. Группа модулей сцеплена по формату, если они используют неглобальные структуры данных одинакового строения и поэтому чувствительны к его изменению. Это могут быть, например, параметры или локальные переменные в виде массивов или структур (записей) одинакового типа.

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

4. Группа модулей, использующая общую (глобальную или внешнюю) скалярную переменную, сцеплена по внешним данным. Недостатки глобальных переменных: любой модуль может «испортить» значение глобальной переменной и эту ошибку трудно найти, т. к. невозможно контролировать доступ к данным; модули связаны общим именем переменной и их трудно использовать в других программах; трудно понять программу, т. к. из вызова модуля без анализа логики его и всех подчиненных ему модулей нельзя определить, какие глобальные переменные он изменяет.

5. Группа модулей, использующая общую (глобальную или внешнюю) структуру данных, сцеплена по общей области. К недостаткам глобальных переменных (пункт 4) добавляется зависимость всех модулей от строения общей области (пункт 2).

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

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

Лекция 10 Структурное проектирование сложных программных средств

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

Основные принципы и правила структурирования ПС и БД можно объединить в группы, которые отражают:

— стандартизированную структуру целостного построения ПС и/или БД определенного класса;

— унифицированные правила структурного построения функциональных программных компонентов и модулей;

— стандартизированную структуру базы данных, обрабатываемых программами;

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

— унифицированные правила организации и структурного построения межмодульных интерфейсов программных компонентов;

— унифицированные правила внешнего интерфейса и взаимодействия компонентов ПС и БД с внешней средой, с операционной системой и другими типовыми средствами организации вычислительного процесса, защиты и контроля системы.

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

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

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

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

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

Всем иерархическим системам (в частности, ПС) присущ ряд общих свойств, важнейшими из которых являются:

— вертикальная соподчиненность, заключающаяся в последовательном упорядоченном расположении взаимодействующих компонентов, составляющих ПС;

— право вмешательства и приоритетного воздействия сверху вниз на компоненты нижних уровней;

— взаимозависимость действий компонентов верхних уровней от реакций на воздействия и от функционирования компонентов нижних уровней, информация о которых передается верхним уровням.

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

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

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

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

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

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

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

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

Источник: karpusheva.ru