DRAKON.SU

Не получило, видимо, ещё и потому, что математика д.б. проработана... Как минимум два подхода здесь есть - GAN-алгебра (где можно циклить в схеме деятельности с расщеплением/слиянием, т.е. доалгоритмической) и алгебра сетевых графиков (где циклы запрещены и есть фиктивные работы).

Артефакты, IMHO, д.б. предопределены записью самого действия... Если нужно для наглядности - метим выход операторной вершины, как в IDEF0, наверное...

Таймер также можно понимать и как процесс... параллельно протекающий и задающий параметр условия пуска синхронизируемой вершины.

Действительно, там нет этих икон.
К сожалению, к тому моменту как я это заметил, файл с ними был уже утерян : (
А ковыряться во внутренностях ODG формата уже нет никакого желания ...
Остаётся подрисовывать треугольнички : )

P.S. Кстати, иконы веточных циклов можно полностью закрасить каким-нибудь цветом...

Пока что Дракон позиционировался как чисто алгоритмический язык. Соответственно, изображал он потоки управления.

Полезно было бы и потоки данных изображать ("артефакты в результате деятельности" - это частный случай оных).

В HiAsm было сделано такое - по одной координате - управление, по другой - данные.

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

Если мы присобачим к алгоритму только исполнителей и артефакты, то потоком данных тут и не пахнет (как минимум, он разрывен, и контролировать его целостность неудобно).

Аналогично, если строить диаграмму от потока данных, то разрывен (неочевиден, неудобен) будет алгоритм...

Попробуйте предложить принципиальное решение, исходя из требуемого качества информации на диаграмме!

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

Однозначно. И, возможно, давно пора

Собственно, и я про то же.
А то поди ж, исполнителей нарисовали, так артефактов теперь не хватает... А подумать хотя бы на уровне структуры необходимой информации - увы...

Изначально было предложено это:
viewtopic.php?f=62&t=3630#p66753
Здесь выходы - результат каждого из этапов.
Хотелось бы увидеть критику именно этого варианта.
А исполнители есть и в диаграммах деятельности UML, как инструмент необходимый даже для проектирования ПО для информационных систем.

Бизнес-процесс — это совокупность взаимосвязанных мероприятий или задач, направленных на создание определенного продукта или услуги для потребителей.
И с этой точки зрения и измерение кровяного давления и разработка РПУД - бизнес-процесс.
Это я и пытаюсь описать. Для меня важно кто эти мероприятия (задачи) выполняет и каков их выход.
Еще раз повторюсь, что эта тема была предложена Владимиром Даниловичем в его книгах (например вся 3-я часть "Примеры алгоритмов для различных отраслей знаний" в книге "Дружелюбные алгоритмы..." практически об этом). Я лишь пытаюсь понять как это сделать, опираясь на близкий мне вид деятельности. Тем более, что от ВУЗов требуют наличие СМК.

Я имел ввиду примерно следующее:

"Лапша" получается. Не информативно IMHO.
Так уже близко к IDEF0 получается.
Добавить с другой стороны такое же запутанное "управление" и будет чудно.

Чем больше элементов мы хотим видеть на схеме, тем сложнее эту схему будет понимать. Всё закономерно.
Лапши на самом деле тут нет, поскольку мы чётко видим двух участников процесса, и маршруты их взаимодействия с процессом (синим). При этом маршруты специально не объединены в одну шину, а у каждого участника своя шина.
По шине участника можно проследить какие именно действия в процессе он выполняет и в каком порядке.
В идеале (чего не позволяет статичный рисунок) нужно иметь возможность переключатся от процесса к участникам и наоборот, делая полупрозрачным неиспользуемую часть схемы.

Хм?.. Если Вы и дальше будете бездумно приводить бессмысленные определения из Wiki/стандартов/учебников, то... тема обсуждения растворится сама собой. Чтобы понять бессмысленность данного конкретного определения, поменяйте местами слова "бизнес-процесс" и "мероприятия". Что-то изменилось? Ничего... То есть, Вы повторяете попытку определить что-то через синонимы... Не доблесть...
... и добыча руды, и плавка металла и даже... продажа мороженного на остановке... А знаете сколько ещё всяких бывает?.. У-у-у-у...
А как выполняет... неважно? А каковы критерии того, что тот, кто выполняет... способен выполнять? Неважно?.. А что требуется для выполнения тоже неважно? А критерии достижения результата на каждой стадии? И ещё много-много подобных вопросов.
Вон на схеме нарисован "медработник"... Любой медработник? Уборщица из больницы - это медработник?.. А стоматолог?.. А какие приспособления, инструменты используются при взятии крови?.. Фиолетово?.. Тем более, фиолетовы требования к этим "фиолетовым" инструментам... а потом удивляемся вспышкам гепатита...
Так я, в основном, ему и писал...
Ну, раз требуют... то надо исполнять... а я пишу для тех, кто думает (порой это трудно, но всё же полезно... хотя процесс думания никому пока не удалось записать в виде "бизнес-процесса", то ли менеджеры не думают, то ли методика кривая...).

