DRAKON.SU

Текущее время: Воскресенье, 17 Февраль, 2019 20:52

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




Начать новую тему Ответить на тему  [ Сообщений: 292 ]  На страницу Пред.  1 ... 4, 5, 6, 7, 8, 9, 10 ... 15  След.
Автор Сообщение
СообщениеДобавлено: Вторник, 12 Январь, 2010 08:59 

Зарегистрирован: Воскресенье, 04 Ноябрь, 2007 23:01
Сообщения: 512
Ильченко Эдуард писал(а):
А где описать сам процесс (динамический)?.. В узле расщепления не запускаются динамические процессы, а только описываются, и только одна копия.
Именно запускаются, останавливаются или взаимодействуют на основе какого-либо алгоритма. Описывать сам процесс - на отдельной схеме.

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

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


Последний раз редактировалось Рэйлвэй Каген Вторник, 12 Январь, 2010 09:14, всего редактировалось 4 раз(а).

Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 12 Январь, 2010 09:06 

Зарегистрирован: Воскресенье, 04 Ноябрь, 2007 23:01
Сообщения: 512
Galkov писал(а):
А когда спрашиваешь: как сделать схему, которую я элементарно делаю на "старой" - получается "не пытайтесь". Это же неправильно.
Может быть кто-то порисует на "старой"? С разбором полётов..


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 12 Январь, 2010 10:18 

Зарегистрирован: Вторник, 11 Август, 2009 11:44
Сообщения: 42
Откуда: Бердск
Дык именно на это я и намекаю все время...
И мне все время интересен результат сравнения (не просто же так я на мозги капаю). В аспекте понимаемости происходящего. Скажем, я описывал Вам (если помните) Mutex у нас.
В принципе, связь ентого мьютекса с ресурсом тоже какая-то "невизуальная", по имени. Как-то не очень... А может и нормально...


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 12 Январь, 2010 11:48 

Зарегистрирован: Понедельник, 09 Ноябрь, 2009 17:29
Сообщения: 904
Откуда: Россия, Питер
Драконограф писал(а):
Ильченко Эдуард писал(а):
Часть алгоритма, следующая за маркером узла сбора, при преобразовании в ветку силуэта, должна будет получить «Имя ветки». Поскольку «произвольное имя» можно легко автоматически присвоить в «Имя ветки», то имеет смысл сразу правильно именовать часть алгоритма, следующего за узлом сбора.

А разве текст в узле не есть метка маршрута (на котором м.б. и не один процесс)? Поэтому Рэйлвей Каген и говорит о "произвольном имени"...
Текст в узле можно и меткой назвать. Но, поскольку речь шла об узле сбора (если я правильно понял), то за маркером узла сбора может следовать только один маршрут, поэтому логично говорить не о «произвольном имени», а об имени маршрута (части алгоритма), который, в свою очередь, легко преобразовывается в «Имя ветки» при переходе к силуэту.


Последний раз редактировалось Ильченко Эдуард Вторник, 12 Январь, 2010 16:06, всего редактировалось 1 раз.

Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 12 Январь, 2010 12:00 

Зарегистрирован: Понедельник, 09 Ноябрь, 2009 17:29
Сообщения: 904
Откуда: Россия, Питер
Galkov писал(а):
А говорил я о том, что витание в облаках не всегда хорошо... Ну разве-что кофе варить. По земле тоже ходить надо.
Не умея ходить по земле - кофе не сваришь : )


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 12 Январь, 2010 12:37 

Зарегистрирован: Воскресенье, 04 Ноябрь, 2007 23:01
Сообщения: 512
Galkov писал(а):
я описывал Вам (если помните) Mutex у нас.
Давайте нарисуем разделяемый ресурс. В контексте параллельных процессов. (см.верхнюю схему)
Нижний рисунок - это чтобы легче было смотреть: кто, кого и где ждёт(это не дракон-схема, а просто иллюстрация).
Вложение:
log.png
log.png [ 15.03 КБ | Просмотров: 7947 ]
А вот будет там мутекс, семафор или какой межпроцессный протокол, давайте определять путём декомпозиции расширенной иконы "Ветка".


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 12 Январь, 2010 12:58 

