ISSN 0236-235X (P)
ISSN 2311-2735 (E)

Публикационная активность

(сведения по итогам 2017 г.)
2-летний импакт-фактор РИНЦ: 0,500
2-летний импакт-фактор РИНЦ без самоцитирования: 0,405
Двухлетний импакт-фактор РИНЦ с учетом цитирования из всех
источников: 0,817
5-летний импакт-фактор РИНЦ: 0,319
5-летний импакт-фактор РИНЦ без самоцитирования: 0,264
Суммарное число цитирований журнала в РИНЦ: 6012
Пятилетний индекс Херфиндаля по цитирующим журналам: 404
Индекс Херфиндаля по организациям авторов: 338
Десятилетний индекс Хирша: 17
Место в общем рейтинге SCIENCE INDEX за 2017 год: 527
Место в рейтинге SCIENCE INDEX за 2017 год по тематике "Автоматика. Вычислительная техника": 16

Больше данных по публикационной активности нашего журнале за 2008-2017 гг. на сайте РИНЦ

Вход


Забыли пароль? / Регистрация

Добавить в закладки

Следующий номер на сайте

4
Ожидается:
16 Декабря 2018

Интеллектуальный транслятор — новая парадигма в системах программирования

Статья опубликована в выпуске журнала № 1 за 1996 год.[ 20.03.1996 ]
Аннотация:
Abstract:
Авторы: Валькман Ю.Р. () - , , , Свистов А.Я. () - , ,
Ключевое слово:
Ключевое слово:
Количество просмотров: 8694
Версия для печати

Размер шрифта:       Шрифт:

Традиционные системы программирования: структура, реликтовые принципы, "узкие места ", неэффективность

Назначение любой технологии программирования (ТП) состоит в инструментальном обеспечении процесса изготовления программных изделий [4]. И любая ТП опирается на си-стему программирования (СП) — комплекс средств, обеспечивающих автоматизацию процессов программирования и отладки программ.

В качестве инструментальных средств в СП пользователям предоставляются: редактор текстов, транслятор, редактор связей, библиотека стандартных функций и процедур и отладчик. Для системного программиста — это объекты разработки. С помощью данных средств прикладным программистом обеспечивается (автономное!) проведение операций: ввода и/или редактирования текста программы на входном языке; трансляции ее в объектный код; сборки программного комплекса; выполнения (и отладки) программ на ЭВМ.

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

• Все четыре компоненты СП ничего не знают друг о друге, в частности об используемых и порожденных соседями структурах, текстах.

Так, редактор текстов не знает, с одной стороны, синтаксиса и семантики операторов языка программирования, с другой — структур и типов данных, объектов и классов, эксплицируемой (формализуемой) программистом в рамках создаваемого модуля информации.

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

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

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

• Вследствие всего этого процесс отладки программы существенно затягивается. Программист вынужден снова и снова возвращаться каждый раз к первой операции (редактированию текста программы). И вновь проходить все операции последовательно по циклу. А ведь если бы редактор текстов знал синтаксис соответствующего языка программирования, то он бы мог не только определить множество ошибок, но иногда и самостоятельно отредактировать их. Не говоря уже об идентификации данных, их типов, структур. И транслятор, зная, какое изменение редактором текста было внесено последним, мог бы компилировать только связанные с редакцией фрагменты, а не транслировать заново всю программу. Это же касается и редактора связей, и отладчика. Может ли последний выполнить лишь фрагмент программного модуля, например с одного определенного оператора по другой? Сколько времени бы сэкономилось, но, главное, интеллектуальных усилий программистов.

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

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

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

•  Очень непростыми в традиционной СП являются процессы поддержки развития программных комплексов. Чаще всего (особенно если специалисты уволились) программные модули, в которые необходимо внести изменения, переписываются не всегда с учетом всех их информационных и управляющих связей, но часто с соответствующими последствиями. Инструментария для локализации всех процедурных (модулей) и декларативных (данных) объектов, связанных с вносимым изменением, в СП нет.

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

