DRAKON.SU

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

Эргономика посветлее будет. Она основывается на строении скелета человека, а также, на особенностях тела воспринимать внешние сигналы. Вполне возможно, что они (особенности) ещё далеко не полностью изучены, но они хотя бы изучаемы. Большинство (если не все) эргономические параметры имеют численное представление. Эстетика подобными вещами похвастаться не может.

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

Программу то создать конечно можно. Да, только вот, описание формата .drt Вы планируете открыть?

По поводу чанков и диаграмм:
я так понимаю, что человек может воспринимать 5-9 единиц неструктурированной информации.
Диаграммы же -средство структуризации.

Опять же возникает вопрос, что считать единицей информации на диаграмме.
Если ДРАКОН-схема отображает автомат, в котором 5-9 шагов приводят из начального состояния в конечное, то в нем может быть несколько десятков состояний. Пусть в каждом состоянии 5-9 ветвлений, а в каждой ветке - 5-9 действий.
Это довольно большая диаграмма. И с одного взгляда в ней не разберешься, практика показывает, что нужно минут 5. Это если я объясняю другому человеку, как работает алгоритм.
Прикиньте, у меня был бы текст (а он и получается через два этапа) с форматированием Doxygen. Гиперссылки, иерархия и все такое. Чтобы разобраться, как работает сам алгоритм, требуется гораздо больше времени. Чтобы внести в него корректные изменения еще больше. Потому что охвата нет.

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

Истинное утверждение.


Объясняю свою точку зрения:
Написание кода - не самая трудемкая задача в жизненном цикле ПО.
Внесение изменений на разных этапах - гораздо сложнее. Поэтому, кроме самого кода приходится пользоваться дополнительными средствами документирования. Как графическими так и гипертекстовыми, в том числе и табличными.
Насколько я понял, это вами делается упор на таблицы.
Я примерно понимаю о чем речь - явный пример таких таблиц есть на softcraft.ru, также табличное представление используется в некоторых CASE-средствах в неявном виде на выходе.
Таблицы удобны для интерпретации, легко реализовать пошаговую отладку.
Однако разбираться в них через месяц и вносить изменения - на мой взгляд, неблагодарное дело.
Тут как раз и можно вспомнить о чанках. В таблицах нет дополнительной структуризации информации.
Не могли бы вы привести пример удобной таблицы, описывающей автомат?

Илья Ермаков - ОТ МОДЕРАТОРА:
Уважаемые коллеги, не делайте лишнего цитирования, особенно целиком и особенно тогда, когда отвечаете непосредственно на последнее сообщение.

Достоинства таблиц переходов следующие:
- исправления могут быть внесены в таблицу переходов, и при этом не возникает необходимость переписывания кода
- правильность таблицы может быть проверена с помощью формальных методов
- можно легко осуществлять фильтрацию и сортировку строк по значениям одного или нескольких столбцов (т.е. в таблицах есть дополнительная структуризация информации)
- можно легко переключаться между тремя разными табличными представлениями:
* [начальное состояние]/[конечное состояние], по полю - [событие]
* [начальное состояние]/[событие], по полю - [конечное состояние]
* [конечное состояние]/[событие], по полю - [начальное состояние]
* три столбца: [начальное состояние], [событие], [конечное состояние], при этом количество строк равно количеству переходов на соответствующем графе
- таблицы легко транспонировать (вращать вокруг главной диагонали, при этом строки становятся столбцами, столбцы - строками, а координаты ячеек меняются с (x,y) на (y,x))
- все состояния и события автомата отображаются в явном виде, а не скрыты в глубине алгоритма
- таблица переходов отделена от остального алгоритма (от входа и выхода из автомата, а также действий при входе в то или иное состояние, при выходе из него или при переходе из одного определенного состояния в другое, или при наступлении определенного события), и так проще изучать работу автомата, а связь между таблицей переходов и остальным алгоритмом может быть восстановлена с помощью гиперссылок
- все состояния, события и переходы могут быть откомментированы
- таблицы легко импортировать/экспортировать в файлы MS Access и MS Excel или связывать с ними
- возможно автоматическое построение графа по таблице (с последующим форматированием вручную) для большей наглядности

Уважаемый Алексей Николаевич!

