DRAKON.SU

Владимир Даниелович, большое Вам спасибо за отличные книги, за язык Дракон!

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

Интересно было бы узнать о возможностях применения Языка для проектирования интерфейса человек-компьютер. Этот ракурс разработки программных комплексов в настоящее время тоже обделён в части графического языка.

Крепкого Вам здоровья и горячее пожелание принятия языка Дракон в качестве стандарта преподавания информатики в системе образования нашей Родины!

Есть. Есть даже инструмент, доступный для тестирования, в соседней теме форума. Есть даже опыт применения в бизнес-среде, для описания бизнес-процессов. Есть даже желание (у меня) сделать полноценный компилятор.

Однако вспоминаем формулировку Вирта: "Алгоритмы + структуры данных = программы". Здесь есть только половина. Да и есть ли она? При ближайшем рассмотрении у меня возник вопрос, а что же такое, собственно, алгоритм? И как можно соотнести визуальный инструмент а-ля Дракон с особенностями исполнителя (набором команд процессора целевой системы, например).

Что же получается? Как полноценный язык для разработки - не годится.
Как эргономичная визуальная настройка над ассемблером - не годится.
Для формального описания бизнес-процессов и "чистых алгоритмов" - самое то.

Получается немного грустно - замечательная сама по себе идея вроде бы имеет ограниченную область применения (примерно как одна диаграмма из набора UML).


Интересно, как Вы себе это представляете?
По моему мнению, 30% в интерфейсе человек-компьютер (HMI) составляет дизайн, 50% - эргономика (этим пунктом почти никто, кстати, не занимается, потому имеем то, что имеем - неудобоваримое оконное мышекликанье). Ну и остальные 20% занимает собственно рекация элементов интерфейса на действия пользователя. Причём 90% здесь - стандартное поведение элементов GUI, а 10% - собственно та часть, где можно применить Дракон - логика (сценарий) использования. Или, по-другому, Use Case.

Так стоит ли овчинка выделки? Возможно, стоит, если вспомнить о тех 50% аспектов эргономики, про которые забывают почти все программисты.


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

Спасибо за наводку!


Спасибо за Ваше мнение.

Уважаемый Андрей Федяев!

Из Вашего первого сообщения как будто следует, что Вы имеете практический опыт использования языка Дракон для "обмена идеями".
Правильно ли я Вас понял? Если да, не могли бы Вы поделиться своим опытом и рассказать, как именно Вы использовали Дракон? Какие преимущества Вы получили? Какие трудности встретились на Вашем пути?

Владимир Даниелович, здравствуйте!
Практического опыта применения языка Дракон ещё нет - сейчас идёт внедрение. Когда будут конкретные результаты, обязательно напишу.

Наша команда, www.uidesign.ru, занимается проектированием интерфейсов человек-компьютер. Т.е. по сути мы проектируем сложные системы. У нас очень хорошо получается описывать конкретные состояния системы в виде детальных "чертежей" экранов. На этих же чертежах мы описываем и поведение системы. Поведение описывается текстом и стрелками, указывающими на переход системы из одного состояния в другое (от одного экрана к другому).
Есть предположение, что применение языка Дракон для описания поведения системы перед этапом детального проектирования экранов позволит снизить общие трудозатраты. Это связано с тем, что схемы перерисовать проще, чем перепроектировать экраны. Т.е. более качественная предварительная проработка (схема воспринимается легче текста) снизит количество напрасной работы.
Выделение описания деятельности в отдельный документ, вероятно, облегчит также и последующее внедрение (графический дизайн, html-вёрстка, кодирование) за счёт более наглядного и полного описания спроектированного нами интерфейса.
Конечно же, есть и нюансы. Описание выше дано для пояснения основной идеи.

Большое спасибо TMX за описание применения языка Дракон на всех этапах жизненного цикла разработки устройств на микроконтроллерах!

Видимо разнонаправленные шаги уже сделаны:

1.Привязать отображение декларативной информации можно в граф-схемах
(раскрашенные сети Петри - указывается тип данных, теоретически можно привязать поля типа) http://www.rsdn.ru/article/alg/MRS.xml

2.Преобразование масштаба( зачем это надо - пытались обсудить здесь):

а. с.124 Рис. 32. Пример операции "подстановка" (здесь и далее - страницы по книге В.Д. Паронджанова)