Поскольку в центре проблемы создания новых технологий программирования находится транслятор, а целью проекта является, с одной стороны, интеграция всех процессов системы программирования в рамках одного комплекса, с другой — погружение в вычислительную среду максимума знаний, то представляется правомерным назвать проект ИНТЕЛЛЕКТУАЛЬНЫЙ ТРАНСЛЯТОР.

Концепции и принципы создания новой системы программирования

Основой разработки новой СП являются две базовые идеи, две концепции:

à         представление синтаксиса и семантики алгоритмических конструкций и структур данных в формате трех взаимосвязанных уровней, по аналогии с известной идеологией ANSI/SPARC [10];

à         использование для создания языка концептуального уровня методологии фреймовых конструкций [7] и формального аппарата соответствующей алгебры [3].

В соответствии с архитектурой ANSI/ SPARC в СП ИНТЕЛЛЕКТУАЛЬНЫЙ ТРАНСЛЯТОР любая программная конструкция (описание объекта, операция, процедура и т.п.) различных языков программирования и конкретных программных комплексов проходит три уровня представления: внешний (представление на конкретном языке, например С++ или PASCAL), концептуальный (представление на языке фреймов в обобщенном формате), внутренний (представление в памяти ЭВМ в машинном формате). СП реализует отображение операторов различных алгоритмических языков в фрейм-представление, затем отображение фреймов в вычислительную среду ЭВМ. И наоборот, фрейм-конструкции — в операции различных языков.

Роль концептуальной схемы в СП та же, что и в идеологии ANSI/SPARC— обобщение точек зрения пользователя на проблему. Однако есть ряд существенных отличий.

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

*     Во-вторых, пользователей СП можно разделить также на два класса: алгоритмические языки (и другие средства проектирования и программирования) и разрабатываемый программный комплекс.

Таким образом, с учетом приведенных факторов структуру СП можно условно представить в виде графической формы, изображенной на рисунке 1.

В рассматриваемой СП выделяются два слоя. К верхнему слою относится все множество программных конструкций алгоритмических языков и других средств программирования. Они разделяются на два класса: описание данных и процедур. Двунаправленная стрелка на рисунке 1 означает, что, с одной стороны, процессы используют данные, с другой — данные используются процессами. Применение методологии объектно-ориентированного программирования (ООП) [1] эту границу несколько размывает, так как в описании объектов и классов декларируются их методы и процедуры.

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

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

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

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

В [9] под фреймом-прототипом (ФП) понимается фрейм, у которого в части слотов (или во всех слотах) отсутствуют константные значения. Фреймы-прототипы описывают знание о предметной области. В СП разработана система ФП, каждый фрейм которой соответствует определенному оператору алгоритмического языка. Система ФП хранится и обслуживается в специальной библиотеке.

На верхнем уровне все ФП можно (в соответствии с рис. 1) разделить на ФП характеристик типов и структур данных и ФП операторов обработки. Далее следует выделить: ФП-

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

Наконец, ИНТЕЛЛЕКТУАЛЬНЫЙ ТРАНСЛЯТОР компилирует фрейм-программу в машинное представление — адресное пространство ЭВМ.

•Теперь рассмотрим подробнее концептуальный уровень (ядро системы). Поскольку обсуждаются проблемы интеллектуализации процессов программирования, то вполне правомерен выбор в качестве базового средства концептуализации одного из самых конструктивных формализмов, используемых в системах представления знаний в искусственном интеллекте (ИИ) [6] — фрейма.

объекты, ФП-классы, ФП-операторы, ФП-функции, ФП-процедуры. Дальнейшее деление (до оператора), по-видимому, надо делать с ориентацией на алгоритмические языки и операционные системы (например для WINDOWS: ФП-функции-Сгеаtе, ФП-функции-Gеt, ФП-функции-Load, ФП-функции-Set и т.д.).