Зарегистрирован: Понедельник, 09 Ноябрь, 2009 17:29
Сообщения: 904
Откуда: Россия, Питер
Galkov писал(а):
Мне ближе, например, запись в лог-файл несколькими потоками в "непредсказуемое" время.

И я не вижу, в придуманном в этом топике, адекватных заменителей (еще раз повторюсь) ТИПОВОГО мьютекса...
Может кто откроет глаза :?:

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

Схему в студию!

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

Вы регулярно и настойчиво употребляете загадочное буквосочетание «winAPI” (здесь кавычки означают цитату : ). Почему не linAPI, macAPI или узбекAPI? При строительстве дома узбекAPI, пожалуй актуальнее будет. Шутка.

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

Galkov писал(а):
Ильченко Эдуард писал(а):
Я бы предложил такую конструкцию:
Замечания есть:
1)Количество мьютексов совпадает с количеством защищаемых ресурсов, а не количеством параллельных процессов.
Совершенно согласен. В схеме два объекта, которые защищены мьютексами м1 и м2. Объектом, который защищён мьютексом м1, пользуются неограниченное количество копий процесса «Динамический типа 1». Аналогично с м2.

Galkov писал(а):
Один файл - один мьютекс. А не m1, m2, ... и т.д.. Как это делать, чтобы это было понятно любому, взлянувшему на схему (наша задача - улучшить работу ума !!!) - НЕ ЗНАЮ.
А я знаю. Шутка.

Объект, защищаемый мьютексом м1, обзываете LOG файлом и далее по схеме.

Galkov писал(а):
2) Одна финтифлюшка по имени "Ждать освобождения" - это совершенно неправильно.
Это такой способ разработки алгоритма: сверху-вниз. Вы вольны вставить вместо «Ждать освобождения» свой диспетчер запросов.

Galkov писал(а):
Защита - это синтаксическая конструкция (которой нет, и никто ее не планирует вроде) со своим префиксом (WaitForSingleObject/EnterCriticalSection), и суфиксом (ReleaseMutex/LeaveCriticalSection). И с запретом выхода из этой конструкции мимо суффикса. Не вижу суффикса...
Ну так нарисуйте его. Или заплатите и я нарисую : ) Это опять шутка : )


Последний раз редактировалось Ильченко Эдуард Вторник, 12 Январь, 2010 16:09, всего редактировалось 1 раз.

Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 12 Январь, 2010 13:12 

Зарегистрирован: Понедельник, 09 Ноябрь, 2009 17:29
Сообщения: 904
Откуда: Россия, Питер
Драконограф писал(а):
...можно ли одно из равноправных направлений следования после расщепления (а равно и перед сбором) показывать стрелкой, а другое (то, что по вертикали) - нет? Здесь ведь нет главного маршрута. И так же, получается, будет в силуэте?
Думаю, что можно. Ведь движение потока вниз естестественно (привет потокограммам де Боно : ),
а влево-вправо неочевидно.

В принципе, это в духе Дракона. У развилки стрелочка отсутствует, а в цикле присутствует.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 12 Январь, 2010 13:59 

Зарегистрирован: Понедельник, 09 Ноябрь, 2009 17:29
Сообщения: 904
Откуда: Россия, Питер
А ведь вопрос о количестве потоков далеко не праздный.

Galkov писал(а):
Должен отметить, что это: Изображение
- очень веселая конструкция, для банальной (читай - типовой) синнхронихации двух (хотя и с помощью пяти) потоков :wink:


Рэйлвэй Каген писал(а):
Galkov писал(а):
..Может кто откроет глаза :?:
Я бы с удовольствием.. Но как это сделать человеку, который насчитал 5 процессов там, где их нет?


