Добрый вечер! Будут ли какие-либо критические замечания по схеме во вложении? Спасибо.

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

А завершение процесса на главном узле и на исполнительных узлах синхронное или асинхронное?

А завершение процесса на главном узле и на исполнительных узлах синхронное или асинхронное?

MPI-процесс на управляющем узле заканчивается позже, чем MPI-процессы на исполнительных узлах. А что?

Просто интересно.

Соглашусь с Сашей насчет уменьшения числа блоков. Может не до 5, но если укрупнить блоки диаграмма будет восприниматься проще.

А в целом по синтаксису все корректно?

Соглашусь с другими - диаграмма выглядит пересыщенной информацией.

Для начала я бы поговорил о семантике.

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

Считать данные из таблицы ...
Удалить запрошенные данные ...

На мой взгляд и понятнее и правильнее

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

Неясно с какого момента начинается действие, в чем семантика начального псевдосостояния?

Зачем параллелить процесс и выделять действия администратора? каковы они? при этом уровни действий различны и явно не согласованы...

Сложно, трудно понять, может словами проще?

Соглашусь с другими - диаграмма выглядит пересыщенной информацией.

Чем больше комментариев, тем лучше )

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

Спасибо, подкорректировал этот момент.

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

Система должна находиться все время ожидании.

Зачем параллелить процесс и выделять действия администратора?

На рисунке пока не показано.

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

Взаимосвязь уровней описана в комментариях.

believer, а в чем вопрос?

вроде как Вы делеаете то, что Вам кажется правильным. Ну и на здоровье!

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

Вопрос, а в чем мы можем быть заинтересованы? Скорее всего ни в чем. А потому помощь чисто... ну грамматическая.

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

Да не смог посмотреть Ваш pdf. Может в jpg сохраните?

Вопрос, а в чем мы можем быть заинтересованы? Скорее всего ни в чем. А потому помощь чисто... ну грамматическая.

Меня просто корректность синтаксиса интересовала. Вроде по этому претензий не было. Спасибо.

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

Вывод - помимо синтаксических проблем, похоже есть еще и семантическая ...

А что обозначает стрелка идущая от "Установка флага запроса Е в 1" в стрелку "соединение отсутствует"?

После E:=1 должно быть действие “Удаление строки из таблицы Flags”. Вы думаете, стрелка должна быть направлена прямо в блок этого действия?

Походу новая версия ещё пространственней чем старая, хотя трое "комментаторов" предлагали "укрупнить" блоки. Что не хватает фантазии или на своей волне прикольней?

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

Ещё один вопрос на понимание сферы задачи: MPI это Message Passing Interface?

Меня просто корректность синтаксиса интересовала. Вроде по этому претензий не было. Спасибо.

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

Осмелюсь предложить своё видение этой д. деятельности:

Ur@! А разве так можно? Мне казалось после жирной линии, от которой начинаются ветки процессов, обязательно должна быть вторая - заключающая.. Или как?

Замечания сейчас закреплю на схеме. Спасибо!

То что после разветвления обязательно должна быть синхронизация (или как они там в русской терминологии), это однозначно неверно. Как я понял из советов denis-itk (в паралельной теме о сигналах) и Юрий Булуй важно чтобы потоки управления не обрывались в никуда, а имели логическое завершение либо в конечной активности, либо в этом кружочке с крестиком обозначающем конец потока.
Передо мной висит uml2-постер от oose, если всмотрется, то можно увидеть справа аналогичную ситуацию на диаграмме.

А и ещё, у меня там наверно начало и конец должны лежать всё-таки в одной из партиций.