Пример использования шаблонов генерации

Вступление

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

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

Предметная область

Давайте опишем живые организмы. Скажем что у нас есть сущность Организм, которая состоит из своих частей. Каждая часть это тоже сущность соответствующего типа. Итого имеем два типа сущностей. Что бы не усложнять, мы не вводим ни каких свойств и параметров, кроме двух: имя и описание (тк они есть "с рождения" у любой сущности в нашем инструменте). Запишем это в виде шаблона, который и определит нашу метамодель:


: Часть Тела::Class
? часть тела (может соединяться с другой частью тела)

: Организм::Class
? организм (состоит из частей)
> Часть Тела::Class



: Часть Тела::Class::Attribute
c {}
r {%T%f_kind_of("Часть Тела")=false}: {Части тела могут соединяться только между собой}

Перевожу
: X::Y - определяет стереотип Х для класса элементов Y (Class - обычный класс с тз UML), пока что у нас определены два возможных стереотипа классов Часть Тела и Организм.

? - просто описание стереотипа для информации (будет видно в инструменте рисования модели)

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

: X::Y::Z::Y2 -  определяет допустимые стереотипы Z вложенных UML-элементов Y2 (атрибутов, операций, связей). В данном случае мы определяем наличие у Частей Тела аттрибутов. Z не указан, те используется стереотип по умолчанию (пустой).

Наконец, последнее что мы видим это констрейнт (две строчки начинающиеся с "c" и "r"), проверяющий что целью этих атрибутов может быть только другая Часть Тела.

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


: Формы Жизни::Category
M
> Организм::Class

М - означет что этот стереотип может быть рутовым, те с него может начинаться Модель

После того как мы откроем новую можель, и свяжем ее с нашим "шаблоном", то получим просто пустой экран, что логично, мы ведь еще ни чего не СОЗДАЛИ. На самом деле пустой экран это верхний уровень нашей модели, в котором мы сейчас можем создать элемент единственного типа (точнее стереотипа) Формы Жизни:

Что мы и сделаем:

Теперь у нас есть пакет с нашим проектом, откроем его, внутри тоже разумеется пустая диаграмма. Аналогично, создадим в нем первый экземпляр Организма который назовем "Собака Шарик":

Теперь нарисуем самого Шарика, для этого внутри класса "Собака Шарик" создадим вложенные классы со стереотипом  "Часть тела" (другие нам там и не дадут создать). Не повторяя все ту же последовательность действий, приведу сразу диаграмму:

 

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

: Нога::Class

= Часть Тела::Class

: Рука::Class

= Часть Тела::Class

= <имя стереотипа> это запись определяющее фактически классическое объектно-ориентирлованное наследование  (которое у нас может быть множественным). 

Добавим их в список допустимых стереотипов у Организма:

: Организм::Class

? организм (состоит из частей)

> Часть Тела::Class

> Рука::Class

> Нога::Class

Теперь они нам станут доступны в списке возможных стереотипов внутри Организма,  и мы можем дорисовать Шарика:

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

Для этого перво-наперво нам нужно определить ГЕНЕРАТОР. Те по сути конкретный тип получаемых из модели артефактов. Генераторов может быть сколько угодно, например для разных ЯП, документации и тд.  Нам пока нужен один:

Generator definitions:

group "All" {

generator "output" {

Description: Описание мира

}

}

output - это идентификатор нашего генератора.

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

: Формы Жизни::Category

M

> Организм::Class

+ output

C /%SN

O %SN.txt

Мир состоит из: <%CX

>

+output - это начало шаблона для генератора output. 

С - определяет путь генерации для этого элемента и всех вложенных

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

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

%S - (Self) доступ к текущем элементу модели, N - вывести имя (Name) элемента  (те название элемента на модели).

Таким образом, две команды описанные выше определяют выходной файл с путем: <папка для генерации>/<имя рутового пакета>/<имя рутового пакета>.txt.  Дальше идет собственно шаблон, который выводит константную строчу, и запускает генераторы своих детей. 

