Модулями в языках программирования называют программные элементы, группирующие
определение алгоритмов, данных, типов в относительно цельную по смыслу группу.
Основным назначением модуля является создать такой элемент программы, чтобы он находился по иерархии между отдельной функцией и библиотекой так, чтобы перенос или использование такого элемента означало цельный перенос и готовность использования в другой программе. Отличие модуля от просто набора функций состоит в том, что модуль содержит также и определения некоторых данных. Эти данные могут быть как внутренними служебными данными модуля и невидимыми из других частей программы, так и общими данными, предоставленными другим частям, или функциям. Понятие модуля в модульных языках выражается также в виде синтаксической конструкции - файл, как единица трансляции, или набор файлов. В случае, если такой файл содержит служебные данные, то он уже может называться не просто набором функций, а уже модулем.
Кроме того, в модульных языках присутствует операция инициализации начальных значений данных модуля. Все модульные средства разработки так или иначе поддерживают понятие программы как цели сборки - в результате написания программистом кода должно получиться полное определение программы, ее алгоритмов и используемых данных.
При этом данные модуля в случае его использования в программе автоматически входят в данные программы. Современные компоновщики (линкеры) могут не включать в получаемую программу неиспользуемые данные или функции, даже если они объявлены в модуле. Используется ли определенная функция или пременная модуля или нет, это линкер определяет по списку взаимозависимостей.
Наличие специальных соглашений о порядке инициализации данных, объявленных модулем, означает, что перед выполнением кода, указанного программистом, программа автоматически вызывает код инициализации данных, или загружает их в память из файла с программой.
К модульным языкам относятся как компилирующие, так и интерпретирующие, или скриптовые. В случае применения интерпретатора необходимо, либо чтобы среда разработки поддерживала объединение модулей для среды исполнения так, чтобы при запуске программы среда исполнения выполнила код инициализации модулей, либо один из основных файлов итоговой программы должен вызвать определенные функции (или директивы в зависимости от языка), чтобы указать среде исполнения на применение определенных модулей.
В языке MUMPS модулей в таком определении как они используются в модульных языках, нет. Фактически, процесс в MUMPS системе не имеет такой организации кода, чтобы что-то можно было назвать единым словом "программа", или подпрограмма. Какой код является или, правильнее сказать, используется как подпрограмма или программа или библиотека функций, целиком определяется выполнением процесса.
Сервер хранит лишь совокупность алгоритмов, описанных в рутинах, и совокупность данных. Процесс может начать выполнение с любой рутины и с любой метки в любой рутине. При этом отсутствует такое понятие, как процесс инициализации используемых модулей.
Более того, если процесс вызвал рутину, то это вовсе не означает, что рутина может определить свои собственные данные, не хранимые на диске в глобалах. Рутина может использовать локальные переменные процесса, но у процесса не может быть несколько переменных, принадлежащих только рутине.
Довольно сложно представить себе ситуацию, чтобы рутина взяла и самостоятельно автоматически определила набор переменных и чтобы процесс при запуске начал автоматически, а не по описанному разработчиком алгоритму, проводить работу по инициализации этих переменных. На сервере при эксплуатации крупных программных систем могут присутствовать тысячи рутин, и один только процесс запуска такой программы может занять длительное время. Кроме того, если множество рутин просто будет содержать (даже неинициализированными) немного собственных данных, которые должны входить в пространство запускаемого процесса, то это автоматически вызовет расход памяти до того, как она в действительности понадобится.
Если в программах клиентского класса это является совершенно нормальным из-за жесткой детерминированности общего порядка выполнения кода, то для программных систем серверного класса так не принято делать. Вместо того, чтобы поддерживать понятие модуля, поддерживается понятие функции. В отдельных случаях для практичности разработки и переноса отдельные функции могут быть перенесены пакетом. Но для разработки программ клиентского класса (запускаемый процесс точно определен по перечню функций, которые предстоит исполнить, то есть полное определение программы) модульная стратегия разработки, несомненно, чрезвычайно практична, поскольку намного проще на клиентских местах использовать несколько отдельных программ, собранных из модулей, чем полный набор из тысяч отдельных функций, которые могут быть вызваны в любое время и из любого места.
И в MUMPS системах, и в SQL системах, и во многих других системах серверного класса сознательно избегают применения понятия модуль в том виде, как он используется в системах клиентского класса. Например, в SQL системах поддерживается понятие таблицы безотносительно привязки к алгоритмам хранимых процедур, и, в зависимости от версии SQL системы, понятие пакета хранимых процедур. И наоборот, произвольная хранимая процедура может быть вызвана независимо от наличия остальных процедур. Хотя, конечно, если она использует другую, но отсутствующую, то при выполнении произойдет ошибка.
При необходимости соблюдать в MUMPS системах модульный подход требуется также, как и в модульных языках, выделить следующие элементы:
К программным системам, промежуточным между серверными и клиентскими, могут быть отнесены так называемые сервера приложений, которые с одной стороны являются серверными частями для клиентского презентационного слоя, и, одновременно, клиентскими для слоя СУБД. В таких серверах приложений при использовании модулей, содержащих собственные данные с инициализацией, требующей времени, и наблюдается задержка времени при старте процесса. Кроме того, если сервера приложений используют существенные объемы внутренних данных (например, у модуля может быть буфер для форматирования значений), такие сервера приложений в случае крупной системы могут требовать очень большой памяти и выделения под такой сервер приложений отдельного компьютера.
В случае использования MUMPS систем разработчики именно их же возможности и используют в качестве серверов приложений, поскольку язык MUMPS является полноценным алгоритмическим, поддерживает множество способов ввода-вывода и содержит средства эффективного доступа к хранимым данным.
При построении серверов приложений на MUMPS системе разработчики автоматически получают масштабируемость такого сервера приложений и его переносимость на уровне самой используемой СУБД. Кроме того, в таких серверах приложений, что важно, отсутствует этап сложной трансформации данных между получением их с диска в слой самого сервера приложений.
В случае же использования сервером приложений в качестве временных данных глобалов возможности такого сервера приложений по обработке больших объемов ограничиваются не оперативной памятью, а дисковой. При этом сервер приложений для таких временных данных получает автоматически те же средства кеширования и высокоэффективного доступа для обработки огромных объемов, что и слой хранения данных в СУБД.
Подробнее о книге "MUMPS СУБД"
Основным назначением модуля является создать такой элемент программы, чтобы он находился по иерархии между отдельной функцией и библиотекой так, чтобы перенос или использование такого элемента означало цельный перенос и готовность использования в другой программе. Отличие модуля от просто набора функций состоит в том, что модуль содержит также и определения некоторых данных. Эти данные могут быть как внутренними служебными данными модуля и невидимыми из других частей программы, так и общими данными, предоставленными другим частям, или функциям. Понятие модуля в модульных языках выражается также в виде синтаксической конструкции - файл, как единица трансляции, или набор файлов. В случае, если такой файл содержит служебные данные, то он уже может называться не просто набором функций, а уже модулем.
Кроме того, в модульных языках присутствует операция инициализации начальных значений данных модуля. Все модульные средства разработки так или иначе поддерживают понятие программы как цели сборки - в результате написания программистом кода должно получиться полное определение программы, ее алгоритмов и используемых данных.
При этом данные модуля в случае его использования в программе автоматически входят в данные программы. Современные компоновщики (линкеры) могут не включать в получаемую программу неиспользуемые данные или функции, даже если они объявлены в модуле. Используется ли определенная функция или пременная модуля или нет, это линкер определяет по списку взаимозависимостей.
Наличие специальных соглашений о порядке инициализации данных, объявленных модулем, означает, что перед выполнением кода, указанного программистом, программа автоматически вызывает код инициализации данных, или загружает их в память из файла с программой.
К модульным языкам относятся как компилирующие, так и интерпретирующие, или скриптовые. В случае применения интерпретатора необходимо, либо чтобы среда разработки поддерживала объединение модулей для среды исполнения так, чтобы при запуске программы среда исполнения выполнила код инициализации модулей, либо один из основных файлов итоговой программы должен вызвать определенные функции (или директивы в зависимости от языка), чтобы указать среде исполнения на применение определенных модулей.
В языке MUMPS модулей в таком определении как они используются в модульных языках, нет. Фактически, процесс в MUMPS системе не имеет такой организации кода, чтобы что-то можно было назвать единым словом "программа", или подпрограмма. Какой код является или, правильнее сказать, используется как подпрограмма или программа или библиотека функций, целиком определяется выполнением процесса.
Сервер хранит лишь совокупность алгоритмов, описанных в рутинах, и совокупность данных. Процесс может начать выполнение с любой рутины и с любой метки в любой рутине. При этом отсутствует такое понятие, как процесс инициализации используемых модулей.
Более того, если процесс вызвал рутину, то это вовсе не означает, что рутина может определить свои собственные данные, не хранимые на диске в глобалах. Рутина может использовать локальные переменные процесса, но у процесса не может быть несколько переменных, принадлежащих только рутине.
Довольно сложно представить себе ситуацию, чтобы рутина взяла и самостоятельно автоматически определила набор переменных и чтобы процесс при запуске начал автоматически, а не по описанному разработчиком алгоритму, проводить работу по инициализации этих переменных. На сервере при эксплуатации крупных программных систем могут присутствовать тысячи рутин, и один только процесс запуска такой программы может занять длительное время. Кроме того, если множество рутин просто будет содержать (даже неинициализированными) немного собственных данных, которые должны входить в пространство запускаемого процесса, то это автоматически вызовет расход памяти до того, как она в действительности понадобится.
Если в программах клиентского класса это является совершенно нормальным из-за жесткой детерминированности общего порядка выполнения кода, то для программных систем серверного класса так не принято делать. Вместо того, чтобы поддерживать понятие модуля, поддерживается понятие функции. В отдельных случаях для практичности разработки и переноса отдельные функции могут быть перенесены пакетом. Но для разработки программ клиентского класса (запускаемый процесс точно определен по перечню функций, которые предстоит исполнить, то есть полное определение программы) модульная стратегия разработки, несомненно, чрезвычайно практична, поскольку намного проще на клиентских местах использовать несколько отдельных программ, собранных из модулей, чем полный набор из тысяч отдельных функций, которые могут быть вызваны в любое время и из любого места.
И в MUMPS системах, и в SQL системах, и во многих других системах серверного класса сознательно избегают применения понятия модуль в том виде, как он используется в системах клиентского класса. Например, в SQL системах поддерживается понятие таблицы безотносительно привязки к алгоритмам хранимых процедур, и, в зависимости от версии SQL системы, понятие пакета хранимых процедур. И наоборот, произвольная хранимая процедура может быть вызвана независимо от наличия остальных процедур. Хотя, конечно, если она использует другую, но отсутствующую, то при выполнении произойдет ошибка.
При необходимости соблюдать в MUMPS системах модульный подход требуется также, как и в модульных языках, выделить следующие элементы:
- Какая совокупность рутин в данный момент называется программой.
- Какие локальные переменные должен использовать модуль.
- Какой префикс должен быть у локальных переменных модуля (предназначенные для использования модулем).
- Какой код должен быть вызван при старте программы для выполнения инициализации локальных данных модулей.
К программным системам, промежуточным между серверными и клиентскими, могут быть отнесены так называемые сервера приложений, которые с одной стороны являются серверными частями для клиентского презентационного слоя, и, одновременно, клиентскими для слоя СУБД. В таких серверах приложений при использовании модулей, содержащих собственные данные с инициализацией, требующей времени, и наблюдается задержка времени при старте процесса. Кроме того, если сервера приложений используют существенные объемы внутренних данных (например, у модуля может быть буфер для форматирования значений), такие сервера приложений в случае крупной системы могут требовать очень большой памяти и выделения под такой сервер приложений отдельного компьютера.
В случае использования MUMPS систем разработчики именно их же возможности и используют в качестве серверов приложений, поскольку язык MUMPS является полноценным алгоритмическим, поддерживает множество способов ввода-вывода и содержит средства эффективного доступа к хранимым данным.
При построении серверов приложений на MUMPS системе разработчики автоматически получают масштабируемость такого сервера приложений и его переносимость на уровне самой используемой СУБД. Кроме того, в таких серверах приложений, что важно, отсутствует этап сложной трансформации данных между получением их с диска в слой самого сервера приложений.
В случае же использования сервером приложений в качестве временных данных глобалов возможности такого сервера приложений по обработке больших объемов ограничиваются не оперативной памятью, а дисковой. При этом сервер приложений для таких временных данных получает автоматически те же средства кеширования и высокоэффективного доступа для обработки огромных объемов, что и слой хранения данных в СУБД.
Подробнее о книге "MUMPS СУБД"
Комментариев нет:
Отправить комментарий