Итак, разберем все по порядку.
http://is.ifmo.ru/news/:
«Язык программирования "Дракон" (
http://ru.wikipedia.org/wiki/ДРАКОН_(алгоритмический_язык)). Зачем управляющие алгоритмы описывать так громоздко (
http://www.youtube.com/watch?v=Ua9dUUON ... e=youtu.be), когда есть автоматное программирование (
http://is.ifmo.ru/), в котором используются схемы связей и графы переходов (
http://is.ifmo.ru/books/_book.pdf). Что применять схемы, похожие на схемы алгоритмов, применять нецелесообразно, показано здесь (
http://is.ifmo.ru/books/djvu/pdf/A009.pdf).»
Но ведь если силуэт — это визуальный аналог автомата, то он сам же и представляет собой свою собственную
таблицу переходов (В цикле-силуэте вообще идут прямые ссылки на номера веток-состояний).
Заголовок ветки — это состояние, а сама ветка — эта функция перехода к другим состояниям.
Для получения полной аналогии поместим силуэт внутрь метода Handle объекта и при каждом
вызове Handle силуэт будет стартовать с ветки, являющейся текущим состоянием объекта.
Для цикла-силуэта ситуация вообще тривиальная — при вызове obj.Handle(N) первым действием
обработчика будет: wetka := N;
Хассан Гома
«Проектирование систем реального времени,
распределенных и параллельных приложений»
серия под ред. Буч, Джекобсон, Рамбо
«Для описания конечных автоматов применяются диаграммы и таблицы перехода
состояний.
Диаграмма перехода состояний — это представление конечного автомата в виде графа,
вершины которого соответствуют состояниям, а ребра — переходам между ними.
Таблица переходов состояний — это табличное представление конечного автомата.
В системах с высокой степенью зависимости от состояния диаграммы или таблицы
состояний могут оказаться очень полезными для понимания функционирования систем.
Такая спецификация конечного автомата зачастую более точна и понятна, чем
словесное описание.»
Причем понятно, что силуэт будет выглядеть более эргономично, чем граф переходов
общего вида.
По поводу спецификации:
igor пишет:
«Представьте себе, некая фирма предлагает мне закупить у них и использовать в своих изделиях партию микросхем. Причём, выясняется, что эти микросхемы были неплохо описаны в каком-то техническом журнале, но data-sheet на них отсутствует. Если я заложу эту микросхему в наше изделие, то на следующий день начальство меня уволит, и будет право. Потому что через год (когда заказчику отгружено уже 500 новых изделий) выяснится, что при температурах ниже +10гр эти микросхемы "тошнит", что нагрузочная способность по такому-то выходу не достаточна и т. д. Пусть аналогия несколько натянута, но моя мысль думаю ясна. Описания в каких-то книжках не имеют никакого значения. Нужен официальный документ. Такова практика делопроизводства. И не нам её менять.»
Но в случае, когда все микросхемы сертифицированы должным образом (ура!), то собираем из них
электронную схему и горя не знаем — она у нас будет работать при температурах от -50 до +50.
Но ведь силуэт — это логический аналог электронной схемы, собираемый из графоэлементов.
И условие вроде тут должно работать одинаково при любых температурах, как впрочем и остальные
элементы силуэта. Так что если твердо определены функции всех элементарных элементов и
возможные отношения между ними, то это в каком-то смысле равно спецификации.
И это Владимир Даниелович сделал, см. например, документ DrakonDescription.pdf.
По поводу силуэтов-слепышей — тут тоже не все так просто, это тема нуждается в подробном
обдумывании.
С одной стороны — ну ничего не понятно, что там происходит и может происходить.
А с другой стороны — это шаблон алгоритма, который ждет, чтобы его наполнили реальным
содержанием.
Опять возьмем объект, у которого вспомогательные методы в качестве процедур (для действий)
и функций (для условий) подставляются в Handle-[цикл-]силуэт.
Наследуем от него с перекрытием нескольких методов.
А если наследование будет виртуальным, то вообще во всем этом будет очень легко запутаться.
Так что, перефразируя классика, можно сказать:
Силуэт — оружие [программиста], огнестрельный метод.
Применяй умеючи метод этот!