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

Но кстати затронута интересная тема. Это автоматическое формирование управляющих алгоритмов. Потому, что здесь нет какого-то формального подхода, непонятно вообще с чего начать. Допустим, мы хотим сделать контроллер стиральной машины. На входе пульт управления, и с десяток датчиков. На выходе с десяток исполнительных механизмов и дисплей. А что дальше? Дальше, сейчас так принято, всё отдаётся на откуп программисту. Он "как-нибудь" придумает алгоритм и программу. Это в худшем случае. В лучшем пытаются составить алгоритм в какой-либо формальной форме, например, в виде блок-схем или схем конечных автоматов. Но здесь и заключается самая главная загадка -- как это сделать? Нарисовали кружок начального состояния. А дальше что? Сколько должно быть различимых состояний? Какие условия переходов между ними. Каким-то интуитивным способом, по наитию, находится скелет автомата, и дальше уже додумываются детали. Потом можно задать какие-то проверочные условия и формальными средствами промоделировать алгоритм, проверить его на соответствие этим условиям (см. детали: http://caxapa.ru/841665.html). Далеко не все так делают, части и этот этап опускается. Да и он не гарантирует правильную работу. Нужные проверочные условия попросту могли быть не заданы и в каком-то состоянии алгоритм сделать что-то не то, что от него ожидали. Конечно, для простых автоматов с числом состояний меньше десятка это всё может быть даже не очень актуально, когда они полностью обозримы и проверяемы руками. А большие системы могут дробиться на иерархические системы взаимодействующих автоматов по методике им. Шалыто. Но есть же и действительно сложные системы, и иерархическая система автоматов не факт, что составлена правильно (каждый отдельный автомат вроде корректен, а система в целом работает неправильно, т.к. автоматы между собой неправильно соединены, например). В сложной и большой системе составить схемы автоматов руками, по наитию, может быть не просто или невозможно. Но какие тогда подходы искать? И я думаю, пролог здесь был упомянут не зря. Было бы очень интересно задавать некоторые заранее известные свойства управляющего алгоритма в виде логических условий и пытаться сделать вывод, что управляющий алгоритм с такими условиями невозможен, значит условия нужно изменять, или возможно построение очень большого числа алгоритмов удовлетворяющих условиям, значит число условий нужно увеличивать. И так пока не получится один алгоритм, найденный автоматически. И "программой" будет уже не сам алгоритм, не схема его конечного автомата, а набор логических правил, согласно которому может быть сгенерирована данная схема (которая потом может быть закодирована на языке C и реализована в приборе). Существуют ли такие системы? Не знаю, было бы интересно узнать. В принципе дальнейшим развитием могло бы быть не генерирование алгоритмов или программ на этапе разработки, а выполнение поиска алгоритма прямо в рантайме, по заданным условиям, и тут же его выполнение. Но здесь не совсем понятно, что делать, если возможных алгоритмов получается много, или не получается ни одного. На этапе разработки условия могли быть подправлены людьми, а в рантайме не совсем понятно что делать. И такой подход, очевидно, подразумевает вариативность задаваемых условий, иначе в нём смысла нет. Например, можно не кодировать какие-либо условия прямо в схему автомата, а генерировать разные автоматы, более простые, за счёт меньшего числа условий и состояний. И в момент выполнения выбирать автомат соответствующий текущим заданным условиям, или если выбранный автомат не может решить задачу, заменять его на другой, с другими условиями.