DRAKON.SU
https://forum.drakon.su/

Сравнение языка ДРАКОН со всякими другими
https://forum.drakon.su/viewtopic.php?f=153&t=2215
Страница 3 из 15

Автор:  dvuugl [ Вторник, 05 Январь, 2010 00:25 ]
Заголовок сообщения:  Re: Сравнение Дракона со всякими другими : )

Наверное стрелки нужны только там где возможна неоднозначность,
где возможно перепутать "распараллеливание" со "слиянием".
Возможность присоединить горизонтальную шину к шампуру было бы во многих отношениях полезно:
в одном случае на ней как на перекладине виселицы висели бы параллельные процессы,
в другом структуры данных, в третьем методы класса.
Тогда ассиметричный дракон-маршут задавал бы не только последовательности действий, но предметы, объекты.
Где-то выше на форуме такое рисовал.
Вложение:
p1.png
p1.png [ 50.07 КБ | Просмотров: 19632 ]

Автор:  Владислав Жаринов [ Вторник, 05 Январь, 2010 05:45 ]
Заголовок сообщения:  Re: Сравнение Дракона со всякими другими : )

Уважаемый Эдуард,
Для ясности вот доступные описания методологии моделирования потока процессов IDEF3 (см. вложения выдержек из работ); кстати, в более раннем документе перекрёстки называются несколько ближе к сути, но тоже не очень удачно; Ваши термины, наверное, лучше подойдут (хотя "расщепление" я бы заменил на "расхождение" или "раздачу" - в этом контексте кажется как-то ближе в качестве антонима "сбора"). Пожалуй, можно использовать этот стандарт для изображения систем процессов; введённые Вами разновидности узлов, видимо, можно считать частными случаями. По этому поводу могу высказать следующие соображения (далее ссылаюсь на документ Dubeik_AllFPM... и использую его терминологию).
Во-первых, конечно, подобные средства не входят в ДРАКОН, а образуют вместе с ним гибридный визуальный метаязык представления знаний, подобно тому, как в п/р 1.4 это показано для методологий SADT; тем самым обеспечивается целостность моделирования. Здесь сразу возникает "основной вопрос философии" :) - какой язык первичен, т.е. даёт более обобщённое описание (выше по иерархии, включает в себя описания на другом языке)? Следуя предложенной Вами логике, первичен техноязык, внутри которого употребляются IDEF3-средства; но мне представляется, что IDEF3-подобная модель должна стоять выше; визуалы же д.б. детализациями её событий и рассматриваться как единичные процессы (UOW). Дело в том, что алгоритм в конце концов реально исполняется по конкретному маршруту, а тут получается, что могут проходиться сразу и два и более маршрутов между точками (Илья Ермаков уже указывал на это; см также на этой странице о командном уровне формализации в информатике); хотим много маршрутов - запускаем много визуалов, и каждый крутится независимо (если на очередном шаге не использует величины, ранее выработанные другими).
Далее, если у нас "всё в одном месте" (я так понимаю, что на одной диосцене), то в интересах когнитивной эргономичности (говоря конкретнее, удобства восприятия) детализация минимальна; каждый визуал свёрнут (представлен своим UOW-блоком). Можно потребовать, чтобы схема была гибридной, и тогда естественно было бы представлять блок иконой Вставка; имеем, по аналогии с терминами Владимира Даниеловича, модель-концепцию, но нужно быть осторожным: выходное состояние UOW-алгоритма не обязательно достигается с его завершением, как следует из смысла иконы Вставка (если мы допускаем зацикленные визуалы), да и вообще такая модель не есть алгоритмическая. Точно так же, говоря о возможности визуализации содержания функций ФМ-методологии IDEF0 в этом пункте, я не имел в виду совмещения на одной схеме элементов (конструкций) ДРАКОНа и ФМ-языка; это не мешает отображать визуалы совместно с ФМ-схемой, но как атрибуты содержания её блоков (как сделано в DesignIDEF или AllFPM для текстовых определений); эти два языка по-разному смотрят на предмет описания. Кстати IDEF0 и IDEF3 диаграммы в гибридной модели тоже сочетаются с определёнными ограничениями при информатизации процесса такого моделирования (напр. в AllFPM; см. п. 4.2.2.2 у Дубейковского).
Наконец, отдельно взятый перекрёсток (слияния ли, разветвления ли) отображает принятие решения о запуске последующих процессов (единственного процесса для слияния); из Рис. 1.3.4 (с.24) видно, что можно определить смысл принимаемого решения (посредством блока-референта, присоединённого к перекрёстку ненаправленной связью), а по сути - вопрос, ответ на который определяет, "пройти" данный перекрёсток или "подождать" на нём некий интервал (шаг отслеживания) и задать вопрос снова. Очевидно, т.к. UOW есть свершившееся событие, то приравнивая его к визуалу (предшествующему), имеем условием прохода выработку в ходе исполнения этого визуала состояния, которым помечена выходная дуга его UOw; так и получается та самая "плюс-минус неделя" - скажем, один процесс достиг состояния, разрешающего пройти перекресток слияния (в Ваших терминах - точку сбора), уже N шагов назад, а другой ещё и сейчас не достиг аналогичного (конечно, корректный визуал когда-нибудь должен до него добраться - или выйти по тайм-ауту, как Вы предлагаете), тогда если этот перекрёсток типа "И", то последующий процесс пока не стартует. Поэтому представляется, что перекрёсток можно при алгоритмизации гибридной модели отобразить всё-таки на базе икон И20 Параллельный процесс и условных конструкций техноязыка реального времени, алгоритмически формализующих определение моментов запуска последующих процессов исходя из наблюдаемого состояния предшествующих (а это состояние есть комбинация значений алгоритмических и служебных величин); т.о. модель с перекрёстками просто формализует на доалгоритмическом уровне причинно-следственные связи системы визуалов с учётом времени их начала/завершения (строго - в синхронном варианте и нестрого - в асинхронном). Конечно, в сложных случаях это будет нагляднее, чем сразу пытаться построить дракон-модель. Кстати, в таком контексте, возможно, название иконы Параллельный процесс не вполне отражает её суть, но тут пока мне судить трудно.
Вот такие мысли пока. Конечно, это описание качественного уровня; нужно строго определить, напр., порядок алгоритмизации перекрёстков (в частности, по каким параметрам варьируем задержку запуска процессов в асинхронном), содержание пусковых икон И20 (в машинной инфорсиме это, очевидно, системная команда порождения процесса). По сути, схему с перекрёстками можно рассматривать как модель дракон-диспетчеризации заданной её UOW-ами совокупности алгоритмов; тогда мы можем как альтернативу описания аварийного выхода из UOw-визуала в его теле включить его завершение в алгоритм последующего перекрёстка через икону И20 с сообщением останова (в реальной инфорсиме - командой снятия процесса).
Очевидно, предложение, сформулированное dvuugl, уточняет Ваше, только нужно заранее чётко определить смысл узлов распараллеливания - какой алгоритм стоит за каждым (то, что нарисовано, я могу трактовать в терминах IDEF3 как перекрёстки слияния типа "И", но им должны соответствовать перекрёстки разветвления); и опять-таки эта схема уже не алгоритм, а система алгоритмов, но те, что в теле основного (между перекрёстками), по сути, неявно выделенные (без заголовков и названий); а удобно ли это? Есть идея, что методы класса можно показать и в составе силуэта, приписав их началам допвходы и соответственно разадресовав "подвал" (так, чтобы ветки из одного допвхода не вели на ветки других); а если у ряда методов есть общая конечная часть, то её ставим под своим допвходом и адресуем конечные ветки нужных методов на него. Наверно, можно и произвольно комбинировать допвходы, если в техноязыке допустить некие варианты использования имён визуалов и веток. По поводу структур данных - очень хотелось бы такого схематического изображения, это как раз будет визуальный классиф-подъязык деклар-языка, который нужно поставить "в связке" с техноязыком для наибольшего удобства визуализации.