Galkov писал(а):
А сколько их (вообще-то, я говорил про потоки) тут :?: Изображение


Рэйлвэй Каген писал(а):
2


Вложение:
дом ГОСТ и new.png
дом ГОСТ и new.png [ 30.53 КБ | Просмотров: 7945 ]


Наверно, всё зависит от точки зрения.

В глобальном смысле здесь 1 процесс - построить дом.
Логических (именованных?) — 8 процессов — подготовка участка, линия, коробка, крыша, проводка, лампы, отделка, выход.
Одновременно выполняются 1 или 2 процесса, в зависимости от точки (момента) наблюдения.
В узлах расщепления/сбора по 3 процесса.

Драконограф писал(а):
Как-то вид ГОСТ-овских узлов (я опять же отвлекаюсь от их смысла в ГОСТе - мы можем дать свой) эргономичнее...
Не согласен.

Где прописать имя процесса?
Как преобразовать в силуэт?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 12 Январь, 2010 15:57 

Зарегистрирован: Понедельник, 09 Ноябрь, 2009 17:29
Сообщения: 904
Откуда: Россия, Питер
Рэйлвэй Каген писал(а):
Ильченко Эдуард писал(а):
А что такого плохого в прерывистых линиях?
- люди всегда воспринимают их как неопределённость(за исключением, пожалуй, обозначения невидимого контура на чертежах), но почему-то склонны трактовать такую неопределённость в пользу своих представлений о предмете. Полагаться на одинаковое интуитивное восприятие тут нельзя.
Очень хорошо, что люди воспримут их как неопределённость, для этого они и предназначены.

А какого рода неопределённость, люди узнают из руководства пользователя.
А именно:
а) на схеме представлены динамические маршруты (процессы), т.е. создаваемые во время выполнения;
б) на момент чтения схемы неопределено сколько в конкретные моменты будущего будет запущено таких процессов;
в) супервизор (монитор, диспетчер, контроллёр) динамического маршрута «где-то рядом» левее. И «палка» и «банан» лежат рядом. Говорят это сильно усиливает интеллект : )

Супервизор и процесс можно показать «Вставкой». Зато с одного взгляда понятно кто кем управляет и кто от кого зависит. А реализацию в примитиве или силуэте можно выносить в любое место.

Рэйлвэй Каген писал(а):
А в Драконе есть пока только маршруты. "Может быть маршрут" - такого понятия никто не вводил, а реализовать такое можно простой проверкой условия перед запуском процесса и стандартным изображением маршрута.
Стандартное изображение маршрута не может показать неопределённость запуска во времени и множественность.

Рэйлвэй Каген писал(а):
Но это стрелка на "шине" маршрутов, а "шину" можно тащить дальше, пока нет пересечений с чужими "шинами" и маршрутами. Что будет со стрелкой? В силуэте, ясное дело, такой проблемы не возникнет.
Не могли бы Вы на каком-нибудь примере продемонстрировать?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 12 Январь, 2010 20:55 

Зарегистрирован: Воскресенье, 06 Апрель, 2008 14:43
Сообщения: 1657
Ильченко Эдуард писал(а):
Изображение
Сравниваю и вижу: вариант с ГОСТовской графикой гораздо понятней и выполнен в соответствии с принципом ДРАКОНа - достижения максимальной наглядности.
Так сделано в и.с. DRAKON, так и останется. На все вопросы ответ будет в справке.


Последний раз редактировалось ==== Вторник, 12 Январь, 2010 21:01, всего редактировалось 2 раз(а).

Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 12 Январь, 2010 20:57 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 1442
Ильченко Эдуард писал(а):
Где прописать имя процесса?
Как преобразовать в силуэт?


Предлагаю варианты икон для узлов расщепления (верхняя) и сбора (нижняя):
Вложение:
СхПовед - Узлы.JPG
СхПовед - Узлы.JPG [ 36.13 КБ | Просмотров: 7905 ]

