Средства и методы разработки

имеющих

на входе данные/реакцию автомата от естественных датчиков или естественных, натуральных событий (читай - непредсказуемых). На автоматы хорошо и мило ложатся ТОЛЬКО примитивные, ПРЕДСКАЗУЕМЫЕ, четко определенные "автоматные" алгоритмы не обладающие никакой развитой логикой ветвлений, под-ветвлений, циклов состояний и т.д., чтобы работало "запрограммил и забыл". Когда-то я этих автоматов в компьютерных игрушках еще даже на ассемблере или на J2ME понаделал десятками, всё работало как часы (ржака, в книжке Шалыто "автоматизируют" именно часы, всё понятно, да?). Я не буду описывать как устроены и работают автоматы (автоматный способ написания программы), я напишу лишь суть, а суть в том что отлаживать автоматные программы весьма непросто, можно сказать что прямых методов отладки автоматов при обычном программировании не предусмотрено. И если ты сам не сделал внутренний отладчик автомата, будет очень тяжело. Всё очень легко и просто, пока автомат простенький и свои состояния проходит линейно. Но как только состояний переваливает за 20-ку, как только он начинает по ним ходить циклами, подциклами и проч, как только у тебя появляются под-автоматы (иерархия состояний), мыль веревку. А суть в том что несмотря на то, что это запрограммировал ты сам, несмотря на то что вот вроде бы у тебя распечатан граф переходов, ПОНИМАТЬ и ОТЛАЖИВАТЬ поведение автомата становится сложно, это не простепать логические условия программы. Поэтому за исключением простеньких предсказуемых случаев жесткой последовательности выполнения, с автоматами я советую связываться с большой осторожностью из-за "античеловеческой" специфики сложных автоматов. Дело как в отладке прикладной логики, так и в том что написанная C/C++ программа вообще-то не отражает логику (семантику) работы автомата, т.е. user application логику, являясь всего лишь обеспечением работы автомата. Сразу дам совет - "укротить" работу сложного автомата (повторюсь, не говоря уже о под-автоматах итд) можно исключительно только применив внешние методы отладки. В моем случае как пример полную телеметрию и разборку реакции переключения автомата на графиках телеметрии. Опыт - сын ошибок трудных. Забудь всяк сюда входящий о текстовых логах! От разборки логов нагенерированных автоматом в дурку всяк попадет уже на второй месяц! (Мой автомат отрабатывает с частотой реакции/переключения на события <= 1kHz) И не программировать автомат "напрямую в коде", использовать по-возможности табличный метод контроля за переходами состояний. Все равно, пытаться отлаживать сложный автомат, отлаживая по C-шный код это очень тяжело.

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

Против автоматов, как их замена придуман ряд способов, например https://www.chiark.greenend.org.uk/~sgtatham/coroutines.html - почитать очень полезно, как развитие этой идеи - Protothreads, и как раз, вот настоящее потоковое программирование, только не с объектами синхронизации, а посоветую тебе Message-Oriented programming (message passing). Всё это легко ложится и давно положено на C. Я свое вдохновение черпал у SGI (Silicon Graphics), смотрим как они реализовали Message passing и потоки на pure C, MIPS R4300i, (даже без C standard library), внутри библиотеки LibUltra.