OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Четверг, 28 Март, 2024 22:02

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 135 ]  На страницу Пред.  1, 2, 3, 4, 5, 6, 7  След.
Автор Сообщение
 Заголовок сообщения: Re: Задача на перспективу
СообщениеДобавлено: Пятница, 14 Сентябрь, 2012 22:24 

Зарегистрирован: Воскресенье, 04 Ноябрь, 2007 23:01
Сообщения: 151
Владислав Жаринов писал(а):
зачем тогда упоминать исполнителей и специально определять узлы? А если просто сетевой график с нагрузкой "вершина-работа"?..
Видимо, имея сеть работ, можно определить сетевой график для любой пары узлов и по ней же сгенерить идефы.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Задача на перспективу
СообщениеДобавлено: Суббота, 15 Сентябрь, 2012 11:02 

Зарегистрирован: Понедельник, 09 Ноябрь, 2009 17:29
Сообщения: 144
Откуда: Россия, Питер
Владислав Жаринов писал(а):
А если просто сетевой график с нагрузкой "вершина-работа"?..

В сетевых графиках, вроде бы, запрещены циклы?


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Задача на перспективу
СообщениеДобавлено: Суббота, 15 Сентябрь, 2012 11:14 

Зарегистрирован: Понедельник, 09 Ноябрь, 2009 17:29
Сообщения: 144
Откуда: Россия, Питер
Вложение:
b4.png
b4.png [ 40.65 КБ | Просмотров: 14812 ]

Т.е. допускаем множественность выходов из одного процесса?


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Задача на перспективу
СообщениеДобавлено: Суббота, 15 Сентябрь, 2012 11:46 

Зарегистрирован: Воскресенье, 04 Ноябрь, 2007 23:01
Сообщения: 151
Пока ещё не знаю. Придётся оценить, что ещё сломалось от таких вольностей. Нужно время.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Задача на перспективу
СообщениеДобавлено: Суббота, 15 Сентябрь, 2012 17:23 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 473
Господа, посмотрите на Amber, ещё одна нотация для БП:
-- здесь гл. 8, для меня это первичный источник;
здесь материалы от авторов языка;
здесь небольшой учебник;
здесь кроме Amber есть пару слов и о NEML — близкий к нему язык (также в документе встречаются и др. технологии);
здесь ещё один пример интеграции Amber c Promela для верификации моделей и пр.

А здесь можно ещё посмотреть на всякое, в дополнение к типовым UML, BPMN, IDEF, YAWL и пр.

Ключевой момент в Amber - это использование перекрёстков слияния/выбора/разделения всего двух типов: и/или, вместо типовых трёх (and/or/xor), а то и более, нет спецсимволов как в YAWL, сущность которых забывается через две минуты после просмотра условных обозначений для схемы, нет и надписей вида "выбрать все", "только один" и т.д. В общем, м.б. каких-то мыслишек добавится.

По опыту скажу. Если схемы демонстрировать ни в чём неповинным "бизнес-исполнителям", то с людьми нужно как-то помягче, полегче. У них всё-равно будут вопросы вида "а почему здесь закрашено, а тут нет" (как в Amber), если вдруг они решат ещё что-то понять в схеме кроме содержательного текста. Так что, нужно решение, простое как пробка.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Задача на перспективу
СообщениеДобавлено: Суббота, 15 Сентябрь, 2012 17:53 

Зарегистрирован: Понедельник, 09 Ноябрь, 2009 17:29
Сообщения: 144
Откуда: Россия, Питер
PSV100 писал(а):
Так что, нужно решение, простое как пробка.

Полностью согласен.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Задача на перспективу
СообщениеДобавлено: Воскресенье, 16 Сентябрь, 2012 12:16 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
Ильченко Эдуард писал(а):
Владислав Жаринов писал(а):
А если просто сетевой график с нагрузкой "вершина-работа"?..
В сетевых графиках, вроде бы, запрещены циклы?
Да, потому я сразу и написал, что у Вас другой класс граф-представлений... Но главное в этом:
Рэйлвэй Каген писал(а):
...
Видимо, имея сеть работ, можно определить сетевой график для любой пары узлов и по ней же сгенерить идефы.
- таковых много, имеются в виду "информационные модели" или "трёшки"?..
А узлы (видимо, перекрёстки) - это к чему в реальной системе будет относиться?.. И зачем реальным предметнику, аналитику и программисту именно так поступать?..

И вот тут главное - чем дальше, тем меньше я вижу, как бы это относилось к сути оргдеятельности... хотя бы на примере предложенной задачи...