Расщепление содержит текст базового смысла данного оператора, представленного для определённости на манер строевой команды:) При этом вводится поле параметров для каждого шампура; в базовом смысле оно может содержать набор формальных параметров выполняемого на нём процесса (при алгоритмизации оформляется иконой И11). Расширенный смысл определяет условия прохода, т.е. старта процессов, и дополнительные параметры, могущие входить в эти условия. Так, можно указать норму времени на исполнение шампура; для асинхронного расщепления задать предел (интервал) позднего старта данного шампура, выдержки времени относительно реальных моментов старта других шампуров. Можно указывать относительную важность маршрутов, что будет влиять на порядок назначения им исполнителей из ограниченного множества по мере освобождения от других работ (в частности, чтобы важные процессы не стартовали слишком поздно). Сам старт визуализируется, как обычно в ДРАКОН-2, посылкой сообщения процессу в иконе И20.
Для сбора базовый смысл сформулирован аналогично. В полях параметра указывается, какого доклада (в смысле состава величин и их значений) сочинитель ожидает от процессов шампура. Расширенный смысл определяет условия прохода узла; отсутствием условий можно указывать, что требуется лишь завершение процесса на данном шампуре. По времени для асинхронного сбора содержит также интервал раннего финиша; при этом ноль может указывать эталонный в этом смысле шампур (от реального момента финиша по которому отсчитываются финиши остальных). Можно указать относительную важность докладываемых результатов по шампурам, а также ставить учёт результатов, получаемых по исполнении одних шампуров, в зависимость от наличия и/или значений результатов исполнения других. Из этого вытекает возможность игнорировать незавершённость исполнения одних шампуров, подходящих к узлу, если завершено с тем или иным результатом исполнение других по принципу: "вообще-то для сбора нужно сделать и Это, и То, и Сё, но если сделано хотя бы То и Сё, то Это пока может подождать"; тогда сочинитель предусматривает контроль игнорированных результатов где-то в последующих узлах сбора по схеме (возможно, не в одном месте). Контроль исполнения в этом случае является пассивным: узел сбора ждёт доклада процессов (в виде сообщений И20, входящих в их визуалы, как предлагал Рэйлвей Каген в модели "построить дом"). Однако возможен и активный контроль, что характерно для процессов организованной деятельности: узел, не дождавшись доклада по шампуру, начинает посылать напоминания в иконе И20 отстающему процессу этого шампура; целесообразно, когда сочинитель предполагает, что без доклада узел пройден не будет (подобную ситуацию довелось визуализировать при описании реальной деятельности). Другая типичная ситуация - слишком раннее завершение шампура; в этом случае можно подразумевать вопрос "почему так рано?" и предусмотреть в узле углублённый контроль результатов.
Алгоритмически базовый смысл узла раскрывается через иконы И20. Принцип их распределения по вмзуалам процессов показал Рэйлвей Каген.
Условия прохода м.б. любыми функциональными (типа: "если [НЕ] Это, тогда [НЕ] То ИЛИ [НЕ] Сё"; "И [НЕ] То, И [НЕ] Это"; "лучше/хуже/так же, как/иначе, чем <сущность-образец>"; "имеющий <признаки>"; и т.п.), временнЫми ("[НЕ] раньше/позже, чем [через <интервал> после] <событие>"; "тогда-то по такому-то времени"; "одновременно с <событие>"; "в течение такого-то времени"; "быстрее/медленнее/в том же темпе в сравнении с <процесс-эталон>"; и т.п.), пространственными ("левее/правее/выше/ниже/ближе/дальше, чем <реперный объект/точка> на <смещения по координатам>"; "там-то"; "со <стороны> от <реперный объект/точка>"; "там же, где и <реперный объект/точка>"; "длиннее/короче/крупнее/мельче, чем <объект-эталон>"; "на [расстоянии <величина> по] пути <имя> из <> в <>"; "вплотную/с зазором <размер> к <базовая точка/линия/поверхность>"; "с поворотом оси на <угол>" относительно <реперной оси>; и т.п.). При этом видим, что выделяются условия единичные - для одного маршрута и множественные - увязывающие разные маршруты. Первые указываются в полях иконы, зрительно связанных с соответствующими линиями, вторые - в общем поле. Обычно записываются как логические формулы (объединяющие в сложное условие); их надо визуализировать как нелинейные конструкции. Единичные условия при алгоритмизации, наверное, нужно включать в свои процессы (по их выполнении запускаются следующие процессы), как оформлять множественные условия - надо подумать.
Т.к. иконы узлов растянуты на нужную ширину, то ломаные линии присоединения шампуров отсутствуют. Не нужны дополнительные маркеры. Считал бы эргономичным пометку синхронных узлов дополнительной линией контура (подобно перекрёсткам), чтобы читатель сразу понимал, что процессы по всем шампурам стартуют (финишируют) одновременно (точнее, с разбросом меньше шага отслеживания) и не надо искать временнЫх условий, определяющих старт (финиш).
С использованием этих икон перерисовал схему Ильченко:
Вложение:
СхПовед Напоить себя.JPG
СхПовед Напоить себя.JPG [ 111.18 КБ | Просмотров: 7905 ]

