Если у вас возникли сложности с курсовой, контрольной, дипломной, рефератом, отчетом по практике, научно-исследовательской и любой другой работой - мы готовы помочь.
Предоплата всего
Подписываем
15
file:///home/disk1/12balov/files/36/document.doc
Понятие модуля или, в более общем случае, модульного про граммирования, возникло на определенном этапе развития вычислительного дела и было обусловлено, в первую оче редь, возрастающими объемами программ, их увеличиваю щейся внутренней сложностью и коллективным характером разработок. К настоящему времени понятие модуля продела ло значительную эволюцию от примитивного "разрубания" текста программы на произвольные части или создания биб лиотек включаемых фрагментов до независимо хранимых и разрабатываемых, независимо компилируемых и тестируемых программных единиц со строго определенными интер фейсами, которые могут объединяться в различных сочета ниях, что характерно, например, для языка Ada.
При всех несомненных достоинствах алголоподобных языков, большинство из них имеет существенный недоста ток - отсутствие модульности. Представление программной системы как единой языковой конструкции является препят ствием для эффективной организации коллективных разра боток сложных систем, затрудняет понимание и модифика цию программ. Понятие подпрограмм лишь частично реша ет проблему ввиду неявных и слабо контролируемых информационных зависимостей подпрограмм и их окружения.
С этой точки зрения, введение понятия модуля в Turbo Pascal, которое было проведено, начиная с 4-ой версии систе мы, явилось решающим шагом на пути его превращения в язык, пригодный для крупных разработок производственно го и коммерческого назначения на современном уровне тех нологии программирования. Стал возможным современный стиль реализации программных пакетов различного назначе ния и ориентации, легко подключаемых к любой программе. Кроме того, за счет введения модулей удалось ослабить огра ничения на суммарный объем готовых программ.
Модульные средства в Turbo Pascal'e заметно слабее анало гичных возможностей тех языков, для которых модульный принцип был положен в основу их проектирования. Однако следует признать, что разработчики языка Turbo Pascal на шли удачный компромисс, достаточно органично встроив принципиально новое понятие в считающийся уже классиче ским язык Pascal, не нарушив при этом его целостности, эле гантности и простоты и одновременно значительно расши рив его возможности.
В языке Turbo Pascal модуль (unit) по определению считает ся отдельной программой. Если подпрограмма является структурным элементом Pascal-программы и не мо жет существовать вне ее, то модуль представляет собой от дельно хранимую и независимо компилируемую единицу. С учетом этого факта можно дополнить рассмотрение общей структуры Pascal-программы следующей синтак сической диаграммой для случая языка Turbo Pascal:
Программа на языке Turbo Pascal
В самом общем виде модуль представляет собой совокуп ность (коллекцию) программных ресурсов, предназначенных для использования другими модулями и программами. Под ресурсами в данном случае понимаются любые программные объекты языка Turbo Pascal - константы, типы, переменные, подпрограммы. Важно понимать, что модуль сам по себе не является выполняемой программой - его объекты ИСПОЛЬ ЗУЮТСЯ другими программными единицами.
Все программные ресурсы модуля можно разбить на две части: объекты, прямо предназначенные для использования другими программами или модулями, и объекты рабочего характера. Например, если модуль содержит некоторую под программу универсального назначения, пригодную для ис пользования другими программами, то, скажем, вызывае мые этой подпрограммой процедуры и функции, содержа щиеся в модуле, и используемые ею переменные имеют сугу бо внутренний характер. В соответствии с этим модуль, кро ме заголовка, имеет две основные части, называемые интер фейсом и реализацией.
В интерфейсной части модуля сосредоточены описания объектов, доступных из других программ; такие объекты на зывают видимыми вне модуля. В части реализации помеща ются рабочие объекты, называемые также невидимыми или скрытыми.
Заголовок модуля составляется из служебного слова unit и следующего за ним идентификатора, являющегося именем модуля. Заголовок завершается символом ';' (точка с запя той). Интерфейсная часть начинается со служебного слова interface, за которым следует совокупность обычных опи саний. Часть реализации начинается служебным словом implementation, за которым идут описания скрытых объек тов. Завершает модуль, как и программу, служебное слово end и символ '.' (точка).
Кроме перечисленных частей, модуль может содержать так называемый раздел инициализации, предназначенный для установки начальных значений переменных модуля пе ред его использованием. Этот раздел следует после раздела реализации, начинается со служебного слова begin и содер жит последовательность операторов.
Таким образом, общая структура модуля может быть представлена следующей схемой:
Приведем простейший пример модуля. Для того, что бы избежать многократного описания в различных програм мах некоторых общеупотребительных типов данных, молено сосредоточить их в одном модуле. Данный пример касается описаний, связанных с датами, месяцами, днями и т.д.
unit Calendar;
interface
type
Days = (Mon,Tue,Wed,Thu,Fri,Sat,Sun);
WorkingDays = Mon..Fri;
Months = (Jan,Feb,Mar,Apr,May,June,
July,Aug,Sept,Oct,Nov,Decem);
Summer = June..Aug;
Autumn = Sep..Nov;
Spring = Mar..May;
DayNo = 1..31;
YearNo = 1900..2000;
Date = record
Day : DayNo;
Month : Months;
Year : YearNo
end;
implementation
end.
Данный модуль, ввиду своей простоты, не содержит разделов реализации и инициализации. Механизм использования модулей в других программах будет описан далее.
14.3 Подпрограммы в модулях
Процедуры и функции могут использоваться в модулях на равне с другими Pascal-объектами. Однако для них имеются особенности, обусловленные их структурой. Как уже отмечалось, заголовок подпрограммы содержит всю информацию, необходимую для ее вызова: ее имя, количество и типы параметров и (для функций) тип результата. С другой стороны, тело подпрограммы содержит блок, раскрывающий ее алгоритм. Можно считать, что заголовок подпрограммы является ее интерфейсом, а тело - реализацией. В соответствии с этой точкой зрения в интерфейсной части модуля должны быть представлены только ЗАГОЛОВКИ процедур и функций, видимые (доступные) для других программ (аналогично предварительным описаниям, но без служебного слова forward), а их полные описания будут содержаться в разделе реализации. При этом полное описание подпрограммы может иметь СОКРАЩЕННЫЙ заголовок, состоящий только из служебного слова procedure или function, имени подпрограммы и символа ';'. (Разумеется, можно повторить полный заголовок подпрограммы, но тогда он должен быть точно таким же, как и заголовок в интерфейсной части).
В качестве примера можно привести модуль, содержащий средства работы с комплексными числами
unit CmplVals;
interface
type
Complex = record { способ представления
комплексных чисел }
Re, Im : real
end;
{ Заголовки процедур, реализующих
операции над комплексными числами }
procedure InitC (R,I:real; Var C:Complex);
procedure AddC (Cl,C2:Complex;var R:Complex);
procedure MultC (Cl,C2:Complex;var R:Complex);
procedure DivC (Cl,C2:Complex;var R:Complex);
procedure WriteC(C:Complex);
implementation
{ Полные описания процедур
(с сокращенными заголовками) }
procedure InitC;
begin
with C do
begin
Re:=R; Im:=I
end
end;
procedure AddC;
begin
with R do
begin
Re := Cl.Re + C2.Re;
Im := Cl.Im + C2.Im
end
end;
procedure MultC;
begin
with R do
begin
Re := Cl.Re*C2.Re+Cl.Im+C2.Im;
Im := Cl.Im*C2.Re+Cl.Re*C2.Im
end
end;
procedure DivC;
var
Tmp : real;
begin
with C2 do Tmp:=Re*Re+Im*Im;
with R do
begin
Re := (Cl.Re*C2.Re+Cl.Im*C2.Im)/Tmp;
Im := (C2.Re*Cl.Im+Cl.Re*C2.Im)/Tmp
end
end;
procedure WriteC;
begin
with С do
begin
Write(Re);
if Im=0 then Exit;
if Im>0 then Write(’+’);
Write(Im);
Write('i')
end
end;
end.
Таким образом, механизм модулей позволяет скрыть детали реализации тех или иных программных подсистем,
предоставив в распоряжение использующих программ стро го определенную совокупность интерфейсных объектов. Ес ли необходимо, например, расширить модуль CmplVals вве дением новых процедур или изменить реализацию какой-ли бо процедуры, то если интерфейс модуля при этом останется неизменным, такая модификация НИКАК НЕ ОТРАЗИТСЯ на использующих программах.
Модуль компилируется точно таким же образом, как и обы чные подпрограммы; возможна компиляция из интегриро ванной среды или с помощью компилятора командной стро ки. Но так как модуль не является непосредственно выпол няемой единицей, то в результате его компиляции образует ся дисковый файл с расширением .TPU (Turbo Pascal Unit), при этом имя файла берется из имени файла с исходным тек стом модуля.
Для того, чтобы получить доступ к интерфейсным объек там модуля, необходимо указать в программе имя нужного ТРU-файла. Соответствующая конструкция называется спе цификацией используемых модулей и имеет следующий об щий вид:
uses U1, U2, U3;
где uses - служебное слово, U1, U2, UЗ - идентификаторы ис пользуемых модулей. Эта спецификация должна идти непо средственно после заголовка программы; если некоторый модуль использует объекты другого модуля, то такая специ фикация должна следовать сразу после служебного слова interface.
При наличии спецификации использования в данной про грамме считаются известными все описания из интерфей сной части подключенного модуля. К интерфейсным объектам модуля можно обращаться в программе точно так же, как если бы они были описаны в самой этой программе.
Следующий пример иллюстрирует использование модуля CmplVals:
program DaingComplex;
uses
CmplVals;
var
C1, C2, C3 : Complex;
begin
InitC(1,2,C1); InitC(3,4,C2);
MultC(C1,C2,C3); WriteC(C3);
DivC(C1,C2,C3); WriteC(C3)
end.
Необходимо особо отметить следующие важные момен ты, связанные с использованием модулей:
1. Может случиться так, что идентификаторы интерфейсной части используемого модуля частично пересекаются с идентификаторами использующей программы. В этом случае действует следующее правило видимости имен: ин терфейсные идентификаторы модуля, указанного первым в uses-списке, образуют самый внешний блок программы; интерфейсные идентификаторы второго модуля образуют блок, вложенный в первый блок, и т.д. Если, например, в программе имеется спецификация вида uses А, В; то вложенность блоков выглядит так:
Таким образом, идентификаторы внешнего блока про граммы будут "экранировать" одноименные идентификаторы модулей А и В; аналогично, идентификаторы модуля А будут перекрыты одноименными идентификаторами модуля В.
Однако, существует возможность доступа к интерфейсу используемого модуля несмотря на наличие в программе одноименных идентификаторов. Пусть имеется следую щий модуль:
unit А;
interface
var
X:real;
implementation
...
end.
Далее, пусть программа, использующая этот модуль, так же содержит переменную X:
program Р;
uses А;
var X : integer;
begin
...
end.
Для того чтобы в программе Р иметь доступ к интерфейс ной переменной X из модуля А, необходимо задать состав ное имя, структура которого похожа на селектор поля за писи:
А.Х
Здесь А - имя модуля, X - идентификатор его интерфейс ной переменной. В этом случае конфликт имен снимается, так как простое указание имени X будет означать обраще ние к соответствующей переменной из программы Р, на пример: А.Х := Round(X);
2. Возможны случаи косвенных использований. Например, пусть имеются два модуля:
|
unit A; interface . . . end. |
unit B; interface uses A; . . . end. |
Если некоторая программа использует модуль B, то в со ответствующей спецификации использования необходимо указать только модули, НЕПОСРЕДСТВЕННО используе мые в программе. В данном примере достаточной являет ся следующая спецификация:
program P;
uses В;
. . .
end.
(Необходимо отметить, что в фирменной документации по системе Turbo Pascal можно встретить и противопо ложное требование, согласно которому в спецификации использования должны быть указаны ВСЕ модули, прямо или косвенно используемые программой. Однако из прак тики видно, что компилятор правильно обрабатывает программы, в спецификации использования которых ука заны только модули, непосредственно используемые ею).
3. Схема использования модулей может образовывать древо видную структуру любой сложности, но при этом недопу стимо явное или косвенное обращение модуля к самому себе. Так например, следующие отношения являются оши бочными:
|
unit A; interface uses B; . . . end. |
unit B; interface uses A; . . . end. |
Однако допускается взаимное использования модулей, поз воляющее ослабить указанное ограничение. В этом случае спецификация использования может указываться в разделе реализации. Такая возможность используется сравнительно редко и в настоящем описании не приводится.
4. Если в модуле имеется раздел инициализации, то операто ры из этого раздела будут выполнены ПЕРЕД началом вы полнения программы, в которой используется данный мо дуль. Если программа использует несколько модулей, то их разделы инициализации будут выполнены в том же по рядке, в котором эти модули перечислены в специфика ции использования.
Особенности модулей требуют несколько более подробного рас смотрения вопросов, связанных с их компиляцией и использова нием. Для случая компиляции программы никак не оговарива ется связь имени в заголовке программы и имени дискового файла, содержащего эту программу; так как сам заголовок явля ется необязательным, такая связь не имеет смысла.
В отличие от программ, заголовок модуля несет семанти ческую нагрузку, так как программа или другой модуль, ис пользующие данный, могут ссылаться на него в uses-специ фикации. С другой стороны, при трансляции программы, использующей модули, компилятор должен каким-то обра зом отыскать коды этих модулей, чтобы подключить их к компилируемой программе. Поэтому принято за правило, что имя файла, содержащего исходный текст модуля, долж но совпадать с именем этого модуля (расширение имени файла при этом несущественно, но по умолчанию предполагается .PAS). Компилятор помещает код модуля, получен ный в результате трансляции, в файл с таким же именем и расширением .TPU. При трансляции же программы, исполь зующей этот модуль, компилятор ищет ТРU-файл с именем, заданным в uses-спецификации, и связывает его с кодом программы. Таким образом, в спецификации использования фактически задаются не имена модулей, а имена файлов, их содержащих.
Например, для спецификации
uses MyUnit;
помещенной в некоторой программе, компилятор перед трансляцией самой программы должен найти дисковый файл с именем MYUNIT.TPU; в этом файле должен находить ся код модуля с заголовком вида
unit MyUnit;
Если все-таки необходимо хранить код модуля в файле с другим именем, то можно использовать директиву $U для переопределения имени файла. Эта директива имеет пара метр, который трактуется как "настоящее" имя файла с дан ным модулем. Она должна находиться непосредственно пе ред именем модуля в спецификации использования. Напри мер, конструкция
uses {$U MY) MyUnit;
приведет к тому, что компилятор будет искать код модуля MyUnit в дисковом файле MY. TPU.
При трансляции программы или модуля, использующего другие модули, компилятор последовательно отыскивает файлы, содержащие коды используемых модулей, с тем что бы подключить их к компилируемой программе. При этом компилятор работает по следующей схеме:
1) Компилятор просматривает содержимое системного биб лиотечного файла модулей TURBO.TPL (Turbo Pascal Library). Этот файл будет кратко описан далее в этом раз деле.
2) Если искомый модуль не найден в файле TURBO. TPL, то компилятор осуществляет поиск соответствующего TPU-файла в ТЕКУЩЕМ каталоге.
3) Если в текущем каталоге нужный файл не найден, то по иск продолжается в каталогах, заданных в альтернативе Options/ Directories/Unit Directories для интегри рованной среды или в параметре /U вызова ТРС–компилятора.
4) Если на предыдущих шагах файл не найден, то компиля тор прекращает работу и выдает диагностическое сообще ние об ошибке.
5) Если компилятор активизирован посредством альтерна тив Compile/Make или Compile/Build, то вышеуказан ные шаги проводятся в поисках ИСХОДНЫХ ТЕКСТОВ ис пользуемых модулей, которые будут оттранслированы перед трансляцией самой программы. При этом подразуме вается, что имя файла с текстом модуля совпадает с име нем модуля и имеет расширение .PAS.
Как было указано, первый шаг компилятора при поиске используемых модулей состоит в анализе системного файла TURBO.TPL. Этот файл имеет специальную структуру и пред назначен для компактного хранения и быстрого доступа к наиболее часто используемым модулям. Обычно в этом фай ле содержатся несколько системных (стандартных) модулей, однако с помощью специальной служебной программы TPUMOVER можно произвольным образом конструировать файл TURBO.TPL, включая в него нужные модули и удаляя неиспользуемые.
Понятие библиотеки модулей является потенциально удобным, но к сожалению, Turbo Pascal поддерживает только один библиотечный модуль; нельзя сформировать библиоте ку модулей в некотором TPL-файле и обеспечить подключе ние к программе модулей из этой библиотеки.
Turbo Pascal имеет восемь стандартных модулей, в которых, собственно, и содержатся все упоминаемые в книге систем ные процедуры и функции. Имена этих модулей следующие:
SYSTEM
DOS
CRT
PRINTER
OVERLAY
GRAPH
TORBO3
GRAPHS
Программные ресурсы, сосредоточенные в стандартных модулях, образуют мощные пакеты системных средств, кото рые обеспечивают высокую эффективность и широкий спектр применений системы Turbo Pascal.
Каждый модуль хранится в одноименном TPU-файле в сис темном каталоге Turbo Pascal. Кроме того, обычно модули System, Dos, Crt, Printer и Overlay входят в состав сис темного библиотечного файла TURBO. TPL. Для того, чтобы воспользоваться ресурсами стандартного модуля, необходимо указать его имя в спецификации использования по обычным правилам. Исключение сделано для модуля System, имя кото рого можно не указывать, так как содержащиеся в нем ресурсы подключаются автоматически к любой программе.
Каждый стандартный модуль содержит логически связан ную совокупность типов, констант, переменных и подпро грамм, относящихся к определенной области применений. Да лее приводится общая характеристика стандартных модулей.
В модуль System входят все процедуры и функции автор ской версии языка Pascal, подпрограммы стандартного Пас каля, а также много дополнительных подпрограмм общего характера, в частности, ориентированные на конкретную операционную среду.
Модуль Dos содержит средства доступа к операционной системе и по существу является программным представлени ем системного интерфейса MS-DOS.
Модуль Crt обеспечивает практически полный спектр возможностей для доступа к экрану дисплея в текстовом ре жиме. Кроме того, в данный модуль включены средства чте ния информации с клавиатуры (включая расширенные коды клавиш) и простейшего управления звуком.
Модуль Printer содержит единственный интерфейсный элемент - переменную Lst стандартного типа text, системно связанную с логическим устройством PRN (то есть с печатаю щим устройством, если оно имеется в конфигурации). Испо льзование этой переменной в стандартных процедурах Write и WriteLn приводит к выводу информации на печать.
Модуль Overlay предоставляет средства для организа ции так называемых оверлейных программ, позволяющих обеспечить достаточно эффективное выполнение больших программных систем, размер которых превышает объем до ступной оперативной памяти.
Модуль Graph объединяет многочисленные программ ные средства управления графическим режимом работы дис плея. Данный модуль обеспечивает использование всех воз можностей наиболее распространенных типов дисплейных адаптеров - CGA, EGA, VGA, Hercules и т.п. как для монохро мных, так и для цветных дисплеев, и позволяет создавать раз нообразные и эффективные графические программы.
Модули Turbo3 и Graph3 обеспечивают совместимость с данной версией системы Turbo Pascal тех программ, кото рые были разработаны для ранней версии 3.0.
В данном разделе содержится законченный пример модуля, в котором сосредоточены средства работы с памятью типа "стек". Обратите внимание, что способ конкретной реализа ции стека скрыт в разделе implementation; поэтому переход к другой реализации стека (не в виде массива, а, например, в виде связанного списка) не повлечет за собой необходимость изменения программ, использующих этот модуль (эти про граммы "не узнают" о таком изменении).
unit StackOps; { Операции над стеком целых }
interface
procedure Push ( Elem:integer );
function Pop : integer;
function Empty : boolean;
function Full : boolean;
implementation
{ Стек реализован в виде линейного массива элементов;
переменная Тор отмечает текущую вершину стека }
const
Мах = 100;
var
Stack array[1..Max] of integer;
Top : integer;
procedure Push; { помещение элемента в вершину стека }
begin
if Top>Max then Exit;
Stack[Top] := Elem;
inc(Top)
end;
function Pop; { извлечение элемента из вершины стека }
begin
Рop := 0 ;
if Top=1 then Exit;
dec(Top);
Pop := Stack[Top]
end;
function Empty; { проверка на пустоту стека }
begin
Empty := (Top=1)
end;
function Full; { проверка на заполненность стека }
begin
Full := (Тор>Мах)
end;
begin
{ инициализация: первоначально стек пуст }
Тор := 1
end.
В данном заключительном разделе приводятся синтаксичес кие диаграммы для конструкций, рассмотренных в этой гла ве. Кроме того, здесь показана полная синтаксическая диа грамма для программы.
Программа
Модуль
Заголовок модуля
Интерфейс модуля
Спецификация использования
Элемент интерфейса
Реализация модуля
Элемент реализации
Инициализация модуля