Вложения:
Комментарий к файлу: Черемных С.В. и др. Структурный анализ систем: IDEF-технологии. - М.: Финансы и статистика, 2001.
Cher_StrSA_Gl3(IDEF3).pdf [2.98 МБ]
Скачиваний: 486
Комментарий к файлу: Дубейковский В.И. Эффективное моделированиее с AllFPM 4.1.4... - М.: ДИАЛОГ-МИФИ, 2007.
Dubeik_AllFPM_P1p3(IDEF3)bl+gr.pdf [1.89 МБ]
Скачиваний: 488

Автор:  Владимир Паронджанов [ Вторник, 05 Январь, 2010 12:38 ]
Заголовок сообщения:  Re: Сравнение Дракона со всякими другими : )

Ильченко Эдуард писал(а):
Вариант со стрелочками взгляду приятнее(ИМХО).

Кстати, Владимир, стрелочки здесь как часть визуального языка? Вроде в Драконе стрелочки не принято рисовать.


В драконе (описанном в книге) стрелки используются очень редко,
только в двух случаях:
1. Стрелка силуэта (каждый силуэт имеет одну стрелку).
2. Стрелка обычного цикла, переключающего цикла и цикла ЖДАТЬ.
См. рис. 2, макроиконы 4, 5, 7.
________________________________________________________________

Глядя на Ваши рисунки, я увидел, что существующий Дракон не решает
Вашу задачу. Отсюда я сделал вывод. Надо добавить к Дракону дополнительные средства,
чтобы Дракон мог справиться с Вашей задачей.

Вопрос таков. Как должны выглядеть эти вновь добавляемые средства?
Пока что ответ мне не ясен.
Мое предложение вряд ли является приемлемым
viewtopic.php?p=39969#p39969.

Может быть, предложение двуугла является более удачным.
viewtopic.php?p=39971#p39971

Было бы очень хорошо сообща подумать

Автор:  Ильченко Эдуард [ Вторник, 05 Январь, 2010 15:07 ]
Заголовок сообщения:  Re: Сравнение Дракона со всякими другими : )

Владимир Паронджанов писал(а):
Может быть, предложение двуугла является более удачным.
http://forum.oberoncore.ru/viewtopic.php?p=39971#p39971

Было бы очень хорошо сообща подумать
Согласен. Картинка получается лёгкой и, в принципе, понятной.
Вложение:
Напоить себя3.png
Напоить себя3.png [ 43.42 КБ | Просмотров: 19587 ]
Драконограф писал(а):
и опять-таки эта схема уже не алгоритм, а система алгоритмов, но те, что в теле основного (между перекрёстками), по сути, неявно выделенные (без заголовков и названий); а удобно ли это?

