DRAKON.SU

Текущее время: Четверг, 28 Март, 2024 18:24

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 72 ]  На страницу Пред.  1, 2, 3, 4  След.
Автор Сообщение
СообщениеДобавлено: Вторник, 07 Июль, 2020 23:12 

Зарегистрирован: Пятница, 08 Декабрь, 2017 18:24
Сообщения: 439
Откуда: Астрахань-Сочи
А_МУР писал(а):
Все кто до сих пор участвует в форуме - это люди связанные именно с практическим программированием ЭВМ, а так же подавляющее большинство пользователей ИС Дракон "практикующие"(воспользуюсь врачебным термином) программисты

Мне сложно называть себя программистом. Скорее специалист по проектному обучению. И мне ДРАКОН интересен скорее как способ описания специфического знания, а не инструмент для создания программы для ПК/МК. Но использую его для программирования, т.к. это детям интересно, и результат быстро достижим.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 11 Июль, 2020 13:50 

Зарегистрирован: Среда, 27 Сентябрь, 2017 18:44
Сообщения: 332
Дмитрий Бардынин писал(а):
А_МУР писал(а):
Все кто до сих пор участвует в форуме - это люди связанные именно с практическим программированием ЭВМ, а так же подавляющее большинство пользователей ИС Дракон "практикующие"(воспользуюсь врачебным термином) программисты

Мне сложно называть себя программистом. Скорее специалист по проектному обучению. И мне ДРАКОН интересен скорее как способ описания специфического знания, а не инструмент для создания программы для ПК/МК. Но использую его для программирования, т.к. это детям интересно, и результат быстро достижим.


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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 03 Сентябрь, 2020 17:10 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 396
А_МУР писал(а):
У Владимира Даниловича нет четкого описание свойств Вставки
В тех случаях когда ее используют (которые я видел здесь и на видео)
Вставка это отдельный экземпляр процедуры со своим пространством имен, и нуждающийся в передачи данных из схемы в Вставку и Обратно
[...]
Капсула использует пространство имен, самой схемы в которой находится, ей не нужно задавать отдельные переменные, соответственно она их и изменяет при исполнении.
вместо набора икон формируется одна икона с заданным именем. В дереве проекта, под именем схемы, формируется дочерний узел с именем капсулы.
в дальнейшем можно пройти в капсулу и отредактировать ее внутреннюю схему. Также можно копировать капсулу в другие места программы.
Основная особенность капсулы- капсула не нуждается в объявлении переменных и экземпляров, и использует переменные "Материнской" Схемы
Данный механизм сродни Действию в ООП, но все же он отличается, и продиктован не подражанием ООП, а удобством дальнейшей работой со схемой

Вспоминается методика по Зюбину:
* https://forum.oberoncore.ru/viewtopic.php?f=152&t=5971&view=previous#p99829

* Пути расширения языка ST из состава МЭК 61131-3 для задач промышленной автоматизации

* Программирование информационно-управляющих систем на основе конечных автоматов: учебное пособие

* Разработка графического формализма для описания алгоритмов в процесс-ориентированном стиле

Там свой язык для ПЛК (текстовый и вариант блок-схем). Транслируется в С, всё на глобальных переменных, однако процессы имеют своё логическое распределение имён с заданными областями видимости -- мол такие-то переменные доступны всем процессам или таким-то выбранным. Процесс может иметь вход/выход как ссылки на переменные других процессов.
В общем, есть смысл взглянуть на тамошние мотивы, может быть подскажут что-то насчёт организации общих алгоритмов (именно общих или обобщённых, когда нужны и параметры подпрограмм). При трансляции, как вариант, подпрограммы можно сливать и в общую "goto-лапшу" или "автомат" единого тела FB, как здесь:
https://forum.drakon.su/viewtopic.php?f=211&t=6305&start=40#p102165


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 03 Сентябрь, 2020 17:13 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 396
А_МУР писал(а):
Использование процедур в Драконе вызывает большое количество ошибок и лишних икон

Например попробуйте использовать процедуру Таймер или Тригер фронта. Если в программе только два маршрута , то все еще пока логично, но как только становится маршрутов больше- возникают следующие условия использования Вставки:
1)необходимо чтобы процедура вызывалась каждый цикл программы, тогда мы перемещаем икону " Вставка" вызова процедуры в начало программы или конец, что делает схему не читаемой- ведь хорошо когда икона находится на своем месте по графическому смыслу
2)В каждом маршруте должна появится управляющая икона, которая должна взводить управляющую переменную, если проглядеть эту икону и не поставить в нужное место, программа начинает работать неправильно - А теперь если у нас 20 маршрутов, то и Управляющих икон должно быть 20 (икон паразитов которые занимают место)
3) работа с выходными значениями требует появления таких икон как Вопрос и Выбор

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

Вспомнились ваши примеры, среди них:
https://forum.drakon.su/viewtopic.php?f=211&t=6305#p102080

