М.М. ГОРБУНОВ-ПОСАДОВ - Системное обеспечение пакетов прикладных программ (1184225), страница 4

Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 4)

Теперь проблемнаяориентация языка заданий выражалась не только используемой мнемоникой,но главным образом специальными языковыми макроконструкциями,позволяющими компактно и наглядно формулировать основные фазыпроцессов решения задач из конкретной предметной области. Такого родаидеология разработки языков заданий, называемых иногда встроенными иливложенными, имеет и теперь очень много сторонников и получила широкоераспространение в практике построения так называемых модульных системразличной проблемной ориентации. Причиной такой популярностивстроенных языков, хотя они и требуют от пользователя хороших навыков впрограммировании, по-видимому, является тот разумный компромисс,который легко достигается между выразительной силой расширяющих языкмакроконструкций и стоимостью их системной реализации [41,42].Следующий этап развития языков заданий пакетов характеризуетсяпоявлением самостоятельных (т.е. не связанных ни с какими языкамипрограммирования) проблемно-ориентированных или специализированныхязыков заданий [17,43,44].

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

указывает, «чтоделать»), а меньшая - описанием процесса решения этой задачи (т.е.определяет, «как делать»).Концепция проблемно-ориентированных языков, основанных нааппарате специализированных программирующих программ, былапредложена В.М.Глушковым еще в 1959г. [45]. Однако только в рамкахработ по пакетной проблематике она получила свое практическоевоплощение. Это объясняется тем, что большая семантическаянасыщенность конструкций проблемно-ориентированного языка требуетразвитых программных средств для их реализации. В пакете указаннаятрудность преодолевается за счет удачного структур-ного решения: основная нагрузка ложится на модули функциональногонаполнения, программно реализующие знания о вычислениях, проводимых впредметной области, а интерпретация задания сводится к вызовусоответствующих модулей и организации информационных связей междуними.В настоящее время получило распространение создание пакетов спомощью специально разработанных для этой цели инструментальнобазовых систем, т.е.

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

языком для описания языков),посредством которого определяются синтаксис и семантика языка заданийкаждого создаваемого пакета. Этот подход в случае достаточно развитогометаязыка обеспечивает значительную независимость инструментальнобазовой системы от приложений и позволяет определять совершенноразличные по форме языки заданий пакетов [49,50].Средства системного наполнения развитого пакета берут свое начало отпервых компилирующих и интерпретирующих систем, которыеавтоматизировали процессы сборки основной программы пользователя изотдельных частей и включения в нее библиотечных подпрограмм [51-54].В первых специализированных системах программирования и пакетахпрограмм (например, [18,55]), языки заданий которых совпадали с базовымиязыками программирования, для этих целей использовались либо отдельныесредства штатного программного обеспечения, такие как компиляторы,макрогенераторы, редакторы внешних связей, редакторытекстов, либо основанные на них многофункциональные системыавтоматизации программирования [56,57].

Однако уже в первых пакетахфункции системного наполнения не ограничивались только организациейвзаимодействия пакета с перечисленными выше компонентами штатногопрограммного обеспечения, а распространялись также и на специфическиепроцессы в работе пакета. Например, в специализированной системепрограммирования HYDRA с помощью системных подпрограмм решалисьвопросы динамического распределения оперативной памяти, формированияспецифичных структур данных и доступа к ним, а также организациивзаимодействия модулей.В дальнейшем, с появлением большего разнообразия форм охватапредметной области, получили распространение языки заданий,включающие в себя средства поддержки всего диапазона действий,выполняемых проблемным программистом при решении конкретных задач.Оказалось, что специализация языка позволяет существенно повыситьпроизводительность труда проблемного программиста на любом этапе егоработы. Реализация такого подхода потребовала подключения широкогонабора средств системного программирования, состав которых характерен идля других современных форм пакетов [15,34,58-61].Действительно, знакомство с внутренними структурами этих пакетовпозволяет выделить такие ставшие уже традиционными составляющиесистемного наполнения (рис.2):- резидентный монитор, осуществляющий интерфейс как междуотдельными компонентами системного наполнения, так и между ними иштатным программным обеспечением;трансляторвходныхзаданий,формирующийвнутреннеепредставление задания и реализуемый обычно в виде макрогенератора илипрепроцессора;- интерпретатор внутреннего представления задания;- архив функционального наполнения (подсистема храненияпрограммного материала);- банк расчетных данных (подсистема хранения начальных ипромежуточных данных, а также результатов расчетов);- монитор организации вычислительного процесса (взаимодействиемодулей по данным и управлению);- планировщик вычислительного процесса, который определяетпоследовательность выполнения модулей, реализующую задание пакету;мониторорганизацииинтерактивноговзаимодействияспользователем.В различных пакетах перечисленные компоненты получили разнуюстепень развития, иногда просто отсутствовали, реализовывались наоснове различный системных подходов и по-разному назывались(терминология в пакетной проблематике, к сожалению, не вполнеустановилась).

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

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

Характеристики

Список файлов книги