Высокоуровневый шаблон для динамического прогрессирования состояния?

Question

Вы когда-нибудь сталкивались с ситуацией, подобной этому, и если да, то как вы ее разрешили?

У нас есть запись, которая проходит через несколько стадий прогрессии, таких как: представление

- > предварительная оценка - > окончательный обзор - > активного

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

• Некоторые из этих состояний могут потребовать ряд дополнительных условий, которые будут выполнены до звукозаписывающих переходит к следующему состоянию . Некоторые из этих условий или «под-состояния» могут быть необязательными, и могут потребоваться , или это может быть , необходимое для соответствия критериям «Любой 2 из 3 возможных условий». Эти подкатегории могут быть встречены в любом порядке.

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

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

Не стесняйтесь добавлять комментарии, если вы хотите получить более подробное пояснение - это довольно сложная проблема для описания, поэтому меня это не удивит, если я не буду достаточно ясным. Благодаря!

Answer 1

Вы могли бы рассмотреть

Modelling Office Processes with Functional Parsers 
Technical report UU-CS-1994-50 
Gert Florijn 
Utrecht University 
[http://www.serc.nl/people/florijn/papers/UU-CS-1994-50.html][1] 

Вот отрывок:

3,2. Первый пример: возмещение расходов

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

expenseclaim = arec "expenseclaim" 
      (serie [expenseform, inspect, oneof [reimbursed, refused]]) 
reimbursed = arec "reimbursed" (serie [approved, reimbursement]) 

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

expenseform = arec "expenseform" (serie [personal, claim]) 
personal = arec "personal" (serie [requester,department,bankaccount]) 
claim  = arec "claim" (serie [project,travel,conference,other]) 

другие парсеры в моделируются как элементарные парсеры действия, т.е.

inspect  = actl "inspect"  approved = actl "approved" 
refused  = actl "refused"  requester = actl "requester" 
department = actl "department"  bankaccount = actl "bankaccount" 
project  = actl "project"  travel  = actl "travel" 
conference = actl "conference"  other  = actl "other" 
reimbursement = actl "reimbursement"