DRAKON.SU

Текущее время: Пятница, 29 Март, 2024 01:11

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




Начать новую тему Ответить на тему  [ Сообщений: 188 ]  На страницу Пред.  1 ... 5, 6, 7, 8, 9, 10  След.
Автор Сообщение
СообщениеДобавлено: Вторник, 03 Июль, 2018 20:22 

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 5846
Откуда: Москва
Владимир Ситников писал(а):
Я предлагаю в случае автоматного программирования оставить икону Адрес в покое.

Если же нужна операция "вернуть управление в диспетчер", "вернуть управление в ОС" и т.п., то в этом месте нужно разместить икону Пауза. Например, "пауза на 0 секунд".

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

Рассмотрит одну из 20 веток, например, пятую.
Предположим, что 5-я ветка имеет одну икону Адрес и цикл со стрелкой, подключенной к выходу иконы "Имя ветки".

Владимир, вы предлагаете:
1) икону Адрес оставить без изменения,
2) в цикл со стрелкой вставить икону Пауза с надписью 0с

Правильно? Или нет?

Если правильно, то получается, что для возврата управления в диспетчер, будут использоваться два разных обозначения:
1) икона Адрес
2) икона Пауза с надписью 0с

Я правильно изложил вашу мысль? Или нет?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 03 Июль, 2018 20:39 

Зарегистрирован: Среда, 03 Май, 2017 09:55
Сообщения: 200
Владимир Паронджанов писал(а):
Если правильно, то получается, что для возврата управления в диспетчер, будут использоваться два разных обозначения:
1) икона Адрес
2) икона Пауза с надписью 0с

Я правильно изложил вашу мысль? Или нет?

Нет.

Я предлагаю, что для возврата управления должна использоваться икона Пауза.
Икона Адрес приводить к возврату управления не должна.

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

Степан Митькин предлагал такой перечень: Параллельный процесс, Ввод, Вывод, Пауза, Синхронизатор.

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

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 03 Июль, 2018 21:09 

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 5846
Откуда: Москва
Кто использует автоматное программирование на языке ДРАКОН?

Сергей Дмитриевич Ефанов и Степан Борисович Митькин.
Они пришли к этой идее независимо друг от друга.

Сергей Ефанов использует два вида автоматного программирования на ДРАКОНе (Автомат1 и Автомат2) для программирования контроллеров и создает законченные контроллеры. Например, для торговых автоматов.

Как индивидуальный предприниматель, Ефанов создает законченный продукт (контроллер): и аппаратуру, и программу.

Он использует язык ДРАКОН для коммерческих целей в течение шести лет, применяя программу Тышова ИС Дракон.

Я отношусь к Ефанову и его разработкам с очень большим доверием. В автоматном программировании, разработанном Ефановым, икона Адрес используется для возврата управления в диспетчер. Это проверено Ефановым в течение шести лет работы с ДРАКОНом на многих проектах.

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

Автомат1 — это силуэт, который трактуется как switch и case. Недостаток: когда переключатель имеет много положений, программа начинает работать медленно (тормозит).

Чтобы ускорить работу (и повысить точность задания временных интервалов), Ефанов придумал Автомат2.

Автомат2 — это указатель на функцию. Каждая ветка автомата — это функция. Достоинство в том, что скорость не зависит от числа функций (веток силуэта-автомата) и остается неизменной с ростом числа веток.

Добавление

В одном проекте у Ефанова примерно 30-50 автоматов (в среднем).

Вот статистические данные по одному конкретному проекту Сергея Ефанова.

В проекте 50 автоматов.

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

Остальные 26 автоматов вызываются из других автоматов. Это значит, что некоторые автоматы могут вызывать другие автоматы.

Вот такие дела.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 04 Июль, 2018 00:36 

Зарегистрирован: Среда, 03 Май, 2017 09:55
Сообщения: 200
Владимир Паронджанов писал(а):
Это драгоценный производственный опыт. Считаю, что нужно опираться на опыт, совместно наработанный Ефановым и Тышовым.

Простите, но чего же такого драгоценного в этом опыте? Вопрос риторический.
То, что сделали Ефанов с Тышовым называется искать под фонарём
Очевидно, что сделать транслятор "одна Дракон ветка в одну C-функцию" несложно. Вот и возникла гениальная идея "Автомат1, Автомат2".
А то, что у иконы Адрес появляется совершенно новый смысл -- плевать.

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

