Способ обработки процессов машиной состояний

Способ обработки процессов машиной состояний

Иллюстрации

Показать все

Реферат

Настоящее изобретение относится к технологии машины состояний и, в частности, к автоматической генерации задач машиной состояний.

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

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

Как правило, задачи назначаются в порядке очередности и выполняются последовательно в этом порядке. Машина состояний обеспечивает выполнение задач не по порядку, когда это необходимо. Иными словами, задачи 1, 3 и затем 7 могут быть выполнены в данном порядке. Часто требуется выполнение задач вне последовательности, когда задачи относятся к другому проекту. Выполнение задач не по порядку обеспечивается машиной состояний, которая позволяет выполнение задач в любой предварительно заданной последовательности.

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

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

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

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

На чертежах:

ФИГ. 1 иллюстрирует пример общепринятой диаграммы перехода состояний;

ФИГ. 2 иллюстрирует показательный пример рабочего процесса с использованием задач машины состояний;

ФИГ. 3 иллюстрирует блок-схему способа для автоматической генерации задач машиной состояний согласно примерному варианту;

ФИГ. 4 иллюстрирует показательный пример параметров состояний;

ФИГ. 5 иллюстрирует показательную машину состояний, использующую автоматическую генерацию задач согласно примерному варианту;

ФИГ. 6 иллюстрирует еще один пример рабочего процесса, который использует машину состояний и автоматически сгенерированные задачи;

ФИГ. 7 показывает алгоритм, иллюстрирующий переход из одного состояния в другое состояние;

ФИГ. 8 иллюстрирует схему примерной компьютерной системы, которая может быть использована для реализации изобретения.

Простым примером машины состояний являются вращающиеся ворота, которые открываются при чтении пропуска пользователя (то есть магнитной карты). Переход по состояниям данной машины состояний показан на ФИГ. 1. Диаграмма перехода состояний гласит:

если вращающиеся ворота находятся в состоянии "закрыто" и возникает событие "магнитная карта", вращающиеся ворота переходят в состояние "открыто" и вызывают действие открытия;

если вращающиеся ворота находятся в состоянии "закрыто" и имеет место событие "Проход", вращающиеся ворота переходят в состояние "закрыто" и вызывают действие закрытия;

если вращающиеся ворота находятся в состоянии "закрыто" и имеет место событие "Проход", вращающиеся ворота не изменяют своего состояния "закрыто", но вызывают действие сигнализации;

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

Однако действия (или задачи) данной машины состояния предопределены. Большой объект может иметь сотни и тысячи состояний и связанных задач в пределах своих комплексных рабочих процессов. Требуется машина состояний и автоматическая генерация задач.

В управлении проектами задача - это активность, которая должна быть достигнута (или выполнена) за определенный период времени. Задача может быть назначена ответственному лицу. Задача имеет дату начала и дату конца (время).

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

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

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

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

После того как исправитель ошибок (разработчик программного обеспечения) исправит ошибку, исправитель ошибки закрывает свою задачу, и состояние объекта "ошибка" переходит в состояние "ошибка исправлена". Согласно примерному варианту машина состояний используется для обработки рабочего процесса и управления состояниями объектов. Задачи генерируются автоматически и используются в машине состояний. Специалист примет во внимание то, что использование машины состояний с автоматическим генерированием задач является новаторским и обеспечивает более эффективную автоматизированную обработку процесса состояний.

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

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

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

В некоторых представлениях КА также возможно ассоциировать действия с состоянием:

входное действие выполняется при входе в состояние;

выходное действие выполняется при выходе из состояний.

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

Диаграммы состояний используются для того, чтобы дать абстрактное описание поведения системы. Это поведение анализируется и представляется в серии событий, которые могут произойти в одном или нескольких возможных состояниях. Согласно примерному варианту каждая диаграмма представляет объекты одного класса и отслеживает различные состояния объекта посредством системы. Диаграммы состояний могут быть использованы для графического представления конечных автоматов.

Другим возможным представлением КА является таблица переходов. Классическая форма диаграммы состояний для КА или конечного автомата (КА) является направленный граф. Для детерминистического конечного автомата (ДКА), недетерминистического конечного автомата (НКА), обобщенного недетерминистического конечного автомата (ОНКА) или автомата Мура вход обозначается на каждом ребре.