В точке A, происходит выбор варианта. Об этом однозначно говорит икона "Выбор".

В точке B, происходит запуск независимых (параллельных) процесов. Явного указания на это нет (как в случае с иконой "Выбор"). Хотелось бы услышать мнение сообщества. Нужно ли такое указание? Как оно должно выглядеть? Не будет ли оно загромождать схему?

Автор:  Ильченко Эдуард [ Вторник, 05 Январь, 2010 15:21 ]
Заголовок сообщения:  Re: Сравнение Дракона со всякими другими : )

Драконограф писал(а):
Есть идея, что методы класса можно показать и в составе силуэта, приписав их началам допвходы и соответственно разадресовав "подвал" (так, чтобы ветки из одного допвхода не вели на ветки других); а если у ряда методов есть общая конечная часть, то её ставим под своим допвходом и адресуем конечные ветки нужных методов на него. Наверно, можно и произвольно комбинировать допвходы, если в техноязыке допустить некие варианты использования имён визуалов и веток. По поводу структур данных - очень хотелось бы такого схематического изображения, это как раз будет визуальный классиф-подъязык деклар-языка, который нужно поставить "в связке" с техноязыком для наибольшего удобства визуализации.
Есть ли обсуждение на форуме? Если есть, то не могли бы Вы дать ссылочку?

Автор:  dvuugl [ Вторник, 05 Январь, 2010 16:04 ]
Заголовок сообщения:  Re: Сравнение Дракона со всякими другими : )

Полезность возможности присоединения ШИНЫ к шампуру (на предмет структур данных), возможно не очень внятно, пытался обосновать здесь: viewtopic.php?f=62&t=1787
Кратко: от ДРАКОНА как модели действия к ДРАКОНУ как модели изделия, предмета (его структуры).
ДРАКОН задаёт не маршрут действия, а маршрут восприятия чего-либо, в том числе и действия. В разных случаях, контекстах шина может моделировать, означать параллельные процессы, структуры объектов, классы. А здесь может быть обозначить явно каким-нибудь знаком параллельности? :
Вложение:
napoit1.png
napoit1.png [ 9.01 КБ | Просмотров: 19579 ]

Автор:  Ильченко Эдуард [ Вторник, 05 Январь, 2010 16:41 ]
Заголовок сообщения:  Re: Сравнение Дракона со всякими другими : )

dvuugl писал(а):
А здесь может быть обозначить явно каким-нибудь знаком параллельности? :
Вложение:
napoit1.png
Лично я не против.

Автор:  Владимир Паронджанов [ Вторник, 05 Январь, 2010 18:02 ]
Заголовок сообщения:  Re: Сравнение Дракона со всякими другими : )

Мои предложения.
Дополнить визуальный алфавит Дракона двумя иконами:
1. Точка расщепления (черный кружок)
2. Точка сбора (стрелка слияния)
_____________________________________________________

Исправление. Стрелку делать не черную, а с двумя крыльями,
как предложил двуугл
viewtopic.php?p=39971#p39971

В этом случае стрелка силуэта будет отличаться от стрелки слияния

Вложения:
Комментарий к файлу: две иконы: черный кружок и стрелка слияния
Кофе кофе.png
Кофе кофе.png [ 38.54 КБ | Просмотров: 19553 ]

Автор:  Илья Ермаков [ Вторник, 05 Январь, 2010 18:45 ]
Заголовок сообщения:  Re: Сравнение Дракона со всякими другими : )

Доп. предложения:

Те действия, которые в параллельных ветках, помечать как-то (например, черта у правого края прямоугольника).

Автор:  Владислав Жаринов [ Среда, 06 Январь, 2010 05:54 ]
Заголовок сообщения:  Re: Сравнение Дракона со всякими другими : )

Ильченко Эдуард писал(а):
Есть ли обсуждение на форуме? Если есть, то не могли бы Вы дать ссылочку?

Если по поводу представления методов (в широком смысле - специфических приёмов визуализации объектных алгоритмов), то нет - эта идея недавно пришла мне в голову. Т.к. сформулирована не программистом, то возможно, в общем случае будет неверной, но при заданных ограничениях, похоже, такой силуэт работать будет. Конечно, имена допвходов содержат названия методов. По подъязыку классификации (визуализации структуры сложного типа объекта, а в общем случае, как я понимаю, вообще всех типов конкретной дракон-модели) ссылку уже дал dvuugl. В каком-то смысле здесь видна информатизация синтаксических диаграмм. Очень интересна идея, что дракон-схема может выражать разные точки зрения и даже на разные предметы, но всегда ли она при этом останется именно визуальным алгоритмом (или хотя бы выполнимой спецификацией деятельности) - наверное, надо ещё смотреть.

Автор:  Владислав Жаринов [ Среда, 06 Январь, 2010 06:18 ]
Заголовок сообщения:  Re: Сравнение Дракона со всякими другими : )

Владимир Паронджанов писал(а):
Мои предложения.
Дополнить визуальный алфавит Дракона двумя иконами:
1. Точка расщепления (черный кружок)
2. Точка сбора (стрелка слияния)
_____________________________________________________