Хочу от всего сердца поблагодарить Вас за Ваше сообщение
Четверг, 24 Апрель, 2008 10:47 . Благодаря Вам я получил
бесценную возможность изложить важную для меня тему более
рельефно. Потому что Вы направили на нее яркий луч прожектора
(«Грустно, господа!»). И тем самым привлекли к ней внимание
участников форума.

Сначала поясню, какие именно моменты в Вашем сообщении вызвали
у меня чувство протеста.
Отмечу два НАИБОЛЕЕ ВАЖНЫХ утверждения.

Первое утверждение, с которым я РЕШИТЕЛЬНО не согласен.

Алексей Донской писал:
Выводы:
…размер чертежа не имеет принципиального значения…
Важное замечание: чертёж на бумаге не имеет ни одного
преимущества

Второе утверждение, с которым я РЕШИТЕЛЬНО не согласен.

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

Уважаемый Алексей Николаевич!

Не знаю, хотели ли Вы этого, но из сопоставления двух
цитированных утверждений следует, что защищаемая мной
позиция [а я придаю большое значение правильному выбору
размера диосцены (зрительной сцены)] АНТИНАУЧНА, так как
противоречит научно установленным фактам.
Отсюда вытекает также неявное обвинение в том, что я не
владею материалом, поскольку я, по Вашему мнению, не знаком
с фактами, которые давно установили авторитетные ученые.

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

В Вашем сообщении имеется неявная ссылка на хорошо известную
статью американского профессора Джорджа Миллера.
В разделах 1, 2, 3 я привожу информацию об этом, а также о
более поздних иследованиях психологов.

Раздел 1. 1956 год. Профессор Джордж Миллер: Магическое число 7

Профессор психологии Принстонского университета Джордж Миллер (George Armitage Miller)
родился 3 февраля 1920 года. http://en.wikipedia.org/wiki/George_Armitage_Miller
См. фотографию http://www.cogsci.princeton.edu/~geo/

В 1956 году Джордж Миллер опубликовал статью,
которая принесла ему мировую известность и вписала
его имя в историю психологии.

Статья называется: The magical Number Seven, Plus Or Minus Two:
Some Limits on Our Capacity for Information Processing.
Впервые статья была опубликована в: The Psychology Review,
vol. 63, N 2, March 1956 pp. 81-97.

Имеется русский перевод:
Миллер Дж. А. Магическое число семь плюс или минус два.
О некоторых пределах нашей способности перерабатывать
информацию. — В сборнике: Инженерная психология. М.:
Прогресс, 1964. С. 192—225.

В Рунете статья отсутствует. Но ее можно посмотреть
на английском. Stephen Malinowski опубликовал ее
в сети с разрешения автора.
http://www.musanim.com/miller1956/

Статья Миллера посвящена количественной оценке объема
кратковременной памяти. Он обобщил результаты психологических
экспериментов, проведенных в период с 1932 по 1955 год.
И пришел к выводу, что объем кратковременной памяти равен 7±2.

Статья Миллера была опубликована в 52 года назад. Она
опиралась на двухкомпонентную модель человеческой памяти
(кратковременная и долговременная память).

Раздел 2. 1968 год. Модель памяти Аткинсона-Шиффрина

В 1968 году Аткинсон и Шифрин предложили новую (трехкомпонентную)
модель памяти, добавив в модель сенсорный регистр и значительно
ее усложнив. Модель Аткинсона и Шифрина долгое время считалась классической.
См. R.C. Atkinson, R.M. Shiffrin. Human Memory:
A proposed System and its Control Processes. – In: K.W. Spence,
J.T. Spence (editors)/ the Psycology of Learning and Motivation:
Advances in Research and Theory. Vol. 2. New York, Academic Press.
P. 80—195.
Русский перевод: Человеческая память: система памяти и процессы управления. —
в Кн.: Р.Аткинсон. Человеческая память и процесс
обучения. М.: Прогресс, 1980. С. 53—203.

Раздел 3. 2004 год. Современный взгляд на модель памяти.

Современное состояние вопроса освещено в книге: Robert L. Solso.
Cognitive Psychology. – Allin and Bacon, Inc. Boston, London…, 6-th edition.
Русский перевод: Когнитивная психология / Р. Солсо. — 6-е изд. — СПб.:
Питер, 2006. — 589 с. — (Серия «Мастера психологии»). Эту книгу
желающие могут скачать в сети.


Раздел 4. Выводы

