DRAKON.SU

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

Есть набор данных. Есть тип данных "событие". Есть тип данных "обработчик события". Последний выражается алгоритмом. В чём проблемы? Всё элементарно же!

Мы НЕ ЗАДАЁМ единый алгоритм формы.
Мы задаём специфический набор данных, обладающих собственным поведением.
Проблем нет.

Так это не мне намекать надо, я об этом здесь давно талдычу

Имеет. Это тоже язык.
Если угодно, можно назвать метаязыком, языком другого уровня.
Любая формальная система представления есть язык.

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

А возникают эти уровни, имхо, из-за изначальной неадекватности инструмента-языка решаемой задаче.
Вот тут и рождаются правила по применению языка, правила по формализации правил (ака стандарты), научные школы и т.д. и т.п.
Может, лучше задачу решать?

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

Это не представление, а правила оформления. Язык не заставляет рисовать "шампуры", не делать пересечений... разбивать на процедуры длинные фрагменты кода, включать комментарии и т.п. Все это правила.
Зачем???
Да, нормальный инструмент... для записи алгоритмов. Но пытаться на нем рисовать процесс познания или систему какую-то я бы не стал (это не сфера применения данного средства и говорить об адекватности таким задачам, IMHO, некорректно).

Для чего?
Мы же вроде как обсуждаем достаточно глобальные вопросы - причём тут мелкая техническая привязка к реализации подпрограммы?

И чем, кстати, Вам не нравится передача кучи параметров по ссылке?

Процедура - это такой же объект в системе, имеет связи с другими объектами (потоки управления, потоки данных). Поэтому можно ещё классифицировать подпрограммы по "ширине интерфейса с системой".
Один крайний случай - подпрограмма имеет доступ ко всему (глобальному) пространству состояний.
Другой крайний случай - функция, которая возвращает результат в виде одной переменной.
Между ними есть множество промежуточных вариантов, когда "ширина" входного и выходного потока данных ограничена и регламентируется интерфейсом процедуры. Интерфейс может быть декларируемым (как в большинстве языков программирования) или даже недекларируемым (как в Форте). Возможностей - миллион.

Форма в данном случае является контейнером данных и алгоритмов, если уж на то пошло.
Любое преобразование данных (включая передачу их по интерфейсу GUI) задаётся алгоритмами. Куда ни копни, внутри в качестве элементарного кирпичика будет алгоритм. Сама по себе форма, конечно же, алгоритмом не является, но это нам ничего не даёт.
В данном случае нам нужно иметь средства проектирования:
- внутренней структуры контейнера (взаимосвязи кирпичиков данных и алгоритмов);
- внешних интерфейсов контейнера;
- самих алгоритмов-кирпичиков;
- визуальных представлений контейнера...

Так я и не говорю про Дракон. Просто он является поводом поговорить о проектировании в целом.

Ну так я и пишу об адекватности инструмента

Таки язык, Александр, язык. Пусть неформальный, пусть мета, но язык.
А любой язык организует ПРЕДСТАВЛЕНИЕ рассматриваемого предмета С ОПРЕДЕЛЁННОЙ ТОЧКИ ЗРЕНИЯ. Это - основная функция языка, имхо

Даже для рисования алгоритмов - не самый нормальный. Нужны же ведь 3д очки!

Я просто пример привел. Конкретный пример это всегда частность.
Дело не в том, что нравится или не нравится. Нелогичным кажется тот момент, что N-параметров возвращаются, как VAR-параметры, а один, как результат функции.
Да, конечно.
Почему передача включена в преобразование?.. И почему Вы решили, что преобразование данных обязательно задается алгоритмами? А если преобразование выбирается самими данными, по одним им ведомой причине... то есть, не задано в виде последовательных шагов...
Хорошо, давайте копнем... атом - это алгоритм или система? А человек? А вселенная?
Почему ничего не дает?
Построитель форм + набор компонентов + компилятор в некое подобие .RC-файлов.
А!.. Простите великодушно, я этого не понял...
Мы, наверно, слишком различно смотрим на понятие "язык"...
А почему, собственно, алгоритмы должны быть плоскими?.. Может для того, чтобы появился повод обсуждать пересечения?

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

"Атомов не существует, поверьте квантовому химику!" (с) А.Хаврюченко

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

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

Поздравляю вас с этим "открытием".

дык, более того - никто пока толком не объяснил (или я не заметил), что такое "требования структурности" в применении к алгоритмам

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

На всякий случай напомню:

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

+100

