Жизненный цикл программ (ЖЦП)

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

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

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

 

 

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

В производственном программировании сложилось понятие ЖЦП, струк- тура которого требует не только четкого ответа на вопросы «Что? Как? Кто?», но и уяснения приоритетов между ними.

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

Как? Как будет устроена программа обработки? Каков алгоритм обра- ботки данных? Из каких действий выстраивается функционирование про- граммы?

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

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

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

Таблица 1

Условия завершения фазы ЖЦП

№ фазы	Название фазы	Условие завершения фазы
0	Постановка за- дачи	Удостоверена достаточность средств управле- ния качеством разрабатываемой программы
1	Определение тре- бований	Признана готовность документа, представляю- щего обзор желаемых результатов работы про- граммы
2	Спецификация требований	Выполнен выбор средств для подтверждения результатов программы
3	Проектирование	Определены методы проверки правильности проекта

Продолжение т абл. 1

 

№ фазы	Название фазы	Условие завершения фазы
4	Реализация про- граммы	Проведено тестирование компонент про- граммы на полном комплекте выбранных средств
5	Тестирование	Выполнена интеграция/сборка программы из ранее готовых и разработанных компонентов
6	Сопровождение	Проведена аттестация программы, показавшая фактические границы ее работоспособности
7	Развитие	Проверено соответствие функционирования программы пользовательским требованиям к решению задачи

 

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

Фазы:

1) исследование;

2) анализ осуществимости;

3) конструирование возможных решений;

4) программирование;

5) оценка свойств программы;

6) использование программы.

Функции:

1) планирование;

2) разработка;

3) обслуживание;

4) документирование;

5) испытание;

6) поддержка;

7) сопровождение.

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

– программы подвержены итеративному развитию;

– существуют стабильные сценарии применения программы;

– неизбежно наращивание комплекса программируемых и выполняемых функций;

– ничто в разработке на делается однократно – раз и навсегда;

– не исключено размножение числа фаз.

 

 

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

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

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

Минимизацию повторов обеспечивают созданием специальных промыш- ленных технологий программирования, противоречиво наследующих пре- имущества каскадной схемы ЖЦП и управления качеством по таблицам Ган- тера:

- форсированное принятие решений – сразу и как можно больше;

- управление качеством и профилактика необоснованных преждевре- менных решений;

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

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

Для больших систем собственно программирование сводится к реализа- ции или выбору модулей, сборке программ из модулей и документированию полученных результатов. Следует отметить, что реализация модулей обла- дает существенно большей (в 3–9 раз) трудоемкостью, чем разработка функ- ционально эквивалентных автономных программ. Сборка программ из гото- вых модулей имеет дополнительную нагрузку на ответственное изучение их устройства и функционирования.

 

 

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

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

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

 

Эксплуатационная прагматика

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

– критерии качества программ могут изменяться в процессе программи- рования, что возможно повлечет существенный пересмотр многих ранее при- нятых решений;

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

 

2 Фредерик Брукс. Мифический человеко-месяц, или Как создаются программные си- стемы = The mythical Man-Month: Essays on Software Engineering. М.: Символ-Плюс, 2010. 304 с.

 

 

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

- технологии программирования обеспечивают гарантированное получе- ние результата разработки при условии соответствия технологическим тре- бованиям;

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

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

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

 

Выводы

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

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

3. Классификация ЯСП по поддерживаемым ПП требует анализа их опе- рационной семантики и реализационной прагматики с учетом эксплуатаци- онной прагматики.

 

 

ЛЕКЦИЯ 2. ПОДДЕРЖКА ПАРАДИГМ ПРОГРАММИРОВАНИЯ

Задача этой лекции – показать, каким образом определение языка про- граммирования (ЯП) и его реализация в системе программирования (СП) поддерживают разные парадигмы программирования (ПП). Рассмотрим средства и методы, используемые при определении языков программирова- ния и их расширение при реализации систем программирования. Для приме- ров используется материал учебного языка Pure Lisp и подмножества языка Pascal, достаточного для поддержки структурного программирования, кото- рое многие рассматривают как императивный эквивалент функционального программирования.

Обычно определение ЯП задается раздельно на уровнях лексики, синтак- сиса и семантики. Реализация СП требует определения и прагматики, задаю- щей конкретные способы представления структур данных в машине и выби- рающей границы осуществимых вычислений. Для определенной семантики ЯП вычисления могут быть выполнены как интерпретатором или компилято- ром, так и тем и другим по мере необходимости. Компиляция может выпол- няться как для всей программы полностью, так и раздельно для указанных функций/процедур, в том числе «на лету».

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