Владимир Паронджанов писал(а):
Автомат2 — это указатель на функцию. Каждая ветка автомата — это функция. Достоинство в том, что скорость не зависит от числа функций (веток силуэта-автомата) и
Цитата:
остается неизменной с ростом числа веток
.

Это неправда. Если размещать в каждой ветке ровно одну икону, то и Автомат2 станет тормозить.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 05 Июль, 2018 12:11 

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 5846
Откуда: Москва
Владимир Ситников писал(а):
А то, что у иконы Адрес появляется совершенно новый смысл -- плевать.
Владимир, спасибо за критическое замечание.

Вы правы. В автоматном программировании у иконы Адрес добавляется новая функция, которой не было в в случае императивного программирования.

Однако вы пишите "совершенно новый смысл". Это не так.
Смысл иконы Адрес — передать управление в нужную ветку силуэта. Этот смысл полностью сохраняется.

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

Зачем нужен микродиспетчер (посредник)?

Микродиспетчер обеспечивает мультизадачность.
Если у нас, к примеру, 20 задач, то есть 20 автоматов-силуэтов, микродиспетчер поочередно опрашивает (и включает в работу) все 20 автоматов-силуэтов.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 05 Июль, 2018 13:44 

Зарегистрирован: Среда, 03 Май, 2017 09:55
Сообщения: 200
Владимир Паронджанов писал(а):
Однако вы пишите "совершенно новый смысл". Это не так.


Читаем внимательнее:
Владимир Ситников писал(а):
А то, что у иконы Адрес появляется совершенно новый смысл -- плевать.


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

Передавать управление по Адресу можно и без посредников.
Вот цитата из вашей же книги:
Как улучшить работу ума писал(а):
стр. 84
Итак, зачем нужна ветка? Чтобы помочь работнику умственного
труда, программисту и разработчику технологии формализовать смысловое
разбиение проблемы, программы или техпроцесса на части и
дать частям удобные смысловые названия. При этом разделение проблемы
на N смысловых частей реализуется путем разбиения алгоритма
на N веток.


Разбивка должна быть смысловой, а не из-за того, что "нужно или не нужно возвращать управление в диспетчер".
Эксперименты с Автомат1 и Автомат2 нужно понять, простить, и отвергнуть.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 05 Июль, 2018 13:47 

Зарегистрирован: Среда, 07 Январь, 2015 14:53
Сообщения: 1356
Владимир Ситников писал(а):
Эксперименты с Автомат1 и Автомат2 нужно понять, простить, и отвергнуть.
Да, пожалуйста простите!


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 07 Июль, 2018 19:52 

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 5846
Откуда: Москва
Владимир Паронджанов писал(а):
Это драгоценный производственный опыт. Считаю, что нужно опираться на опыт, совместно наработанный Ефановым и Тышовым.

Владимир Ситников писал(а):
Простите, но чего же такого драгоценного в этом опыте?

Владимир, спасибо за вопрос.
Мои соображения таковы:

1. Контроллеры и микроконтроллеры широко распространены в мире и часто используются, в том числе в интернете вещей.
Это огромный рынок.

2. Желательно, чтобы язык ДРАКОН проник на этот рынок как коммерческая услуга. Именно этим занимается Сергей Ефанов с помощью программы Геннадия Тышова "ИС Дракон".

Сергей Ефанов использует язык ДРАКОН не для экспериментов, а для коммерческой деятельности, причем продолжительное время, уже шесть лет.

3. В течение шести лет (благодаря Сергею Ефанову и Геннадию Тышову) язык ДРАКОН используется в производственном процессе для создания конечного продукта для коммерческих целей.

4. Это позволяет говорить о производственном опыте.

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

6. Сергей Ефанов — индивидуальный предприниматель. Он работает один, без помощников. Таким образом, масштабы этого производственного опыта невелики.

7. Сергей Ефанов — пионер, идущий неведомыми (в бизнесе) путями.
Сергей Ефанов — первопроходец, впервые в мире доказавший, что язык ДРАКОН можно использовать для коммерческих целей и добиться коммерческого успеха.

