Intellect Board Pro
Система управления форумами
Объявление

30 ноября 2015 года выпущена окончательная версия Intellect Board 3.00! Перейти к скачиванию
Также доступен конвертор данных для IntB 2.22

Для получения новостей о новых версиях подписывайтесь на наши страницы ВКонтакте и в Twitter.

Привет, гость!

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

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

Настройки отображения темы Показывать по сообщений с сортировкой .
Выводить , отправленные .
Одна страница
Распечатать
_1_
Участник
Всего сообщений: 147
Зарегистрирован: 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_
Участник
Всего сообщений: 147
Зарегистрирован: 14 окт 2014, 09:11
Рейтинг пользователя: 15

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

_1_
Участник
Всего сообщений: 147
Зарегистрирован: 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_
Участник
Всего сообщений: 147
Зарегистрирован: 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_
Участник
Всего сообщений: 147
Зарегистрирован: 14 окт 2014, 09:11
Рейтинг пользователя: 15

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

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

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

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

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

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

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

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

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


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

_1_
Участник
Всего сообщений: 147
Зарегистрирован: 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_
Участник
Всего сообщений: 147
Зарегистрирован: 14 окт 2014, 09:11
Рейтинг пользователя: 15

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




 #8        
 
 


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

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

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

Одна страница
Распечатать

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

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

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

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

0: Контрольная точка "Вспомогательные действия выполнены". Время выполнения: 0.013. Запросов: 19, время запроса: 0.003 (20.31)%. Памяти использовано: 849544 байтов

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