Для автомата Мили вход и выход указываются на каждом ребре, разделенные косой чертой "/": "1/0" обозначает изменение состояния, при котором встреча символа "1" приводит к символу "0" на выходе. Для автомата Мура выход состояния обычно пишется внутри круга состояния, отделенным от обозначения состояния косой чертой "/". Существуют также варианты, объединяющие эти два обозначения.

Например, если состояние имеет количество выходов (например, "а = двигатель против часовой стрелки = 1, б = сигнальная лампа неактивна = 0"), то диаграмма должна отразить это: например, "q5/l,0" обозначает состояние q5 с выходами а=1, б=0. Обозначение записывается внутри круга состояния.

ФИГ. 2 иллюстрирует пример рабочего процесса, обрабатываемого машиной состояний с автоматическим генерированием задач. ФИГ. 2 описывает пример генерирования задач машиной состояний для рабочего процесса найма компанией нового сотрудника. Стоит отметить, что рабочий процесс представляет собой процесс, описываемый различными состояниями. Любое состояние может быть присоединено к существующим состояниям рабочего процесса и может быть добавлено к рабочему процессу.

На ФИГ. 2 предмет (объект) 200 - это наем нового сотрудника. Рабочий процесс для найма сотрудника 202 компанией применяется к объекту 200. Стоит отметить, что предмет 200 может иметь различные параметры (то есть, например, имя, возраст, пол, образование, опыт, семейное положение и т.д.). Параметры предмета могут быть включены в состояния рабочего процесса, как описано ниже.

Рабочий процесс 202 начинается в шаге 205, где генерируется запрос на наем нового сотрудника. Параметры предмета 200 устанавливаются в состоянии 205. Далее процесс переходит в состояние 210, где процесс ожидает одобрения (например, от менеджера по человеческим ресурсам или директора). Задача 215 генерируется в состоянии 210 для одобрения нового найма. Эта задача может быть назначена одному или нескольким служащим в зависимости от рабочего процесса 202. Например, если только директор может одобрить данный наем, то задача назначается директору. Если одобрить наем могут директор и менеджер по человеческим ресурсам, то они оба назначаются задаче 215. Также стоит отметить, что задача может иметь одну или несколько подзадач. Например, задача 215 может иметь две подзадачи. Подзадача 1 может быть назначена бухгалтеру, и бухгалтер должен проверить наличие необходимых для найма сотрудника средств. Подзадача 2 может быть назначена менеджеру, и менеджер должен оценить продуктивность текущего сотрудника. Так что задача 215 может быть закрыта после того, как будут закрыты Подзадача 1 и Подзадача 2. Если Подзадача 1 или Подзадача 2 не закрыты, то задача 215 не может быть закрыта. Поэтому Подзадача 1 и Подзадача 2 являются параллельными подзадачами. Рабочий процесс 202 остается в том же состоянии до тех пор, пока не будет завершена задача 215.

Стоит отметить, что состояние 205 может быть исключено, и процесс найма может начаться в состоянии 210, у которого уже есть сгенерированная задача 215. Состояние 205 может быть реализовано, например, в виде меню или кнопки интерфейса найма. Меню или кнопка открывает окно для ввода параметров объекта. Данная задача может включать открытие меню или окна, описанного выше, и после ввода параметров для нового найма (таких как Отдел, Установленный срок, Тип работы, Название объекта, Дополнительная информация), задача может быть закрыта. Если директор решает, что в настоящий момент в найме нет необходимости, директор может закрыть задачу 215, и рабочий процесс переходит в состояние 220 "Отменено". Кроме того, директор может выбрать переход на состояние 220, и задача 215 закрывается автоматически. Так рабочий процесс 220 останавливается.

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

Стоит отметить, что если в состоянии 220 наем не одобрен, рабочий процесс также может вернуться в состояние 210 (не показано на ФИГ. 2), где процесс остается в подвешенном состоянии, пока директор не одобрит наем нового сотрудника. Если директор одобряет наем, закрывая задачу 215, рабочий процесс переходит в состояние "одобрено" 225. Директор может закрыть задачу, чтобы перейти в состояние 225.

