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

Дополнительные материалы:

        У данного пользователя нет прав размещать ссылки!
        У данного пользователя нет прав размещать ссылки!
        У данного пользователя нет прав размещать ссылки!
        У данного пользователя нет прав размещать ссылки!. Проще и универсальней другой метод: логические элементы.

       Две программки для упрощения логических функций
             • У данного пользователя нет прав размещать ссылки!
             • У данного пользователя нет прав размещать ссылки!

       

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

 
Спасибо за предположение о моих возможностях родить интересную критику. Но, чтобы 'просто' объяснить, нужно много потрудиться. Митькин потому и объясняет просто, что не один месяц он потратил на изучение теории и на прояснение задач Драконов.
 
Кстати, и в том классном посте Митькина можно найти 'халтуру':

1. Из текста не многим понятно, что такое «общая судьба». А тем, кто понял, также становится понятно, что в дракон-схемах почти отсутствуют средства объединения иконок в дополнительные классы. Этот недостаток устранён в дракон-редакторе У данного пользователя нет прав размещать ссылки! (У данного пользователя нет прав размещать ссылки!): появился цветной текст, заливка для икон и возможность их двигать по вертикали.
   
   
2. ДРАКОН изображает алгоритмы в графическом виде, а не в текстовом. Лучше один раз увидеть, чем тысячу раз прочитать.
   )) Текста и в ДРАКОНе хватает. Приходится читать, чтоб понять хоть что-нибудь. А вот картинки пока не используются. Зря. Приходится их довешивать в графическом редакторе (в формате, не совместимом с дракон-редактором ).
   
   
3. Диаграмма часто являет собой неповторимый рисунок. Этот рисунок облегчает запоминание.
   Этот структурный рисунок вторичен для самого компьютера. То есть, человеку-то он помогает запоминать и вспоминать. А компьютеру не помогает. В результате, компьютер не найдёт аналогичные части рисунков в Интернете. => поиск аналогичных структур и программ  очень затрудняется. Так что, задача понятности ещё не решена полностью: пока блок-схема не понятна компьютеру, она не сможет быть идеальной, доступной для автоматизированной проверки, различным преобразованиям и блочной унификации.
   
   
4. Правило "чем правее, тем хуже" позволяет мгновенно выделять успешный путь через алгоритм.
   Это незыблемое правило играет против использования логических элементов в дракон-схемах... В результате, в дракон-схемах затруднительно применять метки и параллельные потоки.
   
    
5. Что есть в ДРАКОНе такого, чего больше нигде нет? — Конструкция "силуэт".
   )) Любая релейно-контактная схема — это, в каком-то смысле, силуэт.
     У данного пользователя нет прав размещать ссылки!
   
   
   
   К тому же,
   ▼   Современная промышленная автоматика, хоть и базируется на микропроцессорах, для отображения логики использует элементы, соединённые подобно РКС. Сам же Степан Борисович У данного пользователя нет прав размещать ссылки! упоминает конечные автоматы.
   ▼   Любой силуэт обладает изъяном: не полностью визуализирует соответствующий алгоритм:
   
        
    сходящиеся ветвления показаны не графическим, а, скорее, табличным способом... Это снижает наглядность и 'понимабельность'. Этот недостаток можно скомпенсировать навигацией, выполненной в виде сетевых деревьев (которых пока нет ни в одном дракон-редакторе).
   

Вот, они, эти недостатки:
 
1) Теоретические:

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

 
2) Организационные:

• Не предусмотрены вполне посильные вознаграждения разработчиков (и просто активных и полезных участников обсуждений). Например, бесплатное предоставление им новых версий ИС ДРАКОН.
• Доступ  к  специфицированным исходникам. Без этого трудно будет

а) встраивать дракон-редактор в готовые программные продукты …б) использовать режим визуально-интерпретируемой отладки пользовательских программ ...в) Открытость алгоритмов генерации и управления блок-схемами необходима для разнообразия дракон-редакторов. Чем больше будет вариативность представления алгоритмов и методов работы с ними, тем легче находить и обмениваться этими эффективными интерфейсными и методологическими находками. Закрытость кода —  это главное препятствие к обмену.

• В современной промышленности не обойтись без использования финансовых отношений. Все понимают, что денежные инструменты необходимы. Но в сфере производства информации (например, на форумах) до сих пор не принято в количественно-оформленном смысле создавать и  учитывать авторитетность участников. Почему-то считается, что без непрерывного сопровождения оценками можно эффективно решать какие-либо вопросы, и эффективно создавать ценные сведения. Решать-то можно. НО вряд ли это можно назвать эффективным и целесообразным. Организованность действий  и ответственность мнений пока стремится к нулю, несмотря на изначальный энтузиазм достаточно-профессиональных участников. Красивая идея и перспективная теория – этого ещё не достаточно для достижения хороших результатов. Необходимы инструменты взаимодействия. В Интернете они несколько отличаются от традиционных, принятых в трудовых или творческих коллективах… Хотя, думаю, что, возникнув на форумах, методика информационных оценок, со временем, окажется эффективной и в реальном общении.
  В первую очередь – в среде форумчан – нужны эффективные инструменты взаимодействия и поиска информации. Именно на разработку этих инструментов нужно в первую очередь затратить достаточное количество усилий. А уже потом обсуждать формат данных, применяемых в дракон-схемах. И прочие специальные вопросы.
  
• В новых условиях даже вопрос об открытости кода дракон-редакторов решится сам-собой… Например, я подозреваю, что автор лучшего дракон-редактора пока не стремится к открытому коду именно по причине, что такая открытость приведёт к уходу этой технологии за границу. И тут даже не в деньгах дело, а в том, что успешные технологии делают успешную политику, и ведут к поражению конкурирующих стран. Если выиграют конкуренты, многим нашим людям будет от этого плохо. Но всё это не значит, что нельзя делать открытым код перспективного редактора. Можно. Но можно лишь в условиях, когда этот открытый код будет в нашей стране работать и развиваться быстрее, чем на Западе. Или когда прекратится конфронтация и пакости (направленные в нашу сторону). В этих направлениях хорошие тенденции возможны при наличии технологий правильных оценок и голосований по рейтингам, для решения любых ответственных дел.

 
 
3) Программные (недоделки):

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

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

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

Применение блок-схем для макро-программирования
(такие возможности появятся среди пользовательских настроек программ).
 
Например, вот схема работы кэширующего прокси:
У данного пользователя нет прав размещать ссылки! 
Рассматривая эту схему, наши люди, конечно, улыбнутся        
Ну да не об ошибках сейчас речь… Ошибки лишь намекают, что автор схемы, к сожалению, не был знаком с ДРАКОНом.
 
Понятно, что эту логику можно как-то менять, адаптируя программу под свои нужды. Раньше пользовательские настройки включали в себя только проставку галочек и заполнение текстовых полей. А теперь есть возможность управлять и структурой программных блоков. Создавая программу, разработчик вынужден будет изначально состыковывать её со стандартизированной библиотекой универсального построителя блок-схем.

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

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


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

(У данного пользователя нет прав размещать ссылки!У данного пользователя нет прав размещать ссылки! У данного пользователя нет прав размещать ссылки! …)  Изображения в ДРАКОН-схемах
методы вставки рисунков

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

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

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


Пример схемы с внедрёнными рисунками:

У данного пользователя нет прав размещать ссылки!




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

Поделюсь оригинальной интерфейсной находкой: Дополнительное контекстное меню