Точно. Кстати, это совмещение уже есть - у Калянова... Он там и целую грамматику бизнес-процессов навернул на это представление... но подход вызывает сомнение у alexus... и не только у него...
В идеале нужно исходить из такого свойства систем (куда, я полагаю, мы отнесём и системы представления знаний ), как "целостность и членимость". Т.е. запись конкретной деятельности строится как частный случай "деятельности вообще". И надо иметь возможность показать эту запись и совмещённо, и разнесённо. Для чего определить, на какие логически самостоятельные части делится описание.

То, что процесс состоит из подпроцессов не новость. Так можно и определение системы раскритиковать.

Мед работник - это не мое.
Критерии оценки и квалификация сотрудника не являются предметом графического описания, но они тоже подлежат рассмотрению.

Недовольные всегда были есть и будут, несмотря на то что делается, как делается и т.п. Это Фрейд подробно описал.

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

Десятки крупных институтов занимаются проблемой описания деятельности, процессов, систем и т.п., как словесно, так и схематично. У каждого свои подходы, свои схемы, свои сторонники и свои противники. А не ошибается лишь тот, кто ничего не делает.

Посмотрите начало книги Кольваха в этом посте... Вы не об этом (о квалификационных характеристиках исполнителей, на которых определяется деятельность)?..
Кстати, в реальности есть и общий случай деятельности - множественный по задачам и/или числу исполнителей - см. этот пост. Вы, очевидно, и это подразумеваете?

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

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

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

Знаменитая свифтовская шутка:

So, naturalists observe, a flea
Hath smaller fleas that on him prey;
And these have smaller still to bite'em;
And so proceed ad infinitum.

(Итак, ученые видят: блоха,
На ней сидят блошки поменьше и сосут ее кровь;
На меньших блошках сидят еще меньшие и кусают их.
И так до бесконечности.)

Все логично

P.S. Дальше буду писать только по существу вопроса, дабы не перенесли во флейм.

Посмотрел, там же и ответил. Да, я о квалификации говорил и о квалификационных требованиях, которые отчасти задаются государством (и должны не только задаваться, но и сертифицироваться, и контролироваться). То есть, если работодателю нужно подтверждение моих знаний и навыков, то он направляет меня на государственную аттестационную комиссию, которая выдаёт или не выдаёт мне сертификат, подтверждающий мою квалификацию. По большому счёту разработка требований к профессиям и квалификациям/категориям, обучение, сертификация/контроль - задача государственная. Точно также, как государство утверждает требования (в рамках стандартов (ГОСТ)) к продукции и полуфабрикатам. К оборудованию (классам точности и т.п.) и метрологии, с содержанием метрологических служб/лабораторий.
Поэтому, описывая "бизнес-процесс", мы не должны выдумывать какие-то требования, а просто указывать: Болт М16 по ГОСТ 7798-70, 7796-70, работники профессий 20626, 20448, 20463 по ОКПДТР (или типа того), станки фрезерные кл. точности 3 по ГОСТ...
Честно говоря, не совсем понял, что понимается под "множественной" деятельностью...

Во-во... Кстати, тем, кто укажет на то, что не все квалификации м.б. предусмотрены справочником профессий, можно ответить - во-первых, справочник может и должен быть динамичным (наверное, в его поддержании и есть основная роль государства и всевозможных "центральных институтов труда"); во-вторых, в хорошем справочнике изначально оставляется "перспективный случай" (помнится, в советское время слесарь высшего разряда, скажем, определялся как способный выполнять "особо сложные, точные, уникальные" изделия)...
Имеется в виду - что мы в простейшем случае для единичного исполнителя определяем занятость в единственном экземпляре одного процесса. Более сложно - когда исполнитель коллективный и между разными РМ распределяется содержание процесса. И наконец, исполнитель (единоличный или коллективный) м.б. занят в ряде процессов и/или рядом экземпляров одного процесса (на разных совокупностях предметов труда), причём виды/экземпляры процессов м.б. не равно значимы и/или срочны.