Все узлы здесь считаю синхронными. Условия, конечно, придумывал навскидку. Параметры отдельно не задавал (предполагая наличие только тех, что использованы в условиях). Также привёл топологию переключателя к нормальной для техноязыка (побочные вертикали вроде как нельзя присоединять к главной вертикали в разных точках).
Важной представляется идея Ильченко о выделении главного маршрута для процесса управления расщеплением/сбором ("супервизора") в рамках всей схемы. Возможную логику такого процесса я уже предлагал в этом сообщении (называя его "диспетчером"). Как часть его можно включить и процедуру-"напоминайку" для отстающих процессов, получающую список "отстающих" как формальный параметр; альтернативный вариант - реализовать её как "зацикленный" процесс, только запускаемый в начале схемы и собирающий список "отстающих" по узлам.
Конструкция, ограниченная расщеплением и сбором (равно как и каскадами одновидовых узлов), образует своего рода мультишампур-блок. Шампуры в нём можно упорядочивать по-разному, как и в техноязыке: по значимости, по желаемому времени запуска (если подразумевается асинхронность).
Если допустить динамические маршруты, то можно принять также правило, чтобы не плодить разные типы линий: все маршруты, входящие в мультишампур-блок, динамические.
Точный состав допустимых параметров условий прохода, конечно, оговаривается для конкретного диалекта расширенного таким образом техноязыка.
При переходе к силуэту можно допустить разрыв шампуров мультишампур-блока; в этом случае иконы Имя ветки и Адрес используются в смысле Рэйлвей Каген (но в отношении 1:1) и для указания на это специально помечаются (как у него); их текст служит меткой маршрута (в частном случае может совпадать с именем единственного входящего процесса). Остальные иконы имеют обычный смысл разрешённых БП техноязыка. По умолчанию мультишампур-блок помещается целиком в теле одной ветки. Имя процесса там, где ему положено по правилам техноязыка - в иконе процесса.
Остаётся вопрос с "зацикленными" процессами; они "никогда" не закончатся и при обычной логике узел сбора с их участием не будет пройден. Если такой процесс может входить в мультишампур, то не следует ли допустить запуск его в любом месте схемы, а в мультишампуре - только чтение его текущего состояния (которое может включать и счётчик проходов процесса) и выход по состоянию (в частности - по достижению счётчиком некоторого значения)?
И ещё: допустим, в параллельном прогязыке Оккам есть два рандеву-оператора - один посылает сообщения другому процессу, как И20, а другой принимает сообщения от другого процесса. Вероятно, какой то смысл в этом есть (дело же не в том, что Оккам - текстовый язык :))?
Конечно, и это предложение, подобно КВНу, опять "не решит всех проблем":). Кто может, пусть предлагает лучше, и с возможно более подробными разъяснениями...
P.S. Да, и явное указание объектов шампура в узле расщепления должно, полагаю, автоматически означать их блокировку, т.е. эквивалент команды "[Процессы, ]Разобрали цели!", чтобы не получалось, как с Дарьей Домрачевой :); проход узла сбора означает освобождение объектов собираемых им шампуров. Если какие-то объекты ещё не освобождены процессами, стартовавшими в других расщеплениях (из параллельно выполняемых мультишампур-блоков, отстающими из предыдущих блоков), то старт откладывается (шампур, т.е. поток, "засыпает").
При уточнении смысла узлов надо также подумать о дублировании (размножении) одного маршрута (содержанием которого м.б. и конструкция из мультишампур-блоков) во время выполнения. Также пока неясно с зацикливанием такой схемы (тем более что это вроде как не алгоритм). В общем, многое еще прояснять надо...
P.P.S. Корректируются также узлы для общего случая, изменил определения базового смысла с учётом сказанного выше. Также имена в точечной записи должны означать свойства объектов (не везде соблюдал). Нарисовал схему поведения в форме силуэта, правда, для такой схемы это построение надуманное. Кстати, мои извинения Эдуарду: его переключатель также допустим, просто в нём пересажена лиана "Квас"; а мой вариант имел целью показать употребление каждого напитка :)
Ещё об "алгоритмической расшифровке" узлов. Узел расщепления в результате выдаёт последовательность сообщений И20 (далее тип сообщения буду указывать через дефис). При этом в его алгоритме вначале описывается (исходя из содержания иконы Узел расщепления) вычисление порядка старта шампуров, формирующее массивы: имён их процессов; количеств порождаемых копий (в частном случае равно единице); интервалов старта текущего шампура относительно предыдущего (для синхронного узла все равны нулю); реальных моментов старта шампуров (по единому времени; вначале все элементы нулевые); наборов параметров (включая формальные, если есть), размножаемых (возможно, с изменениями, также описываемыми изначально в иконе Узел расщепления) по числу копий; индекс массивов есть номер шампура по порядку старта. Далее повторяется по числу исходящих шампуров (следованием, а лучше как тело охватывающего цикла ДЛЯ по номеру шампура) конструкция следования из: цикла ЖДАТЬ, проверяющего доступность "своих" объектов (и исполнителей при ограничении на их доступность); иконы Пауза, берущей интервал старта "своего" шампура; цикла порождения копий, в теле которого идут: конструкция описания "захвата" набора параметров шампура; икона И20-Старт, в которой и имя процесса, и набор формальных параметров есть переменные-компоненты нужных массивов, выбираемые по индексу шампура ("параметризованное" сообщение процессу; вроде техноязыком допускается); икона Действие для записи реального момента старта текущего шампура в "свой" элемент массива (можно заменить её на Пуск таймера и тогда делать вместо паузы цикл порождения по таймеру с параметром (ПерТаймера[ПредШамп]+ИнтСтарта[ТекШамп]; или, если так можно, делать Пуск таймера текущего по ПерТаймера[ПредШамп], сравниваемой по "не меньше" с ИнтСтарта[ТекШамп]). Т.о. у нас заранее (до исполнения) определены "типы" шампуров как алгоритмы их процессов, а временнОй порядок следования типов и число экземпляров каждого типа определяются при исполнении (конечно, на схеме поведения эргономично упорядочить асинхронные шампуры в порядке старта, о чём уже говорилось); это указывается в тексте единичного поля узла расщепления. Если узлы расщепления каскадируются, то на шампуре текущего узла, идущем к следующему узлу расщепления, стартует его визуал (все узлы имеют уникальные имена, назначаемые и их алгоритмам) сразу; неясно, можно ли допускать вставку между ними ещё и целевого процесса - ведь его работу обычно ещё надо контролировать.
В составе алгоритма шампура (сочиняемого, очевидно, вполне независимо от охватывающих узлов) от схемы поведения появляется икона И20-Доклад, где имя адресата есть имя алгоритма "своего" узла сбора, а содержание сообщения - набор "докладываемых" величин процессов шампура. Видимо, если содержание шампура сочинитель представляет как цепочку отдельных процессов, то каждый предшествующий процесс в цепочке перед иконой Конец запускает последующий (также по И20-Запуск). Видится ограничение для этого случая: сочинитель д.б. уверен, что каждый предшествующий процесс нормально завершится, для чего строить все процессы, кроме последнего, логически просто, минимизируя "подводные камни" периода исполнения.
Алгоритм узла сбора в первую очередь также вычисляет параметры своего дальнейшего исполнения, формируя массивы (индексированные также по шампурам, но уже по входящим): нормативных значений наборов параметров для "доклада" от процессов шампура; признаков [не]выполнения единичных условий. Далее в цикле пошампурно анализируются единичные условия, в результате чего устанавливается признак выполнения для данного шампура. Вопрос, что делать, если обнаружено невыполнение: во-первых, полагая его причиной сбой, можно послать И20-Старт процессу (единственному/первому) этого шампура для "пересчёта" (ограничение: если шампур управляет реальными объектами, это м.б. бессмысленно или даже опасно); во-вторых, можно запустить алгоритм аварийного управления (ограничение: если по логике решения задачи это возможно независимо от других шампуров); в-третьих, ничего не делать и перейти к обработке множественных условий узла; наверное, возможны "в-четвёртых" и т.д. (кто-нибудь их будет находить при матанализе и информоделировании схем поведения, в практике визуализации реальных задач). Эту часть сбора, как уже говорилось, наверное можно визуализировать как отдельный процесс, связанный только со "своим" шампуром (через "рандеву" по И20-Доклад; при этом узел расщепления должен давать И20-Старт и этому процессу вместе с первым процессом шампура); тогда, очевидно, можно разнести исполнение для разных шампуров по ресурсам [квази]мультипрограммного исполнителя. Далее переходим к общей части, начинающейся с проверки множественных условий (использующих "доклады" от разных шампуров); для них, очевидно, справедливы те же соображения, что для проверки единичных, и дополнительно в этих условиях учитываются признаки проверки единичных. Следствием выполнения условий д.б. проход всего узла; этот проход алгоритмизуется следованием из: процедур освобождения объектов шампуров узла; иконы И20-Старт для процесса следующего узла расщепления (или следующего шампура, если идёт каскадирование узлов сбора либо достигнута нижняя граница МШБ). В каскаде данная организация узлов сбора принципиально не меняется.
Вернёмся к каскадированию узлов расщепления через шампуры с целевыми процессами. Наверное, в некоторых случаях можно сформулировать это как единичную часть сбора и включить её после целевого процесса; т.о. перед расщеплением имеем "сбор одного шампура". Это надо показывать и на МШ-схеме (добавляя единичный блок сбора сверху иконы расщепления).
Кстати, о проблеме "пустого" шампура между расщеплением и сбором: м.б. заполнять его "докладом" без передаваемых параметров?
Аварийно процесс завершается иконой И20-Финиш.
Вот такие соображения; надо их ещё проверять на корректность и развивать. Прошу критиковать.


Последний раз редактировалось Владислав Жаринов Четверг, 14 Январь, 2010 13:41, всего редактировалось 6 раз(а).

Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 12 Январь, 2010 21:03 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 1442
Геннадий Тышов писал(а):
Сравниваю и вижу: вариант с ГОСТовскии графикой гораздо понятней и выполнен в соответствии с принципом ДРАКОНа - достижения максимальной наглядности.
Так сделано в и.с. DRAKON, так и останется. На все вопросы ответ будет в справке.

В общем-то, как выяснилось, против ГОСТовского вида мультишампуров я ничего не имею. Один вопрос - каков смысл вертикалей справа от цифр 66 и 72?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 12 Январь, 2010 21:14 

Зарегистрирован: Воскресенье, 06 Апрель, 2008 14:43
Сообщения: 1657
Дракон-схема получена пребразованием из UML диаграммы

Изображение

Цитата:
Один вопрос - каков смысл вертикалей справа от цифр 66 и 72?

Вами упомянутые связи соответствуют средним связям в UML диаграмме между узлами "разветвление" и "слияние".


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 12 Январь, 2010 22:08 
Аватара пользователя

Зарегистрирован: Суббота, 29 Март, 2008 19:27
Сообщения: 998
Откуда: Россия, Чебоксары
Драконограф писал(а):
Предлагаю варианты икон для узлов расщепления (верхняя) и сбора (нижняя)
Наконец-то! Уж думал, никто не предложит, а самому лениво :)