%C - (Child) ребенок текущего элемента

<... >  - это цикл, в данном случае по %C - те по детям. X - запускает текущий генератор на элементе.

Теперь опишем шаблон для Организмов, те для "детей":

: Организм::Class

+ output

%SN[, %SD,] это <{; }%CX>.

%SN - имя Организма

%SD - (Documentation) документация элемента с модели

[...] - условие, в данном случая его особая "пустая" форма, означает что запятые и пробел выведутся, только в том случае если у элемента не пустая документация.

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

Наконец последний шаблон, для Части тела:

: Часть Тела::Class

+ output

%SN[ %SD][, из которой растут <{, }[%CN ]%C%TN>]

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

%T - это "таргет" (Target) элемента, например тип атрибута или тип возвращаемого значение операции, тип связи и тд. Соответственно, связка %C%T - это доступ к таргету текущего ребенка.

Теперь мы можем запустить генерацию:

Выходной файл, как можно уже догадаться, будет следующим:

Мир состоит из: Собака Шарик это Голова зубастая; Хвост рогаликом; Тушка пятнистая, из которой растут Голова, Передняя правая Лапа, Передняя левая Лапа, Задняя левая Лапа, Задняя правая Лапа, Хвост.

Если мы расширим модель, то и описание разумеется будет расширяться. Предположим мы хотим теперь описать новую форму жизни - Человек. И предположим, что мы понимаем что Людей у нас в модели будет много (в отличие от Шарика, который один), рисовать каждый раз человека из чего он состоит, точно не хочется, поэтому мы используем summoning  те порождение элементов модели. Для начала определим новый стереотип Человек (и сразу за компанию еще один - Бог, что за человек без Бога ;)) на метамодели:

: Человек::Class

= Организм::Class

: Бог::Class

= Человек::Class

Теперь, как мы условились выше нам нужно один раз описать из чего состоит ЛЮБОЙ человек и Бог, что бы не делать это каждый раз ручками на модели:

: Человек::Class

= Организм::Class

+ spell

%S%f_add_class(HEAD,Часть Тела,Голова,TMP)

%S%{HEAD}%f_set_documentation(светлая)

%S%f_add_class(L_HAND,Рука,Левая рука,TMP)

%S%f_add_class(R_HAND,Рука,Правая рука,TMP)

%S%f_add_class(L_FOOT,Рука,Левая нога,TMP)

%S%f_add_class(R_FOOT,Рука,Правая нога,TMP)

%{TMP}%f_set_documentation(немного короче левой)

: Бог::Class

= Человек::Class

+ spell

%S%f_add_class(SECOND_HEAD,Часть Тела,Вторая голова,TMP)

%{TMP}%f_set_documentation(еще лучше первой)

= Человек::Class;spell

+ spell - идентификатор специального системного генератора для суммонинга. 

%S%f_add_class(X,Y,Z,V) - вызов функции которая добавит внутрь текущего элемента (%S) новый класс указанного стереотипа.

Y - стереотип создаваемого класса

Z - имя создаваемого класса

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

%S%{HEAD} - доуступ к переменной HEAD (созданной шагом выше) на текущем элементе. Эквивалентная запись в данном случае это просто %{TMP} (такая двойственность возникла исторически, но иногда по прежнему удобна)

%f_set_documentation - устанавливает поле документации

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

Дорисуем модель:

После генерации предсказуемо получим на выходе:

Мир состоит из: Собака Шарик это Голова зубастая; Хвост рогаликом; Тушка пятнистая, из которой растут Голова, Передняя правая Лапа, Передняя левая Лапа, Задняя левая Лапа, Задняя правая Лапа, Хвост.

Вася это Голова светлая; Левая рука; Правая рука; Левая нога; Правая нога немного короче левой.