На первом рисунке по ссылке выше есть применение ФБ "ТАЙМЕР_ИМП_1" -- видимо, пример "классики".
Там же в теме "комментарий" по означенной проблематике:
https://forum.drakon.su/viewtopic.php?f=211&t=6305&start=20#p102163
А_МУР писал(а):
Чисто техническая ветка.... Смысл ее заключается в следующем: под экземпляр в контролере выделяется память все пременнные в экземпляре сохраняются Если не обращатся к подпрограме то состояние переменых в подпрограмме много....Много циклов контролера ОСТАЮТСЯ БЕЗ ИЗМЕНЕНИЯ Это приводит к "зависанию" пременных ЭТО вопрос к Владимиру Даниловичу- КАК ГРАФИЧЕСКИ ВСЕ ЭТО ПРЕДСТАВЛЯТЬ???

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 03 Сентябрь, 2020 17:22 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 396
https://forum.drakon.su/viewtopic.php?f=211&t=6860#p104864
А_МУР писал(а):
Попробуйте сделать схему на 200 икон и потом ее разобрать?

Увы, не попробую (особенно на 200 икон). В своей деятельности с ПЛК/встроенкой не повязан, о предметке поверхностные представления.
Для оперативной деятельности (программирование) Дракон не использую, лишь для моделей "верхнего уровня", постановок задач. И то, если не нужна "презентация", то в ходу псевдокод (или иногда реальный специализированный скриптинг) и Р-схемы, заменить их Дракон-ом всё никак не получается.
Однако позволю себе предположить, что в случае 200 и более икон необходима некая иная методика, изначально "разобранная", что ли...
А_МУР писал(а):
LCOM обратите внимание причем МАТЛАБ и Дракон
Это последняя запись по теме ИС Дракон!
Это явно не я писал!!!
Цитата:
Конечные автоматы - будущее ПЛК программирования. Обратите внимание на Matlab Simulink Stateflow. Он также умеет генерировать ST код.


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

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

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

Возникают вопросы по поводу непосредственно вычислительной модели. У Зюбина кроме "состояний" есть и "логический параллелизм" процессов через их "ручной" запуск/останов -- если под "процессами" эмулировать применение ФБ, то моделирование тогда оторвано от "традиционного" использования ФБ или предполагается иной стиль работы. Однако не стоит сразу же отбрасывать "чужеродное" -- не так уж просто по-другому вырулить на Дракон-е...

У Ефанова, к примеру, задействована модель на базе switch-технологии от Шалыто, где есть "задержка результатов" на один такт исполнения системы согласно политики диспетчеризации процессов -- не от хорошей жизни. К тому же в этом случае возникают обвязки в виде отдельных переменных-"сообщений" (требующих специализированной инфраструктуры, т.е. набора операций или "фреймворка" для своей поддержки) -- в дополнение к имеющимся "свойствам" ФБ (их входам/выходам, если внедрять такую модель поверх ФБ).
А_МУР писал(а):
Кстати давно на форуме не было нашего глубоко уважаемого коллеги Ситникова Владимира, а вот на форуме Овен он активен сейчас!

Помнится, он критиковал модели автоматов выше, небезосновательно. Предлагал использовать "паузу" как границу "такта" (или "автоматного состояния") в алгоритме, если не ошибаюсь, под впечатлением методики реализации корутин в Kotlin.
Но в целом методология так и не была обозначена в какой-то более-менее целостной форме.
А_МУР писал(а):
1702-2020-00745. Предоставление (передача) на условиях неисключительной лицензии прав на использование программ для электронно-вычислительных машин и поставка (передача в собственность) сертификата на техническую поддержку ПО ANSYS на период до 31.12.2022 г.

Вот у ANSYS, в тамошней SCADE, автоматы очень-таки толково выглядят.
А_МУР писал(а):
Опять же я повторю самое главное отличие Дракона и Других языков:
Дракон - это поток управления,
Другие языки -поток данных.
Таким образом нужно использовать сильную сторону Дракона - объективность управления

Можно воспользоваться некоторыми фундаментальными принципами от упомянутой "многолимонной" SCADE и внедрить их, но уже в "наколенную" императивщину "для бедных". Ключевое:
- автомат как гиперфункция (на манер терминологии от Зюбина выше) -- функции/процессы могут изменять своё поведение во время работы в качестве реакции на один и тот же вход -- полиморфный гиперпроцесс с "переключением" или выбором функций во время исполнения;
- иерархическая и параллельная композиция автоматов с "вытеснением" -- прекращением работы автоматов или переводом их в иное состояние;
- так называемый "модульный reset" -- операция вида "сброс состояния" или "начинать сначала", "в исходное" или т.п., распространяемые косвенно в разрезе нужной композиции процессов.