Исправление. Стрелку делать не черную, а с двумя крыльями,
как предложил двуугл
viewtopic.php?p=39971#p39971

В этом случае стрелка силуэта будет отличаться от стрелки слияния


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

Автор:  Ильченко Эдуард [ Среда, 06 Январь, 2010 14:18 ]
Заголовок сообщения:  Re: Сравнение Дракона со всякими другими : )

Драконограф писал(а):
Однако не очень ясно, как трактовать отдельно взятый процесс, содержащийся в охватывающей дракон-схеме между точками расщепления и сбора. Он является самостоятельным алгоритмом? Получается, что он не имеет ни имени, ни формальных параметров. Кроме того, с момента запуска каждый процесс (не исключая охватывающего) "живёт своей жизнью", а координируется ли как-то их выполнение? Наверно, и у Вас есть какое-то мнение на этот счёт?
Изначально речь шла о таких процессах:
Ильченко Эдуард писал(а):
Независимые процессы А и В могут выполняться параллельно (А || B), в порядке А -> В или В -> А. Совершенно не важно кто выбирает порядок: транслятор по RAND, программист или "начальник транспортного цеха". Нет задачи попасть в точку сбора в определённое время. Есть задача, чтобы все процессы достигли этой точки.
Имя процессу нужно если он будет контролироваться извне. Например, некий менеджер : ) контролирует возведение стен дома, по тайм-ауту ему посылается сообщение, что «стены до сих пор нет» и имя запоротого процесса.

А вот в случае приготовления кофе, ИМХО, имя процессу и не нужно, только картинку перегрузит.

Что касается бизнес-процессов, то выше приведённая конструкция выглядит не плохо.
Чего не скажешь в случае программирования, как такового. В программе порядок действий должен быть задан однозначно. Следовательно, нужно определить порядок запуска процессов. Например слева на право. Тогда вся конструкция вырождается в линейный алгоритм. Зато появляется возможность визульно представить 1-D конструкцию алгоритма как 2-D. Хорошо ли это, не знаю : )

Кстати, «точка слияния» в паре с «точкой расщепления», на мой взгляд звучит лучше чем «точка сбора».

Автор:  Рэйлвэй Каген [ Среда, 06 Январь, 2010 16:23 ]
Заголовок сообщения:  Re: Сравнение Дракона со всякими другими : )

Попробовал я тут поэкспериментировать с силуэтом в следующих аспектах:
1.разрешил многоадресные ссылки (икона "адрес" со списком адресов вместо одного адреса)
2.динамические связи маршрута выполнения алгоритма отобразил на
статические связи по данным (было давно уже в дискуссиях с Алексеем Донским)
3.ну очень уж понравились мне join'ы и split'ы от YAWL :)

Вот что получилось:
Вложение:
дом_силуэт.png
дом_силуэт.png [ 10.8 КБ | Просмотров: 19500 ]
Можно представить эту штуку в виде примитива, поскольку существует
планарная раскладка (заодно спрячем "лишние" иконы):
Вложение:
дом_примитив.png
дом_примитив.png [ 21.37 КБ | Просмотров: 19500 ]


И самое главное - в отличие от безымянных точек и стрелок, получившиеся
join'ы и split'ы позволяют проводить дальнейшую их декомпозицию до состояния,
понятного группе элементарных "последовательных исполнителей":
Вложение:
дом.png
дом.png [ 19.48 КБ | Просмотров: 19260 ]




p.s.: И ещё я дополнил бы получившийся зверинец вот такой штукой:
Вложение:
blackbox.png
blackbox.png [ 989 байт | Просмотров: 19499 ]

Автор:  Ильченко Эдуард [ Среда, 06 Январь, 2010 17:17 ]
Заголовок сообщения:  Re: Сравнение Дракона со всякими другими : )

Рэйлвэй Каген писал(а):
Попробовал я тут поэкспериментировать с силуэтом в следующих аспектах:
1.разрешил многоадресные ссылки (икона "адрес" со списком адресов вместо одного адреса)
2.динамические связи маршрута выполнения алгоритма отобразил на
статические связи по данным (было давно уже в дискуссиях с Алексеем Донским)
3.ну очень уж понравились мне join'ы и split'ы от YAWL :)
Поскольку это меня мучили вопросы независимых процессов : ) скажу - очень интересно. И по Драконовски, ИМХО.

Автор:  Владислав Жаринов [ Четверг, 07 Январь, 2010 05:38 ]
Заголовок сообщения:  Re: Сравнение Дракона со всякими другими : )

Ильченко Эдуард писал(а):
Кстати, «точка слияния» в паре с «точкой расщепления», на мой взгляд звучит лучше чем «точка сбора».

Согласен, только пусть будет "узел"; солидаризируюсь с Рэйлвей Каген, что это всё-таки не "безымянная точка", а нечто содержательно посложнее, и надо это отличать терминологически. Далее пользуюсь такой терминологией.

Ильченко Эдуард писал(а):
Независимые процессы А и В могут выполняться параллельно (А || B), в порядке А -> В или В -> А. Совершенно не важно кто выбирает порядок: транслятор по RAND, программист или "начальник транспортного цеха". Нет задачи попасть в точку сбора в определённое время. Есть задача, чтобы все процессы достигли этой точки. Имя процессу нужно если он будет контролироваться извне. Например, некий менеджер : ) контролирует возведение стен дома, по тайм-ауту ему посылается сообщение, что «стены до сих пор нет» и имя запоротого процесса.

