company_banner

Про биологию, мега-стройки и магических животных

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



    Фронт-офисная биология


    Задача: есть Банк с огромной линейкой банковских продуктов и сервисов по каждому из продуктов (подробнее наwww.sberbank.ru). Необходимо автоматизировать все фронтальные сценарии по каждому из продуктов, по каждому из каналов для разных групп клиентов (да, да – разные категории клиентов могут иметь разные сценарии обслуживания по одному каналу).

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

    • Количество сценариев (фронтальных процессов): ~ 103
    • Количество визуальных форм в сценариях: ~104
    • Количество печатных форм в сценариях: ~2 ᵡ 103

    Уже лучше. У нас есть какая-то фактура, но пока это какая-то замершая экосистема без динамики и без эволюции.

    Однако,

    • те, от кого зависит общее количество продуктов и сценариев их обслуживания, раз в квартал согласуют новый план по продажам и выпускают новые продукты и акции, требующие замены старых сценариев и селекции дополнительных «гибридных» сценариев в рамках кросс-продаж. За год весь старый функционал может быть заменен на новый.

    • те, от кого зависит дизайн визуальных форм периодически склонны радикально менять или дизайн или принципы наполнения форм, то предполагая замену всей популяции сценариев, форм, сопутствующего функционала, то требуя ее увеличения на порядок до ~105

    • ЦБ РФ, как метеорит, убивший динозавров, может аффектить всех, требуя своими новыми положениями пересмотр и ревизию всего функционала целиком.

    Но есть еще и факторы, благоприятно сказывающиеся на росте количества функционала:

    • Ожидания бизнеса по возможности выстраивания сегмента-ориентированных или персонифицированных процессов обслуживания, что является удачной почвой для роста количества вариантов сценариев обслуживания до ~ 104

    • Естественно, все сценарии нужно тестировать на эффективность либо landing page, либо на удобство рабочего места оператора, что если опять не плодит кол-во самих сценариев, то увеличивает популяцию визуальных форм до ~105-6

    • Есть и длительные тренды внутривидовой борьбы. Например, удаленное обслуживание вытесняет офисное, и фронтальный функционал по удаленным каналам растет сам по себе. При этом офис не сдается – пытается получить часть «генофонда удаленки» и создать новые сценарии омниканального (Omni channel) обслуживания — ~105-∞

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

    Не вавилонская система


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

    Сам по себе RAD доступен практически во всех фронтальных отраслевых решениях. Однако он строится вокруг конфигурационного ядра либо слабо гранулированной архитектуры, что не позволяет нам решить вышеуказанную задачу с перекрытиями. Естественно с конфигурационным ядром так нельзя, извлечение или замена любой несущей конструкции приведет к обрушению, перестройки всего прикладного функционала вместе с обязательным регрессом.

    Кроме того, конфигурационное ядро не позволяет нам удовлетворить ожидания экспоненциального роста количества функционала, о котором говорили ранее. RAD – это быстрее для типового функционала, но RAD не позволяет «порождать» новый приклад на основе уже существующего.

    Решение пришло со стороны MDD (Model Driven Development). Это только на первый взгляд «предметно-ориентированный язык» — это что-то абстрактное и заумное. Нам же никто не мешает создать «предметно-ориентированный язык» самих конфигураций. При том, конфигураций разных этажей башни: архитектуры, функционала, самой банковской области могут трансформироваться друг в друга и, в конце концов в исполняемый код. Мы положились на следующие преимущества MDD:

    • Конечный исполняемый код можно всегда переопределить или дописать функционал, не трогая алгоритмы трансформации и получить важное частное решение

    • Сами алгоритмы трансформации можно заменять и расширять, не меняя уже сгенерированный код. Как мы говорили выше, целевой срок его жизни не большой

    • И самое главное. Уже готовый прикладной функционал это всего лишь один из видов модели и только потом конечный код. А значит, для него можно придумать алгоритм, который перегонит его, по необходимости, в другую модель при замене архитектуры, требований ЦБ, необходимости автоматизации A/B-тестов, порождению специализированных сценариев обслуживания по каналам и сегментам потребителей.

    Так мы дошли до понимания как делать башню, которая в какой-то момент должна начать строить саму себя.

    Магический зверь и где он обитает


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


    АРМ Архитектора


    АРМ Системного аналитика


    АРМ Системного аналитика


    Да, мы посадили наших системных аналитиков за Eclipse + Papyrus. Общая модель конфигураций пока построена на базе зарендеренного дерева UML-объектов и позволяет сейчас конфигурировать: общую декомпозицию требований, артефакты конфигураций процессов, визуальных форм, точек интеграции, сущности и их атрибуты, справочники и кучу системных объектов самой платформы ЕФС. Чуть позже здесь будет и JasperReport-редактор.

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


    Общая модель генерации кода

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

    Следующий этап генерации, это генерация компонентной модели. Как видно на первом скриншоте, модель выглядит достаточно скучно: просто оранжевые и белые квадратики. Это компоненты (в нашей терминологии – прикладные модули), которые на следующем этапе трансформируются в конечный код. Внутри каждого модуля обозначены ключевые классы с соответствующей ролью – типовым паттерном взаимодействия. Все это, в конце концов, и превращается в исполняемый код.

    Естественно, при нажатии магической кнопки с единорогом, на уровне функциональной модели весь конвейер трансформаций проходит за раз. Но наличие такой пошаговой генерации позволяет нам:

    • Наконец, добавить слой бизнес-конструкторов независимо от организации функционального слоя и компонентной архитектуры

    • Расширять состав функциональных элементов и добавлять канало-специфичные функциональные элементы

    • Управлять компонентной архитектурой независимо от функционала

    • Ограничить сложность кода трансформации группы связанных конфигурационных элементов одного уровня в другой группу другого элемента объемом в 1K-2K строк кода.

    • Решать задачи детально, но не глобально. Например, задачи трансформации VO->DTO->VO очень часто имеет частное решение объемом «да ладно, за эти выходные точно запилю».

    • Иметь на каждом слое немножечко избыточное кол-во конфигураций, чтобы автоматизировать порождение частных случаев конфигураций и «автоматизировать автоматизацию автоматизации». Например, для канального фронтального сценария порождение множества его вариация для A/B-тестирования может быть выполнено автоматически.  Ну и маппинг, маппинг, маппинг.

    Как уже говорили в предыдущих двух разделах, последний пункт особенно важен. Он то и позволит 104 визуальных форм превращать в 105 для задач автоматизации A/B-тестов или вывода сценария в новый канал. При этом трудозатраты не увеличиваются и в 2 раза.

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

    Любой конечный код должен иметь возможность быть исправлен и доработан вручную. Исправления такого рода, особенно если вопрос касается необходимости добавления небольшой фичи или исправления багов во время функционального/интеграционного тестирования часто проходят мимо других участников – не отражаются в спецификации или, как в нашем случае, в модели.

    Для обеспечения полноты конфигураций мы разработали функционал, автоматизирующий реверс-инжиниринг (Reverse engineering). Мы строим Java Model выделенного блока функционала, соответствующего отдельному прикладному модулю (оранжевый квадратик на первом скриншоте), и пытаемся распознать паттерны кода, сравнивая их с тем что есть в компонентной модели. Пока эта магия более-менее успешно работает для прикладных сущностей, публичного API, ключевых системных объектов.

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

    Comments 5

      +1
      Автоматизированный реверс-инжиниринг — это очень интересно, хочется подробностей или даже отдельной публикации по нему.

      Цифры форм впечатляют. Уже запустили в продакшен? Заметен эффект от автоматизации?
        +2
        Про реверс конечно сделаем отдельную публикацию.

        Сам RAD-инструмент прямо сейчас запущен в ряд проектов, где уже участники проектов стали работать с ним. Говорить о конкретных метриках и показателях эффективности пока рано, но по текущему опыту один пользователь за день по UX-постановке может за 1-2 дня набросать процесс типа «блокировки карты» на заглушках. Доведение набросков до прома и есть текущий этап внедрения RAD-инструмента.
        0
        У вас очень интересный проект, я думал модельно-ориентированной разработкой у нас никто не занимается.

        Важным элементом функциональной модели является огромное количество валидаций. Для пользователей, не являющихся профессиональными разработчиками, причина, по которой код не компилируется, или выскакивает NPE, будет тайной. По аналогичным причинам в систему добавлен стандартный для таких решений функционал пошаговой отладки процессов фронтальных сценариев.
        Правила валидации моделей можно описывать на языке OCL в UML профиле. Может, даже и не потребуется делать отладчик. По крайней мере, ошибки в модели, приводящие к NPE или ошибкам компиляции наверняка можно обнаружить с помощью статического анализа (у нас в одном проекте было порядка 300 правил на языке OCL, очень удобная штука). Отладка, конечно, тоже штука полезная, с помощью неё можно искать логические ошибки в сценариях.

        Любой конечный код должен иметь возможность быть исправлен и доработан вручную. Исправления такого рода, особенно если вопрос касается необходимости добавления небольшой фичи или исправления багов во время функционального/интеграционного тестирования часто проходят мимо других участников – не отражаются в спецификации или, как в нашем случае, в модели.
        Меня это очень смущает в вашем подходе. Я бы не заморачивался с реверс-инжинирингом. И либо запретил бы изменение кода не через модель, либо разделил бы генерируемый код и кастомизируемый. Честно говоря, первый вариант реализовать сложно. У нас был проект, в котором мы генерили на основе модели документацию. Аналитик сделал модель, сгенерил по ней документ, отправил заказчику, заказчик в документе что-то исправил и отправил дальше на согласование. А до аналитика эти изменения либо не дошли, либо он не успел их внести. Короче это идеализированный вариант. А с разделением кода вполне реальный.

        А редактор форм в Papyrus вы сами сделали? Или уже готовый есть? Не видел такой.

        Мы сталкивались с тем, что UML не всегда удобен. Например, на нём сложно проектировать древовидные структуры. Или много времени уходит на добавление UML стереотипов: нужно создать класс, перейти на вкладку стереотипов, нажать кнопку «добавить», выбрать стереотип, нажать ок. А хочется всё это делать одной кнопкой. Как вариант, можно отказаться от UML, запилить свою Ecore модель ровно с теми сущностями и атрибутами, какие нужны и не заморачиваться со стереотипами. Я описывал в этой статье как это сделать. А потом с помощью Eclipse Sirius запилить редактор диаграмм. Он использует те же самые фреймвоки, что и Papyrus, будет ничем не хуже, только заточен конкретно под вашу модель, без лишнего. Или можно даже такие штуки делать на Sirius. Кстати в нем легко сделать симуляцию моделей (или отладку сценариев в вашем случае). Посмотрите примеры. Очень клевая штука!

        Ну, и конечно, в плане преобразований модель-модель и модель-код. Есть много готовых DSL, заточенных конкретно под эту задачу (статья 1, статья 2, статья 3). Я бы не стал писать преобразования на Java.
          0
          Спасибо за подробный комментарий.
          1. Мы действительно используем OCL для задания ограничений. Далее OCL-выражение трансформируется либо в Java, либо в TypeScrypt. Зависит от того, где исполняется код: серверной или клиентской части
          2. Запретить изменять код означает запретить создавать новые слабо формализуемые фичи, да и костыль бывает необходимо воткнуть. Здесь, главное, не терять такого рода изменения
          3. Редактор форм, в отличии от других визуализаций, сделан прямо на базе Eclipse.
          4. Мы отошли от редактирования через ручное добавление наследников Element и задания стереотипов. На этом этапе мы использовали IBM RSA. Естественно, дерево в ModelExplorer — это дерево наследников Element, но добавление каждого из них осуществляется по кнопке контекстного меню с предопределенным стереотипом.
          5. Спасибо. Примеры обязательно посмотрим.
          –2
          Приглашаем на технологическую конференцию Сбербанка «Продвижение» 3 июня 2017г. в DI Telegraph (Москва, ул. Тверская 7).
          В программе выступления по актуальным темам разработки и архитектуры, мастер-классы и демонстрация передовых разработок на основе технологий искусственного интеллекта, биометрии, дополненной и виртуальной реальности.
          Вход свободный по предварительной регистрации https://ufs-programm.timepad.ru/event/490838/
          Актуальная программа и новости мероприятия в группе https://www.facebook.com/groups/433394900345631/

          Only users with full accounts can post comments. Log in, please.