Нужна оценка, насколько может быть усложнён язык моделирования и оправданно ли...

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 03 Сентябрь, 2020 17:26 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 396
Расширим базовый тезаурус императивного языка моделирования (в дополнение к последовательности и goto, развилкам и циклам).

Добавим "паузу" в потоке управления или "передача управления". Пример, абстрактный псевдокод:
Код:
sub f1(in a: int; in b: real; out y: real)
{
    if cond(a) then
      y := calc1(a, b);
    else
      y := calc2(a, b);
    end;
    yield;
    y := calc3(a, b);
}

Подпрограмма f1 обозначена через sub, чтобы подчеркнуть, что речь не о традиционных функциях как комбинаторных автоматах без состояния (обозначаемые часто как fn/function и т.п.).
Оператор yield -- приостановка или выход из алгоритма (не окончательный "возврат"/"return") с выдачей выходных данных (если имеются). При следующем такте, т.е. вызове f1(...) с новыми входными данными, управление восстановится в точке yield, и алгоритм продолжит исполнение далее (при этом все необходимые внутренние переменные сохраняют своё состояние). При достижении конца алгоритма или оператора вида return последующий такт исполнения осуществляется с начала тела алгоритма.

Так в данном примерчике имеем два варианта расчёта "y", исполняемые попеременно.

Предполагается предельная абстракция. Функция/процедура рассматривается как "вручную" регулярно вызываемая аля сопрограмма/корутина/субрутина (или, если угодно, как некий аналог селективных хранимых процедур в SQL-СУБД), со ссылками на входные/выходные данные (в сигнатуре опции in/out). Интерпретация разная: в каких-то случаях подпрограммы понимаются как "протоколы о намерениях", на основе которых осуществляется реализация распределенных систем, где-то формализм "переводится" или адаптируется на язык структур/объектов ("сохраняющих" состояние) с набором связанных методов (т.е. реальное сохранение и модификация данных осуществляется в "полях" структур/объектов), где-то непосредственно в технологическом языке возникнет прямая реализация (операции yield и др.), как в том же упомянутом Kotlin, например, и т.д.
Таким образом, предполагается отсутствие какого-то специализированного планировщика процессов и т.п., в этом случае "диспетчеризация реагирующих алгоритмов" -- повторное исполнение "вручную" или повторный вызов процедуры/функции/функционального блока (где-то там, в каком-то "управленческом" цикле, например). Или же задачи композиции совместно исполняемых процессов являются дополнительными согласно уже конкретной предметке, вне означенных рамок, в этом случае операция yield осуществляет передачу управления условному диспетчеру и т.п.

Р-схема, текстовая псевдографика:
Вложение:
r1.png
r1.png [ 5.39 КБ | Просмотров: 6450 ]

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

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 03 Сентябрь, 2020 17:29 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 396
Пример использования "yield" в цикле -- цикла вида while, с множеством условий (ака "цикл Дейкстры") -- выполняем действия пока валидны предикаты цикла и "выходим" во внешнюю среду каждый раз после итерации:
Код:
var fb1: FB1(...);
var fb2: FB2(...);
var fb3: FB2(...);

sub f1(in a: int; in b: real; out y: real)
{
    ...
    y := p1();
    while fb1(a, b) < limit do
        if cond1(a) then p2()
        else p3() end;
        y := calc1(a, b);
    elif fb2(a) do
        p4();
        y := calc2(a);
    elif cond2(a, b) & cond3(fb3(a), b) do
        p5();
        y := calc3(a, b);
    then
      yield;
    end;
    y := calc4(a, b);
    ...
}

Вложение:
r2.png
r2.png [ 16.76 КБ | Просмотров: 6450 ]

Переменные fb1, fb2, fb3 символизируют другие "процедуры с состоянием" ("функциональные блоки").

Тело оператора "while ... end" (на схеме цикл выделяется "петлёй" -- двойной дугой) дополняется "then"-частью -- общая зона действий, исполняется в случае срабатывания какой-либо "охраны" (условия цикла), т.е. при наличии итерации цикла. В данном случае там единственный yield. После каждой итерации выполняется "выход". Когда цикл "непроходной" (не сработала ни одна охрана), то он завершается (без "выхода", поскольку "проход" в конечную вершину структуры-цикла в данном случае интерпретируется по двойной дуге).
На схеме then-часть цикла трансформирована в единственную вершину с точкой (общая вершина для всех структур под двойной дугой).


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 03 Сентябрь, 2020 17:36 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 396
Оператор выбора/ожидания событий.

Такие "акты коммуникации" имеются как и в различных теоретических "исчислениях процессов", так и в ряде языков моделирования/программирования в виде операторов select, receive и прочие спецоперации. Ниже используется оператор select:
Код:
var fb1: FB1(...);
var fb2: FB2(...);
var fb3: FB2(...);