А вот в случае приготовления кофе, ИМХО, имя процессу и не нужно, только картинку перегрузит.

Что касается бизнес-процессов, то выше приведённая конструкция выглядит не плохо.
Чего не скажешь в случае программирования, как такового. В программе порядок действий должен быть задан однозначно. Следовательно, нужно определить порядок запуска процессов. Например слева на право. Тогда вся конструкция вырождается в линейный алгоритм. Зато появляется возможность визульно представить 1-D конструкцию алгоритма как 2-D. Хорошо ли это, не знаю : )

Порядок запуска процессов д.б. таким, как нужно для достижения цели. По поводу контроля извне: сейчас даже в функциональном моделировании бизнес-процессов (IDEF0) пришли к тому, что среди боксов верхнего уровня иерархии д.б. управляющий, чтобы система была кибернетической, т.е. целенаправленной (см., кажется, в книге Дубейковского, предшествующей той, из которой давал выдержку, или в работе: Костров А.В. и др. Уроки информационного менеджмента. – М.:Финансы и статистика, 2005.). Поэтому "менеджер" теперь есть всегда :) И надо учитывать это и в более низкоуровневых моделях, вплоть до программ (и вообще командных моделей деятельнсти).
Попробую предметно обсудить в этом аспекте свойства предложения по расширению техноязыка, сформулированного, как я понимаю, независимо также dvuugl. Прошу простить за многословие вместо картинок, но сам же согласился с тем, что формализация начинается с текста, т.е. чтобы начертить что-то, это сначала надо проговорить:). Конкретно для модели dvuugl зададимся следующими вопросами:
1) Можно ли вводить такое расширение? Да, и даже необходимо, и не только в целях наглядности, но и чтобы отразить реально возможное многообразие путей (маршрутов) решения задачи.
2) Является ли данная модель дракон-схемой (визуализацией некоторого алгоритма)? Нет, не является, и именно в силу того, что мы решили показать на ней многообразие маршрутов. В результате процесс выполнения этой схемы перестаёт быть алгоритмическим (невозможно указать единственную цепочку шагов от начала к концу даже при определённых и корректных значениях всех входных данных).
3) Можно ли свести данную модель к информатической (алгопроцессу или системе алгопроцессов) с сохранением смысла, вложенного её сочинителем (научно говоря, "семантики")? Думаю, да, можно. Например, средствами классического техноязыка я бы воспользовался так. Полагаю модель dvuugl частным случаем модели с узлами-перекрёстками, причём тип узла сбора неявно устанавливается по типу предшествующего узла расщепления; также все узлы асинхронные и имеют тип "И" (строго говоря, при единственном типе узлов неважно, явно или неявно устанавливается тип - всё равно других в модели быть не может; это важно, если мы захотим расширить язык модели). Тогда данную модель можно преобразовать следующим образом:
1. Выносим каждый маршрут (шампур-блок) между узлами в отдельный визуал, которому даём имя (т.е. делаем своего рода групповую подстановку); при этом вынесенные визуалы понимаются не как вставки, а как параллельные процессы-потомки, отсюда и дальнейшие рассуждения. Можно определить формальные параметры (если считать, что в сообщении на запуск визуала, передаваемом иконой И20, они м.б. перечислены также, как в иконе Вставка).
2. На место узла расщепления ставим икону И20, инициирующую все вынесенные визуалы. В конце каждого из этих визуалов ставим икону И20, посылающую сообщение о завершении этого алгоритма визуалу-родителю (м.б. передан конкретный результат исполнения потомка).
3. От иконы И20 к узлу слияния прокладываем звено вертикали; его содержанием считаем цикл ЖДАТЬ, в котором проверяем получение сообщений о завершении от каждого потомка (т.к. у нас сбор "И", то условием выхода из цикла будет наличие сообщений ото всех потомков).
Такую систему алгоритмов уже можно исполнять (неважно, параллельно, или квазипараллельно).
Попробую конкретизировать сказанное ранее. Информатическая модель, как только её дополнить возможностями, при которых теряется свойство развёртываемости при каждом исполнении по единственному маршруту, перестаёт быть информатической и возвращается на математический уровень формализации (а то и на качественный, если не обеспечивается даже математическая строгость); как следствие, надо найти средства и условия обратного перехода от такой модели к информатической. Это касается и IDEF3-подобных моделей деятельности. Считаю их более общим случаем и попробую предложить метод сведения таких моделей к алгоритмическим.
Про диспетчеризацию было упомянуто не зря. Основная идея алгоритмизации модели с узлами расщепления/сбора процессов (буду называть её схемой поведения, исходя из смысла, приданного в IDEF3) следующая. Некий надалгоритм (системный процесс) в цикле ЖДАТЬ (задающем шаг отслеживания) регулярно проверяет состояние совокупности активных (выполняемых на данном шаге) процессов из числа входящих в схему поведения, на соответствие совокупности условий, определённых узлами этой схемы (понятно, что можно ограничиться узлами, которым предшествуют активные процессы, если устанавливать/сбрасывать и проверять атрибут активнсти). Когда выполнено условие для некоторого узла (совокупности узлов), результатом является запуск процесса (совокупности процессов) посылкой определённых сообщений (представляемой посредством икон И20).
Для асинхронного режима дополнительно определяются возможные (потенциально учитываемые при алгоритмизации поведения) условия неодновременного начала (т.е. допустимого "откладывания" запуска) тех или иных процессов из числа инициируемых асинхронным узлом расщепления (конечно, если тип узла не "Исключающее ИЛИ"; это особый случай, и как видно из сравнения определений узлов у Дубейковского и Черемных, при информатизации схем поведения в среде AllFPM даже "потеряно" выделение синхронности/асинхронности для этого типа узлов; наверное, не случайно:) ) и равно возможные условия неодновременного завершения процессов из числа инициируемых асинхронным узлом сбора (т.е. допустимого раннего окончания некоторых процессов). Эти условия, очевидно, м.б. по времени (учитывая: возможные в реальности разбросы моментов; необходимые интервалы между началами/завершениями конкретных процессов, определяемые "физикой" моделируемой системы; и т.д.), по доступности исполнителей процессов (квантов времени исполнителя), по чему-либо ещё. Иначе говоря, смысл узла расщепления/сбора, определяемый явно (через содержание подключённого узла-референта) или неявно, м.б. не любым, а только таким, который можно превратить в алгоритмический процесс (описать который, как и основные процессы, конечно, оптимально на техноязыке).
Фактически предлагается для каждой модели поведения процессов (представляемой как схема поведения) строить надалгоритм диспетчеризации (и конечно перестраивать его вслед за корректировкой схемы); модель должна охватывать систему целиком. Очевидно, для автоматизации работы по алгоритмизации моделей поведения нужна либо среда гибридного моделирования, для которой язык схем поведения является входным так же, как и ДРАКОН, и которая строит надалгоритм по схеме поведения, либо для дракон-среды (поддерживающей только техноязык - гибридизированный с прогязыками или нет, понятно, здесь роли не играет) - отработанные методики формирования такого надалгоритма для произвольной схемы поведения (ну и поддерживающие их заготовки-образцы фрагментов надалгоритма).
Возможны, наверное, и другие пути сквозной формализации отношений между процессами. Так, можно, наверное, перенести на общие модели поведения принцип, показанный на частной модели dvuugl: не формировать отдельный процесс управления поведением, а распределить его функции по смежным процессам. Кроме того, как уже указывалось где-то на форуме, иконы И20 реализуют метод рандеву, а возможен ещё по крайней мере метод семафоров.