Возможно, это промежуточные результаты ломания... и когда-то что-то соберётся. Для чего обращу внимание на отдельные свойства практически полезного результата.

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

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

3. В общем случае каждый исполнитель м.б. занят более, чем одним экземпляром ТП. Посему нужна координация на каждом РМ и в каждой МП (кстати, даже и для того, чтобы "всё бросить"). Её мы представляем как коорд-процесс - головной по отношению к ТО-процессам. Т.е. взаимодействующий с ними.
    И тут подход к моделированию взаимодействия м.б. разным. Либо процесс каждого экземпляра ТО отслеживает приход вовремя "своего" экземпляра (партии дискретного, объёма непрерывного) предмета труда - и уведомляет коорд-процесс в рамках принятого механизма (рандеву, допустим). А коорд-процесс только решает, как распределить исполнение ТО-процессов в новой ситуации. Исходя, между прочим, не только из приоритетов - но и из делимости ТО (например, на установы штук/загрузки порций, вспомогательные действия). И, ожидая моментов делимости, порождает, активирует/откладывает, снимает ТО-процессы для экземпляров. Либо коорд-процесс также включает отслеживание - а ТО-процессы только целевые действия.
Всё сказанное равно приложимо и к МП. По сути, там тоже свои техоперации - только более единообразные обычно...

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

И теперь понятно также, что всё это уже алгопроцессы. На каком-то языке параллельного программирования. Например, на той же Промеле - только надо соотносить протоколы рандеву-каналов с логикой реальных связей производственных мощностей...
Вот так и м.б. получена нотация, "простая, как пробка" - ибо сетевые графы известны (изучавшим ОПУП в вузе получше, менее образованным - в объёме первоначального профобучения). Ну а алгоритмы в школе проходят... :wink: Не, я конечно понимаю, что не попавшие в ХШП или Байтики именно "проходят"... :)
    И вот тут главная языковая "задача на перспективу" - сформировать язык представления "алгорасшифровки" сетевых графиков через взаимодействующие алгопроцессы. Чисто текстовый или как - но чтоб был понятен аналитикам, программистам (хотя бы ведущим - т.е. "архитекторам ПО"), предметникам (опять же - если не большинству, то хотя бы закпредам-постановщикам - а это от уровня цеховых мастеров/технологов/ПЭО-шников)...
    Понятно, что "цеховых" - это условно, в нереальном секторе это обычно управления/департаменты разные... Но. Вот спектр ролей не условен - потому что системный подход подразумевает и в "идеалистическом производстве" систематические техподготовку и планирование... а не только "учёт и контроль"... :) Считайте, что это как бы "реинжиниринг оргструктуры"... когда "менеджмент качества" просто-напросто замыкает рабочие и транспортные места в киберсистему с государством, рынком и собственниками... :wink:

И вот хотелось бы, чтобы участники продумали, где и для чего им нужны доалгоритмические модели. И обосновали бы. Исходя из приведённого выше обзора реального смысла деятельности...


Последний раз редактировалось Владислав Жаринов Воскресенье, 16 Сентябрь, 2012 14:40, всего редактировалось 1 раз.

Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Задача на перспективу
СообщениеДобавлено: Воскресенье, 16 Сентябрь, 2012 13:39 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
Можно, конечно, предложить и конкретный способ двигаться к вышеописанному. Для начала хорошо бы расписать общий вид процессов каждого из трёх родов: техоперационного, транспортного, координационного. Как "алгорасшифрованных" - т.е. без всяких "перекрёстков" (напомню, они в вершинах сетевых графов ТП остались :)). Включая механизмы взаимодействия между ними (заметим, в рамках одного рабочего/транспортного места - все взаимодействия между разными местами представлены транспортными процессами, а условия связности - в координационном). У кого получится?..


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Задача на перспективу
СообщениеДобавлено: Воскресенье, 16 Сентябрь, 2012 22:25 

Зарегистрирован: Воскресенье, 04 Ноябрь, 2007 23:01
Сообщения: 151
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:31, всего редактировалось 1 раз.

Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Задача на перспективу
СообщениеДобавлено: Воскресенье, 16 Сентябрь, 2012 22:27 

