DRAKON.SU

< от Ильченко Эдуард:
Ну вот, опять ненужная дискриминация.

Что мешает рисовать бесконечные примитивы? – например,

• Или параллельным действием замкнуть цепь алгоритма, и, затем, удалить икону [Конец].
• Или преобразованием бесконечного силуэта в примитив.

==

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

--

Теоретически, циклические алгоритмы могут быть не только "бесконечными", но и "безначальными"…
Но на практике с такой необходимостью пока не столкнулся )

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

Обычно, через параллельную логику алгоритмом управляют потоки данных


Бесконечным назовём цикл, в котором невозможно заранее указать момент выхода. Цикл будет выполняться бесконечно, если бы… не произошли некоторые события (например, нажатие виртуальной кнопки [завершить работу Windows]).

PS: Даже если событийный выход из бесконечного цикла не обозначен, событие [Удар кувалдой по системному блоку] наверняка прекратит "бесконечную" работу этой операционной системы.

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



Вот это тоже - то что надо:
Два в данном случае (или более) независимых параллельных (друг другу во времени) циклических процесса,
заданных в (условно) бесконечном цикле - без явного выхода из своих циклов.



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



В принципе да - можно подвесить конечный терминатор на (условном) выходе (который никогда не сработает).
Но это пока только интуитивное представление.
Желательно его как-то логически обосновать (об это тоже позднее).

============================
И еще.
Уважаемый LKom вполне справедливо пишет

Вот с этим странностями в параллельном программировании (и в параллельной алгоритмике) нужно четко разобраться:
с их физическим смыслом.
Что бы потом у детишек в параллельной образовательной робототехнике крыша не поехала.

-------------------
Здесь еще есть одна заковыка:

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

Тем более, что в проектировании, например:
1) Вычислительная или технологическая система как объект проектирования:
здесь вычислительный или технологический объект - это объект проектирования.
Вроде бы нет неясностей: объект - это объект
(хотя, строго говоря, термин "объект" слева и справа используется в разных смыслах).
2) Вычислительный или технологический процесс как объект проектирования.
Здесь опять появляется: процесс - это объект.

Это все очень хорошие головоломки для наших детишек в параллельной образовательной робототехнике.

====================
Продолжение следует.

Странные рисунки - это схемы с бесконечным циклом:
http://forum.oberoncore.ru/viewtopic.php?p=94232#p94232
Это простое управление периодическими процессами:
есть вход в цикл и нет никаких выходов из цикла.
Его легко реализовать, например, простым оператором goto в конце цикла с меткой перехода в начале цикла:

m:
тело цикла
goto m

Такое управление циклами довольно широко применяется.
Но зачем нужны такие "ашипки" с зацикливанием исполнения алгоритма (программы)?

В Википедии в статье "Бесконечный цикл"
[url]https://ru.wikipedia.org/wiki/Бесконечный_цикл[/url]
приводятся немного странные в некоторых отношениях аргументы

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

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

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

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

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

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

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

Продолжение следует.

http://forum.oberoncore.ru/viewtopic.php?p=94232#p94232





Сомнительная новация Эдуарда Ильченко, в которой нет необходимости.
Повторю слова andr - "брызги фантазии - в поисковом порядке для полноты теоретических ощущений".

Согласно Дракона, делается гораздо проще, логичней и наглядней.

Именно в поисковом порядке.
Мы подвисли на схемном алгоритмическом описании первой же простой детской параллельной программы из сборника в среде Scratgh.
Идет мозговой штурм - с брызками фантазии.
У Эдуарда появился неожиданный пример:
в принципе, видимо, допустимо, но до сих пор есть информация к размышлению.
А если у Вас появился более продвинутый вариант примера - так в этом и есть смысл этой работы на форуме.

Давайте посмотрим, что получается:

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

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

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



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

andr,
у Вас много написано, поясню то, что в конце:


На первой схеме имеется 4 параллельных действия: иконы Действие А и Г и иконы ПараллельныйПроцесс Б и В.
Из верхней линии === одновременно запускаются на выполнение иконы А, Б, В и Г.
На нижнюю линию === управление будет передано из икон А и Г после завершения в них действий, из икон Б и В после запуска процессов схем Б и В. При этом не будет производится ожидание завершения процессов схем Б и В, т.к. икона ПараллельныйПроцесс по команде Пуск запускает внешний процесс и сразу возвращает управление.
Следовательно икона Конец получить управление.

Соответственно схемы Эдуарда Ильченко и LKom функционально эквивалентны, Дракону соответствуют схемы LKom.

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

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

