Соглашусь, в данном случае проще сразу в код смотреть. НО. Схема была бы сильно лучше, если убрать оттуда весь мусор, специфичный для целевого ЯП (объявление переменных и т.д.). Собственно, мне поэтому никогда не импонировала идея программить непосредственно на Драконе. Возможно, что это еще работает для какого-то сильно низкоуровневого языка (типа асма). Но в случае нормального ЯВУ - оно как собаке пятая нога. Тем не менее, даже в случае ЯВУ дракон хорошо работает (по моему небольшому опыту) как спека к реализуемому функционалу.
Если этот "мусор" убрать, то от алгоритма в общем то ничего и не останется :-) Алсо если из реализации на том же паскакале убрать этот мусор и оставить лишь высокоуровневую часть алгоритма, то такой код будет так же нагляден как и высокоуровневая схема. Только вот на паскале алгоритм все еще будет реализован (вся мелочь мусорная будет просто в отдельных процедурах сидеть) а вот у дракона уже нет (как я понимаю, средств декомпозиции вменяемых у Дракона нет).
как я понимаю, средств декомпозиции вменяемых у Дракона нет
Аналог процедур есть.
Можно пример?
Вставлю-ка и я свои 5 копеек...
Да, "аналог процедур" (графическая основа для записи их вызова) есть -
Вставка (активная). Т.е. как Валерий Соловьёв и говорил...
Ежели немного подумать - можно развить синтаксис настолько, чтобы записать и вызов/возврат в Обероне-2 - как
здесь показано...
Но народ прав в том отношении, что "всё, кроме маршрутных ключевых слов" в одну дракон-схему впихивать - неэргономично. Надо бы выдумать схемы и для других ключевых слов...
И соответственно из дракон-схемы их убрать... и связанную с ними часть текста перенести туда.
Так я и делаю. Например,
здесь - кстати, можно и рекурсию там показывать. Но её можно и описать через список следующих вызовов (после возврата из текущего).
Но, как и в материальной технике, только схем, прямо представляющих программы (дракон-схема - часть такого представления), нам, думаю, недостаточно. Это всё равно, как при наладке сложной установки или целого цеха пользоваться только конструкторской документацией...
Недаром в эксплуатационной, кроме части "Устройство", есть и часть "Принцип действия". А вот этого текст программы (равно как и дракон-схема по этому тексту) напрямую не описывают...
И спеку я понимаю именно в этом смысле - описание принципа действия. И она необязательно чисто декларативна...
Для примера на это самое:
...
А под схемой конечного автомата я конечно же понимаю STD (state transition diagram).
Ну и херня этот твой STD Запиши на нем обсуждаемый алгоритм. Дракон будет лучше.
А в этой задаче разве много состояний с переходами из состояния в состояние? По моему, тут у нас просто довольно линейный алгоритм с ветвлением.
- вот
здесь по диаграмме состояний задачи получен алгоритм. Закодированный "графитно". Кстати, аж в двух формах - силуэтно и по Дейкстре. И даже ассерт есть...
Только в общем случае переход от структуры состояний к алгоритму нетривиален - обсуждалось в
этом посте. Ну, это все и без меня знают...
А мысль в том - что и программа, и спеки на неё независимо м.б. хоть чисто текстовыми, хоть на табличной основе, хоть на графовой. Важно, чтобы задача отражалась со всех тех сторон, которые нужны для её понимания.
Параллелизм там, кстати, тоже есть - через рандеву. Но т.к. это алгоритмически строго - то м.б. не понятней вызовов процедур. И для этого нужен язык уровня спек (доалгоритмический) - подобно автоматам как представлению логики решения задачи. Вот создатель ДРАКОНа предлагает Z-схемы - для частного случая, когда можно "зациклограммить" совместное исполнение программ.
А вот ещё "один чувак" ((С)
Geniepro)
начал рассказывать о чём-то подобном, но уже реализованном в среде поддержки разработки и программ, и аппаратуры:
http://forum.oberoncore.ru/viewtopic.php?f=62&t=4060.