Идти первым всегда трудно. Поэтому успешный опыт пионеров и первопроходцев является драгоценным.
Они протаптывают новые тропинки и прокладывают дорогу для других. Тех, кто пойдет по их следам.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 09 Июль, 2018 17:04 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 396
Цитата:
Эксперименты с Автомат1 и Автомат2 нужно понять, простить, и отвергнуть.

Отвергнуть элементарно, а вот что предложить в замен то ...

В самом деле, совокупность алгоритмов-автоматов как набор силуэтов с ветками-"состояниями", взаимодействующих друг с другом и внешней средой, представляет из себя "плоскую" форму алгоритмической системы. Пример "не плоской" формы, в данном случае как "взаимодействие плоскостей" -- кроме явного выражения следования "состояний" применяется и параллельная композиция вычислительных потоков с "или"-конвергенцией (по ссылке из смежной темы про автоматы -- С.Д. Ефанов использовал в основе SWITCH-методологию, включая и соответствующую вариацию модели сообщений):
http://www.kit-e.ru/articles/circuit/2007_2_148.php
Вложение:
148p3.png
148p3.png [ 19.17 КБ | Просмотров: 9455 ]

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

Воспользуемся альтернативой:
https://forum.drakon.su/viewtopic.php?f=142&t=6246&start=80#p101870

, т.е. вместо "веток-состояний" применим иконы, подразумевающие неатомарность действий -- передачу управления диспетчеру (выход во внешнюю среду). В данном случае (по мотивам рисунка выше) используется "ввод" для ожидания событий, и пусть параллельные линии подразумевают "или"-вытеснение потоков действий (весь блок параллельных операций завершается при окончании работы любого потока):
Вложение:
par_aut0.png
par_aut0.png [ 16.71 КБ | Просмотров: 9455 ]

По сравнению с оригиналом для сообщения "x4" применяется дополнительный анализ атрибутов при приёме этого сообщения -- так всего лишь подчёркивается тот факт, что в общем случае необходимы и какие-то проверки условий, и неатомарные иконы аля "ввод" не отменяют использование тех же "вопросов", и паттерн аля "ожидающий цикл" остаётся в применении.
И, прежде всего, необходимо отметить особенность "параллельных линий" -- вряд ли их возможно адекватно "разрывать" по веткам силуэта (особенно в случаях возникновения не только одной группы действий):
https://forum.drakon.su/viewtopic.php?f=62&t=5441

Соответственно, тогда форма алгоритмов должна максимально способствовать сокращению элементов схемы по вертикали, и, собственно то, по горизонтали тоже (необходимо поменьше "развесистых" конструкций в виде условных выражений и циклов, и т.п.). Попробуем вместо "ввода" применить "синхронизатор" для выражения ожидания сообщений, который присоединяется сбоку к иконам (т.е. уменьшить "насадку на шампур" по вертикали):
Вложение:
par_aut1.png
par_aut1.png [ 15.49 КБ | Просмотров: 9455 ]

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

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 09 Июль, 2018 17:09 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 396
Но всё же, для "автоматного" силуэта напрашиваются хоть какие-то визуальные отличия. Всё-таки принцип "метафор", фактически, нивелируется, теряется смысл как таковой чертежей такого класса.
Может быть как-то так:
Вложение:
aut2.png
aut2.png [ 16.25 КБ | Просмотров: 9455 ]

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

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 09 Июль, 2018 21:06 

Зарегистрирован: Среда, 03 Май, 2017 09:55
Сообщения: 200
PSV100 писал(а):
Методика "ветка-состояние" не выражает параллельные композиции.

Она много чего не выражает. Зачастую удобно выделить ветку для упрощения восприятия самого алгоритма. И в этом случае вовсе не нужно, чтобы ветка стала отдельным состоянием автомата.

PSV100 писал(а):
Отвергнуть элементарно, а вот что предложить в замен то ...

Много раз предлагали уже: возвращать управление в диспетчер по Паузам (а не по веткам).
И всего делов.

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

PSV100 писал(а):
Воспользуемся альтернативой:
viewtopic.php?f=142&t=6246&start=80#p101870

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

