- PVSM.RU - https://www.pvsm.ru -
История в многих частях с продолжением и еще никому не известным (но обязательно счастливым) концом.
Задача: есть Банк с огромной линейкой банковских продуктов и сервисов по каждому из продуктов (подробнее на http://www.sberbank.ru [2]). Необходимо автоматизировать все фронтальные сценарии по каждому из продуктов, по каждому из каналов для разных групп клиентов (да, да – разные категории клиентов могут иметь разные сценарии обслуживания по одному каналу).
Пока звучит скучно и непонятно. Однако те, кому приходилось автоматизировать финансовый сектор, могут прикинуть количество фронтальных сценариев к автоматизации и необходимое количество функциональных элементов. Простые инженерные оценки дадут приблизительно следующие показатели:
Уже лучше. У нас есть какая-то фактура, но пока это какая-то замершая экосистема без динамики и без эволюции.
Однако,
Но есть еще и факторы, благоприятно сказывающиеся на росте количества функционала:
Похоже, что фронтальный функционал склонен размножаться и эволюционировать как бактерии в питательной среде и любое внешнее влияние, кроме морального устаревания канала обслуживания, только загибает рост экспоненты. Бочкой Петри для фронт-офисного функционала Сбербанка должна стать Единая Фронтальная Система или сокращенно ЕФС.
Естественно, автоматизацию такого масштаба на одной коленке не построить и не поддержать последующие изменения. Решение, выводящее общее количество коленок строителей на горизонтальную асимптоту, не столь очевидно. Кроме того, что кирпичей много и их нужно очень быстро складывать, нужно еще уметь заменять перекрытия нижних этажей, не обрушив верхние.
Поскольку вычислительная сложность целевого решения низкая и функционал в основном раскладывается на типовой, как кирпичи лего, высокую скорость стройки даст RAD.
Сам по себе RAD доступен практически во всех фронтальных отраслевых решениях. Однако он строится вокруг конфигурационного ядра либо слабо гранулированной архитектуры, что не позволяет нам решить вышеуказанную задачу с перекрытиями. Естественно с конфигурационным ядром так нельзя, извлечение или замена любой несущей конструкции приведет к обрушению, перестройки всего прикладного функционала вместе с обязательным регрессом.
Кроме того, конфигурационное ядро не позволяет нам удовлетворить ожидания экспоненциального роста количества функционала, о котором говорили ранее. RAD – это обычно быстрее для типового функционала, но RAD не позволяет «порождать» новый приклад на основе уже существующего.
Решение пришло со стороны MDD (Model Driven Development). Это только на первый взгляд «предметно-ориентированный язык» — это что-то абстрактное и заумное. Нам же никто не мешает создать «предметно-ориентированный язык» самих конфигураций при том, конфигураций разных этажей башни: архитектуры, функционала, самой банковской области могут трансформироваться друг в друга и в конце концов в исполняемый код. Мы положились на следующие преимущества MDD:
Так мы дошли до понимания как делать башню, которая в какой-то момент должна начать строить саму себя.
Собственно, именно этот магический зверь обитает у нас на кнопке запуска процесса генерации. Как это выглядит рабочее место пользователя, представлено на скриншотах ниже.
АРМ Архитектора
АРМ Системного аналитика
АРМ Системного аналитика
Да, мы посадили наших системных аналитиков за Eclipse + Papyrus. Общая модель конфигураций пока построена на базе зарендеренного дерева UML-объектов и позволяет сейчас конфигурировать: общую декомпозицию требований, артефакты конфигураций процессов, визуальных форм, точек интеграции, сущностей, их атрибутов справочников и кучу системных объектов самой платформы ЕФС. Чуть позже здесь будет и JasperReport-редактор.
Общая целевая модель генерации приведена на схеме ниже. Первый пока отсутствующий уровень — это уровень конструкторов предметной области. Объекты модели предметной области трансформируются в объекты функциональной модели. Например, в планах реализация конструктора заявки на банковский продукт, включая статусную модель. Последняя будет иметь свою волшебную кнопку и порождать на уровне функциональной модели прототип процесса, для работы с заявкой.
Общая модель генерации кода
Второй уровень, это собственно уровень модели функциональных элементов. Он позволяет уже породить первый полезный артефакт для IT-проекта – полную спецификацию функциональных элементов.
Следующий этап генерации, это генерация компонентной модели. Как видно на первом скриншоте, модель выглядит достаточно скучно: просто оранжевые и белые квадратики. Это компоненты (в нашей терминологии – прикладные модули), которые на следующем этапе трансформируются в конечный код. Внутри каждого модуля обозначены ключевые классы с соответствующей ролью – типовым паттерном взаимодействия. Все это в конце концов и превращается в исполняемый код.
Естественно, при нажатии магической кнопки с единорогом на уровне функциональной модели весь конвейер трансформаций проходит за раз. Но наличие такой пошаговой генерации позволяет нам:
Как уже говорили в предыдущих двух разделах, последний пункт особенно важен. Он то и позволит 104 визуальных форм превращать в 105 для задач автоматизации A/B-тестов или вывода сценария в новый канал. При этом трудозатраты не увеличиваются и в 2 раза.
Важным элементом функциональной модели является огромное количество валидаций, так как для пользователей, не являющихся профессиональными разработчиками, причина, по которой код не компилируется, или выскакивает NPE, будет тайной. По аналогичным причинам в систему добавлен стандартный для таких решений функционал пошаговой отладки процессов фронтальных сценариев.
Любой конечный код должен иметь возможность быть исправлен и доработан вручную. Исправления такого рода, особенно если вопрос касается необходимости добавления небольшой фичи или исправления багов во время функционального/интеграционного тестирования часто проходят мимо других участников – не отражаются в спецификации или, как в нашем случае, в модели.
Для обеспечения полноты конфигураций мы разработали функционал, автоматизирующий реверс-инжиниринг (Reverse engineering). Мы строим Java Model выделенного блока функционала, соответствующего отдельному прикладному модулю (оранжевый квадратик на первом скриншоте) и пытаемся распознать паттерны кода, сравнивая их с тем что есть в компонентной модели. Пока эта магия более-менее успешно работает для прикладных сущностей, публичного API, ключевых системных объектов.
На этом пока все. А чтобы разобраться детальнее с внутренней механикой инструмента, требований к нему и архитектурой, в следующей статье мы поговорим о том, что общего у электриков и архитекторов из IT.
Автор:
Источник [3]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/java/250521
Ссылки в тексте:
[1] Image: https://habrahabr.ru/company/efs/blog/324626/
[2] http://www.sberbank.ru: http://www.sberbank.ru/
[3] Источник: https://habrahabr.ru/post/324626/
Нажмите здесь для печати.