Только пример схемы выглядит... громоздко уж очень...

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 12 Январь, 2010 22:43 

Зарегистрирован: Понедельник, 09 Ноябрь, 2009 17:29
Сообщения: 904
Откуда: Россия, Питер
Геннадий Тышов писал(а):
Сравниваю и вижу: вариант с ГОСТовской графикой гораздо понятней и выполнен в соответствии с принципом ДРАКОНа - достижения максимальной наглядности.]
Вероятно, у нас просто разные вкусы. А о вкусах, как известно, не спорят : )
Геннадий Тышов писал(а):
Так сделано в и.с. DRAKON, так и останется.
Ну что же, придётся делать альтернативный редактор : )


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 13 Январь, 2010 01:42 

Зарегистрирован: Воскресенье, 04 Ноябрь, 2007 23:01
Сообщения: 512
Ильченко Эдуард писал(а):
Не могли бы Вы на каком-нибудь примере продемонстрировать?
Эдуард! Попробуйте, пожалуйста, перевести на "шину" следующую схему:
Вложение:
model41.png
model41.png [ 14.15 КБ | Просмотров: 7881 ]


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 13 Январь, 2010 05:36 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 1442
Эдуард Ильченко писал(а):
Из 25! знаков в Драконе в чистую используются 5!.