Вариации "событие x2 может срабатывать даже тогда, когда мешалка находится в состоянии <<Этап 2>>" ломают мозг. Более того, даже, если представить себе, что "текущее состояние после x1 раздваивается и одно полусостояние ждёт x2, а второе полусостояние пошло по этапам", то невозможно понять как полусостояние x2 (сработка кнопки стоп) прикончит того, которое "пошло по этапам".
В общем, для данной задачи гораздо лучше обработку x2 вынести в отдельную Д-схему. При этом, даже "домохозяйке" можно будет показать (маленькую схему про "стоп") и она поймёт "как работает кнопка стоп".

Если есть другие задачи -- давайте обсудим.


Последний раз редактировалось Владимир Ситников Понедельник, 09 Июль, 2018 21:24, всего редактировалось 2 раз(а).

Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 09 Июль, 2018 21:14 

Зарегистрирован: Среда, 03 Май, 2017 09:55
Сообщения: 200
PSV100 писал(а):
Но всё же, для "автоматного" силуэта напрашиваются хоть какие-то визуальные отличия. Всё-таки принцип "метафор", фактически, нивелируется, теряется смысл как таковой чертежей такого класса.

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

Есть ещё предложение: вообще не различать, а считать, что Д-схемы всегда работают в автоматном режиме.
Как вам такое?

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 10 Июль, 2018 10:35 

Зарегистрирован: Среда, 03 Май, 2017 09:55
Сообщения: 200
PSV100 писал(а):
если "контроль кнопки стоп" выделить в отдельный силуэт-автомат (отдельный алгоритм)

Именно это и есть здравый подход для этой задачи.

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

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


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

Что, если завершать нужно не все параллельные ветки, а нужно дождаться завершения как минимум двух веток?
Ещё одну нотацию изобретать будете?


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

Я к чему: на оба вопроса должны быть ответы "нет" и "нет".

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

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

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


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

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 5846
Откуда: Москва
Владимир Ситников писал(а):
Вот цитата из вашей же книги:
Как улучшить работу ума писал(а):
стр. 84
Итак, зачем нужна ветка? Чтобы помочь работнику умственного труда, программисту и разработчику технологии формализовать смысловое разбиение проблемы, программы или техпроцесса на части и дать частям удобные смысловые названия.
При этом разделение проблемы на N смысловых частей реализуется путем разбиения алгоритма на N веток.


Разбивка должна быть смысловой, а не из-за того, что "нужно или не нужно возвращать управление в диспетчер".

Владимир, вы правы. Разбивка на ветки должна быть смысловой.

Однако автоматное программирование полностью соблюдает эту идею. И никак ее не компрометирует.

Правило "Силуэт делится на ветки по смыслу" является одинаковым и для императивного, и для автоматного программирования на языке ДРАКОН.
Никакой разницы.


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

Зарегистрирован: Среда, 03 Май, 2017 09:55
Сообщения: 200
Владимир Паронджанов писал(а):
Однако автоматное программирование полностью соблюдает эту идею. И никак ее не компрометирует.

Вы говорили о "возврате в диспетчер по иконе Адрес". Это идёт в разрез со здравым смыслом (с разбиением на ветки по смысловому признаку)

Вот пример: viewtopic.php?f=142&t=6092&p=100466#p100478

Если при переходе между 14 (переход на обработку аварии) - 16 (поднимаем панику) будет возврат управления в диспетчер, то получится картина, что аварию распознали, даже выставили ErrorFlag, а панику не успели поднять. По сути, потеряли время на ровном месте. Передача управления 14-15-16 должна быть мгновенной, т.е. без каких-либо возвратов в диспетчер или куда там ещё.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 10 Июль, 2018 12:31 

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 5846
Откуда: Москва
Владимир Паронджанов писал(а):
Однако автоматное программирование полностью соблюдает эту идею. И никак ее не компрометирует.

Владимир Ситников писал(а):
Вы говорили о "возврате в диспетчер по иконе Адрес".

Вы правы. Я говорил именно это.

Владимир Ситников писал(а):
Это идёт в разрез со здравым смыслом (с разбиением на ветки по смысловому признаку)
Не могу с вами согласиться.

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

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


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

