Что такое структура программы определение

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

КОМАНДА ПЕРЕХОДА (ПЕРЕДАЧИ УПРАВЛЕНИЯ)

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

CLEAR REGISTER 5 TO ZERO

READ FIRST NUMBER FROM DATA CARD

READ SECOND NUMBER

READ THIRD NUMBER

READ FOURTH NUMBER

READ LAST NUMBER

ADD IT TO THE SUM AND

PRINT THE FINAL TOTAL

Рис. 5.1. Вычисление суммы пяти чисел, вводимых с перфократ. последовательность команд

производит обмен содержимым между регистрами 4 и 5. Любой другой порядок выполнения этих команд (проверьте) не позволит добиться этой цели.

Структура программы

Но во многих случаях желательно, чтобы команды выполнялись в несколько ином порядке, чем они написаны. Предположим, что требуется подсчитать сумму пяти чисел, набитых на картах. На рис. 5.1 представлен один из способов достижения этой цели, при этом регистр 5 используется для хранения частичных сумм чисел, считываемых последовательно в регистр 2 по команде RWD.

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

Теперь надо всего лишь организовать цикл, включающий команды ARи RWD; и выполнение этих команд будет возобновляться всякий раз, пока процессор не выйдет из цикла. Рис. 5.2 содержит блок- схему этого способа решения задачи. После ввода первого числа и вычисления частичной суммы мы снова возвращаемся к команде чтения карты. При этом используется безусловный переход, выполняющийся вне зависимости от каких-либо обстоятельств.

ВS2 Branch (unconditional) PC (счетчиккоманд) S2

При описании команды перехода мы указали лишь один операнд S(storage— память), снабдив его индексом 2. Это сделано потому, что данный операнд в соответствующей команде является вторым. S2 обычно представляет собой символическое имя команды, к выполнению которой мы хотим перейти. Итак, если мы хотим осуществить переход к выполнению команды с именем AGAIN, нужно написать

Рис. 5.2. Блок-схема вычисления суммы последовательности чисел, вводимых с перфокарт.

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

На рис. 5.3 изображена программа, соответствующая блок-схеме 5.2. Используем следующие обозначения

SUM регистр 5

А регистр 2

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

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

SR 5,5 START SUMАТ0

NEWNUM RWD 2 READ NEXTNUMBER

AR 5,2 ADD ITTO SUM

В NEWNUM GO BACK FOR MORE

Рис. 5.3. Программа вычисления суммы последовательности чисел, вводимых с перфокарт.

Например, в результате выполнения команды ARможет получиться отрицательное число, положительное число или 0 (ситуацию переполнения мы пока не будем рассматривать). Признак результата после выполнения команды ARуказывает, какой именно случай имел место. Если

то после выполнения команды

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

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

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

Сейчас нам достаточно рассмотреть 6 команд условного перехода. Другие возможности организации переходов обсуждаются в гл. 9.

BP S2 Branch on Plus PC S2, еслирезультат> О

Слово результат означает результат выполнения последней команды, меняющей признак результата. По команде ВР (ПЕРЕХОД ПО ПЛЮСУ) переход на S2 осуществляется в случае, если результат больше 0.

Рис. 5.4. Примеры применения команд условного перехода.

Команда BZ(ПЕРЕХОД ПО НУЛЮ) вызывает выбор следующей команды из ячейки с адресом S2, если результат выполнения последней команды, влияющий на признак результата, равен 0.

BM S2 Branch on Minus PC S2, еслирезультат< О

Команда ВМ (ПЕРЕХОД ПО МИНУСУ) вызывает выбор S2 в качестве следующей команды, если результат выполнения последней команды, изменяющей признак результата, меньше 0.

Обратимся теперь к рис. 5.4. Регистры содержат указанные числа перед началом выполнения каждой из четырех последовательностей команд. Какие команды выполняются по окончании каждой из последовательностей: YESили N0? В случае (а) сумма равна 00000012, т. е. положительна, поэтому по команде ВР осуществляется переход к выполнению YES.

