Разработка СЭД: что сможет дать "Конструктор решений"
Использование решений-конструкторов не является чем-то новым – многие разработчики не раз говорили о том, что тот или иной продукт имеет функцию конструктора и позволяет на его основе создавать готовое ПО. Тем не менее, их возможности ограничены, и на деле продуктом такой работы становятся лишь весьма ограниченные по функционалу решения. Новый инструмент со старым называнием анонсировала компания "ДоксВижн", заявив, что в реальностиэто совершенно иной продукт, существенно отличающийся от своих предшественников. В чем же заключаются эти отличия и насколько новый "Конструктор решений" облегчит жизнь и интеграторам, и заказчикам?
Еще одним плюсом использования конструктора является существенное сокращение времени и объема программирования. Это наглядно видно в представленных выше таблицах. В целом, необходимость подключения сотрудника с навыками программирования при разработке на конструкторе возникает лишь в тех местах, где нужно описать логику поведения. Наш собственный опыт разработки подсказывает, что в 80% решений вклад описания логики в общую трудоемкость создания решения не превышает 20%. При этом надо заметить, что на конструкторе и само описание логики заметно упрощается из-за использования высокоуровневой объектной модели.В результате можно говорить о том, что для разработки широкого класса решений уже не нужен хороший программист, достаточно специалиста с базовыми навыками программирования.
Иногда возникает необходимость создавать решения с очень сложной логикой и/или интерфейсом, для которых может не хватить возможностей "Конструктора решений". Однако его использование и в этом случае позволит создавать различные дизайны и привязать их к видам карточки, ролям и состояниям, для собственных интерфейсных элементов настроить видимость/размер/местоположение/метку стандартными средствами конструктора, настроить автомат состояний, роли и права доступа, уведомления на события в карточках. Помимо всего прочего, можно самостоятельно запрограммировать лишь часть интерфейса, а остальное выполнить на конструкторе. И таким образом, сделать полностью самостоятельно только самые сложные вещи, а большую часть функционала реализовать стандартным для конструктора способом.
Новые понятия
Конструктор приносит свою идеологию в разрабатываемые решения. Например, все разрабатываемые карточки обязательно имеют автомат состояний, операции перехода между состояниями и возможность настраивать доступность отдельных операций, как для различных состояний, так и для ролей пользователей.
Операцией называется любое редактирование данных в карточке, нажатие кнопки или выбор пункта меню. Операции появляются автоматически, когда в процессе конструирования какой-либо элемент управления размещается на форме карточки. Помимо этого, можно вручную определить дополнительно любое количество операций.
Как это используется? Для операций можно включать или выключать их доступность в зависимости от состояния и роли пользователя. Операции могут совершать переходы из состояния в состояние. Операции всегда фиксируются в журнале операций, который может быть доступен для просмотра. Для любой операции можно создать шаблон уведомления и настроить отправку уведомления тем или иным пользователям при ее совершении.
Автомат состояний дает возможность описать набор состояний, определить операции и/или правила перехода между состояниями и задать доступность тех или иных операций для каждого состояния.
Как правило, автомат состояний и доступность операций в различных состояниях настраиваются разработчиком решения, в отличие от настройки ролей, которая производится при внедрении.
Ролевая модель описывает роли пользователей в карточке и дает возможность задать доступность отдельных операций в зависимости от выполняемой пользователем роли.
Примеры ролей
| Название роли | Действие роли | Комментарий |
| Все | Все пользователи системы | |
| Контролер задания | Определяется как пользователь указанный в поле контролер карточки "Задание" | Простое контекстно-зависимое ролевое условие |
| Ответственный | Определяется как пользователь, работающий в том же подразделении, что и автор карточки, и одновременно состоящий в группе "Ответственные сотрудники" | Два ролевых условия, связанных по "И": Контекстно-зависимое и статическое |
| Исполнитель связанного задания | Определяется как пользователь, указанный в связанном с данной карточкой задании в поле "Исполнитель" | Контекстно-зависимое условие, проверяющее условия в связанной карточке |
Источник: "ДоксВижн", 2011
При описании ролей можно оперировать не только статическими ролями, опирающимися на конкретных пользователей и/или на группы пользователей, но и контекстно-зависимыми условиями, учитывающими данные карточек.
Вообще говоря, любое описание роли может состоять из множества отдельных ролевых условий, связанных между собой по "и" или по "или". Возможна "смесь" статических и контекстно-зависимых условий в описании роли.
Пример интерфейса описания ролей
Источник: "ДоксВижн", 2011
Следует обратить внимание на то, что, во-первых, доступность операцийдля состояний имеет приоритет. Иными словами, если операция описана как недоступная в данном состоянии, для ролей включать ее бесполезно. Во-вторых, при описании доступности операций для ролей можно применять как Allow, так и Deny.
Интерфейс доступности операций
Источник: "ДоксВижн", 2011
Существует также специальный интерфейс, позволяющий удобно управлятьдоступностью операций, а также проверять реальную доступность, указав реального пользователя.
Механизм уведомлений – это новый сервис DocsVision, который позволяет настроить уведомления при совершении любых операций в карточках. Для того, чтобы настроить уведомление, необходимо описать шаблон уведомления.
Описание шаблона уведомления
Источник: "ДоксВижн", 2011
При этом можно задать параметры уведомлений, например, включать данные карточки в текст уведомления, задавать дополнительные условия "срабатывания" уведомления в виде поискового запроса, настраивать периодические уведомленияили уведомления с отложенным сроком действия, гибко регулировать список получателей, а также использовать различные способы доставки уведомлений. При получении уведомлений пользователь имеет возможность отписаться от дальнейшего получения подобных уведомлений.
История операций. Помимо всего прочего, все совершаемые в карточке операции автоматически записываются в специальный журнал.
Пример истории операций в карточке
Источник: "ДоксВижн", 2011
При этом данные журнала, относящиеся к конкретному экземпляру карточки, можно сделать доступными на просмотр прямо из самой карточки, разместив в ней стандартный элемент управления конструктора"История".
Короткая ссылка на материал: //cnews.ru/link/a2585