Автор:  Владислав Жаринов [ Четверг, 07 Январь, 2010 05:47 ]
Заголовок сообщения:  Re: Сравнение Дракона со всякими другими : )

Рэйлвэй Каген писал(а):
Попробовал я тут поэкспериментировать с силуэтом в следующих аспектах:
1.разрешил многоадресные ссылки (икона "адрес" со списком адресов вместо одного адреса)
2.динамические связи маршрута выполнения алгоритма отобразил на
статические связи по данным (было давно уже в дискуссиях с Алексеем Донским)
3.ну очень уж понравились мне join'ы и split'ы от YAWL :)

Здорово! Можно оставаться в рамках драконовской нотации, и в то же время "на глаз" понятно, что это модель поведения ряда процессов. А смысл многоадресной ссылки какой? Только "асинхронное И" (используя термины IDEF3)?

Рэйлвэй Каген писал(а):
p.s.: И ещё я дополнил бы получившийся зверинец вот такой штукой:

А здесь какой смысл? Набор действий, для которых пока (на данном уровне рассмотрения) не указан порядок выполнения?

Автор:  Рэйлвэй Каген [ Четверг, 07 Январь, 2010 12:01 ]
Заголовок сообщения:  Re: Сравнение Дракона со всякими другими : )

1. многоадресная ссылка нужна для определения взаимодействий "один ко многим". При этом категорически не хотелось бы фиксировать нотацию только в рамках AND/XOR/OR-splits/joins, поскольку в Драконе есть возможности для алгоритмической "расшифровки" взаимодействий.
2. "чёрный ящик" предназначен для определения взаимодействий "многие ко многим".

Прим.: механизм "многие к одному" уже реализован в Драконе на базе стандартных икон "Адрес"-"Ветка"

Автор:  Владислав Жаринов [ Пятница, 08 Январь, 2010 06:01 ]
Заголовок сообщения:  Re: Сравнение Дракона со всякими другими : )

Рэйлвэй Каген писал(а):
1. многоадресная ссылка нужна для определения взаимодействий "один ко многим". При этом категорически не хотелось бы фиксировать нотацию только в рамках AND/XOR/OR-splits/joins, поскольку в Драконе есть возможности для алгоритмической "расшифровки" взаимодействий.

Имеется в виду анализ наблюдаемых состояний предшествующих процессов, как в IDEF3?

Рэйлвэй Каген писал(а):
2. "чёрный ящик" предназначен для определения взаимодействий "многие ко многим".

Прим.: механизм "многие к одному" уже реализован в Драконе на базе стандартных икон "Адрес"-"Ветка"

А как раскрывается такое взаимодействие в виде алгоритма?

