DRAKON.SU

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

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




Начать новую тему Ответить на тему  [ Сообщений: 86 ]  На страницу 1, 2, 3, 4, 5  След.
Автор Сообщение
СообщениеДобавлено: Среда, 30 Январь, 2019 14:27 
Аватара пользователя

Зарегистрирован: Вторник, 04 Октябрь, 2011 17:45
Сообщения: 585
Журнал "Программная инженерия", Номер 1 2019 год
Митькин С.Б.
Автоматное программирование на языке ДРАКОН
https://drakonhub.com/files/pe_drakon_a ... n_2019.pdf


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

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


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

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 5846
Откуда: Москва
Степан Митькин писал(а):
Журнал "Программная инженерия", Номер 1 2019 год
Митькин С.Б.
Автоматное программирование на языке ДРАКОН
https://drakonhub.com/files/pe_drakon_a ... n_2019.pdf
Поздравляю Степана Борисовича Митькина с замечательным достижением — публикацией оригинальной статьи " Автоматное программирование на языке ДРАКОН" в авторитетном профессиональном журнале "Программная инженерия".

Степан, надо разослать вашу статью специалистам: Шалыто, Петренко, Лаврищевой и др.


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

Зарегистрирован: Вторник, 04 Октябрь, 2011 17:45
Сообщения: 585
А_МУР писал(а):
Это если рассматривать конечные автоматы как кирпичики для построения сложных программ.

Это правильный вопрос. Я вскользь касаюсь его в разделе "Сеть автоматов".
К сожалению, в статье не было возможности подробно рассказать о взаимодействии автоматов.
Если в кратце:
1. Есть известный набор правил, которых следует придерживаться при построении программы из многих автоматов.
2. Если не придерживаться тех правил, то возникнут известные проблемы.

ДРАКОН позволяет строить очень большие сети автоматов, потому что "подчинённые" автоматы не изображаются с "главным" на одной диаграмме.


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

Зарегистрирован: Среда, 27 Сентябрь, 2017 18:44
Сообщения: 332
Степан если в схеме содержится два или более одинаковых конечных автомата, то мы можем говорить о программных экземплярах автоматов?

Для меня вопрос применения конечных автоматов, для построения схем по "кирпичикам" это ежедневный и злободневный вопрос.

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

Если экземпляр автомата не получил поток управления, то он сохраняет на своих входах предыдущее состояние. И это оказалось очень критично.


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

Зарегистрирован: Среда, 27 Сентябрь, 2017 18:44
Сообщения: 332
Если не понятно - могу приводить примеры!


Последний раз редактировалось А_МУР Четверг, 31 Январь, 2019 14:50, всего редактировалось 1 раз.

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

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

Для меня вопрос применения конечных автоматов, для построения схем по "кирпичикам" это ежедневный и злободневный вопрос.

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

Если экземпляр автомата не получил поток управления, то он сохраняет на своих входах предыдущее состояние. И это оказалось очень критично.



У меня есть несколько приемов обхода таких состояний, но все они вносят такой сумбур, что схема становится не читаемой


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

Зарегистрирован: Пятница, 08 Декабрь, 2017 18:24
Сообщения: 439
Откуда: Астрахань-Сочи
Степан Митькин писал(а):
Журнал "Программная инженерия", Номер 1 2019 год
Митькин С.Б.
Автоматное программирование на языке ДРАКОН
https://drakonhub.com/files/pe_drakon_a ... n_2019.pdf


Отличная статья! Спасибо, внушает :)


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

Зарегистрирован: Пятница, 08 Декабрь, 2017 18:24
Сообщения: 439
Откуда: Астрахань-Сочи
В статье:
Цитата:
"Программа DRAKON Editor версии 1.31 не поддерживает входные действия на автоматных ДРАКОН-схемах. Тем не менее принципиальная возможность добавить эти действия существует. Входные действия можно расположить над макроиконой "выбор" с ключевым словом "receive".
Выходные действия автоматные ДРАКОН-схемы не поддерживают совсем"
(см.стр.10)

По первому утверждению все понятно, это места отмеченные зеленым маркером на иллюстрации "Дракон-автомат".
Но почему второе утверждение про выходные действия столь категорично? Почему нельзя выходные действия поместить в места, помеченные красным маркером?
Вложение:
Комментарий к файлу: Дракон-автомат
Автоматы.png
Автоматы.png [ 79.17 КБ | Просмотров: 10065 ]