Когда пришлось поработать с учениками ПТУ в курсах информатики и автоматизации производства,
там и в голову не приходило популярничать с параллельными алгоритмами:
параллелили простые, но реальные вычислительные и технические задачи
(упрощенные модели типа мнемосхем объектов автоматизации, отражающие необходимую суть).

Для приложения дракон-концепции к теории параллельных алгоритмов
необходимо краткая справочная сводка по дракон-системе.
За основу можно принять ЯЗЫК ДРАКОН. КРАТКОЕ ОПИСАНИЕ

Но необходимо сходу вводить параллельные алгоритмы и только, в частности, последовательные алгоритмы
(такие прикидки уже прорабатываются - в ориентации, в частности, на Фабулу).

Вот и первая детская задача в Scratch-e, рассматриваемая выше (по качелям и качалкам) - параллельная по своей природе:
это не случайно - это реальная окружающая нас параллельная действительность.

--------------------------------------------------
Все это - по поводу указанной в начале поста рекомендации "Читать ...":
применительно к обсуждаемым параллельностям.

=======================

Я понял свою промашку, уважаемый LKom.
Я просто элементарно забыл смысл этих графических знаков (икон) вызова параллельных процессов.
Мы их уже обсуждали на другой теме:
http://forum.oberoncore.ru/viewtopic.php?p=93615#p93615
и далее
http://forum.oberoncore.ru/viewtopic.php?p=93618#p93618

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

=====================
А в целом в предыдущем моем посте
http://forum.oberoncore.ru/viewtopic.php?p=94262#p94262
у меня немного невпопад вашим схемам, уважаемый LKom,
но сгенерился некоторый синтаксис (и немного алгебры) работы с бесконечными циклами.
Далее приводятся ориентировочные (черновые) прикидки:

1
Ai = ->Ai-> = -Ai-
обозначение обычных (двухполюсных) алгоритмов - с одним входом и выходом по потоку управления.
Внешние связи -> = - можно навешивать и удалять одновременно или по отдельности:
Ai = -Ai = Ai- = -Ai-

2
Ai* = -Ai*
обозначение бесконечного цикла - некоторого алгоритма Ak, включенного в бесконечный цикл;
всегда есть вход.

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

4
Ai1* || Ai2* = Ai* = -Ai*-
допустимо параллельное соединение двух (или более) бесконечных циклов:
объединить параллельно по входам и фиктивным выходам.
Это расширение исходных структурных определений.
Получается новый (составной) двухполюсник (с составляющими параллельными б/к циклами)
и с фиктивным общим выходом.

5
Ai-Aj*
допустимо последовательное подключение б/к цикла (условно) справа.
Это также расширение исходных структурных определений

6
Ai*-Aj = Ai*
допустимо последовательное подключение б/к цикла (условно) слева.
Это также расширение исходных структурных определений.
При этом хвост Aj можно удалить - он никогда не заработает.

7
Ai*-Aj* = Ai*
допустимо последовательное подключение 2-х б/к циклов.
Это также расширение исходных структурных определений.
При этом хвост Aj* можно удалить - второй б/к цикл никогда не заработает.

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

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

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

Теперь можно добивать вопрос с б/к циклами - и вернуться к нашим детишкам:
чтобы более или менее грамотно разбираться, что они там накорябали в Scratch-е
(to scratch - корябать).

Проблемная задача проф-ориентации дракон-концепции

Эта проблема связана со следующими обстоятельствами.

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

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

3
Кроме того, маячит и бытовая робототехника
(связанная в определенной мере с образовательной робототехникой):
для всех возрастных групп - вплоть пенсионных возрастов
(но это пока очень очень расплывчатая перспектива).

5
Это все необходимо реализовать с учетом возрастной специфики,
но в рамках профориентации и взаправду - без детского сюсюкания.

Это вполне реально и есть некоторый практический опыт:
-- с младшими студентами и старше (вплоть 5-х курсов):
это почти всю жизнь (начиная с 70-х гг. - по совместительству)
-- в ПТУ (соответствует 9-м классам 11-летней средней школы):
в конце перестройки (пока не начало разваливаться производство).

6
В частности, ставится задача и начинает осваиваться теоретико-алгоритмический анализ
реальной параллельной алгоритмики
в области массового компьютерного и робототехнического творчества:
-- начиная с анализа гениальных детских каракулей - типа качелей:

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


7
Ключевым первоочередными инструментальным средством принимается блок-схемный редактор Фабула:
опытное освоение - реально уже начинается.
Первоочередное освоение именно Фабулы - это по разным случайным обстоятельствам.

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

=========================
8
Все это очень хорошо (как прекрасное далёко).
Однако в реальности начинают появляться разные осложнения.

