OberonCore https://forum.oberoncore.ru/ |
|
Задача на перспективу https://forum.oberoncore.ru/viewtopic.php?f=86&t=3633 |
Страница 5 из 7 |
Автор: | Рэйлвэй Каген [ Пятница, 14 Сентябрь, 2012 22:24 ] |
Заголовок сообщения: | Re: Задача на перспективу |
Владислав Жаринов писал(а): зачем тогда упоминать исполнителей и специально определять узлы? А если просто сетевой график с нагрузкой "вершина-работа"?.. Видимо, имея сеть работ, можно определить сетевой график для любой пары узлов и по ней же сгенерить идефы.
|
Автор: | Ильченко Эдуард [ Суббота, 15 Сентябрь, 2012 11:02 ] |
Заголовок сообщения: | Re: Задача на перспективу |
Владислав Жаринов писал(а): А если просто сетевой график с нагрузкой "вершина-работа"?.. В сетевых графиках, вроде бы, запрещены циклы? |
Автор: | Ильченко Эдуард [ Суббота, 15 Сентябрь, 2012 11:14 ] |
Заголовок сообщения: | Re: Задача на перспективу |
Вложение: Т.е. допускаем множественность выходов из одного процесса? |
Автор: | Рэйлвэй Каген [ Суббота, 15 Сентябрь, 2012 11:46 ] |
Заголовок сообщения: | Re: Задача на перспективу |
Пока ещё не знаю. Придётся оценить, что ещё сломалось от таких вольностей. Нужно время. |
Автор: | PSV100 [ Суббота, 15 Сентябрь, 2012 17:23 ] |
Заголовок сообщения: | Re: Задача на перспективу |
Господа, посмотрите на Amber, ещё одна нотация для БП: -- здесь гл. 8, для меня это первичный источник; — здесь материалы от авторов языка; — здесь небольшой учебник; — здесь кроме Amber есть пару слов и о NEML — близкий к нему язык (также в документе встречаются и др. технологии); — здесь ещё один пример интеграции Amber c Promela для верификации моделей и пр. А здесь можно ещё посмотреть на всякое, в дополнение к типовым UML, BPMN, IDEF, YAWL и пр. Ключевой момент в Amber - это использование перекрёстков слияния/выбора/разделения всего двух типов: и/или, вместо типовых трёх (and/or/xor), а то и более, нет спецсимволов как в YAWL, сущность которых забывается через две минуты после просмотра условных обозначений для схемы, нет и надписей вида "выбрать все", "только один" и т.д. В общем, м.б. каких-то мыслишек добавится. По опыту скажу. Если схемы демонстрировать ни в чём неповинным "бизнес-исполнителям", то с людьми нужно как-то помягче, полегче. У них всё-равно будут вопросы вида "а почему здесь закрашено, а тут нет" (как в Amber), если вдруг они решат ещё что-то понять в схеме кроме содержательного текста. Так что, нужно решение, простое как пробка. |
Автор: | Ильченко Эдуард [ Суббота, 15 Сентябрь, 2012 17:53 ] |
Заголовок сообщения: | Re: Задача на перспективу |
PSV100 писал(а): Так что, нужно решение, простое как пробка. Полностью согласен. |
Автор: | Владислав Жаринов [ Воскресенье, 16 Сентябрь, 2012 12:16 ] |
Заголовок сообщения: | Re: Задача на перспективу |
Ильченко Эдуард писал(а): Владислав Жаринов писал(а): А если просто сетевой график с нагрузкой "вершина-работа"?.. В сетевых графиках, вроде бы, запрещены циклы?Рэйлвэй Каген писал(а): ... - таковых много, имеются в виду "информационные модели" или "трёшки"?..Видимо, имея сеть работ, можно определить сетевой график для любой пары узлов и по ней же сгенерить идефы. А узлы (видимо, перекрёстки) - это к чему в реальной системе будет относиться?.. И зачем реальным предметнику, аналитику и программисту именно так поступать?.. И вот тут главное - чем дальше, тем меньше я вижу, как бы это относилось к сути оргдеятельности... хотя бы на примере предложенной задачи... Возможно, это промежуточные результаты ломания... и когда-то что-то соберётся. Для чего обращу внимание на отдельные свойства практически полезного результата. 1. Сетевые графики для достижения любого рода цели задаются заранее - это и есть техпроцессы. Состоящие из техопераций (ТО, представлены вершинами) и межоперационных передач (МП, дугами) с предметами труда. И доводятся до будущих исполнителей - субъектов производственных мощностей для ТО и МП (рабочих и транспортных мест). Тогда исполнитель, получив некий род предметов труда, знает, что с ним делать... и никакие "перекрёстки" ему для этого не нужны...
Возможен вопрос - а как быть с разными повторными рассмотрениями документов? А так и быть - либо считать не прошедшее рассмотрение браком и передавать на свой ТП... либо считать выпуском новой/усовершенствованной продукции и включать в основной ТП соответствующий техмаршрут (альтернативный). Если же логика техпроцесса такова, что удобнее зациклить - то зацикливаем, что ж делать... но в разработку ТП включаем операцию размыкания контуров через фиктивные работы (обсуждалось уже по Романовскому). 2. Сам процесс достижения цели данного рода в конкретном объёме и условиях - это реализация ведущих к этой цели ТП на назначенных РМ вместе с их связями в структуре ПМ. Как экземпляра ТП соответствующего рода. И модель этого в простейшем случае будет прямо следовать из сетевого графа ТП - т.е. иметь вид чередования алгоритмических процессов ТО и МП. Что имеет место или когда оргсистема (или её рассматриваемая часть) всегда занята единственным экземпляром ТП, или для цели наивысшего приоритета (на любом РМ/ТМ "всё бросаем и занимаемся только этим"). Тут важно понимать - что "перекрёстки" у нас были заложены в сетевых графах ТП. А для представления содержания ТП их уже надо "алгорасшифровать". Что корректно делать для общего случая - о котором далее. 3. В общем случае каждый исполнитель м.б. занят более, чем одним экземпляром ТП. Посему нужна координация на каждом РМ и в каждой МП (кстати, даже и для того, чтобы "всё бросить"). Её мы представляем как коорд-процесс - головной по отношению к ТО-процессам. Т.е. взаимодействующий с ними.
Главное - что в общем случае в модели реализации ("бизнес-процессе") между соседними целевыми процессами экземпляра (ТО и МП) будут вклиниваться артефакты координации - другая работа на данном РМ и ТМ и решение о переходе на работу по данному экземпляру (и последующем возврате к другой работе). Только с точностью до этого мы можем абстрактно, "до опыта", описать "бизнес-процессно". Другое ограничение - модель бизнес-процесса всегда возможна лишь относительно конкретной цели (рода техпроцесса).
И теперь понятно также, что всё это уже алгопроцессы. На каком-то языке параллельного программирования. Например, на той же Промеле - только надо соотносить протоколы рандеву-каналов с логикой реальных связей производственных мощностей... Вот так и м.б. получена нотация, "простая, как пробка" - ибо сетевые графы известны (изучавшим ОПУП в вузе получше, менее образованным - в объёме первоначального профобучения). Ну а алгоритмы в школе проходят... Не, я конечно понимаю, что не попавшие в ХШП или Байтики именно "проходят"...
Понятно, что "цеховых" - это условно, в нереальном секторе это обычно управления/департаменты разные... Но. Вот спектр ролей не условен - потому что системный подход подразумевает и в "идеалистическом производстве" систематические техподготовку и планирование... а не только "учёт и контроль"... Считайте, что это как бы "реинжиниринг оргструктуры"... когда "менеджмент качества" просто-напросто замыкает рабочие и транспортные места в киберсистему с государством, рынком и собственниками... И вот хотелось бы, чтобы участники продумали, где и для чего им нужны доалгоритмические модели. И обосновали бы. Исходя из приведённого выше обзора реального смысла деятельности... |
Автор: | Владислав Жаринов [ Воскресенье, 16 Сентябрь, 2012 13:39 ] |
Заголовок сообщения: | Re: Задача на перспективу |
Можно, конечно, предложить и конкретный способ двигаться к вышеописанному. Для начала хорошо бы расписать общий вид процессов каждого из трёх родов: техоперационного, транспортного, координационного. Как "алгорасшифрованных" - т.е. без всяких "перекрёстков" (напомню, они в вершинах сетевых графов ТП остались ). Включая механизмы взаимодействия между ними (заметим, в рамках одного рабочего/транспортного места - все взаимодействия между разными местами представлены транспортными процессами, а условия связности - в координационном). У кого получится?.. |
Автор: | Рэйлвэй Каген [ Воскресенье, 16 Сентябрь, 2012 22:25 ] |
Заголовок сообщения: | Re: Задача на перспективу |
PSV100 писал(а): ..ещё одна нотация для БП:.. Было такое, отсмотрел года 3-4 назад. Сами вороги честно в п.3.5. писал(а): "the relations between domains (views) is poorly defined, and the models created in different views are not further integrated" PSV100 писал(а): ..решение, простое как пробка. Будет, но оно совсем не на поверхности
|
Автор: | Рэйлвэй Каген [ Воскресенье, 16 Сентябрь, 2012 22:27 ] |
Заголовок сообщения: | Re: Задача на перспективу |
Владислав Жаринов писал(а): Рэйлвэй Каген писал(а): ...Видимо, имея сеть работ, можно определить сетевой график для любой пары узлов и по ней же сгенерить идефы. - таковых много, имеются в виду "информационные модели" или "трёшки"?..... |
Автор: | Владислав Жаринов [ Понедельник, 17 Сентябрь, 2012 07:20 ] |
Заголовок сообщения: | Re: Задача на перспективу |
А, я так и подумал. Чтобы, очевидно, задать БД описания типа техпроцесса? Тут штука именно в том, что Вы и говорите - решение не лежит на поверхности (например, в фиксации рассказов исполнителей, как они делали эту конкретную работу ). А именно в представлении деятельности как заранее проектируемой (и тут опять же Ваш давний совет "не впадать в программизм при построении нотаций" не зря - только его надо распространить и на использование опыта не только НИОКР, но и ТПП - и не только средств представления, но и подходов к делу "разработки И документирования процессов/программ/предметок"). Возможный подход я описал. И, сопоставляя описание с обзором реальной системной среды типа КУБа, можно сделать вывод - в среде заложены некие реализации коорд-процессов (м.б. одна реализация), экземпляры котор<ых|ой> порождаются на каждую единицу производственных мощностей, заданную в среде сочинителем. Так можно моделировать деятельность - на основании описанных сочинителем же процессов ТО и МП (практически, как можно видеть, параметризуются типы процессов через экранные формы на основании справочников) - и заданных им же назначений на работы (условных при проектировании/анализе и реальных при управлении). И получать показанные в роликах данные хода исполнения внутри среды - безо всякой Промелы и Спина. Эти данные опять же можно считать характеристиками "бизнес-процесса" как реализации реалистичной модели деятельности. В данном случае характеристики числовые (в цифровых полях и прогресс-индикаторах) - но Усов вроде говорил, что можно выдавать и в форме диаграмм Гантта и/или отрезковых (форма, привычная в советской практике). Ну а планировать - на основании обычной математики того же, без моделирования - как в ОПУП и принято было (см. сжатое изложение в выдержке здесь - там же можно и отрезковые диаграммы видеть). В соседних постах той ветки, кстати, о разных подходах к тому же самому...
Так ли я понял и как на самом деле решено у Усова - это у него и надо спрашивать... А главное - решение не на поверхности прежде всего в том смысле, что аналитику как участнику триады надо вникать в суть оргдеятельности вообще (что по своему сделал Усов) и конкретного дела в частности - которое знают технологи этого дела. А не исключительно в изообретении очередной "грамматики бизнес-процессов" - Калянова тут не переплюнуть в математическом смысле... - ибо она всё равно будет о реализации (конкретном "опыте", говоря словами тервера). Т.е. представлять результаты "бросания кубиков" - а не те формулы, по которым мы можем получить эти результаты... Ну и если технологов для данной предметки в явном виде нет (что частое явление пока в "идеальном производстве" - софтовом в частности) - то аналитику и придётся им стать. |
Автор: | Ильченко Эдуард [ Понедельник, 17 Сентябрь, 2012 11:56 ] |
Заголовок сообщения: | Re: Задача на перспективу |
Владислав Жаринов писал(а): аналитику как участнику триады надо вникать в суть оргдеятельности вообще (что по своему сделал Усов) и конкретного дела в частности - которое знают технологи этого дела. А не исключительно в изообретении очередной "грамматики бизнес-процессов" В любом случае, аналитику придётся как-то записать свою «алхимию», тут и пригодится «простой как пробка» инструмент (язык, метод и т. п.). В целях разработки инструмента, имхо, думать удобнее о существующих процессах (сущностях, алгоритмах и т. п.), уже кем-то как-то описанных, чем пытаться оттехпроцессить построение «воздушного замка» : ) |
Автор: | PSV100 [ Вторник, 18 Сентябрь, 2012 18:24 ] |
Заголовок сообщения: | Re: Задача на перспективу |
Владислав Жаринов писал(а): ... потому что системный подход подразумевает и в "идеалистическом производстве" систематические техподготовку и планирование... а не только "учёт и контроль"... Считайте, что это как бы "реинжиниринг оргструктуры"... когда "менеджмент качества" просто-напросто замыкает рабочие и транспортные места в киберсистему с государством, рынком и собственниками... Вы уже в шаге от разоблачения "матрицы" Владислав Жаринов писал(а): Можно, конечно, предложить и конкретный способ двигаться к вышеописанному. Для начала хорошо бы расписать общий вид процессов каждого из трёх родов: техоперационного, транспортного, координационного. Как "алгорасшифрованных" - т.е. без всяких "перекрёстков" (напомню, они в вершинах сетевых графов ТП остались ). Включая механизмы взаимодействия между ними (заметим, в рамках одного рабочего/транспортного места - все взаимодействия между разными местами представлены транспортными процессами, а условия связности - в координационном). У кого получится?.. У меня точно не получится. Лучшие решения на ДРАКОНе (по разным причинам) были в таком стиле: Или "был кайф" от UML с "мульти-шампурами": А придумать грамотную альтернативу этому ужасу пока не могу - нет редактора для Р-схем . Кстати, имхо, комплексы РТК подтверждают Ваши взгляды на "[ре]инжиниринг оргструктуры". Исходя из скромных публикаций да показаний свидетелей получается, что там и были только сетевые графики плюс алгоритмика, и вспомогательные схемы (структуры, отношения и пр.). Лично я, собственно, только вот сейчас, здесь на форуме, "глобально, с высоты..." задумался над зарисовкой оргдеятельности. Рисовать "процессы" приходится редко, в основном, программные алгоритмы требуют больше "внимания". А "писать картины маслом" не научился, к примеру, часто смешиваются "кони и люди" - реальные исполнители и "компьютеры": здесь в квадратике что-то человек делает, затем расчёты на "компьютере", в след. квадратиках исполнители разгребают результаты и т.п. А на верхнем уровне даже сетевого графика работ нет в явном графическом виде, как-то банального списка "бизнес-работ" хватает... В общем, полная "алхимия"... А сказать я хочу то, что "самое простое как пробка" - м.б. и самым эффективным... Короче говоря, учиться культуре производства никогда не поздно, и важно не стыдиться признаваться в "недоученности" |
Автор: | Ильченко Эдуард [ Вторник, 18 Сентябрь, 2012 23:56 ] |
Заголовок сообщения: | Re: Задача на перспективу |
Нотация eEPC подкупает своей простотой. Вложение: NB01.png [ 22.06 КБ | Просмотров: 14885 ] Пока в неё не добавляют всяких разных других картинок. Вложение: На мой взгляд, большинство значков не несут в себе какой-то особый смысл. В основном этот смысл определяется из текста. Попробую «помять в руках» : ) минимальный набор элементов этой нотации в купе с правилами ДРАКОНа на расположение маршрутов. Начертание значка событие (оно похоже на начертание иконы Вопрос) заменено на вот такое: Вложение: NB02.png [ 993 байт | Просмотров: 14885 ] а значка функция на такое (тройная полка): Вложение: NB03.png [ 1.65 КБ | Просмотров: 14885 ] ну и точки расщепления слияния: Вложение: NB04.png [ 1.86 КБ | Просмотров: 14885 ] Ниже Структурная Схема Бизнес-Процесса «Поставка чего-нибудь. Первый этап.». В качестве события используется готовность какого-либо документа, существующего в рамках БП. Вложение: В eEPC, вроде бы, принято считать событием некоторый свершившийся факт, не имеющий продолжительности по времени. Смотрю на схему и вижу : ), что событие состоит как минимум из двух таких фактов, отстоящих друг от друга на некотором временнОм интервале. В этом временнОм интервале происходит передача информации (а может и материи : ) от одного исполнителя к другому. Соответственно, событие имеет начало и конец. Начало события это выход из предыдущего процесса, а конец события это вход в следующий процесс. При этом вход процесса может активироваться разными событиями. Следовательно, процесс должен иметь или один вход с параметрами или несколько отдельных входов. Для целей визуального отображения мне представляется удобным иметь несколько входов для внешних границ БП и один вход (через точки слияния) для процессов внутри БП. Те же соображения о входах применимы и к выходам. Для ясности буду называть всю схему Бизнес-Процессом (БП), а процессы внутри неё — просто процессами. Если внутренний процесс разворачивается в схему, то он становится БП. Попробую определить границы процессов в БП. Вложение: Раз имеем события с началом и концом, то можем представить события в таком виде (где-то на форуме я такие картинки уже видел : ). Вложение: Схема прекрасно масштабируется. Вложение: Собственно, теперь понятно, что должна представлять собой петля силуэта в схемах БП с подобной нотацией: шину событий (транспортную магистраль по доставке событий). |
Автор: | Владислав Жаринов [ Среда, 19 Сентябрь, 2012 10:59 ] |
Заголовок сообщения: | Re: Задача на перспективу |
Это интересно. Теперь уже Эдуард близок к "разоблачению". В том смысле, что остаётся немного, чтобы посмотреть, как мы выбираем "один из нескольких". Тут не зря опять же Рэйлвей Каген говорил о различных исчислениях пространства. В данном случае это проще может рассматриваться. Обычно все процессы упорядчиваются по одной координате. Горизонтально, скажем. И вот при описании бизнес-процессов предлагается управление работами как-то включить в тот же порядок. Но. Можно взглянуть и иначе. Когда процессы координации действуют на целевые процессы сообразно текущему назначению на работы как бы в ортогональном направлении - охватывая целевые операции разных процессов на своём рабочем/транспортном месте. И "добавляя своего" в каждый целевой процесс по ходу исполнения. Это и будут решения по координации. Тут и никакой событийной шины не нужно - событие состоит в приходе предмета труда на операцию не в установленных временных/качественных рамках. Может, кто-то помнит анекдот про сына лорда... ну тот, который заканчивается фразой "Да как-то до сих пор всё было в порядке."?.. Передаются предметы - и, как частный случай, новые правила координации в координационные процессы от управляющих. Но. Обновление определения коорд-процесса - это часть не эксплуатации оргсистемы, а её построения. При эксплуатации меняются только некие заложенные по определению уставки - ну и перечни назнченных работ, конечно. Т.о. задача проектировщика деятельности в отношении коорд-процессов - максимально учесть условия выполнения работ и заложить нужные настройки координации. Отсюда и сказанное об РТК-Микро, что там состав модели в принципе такоой же, как Усовым принят... И для начала можно, разумеется, собирать минимальный состав данных о проектируемых техпроцессах... Плановикам и не надо обычно ничего кроме того, что указывается при традиционнной нотации сетевых графиков - т.е. характеристик работ во времени... Но вот когда мы должны определять, как выбрать из назначенных работ очередную к исполнению на данном месте - тут уже структуру и свойства работ знать надо... Что и к определению коорд-процессов относится... |
Автор: | PSV100 [ Среда, 19 Сентябрь, 2012 15:15 ] |
Заголовок сообщения: | Re: Задача на перспективу |
Владислав Жаринов писал(а): ... Обычно все процессы упорядчиваются по одной координате. Горизонтально, скажем. И вот при описании бизнес-процессов предлагается управление работами как-то включить в тот же порядок. Но. Можно взглянуть и иначе. Когда процессы координации действуют на целевые процессы сообразно текущему назначению на работы как бы в ортогональном направлении - охватывая целевые операции разных процессов на своём рабочем/транспортном месте. И "добавляя своего" в каждый целевой процесс по ходу исполнения. Это и будут решения по координации. Тут и никакой событийной шины не нужно - событие состоит в приходе предмета труда на операцию не в установленных временных/качественных рамках.... Такие мысли подталкивают развитие ДРАКОНа к такому направлению зарисовки управления работами : Вложение: Loop_Counter.gif [ 82.34 КБ | Просмотров: 14852 ] Картинка выдрана отсюда: Kontinuum, там можно скачать презентацию "workflow software" от этой конторы. Подкину дровишек насчёт eEPC-нотации, всё-таки, там есть положительные зачатки. Я уже приводил ссылки в теме про Р-схемы, но повторю их здесь: - здесь очень кратко основная суть; - здесь коротко в целом о методологии и какие имеются типы диаграмм; - здесь краткое сравнение с IDEF; - здесь есть пару слов, но самое ценное там в комментариях, где некий товарищ starodubcev "уже всё изобрёл до нас", выложил свой труд Соглашение по моделированию, фактически, как я понимаю, описал рисовалки процессов в SAP R3. В принципе, в eEPC логика та же: на верхнем уровне - цепочки процессов а-ля сетевые графики, которые могут "расшифровываться" более детальными цепочками с алгоуказаниями, плюс всякие структурные диаграммы. Есть и некие "расширенные цепочки", как на верхнем уровне: Вложение: 01_29.gif [ 7.18 КБ | Просмотров: 14852 ] так и пониже: Вложение: Что-то полезное в этих "прикрученных" иконах есть, тот же "документопоток". М.б. и какие-то "координации" прикручивать ? Кстати, есть и какая-то "фича": модель вариантов бизнес-процесса, можно глянуть в файлике про "Соглашение по моделированию", с. 98, вот картинка оттуда: Вложение: Я особо не разбирался, но как я могу понять, каждый квадратик там м.б. раскрыт соответствующей схемой, и фактически, это некая сводная таблица вариантов функций в зависимости от сценариев процесса. В любом случае, имхо, всё-равно нужно отталкиваться от событий, или результатов функций (или предикатов в Р-схемах), в т.ч. и коорд-процессы тоже зависят от сложившейся ситуации... |
Автор: | Ильченко Эдуард [ Среда, 19 Сентябрь, 2012 20:04 ] |
Заголовок сообщения: | Re: Задача на перспективу |
Та же схема, но в силуэте. СФУНКЦ : ) Событийно-ФУНКЦиональная нотация. Вложение:
|
Автор: | Рэйлвэй Каген [ Среда, 19 Сентябрь, 2012 21:24 ] |
Заголовок сообщения: | Re: Задача на перспективу |
По-моему, дублирование не особо оправданно: Вложение:
|
Автор: | Рэйлвэй Каген [ Среда, 19 Сентябрь, 2012 21:41 ] |
Заголовок сообщения: | Re: Задача на перспективу |
Ильченко Эдуард писал(а): Смотрю на схему и вижу : ), что событие состоит как минимум из двух таких фактов, отстоящих друг от друга на некотором временнОм интервале.. Да, они такие Потому, что реакция на событие может быть
|
Автор: | Ильченко Эдуард [ Среда, 19 Сентябрь, 2012 22:04 ] |
Заголовок сообщения: | Re: Задача на перспективу |
Рэйлвэй Каген писал(а): По-моему, дублирование не особо оправданно: Как я понял ТЗ (при всём том, что не сильно его придерживаюсь : ) это разные документы, порождающие разные процедуры, что видно на рисунке выше. |
Страница 5 из 7 | Часовой пояс: UTC + 3 часа |
Powered by phpBB® Forum Software © phpBB Group https://www.phpbb.com/ |