«В.Д. ИЛЬИН СИСТЕМА ПОРОЖДЕНИЯ ПРОГРАММ. Версия 2013 г. М.: ИПИ РАН, 2013 © В.Д. Ильин, 2013 ISBN 978-5-91993-030-3 Об издании УДК 004 + 336 ББК 32.973.26-018 Ильин, Владимир Дмитриевич. Система порождения программ. ...»

Федеральное государственное бюджетное учреждение науки

ИНСТИТУТ ПРОБЛЕМ ИНФОРМАТИКИ

РОССИЙСКОЙ АКАДЕМИИ НАУК

В.Д. ИЛЬИН

СИСТЕМА ПОРОЖДЕНИЯ

ПРОГРАММ.

Версия 2013 г.

М.: ИПИ РАН, 2013

© В.Д. Ильин, 2013 ISBN 978-5-91993-030-3 Об издании УДК 004 + 336 ББК 32.973.26-018 Ильин, Владимир Дмитриевич. Система порождения программ. Версия 2013 г.

[Электронный ресурс] = The System of program generating. Version 2013 :

[монография] : для специалистов в автоматизации программирования, разработчиков программных средств, преподавателей, аспирантов и студентов вузов / В. Д. Ильин.

— Электрон. текстовые дан. (1 файл). — М.: ИПИ РАН, 2013. — 1 электрон. опт. диск (CD-ROM); 12 см. — Систем. требования: компьютер типа десктоп, ноутбук, планшетный; процессор 800 Мгц; ОЗУ 512 Мб; операц. система Windows, OS X, Android, iOS; программа для просмотра pdf-файлов; видеосистема с диагональю экрана не менее 5 дюймов; стандартная акустическая система. — Загл. с экрана.

Монография посвящена проблеме автоматизированного конструирования программных систем с заданными характеристиками.

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

Приведено детальное описание её применения для конструирования пакетов программ в системе ГЕНПАК.

В версии 2013 г. представлены новые s-модели задачных конструктивных объектов и задачных графов.

Для описания s-моделей применена новая версия языка TSM.

Книга может быть полезна преподавателям, аспирантам и студентам вузов.

Электронное научное издание © Ильин Владимир Дмитриевич, Федеральное государственное бюджетное учреждение науки

ИНСТИТУТ ПРОБЛЕМ ИНФОРМАТИКИ

РОССИЙСКОЙ АКАДЕМИИ НАУК

В.Д. ИЛЬИН

СИСТЕМА ПОРОЖДЕНИЯ

ПРОГРАММ.

Версия 2013 г.

Москва

ИПИ РАН

© В.Д. Ильин, ISBN 978-5-91993-030-

ОБ АВТОРЕ

Ильин Владимир Дмитриевич Доктор технических наук, профессор.

Зав. лабораторией «Методологических основ информатизации» в Институте проблем информатики РАН.

Автор книг и статей по Sмоделированию, автоматизации программирования, методологии информатизации экономической деятельности и государственного управления, системам знании.

Книги, связанные методологией s-моделирования с этой монографией 1. Ильин А.В., Ильин В.Д. Основы теории s- моделирования. М.: ИПИ РАН, 2009, 143 с. – ISBN 978-5-902030-78- 2. Ильин А.В., Ильин В.Д. S-моделирование объектов информатизации. М.: ИПИ РАН, 2010, 412 с. – ISBN 978-5-902030-86- 3. Ильин А.В., Ильин В.Д. Символьное моделирование в информатике. М.: ИПИ РАН, 2011, 204 с. ISBN 978-5-91993-005- 4. Ильин А.В., Ильин В.Д. S-моделирование задач и конструирование программ. М.: ИПИ РАН, 2012, 146 с. – ISBN 978-5-91993-013- 5. Ильин В.Д. S-моделирование имущественного обмена. М.: ИПИ РАН, 2008, 80 с. – ISBN 978-5-902030-62- 6. Ильин В.Д. Модель нормализованной экономики. М.: ИПИ РАН, 2009, 125 с. – ISBN 978-5-902030-77- 7. Ильин В.Д. S-модель нормализованной экономической системы. М.: ИПИ РАН, 2010, 103 с. – ISBN 978-5-902030-79- 8. Ильин А.В., Ильин В.Д. S-экономика: механизм хозяйствования в эпоху Интернета. М.: ИПИ РАН, 2011, 105 с. – ISBN 978-5-902030-94- 9. Vladimir D. Ilyin. S-economics. M.: IPI RAN, 2012, 54 p. – ISBN 978-5-91993-017- 10. Ильин А.В. Экспертное планирование ресурсов. М.: ИПИ РАН, 2013, 58 с. – ISBN 978-5-91993-022- 11. Ильин А.В., Ильин В.Д. Научно-образовательные веб-ресурсы. S-моделирование. М.: ИПИ РАН, 2013, 110 с. – ISBN 978-5-91993-023- Содержание < УДК 004 + В.Д. Ильин Система порождения программ. Версия 2013 г.

– М.: ИПИ РАН, 2013. – с. 142 – ISBN 978-5-91993-030- Монография посвящена проблеме автоматизированного конструирования программных систем с заданными характеристиками.

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

Приведено детальное описание её применения для конструирования пакетов программ в системе ГЕНПАК.

В версии 2013 г. представлены новые s-модели задачных конструктивных объектов и задачных графов.

Для описания s-моделей применена новая версия языка TSM.

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

Книга может быть полезна преподавателям и студентам вузов.

Издано по решению Учёного совета Института проблем информатики Российской академии наук (ИПИ РАН) © В.Д. Ильин, ISBN 978-5-91993-030- Vladimir D. Ilyin The System of program generating. Version – M.: IPI RAN, 2013. – p. 142 – ISBN 978-5-91993-030- The monograph is devoted to the problem of computer-aided design of software systems with the specied characteristics.

The book describes the theoretical foundations of the methodology called I-generating the target software systems.

An example of the application of this methodology is the system GENPAK which is described in detail.

New s-models of the task constructive objects and task graphs are presented in the version of 2013.

New version of the TSM-language is used to describe s-models.

For professionals in the automation of programming and software developers.

The book can be useful to university teachers and students.