sub f1(in a: int; in b: real; out y: real)
{
    ...
    p1();
    select fb1(a, b) >= limit do
      if cond1(a) then p2(a)
      else p3(a) end;
      p4(b);
    elif fb2(a) do
      p5(a);
      p6(b);
    elif cond2(a, b) & cond3(fb3(a), b) do
      p7(a, b);
      p8(b);
    else
      if cond4(a) then
        y := calc1(a, b);
      else
        y := calc2(a, b);
      end;
      p9(a, b);
    end;
    reset(fb1, fb2, fb3);
    y := calc3(a, b);
    ...
}

Вложение:
r3.png
r3.png [ 14.35 КБ | Просмотров: 6449 ]

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

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

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

Так в примере в else-части осуществляется установка выходных данных пока ожидаются заданные события. В случае возникновения событий выполняются какие-то действия и "выбор" завершается.


К переменным fb1, fb2, fb3 применяется условно стандартная операция reset -- "сброс" состояния для заданных объектов/функциональных блоков. Сброс заключается в прекращении всех возможных "пауз" у процесса -- осуществляется прерывание операций ожидания "входа" и завершение всего алгоритма.

В дополнение к возможным стандартным операциям вида "конструктор/деструктор", в т.ч. и как здесь -- Init и Exit в ООП для функциональных блоков:
http://prolog-plc.ru/oopIECru

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

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

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

В свою очередь, и исходный алгоритм f1 может быть "сброшен" когда-то извне.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 03 Сентябрь, 2020 17:38 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 396
Частный случай -- ожидание единственного события и ничего не делать:
Код:
...
p1();
await Cond(...);
p2();
...

Вложение:
r4.png
r4.png [ 1.71 КБ | Просмотров: 6449 ]


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 03 Сентябрь, 2020 17:40 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 396
Цикл ожидания событий (оператор "for select"):
Код:
var fb1: FB1(...);
var fb2: FB2(...);
var fb3: FB2(...);

sub f1(in a: int; in b: real; out y: real)
{
    ...
    p1();
    for select fb1(a, b) >= limit do
      if cond1(a) then p2(a)
      else p3(a) end;
      p4(b);
    elif fb2(a) do
      p5(a);
      p6(b);
    elif cond2(a, b) & cond3(fb3(a), b) do
      p7(a, b);
      p8(b);
      if CondExit(a, b) then exit end;
    else
      if cond4(a) then
        y := calc1(a, b);
      else
        y := calc2(a, b);
      end;
      p9(a, b);
    end;
    reset(fb1, fb2, fb3);
    y := calc3(a, b);
    ...
}

Вложение:
r5.png
r5.png [ 15.43 КБ | Просмотров: 6449 ]

(в языках моделирования/программирования с оператором вида "select" не всегда встречается отдельный специализированный циклический оператор для выбора событий).

Дуга-"выбор" задана как двойная ("петля"). События "выбираются" циклически, т.е. после успешного "срабатывания" выбор повторяется. Цикл может быть завершён через оператор вида exit/break (на схеме отмечен как структурный переход "#" -- на конец данного блока -- выход из цикла), или иным способом (см. далее). Или же цикл может быть прекращён внешне, как и весь алгоритм -- через "сброс" где-то извне.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 03 Сентябрь, 2020 17:42 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 396
Изменим пример с циклом "for select" след. образом:
Код:
var fb1: FB1(...);
var fb2: FB2(...);
var fb3: FB2(...);

sub f1(in a: int; in b: real; out y: real)
{
    ...
    p1();
    for select fb1(a, b) >= limit do
      if cond1(a) then p2(a)
      else p3(a) end;
      p4(b);
    elif fb2(a) do
      p5(a);
      p6(b);
    elif (cond2(a, b) & cond3(fb3(a), b))
         or cond4(a) do
      p7(a, b);
      p8(b);
      if CondExit(a, b) then exit end;
    else
      if cond5(a) then
        y := calc1(a, b);
      else
        y := calc2(a, b);
      end;
      p9(a, b);
    finally 
      reset(fb1, fb2, fb3);
    end;   
    y := calc3(a, b);
    ...
}

Вложение:
r6.png
r6.png [ 16.45 КБ | Просмотров: 6449 ]

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

Действия по "сбросу" объектов fb1, fb2, fb3 перенесены в секцию finally, операция reset на схеме указана альтернативно через имя "~".


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 03 Сентябрь, 2020 17:50 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 396
Ещё одна полезная секция -- "наблюдатель" (unless):
Код:
   
var st: stream(...);
var d: data;
...
p1();
st.prepare(...);
do
  d := st.read(...);
  p2(d);
  if cond(d) then
    p3(d);
    st.write(d, ...);
  else
    st.write(d, ...);
  end;
  st.write(d, ...);
unless st.eod() do
  print('bad data');
elif st.err() do
  print('error: ' + st.errstr());
finally
  st.done(...)
  p4(); 
end;
p5();

Вложение:
r7.png
r7.png [ 11.93 КБ | Просмотров: 6449 ]