Анализ современных психологических исследований позволяет сделать следующие выводы.

1. При оценке кратковременной памяти психологи предъявляют
человеку материал для зрительного восприятия с помощью тахистоскопа
на ограниченное время (миллисекунды или секунды), после чего
зрительный материал мгновенно удаляется.

2. При реальной производственной работе (программиста или инженера)
с монитором компьютера или бумажным чертежом никто не гасит экран
и не убирает чертеж вопреки воле работника. Инженер или программист
могут смотреть на экран и чертеж неограниченно долго (а именно,
столько, сколько посчитают нужным).

3. Условия проведения психологических экспериментов коренным
образом отличаются от реальных условий, в которых работает
зрительный анализатор инженера и программиста.

4. Психологические эксперименты заслуживают всяческого одобрения.
При этом надо иметь в виду, что указанные эксперименты в
большинстве случаев носят академический характер. Их главная
цель — продвинуть вперед психологическую науку, добыть новые
научные факты, обеспечить приращение психологического знания.

5. Использование результатов академических психологических
работ для решения прикладных задач программистами и инженерами —
это отдельная большая проблема, которую необходимо тщательно и
всесторонне исследовать. Это вопрос о связи фундаментальной и
прикладной науки.

6. Прямое (бездумное) перенесение результатов психологических экспериментов
с использованием тахистоскопа в качестве рекомендаций
или стандартов для ограничения числа элементов (или чанков)
на экране или чертеже является грубой ошибкой.

Раздел 5. О чем говорит личный опыт Паронджанова, полученный при разработке
сложных логических устройств

Давным-давно, на заре туманной юности я разрабатывал сложной
логическое устройство военного назначения. Я был начальником
лаборатории разработчиков численностью 20—25 человек.
Опущу начальные этапы разработки, когда определялись назначение,
идеология и структура устройства. Расскажу только о разработке принципиальных
электрических схем.
Требования по надежности: устройство должно было работать при
любом одном отказе. Поэтому оно состояло из трех идентичных
каналов резервирования. Сигналы на выходе устройства вырабатывались
по схеме голосования «2 из 3».
Один канал резервирования насчитывал 30 многослойных двусторонних
печатных плат. На каждой плате установлены 120 интегральных схем
транзисторно-транзисторной логики (ТТЛ). Больших интегральных схем
(БИС) в ту пору еще не было.
Таким образом, суммарное количество интегральных схем в одном
канале резервирования равно 30 плат х 120 элементов = 3600
элементов (интегральных схем). Суммарное количество интегральных
схем во всем устройстве (в трех каналах резервирования) равно
3600 х 3 =10800.

Поскольку каналы резервирования были идентичны, электрические
схемы надо было выпустить только для одного канала. То есть для
схемы из 3600 интегральных схем.

Зададим себе вопрос. Сколько элементов (интегральных схем)
следовало разместить на одном листе электрической схемы? Если
слушаться Алексея Донского и Сергея Прохоренко, то на одном
листе электрической схемы надо разместить примерно 7 интегральных
схем. Сколько листов СхЭ при этом получится? Ответ очевиден:

3600 : 7 = 514 листов

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

Если бы я попытался идти по этому пути, мои подчиненные подняли
бы меня на смех и отказались повиноваться. Если бы я упорствовал
и стоял на своем, ссылаясь на ограниченную емкость человеческой
памяти (которая не имеет ни малейшего отношения к характеру работы
моей лаборатории), дело кончилось бы тем, что меня просто отстранили
бы от должности, как некомпетентного работника, который не справился
с поставленной задачей.

К счастью, у меня и в мыслях не было разрезать нашу огромную
электрическую схему на кусочки по «7 чанков».
Посоветовавшись с ребятами, я принял решение: электрическая схема
каждой платы (120 интегральных схем плюс соединительные линии)
должна целиком размещаться на одном листе бумаги. Для этого
пришлось выбрать формат А0 (который по площади эквивалентен
16 листам формата А4).
В результате электрическая схема одного канала нашего устройства разместилась
на 30 листах формата А0 (а не на 514 листах
формата А4, как учат Донской и Прохоренко).

