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

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

Нужна система, которая позволит отслеживать остатки товаров и заказывать их своевременно.

Действующие лица:

1. Товаровед, который формирует заказы для поставщиков
2. Оператор, который вводит приходные накладные.

Само приложение есть процесс синглетон. Процесс имеет два состояния 1. New 2. Registered
В состоянии New процесс имеет операцию Login (Залогиниться) и Exit (Выйти)
В состоянии Registered процесс имеет операцию Logout (Разлогиниться), Exit(Выйти), OrderWare(Сформировать заказ, собственно это уже процесс), AcceptWare(Принять товар, это тоже процесс)

Процессы и операции реализованы классами. Процесс наследуется от операции.

Приложение, абстрагированное от предметной области уже есть. И у него уже есть операции Login, Logout, Exit
Значит для реализации конкретной прикладной задачи (розничная торговля) нужно создать два процесса.

OrderWare и AcceptWare

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

1. Ордер
2. Продукт (Товар)
3. Регистр учета

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

1. Поставщик
2. Товар
3. Единица изм.
4. Количество

Получаем документ Ордер, где в шапке номер, дата и в многострочной части список товаров с количеством в разрезе поставщиков.
Этот процесс OrderWare запускает товаровед. Поскольку это новый экземпляр процесса, то у него будет состояние New, к которому привязана операция PickupWare (Подобрать товар) и она указана по дефолту для данного состояния. Соответственно при запуске процесса OrderWare выполнение сразу перейдет к операции PickupWare. Операция сформирует документ Order и выдаст окно товароведу. Товаровед может вручную подправить строки документа. Например, подправить количество или добавить новые позиции.
Тут на ум приходят следующие мысли. Обычно изменения в документе товаровед не будет делать с бухты барахты, а по какой-то внешней причине. Но это мы рассмотрим позже. И вот товаровед начинает заказывать товар. Он может сделать это либо по телефону, либо отправить Емайл поставщикам, либо через вебсервис. Рассмотрим ситуацию, когда товаровед это делает по телефону.
Если несколько разных товаров заказывается у одного и того же поставщика, то логично группировать строки в документе по поставщикам, чтобы товаровед не звонил несколько раз одному и тому же поставщику.
В таком случае товаровед начинает по списку звонить и заказывать. Если удалось дозвониться и заказать требуемое количество. то товаровед ставит галочку, если не удалось заказать требуемое количество, то правит количество. Если вообще не удалось дозвониться, то выбирает другого поставщика (если такой предусмотрен для товара) или удаляет позицию.
По окончании процедуры заказа товаровед сохраняет документ - фиксирует заказ.
В плановый регистр учета вносятся записи о предполагаемом приходе.

Теперь на сцену выходит новый актер - оператор.

Когда приходит товар, он запускает свой процесс AcceptWare, который доступен только когда был сформирован заказ. То есть основанием для запуска процесса AcceptWare является наличие процесса OrderWare в состоянии Ordered
Процесс выполняет дефолтную операцию, которая запрашивает у оператора ввести поставщика, который привез товар. Так как поставщиков у нас может быть несколько, то привозить товар они будут не одновременно, и одному процессу OrderWare будет соответствовать несколько процессов AcceptWare. которые будут создаваться по мере поступления товара.
Указав поставщика оператор получает на экран форму с сформированным документом M-15 приходный ордер, в котором указан номер, дата и поставщик. А в многострочной части указана номенклатура из заказа для данного поставщика и с количествами из заказа. Оператор должен проверить соответствие состава и количества и подтвердить документ.
После этого в регистр учета факта попадают строки товара с количеством.

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

У меня есть две платформы. Одна Delphi/MSSQL, вторая WinForms/WebMethod/MSSQL.
Эти платформы позволяют создавать объекты процессов и операций один в один в соответствии с проектом.

Жду откликов. Спасибо за внимание.

ДжекНепотрошитель,

Да, я не стал описывать это. Но это описывается и реализуется теми же процессами и операциями. Точно так же стандартно.
Мне интересно, кто еще так делает и какие при этом используются системы. Есть ли системы позволяющие описанные процессы реализовывать без преобразования?

ViPRos,

Да, верно, WorkFlow.

Ищу применение для своих систем.

Лагман,

Вот тут я попытался описать концепцию математической модели на примере реализации в PHP