DRAKON.SU

Спасибо, Степан Борисович

Предлагаю последнюю редакцию для "Макроиконы языка ДРАКОН"

Геннадий Тышов опубликовал замечания: Полезное замечание. Спасибо. Учту. Внесу изменения в английский текст.

Здесь мне преимущества не очевидны.

Какой недостаток?

ДРАКОН создан для того, чтобы ЗАМЕНИТЬ этот давно устаревший стандарт.

Выкладываю рисунок 18 (Fig. 18) содержащий Макроиконы.
Рисунок исправлен в соответствии с замечанием Геннадия Тышова.

Геннадий Николаевич, спасибо за подсказку.

Владимир Даниэлович, здравствуйте.

Меня на премодерацию поставили, теперь пытаюсь публиковать свои посты в виде цитат. То есть, разрешаю это править и публиковать.

--

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

Читать надо здесь
http://drakon.su/knigi_vladimira_parondzhanova._skachat

Особенно здесь см. глава 13 и 14
http://drakon.su/_media/biblioteka_1/01 ... linnik.pdf

Это неверно.
Вставка (подпрограмма) не может разорвать шампур. Вызов подпрограммы приостанавливает выполнение основной программы, это верно. Но шампур тут ни при чем.

Надо сначала почитать, азы надо знать.

Уважаемые коллеги!

Выкладываю последний и окончательный вариант ИКОН и МАКРОИКОН
предназначенный для издания моей книги на английском языке.

Представленный вариант получен по результатам обсуждения
на этом форуме в период 2008—2015 годы.

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

Представленный вариант (состоящий из 28 икон и 22 макроикон)
был бы невозможен без Ваших советов и критических замечаний.
Еще раз, большое спасибо.

ИКОНЫ


МАКРОИКОНЫ

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


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

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

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

2. В отношении отображения параллелизма.

Есть вопросы:

1) Почему начало параллельного участка (п. 27) отображается двойной поперечной линией,
а конец параллельного участка (п. 28) отображается одинарной поперечной линией?.
Здесь есть какая-то осмысленная аргументация?
Она где-то обсуждалась и отфиксировалась?

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

--------------------------------------------
Далее приводятся примеры схем с "с хвостами" - какие могут быть по ним возражения?

Представлен алгоритм пошаговых вычислений по формуле:
y = Sin(x1 + x2) * Cos(x1 +x2).

Параллелизм отражается (примерно) "по Госту 19.701—90 и по ISO 5807-1985".
Это вертикальное (программно-ориентированное) исполнения
с парными поперечными линиями на входе и на выходе параллельного участка.
Чем это плохо?


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


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


Явная простановка логики узловых элементов - параллельная конъюнкция:
# = R: узел вилки - репитер - множественный повторитель;
o = &: узел сборки - конъюнктор (логическая операция И, And):
контроль окончания всех параллельных потоков,
срабатывание по последнему во времени событию окончания параллельных потоков.

Возможна параллельная дизъюнкция:
полностью аналогичная схема с заменой узла сборки по конъюнкции o = &
на узел сборки по дизъюнкции (Или, Or) o = V.


Подтверждение пользы поперечных "хвостов" (усов).

2 Владимир Паронджанов

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

С чем связаны изменения?

А так красивше : )

Что-то было здесь.

Вернемся к нашим concurrent process - параллельным процессам:
кому это интересно - копаться в изначальных смыслах терминологии.

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

Если "мы" выдвигаем книгу Дракона с параллелизмами на издание на английском языке (в логове параллелизма),
то, наверное, полезно более или менее разобраться с ними хотя бы промежду собой.

-------------------------------------------------
1. Вопрос на засыпку №1:
что значит геометрическая метафора (аналогия) "параллельные" для процессов (???-01).

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

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

В алгоритмике и программировании параллельные процессы отображаются
параллельными отрезками прямых линий на временных диаграммах разных типов.
Например:

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

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

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

