Здрасте. Задача не сформулирована, есть лиши примерная схема, далее станет понятно почему. Если некоторая задача понятна, части её, то это можно удержать в уме, понять и представить. Если же задача весьма сложна, есть сотни компонентов, каждый из которых в свою очередь может принимать некоторое состояние и так лавинно разрастается. Причём некоторые части этого дерева" можно связать и логически исключить другие части. Из за масштаба системы её сложно ужержать в уме. Это касается любой сложной задачи. Нужна система, которая позволит наглядно(графически) отобразить всё это. Текстовое отображение в данном случае бессмысленно, так как это не визуальное отображение, а смысловое. Короче говоря нужен метод для отображения в графическом виде задачи, графически отображать связи между частями и исключать не нужные. Тоесть в виде диограмки выполнять анализ задачи.
unc1e, Эта схема требует чтения каждой компоненты. Это обычный граф, дерево. При этом никакая часть его не отражает графически логическую функцию. Я знаю про такие диаграмки с детства, ну между прочим.
Indy_, любую схемку можно обозвать графом, если подумать. ...Хотя если объединить пару блоков в некий кружочек - это перестанет быть графом, однозначно. Вам необходимо рисовать кружки, много кружков. ...Хотя если часто рисовать последние - люди начнут думать, что вы замкнуты в себе. Вот так вот...
UML Indy поставил IDA и впервые увидел граф программы? Да, но вы не знаете что деталировку блок схемы определяет разработчик, а не учитель. Инде для себя открыл новую область называется схемами. Схемы вам абсолютно не помогут. Просто как при изучении любой другой области возникает WoW-эффект. Эффект этот возникает по двум причинам в новой области много новых слов тысячи. За каждым словом скрывается некоторая функция. И пока новичок их не изучит ему будет казаться, что в этом есть какой-то тайный смысл который сделает его умнее. Но таких тайных знаний там нет. Нет их так как мы мыслим путём сведения новых знаний к предыдущим. При таком подходе просто неоткуда взяться новым навыкам которые могли бы вас сделать умнее. Суть схем в умении их быстро читать. Этому правда никто не учит. Ровно как и не учат в правильному представлению данных. В тексте главное ставят в начало и конец. Так же и со схемами в мозговых-картах главное рисуют в центре. В тексте есть таблицы. В схемах применяют позиционные обозначения которые наносятся на блоки слева-направо что-бы быстро искать по схеме. И прикладывают таблицу элементов. Так же в тексте можно отобразить дерево и граф. К примеру дерево Код (DOS): C:. ├───.altera.quartus │ └───system_console ├───.altera.sbt4e │ ├───configuration │ │ ├───org.eclipse.core.runtime │ │ │ └───.manager │ │ ├───org.eclipse.equinox.app │ │ │ └───.manager │ │ ├───org.eclipse.equinox.simpleconfigurator │ │ ├───org.eclipse.equinox.source │ │ ├───org.eclipse.osgi │ │ │ ├───.manager │ │ │ └───bundles │ │ │ ├───123 │ │ │ │ └───data │ │ │ ├───143 │ │ │ │ └───data │ │ │ │ ├───-2033496198 │ │ │ │ └───1144937706 │ │ │ ├───152 │ │ │ │ └───data Таким же способом можно отобразить граф пример выдачи gprof. Даже графики псевдографикой моно используя лишь /\_ Рассмотрим язык VHDL который был изобретён в 70-тых годах чтобы как раз уйти от схем. Так как их попросту было неудобно рисовать и они были ненаглядными из-за своей сложности. А если взять драконьи-схемы, то можете увидеть как сильно их охаивают. Как раз из-за того что они ненаглядны, что там нет блоков для группировки. Сокрытие данных это мощная вещь. В ООП программист зная только название метода может додумать как там внутри всё устроено. В схемах деления так же применяют сокрытие. Разработчик сам определяет на каком уровне ему остановиться в разбиении. Ну не рисовать все до болта или ассемблерной строчки. Ещё раз напомню про блок-схемы. Они от того и блок что серию блоков с командами можно заменить одним блоком. Тем самым скрыв лишнюю информацию. Аналогично тому как сейчас делают в редакторах для свёртки текста. А в UML для этого есть диаграммы классов. О том как их рисовать хорошо описано у банды 4: Э. Гамма, Р. Хелм, Р. Джонсон, Д. Влиссидес-Приемы объектно-ориентированного проектирования. Паттерны проектирования Надеюсь теперь понятно, что нет никакого смысла противопоставлять текст и графику. Так какой выход? Гради Буч-Объектно-ориентированный анализ и проектирование с примерами на С++-Невский Диалект (2000) Прочитав Буча можно прийти к следующим выводам: -что каждому человеку нужно своё представления. - в каждый момент разное. - даже ели мы выведем так, то всё равно человек будет оперировать своими знаниями и своими интересами. Выход был найден это интерактивный поиск. Человек запрашивает у машины что он хочет увидит, сообщая ей свои интересы. Машина отсекает лишнее и выдаёт его в том представление который хочет видеть человек. Как правило обычно его интересует несколько аспектов, поэтому информацию следует преподносить, как то делает Wolfram Mathematica. Процесс этот интерактивный, человек производит уточнения результатов. За чудом Wolfram Mathematica скрывается куча частных проблем решённых программистами. А также куча знаний записанных в учебниках по математики. А для перевода текста в графику есть куча визуализаторов. Тот же граф удобно описать текстом и отдать на визуализацию. http://www.webgraphviz.com/ Вы конечно скажете, но ведь отоброжение зависит от смысла? Как машина узнает что данный блок нужно поставить выше остальных, а эти три вершины в месте? Ну что же частично позиции сохраняются поэтому какие части сгруппировать можно указать кодом. Так вот вся сила в скорости восприятия информации. Как отсечь лишнее? Как сгруппировать интересующую информацию как её удобнее представит. На всё это даёт ответ поисковые технологии и ИИ. Правда область эта молода, но в целом есть куча достижений.
Pavia, Спасибо большое за развёрнутое описание ваших мыслей. Но есть несколько важных нюансов. > Indy поставил IDA и впервые увидел граф программы? Судя по этому утверждению вы думаете что я совсем глупый. Я спросил про возможность визуальным путём решать логические задачи, поиск соответствия и абстракции. Возможный способ отобразить алгоритмы на бумагу" и что бы на основе этого было возможно провести анализ. Я не спрашивал про компиляторные косяки и вообще эта тема не касается каких то диаграмок по госту и яп.
Ну как не просили? отобразить заменяем нарисовать и получаем определение диаграммы. Анализ это разбор по русски. Графики ничего не разбирают у них нет рук. Разбирает либо человек либо машина. Это неудобно. Конечно такие методики есть. Бинокрулярный или стерео метод или как-то так. Берём два похожих рисунка и подносим к глазам один глаз смотрит на один рисунок другой на другой. Мозг быстренько вычисляет разницу и человек будет видеть такие отличия как 3D выступы, изменения рельефа. Такой способ сравнения применяется в микроэлектроники для поиска дефекта микросхем. А так же в ШОУ Символьные вычисления к примеру диффуров в математике. На самом деле вся математика основана на визуальном пути решения. А что за логические задачи? Абстрагирование по русски обобщение. Рисуем по краям листа все классы. Потом ищем общие элементы и рисуем их в центре. К чему я. Давно известно что надо разделять правду от сказки. Нет никакого графического пути решения.Давно известно что надо раделять модель и отображение. Так вот путь решения любой задачи это перебор. Не важно чего. Двухмерные рисунки позволяют быстро перебирать решения отсекая лишнее. Но только для определенных случаев. Насколько я понимаю вы хите сличить графы программ. Так вот эта задача класса NP. Другими словами окромя полного перебора она не решается. Как тут помогут рисунки? Двухмерные рисунки позволяют быстро перебирать решения отсекая лишнее. Для этого граф надо представить функцией. А сам переход от одного графика к другому числом. Перестановки элементов можно представить числом. Проблема графов что даже самый простой граф имеет N^N перестановок и вы просто их не сможете отобразить. Вот если вы ограничите перебор до разумных приделов, то тогда вы сможете это отобразить, но не ранее. Как это сделать? Ввести ограничения на сохранения порядка следования структур. Ограничить варианты перебора как то сделано в алгоритме diff. Правда вам больше подойдёт анализ плотности переходов t-SNE. Математика там простая вычисляем локальную плотность и растаскиваем в стороны. https://distill.pub/2016/misread-tsne/ А ещё если продолжать тему ШОУ. Всегда под алгоритм можно подобрать хорошие данные которые будут работать. А так же анимация это тоже кластерное ШОУ. Вместо прямого вычисления процесс разбивается на шаги и каждый отображается отдельно. К чему это я, к тому что из алгоритма обратного распространения ошибки можно исключить распространение - так как это сделано для ШОУ.
Проблема решена в проектировании аппаратуры, блок-схемами. Каждый большой блок состоит из более мелких, каждый мелкий - из ещё более мелких. Так сложность убывает в геометрической прогрессии и решаются экспоненциально-сложные задачи проектирования.
