А_МУР писал(а):
Alexey_Donskoy писал(а):
- по возможности не использовать т.н. "силуэт", поскольку он рвёт маршруты (по сути он ничуть не лучше классической общей шины на электрических схемах - источника труднообнаружимых ошибок);
- если таки использовать "силуэт", то т.н. "веточные циклы" должны быть строго под запретом;
Алексей совершенно прав, в силуэте найти ошибку практически не возможно, либо Силуэт нужно дорабатывать, либо вводить правила его использования
Силуэт по сути есть "наглядный goto". Он неизбежен (даже если его "не желать", т.е. не предполагать использовать в конкретном случае), чтобы снять пересечения линий при их возникновении.
А пересечения неизбежны, например, при потребности "прыгнуть" вовнутрь цикла в случае построения предельно оптимальной формы алгоритма (см., к примеру, "классику" от Кнута, демонстрировавшего необходимость применения goto при соответствующих требованиях). Через силуэт можем "залезть" куда угодно, "раскидывая" циклы по веткам силуэта и имея возможность таким образом задать любую последовательность действий. В Р-схемах, к примеру, есть возможность явно задать циклы и "прыгнуть" вовнутрь, если целенаправленно разрешить такие переходы, используя обычные средства (т.е. дуги (с пересечением линий) или структурные переходы) -- явно демонстрируя возникающую алгоритмику, с возможностью соотнесения условий циклов (и их инвариантов и пр.) с новыми внутренними "входами" и т.д. (т.е. "goto" реализовано "в лоб").
В ДРАКОН-е подобные алгоритмы через силуэт можно построить непреднамеренно, с возможным искажением в работе циклов и т.п. "Ветки" в силуэте могут возникать (и, скорее всего, наиболее часто) из-за потребности "разрулить" связи между условными выражениями, из-за возникающего загромождения или усложнения участков схемы, или из-за "не влазит на экран" и т.д.
Хоть "ветка" заявлена как некая замкнутая логическая структурная единица, но фактически таковой не является. Может быть в контексте "автоматного моделирования", рассматриваемого здесь на форуме, "ветка" более-менее методологически обособлена.
По этому поводу можно привести примерчик автомата из методологии от Esterel/Lustre (упрощённо):
Код:
process count(x) = o where
automaton
| Zero -> do o = 0 until x then Plus(1)
| Plus(v) -> do o = v then Plus(v+1)
end
Здесь процесс-автомат "count" со входом "x" и выходом "o" прибывает в состоянии Zero (а-ля "ветка" силуэта), возвращая 0 пока на входе не появится "x" ("x" изменит значение с неопределенного на определенное), затем возникает последовательность состояний Plus(1), Plus(2), Plus(3)...
В данном случае "ветки" изолированны (а-ля подпрограмма), каждая со своим "состоянием" в виде локальных переменных (в примерчике их нет), плюс вход/выход всего процесса. "Ветки" могут быть параметризованными (что снижает потребность в обращении к "предыстории", т.е. "предшествующим маршрутам"). Соответственно условия переходов -- также замкнутые, приватные.
В ДРАКОН-е изолировать "ветки" в общем случае невозможно (возникнут ограничения алгоритмических возможностей).