--------------------------------------------------
Вопрос на засыпку № 2:
что значит английский термин "concurrent" для процессов (???-02).

Термин "current" означает: текущий - протекающий в пространстве или происходящий в настоящее время (это прилагательное),
а также - поток, струя и т.п. (существительное).

Термин "concurrent" означает одновременный, параллельный (во времени).
То есть - это, примерно как, процесс , совместно (con...) протекающий (...current) во времени, одновременно выполняемый:
процесс, выполняемый одновременно с некоторым другими процессами.

Термин "concurrent" для процессов - это первичный и более точный по смыслу, чем термин "parallel".

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

То есть основной смысл параллелизма процессов - это их одновременность .
А точнее - это их совмещение во времени.
А еще точнее - это пресечение интервалов времени их выполнения.

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

---------------------------------------
Параллельные процессы могут быть:

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

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

Вы правы. Прямые углы заменены на скругленные.

Почему? Причин несколько

1. Чтобы показать "Исполнителя" или его аналоги.
download/file.php?id=2757&mode=view
См пример здесь

2. Ввести правило: "Икона, присоединяемая справа, имеет особую форму, отличную от иконы "действие" — прямоугольник с закругленными углами.

3. Ввести единое обозначение для формальных параметров и исполнителей

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

Я исхожу из того, что слово "исполнитель" надо переводить на английский как actor.

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

Проблему исполнителя — actor я считаю открытой в том смысле, что исполнителя можно показывать двумя разными графическими средствами:

— прямоугольник со скругленными краями, присоединяемый справа;

— на верхнем этаже иконы "полка".

Просмотрел. Не понравилось!
— Треугольником обозначать слияние параллельных потоков – это тройная ошибка:

1) нет возможности обозначить логику такого слияния
2) отсутствует инверсный выход (на случай, если нужно обработать отрицательный результат (от противного).
3) появился новый элемент: треугольник. А ведь достаточно было всё той же иконки: Проверка условия (развилка).

Вот, здесь Вы почти правильно нарисовали. На том рисунке метками можно было бы обозначить дополнительные потоки, входящие в логический элемент. Но меток в ДРАКОНе пока нет….

--

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

• Параллельный процесс это: «А чёрт его знает, кто его запустил! Может быть, я? Не помню!»
• Параллельные действия – это начало параллельных процессов (синхронно активируются из одного потока)

Управление параллельным процессом осуществляется при помощи меток, активируемых извне (из других алгоритмов или из родительских программ). Метки активируют параллельные потоки, которые сходятся в логических элементах (или в логических силуэтах).
Это управление осуществляется из стороннего алгоритма, при помощи параллельных действий (и при помощи ссылок на метку).

В продолжение начатого разговора по Cocurret prosess (параллельные процессы).
Есть персональный интерес - в разных отношениях.
В частности - с позиции потенциального заказчика графической алгоритмической системы:
в приложении к Образовательной робототехнике (ОРТ), в частности.

------------------------------------------
На схеме надо поменять местами аббревиатуры блоков:
ВСн (Вычислить синус) и ВКс (Вычислить косинус).
Это и у меня на моих блок-схемах - надо будет исправить в своем файле оригинала.
Но суть не в этом.

--------------------------------------------
Вспоминаются прежние труды за кульманами в разных КБ
(это было давно - в пролом веке, еще до персональных компьютеров).
Смотришь на свои чертежи - ужасно нравятся.
А смотришь у соседа - так себе.

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

Это все к чему?
А как понимать в отношении, чтобы было красивше в редакторе Дракон:
1-е), 2-е) или 3-е) или еще что-то?


Полезно обсудить визуализацию элементов типа:

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

Общая ситуация с параллельными (и последовательными) алгоритмами такая:

Выделяются 3 уровня отражения (и понимания)
логики механизмов управления параллельными (и последовательными) процессами во времени:
или логико-временная интерпретация параллельных (и последовательных) алгоритмов

Далее эти три уровни будут кратко изложения по отдельности (чтобы не перегружать сообщения)

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