Теперь попробую рассмотреть предложение Рэйлвей Каген, как я его понял первоначально. Исходя из представленных схем, можно считать, что его смысл заключается в следующих положениях (если я неправ, полагаю, меня поправят):
а) ввести в техноязык узлы расщепления/сбора, что означает возможность функционального моделирования потока процессов (process flow) формализуемой задачи; т.о. речь идёт о реализации методологии формализации знаний типа IDEF3 в форме неалгоритмических моделей (схем поведения). Представлять схемы поведения (также называемых диаграммы потока процессов, англ. PFD) в двух формах: подобной примитиву и подобной силуэту.
б) в качестве обозначений узлов расщепления/сбора использовать иконы разрешённого (техноязыком) безусловного перехода (Адрес/Имя ветки), но употреблять их не по алгоритмическим правилам (обозначая отношения мощностью более чем 1:1), причём не только в силуэтовидной, но и в примитивидной форме схем поведения. При этом в первой форме вводятся, кроме реальных узлов расщепления/сбора, также фиктивные (имеющие смысл БП-соединителей "для связки" части расщепляемых путей через петлю).
в) принять логику узлов типа "И" (по проходе узла расщепления, выражающего отношение 1:M, должны стартовать все M последующих процессов; для прохода узла сбора, выражающего отношение N:1, должны завершиться все N предшествующих процессов).
г) принять временной тип узлов расщепления - синхронный (все последующие процессы стартуют, и притом одновременно), узлов сбора - асинхронный (все предшествующие процессы д.б. закончены, но необязательно одновременно).
д) считать, что процесс-элемент потока (единица поведения, UOW, UOB) завершается по завершении описывающего её алгоритма, т.е. UOB-визуал нужно построить так, чтобы он давал требуемое состояние перед иконой Конец; отсюда естественно не формулировать требуемое состояние явно посредством метки (в отличие от IDEF3-схем).
е) обозначать единицу поведения иконой Действие.
Как я понимаю, схема поведения всегда предельно концептуализована (в терминологии создателя техноязыка).
ж) использовать доп. отличительный признак икон БП в роли реальных узлов в виде перетолщенной прямой стороны контура; в тексте иконы-узла дублировать имена последующих процессов.
з) ввести процедуру преобразования схемы поведения в дракон-модель.
Разберём эти положения в данных формулировках.
а) не вызывает вопросов, т.к. автор показал, что он также подразумевает содержание узлов как некие алгоритмы, которые ещё нужно "проявить", чтобы получить алгоритмическую модель (показанную как схема "Дом"). Названия форм схемы "примитив" и "силуэт" вносят путаницу; поэтому употребляю другие термины.
Попытка двойственности форм схемы, на мой взгляд, вносит следующие проблемы: появляются пустые пути между расщеплением и сбором (не содержащие процессов); невозможны цепочки одновидовых узлов (расщепление за расщеплением, сбор за сбором). По моему разумению, такие цепочки нужно допустить. Их можно ввести и в силуэтовидную форму (раз уж мы трактуем силуэт как способ планаризации графов определённого рода); тогда в отдельных "ветковидных" конструкциях будут деревья расщеплений и сборов.
б) весьма элегантно и (на уровне моих знаний) также вопросов не вызывает, кроме того, что сказано для а). Каждое расщепление должно иметь парный ему сбор (не обязательно того же типа); в данном примере это вроде как соблюдается.
в) логикой "И" расщепление/сбор процессов не ограничиваются. Другие типы логик введены в стандарт IDEF3, очевидно, не зря, а потому, что такие отношения процессов в потоках встречаются на практике. Для них, конечно, несколько изменится способ формирования условий прохода узла.
г) наверное, и временной тип узла д.б. разным, как в IDEF3. Тогда расщепление м.б. также асинхронным (после прохода узла последующие процессы не обязаны стартовать одновременно), а сбор - также синхронным (для прохода узла предшествующие процессы обязаны завершиться одновременно).
Д) при таком определении перехода от процесса к узлу модель наиболее просто алгоритмизуется. Надо подумать, нужно ли расширять возможности взаимодействия, но похоже сам Рэйлвей Каген считает, что нужно (говоря о "расшифровке").
е) логичнее было бы в соответствии с логикой техноязыка и ТФЗ-ДРАКОН для процесса, визуализация которого уже известна, использовать икону Вставка, а иначе - икону Комментарий, текст которой описывает задумку будущего алгоритма (помнится, Паронджанов такой тип комментария называл стратегическим?). Кстати, можно допустить цепочку процессов между парными узлами.
ж) отличительные признаки иконы лучше выбрать, как в IDEF3 (имея в виду показать временной тип узла). Не совсем понятно, зачем дублировать имена (да ещё неточно, а с сокращением); видимо, для одновременного представления схемы как силуэта, хотя всё-таки сведение неалгоритмической модели к силуэту представляется несколько искусственным.
При расширении логики узлов текст естественным образом содержит указание типа логики (а развёрнутое определение условия прохода, как в референте узла IDEF3, в техноязыке можно поместить в приложения иконы).
З) естественно следует из а). Процедура перехода, исходя из сопоставления исходных моделей поведения ("Дом_примитив" и "Дом_силуэт") и конечной алгоритмической дракон-модели "Дом", видимо, та же, что я предложил при анализе модели dvuugl. Однако не просматривается принадлежность всех процессов дракон-модели к одной исходной модели поведения (к решению общей задачи "построить дом").
Не совсем понятно, почему у реальных узлов силуэтовидной формы (схема "Дом_силуэт") больше линий, чем надо. Результат доработки в графредакторе образа схемы, построенной в Ты-среде? Кстати, как делалась схема "Дом_примитив"?
Пока такие соображения, наверно, буду ещё их уточнять. В целом нужно ещё прояснять смысл узлов (гл. обр. возможности той самой "алгоритмической расшифровки взаимодействий" посредством их). Главное - в итоге определить, как все возможные смыслы узлов воплощаются в алгоритмические конструкции. Всё, что касается IDEF3, трактую в смысле Дубейковского (выдержки, вложенной в этом сообщении), т.к. это результат уточнения методологии для автоматизированной реализации.

