Спасибо за подробный комментарий.
1. Мы действительно используем OCL для задания ограничений. Далее OCL-выражение трансформируется либо в Java, либо в TypeScrypt. Зависит от того, где исполняется код: серверной или клиентской части
2. Запретить изменять код означает запретить создавать новые слабо формализуемые фичи, да и костыль бывает необходимо воткнуть. Здесь, главное, не терять такого рода изменения
3. Редактор форм, в отличии от других визуализаций, сделан прямо на базе Eclipse.
4. Мы отошли от редактирования через ручное добавление наследников Element и задания стереотипов. На этом этапе мы использовали IBM RSA. Естественно, дерево в ModelExplorer — это дерево наследников Element, но добавление каждого из них осуществляется по кнопке контекстного меню с предопределенным стереотипом.
5. Спасибо. Примеры обязательно посмотрим.
Первая модель — это модель исходных функциональных элементов (формы, процессы, точки интеграции). Она совсем оторвана от языка, на котором будет генерироваться исходный код. Вводная по ней была в предыдущей статье.
Вторая модель — это модель типовых паттернов, на базе компонентной модели, описанной в данной статье. Она уже ближе к фактической реализации и предполагает генерацию кода на ООП.
Ну и в конце-концов — исходный код на Java
Преобразования в обратную сторону также идут, как Вы указали.
Добрый день. Мы явно используем API JavaModel. В части типов, атрибутов, операций (методов) оно достаточно похоже на uml2, так что выявлять различия в коде и исходной модели удобно без дополнительных инструментов.
Спасибо за обратную связь, поясню.
В данной публикации мы обозначили тему, которую раскроем в нескольких статьях. В следующем материале, речь пойдет про интеграцию Eclipse Modeling Framework в инструменты DevOps. И никаких электриков, архитекторов и представителей Q&A :)
Сегодня, мы поделились с Вами общей проблематикой управления компонентной архитектурой в крупном корпоративном приложении. Но связывая этот текст с предыдущей публикацией и анонсируя будущую, конкретизирую:
Мы автоматизировали процесс создания отдельных компонент (выше по тексту — модули), осуществляя прямую генерацию самих компонент и всех слоев изоляции внутри модулей, непосредственно из самой функциональной конфигурации (см. предыдущую публикацию)
Реализовано на базе EMF с созданием собственной Model2Model трансформации и далее Model2Java трансформации.
Важно что все конфигурации в рабочем места аналитика заранее валидируются на M2M генерацию с поддержкой приведенных в статье шаблонов проектирования для типового функционала фронт-офиса.
Естественно, любой код может быть доработан руками. Требуется проверять изменения на нарушения по зависимостям модулей, да и вообще использования типовых паттернов.
Для этого мы строим JavaModel кода (выполняем reverse) и выполняем трансформацию в модель, аналогичную исходной, из которой шла генерация кода.
Сравниваем, 2 модели, ищем расхождения. Допустимые включаются в модель (пока в полу ручном режиме). Не допустимые фиксируются в отчете и отправляются в команду, вносившую изменения в сгенерированный код.
Сам RAD-инструмент прямо сейчас запущен в ряд проектов, где уже участники проектов стали работать с ним. Говорить о конкретных метриках и показателях эффективности пока рано, но по текущему опыту один пользователь за день по UX-постановке может за 1-2 дня набросать процесс типа «блокировки карты» на заглушках. Доведение набросков до прома и есть текущий этап внедрения RAD-инструмента.
1. Мы действительно используем OCL для задания ограничений. Далее OCL-выражение трансформируется либо в Java, либо в TypeScrypt. Зависит от того, где исполняется код: серверной или клиентской части
2. Запретить изменять код означает запретить создавать новые слабо формализуемые фичи, да и костыль бывает необходимо воткнуть. Здесь, главное, не терять такого рода изменения
3. Редактор форм, в отличии от других визуализаций, сделан прямо на базе Eclipse.
4. Мы отошли от редактирования через ручное добавление наследников Element и задания стереотипов. На этом этапе мы использовали IBM RSA. Естественно, дерево в ModelExplorer — это дерево наследников Element, но добавление каждого из них осуществляется по кнопке контекстного меню с предопределенным стереотипом.
5. Спасибо. Примеры обязательно посмотрим.
Преобразования в обратную сторону также идут, как Вы указали.
В данной публикации мы обозначили тему, которую раскроем в нескольких статьях. В следующем материале, речь пойдет про интеграцию Eclipse Modeling Framework в инструменты DevOps. И никаких электриков, архитекторов и представителей Q&A :)
Сегодня, мы поделились с Вами общей проблематикой управления компонентной архитектурой в крупном корпоративном приложении. Но связывая этот текст с предыдущей публикацией и анонсируя будущую, конкретизирую:
Но это же так скучно ;)
Сам RAD-инструмент прямо сейчас запущен в ряд проектов, где уже участники проектов стали работать с ним. Говорить о конкретных метриках и показателях эффективности пока рано, но по текущему опыту один пользователь за день по UX-постановке может за 1-2 дня набросать процесс типа «блокировки карты» на заглушках. Доведение набросков до прома и есть текущий этап внедрения RAD-инструмента.