В упомянутой SCADE есть всякие способы "вытеснения", воспользуемся вариантом на манер оператора "do ... unless ..." из SCADE/Lustre (делать что-то пока не произойдут такие-то события) или "watching" из императивного SCADE/Esterel. По сути подобные операторы представляют из себя иерархическую композицию автоматов, где автоматы верхнего уровня имеют приоритет в реакциях на события и могут реагировать в виде переходов в иное состояние, "вытесняя" или прекращая работу внутренних вложенных автоматов (на диаграммах состояний так всё и отображается в явном виде).

В примере блок "do...end" (аналог "begin...end") разделен на секции, задействуя "финализатор" (finally) и "наблюдатель" (unless) -- последний на схеме обозначен параллельной структурой через спецвершину "(:)". Как и для оператора "выбор", в секции unless предполагается наличие начальных предикатов (из своей стартовой вершины) -- события, при возникновении которых немедленно осуществляется проход по данной структуре (выполняются указанные действия и пр.) и весь блок "вытесняется" (осуществляется немедленный выход из блока), с исполнением "финализатора" (если есть). Если при работе "наблюдаемого" блока указанные события не возникают, то секция unless не исполняется.

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

Данные могут возникать при "входе" во время любого "ожидания" -- секция unless может контролировать и "выбор события" в каком либо виде, в том числе может прекращать работу циклов "for select" (циклический выбор событий ранее) и любых циклов вместо операторов exit/break. В случае "выбора событий" семантика "доступности" данных такая же, как и для соответствующего оператора "ожидания", но у unless выше приоритет.

Если анализируются "пассивные" изменяемые объекты -- операнды, над которыми совершается работа, то предполагается анализ их нового состояния после совершения операции над ними.

Так в примере используется некий объект st типа stream (какая-то работа с потоком данных). После каждой операции чтения/записи (изменяющей состояние объекта) возможны проблемы: может возникнуть техническая ошибка -- метод "err()" возвращает true, если объект находится в "ошибочном" состоянии; может быть выявлено окончание данных или их некорректное состояние -- метод "eod()" сигнализирует об этом.
В каких-то случаях может быть выстроен цикл вида:
Код:
while ~st.eod() & ~st.err() do
  st.read(...)
end

Выше "опасное" действие в цикле находится под "защитой" его условия. В исходном примере нет подобного цикла, необходимо делать проверки после каждой операции с потоком (или перед последующей операцией с ним). Можно действовать "в рамках структурности" -- анализировать "вручную" каждый раз и далее продвигаться согласно "защите" потока управления (без дополнительных досрочных выходов и т.п.), как здесь, например:
https://forum.oberoncore.ru/viewtopic.php?f=27&t=3175#p57990
https://forum.oberoncore.ru/viewtopic.php?f=6&t=2290

Однако, каждый раз требуется один и тот же анализ (и реакция). В программировании напридумано немало трюков, чтоб "выкручиваться" в подобных случаях: задействование механизма исключительных ситуаций (сами операции "бросают исключения"), обвёртки в виде спецфункций/макросов (или их аналог в виде специализированных языковых инструкций в условно новых ЯП), генерирующие исключения или осуществляющие досрочные выходы из функций, либо производящие скрытые goto в нужные места и пр.
В автоматных же методиках ("реагирующих") полвека назад предполагалось выделение "главного" автомата, наделенного в едином месте полномочиями (т.е. некие общие действия, которые должны быть во множестве мест, выносятся в единую точку).

Так в примере выше внутри do-блока после каждой операции с объектом st в случае проблем блок сразу прекратит работу. В некотором смысле в данном случае предикаты "защитных" событий (в операторе unless) являются внешними, т.е. эти условия связаны с внешними данными (данные из некоего потока), мол на которые реагирует "скрытый главный автомат".

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

В том числе через unless можно выразить и перехват exception/trap и т.п., если требуется конкретикой технологического языка.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 03 Сентябрь, 2020 17:52 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 396
"Наблюдатель" возможен и при использовании "активных" объектов -- объектов, совершающих работу -- параллельные, конкурентные процессы:
Код:
var ao: ActiveObj(...);
var d: data;
...
p1();
do
  d := ao.GetData(...);
  if cond1(d) then
    while cond2(d) do
      d := ao.GetData(...);
      p2(d);
      if cond3(d) then ao.SetData(...) end;
    end;
  end;
unless top(ao) do
  print('ao done');
elif d < 0 do
  print('bad data');
end;
p3();
...

Вложение:
r8.png
r8.png [ 10.28 КБ | Просмотров: 6449 ]