Вполне очевидно, что априори до установления каких-либо связей программистом при реализации конкретного модуля ФП имеют четко выраженную иерархическую структуру (которая потом программистом трансформируется в сетевую). Поэтому на множестве ФП можно выделить: ФП-родители и ФП-потомки. Таким образом, в СП классификация фреймов многокритериальна, и один ФП по различным критериям может принадлежать разным классам. Поэтому библиотека ФП, поддерживая такие структуры и классификаторы, фактически трансформируется в БДиЗ ФП.

При написании программы пользователь в такой среде выбирает адекватные его проблеме

ФП и обозначает их (заполняет их слоты). Отлаженная программа представляет собой сеть фреймов-экземпляров (ФЭ) [9], которую правомерно, с одной стороны (с учетом того, что каждая дуга в соответствующем графе играет четко определенную роль), назвать "раскрашенной семантической сетью" [2], с другой (учитывая, что на ней определяются различные траектории выполнения программы в зависимости от значений исходных данных) — ситуационной сетью сценария [8] выполнения программы.

• На рисунке 2 представлена схема архитектуры СП в общем виде и автоматизированные рабочие места (АРМ) различных классов пользователей, точнее, редакторы-конструкторы, которые они используют в качестве инструментальных средств.

Посредством конструктора-редактора (1) проектировщики ФП анализируют различные предметные области, языки программирования, средства проектирования, стандарты на интерфейсы, операционные системы, методы и технологии программирования, системы управления базами данных и знаний, библиотеки стандартных функций и процедур и т.п., проектируют системы фреймов-прототипов для описания декларативной (в частности классов и объектов данных) и процедурной компонент, отлаживают их, апробируют и записывают в БДиЗ (1). Для отображения операторы алгоритмических языков → ФП используется отдельная специализированная БДиЗ (4) (пока для языков С++ и PASCAL). При этом, естественно, используется информация об их семантике и синтаксисе. В процессе отладки и эксплуатации системы фреймов-прототипов (1) может понадобиться их редактирование (удаление некорректных и неиспользуемых ФП, их модификация). Это тоже функции данного инструментального средства.

Посредством следующего инструментального комплекса (2) фрейм-программисты разрабатывают фрейм-программы. При этом используются системы ФП из БДиЗ (1), они означиваются, строятся фрейм-объекты и фрейм-классы, фрейм-процедуры и т.п., то есть реализуется программный продукт в среде фрейм-конструкций. Этот проект записывается в БДиЗ (2). В процессе отладки с помощью соответствующих операций осуществляется его редактирование. Заметим, все операции выполняются конструкторами-редакторами (1) и (2) в интерактивном режиме. Копия отлаживаемой программы в машинных кодах записывается в БД(3).

Инструментальный комплекс конструктор-редактор (3) осуществляет выполнение программы и запись результатов (тестовых данных, информацию о сбоях) сначала в БДиЗ (3), затем в БДиЗ (2). Выполнение программы осуществляется под управлением фрейм-программистов также в интерактивном режиме.

Пользователи первого класса (по крайней мере, вначале) работают по старинке. В рамках ИНТЕЛЛЕКТУАЛЬНОГО ТРАНСЛЯТОРА

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

Затем в соответствии с технологией программирования, принятой в СП для этого класса пользователей, текст отлаживаемой программы (на языках С++ или PASCAL) передается на вход конструктора-редактора (4). На его другой вход передаются фрейм-конструкции в форме ФП из БДиЗ (4). Фактически для каждого оператора алгоритмического языка конструктор-редактор "подбирает" соответствующий ФП и осуществляется трансляция (означивание фреймов: ФП ® ФЭ) программы на С++ или PASCAL в фрейм-программу, и она записывается в БДиЗ (2) и БД (3). Конструктор-редактор (4), таким образом, работает автоматически (без участия пользователей).