Зарегистрирован: Воскресенье, 04 Ноябрь, 2007 23:01
Сообщения: 151
Владислав Жаринов писал(а):
Рэйлвэй Каген писал(а):
...Видимо, имея сеть работ, можно определить сетевой график для любой пары узлов и по ней же сгенерить идефы.
- таковых много, имеются в виду "информационные модели" или "трёшки"?.....
- информационные модели


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Задача на перспективу
СообщениеДобавлено: Понедельник, 17 Сентябрь, 2012 07:20 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
А, я так и подумал. Чтобы, очевидно, задать БД описания типа техпроцесса?

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

Возможный подход я описал. И, сопоставляя описание с обзором реальной системной среды типа КУБа, можно сделать вывод - в среде заложены некие реализации коорд-процессов (м.б. одна реализация), экземпляры котор<ых|ой> порождаются на каждую единицу производственных мощностей, заданную в среде сочинителем. Так можно моделировать деятельность - на основании описанных сочинителем же процессов ТО и МП (практически, как можно видеть, параметризуются типы процессов через экранные формы на основании справочников) - и заданных им же назначений на работы (условных при проектировании/анализе и реальных при управлении). И получать показанные в роликах данные хода исполнения внутри среды - безо всякой Промелы и Спина. Эти данные опять же можно считать характеристиками "бизнес-процесса" как реализации реалистичной модели деятельности.
В данном случае характеристики числовые (в цифровых полях и прогресс-индикаторах) - но Усов вроде говорил, что можно выдавать и в форме диаграмм Гантта и/или отрезковых (форма, привычная в советской практике). Ну а планировать - на основании обычной математики того же, без моделирования - как в ОПУП и принято было (см. сжатое изложение в выдержке здесь - там же можно и отрезковые диаграммы видеть). В соседних постах той ветки, кстати, о разных подходах к тому же самому...
    Внимание! Движок Спейса скрывает вложения для гостей - для доступа нужно логиниться.

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Задача на перспективу
СообщениеДобавлено: Понедельник, 17 Сентябрь, 2012 11:56 

Зарегистрирован: Понедельник, 09 Ноябрь, 2009 17:29
Сообщения: 144
Откуда: Россия, Питер
Владислав Жаринов писал(а):
аналитику как участнику триады надо вникать в суть оргдеятельности вообще (что по своему сделал Усов) и конкретного дела в частности - которое знают технологи этого дела. А не исключительно в изообретении очередной "грамматики бизнес-процессов"

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Задача на перспективу
СообщениеДобавлено: Вторник, 18 Сентябрь, 2012 18:24 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 473
Владислав Жаринов писал(а):
... потому что системный подход подразумевает и в "идеалистическом производстве" систематические техподготовку и планирование... а не только "учёт и контроль"... :) Считайте, что это как бы "реинжиниринг оргструктуры"... когда "менеджмент качества" просто-напросто замыкает рабочие и транспортные места в киберсистему с государством, рынком и собственниками... :wink:

Вы уже в шаге от разоблачения "матрицы" :)

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

У меня точно не получится. Лучшие решения на ДРАКОНе (по разным причинам) были в таком стиле:

Изображение

Или "был кайф" от UML с "мульти-шампурами":

Изображение

А придумать грамотную альтернативу этому ужасу пока не могу - нет редактора для Р-схем :). Кстати, имхо, комплексы РТК подтверждают Ваши взгляды на "[ре]инжиниринг оргструктуры". Исходя из скромных публикаций да показаний свидетелей получается, что там и были только сетевые графики плюс алгоритмика, и вспомогательные схемы (структуры, отношения и пр.).

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

Короче говоря, учиться культуре производства никогда не поздно, и важно не стыдиться признаваться в "недоученности" :roll:


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Задача на перспективу
СообщениеДобавлено: Вторник, 18 Сентябрь, 2012 23:56 

Зарегистрирован: Понедельник, 09 Ноябрь, 2009 17:29
Сообщения: 144
Откуда: Россия, Питер
Нотация eEPC подкупает своей простотой.
Вложение:
NB01.png
NB01.png [ 22.06 КБ | Просмотров: 14623 ]


Пока в неё не добавляют всяких разных других картинок.
Вложение:
1-9.gif
1-9.gif [ 21.46 КБ | Просмотров: 14623 ]


На мой взгляд, большинство значков не несут в себе какой-то особый смысл. В основном этот смысл определяется из текста.
Попробую «помять в руках» : ) минимальный набор элементов этой нотации в купе с правилами ДРАКОНа на расположение маршрутов.

Начертание значка событие (оно похоже на начертание иконы Вопрос) заменено на вот такое:
Вложение:
NB02.png
NB02.png [ 993 байт | Просмотров: 14623 ]


