Комментарии 20
>> АП не стало магистральным трендом. Главная причина здесь — недостаточный опыт использования ( часть №1)
ну не только это, главная причина в том что автоматное программирование довольно нишевое, и не везде его можно и не всегда целесообразно применять
и даже тогда когда есть смысл есть много моментов
например в схеме анализа bacab слишком много линий, это при том, что последовательность простая. стоит появится множественным линиям ( как уже не раз на хабре отмечалось ) получается полный швах. конечно, можно применить элементы концентраторы, которые помогут сделать схему читаемой. но так же можно отметить, что проблема неявных переходов остаётся, и плодить лишние стрелки тут совсем уже плохо.
вот ваш пример c bacab
на ней голубым цветом как раз концентраторы.
у Вас не заметно 2 важных аспекта
— то что если схема порождает код — значит ошибок на этом участке нет и всё точно,
— то что схема позволяет строить более сложные переходы проще. на моей блок схеме добавлена буква Е. А вот добавить это условие в привычный код намного сложнее.
но как показала практика блок схемы это всё же крайне нишевое решение. потому в других местах это становится тупиковым направлением, даже если кажется, что есть какие-то преимущества.
ну не только это, главная причина в том что автоматное программирование довольно нишевое, и не везде его можно и не всегда целесообразно применять
и даже тогда когда есть смысл есть много моментов
например в схеме анализа bacab слишком много линий, это при том, что последовательность простая. стоит появится множественным линиям ( как уже не раз на хабре отмечалось ) получается полный швах. конечно, можно применить элементы концентраторы, которые помогут сделать схему читаемой. но так же можно отметить, что проблема неявных переходов остаётся, и плодить лишние стрелки тут совсем уже плохо.
вот ваш пример c bacab
скрытая картинка
на ней голубым цветом как раз концентраторы.
тут немножко кода
W=703
switch(W)
{
case 703:
if (S==«b»){W=704;continue;}
return;
case 704:
if (S==«a»){W=705;continue;}
return;
case 705:
if (S==«c»){W=706;continue;}
return;
case 706:
if (S==«a»){W=708;continue;}
if (S==«E»){W=712;continue;}
return;
case 707: return;
case 708:
if (S==«b»){W=707;continue;}
return;
case 710: return;
case 712:
if (S==«b»){W=707;continue;}
return;
default: return;
}
switch(W)
{
case 703:
if (S==«b»){W=704;continue;}
return;
case 704:
if (S==«a»){W=705;continue;}
return;
case 705:
if (S==«c»){W=706;continue;}
return;
case 706:
if (S==«a»){W=708;continue;}
if (S==«E»){W=712;continue;}
return;
case 707: return;
case 708:
if (S==«b»){W=707;continue;}
return;
case 710: return;
case 712:
if (S==«b»){W=707;continue;}
return;
default: return;
}
у Вас не заметно 2 важных аспекта
— то что если схема порождает код — значит ошибок на этом участке нет и всё точно,
— то что схема позволяет строить более сложные переходы проще. на моей блок схеме добавлена буква Е. А вот добавить это условие в привычный код намного сложнее.
но как показала практика блок схемы это всё же крайне нишевое решение. потому в других местах это становится тупиковым направлением, даже если кажется, что есть какие-то преимущества.
у Вас не заметно 2 важных аспекта
— то что если схема порождает код — значит ошибок на этом участке нет и всё точно,
Не уверен, что правильно Вас понимаю, поясните пожалуйста что значит «схема порождает код»?
— то что схема позволяет строить более сложные переходы проще. на моей блок схеме добавлена буква Е.
И что получается, автомат который теперь определяет 2 кода: bacab и bacEb? Или пардон?
причина в том что автоматное программирование довольно нишевое, и не везде его можно и не всегда целесообразно применять
Если не попадать под влияние распространённых стереотипов, о которых рассказано в пункте «Артефакты автоматной схемотехники» автоматное программирование очень похоже на «естественное» программирование. Основное отличие — в проектировании. Я это буду демонстрировать на примерах.
Если не попадать под влияние распространённых стереотипов
не знаю, я не попадаю, просто практика и удобство применения говорит что не так всё просто и радужно как может показаться на первый взгляд
«схема порождает код»
как изображено, ровно так и будет реализовано. а иначе зачем? не красоваться же.
И что получается, автомат который теперь определяет 2 кода: bacab и bacEb?
ну да, в коде вроде это должно быть понятно
if (S==«a»){W=708;continue;}
if (S==«E»){W=712;continue;}
можно например добавить ещё немного и получить
новая схема
эта схема определяет
bacab и bacEb
+ bacE,bacE1,bacE12
и порождающий код будет точно соответствовать схеме.
*такую программу можно нужно реализовывать не через switсh, а через таблицы, это не только работает работает быстрее, но и:
*эти таблицы составляются автоматически, я приведу пример. Диаграмму состояний я нарисовал как пример. Для символьных автоматов диаграммы в процессе разработки не нужны. Я приведу программу, которая составляет таблицы
* автоматы распознающие коды, точнее определяющий один из нескольких возможных это интересная тема, у меня есть. Вообще символьным автоматам я собираюсь посвятить отдельную статью.
* диаграммы состояния составляются для функциональных автоматов. В этом случае диаграмма состояний замечательно описывает процесс. Например рисунок 3 в тексте статьи.
И позвольте задать Вам вопрос как читателю. Достаточно ли я провёл разделение автоматов на символьные и функциональные, или оно не выглядит столь фундаментальным? Дело в том, что я хочу направить внимание читателей на то, что акцент будет на функциональные автоматы и описание при помощи диаграммы состояний именно алгоритмов, а не символьных автоматов, которые получаются алгоритмически и хранятся в виде таблиц
Тогда поясните фразу
лучше с примером
*эти таблицы составляются автоматически, я приведу пример. Диаграмму состояний я нарисовал как пример. Для символьных автоматов диаграммы в процессе разработки не нужны. Я приведу программу, которая составляет таблицы
* автоматы распознающие коды, точнее определяющий один из нескольких возможных это интересная тема, у меня есть. Вообще символьным автоматам я собираюсь посвятить отдельную статью.
* диаграммы состояния составляются для функциональных автоматов. В этом случае диаграмма состояний замечательно описывает процесс. Например рисунок 3 в тексте статьи.
И позвольте задать Вам вопрос как читателю. Достаточно ли я провёл разделение автоматов на символьные и функциональные, или оно не выглядит столь фундаментальным? Дело в том, что я хочу направить внимание читателей на то, что акцент будет на функциональные автоматы и описание при помощи диаграммы состояний именно алгоритмов, а не символьных автоматов, которые получаются алгоритмически и хранятся в виде таблиц
«схема порождает код» — как изображено, ровно так и будет реализовано. а иначе зачем? не красоваться же.
Тогда поясните фразу
— то что если схема порождает код — значит ошибок на этом участке нет и всё точно,
лучше с примером
Тогда поясните фразу — то что если схема порождает код
ну как бы я уже приводил пример, повторю
схема и соответствующий код
в точности порождает
W=703
switch(W)
{
case 703:
if (S==«b»){W=704;continue;}
return;
case 704:
if (S==«a»){W=705;continue;}
return;
case 705:
if (S==«c»){W=706;continue;}
return;
case 706:
if (S==«a»){W=708;continue;}
if (S==«E»){W=712;continue;}
return;
case 707: return;
case 708:
if (S==«b»){W=707;continue;}
return;
case 710: return;
case 712:
if (S==«b»){W=707;continue;}
return;
default: return;
}
это работающий код и мне не надо думать что реализуемое поведение будет отличаться от схемы. если на схеме стрелка идёт от 'с' к 'а' и к 'Е' то трассировка и проверка не нужна.
в точности порождает
W=703
switch(W)
{
case 703:
if (S==«b»){W=704;continue;}
return;
case 704:
if (S==«a»){W=705;continue;}
return;
case 705:
if (S==«c»){W=706;continue;}
return;
case 706:
if (S==«a»){W=708;continue;}
if (S==«E»){W=712;continue;}
return;
case 707: return;
case 708:
if (S==«b»){W=707;continue;}
return;
case 710: return;
case 712:
if (S==«b»){W=707;continue;}
return;
default: return;
}
это работающий код и мне не надо думать что реализуемое поведение будет отличаться от схемы. если на схеме стрелка идёт от 'с' к 'а' и к 'Е' то трассировка и проверка не нужна.
разделение автоматов на символьные и функциональные, или оно не выглядит столь фундаментальным
по мне, как пользователю подобных автоматов, нет особой разницы и те и те автоматы, просто для символьных одни условия, для функциональных другие. но само построение одинаково.
*такую программу можно нужно реализовывать не через switсh, а через таблицы, это не только работает работает быстрее, но и:
ну switch используется по причине простой и понятной
1. он реально быстр, быстрее if и таблиц с хешами и прочим. проблемы у него будут если повесить 1000 case на один switch. тут хэш будет быстрее.
2. наглядность, если есть какая то ошибка, то в switch -case эту ошибку можно увидеть и отловить. в случае таблиц отладка затруднена. понять почему ветвление пошло по этому маршруту сложнее.
по мне, как пользователю подобных автоматов, нет особой разницы и те и те автоматы, просто для символьных одни условия, для функциональных другие. но само построение одинаково.
Позвольте пример — если даже не рассматривать тему символьных автоматов вообще, то автоматное программирование это удобный способ записи алгоритмов
Я как практикующий автоматный программист почти не составляю символьные, кроме как для примеров, но я могу при помощи диаграммы состояний записать алгоритм(автомат), который по заданному коду будет составлять таблицу(то есть автомат, которой строит другие автоматы) для распознавания любого кода. И вот те автоматы будут состоять из таблицы составленной компьютером, то есть речь не идёт об ошибках, которые может допустить человек а потом можно и не увидеть. Но быстродействие варианта к примеру для рис 12 не сравнится по быстродействию с быстродействием switch. Но если нет преимуществ, тогда зачем? Поясню, использование этой конструкции не противоречит автоматному программированию, но зачем?
Другое дело функциональные программные автоматы — их можно показать как пример 1 — пример 8 и среди них т.н. базовая конструктивная реализация самое то. Это из моей практике, могу подтвердить коллегам, что очень практичная в использовании и скоростная как я не знаю что.
я могу при помощи диаграммы состояний записать алгоритм(автомат), который по заданному коду будет составлять таблицу
т.е. создав подобную блок-схему в программе она создаст поведенческую модель( сформирует код, таблицу поведения). так? я как то плохо виду как приведённая блок схема может превратится в рабочее тело.
и не надо забывать, что у подобного подхода есть 2 крупных минуса
1. прерывания.
они плохо кладутся в диаграмму состояний.
как пример — реализация 3х кнопочных часов Элекстроника
фото часов
вроде эти часы конечный автомат, но вот диаграммами его не описать. придётся шаманить
2. многопоточность. как её впихивать в состояния?
и да, по switch-case
case позволяет прыгать с ветки на ветку. довольно удобная штука
switch(char)
{
case 'a': goto case 'b';
case 'b':…
}
про часы интересный пример, я возможно использую его для иллюстрации
хороший вопрос. для обмена прерывание-фон активно используются кольцевые буферы для обмена данными. автоматы висят в прерываниях (как показано на рис 7 )
многопоточность. как её впихивать в состояния?
хороший вопрос. для обмена прерывание-фон активно используются кольцевые буферы для обмена данными. автоматы висят в прерываниях (как показано на рис 7 )
я не про обмен данными, а про общую синхронизацию.
есть система, которая пребывает в каком то состоянии. у неё несколько фоновых потоков. + происходят прерывания.
и вот как это диаграммами однозначно запилить?
часы это похожий пример. есть кварцевой генератор тактов — фоновый поток. есть кнопки — прерыватели. в зависимости от порядка нажатий — на экране показывается разная инфа.
есть система, которая пребывает в каком то состоянии. у неё несколько фоновых потоков. + происходят прерывания.
и вот как это диаграммами однозначно запилить?
часы это похожий пример. есть кварцевой генератор тактов — фоновый поток. есть кнопки — прерыватели. в зависимости от порядка нажатий — на экране показывается разная инфа.
Вот здесь как предугадал, что вы напишите про диаграммы состояний. нет единой диаграммы состояний — есть сообщество программ — автоматов и всё. обмен данными через буферы, синхронизация через флаги, никаких проблем
+ про часы я пожалуй сделаю пример
+ про часы я пожалуй сделаю пример
может быть я что то недопонял, диаграммы состояний с флагами нужны для чего
№1) для понимания процессов
№2) на основе графа зависимостей — построение программной реализации
из текста как я понял что речь идёт о п.№2, но как то очень лихо примешан буфер, флаги. Есть конкретное понимание как это работает, или это общее представление как должно быть.
мой моск плохо понимает, как скрестить в одном графе одновременно и состояния, и прерывания, и кольцевой буфер.
как общая картинка для понимания №1 — почему бы и нет,
а вот как №2 — создание модели непонимать. если у Вас есть такое понимание, готов выслушать.
№1) для понимания процессов
№2) на основе графа зависимостей — построение программной реализации
из текста как я понял что речь идёт о п.№2, но как то очень лихо примешан буфер, флаги. Есть конкретное понимание как это работает, или это общее представление как должно быть.
мой моск плохо понимает, как скрестить в одном графе одновременно и состояния, и прерывания, и кольцевой буфер.
как общая картинка для понимания №1 — почему бы и нет,
а вот как №2 — создание модели непонимать. если у Вас есть такое понимание, готов выслушать.
мы же говорим об автоматной многозадачности? если вкрадце, то можно рассматривать автоматы как классы, обращение к которым идёт только через кольцевые буферы(каналы связи между процессами) которых может быть сколько угодно. Один автомат — один процесс. Не нужно составлять диаграмму состояний которая охватит все биты микроконтроллера — перечитайте раздел «Артефакты автоматной схемотехники», там же ответы на ваши вопросы, можно сказать, между строк. Но будет статья и я подчеркну этот факт, спасибо за интерес
мы говорим о подходе к созданию программ с использованием графа состояний. не так ли?
и подразумевается, что применение этого подхода должно значительно упростить процесс создания.
в «Артефакты автоматной схемотехники» не увидел между строк понимание сложных моментов — смеси разнородных вещей — самих состояний, буферов, потоков ( и!!! массива потоков )
там же сложность в том, что в одном случае стрелка означает одно, в другом другое. легко запутаться.
я когда то занимался автоматами, но перестал, т.к. понял ограниченную перспективу их реального применения. для каких то задач они идеальны, но их очень мало.
и подразумевается, что применение этого подхода должно значительно упростить процесс создания.
в «Артефакты автоматной схемотехники» не увидел между строк понимание сложных моментов — смеси разнородных вещей — самих состояний, буферов, потоков ( и!!! массива потоков )
там же сложность в том, что в одном случае стрелка означает одно, в другом другое. легко запутаться.
я когда то занимался автоматами, но перестал, т.к. понял ограниченную перспективу их реального применения. для каких то задач они идеальны, но их очень мало.
там же сложность в том, что в одном случае стрелка означает одно, в другом другое. легко запутаться.
над стрелками однозначные подписи, это психологический аспект: это кажется непривычным и поэтому малопонимаемым вообще, но это не так
я учту то что Вы написали, я отвечу статьёй с картинками, так будет понятней.
Как подписи у стрелок отождествляют код. Или это просто информативный текст?
1. прерывания.
они плохо кладутся в диаграмму состояний.
это в общем дополнение к коменту выше — не составляется единый автомат всего программного процесса — всё разбивается на ряд подавтоматов, часть из которых висит в прерывании часть в фоне, обмен межу которыми через структуры данных — кольцевые буферы самый универсальный вариант
del
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Автоматное программирование. Часть 3. Диаграмма состояний и переходов. Продолжение