Стоит отметить, что задачи могут не генерироваться во время перехода в следующее состояние (т.е. для следующего состояния). Например, переход из состояния 210 в состояние 220 или в состояние 225 не требует генерирования задачи. Однако переход в состояние 230 генерирует задачу 235, требующую одобрения потенциальных кандидатов. Например, эта задача может быть назначена менеджеру проекта.

Если менеджеру проекта не нравится кандидат, менеджер проекта может закрыть задачу 235 и выбрать переход в состояние 255 "отклонен". На данном этапе рабочий процесс по найму останавливается. Если рабочий процесс находится в состоянии 230 и менеджеру проекта нравится кандидат, менеджер может закрыть задачу 235 и перевести рабочий процесс в состояние 232, где с кандидатом проводится собеседование. Переход в состояние 232 автоматически генерирует задачу 240 для собеседования кандидата. Задача 240 может быть назначена менеджеру проекта или его помощнику.

Если менеджер не удовлетворен собеседованием, он может закрыть задачу 240 и перевести рабочий процесс в состояние 255 "отклонено". Затем рабочий процесс 220 останавливается. Если менеджер удовлетворен собеседованием, он может закрыть задачу 240 и перевести рабочий процесс в следующее состояние 245 (т.е. переговоры по найму).

Переход в состояние 245 автоматически генерирует задачу 250 для переговоров с кандидатами. Эта задача может быть назначена, например, менеджеру по человеческим ресурсам или финансовому директору. Если переговоры были безрезультатными, менеджер закрывает задачу 250 и выбирает переход в состояние 255. Однако если было достигнуто соглашение, менеджер закрывает задачу 250 и выбирает переход в состояние 260 "позиция заполнена". Затем рабочий процесс 202 прерывается.

ФИГ. 3 иллюстрирует блок-схему способа автоматического генерирования задач машиной состояний согласно примерному варианту. Рабочий процесс начинается в шаге 310. Рабочий процесс начинается с начального состояния, определяющего объект. Далее рабочий процесс переходит в следующее состояние в шаге 330. Затем процесс проверяет, достиг ли рабочий процесс конечного состояния в шаге 340. Если состояние является конечным, рабочий процесс останавливается в шаге 350. Начальное и конечное состояния явно задаются согласно конфигурации рабочего процесса.

Если в шаге 340 состояние не является конечным, процесс переходит к шагу 360, где он проверяет, требуется ли генерирование задачи. Если требуется генерирование задачи, задача автоматически генерируется в шаге 370. После того как в шаге 370 задача будет сгенерирована, процесс переходит к шагу 375. Если генерирования задачи не требуется в шаге 360, процесс переходит к шагу 380.

Если в шаге 380 выбран переход в следующее состояние, процесс переходит в необязательный шаг 320. Если задача закрывается своим исполнителем в шаге 375 и выбран переход в следующее состояние, процесс переходит к необязательному шагу 320, где процесс проверяет условия закрытия задачи или перехода состояния. Требования для генерирования задач включены в рабочий процесс для каждого состояния, для которого необходимо сгенерировать задачу.

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

ФИГ. 4 иллюстрирует примерные параметры состояния. Когда рабочий процесс создан, устанавливаются параметры состояния. Параметрами состояния могут быть название состояния 405, тип состояния 410 и задача 420 (если в генерировании задачи есть необходимость для перехода в другое состояние). Параметры могут включать дополнительные поля задачи и объекта.

Название состояния 405 определяет состояние. Тип состояния определяет иерархию состояния в рабочем процессе. Тип состояния может быть начальным 430, промежуточным 435 и конечным 440. Промежуточное состояние имеет переходы из предыдущего состояния и в следующее состояние (например, состояние 210 на ФИГ. 2). Параметр состояния задачи обеспечивает автоматическое генерирование задач во время переходов из одного состояния в другое. Полями задачи могут быть "Не назначать" 450 (т.е. задача не генерируется при переходе из одного состояния в другое); "Исполнитель" задачи 460 и "Правило назначения" задачи 465. Стоит отметить, что правило назначения может быть реализовано на любом языке программирования.

Согласно примерному варианту для правил переходов для бизнес-процесса могут быть использованы специальные имена. Имя может быть:

свойство, идентифицирующее объект;

сейчас, указывающее текущую дату и время;

текущий Пользователь, указывающее текущего пользователя.