"Алгори́тм, от имени учёного аль-Хорезми — точный набор инструкций, описывающих порядок действий исполнителя для достижения результата решения задачи за конечное время. " - Это википедия. Система есть совокупность статических и динамических объектов, каждый из которых работает по собственному "алгоритму". Зачем смешивать понятия ?

Структуризация кода позволила, в свое время, существенно снизить сложность программ. А снижение сложности создания программ, в свою очередь, позволило повысить сложность решаемых задач. Для примера...
Снижение сложности за счет локализации кода:
Код разбит на подпрограммы, вход в подпрограммы выполняется через единственную точку входа. Таким образом, функционально единая часть код локализована в теле подпрограммы и на нее не может быть совершен произвольный переход. Происходит существенное снижение количества потенциально возможных связей и, следовательно, сложности программы в целом.
Снижение сложности за счет локализации данных:
Данные в структурном программировании выступают в трех видах:
1. Глобальные данные, отвечающие за сохранение значений между вызовами подпрограмм и доступные из всех подпрограмм (глобальная область видимости);
2. Локальные данные, доступные только внутри подпрограммы и недоступные для других подпрограмм;
3. Фактические параметры, передаваемые в подпрограмму извне.
Механизм формально/фактических параметров, в частности, позволил избавиться от зависимости от глобальных данных, а, следовательно, создал возможность переносимости отлаженных подпрограмм между разными программами.
Механизм локальных данных позволил подпрограмме изолировать свои данные от модификации извне. То есть, обеспечить снижение связности по данным.

Сказанное выше не исчерпывает то, что привнесено структурным программированием или им "узаконено".

Ну не знай, не знай!
Имеющий глаза, как говорится, да увидит по вере своей!

Истоки - да, согласен.
Путь-то, однако, накатан уже, вся инфраструктура... Сфоторгарфировал (цифровым аппаратом), обработал фото (программой, по стандартному алгоритму), ну и т.д.
Мы ж не будем сейчас говорить об уходе от компьютеров и цифровой техники?

Хотя могло бы быть интересно

полностью согласен... но сильно подозреваю, что речь немного не об этом была...

Уважаемым albobin был предложен вариант, который остался вроде бы незамеченным. Наверно, потому что не был визуализирован : )
Визуализирую : ) см. рисунок справа.



Учитывая, что q3 выход по ошибке, то алгоритм стал даже понятнее. Конечно, имхо.

IMHO - если из словесной спецификации Алексея исходить, то именно s5 д.б. на главном маршруте фрагмента (ох, жаль, что "туннели" не используем - вот и рисуем часть как целое ) - а альтернатива по q3 на побочном. Так что с этой т. зр., если не разрешать пересечения - лучше правая схема на цветном фоне.

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

Не могли бы Вы графически изобразить вышеуказанный алгоритм, с использованием "туннелей"? По Вашей ссылке не могу сообразить что к чему ... : (

В принципе там определение, а примеры разбросаны по иллюстрациям Вот я сделал специально эскиз (заодно уж и с областями - раз уж о них писал). Варианту А соответствует на этом рисунке, допустим, правая из схем на цветном фоне, варианту Б - Ваша схема.
Тела схем рисовать не стал - обозначил шампур-заместителями : P.S. Посмотрел - в альбомном формате лучше компонуется. Заодно кое-что изменил - чтобы ещё некоторые вещи показать.

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

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

P.P.S. Взял больший формат и разделил способы. Видно, что автономная область отличается от выноски отсутствием атрибуции статуса сочинения. А кроме того, любая вынесенная область - элемент своеобразного каталога вариантов (палетты) для оперативного подключения к любой модели (в т.ч. из другого документа). Выноска же делается всегда в том же документе и частью модели не является - м.б. связана только по ссылке с ограничителем, который указал сочинитель - в общем, в терминах IDEF, это "схема FEO".

Да, об индексах областей (в т.ч. группах подстановки) см. в этом подпункте; там же - о смысле атрибутов 'Вх?' и 'SUBSTEXT' (на примере определения синт-переключателя во второй части). О цветовых обозначениях текста для графит-макетов - стр.1 в словаре на этой схеме.

Честно скажу, так и не понял как это всё поможет отобразить алгоритм в наиболее понятном виде : ) Вплоть до неясности с тем, что такое "обсуждаемый фрагмент схемы": лиана от q3, икона q3 с лианой или какой-то другой набор элементов.

Ну, да ладно : ) Всё равно большое спасибо!

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

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

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

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