DRAKON.SU

Текущее время: Четверг, 28 Март, 2024 14:42

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 276 ]  На страницу Пред.  1 ... 7, 8, 9, 10, 11, 12, 13, 14  След.
Автор Сообщение
СообщениеДобавлено: Среда, 23 Январь, 2019 19:29 

Зарегистрирован: Среда, 27 Сентябрь, 2017 18:44
Сообщения: 332
LKom писал(а):
В иконах 2.9, 1.33, 1.26, 1.36 использовать идентификатор - ФЛАГ_ЦВЕТА_КРАСНЫЙ, взамен идентификаторов ФЛАГ_ЦВЕТА и ФЛАГ, т.к. значение ИСТИНА соответствует КРАСНОМУ цвету.

Где присваивается значение внутренним переменным: ДЕТЕКТОР_1, ДЕТЕКТОР_3, ДЕТЕКТОР_4 ? Визуально не видно.
Почему нумерация такая, а не 1, 2, 3?

Можно удалить иконы 1.21, 1.29, 1.37, т.к. программный код у них не предусмотрен, а значение внутренних переменных ДЕТЕКТОР_1, ДЕТЕКТОР_3, ДЕТЕКТОР_4 присваивается входу ПУСК соответствующего ТАЙМЕРА.

При "НОРМАЛЬНОМ РЕЖИМЕ" выходным переменным КРАСНЫЙ и ЗЕЛЕНЫЙ нигде не присваивается значение ЛОЖЬ.

Да действительно пропустил зеленый и красный ложь


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 23 Январь, 2019 19:41 

Зарегистрирован: Среда, 27 Сентябрь, 2017 18:44
Сообщения: 332
А_МУР писал(а):
Дмитрий Бардынин писал(а):
А_МУР писал(а):
про работу с ВВ написать ни чего не могу т.к использую свой вариант работы со временем, продиктованный спецификой ПЛК

Как бы Вы реализовали последний алгоритм светофора на ПЛК?

Вот этот
Вложение:
Снимок7.JPG


У меня получилась вот так
Вечером смогу создать код и загрузить в ПЛК проверить работоспособность схемы и ошибки


Нет сегодня явно не получается загружать в ПЛК
Других алгоритмов хватает по уши...
Попробую завтра прогрузить схему светофор..


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 23 Январь, 2019 20:18 

Зарегистрирован: Среда, 07 Январь, 2015 14:53
Сообщения: 1356
А_МУР писал(а):
В ТЗ есть описание Детектора и механизма работы, но он пока не совеошенен, я в каждой программе которую делаю совершенствую механизм применения многих икон в том числе и детектора. Пока дописываю код ручками

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

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

Скорее всего нет необходимость в "Ноу Хау".


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 24 Январь, 2019 06:28 

Зарегистрирован: Среда, 27 Сентябрь, 2017 18:44
Сообщения: 332
А_МУР писал(а):
LKom писал(а):
В иконах 2.9, 1.33, 1.26, 1.36 использовать идентификатор - ФЛАГ_ЦВЕТА_КРАСНЫЙ, взамен идентификаторов ФЛАГ_ЦВЕТА и ФЛАГ, т.к. значение ИСТИНА соответствует КРАСНОМУ цвету.

Где присваивается значение внутренним переменным: ДЕТЕКТОР_1, ДЕТЕКТОР_3, ДЕТЕКТОР_4 ? Визуально не видно.
Почему нумерация такая, а не 1, 2, 3?

Можно удалить иконы 1.21, 1.29, 1.37, т.к. программный код у них не предусмотрен, а значение внутренних переменных ДЕТЕКТОР_1, ДЕТЕКТОР_3, ДЕТЕКТОР_4 присваивается входу ПУСК соответствующего ТАЙМЕРА.

При "НОРМАЛЬНОМ РЕЖИМЕ" выходным переменным КРАСНЫЙ и ЗЕЛЕНЫЙ нигде не присваивается значение ЛОЖЬ.

Да действительно пропустил зеленый и красный ложь


Далее преведенные изменения касаются раздела ПЛК
Для удобства пользователя необходимо пересмотреть иконы относительно канонов.
Сегодня икона представляет из себя объект с одним, а то и с двумя текстовами полями.
Пиши чего хочешь и как хочешь.
При програмировании ПЛК (если мы расматриваем Дракон как конечный язык) все индификаторы вносимые в иконы строго определены в пространстве имен. Свободно пользователь может писать только в коментариях.
Необходимо что бы икона стала как чек лист. Тогда появится графический порядок.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 24 Январь, 2019 06:54 