б. сворачивание Дракон-схемы в граф-схему (ветка Дракона->переход на граф-схеме)

рис.136,137 на с.262

Граф описывает машину состояний (state mashine)

Дракон-схема описывает машину маршрутов (route mashine ??)

Применительно к конкретной задаче - это две проекции одной и той же сущности. Насколько эти проекции независимы?

в. куда дальше сворачивать группу состояний из граф-схемы?

г. если после "в" попали в Дракон, то далее - п."б" .. и по кругу тыгыдым-тыгыдым-тыгыдым

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

а. ограниченности выразительных возможностей языка(где-то есть указатели, где-то нет..)

б. часто не позволяет учесть машиннозависимые детали реализации алгоритма (см. "Что же такое алгоритм")

4. Куда-то ещё надо деть информацию о назначении веток и состояний, теряемую в традиционной системе при написании исходника. Кто-то выносит в комментарии, кто-то нет.

Пока отложим сей вопрос...

Я сильно сомневаюсь в том, что можно провести такую аналогию с машиной состояний... То есть таки да, можно выделить (как бы) состояния, в которые переходит система по завершении ветки Дракона... А что дальше? Из одного состояния в другие может вести много переходов, и посему требуется (подразумеваемый) интерпретатор состояний, который проверяет УСЛОВИЯ каждого возможного перехода. В конце ветки ничего такого нет, там есть простое продолжение алгоритма (ну, может, ещё точка объединения - в начало очередной ветки может вести много путей). Однако алгоритм в Дракон-схеме детерминирован, и состояний с условиями просто нету!

Вот я и говорю - с чего бы?

На самом деле, конечно, можно найти и состояния, и проверку условий. Только проверка условий в Дракон-схеме обычно производится в середине или в конце ветки, где и возникает развилка... Так вот, состояния там и находятся - перед развилками. Перед каждой развилкой, если быть точным. Но такая их трактовка не является полезной для отображения на диаграмме состояний... Это громадная разреженная матрица с узлами, не несущими смысловой нагрузки с точки зрения человека-разработчика.

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

Ветки Дракона выполняют примерно ту же роль, что процедуры - инкапсуляция ОБЩЕГО кода (технический аспект), а вдобавок к этому - ещё и декомпозицию кода (когнитивный аспект). Причём первое поддаётся формальному анализу, а второе - из области неформального искусства! Посмотрите на диалог Паронджанова с ain'ом, это очень показательно.

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

Этто как так?
Ветка в Драконе может иметь несколько выходов внизу. Развилку по условию со своим адресом дальнейшего перехода в каждом случае! Полноценный стэйт-мачин...

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

А если живого опыта нет - то нужно просто не бояться "перегнуть палку в дисциплине". "Модульности много не бывает" (С) Кто-то из участников этого форума

Вот, о чём я и говорю. В SD сделан акцент на одно, в Драконе - совершенно на другое. Хотя формально их и можно считать эквивалентными, но в когнитивном аспекте - не получится...

?? М.б. Вы имели в виду Sequence Diagram?
Вообще-то диаграммы состояний(State Chart) - весьма компактны и информативны.
В противовес им, диаграммы взаимодействия(диаграммы последовательности)
малоприменимы для проектирования мало-мальски сложных систем.
В работе http://is.ifmo.ru/misc/diagrms есть наглядный пример.

Только в данном случае интересуют другие состояния.

Владимир Паронджанов ищет "функционально завершенные" состояния будущей системы, подталкивая ain'a к более четким определениям функций системы(перечня действий) и выделению сущностей, с которыми работают эти функции. Может быть я неудачно выразился, пусть более опытные участники меня поправят.

Попробуем препарировать один из результатов http://forum.oberoncore.ru/viewtopic.php?p=17127#p17127

Прямо по книге В.Д. Паронджанова (ветка Дракона->переход на граф-схеме рис.136,137 на с.262)
Кстати, сворачивание Дракон-схемы в граф-схему может быть выпонено полностью автоматически, с использованием информации из икон "Имя ветки" и "Адрес".

Получили:
1. не определена логика переходов после "Выбор режима"

- на данном уровне проектирования несущественно, как именно

осуществляется вход в каждый режим. Важно, что разработчик

предусмотрел различные варианты.

Реализация - в командной и декларативной части - уровнем ниже.

Описание перехода - должно быть в терминах логики и времени.

Как привязать на граф-схеме?

При восходящем преобразовании в граф-схему - анализировать ветку на предмет

логических переходов и операторов синхронизации, затем выносить в описание перехода.

При нисходящем преобразовании из граф-схемы - создавать шаблон ветки с учетом

указанной на граф-схеме логики переходов.

В случае сёрфинга по проекту - проверять маршрут на соответствие описанию.

2. не определены действия оператора (вообще не видно, что таковые ожидаются)

- существенный прокол. Необходимо, чтобы значимые признаки

проектируемой системы не скрывались при любых преобразованиях

масштаба.

Для рассматриваемой системы это может быть сигналом к изменению

организации взаимодействия с оператором. Поскольку в данном случае

проектирование происходит "снизу вверх" - от детального представления к более общему,

можно оформить взаимодействие с оператором в виде отдельной ветки "Диалог"

(по сути - выделить в отдельный маршрут).

Передавать в неё "код.диалога", возвращать "код.выбора.оператора", а в ветке "Работа с базой" его проверять.

.. и свернуть заново:



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

К слову - Компонентное программирование - разработка "снизу вверх"
Вроде как систематизируется "бардак" ((с)Valery Solovey из указанной темы).
Сочетание восходящего и нисходящего проектирования всё-таки позволяет вытащить дополнительную инфу для проектирования системы.

Предположения:
Часть маршрутной информации верхнего уровня может транслироваться
не только в командные, но и декларативные описания нижележащего уровня.



Давайте зададим этот вопрос Владимиру Даниеловичу,
поскольку доступная на сегодня информация крайне скудна.
(таблицы, списки, вынесенные за пределы Дракон-схемы)


p.s. Не смог найти рисовалку графов вроде применённой в http://is.ifmo.ru/misc/sdvssc.pdf,
поэтому картинки слегка вэк.. Может кому попадалась легкая и фришная??

р.р.s. поправил условия веток на рис.2 + уточнение терминологии

Попробуйте Higres от Новосибирского Института систем информатики им. А.П. Ершова...

http://pco.iis.nsk.su/higres/

Они компактны и информативны как самостоятельная сущность. Но тут ведь пробегало предложение взаимного автоматического перевода Дракон - State Chart. Тогда, если перевести в одну сторону (из диаграммы состояний в Дракон), не будет конкретитки (да ведь это и есть проектирование сверху вниз); а наоборот - тоже теоретически возможно, но диаграмма состояний, поднятая из алгоритма, будет избыточна и нецелесообразна для человека...

Правильно, так и есть! Однако методология получается не очень адекватная, слишком сложная, вроде птолемеевских эпициклов... Можно вместо этого и диаграммы состояний явно применить, а уж переходы отображать и проектировать в Драконе!

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

Да, это серьёзно...

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

как-то попадаются больше CADы фирварные: http://www.progesoft.com/ - аналог автокада, http://www.tflex.ru/ - T-Flex CAD... Но где-то точно видел фришную рисовалку, если найду, сообщу...

Ради этого я и налепил графов по ain'овской дракон-схеме.

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

Практически - только что показал на картинках в предыдущем посте. Поднял из дракон-схемы в граф-схему. Избыточности не обнаружил.

Уважаемый Alexey_Donskoy!

По поводу "птолемеевских эпициклов" я ответил Вам здесь
viewtopic.php?p=17129#p17129

Уважаемый Рэйлвэй Каген!

Если говорить по-крупному, я с Вами согласен. Но есть деталь, которая у меня вызывает сомнения. Я имею в виду понятие "состояние" (состояние конечного автомата).

Хочу изложить свое (возможно, ошибочное) мнение по этому вопросу.

Мне кажется, следует различать две трактовки дракон-схемы силуэт.

Первая трактовка ни у кого не вызывает сомнений. Силуэт - это конечный автомат, который может иметь разные состояния. Это часто подчеркивает Илья Ермаков. Много пракических примеров, где демонстрируется плодотворность такой трактовки, дал ТМХ.
viewtopic.php?p=14450#p14450

Вторая трактовка (на которую, как мне кажется, не обратили внимания) - это возможность трактовать силуэт как модификацию метода структуризации программ Ашкрофта-Манны. Об этом я говорил здесь (см. Замечание 3 и замечание 4)
viewtopic.php?p=13427#p13427

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

