ibnteo писал(а):
Читая код, зачастую тратишь мыслетопливо на разгадывание условий навроде (A and B and (C or D)), пытаешься не запутаться а скобках, в схематическом виде всё будет как на ладони.
Вот ещё причина переходить на Дракон-схемы, это экономия мыслетоплива при работе с алгоритмами, текстовое описание требует больших умственных затрат. Лучше потратить их на что-то другое, чем чтение алгоритма.
...
Рассмотрел вариант, где код будет разложен на максимальное количество икон, не понравился такой вариант, буду укрупнять иконы, любой IF это одна икона Вопрос, но будет конструктор логических выражений, который появляется на схеме при входе в икону, при потере фокуса логическое выражение будет складываться в главную икону. Это позволит увидеть логическое выражение в схеме, и не будет мешать при обзоре всей схемы, где важнее видеть описание таких икон, чем их код.
Всё же, неясно, как снимается потребность в мыслетопливе при чтении алгоритма. Нагрузка в любой иконе соотносится с прочими схемными элементами (нагрузка в какой-либо форме, хоть как описание вместо технологического языка, если почему-то этот технологический язык по сути выкидывается из репертуара моделирования, зачем он тогда нужен? Постановка задачи -- на своём языке, должна быть в другом месте, она ведь далеко не всегда "один в один" по структуре. Уточняющие комментарии, как вспомогательный элемент к выражению на технологическом языке, которые и должны быть рядом совместно, конечно же, возможны). Если ещё и какой-то конструктор-раскрыватель необходим, то тогда и раскрывать надо всё одновременно, во всяком случае в пределах зоны "симультанного наблюдения". Вряд ли некие "ромашки" как в Kodu Game (где-то здесь на форуме был акцент на элементах дизайна в тех краях) создадут какой-то "прорыв", особенно для mainstream-а.
Даже если ограничить топологию (однако как именно?) чтобы быть "один в один" для текст/схема, то "деревья решений" сократятся (с "разбуханием" икон), но не исчезнут. Здесь на форуме была специальная тема, посвящённая ключевым (фундаментальным) особенностям Дракон-а в построении отношений между маршрутами:
Преимущества языка ДРАКОН для деревьев принятия решенийПредлагаю взглянуть на следующий пример -- самый сложный среди там представленных именно как "дерево решений", с промежуточными действиями. Но для объективности сначала не читая текст, содержащий постановку задачи:
https://forum.drakon.su/viewtopic.php?f=228&t=6666#p103696Желательно поэкспериментировать:
-- восстановить постановку задачи, наблюдая алгоритм на данном технологическом языке (он ведь должен обеспечивать наглядность и понимание) не зная исходной модели на естественном языке;
-- насколько облегчается эта задача восстановления, если предварительно знать постановку.
А восстанавливать модель необходимо в любом случае, как минимум, для оценки корректности. Помогут ли здесь некие "ромашки", если ещё и нагрузка в иконах не пойми что?
Предлагаю оценить следующие факты. В примере дублируется условие 'machine.state = "expanding"' (к слову, "визуальная гибкость" Дракон-а за рамками академических примерчиков не снимает проблемы дублирования в общем случае). Достаточно ли выразителен язык, чтобы уточнить наблюдателю: это именно одна и та же проверка или новая оценка состояния, которое могло измениться (в императивной среде с совместно исполняемыми процессами)? Пусть суть этой проверки понятна из контекста согласно типу используемых элементов (к слову, вероятно, пример с применением некой автоматной методики, явный опрос "в каком состоянии?" имеет настороженную методологическую окраску, вроде бы, "состояние" не для этого предназначено). В случае чего, (тем более, если операция опроса "тяжёлая") эту проверку можно оформить отдельно с сохранением результатов, как в примере целенаправленно исполняется один раз функция "getUnixTime()" для установки значения переменной "now", используемой в нескольких местах. Однако переменная может оказаться невостребованной и её вычисление напрасным в зависимости от результатов "вопросов", если допустить необязательность или даже не допустимость данного действия ("getUnixTime()") без потребности -- очевиден ли на схеме факт необязательности инициализации переменной "now"? Очевидно ли: дублированное выражение 'machine.state = "expanding"' вычисляется всегда в алгоритме или есть путь без такой проверки?
В общем, не помешает оценить, насколько легко и легко ли выявляются факты выше на схеме, достаточно ли такой формы именно "дерева", или скорее, "сети" или же желательно в дополнение иметь и некие иные формы моделей. И какая помощь от потенциальных "ромашек" для подобной аналитики.
ibnteo писал(а):
А вот Дракон-схемы сразу принял, было лишь сопротивление в надписях вне иконы Вопрос, не смог это перебороть в себе, причём за довольно долгое время, пришлось искать решение этой проблемы.
Схемы, если всё же именно "читать алгоритм", неизбежно придётся оценивать и в обратном порядке. В этом случае при входе в икону со стороны "да" на пути возникает предложенная жирнющая "стрелка-стопор" (теперь она в противоположном направлении).
В целом, вопрос замены текстовых "да/нет" это лишь выбор цвета "шашечек" при той же самой езде.