Первые компьютерные системы, автоматизирующие управление бизнес-процессами появились давно, в начале 90-х годов прошлого века. Развитие СУБП систем за прошедший период, в частности, заимствование одними системами различных решений, примененных в других системах, привело к появлению у этого класса программного обеспечения большого количества общих черт. Например, современные СУБП поддерживают такие понятия, как определение бизнес-процесса и экземпляр бизнес-процесса, определение бизнес-процесса обязательно содержит графическую схему бизнес-процесса, состоящую из узлов и переходов между ними. Также современные СУБП используют роли бизнес-процесса и правила назначения исполнителей на роли.
Основной задачей СУБП является генерация заданий исполнителям и контроль за их выполнением. (Задание генерируется в момент прихода точки управления в узел-действие). Современные СУБП поддерживают связанный с основной задачей набор функций, который примерно одинаков во всех распространенных СУБП. Эти функции реализуются при помощи графических интерфейсов, которые тоже примерно одинаковы в различных СУБП.
В данном разделе показаны структура, основные компоненты и графические интерфейсы типичной СУБП, описано взаимодействие между ними, кратко пояснена работа пользователей с интерфейсами системы.
Для иллюстрации примеров графических интерфейсов в настоящем курсе использована система RunaWFE Professional Онлайн.
Современная СУБП должна обеспечивать разработку бизнес-процессов в графической среде, исполнение экземпляров бизнес-процессов, мониторинг состояний экземпляров, ведение истории событий экземпляров бизнес-процессов, интеграцию приложений при помощи используемых бизнес-процессами коннекторов, администрирование пользователей, а также возможность замещения исполнителей заданий.
Для выполнения этих функций в СУБП служат следующие графические интерфейсы:
Для создания и изменения бизнес-процессов обычно применяются графические дизайнеры, являющиеся частью среды разработки, которые могут быть как отдельными самостоятельными программами, так и интернет-приложениями.
Типичная СУБП состоит из следующих основных компонентов:
Среда исполнения бизнес-процессов - это основной компонент СУБП. Она реализует исполнение экземпляра бизнес-процесса в соответствии с его определением. Этот компонент содержит определения загруженных в него бизнес-процессов и выполняющиеся экземпляры бизнес-процессов. Генерирует списки заданий и визуальные формы, соответствующие заданиям. Как правило, среда исполнения бизнес-процессов позволяет создавать и изменять свойства пользователей, а также дает возможность устанавливать различные права на объекты системы.
Среда разработки бизнес-процессов служит для создания и модификации исполнимых бизнес-процессов. В этой среде определяются последовательность выполнения шагов бизнес-процесса и данные, назначаются роли участникам процесса, вводятся правила маршрутизации, определяются графические формы заданий, используемые участниками бизнес-процесса для выполнения задач. Среда разработки позволяет сконструировать графическую схему бизнес-процесса с описанием ее деталей в виде свойств отдельных элементов (действий, подпроцессов, маршрутных узлов и т.д.) или бизнес-процесса в целом. Среда разработки - инструмент разработчика бизнес-процессов (бизнес-аналитика). Он, в частности, обеспечивает внесение изменений в бизнес-процесс путем модификации графической схемы и свойств элементов.
При помощи интерфейсов для работы с заданиями исполнителей пользователь может:
При помощи интерфейсов для администрирования системы администратор может:
Используя среду разработки, бизнес-аналитик может разрабатывать бизнес-процессы, включая бизнес-правила, различные элементы коннекторов к внешним системам и другие элементы, а также загружать их в среду исполнения.
При помощи среды разработки бизнес-аналитики
Для разработки бизнес-процесса бизнес-аналитику надо:
После того, как бизнес-процесс разработан, он загружается в Среду исполнения. После этого можно запускать экземпляры данного бизнес-процесса и выполнять генерируемые ими задания.
На схеме бизнес-процесса узлы процесса можно изображать по-разному. Способ изображения узлов и переходов важен, потому что от этого зависит легкость (или сложность) понимания бизнес-процесса людьми.
Согласованные наборы графических элементов, из которых строятся схемы бизнес-процессов, называются графическими нотациями изображения бизнес-процессов. Наиболее известной графической нотацией изображения бизнес-процессов является: BPMN (подробнее о стандарте bpmn рассказывается в лекции 3.)
Базовые элементы нотации BPMN, относящиеся к перспективе потока управления:
Узел-Действие:
Шлюзы. В BPMN существует единая форма для узлов-шлюзов, представляющая собой ромбик:
Конкретные шлюзы отличаются изображенными внутри этой формы иконками.
Ветвление - Узел выбора направления дальнейшего движения точки управления:
Внутри ромбика содержится иконка - "крестик".
Разделение - Разделение точки управления на несколько точек управления:
Внутри ромбика содержится иконка - "плюсик".
Слияние - Слияние точек управления в одну точку управления:
Элемент точно такой же, как и разделение, однако у него должен быть только один исходящий переход и несколько входящих.
Во время выполнения бизнес-процессов возникают ситуации, когда исполнитель, которому предназначено задание, не имеет возможности его выполнить, - например, заболел, находится в отпуске или командировке. На эту проблему обычно можно не обращать внимания при моделировании бизнес-процессов, но она становится критической при реальном исполнении бизнес-процессов, т.к. отсутствие возможности выполнить задание приводит к остановке экземпляра бизнес-процесса, нарушению сроков, обязательств перед контрагентами и другим неприятностям.
В таких случаях используется замещение пользователей - задание перенаправляется другому пользователю. Используя замещение пользователей можно добиться того, что надежность работы СУБП будет выше надежности работы составляющих ее элементов (людей).
Часто в инструментальных решениях для управления бизнес-процессами пытаются построить систему замещения пользователей при помощи импорта организационной структуры предприятия и задания в ней функций замещения, основанных на положении сотрудников в административной системе управления предприятием. В некоторых случаях эта проблема решается при помощи вставки программного кода, реализующего перенаправление заданий, непосредственно в бизнес-процессы.
Оба этих решения неудобны: Организационная структура предприятия является отдельной сущностью и помещать ее в СУБП нежелательно, т.к. она также используется в других системах предприятия (ERP, CRM и т.п.). В случае использования программного кода бизнес-процесс становится неудобным для модификации, т.к. для изменения замещения, как правило, требуется привлекать программиста.
Но главное - такое решение неудобно управленцам, потому, что оно не соответствует их мышлению. В случае замещений исполнителей задач управленцам гораздо комфортнее думать "в терминах" людей, а не бизнес-процессов. Им удобнее не перебирать все бизнес-процессы, в которых теоретически может участвовать замещаемый пользователь и изменять в них настройки, а явно задать замещение в свойствах пользователя, может быть, указав при этом какие-то условия, при выполнении которых замещение будет выполнено.
Поэтому механизм замещения исполнителей заданий предлагается основывать на наборах правил замещения, относящихся не к бизнес-процессам, а к пользователям СУБП: Для каждого пользователя составляется упорядоченный набор правил замещения, которые последовательно просматриваются до тех пор, пока либо не будет найдено подходящее правило замещения, либо будет выяснено, что ни одного подходящего правила нет.
Описание правила назначения заместителя.
Правило содержит функцию над организационной структурой предприятия, которая возвращает заместителя.
Каждое правило имеет следующие параметры:
Пример правила назначения заместителя:
Применение правил замещения Пользователя.
У пользователя может быть одно из двух состояний:
Механизм замещения применяется только к пользователям, имеющим статус "не активен". В этом случае из списка правил будут выбраны все правила замещения, относящиеся к данному пользователю, далее из этих правил будет выбрано первое по порядку правило, которое применимо (выполняется формула в "Применимо ли правило") и заместитель в котором имеет статус "Активен". В список заданий этого пользователя (заместителя) и будет перенаправлено данное задание.
Замечание. Возможны ситуации, в которых у пользователя не будет заместителя.
Реализация механизма замещения одних исполнителей заданий другими
В системе в свойствах пользователя предлагается задать набор правил замещения. Для конкретного пользователя правило замещения будет состоять из двух частей:
При формировании списка заданий правила замещения, относящиеся к данному пользователю, просматриваются сверху вниз до тех пор, пока либо не будет найдено первое по порядку подходящее правило замещения (в котором выполняется условие в "критерии" и заместитель имеет статус "Активен"), либо будет выяснено, что ни одного подходящего правила нет.
В список заданий этого пользователя (заместителя) и будет перенаправлено данное задание.
Использование концепции бинарных отношений над множествами для упрощения процедуры инициализации ролей
Связывание узлов бизнес-процесса с исполнителями заданий производится при помощи ролей. При разработке бизнес-процесса создается роль и ставится в соответствие определенным узлам схемы. Во время выполнения экземпляра бизнес-процесса для ролей необходимо определить исполнителей.
Инициализация роли - это назначение на роль конкретного исполнителя. При переходе от моделирования бизнес-процессов на компьютере к исполнению бизнес-процессов в компьютерной среде появляется проблема выбора конкретных исполнителей, которым будет направлено задание.
Реализация компонентов-инициализаторов ролей бизнес-процессов является одной из самых неудобных и трудоемких проблем при внедрении систем управления бизнес-процессами на предприятиях.
Традиционных подходов к реализации инициализатора роли два:
Организационная структура предприятия является отдельной сущностью и помещать ее в СУБП нежелательно. Кроме того, путем задания иерархической организационной структуры можно инициализировать роли, соответствующие иерархии управления - "руководитель сотрудника", "руководитель отдела", "председатель правления". Однако, сложно инициализировать роли, не относящиеся к административному управлению, например, "секретарь, отвечающий за корреспонденцию данного сотрудника".
Вынос инициализации роли в другую систему и организация удаленного вызова процедуры из другой информационной системы приводят к техническим сложностям, а также работам по настройкам, связанным с информационной безопасностью.
Использование математического понятия "бинарное отношение" для решения проблемы
Использование понятия чистой математики - "бинарного отношения" позволяет разработать очень простое, но весьма эффективное решение задачи построения инициализатора роли.
Бинарное отношение можно рассматривать как обобщение понятия функция.
Бинарным отношением между двумя конечными множествами A и B называется набор упорядоченных пар (a,b), в которых первый элемент принадлежит к множеству A, а второй к множеству B.
Некоторые (но не все) бинарные отношения соответствуют функциям. Можно определить функцию как такое бинарное отношение R, в котором каждому значению b в парах бинарного отношения соответствует лишь одно единственное значение a (но не наоборот).
Добавим возможность инициализации ролей при помощи бинарных отношений в случае, когда по уже известному исполнителю заданий надо определить исполнителя одного из последующих заданий. Например, это может быть непосредственный руководитель сотрудника, подавшего на что-то заявку, или сотрудник отдела кадров, отвечающий за ведение личного дела конкретного работника.
При использовании бинарных отношений над множеством исполнителей задач бизнес-процесса процедура назначения возможных исполнителей задания становится очень простой и ее легко реализовать прямо в СУБП. Кроме того, это дает возможность инициализировать роль сразу множеством возможных исполнителей заданий: Часто в бизнес-процессе задание направляется не одному исполнителю, а множеству возможных исполнителей задания. Выполняет это задание тот пользователь, который первым возьмет его на исполнение.
Принцип процедуры инициализации роли следующий: Берется уже известный исполнитель заданий. Находятся все пары бинарного отношения, в которых этот исполнитель находится в правой части. Рассматривается множество, состоящее из всех левых частей отобранных пар. Этим множеством и инициализируется роль.
Простота процедуры назначения следует из того, что любое отношение над исполнителями заданий можно задать множеством пар (Исполнитель1, Исполнитель2), при этом не требуется проверять каких-либо ограничений (как, например, для функции - существование только одного значения функции для одного аргумента).
Использование групп пользователей при задании отношений
Задавать отношения перечислением всех определяющих его пар пользователей неудобно, так как таких пар может быть очень много. Для уменьшения количества вводимых данных имеет смысл воспользоваться группами пользователей.
Группы пользователей служат для объединения пользователей по какому-либо признаку. Одни группы могут содержать в себе другие группы.
Зададим отношение в СУБП как множество пар (исполнитель1, исполнитель2), в которых исполнитель является пользователем или группой пользователей.
Если пар нет, то роль не инициализируется. Если множество состоит только из одного пользователя, то роль инициализируется им. В остальных случаях роль инициализируется множеством всех пользователей, попавших в левые части пар или принадлежащих какой-либо из групп попавших в левую часть, а также любой из их подгрупп.
Пример реализация концепции бинарных отношений
В главное меню СУБП RunaWFE был добавлен пункт - Отношения (в английской локализации - Relations).
В этом пункте можно посмотреть/добавить/удалить отношение, открыть отношение и отредактировать множество составляющих его пар.
Для каждого исполнителя в его свойствах добавлены два раздела:
Каждое отношение можно открыть и отредактировать множество исполнителей в другой части отношения
Работа с отношениями в веб-редакторе (среде разработки)
В веб среде разработки при редактировании инициализатора роли можно выбрать "задать роль с помощью отношения".
Далее отношение можно поставить в соответствие роли. В форме выбирается имя отношения и переменная или константа, соответствующая правой части отношения, задающая пользователя или группу пользователей.
RunaWFE?Первые компьютерные системы, автоматизирующие управление бизнес-процессами появились давно, в начале 90-х годов прошлого века. Развитие СУБП систем за прошедший период, в частности, заимствование одними системами различных решений, примененных в других системах, привело к появлению у этого класса программного обеспечения большого количества общих черт. Например, современные СУБП поддерживают такие понятия, как определение бизнес-процесса и экземпляр бизнес-процесса, определение бизнес-процесса обязательно содержит графическую схему бизнес-процесса, состоящую из узлов и переходов между ними. Также современные СУБП используют роли бизнес-процесса и правила назначения исполнителей на роли.
Основной задачей СУБП является генерация заданий исполнителям и контроль за их выполнением. (Задание генерируется в момент прихода точки управления в узел-действие). Современные СУБП поддерживают связанный с основной задачей набор функций, который примерно одинаков во всех распространенных СУБП. Эти функции реализуются при помощи графических интерфейсов, которые тоже примерно одинаковы в различных СУБП.
В данном разделе показаны структура, основные компоненты и графические интерфейсы типичной СУБП, описано взаимодействие между ними, кратко пояснена работа пользователей с интерфейсами системы.
Для иллюстрации примеров графических интерфейсов в настоящем курсе использована система RunaWFE Professional Онлайн.
Современная СУБП должна обеспечивать разработку бизнес-процессов в графической среде, исполнение экземпляров бизнес-процессов, мониторинг состояний экземпляров, ведение истории событий экземпляров бизнес-процессов, интеграцию приложений при помощи используемых бизнес-процессами коннекторов, администрирование пользователей, а также возможность замещения исполнителей заданий.
Для выполнения этих функций в СУБП служат следующие графические интерфейсы:
Для создания и изменения бизнес-процессов обычно применяются графические дизайнеры, являющиеся частью среды разработки, которые могут быть как отдельными самостоятельными программами, так и интернет-приложениями.
Типичная СУБП состоит из следующих основных компонентов:
Среда исполнения бизнес-процессов - это основной компонент СУБП. Она реализует исполнение экземпляра бизнес-процесса в соответствии с его определением. Этот компонент содержит определения загруженных в него бизнес-процессов и выполняющиеся экземпляры бизнес-процессов. Генерирует списки заданий и визуальные формы, соответствующие заданиям. Как правило, среда исполнения бизнес-процессов позволяет создавать и изменять свойства пользователей, а также дает возможность устанавливать различные права на объекты системы.
Среда разработки бизнес-процессов служит для создания и модификации исполнимых бизнес-процессов. В этой среде определяются последовательность выполнения шагов бизнес-процесса и данные, назначаются роли участникам процесса, вводятся правила маршрутизации, определяются графические формы заданий, используемые участниками бизнес-процесса для выполнения задач. Среда разработки позволяет сконструировать графическую схему бизнес-процесса с описанием ее деталей в виде свойств отдельных элементов (действий, подпроцессов, маршрутных узлов и т.д.) или бизнес-процесса в целом. Среда разработки - инструмент разработчика бизнес-процессов (бизнес-аналитика). Он, в частности, обеспечивает внесение изменений в бизнес-процесс путем модификации графической схемы и свойств элементов.
При помощи интерфейсов для работы с заданиями исполнителей пользователь может:
При помощи интерфейсов для администрирования системы администратор может:
Используя среду разработки, бизнес-аналитик может разрабатывать бизнес-процессы, включая бизнес-правила, различные элементы коннекторов к внешним системам и другие элементы, а также загружать их в среду исполнения.
При помощи среды разработки бизнес-аналитики
Для разработки бизнес-процесса бизнес-аналитику надо:
После того, как бизнес-процесс разработан, он загружается в Среду исполнения. После этого можно запускать экземпляры данного бизнес-процесса и выполнять генерируемые ими задания.
На схеме бизнес-процесса узлы процесса можно изображать по-разному. Способ изображения узлов и переходов важен, потому что от этого зависит легкость (или сложность) понимания бизнес-процесса людьми.
Согласованные наборы графических элементов, из которых строятся схемы бизнес-процессов, называются графическими нотациями изображения бизнес-процессов. Наиболее известной графической нотацией изображения бизнес-процессов является: BPMN (подробнее о стандарте bpmn рассказывается в лекции 3.)
Базовые элементы нотации BPMN, относящиеся к перспективе потока управления:
Узел-Действие:
Шлюзы. В BPMN существует единая форма для узлов-шлюзов, представляющая собой ромбик:
Конкретные шлюзы отличаются изображенными внутри этой формы иконками.
Ветвление - Узел выбора направления дальнейшего движения точки управления:
Внутри ромбика содержится иконка - "крестик".
Разделение - Разделение точки управления на несколько точек управления:
Внутри ромбика содержится иконка - "плюсик".
Слияние - Слияние точек управления в одну точку управления:
Элемент точно такой же, как и разделение, однако у него должен быть только один исходящий переход и несколько входящих.
Во время выполнения бизнес-процессов возникают ситуации, когда исполнитель, которому предназначено задание, не имеет возможности его выполнить, - например, заболел, находится в отпуске или командировке. На эту проблему обычно можно не обращать внимания при моделировании бизнес-процессов, но она становится критической при реальном исполнении бизнес-процессов, т.к. отсутствие возможности выполнить задание приводит к остановке экземпляра бизнес-процесса, нарушению сроков, обязательств перед контрагентами и другим неприятностям.
В таких случаях используется замещение пользователей - задание перенаправляется другому пользователю. Используя замещение пользователей можно добиться того, что надежность работы СУБП будет выше надежности работы составляющих ее элементов (людей).
Часто в инструментальных решениях для управления бизнес-процессами пытаются построить систему замещения пользователей при помощи импорта организационной структуры предприятия и задания в ней функций замещения, основанных на положении сотрудников в административной системе управления предприятием. В некоторых случаях эта проблема решается при помощи вставки программного кода, реализующего перенаправление заданий, непосредственно в бизнес-процессы.
Оба этих решения неудобны: Организационная структура предприятия является отдельной сущностью и помещать ее в СУБП нежелательно, т.к. она также используется в других системах предприятия (ERP, CRM и т.п.). В случае использования программного кода бизнес-процесс становится неудобным для модификации, т.к. для изменения замещения, как правило, требуется привлекать программиста.
Но главное - такое решение неудобно управленцам, потому, что оно не соответствует их мышлению. В случае замещений исполнителей задач управленцам гораздо комфортнее думать "в терминах" людей, а не бизнес-процессов. Им удобнее не перебирать все бизнес-процессы, в которых теоретически может участвовать замещаемый пользователь и изменять в них настройки, а явно задать замещение в свойствах пользователя, может быть, указав при этом какие-то условия, при выполнении которых замещение будет выполнено.
Поэтому механизм замещения исполнителей заданий предлагается основывать на наборах правил замещения, относящихся не к бизнес-процессам, а к пользователям СУБП: Для каждого пользователя составляется упорядоченный набор правил замещения, которые последовательно просматриваются до тех пор, пока либо не будет найдено подходящее правило замещения, либо будет выяснено, что ни одного подходящего правила нет.
Описание правила назначения заместителя.
Правило содержит функцию над организационной структурой предприятия, которая возвращает заместителя.
Каждое правило имеет следующие параметры:
Пример правила назначения заместителя:
Применение правил замещения Пользователя.
У пользователя может быть одно из двух состояний:
Механизм замещения применяется только к пользователям, имеющим статус "не активен". В этом случае из списка правил будут выбраны все правила замещения, относящиеся к данному пользователю, далее из этих правил будет выбрано первое по порядку правило, которое применимо (выполняется формула в "Применимо ли правило") и заместитель в котором имеет статус "Активен". В список заданий этого пользователя (заместителя) и будет перенаправлено данное задание.
Замечание. Возможны ситуации, в которых у пользователя не будет заместителя.
Реализация механизма замещения одних исполнителей заданий другими
В системе в свойствах пользователя предлагается задать набор правил замещения. Для конкретного пользователя правило замещения будет состоять из двух частей:
При формировании списка заданий правила замещения, относящиеся к данному пользователю, просматриваются сверху вниз до тех пор, пока либо не будет найдено первое по порядку подходящее правило замещения (в котором выполняется условие в "критерии" и заместитель имеет статус "Активен"), либо будет выяснено, что ни одного подходящего правила нет.
В список заданий этого пользователя (заместителя) и будет перенаправлено данное задание.
Использование концепции бинарных отношений над множествами для упрощения процедуры инициализации ролей
Связывание узлов бизнес-процесса с исполнителями заданий производится при помощи ролей. При разработке бизнес-процесса создается роль и ставится в соответствие определенным узлам схемы. Во время выполнения экземпляра бизнес-процесса для ролей необходимо определить исполнителей.
Инициализация роли - это назначение на роль конкретного исполнителя. При переходе от моделирования бизнес-процессов на компьютере к исполнению бизнес-процессов в компьютерной среде появляется проблема выбора конкретных исполнителей, которым будет направлено задание.
Реализация компонентов-инициализаторов ролей бизнес-процессов является одной из самых неудобных и трудоемких проблем при внедрении систем управления бизнес-процессами на предприятиях.
Традиционных подходов к реализации инициализатора роли два:
Организационная структура предприятия является отдельной сущностью и помещать ее в СУБП нежелательно. Кроме того, путем задания иерархической организационной структуры можно инициализировать роли, соответствующие иерархии управления - "руководитель сотрудника", "руководитель отдела", "председатель правления". Однако, сложно инициализировать роли, не относящиеся к административному управлению, например, "секретарь, отвечающий за корреспонденцию данного сотрудника".
Вынос инициализации роли в другую систему и организация удаленного вызова процедуры из другой информационной системы приводят к техническим сложностям, а также работам по настройкам, связанным с информационной безопасностью.
Использование математического понятия "бинарное отношение" для решения проблемы
Использование понятия чистой математики - "бинарного отношения" позволяет разработать очень простое, но весьма эффективное решение задачи построения инициализатора роли.
Бинарное отношение можно рассматривать как обобщение понятия функция.
Бинарным отношением между двумя конечными множествами A и B называется набор упорядоченных пар (a,b), в которых первый элемент принадлежит к множеству A, а второй к множеству B.
Некоторые (но не все) бинарные отношения соответствуют функциям. Можно определить функцию как такое бинарное отношение R, в котором каждому значению b в парах бинарного отношения соответствует лишь одно единственное значение a (но не наоборот).
Добавим возможность инициализации ролей при помощи бинарных отношений в случае, когда по уже известному исполнителю заданий надо определить исполнителя одного из последующих заданий. Например, это может быть непосредственный руководитель сотрудника, подавшего на что-то заявку, или сотрудник отдела кадров, отвечающий за ведение личного дела конкретного работника.
При использовании бинарных отношений над множеством исполнителей задач бизнес-процесса процедура назначения возможных исполнителей задания становится очень простой и ее легко реализовать прямо в СУБП. Кроме того, это дает возможность инициализировать роль сразу множеством возможных исполнителей заданий: Часто в бизнес-процессе задание направляется не одному исполнителю, а множеству возможных исполнителей задания. Выполняет это задание тот пользователь, который первым возьмет его на исполнение.
Принцип процедуры инициализации роли следующий: Берется уже известный исполнитель заданий. Находятся все пары бинарного отношения, в которых этот исполнитель находится в правой части. Рассматривается множество, состоящее из всех левых частей отобранных пар. Этим множеством и инициализируется роль.
Простота процедуры назначения следует из того, что любое отношение над исполнителями заданий можно задать множеством пар (Исполнитель1, Исполнитель2), при этом не требуется проверять каких-либо ограничений (как, например, для функции - существование только одного значения функции для одного аргумента).
Использование групп пользователей при задании отношений
Задавать отношения перечислением всех определяющих его пар пользователей неудобно, так как таких пар может быть очень много. Для уменьшения количества вводимых данных имеет смысл воспользоваться группами пользователей.
Группы пользователей служат для объединения пользователей по какому-либо признаку. Одни группы могут содержать в себе другие группы.
Зададим отношение в СУБП как множество пар (исполнитель1, исполнитель2), в которых исполнитель является пользователем или группой пользователей.
Если пар нет, то роль не инициализируется. Если множество состоит только из одного пользователя, то роль инициализируется им. В остальных случаях роль инициализируется множеством всех пользователей, попавших в левые части пар или принадлежащих какой-либо из групп попавших в левую часть, а также любой из их подгрупп.
Пример реализация концепции бинарных отношений
В главное меню СУБП RunaWFE был добавлен пункт - Отношения (в английской локализации - Relations).
В этом пункте можно посмотреть/добавить/удалить отношение, открыть отношение и отредактировать множество составляющих его пар.
Для каждого исполнителя в его свойствах добавлены два раздела:
Каждое отношение можно открыть и отредактировать множество исполнителей в другой части отношения
Работа с отношениями в веб-редакторе (среде разработки)
В веб среде разработки при редактировании инициализатора роли можно выбрать "задать роль с помощью отношения".
Далее отношение можно поставить в соответствие роли. В форме выбирается имя отношения и переменная или константа, соответствующая правой части отношения, задающая пользователя или группу пользователей.
RunaWFE?
Для получения официальных документов о завершении программы дополнительного профессионального образования (удостоверения о повышении квалификации, дипломов о профессиональной переподготовке и MBA) необходимо предоставить:
Внимание! Вы можете не заказывать доставку бумажной версии официального документы, а скачать его в электронном виде и распечатать самостоятельно. Информация о выданном документе в течение 1 месяца загружается в Федеральную информационную систему «Федеральный реестр сведений о документах об образовании и (или) о квалификации, документах об обучении» - ФИС ФРДО.
Доступ на новый сайт осуществляется с использованием адреса электронной почты, который был указан вами при регистрации на "старом". Мы постарались перенести все ваши данные с прежнего ресурса, однако не исключена вероятность потери части информации.
При возникновении проблемы со входом, воспользуйтесь функцией сброса пароля
Если вы обнаружите несоответствия, пожалуйста, сообщите нам.