8.1
В частности, на первом же простейшем детском примере (анализ качелей)
благие изложенные намерения закувыркались - начиная с поста
http://forum.oberoncore.ru/viewtopic.php?p=94211#p94211
и далее.
Это частное проявление первичной базисной задачи ключевой значимости.
Но все это вполне нормально - решается в рабочем порядке:
-- кое-что уже прояснилось (общими усилиями посетителей этой темы);
-- и далее автору этого поста уже в принципе ясно:
как ее (эту задачу) добить, углУбить, обобщить и т.п.

8.2
Однако выявляются следующие более проблемные вопросы.

8.2.1


8.2.2
Предполагается подготовить серию статей по применению системы Дракон+Фабула,
ориентированных на специалистов в области автоматизированных и роботизированных систем.
И здесь появляются такие обстоятельства:

1)
Проблемные ссылки на базовую авторскую дракон-литературу с названиями:

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

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

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

2) Далее перечисляются первые примеры конкретных алгоритмов - на их основе излагается дракон-концепция:
Рыбная ловля.
Сборы на рыбалку.
В гостях у льва.
История с супом.
История с деньгами.
Поездка на автобусе.
История с чернильницей.
История с мотоциклистом.
История с кашей.
И т.д.

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

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

3) По своим наименованиям и по содержанию эта литература имеет поучительную направленность:
научить читателя правильно мыслить, улучшить работу ума и т.п.
Это актуально для общей популяризации.

Но учить уму-разуму квалифицированных специалистов - это совершенно неуместно.
Например, молодые заносчивые ребята начинают обследовать производство как объект автоматизации.
Там, естественно, много проблем, и соответственно:
"У вас здесь все плохо и все не так, и мы вас всех научим".

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

============================
Такие проблемы, по-видимому, имеют место и в медицинских (и других) профессиональных алгоритмических приложениях.
Если это так, то это, очевидно, на будет способствовать.

Решения проблемной задачи
(в технических и других проф-приложениях)

Появляются некоторые предварительные соображения по развязке появившихся проблемных обстоятельств.

1
Разделение (прикладной) дракон-концепции + Фабула (или другие схемные редакторы)
на два (или более) уровня изложения - по аналогии с первичным курсом (образовательной) информатики (1985 г. и далее):

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

По примерной аналогии со школьным учебником ОИВТ:
часть 1 (включая алгоритмику), часть 2 (включая программирование).
А.П. Ершов, В.М. Монахов, С.А. Бешенков.
Основы информатики и вычислительной техники:
Проблемное учебное пособие для сред. учеб. заведений. В 2-х ч. Ч. 1.
- М.: Просвещение, 1985. - 96 с.

1.2
Служебный уровень изложения - методологическое, методическое обеспечение первого уровня и т.п.

По примерной аналогии с методическим обеспечением указанного учебного курса.
А.П. Ершов, В.М. Монахов, С.А. Бешенков.
Изучение основ информатики и вычислительной техники.
Методическое пособие для учителей и преподавателей сред. учеб. заведений. В 2-х ч. Ч. 1.
- М.: Просвещение, 1985. - 191 с.
(в два раза толще - хороший ориентирующий показатель).

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

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

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

Но пока не ясно куда вынести агитацию и пропаганду (вне рабочего первого уровня).
Это может быть, наверное, учебное пособие для обучаемых контингентов.
То есть 2-й уровень расщепляется по направлениям (для обучающих и обучаемых).

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

Нашел свою старую алгоритмическую документацию 1987 г. и 1973 г.
Несколько листов разных форматов - А3, А2, А1 и описания.
Подклеил кое-какие листы, надо будет их сканировать целиком.
Нашел фрагмент типа силуэта (условно силуэт):


Это конечно не по правилам оформления дракон-силуэтов (1987 г.).
Но есть объект для анализа в силуэт-концепции.

Это аванпроектная разработка предпроектной стадии (к разработке технического задания):
гибкая автоматическая линия для обработки втулок весом в диапазоне 20-120 кг (по памяти).
4 металлорежущих станка расположены в ряд - с промежуточными накопителями.
Обслуживаются двумя портальными мобильными обслуживающими промышленными роботами:
ездят сверху по общему монорельсу.
Выше приводится общая блок-схема алгоритма одного робота - для второго аналогично.

Это алгоритм с циклическим просмотром общей ситуации на линии
и обслуживания обнаруженных запросов:
загрузка деталей на станки из накопителей и разгрузка станков
в накопители (если очередной станок занят) или на свободный очередной станок.

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

Есть хорошая алгоритмическая задача на асинхронные конвейерные алгоритмы:
(причем пара взаимодействующих конвейерных алгоритмов).
Надо бы прикинуть модельные программы в средах Scratch и V-REP.
С оформлением схемы в системе Дракон+Фабула:
с явным и неявным применением принципов силуэта.
И поэкспериментироваться с разными данными.
Надо бы одного-двух студентов - есть доступная работенка
(немного припоздал, но надо будет попробовать подсуетиться).