Issued by decision of the Academic Council of Institute for Informatics Problems, Russian Academy of Sciences (IPI RAN) © Vladimir D. Ilyin, ISBN 978-5-91993-030- Содержание < Содержание Программирование поведения символьных автоматов: проблема продуктивности Программное обеспечение автоматизированной разработки программV Объектно-ориентированный подход к программированиюV Генераторы приложений и сервис-ориентированные архитектурыV И-порождение: конструирование целевых программных системV Содержание < Конструирование разрешающих структур на задачных графахV Конструирование табс-представленных целевых системV Прототипы целевых систем: средство накопления задачных знанийV Интерактивный преобразователь ресурсов: пример реализации И-порожденияV РЕСУРС-комплекс: архитектура, характеристика реализации, оценка Содержание < Предисловие Но запросы продолжались: интересовавшиеся попрежнему давали поисковым машинам задание О содержании В книге представлен (с рядом исправлений, сокращений и дополнений) материал монографии В.Д. Ильин. Система порождения программ. М.: Наука, 1989, с.264 ISBN 5-02-006578-1.

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

Представлено описание системы порождения ГЕНПАК, ориентированной на продуцирование пакетов программ для решения задач учёта и планирования (ГЕНПАК относится к семейству ИГЕНгенераторов).

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

О судьбе книги «Система порождения программ»

"Система порождения программ" - первая монография В.Д. Ильина, опубликованная в 1989 в издательстве "Наука".

В эти дни (ноября 2013 г.) её можно найти не только в основных библиотеках России и бывших республик СССР, но и в крупнейших библиотеках США, Великобритании и Германии.

С 1990 ссылки на эту книгу можно встретить в научных работах разного назначения, связанных с автоматизацией программирования.

URSS — российская издательская группа научной и учебной литературы (монографий, журналов, сборников трудов институтов РАН и др.) - через свой интернет-магазин принимает заказ на продажу этой книги.

Крупнейшая в мире (по обороту) американская компания, занимающаяся интернетторговлей - amazon.com - тоже пытается продавать эту книгу.

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

Содержание < Примеры таких сайтов:

• http://www.bookarchive.ru/computer/programming/other_programm/234819-sistema-porozhdenijaprogramm.html • http://www.twirpx.com/le/1044788/ • http://2programmers.com/news/read/Sistema-porozhdenija-programm.html • http://mirknig.com/knigi/programming/1181593667-sistema-porozhdeniya-programm.html • http://www.kodges.ru/komp/program/188890-sistema-porozhdeniya-programm.html • http://www.takelink.ru/knigi_uchebniki/knigi_komputernie/179697-ilin-vd-sistema-porozhdeniyaprogramm.html В Российской государственной библиотеке (Ленинке):

