Тема создана для обсуждения вопросов, озвученных здесь. 19091036

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

Я тут тебе описал два метода как можно задать граф процессов

1. Статический - типа рисуешь процессы вручную
2. Динамический - типа процессыный граф формируется на основе какого то алгоритма

Вопрос 1

Как вообще задавать это ограничение -
т.е. длительность какого то подграфа в процессном графе (а этих подграфов там может несметное количество разных и клонов) не должно превыщать определеннное число единиц чего то

Вопрос 2 -

как определить, что в заданном графе вообще есть такие подграфы

....

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

BPMN ориентирован работает на статических графах.

Существует прием, который позволяет превратить динамический граф в статический. Это граф "всех возможных вариантов" - он ведь статический, не так ли? Конечно же, он может быть весьма масштабным. Такой прием нам подходит?

ViPRosGarya,
таких задач в производстве тьма

ни один БПМН это не опишетВерно, BPMN не для описания динамических графов. :)
Однако, с его помощью можно описать алгоритм, который работает с динамическим графом.
Можно создать наборы сущностей, например, "узлы графа". С помощью BPMN можно соединять узлы ребрами или, напротив, удалять ребра графа. Можно задествовать активити "для всех ребер, с которыми состыкован данный узел выполнить оценнку длительности", причем запустить такое вычисление как параллельное. Можно сделать рекуррентные вызовы подпроцессов, которые запускают оценку по смежным узлам. Таким образом, что вычисления "бешенно распараллелятся". А для того, чтобы отработала главная идея метода ветвей и границ, можно воспользоваться в какой-то структуре, к которой имеют доступ все ветки вычислений, фиксировать наиболее оптимальные текущие полученные результаты. Откатом активити и подпроцессов можно реализовать прерывание "раскрашивания графа", длина которого вышла за пределы текущего наиболее оптимального.

ViPRosViPRos,



Критический путь граф АА <= что то?
без вопроса :)"Критический путь" и "оптимальный путь" - разные вещи. Тот факт, что у тебя есть "критический" - это не просто хорошо, это суперотлично. :) Если время расчета ограничено, а граф имеет колоссальную размерность (а с граф возможных вариантов наверняка именно так и есть), можно искать не самое оптимальное решение, а близкое к оптимальному, которое укладывается в заданные ограничения.

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

ViPRosGaryaпропущено...
Верно, BPMN не для описания динамических графов. :)
Однако, с его помощью можно описать алгоритм, который работает с динамическим графом.
Можно создать наборы сущностей, например, "узлы графа". С помощью BPMN можно соединять узлы ребрами или, напротив, удалять ребра графа. Можно задествовать активити "для всех ребер, с которыми состыкован данный узел выполнить оценнку длительности", причем запустить такое вычисление как параллельное. Можно сделать рекуррентные вызовы подпроцессов, которые запускают оценку по смежным узлам. Таким образом, что вычисления "бешенно распараллелятся". А для того, чтобы отработала главная идея метода ветвей и границ, можно воспользоваться в какой-то структуре, к которой имеют доступ все ветки вычислений, фиксировать наиболее оптимальные текущие полученные результаты. Откатом активити и подпроцессов можно реализовать прерывание "раскрашивания графа", длина которого вышла за пределы текущего наиболее оптимального.
Во первых это твои мечты :)
Во вторых каждый активити - это минимум поток процессор
во третьих - это программирование :)Ты трижды прав. :)
Я говорю о том, что BPMN, в том случае, если задействуется как технология распараллеливания вычислений, может распараллелить их в груде таких задач, в которых прежде традиционно распараллеливание не использовалось (ну, например, в том же методе ветвей и границ обычно работает традиционный цикл последовательного перебора). А то, что для каждого из такого вычисления потребуется отдельный поток - это верно. Но с учетом, что компьютеры стремятся к многопроцессорной, многоядерной архитектуре, и при том каждое из ядер может отрабатывать в режиме разделяемого времени множество потоков вычислений, сама технология высокоэффективного распараллеливания вычислений может "рвануть". Компьютеры могут стать и тысяче-процсессными и миллионо-ядерными... Просекаешь, о чем я?
А если еще заложить и специальные процессные низкоуровневые инструкции для диспетчеризации потоков вычислений, да завязать их с BPMN-подобными средствами в операционных системах, которые в свою очередь транслируются на любой высокий уровень, мы получаем бесконечно-масштабируемую вычислительную архитектуру с бесконечными возможностями для распараллеливания вычислений. Да, это мечта... Но она ведь и может воплотиться, не так ли? :)

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

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

