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