В примере используется некий объект ao типа ActiveObj, имеющий свой параллельный поток управления. Предикат в unless как функция "top(ao)" (на схеме альтернативно -- крышечка с аргументом) означает "сигнализирующее" состояние у объекта -- в данном случае: объект завершил свою работу (сигнал по умолчанию).
Для "активных" объектов анализ их нового состояния (для "вытеснения") осуществляется перед обращением к таким объектам (или, точнее, во время обращения к активному объекту -- в конкретике реального технологического языка, скорее всего, будут свои особенности операций в подобных случаях, например, при вызовах вида "ao.GetData(...)" предполагается блокировка объекта или т.п. -- по сути осуществляется обращение к условному диспетчеру, который "разбирается" в событиях как и при операторах вида "select").
Второй предикат "d < 0" в unless -- над "пассивным" объектом.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 03 Сентябрь, 2020 17:56 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 396
Аналогично активным объектам возможны "вытеснения" и при анализе конкурентных объектов или разделяемых переменных (пассивных) между параллельными процессами:
Код:
sub traverse (t : expr)
{
  var found: signal[data];
  var dat: data = nil;
  ...
  if t <> nil then
    do
      traverse(t.left);
    par
      traverse(t.right);
    par
      process(t.tag);
      if cond(t.tag) then
        emit(found, t.tag);
      end;
    unless top(found) do
      dat := found.get();
    end;
  end;
  if dat <> nil then
    p1(dat);
  end;
  ...
}

Вложение:
r9.png
r9.png [ 9.85 КБ | Просмотров: 6449 ]

Выше используются параллельные (и рекурсивные) действия в блоке "do...par...end" (на схеме структура с дивергенцией/конвергенцией процессов задана через спецвершины "(||)" и "(&)"). Рекурсивные вызовы обозначены двойной стрелкой, начало рекурсивной процедуры -- "двойной" вершиной (в "графике" -- кружок с двойной границей).
Объект found специального типа signal -- для конкурентного доступа, операция emit (на схеме -- крышечка как действие) -- "взвод" сигнала, top (как и в примере ранее, на схеме крышечка в качестве предиката) -- определение наличие сигнала.
В примере параллельные действия могут быть "вытеснены" в случае обнаружения искомых данных (технологический язык может предусматривать прерывание параллельных процессов и т.д.).

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 03 Сентябрь, 2020 17:59 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 396
И последний "автоматный" штрих -- явные "автоматные состояния", или явные "гиперфункции" (по Зюбину выше):
Код:
sub f1(in x: real; out y: real)
{
  y := calc(...);
  ...
  yield;
  ...
  return f1_1(data, x, y);
};

sub f1_1(m: int; in x: real; out y: real)
{
  y := calc(m, ...);
  ...
  yield;
  ...
  return f1_2(x, y);
};

sub f1_2(in x: real; out y: real)
{
  loop
    y := calc(...);
    ...
    yield;
  end;
};

Подпрограмма f1, которая может иметь какие-то промежуточные выходы как yield или в каком-либо ином виде, заканчивается особым образом -- для return в качестве операнда указывается функция f1_1 -- переключение в иное "автоматное состояние" (подпрограмма f1 не имеет выходного результата в сигнатуре как результат функции, т.е. её тип "sub f1(...): void", а не, напр., "sub f1(...): int", и для "обычного" return в данном случае нет операндов). Для f1_1 передаются ссылки на входные и выходные параметры (идентифицированы в сигнатурах через in/out), плюс некоторый дополнительный параметр (его значение сохраняется во время работы f1_1 как и прочие необходимые локальные данные). Теперь при вызове f1(...) будет "скрыто" выполняться f1_1(...). Затем f1_1 когда-то сделает "переход" в f1_2. При завершении f1_2 (если подпрограмма завершается самостоятельно) или при потенциальном "сбросе" f1 восстановит исходное "состояние", т.е. работа начнётся вновь с самой f1, и т.д.

Вторая форма "переключения в состояние" -- вместо "return ..." оператор "immediate ...", напр., "immediate f1_1(data, x, y)". В этом случае осуществляется "немедленный" переход -- происходит выход из исходной процедуры (например, f1) и сразу же выполняется новая указанная процедура (f1_1). В случае же оператора return -- новая процедура исполняется при следующем такте системы (при последующем акте диспетчеризации f1).

Такие субпрограммы напоминают части оператора "automaton" в SCADE/Lustre.

На алгоритмических Р-схемах "автоматные" переходы можно указать как особые структурные переходы:
Вложение:
r10.png
r10.png [ 19.71 КБ | Просмотров: 6449 ]


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 03 Сентябрь, 2020 18:04 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 396
К вопросу организации схем. Сформируем схемку для алгоритма:
Код:
fn func1(a, b: int): int
{
  type Res = {OK, Bad, Warn};
  const Size = 100;

  var obj = init(...);
  var m: int = 0;
  var r: Res;

  if cond1(a, b) or cond2(a, b) then
    return -1;
  end;

  prepare(obj, Size, ...);
  r := p1(obj, a);
  if r <> OK then
    p2(obj);
    return -1;
  end;

  m, r := p3(obj, a);
  while cond3(m, r) do
    m, r := p4(obj, b);
  end;
  if r = OK then
    p5(obj, m);
  else
    m := 0;
  end;
  return m;
finally
  finalize(obj);
}