Например, для состояния 205 (см. ФИГ. 2) название состояния - это "новый наем"; тип состояния -"Начальное состояние"; "исполнитель" задачи - директор, задача "Нужно одобрение нового найма".

Также правило назначения может быть реализовано как правила логического вывода (правила вывода, правила преобразований). Правила логического вывода - это акт вывода заключения, основанный на форме положений, интерпретированных как функция, которая принимает положения, анализирует их синтаксис и возвращает заключение (или заключения). Например, правило вывода модус поненс принимает два положения, одно в форме "если p, то q" и другое в форме "р", и возвращает заключение "q". Правило верно в отношении семантики классической логики (а также семантике многих других неклассических логик), в том смысле, что если положение верно (при интерпретации), что верен и вывод.

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

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

ФИГ. 5 иллюстрирует примерную машину состояний, использующую автоматическое генерирование задач в согласно примерному варианту. Объект 200 имеет свой шаблон 710. Шаблон 710 может содержать название шаблона и другие показанные поля. Например, процесс исправления ошибки, ошибки имеют свойства, содержащиеся в шаблоне. Состояние может быть одним из полей шаблона.

Согласно примерному варианту шаблон 710 имеет рабочий процесс 202, форму 730 и поля 740. Форма 730 используется для отображения (внутри ГУИ) данных, собранных из полей 740, объекта 200 и из шаблона задачи. Поля 740 отображаются по порядку. Объекты 200 и задачи могут быть сохранены в группах объектов. Каждая группа объектов может иметь свой собственный шаблон со специальными свойствами.

Каждая автоматически сгенерированная задача имеет заголовок, который происходит из названия объекта и названия состояния. Состояние содержит дату назначения задачи, определенную рабочим процессом. Кроме того, задача может содержать описание объекта и комментарии. Стоит отметить, что некоторые поля задачи генерируются автоматически и некоторые могут быть изменены исполнителем задачи. Согласно примерному варианту задача может иметь родительское свойство, содержащее ссылку на родительский объект (т.е. предмет), которому принадлежит задача. Таким образом, задачи с одинаковыми ссылками на родительский объект принадлежат одному объекту. Пользователь может посмотреть все задачи для родительского объекта, используя ссылку.

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

Согласно примерному варианту связанные с рабочим процессом данные, данные шаблона, поля объекта, задачи и другие служебные данные могут храниться в базе данных в форме троек (или в другом формате). Тройки могут быть сохранены в хранилище троек. Хранилище троек является специальной базой данных для хранения и извлечения троек. Тройка является сущностью данных, состоящей из подлежащего-сказуемого-дополнения, таких как, например, "Джону - 35 лет" или "Джон знает Хелен".

Так же, как и в реляционной базе данных, информация хранится в хранилище данных и может быть получена с использованием языка запросов. Однако в отличие от реляционной базы данных хранилище данных оптимизировано для хранения и извлечения троек. В дополнение к запросам тройки могут быть импортированы/экспортированы с использованием Среды Описания Ресурса (RDF) и других форматов.

В хранилищах троек могут храниться миллиарды троек. Хранилища троек могут быть построены как собственные СУБД или они могут быть построены поверх существующих коммерческих реляционных СУБД. RDF-модель данных основана на классических концептуальных подходах к моделированию, таких как сущность-связь, или классических диаграммах. RDF основана на принятии утверждений о ресурсах (в частности, веб-ресурсов) в форме выражений подлежащее-сказуемое-дополнение.

Эти выражения известны как тройки в терминологии RDF. Подлежащее обозначает ресурс, а сказуемое определяет признаки или аспекты ресурса и выражает отношение между подлежащим и дополнением. Например, одним из способов представить понятие небо "У неба цвет - синий" в RDF является тройкой: подлежащее обозначает "небо", сказуемое обозначает "цвет" и дополнение обозначает " синий".

Вследствие этого RDF заменяет объект для подлежащего, который использовался бы в классической нотации модели сущность-атрибут-значение в объектно-ориентированной конструкции. В данном примере объектом является "небо", атрибутом - "цвет" и значением - "синий". RDF - это абстрактная модель с несколькими форматами сериализации (т.е. форматами файлов), и таким определенным образом, в котором закодированный ресурс или тройка варьируется от формата к формату.