Здесь, однако, возникла трудность, которую я заранее предвидел.
Мне было ясно, что на регулировочном участке в цеху, а также
комплексном стенде физически нет места, чтобы разложить
(на столах, на полу или на веревках) 30 листов бумаги формата А0.
Поэтому я сделал следующее. Сфотографировал все 30 листов,
уменьшил их в масштабе до малого размера (получился формат
средний между А2 и А3) и наклеил на картон.
Были изготовлены 3 комплекта такой документации:
— для регулировочного участка в цеху.
— для отработки на комплексном стенде,
— для работы в лаборатории.

Все! Проблема была решена. Сотрудники лаборатории, регулировщики
цеха и работники комплексного стенда получили наиболее удобные
условия для работы. Нареканий не было. Прибор был успешно отработан, прошел все
необходимые испытания и сдан на вооружение.

Вывод. Практика реальной работы по разработке, отработке,
проведению полного объема испытаний и сдачи на вооружение сложного
логического устройства позволяют утверждать следующее. Абстрактные рассуждения
о необходимости соблюдать правило «7±2», не опирающиеся
на точное понимание границ применимости этого утверждения, не
приносят никакой пользы, зато могут принести значительный вред.

Раздел 6. James Kalbach О мифе "семь плюс минус два"

В качестве дополнительной иллюстрации я приведу (без комментариев)
статью
James Kalbach The Myth Of "Seven, Plus Or Minus 2
http://www.ddj.com/184412300
опубликованную в Dr. Dobbs Portal: The world of software
development
Имеется русский перевод Александр Качанов О мифе "семь плюс
минус два".

Ниже я привожу отрывки из этого перевода

Раздел 7. James Kalbach О мифе "семь плюс минус два"
Отрывки из русского перевода.

Быстрое развитие Web взвалило неимоверную нагрузку на плечи тех,
кто занимается разработкой веб-сайтов. Естественно, что создатели
веб-сайтов готовы ухватиться за любую мысль, похожую на стандарт,
чтобы как-то ускорить свою работу. Но многие так называемые стандарты
уже устарели и мало подходят для современности. Так как мы сейчас
вступаем в этап, который можно назвать Web второго поколения, пришло
время пересмотреть существующие методы.
Одним из таких методов, на который стоит обратить пристальное
внимание, является волшебное правило "семь плюс минус два (7±2)".
Этот принцип очень часто применяется для того, чтобы определить
количество пунктов в меню навигации на веб-сайте. Правило это
вошло в практику, чтобы ускорить процесс дизайна, ну и чтобы
объективно объяснить принятое решение заказчику.
Откуда же пришло это правило?
В 1956 году психолог Георг Миллер (George Miller) опубликовал
результаты своего исследования. С тех пор правило 7±2 стало
сверхпопулярным среди дизайнеров интерфейсов. Более внимательное
изучение работ Миллера показывает, что он не делал в ней никаких
выводов, которые можно применить к дизайну веб-навигации.
Во-первых, Миллер занимался изучением пределов человеческой кратковременной памяти.
Он пришел к выводу, что существует
предельное количество предметов, которые мы способны удержать
в нашей кратковременной памяти: 7±2. Он не занимался изучением
вопроса, сколько предметов человек может воспринимать, предположив,
что их может быть несколько тысяч. Навигация на веб-сайте в общем
случае никак не связана с кратковременной памятью. За редким
исключением посетителям никогда не приходится запоминать все
пункты в меню. По сути, меню навигации присутствует на каждой
странице сайта и всегда доступно для посетителя. Кратковременная
память здесь не играет совершенно никакой роли.
Во-вторых, удивительно, что это исследование, сделанное так
давно, до сих пор используется. Не смотря на то, что Миллер
выполнил свою работу очень хорошо, ее результаты слишком устарели,
чтобы их можно было применять к веб-дизайну. Исследования,
выполненные уже совсем недавно, показывают, что вывод Миллера
был неточным и слишком упрощенным. Кроме того, за 50 лет,
прошедших с момента проведения опытов Миллера, наши общие
способности и навыки в обработке информации наверняка увеличились,
в особенности с приходом Интернета.
Хоть магическое правило Миллера 7±2 и напоминает нам об умеренности,
его нельзя применять при проектировании навигации и использовать
его как универсальное решение. И уж тем более, это правило не должно
восприниматься как абсолютный закон. С другой стороны, заваливать
посетителей сотней меню тоже безответственно. Проблема с путаницей
и информационной перегруженностью разумеется существует, и наверняка
есть определенное число пунктов меню, которые можно показать
посетителю на странице, при этом не вызывав у него паники. Но
число это никоим образом не вытекает из правила Миллера.
Совершенно ясно, что оптимальное количество пунктов в меню нельзя
свести к одному обобщенному правилу, применимому во всех ситуациях.
Наоборот при проектировании информационной архитектуры сайта
следует помнить о других двух самых важных правилах: баланс широты
и глубины информации, и способ ее представления……………………………………………………………
…………………………………………………………………………………………………………...........................
.....................................
Возьмем к примеру веб-сайт http://www.health.com. Мне нравится этот
сайт - приятный дизайн с всегда свежими материалами. Однако главное
меню сайта аккуратно ужато до семи пунктов (если не считать "home").
В результате у сайта получается глубокая структура. Найти нужный
материал становится проблематично: я иногда отчаянно блуждаю по
сайту, чтобы найти статьи по такой теме как