а значка функция на такое (тройная полка):
Вложение:
NB03.png
NB03.png [ 1.65 КБ | Просмотров: 14623 ]


ну и точки расщепления слияния:
Вложение:
NB04.png
NB04.png [ 1.86 КБ | Просмотров: 14623 ]


Ниже Структурная Схема Бизнес-Процесса «Поставка чего-нибудь. Первый этап.».
В качестве события используется готовность какого-либо документа, существующего в рамках БП.
Вложение:
NB05.png
NB05.png [ 62.26 КБ | Просмотров: 14623 ]


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

Для ясности буду называть всю схему Бизнес-Процессом (БП), а процессы внутри неё — просто процессами. Если внутренний процесс разворачивается в схему, то он становится БП.

Попробую определить границы процессов в БП.
Вложение:
NB06.png
NB06.png [ 92.86 КБ | Просмотров: 14623 ]


Раз имеем события с началом и концом, то можем представить события в таком виде (где-то на форуме я такие картинки уже видел : ).
Вложение:
NB07.png
NB07.png [ 12.32 КБ | Просмотров: 14623 ]


Схема прекрасно масштабируется.
Вложение:
NB08.png
NB08.png [ 32.67 КБ | Просмотров: 14623 ]


Собственно, теперь понятно, что должна представлять собой петля силуэта в схемах БП с подобной нотацией: шину событий (транспортную магистраль по доставке событий).


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Задача на перспективу
СообщениеДобавлено: Среда, 19 Сентябрь, 2012 10:59 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
Это интересно. Теперь уже Эдуард близок к "разоблачению". :) В том смысле, что остаётся немного, чтобы посмотреть, как мы выбираем "один из нескольких".

Тут не зря опять же Рэйлвей Каген говорил о различных исчислениях пространства. В данном случае это проще может рассматриваться. Обычно все процессы упорядчиваются по одной координате. Горизонтально, скажем. И вот при описании бизнес-процессов предлагается управление работами как-то включить в тот же порядок. Но. Можно взглянуть и иначе. Когда процессы координации действуют на целевые процессы сообразно текущему назначению на работы как бы в ортогональном направлении - охватывая целевые операции разных процессов на своём рабочем/транспортном месте. И "добавляя своего" в каждый целевой процесс по ходу исполнения. Это и будут решения по координации. Тут и никакой событийной шины не нужно - событие состоит в приходе предмета труда на операцию не в установленных временных/качественных рамках. Может, кто-то помнит анекдот про сына лорда... ну тот, который заканчивается фразой "Да как-то до сих пор всё было в порядке."?.. :) Передаются предметы - и, как частный случай, новые правила координации в координационные процессы от управляющих.
Но. Обновление определения коорд-процесса - это часть не эксплуатации оргсистемы, а её построения. При эксплуатации меняются только некие заложенные по определению уставки - ну и перечни назнченных работ, конечно. Т.о. задача проектировщика деятельности в отношении коорд-процессов - максимально учесть условия выполнения работ и заложить нужные настройки координации.

Отсюда и сказанное об РТК-Микро, что там состав модели в принципе такоой же, как Усовым принят... И для начала можно, разумеется, собирать минимальный состав данных о проектируемых техпроцессах... Плановикам и не надо обычно ничего кроме того, что указывается при традиционнной нотации сетевых графиков - т.е. характеристик работ во времени...
Но вот когда мы должны определять, как выбрать из назначенных работ очередную к исполнению на данном месте - тут уже структуру и свойства работ знать надо... Что и к определению коорд-процессов относится...


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Задача на перспективу
СообщениеДобавлено: Среда, 19 Сентябрь, 2012 15:15 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 473
Владислав Жаринов писал(а):
... Обычно все процессы упорядчиваются по одной координате. Горизонтально, скажем. И вот при описании бизнес-процессов предлагается управление работами как-то включить в тот же порядок. Но. Можно взглянуть и иначе. Когда процессы координации действуют на целевые процессы сообразно текущему назначению на работы как бы в ортогональном направлении - охватывая целевые операции разных процессов на своём рабочем/транспортном месте. И "добавляя своего" в каждый целевой процесс по ходу исполнения. Это и будут решения по координации. Тут и никакой событийной шины не нужно - событие состоит в приходе предмета труда на операцию не в установленных временных/качественных рамках....

Такие мысли подталкивают развитие ДРАКОНа к такому направлению зарисовки управления работами :) :

Вложение:
Loop_Counter.gif
Loop_Counter.gif [ 82.34 КБ | Просмотров: 14590 ]