Включение в СП двух инструментальных комплексов (5) и (4) и двух информационных объектов (4) и (5) преследует три цели.

=> Во-первых, программисты первого класса будут постепенно осваивать средства нового СП и самостоятельно определять его преимущества, удобства, эффективность работы и целесообразность перехода на новую технологию - тем самым обеспечивается преемственность.

=> Во-вторых, конструктор-редактор (4) может работать и в инвертированном режиме, то есть транслировать тексты программ, написанных фрейм-конструкциями в их тексты на алгоритмических языках (разумеется, при условии, что каждому ФЭ текста программы определен адекватный оператор алгоритмического языка). Таким образом можно осуществлять конвертацию текста программы, например на С++ в PASCAL-текст, или наоборот.

=> В-третьих, в настоящее время наработано великое множество широко используемых и популярных программных проектов, которые нуждаются в модификации. И нам представляется, что необходимые доработки намного легче производить посредством ИНТЕЛЛЕКТУАЛЬНОГО ТРАНСЛЯТОРА. Но тогда эти проекты нужно погрузить в его среду.

И это первые (принципиально новые!) качества СП ИНТЕЛЛЕКТУАЛЬНЫЙ ТРАНСЛЯТОР.

Новая технология программирования:

новые качества, эффективность

использования

Изложенные функции и средства СП ИНТЕЛЛЕКТУАЛЬНЫЙ ТРАНСЛЯТОР обеспечивают переход программных комплексов на принципиально новую технологию проектирования.

* В новой среде программист не пишет операторы, а выбирает ему необходимые ФП, заполняет их слоты и связывает фреймы. Таким образом, синтаксические ошибки невозможны. Используемые в слотах идентификаторы фрейм-операций и данных проверяются на корректность конструктором-редактором (2) непосредственно после ввода (на основании информации, хранимой в БДиЗ проекта, уже введенной ранее). Проверяется и корректность используемых типов данных. Поэтому и семантические ошибки во многом исключены. Таким образом, программист может полностью акцентировать свое внимание на решаемой проблеме, знания синтаксиса и семантики операторов языков ему не нужны.

* Создаваемую программу можно разрабатывать фрагментарно, оставляя трудноформализуемые части на потом. Но можно и выполнять только определенные фрагменты, отлаживая их по мере готовности. Когда-то такие процессы выполнения программ А.П. Ершов назвал полу вычислениями [4]. Таким образом, трансляция программы сводится к означиванию фреймов и синтезу машинных кодов. Редактирование программы заключается в замене фреймов и/или значений их слотов. При этом транслируются только те фрагменты программы, которые в процессе редактирования были модифицированы. Поэтому время трансляции практически незаметно. И этап компиляции трансформируется в СП в процесс проверки семантической целостности проекта после ввода, изменения или удаления фрейм-операции, фрейм-объекта, фрейм-класса и т.д.

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

* СП, как и положено интеллектуальной системе, является полиглотом. Она в состоянии, как уже говорилось, не только понимать в принципе любой язык (необходимо только для него подготовить соответствующую БДиЗ (4) и конструктор-редактор (4)) (рис. 2), но и переводить программы с одного языка на другой, например С++ в PASCAL и т.д. Таким образом, пользователь может видеть свои продукты, выраженные в различных языках программирования. Кроме этого, он при желании может посмотреть и машинное представление своей программы.

* СП значительно облегчает процессы модификации программных проектов. Поскольку фрейм-конструкции в БДиЗ проекта (2) содержат все необходимые идентификаторы, то программисту в интерактивном режиме предоставляются все фрагменты программ и данных, связанных с изменяемой частью (в данном случае с ФЭ-процессом или ФЭ-данными, фреймами-объектами, классами).

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

* Фрейм-конструкции описания структур и типов данных представляют собой (совместно с конструктором-редактором (2)) весьма технологичный инструмент разработки схем(структур) баз данных и знаний.

