caxapa.ru :: Нельзя объять необъятное(С)

Пятница
3 сентября Вход |Карта сайта |Предприятия |Upload |**eeWiki** |
	О смысле всего сущего • 0xFF • Средства и методы разработки • Мобильная и беспроводная связь • Объявления • Webmaster •		•Микроконтроллеры •ARM •AVR •PIC •MSP •Программируемая логика •DSP •Схемы, платы, компоненты
Средства и методы разработки

Vit (13.06.2009 15:27, ссылка) , в ответ на Автоматное программирование - ну почему все так тоскливо в реале? автор: Evgeny_CD

Нельзя объять необъятное(С)

"Конечные автоматы" это определение из теории алгоритмов и относится именно к алгоритмам, а не непосредственно к технологии их использования при программировании. В то же время термин "автоматное программирование" популяризован в рамках творчества одного г-на (кажется Шалыто) как технология, с математическим обоснованием её эффективности. Не осилил. Также не думаю, что стОит всё в кучу смешивать. я хоть и тоже дал линк на википедию, думаю, что по Вашему линку именно такая куча.
Использование на практике описания работы некоего устройства (алгоритма) как конкретного конечного автомата чаще гораздо бОльший геморрой, чем это кажется. Ведь есть ортогональные вещи - синхронные и асинхронные процессы, изоляция задачи и межпроцессное взаимодействие, константы, инициализируемые и неинициализируемые переменные. Точно так же алгоритм может быть представлен в виде дерева и графов.
Я использую FSM довольно часто, но для решения конкретных задач, которые сами по себе легко поддаются подобному описанию. ИМХО, ввиду объективных сложностей нецелесообразно описывать все задачи как FSM, а так как многозадачность вроде как норма, то использовать одну отвёртку для разных шлицев как-то не того. Точно так же можно вспомнить ЕСКД, где, например, схемы электрические бывают принципиальными, функциональными, структурными и смешанными - у них разное назначение.
А проектирование ПО, ИМХО, должно начинаться с описания требований, а далее с создания спецификации (перечня) программных модулей. Структурированность такого перечня часто приводит к оперированию уже с объектами, при этом действия становятся методами и, как ни странно, часто далее не важен способ описания алгоритма, т.е. вся эта чехарда с UML становится нужна только для моделирования (что само по себе вполне может быть подспорьем при программировании) и/или оформления части документации (например, "алгоритм управления блоком наполнения емкости одоранта в режиме пониженного расхода газа при запрещенном дозировании" и рядом "алгоритм управления блоком наполнения емкости одоранта в режиме среднего расхода газа при разрешенном дозировании при измеряемом уровне протечки").
Так что если для описания взаимодействия контроллера с окружающим миром можно написать строчку "протокол Modbus, карта переменных представлена в Приложении Е", то если этого достаточно, бОльшего не нужно. А для реализации оного в конкретной программе берётся с полочки либа и пишется та же карта и соответствующий набор пользовательских функций. Точно так же не нужно очередной раз описывать релейные, ПИ- и ПИД-регуляторы, если всего-лишь меняются параметры. Опять же не имеет смысла описывать с помощью FSM те же скриптоподобные действия, например, настройка GSM-модема, задание параметров точки доступа, создание GPRS-соединения, отправка данных на первый сервер с использованием поочередно HHTP-get, HTTP-post, SMTP, те же действия для второго сервера, закрытие соединения - хоть и беспроблемно решается на FSM, но такой набор действий настолько очевиден, что разукрупнение не имеет смысла - один раз пишется модуль отправки и определяется набор конфигурационных параметров к нему, затем описание в виде повторяющегося алгоритма больше никому, кроме первоклашки, уже не нужно - только может затруднять чтение и понимание программы/алгоритма.
Введение в обиход всяких "иерархических FSM" при этом видится всего-лишь неуклюжей попыткой структурирования задачи. Как у Форда "Вы можете выбрать автомобиль любого цвета, при условии что этот цвет черный"(С) (прошу сильно не пинать, если цитату привёл не точно).
Не приживутся базы описания состояний для универсального генератора программ - некому, некогда и не за что этим заниматься.

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