В случае (б) также произойдет переход на команду YES, так как результат выполнения SRположителен, aLRне влияет на признак результата. В случае (в) после выполнения команды MRв регистре 8 устанавливается значение 00000000. В результате сложения получается положительное число, и следующей выполняется снова команда YES. Наконец, в случае (г) сумма равна 00000000, LCRне влияет на признак результата и переход осуществляется на команду с именем N0.

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

BNP S2BranchonNot Plus PC S2, результат 0

BNZ S2BranchonNot Zero PC S2, результат 0

BNM S2BranchonNotMinus PC S2, результат 0

При этом подразумевается, что любое число со знаком плюс больше 0 (0 — неположителен) и любое число со знаком минус — меньше 0

Рис. 5.5. Блок-схема программы вычисления cуммы пяти чисел.

L 9,=F’5′ FINAL VALUE OFLCOP COUNTER IN REG.9

L 7,=F’0′ STARTING VALUE OF LOOPCOUNTER IS 0

L 4,=F’1’INCREMENT FOR LOOP COUNTER IS 1

SR 5,5 START SUM AT 0

NEXTNUM RWD 2 READ A NUMBER

AR 5,2 ADD IT TO SUM

AR 7,4 INCREMENT LOOP COCNTER

Ln 8,9 MAKE A COPY OF FINAL COUNTER VALUE

SR 8.7 COMPUTE DIFFERENCE К-I

BM NEXTNUM GO BACK FOR MORE IF NOT DONE

Рис. 5.6. Программа вычисления и печати суммы пяти чисел, вводимых с перфокарт.

(0 — неотрицателен). Например, по команде BNPпроизводится переход, если признак результата указывает, что последний меньше или равен 0.

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

На рис. 5.5. изображена блок-схема программы, вычисляющей сумму пяти чисел, набитых на перфокартах. На рис. 5.6 приведена соответствующая программа на языке ассемблера. В этой программе

SUM регистр5

А регистр 2

К регистр 9(контрольноезначение счетчика цикла)

I регистр 7(счетчик цикла)

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

Команда сравнения и загрузки с установкой признака результата

Пока для сравнения двух заданных чисел нам пришлось бы вычислить их разность и проверить признак результата. Но при выполнении команды SRразность попадает в регистр R1, таким образом уничтожается одно из сравниваемых чисел.

Можно избежать этой неприятности, как это показано на рис. 5.6, сохраняя копию стираемого числа в некотором регистре (в данном случае копию К в регистре 8). В программе 5.6 перед сравнением счетчика цикла I, находящегося в регистре 7, с его конечным значением мы копируем содержимое регистра 9 в регистр 8.

Для сравнения выполняется команда

полученный признак результата используется командой перехода. Этот метод неудачен по крайней мере по двум причинам: используется лишний регистр для хранения копии К (а мы всегда заинтересованы в наиболее экономном использовании регистров) и выполняется команда

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

Команда CR (СРАВНЕНИЕ)

Устанавливает признак результата в соответствии со знаком (R1)—(R2)

производит вычитание (R2) из (R1) и устанавливает признак результата в соответствии с этой разностью. Но запись разности при этом не производится; таким образом, содержимое R1 остается неизменным.

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

После выполнения команды

и признак результата соответствует положительному числу.

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

На рис. 5.7 приведена программа рис. 5.6, модифицированная использованием команды CR. Теперь не нужно копировать содержите регистра 9 в регистр 8 и, значит, ни к чему выполнять команду

FINAL VALUE OF LOOP COUNTER IN REG 9

STARTING VALUE OF LOOP COUNTER IS 0

INCREMENT FOR LOOP COUNTER IS 1

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

Структура программных продуктов

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

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

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

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

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

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

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

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

Среди множества модулей различают:

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

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

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

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

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

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

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

• программы с жестким сценарием диалога – стандартизированное представление информации обмена;
• дескрипторные программы – формат ключевых слов сообщений;

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