Зарегистрирован: Среда, 03 Май, 2017 09:55
Сообщения: 200
Владимир Паронджанов писал(а):
Вы правы. Временные соотношения надо рассчитывать без ошибок.
Если не делать глупых ошибок, то автоматное программирование не компрометирует обсуждаемую идею.


Глупых ошибок это каких?


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

Почитайте viewtopic.php?f=142&t=6246&p=101972#p101965 и viewtopic.php?f=142&t=6246&p=101972#p101966
Разделение на "автоматные" и "не-автоматные" Дракон схемы вообще лишнее.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 10 Июль, 2018 14:10 

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 5846
Откуда: Москва
Владимир Ситников писал(а):
Передача управления между ветками это просто goto.
Вы правы.

Владимир Ситников писал(а):
Нет абсолютно никакого смысла в том, чтобы возвышать передачу управления "между ветками" через какие-то там диспетчеры или ещё что.
Не могу с вами согласиться. Смысл есть.

Аргументы у меня такие.

Я опираюсь на опыт Сергея Ефанова. Он использует автоматное программирование на языке ДРАКОН постоянно.
в 95-97% случаев.

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

Микродиспетчер Ефанова (бесконечный цикл) работает в режиме кооперативной (совместной) многозадачности.

Владимир Ситников писал(а):
Передача управления между ветками это просто goto.
В автоматном режиме вместо goto (для случая switch case) работа организована так.

Икона "Имя ветки" — это case, икона Адрес — это break.

Описание процесса

— вместо goto выполняется break с запоминанием адреса следующей ветки,

— затем выход из автомата (из switch) в микродиспетчер (бесконечный цикл), который в режиме кооперативной многозадачности обслуживает остальные автоматы,

— затем выход из микродиспетчера и вход в switch нашего (рассматриваемого) автомата, который передает управление в нужный case (икону "Имя ветки"),

— затем снова через break выход из автомата и т.д.

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 10 Июль, 2018 14:49 

Зарегистрирован: Среда, 03 Май, 2017 09:55
Сообщения: 200
Владимир Паронджанов писал(а):
Я доверяю Сергею Ефанову, так как знаком с его работой.
Для меня важно. что Ефанов использует ДРАКОН для коммерческих целей.

Замечательно. Так и писали бы с самого начала: "раз С.Ефанов так делает, значит это самый правильный подход".

Если завтра С.Ефанов в колодец прыгнет, то всем тоже нужно будет так сделать?
Не удивлюсь, если и на этот вопрос будет положительный ответ.

Сравнивать нужно не по именам ("Ефанов против Митькина"), а по применимости в реальных задачах.

Тов. PSV100 последовательно рассматривает разные варианты и рассматривает как разные подходы решают или не решают поставленную задачу.
Это хорошо.
А у вас единственный аргумент -- вера в С.Ефанова. Прекрасно.
Все эти break/switch никак не объясняют того почему переход по адресу, якобы, должен возвращать управление в диспетчер.

Ссылки на С.Ефанова ничем не сопровождаются кроме слов "он 6 лет уже этим занимается".
Это при том, что в ИС Дракон возможность "ветка-функция по С. Ефанову" появилась только в августе 2017-го


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 10 Июль, 2018 15:36 

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 5846
Откуда: Москва
PSV100 писал(а):
Но всё же, для "автоматного" силуэта напрашиваются хоть какие-то визуальные отличия. Всё-таки принцип "метафор", фактически, нивелируется, теряется смысл как таковой чертежей такого класса.

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

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

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

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

Это плохо. Потому что трудно (для пользователей).
Очень трудно для пользователей.

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

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

Предложить "товар" (новые графические обозначения), который захотят "купить" пользователи очень и очень непросто.

Между тем, задачу можно решить не вводя новых обозначений, а ограничившись старыми.

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

Это значит, что необходимость вводить новые обозначения становится ненужной.

Пояснение решает проблему более простыми средствами.
Дополнительная нагрузка на память пользователей становится ненужной.

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

Надо не затруднять людей, а облегчать их труд.
Будьте проще — к вам потянутся.

Визуальные отличия между императивным и автоматным программированием на языке ДРАКОН должны быть минимальными или даже нулевыми.


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 188 ]  На страницу Пред.  1 ... 5, 6, 7, 8, 9, 10  След.

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


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

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


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

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