Зарегистрирован: Среда, 27 Сентябрь, 2017 18:44
Сообщения: 332
LKom писал(а):
А_МУР писал(а):
В ТЗ есть описание Детектора и механизма работы, но он пока не совеошенен, я в каждой программе которую делаю совершенствую механизм применения многих икон в том числе и детектора. Пока дописываю код ручками

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

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

Скорее всего нет необходимость в "Ноу Хау".


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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 24 Январь, 2019 07:59 

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 5846
Откуда: Москва
А_МУР писал(а):
Сегодня икона представляет из себя объект с одним, а то и с двумя текстовыми полями.
Пиши чего хочешь и как хочешь.

При программировании ПЛК (если мы рассматриваем Дракон как конечный язык) все индификаторы, вносимые в иконы, строго определены в пространстве имен. Свободно пользователь может писать только в комментариях.

Необходимо что бы икона стала как чек лист. Тогда появится графический порядок.
Правильная мысль. Поддерживаю


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 24 Январь, 2019 08:09 

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 5846
Откуда: Москва
А_МУР писал(а):
мы упираемся в отсутствие в ИС Дракон пространства имен.
Для создания пространства имен в ИС Дракон необходимо в схеме переменных предусматривать динамический массив в котором будут сохраняться объявленные пользователем индификаторы их типы, начальные значения тип данных и т.д.

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

Если пользователь пишет в иконе программы неизвестный индификатор, которого нет в массиве пространства имен, программа ИС дракон должна предложить его объявить (опять же икона должна быть как чек-лист).
Поддерживаю.

В пространстве имен не следует использовать иконы Ввод и Вывод. Вместо них лучше использовать икону Полка


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 24 Январь, 2019 08:23 

Зарегистрирован: Среда, 27 Сентябрь, 2017 18:44
Сообщения: 332
Владимир Паронджанов писал(а):
А_МУР писал(а):
мы упираемся в отсутствие в ИС Дракон пространства имен.
Для создания пространства имен в ИС Дракон необходимо в схеме переменных предусматривать динамический массив в котором будут сохраняться объявленные пользователем индификаторы их типы, начальные значения тип данных и т.д.

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

Если пользователь пишет в иконе программы неизвестный индификатор, которого нет в массиве пространства имен, программа ИС дракон должна предложить его объявить (опять же икона должна быть как чек-лист).
Поддерживаю.

В пространстве имен не следует использовать иконы Ввод и Вывод. Вместо них лучше использовать икону Полка


не соглашусь с Вами икона ввод, икона вывод, и икона ввод-вывод имеют очень большой смысл

при формировании подпрограммы внутри другой подпрограммы мы даем понятия для среды где входы, где выходы, и в каком порядке они отображаются


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 24 Январь, 2019 08:53 

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 5846
Откуда: Москва
А_МУР писал(а):
при формировании подпрограммы внутри другой подпрограммы мы даем понятия для среды где входы, где выходы, и в каком порядке они отображаются
Вы можете это делать в любом случае.

Это никак не зависит от того, какая икона нарисована в пространстве имен: Полка или Ввод (Вывод).

Разве не так?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 24 Январь, 2019 08:57 

Зарегистрирован: Среда, 27 Сентябрь, 2017 18:44
Сообщения: 332
Владимир Паронджанов писал(а):
А_МУР писал(а):
при формировании подпрограммы внутри другой подпрограммы мы даем понятия для среды где входы, где выходы, и в каком порядке они отображаются
Вы можете это делать в любом случае.

Это никак не зависит от того, какая икона нарисована в пространстве имен: Полка или Ввод (Вывод).

Разве не так?

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 24 Январь, 2019 15:28 

Зарегистрирован: Пятница, 08 Декабрь, 2017 18:24
Сообщения: 439
Откуда: Астрахань-Сочи
А_МУР писал(а):
Владимир Паронджанов писал(а):
А_МУР писал(а):
при формировании подпрограммы внутри другой подпрограммы мы даем понятия для среды где входы, где выходы, и в каком порядке они отображаются
Вы можете это делать в любом случае.

Это никак не зависит от того, какая икона нарисована в пространстве имен: Полка или Ввод (Вывод).
Разве не так?

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


В моем генератор пространство имен частично реализовано: имена диаграмм уже содержатся в файле, и "Вставка", "Вывод" и "Ввод" сравнивает свое содержимое со списком диаграмм и разрешенных слов.

Пришел к мысли, что не плохо бы и переменные сравнивать, дабы опечатки не портили сборку.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 24 Январь, 2019 15:41 

Зарегистрирован: Среда, 27 Сентябрь, 2017 18:44
Сообщения: 332
Цитата:
В моем генератор пространство имен частично реализовано: имена диаграмм уже содержатся в файле, и "Вставка", "Вывод" и "Ввод" сравнивает свое содержимое со списком диаграмм и разрешенных слов.