И еще непонятно назначение ветки "Exit". Может иконку ветки совсем убрать? А иконку Конец - оставить.

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

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 12 Февраль, 2019 13:03 
Аватара пользователя

Зарегистрирован: Вторник, 04 Октябрь, 2011 17:45
Сообщения: 585
Дмитрий Бардынин писал(а):
Почему нельзя выходные действия поместить в места, помеченные красным маркером?

Потому что из одного состояния может быть несколько выходов, а правило, выполняемое на любом из выходов из состояния, должно быть одно.
Пример: "при выходе из состояния X закрыть файл Y". При этом из состояния X автомат может перейти в состояния A, B и C.
Дмитрий Бардынин писал(а):
И еще непонятно назначение ветки "Exit". Может иконку ветки совсем убрать?

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


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

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

Потому что из одного состояния может быть несколько выходов, а правило, выполняемое на любом из выходов из состояния, должно быть одно.
Пример: "при выходе из состояния X закрыть файл Y". При этом из состояния X автомат может перейти в состояния A, B и C.

Дать возможность установки иконки Действие только на уникальных выходах, а не уникальные - блокировать.


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

Зарегистрирован: Среда, 07 Январь, 2015 14:53
Сообщения: 1356
Что такое - "уникальный выход"?

Откуда взят такой термин?


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

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

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

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


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

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 396
https://forum.drakon.su/viewtopic.php?f=94&t=6449#p102803
Дмитрий Бардынин писал(а):
Цитата:
"Программа DRAKON Editor версии 1.31 не поддерживает входные действия на автоматных ДРАКОН-схемах. Тем не менее принципиальная возможность добавить эти действия существует. Входные действия можно расположить над макроиконой "выбор" с ключевым словом "receive".
Выходные действия автоматные ДРАКОН-схемы не поддерживают совсем"

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

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

В общем случае необходимо различать:
- переходы в другие состояния, а также и переход в собственное состояние -- "петля" в графах переходах/диаграммах состояний. В последнем случае также необходимо выполнить выходные действия и затем входные -- "сброс" или "reset", начинаем работать с начала, м.б. с корректировками;
- "шаг системы" без перехода в иное состояние. В автоматных методиках часто действия без перехода обозначаются аля "do action/activity" или "during action" (в случае поддержки множества событий, в каком-либо виде, возможно дополнительное деление аля "immediate" или нет -- многократное или одноразовое исполнение при дублировании событий, и т.д.).

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

Входные действия могут быть определены в местах с "зеленым маркером", как здесь:
https://forum.drakon.su/viewtopic.php?f=62&t=6097#p100629

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


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

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 15 Февраль, 2019 20:02 

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

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

Альтернативный подход -- рассматривать процесс как "гиперпроцесс" -- полиморфный, с переключением или выбором конкретного варианта исполнения (функции-состояния) в runtime, как на рисунках ниже. Здесь процесс "Process" имеет два дополнительных или альтернативных процесса-состояния. На схемах имеется попытка применения "терминаторов" из блок-схем, а также и "вопросы иначе". Для внешней среды Process есть единый процесс (и идентифицируется единственным именем), который может сам переключаться на необходимый процесс-состояние (конечно, можно тестировать актуальное состояние процесса). В примере "Subpoc 2" завершает весь процесс (Process). Схемы можно компоновать и горизонтально, эмулируя единый силуэт (или каким-то способом обозначить их общность). Внутри любого процесса-состояния ветки могут использоваться как угодно, т.е. как обычно, в т.ч. и для выражения изменения поведения процесса (мол незначительного).
Вложение:
process.png
process.png [ 25.23 КБ | Просмотров: 9934 ]

Вложение:
subproc1.png
subproc1.png [ 21.18 КБ | Просмотров: 9934 ]

Вложение:
subproc2.png
subproc2.png [ 8.65 КБ | Просмотров: 9934 ]


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 18 Февраль, 2019 10:58 
Аватара пользователя

Зарегистрирован: Вторник, 04 Октябрь, 2011 17:45
Сообщения: 585
PSV100 писал(а):
Неоднократно отмечалось, что деление на ветки как желаемые автоматные состояния не всегда возможно
К примеру, может возникнуть алгоритмическая ситуация, при которой возникает пересечение линий (из-за переплетения условий). Последнее снимается также через силуэт, в итоге возникают прикладные "автоматные" и вспомогательные ветки.

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

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

Язык должен быть ТУПОЙ, КАК ДРОВА.