Будда это Вторая голова еще лучше первой; Голова светлая; Левая рука; Правая рука; Левая нога; Правая нога немного короче левой.

Маша это Голова светлая; Левая рука; Правая рука; Левая нога; Правая нога немного короче левой.

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

Теперь еще немного расширим метамодель. Определим на ней возможность связи между Организмами:

: Организм::Class::ClassDependency

: Организм::Class::любит::ClassDependency

= Организм::Class::ClassDependency

: Организм::Class::верит в::ClassDependency

= Организм::Class::ClassDependency

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

Подправим шаблон нашего генератора:

: Организм::Class

+ output

%SN[, %SD,] это <{; }%CX>.<{}{%CC=Dependency} %SN %CS %C%TN.>

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

<..> - Цикл по детям с условием выборки только детей с типом класса (%CС - Class) Dependency ("связь"),  c выводом своего имени, их стереотипа (%СS - Stereotype) и имени цели.

После генерации получим изменения:

Мир состоит из: Собака Шарик это Голова зубастая; Хвост рогаликом; Тушка пятнистая, из которой растут Голова, Передняя правая Лапа, Передняя левая Лапа, Задняя левая Лапа, Задняя правая Лапа, Хвост. Собака Шарик верит в Вася.

Вася это Голова светлая; Левая рука; Правая рука; Левая нога; Правая нога немного короче левой. Вася любит Собака Шарик. Вася любит Маша. Вася верит в Будда.

Будда это Вторая голова еще лучше первой; Голова светлая; Левая рука; Правая рука; Левая нога; Правая нога немного короче левой.

Маша это Голова светлая; Левая рука; Правая рука; Левая нога; Правая нога немного короче левой.

Язык Программирования

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

Пусть наш ЯП обладает  минимальным набором понятий (это ж пример всетаки, да, не беру реальный, потому что Дельфи и java давным-давно забыл,  С++ уже начинаю, а Objective C боюсь многих своим синтаксисом с ума сведет), пусть будет что-то вроде такого джава образного, что бы все в одном файле:

module M1 {

class C1 ---> BaseClass {

     property propA: TypeA;

     operation opB (arg1: Type1, arg2: Type2): TypeRet {

           // тело метода

     }

}

}

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

Запишем это на шаблоне. Для начала дополним описание генераторов, новым для нашего языка:

Generator definitions:             

group "All" {                      

generator "output" {           

Description: Описание мира 

}                              

                                   

generator "langx" {            

Description: А вот и код   

}                              

}                                  

Теперь добавим новые стереотипы, с пустым генератором языка:

: ModuleX::Category

> ClassX::Class

+ langx

O src/%SN.langx

: ClassX::Class

d

+ langx

: ClassX::Class::property::Attribute

+ langx

: ClassX::Class::Operation

a ra

m t

+ langx

: ClassX::Class::ctor::Operation

= ClassX::Class::Operation

T

+ langx

И так сначала идет определения для модуля. МодульХ может содержать элементы КлассовХ и  будет порождать файл в подкаталоге src с названием <имя модуля>.langx.

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

Определяем на КлассеХ проперти, операцию без стереотипа, и конструктор, как операцию со стереотипом ctor. Операции могут быть (r) регулрными (regular) или (a) абстрактными (abstract), и быть доступными для реализации и перекрытия в наследниках (m t). Конструкторы, кроме того могут не иметь таргета (T), те им необязательно задавать тип возвращаемого результата.

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

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

: LangX::Class

+ langx

// %SD

%S%f_element_definition()

%f _element_definition

/ пусто

: ClassX::Class

= LangX::Class

: ClassX::Class::Operation

= LangX::Class

...

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

Определим этот метод для реальных стереотипов:

: ClassX::Class

%f _element_definition

class %SN[ --\> <{, }%GN>] {

<%CX

>\

<%oX

>};