Наиболее просты для реализации и распространены диалоговые программы с жестким сценарием диалога, которые предоставлены в виде:

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

Диалоговый процесс управляется согласно созданному сценарию, для которого определяются:

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

Графический интерфейс пользователя (Graphics User Interface — GUI) является обязательным компонентом большинства современных программных продуктов, ориентированных на работу конечного пользователя. К графическому интерфейсу пользователя предъявляются высокие требования как с чисто инженерной, так и с художественной стороны разработки, при его разработке ориентируются на возможности человека.

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

Стандартный графический интерфейс пользователя должен отвечать ряду требований:

• поддерживать информационную технологию работы пользователя с программным продуктом – содержать привычные и понятные пользователю пункты меню, соответствующие функциям обработки, расположенные в естественной последовательности использования;
• ориентироваться на конечного пользователя, который общается с программой на внешнем уровне взаимодействия;
• удовлетворять правилу «шести» — в одну линейку меню включать не более 6 понятий, каждое из которых содержит не более 6 опций;
• графические объекты сохраняют свое стандартизованное назначение и по возможности местоположение на экране.

Цели структурного программирования.

Целями структурного программирования являются:

1.Обеспечить дисциплину программирования в процессе создания программных комплексов. Дейкстра дал следующее определение: «Структурное программирование – это дисциплина, которую программист навязывает сам себе».

2.Улучшать читабельность программы. Читабельность улучшается, если придерживаться следующих правил:

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

переходов на другую страницу.

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

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

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

Основные принципы структурной методологии

К основным принципам структурной методологии относятся:

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

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

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

При разработке ПО этот принцип означает разделение программы на отдельные фрагменты (модули), которые просты по управлению и допускают независимую отладку и тестирование.

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

Статьи к прочтению:

• Структура современной информатики
• Структура типичной школьной локальной сети.

Презентация программного продукта. Конференция.

Похожие статьи:

• Состав программного продукта Комплексная лабораторная работа по дисциплине ПКШ “Система классов улиц и домов” Руководство системного программиста (вид документа) писчая бумага (вид…
• Обзор существующих программных продуктов СОДЕРЖАНИЕ ВВЕДЕНИЕ. 2 1 ТЕОРЕТИЧЕСКАЯ ЧАСТЬ. 5 1.1 ОБЗОР СУЩЕСТВУЮЩИХ ПРОГРАММНЫХ ПРОДУКТОВ.. 5 1.1.1 ОБЗОР WINDOWS COMMANDER 5.11. 6 1.1.2 ОБЗОР FAR…

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

Методы разработки структуры программы

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

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

В процессе разработки программы ее модульная структура может по-разному формироваться и использоваться для определения порядка программирования и отладки модулей, указанных в этой структуре. Поэтому можно говорить о разных методах разработки структуры программы. Обычно в литературе обсуждаются два метода [7.1, 7.7]: метод восходящей разработки и метод нисходящей разработки.

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

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

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

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

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

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

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

Первым тестируется головной модуль программы, который представляет всю тестируемую программу и поэтому тестируется при «естественном» состоянии информационной среды, при котором начинает выполняться эта программа. При этом все модули, к которым может обращаться головной, заменяются на их имитаторы (так называемые заглушки [7.5]).

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

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

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

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

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

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

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

Рис. 7.1. Первый шаг формирования модульной структуры программы при конструктивном подходе.

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

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

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

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

Рис. 7.2. Второй шаг формирования модульной структуры программы при конструктивном подходе.

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

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

При нисходящей разработке дерево можно обходить также в лексикографическом порядке (сверху-вниз, слева-направо). Возможны и другие варианты обхода дерева. Так, при конструктивной реализации для обхода дерева программы целесообразно следовать идеям Фуксмана, которые он использовал в предложенном им методе вертикального слоения [7.8].

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

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

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

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

Рис. 7.3. Классификация методов разработки структуры программ.

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

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