Классификация программного обеспечения

ОСНОВНЫЕ ПОНЯТИЯ

КЛАССИФИКАЦИЯ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

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

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

системное: операционные системы; драйверы устройств; раз­личные утилиты;

для разработчиков: среды программирования; трансляторы и интерпретаторы; CASE-средства; библиотеки программ;

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

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

Программная система представляет собой набор решений множества различных, но связанных между собой задач (ОС, СУБД). Более узкоспециализированные программы не называют системами (редактор текстов, компилятор и т. п.)

ЦИКЛ ЖИЗНИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

Жизненный цикл ПО (software life-cycle) - весь период времени существования системы программного обеспечения, начи­ная от выработки первоначальной концепции этой системы и кончая ее моральным устареванием.

Жизненный цикл (рис. 1) представляется в виде некоторого числа последовательных фаз, в определенных местах охватывае­мых обратными связями, когда может возникнуть необходимость повторения какого-либо одного или даже всех этапов разработки системы. Такая модель обеспечивает отражение итеративности* процессов существования ПО.

 

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

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

ЭТАПЫ СОЗДАНИЯ ПРОГРАММ

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

а) уточнение видов и последовательности всех работ;

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

в) выявление аналогов, обеспечивающих достижение подобных целей, их достоинств и недостатков.

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

а) постановка задачи на разработку новой программы;

б) оценка достигаемых целей разрабатываемого программного изделия.

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

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

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

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

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

5. Комплексное тестирование.

6. Разработка эксплуатационной документации.

7.Приемо-сдаточные и другие виды испытаний.

8. Корректировка программ. Проводится по результатам пред­шествующих испытаний.

8. Сдача заказчику. Осуществляется окончательная сдача про­граммного изделия заказчику.

10. Тиражирование.

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

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

ДОКУМЕНТИРОВАНИЕ ПРОГРАММ

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

Программная спецификация (program specification) - точное описание того результата, которого нужно достичь с помощью про­граммы. Это описание должно точно устанавливать, что должна делать программа, не указывая, как она должна это делать.

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

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

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

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

объекты, участвующие в задаче (что делает программа и что делает человек, работающий с этой программой);

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

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

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

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

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

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

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

ТЕОРИЯ ПЕРВИЧНЫХ ПРОГРАММ

 

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

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

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

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

 

Любая блок-схема состоит только из этих трех компонентов.

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

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

 

 

На рис. 3 изображены все первичные программы, которые включают в себя не более четырех узлов. Первичные программы а, б, д, и представляют собой последовательности функциональных узлов. Первичная программа е — конструкция if-then,.ж — do-while, з - repeat-until, к - if-then-else, л - do-while-do.

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

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

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

АЛЬТЕРНАТИВЫ

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

Условный оператор является частным случаем case- или switch-оператора, в котором выражение имеет булев тип. Так как булевы типы имеют только два допустимых значения, условный оператор делает выбор между двумя возможными путями. Конструкция для двух альтернатив на Паскале имеет следующий вид:

if L

then begin

{Действие при L-True} end; else begin

{Действие при L=False} end; здесь L-логическое выражение.

Вариант конструкции для нескольких альтернатив имеет вид:

Switch: = 0;

L1: =...

L2: =...

L3: =...

if L1 then Swich: = 1;

if L2 then Swich: = 2;

if L3 then Swich: = 3;

case Swich of 1: begin

{Действие при L1=True} end; 2: begin

{Действие при L2=True} end; 3:begin

{Действие при L3=Тrие} end; else begin

{Вывод сообщения об ошибочном кодировании модуля} end; end; {End of Case}

2.3. ЦИКЛЫ

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

ОПЕРАТОРЫ ПЕРЕХОДА

Оператор безусловного перехода имеет следующий вид: goto, здесь goto — зарезервированное слово: <метка> — метка.

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

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

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

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

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

В современных языках Object Pascal, Ada, C++ и Eiffel есть спе­циальные языковые конструкции, так называемые исключения, ко­торые непосредственно решают и эту проблему.

ПЕРЕДАЧА ПАРАМЕТРОВ

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

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

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

параметры-значения;

параметры-переменные;

параметры-константы.

Например, procedure MyProc (A: Real; var В: Real; const С: String);

здесь А - параметр-значение, в - параметр-переменная, С - пара­метр-константа.

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

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

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

Если параметр определен как параметр-переменная, то при вы­зове подпрограммы передается сама переменная, а не ее копия (фактически в этом случае подпрограмме передается адрес пере­менной). Изменение параметра-переменной приводит к изменению самого фактического параметра в вызывающей программе.

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

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

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

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

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

Нетипизированные параметры. Одним из свойств языка Object Pascal является возможность использования нетипи­зированных параметров.

Параметр считается нетипизированным, если тип формального параметра-переменной в заголовке подпрограммы не указан, при этом соответствующий ему фактический параметр может быть пе­ременной любого типа. Нетипизированными могут быть только параметры-переменные: procedure MyProc(var aParametr);

Нетипизированные параметры обычно используются в случае, когда тип данных несуществен. Такие ситуации чаще всего возни­кают при разного рода копированиях одной области памяти в дру­гую, например, с помощью процедур BlockRead, BlockWrite, Move-Memory и т. п.

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

type

Prod = procedure (a, b, с: Real; var d: Real);

РгосЗ == procedure;

Fund = function: String;

Func2 = function (var s: String): Real;

В программе могут быть объявлены переменные процедурных типов, например:

var

p1: Proc1;

fl, f 2: Func2;

ар: array [1.. N] of Prod;

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

2.7. РЕКУРСИЯ

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

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

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

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

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

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

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

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

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

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

1) форма с выполнением действий до рекурсивного вызова (на
рекурсивном спуске);

procedure Rec; begin

S;

if условие then Rec; end;

2) форма с выполнением действий после рекурсивного вызова
(на рекурсивном возврате);

procedure Rec; begin

if условие then Rec;

S; end;

3) форма с выполнением действий как до, так и после рекур­сивного вызова (с выполнением действий как на рекурсивном спуске, так и на рекурсивном возврате).

procedure Rec; begin

S1;

if условие then Rec; S2; end;

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

 

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

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

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

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 этих модулей.

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

 

ОСНОВНЫЕ ПОНЯТИЯ

ПОЛЯ

Класс представляет собой единство трех сущностей - полей, методов и свойств. Объединение этих сущностей в единое целое достигается за счет применения инкапсуляции.