Иначе народ не поймёт. Иначе будет попытка повторить гротескную сложность си-плюс-плюс с его виртуальными перегруженными операторами.


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

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


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

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

Язык должен быть ТУПОЙ, КАК ДРОВА.

Иначе народ не поймёт. Иначе будет попытка повторить гротескную сложность си-плюс-плюс с его виртуальными перегруженными операторами.

К сожалению, должен, но в реальности Дракон, фактически, от С++ не отстаёт и даже в некоторых моментах превосходит.
Рядом, в иной теме форума, были соответствующие заметки насчёт семантической выразительности. Вот появился и ещё один пример, насчёт "вставки":
https://forum.drakon.su/viewtopic.php?f=78&t=6453#p102843

Оказывается, что "вставка" понимается полиморфно: и как "повторное использование (без вызова)", и как "вызов процедуры/функции". В "стандарте" предназначение определено, скорее, как первое:
https://forum.drakon.su/viewtopic.php?f=62&t=6156#p100785
Цитата:
Икона "вставка" говорит, что в этом месте из алгоритма вынут "кусок", который перенесён в другое место. В иконе пишут название этого "куска"

При этом первоначально, до Дракон-а в массах, всё же "вставка" была "предопределенным процессом" как и в блок-схемах:
https://forum.drakon.su/viewtopic.php?p=23281#p23301

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

В общем, вновь семантика зависит, скорее, традиционно от предметки (даже С++ "отдыхает" в таких случаях).


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

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 396
Степан Митькин писал(а):
Слишком сложно.
У нас есть сеть автоматов. Можно на ходу менять топологию сети, получается то же самое, что "полиморфный гиперпроцесс".
Например, автомат разбора программного кода, когда к нему приходят кавычки, временно вставляет выше по течению другой автомат - автомат разбора строковых литералов.

Нет, не совсем то же самое. Всё же, прежде всего, понятие некой сети автоматов, фактически, задаётся вне условной методики "силуэт-автомат" -- композиция автоматов ("силуэтов") не отражается в Дракон-схемах -- необходимы иные вспомогательные формализмы.
В случае сети возникает "гипер", но как совокупность совместно исполняемых процессов. Гиперпроцесс же предполагает взаимоисключаемое исполнение процессов (функций-состояний). Термины из результатов В.Е. Зюбина (есть и соответствующие математические формализмы):
https://forum.oberoncore.ru/viewtopic.php?f=152&t=5978#p99829

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


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

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 396
В случае условной "блок-схемной" автоматной методики -- понимая автомат как "гиперпроцесс" и используя блок-схемы в диалекте, напоминающем Дракон, как на рисунках ранее (с "терминаторами", и пусть схемы будут именно "упорядоченными блок-схемами") -- автоматные состояния по сути есть отдельные процессы (в некотором связном наборе). Исполнение терминальных состояний -- процессов с "концом" -- лучше отражать через "предопределенный процесс" (напр., "вызвать" процесс обработки "кавычек" (который каким-то образом в т.ч. будет осуществлять и ввод/вывод сигналов/событий) и дождаться его окончания исполнения). Переходы через "терминаторы" актуальны для процессов с условным вечным управляющим циклом (в итоге они также могут изменять своё поведение). Вызывать такие процессы через "вставку" некорректно (они управляются внешне через старт/останов параллельного процесса и т.п.). Необходим и дополнительный семантический контроль, напр., нельзя одновременно использовать субпроцессы-состояния (из одного набора для гиперпроцесса) в "параллельных действиях", и пр.
В итоге такая задача как "разбор программного кода" будет полностью выражена через "автоматную методику". Общая совокупность гиперпроцессов с наборами внутренних процессов-состояний будет представлена отдельно (наборы смежных схем). Алгоритм как протокол следования операций с условиями будет размазан по схемам, нет какого-то декларативного характера построения диаграмм, т.е. события и ожидания будут возникать где угодно по алгоритму (для компактификации или выражения некоего "принципиального устройства" протоколов необходимы иные формы, напр. аля БНФ какой-то, или графы переходов и пр.). Можно сделать привязку данных по процессам (как-то зафиксировать используемые процессом/субпроцессом данные). Соответственно возможна последующая интерпретация автоматов в необходимом виде (классы с методами или структуры данных с операциями, включая все необходимые процедуры инициализации и деструкции, причём с возможностью задавать данные как union-структуры или вариантные записи с учётом использования данных по процессам).


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 86 ]  На страницу 1, 2, 3, 4, 5  След.

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


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

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


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

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