Вложение:
r11.png
r11.png [ 11.61 КБ | Просмотров: 6449 ]

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

Переделаем:
Вложение:
r12.png
r12.png [ 10.22 КБ | Просмотров: 6449 ]

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

Ещё вариант:
Вложение:
r13.png
r13.png [ 9.99 КБ | Просмотров: 6449 ]

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

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

Подобный "силуэт" был (вероятно, и есть) в "горизонтальном Дракон-е" -- InteloGraf:
https://forum.drakon.su/viewtopic.php?f=62&t=4060
http://intelograf.narod.ru/


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 03 Сентябрь, 2020 18:05 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 396
В общем, вот такое направление наколенной автоматной методики, реализующей "гиперфункции" с помощью операторов передачи управления (yield), ожидания/выбора событий (select и for select, await), переключения или "перехода в состояние" (специальная форма return и immediate), операции "сброса" (reset), а также секций "финализатор" (finalize) и "наблюдатель" (unless).

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 03 Сентябрь, 2020 18:09 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 396
А_МУР писал(а):
Методика создания ФБ подобных КДС, как показывает практика не самый лучший способ
[...]
Мне лично не нравится дизайн иконы Вставка по Параджанову. Эта икона имеет малоинформативный дизайн и не удобство размещения в ней информации, я чаще в место нее использовал полку. Сейчас я вижу дизайн этой Иконы как чертежное обозначение микросхемы. В принципе от начального отличается мало но более разветвленная, имеет формализированные поля ввода-вывода, согласно объявленным переменным
[...]
Дмитрий, ведь заголовок не самое важное в процедуре - вторая важная часть любой процедуры это тянущие все в низ контрольные переменные, которые в схеме надо приладить так чтобы во время отладки, определить правильность работы процедуры и их нужно вытягивать на поверхность иконы процедуры .

А капсула это продолжение схемы, там даже нумерация пересылок должна использоваться общая с схемой

Почему я выделяю две капсулы Действие и Вопрос:

иногда капсула должна иметь два выхода как в случае с Чуком и Геком - четыре вопроса в одном - и контролировать это дело проще
[...]
работа с выходными значениями требует появления таких икон как Вопрос и Выбор
[...]
Опять же я повторю самое главное отличие Дракона и Других языков:
Дракон - это поток управления,
Другие языки -поток данных.
Таким образом нужно использовать сильную сторону Дракона - объективность управления

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

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

Вот здесь заметил императивную реализацию (на С++) стандартного набора базовых элементов в стиле CODESYS (таймеры, триггеры и пр.) для Arduino:
https://habr.com/ru/post/402315/

Подход выглядит практичным: объекты имеют "свойства" (ака входы/выходы ФБ) для поддержки исторического наследия методик и функции-методы вида "run(...): boolean", что позволяет использовать конструкты и в виде комплексных выражений (в т.ч. и как вложенные функции "g(f(x))") -- в общем, типичные выражения-вычисления (expression). Если язык/платформа позволяет перегрузить операцию "аппликации", то вместо "obj.run(...)" можно использовать объект "напрямую" аля "obj(...)".
В целом "формулы-выражения" могут быть внедрены где угодно либо там, где необходимо, в т.ч. и для компактизации конструкций (избавление от "одиночных" икон).
Однако, для прям уж "комфортной продвинутой инженерной" отладки необходим и такой же крутой интерпретатор, на манер некоторых IDE, "разбирающихся в формулах по месту", напр.:
https://github.com/lamdu/lamdu
http://lighttable.com/

Изображение

Изображение


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 03 Сентябрь, 2020 18:16 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 396
А на форуме когда-то была попытка воссоединить Дракон и FBD:

* Алаверды Дракону
* Как запустить Дракона?
* Два пернатых в одной берлоге не уживутся?
* ДРАКОН и функциональные языки программирования

Степан конкретно обозначил проблематику (продублирую):
https://forum.drakon.su/viewtopic.php?p=75329#p75335
Степан Митькин писал(а):
Дмитрий Дагаев писал(а):
Есть МЭКовский язык FBD. Имеет смысл делать два языка в одном флаконе: Дракон и FBD.

FBD имеет важное преимущество.
Он позволяет визуально обозначать потоки данных через функции.

Возьмём наш пример:
Код:
Result = cool(foo(U), bar(V))

Недостаток этой записи в том, что в ней три действия упакованы в одну строку. Упакованы слишком плотно. Распаковка требует некоторых умственных усилий.

Можно переписать этот пример по-другому:
Код:
X = foo(U)
Y = bar(V)
Result = cool(X, Y)

Здесь каждое действие занимает одну строку. Читателю не нужно парсить сложное, обильно вложенное выражение.