Действительно, ГОСТ ведь определяет также алфавит декларативного языка (как я понимаю, к его конструкциям относятся схемы данных) и актив-языка описания исполнителей (схемы ресурсов). Кстати, стандарт деклар-языка разрабатывался для целей дракон-программирования. Жаль, что дело пока заглохло.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 13 Январь, 2010 05:39 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 1442
Геннадий Тышов писал(а):
Вами упомянутые связи соответствуют средним связям в UML диаграмме между узлами "разветвление" и "слияние".

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 13 Январь, 2010 10:00 

Зарегистрирован: Воскресенье, 04 Ноябрь, 2007 23:01
Сообщения: 512
Вдогон к этому сообщению:
Рэйлвэй Каген писал(а):
Ильченко Эдуард писал(а):
Не могли бы Вы на каком-нибудь примере продемонстрировать?
Эдуард! Попробуйте, пожалуйста, перевести на "шину" следующую схему:
Я только "выпрямил" изгибы, не смешивая шины. Из "Адресов" и "Веток" получились своеобразные флажки. Затем "спрятал" флажки под теми иконами, на которые эти флажки "показывали" вершиной. Дальше продолжать как-то страшно.. Получится эльбрусовский распараллеливающий компилятор с ручным приводом :).
Вложение:
model4-step2_step3.png
model4-step2_step3.png [ 20.68 КБ | Просмотров: 7837 ]


Последний раз редактировалось Рэйлвэй Каген Среда, 13 Январь, 2010 21:25, всего редактировалось 1 раз.

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

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


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

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


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

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