DRAKON.SU

Модератор: вопрос выделен из темы viewtopic.php?f=62&t=957

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

Пример такого алгоритма в студию. Тогда можно будет говорить предметно.

Алгоритм управления станком с чпу. Реальный алгоритм существенно сложней и будет содержать перекрестные связи между блоками.

Вот следующее приближение.
Во первых есть два главных процесса
1 - цикл управление режимами работы "режим работы станка"
2 - цикл работы автоматики "действия компьютера чпу"
Кроме них два вспомогательных процесса
3 - контроль датчиков аварии "авария произошла"
4 - контроль кнопок "стоп" и "авария"

По идее циклы 1 и 2 должны работать как два потока, 1 главный, а 2 подчиненный
Циклы 3 и 4 работают по прерыванию в любой момент работы, по сигналу срабатывания датчиков или кнопки стоп должен выполниться штатный или аварийный останов.

Как все это корректно изобразить?

Потребуется ещё одна Дракон-схема. На обработчик прерываний.
По имеющейся схеме:

1. ветка "Аварийный останов" и "Выключить станок" никогда не вызываются. Это неправильно.

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

Дальнейшие действия зависят от того, как Вы организуете взаимодействие с системой прерываний - команды "стоп" и "авария" будут вызываться непосредственно из обработчика прерываний, или будут просто выставлены соответствующие флаги состояния с проверкой в основном цикле программы. Как-то так..

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

Ага, Вы используете поллинг. Прерывания тут никаким боком..
Нижнюю дракон-схему я разделил бы на 2 силуэта - "Система безопасности" и "Действия компьютера ЧПУ". Верхнюю схему - дополнил входом и веткой "Включение станка". В этой ветке указать запуск Ваших параллельных процессов "Система безопасности" и "Действия компьютера ЧПУ" с помощью икон "Параллельный процесс". Выход ветки, по всей видимости - на "Диалог с оператором". Ну и внести исправления в верхнюю схему, о которых я говорил выше.

p.s: Что касается прерываний - на Драконе можно сделать обработчик. А по схеме программы использовать разрешение/запрещение прерываний.

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

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

А разве нельзя использовать для отображения передачи сигнала (сообщения) иконы входа - выхода?

Можно. Как один из вариантов организации межпроцессного взаимодействия. Которое в рассмотренных вариантах пока никак не организовано.

Это как раз тот случай, когда использование только одной, предметной, области не позволяет полностью спроектировать систему. Необходимы некоторые специфические моменты из области построения вычислительных систем. Может быть, "программирование без программистов" несколько преждевременно?

Что скажут уважаемые коллеги по поводу приведённых вариантов? Содержат ли схемы достаточно полную информацию для реализации? И остаётся ли для программиста некоторая свобода использования различных "механизмов" в рамках заданной архитектуры? Как Вы считаете?

Алгоритм "Часы-сигнализатор с низким потреблением, мелодией и представлением"
а. после выполнения ветки "начало" устройство переходит в режим пониженного потребления.
6. в хх:00 паралельно выполняются алгоритмы 2-х веток "мелодия" и "сцена".
в. в хх:30 выполняется алгоритм в ветке "мелодия".
г. после завершения пп. "б" и "в" устройство вновь переходит в режим пониженного потребления.

ОШИБКИ: Не найдено.
ОГРАНИЧЕНИЯ:
а. время выполнения каждой из веток "мелодия" и "сцена" не должно превышать 30 минут.

Алгоритм "Часы-индикатор с мелодией и представлением"
а. после выполнения ветки "начало" последовательно повторяется алгоритм ветки "работать" для реализации динамической индикации на дисплее.
6. в хх:00, по окончании алгоритма ветки "работать", начинают паралельно выполняться алгоритмы сразу 3-х веток "работать", "мелодия" и "сцена".
в. в хх:30, по окончании алгоритма ветки "работать", начинают паралельно выполняться алгоритмы сразу 2-х веток "работать" и "мелодия".
г. текущее время обновляется периодически, по срабатыванию таймера - 1 раз в минуту.

ОШИБКИ:
а. поскольку время выполнения ветви "работать" меньше периода таймера(1 мин.), то алгоритм за 1 минуту будет запускать в хх:00 "мелодию" со "сценой" и в хх:30 "мелодию" несколько раз подряд.
ОГРАНИЧЕНИЯ:
а. время выполнения каждой из веток "мелодия" и "сцена" не должно превышать 30 минут.

Порекомендую найти и прочитать книгу Бара "Язык Ada в проектировании систем" (1986). Там замечательно рассмотрены самые разные проектные схемы с параллелизмом. И визуальная проектная нотация тоже вводится.

Просто интересно будет всем, по теме.

Есть электронно, если никто не найдёт - вечером могу выложить.