Полный текст перевода см.
http://newsroot.net/articles/14039.htm

Ну, не надо наводить тень на плетень. Я как раз писал совершенно противоположное тому, что Вы мне приписываете. Вот дословно мое сообщение в форуме "Дракон, особенности восприятия, графика-текст..." от Вторник, 29 Апрель, 2008 15:42 :



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

ПРОШУ МОДЕРАТОРА НЕ УДАЛЯТЬ ЦИТАТЫ, ТАК КАК ПОТЕРЯЕТСЯ КОНТЕКСТ

ОТ МОДЕРАТОРА: Прошу не считать модератора дураком. Речь шла о полном цитировании строго предшествующего сообщения.

Всем привет!

Собственно, и я говорил о том, что цена переключения контекста между многими мелкими листами значительно выше цены перевода глаз из одного угла чертежа в другой. Так что...

Владимир Данилович убедительно и со ссылками показал историю вопроса про 7 чанков, и я не могу с ним не согласиться. Инженерная работа над чертежом - это отнюдь не рассматривание рекламы, где действительно требуется впечатление в расчёте на секундное восприятие.

Более интересным является возражение против чертежа на бумаге как такового. Работа на бумаге имеет множество неоправданных ограничений. Да, на бумаге удобно играть в крестики-нолики. В шахматы на бумаге играть значительно сложнее (карандаш+ластик). Так же неудобно и любому специалисту работать на бумаге - по очень простой причине - бумага статична, в то время как работа динамична.

Другой вопрос в том, что до сих пор почти ни один инструмент компьютерный не достиг хотя бы такого эргономического удобства, как бумага (мне тоже легче думается, лёжа на диване с блокнотом - не представляю себе такого же удобства с КПК и тем более с мышкой ). Но! это касается только первоначального, концептуального, обдумывания. Рисовать на бумаге ER-диаграмму уже как-то несподручно (карандаш+ластик), а уж тем более - писать куски кода...


Под этими словами подписываюсь на 100%. Считаю эти положения принципиально важными.

Электронная бумага нам поможет? Я про неё уже говорил в Москве Илье, так что это не нашло отображения на форуме...

http://ru.wikipedia.org/wiki/E-Ink

(Кстати, первоначально, разработка того же Xerox PARC, если кому интересна история)

Самое то! Но ведь это ещё за горами... А пока нужно ориентироваться на дисплей. И мышь, туды её... а заменить нечем пока...

Можно ли использовать Дракон-Схемы для языков программирования типа Пролог и Лисп?

В общем - нет. Потому как ориентирован он на императивную модель алгоритма (см. параллельную ветку).

Лисп использует в качестве основы функциональную модель. В ней как таковое отсутствует понятие "состояния" - нельзя точно сказать, какой блок за каким следует.

Пролог еще более оторван от императивной модели (Лисп хотя бы процедурен), он декларативен. Упрощая, можно сказать, что в Прологе имеется постановка задачи, но не алгоритм ее решения.

Пролог-программа - типа, параметризация для того алгоритма, который зашит внутри Пролог-машины. (Весьма ограниченного концептуально вывода по хорновским дизъюнктам...)

Добрый всем час.

Обращаюсь к Владимиру Пароджанову.

Занимаюсь разработкой визуальных сред для контроллеров промавтоматики.
Совершенно случайно набрел на этот форум и познакомился с дракон-схемами.
Исходная цель создания "дракона" близка к задачам технологического программирования: "Программирование без программистов".

