Ну что ж... можно взять и какое-нибудь НТ-произведение, где была бы по возможности целостная картина конкретной предметки, из которой знай себе извлекай постановки задач и определения решений... кое-что на примете есть...
Но тут встаёт всё та же проблема - как представлять-то бизнес-процесс? И взаимосвязанная - как получать сведения для представления?..
А решение естественным образом получается, если признать-таки тот факт, что БП есть "проекция слона", под которым понимается системная модель, её "вариант использования" для конкретных условий.
Тогда очевидно уже сказанное - что БП прежде всего возможен только для конкретной цели из множества возможных в системе деятельности (недаром сказанное и Остерлохом, и Горбуновым на этот счёт). И получается (текстом ли, в другой форме записи) как вьюшка от тех ТП, композиция которых ведёт к этой рассматриваемой цели. Со включением артефактов координации техопераций на каждом РМ, включённом в исполнение этой композиции как небходимый (по определению ТП) элемент ПМ оргсистемы.
Что определяет необходимость, кроме цели и целевых ТП, задать для получения БП также структуру ПМ, определения субъектов деятельности, коорд-техпроцессы как зависимые от профилей квалификации субъектов и назначения субъектов (а значит, и их коорд-ТП) и целевых ТО (а значит, и частных опер-ТП) на перерабатывающие и транспортные РМ. Всё это делается в рамках системной модели. Как - примерно показано в демороликах КУБа.
Как конкретно получается? Тоже уже говорил - для начала проходом по структуре ПМ в поорядке, определяемом композицией ТП, с составлением композиции уже из частных ТП. Которые есть алгоритмические процессы - и стало быть, в граф-записи требуют только техноязыка или аналогичной нотации - Р-алгосхем, например. При этом на место каждой вершины и связи сеть-графика ТП подставляется определение соответствующего опер-ТП - перерабатывающего и транспортного.
Здесь важно, что алгопроцессы взаимодействуют по передаче предметов труда. Что представимо операторами обмена сообщениями - только к исходно данному создателем техноязыка оператору передачи нужен парный оператор приёма. Как они употребляются - увидим дальше.
Следующий шаг - учёт координации. Как - тоже было сказано в принципе. Конкретно - в описание каждого опер-ТП сразу после заголовка вставляется описание реализации координирующих функций. Если принять, что отслеживание движения предметов труда есть часть коорд-функций (что мне представляется более естественным) - то описание начинается с субалгопроцесса этого отслеживания. Здесь можно применить типичный кернел-алгоритм "ожидание реакции оператора" (реакцией будет положительный результат исполнения оператора приёма соообщений от каждого предыдущего опер-ТП - типа ввода пользователя
). Далее следует выбор (запуск) целевой операции. Условие выбора - доступность субъекта и нужных средств труда данного РМ. Случаи недоступности - занятость в неделимой и неотменяемой (с учётом приоритетов) работе по другому ТП (по сути, элементарной транзакции) либо неготовность субъекта/средств - отражаются обычным условным выбором "другой работы" либо восстановительного ТП (определяемого отдельно). Выбор также по-кернеловски зациклен так, что выйти можно только по доступности.
Это, конечно, алгоритмические приближения того, что реально делает субъект (человек/коллектив) РМ как интеллектуальная система - но отвечающие здравому смыслу и ограничениям алгоритмизации.
Возможен и другой подход - объединение отслеживания и запуска в единый алгоритм ожидания по совокупным условиям.
В любом случае важно помнить, что процесс-отправитель сообщения также ждёт завершения передачи. Что понятно из смысла операторов обмена сообщениями. Который раскрывается в алгоритмах реализации этих операторов. Как - обсуждается далее.
На этом учёт координации заканчивается - так что дальше пойдёт собственно целевой опер-ТП. Заканчивается он... правильно - оператором передачи результата труда на следующее РМ (определяемое следующей ТО). В описании ТП указывается тип РМ, соответствующего ТО - а в БП как описании реализации это будет уже конкретное РМ согласно назначению на работы. Важно, что в зависимости от результатов послеоперационного контроля (если такой предусмотрен по целевой технологии) предмет м.б. полностью или частично признан бракованным и тогда передан на взаимосвязанный ТП (один из техпроцессов) обработки брака (также определяются отдельно).
Теперь об отражении связности. При указанных выразительных средствах можно считать, что канал передачи сообщений (предметов труда) - это и есть транспортное РМ. А сеть каналов образует транспортную подсистему оргсистемы. Так что мы можем задать для каждого выделенного типа каналов протокол передачи. Его реализация и будет "бизнес-субпроцессом" для каждого ТРМ, где канал отвечает этому типу. Но можно и явно определить транспортные ТО - тогда они будут также принимать и отдавать предметы труда, как описано выше - только суть операций сводится к перемещению/хранению предметов.
В обоих случаях для БП-описания в определение также включаются артефакты координации - алгопроцессы отслеживания и выбора.
По сути, явное определение передач - это "алгорасшифровка" операторов обмена.
Ну и как можно организовать БП-описание как алгомодель? В недавних дискуссиях здесь и в других темах это обсуждалось - но пока видны только подступы к решению. Удивительно, как никто не сформулировал очевидной идеи в рамках исходного техноязыка - хотя нужные слова прозвучали...
Конкретно - в силуэте можно выделять ветки по опер-ТП (включая коорд-артефакты). Тогда очевидно, что можно ввести соединение веток по передачам сообщений. Синтаксически - просто заменить "глифы" безусловно-веточных переходов - Адрес на передачу (И20 "Параллельный процесс" в исходном алфавите), Имя на приём (парный к И20).
Возможно, читатели уже сообразили, что под "нужными словами" имелось в виду сказанное Эдуардом о "петле силуэта как шине сообщений"
здесь. А также почему идея не прозвучала - для этого нужно было отождествить переходы с передачами. А тут первое препятствие - в исходном-то алфавите пары к И20 нет... так что пока не выйдешь за его рамки - будешь ограничен в выразительных средствах...
Другой возможный ограничитель мышления - переход по передаче предмета не то же самое, что безусловный по веточным соединителям. Как-никак, даже при неявной передаче с предметом может что-то случиться (или он "морально устареет" при чересчур долгой передаче) - и тогда может стать браком. Так что возможных выходов здесь, в отличие от безусловного перехода, как минимум два... Только это Эдуардом там же рассматривалось, как можно видеть, исключительно для неявного представления передач ("в еЕРС принято считать событием некий свершившийся факт", но "вижу, что... происходит передача... от одного исполнителя к другому").
Отсюда и попытка вроде как воспроизвести (в виде "границ процесса") структуру каналов передачи (т.е. графа ПМ как актив-схемы) в рамках структуры алгопроцессов (т.е. графа БП как импер-схемы).
Конечно же, из сказанного выше понятно, что схема БП - это такой же алгопроцесс, как и составляющие её схемы перерабатывающих/транспортных техопераций и координационных действий. И получается, в сущности, в процессе, подобном "сборке" в среде Тышова... с поправкой на то, что шампур-блоки артефактов, прежде чем включать в БП-композицию, надо построить из алгоритмического (программного) определения коорд-ТП по определённым правилам.
В общем-то эти правила и будут оригинальной составляющей метода для "бизнес-описательства"... а также наличие у каждой ветки отдельного исполнителя (тип РМ+экземпляр субъекта).
Далее, для явного представления передач нужно отвести им отдельные ветки "бизнес-силуэта". Которые формируются как описано выше.
Что ещё важно - в силу небезусловности переходов естественно будет перейти от "бизнес-силуэта" к "бизнес-дейкстралу". Тогда дейкстрал-ветви точно так же будут "алгорасшифровками" работ и артефактов, а их выбор м.б. организован различно. Либо завершение текущей ветви вызывает такое изменение вектора состояния, проверяемого в охранах дейкстрал-"шапки", что истинна охрана нужной ветви - тогда удобно менять внутри ветви транспорта, а связь со следующей перерабатывающей ветвью сделать как бы безусловной (что имеет ограничения). Либо состояние определяется исключительно завершением передачи всех нужных сообщений - тогда оператор их приёма включается в "шапку" перед выбором, условием которого служит получение всех сообщений, требующих приёма. Собственно, легко видеть, что тогда отдельный оператор выбора и не нужен
- ибо очередная ветвь как раз охраняется вектором сообщений и каналов для приёма - т.е. возможна такая же замена, как для "бизнес-силуэта". Однако в этом случае целесообразно обособить процессы транспорта по каждой дуге в свою ветвь - связав операторами передачи с ветвями процессов предыдущей и следующей переработок. Далее можно выделить типы ТО транспорта и параметризовать их повторное использование. И аналогично поступить с ТО переработки.
И вот тут мы должны вспомнить о "разрыве" при укладке графа. Он проявляется в том, что надо следовать по петле от конца одной дейкстрал-ветви (ветки силуэта) к началу другой. Очевидно, разрыв можно преодолеть "примитивизацией" схемы. А тут уже проявляется то, что в случае повторного использования примитив д.б. со многими входами - для каждой ветви-типа. Это исключаем "дублированием кода" для каждогоо экземпляра типа в нужном месте. Так получится полная "развёртка кода".
Можно, однако, и иначе - не "примитивизировать", а выделить каждую ветку в свою схему (визуал). И тут становится очевидно ещё вот что - кроме передач сообщений, нужны активации частных техпроцессов (порождения экземпляров типа). Операторы порождения естественно включить в состав артефактов выбора - снятие же можно не определять явно, считая его результатом достижения конца процесса.
Однако надо понимать, что снятие освобождает ресурсы. Т.е. влияет на работу коорд-процесса.
Такая модель уже является хорошим приближением как к реальности - так и к системной модели. Основное отличие от второй в том, что там коорд-процессы будут целостными - а не в виде набора артефактных "кирпичиков".
Также можно ввести системные элементы и в единую, уложенную схему.
Ну и наконец заметим, что всё сказанное снова от фрмы записи не зависит. Обсуждавшиеся алгоструктуры можно представить как графово, так и текстово - или со структурными скобками (в ряде случаев двумерными)...
Вход
FAQ
Поиск
