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

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

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

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

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

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

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

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

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

Ключ - значение переменной, используемое для подтверждения полномочий на доступ к некоторой информации или подпрограмме.

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

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

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

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

КРИТЕРИИ ОЦЕНКИ КАЧЕСТВА

СТРУКТУРНОЙ СХЕМЫ ПРОГРАММЫ

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

1) полнота выполнения специфицированных функций;

2)возможность быстрого и дешевого пополнения новыми, ра­нее не специфицированными функциями;

3)обозримость (понятность) для проектировщика составных частей программы;

4)максимальная независимость отдельных частей программы;

5) возможность связывания подпрограмм редактором связей;

6)достаточность оперативной памяти;

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

8) отсутствие разных модулей со сходными функциями. Один и тот же модуль должен вызываться на разных уровнях схемы иерархии;

9)достижение такого графика работы коллектива программи­стов при реализации программы, который обеспечивает равномер­ную загрузку коллектива;

 

10)всемерное сокращение затрат на тестирование программы.
Хорошая схема иерархии в 2-5 раз сокращает затраты на тестиро­вание по сравнению с первоначальным вариантом;

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

Генерация вариантов прекращается при невозможности даль­нейших улучшений. Рациональная структура программы обеспечи­вает сокращение общего объема текстов в 2-3 раза, что соответст­венно удешевляет создание программы и ее тестирование, на кото­рое обычно приходится не менее 60% от общих затрат. При этом облегчается и снижается стоимость сопровождения программы.

МОДУЛЬНОЕ ПРОГРАММИРОВАНИЕ

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

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

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

Концепцию модульного программирования можно сформули­ровать в виде нескольких понятий и положений:

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

2) модуль представляет собой «черный ящик» с одним входом и одним выходом. Это позволяет безболезненно производить мо­дернизацию программы в процессе ее эксплуатации, облегчает ее
сопровождение, а также позволяет разрабатывать части программодного проекта на разных языках программирования;

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

4) исходный текст модуля должен иметь заголовок и интер­фейсную часть, где отражаются назначение модуля и все его внеш­ние связи;

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

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

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

 

3.7. СТРУКТУРА МОДУЛЯ В OBJECT PASCAL

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

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

unit <идентификатор_модуля>;

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

{Интерфейсный раздел} interface

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

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

Связь модуля с другими модулями устанавливается специаль­ным предложением:

{Список импорта интерфейсного раздела} uses <список_модулей>

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

{Список экспорта интерфейсного раздела} const type var

procedure function

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

{Раздел реализации) implementation

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

{Список импорта раздела реализации) uses

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

{Подразделы внутренних для модуля описаний} label const type var

procedure function

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

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

{Раздел инициализации} initialization

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

{Раздел завершения) finalization

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

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