Пришел к мысли, что не плохо бы и переменные сравнивать, дабы опечатки не портили сборку.

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 24 Январь, 2019 15:51 

Зарегистрирован: Среда, 27 Сентябрь, 2017 18:44
Сообщения: 332
Дмитрий Бардынин писал(а):

В моем генератор пространство имен частично реализовано: имена диаграмм уже содержатся в файле, и "Вставка", "Вывод" и "Ввод" сравнивает свое содержимое со списком диаграмм и разрешенных слов.

Пришел к мысли, что не плохо бы и переменные сравнивать, дабы опечатки не портили сборку.


В какой среде реализуется


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 24 Январь, 2019 18:43 

Зарегистрирован: Пятница, 08 Декабрь, 2017 18:24
Сообщения: 439
Откуда: Астрахань-Сочи
А_МУР писал(а):
Дмитрий Бардынин писал(а):

В моем генератор пространство имен частично реализовано: имена диаграмм уже содержатся в файле, и "Вставка", "Вывод" и "Ввод" сравнивает свое содержимое со списком диаграмм и разрешенных слов.

Пришел к мысли, что не плохо бы и переменные сравнивать, дабы опечатки не портили сборку.


В какой среде реализуется

Степана Митькина редактор.
Генератор Ардуино переписан на базе примера Си.
Правда сам редактор тоже исправлял, чтобы корректно обрабатывал нужные иконки. Он на TCL написан, легко правится.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 24 Январь, 2019 18:49 

Зарегистрирован: Пятница, 08 Декабрь, 2017 18:24
Сообщения: 439
Откуда: Астрахань-Сочи
А_МУР писал(а):
Цитата:
В моем генератор пространство имен частично реализовано: имена диаграмм уже содержатся в файле, и "Вставка", "Вывод" и "Ввод" сравнивает свое содержимое со списком диаграмм и разрешенных слов.

Пришел к мысли, что не плохо бы и переменные сравнивать, дабы опечатки не портили сборку.

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


Быстрый ввод я реализовал в Редакторе, дописав пункт контекстного меню с деревом поименованных иконок. С переменными пока не срочно, т.к. я хочу в первую очередь реализовать возможность набирать программу кликами, а не текстом. Это удобно делать на интерактивной доске, на экране планшетного ПК, или смартфона. Современная детвора больше пальцем по экрану водить научена, чем мышкой и клавиатурой пользоваться.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 24 Январь, 2019 19:33 

Зарегистрирован: Среда, 27 Сентябрь, 2017 18:44
Сообщения: 332
Дмитрий Бардынин писал(а):
А_МУР писал(а):
Цитата:
В моем генератор пространство имен частично реализовано: имена диаграмм уже содержатся в файле, и "Вставка", "Вывод" и "Ввод" сравнивает свое содержимое со списком диаграмм и разрешенных слов.

Пришел к мысли, что не плохо бы и переменные сравнивать, дабы опечатки не портили сборку.

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


Быстрый ввод я реализовал в Редакторе, дописав пункт контекстного меню с деревом поименованных иконок. С переменными пока не срочно, т.к. я хочу в первую очередь реализовать возможность набирать программу кликами, а не текстом. Это удобно делать на интерактивной доске, на экране планшетного ПК, или смартфона. Современная детвора больше пальцем по экрану водить научена, чем мышкой и клавиатурой пользоваться.

Не только детвора! Все выпускники вузов начиная с2007 г


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 12 Февраль, 2019 21:01 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 396
https://forum.drakon.su/viewtopic.php?f=78&t=6263&start=20#p102472
Дмитрий Бардынин писал(а):
Для Исполнителя обе иконы справа от Синхронизатора диктуют приказы одновременно, и лишь дополнительное воздействие Синхронизатора определяет, что делать Исполнителю.

В целом, такая предполагаемая интерпретация элементов диаграммы не соответствует тому, что задано схемой. Прежде всего, сам "синхронизатор" в своей основе вызывает неоднозначное понимание. В реальности декларируется следующее:
Вложение:
Снимок9.GIF
Снимок9.GIF [ 14.5 КБ | Просмотров: 6739 ]

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

Таким образом, граф следования явно указывает на то, что должно исполняться действие "вывод", которое имеет какие-то свои параметры/характеристики в виде присоединенных икон. Однако, пока безотносительно "временной вставки", содержательно это действие "не понимает" никакие "синхронизаторы", этот "синхронизатор" не является свойством данного действия, т.е. внутри иконы "вывод" ничего о синхронизаторе "не знают".

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 12 Февраль, 2019 21:05 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 396
Дмитрий Бардынин писал(а):
Также связка Паузы или Таймера с "Временной вставкой" действует на Исполнителя одновременно, что логично было бы обозначить параллельным шампуром.

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