Картинка выдрана отсюда: Kontinuum, там можно скачать презентацию "workflow software" от этой конторы.

Подкину дровишек насчёт eEPC-нотации, всё-таки, там есть положительные зачатки. Я уже приводил ссылки в теме про Р-схемы, но повторю их здесь:

- здесь очень кратко основная суть;

- здесь коротко в целом о методологии и какие имеются типы диаграмм;

- здесь краткое сравнение с IDEF;

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

В принципе, в eEPC логика та же: на верхнем уровне - цепочки процессов а-ля сетевые графики, которые могут "расшифровываться" более детальными цепочками с алгоуказаниями, плюс всякие структурные диаграммы. Есть и некие "расширенные цепочки", как на верхнем уровне:

Вложение:
01_29.gif
01_29.gif [ 7.18 КБ | Просмотров: 14590 ]


так и пониже:

Вложение:
01_31.gif
01_31.gif [ 14.75 КБ | Просмотров: 14590 ]


Что-то полезное в этих "прикрученных" иконах есть, тот же "документопоток". М.б. и какие-то "координации" прикручивать ?
Кстати, есть и какая-то "фича": модель вариантов бизнес-процесса, можно глянуть в файлике про "Соглашение по моделированию", с. 98, вот картинка оттуда:

Вложение:
eEPC_PSD.PNG
eEPC_PSD.PNG [ 32.58 КБ | Просмотров: 14590 ]


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

В любом случае, имхо, всё-равно нужно отталкиваться от событий, или результатов функций (или предикатов в Р-схемах), в т.ч. и коорд-процессы тоже зависят от сложившейся ситуации...


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Задача на перспективу
СообщениеДобавлено: Среда, 19 Сентябрь, 2012 20:04 

Зарегистрирован: Понедельник, 09 Ноябрь, 2009 17:29
Сообщения: 144
Откуда: Россия, Питер
Та же схема, но в силуэте.
СФУНКЦ : ) Событийно-ФУНКЦиональная нотация.
Вложение:
NB09.png
NB09.png [ 57.4 КБ | Просмотров: 14572 ]


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Задача на перспективу
СообщениеДобавлено: Среда, 19 Сентябрь, 2012 21:24 

Зарегистрирован: Воскресенье, 04 Ноябрь, 2007 23:01
Сообщения: 151
По-моему, дублирование не особо оправданно:
Вложение:
untitled.png
untitled.png [ 21.11 КБ | Просмотров: 14562 ]


Последний раз редактировалось Рэйлвэй Каген Среда, 19 Сентябрь, 2012 21:46, всего редактировалось 1 раз.

Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Задача на перспективу
СообщениеДобавлено: Среда, 19 Сентябрь, 2012 21:41 

Зарегистрирован: Воскресенье, 04 Ноябрь, 2007 23:01
Сообщения: 151
Ильченко Эдуард писал(а):
Смотрю на схему и вижу : ), что событие состоит как минимум из двух таких фактов, отстоящих друг от друга на некотором временнОм интервале..
Да, они такие :)
Потому, что реакция на событие может быть
    1. немедленной
    2. отложенной
Соответственно дальнейшая судьба события:
    1. вызвать обработчик ситуации
    2. быть помещённым в кэш
Мы здесь пока рисуем всё для отложенной обработки.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Задача на перспективу
СообщениеДобавлено: Среда, 19 Сентябрь, 2012 22:04 

Зарегистрирован: Понедельник, 09 Ноябрь, 2009 17:29
Сообщения: 144
Откуда: Россия, Питер
Рэйлвэй Каген писал(а):
По-моему, дублирование не особо оправданно:

Как я понял ТЗ (при всём том, что не сильно его придерживаюсь : ) это разные документы, порождающие разные процедуры, что видно на рисунке выше.


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 135 ]  На страницу Пред.  1, 2, 3, 4, 5, 6, 7  След.

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 2


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Вся информация, размещаемая участниками на конференции (тексты сообщений, вложения и пр.) © 2005-2024, участники конференции «OberonCore», если специально не оговорено иное.
Администрация не несет ответственности за мнения, стиль и достоверность высказываний участников, равно как и за безопасность материалов, предоставляемых участниками во вложениях.
Без разрешения участников и ссылки на конференцию «OberonCore» любое воспроизведение и/или копирование высказываний полностью и/или по частям запрещено.
Powered by phpBB® Forum Software © phpBB Group
Русская поддержка phpBB