Прочитал этот тред и Вашу книгу "Как улучшить работу ума". Отличная книга, спасибо!
Конечно, она заставляет думать и задавать вопросы.

Основной вопрос:
- можете ли Вы провести сравнение "дракон"с известными системами технологического программирования LAD, FBD. В чем Вы видите преимущества "дракона"? Как планируете
его развивать?

Замечу, что средства программирования PLC весьма развиты чтобы обеспечить средний-высокий
уровень сервиса при работе с графическими языками. Цели схожи с "драконом".
В известных системах для задач управления и регулирования графические языки
четко формализованы.

Существуют даже более жесткие ограничения на алгоритм:
- упрощение во избежание ошибок; например, во многих системах отсутствуют циклы, вызовы подпрограмм и тд;
- дается четкое описание runtime - цикличное последовательное исполнение всех цепей программы;
- не требуется текстовых операторов внутри блоков:
- нет двухуровневой компиляции (сначала из графики в текст,затем в исполняемый модуль),
зато есть возможности отладки графических объектов в динамике (подсветка контактов).

Графические представления однозначно транслируются в систему команд ПЛК (или его среды выполнения). Возможна трансляция одного графического представления в другое. Одновременно эти языки поддерживаются удобными редакторами - примеры: IsaGraf, Step 7, CodeSys и др.

______

И еще вопрос,
известны ли Вам какие либо сравнения затрат и результатов по повышению эргономичности
текстовых представлений программ (подсветка синтаксиса, выделение блоков, отступы и многое другое) и графических?

как инженер-автоматчик, от себя могбы добавить:
*TraceMode 6 Рус - tcnm возможность скачать бесплатно базовую версию 50МБ (или заказать бесплатный КД) на http://www.adastra.ru
*CodeSys 2.3 Рус - самый предпочтительный вариант для ознакомления - но надо качать ~ 115 Мб, есть толковая документация.
FBD - помему не очень ссответствует концепциии ДРАКОН-1 (т.к. здесь обсуждается именно он)
--- для справки --- тем кто не читал о МЭКовския языках для ПЛК ----
*Язык функциональных блоковых диаграмм FBD – это графический язык программирования. Он работает с последовательностью цепей, каждая из которых содержит логическое или арифметическое выражение, вызов функционального блока, переход или инструкцию возврата.
* Непрерывные функциональные схемы CFC - В отличие от FBD редактор непрерывных функциональных схем не использует цепи, но дает возможность свободно размещать компоненты и соединения, что позволяет создавать обратные связи.
* Язык последовательных функциональных схем SFC – это графический язык, который позволяет описать хронологическую последовательность различных действий в программе. Для этого действия связываются с шагами (этапами), а последовательность
работы определяется условиями переходов между шагами.
--------------------------
SFC - помоему больше других приближен к Дракону-1

Обратили ли Вы внимание на сообщения TMX: viewtopic.php?f=62&t=493&p=14462#p14462 и viewtopic.php?f=62&t=493&p=14515#p14515 ? Соответственно, мне было бы интересно услышать и Ваше мнение... по тем же вопросам...


Разве только в порядке экспертной оценки (скажем, в баллах)... Вот моё мнение:
- подсветка синтаксиса +60
- выделение блоков +50
- отступы (как частный случай выделения блоков) +10
- сворачивание блоков +90

Как ни парадоксально, для графических языков примерно то же самое
Только здесь есть и противоречивые оценки (зависят от ситуации):
- большой размер диаграммы от -100 до +500
- объединение нескольких линий в общую шину от -50 до +150

Хотя бывают и уникальные требования пользователей (так, у меня один просит чёрный фон - уж не знаю, из какого Автокада он привык к такому)...

Да, конечно. Он работает в близкой области.

Разница в том, что ТМХ сам занимается разработкой программы "в составе целевых устройств", а не выпуском PLC. В моем случае изделие - промконтроллер и система технологического программирования к нему. Вот, думаю: стоит ли реализовывать "дракон" в дополнение к существующим LAD, STL? Насколько это будет полезно? Насколько трудоемка разработка?

После чтения книги есть масса вопросов. Хотелось бы узнать от Владимира Пароджанова его мысли о практической реализации языка. В идеале , простой компилятор "Дракона" написанный на самом "драконе"..



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

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