Но и тут есть проблема. Длина текста возрасла за счёт появления переменных X и Y. Кроме того, читатель вынужден сканировать глазами исходный текст, чтобы выявить места, где переменные определяются и где используются.

Конечно, тот факт, что переменные в Эрланге не могут менять своего значения, серьёзно облегчает чтение. Да и современные среды разработки помогают. Они подсвечивают вхождения переменной при её выделении.

Тем не менее, FBD (functional block diagrams) намного нагляднее текста. Поток данных можно отследить пальцем. Это гораздно легче, чем своими собственными глазами (чуть не сказал "руками") искать подстроку в тексте. Путь данных виден невооружённым глазом.
Но, как всегда, есть одно "но". Неудобно делать ветвление. Здесь ДРАКОНу равных нет. Вот как бы объединить ДРАКОН и FBD?

Дмитрий Дагаев предлагает вставлять FBD внутрь икон ДРАКОНа.
Вот так:
Вложение:
Вложение fbd_in_icon.png больше недоступно

(Взято из http://drakon.su/_media/biblioteka/alaverdy_drakon.pdf).

Преимущества FBD в этом примере неочевидны.
- Блоки ИЛИ и И лучше выражены в FBD.
- ДРАКОН чётче отслеживает различные комбинации результатов проверок.

И ещё. Эти две диаграммы представляют несколько разные алгоритмы.
ДРАКОН-версия налагает явный порядок вычисления аргументов логических функций.
С одной стороны, это плохо. В некоторых случаях этот порядок не важен. Проектировщик алгоритма вкладывает больше информации в диаграмму, чем необходимо.
С другой стороны, это хорошо. Производительность программы легче поддаётся оценке и улучшению. Это также имеет значение с точки зрения безопасности. Явное указание последовательности проверок может снизить угрозу некоторых видов атак.

У меня вопрос к участникам форума, и особенно к Дмитрию Дагаеву:

Как можно объединить визуальную наглядность потоков данных FBD и чёткость ветвления ДРАКОНа?

Рисунок к цитате выше:
Изображение

И к рисунку:
https://drakon.su/_media/biblioteka/alaverdy_drakon.pdf
Вложение:
dr1.png
dr1.png [ 108.2 КБ | Просмотров: 6449 ]


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 03 Сентябрь, 2020 18:24 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 396
"Комплементарность" выше подразумевает вписывание Дракон-схемы вовнутрь FBD-блока (Дракон внутри FBD):
https://forum.drakon.su/viewtopic.php?f=62&t=4086#p75341

и инъекции FBD-блоков вовнутрь "вопросов":
https://forum.drakon.su/viewtopic.php?f=62&t=3355&view=next
Вложение:
dr3.png
dr3.png [ 81.63 КБ | Просмотров: 6448 ]

Вложение:
dr4.png
dr4.png [ 248.63 КБ | Просмотров: 6448 ]

Насчёт "чёткости ветвления ДРАКОНа". На последнем рисунке схема справа ("визуальное логическое выражение") демонстрирует правило "семейного сходства" (если не ошибаюсь) -- мол все последующие иконы ниже "узла принятия решений" (ниже "дерева вопросов") должны быть выровнены между собой (на смежных маршрутах) и быть именно ниже "зоны" предикатов (однако, подобные правила не реализуются самим синтаксисом языка -- дополнительно вручную или задача выравнивания возлагается на редактор, если он сможет "догадаться"). В случае масштабных "деревьев решений", когда вопросы переплетаются с действиями и другими промежуточными элементами, подобное выравнивание не всегда возможно. Здесь на форуме уже была тема с демонстрацией "деревьев решений", где, пожалуй, главная задача -- выкрутиться без пересечения линий, иначе алгоситуацию придётся рвать на ветки силуэта (или разные схемы), для чего в ход идут и "неструктурные" переходы (в т.ч. переходы на смежные маршруты), дублирование условий в предикатах (условная методика "визуального логического выражения" хоть и снижает, но не избавляет от потребности в дубликатах выражений), и пр. Например:
https://forum.drakon.su/viewtopic.php?f=215&t=6666&p=103698#p103696
Изображение

Да, на схеме есть принципиальная возможность отобразить сложные комплексные условия. Узлы решений представляются нечто вроде в стиле "линейных бинарных графов" (от школы Шалыто):
https://forum.drakon.su/viewtopic.php?f=148&t=6693

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

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


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 72 ]  На страницу Пред.  1, 2, 3, 4  След.

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 5


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
cron
Вся информация, размещаемая участниками на конференции (тексты сообщений, вложения и пр.) © 2008-2024, участники конференции «DRAKON.SU», если специально не оговорено иное.
Администрация не несет ответственности за мнения, стиль и достоверность высказываний участников, равно как и за безопасность материалов, предоставляемых участниками во вложениях.
Powered by phpBB® Forum Software © phpBB Group
Русская поддержка phpBB