по содержанию:
основной недостаток Бар'овской нотации - тот же, что и у всяких YAWL'ов и COSA'в - при лавинообразном увеличении сложности описываемых взаимодействий существенно падает эффективность используемых методов управления сложностью отображения этих описаний.
Что в итоге и не позволит пересечь ту самую границу между кустарным и промышленным производством ПО. Разумеется, это всего лишь частное мнение.

по сути:
Никто и не возражает, что удобство проектирования как раз в том, чтобы проектировать соответствующие части системы в естественных для них областях. Но при этом важно иметь полное и взаимно-однозначное соответствие моделей, рассматриваемых в этих областях. И инструмент проектирования должен обеспечивать это. Если же модели на каком-то этапе начнут использоваться во взаимно-дополняющем режиме - такой инструмент даже и рассматривать не стОит.

Я вообще не за Баровскую нотацию. Это - рисунки (а не структуры со строгой компоновкой), отсюда все их недостатки (субъективно для меня - не читаются они ).

Речь о том, что у Бара отлично рассмотрены схемы параллельных архитектур и проектирования в терминах параллельных (распределённых) задач (привет мейнстрим-ООП-шникам ). Более поздних аналогов по ясности и глубине не встречал, что не удивительно, в связи с временной вынужденной деградацией в 90-х модели программирования на ПК до БД-центричной, однопоточной, примитивно-клиент-серверной...

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

Наверное, информации достаточно, если условиться о некоторых моментах.

1. Например (см. верхнюю схему), Мелодия и Сцена (это же параллельные процессы ?) никак не выделены визуально. Хотя это не принципиально. Достаточно условиться о том, что переход по адресу «* мелодия * сцена» будет генерировать вызов и Мелодии и Сцены.

2. Мелодия и Сцена, в общем случае, имеют разную длительность. Соответственно, переход с адресов «Спать» на ветку «Спать» будет происходить в разное время, поэтому нужно условиться, что если один процесс передал управление ветке «Спать», то второй просто оканчивается.

3. Что выражают три чёрных квадрата в иконе Имя Ветки «Спать» ?

4. Поскольку процессы Мелодия и Сцена параллельные, то, наверное, нужно не передавать им управление, а запускать их. Соответственно, адрес «мелодия» должен иметь чёрную полосу внизу.

5. Таймер упомянут, но сам не показан. А ведь он фактически ещё один параллельный процесс. Если таймер реализован в железе, то его можно и не показывать, а если программный, да ещё нагружен некоторыми действиями, то его имеет смысл показать в отдельной ветке.

6. Если прерывание по таймеру показано специальным значком, то логично и завершение прерывания показать аналогичным значком.

Ниже я попробовал представить свой вариант.

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

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

Эдуард, спасибо за предметный анализ и примеры. Теперь по пунктам:

1."мелодия" и "сцена" - просто независимые ветви алгоритма. "Достаточно условиться.." - так оно и есть. Список веток, размещённый в "Адресе" как раз означает передачу управления на указанные ветки.
Поэтому в Ваших вариантах кажется излишним символ ГОСТ на вход/выход с петли силуэта. Я сомневаюсь, что Ваша верхняя схема будет играть просто мелодию, без представления, в хх:30. Эта схема вызывает трудности с однозначной трактовкой вызова ветвей, присоединённых к символу "параллельные действия". Вдобавок, по Дракону, вход в петлю силуэта возможен только через "Адрес", а выход - из петли - через "Ветку". Но, тем не менее, Вы нашли принципиальное ограничение для использования символа ГОСТ "параллельные действия" в силуэте(даже если присоединить его к петле силуэта строго по Дракону, с описанием таких часов будут сложности).
Напомню, что идея представления параллельных процессов в силуэте состояла в том, что вся информация о передаче управления уже содержится в соответствующих иконах "Адрес", а приём управления содержится в иконе "Ветка". Визуализация же идеи происходит по упрощенной схеме - по принципу пиктограмм на "Адресе" и "Ветке", с возможностью их последующей алгоритмической расшифровки. У Вас же получается, как минимум, дублирование по передаче управления, а в верхней схеме ещё и некоторая неоднозначность.
Дополнительно, см. ответ по п.4.

2.это отражено в моём первом варианте часов(с веткой "спать"). Ветка "спать" предусматривает на входе ожидание передачи управления с группы ссылающихся на неё адресов(см. ответ на п.3).

3.это не отдельные квадраты, а полоска, похожая на Ваше предложение - "Дождаться нескольких из..". Смысл отражён в комментарии к ветке "спать". Т.е. вход в эту ветку более сложный, нежели простое ожидание передачи управления со всех адресов, ссылающихся на неё. Подразумевается, что алгоритмическая расшифровка этого может быть выполнена на отдельной Дракон-схеме в ходе последующего (уточняющего!) проектирования.

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