Шаблон для Класса, согласно нашему синтаксису выводит его имя, указание базового класса (%G - Generalization), если есть, затем разворачивает генерацию своих детей, и абстрактных детей унаследованных от предков (%o), которые данный класс реализует.

: ClassX::Class::Operation

%f _element_definition

operation %f_to_javaex(%SN) (<{, }%CN:%C%TN>): %TN {

}

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

: ClassX::Class::property::Attribute

%f _element_definition

property %f_to_javaex(%SN): %TN;

С проперти все аналогично и даже проще.

: ModuleX::Category

%f _element_definition

module %SN {

<{\n\n}%CX>

}

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

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

: ClassX::Class::ctor::Operation

= ClassX::Class::Operation

T

+ spell

%S%f_set_target(%PU)

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

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

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

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

: Формы Жизни::Category

+ spell

%S%f_summon_framework()

<%CX>

%f _summon_framework

%S%f_add_category(XWF,ModuleX,XFramework,FW)

%{FW}%f_set_documentation(Фреймворк для Форм Жизни)

%{FW}%f_add_class(BP_BASE,ClassX,BodyPartsBase,ADDS)

%{ADDS}%f_set_documentation(Базовый класс для Частей тела)

%{FW}%f_add_class(ORG_BASE,ClassX,OrganismBase,ADDS)

%{ADDS}%f_set_documentation(Базовый класс для Организмов)

%{ADDS}%f_add_operation(CTOR_DEF,ctor,make_deafult():OrganismBase,TMP)

%{TMP}%f_set_documentation(Дефолтный пустой конструктор - должен определятся в конкретном экземпляре)

%{TMP}%f_set_abstraction_type(abstract)

%{ADDS}%f_add_operation(EX1,,all_my_parts():BodyPartsBase,TMP)

%{TMP}%f_set_documentation(Операция для примера)

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

Его содержимое:

// Фреймворк для Форм Жизни

module XFramework {

// Базовый класс для Частей тела

class BodyPartsBase {

};

// Базовый класс для Организмов

class OrganismBase {

// Дефолтный пустой конструктор - должен определятся в конкретном экземпляре

operation makeDeafult (): OrganismBase {

}

// Операция для примера

operation allMyParts (): BodyPartsBase {

}

};

}

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

: ClassX::Class

%f _element_definition

%f_set_var(CONTEXT,S)\

