Intellect Board Pro
Расширяемая система управления форумами с открытым исходным кодом
Объявление
Выпущена версия 3.02 с двумя новыми типами разделов: блог и микроблог.
Перейти к скачиванию
Привет, гость!

Блок-схемы на форумах

Вместо майнд-схем допустимо публиковать списки и деревья ссылок. А здесь покажу ещё один полезный вариант такой навигации, на основе блок-схем. Обычно, интеллект-карты помогают запомнить или упорядочить знания. А блок-схемы удобны для представления алгори

Настройки отображения темы Показывать по сообщений с сортировкой .
Выводить , отправленные .
Страницы:
Распечатать
_1_
Участник
Всего сообщений: 233
Зарегистрирован: 14 окт 2014, 09:11
Рейтинг пользователя: 15

0
31 августа 2015, 18:28. Редактировалось 11 раз, последний — 3 декабря 2015, 21:43#1
    Дополнительные материалы:

            Исключающее ИЛИ на языке ДРАКОН. Как изобразить?
            Первоочередные задачи по улучшению ДРАКОН-конструктора
            Каким вы видите редактор Дракон-схем?
            Не нравятся мне эти синхронизаторы. Проще и универсальней другой метод: логические элементы.

           Две программки для упрощения логических функций
                 • http://programki.net/program.php?pr=299
                 • http://www.softportal.com/software-5370-ogicheskie-irazsheniya.html

           
    Прикрепленные файлы:
    • X1 + X2 + X3 (доказательство рекурсивности).PNG
    • Внешние метки (о зависании должен сигнализировать циклический силуэт).PNG
    • Внутренние метки.png
    • drt-frmt (структура новых drt-файлов).rar (+).PNG
    • Логический элемент в примитиве.PNG
    • Пояснения к элементам управления интерактивным силуэтом.png
    • Визуальная компоновка выбранных веток.PNG
    • Принцип работы логического элемента.png
    • для силуэта разорвать дерево в +узлах.png
    • silhouette.gif

    _1_
    Участник
    Всего сообщений: 233
    Зарегистрирован: 14 окт 2014, 09:11
    Рейтинг пользователя: 15

    0
    31 августа 2015, 18:29. Редактировалось 4 раза, последний — 17 января 2019, 22:25#2
      Уже вряд ли кто пытается вычерчивать такие схемы по линиям. Ведь при таком непроизводительном способе сложно вносить изменения: даже незначительная  модификация одной иконки часто ведёт к необходимости лопатить и всю схему. Поэтому, вообще-то, блок-схемы мало распространились: просто не было эффективных инструментов для работы с ними.
      Сегодня положение меняется. Есть огромные и навороченные специализированные пакеты. А здесь расскажу о компактной и условно-бесплатной отечественной разработке. Мало того, что она автоматически выполняет огромную рутинную работу по исключению пересечений соединительных линий, так ещё и применяет прогрессивные стандарты визуализации (отличные как от ГОСТов так и от зарубежных).
       
      Кроме заточки как инструмент программирования, дракон-схемы реально помогают думать и обмениваться знаниями (в том числе, между специалистами разных профилей, что особенно ценно)). Именно последнее свойство предполагает использование таких схем в веб-дизайне или на форумах, и здесь я их тоже уже несколько раз применил, правда, без мэпинга.
       
      Есть разные дракон-редакторы (сейчас даже не совместимые по формату данных). Пока лучшими возможностями обладает ИС ДРАКОН, которая была написана и сейчас совершенствуется одним хорошим программистом: Геннадием Николаевичем Тышовым. По каким-то своим соображениям он не распространяет исходники (на это могут быть уважительные причины), и требует рублей 700 за один полнофункциональный дистрибутив. Новые дистрибутивы имеют больше ограничений, поэтому я пока использую выпуск 2012 года, и за последними изменениями почти не слежу, тем более, что принципиальные недостатки программы из года в год остаются прежними. Именно их опубликую здесь как ответ в другой, специализированный, форум. Там, на форуме, действуют жёсткие модераторские ограничения, из-за которых  общаться тяжеловато, по крайней мере, мне иногда удобней отвечать с других площадок.
      Итак,
       
      Прикрепленные файлы:

      _1_
      Участник
      Всего сообщений: 233
      Зарегистрирован: 14 окт 2014, 09:11
      Рейтинг пользователя: 15

      0
      31 августа 2015, 18:31. Редактировалось 15 раз, последний — 3 декабря 2015, 22:05#3
             Шилин Александр написал(а):
        __1__ написал:
        Дракон имеет уйму недостатков... , причём, некоторые из них фундаментальны. Спорить о них сейчас нет сил и времени.

        Можно не спорить. Можно просто их перечислить.
        Вот С.Митькин очень хорошо перечислил () достоинства Дракона. Я этот текст без изменений часто использую в материалах по Дракону.


         
        Спасибо за предположение о моих возможностях родить интересную критику. Но, чтобы 'просто' объяснить, нужно много потрудиться. Митькин потому и объясняет просто, что не один месяц он потратил на изучение теории и на прояснение задач Драконов.
         
        Кстати, и в том классном посте Митькина можно найти 'халтуру':
        1. Из текста не многим понятно, что такое «общая судьба». А тем, кто понял, также становится понятно, что в дракон-схемах почти отсутствуют средства объединения иконок в дополнительные классы. Этот недостаток устранён в дракон-редакторе Фабула (http://drakon.su/programma_fabula_._redaktor_drakon-sxem): появился цветной текст, заливка для икон и возможность их двигать по вертикали.

        2. ДРАКОН изображает алгоритмы в графическом виде, а не в текстовом. Лучше один раз увидеть, чем тысячу раз прочитать.
          )) Текста и в ДРАКОНе хватает. Приходится читать, чтоб понять хоть что-нибудь. А вот картинки пока не используются. Зря. Приходится их довешивать в графическом редакторе (в формате, не совместимом с дракон-редактором ).

        3. Диаграмма часто являет собой неповторимый рисунок. Этот рисунок облегчает запоминание.
          Этот структурный рисунок вторичен для самого компьютера. То есть, человеку-то он помогает запоминать и вспоминать. А компьютеру не помогает. В результате, компьютер не найдёт аналогичные части рисунков в Интернете. => поиск аналогичных структур и программ  очень затрудняется. Так что, задача понятности ещё не решена полностью: пока блок-схема не понятна компьютеру, она не сможет быть идеальной, доступной для автоматизированной проверки, различным преобразованиям и блочной унификации.

        4. Правило "чем правее, тем хуже" позволяет мгновенно выделять успешный путь через алгоритм.
          Это незыблемое правило играет против использования логических элементов в дракон-схемах... В результате, в дракон-схемах затруднительно применять метки и параллельные потоки.

           
        5. Что есть в ДРАКОНе такого, чего больше нигде нет? — Конструкция "силуэт".
          )) Любая релейно-контактная схема — это, в каком-то смысле, силуэт.
           



          К тому же,
          ▼   Современная промышленная автоматика, хоть и базируется на микропроцессорах, для отображения логики использует элементы, соединённые подобно РКС. Сам же Степан Борисович там упоминает конечные автоматы.
          ▼   Любой силуэт обладает изъяном: не полностью визуализирует соответствующий алгоритм:
               
           сходящиеся ветвления показаны не графическим, а, скорее, табличным способом... Это снижает наглядность и 'понимабельность'. Этот недостаток можно скомпенсировать навигацией, выполненной в виде сетевых деревьев (которых пока нет ни в одном дракон-редакторе).

        _1_
        Участник
        Всего сообщений: 233
        Зарегистрирован: 14 окт 2014, 09:11
        Рейтинг пользователя: 15

        0
        4 сентября 2015, 07:35. Редактировалось 10 раз, последний — 15 февраля 2016, 10:09#4
               Шилин Александр написал(а):
          __1__ написал:
          Дракон имеет уйму недостатков... , причём, некоторые из них фундаментальны. Спорить о них сейчас нет сил и времени.

          Можно не спорить. Можно просто их перечислить.
          Если Вы приведёте свой список недостатков и он будет понятным и наглядным, то готов использовать его в дальнейшем как конструктивную критику, над которой надо работать.
          Честное слово: альтернативное аргументированное мнение всегда очень полезно и интересно.


          Вот, они, эти недостатки:
           
          1) Теоретические:
          • Неправильный (неэргономичный) силуэт…
            В правильном силуэте обход снизу вверх нужно делать против часовой стрелки: это позволяет избежать пересечений, и готовит пользователя к восприятию параллельных потоков и логических элементов (реализованных средствами силуэта).  

          • Некомпетентная самодеятельность в способах представления параллельных процессов и параллельных действий...
          • Не реализована булева логика. Кстати, без неё любая параллельность ущербна, не полноценна.
            Как реализовать логические элементы я показывал в соответствующей теме, но никто за эти подсказки не зацепился. А ведь они гениальны!.. (хоть и требуют кардинальных изменений в синтаксисе дракон-схем …). Ну, тут уж сами решайте: если нужна параллельность и логика, придётся делать революцию ) Параллельные вычисления – это мэйнстрим в современном программировании (особенно, для управления промышленным оборудованием или военными изделиями). Но параллельность бывает и мнимой, достигаемой за счёт избыточной скорости последовательных операций (это давняя технология, которая, к сожалению, применима не всегда, и не для всех задач). В практике программирования для меня оказалось неожиданным, что к моделированию логических элементов сводятся совершенно разные задачи (которые раньше приходилось решать неудобными методами): как в интегральном и дифференциальном исчислении для решения задач каждый раз не требуется раскручивать километры доказательств (взял из таблицы интеграл, и всё!), так и в программировании: готовые правила преобразования булевских функций сильно упрощают программные модели, построенные  с использованием логических элементов.
          • Отсутствует необходимый акцент на изначальной записи проектируемой схемы в реляционную БД. Любая программа или алгоритм изначально должна записываться на правильный ‘носитель’, а у нас по-прежнему принято для этого пользоваться ‘бумагой’. Изначальная запись в правильную БД даёт огромные преимущества… Например, она позволяет автоматически генерировать максимально понятные схемы. Чтобы получить срандартизированную и лаконичную схему из 500 иконок, нужно проделать огромный объём рутинной работы: для такого упорядочивания человеку требуется несколько месяцев (без права совершить хотя бы одну ошибку!). А компьютер, средствами SQL обрабатывая данные из базы, спокойно справляется с этим за время в пределах минуты. В реальных задачах, в рамках творческого взаимодействия человек-компьютер, эту операцию приходится повторять многократно, каждый раз меняя исходные данные после неудовлетворительного результата очередных вычислений… Сегодня нормализация алгоритмов вообще не проводится, и это делает программы уникальными, нестандартизируемыми, недоступными для быстрой проверки их правильности и для автоматического поиска аналогов (через Интернет).
            Думаю, что именно запись в БД является главным и необходимым условием для правильной, красивой и лёгкой кодогенерации…
          • Отсутствуют ссылки, метки, множественные входы в схему (хотя, в программах Тышова множественные входы всё же были реализованы) . Понятно, что если заявлена возможность параллельных операций, то входов и выходов может быть сколько угодно. Без множественности управляющих входов Дракон ориентирован на последовательную обработку: ведь параллельные действия могут перекинуться в подпрограмму, а это значит, что в этой подпрограмме должно быть несколько входов.
          • Нет даже намёков на самопрограммирующиеся схемы (за счёт стандартизации блоков и пустых объектов...). Самопрограммируемая вложенность  и унификация программных блоков — это дальнее будущее программирования. Тоже очередная революция . Такой подход позволит не тянуть множество связей из внешних блоков во внутренние.
          • Если не считать нескольких стандартизированных макроикон, то в Драконе пока нет упора на мульти-элементный подход: понадобится набор нормализованных иерархически-вкладываемых программных макро-блоков, из которых будет строиться любая программа. Точнее, сначала методами визуального конструирования схема создаётся из простейших икон, а потом автоматически производится её нормализация: трансформирование в набор стандартных макро-блоков.  Схема понятна, если в ней мало иконок. Излишние подробности мешают восприятию, поэтому их придётся временно скрывать, заталкивать внутрь "мультиков" (это и будет происходить в процессе нормализации). А пока вместо компактных и лаконичных интерактивных схем Владимир Даниэлович в своих книгах мечтает о диаграммах размером с письменный стол ))
           
          2) Организационные:
          • Не предусмотрены вполне посильные вознаграждения разработчиков (и просто активных и полезных участников обсуждений). Например, бесплатное предоставление им новых версий ИС ДРАКОН.
          • Доступ  к  специфицированным исходникам. Без этого трудно будет

          • а) встраивать дракон-редактор в готовые программные продукты …б) использовать режим визуально-интерпретируемой отладки пользовательских программ ...в) Открытость алгоритмов генерации и управления блок-схемами необходима для разнообразия дракон-редакторов. Чем больше будет вариативность представления алгоритмов и методов работы с ними, тем легче находить и обмениваться этими эффективными интерфейсными и методологическими находками. Закрытость кода —  это главное препятствие к обмену.
          • В современной промышленности не обойтись без использования финансовых отношений. Все понимают, что денежные инструменты необходимы. Но в сфере производства информации (например, на форумах) до сих пор не принято в количественно-оформленном смысле создавать и  учитывать авторитетность участников. Почему-то считается, что без непрерывного сопровождения оценками можно эффективно решать какие-либо вопросы, и эффективно создавать ценные сведения. Решать-то можно. НО вряд ли это можно назвать эффективным и целесообразным. Организованность действий  и ответственность мнений пока стремится к нулю, несмотря на изначальный энтузиазм достаточно-профессиональных участников. Красивая идея и перспективная теория – этого ещё не достаточно для достижения хороших результатов. Необходимы инструменты взаимодействия. В Интернете они несколько отличаются от традиционных, принятых в трудовых или творческих коллективах… Хотя, думаю, что, возникнув на форумах, методика информационных оценок, со временем, окажется эффективной и в реальном общении.
            В первую очередь – в среде форумчан – нужны эффективные инструменты взаимодействия и поиска информации. Именно на разработку этих инструментов нужно в первую очередь затратить достаточное количество усилий. А уже потом обсуждать формат данных, применяемых в дракон-схемах. И прочие специальные вопросы.
          • В новых условиях даже вопрос об открытости кода дракон-редакторов решится сам-собой… Например, я подозреваю, что автор лучшего дракон-редактора пока не стремится к открытому коду именно по причине, что такая открытость приведёт к уходу этой технологии за границу. И тут даже не в деньгах дело, а в том, что успешные технологии делают успешную политику, и ведут к поражению конкурирующих стран. Если выиграют конкуренты, многим нашим людям будет от этого плохо. Но всё это не значит, что нельзя делать открытым код перспективного редактора. Можно. Но можно лишь в условиях, когда этот открытый код будет в нашей стране работать и развиваться быстрее, чем на Западе. Или когда прекратится конфронтация и пакости (направленные в нашу сторону). В этих направлениях хорошие тенденции возможны при наличии технологий правильных оценок и голосований по рейтингам, для решения любых ответственных дел.
           
           
          3) Программные (недоделки):
          • Фотмат drt-файлов не поддерживает мнгопоточность (каждый поток содержит специфичную информацию о проектируемой схеме).
            Дракон-схема должна иметь несколько иерархически вложенных уровней данных: начиная от строгих реляционных отношений между иконами и заканчивая нестандартными (дизайнерскими) оформительными фенечками.
          • Гном вместо стандартизированной записи в реляционную БД  —  это спорный подход… Конечно, опорные сигналы важны как средство визуального восприятия и запоминания. Но какими способами их записывать, выводить и хранить в компьютере — тут, наверное, ещё много раз всё изменится или дополнится (исходя из новых исследований и новых технологий обучения).
          • Для схем отсутствует представление сетевым деревом.
             
            Уже несколько лет прошло, но никто даже не пожелал применить в Драконах эту технологию. Иерархическая навигация автоматически должна сопровождать любую более-менее сложную дракон-схему. Именно сетевое дерево в визуальной связке с привычной дракон-схемой кардинально повысит наглядность и интерактивность (а не огромные схемы, размером с письменный стол ). Хотя и огромные схемы, наверное, могут пригодиться.
            Синхронная подсветка иконы и соответствующего ей узла сетевого дерева.
          • И вообще: отсутствуют способы автоматического взаимного конвертирования схем из примитива в силуэт (или ещё в какие-то типы UML-диаграмм, если они окажутся полезны)). Например, в чём-то перспективны HiAsm-схемы. Там допустимы пересечения линий. Ну и что? Метод интерактивного выделения связей помогает избежать дискомфорта и путаницы. Только не надо говорить, что конвертация из силуэта в примитив не всегда возможна Она возможна именно после принятия некоторых дополнений к сегодняшнему синтаксису и теории дракон-схем (метки, самопрограммирование, и т.п.). Именно примитив (а не силуэт) — каркас для большинства будущих диаграмм (по крайней мере, он более удобен в начальных и промежуточных стадиях проектирования алгоритмов).
          • Из иконок и комментариев давать гиперссылки (в том числе, в локальные документы MS Word). И наоборот, добавить возможность ставить метки на любой элемент дракон-схемы (будь то фрагмент текста, блок икон и комментариев), и по внешней или внутренней ссылке фокусироваться на нём.
            + Поддержка множественных ссылок
          • Разнообразить интерактивное взаимодействие с дракон схемой: всплывающие подсказки, изменение внешнего оформления икон, цветовая маркировка, внедрённые рисунки, и т.п..
            Привести ‘оформительские’ слои данных дракон-схем к общепринятым растровым и векторным форматам.
          • При сохранении схем в графическом формате автоматически добавлять к ней архивный аппендикс, содержащий  drt-прообраз.


          _1_
          Участник
          Всего сообщений: 233
          Зарегистрирован: 14 окт 2014, 09:11
          Рейтинг пользователя: 15

          0
          2 декабря 2015, 06:02. Редактировалось 5 раз, последний — 2 декабря 2015, 07:29#5
            Я начал конкретно думать об интерфейсе платёжной системы, и, кажется, нашёл перспективное решение: интерактивные платёжные шаблоны… Выглядеть это будет так (см.далее)
             
            В дракон-схеме (или в UML-диаграмме) каждая иконка будет работать как меняющая свой цвет кнопка: вызывая свою платёжную форму, в которой надо заполнить какие‑то поля и проставить галочки. То есть, эти формочки будут всплывать по нажатию на соответствующей иконе. Чтобы для пользователя удобно разграничить рабочее пространство, предлагаю в таких диаграммах принять следующее соглашение о цвете икон:
             
            (графический архив)

             
             Для платёжной системы главное не интерфейс, а база данных. Интерфейс – это лишь окно в эту базу, и для каждого из взаимодействующих пользователей это окно своё: может отличаться не только динамикой цвета икон, но и их набором, структурой, взаимным расположением. То есть, платёжная схема будет в чём-то индивидуальна, и, таким образом, привязана к пользователю и к задаче.
             
            Пример таких шаблонов (эта платёжная схема предназначена для начисления репутации):

            —  здесь браузерный кроссплатформенный дракон-конструктор поможет в следующем:
            ·       В каждой транзакции пользователь сможет отредактировать текст иконок, и добавить к ним комментарии. Этим он уточнит смысл элементов схемы.
            ·       Если нужного шаблона пока не нашлось, пользователь (или любой помощник) сможет создать свою блок-схему. А потом администратор подключит к ней нужные всплывающие формы, и назначит права доступа.
            Прикрепленные файлы:
            • цвет иконок.rar (+).png

            _1_
            Участник
            Всего сообщений: 233
            Зарегистрирован: 14 окт 2014, 09:11
            Рейтинг пользователя: 15

            0
            4 декабря 2015, 14:40. Редактировалось 2 раза, последний — 4 декабря 2015, 15:18#6
              Применение блок-схем для макро-программирования
              (такие возможности появятся среди пользовательских настроек программ).
               
              Например, вот схема работы кэширующего прокси:
               
              Рассматривая эту схему, наши люди, конечно, улыбнутся        
              Ну да не об ошибках сейчас речь… Ошибки лишь намекают, что автор схемы, к сожалению, не был знаком с ДРАКОНом.
               
              Понятно, что эту логику можно как-то менять, адаптируя программу под свои нужды. Раньше пользовательские настройки включали в себя только проставку галочек и заполнение текстовых полей. А теперь есть возможность управлять и структурой программных блоков. Создавая программу, разработчик вынужден будет изначально состыковывать её со стандартизированной библиотекой универсального построителя блок-схем.

              _1_
              Участник
              Всего сообщений: 233
              Зарегистрирован: 14 окт 2014, 09:11
              Рейтинг пользователя: 15

              0
              7 декабря 2015, 10:38. Редактировалось 1 раз, последний — 7 декабря 2015, 10:41#7

                Буквенные индексы икон (запоминатели)

                Предлагаю в стандартном виде для каждой иконки опционно выводить буквенный индекс.
                Опционно – значит, его можно показать/убрать (и делать это в настройках, сразу для всех иконок схемы). Эта опция может быть интерактивной: посадить её на горячую клавишу: индексы появятся если клавиша нажата. Такой индекс работает как запоминатель: даже при неразличимо-мелких надписях он поможет вспомнить содержимое соответствующей иконки.


                Такие буквенные индексы особенно полезны для схем-слепышей и для пазл-схем. 

                _1_
                Участник
                Всего сообщений: 233
                Зарегистрирован: 14 окт 2014, 09:11
                Рейтинг пользователя: 15

                0
                12 декабря 2015, 22:36. Редактировалось 5 раз, последний — 12 декабря 2015, 23:12#8
                  ( …)  Изображения в ДРАКОН-схемах
                  методы вставки рисунков


                  Пока дракон-редакторы не научились генерировать схемы в общепринятом формате (доступном в стандартных графических редакторах), я применяю следующий метод вставки рисунков:
                  1)  Условно обозначаю рисунок иконой-прототипом соответствующих размеров (например, комментарием), и в таком виде спокойно работаю со схемой до момента её готовности
                  2)  "Фотографирую" схему при помощи замечательного инструмента SnagIt. Этой программой можно точно снять копию (ни пиксела лишнего!), и делать скриншоты даже если изображение не помещается на мониторе.
                  3)  Если рисунки в схеме часто планируется менять (или копировать составные части для применения в других составных рисунках), использую SnagIt-редактор, и сохраняю схему в специальном формате (*.snag – в этом формате графические объекты составного рисунка разделены на уровне данных). Или сохраняю в формат *.svg (фактически, это XML).

                  Если схема ‘одноразовая’ (то есть, изменять её не планируется), то  для совмещения её с рисунком, обычно, сразу применяю
                  MS Word, т.к. в этом удобном редакторе всё равно веду все конспекты и протоколы своей работы. Например, публикуя рисунок или схему, одновременно, в своих локальных документах протоколирую гиперссылки, ведущие к этим публикациям.
                  (i)i

                       В этих двух редакторах для точного масштабирования рисунка относительно схемы есть интерактивный способ: перетаскивать границу плавающего изображения.


                  Пример схемы с внедрёнными рисунками:
                  Прикрепленные файлы:
                  • Правила оформления графических архивов.png

                  _1_
                  Участник
                  Всего сообщений: 233
                  Зарегистрирован: 14 окт 2014, 09:11
                  Рейтинг пользователя: 15

                  0
                  22 января 2016, 15:17#9




                     #8        
                     
                     


                    tectograph   — конструктор для создания иерархий.

                    _1_
                    Участник
                    Всего сообщений: 233
                    Зарегистрирован: 14 окт 2014, 09:11
                    Рейтинг пользователя: 15

                    0
                    7 февраля 2016, 22:55. Редактировалось 2 раза, последний — 15 февраля 2016, 06:20#10
                      Поделюсь оригинальной интерфейсной находкой: Дополнительное контекстное меню  
                      Прикрепленные файлы:

                      Страницы:
                      Распечатать

                      У вас нет прав для отправки сообщений в эту тему.

                      0: Контрольная точка "Конец инициализации". Время выполнения: 0.002. Запросов: 8, время запроса: 0.001 (46.16)%. Памяти использовано: 524032 байтов

                      0: Контрольная точка "Фиксация действия пользователя выполнена". Время выполнения: 0.002. Запросов: 10, время запроса: 0.001 (50.48)%. Памяти использовано: 524360 байтов

                      0: Контрольная точка "Основное действие выполнено". Время выполнения: 0.014. Запросов: 17, время запроса: 0.003 (25.29)%. Памяти использовано: 859344 байтов

                      0: Контрольная точка "Вспомогательные действия выполнены". Время выполнения: 0.014. Запросов: 21, время запроса: 0.004 (27.09)%. Памяти использовано: 874936 байтов

                      0: Контрольная точка "После срабатывания шаблонизатора.". Время выполнения: 0.023. Памяти использовано: 1185488 байтов