"Система порождения программ" (вторая в подборке, включающей 12 из 15 опубликованных (с 1988 по 2012) монографий (9), препринтов (5) и учебных пособий (1) В.Д. Ильина.

Содержание < Содержание < Даже в библиотеке Эстонии, "решительно порвавшей с советским прошлым", хранят эту книгу [официальный положительный отзыв на "Систему порождения программ" в 1990 г. написал проф. Энн Тыугу (автор книги "Концептуальное программирование")].

Замечания о части результатов, представленных в [Ильин В.Д. 1989, 1] 1. Часть аналитического обзора средств автоматизации программирования содержит материал, читая который следует помнить, что написан он был в 1989.

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

Содержание < Введение Построение целевой системы относится к задачам автоматизации разработки программного обеспечения.

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

Её архитектура рассчитана на объединение нескольких систем в целевую систему более высокого уровня.

Существует возможность получить новую систему как сужение исходной.

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

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

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

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

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

Языки взаимодействия с порождающей системой — это интерактивные формоориентированные языки описания порождаемой системы.

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

О реализации Только реализация может обнаружить невидимые до неё недостатки и подтвердить существование достоинств.

Поэтому была разработана система ГЕНПАК порождения пакетов программ.

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

Содержание < Экспериментальная версия была написана на Паскале и работала под управлением ОС РАФОС 2.

Такой выбор языка и операционной системы не означает, что они хороши для этой цели.

Они использованы лишь потому, что к началу разработки существовал задел в виде системы ДИЭКС [Барышников, Ильин В.Д. и др.].

Некоторые компоненты ДИЭКСа предполагалось применить в новой системе.

Ещё менее пригодным для такой разработки был комплекс УВК СМ 1407.01.

Конечно, ещё до начала реализации была готовность поменять ОС РАФОС 2 на Unix, Паскаль на Си, а УВК СМ 1407.01, например, на одну из моделей VAX 8000.

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

О представлении материала Стремлением к компактному изложению объясняется графическое представление части материала.

Для этого используется форма определений, описание которой дано в разделе о TSM-комплексе.

[Рисунки, полученные сканированием бумажного экземпляра монографии, могли бы выглядеть получше (исполнителю заказа, очевидно, не хватило умения)].

Содержание < TSMкомплекс средств описания sмоделей  TSMкомплекс средств описания sмоделей (англ. TSM) – расширяемый набор средств унифицированного описания sмоделей систем понятий и систем знаний.

Включает средства одноуровневой записи формул, выделения частей гипермедийных описаний s-моделей и замены выбранными сокращениями часто повторяющихся фрагментов.  Первая версия TSM была предложена при работе над теорией порождения программ, где TSM служил средством записи спецификаций задачных конструктивных объектов [Ильин В.Д. 1989, 1].

Изложенная здесь версия содержит ряд синтаксических улучшений варианта TSM, развитого в [Ильин А.В. 2007].

Одноуровневые TSMописания соответствуют стилю, принятому в языках программирования.

Для TSM-описаний достаточно стандартной клавиатуры и набора специальных символов, имеющихся в составе текстовых редакторов Word (пакета MS Ofce), Pages (пакета iWork), Writer (пакетов LibreOfce или OpenOfce) или др., что существенно для успешного развития TSM.

Универсализации TSM способствовало применение этого комплекса при формировании образовательных ресурсов и разработке системы знаний информатики СИНФ.

Уровни фрагментов описания  Фрагмент TSMописания – часть описания, включающая не менее одного полного абзаца (без заголовка или с заголовком).  Выделяется косыми (slashes), размещаемыми в начале фрагмента: /k/ (k – номер уровня вложенности).

Для первого и второго уровней значения k не указываются (/ – первый уровень вложенности; // – второй); для третьего и последующих уровней можно указывать (начало фрагмента третьего уровня можно обозначить как /// или как /3/).

Выделения Для выделения определений, замечаний, примеров, имен понятий и отдельных частей описания используются следующие средства:

   часть описания с фиксированными в ее пределах обозначениями (здесь и далее символ заменяет слово означает);

   утверждение (определение, аксиома и др.);

   замечание;

   пример;

Содержание <    рекомендация или комментарий составителя описания;

{SS}  здесь набранный курсивом текст (может быть пустым), который следует интерпретировать как расширенный префикс s- для выделенных курсивом элементов списка;

 {S-модельS} – здесь расширенным префиксом служит sмодель;

{SS} – здесь префикс s- .

Курсивом могут быть выделены:

• первые вхождения названий понятий [определяемых или определённых (последние могут быть гиперссылками)];

• фрагменты описания, к которым автор хочет привлечь внимание;

• формулы.

Сокращения Для часто повторяющихся названий понятий:

СМ символьное моделирование;

S-моделирование СМ произвольных объектов в человекомашинной среде;

s-машина машина, помогающая создавать и применять sмодели;

s-среда совокупность взаимодействующих людей и управляемых ими s-машин, предназначенная для решения задач S-моделирования.

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

Формулы Для теоретико-множественных и других формул применяется одноуровневая форма записи.

/ Индексы, пометы Не накладывается никаких ограничений на максимальное число индексов для переменных и помечающих символов (помет).

Все индексы и пометы записываются в строчку внутри квадратных скобок, следующих сразу за индексируемой (или/и помеченной) переменной.

Индексы, определяющие элемент массива, отделяются запятыми, индексированные индексы – косой чертой «/».

Верхний индекс от нижнего отделяется точкой с запятой «;». Если в описании индекса точка с запятой не встречается, то индекс считается нижним. Если сразу после точки с запятой стоит закрывающая вертикальная черточка, то — задан только верхний индекс.

 x[out; j=1…n]  вектор x из n компонент, имеющий помету out;

a[inp; i=1...m, j=1...n]  матрица a размера m*n, имеющая помету inp;

c[; 1]  c-один со штрихом (штрих «» – верхняя помета, 1 – нижний индекс);

Содержание < d[j/i;]  d с верхним индексированным индексом j i-тое (чтобы показать отсутствие нижних индексов, поставлена точка с запятой, за которой сразу следует закрывающая вертикальная черточка);

d[j/i]  d с нижним индексированным индексом j i-тое (отсутствие точки с запятой указывает на отсутствие верхних индексов) .

/ Теоретико – множественные a: elem A  a является элементом множества A;

a, b: elem C  a, b — элементы множества С (число элементов, разделённых запятыми, может быть любым);

A: set a  A – множество, содержащее элемент a;

AA  B содержит A;

AE  A содержит E или совпадает с E;

AB  объединение множеств A и B;

AB  пересечение множеств A и B;

A\B  разность множеств A и B;

A*B  декартово произведение множеств A и B;

RA * B  бинарное отношение, заданное на множествах A и B.

Символ 0 обозначает пустое множество или нуль (в зависимости от контекста);

cимвол # обозначает «не равно».

 Если x: elem X, y: elem Y и x = y, то x: elem (X  Y);

если X: set x, Y: set y и пара (x, y): elem R, где RA*B, то (X*Y)(A*B)#0.  / Функции Аргументы функции размещаются в круглых скобках, стоящих сразу за идентификатором, обозначающим функцию.

 f(x)  f от x; f[max;](x[i=1…n])  f с верхней пометой max от x[i = 1...n].  При записи операций символы «+», «–«, «*», «/» обозначают соответственно сложение, вычитание, умножение, деление, а символ «**» – возведение в степень.

Для записи суммы вместо символа «» используется «sum»; при этом индекс суммирования, его начальное и конечное значения записываются в квадратных скобках справа от «sum».

 sum[i=1...n]x[i]  сумма x[i] по i от 1 до n.  Типы: специализация и обобщение  Тип X  множество X, элементы которого имеют фиксированные набор атрибутов и семейство допустимых операций.

Может иметь подтипы, называемые специализациями типа X, и надтипы, называемые обобщениями типа X.  Содержание < / Специализация типа  Специализация типа X – порождение подтипа X[::rule] (здесь сдвоенное двоеточие «::» — символ специализации) с семейством связей, расширенным добавлением связи rule.

Выделяет подмножество X[::rule] множества X.

Специализацией называем и результат X[::rule] этого порождения (X>X [::rule]).  // Специализация типа, заданная последовательностью добавленных связей X[::(rule1)::rule2] – специализация типа X[::rule1] по связи rule2.

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

/ Обобщение типа  Обобщение типа Z – это порождение его надтипа Z[rule] путём ослабления (здесь # – символ ослабления) связи rule из семейства связей, соответствующей типу Z.

Исключение связи считаем её предельным ослаблением.  Графическая форма записи определений Как обычно, определение даётся путём построения дерева атрибутов изучаемого понятия.

Сначала атрибуты перечисляются, а затем, в свою очередь, определяются (если это необходимо).

Листьями так построенного дерева являются терминальные атрибуты (не требующие в данном контексте дальнейшего определения).

Другой способ описания понятия — указание на понятия, связанные с определяемым.

Важной особенностью введённой формы определения понятий являются средства явного указания на ТОЧКУ ЗРЕНИЯ (КОРРЕСПОНДЕНТА, которому адресовано определение), СТАДИЮ (на которой в процессе изучения или работы определение может быть полезно) и ЦЕЛЬ (в процессе достижения которой определение имеет смысл).

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

Важность явного указания точки зрения не требует пространного комментария:

достаточно заметить, что масса недоразумений при определении понятий и их истолковании значительно уменьшилась, если бы авторы точно указывали, КОМУ, на какой СТАДИИ и для какой ЦЕЛИ может пригодиться определение.

Предложенная форма не требует изображения дерева атрибутов определяемого понятия в виде графа.

Определение выглядит как последовательность взятых в рамку утверждений.

Часть площади внутри рамки отведена для значений ТОЧКИ ЗРЕНИЯ (если по контексту эти значения неясны).

Все утверждения, размещённые в рамке, имеют одинаковую структуру:

|| @ ||.

Содержание < Левая и правая части ограничены вертикальными чёрточками, а связывающий их символ @ принимает одно из трёх следующих значений: @ = (:, ->, ~).

Первое значение ":" (двоеточие) является заменителем слова "это".

Утверждение вида || : || означает, что текст справа рассматривается как определяющий (основанный на известных понятиях) по отношению к тексту слева, содержащему определяемое понятие.

Второе значение "->" (стрелка) заменяет слова "связано с".

Утверждение вида || -> || истолковывается, как "определяемое понятие (слева) связано с другими (важными в данном контексте) понятиями (справа).

И, наконец, значение " ~ " (эквивалентность) используется для переобозначения определяемого понятия.

То есть утверждение вида || ~ || означает, что справа введено обозначение того, что имеем слева.

Содержимое, заключенное между вертикальными чёрточками, может быть текстом, графическим изображением или их сочетанием.

Никаких синтаксических ограничений, накладываемых на представление такого содержимого, предложенная форма не вводит.

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

Опыт показал, что эта форма определений позволяет не только экономно расходовать ресурс восприятия читателя.

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

Применимость TSM рассчитан на создание строчных одноуровневых описаний sмоделей посредством QWERTY-клавиатуры.

Применим при sмоделировании объектов любой предметной области.

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

Оно делает потенциально короткой по времени и уникальной по эффективности цепочку: замысел — его символьное воплощение — реализация в виде задуманного поведения автомата.

К сожалению, пока только потенциально.

Процесс символьного воплощения замысла в виде сегодняшней разработки программного обеспечения никак не назовёшь коротким по времени.

Из-за этого остаётся лишь потенциальной и уникальная эффективность всей цепочки.

Её среднее звено является критическим.

С тех пор как существует программирование, программисты ищут способы повышения производительности своего труда.

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

Естественно, что первыми в деле сохранения, накопления и применения знании с помощью s-машин стали разработчики программных средств.

Уже на начальных этапах развития программирования (вместе с языками и трансляторами) они стали создавать различные библиотеки программ.

За вопросами «Как объединить подобные библиотеки?» и «Как добавлять в них апробированные программы?» последовал вопрос «Какои должна стать система знании о программируемых задачах, чтобы служить основанием автоматизации программирования?»

Наряду с другими ответами на подобные вопросы (на основе опыта успешнои реализации и применения генератора программ для создания, обработки и представления табличных структур [Ильин В.Д. 1987]) автором был предложен подход к построению программ как интерактивному конструированию из задачных конструктивных объектов.

В системе автоматизированного конструирования программ (названнои системои порождения программ [Ильин В.Д. 1989, 1]) система знании о программируемых задачах представлена в форме конструкции, построенных из задачных конструктивных объектов.

Основания для автоматизации любои деятельности тем значительнее, чем лучше она изучена и чем удачнее формализована её технология [Ильин А.В., Ильин В.Д. 2010].

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

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

[Manna, Waldinger 1971, 1981]).

Второе — теми, кто не считает программу формальным объектом и рассматривает её как сообщение, определяющее поведение автомата с заданными своиствами и Содержание < существующее в символьном, кодовом и сигнальном воплощениях, связанных отношениями трансляции.

Не станем приводить здесь аргументацию несостоятельности первого подхода: с нею можно ознакомиться в [Ильин А.В., Ильин В.Д. 2011].

Ограничимся цитированием аннотации доклада об автоматическом синтезе программ и структурном программировании, сделанного видными представителями первого направления [Lee, Chang]: «When a computer is used to synthesize a program, there is usually too much information for it to handle. In this paper, we propose the use of stepwise renement technique, based upon the concept of structured programming, to overcome this difculty.»

Представитель подходов второго направления (один из авторов системы LabVIEW [Conway, Watts]) Steve Watts удачно выразил его методологическую особенность: «A lot of techniques and methodologies get bogged down with computer science and forget about the design aspects; our intensions are to always concentrate on design and hopefully some of the computer science.»

Вполне естественно, что продуктивные идеи автоматизации программирования родились в среде программистов (такие, как идея модульного проектирования программ по принципу «сверху вниз», реализованная в технологии структурного программирования [Dijkstra]).

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

Системы программирования целесообразно связать с системами знании о программируемых задачах, а системы знании — между собои.

Исследователи, работающие в области автоматизации программирования, продолжают поиск способов повышения продуктивности.

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

Работа по расширению традиционных методов программирования продолжается.

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

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

Вслед за АПЛ появились такие языки как SETL, который позволяет программировать, пользуясь математическими понятиями.

Содержание < Важным этапом стала разработка пакетной проблематики как технологии решения задач.

Какая часть работы может быть поручена системе?

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

Велико стремление ряда исследователей [Darlington; Broy] представить процесс конструирования программ как последовательность формальных преобразований.

Ведётся поиск методов построения генераторов программ, пользующихся растущим спросом [Horowitz, Kemper, et al; Luker, Burns; Ильин В.Д. 1986, 1987].

Разрабатываются языки и системы спецификации [Агафонов; Бежанова].

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

Не сдаёт своих позиций Лисп, применение которого для решения задач автоматизации программирования является традиционным.

В частности, Лисп успешно используется в задачах синтеза программ по образцам поведения.

Новый подход к программированию, обозначившийся ещё в языке Симула-67, окреп и утвердился с появлением языка Смолток-80.

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

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

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

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

Естественно, что вместе с тем иначе толкуется и понятие программирование.

Программы, написанные в кодах машины, имели единственное лицо.

Оно было одним и тем же и для программиста, и для машины (с точностью до двоичного представления в ней).

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

Теперь у нее стало два лица.

Их соответствие осталось пока взаимно-однозначным.

Здесь еще не возникли проблемы ошибок перевода и потери эффективности.

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

Настало время построения трансляторов.

Время борьбы с ошибками перевода и потерей эффективности.

Число лиц у одной и той же программы возросло.

Возникает вопрос: чем больше лиц у одной и той же программы, тем выше уровень автоматизации процесса её разработки?

Ответить просто — да — вряд ли правильно.

Поэтому скажем, что это связанные вещи.

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

При этом они берут на себя и тонкую задачу предвидения того, что будет полезно и удобно программисту.

Чем меньше они оставляют программисту, тем выше, естественно, становится производительность его труда, но тем ограниченнее его возможности повлиять на некоторые детали.

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

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

Описание, понятное ему и воспринимаемое системой.

Остальное доделала бы система, руководствуясь этим описанием.

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

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

Тогда необходимо будет иметь много специализированных систем.

Сделаем еще шаг: представим, что мы объединили бы все такие системы, создав среду, где программирование в его традиционном смысле уступило бы место процессу, больше похожему на просмотр того, чем располагает среда, постановку ей вопросов, изучение её ответов, и только после этого — постановку задачи, которую среда должна представить в виде программы.

Построение решения исходной задачи среда выполняла бы путем представления ее в виде совокупности задач с известными решениями.

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

Идея создания такой среды явилась отправной для постановки задачи порождения целевых систем.

Содержание < На поиск метода её решения наибольшее влияние оказали опыт автора в разработке генераторов прикладных программ [Ильин 1986, 1987, 1989] и идеология объектноориентированного программирования.

Содержание < Автоматизация разработки программ: обсуждение Является ли программирование как деятельность процессом решения задач?

Вряд ли кто-то на такой вопрос ответит отрицательно.

Какие задачи приходится решать, создавая программу?

Этот вопрос вызовет гораздо большие затруднения, чем первый.

Предположим, что и на него удалось получить ответ: что-нибудь в духе Структура данных + алгоритм = программа.

Будем неотступны: как выглядит постановка каждой из задач?

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

Продолжим работу и поинтересуемся тем, как мы решаем эти задачи.

Какую часть решения приходится изобретать каждый раз заново, а какую мы берем с соответствующей полки нашей памяти?

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

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

Первые могут относиться к разным предметным областям, вторые - к собственно программированию.

Что у этих задач общего и в чем различие между ними, если нас интересует возможность поручить автомату решение не только первых, но и вторых?

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

Различие - в степени изученности.

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

Его доступность и похожесть на привычное для всех написание текстов создают иллюзии.

Диапазон иллюзий велик: от программирования для всех до программирования — искусства избранных.

И все-таки программа остаётся всего лишь описанием решения некоторой задачи, рассчитанным на восприятие автоматом.

Независимо от того, может или нет её создатель представить спецификацию задачи, которую он запрограммировал.

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

Наверное, поэтому вошёл в обиход стиль разработки, для которого характерен приоритет действия над осознанием цели, ради которой оно совершается.

Нигде нет такого простора для псевдорешений не полностью осознанных задач, как в программировании.

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

Содержание < Вспомним ещё раз историю пресловутой программы RANDU из библиотеки SSP, алгоритмическая некорректность которой была выявлена спустя много лет после начала её применения.

А сколько неразвенчанных RANDU-подобных программ продолжает своё существование, вводя в заблуждение тех, кто ими пользуется?

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

Итак, программирование как процесс решения задач требует исследования.

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

Обсуждаются и некоторые другие подходы.

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

Каждой предметной области, характеризующейся множеством понятий и отношений между ними, ставится в соответствие множество задач.

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

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

Но существует ведь и причина причин, объясняющая, почему возникают эти ошибки.

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

Ошибочность упования на один "самый лучший" язык (в смысле его приспособленности ко всем стадиям разработки) подтверждена не только неуспехом Ада-проекта.

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

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

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

Содержание < Это было не только тяжело и долго.

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

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

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

Настали времена постадийного разделения труда.

Времена изобретения баз знаний о программируемых задачах, языков спецификации и программирования, редакторов (включая графические — для образного представления программных конструкций), инструментальных систем, поддерживающих символьное воплощение замысла (без искажений при переходе от одной стадии разработки к следующей за ней) [Ильин В.Д. 1989, 1; Ильин А.В. 2007;

Conway, Watts ].

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

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

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

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

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

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

Если взялись за решение, то неизбежно возникает второй вопрос: какие у нас для этого основания? Собираемся ли мы исследовать каждую задачу, чтобы сначала найти алгоритм, а затем пройти отрезок пути, который связан с программной реализацией?

Предположим, что не видим в таком подходе ничего смущающего нас.

Тогда возникает третий вопрос.

Удастся ли нам обеспечить надлежащее качество и ту производительность труда, которая нас устраивает?

Ведь каждую задачу мы готовы разрабатывать как бы заново.

Представим альтернативный подход.

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

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

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

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

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

Замысел, задача, программа Осознание цели в процессе некоторой деятельности ещё не означает ясного представления о том, какие задачи должны быть решены для достижения цели.

Это справедливо и для разработки программного обеспечения.

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

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

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

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

Элементарный шаг в процессе символьного воплощения замысла 2 Символьное воплощение замысла (СВЗ) и проверка соответствия СВЗ замыслу

СООТВЕТСТВУЕТ НЕ СООТВЕТСТВУЕТ

3 Анализ состоятельности замысла с использованием СВЗ

ЗАМЫСЕЛ СТОИТ РЕАЛИЗОВАТЬ НЕОБХОДИМЫ ИЗМЕНЕНИЯ ЗАМЫСЛА

Реализация замысла в виде задуманного поведения среды Процесс разработки программы можно представить как пошаговое символьное воплощение замысла.

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

Известные затруднения при формировании замысла вызывает неинформированность о возможностях системы.

Трудно бывает определить её возможности.

Поэтому необходимо предварительное обучение "под руководством" системы и информационное обслуживание в процессе работы.

Изучая её возможности, разработчик формирует представление о пространстве допустимых замыслов.

Действуя таким способом, первый этап работы — формирование замысла с помощью системы — можно будет выполнить более успешно.

Эффективность символьного воплощения замысла зависит и от того, какие языковые средства поддерживает система.

Очень важно, как выглядит реализация языка: текст или графика, или их сочетание.

Всё это во многом определяет то, насколько успешным будет процесс символьного воплощения замысла.

Анализ синтаксической правильности берёт на себя система.

Но анализ правильности самого замысла, выполняемый путём изучения его символьного воплощения, — прерогатива человека.

Важно, чтобы система поддерживала определение точек зрения.

Содержание < Два взгляда на специфицирование описание задания на исследователя специфицирования программирование задач, неоднозначное исследование специфицирования как средства повышения толкование продуктивности программной реализации 2 Специфицирование ТОЧКА ЗРЕНИЯ задач с описанием спецификатора программируемых задач программной реализации Стадия:

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

Программа: точки зрения пользователя и разработчика Для пользователя программа служит средством решения задач предметной области.

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

Другая точка зрения у разработчика.

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

Содержание < Языки: средства повышения продуктивности Языковое направление в автоматизации разработки программ является изначальным и неразрывно связано со всеми остальными.

В каждом языке воплощается взгляд на то, как должно выглядеть символьное описание алгоритма решения задачи (в виде программы, рассчитанной на автомат).

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

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

Разработка языков и сред программирования (как и программирование решения задач) связана с изучением познавательных возможностей человека.

Интеллектуальное поведение связано с манипулированием символами.

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

Символьные сообщения позволяют в компактном виде определять понятия и связи между ними.

Если структура простых логических операций может быть проанализирована без помощи символьных записей, то структура сложных соотношений, как справедливо заметил Р. Ледли, "не может быть обозрена без употребления символов".

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

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

Содержание < Попытки объединить некоторое множество языков в языковую среду более продуктивны, чем попытки создать единый «большой язык».

Стремление к повышению уровня языков существует с тех пор, как существует программирование.

Сегодня в ходу словосочетание "язык очень высокого уровня".

Какие слова понадобятся завтра?

Еще нелепее то, что явно и неявно уровень языка связывается со степенью его непроцедурности: мол, чем более непроцедурным является язык, тем выше его уровень.

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

Это заблуждение иногда становится основой для рассуждений о том, что современная тенденция в развитии языков программирования связана с доктриной "ЧТО вместо КАК" (языки, позволяющие описать, ЧТО представляет собой задача, будто бы должны постепенно потеснить языки, предназначенные для описания алгоритма решения задачи, т.е. для ответа на вопрос КАК?).

Понятия ЧТО- и КАК-языков Языки описания постановок задач (будем называть их ЧТО-языками) так же необходимы, как и языки описания процессов решения задач (КАК-языки).

Они не являются конкурентами.

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

Итак, всегда будут необходимы языки разных уровней, как в классе ЧТО-языков, так и в классе КАК-языков.

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

Во многих случаях было бы удобно иметь в своем распоряжении семейство языков, в которое входили бы и ЧТО-языки (для описания постановок программируемых задач), и КАК-языки (для описания процесса их решения).

В качестве примера приведём следующее сопоставление.

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

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

Хотя АПЛ имеет хорошо определенную операционную семантику, он все-таки относится к языкам весьма высокого уровня в классе КАК-языков.

Содержание < Ощущение свободы от деталей при работе с АПЛ обеспечено такой важнейшей характеристикой, как УТАИВАНИЕ ПОДРОБНОСТЕЙ.

Можно уверенно говорить о том, что уровень языка тем выше, чем совершенней механизм УТАИВАНИЯ ПОДРОБНОСТЕЙ.

В частности, в АПЛ программист более свободен от деталей, чем в Паскале или Фортране.

Тогдашний триумф АПЛ во многом был, видимо, предопределен ясной позицией, которую имел К. Айверсон, начиная работу над созданием языка.

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

И хотя вначале АПЛ использовался только как предъязык для записи формулировок алгоритмов, которые затем вручную транслировались на выбранный язык программирования, уместно вспомнить, что именно с помощью АПЛ было сделано точное и компактное описание аппаратных средств IBM 360.

И все ныне существующие версии АПЛ так или иначе связаны с АПЛ/360.

Интерактивность и ориентация на обработку структур данных определили так называемый АПЛ-стиль программирования.

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

Однако многие программисты-профессионалы считают, что такие языки, как Си и Модула-2 более подходят для создания больших систем, предназначенных для алгоритмизируемых задач.

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

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

В классе ЧТО-языков влиятельное положение занял Пролог, основанный на исчислении предикатов первого порядка.

Создание этого языка и появление его многочисленных расширений ознаменовали завершение периода младенчества в развитии программирования.

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

Повышение уровня осознанности и доказательности при разработке программ - вот краткая характеристика Пролог-стиля программирования.

Не сдаёт своих позиций Лисп, основанный на Лямбда-исчислении.

Объектно-ориентированный подход к программированию Объектно-ориентированное программирование (ООП) [англ. Object-oriented programming (OOP) ] — это методология разработки программ для символьного моделирования с помощью компьютеров систем произвольного назначения, Содержание < представимых в виде совокупностей объектов, каждый из которых отнесён к определённому классу и наделён наборами данных (атрибутов объекта) и процедур (методов) их обработки. Классы объектов представлены в виде иерархии наследования атрибутов и методов.

С развитием символьного моделирования и усложнением моделируемых систем всё более явными становились недостатки методологий разработки программ с использованием процедурно-ориентированных языков программирования (Алгола, Фортрана и др.).

Это объясняется отсутствием в них средств, удобных для описания сложных систем, слабой поддержкой повторной применимости ранее разработанных программ и совместных разработок коллективами программистов.

В конце 1960-х был создан язык симула 67, ставший первым языком ООП.

В нём объединение данных и процедур их обработки было названо объектом, а совокупность схожих объектов — классом.

Среди языков ООП, созданных вслед за Simula 67, наиболее удачным признан Smalltalk80 (Смолток80), разработанный в конце 1970-х.

Его успех способствовал развитию и распространению концепции ООП: в начале 1980-х на основе языка C был создан C++; в середине 1980-х на основе Pascal — Object Pascal; в середине 1990-х был создан язык Java.

Основные понятия ООП Объект в ООП – это модель экземпляра определённого класса сущностей моделируемой системы.

Класс содержит определение данных и методов, являющихся общими для входящих в него объектов.

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

В иерархии наследования класс-потомок порождается путём добавления одного или нескольких атрибутов и\или методов к атрибутам и\или методам одного или нескольких классов-родителей.

Важнейшей особенностью ООП является возможность утаивания деталей реализации за интерфейсом класса (т.н. инкапсуляция).

Применение и перспективы развития Преимущества ООП особенно отчётливо проявляются при создании сложных программных систем, выполняемых коллективами разработчиков:

• одни могут проектировать функциональное поведение и структуру системы;

• другие — её составляющие и способы их взаимодействия;

• третьи — заниматься программной реализацией.

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

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

Прирастает семейство языков ООП, совершенствуются системы программирования, увеличивается число программ различного назначения (для Интернет-сервисов, систем мобильной связи и др.), разработанных на языках ООП (C++, Java и др.).

Парадигма ООП: основание продуктивного программирования Идеи объектно-ориентированного программирования работают и в предлагаемом здесь подходе к порождению пакетов программ.

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

В ней главная роль отведена созданию «программного объекта», понимаемого как некоторая структура данных с приписанными к ней процедурно-воплощёнными методами её обработки.

Каждый объект имеет память, предназначенную для описания его состояния.

Такое описание делается посредством задания значений атрибутов объекта.

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

Метод может вызывать как другие методы своего класса, так и доступные методы объектов других классов.

Атрибуты, параметры вызова и локальные переменные методов могут принадлежать как простым типам данных, так и другим классам объектов.

Тенденции развития Наметился серьезный поворот в переоценке роли текстовых языков.

Недостаток многих работ по автоматизации программирования предопределён стремлением к логически завершенному образу системы автоматизации программирования, в которой взаимодействие разработчика с системой осуществляется посредством текстовых сообщений.

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

Успех таких продуктов как dBase III (Ashton-Tate) во многом определяется отказом от упомянутой привычки в пользу табличных и графических форм.

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

Язык визуального программирования и языки формо-ориентированного программирования открывают новые возможности в разработке программ.

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

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

Графические и формо-ориентированные средства хорошо приспособлены для представления сути той или иной программы или системы программирования.

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

Рост качества терминалов и их удешевление способствует тому, что в ближайшее время доминирующее положение займут интерактивные языки.

Программирование в диалоге с системой станет таким же привычным, как сегодняшнее программирование наедине с собой.

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

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

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

Необходимо также освободить разработчика от управления распределением и перераспределением памяти.

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

Содержание < Повторное использование программ В этом разделе рассматриваются два подхода к повторному использованию программ в системах автоматизированной разработки: один из них основан на методологии, получившей название CAP (Computer Aided Programming - программирование с помощью ЭВМ) [Basset]; другой - на методологии, изложенной в [Polster].

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

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

Из-за этих деталей программу приходится изменять, подгоняя под новую область или условия применения.

Процесс подгонки не только трудоёмок, но и чреват трудно предсказуемыми побочными эффектами.

Зачастую он настолько непрост, что целесообразнее написать новую программу.

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

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

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

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

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

Главная проблема — в том, что процедура, обладающая значительной гибкостью на этапе выполнения, во время включения в вызывающую программу не обладает никакой гибкостью (понимаемой как приспособленность к изменениям).

Методология САР основана на идее функционального программирования и реализует подход к решению задач как к описанию области в некотором абстрактном пространстве функций.

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

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

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

Содержание < Каждой конкретной задаче присущи ограничения на область определения входных данных.

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

Назовем изменяющиеся ограничения степенями свободы.

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

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

Это множество может быть бесконечным и содержать константы и переменные как простейшие функции.

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

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

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

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

САР-система обеспечивает процесс удобного и эффективного объединения автоматически создаваемого текста программы с написанными вручную фрагментами.

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

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

Язык оптимально определяет функциональное пространство (а, следовательно, и связанный с ним класс задач) тогда и только тогда, когда выполняются следующие требования:

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

• степени свободы являются независимыми оптимально-специфицированными пространствами констант, переменных или функций;

• выражения языка максимально компактны.

На практике не удается достичь строгого соответствия языка перечисленным требованиям.

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

Для оптимального языка характерны спецификации задач.

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

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

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

В над-специфицирующем языке отношение выражений к реализуемым функциям определяется как "много к одному", а требования 2 и 3 не выполняются.

Над-специфицирующие языки вездесущи.

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

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

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

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

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

Фрейм реализуется в виде файла, содержащего смесь текста на некотором языке программирования и метакоманд, распознаваемых САРпрепроцессором.

Эта смесь называется текстом фрейма.

Фрейм может содержать другие фреймы.

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

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

Команда COPY позволяет включать в текст заданный фрейм вместе со всеми подчиненными ему фреймами.

Команда SELECT позволяет выбирать один фрейм из заданного набора (аналогично предложению CASE во многих языках программирования).

Команда BREAK определяет "точки разрыва" в тексте фрейма.

Содержание < Эти точки помечают места, куда может быть вставлен (с помощью команды INSERT) другой фрейм, дополняющий и/или замещающий фрейм, присутствующий по умолчанию (определенный заранее посредством команды DEFAULT).

Команда REPLACE позволяет заменять одни строки текста на другие, которые требуются в конкретной программе.

Замена производится на всю глубину иерархии фреймов.

Структура фрейма в САР-системе имена всех степеней свободы, присущих классу задач.

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

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

Содержание < Разработка программ в САР-системе над-специфицирующем уровне (посредством языка программирования).

Развитие CAP предполагает возможность создания SPC-фрейма с помощью инструментальных средств под-специфицирующего уровня.

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

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

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

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

Содержание < Генерация частичных систем Повторное использование программ предполагает проектирование и реализацию систем, рассчитанных на часто возникающие задачи.

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

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

При этом использование всей системы в лучшем случае расточительно, а в худшем невозможно.

Например, из-за её недостаточной эффективности или ограниченности ресурсов, которыми располагает пользователь.

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

Генерация версии полной программы соответствующих вершинам маршрута.

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

Содержание < Генераторы программ Широкое распространение получили генераторы приложений и генераторы кодов [Horowitz, Kemper at al.].

К первым относятся такие продукты, как N0MAD2 (National CSS), FOCUS (Information Builders, Inc.), RAMIS (Mathematica Products Group, Inc.), dBASE II, dBASE III (AshtonTate), каждый из которых состоит из СУБД, генератора отчётов, языка запросов базы данных, графического пакета и специального программного обеспечения.

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

Генераторы кодов обычно представляют собой диалоговые системы, ориентированные на специфицирование программ.

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

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

Генераторы приложений представляют собой специализированные программные системы, ориентированные на решение задач заданной предметной области.

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

Повышение продуктивности, обеспечиваемое за счёт применения генераторов приложений, различно (в зависимости от характера приложений и подготовленности разработчиков приложений), но во всех случаях оно оценивается как (5-10)-кратное.

Генераторы приложений ADF Особую популярность среди непрофессиональных программистов, занимающихся разработкой приложений, приобрел ADF (IBM).

Он построен и работает на основе СУБД IMS.

Все приложения, разработанные посредством ADF, имеют общую структуру и представляют собой множество программных модулей, так объединённых разработчиком, чтобы они наилучшим образом выполняли задачи конкретного приложения.

Модули содержат средства управления диалогом, доступа к данным, реализации прикладной логики и управления взаимодействием с вышестоящими модулями.

Язык ADF поддерживает также недиалоговый и пакетный режимы работы.

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

ДИЭКС К генераторам приложений относится и система ДИЭКС [Барышников, Ильин В.Д. и др.], предназначенная для решения задач обработки результатов эксперимента и их графической интерпретации.

Содержание < Эта система стала отправным результатом для разработки ИГЕН-генераторов [Ильин В.Д., 1986, 1987; Ильин В.Д., Куров и др.1987; Ильин В.Д., Мартьянов].

Поскольку объектами автоматизированного конструирования, изучаемыми в этой книге, являются генераторы приложений, рассмотрим подробнее их общую характеристику, воспользовавшись материалами обзора [Horowitz, Kemper at al.].

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

Генераторы обеспечивают язык "программирования" высокого уровня с удобным для пользователя синтаксисом.

Поэтому ГП могут быть легко использованы конечным пользователем, не имеющим программистских навыков.

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

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

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

Такой подход имеет целый ряд преимуществ.

Во-первых, отсутствует этап кодирования в обычном смысле.

Спецификация постепенно превращается в программу.

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

Упрощаются этапы тестирования и сопровождения.

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

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

Есть основание утверждать, что применение ГП позволяет значительно уменьшить время разработки приложений.

ГП имеют собственные системы управления базами данных и поддерживают доступ к внешним файлам.

Обычно используется иерархическая или реляционная модель данных.

База данных, как правило, состоит из двух файлов: основного - и файла данных.

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

Содержание < Основной файл обычно создается в диалоговом режиме следующим образом:

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

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

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

Одна из важных особенностей генераторов приложений — наличие генераторов отчетов.

Язык генератора отчетов часто характеризуется как непроцедурный.

Это, однако, не означает полного отсутствия подпрограмм.

Непроцедурный для генератора отчетов означает язык высокого уровня.

Пользователь генератора отчётов должен указать только основные шаги вычисления, но может не вникать в детали нижнего уровня (такие как представление данных или детальная последовательность вычисления).

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

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

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

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

Графический пакет в составе ГП - это особый вид генератора отчетов, формирующий отчеты в графической, а не табличной форме.

Для простоты использования синтаксис графического языка — в основном тот же, что и в языке генератора отчетов.

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

Обычно ГП представляют графические объекты в форме гистограмм, диаграмм и графиков.

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

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

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

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

Для этого на дисплей выводится таблица-шаблон соответствующей базы данных, а пользователь заполняет свободные поля.

Содержание < Манипулирование данными обычно реализуется посредством меню.

Это освобождает пользователя от необходимости запоминать синтаксис описания.

Кроме редактирования данных, пользователь имеет возможность изменять определение базы данных.

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

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

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

В таких приложениях, как правило, также используется меню.

Сравним ГП с системами программирования.

Генераторы приложений используются в сочетании с системой управления базами данных.

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

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

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

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

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

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

Сравнение языковых возможностей ГП и традиционного компилятора Входные языки Диалоговые, формо- Не диалоговые, текстовые, не Выходные языки Высокого уровня; обычно - Ассемблер или система команд ГП, как правило, обеспечивают интерфейс языка программирования общего назначения с системой управления базами данных и некоторыми командами ГП высокого уровня.

ГП и язык программирования могут рассматриваться как две отдельных компоненты.

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

Доступ к системе управления базами данных имеет только ГП.

ГП направит запрошенную вставку в рабочую область, обеспеченную пользователем.

Таким образом, ГП - это система автоматизированной разработки программ, включающая средства управления базами данных с ЧТО-языковыми средствами формирования отчётов (в табличной и графической форме).

Содержание < Есть два пути повышения гибкости ГП.

Один из них - встроить КАК-язык в уже существующий ГП.

Второй - расширить некоторый КАК-язык таким образом, чтобы он включал в себя возможности ГП.

Генераторы приложений и сервис-ориентированные архитектуры Содержание < И-порождение: конструирование целевых программных систем И-порождением названа методология автоматизированного конструирования программных систем по описанию их характеристик и условий применения.

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

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

Как построено изложение Сначала новые понятия вводятся на содержательном уровне (определяется их прагматика с указанием точек зрения).

Это позволяет ответить на вопросы: зачем вводится понятие, где предполагаем его употреблять и какое множество объектов и отношений между ними ставится в соответствие введенному понятию?

Затем дается формализованное представление понятия (модель понятия).

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

Модель изобретается как конструктивный объект, рассчитанный на взаимодействие с моделями других понятий из интересующей нас предметной области (понимаемой как система понятий, введённая для изучения некоторой проблемы).

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

Формализованное представление понимается здесь шире, чем математическое.

Там, где это целесообразно и возможно, формализованная модель строится с применением математических понятий.

О содержании Раздел, посвящённый теоретическим основам И-порождения, — основной.

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

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

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

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

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

Правила поведения системы И-порождения при конструировании целевых систем реализуются как правила табс-навигации.

Концептуальные основы И-порождения И-порождение рассматриваем как индуктивное построение множества задачных конструктивных объектов.

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

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

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

Разработка генератора приложений требует решения комплекса задач, завершающихся созданием:

1. языка взаимодействия с системой;

2. модели предметной области, на которой интерпретируются сообщения, представленные на языке взаимодействия с системой;

3. интерпретатора сообщений;

4. интерфейса с пользователем;

5. системы управления базами данных;

6. процессора прикладного ввода-вывода (выполняющего ввод с контролем, формирование отчётов и вывод во внешнюю по отношению к базе данных среду);

7. функционального наполнения системы, определяющего её целевое назначение;

8. монитора системы;

9. специальной системы программирования, ориентированной на задачи заданной предметной области;

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

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

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

Содержание < Изобрести способ разрабатывать программные системы с помощью автомата — значит решить следующие задачи поддержки процесса разработки:

1. перевод требований заказчика на язык разработчика;

2. помощь разработчику в переводе заданных требований в описание множества понятий и отношений на этом множестве (необходимого для построения модели предметной области);

3. определение входного языка, предложения которого интерпретируются на модели предметной области;

4. реализация семейства отношений модели предметной области;

5. создание баз данных, воплощающих память программной системы;

6. построение интерпретатора входного языка;

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

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

9. синтез исходного текста программы;

10. построение обучающей системы;

11. документирование системы.

Здесь рассматривается подход к решению задач, указанных в п.п. 2-11.

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

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

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