5.Таймер - аппаратный. Переделать схемы под программный таймер ничто не мешает.

6.такой значок не требуется, т.к. получается излишнее дублирование списка со входа ветки. Гораздо удобнее и эргономичнее просто указать нужный "адрес", либо использовать одно из завершений, показанных в нотации. Наверное, на этом уровне даже само понятие "прерывание" вводить нецелесообразно. Работаем ведь с ситуациями. Логичнее будет назвать ловушку "сработал таймер".

А как же тогда быть с веткой "работать"?
1. В "хх:00" она запускается одновременно и выполняется параллельно с выполнением "мелодия" и "сцена", потом циклически перезапускается.
2. В "хх:30" она запускается одновременно и выполняется параллельно с выполнением "мелодия", потом циклически перезапускается.

Иначе на какое-то время перестанет обновляться дисплей..

Значит ли это, что любая ветвь алгоритма есть независимый процесс (на основании того, что все они визуально одинаково прикреплены к петле силуэта)? Или независимость определяется соответствующей иконой адреса? Если справедливо последнее, то теряется эргономичность, имхо, поскольку веток много и глаза начинают блудить в поисках независимых веток. Адрес сказал, что есть независимые ветки, а глаза их не видят, раз они одинаково крепятся к петле силуэта. Приходится читать текст. Результат — тормоза в восприятии.

Я бы предложил трактовать этот символ (см. мой нижний рисунок) не в ГОСТовском понимании, а в смысле визуализации места крепления к петле силуэта ветки с независимым процессом. И только. А визуализацию передачи и приёма управления оставить соответствующим «Адресу» и «Ветке», как Вы и писали. Уточню, что я говорю о символах на моём нижнем рисунке под буквой В. Из такого символа может выходить только одна ветка, как и входить в него.

Может быть здесь был бы уместен вариант «Дождаться любого из...»?

Согласен.

Согласен.

Допустим имеем ветку «Работать» зацикленную саму на себя. Ловушка «Сработал таймер» прерывает работу ветки «Работать», что-то делает и передаёт управление опять в ту же точку ветки «Работать», в которой произошло прерывание.

Если из ловушки уходить по иконе «Адрес», то в соответствии с правилами Дракона управление должно быть передано на икону «Имя ветки» (т. е. в начало процесса), что неправильно. Управление должно быть передано куда-то в середину ветки (понятно, что это может быть и начало и конец ветки). Соответственно, раз ветка со значком ловушки получает управление из середины некоторого процесса, то логично чтобы и возврат в то же самое место выделялся аналогично.

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

Хорошо бы ещё как-то визуально отделять силуэт алгоритма от силуэта управления.

Параллельные линии слева это попытка отделить силуэт управления от силуэта алгоритма.

У меня начинает складываться ощущение, что для описания бизнес-процессов силуэт не очень подходит. Он прячет (визуально) потоки управления и приходится тратить дополнительные усилия для их выявления. Господа бизнесмены (особенно не знающие программирования) не склонны тратить дополнительные усилия : ) А хотелось бы систему, которой мог бы пользоваться любой менеджер и которая позволяла бы создать программную модель бизнес-процессов на предприятии.

Смутно подозреваю, что может помочь некий гибрид примитива с силуэтом : ))) Но могу и ошибаться : )

Мда, кривой из меня объяснятор. Каждое объяснение вызывает больше вопросов, чем было .

1. Ветвь - это, по В.Д.Паронджанову, смысловая часть алгоритма. Я неосторожно применил слово "независимые". На ветвь не накладываются никакие зависимости или независимости из-за указания имени ветви в иконах "Адрес". Содержание иконы "Адрес" говорит о том, происходит ветвление маршрутов(есть списов имен веток - "вода по трубам-маршрутам течёт ко всем указанным веткам сразу") или нет(указано имя одной ветки - "только одна труба идёт от этого адреса к указанной ветке"). Читать текст в адресах приходится и в классическом силуэте. За эту плату мы получаем изображение сложного алгоритма в виде визуально непересекающихся ветвей, т.е. уходим от примитива, который не получилось нарисовать без пересечений.

Считать ли ветвь процессом? Не знаю, как Вам, но мне кажется, что терминология Дракона в этом случае выигрывает. А иначе придётся вводить правила, когда ветвь - это процесс, а когда нет. Лучше не усложнять простые вещи.

Нелогично:
а. лишнее дублирование имени ветки, в которую возвращаемся
б. неоднозначная трактовка, если ловушка более, чем для одной ветви
в. отсутствует прямое указание на завершение алгоритма обработки прерывания - маршрут к иконе "Конец"

Не прячет, а концентрирует разветвления и слияния потока управления на границе силуэта в виде пригодном и для моделирования, и для редактирования.