Здравствуйте, DarkGray, Вы писали:

DG>Siemens, beckhoff, schneider и т.д. — сейчас все предлагают визуальные среды для программирования на FBD, который по сути графическое представление ассемблера. Дракон по сравнению с FBD — это шаг вперед, это графическое представление языков уровня алгола или паскаля.
DG>Соответственно, дракон в нише для программирования электроники домофона, гаражных ворот, бойлерной, мини-конвеера для сахарного заводика и т.д. — смотрится перспективно, по сравнению с тем, что сейчас там есть.
Почему? Это всё обычные примеры КА. ДРАКОН асболютно отстойно подходит для них, так как переходы между состояниями получаются скрытыми в мелочах из действий.

Тем более, что в ДРАКОНе абсолютно отсутствуют понятия инвариантов и программирования по контракту, что как раз весьма важно для вещей типа бойлерной или контроллера светофора. Не хотелось бы, чтобы у светофора горело одновременно два зелёных света. Т.е. нельзя формально взять схему и показать, используя эту схему, что никогда не возможно наличие конфликтующих зелёных. Точнее можно, но потребуется обычное формальное текстовое доказательство.

Для сравнения, в JPF от НАСА есть интересный режим, когда задаётся конечный автомат состояний (в виде графической схемы!) и верификатор проверяет, что код соответствует этой схеме. Причём таких схем может быть несколько.