Посредством фреймов удобно описывать ограничения целостности предметной области, а с помощью конструктора-редактора (2) осуществлять трансляцию семантических и прагматических триггеров целостности в синтаксические фильтры. Принципиально то, что СП обеспечивает единый инструмент, в котором сочетаются все три аспекта: синтаксис, семантика и прагматика. И не только для декларативной компоненты (БДиЗ), но и для процедурной (операционной части программных комплексов).

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

* В [5] В.Д. Ильин определяет жизненный цикл программ цепочкой замысел-задача-программа. Представляется целесообразным его расширить: предметная область (проблема)-цель-замысел-задачи-программный комплекс. Ранее в этой цепочке (точнее иерархической структуре) был разрью, который породил создание автономных (относительно процессов программирования) средств спецификации программ. С нашей точки зрения, СП ИНТЕЛ-ЛЕКТУАЛЬНЫЙ ТРАНСЛЯТОР ликвидирует этот разрыв.

С использованием СП весь проект, от цели, сформулированной вербально на верхнем уровне, до ФЭ программного комплекса, представляется в форме пирамиды. Принципиально то, что эта пирамида строится постепенно различными программистами (и системоаналитиками (спецификаторами) в процессе развития проекта средствами ФП (хранимыми в БДиЗ (1)) и проектировщика-редактора (2) и поддерживается в актуальном состоянии в БДиЗ (2).

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

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

* Известно, что в процессе разработки различных проектов опытные программисты, как правило, создают собственные инструментальные комплексы, которые постепенно находят воплощение в их проблемно-ориентированном специализированном АРМе. Конструкторы-редакторы (1) и (2) предоставляют широкие возможности для таких процессов. Так, пользователи могут создать себе целую БДиЗ фреймов-прототипов для самых различных применений. Такие системы фрейм-конструкций (аналогичные макрооператорам) позволят им манипулировать готовыми блоками данных и действий при реализации новых проектов, что значительно повысит эффективность их создания (как по времени, так и по качеству — в ФП отображаются апробированные и отлаженные конструкторские решения).

В настоящее время СП ИНТЕЛЛЕКТУ-

АЛЬНЫЙ ТРАНСЛЯТОР разрабатывается в Constellation Prodject LTD (Израиль). В основу его реализации положены принципы и проектные решения, здесь изложенные.

Список литературы

1.    Буч Г. Объектно-ориентированное проектирование: с примерами применения. - М.: Конкорд, 1992. — 519 с.

2. Вагин В.Н. Дедукция и обобщение в системах принятия решений. — М., 1983. — 366 с.

3. Вольфенгаген В.Э., Яцук В.Я. Алгебра на фреймах для манипулирования знаниями// Изв. АН СССР. Сер. Техническая кибернетика. — 1984. — №5. — С. 4-14.

4. Ершов А.П. Опыт интегрального подхода к актуаль-ой проблематике программного обеспечения// Кибернетика. —1984. —№3. —С. 3-19.

5. Ильин В.Д. Система порождения программ. — М.: Наука,-1989. —264 с.

6. Искусственный интеллект. — В 3-х кн. — М.: Радио и связь.— 1990.

7. Минский М. Структура для представления знаний // Психология машинного зрения. — М.: Мир, 1978. — С. 249-338.

8. Поспелов Д.А. Ситуационное управление// Теория и практика. — М.: Наука, -1986. — 284 с.

9. Толковый словарь по искусственному интеллекту. — М.: Радио и связь, -1992. — 256 с.

10.    ANSI/ХЗ/SPARC Stady Group on Data BaseManagement Systems; Interin. Report FDT//Bull. АСМSIGMOD. — 1975. —7; № 12. — Р. 8-34.


Постоянный адрес статьи:
http://swsys.ru/index.php?page=article&id=1057
Версия для печати
Статья опубликована в выпуске журнала № 1 за 1996 год.

Возможно, Вас заинтересуют следующие статьи схожих тематик: