DRAKON.SU

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

(модератор) тема выделена из viewtopic.php?f=78&t=3463 согл. пп. 0.3 и 2.1

Конечно, есть в литературе... это же известно со времен К. Маркса... Нормированием активно занимался Ф. Тейлор... его еще дедушка Ленин критиковал за ""научную" систему выжимания пота"... Правда потом эту лженаучную теорию активно (в приказном порядке) внедряли на советских предприятиях.
Не совсем так... В конечном итоге (если не опускать руки... не роптать... не мечтать о дивидендах и аксельбантах) получается не то, что просто... а необычайно просто (банально!) и... красиво. Но путь к этой простоте весьма и весьма труден. На этом пути мало призвания и таланта (хотя они, наверное, помогают...) на этом пути есть только одна путеводная звезда...
... и еще... У меня тоже долго были проблемы с тем, чтобы переложить на формальный язык свои модели... суетился много, руками размахивал (я-то знал, что это здорово), а выразить не мог. И мне очень помогла... восточная философия. Я о ней и раньше слышал, но относился крайне скептично... у нас восточная философия проходит по разряду "эзотерики", а на самом деле она что-то вроде математики, только более строгой и глобальной. Когда я ее узнал поближе, то с ее помощью шлифовал свои модели. Даже если я не указываю на это в своих работах, то... только ради читателей, так сказать, щадя их чувства (нельзя же "эзотерику" использовать в качестве серьезного аргумента)
И читая здесь, на форуме, обсуждения Дракона, не могу отделаться от мысли... что при всей красоте концепции, развитие идет не в том направлении... IMHO. Пожалуйста, не сочтите это за критику, я не готов критиковать Дракон.

Не, я как раз имел в виду сопряжение с графами, а не "предметную" суть. Там дело ещё в том, что не достигнуто такое же понимание императивного и активного, как, скажем декларативного (в плане той же "системы языков" и преобразований моделей). Попытки формально-языкового представления есть и для процессов (грамматики, вводимые Каляновым), и для механизмов (А-аппарат, описанный у Алгазинова и Сироты), но нужно думать, как это может образовывать систему...
Ну, вот Девятов с Мартиросьяном используют и вроде неплохо...
А как Вы могли бы сформулировать это направление и то, что в нём не то? Думаю, это интересно...

Уважаемый alexus!

Буду Вам очень благодарен, если Вы сочтете возможным пояснить Вашу мысль.
Если Вы не против, хотелось бы получить пояснения по двум вопросам.

1. Что означают слова "развитие идет не в том направлении"?

2. В каком направлении следовало бы двигаться?

В качестве одного из возможных вариантов развития:
----------------------------------------------------------------------------------------------------

Нужно ли ВСЕ маршрутные операторы соединять
линиями логических переходов ?


По мнению Алексея Донского иногда поиск вариантов, при котором линии на схеме
не пересекаются, отнимает больше времени, чем разработка самого алгоритма.
Геннадий Николаевич с ним неявно согласился, введя флажок "разрешить
пересечение лиан".


Рассмотрим обозначение цикла ДЛЯ на рисунке 1.

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

У меня в при работе с программой dal_vjaz сформировся следующий
взгляд на этот вопрос:

Нужно ввести разделение маршрутных операторов на основные
и дополнительные.

Основные маршрутные операторы:

IF - если (условие), то начать блок

EI - конец блока иначе если (условие), то начать блок

EB - иначе начать блок (на схеме отображается как начало
альтернативной ветки условия)

E - конец блока (на схеме отображается как точка соединения
линий условного блока)

CB - начало цикла

CE - конец цикла

(с учетом вышеприведенных замечаний о цикле ДЛЯ можно было бы
ввести визуальную конструкцию "обобщенный цикл", см. рис. 3)

HD - заголовок ветки силуэта

AD - адрес следующей ветки силуэта

A - действие (action)

RET - конец, возврат из процедуры

Для основных маршрутных операторов линии логических переходов
обозначаются, как это и принято в языке ДРАКОН.



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

C? - продолжить цикл по условию: if (usl) continue;

B? - выйти из цикла по условию: if (usl) break;

A? - переход вверх по условию: if (usl) goto m1; // A

--A - действие, к которому выполняется переход вверх по условию

V? - переход вниз по условию: if (usl) goto m2; // V

--V - действие, к которому выполняется переход вниз по условию

ERR? - переход к обработке ошибки по условию: if (err) goto m_err;

ERR - обработка ошибки

RET? - выход из процедуры по условию: if (usl) return;


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

На схеме дополнительным маршрутным операторам будут соответствовать
следующие значки:

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


А вот и более сложная схема:

Кстати "хулиганский" переход от действия 4 к действию 11 в языке ДРАКОН
запрещен.
А вот та же схема, но нарисованная в ИС Дракон.

Я скопировал схему из ИС Дракон в Paint и добавил значки операцией
"вставить из файла".


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

Какими должны должны значки и обозначения для дополнительных маршрутных
операторов - выяснится в процессе обсуждения, если оно последует.


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

С точки зрения структуры, любая система представима элементами и связями между элементами. В этом случае процесс - это то, что связывает входы и выходы элементов по возможным/допустимым связям. Процесс имеет начало и конец и, в общем случае, представим орграфом. Если желаете, могу проиллюстрировать эти известные положения теории систем примерами из работ К. Маркса (hint: производительные силы и производственные отношения), А.А. Богданова и др. Все сказанное - формально, оно не может иметь никакого другого толкования, поэтому мне не совсем понятны трудности с описанием.
Если честно... я всегда немного завидовал (по-хорошему) людям, которые могут писать. Для меня это каторга... А если, кто-то грамотно использует восточную философию для изложения своих идей, то это просто замечательно!.. Я же только структурирую свои мысли, модели...
Нет, я не думаю, что это интересно. Проблема в том, что это так или иначе связано с мировоззрением... А это совсем неинтересно для большинства... IMHO.

Ну а если более конкретно, уважаемый alexus ?

Понятно, что ДРАКОН - это не язык целостного описания систем, но ведь у него и в том состоянии,
в котором он находится сейчас, имеются и некоторые проблемы (например см. мое сообщение выше).
Конечно, ДРАКОН красив по сравнению с архаичными блок-схемами, у которых от каждого блока
к другому нужно рисовать стрелочку, да и сами элементы блок-схем изображать друг относительно
друга достаточно произвольным образом.
Упорядоченность и структура как правило всегда красивее хаоса.
Но время не стоит на месте - ООП и UML бросили очень сильный вызов - программа представляется
как структура классов с маленькими методами-обработчиками на полэкрана - для таких и алгоритмы
не очень нужны, а если и нужны, то для этого есть UML-диаграммы.
Есть конечно у UML и недостатки, куда уж без них.
Но речь сейчас о недостатках ДРАКОНА. А то, что он не подходит с философской точки зрения -
слишком общий ответ.
Может, скажете что-нибудь конкретное про эргономический и алгоритмический аспекты ?

Зачем за большинство придумывать что ему интересно?
Мне вот интересно. Людям вокруг меня — интересно. Программисты - те вообще приверженцы всяких дзенов : )

Имхо, приведённый Вами пример прекрасно описывается классическим Драконом, без привлечения "нуль-Т" переходов.
(см. Рис. 2)

Да Эдуард, Вы правы в этом конкретном случае, и я думаю что и для многих
других случаев тоже.
Но Вам пришлось заплатить:
1) увеличением числа связей на схеме;
2) отказом от силуэта.
И это при том, что схема достаточно простая.

А вопросы такие:
1) Как отделить главные логические связи от второстепенных и сделать
так, чтобы второстепенные (или, скажем, менее значимые) связи не затеняли
основную структуру алгоритма.
2) Если можно не отображать логические связи для цикла ДЛЯ, то
почему только для него и где проходит граница ?
Язык ДРАКОН в его нынешнем состоянии ответа на эти вопросы к сожалению
не дает.

Уважаемый Владимир!

Я искренне считаю Ваше подвижничество очень нужным и полезным делом. Это вселяет оптимизм, дарит надежду (в наше не самое светлое время!). Однако при этом у меня есть внутреннее неприятие многих идей, которые Вы высказываете, не обессудьте. Вполне возможно, что именно этот факт и влияет на мое восприятие Дракона. Но мне бы хотелось подчеркнуть, что я недостаточно знаком с языком Дракон, чтобы заниматься его критикой. Мои суждения строятся на тех проблемах, которые поднимаются и обсуждаются в данной конференции, а этого... недостаточно. Высказывать же какие-то мысли в основе, которых лежат предположения... несерьезно. Я постараюсь познакомиться с Драконом поближе, возможно тогда я смогу быть более полезным. А пока, я должен принести свои извинения.
Отдельно мне бы хотелось отметить один момент... Вы говорите о том, что Дракон (и концепция в целом) являются первопроходцами. Я не подвергаю этот факт сомнению, просто может быть Вам будет интересно... В начале 90-х мне довелось познакомиться и работать с двумя интересными людьми Александром Блинковым и Андреем Киселевым. Они были заражены примерно той же идеей: создать формальную основу для... (творческой!) деятельности. В основе была идея формализации на основе... законов термодинамики. Позже, в 1994 г. они издали книгу: Блинков. А.В., Киселев А.Н. "Решение всех проблем. Неординарное мышление и поведение." Екатеринбург: Баско, 1994. (Весьма занимательная книга... несмотря на столь претенциозное название). Они творили примерно в то же время, что и Вы, хотя и на другой основе, но с близкой, как мне кажется, целью. Читая Вашу книгу, я невольно замечаю за собой, что строю параллели, между тем, что пишите Вы и тем, что предлагали они... Но принять ни то, ни другое я пока... не готов. Мысли А. Блинкова можно почитать здесь.

Пожалуй, так можно сказать:
1) Сразу логически выводить структуру алгоритма. Тогда в ней должны оказаться только значимые связи. Пример (как раз на уход от циклов ДЛЯ) - здесь. Кстати, там также ушли от "лишних" величин.
2) Цикл ДЛЯ в техноязыке - это наследие ГОСТ. Там и правда не предусмотрено отображение петли цикла - что не есть эргономично (в том же примере я восстановил петлю как пунктирную дугу). Авторский ДРАКОН даёт ответ на вопрос - как ещё можно визуализировать цикл ДЛЯ - на базе цикла ДО (логика которого и лежит в основе) - см. этот рисунок (представляет просто "графитное" абстрагирование идеи, показанной на конкретном примере в /Как улучшить работу ума, с. 136/).
Кстати, непонятно, почему у Вас здесь на правой схеме дуга петли цикла двунаправленная?

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

Драконограф пишет:
>Кстати, непонятно, почему у Вас здесь на правой схеме дуга петли цикла двунаправленная?

Да потому, что при некоторых условиях цикл ДЛЯ может вообще не выполняться ни разу, и
тогда просто следует обход блока, находящегося внутри цикла.

Я к этому отношусь по-другому.
Я приобрёл понимание того, как работает алгоритм. Теперь не нужно искать «дырки в пространстве». Имеется чёткая топология, абсолютно точно отображающая исходную схему.
P.S. А Вам пришлось заплатить отсутствием связей, там где они должны быть.


Что в этом плохого? Простая схема требует простых решений.


Главные логические связи отделяет от второстепенных создатель алгоритма.
Что бы второстепенные связи не затеняли главные их нужно выносить вправо.
Я так и сделал на Рис. 2.


Потому что так дано в определении языка, никто не мешает Вам или мне определить другой язык.
Граница проходит по циклу ДЛЯ.

Мне интересны реальные случаи, когда Дракону необходимы нуль-Т переходы, но до сих пор получалось обходиться без них.


У меня предложение, давайте, если Вы не против, Вы предоставите мне схему, скажем, с 20-ю нуль-Т переходами в Ваших определениях, желательно реальную, а не «сферического коня», а я попытаюсь отобразить её на классическом Драконе. Результаты обсудим.

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

Ну, это не бесспорно. У хаоса тоже есть своя красота, величие и могущество. Кстати, хаос - непременный атрибут... творчества. Антуан де Сент-Экзюпери замечательно сказал: "Жизнь творит порядок, но порядок жизнь не творит"... Я не призываю к хаосу, но... без творчества как-то скучно...
Что касается Дракона, то я пытаюсь с ним... сблизиться. Если получится, то я напишу Но "квантор всеобщности" у формального языка... мне откровенно мешает.
У UML не может быть недостатков... по определению! Поскольку основное определение UML - это недостаток. Вспомните историю того, как создавался UML... В конце 80-х никому тогда неизвестный Г. Буч ездил по конференциям и агитировал народ за то, чтобы сесть за стол и разработать единый(!) язык описаний. Он патетически заламывал руки и восклицал: "Я вижу будущее, и оно объектно-ориентированное". Некоторые клюнули на его "рекламу", но создать что-то концептульно стройное, конечно, не удалось. Каждый пытался втащить в UML что-то свое и получилась свалка, которую уже у самих авторов... язык не поворачивался назвать "единым", назвали "объединенным"... А когда Г. Буч и Ко начинают рассуждать о системах, то... лучше... перекреститься.
Простите, пока другого ответа у меня нет.[/quote]
С этими аспектами, я надеюсь, все в порядке. Меня пока настораживают попытки описать на Драконе любую деятельность и соответствующие подвижки в самом языке.

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

Эдуард Ильченко пишет:
>Мне интересны реальные случаи, когда Дракону необходимы нуль-Т переходы, но до сих пор получалось обходиться без них.

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

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

Так Вы полагаете, представление через цикл ДО у Владимира Даниеловича неверно/неполно?

Это частность.