Овальные терминаторы алгоритмов

Это к вопросу о применении или не применении
и о (физическом) смысле овальных терминаторов.

В посте о технологических алгоритмах маршрутных технологий
обсуждаются разные виды схем алгоритмов - без оконечных овалов.
http://forum.oberoncore.ru/viewtopic.php?p=94733#p94733

На это есть свои технологические причины.
В алгоритмах операционных карт ситуация может быть иная.

------------------
Есть задача из области алгоритмов группового управления.
В данном простейшем случае - групповое управление двумя независимыми объектами.




-------------------------
Блок-схема группового алгоритма выполнена встроенным графическим редактором Word.

Появляется следующий практический вопрос.
Есть ли возможность строить такие групповые алгоритмы
в графических средах поддержки Дракон-концепции:
-- ИС Дракон?
-- DRAKON Editor?
-- Фабула?

В Фабуле - нет.

Можно:

Разместите действия отдельных алгоритмов в ПараллельныхДействиях.
К каждому действию отдельных алгоритмов подключите СинхронизаторПоТаймеру.
В общей части установите Таймер.

При выполнении группового алгоритма будет запущен Таймер, общий для отдельных алгоритмов.
Действия в отдельных алгоритмах будут запускаться СинхронизаторамиПоТаймеру, после установленных интервалов времени.
Таким образом все действия в групповом алгоритме будут синхронизированы общим Таймером.

andr,

Терминаторы не являются овалами, в строгом смысле термина - овал.
Скорее, являются закругленными прямоугольниками.

См. https://ru.wikipedia.org/wiki/Овал

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

Это в строгом смысле?

Александр Ильин, утомил.
У Вас, "это" не понятно что, есть хорошая рекомендация - вещи называть своими именами.
Прочитайте название темы.

Коротко и ясно - поскольку в исходной дракон-концепции это не предполагается.

Но желательно было бы приспособить ее для беспроблемного теоретико-алгоритмического применения:
параллельные и, в частности, последовательные алгоритмы - в технических и технологических приложениях.

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

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

Предлагается деловая игра:
(потенциальный) заказчик - (потенциальный) разработчик.

1
Вся теория параллельных (и последовательных) алгоритмов
начинается с групповых алгоритмов управления (стационарными или мобильными) объектами типа:
Ai = (Ai1, Ai2, ..., AiN).

От них производятся прочие алгоритмы, например - навешивание структурных операций:
->(A1, A2) = (A1->A1) - последовательный алгоритм;
||(A1, A2) = (A1 || A2) - параллельный алгоритм.

Вопросы:
1)
Почему в Фабуле сейчас нельзя построить блок-схемы первичных групповых алгоритмов типа:
http://forum.oberoncore.ru/viewtopic.php?p=94762#p94762.
Конкретные причины - для ясности со стороны (если это не секрет фирмы).
2)
Возможно ли в принципе выйти на них - в рамках существующей системы?

2
За одно (аппетит приходит во время игры):
Те же вопросы по поводу первичных последовательных технологических алгоритмов маршрутной технологии:
http://forum.oberoncore.ru/viewtopic.php?p=94733#p94733

3
И, в частности, по поводу технологических блок-схем типа:
http://forum.oberoncore.ru/viewtopic.php?p=94723#p94723

Все это нужно для полноты теоретического и прикладного счастья пользователя дракон-услуг.

------------------------------------

Большое спасибо, уважаемый LKom.
Вопрос принимается на проработку - по мере возможности.
Там кажется просматривается автоматизация построения каких-то временных диаграмм?:
"Действия в отдельных алгоритмах будут запускаться СинхронизаторамиПоТаймеру, после установленных интервалов времени".
Это тем более перспективно.

-------------------------

Критика принимается.
Надо будет выражаться внимательнее.

Но, к стати говоря, овалы применяются в качестве терминаторов алгоритмов,
если в наборе фигур графического редактора нет УГО типа "терминатор" блок-схем алгоритмов.

-----------------------


Полезная терминологическая перепалка.
Вообще в блок-схемном наборе УГО есть:
1)
Прямоугольник со скругленными углами - используется, например, для обозначения состояний:
-- состояния обычно обозначаются кругами, но круг - не технологичная фигура для вставки надписей;
-- вместо кругов используются скругленные оп углам прямоугольники.
2)
Овало-подобное УГО терминаторов - с полуокружностями по сторонам.
Для терминаторов блок-схем алгоритмов желательно было бы подобрать
геометрически точный термин, желательно одним словом
(как овальный терминатор - но поточнее).