Понятие "алгоритм" шире, чем понятие "автоматный алгоритм".
Понятие "процедурное программирование" шире, чем понятие "автоматное программирование"
Понятие "процедурный язык" шире, чем понятие "автоматный язык".

Я хочу сказать, что дракон - процедурный язык. Мне кажется, когда Илья Ермаков говорит, что Дракон - структурно-автоматный язык, он неоправданно сужает сферу возможного применения языка Дракон.

Перейду к изложению сущности второй трактовки понятия "силуэт".
При второй трактовке понятие "состояние" перестает быть плодотворным. Необходимость в таком понятии отпадает. Ветка при этом трактуется не как "состояние". А как важный структурный (и СМЫСЛОВОЙ) элемент алгоритма (программы).

Примером такой ситуации является задача, которую попытался решить ain.
Если я правильно понимаю ситуацию, ain уже давно написал свою программу. И она успешно работает.
Зачем-же он решил потратить свое драгоценное время на "возню" с Драконом?
По-моему, для того, чтобы получить более ясное представление о своей программе, взглянуть на нее под другим, более выгодным углом зрения.

Вот как я понимаю работу с ain.

А теперь вопрос. Разве ain'у было бы лучше, если бы я стал говорить про конечный автомат и его состояния? Думаю,что нет. Получилось бы неоправданное наукообразие и нагромождение ненужных, избыточных понятий, без которых вполне можно обойтись. И которые ровным счетом ничего не дают для понимания сути дела. А я бы попал в дурацкое положение тех людей, про которых говорят: "Они хочут свою образованность показать".

Поэтому я воспользовался "бритвой Оккама", которая беспощадно отсекает все, без чего можно обойтись. Оккам говорил: "Не умножайте сущности без нужды".

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

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

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

Связи между ветками силуэта в Дракон-схеме являются невизуальными.

Человек вынужден выстраивать их в уме, считывая содержимое икон "Имя ветки" и "Адрес". Насколько близко окажется очередной банан от палки, можно только предполагать. Восходящее преобразование (сворачивание) дракон-схемы в граф-схему (рис.136,137 на с.262 В.Д. Паронджанов "Как улучшить работу ума") удачно визуализирует именно связи между ветками.
Для алгоритмов, легко умещающихся в человеческой памяти, такое сворачивание будет востребовано разве что в учебных целях.
Насколько удобнее(эргономичнее) проектировать логику работы системы в таком представлении? Для меня - удобно, но не факт, что кому-то ещё понравится. Привлекает возможность введения неструктурированной информации в произвольном виде. Для начального этапа больших проектов это достаточно важно, поскольку на "высоком уровне трудно отделить главное от второстепенного, трудно даже заставить себя это проделать"((с)Илья Ермаков), а себестоимость структурной ошибки в случае автоматической трансляции резко падает. Кроме того, становится возможным привлечь обширный наработанный мат.аппарат для моделирования системы уже на верхних уровнях с целью исключения таких ошибок.
Более того, думаю, что не стОит заниматься структурными преобразованиями на уровне граф-схемы в ручном режиме. Легче и проще это сделать на уровне Дракон-схемы в автоматическом режиме. Да и само название "граф-схема" в нашем случае можно заменить на "логический каркас", поскольку детали реализации веток в таком представлении оказываются скрытыми.

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

восходящее дракон-схема -> граф-схема (ветка силуэта -> переход; с сокращением избыточности)

Для успешного "тыгыдым-тыгыдым-тыгыдым по кругу" нужны преобразования :

нисходящее граф-схема -> дракон-схема (переход -> ветка силуэта; с созданием шаблонов)

нисходящее дракон-схема -> граф-схема (с созданием шаблонов)

восходящее граф-схема -> дракон-схема (с сокращением избыточности)

Какая информация в каком виде представляется - неважно. Занимаясь большими проектами, Вы сталкиваетесь с описанными Ильёй проблемами. Автоматическая трансляция здесь не поможет. А если до неё дошло, то описанное Ильёй уже позади.

Согласен на 100%. Привлечение всего доступного научного аппарата безусловно является положительным и крайне желательным моментом. Вместе с тем в жизни существует реальная проблема, которую Джеймс Мартин обозначил как "Прикладное программирование без программистов" (Application Development without Programmers). Это очень сложная проблема. И ее тоже надо решать. Причем решать эффективно.

Не во всей отрасли, а в НПЦ им. Пилюгина.