Comments 5
Автоматизированный реверс-инжиниринг — это очень интересно, хочется подробностей или даже отдельной публикации по нему.
Цифры форм впечатляют. Уже запустили в продакшен? Заметен эффект от автоматизации?
Цифры форм впечатляют. Уже запустили в продакшен? Заметен эффект от автоматизации?
Про реверс конечно сделаем отдельную публикацию.
Сам RAD-инструмент прямо сейчас запущен в ряд проектов, где уже участники проектов стали работать с ним. Говорить о конкретных метриках и показателях эффективности пока рано, но по текущему опыту один пользователь за день по UX-постановке может за 1-2 дня набросать процесс типа «блокировки карты» на заглушках. Доведение набросков до прома и есть текущий этап внедрения RAD-инструмента.
Сам RAD-инструмент прямо сейчас запущен в ряд проектов, где уже участники проектов стали работать с ним. Говорить о конкретных метриках и показателях эффективности пока рано, но по текущему опыту один пользователь за день по UX-постановке может за 1-2 дня набросать процесс типа «блокировки карты» на заглушках. Доведение набросков до прома и есть текущий этап внедрения RAD-инструмента.
У вас очень интересный проект, я думал модельно-ориентированной разработкой у нас никто не занимается.
А редактор форм в Papyrus вы сами сделали? Или уже готовый есть? Не видел такой.
Мы сталкивались с тем, что UML не всегда удобен. Например, на нём сложно проектировать древовидные структуры. Или много времени уходит на добавление UML стереотипов: нужно создать класс, перейти на вкладку стереотипов, нажать кнопку «добавить», выбрать стереотип, нажать ок. А хочется всё это делать одной кнопкой. Как вариант, можно отказаться от UML, запилить свою Ecore модель ровно с теми сущностями и атрибутами, какие нужны и не заморачиваться со стереотипами. Я описывал в этой статье как это сделать. А потом с помощью Eclipse Sirius запилить редактор диаграмм. Он использует те же самые фреймвоки, что и Papyrus, будет ничем не хуже, только заточен конкретно под вашу модель, без лишнего. Или можно даже такие штуки делать на Sirius. Кстати в нем легко сделать симуляцию моделей (или отладку сценариев в вашем случае). Посмотрите примеры. Очень клевая штука!
Ну, и конечно, в плане преобразований модель-модель и модель-код. Есть много готовых DSL, заточенных конкретно под эту задачу (статья 1, статья 2, статья 3). Я бы не стал писать преобразования на Java.
Важным элементом функциональной модели является огромное количество валидаций. Для пользователей, не являющихся профессиональными разработчиками, причина, по которой код не компилируется, или выскакивает NPE, будет тайной. По аналогичным причинам в систему добавлен стандартный для таких решений функционал пошаговой отладки процессов фронтальных сценариев.Правила валидации моделей можно описывать на языке OCL в UML профиле. Может, даже и не потребуется делать отладчик. По крайней мере, ошибки в модели, приводящие к NPE или ошибкам компиляции наверняка можно обнаружить с помощью статического анализа (у нас в одном проекте было порядка 300 правил на языке OCL, очень удобная штука). Отладка, конечно, тоже штука полезная, с помощью неё можно искать логические ошибки в сценариях.
Любой конечный код должен иметь возможность быть исправлен и доработан вручную. Исправления такого рода, особенно если вопрос касается необходимости добавления небольшой фичи или исправления багов во время функционального/интеграционного тестирования часто проходят мимо других участников – не отражаются в спецификации или, как в нашем случае, в модели.Меня это очень смущает в вашем подходе. Я бы не заморачивался с реверс-инжинирингом. И либо запретил бы изменение кода не через модель, либо разделил бы генерируемый код и кастомизируемый. Честно говоря, первый вариант реализовать сложно. У нас был проект, в котором мы генерили на основе модели документацию. Аналитик сделал модель, сгенерил по ней документ, отправил заказчику, заказчик в документе что-то исправил и отправил дальше на согласование. А до аналитика эти изменения либо не дошли, либо он не успел их внести. Короче это идеализированный вариант. А с разделением кода вполне реальный.
А редактор форм в Papyrus вы сами сделали? Или уже готовый есть? Не видел такой.
Мы сталкивались с тем, что UML не всегда удобен. Например, на нём сложно проектировать древовидные структуры. Или много времени уходит на добавление UML стереотипов: нужно создать класс, перейти на вкладку стереотипов, нажать кнопку «добавить», выбрать стереотип, нажать ок. А хочется всё это делать одной кнопкой. Как вариант, можно отказаться от UML, запилить свою Ecore модель ровно с теми сущностями и атрибутами, какие нужны и не заморачиваться со стереотипами. Я описывал в этой статье как это сделать. А потом с помощью Eclipse Sirius запилить редактор диаграмм. Он использует те же самые фреймвоки, что и Papyrus, будет ничем не хуже, только заточен конкретно под вашу модель, без лишнего. Или можно даже такие штуки делать на Sirius. Кстати в нем легко сделать симуляцию моделей (или отладку сценариев в вашем случае). Посмотрите примеры. Очень клевая штука!
Ну, и конечно, в плане преобразований модель-модель и модель-код. Есть много готовых DSL, заточенных конкретно под эту задачу (статья 1, статья 2, статья 3). Я бы не стал писать преобразования на Java.
Спасибо за подробный комментарий.
1. Мы действительно используем OCL для задания ограничений. Далее OCL-выражение трансформируется либо в Java, либо в TypeScrypt. Зависит от того, где исполняется код: серверной или клиентской части
2. Запретить изменять код означает запретить создавать новые слабо формализуемые фичи, да и костыль бывает необходимо воткнуть. Здесь, главное, не терять такого рода изменения
3. Редактор форм, в отличии от других визуализаций, сделан прямо на базе Eclipse.
4. Мы отошли от редактирования через ручное добавление наследников Element и задания стереотипов. На этом этапе мы использовали IBM RSA. Естественно, дерево в ModelExplorer — это дерево наследников Element, но добавление каждого из них осуществляется по кнопке контекстного меню с предопределенным стереотипом.
5. Спасибо. Примеры обязательно посмотрим.
1. Мы действительно используем OCL для задания ограничений. Далее OCL-выражение трансформируется либо в Java, либо в TypeScrypt. Зависит от того, где исполняется код: серверной или клиентской части
2. Запретить изменять код означает запретить создавать новые слабо формализуемые фичи, да и костыль бывает необходимо воткнуть. Здесь, главное, не терять такого рода изменения
3. Редактор форм, в отличии от других визуализаций, сделан прямо на базе Eclipse.
4. Мы отошли от редактирования через ручное добавление наследников Element и задания стереотипов. На этом этапе мы использовали IBM RSA. Естественно, дерево в ModelExplorer — это дерево наследников Element, но добавление каждого из них осуществляется по кнопке контекстного меню с предопределенным стереотипом.
5. Спасибо. Примеры обязательно посмотрим.
Приглашаем на технологическую конференцию Сбербанка «Продвижение» 3 июня 2017г. в DI Telegraph (Москва, ул. Тверская 7).
В программе выступления по актуальным темам разработки и архитектуры, мастер-классы и демонстрация передовых разработок на основе технологий искусственного интеллекта, биометрии, дополненной и виртуальной реальности.
Вход свободный по предварительной регистрации https://ufs-programm.timepad.ru/event/490838/
Актуальная программа и новости мероприятия в группе https://www.facebook.com/groups/433394900345631/
В программе выступления по актуальным темам разработки и архитектуры, мастер-классы и демонстрация передовых разработок на основе технологий искусственного интеллекта, биометрии, дополненной и виртуальной реальности.
Вход свободный по предварительной регистрации https://ufs-programm.timepad.ru/event/490838/
Актуальная программа и новости мероприятия в группе https://www.facebook.com/groups/433394900345631/
Sign up to leave a comment.
Про биологию, мега-стройки и магических животных