3.2.1 Практическая логика здравого (интуитивного) смысла


И далее по п. 3.2.1

На этом уровне структура параллельных алгоритмов обсуждается на уровне терминов типа:
-- fork (вилка) - узел разделения (дивергенции) потоков управления;
-- join (сборка) - узел соединения (конвергенции) потоков управления.

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

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

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

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

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

1) Графическая система должна вписываться в идеологию полиморфной системы алгоритмических языков, включая:

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

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

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

-- табличные и матричные формы представления алгоритмов.

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

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

Это отголоски планов разработки подсистемы алгоритмического обеспечения для САПР робототехнологических систем.
К сожалению реальные робототехнические работы "грохнулись" где-то в 1987 г. - по понятным причинам.
Но теперь все снова вокруг оживает - и в новых формах и перспективах.
И лидирует у нас по массовости что?:
детская образовательная робототехника.

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

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

Ошибочка вышла.

Нужно, козе понятно, Concurrent processes - молотил вслепую в тексте мелким шрифтом.

Эта терминология взята из UML. Заимствованы термины, но не графические обозначения.
См. здесь

Большое спасибо - хорошая сводная схема:

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

Здесь кроме узлов fork (вилка), join (сборка) - для двухстороннего параллельного объединения,
и узла merge (слияние) есть парный ему узел desision (решатель) - для простого (бинарного) ветвления:
замкнутого альтернативного ветвления - ветвления на узле desision с замыканием на узле merge .

-------------------------------
Истолкование работы таких схем соответствует предложенному выше
1-му уровню логико-временной интерпретации:


На следующем 2-м уровне (1.2):
1.2) Явная структурная логика параллельных алгоритмов
общей системы уровней:

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

Вкратце, получается такая общая система представлений:

1) Параллельная сборка join - это сборка по конъюнкции (логической операции And, И), то есть:
join_and, join_& или просто and = & (но это нужно обосновать);
сборка_и, сборка_& или просто и = &.

2) Если есть параллельная сборка join_and, сборка_и по конъюнкции,
то должна быть и параллельная сборка join по дизъюнкции (логической операции Or, Или), то есть:
join_or, join_V или просто or = V (но это тоже нужно обосновать);
сборка_или, сборка_V или просто или = V.

3) Параллельная вилка fork - это множественный повторитель # = R.
В паре со сборкой он дает парную структурную операцию параллели (операторов) || = #o.
Традиционно это параллельная конъюнкция || = #& (типа ||_&)
Ей противопоставляет параллельная дизъюнкция || = #V (типа ||_V) .

4) Внутри узла решателя desision выявляется узел вилки fork (# = R).

5) Узел слияния merge - это не что иное как узел дизъюнкции V потоков управления:
узел сборки по дизъюнкции (Or. Или).

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

-----------------------------------------
Продолжение следует 4
(Явная структурная логика параллельных алгоритмов).

Второй уровень логико-временной алгоритмов интерпретации алгоритмов в общей системе:


------------------------------------------------------------------
Для параллельных структур алгоритмов
(базового структурного типа - последовательно-параллельные связи двухполюсников)

И далее:

И далее:

И далее:


---------------------------------------
Для последовательных структур алгоритмов.
Этот вопрос до конца не разработан.
Далее приводится следующие сведения:

И далее:

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

Маленьким кружком обозначен дизъюнктивный узел узел сборки потоков управkения
(по логической функции Или, Or) - фактически join_or:
соответствует термину merge - слияние в некоторых графических языках.

=============================
Здесь используются структурные схемы алгоритмов (ССА) типа штрих-схем (ССА = ШСА)
в данном случае - это литерная псевдографика:

-- операторы обозначаются короткими поперечными отрезками - штрихами:
соответствуют прямоугольным блокам на блок-схемах алгоритмов (ССА = БСА);

-- узлы (бинарного) альтернативного ветвления обозначаются крестиком (повернутым на 45 град.).

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

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