Для иллюстраций здесь используются модифицированные формы Бе- куса-Наура, в которых знак «=» связывает имя понятия с его определением,

«|» - выделяет альтернативные определения, «(» и «)» выделяют группу, «[» и «]» выделяют необязательное вхождение, «{» и «}» - границы многократно повторяемого вхождения, возможно ни одного.

Синтаксис бестипового учебного подмножества языка Pascal ³

 

БНФ	Пояснение
ident = letter {letter | digit}	Идентификатор
integer = digit {digit}	Целое
factor = ident | integer | "(" expression ")". expression = factor [("=" | "<" | "+"|"-" | "*" | "DIV") factor	Выражение: = < – Отношения между числами + – * DIV – Операции над числами
statement = [assignment | ProcedureCall | IfStatement | WhileStatement]	Оператор
assignment = ident ":=" expression	Присваивание
StatementSequence = statement {";" statement}	Последовательность исполнения команд
IfStatement = "IF" expression "THEN" StatementSequence ["ELSE" StatementSequence] "END"	Ветвление
WhileStatement = "WHILE" expression "DO" StatementSequence "END"	Цикл
IdentList = ident {"," ident}. FormalParameters = "(" [IdentList {";" = ["VAR"] IdentList }] ")". ProcedureHeading = "PROCEDURE" ident [FormalParameters]. ProcedureBody = declarations "BEGIN" [StatementSequence] "END" ProcedureDeclaration = ProcedureHeading ";" ProcedureBody. declarations = ["CONST" {ident "=" expression ";"}] | ["VAR" {IdentList;"}]	Определение функции
ActualParameters = "(" [expression {"," expression}] ")". ProcedureCall = ident [ActualParameters]	Вызов функции
module = "MODULE" ident ";" declarations ["BEGIN" StatementSequence] "END" ident "."	Автономно компилируемая еди- ница

 

Существуют ЯП, такие как Lisp и другие, в которых программы представ- ляют непосредственно как структуры данных, используемые при представле- нии и выполнении программы. В таком случае синтаксис выглядит проще. Используется лишь его конкретизация для семантической сопоставимости с другими ЯП.

 

3 Понятие «тип данных» будет привлечено позднее.

Синтаксис учебного концентра языка Lisp

Конкретизация синтаксиса для представления семантики	Пояснение
форма = переменная | (QUOTE S-выражение) | (COND {(форма форма)} | (функция {аргумент})	Переменная Константа Ветвление Вызов функции
аргумент = форма	Фактический параметр
переменная = идентификатор	Для именования значений
функция = название | (LAMBDA список_переменных форма) | (FUNC название функция)	Имена, включая операции над списками Безымянная функция Именование функции
список_переменных = ({переменная})	Любое число, возможно ни одного
название = идентификатор	Для именования функций
идентификатор = атом	Для именования любого данного
Собственно синтаксис
S-выражение = атом | (S-выражение. S-выражение) | ({S-выражение})	Атом Консолидация Список
атом = БУКВА {БУКВА | ЦИФРА}	Лексика

Исключение «синтаксического сахара» в ЯП обеспечивает внутреннее по- нимание сущности реализуемого алгоритма при подготовке и отладке про- граммы автором.

Определение лексики и синтаксиса ЯП неявно связано с эксплуатацион- ной и реализационной прагматикой той или иной ПП, поэтому без их деталь- ного рассмотрения переходим к анализу особенностей семантики и прагма- тики ЯП.

 

Семантика

Проблема определения ЯП и СП наиболее тщательно проработана в Вен- ской методике определения языков программирования⁴. Эта методика разра- ботана в конце 1960-х годов. Основная идея – использование абстрактного синтаксиса (АС) и абстрактной машины (АМ) при определении семантики языка программирования. Конкретный синтаксис (КС) языка отображается в

⁴ Lucas P., Lauer P., Stigleitner H. Method and Notation for the Formal Definition of Pro- gramming Languges. IBM Laboratory. Venna, TR 25.087, 1968.

 

 

абстрактный, а абстрактная машина может быть реализована с помощью кон- кретной машины (КМ), причем и отображение и реализация могут иметь не- большой объем и невысокую сложность.

 

Диаграмма	Пояснение
КС ↔ АС → АМ → КМ	Существует отображение конкретного синтаксиса в абстрактный и обратно. Абстрактный синтаксис отображается в абстрактную машину. Абстрактная машина реализуется с помощью конкретной машины

Рис. 1. Схема определения ЯП по Венской методике (Похожая идея теперь реализована в C-lang – LLVM)⁵

 

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

Если КС удается нормализовать, то его перевод в АС и обратно (КС ↔ АС) можно построить автоматически, что можно сделать синтаксическими конструкторами типа YACC, LEX. Сущность определения языка концентриру- ется в виде так называемой универсальной семантической функции языка (УФ: АС → АМ), выполняющей переход от абстрактного синтаксиса к аб- страктной машине – трансляцию (интерпретацию и/или компиляцию). УФ и АМ образуют определение функциональной и операционной семантики ЯП. Такая абстрактная декомпозиция определения ЯП достаточна для установле- ния первичной границы между фронт-эндом и бек-эндом. Для производствен- ных ЯП определение УФ достаточно сложно, что приводит к ошибкам в оценке трудоемкости не менее чем в два раза. По этой же причине нередко определе- ние семантики ЯП сводят к определению АМ, реализация которой чувстви- тельна к навыкам низкоуровневого программирования и потому ее реализаци- онная прагматика часто остается без формализации. Выбор АМ существенно влияет на пространство допустимых КМ.

Граница между АС и АМ может быть уточнена введением уровня базо- вых средств (БС), что гарантирует при тривиальности перехода БС ↔ АМ, профилактику усложненности АМ и взаимозаменяемость АМ и БС на первых шагах раскрутки реализации СП.

 

 

5 Статья Руслана Хайрова про особенности LLVM [Электронный ресурс]. Режим до- ступа: https://habrahabr.ru/post/47878.

 

Диаграмма	Пояснение
КС ↔ АС	При отображении АС в АМ выделяется
↓	уровень базовых средств (БС),
БС ↘	просто отображаемых на АМ и обратно.
↕   КМ	Переход к КМ может быть выполнен
АМ ↗	и как реализация БС

Рис. 2. Декомпозиция определения ЯП с выделением уровня базовых средств (БС)

 

В состав БС обычно включают операции ЯП и средства управления вы- числениями, несводимые к более простым средствам ЯП. Можно сказать, что в результате ЯП рассматривается как консервативное расширение БС. Выде- ление БС гарантирует четкое отделение языково ориентированного фронт- энда от машинно-ориентированного бек-энда, что дает минимизацию трудо- емкости при переносе СП на новую аппаратуру. Такая декомпозиция была выполнена в первых реализациях языков Lisp и C. Можно ограничить БС од- ной областью данных, рассчитывая, что операции над другими областями данных несложно включить как дополнительные команды, расширяющие АМ. Тем не менее, даже для не слишком сложных ЯП число одноуровневых функций, образующих фронт-энд, легко превосходит тысячу, дополненную рядом библиотек и пакетов, нередко обладающих общим функциональным назначением при различных механизмах реализации. Попытки улучшения СП обычно требуют повторного программирования заметного числа взаимо- связанных функций над общими данными или дополнения СП новой библио- текой, нацеленной на повышение производительности программ. В послед- нем случае программист получает рекомендацию отредактировать ранее от- лаженную программу.

Сложность целостной реализации универсальной функции УФ: АС → БС ↔ АМ преодолевается декомпозицией ее на прикладные семанти- ческие системы (ПС) – семантическая декомпозиция. Прикладные семанти- ческие системы {ПС1,…,ПСn} представляют отдельные механизмы ЯП, в принципе эффективно сводимые к аппаратным решениям при реализации и развитии автомата АМ → КМ.

 

Диаграмма	Пояснение
КС ↔ АС = {ПС1,…,ПСn}	При анализе АС выделяются приклад-
-----------------	ные семантики (ПСi), реализация ко-
↓	торых возможна с помощью БС.
БС ↘	Предварительная реализация ПС мо-
↕    КМ	жет быть выполнена средствами реа-
АМ ↗	лизуемого ЯП

Рис. 3. Декомпозиция определения ЯП с разложением на прикладные семантики (ПСi)

 

 

Это позволяет реорганизовать УФ в комплекс из более простых УФi: Псi →БС ↔ АМ. Примерно так устроено описание языка Basic, представ- ляющее собой набор подъязыков, обеспечивающих доступ к отдельным сред- ствам аппаратуры, пополнение состава которых выполняется добавлением соответствующего подъязыка, слабо связанного с остальными.

Комплект основных видов прикладных семантических систем ПСi в ка- честве типовых компонент ЯП обычно предоставлен средствами работы с па- мятью, организации вычислений, обработки структур данных и управления вычислениями, реализация которых обладает общей спецификой. Возможно выделение средств диагностики, типового контроля, средств укрупнения действий и т. д. Такая семантическая декомпозиция ЯП имеет шансы до- стичь независимости развития соответствующих ей компонентов СП. Обычно ЯП содержит около 20 видов ПС, причем число ПС одного вида мо- жет приближаться к десятку. Выделение таких семантических систем обу- словлено различиями в схеме применения операций к операндам, связан- ными с реализационной прагматикой СП и наличием их аппаратной под- держки. Понятие «семантическая система» выделяет конкретный тип данных (ТД), набор базовых операций (БО) над ним и правило применения операций (ПО) к данным.

Интеграция новых компонентов ЯП в ранее реализованную версию СП требует включения ряда согласованных определений на всех уровнях опре- деления ЯП. На уровне АМ это означает дополнение ее регистрами и специ- альными командами.

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

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

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

 

 

техника обработки таблицы и ее структура. Чаще всего встречаются системы памяти, ориентированные на работу с ассоциативно именуемыми значени- ями (value-oriented), с именованными переменными (name-oriented), с пря- мыми указателями (pointer-oriented) и неявными копиями значений в стеке (stack-oriented).

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

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

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

Для основных ПП определение АМ сводится к системе команд (СК) над небольшим числом регистров, обычно от двух до шести. СК может быть полу- чена как отображение части БС, а состав регистров и особенности их функцио- нирования отражают реализационную прагматику обработки данных.

 

Диаграмма	Пояснение
КС ↔ АС = { ПС1,…, ПСn } ↓       ↓        ↓ БС = { БО1,…, БОn } ↕      ↕         ↕ АМ ~ < СК1,…, СКn > → КМ ~ ------------------- ~ регистры	ПС = <ТД, БО, ПО> При анализе АМ для эффективной реализации Псi определяются компонеты Боi и соответствующие им системы команд (СКi) над конкретными регистрами

Рис. 4. Декомпозиция определения ЯП по интерфейсу с реализационной прагматикой

 

 

Компоненты УФi: ПСi → БОi → CKi обретают более четкую форму, но следует отметить, что разные CKi могут совпадать, обладать пересечениями или при реализации сводиться к различным парадигмальным вариантам.

Множество прикладных семантических систем можно разбить на под- множества, реализуемые в рамках одинаковых парадигм. Обычно РП может поддерживать одну ПП, но встречаются ПСi, требующие совместного приме- нения ряда парадигм. Например, в языке F# реализация ленивых вычислений выполнена на стыке функционального и объектно-ориентированного про- граммирования.

 

Диаграмма	Пояснение
КС ↔ АС = { ПС1,…, ПСn }	Определение АМ
↓       ↓        ↓	дополняется отображением ее
БС = { БО1,…, БОn }	СКi на ряд парадигмальных ва-
↕      ↕         ↕ АМ ~ < СК1,…, СКn >	риантов реализационной праг- матики (Рпi), представляющих
↕         ↕	собой подмножества комплекта
< РП1,…, РПn> → КМ	поддержанных в СП парадигм

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

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

Таблица 4

Примеры основных конструкций ядра языка Pascal над целыми числами

X	Переменные
123 C	Константы
(A1 + A2)	Вычисления
(A1 = A2)	Отношения
;	Пустой оператор
X:= a	Присваивание
S1; S2	Последовательные операторы
if p then ST else SF	Ветвление
while P do S	Цикл
var X	Объявление переменной

const C = 123	Объявление именованной константы
proc Pr (V…) S	Определение процедуры
Pr (A…)	Вызов процедуры

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

Таблица 5

Примеры основных конструкций ядра Pure Lisp над списками⁶

X	Переменная
(quote C)	Константой может быть любое символьное выражение
(atom X)	Проверка символьного выражения на неделимость
(eq X Y)	Совпадение адресов
(cond (P ST)…(T SF))	Ветвление
(lambda (X …) E…)	Безымянная функция
(defun F E)	Именование функции
(F A …)	Вызов функции

Унификация значений и функций в языке Lisp позволяет в базовые сред- ства не включать именование функций, рассматривая такой механизм как вспомогательную семантику «Категории объектов», которые появятся в бо- лее полном определении ЯП. Формально Defun можно свести к передаче па- раметра с помощью Lambda.

Следует принять во внимание, что ЯП с общей абстрактной машиной (АМ) равномощны по пространству порождаемых процессов.

Таблица 6