Начать с нуля SandBox, тесты к нему и мета-модель.
И расписывать по шагам - как оно вырастает "с нуля".
С одиночным "главным" наследованием. Чтобы ВСЕ примитивы мета-модели (и Class и Category) наследовались от абстрактного примитива Base.
И с выделением "примесей" AttrHolder, PropertyHolder, ReadOnlyPropertyHolder, UsesHolder etc.
А может и БЕЗ них. Обойтись ТОЛЬКО "квадратиками". А атрибуты и операции сделать ТОЖЕ "квадратиками". По аналогии с method и ViewArea.
А "операции" оставить ТОЛЬКО для "сигнатур". А "атрибуты" рисовать "квадратиками" с наследованием (как ViewArea) т.е. стрелка "наследования" указывает целевой тип атрибута, а имя "квадратика" указывает имя атрибута. Ну и понятное дело - на "квадратик" можно "навесить" пользовательские свойства.
В "стрелках" есть БОЛЬШАЯ "сермяжная правда" в отличии от "сигнатур" - "стрелки" - НАПРЯМУЮ указывают на тип, а "сигнатуры" - предполагают парсинг и вариативность типа. Стрелки же - вариантивность типов - ИСКЛЮЧАЮТ.
Кстати и для "методов" можно избавится от "сигнатур". По индукции. Вводя внутри методов стереотипы <<Param>> со стрелкой к типу. Это - УНИФИЦИРУЕТ. Но! Может сказаться на производительности рисования диаграмм. Тут - надо ТЩАТЕЛЬНО подумать.
Практически получится "UML без UML". ОЧЕНЬ маленькое подмножество - "стрелки" и "квадратики". На основе которого можно нарисовать ВСЁ, что рисуется и сейчас.
Отдельно выделить - АКСИОМАТИКУ (совсем базовые примитивы) и производные (которые перед генерацией распадаются на базовые примитивы, путём их конструирования перед генерацией).
АКСИОМАТИКА - зависит от целевого языка генерации, а ПРОИЗВОДНЫЕ - не зависят. Они лишь порождают примитивы из АКСИОМАТИКИ.
Единственная языковая зависимость может выражаться либо в применяемых генераторах, либо в ifdef/ifndef.
Таким образом - получаем "компактное" языко-зависимое "ядро" и набор языко-независимых производных стереотипов.
Также надо ОКОНЧАТЕЛЬНО подумать о возможности рисования представления ПРОИЗВОДНЫХ примитивов в виде диаграмм ВНУТРИ данных примитивов. В диаграммах могут использоваться как примитивы из АКСИОМАТИКИ, так и РАНЕЕ определённые ПРОИЗВОДНЫЕ примитивы.
Эти диаграммы достаточно "просто" обрабатывать. Достаточно перебрать все элементы диаграммы и создать такие же (по образу и подобию) уже в конечном экземпляре примитива. Надо лишь учесть возможность подстановки специальных переменных типа SELF, PARENT, PARENT1..PARENTN etc. Это уже надо по месту додумывать. "Сферического коня" - тут ни в коем случае - рождать не нужно.
Также надо подумать о "разрисовывании" вызовов встроенных (и определённых ранее) примитивов DSL ПРЯМО внутри методов генерации. Чтобы в конечном итоге иметь возможность "безболезненно" сменить текстовый DSL. В виде "блок-схем".
Вкратце - может получится, что от мета-мета-модели останутся лишь стереотипы Class, Category и dependency (унаследованные от ЕДИНОГО предка Base). Все остальные - не нужны.
Причём "начать плясать" именно от "контейнерных" примеров в SandBox: Project->Library->SimpleClass. Далее понадобился ExeTarget - вводим его. Понадобился Enum или Pointer - вводим их. etc по индукции. Понадобился TestTarget и TestCase - вводим их. Ну в общем - "в стиле XP". Делаем ТОЛЬКО то, что НУЖНО в данный конкретный момент.
И смотреть на временные срезы этого хозяйства. Как оно растёт.
Там глядишь и до VCM в "новом понимании" можно добраться.
Ну и иметь в виду - http://18delphi.blogspot.com/2013/07/blog-post_24.html
Также надо подумать (в разрезе SandBox) о микро-UseCase'ах и микро-UserNeeds. Чтобы сразу под проектные классы "подкладывать" ТРЕБОВАНИЯ.
И расписывать по шагам - как оно вырастает "с нуля".
С одиночным "главным" наследованием. Чтобы ВСЕ примитивы мета-модели (и Class и Category) наследовались от абстрактного примитива Base.
И с выделением "примесей" AttrHolder, PropertyHolder, ReadOnlyPropertyHolder, UsesHolder etc.
А может и БЕЗ них. Обойтись ТОЛЬКО "квадратиками". А атрибуты и операции сделать ТОЖЕ "квадратиками". По аналогии с method и ViewArea.
А "операции" оставить ТОЛЬКО для "сигнатур". А "атрибуты" рисовать "квадратиками" с наследованием (как ViewArea) т.е. стрелка "наследования" указывает целевой тип атрибута, а имя "квадратика" указывает имя атрибута. Ну и понятное дело - на "квадратик" можно "навесить" пользовательские свойства.
В "стрелках" есть БОЛЬШАЯ "сермяжная правда" в отличии от "сигнатур" - "стрелки" - НАПРЯМУЮ указывают на тип, а "сигнатуры" - предполагают парсинг и вариативность типа. Стрелки же - вариантивность типов - ИСКЛЮЧАЮТ.
Кстати и для "методов" можно избавится от "сигнатур". По индукции. Вводя внутри методов стереотипы <<Param>> со стрелкой к типу. Это - УНИФИЦИРУЕТ. Но! Может сказаться на производительности рисования диаграмм. Тут - надо ТЩАТЕЛЬНО подумать.
Практически получится "UML без UML". ОЧЕНЬ маленькое подмножество - "стрелки" и "квадратики". На основе которого можно нарисовать ВСЁ, что рисуется и сейчас.
Отдельно выделить - АКСИОМАТИКУ (совсем базовые примитивы) и производные (которые перед генерацией распадаются на базовые примитивы, путём их конструирования перед генерацией).
АКСИОМАТИКА - зависит от целевого языка генерации, а ПРОИЗВОДНЫЕ - не зависят. Они лишь порождают примитивы из АКСИОМАТИКИ.
Единственная языковая зависимость может выражаться либо в применяемых генераторах, либо в ifdef/ifndef.
Таким образом - получаем "компактное" языко-зависимое "ядро" и набор языко-независимых производных стереотипов.
Также надо ОКОНЧАТЕЛЬНО подумать о возможности рисования представления ПРОИЗВОДНЫХ примитивов в виде диаграмм ВНУТРИ данных примитивов. В диаграммах могут использоваться как примитивы из АКСИОМАТИКИ, так и РАНЕЕ определённые ПРОИЗВОДНЫЕ примитивы.
Эти диаграммы достаточно "просто" обрабатывать. Достаточно перебрать все элементы диаграммы и создать такие же (по образу и подобию) уже в конечном экземпляре примитива. Надо лишь учесть возможность подстановки специальных переменных типа SELF, PARENT, PARENT1..PARENTN etc. Это уже надо по месту додумывать. "Сферического коня" - тут ни в коем случае - рождать не нужно.
Также надо подумать о "разрисовывании" вызовов встроенных (и определённых ранее) примитивов DSL ПРЯМО внутри методов генерации. Чтобы в конечном итоге иметь возможность "безболезненно" сменить текстовый DSL. В виде "блок-схем".
Вкратце - может получится, что от мета-мета-модели останутся лишь стереотипы Class, Category и dependency (унаследованные от ЕДИНОГО предка Base). Все остальные - не нужны.
Причём "начать плясать" именно от "контейнерных" примеров в SandBox: Project->Library->SimpleClass. Далее понадобился ExeTarget - вводим его. Понадобился Enum или Pointer - вводим их. etc по индукции. Понадобился TestTarget и TestCase - вводим их. Ну в общем - "в стиле XP". Делаем ТОЛЬКО то, что НУЖНО в данный конкретный момент.
И смотреть на временные срезы этого хозяйства. Как оно растёт.
Там глядишь и до VCM в "новом понимании" можно добраться.
Ну и иметь в виду - http://18delphi.blogspot.com/2013/07/blog-post_24.html
Также надо подумать (в разрезе SandBox) о микро-UseCase'ах и микро-UserNeeds. Чтобы сразу под проектные классы "подкладывать" ТРЕБОВАНИЯ.
Комментариев нет:
Отправить комментарий