ФИГ. 6 иллюстрирует другой пример рабочего процесса, который использует машину состояний и автоматически сгенерированные задачи. В данном примере описывается рабочий процесс, отражающий покупку стула для офиса компании. Первое состояние 810 - создание запроса на покупку. Далее процесс переходит в состояние 820, и задача автоматически генерируется менеджеру, которому необходимо проверить заказ. Если менеджер решает, что стул нужен, и подтверждает заказ, менеджер может закрыть задачу и выбрать состояние 830, и автоматически сгенерируется задача бухгалтеру.

Если в состоянии 820 менеджер решает, что в покупке стула нет необходимости, он может выбрать следующее состояние 840, и процесс переходит в состояние 840, где рабочий процесс заканчивается. Если бухгалтер в состоянии 830 решает, что покупка не укладывается в бюджет, он может выбрать состояние 840, и процесс перейдет в состояние 840, в котором рабочий процесс заканчивается. Если бухгалтер утверждает приобретение кресла, бухгалтер закрывает задачу и выбирает состояние 850, и процесс переходит в состояние 850. На этом этапе генерируется еще одна задача для сотрудника отдела закупок. После того как стул оплачен, сотрудник отдела закупок закрывает свою задачу и выбирает состояние 860, так что процесс переходит в состояние 860, где рабочий процесс заканчивается.

ФИГ. 7 иллюстрирует переход из одного состояния в другое состояние, используя пример на ФИГ. 6. Здесь Объектом является покупка стула. Рассмотрим переход из состояния 820 (Состояние 1) в состояние 830 (Состояние 2). Состояние 1 является текущим состоянием Объекта (и Рабочего процесса). Состояние 2 является будущим состоянием Объекта, на которое должен перейти Объект. Как было отмечено выше, пользователь, который отвечает за конкретное состояние, может выбрать это состояние (например, если задача должна быть закрыта с целью перехода, то пользователь, которому назначена задача, может закрыть задачу и выбрать следующее состояние).

На Объект накладываются дополнительные ограничения при переходе в следующее состояние (состояние 2) ("состояние 2 ограничения"), и Объект должен удовлетворять этим ограничениям. "Состояние 2 триггеры" являются изменениями в полях, которые должны произойти при переходе к состоянию 2. "Состояние 2 задач триггеры" являются изменениями в подзадаче, сформированные при переходе в состояние 2. "Состояние 2 необходимо создать задачу" определяет, должна ли быть сгенерирована задача в текущем состоянии. "Состояние 2 задачи исполнитель" является пользовательским выражением для вычисления исполнителя сгенерированной задачи, "переход 1" является переходом из состояния 1 в состояние 2. "Переход 1 ограничения" являются ограничениями, которым должен удовлетворять Объект при переходе согласно "переходу 1'. "Переход 1 триггеры" являются изменениями в полях, которые возникают во время перехода на основании "перехода 1".

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

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

Триггеры также являются пользовательскими выражениями, написанными на языке выражений, которые обрабатываются и принимают в качестве входа ИД Объекта и предоставляют в качестве выхода некоторые поля Объекта или задачи, значение которой должно быть вписано в это поле.

Пользовательское выражение может использовать свойства Объекта или задачи (и Объектов, связанных с этим Объектом или задачей, как описано выше) и специальные переменные, также описанные выше.