class %SN[ --\> <{, }%GN>] {

...

: ClassX::Class::Operation

%f _element_definition

operation %f_to_javaex(%SN) (<{, }%CN:%C%TN>): %TN\

[{%{CONTEXT}U=%PU&%Sa=abstract}{%S%f_body()} = 0;]

%f _body

{

%U[

]

}

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

%U - это вывод так называемых Юзер Секций (User Sections) -  кусков текста обрамленных специального вида комментариями (формат их может настраиваться для каждого генератора отдельно), которые при повторной генерации парсятся генератором, их содержимое идентифицируется и вставляется во вновь сгенерированный код в место с теми же самыми идентификаторами. За счет этого становится возможным, дополнять сгенерированные артефакты любыми пользовательскими вставками, которые будут сохранены при перегенерации, перемещены в другое место если это потребуется, или удалены если был удален элемент с которым они были связаны.

Запустим генерацию:

// Фреймворк для Форм Жизни

module XFramework {

// Базовый класс для Частей тела

class BodyPartsBase {

};

// Базовый класс для Организмов

class OrganismBase {

// Дефолтный пустой конструктор - должен определятся в конкретном экземпляре

operation makeDeafult (): OrganismBase = 0;

// Операция для примера

operation allMyParts (): BodyPartsBase {

//#UC START# *D5AD8599E380*

//#UC END# *D5AD8599E380*

}

};

}

//#UC START# *D5AD8599E380* - это начало юзерсекции с ИД D5AD8599E380, соответствующим ИД элемента операции all_my_parts, который автоматически получается при суммонинге и сохраняется в файле модели. //#UC END# - соответственно ее конец.

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

Будем считать что фреймворк готов, и можно приступать к отображение предметной области. Первая проблема с которой мы сталкиваемся это имена элементов. В нашем примере они русские, а для отображения на langX  нужны латинские. Для ее решения мы добавим на все элементы предметной области дополнительное поле-свойство, в котором проектировщик сможет указать латинский аналог русского названия элемента. Что бы не добавлять свойтсво на каждый из элементов предметной области, мы добавим один базовый стереотип, на котором его и определим:

: ФЖ Элемент::Class

p eng_name:s ? англ название

%f _x_name
[{}{%SN}%S{eng_name}]

: Часть Тела::Class

= ФЖ Элемент::Class

%f _x_name
%S%[inherited]Of%P%f_x_name()

...

: Организм::Class

= ФЖ Элемент::Class

...

p <имя свойства>:<тип>[ ? <описание>] - задает пользовательское свойство для стереотипа. Свойства могут быть бинарными (да/нет), строковыми  (произвольная строка), выбором из списка значений или файлом. В данном случае это просто строка.
Функция _x_name введена просто для удобства - если не задано английское имя, то берется основное имя элемента. А для Части тела она еще использует имя родителя, что бы получить уникальное имя класса.

Добавим английские имена всем элементам:

Теперь реализуем собственно отображение. Тут есть два варианта как поступить. Первый вариант это отнаследовать стереотипы предметной области от стереотипов языкаХ, и дописать нужную специализацию. Второй, более правильный, это явно ссумонить все что нужно, мы выберем этот вариант. Определим спелы (spell) для наших элементов:

: Формы Жизни::Category

+ spell

%S%f_summon_framework()

%S%f_add_category(X_IMPL,ModuleX,%S{eng name},TMP)

%{TMP}%f_add_dependency(%{FW}U)

<%CX>

<%C#f_spell_usage()>

После того как наш рутовый пакет, создаст фреймворк, мы добавим модуль в котором и будет находиться отображение. В качесте имени моуля мы используем значение пользовательского свойства {eng name}. Укажем что отображение зависит от фреймворка (это необходимо для контроля доступа элементов друг к другу), после чего вызовим суммонинг своих детей. Поскольку у нас в метамодели предметной области допускаются циклические зависимости (Вася любит Шарика, а Шарик верит в Васю), то отображение мы разобьем на две фазы, первая ссобственно суммонинг необходимых классов, а вторая связывание их друг с другом, в противном случае возможны неоднозначности, когда нам нужно использовать элемент который мы еще не ссумонили. Для этого мы добавим метод _spell_usage, который определим на только Организме (форма вызова метода через # означает что метод будет вызван только если он определен на экземпляре, в случае с % попытка вызвать не определенный метод приведет к ошибке)

: Организм::Class

+ spell

   %P%{X_IMPL}%f_add_class(X_%SU,ClassX,%S%f_x_name(),ADDS)

   %{ADDS}%f_add_inheritable(OrganismBase)

   %{ADDS}%f_set_documentation(Класс реализации для %SN[ %SD])

   %S%f_set_var(X_IMPL,{ADDS})

   <%CX>

%f _spell_usage

   %f_set_var(MY_IMPL,S%{X_IMPL})

   %f_clear_list(CTOR_ARGS)

   <

      [{%CC=Dependency}{

         %{MY_IMPL}%f_add_attribute(X_%CU,property,%C{eng_name}:%C%{X_IMPL}N,TMP)

         %{TMP}%f_set_documentation(%CN[ %CD])

      }

         %f_add_to_list(CTOR_ARGS,C)

      ]

   >

   [{%{CTOR_ARGS}<{}{}{%CC}>!=0}

      %{MY_IMPL}%f_add_operation(X_CTOR,ctor,make_with(%{CTOR_ARGS}<{,}%C{eng_name}:%C%T%{X_IMPL}N>),TMP)

      %{TMP}%f_set_documentation(Конструктор. Параметры: %{CTOR_ARGS}<{; }%C{eng_name}:%C%TN[ %C%TD]>)

   ]

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

: Часть Тела::Class

+ spell

%P%P%{X_IMPL}%f_add_class(X_%SU,ClassX,%S%f_x_name(),ADD)

%{ADD}%f_add_inheritable(BodyPartsBase)

%{ADD}%f_set_documentation(Класс реализации для %SN[ %SD] от %PN[ %PD])

%S%f_set_var(X_IMPL,{ADD})

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

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

module Example {

// Класс реализации для Голова зубастая от Собака Шарик

class HeadOfSharickTheDog --> BodyPartsBase {

};

// Класс реализации для Лапа от Собака Шарик

class PawOfSharickTheDog --> BodyPartsBase {

};

// Класс реализации для Хвост рогаликом от Собака Шарик

class TailOfSharickTheDog --> BodyPartsBase {

};

// Класс реализации для Тушка пятнистая от Собака Шарик

class BodyOfSharickTheDog --> BodyPartsBase {

};

// Класс реализации для Голова светлая от Вася

class HeadOfVasija --> BodyPartsBase {

};

// Класс реализации для Левая рука от Вася

class LeftHandOfVasija --> BodyPartsBase {

};

// Класс реализации для Правая рука от Вася

class RightHandOfVasija --> BodyPartsBase {

};

// Класс реализации для Левая нога от Вася

class LeftFootOfVasija --> BodyPartsBase {

};

// Класс реализации для Правая нога немного короче левой от Вася

class RightFootOfVasija --> BodyPartsBase {

};

// Класс реализации для Вторая голова еще лучше первой от Будда

class SecondHeadOfBuddah --> BodyPartsBase {

};

// Класс реализации для Голова светлая от Будда

class HeadOfBuddah --> BodyPartsBase {

};

// Класс реализации для Левая рука от Будда

class LeftHandOfBuddah --> BodyPartsBase {

};

// Класс реализации для Правая рука от Будда

class RightHandOfBuddah --> BodyPartsBase {

};

// Класс реализации для Левая нога от Будда

class LeftFootOfBuddah --> BodyPartsBase {

};

// Класс реализации для Правая нога немного короче левой от Будда

class RightFootOfBuddah --> BodyPartsBase {

};

// Класс реализации для Будда

class Buddah --> OrganismBase {

// Вторая голова еще лучше первой

property secondHead: SecondHeadOfBuddah;

// Голова светлая

property head: HeadOfBuddah;

// Левая рука

property leftHand: LeftHandOfBuddah;

// Правая рука

property rightHand: RightHandOfBuddah;

// Левая нога

property leftFoot: LeftFootOfBuddah;

// Правая нога немного короче левой

property rightFoot: RightFootOfBuddah;

// Дефолтный пустой конструктор - должен определятся в конкретном экземпляре

operation makeDeafult (): OrganismBase {

//#UC START# *F66E89A23C1C_BASE*

//#UC END# *F66E89A23C1C_BASE*

}

};

// Класс реализации для Голова светлая от Маша

class HeadOfMary --> BodyPartsBase {

};

// Класс реализации для Левая рука от Маша

class LeftHandOfMary --> BodyPartsBase {

};

// Класс реализации для Правая рука от Маша

class RightHandOfMary --> BodyPartsBase {

};

// Класс реализации для Левая нога от Маша

class LeftFootOfMary --> BodyPartsBase {

};

// Класс реализации для Правая нога немного короче левой от Маша

class RightFootOfMary --> BodyPartsBase {

};

// Класс реализации для Маша

class Mary --> OrganismBase {

// Голова светлая

property head: HeadOfMary;

// Левая рука

property leftHand: LeftHandOfMary;

// Правая рука

property rightHand: RightHandOfMary;

// Левая нога

property leftFoot: LeftFootOfMary;

// Правая нога немного короче левой

property rightFoot: RightFootOfMary;

// Дефолтный пустой конструктор - должен определятся в конкретном экземпляре

operation makeDeafult (): OrganismBase {

//#UC START# *F66E89A23C1C*

//#UC END# *F66E89A23C1C*

}

};

// Класс реализации для Собака Шарик

class SharickTheDog --> OrganismBase {

// Голова зубастая

property head: HeadOfSharickTheDog;

// Лапа

property paw: PawOfSharickTheDog;

// Хвост рогаликом

property tail: TailOfSharickTheDog;

// Тушка пятнистая

property body: BodyOfSharickTheDog;

// Конструктор. Параметры: beleveTo:Вася

operation makeWith (beleveTo:Vasija): SharickTheDog {

//#UC START# *3565C7C4C308*

//#UC END# *3565C7C4C308*

}

// Дефолтный пустой конструктор - должен определятся в конкретном экземпляре

operation makeDeafult (): OrganismBase {

//#UC START# *F66E89A23C1C*

//#UC END# *F66E89A23C1C*

}

};

// Класс реализации для Вася

class Vasija --> OrganismBase {

// Голова светлая

property head: HeadOfVasija;

// Левая рука

property leftHand: LeftHandOfVasija;

// Правая рука

property rightHand: RightHandOfVasija;

// Левая нога

property leftFoot: LeftFootOfVasija;

// Правая нога немного короче левой

property rightFoot: RightFootOfVasija;

// Конструктор. Параметры: loveTo:Собака Шарик; loveTo:Маша; beleveTo:Будда

operation makeWith (loveTo:SharickTheDog, loveTo:Mary, beleveTo:Buddah): Vasija {

//#UC START# *5558B8CAB716*

//#UC END# *5558B8CAB716*

}

// Дефолтный пустой конструктор - должен определятся в конкретном экземпляре

operation makeDeafult (): OrganismBase {

//#UC START# *F66E89A23C1C*

//#UC END# *F66E89A23C1C*

}

};

}

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

Для подключения фреймворка добавим в шаблон модуля следующий код:

: ModuleX::Category

%f _element_definition

[import <{,} %DN>;

]module %SN {

<{\n\n}%CX>

}

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

Для вызова базового конструктора, добавим такой шаблон:

: ClassX::Class::ctor::Operation

+ spell

%S%f_set_target(%PU)

%S%f_set_pre_uc_content(langx,,%S%f_ctor_pre_content())

%f _ctor_pre_content

self = %P%GN.makeDefault;

_set_pre_uc_content - это системная функция которая добавляет указанный в аргументе шаблон ПЕРЕД выводом юзер секции.

Наконец, для устранения дублирующихся ИД юзер секций, используем уже имеющийся у нас контекст генерации:

: ClassX::Class::Operation

%f _body

{

[{%{CONTEXT}U=%PU}{\

%U[{_BASE_FOR_%{CONTEXT}U}

]

}\

%U[

]

]\

}

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

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

import  XFramework;

module Example {

....

// Конструктор. Параметры: beleveTo:Вася

operation makeWith (beleveTo:Vasija): SharickTheDog {

self = OrganismBase.makeDefault;

//#UC START# *3565C7C4C308*

//#UC END# *3565C7C4C308*

}

// Дефолтный пустой конструктор - должен определятся в конкретном экземпляре

operation makeDeafult (): OrganismBase {

//#UC START# *F66E89A23C1C_BASE_FOR_5ECD455013CA*

//#UC END# *F66E89A23C1C_BASE_FOR_5ECD455013CA*

}

....

}

Заключение

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

Дополнение
По просьбе трудящихся добавляю мета-модель:

И ключевую ЧАСТЬ мета-мета-модели. Повторю она ЕДИНАЯ для ВСЕХ:

Самый интересный тут "квадартик" это MDAClass - оно определяет сам себя. И сам из себя генерируется.