Спасибо, теперь я "вооружен и очень опасен" :) Но вернемся в тему....
Я так понял, что в "ВКП" эти диаграммы нарисованы чуть ли не MS Visio, а здесь у нас примитивное "Visio" прямо на борту, с возможностью редактирования и отладки, пошагового исполнения и т.п., что переводит программирование автоматов в разряд "как слышится — так и пишется".
Так оно и есть - Visio. А, конечно, хотелось бы иметь "на борту" графику, но ... Графическая форма, несомненно, наглядна, удобна и т.д. но табличная форма (текстовая) иногда удобнее и уж совсем проще в реализации. В любом случае графическая форма должна быть преобразована в исполняемую форму и здесь табличная форма является именно таковой. А отсутствие "бортовой графики" я компенсирую средствfми визуализации, внедренными в ВКПа (их я и представил в последних статьях). Конечно, это несколько не то, но и они здорово помогают. Конечно, лучше бы иметь и то и другое. Например, в MATLAB-е есть и графическая и табличные формы представления автоматов. И это и правильно и хорошо. А в LabVIEW есть табличная форма описания автоматов?
Но в любом случае форма формой, но все же нужно иметь представление, какой автомат она реализует. Именоо в математическом смысле. Именно от этого надо "плясать". Например, мне кажется, что LabVIEW реализует фактически автоматы Мура. Если это так, то это несколько ограниячивает их возможности.
Не очень понятно автомат в LabVIEW абстрактный или структурный. По первому впечатлению - аьстрактный. Почему? Во-первых я вижу только один "символ", как условие перехода. Фактически имеем и один "символ" на выходе. С ними можно, конечно, связать те или иные отдельные действия и даже их последовательность, но это все же не то. Структурный автомат (с абстрактным состоянием) - более гибкая модель и ближе к реалиям.
Можно запустить несколько автоматов параллельно - это хорошо. Но какой это параллелизм? Надо проверять. А что проверять и как проверять, если нет формального определения этого параллелизма? Как, например, можно проверить операцию умножения (хотя бы 2*2), не зная результат?
"Шведский нож", думаю, потому и не зашел, что за его "лесом" возможностей не видно "деревьев" - формальной модели автоматов. Или это диаграммы Харела, как в UML? Например, в тот же MATLAB в их Stateflow однозначно сказано - Харел. И с ними все ясно. В LabVIEW я пока не знаю - одни мои догадки.Где-то про это сказано? Т.е. про формальную модель отдельного автомата, про формальную модель множества автоматов? Если это есть, то есть и точка отсчета и одновременно цель, которой должна соотвествовать реализация. Если нет - то видим "шведские" варианты "леса" из завалов "деревьев".
Например, раньше к этому процессу - созданию новых вычислительных моделей подходили много строже. Считали, что та же машина Тьюринга - это абсолютный эталон, а потому, когда предлагалась новая модель, то приводилась и формальная процедура приведения к ней. То же самое делали по отношению к автоматам. Сейчас этим просто не замарачиваются. А так быть не должно. Хотя есть ;)
Как я убедился автоматы в LabVIEW достаточно интересны, но где "точка отсчета"? Например, срабатываение двух переходов - маразм с точки зрения теории обычной модели модели. Это грубейшая ошибка, а мы еще обсуждаем, какой переход может сработать ;) Подобную модель просто нужно корректировать или устранить подобную вещь, а не думать, что и за чем будет выполняться. Кто-то с этим явно не согласиться, но ... Реализаци математики, в которой 2*2=5 для кого-то может иметь важное значение, но, во-первых, необходимость такой математики нужно еще обосновать, а, во-вторых, сравнить с той математикой в которой 2*2= 4.
Например, я не понимаю, что такое квантовый компьютер. Как на нем реализовать простейший алгоритм, например, нахождение наибольшего общего делителя (НОД). Понятие алгоритма, ведь, ни кто еще не отменял. Он что - реализует какие-то иные алгоритмы? Но если ты "компьютер", то будь добр реализовать любые алгоритмы. Ну, ладно, ты что-то там считаешь очень сложное для понимания... Но неужели это нельзя представить в форме алгоритма и сымитировать вычисление на обычном компьютере? Пусть это будет даже очень и очень медленно.
К чему это я так пространно? Можно много обсуждать автоматы. но если нет процедур их сравнения, то это почти бессмысленный разговор дилетантов. Типа есть Бог или нет. Наука говорит - нет, вера - есть. Я почему-то больше доверяю науке ;) С автоматами проще - есть теория автоматов. Поэтому для меня автомат, имеющий несколько активных переходв - это "божественный автомат" ;-). Он выпадает из моего научного понимания модели автомата. Да, есть недетерминированные автоматы. Но это совсем другое дело. Там, во-первых, срабатывают все такие переходы, а, во-вторых, они приводятся к обычным - детерминированным автоматам. Есть еще, правда, вероятностные автоматы. Но, надеюсь, в LabVIEW речь совсем не о них ;)
Никак не ожидал, что что-то подобное есть в LabVIEW. Конечно, вопросы по автоматам есть. Возможно, потому, что для понимания надо было бы прощупать их ручками.
Итак, по автоматам. Ну, например, во-первых, - переходы. На мой взгляд как-то слишком уж в лоб. Хотелось бы иметь, как минимум, конъюкции условий перехода. Т.е. что-то типа transition1transition3 - подобно x1x3 или transition1^transition3 - если нужно что-то типа x1^x3. Т.е. иметь возможность составлять логические выражения. Также важно, если условие перехода включает несколько transitions, то они должны восприниматься, как параллельные.
Во-вторых, - действия. В классических автоматах есть действия по типу Мили и/или типу Мура. Здесь, похоже, только по типу Мура. При этом я не воспринимаю их, как действия реализуемые В состояниях, а как действия ПРИ них. Хотя полное впечатление складывается, что они исполняются при входе в состояния. Это совсем не по автоматному :) Не устраивает и их последовательное исполнение. Надо бы, если операции в рамках отдельного действия, то они последовательные. Если это несколько действий, то - параллельные. Ну, как в ВКПа ;)
Хотелось бы иметь четкое понимание того, как ведут себя сети автоматов, если их, конечно, можно создавать вообще. В ВКПа - это рядовое дело. Собственно, ради них и следует занимться автоматным программированием. Отдельные автоматы - одно, сети - другой уровень. Это как последовательное и паралельное программирование. Два разных программирования.
О технологии проектирования автоматолв. В чем-то аналогично проектируются визуальные автоматы и в ВКПа. Конечно, в LabVIEW сделано много шикарнее и визуальнее, но принцип примерно тот же - через диалоги сформировать нужные предикаты/действия. Что-то подобное у меня тоже есть в планах, но пока до этого просто руки не доходят. .ВКпа, как мне представляется, пока берет моделью ;). Ну, а если мне нужен автомат посложнее, то я просто его делаю на С++. А с его возможностями ни какая визуализация не сравнится. Как мне показалось и в LabVIEWЮ когда не хватает визуальных возможностей, поступают также на уровне тех же библиотек. Собственно в ВКПа такие же библиотеки, но только на С++.
При этом, навскидку, модель автоматов Stateflow в MATLAB помощнее будет автоматов в LabVIEW. Хотя, не исключаю, модель и одна (типа UML). Но, еще раз, - красиво. Этого ВКПа, что там скрывать, не хватает. Но опять же это все дело техники. Примеры, как минимум, визуальной реализации автоматов в LabVIEW и в MATLAB, демонстатруют это Во-первых, КАК это можно сделать, а, во-вторых, что каких-то принципиальных препятствий для подобной реализации нет.
Еще раз - просто впечатлило! Пока мы тут боремся за первенство термина "автоматного програмирования" в рамках "СВИСТ-технологии" или увлечены некими "традиционными ценностями", кто-то просто "лопатит код" и уже давно не сводит проектирование автомтов к оператору типа SWITCH. Вы показали это очень убедительно и просто наглядно (хочется научиться делать такие же гифки:).
Я даже уверен, что когда-то автоматная модель ВКПа будет реализована в LabVIEW или MATLAB ;) Все идет в эту сторону. А ведь когда-то, лет этак 30-40 назад (эх, как время летит!:), было объявлено, что автоматы исчерпали свои возможности. Даже придумали было .сети Петри. Только, кто теперь помнит про эти сети Петри, и какой бум, особенно в последнее время, вокруг автоматов. Пусть тока это не те автоматы, но, как говорится, - еще не вечер ;)
Все это очень интересно, но... Я вижу графы, которые, ну, очень похожи на графы автоматов, но как Вы их создали? Для меня автомат - это прежде всего язык проектирования, а здесь? Ну, например. Есть переходы, но нет условий переходов. А действия где? Есть состояния, а при них - имена или имена действий или и то и другое? Т.е. складывается впечатление, что данные автоматы - это некие анимированные картинки?
Дракон- это не язык программирования, а "образ мышления", на что мне указали его адепты.
Тут надо бы понимать, что они (адепты) понимали под "образом мышления". Программист проектирует алгоритмы. В этом смысле язык программирования - текстовая форма алгоритма, а граф (блок-схема, автомат и т.п.) - графическая. Понятно, как первая превращается в код для процессора. То же самое можно сделать и с графической формой. В конце концов можно "мыслить" образно графом, нарисовать его, а потом ручками перейти от крафической формы к текстовой. Но первый Ваш "образ" - это граф. Этим отличается отличие "графического мышления" от "текстового". Но и в основе ДРАКОНА и любого языка программирования понятие блок-схемы. И вот в этом смысле адепты были не правы, т.к. используете Вы ДРАКОН или нет, но в основе подобного мышления одно - "блок-схемное мышление".
Когда Вы используете автоматную модель представления алгоритма, то у Вас поневоле будет и другое мышление - автоматное. Я, например, достаточно давно не "мыслю" блок-схемами, а - автоматами. И это, действительно, другое "мышления". От "блок-схемного" отказаться сразу конечно сложно, но вполне возможно. Это я говорю, основываясь на собственном опыте.
Можно, конечно, считать, что "графическое" и "текстовое" - это разные формы мышления. И где-то это так. Но все же кардинальным образом мышление изменяет используемая модель вычислений. В этом смысле ДРАКОН не меняет мышление. И только "автоматное мышление" - иное мышление, как, например, существует "объектное .мышление".
Этих преобразователей уже вагон написан...
В этом нет ни чего плохого. Другое дело, ЧТО они преобразуют. Догадываетесь о чем речь?
Вы меня сподвигаете - создать преобразователь ДРАКОН схем в абстрактный автомат,
Совсем нет. Наоборот, хочу отговорить от этой мысли ;) Вы только зря потратите свои сылы. Просто, преобразуя ручками блок-схемы в автоматы, Вы поймете, чем автоматы отличаются от блок-схем. Это, первое. Второе - почему здесь абстрактные автоматы ни при чем - нужны структурные автоматы (с абстрактным состоянием). Третье - созреете к переходу от отдельных автоматам к сетям. Это, чтобы параллельно программировать.
Да, чуть не забыл, нужно выбрать, а, может, и создать свой метод кодирования автоматов для того языка программирования, на котором Вы работаете. Все это лучше сначала делать ручками. Через них просто лучше доходит. А уж потом, если будет желание, время и понимание того, что это просто необходимо и без этого просто жизни нет, то тогда можно и "создавать преобразователи".
Т.е. сначала нужно врубиться в идею автоматного программирования, а уж потом приступать к ее реализации. Не надо ставить "телегу впереди лошади". Во, как-то так - на пальцах, так сказать.
Это я делюсь своим опытом :) Конечно, доходить до всего самому сложно, долго и тяжело, но приготовьтесь и к этому... Хотя, думаю, Вам будет много проще, чем это было мне ;) Плохо ли хорошо, но все это описано в моих статьях здесь на Хабре. Осталось только... "малость подучиться" :)
Вы от него много хотите ;) Он достаточно наглядный и хороший пример визуального програмирования. Причем использованный в реальной работе. Другое дело, что можно критиковать или обсуждать вычислительную модель, положенную в его основу. Это модель блок-схем. Но в рамках даннной модели до сих пор работают почти все языки программирования. Так что в этом смысле он им соотвествует.
ДРАКОН можно было бы внедрить почти в любой язык програмирования с учетом уже современных их возможностей, но ... Блок-схемы это все же программная модель, которую давно пора заменить на что-то другое. Например, на те же автоматы ;) .
Ответ просто один - схему. Но ее еще ужно создать.
Кто-то из мудрых пояснил - вы уже создаёте программы в автоматном стиле, даже не зная об этом, только Ваши автоматы получаются плохими.
Было бы хорошо, если бы "мудрецы" пояснили, как из Ваших блок-схем создать автоматы. Это реально просто - стандартная процедура. Вот Ваша блок-схема, подготовленная к рисованию графа-автомата:
Вы заставили меня задуматься;) Я, конечно, не уберу ^, но, возможно, добавлю !. Как бы на любителя.
Те "рисовалки", которые мне попадались, меня не устраивали. По многим причинам. Поэтому просто рисую автоматы в Visio.
Интеграция, как уже сказал, мне видится через полный доступ ко всей памяти ПЛК, используя любой протокол. Например, modbus. Сделали проект, отработали, отладили дальше - в код ПЛК. Сейчас автоматы - ручками. Кодирование - это самое простое в программировании. А дальше - как получится, но, скорее всего, этим я заниматься не буду.
Да, SFC есть. Есть даже официальный документ, в котором описано кодирование на нем автоматов. Но - не то..Я, конечно, поглядывал в его сторону (и даже давно), но, как оказалось, проще сделать на LD. Так, как я уже этот процесс описал.
Ну, а насчет использования. Как сделаю связь по протоколу, то, может, даже опишу и тогда будем смотеть, что с этим делать. По крайней мере, это самый реальный вариант интеграции ВКПа с ПЛК. Подобные вещи я делал (пусть и не с ПЛК и, к сожалению, не по modbus). Но здесь все достаточно понятно, т.к. делается аналогично, да и цели ясны ;).
Разницы большой между !x1 и ^x1 нет. Все это условности. Мне больше нравится вторая форма.
Про дуги. Не надо путать имена входных каналов - x1, x2, ... xM, y1, y2, ...yN и функции-предикаты и функции-действия им сопоставленные. Автомат по определению - это MxN-полюсник. На дугах пишутся имена каналов, а функции, которые могут быть достаточно сложными - расшифровываются рядом. Так точнее. Хотя, может быть, есть и некоторые проблемы с наглядностью. Но и расшифровка непосредственно на дугах содержимое предикатов и действий - лишнее загромождение графа, да и не все можно порой записать, т.е. уместить. Все это наглядно демонстрируют автоматы, созданные програмистами. Они упрямо хотят вписать в граф автомата на его переходы и в состояния явно невписуемое :).
По поводу связи. В моем варианте (когда связь ПЛК-ПК есть) проектирование ведется на языке автоматов (те же визуальные автоматы в форме FAutomaton). А после того, как все отработано переложить автомат пусть даже ручками - не большая проблема. Делается "по щелчку" на STL или LD (см. опять же мою ссылку). Конечно, хорошо бы иметь компилятор, но ... нужно быть реалистом. Это все возможно, но требует не только денег на реализацию, но и знаний, как это сделать.Часто есть одно, но нет другого или наоборот ;)
Главное, чтобы этот интерфейс не вызывал отторжения у автора. Пока терплю ;) Другие могут предложить (было бы весьма интерсно посмотреть) и даже реализовать свой. Пока, если честно, у меня подобный "пазл" как-то не складывается.
В чем конретно я перемудрил? Не признаю гаданий. Если по поводу символа отрицания - ^, то хотелось бы посмотреть на другие варианты.Остальное - как в книжках по автоматам.
По поводу "загрузить" и "исполнить". Может быть несколько вариантов. Самый реальный описан в моей статье, т.е. просто ручками. Это мой текущий вариант работы. Есть другой на мой взгляд очень хороший и даже красивый вариант: связать, например, по modbus ПК (с ВКПа) с ПЛК. Дальше создаем автоматы в ВКПа, общаясь в реальном времени с оборудованием через ПЛК, имея, конечно, полный доступ к его памями. Отработав все, реализуем автоматы, как в указанной статье. По сути это аналог режима отладки обычной среды разработки для ПЛК. Только в данном случае средой разработки выступает ВКПа.
Думаю, что Qt поддерживает SQL.Так уж сложилось что в ВКПа на Visual Studio я работал с БД, а тут как-то не было нужды. Но уверен, что с этим (БД) проблем не должно, т.к. и там и здесь все тот же C++. Вот даже нашел быстренько.
Вы так и поняли. Все, что можно сделать в Qt и на С++, можно сделать и в ВКПа. Нужны только знания, время и ... деньги. Это, так сказать, по умолчанию. Поэтому, если речь идет обо мне лично, то, может, и не смог бы. Тут даже и спорить не буду или что-то доказывать. Ну а тот, кто хорошо знает возможности Qt и C++, думаю, без проблем. Потому как о каких-то ограничениях здесь я не слышал. Может, подскажете? Да и Вы, судя по статье, намеревались применить что-то типа C#. Неужели на С# можно, а на С++ нельзя? Подозреваю, что можно ;)
Но чуть серьезнее. Если бы передо мной стояла такая же задача... Во-первых, реализовал/нашел бы протоколы. Во-вторых, сделал бы операции/команды, которых нет на визуальном уровне. В-третьих, оформил бы сценарии тестирования в форме автоматов. Ну и, в-четвертых, использовал любую базу данных. Кстати, есть интересный замысел, и, возможно, что-то подобное мне и предстоит сделать... ;)
Да, и еще. Визуальный уровень можно и не подключать, а сделать все на С++. По большей части так и делаю. Протоколы, "ителлектуальное общение", параллелизм - все это обычное дело. Есть готовое - применяю, нет - дорабатываю. И это не только "учебные программки" (они в первую очередь рассчитаны на тех, кто что-то "подозревает"), а вполне себе серьезые вещи. Кстати, разработка самой среды ВКПа, думаю, посложнее будет, чем описанный Вами проект.
А приведенный пример гильотины - это часть реального проекта. Один в один. Более того, в процессе написания статей обнаружились определенные проблемы. Но об этом уже в следующей части. Но вот если б Вы обнаружили эти или какие-то другие проблемы в работе модели, то я был бы, если честно, удивлен. Я бы их даже бы проверил ;)
Хотелось бы, чтобы Ваши подозрения на чем-то основывались. Ну, например, реализуйте на LabVIEW простой алгоритм контроля датчиков гильотины. Получится - прекрасно. Можно будет сравнить. Если это просто "ля-ля", то к чему? Показать, что, мол, - "плавали-знаем"?
Например. При обсуждении моей статьи "Параллелизм без потоков: очевидно и вероятно"@AndreyDmitriev попробовал все, о чем он "подозревал", изложмить именно на LabVIEW. Вот за подобное - спасибо. Я за подобную критику, а не за некие "подозрения".
Итак, повторю. Если знаете LabVIEW, то воплотите свои "подозрения" в жизнь, реализовав мою просьбу - создать тот же алгоритм контроля датчиков. В ВКПа это совсем просто. А на LabWIEW?
Соотвественно и про Quantum Leaps. Я даже нашел статью на Хабре - Quantum Leaps QP и UML statecharts. Вроде про автоматы. Я думал, что про них если не все, то мное знаю. Но, прочитав статью, "подозреваю", что я просто дебил, т.к. совершенно ни чего не понял. Просто не понял какой там алгоритм рассматривается? Видимо про какрй-то счетчик, т.к. есть "count", но как над ним издеваются - за пределами моего разумения. Как, используя QP, т.е. материал этой статьи, реализовать тот же автомат контроля датчиков? Проблема - тьфу, а мозги выворачиваются на изнанку..
В ВКПа я легко преобразую любой автомат в презираемые всеми блок-схему (соотвественно и любую блок-схему в автомат) и реализую ее затем на любом языке. Без всякой ВКПа и автоматов. Но как это сделать в QP и том же UML? "Тайна сия велика есть"? ;)
Это Quantum Leaps? Квантовое программирование, так кажется?
Там есть очень удобное понятие - вложенные конечные автоматы.
В ВКПа это тоже, конечно, есть. Без этого - ни как и ни куда. И даже дано формальное определение вложенного автомата. Есть даже вложенные инерционные автоматы. Обо все этом в статьях по ссылкам, о которых я говорил в предисловии (т.е. в 1-й статье на тему ВКПа)
И по поводу сложности Еще эффективнее бороться со сложностью с помощью параллелизма. Даже не имея вложенности, все вопросы можно решать с помощью параллелизма. Так что кто-то в параллелизме видит только средство для повышения скорости, а для меня главное в нем - это решение проблем со сложностью.
Причудился кошмар - описание автомата в формате XML.Ну, или крайняк - JFSM. Представил также, что, видимо, есть Библия программиста в которой именно они сотворили Мир за шесть (или семь?) дней. И тогда все, что не описано в понятных им, как "как божий день", программных стандартах просто не существует. Т.е. теории автоматов - просто нет. Ну, не вписываются ее автоматы в программные стандарты. Академик Грушков, как и фон Нейман - рыдают, т.к. родились раньше времени - в допрограммистское время.
Но, вдруг, выясняется, что эти самые стандарты бессильны перед весьма простеньким автоматом. По крайней мере, на мою просьбу описать его так и не откликнулись. В этом смысле просто отмолчаться - не лучший вариант. Сказавши "а", нужно быть готовым сказать и "б".
Каким бы классным не было программирование, оно должно отвечать существующим реалиям и формальным териям. Все остальное - от лукавого. Когда я смотрю на описание, не кночи упомянутых, стандартов - оторопь берет. Нет, я их не отрицаю. Если они есть, но, наверное, они кому-то наужны. Но зачем и для чего? Но, если дан ответ на эти вопросы, то нет проблем по совсем простому описанию автомата в обычной для теории автоматов форме создать описание в любом стандарте - том же формате XML или JFSM. Но... зачем нужна "гора", которая гарантированно родит "мышь"?
Я не против стандартов. Они хорошая и полезная штука. Но всему свое место. Не надо их пихать куда попало. Сначала "программисту" нужно было бы разобраться с самим понятием автомата, чтобы понять: достаточно ли стандарта, чтобы его описать, удобно ли и компактно ли это будет и т.д. и т.п. Здесь "туча" проблем. Т.е. прежде, чем что-то советовать, нужно "иметь мужество" за них отвечать. А просто "слинять" - далеко, как уже выше сказано, далеко не самый лучший вариант.
Вот, как-то так... Прошу прощения за достаточно резкий коммент, но ... дилетанизм в определенных вопросах, если честно, достал. Будьте внимательнее, учитывайте и хотя бы просматривайте те ссылки, которые приводятся. От ошибок никто не застрахован. Но есть такие, за которые (и на которые) надо отвечать.
Я так понимаю , "божий инструмент", предложенный checkpoint, не позволяет описать простой автомат? ;)
И еще. "Криптограмма", сохраненная в файл, не предназначена для чтения человеком. Для него - в данном случае есть табличное описание автомата в форме FAutomaton. Кстати, на C++ описание автомата будет фактически таким же. Примеры этого есть в моих статьях (кстати, в той же [1]). И вообще, если на что-то не можете найти ответ, то по логике он должен быть по ссылке. Читайте внимательнее. Ссылки-то зачем-то тоже даются?
Так на объеснение этого и приведены ссылки (см. [1]).
Почему Вы не использовали что-то более стандартное (State Chart XML) ? Вот пример описания FSM котрый ясен как божий день:
Стандартом для автоматов является теория автоматов, которая рассматривает различные способы описания автоматов. Поэтому мое описание максимально приближено к этому стандарту, т.е. смотришь на граф (стандартная графическая форма описания автомата) и переводишь ее в табличную форму описания автомата (см. строки таблицы переходов в списке диалога FAutomaton). Куда уж проще и нагляднее?
А как перевести Ваш "божий день" в нормальную форму - граф, таблицу переходов не могу, если честно, представить. Для сравнения, чтобы было понятно (какой автомат Вы закодировали), закодируйте хотя бы автомат .Sensors2 (см. рис. 3 выше). Заодно сравним и с моим представлением. Если будет нагляднее, может, я свою "криптограмму" и изменю.
Чтобы не доводить дело до крайностей - до проявления мужества или, не дай Бог, проведения каких-либо специальных мероприятий, я в свое время (и достаточно давно) решил пойти по пути здавого смысла. Да, безусловно, интерфейс - важная часть, но это в первую очередь "одежка", а основное все же - смысл. В просторечии - ядро среды. Ее, скажем так, - мозги. На программистском сленге - вычислительная модель. Т.е. то, из-за чего и затеялся "вертеж". И то, что поначалу было только "схемкой" теперь стало реальность. Для кого-то, может, не столь модно "одетой", как того хотелось бы...
Я, конечно, думал про интерфейс, про то, каким он должен быть. И, безусловно, хотелось, чтобы он был красивым, наглядным, современным и далее по списку. Но я не модельер, а простой технарь. Даже где-то - программист ;) А потому, он (интерфейс), в конце концов, получился такой, какой есть. Он мне удобен.
Но, если теперь поговорить о здравом смысле, то в ВКПа без проблем можно создать любой интерфейс, т.е. любую "одежку". Это легко можно сделать через создание соотвествующей библиотеки. Как технарь, создав такую возможность, я просто перестал "париться" по его (интерфейсу) поводу. Одевайте, как хотите.
Но трогать мозги - другое дело. Тут уж, действительно, нужно мужество, чтобы переключиться на другое мышление - автоматное. Я через это прошел и потому знаю, о чем говорю.
Вы обратили внимание на "одежку". И Ваши замечания, наверное, даже справедливы. С чем-то я вполне согласен. Но, еще раз, как технарю, мне пока не до одежки. Я больше "кайфую" от того, что мне удалось убрать множество косяков. А, ведь, есть и другие, которые время от времени проявляются. Я больше доволен тем, что происходит это теперь достаточно редко. А есть планы и по развитию среды. Нет - не "одежки", а - функциональности, повышению надежности и т.д. и т.п. Многое - уже получилось, что-то - надо сделать, т.к. почти ясно как. Так что заняться есть чем...
Другими словами. Пока мне комфортно в существующей "одежке". Выявляется "дырочка" - латаю. Но в первую очередь думаю о "мозгах". И вот к ним у меня серьезных замечаний почти нет. А потому хотелось бы поговорить в первую очередь о них. Может я чего не вижу?
А интерфейс - дело десятое. Кому не нравится - нет проблем создать свой. Вот такой, думаю, вполне здравый смысл. Каждый должен зханиматься своим делом: кто-то дизайном ,а кто-то - мозгами. Я сосредоточен на последнем. И главное здесь, чтобы они (модельер и технарь) помогали друг другу, а не мешали.
Ваши бубличные члены не имеют никаких вменяемых значений до вызова FCreationOfLinksForVariables и если кто-то их случайно тронет до этого момента, то у вас будет UB.
Вы правы. Может быть, конечно, все. Но только давайте будем поспокойнее...
От дурака сложно придумать защиту. Чтобы проблем не было есть определенные правила создания связей между объектами-автоматами. Тут все ок. Работает и уже давно. Проблема в другом - в подвисании ссылок, т.к. автомат может быть удален из среды и все ссылки на него будут недействительны. Вот это актуально.
Я посмотрел Ваши статьи. Точнее не сами статьи, а их тематику. Что-то подобное, как мне кажется, я там узрел. Вы, похоже, тоже работаете со множеством активных взаимодействующих объектов. Может быть, даже их число меняется в динамике. Как Вы решаете эти проблемы, если только решаете? Типа посылки сообщения объекту, с которым была связь, но потом в силу его удаления - пропала. Как объект узнает, что его "друг" исчез? В общем случае - это даже множество объектов.
Скажем так, образно, речь идет о том, чтобы выдернуть логический элемент из схемы в процессе ее работы. Можно, конечно, остановить работу сети и переписать связи при удалении того или иного объекта, но, может, есть более красивое решение?
Выводы сделал. Больше постараюсь не вляпываться.
Это нормально. Это Ваше решение. Не хотите - навязывать что-то не буду. Действительно, кому-то и А.А.Шалыто - это норм. Я свое слово сказал, а Ваше дело или его услышать или проигнорировать.
Спасибо, теперь я "вооружен и очень опасен" :) Но вернемся в тему....
Так оно и есть - Visio. А, конечно, хотелось бы иметь "на борту" графику, но ... Графическая форма, несомненно, наглядна, удобна и т.д. но табличная форма (текстовая) иногда удобнее и уж совсем проще в реализации. В любом случае графическая форма должна быть преобразована в исполняемую форму и здесь табличная форма является именно таковой. А отсутствие "бортовой графики" я компенсирую средствfми визуализации, внедренными в ВКПа (их я и представил в последних статьях). Конечно, это несколько не то, но и они здорово помогают. Конечно, лучше бы иметь и то и другое. Например, в MATLAB-е есть и графическая и табличные формы представления автоматов. И это и правильно и хорошо. А в LabVIEW есть табличная форма описания автоматов?
Но в любом случае форма формой, но все же нужно иметь представление, какой автомат она реализует. Именоо в математическом смысле. Именно от этого надо "плясать". Например, мне кажется, что LabVIEW реализует фактически автоматы Мура. Если это так, то это несколько ограниячивает их возможности.
Не очень понятно автомат в LabVIEW абстрактный или структурный. По первому впечатлению - аьстрактный. Почему? Во-первых я вижу только один "символ", как условие перехода. Фактически имеем и один "символ" на выходе. С ними можно, конечно, связать те или иные отдельные действия и даже их последовательность, но это все же не то. Структурный автомат (с абстрактным состоянием) - более гибкая модель и ближе к реалиям.
Можно запустить несколько автоматов параллельно - это хорошо. Но какой это параллелизм? Надо проверять. А что проверять и как проверять, если нет формального определения этого параллелизма? Как, например, можно проверить операцию умножения (хотя бы 2*2), не зная результат?
"Шведский нож", думаю, потому и не зашел, что за его "лесом" возможностей не видно "деревьев" - формальной модели автоматов. Или это диаграммы Харела, как в UML? Например, в тот же MATLAB в их Stateflow однозначно сказано - Харел. И с ними все ясно. В LabVIEW я пока не знаю - одни мои догадки.Где-то про это сказано? Т.е. про формальную модель отдельного автомата, про формальную модель множества автоматов? Если это есть, то есть и точка отсчета и одновременно цель, которой должна соотвествовать реализация. Если нет - то видим "шведские" варианты "леса" из завалов "деревьев".
Например, раньше к этому процессу - созданию новых вычислительных моделей подходили много строже. Считали, что та же машина Тьюринга - это абсолютный эталон, а потому, когда предлагалась новая модель, то приводилась и формальная процедура приведения к ней. То же самое делали по отношению к автоматам. Сейчас этим просто не замарачиваются. А так быть не должно. Хотя есть ;)
Как я убедился автоматы в LabVIEW достаточно интересны, но где "точка отсчета"? Например, срабатываение двух переходов - маразм с точки зрения теории обычной модели модели. Это грубейшая ошибка, а мы еще обсуждаем, какой переход может сработать ;) Подобную модель просто нужно корректировать или устранить подобную вещь, а не думать, что и за чем будет выполняться. Кто-то с этим явно не согласиться, но ... Реализаци математики, в которой 2*2=5 для кого-то может иметь важное значение, но, во-первых, необходимость такой математики нужно еще обосновать, а, во-вторых, сравнить с той математикой в которой 2*2= 4.
Например, я не понимаю, что такое квантовый компьютер. Как на нем реализовать простейший алгоритм, например, нахождение наибольшего общего делителя (НОД). Понятие алгоритма, ведь, ни кто еще не отменял. Он что - реализует какие-то иные алгоритмы? Но если ты "компьютер", то будь добр реализовать любые алгоритмы. Ну, ладно, ты что-то там считаешь очень сложное для понимания... Но неужели это нельзя представить в форме алгоритма и сымитировать вычисление на обычном компьютере? Пусть это будет даже очень и очень медленно.
К чему это я так пространно? Можно много обсуждать автоматы. но если нет процедур их сравнения, то это почти бессмысленный разговор дилетантов. Типа есть Бог или нет. Наука говорит - нет, вера - есть. Я почему-то больше доверяю науке ;) С автоматами проще - есть теория автоматов. Поэтому для меня автомат, имеющий несколько активных переходв - это "божественный автомат" ;-). Он выпадает из моего научного понимания модели автомата. Да, есть недетерминированные автоматы. Но это совсем другое дело. Там, во-первых, срабатывают все такие переходы, а, во-вторых, они приводятся к обычным - детерминированным автоматам. Есть еще, правда, вероятностные автоматы. Но, надеюсь, в LabVIEW речь совсем не о них ;)
Вот, честно - впечатлен!
Никак не ожидал, что что-то подобное есть в LabVIEW. Конечно, вопросы по автоматам есть. Возможно, потому, что для понимания надо было бы прощупать их ручками.
Итак, по автоматам. Ну, например, во-первых, - переходы. На мой взгляд как-то слишком уж в лоб. Хотелось бы иметь, как минимум, конъюкции условий перехода. Т.е. что-то типа transition1transition3 - подобно x1x3 или transition1^transition3 - если нужно что-то типа x1^x3. Т.е. иметь возможность составлять логические выражения. Также важно, если условие перехода включает несколько transitions, то они должны восприниматься, как параллельные.
Во-вторых, - действия. В классических автоматах есть действия по типу Мили и/или типу Мура. Здесь, похоже, только по типу Мура. При этом я не воспринимаю их, как действия реализуемые В состояниях, а как действия ПРИ них. Хотя полное впечатление складывается, что они исполняются при входе в состояния. Это совсем не по автоматному :) Не устраивает и их последовательное исполнение. Надо бы, если операции в рамках отдельного действия, то они последовательные. Если это несколько действий, то - параллельные. Ну, как в ВКПа ;)
Хотелось бы иметь четкое понимание того, как ведут себя сети автоматов, если их, конечно, можно создавать вообще. В ВКПа - это рядовое дело. Собственно, ради них и следует занимться автоматным программированием. Отдельные автоматы - одно, сети - другой уровень. Это как последовательное и паралельное программирование. Два разных программирования.
О технологии проектирования автоматолв. В чем-то аналогично проектируются визуальные автоматы и в ВКПа. Конечно, в LabVIEW сделано много шикарнее и визуальнее, но принцип примерно тот же - через диалоги сформировать нужные предикаты/действия. Что-то подобное у меня тоже есть в планах, но пока до этого просто руки не доходят. .ВКпа, как мне представляется, пока берет моделью ;). Ну, а если мне нужен автомат посложнее, то я просто его делаю на С++. А с его возможностями ни какая визуализация не сравнится. Как мне показалось и в LabVIEWЮ когда не хватает визуальных возможностей, поступают также на уровне тех же библиотек. Собственно в ВКПа такие же библиотеки, но только на С++.
При этом, навскидку, модель автоматов Stateflow в MATLAB помощнее будет автоматов в LabVIEW. Хотя, не исключаю, модель и одна (типа UML). Но, еще раз, - красиво. Этого ВКПа, что там скрывать, не хватает. Но опять же это все дело техники. Примеры, как минимум, визуальной реализации автоматов в LabVIEW и в MATLAB, демонстатруют это Во-первых, КАК это можно сделать, а, во-вторых, что каких-то принципиальных препятствий для подобной реализации нет.
Еще раз - просто впечатлило! Пока мы тут боремся за первенство термина "автоматного програмирования" в рамках "СВИСТ-технологии" или увлечены некими "традиционными ценностями", кто-то просто "лопатит код" и уже давно не сводит проектирование автомтов к оператору типа SWITCH. Вы показали это очень убедительно и просто наглядно (хочется научиться делать такие же гифки:).
Я даже уверен, что когда-то автоматная модель ВКПа будет реализована в LabVIEW или MATLAB ;) Все идет в эту сторону. А ведь когда-то, лет этак 30-40 назад (эх, как время летит!:), было объявлено, что автоматы исчерпали свои возможности. Даже придумали было .сети Петри. Только, кто теперь помнит про эти сети Петри, и какой бум, особенно в последнее время, вокруг автоматов. Пусть тока это не те автоматы, но, как говорится, - еще не вечер ;)
Здравствуйте! Приятно вновь встретиться ;)
Все это очень интересно, но... Я вижу графы, которые, ну, очень похожи на графы автоматов, но как Вы их создали? Для меня автомат - это прежде всего язык проектирования, а здесь? Ну, например. Есть переходы, но нет условий переходов. А действия где? Есть состояния, а при них - имена или имена действий или и то и другое? Т.е. складывается впечатление, что данные автоматы - это некие анимированные картинки?
Рассейте мои сомнения... ;)
Тут надо бы понимать, что они (адепты) понимали под "образом мышления". Программист проектирует алгоритмы. В этом смысле язык программирования - текстовая форма алгоритма, а граф (блок-схема, автомат и т.п.) - графическая. Понятно, как первая превращается в код для процессора. То же самое можно сделать и с графической формой. В конце концов можно "мыслить" образно графом, нарисовать его, а потом ручками перейти от крафической формы к текстовой. Но первый Ваш "образ" - это граф. Этим отличается отличие "графического мышления" от "текстового". Но и в основе ДРАКОНА и любого языка программирования понятие блок-схемы. И вот в этом смысле адепты были не правы, т.к. используете Вы ДРАКОН или нет, но в основе подобного мышления одно - "блок-схемное мышление".
Когда Вы используете автоматную модель представления алгоритма, то у Вас поневоле будет и другое мышление - автоматное. Я, например, достаточно давно не "мыслю" блок-схемами, а - автоматами. И это, действительно, другое "мышления". От "блок-схемного" отказаться сразу конечно сложно, но вполне возможно. Это я говорю, основываясь на собственном опыте.
Можно, конечно, считать, что "графическое" и "текстовое" - это разные формы мышления. И где-то это так. Но все же кардинальным образом мышление изменяет используемая модель вычислений. В этом смысле ДРАКОН не меняет мышление. И только "автоматное мышление" - иное мышление, как, например, существует "объектное .мышление".
В этом нет ни чего плохого. Другое дело, ЧТО они преобразуют. Догадываетесь о чем речь?
В Microsoft Visio 2007
Совсем нет. Наоборот, хочу отговорить от этой мысли ;) Вы только зря потратите свои сылы. Просто, преобразуя ручками блок-схемы в автоматы, Вы поймете, чем автоматы отличаются от блок-схем. Это, первое. Второе - почему здесь абстрактные автоматы ни при чем - нужны структурные автоматы (с абстрактным состоянием). Третье - созреете к переходу от отдельных автоматам к сетям. Это, чтобы параллельно программировать.
Да, чуть не забыл, нужно выбрать, а, может, и создать свой метод кодирования автоматов для того языка программирования, на котором Вы работаете. Все это лучше сначала делать ручками. Через них просто лучше доходит. А уж потом, если будет желание, время и понимание того, что это просто необходимо и без этого просто жизни нет, то тогда можно и "создавать преобразователи".
Т.е. сначала нужно врубиться в идею автоматного программирования, а уж потом приступать к ее реализации. Не надо ставить "телегу впереди лошади". Во, как-то так - на пальцах, так сказать.
Это я делюсь своим опытом :) Конечно, доходить до всего самому сложно, долго и тяжело, но приготовьтесь и к этому... Хотя, думаю, Вам будет много проще, чем это было мне ;) Плохо ли хорошо, но все это описано в моих статьях здесь на Хабре. Осталось только... "малость подучиться" :)
Вы от него много хотите ;) Он достаточно наглядный и хороший пример визуального програмирования. Причем использованный в реальной работе. Другое дело, что можно критиковать или обсуждать вычислительную модель, положенную в его основу. Это модель блок-схем. Но в рамках даннной модели до сих пор работают почти все языки программирования. Так что в этом смысле он им соотвествует.
ДРАКОН можно было бы внедрить почти в любой язык програмирования с учетом уже современных их возможностей, но ... Блок-схемы это все же программная модель, которую давно пора заменить на что-то другое. Например, на те же автоматы ;) .
Ответ просто один - схему. Но ее еще ужно создать.
Было бы хорошо, если бы "мудрецы" пояснили, как из Ваших блок-схем создать автоматы. Это реально просто - стандартная процедура. Вот Ваша блок-схема, подготовленная к рисованию графа-автомата:
Процедура разметки блок-схемы
А так, Вы на правильном пути:)
Вы заставили меня задуматься;) Я, конечно, не уберу ^, но, возможно, добавлю !. Как бы на любителя.
Те "рисовалки", которые мне попадались, меня не устраивали. По многим причинам. Поэтому просто рисую автоматы в Visio.
Интеграция, как уже сказал, мне видится через полный доступ ко всей памяти ПЛК, используя любой протокол. Например, modbus. Сделали проект, отработали, отладили дальше - в код ПЛК. Сейчас автоматы - ручками. Кодирование - это самое простое в программировании. А дальше - как получится, но, скорее всего, этим я заниматься не буду.
Да, SFC есть. Есть даже официальный документ, в котором описано кодирование на нем автоматов. Но - не то..Я, конечно, поглядывал в его сторону (и даже давно), но, как оказалось, проще сделать на LD. Так, как я уже этот процесс описал.
Ну, а насчет использования. Как сделаю связь по протоколу, то, может, даже опишу и тогда будем смотеть, что с этим делать. По крайней мере, это самый реальный вариант интеграции ВКПа с ПЛК. Подобные вещи я делал (пусть и не с ПЛК и, к сожалению, не по modbus). Но здесь все достаточно понятно, т.к. делается аналогично, да и цели ясны ;).
Разницы большой между !x1 и ^x1 нет. Все это условности. Мне больше нравится вторая форма.
Про дуги. Не надо путать имена входных каналов - x1, x2, ... xM, y1, y2, ...yN и функции-предикаты и функции-действия им сопоставленные. Автомат по определению - это MxN-полюсник. На дугах пишутся имена каналов, а функции, которые могут быть достаточно сложными - расшифровываются рядом. Так точнее. Хотя, может быть, есть и некоторые проблемы с наглядностью. Но и расшифровка непосредственно на дугах содержимое предикатов и действий - лишнее загромождение графа, да и не все можно порой записать, т.е. уместить. Все это наглядно демонстрируют автоматы, созданные програмистами. Они упрямо хотят вписать в граф автомата на его переходы и в состояния явно невписуемое :).
По поводу связи. В моем варианте (когда связь ПЛК-ПК есть) проектирование ведется на языке автоматов (те же визуальные автоматы в форме FAutomaton). А после того, как все отработано переложить автомат пусть даже ручками - не большая проблема. Делается "по щелчку" на STL или LD (см. опять же мою ссылку). Конечно, хорошо бы иметь компилятор, но ... нужно быть реалистом. Это все возможно, но требует не только денег на реализацию, но и знаний, как это сделать.Часто есть одно, но нет другого или наоборот ;)
Главное, чтобы этот интерфейс не вызывал отторжения у автора. Пока терплю ;) Другие могут предложить (было бы весьма интерсно посмотреть) и даже реализовать свой. Пока, если честно, у меня подобный "пазл" как-то не складывается.
В чем конретно я перемудрил? Не признаю гаданий. Если по поводу символа отрицания - ^, то хотелось бы посмотреть на другие варианты.Остальное - как в книжках по автоматам.
По поводу "загрузить" и "исполнить". Может быть несколько вариантов. Самый реальный описан в моей статье, т.е. просто ручками. Это мой текущий вариант работы. Есть другой на мой взгляд очень хороший и даже красивый вариант: связать, например, по modbus ПК (с ВКПа) с ПЛК. Дальше создаем автоматы в ВКПа, общаясь в реальном времени с оборудованием через ПЛК, имея, конечно, полный доступ к его памями. Отработав все, реализуем автоматы, как в указанной статье. По сути это аналог режима отладки обычной среды разработки для ПЛК. Только в данном случае средой разработки выступает ВКПа.
Думаю, что Qt поддерживает SQL.Так уж сложилось что в ВКПа на Visual Studio я работал с БД, а тут как-то не было нужды. Но уверен, что с этим (БД) проблем не должно, т.к. и там и здесь все тот же C++. Вот даже нашел быстренько.
Вы так и поняли. Все, что можно сделать в Qt и на С++, можно сделать и в ВКПа. Нужны только знания, время и ... деньги. Это, так сказать, по умолчанию. Поэтому, если речь идет обо мне лично, то, может, и не смог бы. Тут даже и спорить не буду или что-то доказывать. Ну а тот, кто хорошо знает возможности Qt и C++, думаю, без проблем. Потому как о каких-то ограничениях здесь я не слышал. Может, подскажете? Да и Вы, судя по статье, намеревались применить что-то типа C#. Неужели на С# можно, а на С++ нельзя? Подозреваю, что можно ;)
Но чуть серьезнее. Если бы передо мной стояла такая же задача... Во-первых, реализовал/нашел бы протоколы. Во-вторых, сделал бы операции/команды, которых нет на визуальном уровне. В-третьих, оформил бы сценарии тестирования в форме автоматов. Ну и, в-четвертых, использовал любую базу данных. Кстати, есть интересный замысел, и, возможно, что-то подобное мне и предстоит сделать... ;)
Да, и еще. Визуальный уровень можно и не подключать, а сделать все на С++. По большей части так и делаю. Протоколы, "ителлектуальное общение", параллелизм - все это обычное дело. Есть готовое - применяю, нет - дорабатываю. И это не только "учебные программки" (они в первую очередь рассчитаны на тех, кто что-то "подозревает"), а вполне себе серьезые вещи. Кстати, разработка самой среды ВКПа, думаю, посложнее будет, чем описанный Вами проект.
А приведенный пример гильотины - это часть реального проекта. Один в один. Более того, в процессе написания статей обнаружились определенные проблемы. Но об этом уже в следующей части. Но вот если б Вы обнаружили эти или какие-то другие проблемы в работе модели, то я был бы, если честно, удивлен. Я бы их даже бы проверил ;)
Хотелось бы, чтобы Ваши подозрения на чем-то основывались. Ну, например, реализуйте на LabVIEW простой алгоритм контроля датчиков гильотины. Получится - прекрасно. Можно будет сравнить. Если это просто "ля-ля", то к чему? Показать, что, мол, - "плавали-знаем"?
Например. При обсуждении моей статьи "Параллелизм без потоков: очевидно и вероятно" @AndreyDmitriev попробовал все, о чем он "подозревал", изложмить именно на LabVIEW. Вот за подобное - спасибо. Я за подобную критику, а не за некие "подозрения".
Итак, повторю. Если знаете LabVIEW, то воплотите свои "подозрения" в жизнь, реализовав мою просьбу - создать тот же алгоритм контроля датчиков. В ВКПа это совсем просто. А на LabWIEW?
Соотвественно и про Quantum Leaps. Я даже нашел статью на Хабре - Quantum Leaps QP и UML statecharts. Вроде про автоматы. Я думал, что про них если не все, то мное знаю. Но, прочитав статью, "подозреваю", что я просто дебил, т.к. совершенно ни чего не понял. Просто не понял какой там алгоритм рассматривается? Видимо про какрй-то счетчик, т.к. есть "count", но как над ним издеваются - за пределами моего разумения. Как, используя QP, т.е. материал этой статьи, реализовать тот же автомат контроля датчиков? Проблема - тьфу, а мозги выворачиваются на изнанку..
В ВКПа я легко преобразую любой автомат в
презираемые всемиблок-схему (соотвественно и любую блок-схему в автомат) и реализую ее затем на любом языке. Без всякой ВКПа и автоматов. Но как это сделать в QP и том же UML? "Тайна сия велика есть"? ;)Это Quantum Leaps? Квантовое программирование, так кажется?
В ВКПа это тоже, конечно, есть. Без этого - ни как и ни куда. И даже дано формальное определение вложенного автомата. Есть даже вложенные инерционные автоматы. Обо все этом в статьях по ссылкам, о которых я говорил в предисловии (т.е. в 1-й статье на тему ВКПа)
И по поводу сложности Еще эффективнее бороться со сложностью с помощью параллелизма. Даже не имея вложенности, все вопросы можно решать с помощью параллелизма. Так что кто-то в параллелизме видит только средство для повышения скорости, а для меня главное в нем - это решение проблем со сложностью.
Причудился кошмар - описание автомата в формате XML.Ну, или крайняк - JFSM. Представил также, что, видимо, есть Библия программиста в которой именно они сотворили Мир за шесть (или семь?) дней. И тогда все, что не описано в понятных им, как "как божий день", программных стандартах просто не существует. Т.е. теории автоматов - просто нет. Ну, не вписываются ее автоматы в программные стандарты. Академик Грушков, как и фон Нейман - рыдают, т.к. родились раньше времени - в допрограммистское время.
Но, вдруг, выясняется, что эти самые стандарты бессильны перед весьма простеньким автоматом. По крайней мере, на мою просьбу описать его так и не откликнулись. В этом смысле просто отмолчаться - не лучший вариант. Сказавши "а", нужно быть готовым сказать и "б".
Каким бы классным не было программирование, оно должно отвечать существующим реалиям и формальным териям. Все остальное - от лукавого. Когда я смотрю на описание, не кночи упомянутых, стандартов - оторопь берет. Нет, я их не отрицаю. Если они есть, но, наверное, они кому-то наужны. Но зачем и для чего? Но, если дан ответ на эти вопросы, то нет проблем по совсем простому описанию автомата в обычной для теории автоматов форме создать описание в любом стандарте - том же формате XML или JFSM. Но... зачем нужна "гора", которая гарантированно родит "мышь"?
Я не против стандартов. Они хорошая и полезная штука. Но всему свое место. Не надо их пихать куда попало. Сначала "программисту" нужно было бы разобраться с самим понятием автомата, чтобы понять: достаточно ли стандарта, чтобы его описать, удобно ли и компактно ли это будет и т.д. и т.п. Здесь "туча" проблем. Т.е. прежде, чем что-то советовать, нужно "иметь мужество" за них отвечать. А просто "слинять" - далеко, как уже выше сказано, далеко не самый лучший вариант.
Вот, как-то так... Прошу прощения за достаточно резкий коммент, но ... дилетанизм в определенных вопросах, если честно, достал. Будьте внимательнее, учитывайте и хотя бы просматривайте те ссылки, которые приводятся. От ошибок никто не застрахован. Но есть такие, за которые (и на которые) надо отвечать.
Я так понимаю , "божий инструмент", предложенный checkpoint, не позволяет описать простой автомат? ;)
И еще. "Криптограмма", сохраненная в файл, не предназначена для чтения человеком. Для него - в данном случае есть табличное описание автомата в форме FAutomaton. Кстати, на C++ описание автомата будет фактически таким же. Примеры этого есть в моих статьях (кстати, в той же [1]). И вообще, если на что-то не можете найти ответ, то по логике он должен быть по ссылке. Читайте внимательнее. Ссылки-то зачем-то тоже даются?
Так на объеснение этого и приведены ссылки (см. [1]).
Стандартом для автоматов является теория автоматов, которая рассматривает различные способы описания автоматов. Поэтому мое описание максимально приближено к этому стандарту, т.е. смотришь на граф (стандартная графическая форма описания автомата) и переводишь ее в табличную форму описания автомата (см. строки таблицы переходов в списке диалога FAutomaton). Куда уж проще и нагляднее?
А как перевести Ваш "божий день" в нормальную форму - граф, таблицу переходов не могу, если честно, представить. Для сравнения, чтобы было понятно (какой автомат Вы закодировали), закодируйте хотя бы автомат .Sensors2 (см. рис. 3 выше). Заодно сравним и с моим представлением. Если будет нагляднее, может, я свою "криптограмму" и изменю.
Чтобы не доводить дело до крайностей - до проявления мужества или, не дай Бог, проведения каких-либо специальных мероприятий, я в свое время (и достаточно давно) решил пойти по пути здавого смысла. Да, безусловно, интерфейс - важная часть, но это в первую очередь "одежка", а основное все же - смысл. В просторечии - ядро среды. Ее, скажем так, - мозги. На программистском сленге - вычислительная модель. Т.е. то, из-за чего и затеялся "вертеж". И то, что поначалу было только "схемкой" теперь стало реальность. Для кого-то, может, не столь модно "одетой", как того хотелось бы...
Я, конечно, думал про интерфейс, про то, каким он должен быть. И, безусловно, хотелось, чтобы он был красивым, наглядным, современным и далее по списку. Но я не модельер, а простой технарь. Даже где-то - программист ;) А потому, он (интерфейс), в конце концов, получился такой, какой есть. Он мне удобен.
Но, если теперь поговорить о здравом смысле, то в ВКПа без проблем можно создать любой интерфейс, т.е. любую "одежку". Это легко можно сделать через создание соотвествующей библиотеки. Как технарь, создав такую возможность, я просто перестал "париться" по его (интерфейсу) поводу. Одевайте, как хотите.
Но трогать мозги - другое дело. Тут уж, действительно, нужно мужество, чтобы переключиться на другое мышление - автоматное. Я через это прошел и потому знаю, о чем говорю.
Вы обратили внимание на "одежку". И Ваши замечания, наверное, даже справедливы. С чем-то я вполне согласен. Но, еще раз, как технарю, мне пока не до одежки. Я больше "кайфую" от того, что мне удалось убрать множество косяков. А, ведь, есть и другие, которые время от времени проявляются. Я больше доволен тем, что происходит это теперь достаточно редко. А есть планы и по развитию среды. Нет - не "одежки", а - функциональности, повышению надежности и т.д. и т.п. Многое - уже получилось, что-то - надо сделать, т.к. почти ясно как. Так что заняться есть чем...
Другими словами. Пока мне комфортно в существующей "одежке". Выявляется "дырочка" - латаю. Но в первую очередь думаю о "мозгах". И вот к ним у меня серьезных замечаний почти нет. А потому хотелось бы поговорить в первую очередь о них. Может я чего не вижу?
А интерфейс - дело десятое. Кому не нравится - нет проблем создать свой. Вот такой, думаю, вполне здравый смысл. Каждый должен зханиматься своим делом: кто-то дизайном ,а кто-то - мозгами. Я сосредоточен на последнем. И главное здесь, чтобы они (модельер и технарь) помогали друг другу, а не мешали.
Вы правы. Может быть, конечно, все. Но только давайте будем поспокойнее...
От дурака сложно придумать защиту. Чтобы проблем не было есть определенные правила создания связей между объектами-автоматами. Тут все ок. Работает и уже давно. Проблема в другом - в подвисании ссылок, т.к. автомат может быть удален из среды и все ссылки на него будут недействительны. Вот это актуально.
Я посмотрел Ваши статьи. Точнее не сами статьи, а их тематику. Что-то подобное, как мне кажется, я там узрел. Вы, похоже, тоже работаете со множеством активных взаимодействующих объектов. Может быть, даже их число меняется в динамике. Как Вы решаете эти проблемы, если только решаете? Типа посылки сообщения объекту, с которым была связь, но потом в силу его удаления - пропала. Как объект узнает, что его "друг" исчез? В общем случае - это даже множество объектов.
Скажем так, образно, речь идет о том, чтобы выдернуть логический элемент из схемы в процессе ее работы. Можно, конечно, остановить работу сети и переписать связи при удалении того или иного объекта, но, может, есть более красивое решение?
Это нормально. Это Ваше решение. Не хотите - навязывать что-то не буду. Действительно, кому-то и А.А.Шалыто - это норм. Я свое слово сказал, а Ваше дело или его услышать или проигнорировать.