ViPRosа как задать ограничение, как нить подумайТак что тут думать? Ограничения для частично-оптимального решения: "Для участка от A до B время выполнения не более 5 часов."
Ограничение для ресурса:"Задействуется ресурс не более 1 раза на интервале в 1 минуту" и "ресурс работает с 8 утра до 20:00 только по рабочим дням".
Если нужно решить оптимизационные задачи, как распределить ресурс между множеством процессов, то можно "поженить" метод ветвей и границ с методами линейного программирования. В этой книжке есть классные примеры, как это можно сделать.

ViPRos,

Я, видимо, как-то невнятно объясняю...
Есть описания графов, а есть описания алгоритмов действий. Это немного разные вещи.

Классически в программировании алгоритм изображается блок-схемой, чем-то вроде такого:

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

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

Так вот, по сути "действие", "активити", "элементарая операция" в алгоритме - не так уж важно, что конкретно делает. Важно, что в BPMN появляется возможность:
1) Обработки ошибок
2) Настраиваемой компенсации (отката) действий (например, действие A:=A+B, которое уже выполнилось, можно компенсировать-вернуть посредством действия A:=A-B).
3) Возможность "вызова" под-алгоритмов (подпроцессов), в том числе, рекуррентного.
4) Возможность распараллеливания действий, при этом на схеме весь набор распараллеленных потоков изображается как одно действие. Далее "пучок" распараллеленных потоков, выполняющихся в схожей логике, при необходимости, можно собрать в одной точке, либо дождавшись "одного победителя" (по заданным критериям), либо всех, кто был запущен на параллельное выполнение.
5) Возможность обмена информацией относительно слабо связанных между собой алгоритмов, нацеленных на решение разных задач и работающих в разных собственных ритмах (посредством "слабых" связей и "хореографии")

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

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

Так вот я о чем! Я сравниваю с принципами традиционного описания АЛГОРИТМОВ, а не графов. А про графы - это отдельная песня. Если граф можно формализовать (а для твоих задач, я полагаю, его можно формализовать), то его описание можно сгенерить алгоритмом. А уж в какой нотации будет описан алгоритм, это дело десятое... :)

ViPRosЗадам другой вопрос

У тебя есть БД - много там отношений - табличек

в одном из них , например в Строке накладной есть два таких свойства
Материал и Единица измерения
какой(ие) алгоритм(ы) предложишь для поиска максимально подходящего значения одного в зависимости от значения другогоМаксимально подходящего по каким критериям?
Я подозреваю, о чем ты... Для дискретных производств обычно вводят "минимальный размер партии" - своеобразный квант, неделимый атом... :)
Вот до него всё и раскладывается.

Отсюда 19091055 :ViPRosа ведь это просто Пролеживаемость детали :) Срок годности :)

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

Вроде бы, пустяк, о сильно всё упрощает:
1) Размер партии = const
2) Партия атомарна, то есть, всегда обрабатывается целиком.

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

ViPRosGarya,

Размер партии - это суть оптимизации
только его и ищут - оптимального размера партии запуска, а у тебя он константа :)
эхЕсть умные книжки, в которых приведены формулы расчета размера канбан-партии и канбан-контейнера (что не всегда одно и то же).
И есть технология оптимизации JIT, которая предполагает постепенное сокращение размера партий "волевым решением" с тем, чтобы выявить проблемы и побороть их. А в остальное время да, размер партии - константа. ПМСМ, это нормально и правильно для серийного производства или для производства с повторяющимися процессами.
Для "производства под заказ", которое ближе к проектам, такой подход, возможно не самый лучший. Там, действительно, нужно оптимизировать еще до того как будет запущен в работу первый цикл.

ViPRosGaryaпропущено...
Максимально подходящего по каким критериям?
Я подозреваю, о чем ты... Для дискретных производств обычно вводят "минимальный размер партии" - своеобразный квант, неделимый атом... :)
Вот до него всё и раскладывается.
не это задача в лоб

именно если задано значение одного допустим - Бетон, надо искать допустим - Тонна

вот как узнать что Тонна подходит больше или воще только Тонна и подходитИзвини, но я не понял. Не может больше подходить что-либо "вообще". Может подходить больше ПО КАКИМ-ТО КРИТЕРИЯМ . Как только критерии сформулированы, можно попытаться решить задачу. Если критериев нет, значит проблема в недоформулировании задачи.

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