Как отмечалось выше, пользователь может выбрать переход из одного состояния в следующее (например, из "состояния 1" (820 на ФИГ. 6) в "состояние 2" (830 на ФИГ. 6). Сам процесс перехода начинается в шаге 902, где состояние Объекта меняется на "Состояние 2". Затем, в шаге 904, ограничения "перехода 1" проверяются, т.е. проверяются поля Объекта. Например, может существовать требование заполнить "тип автомобиля", когда Объект "покупка автомобиля", и состояние переходит из "выбора автомобиля" в "перейти к автодилеру". Если ограничения не удовлетворены в шаге 904, далее в шаге 906 пользователя информируют об ошибке, и переход на следующее состояние ("Состояние 2") не происходит (Объект остается в предыдущем состоянии, "Состояние 1"). Если в шаге условия "перехода 1 ограничения" удовлетворены, то процесс в шаге 908 запускает "переход 1 триггеры", т.е. обновляет поля Объекта информацией, прочитанной из хранилища данных.

В шаге 910 проверяются "состояния 2 ограничения", т.е. проверяются поля Объекта. Если в шаге 910 "состояния 2 ограничения" не удовлетворяются, процесс переходит в шаг 906. В противном случае, если в шаге 910 "переход 2 условия" удовлетворены, то в шаге 912 запускаются "состояния 2 триггеры" для обновления полей Объекта.

В шаге 914 процесс проверяет, существует ли необходимость создавать задачу для следующего состояния (событие "состояние 2 требует создать задачу"). Если в шаге 914 нет необходимости создавать задачу, то процесс переходит в шаг 922.

Если в шаге 914 необходимо создать задачу, то процесс переходит к шагу 916, где выбирается исполнитель для новой задачи. Пользователь может указать исполнителя явно (например, нажатием кнопки для перехода к следующему состоянию (переход 1), в этом случае процесс переходит к шагу 924, где назначенный - тот, кто был указан пользователем, которого он выбрал при переходе в следующее состояние. Далее процесс переходит в шаг 930.

Если пользователь не указывает явно исполнителя, то в шаге 918 процесс проверяет, был ли исполнитель указан для перехода к следующей задаче, когда был создан рабочий процесс (т.е. исполнитель может быть вычислен на основании правил для состояния 2 задачи исполнитель, содержащихся в рабочем процессе). Если в шаге 918 исполнитель был указан при создании рабочего процесса, то в шаге 926 исполнителем будет тот, кто был выбран во время создания рабочего процесса, т.е. используя предопределенное правило, которое определяет того, кому принадлежит задача, при переходе из Состояния 1 в Состояние 2. Далее процесс переходит в шаг 930.

Если в шаге 918 в рабочем процессе нет правила для исполнителя, то исполнителем задачи является создатель Объекта, смотри 920, процесс переходит в шаг 930.

Далее определяется заголовок для новой задачи. Если в шаге 930 пользователь явно указывает заголовок, то, аналогично ситуации с исполнителем, когда нажата кнопка "переход 1", то процесс - в шаге 934, заголовок задачи становится таким, какой указал пользователь, и процесс переходит к шагу 936.

Если в шаге 930 пользователь не указал явно заголовок, то заголовок задачи может быть создан на основе шаблона, например, Заголовок Объекта + Состояние в шаге 932, после чего в шаге 936 создается задача с параметрами: {группа = Объект.группа, родитель = Объект, создатель = системный пользователь/нет, статус = не начата, исполнитель, заголовок}, где группа - это группа, которой принадлежит Объект.

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

Далее в шаге 922 задача из предыдущего состояния закрывается (если она есть), и затем - в шаге 928, что означает, что Объект теперь находится в следующем состоянии, т.е. "Состоянии 2", и процесс заканчивается.

Со ссылкой на ФИГ. 8, типичная система для реализации изобретения включает в себя многоцелевое вычислительное устройство в виде компьютера 20 или сервера, включающего в себя процессор 21, системную память 22 и системную шину 23, которая связывает различные системные компоненты, включая системную память с процессором 21.

Системная шина 23 может быть любого из различных типов структур шин, включающих шину памяти или контроллер памяти, периферийную шину и локальную шину, использующую любую из множества архитектур шин. Системная память включает постоянное запоминающее устройство (ПЗУ) 24 и оперативное запоминающее устройство (ОЗУ) 25. В ПЗУ 24 хранится базовая система ввода/вывода 26 (БИОС), состоящая из основных подпрограмм, которые помогают обмениваться информацией между элементами внутри компьютера 20, например, в момент запуска.

Компьютер 20 также может включать в себя накопитель 27 на жестком диске для чтения с и записи на жесткий диск, не показан, накопитель 28 на магнитных дисках для чтения с или записи на съемный магнитный диск 29 и накопитель 30 на оптическом диске для чтения с или записи на съемный оптический диск 31, такой как компакт-диск, цифровой видеодиск и другие оптические средства. Накопитель 27 на жестком диске, накопитель 28 на магнитных дисках и накопитель 30 на оптических дисках соединены с системной шиной 23 посредством соответственно интерфейса 32 накопителя на жестком диске, интерфейса 33 накопителя на магнитных дисках и интерфейса 34 оптического накопителя. Накопители и их соотве