Автор:  Рэйлвэй Каген [ Пятница, 08 Январь, 2010 19:06 ]
Заголовок сообщения:  Re: Сравнение Дракона со всякими другими : )

Драконограф писал(а):
Имеется в виду анализ наблюдаемых состояний предшествующих процессов, как в IDEF3?
- имеется в виду возможность декомпозиции икон "Адрес" и "Ветка".
Драконограф писал(а):
А как раскрывается такое взаимодействие в виде алгоритма?
- напоминает механизм, используемый для иконы "Вставка".

далее по пунктам..
а. применяются исключительно базовые термины языка ("примитив" и "силуэт") как указание на необходимость соблюдения существующих правил языка Дракон для каждого способа отображения.
"невозможны цепочки одновидовых узлов (расщепление за расщеплением, сбор за сбором)" - нет, такие конструкции возможны и в примитиве, и в силуэте.
б."Каждое расщепление должно иметь парный ему сбор (не обязательно того же типа)" - да, даже возможен автоматический контроль по этому признаку.
в.г.ж. ни временнОй, ни функциональный тин взаимодействия не указывается явно иконами "Адрес", "Ветка" и "ЧЯ". На данном уровне отображения тип можно указать через "Комментарий". Полностью взаимодействие описывается в ходе последующей декомпозиции.
д. даже отсутствие иконы "КОНЕЦ" никак не помешает дальнейшей алгоритмизации.
е. в отношении икон "Действие", "Вставка" и "Комментарий" ничего не изменяется. Они применяются в соответствии с базовыми правилами языка Дракон.
ж. в иконах "Адрес", "Ветка" использованы имена, отличные от имён в "Действиях", но семантически связанные со смыслом "Действий" . "Заголовки" в итоговых примитивах выбраны совпадающими с основным действием примитива. Правилами языка Дракон это вроде как не регулируется - хоть индексы поставьте.
з.
"ввести процедуру преобразования схемы поведения в дракон-модель" - представленный вариант рассчитан на работу с дракон-схемами и ориентирован на возможность декомпозиции икон "Адрес" и "Ветка". Какой-либо иной технологии я не предлагал.
"не просматривается принадлежность всех процессов дракон-модели к одной исходной модели поведения" - это нормальное состояние для различных уровней метасистемы.
Схемы "Дом_примитив" и "Дом_силуэт" - результаты "мысленного эксперимента", оформленные в обычном графическом редакторе.
Схема "Дом" - полностью сделана в и.с.DRAKON.
Число вертикальных линий, отходящих от икон "Адрес" и "Ветка" в силуэте ни на что не влияет и ничем не регламентируется(просто визуальный образ). Эти линии вместе с чёрным выделением горизонтальной границы икон могли бы обозначать расширенную функциональность и возможность последующей декомпозиции. При использовании модифицированных икон "Адрес" и "Ветка" в примитиве разумно показывать только необходимые входящие/исходящие маршруты для этих икон.
"как все возможные смыслы узлов воплощаются в алгоритмические конструкции" - руками и мозгами пользователя. Путём последовательной декомпозиции. Можно, конечно, присобачить построитель на базе паттернов, но это уже совсем другая песня :)

p.s.:подразумевается, что "ЧЯ" тоже может подвергаться декомпозиции. Ну и название, наверное, может быть попроще..
p.s.2:Конечно, названия "Адрес" и "Ветка" в модифицированном варианте слабо соответствуют новой(расширенной) семантике, но пока лучше пользоваться таковыми.

Автор:  ==== [ Пятница, 08 Январь, 2010 20:03 ]
Заголовок сообщения:  Re: Сравнение Дракона со всякими другими : )

Извините, Вы столько умных много слов написали, прямо ужас.
А ведь можно проще, т.е. по ГОСТ 19.701-90. Смотрите ГОСТ 19.701-90

Здесь
TAU 31 Декабрь, 2009 писал(а):
Согласен. Настала пора добавить это в Ваш редактор. Надо идти в ногу со временем - сейчас наступает эпоха параллелизма.

В и.с. DRAKON язык Дракон расширен понятием "Параллельные действия" из ГОСТ 19.701-90 и соответственно введена икона "Параллельное действие".
Упомянутые алгоритмы выглядят так:
Вложение:
ParalDeistvia.png

И.с. DRAKON и справка будут позже.

Страница 3 из 15 Часовой пояс: UTC + 3 часа
Powered by phpBB® Forum Software © phpBB Group
https://www.phpbb.com/