Аналогична ситуация и в этом случае:
Вложение:
varen.png
varen.png [ 25.15 КБ | Просмотров: 6739 ]

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

"Временную вставку" необходимо понимать как указанную через вспомогательные отношения. В лучшем случае, видимо, необходимо интерпретировать как параметр операции ("ожидания" в примере) -- нечто вроде функций/процессов "высших порядков" -- аля "лямбды", т.е. операции как операнды. Тогда лучше убрать двойную линию (мол множество параметров), использовать обычную линию.
Тогда параметры-"лямбды" в виде присоединенных процессов должны быть универсальным средством, т.е. в применении к прочим иконам-действиям, это должны быть вспомогательные связи-характеристики, как "формальные параметры".
Однако, всё же не ясно тогда в таком случае, как интерпретировать икону "паузу" в виде параметра для иных икон, т.е. как икону "синхронизатор", символизирующий специализированный процесс-ожидание или т.п. Напр., если к действию аля:
y := 2x + 4

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 12 Февраль, 2019 21:07 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 396
https://forum.drakon.su/viewtopic.php?f=139&t=6442&start=40#p102680
Дмитрий Бардынин писал(а):
После непродолжительного исследования интуитивности понимания Временной вставки у неподготовленных читателей, сделал вывод, что не следует смешивать разные способы обработки икон в одну символику. Таким образом, Временная вставка может использоваться для многократного повторения вставки при исполнении иконы-реципиента, и никак иначе. Следовательно, способ, предложенный мною ранее для обработки исключений, не работает.
...
Способ Олега Гарипова адекватнее, КМК. Конечно, с соответствующими оговорками.

Оба способа неадекватны (с картинками по ссылке выше). Иконы для "выбора" (как специальные вершины в графе) образуют альтернативы в выражении отношения следования между операциями, вершины "цикл для" есть метки графа для выражения свойства "повторение". Предполагаемые прыжки по алгоритму в случае исключений и для исполнения секции finally (как и закулисные раскрутки стека) никак не отражены на графе следования.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 12 Февраль, 2019 21:16 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 396
https://forum.drakon.su/viewtopic.php?f=139&t=6442&p=102628#p102647
Владимир Паронджанов писал(а):
LKom писал(а):
Владимир Даниелович, надо смотреть в будущее. Вы же хотите заменить "устаревший" ГОСТ. Может быть свой ГОСТ создадите? Ведь Вельбицикий сделал ГОСТ по Р-технологии.
Это правильная мысль. Действительно, нужен ГОСТ по языку ДРАКОН. Но эту важнейшую задачу должны будут выполнять молодые люди.

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

Иными словами, чтобы снять многозначность и недоопределенность (ликвидируемую по контексту в речи и согласно предметному тезаурусу) естественных языков в формальных системах на базе графики в виде геометрических символов фиксируют единственное предназначение этих символов и отношений между ними. В Дракон-е же наблюдается полиморфизм в предназначении знаков и в связях между ними, поощряемый "Дракон-комитетом". Дракон, скорее, ближе к буквам естественного языка или иероглифам, которые изменяют свою семантику и формируют окончательный свой смысл в зависимости от композиции с другими элементами.
Более того, предлагаются варианты чертежей, где предназначение определяется не только геометрическим образом фигуры, но и текстовым наполнением. К примеру, обработка исключений по ссылке выше, вариант Олега Гарипова, где конструкция "выбора" изменяет свою семантику из-за ключевого слова "try" внутри иконы (причём эта семантика в отрыве от интерпретации графа следования). Аналогично Степан Митькин предлагает изменение семантики "выбора" через ключ. слово "receive" для "автоматных" схем (где уже возникает связь с внешней средой, передача управления и т.д.):
https://forum.drakon.su/viewtopic.php?f=94&t=6449#p102803

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

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

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


В итоге, наблюдаются последствия даже в этой теме (кроме означенного ранее), далее ...


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 276 ]  На страницу Пред.  1 ... 7, 8, 9, 10, 11, 12, 13, 14  След.

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 5


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Вся информация, размещаемая участниками на конференции (тексты сообщений, вложения и пр.) © 2008-2024, участники конференции «DRAKON.SU», если специально не оговорено иное.
Администрация не несет ответственности за мнения, стиль и достоверность высказываний участников, равно как и за безопасность материалов, предоставляемых участниками во вложениях.
Powered by phpBB® Forum Software © phpBB Group
Русская поддержка phpBB