ViPRosпролежываемость детали после поклейки с одной стороны считается временем высыхания клея до того момента, после которого склеивать в эту деталь ничего невозможно
через 20 минут кофе это пойло, а пиво - говно :)
размеры партий и т.д. тут не при чемТо, о чем ты говоришь, это не "пролеживание", это длительность какой-то технологической фазы, которая может быть задана как оптимальное значение +- отклонения (в формате параметров кривой Тагути). В таком случае можно будет оценить качество каждого экземпляра фактически выполненной фазы по тому, насколько близко время выполнения к оптимальному.

andr_andreyGarya,

по всей видимости, ViPRos и предлагает искать "оптимальный" размер партии аналитически/алгоритмически исходя из критериев, которые "трудно" задать. Например, у нас есть процесс на линии, в результате смены рецептуры выпускаемого продукта происходит выпуск брака в определённом количестве (линия чистится от остатков примесей), поэтому перед технологами стоит задача формирования производственного расписания для минимизации количества разносортного брака. В то же время, технолог, как экспертная система, понимает, что сделав 50 тонн брака ради 25 тонн продукта, может быть нецелесообразно, и они удлиняют период выпуска до 100 тонн на склад, учитывая срок годности и план реализации. Интересно, как тут поможет "симулятор" вместо оптимизатора.А не лучше внести коррективы в технологию? Вычищать остатки примесей более тщательно не "боевым" запуском процесса, а "прочищающим", чем-то заведомо "ориентированным на брак"?

ViPRosGaryaпропущено...
Извини, но я не понял. Не может больше подходить что-либо "вообще". Может подходить больше ПО КАКИМ-ТО КРИТЕРИЯМ . Как только критерии сформулированы, можно попытаться решить задачу. Если критериев нет, значит проблема в недоформулировании задачи.
Я ж написал, что именно критерии и надо было найти, что бы построить алгоритмы поиска
В ВИПРОС есть понятие Информационная мощность, которое построена на понятиях "сильных" и "слабых" ассоциаций свойств и типов, а на них построены алгоритмы интеллектуальное поиска
т.е. если А где то и как то ассоциирован с Б, то из этих ассоциаций выбираются самые мощные в информационном смыслеТо, что ты озвучиваешь, насколько я понял, элементы BI.
Похожие элементы существуют в технологии "робастной оптимизации", однако, в ней задействуются не только программные алгоритмы, но и люди (на стадии "мозгового штурма").
В системе может просто не регистрироваться факты и факторы, определяющие функцию чувствительности процесса к параметрам его качества. Вот тут и нужен "мозговой штурм", чтобы выявить как то, что регистрируется, так и то, что не регистрируется. А то, что регистрируется, может быть выявлено, методами анализа накопленных статистических данных - корреляционный анализ, регрессионный анализ и т.д. и т.п.

ViPRosТы быстро отвечаешь :)Извини, но чем дальше в лес, тем толще партизаны. В том смысле, что аврал постепенно стремится к тенденции хронического. На форум могу заскакивать только урывками.

ViPRosесть срок хранения изделия после заданной операции над изделием
после этой операции изделие участвует в еще нескольких операциях (где помимо него возможны и друге изделия)
вот суммарная длина пути с учетом этих операций и межоперационных пролеживаний ограничен во времени этим изделием (возможно у других изделий собственные ограничения)
при таких ограничениях вообще очень сложно построить расписание, даже если ограничение одно
МВГ - это общее понятие, подход к построению конкретного алгоритма
Во многих случаях в таких задачах вообще нет возможности построить аналитическую функцию оценки, так как не все понятия оцифрованы в модели, а БПМН и т.д. вообще не имеют модели предметной областиЭто очень интересная комбинаторная задача. Я решал похожие, и вполне успешно. Полагаю, в данном случае можно задействовать эвристический алгоритм, подобный тому, который применяется для решения " задачи о рюкзаке ". Можно также применить генетический алгоритм, в котором модели выхода виртуально "борются за выживание". Я бы начал с генетического - они всегда меня сильно удивляли. Логика выживания оптимального заложена где-то в глубинах мироздания, нужно только ее нащупать правильными "щупами", задав правила конкуренции моделей и правила определения "победы в конкуренции"... :)

ViPRosGarya,

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