Вы правы, обилие функций приводит к достаточно насыщенному интерфесу работы с заданиями, Но… На картинках 1 и 4 показан «полный интрерфейс» задания, в котором доступны все возможные функции, в реальных проектах, автоматизирующих конкртеный процесс большинство функций может быть скрыто, вплоть до желанной «одной кнопки». Для этого в системе и реализованы механизмы настроек, которые мы описывали в предыдущих статьях. Такая возможность есть… однкао, как показывает практика, в большинстве реальных проектов функциональность заданий все таки оказывается достаточно сложной… Но это не большая беда, так как в любых приложениях задания более менее одинаковые и отличаются только отдельными элементами интерфейса и в тексте задания может быть зафиксирована подсказка о возможных дейсвиях, так что обучатья нужно только один раз при внедрении первого контура или приложения на базе патформы…
Как показал опыт конструктор используется очень часто. По крайней мере в тех случаях, когда приходится решать задачи не закрытые готовыми приложениями или в случае их расширения. Его использование имеет ряд преимуществ перед чистым программированием.
1. Моделировать процессы в конструкторе могут люди, которые не умеют программировать, таких достаточно много среди внедренцев нашей платформы. Благо набор сущностей достаточно богат, чтобы реализовать много сценариев без использования кода
2. В отличии от обычной программы процесс имеет средства визуализации и мониторинга, что-то типа визуального отладчика, это можно использовать как на стадии проектирования, так и при эксплуатации. По крайней мере при возникновении ошибки у вас есть визуальная возможность посмотреть где остановился процесс и прямо в карточке экземпляра процесса просмотреть журнал, определить источник проблемы, оставить процесс, что то в нем поменять и запустить далее. Хороший программист, хорошо понимающий код это сделает и безо всякого дизайнера процессов, но инженер сопровождения очень часто не является автором процесса, и мог получить его уже готовым в коробке.
3. Конечно менеджер не будет рисовать модели процессов в приложениях, это дело инженера. Но согласовать общую схему показанную в «упрощенном режиме» дизайнера или даже потыкать в кнопочки прототипа который собран с помощью конструкторов он может. И даже часто с удовольствием это делает. И это позволяет сокращать цикл и убирать гэп между моделированием и разработкой. Что же касается идеи что менеджер сам начнет себе рисовать процессы — это и правда утопия. Хотя она относится только к BPM системам. Для этого у нас есть другие упрощенные инструменты, но это уже отдельная история.
В общем конструктор процессов часто используют, почти во всех внедрениях. Да и мы сами часто его используем при создании приложений, например, модуль потокового ввода у нас реализован не в коде а с использованием конструктора бизнес процессов, что позволяет его достаточно просто модифицировать и расширять при внедрении.
Но если копнуть глубже, то на практике оказывается, что заменить десяток интерпретируемых функций настроенных в дизайнере на десяток другой строк скомпилированного кода оказывается не плохой идеей для повышения производительности системы. К чему части и прибегают разработчики. Но делается это не написанием какого-то модуля с нуля, а реализации новой функции в конструкторе в виде программного скрипта и функции расширения…
Мегамозг к сожалению совсем не об этом, Посмотрим, мне кажется, что архитектура приложений СЭД тема очеь мало освещенная именно для технической аудиториии…
Приветствую!
На самом деле компонентов в системе гараздо больше. Часть из них является общеплатформными и не меняется от приложения к приложению, к ним относятся пользователи и группы… Я же описываю структуру приложения, то есть те компоненты коорые создаются/модифицируются в конкртеном приложениии. Базовыми перечисленными компонентами список так же не исчерпывается, но для общего понмания структуры приложения их достаточно, в свое время я опишу все более подробно…
1. Моделировать процессы в конструкторе могут люди, которые не умеют программировать, таких достаточно много среди внедренцев нашей платформы. Благо набор сущностей достаточно богат, чтобы реализовать много сценариев без использования кода
2. В отличии от обычной программы процесс имеет средства визуализации и мониторинга, что-то типа визуального отладчика, это можно использовать как на стадии проектирования, так и при эксплуатации. По крайней мере при возникновении ошибки у вас есть визуальная возможность посмотреть где остановился процесс и прямо в карточке экземпляра процесса просмотреть журнал, определить источник проблемы, оставить процесс, что то в нем поменять и запустить далее. Хороший программист, хорошо понимающий код это сделает и безо всякого дизайнера процессов, но инженер сопровождения очень часто не является автором процесса, и мог получить его уже готовым в коробке.
3. Конечно менеджер не будет рисовать модели процессов в приложениях, это дело инженера. Но согласовать общую схему показанную в «упрощенном режиме» дизайнера или даже потыкать в кнопочки прототипа который собран с помощью конструкторов он может. И даже часто с удовольствием это делает. И это позволяет сокращать цикл и убирать гэп между моделированием и разработкой. Что же касается идеи что менеджер сам начнет себе рисовать процессы — это и правда утопия. Хотя она относится только к BPM системам. Для этого у нас есть другие упрощенные инструменты, но это уже отдельная история.
В общем конструктор процессов часто используют, почти во всех внедрениях. Да и мы сами часто его используем при создании приложений, например, модуль потокового ввода у нас реализован не в коде а с использованием конструктора бизнес процессов, что позволяет его достаточно просто модифицировать и расширять при внедрении.
Но если копнуть глубже, то на практике оказывается, что заменить десяток интерпретируемых функций настроенных в дизайнере на десяток другой строк скомпилированного кода оказывается не плохой идеей для повышения производительности системы. К чему части и прибегают разработчики. Но делается это не написанием какого-то модуля с нуля, а реализации новой функции в конструкторе в виде программного скрипта и функции расширения…
На самом деле компонентов в системе гараздо больше. Часть из них является общеплатформными и не меняется от приложения к приложению, к ним относятся пользователи и группы… Я же описываю структуру приложения, то есть те компоненты коорые создаются/модифицируются в конкртеном приложениии. Базовыми перечисленными компонентами список так же не исчерпывается, но для общего понмания структуры приложения их достаточно, в свое время я опишу все более подробно…