Оперативные новости и аналитические материалы мира высоких технологий
Статья

Разработка СЭД: что сможет дать "Конструктор решений"

ПО Интеграция Документооборот Бизнес-приложения Системное ПО Софт

Использование решений-конструкторов не является чем-то новым – многие разработчики не раз говорили о том, что тот или иной продукт имеет функцию конструктора и позволяет на его основе создавать готовое ПО. Тем не менее, их возможности ограничены, и на деле продуктом такой работы становятся лишь весьма ограниченные по функционалу решения. Новый инструмент со старым называнием анонсировала компания "ДоксВижн", заявив, что в реальностиэто совершенно иной продукт, существенно отличающийся от своих предшественников. В чем же заключаются эти отличия и насколько новый "Конструктор решений" облегчит жизнь и интеграторам, и заказчикам?

Еще одним плюсом использования конструктора является существенное сокращение времени и объема программирования. Это наглядно видно в представленных выше таблицах. В целом, необходимость подключения сотрудника с навыками программирования при разработке на конструкторе возникает лишь в тех местах, где нужно описать логику поведения. Наш собственный опыт разработки подсказывает, что в 80% решений вклад описания логики в общую трудоемкость создания решения не превышает 20%. При этом надо заметить, что на конструкторе и само описание логики заметно упрощается из-за использования высокоуровневой объектной модели.В результате можно говорить о том, что для разработки широкого класса решений уже не нужен хороший программист, достаточно специалиста с базовыми навыками программирования.

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

Новые понятия

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

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

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

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

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

Ролевая модель описывает роли пользователей в карточке и дает возможность задать доступность отдельных операций в зависимости от выполняемой пользователем роли.

Примеры ролей

Название ролиДействие ролиКомментарий
ВсеВсе пользователи системы
Контролер заданияОпределяется как пользователь указанный в поле контролер карточки "Задание" Простое контекстно-зависимое ролевое условие
ОтветственныйОпределяется как пользователь, работающий в том же подразделении, что и автор карточки, и одновременно состоящий в группе "Ответственные сотрудники"Два ролевых условия, связанных по "И": Контекстно-зависимое и статическое
Исполнитель связанного заданияОпределяется как пользователь, указанный в связанном с данной карточкой задании в поле "Исполнитель"Контекстно-зависимое условие, проверяющее условия в связанной карточке

Источник: "ДоксВижн", 2011

При описании ролей можно оперировать не только статическими ролями, опирающимися на конкретных пользователей и/или на группы пользователей, но и контекстно-зависимыми условиями, учитывающими данные карточек.

Вообще говоря, любое описание роли может состоять из множества отдельных ролевых условий, связанных между собой по "и" или по "или". Возможна "смесь" статических и контекстно-зависимых условий в описании роли.

Пример интерфейса описания ролей

Источник: "ДоксВижн", 2011

Следует обратить внимание на то, что, во-первых, доступность операцийдля состояний имеет приоритет. Иными словами, если операция описана как недоступная в данном состоянии, для ролей включать ее бесполезно. Во-вторых, при описании доступности операций для ролей можно применять как Allow, так и Deny.

Интерфейс доступности операций

Источник: "ДоксВижн", 2011

Существует также специальный интерфейс, позволяющий удобно управлятьдоступностью операций, а также проверять реальную доступность, указав реального пользователя.

Механизм уведомлений – это новый сервис DocsVision, который позволяет настроить уведомления при совершении любых операций в карточках. Для того, чтобы настроить уведомление, необходимо описать шаблон уведомления.

Описание шаблона уведомления

Источник: "ДоксВижн", 2011

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

История операций. Помимо всего прочего, все совершаемые в карточке операции автоматически записываются в специальный журнал.

Пример истории операций в карточке

Источник: "ДоксВижн", 2011

При этом данные журнала, относящиеся к конкретному экземпляру карточки, можно сделать доступными на просмотр прямо из самой карточки, разместив в ней стандартный элемент управления конструктора"История".

Олег Баранов