Форум Сообщества Аналитиков
Общий раздел => Теория моделирования и нотации => UML SysML и пр. => Тема начата: believer от 19 Июля 2009, 17:52:09
-
Добрый вечер! Будут ли какие-либо критические замечания по схеме во вложении? Спасибо.
-
Что бы я сделал максимум - это показал бы 5 основных блоков на Д чтобы показать параллельность, а эти бы большие блоки описал бы словами.
Сделайте так и покажите два варианта коллегам - что им будет понятнее то и оставьте.
-
А завершение процесса на главном узле и на исполнительных узлах синхронное или асинхронное?
-
А завершение процесса на главном узле и на исполнительных узлах синхронное или асинхронное?
MPI-процесс на управляющем узле заканчивается позже, чем MPI-процессы на исполнительных узлах. А что?
-
Просто интересно.
Соглашусь с Сашей насчет уменьшения числа блоков. Может не до 5, но если укрупнить блоки диаграмма будет восприниматься проще.
-
А в целом по синтаксису все корректно?
-
Соглашусь с другими - диаграмма выглядит пересыщенной информацией.
Для начала я бы поговорил о семантике.
Удаление считанного запроса - звучит довольно странно, так же как и считывание в прочем.
Считать данные из таблицы ...
Удалить запрошенные данные ...
На мой взгляд и понятнее и правильнее
Далее - осуществляется проверка, если резулььтат запроса содержит записи - идем дальше - нет остаемся в цикли из которого боюсь никогда не выйдем.
Неясно с какого момента начинается действие, в чем семантика начального псевдосостояния?
Зачем параллелить процесс и выделять действия администратора? каковы они? при этом уровни действий различны и явно не согласованы...
Сложно, трудно понять, может словами проще?
-
Соглашусь с другими - диаграмма выглядит пересыщенной информацией.
Чем больше комментариев, тем лучше )
Удаление считанного запроса - звучит довольно странно, так же как и считывание в прочем.
Спасибо, подкорректировал этот момент.
Далее - осуществляется проверка, если резулььтат запроса содержит записи - идем дальше - нет остаемся в цикли из которого боюсь никогда не выйдем.
Система должна находиться все время ожидании.
Зачем параллелить процесс и выделять действия администратора?
На рисунке пока не показано.
при этом уровни действий различны и явно не согласованы...
Взаимосвязь уровней описана в комментариях.
-
believer, а в чем вопрос? :)
вроде как Вы делеаете то, что Вам кажется правильным. Ну и на здоровье!
Если Вы описываете блок схему для себя, то зачем Вам чужие комментарри. Если Вы ее делаете для других, то очевидно эти другие должны быть заинтересованы. Вы так не считаете?
Вопрос, а в чем мы можем быть заинтересованы? Скорее всего ни в чем. А потому помощь чисто... ну грамматическая.
Потому, диаграмма и кажется пресыщенной, формулировки активностей неудачные. Момент того, что система в ожидании не очевиден. Для этого наверное лучше показывать диаграмму состояний.
Да не смог посмотреть Ваш pdf. Может в jpg сохраните?
-
Вопрос, а в чем мы можем быть заинтересованы? Скорее всего ни в чем. А потому помощь чисто... ну грамматическая.
Меня просто корректность синтаксиса интересовала. Вроде по этому претензий не было. Спасибо.
-
У вас в вашей диаграмме показано как плодяться параллельные процессы ... это так и должно быть? Неужели одновременно идет "передача параметров запроса" и "прием параметров запроса" и еще третий в добавок???
В первом распараллеливании, не понятно что происходит после "Действия администратора" с этой веткой ... она заканчивается? Система при этом изменяет свое состояние???
А что обозначает стрелка идущая от "Установка флага запроса Е в 1" в стрелку "соединение отсутствует"????
Вывод - помимо синтаксических проблем, похоже есть еще и семантическая ...
-
А что обозначает стрелка идущая от "Установка флага запроса Е в 1" в стрелку "соединение отсутствует"?
После E:=1 должно быть действие “Удаление строки из таблицы Flags”. Вы думаете, стрелка должна быть направлена прямо в блок этого действия?
-
Походу новая версия ещё пространственней чем старая, хотя трое "комментаторов" предлагали "укрупнить" блоки. Что не хватает фантазии или на своей волне прикольней?
Это без наезда, просто попытался разобраться в смысле и как-то не уловил с ходу. Думаю если обобщить активности и ограничить себя их энным количеством (скажем 5) то станет понятней где смысл есть, а где просто от балды. Особо не понятно когда активность всё таки закончится и как распаралеливание в основном узле происходит? Мне также видится очень сильно назревающая проблема в том что обслуживающие узлы продолжают висеть до конца этой бесконечной истории и не убиваются - т.е. в реализации скорей всего после нескольких запросов система сама себя истощит ничего неделаньем и скажет покедова.
Ещё один вопрос на понимание сферы задачи: MPI это Message Passing Interface?
Меня просто корректность синтаксиса интересовала. Вроде по этому претензий не было. Спасибо.
А какие претензии по синтаксу могут быть? Между начальной активностью и конечной: прямоугольники с овальными углами, соединённые стрелками, разветвление, сливание синхронизация (?), с админом не понятно как оно там, ну и фиг с ним.
Осмелюсь предложить своё видение этой д. деятельности:
-
Ur@! А разве так можно? Мне казалось после жирной линии, от которой начинаются ветки процессов, обязательно должна быть вторая - заключающая.. Или как?
Замечания сейчас закреплю на схеме. Спасибо!
-
То что после разветвления обязательно должна быть синхронизация (или как они там в русской терминологии), это однозначно неверно. Как я понял из советов denis-itk (в паралельной теме о сигналах) и Юрий Булуй важно чтобы потоки управления не обрывались в никуда, а имели логическое завершение либо в конечной активности, либо в этом кружочке с крестиком обозначающем конец потока.
Передо мной висит uml2-постер от oose (http://www.oose.de/typo3temp/pics/poster-klein_01_e37be59cf6.gif), если всмотрется, то можно увидеть справа аналогичную ситуацию на диаграмме.
А и ещё, у меня там наверно начало и конец должны лежать всё-таки в одной из партиций.
-
Ur@! Мне казалось после жирной линии, от которой начинаются ветки процессов, обязательно должна быть вторая - заключающая.. Или как?
Ur@ прав. Синхронизация параллельных потоков важна в том случае, если после синхронизации будет переход к деятельности, которая может начаться только после слияния потоков.
Разветвление параллельных потоков говорит нам о том, что после некоторой деятельности возникает ряд параллельных деятельностей или потоков. Должны ли они потом слиться, зависит от контекста задачи.
-
После E:=1 должно быть действие “Удаление строки из таблицы Flags”. Вы думаете, стрелка должна быть направлена прямо в блок этого действия?
Нет должен тогда стоять fork, в который входили бы обе стрелки, а выходила одна - на действие.
-
Нет должен тогда стоять fork, в который входили бы обе стрелки, а выходила одна - на действие.
вряд ли fork, наверно имеется в виду merge. Merge (по-русски слияние?) можно рассматривать как логическое или в отличии от синхронизации, которая тождественна логическому и. Правда с синхронизацией возможны разные варианты.
На первом рисунке не всё правильно, второй, по-моему, правильней и должен также показать возможности синхронизации.
-
merge (слияние) существует исключительно для того, чтобы сделать нотацию более удобной и наглядной. В принципе можно обходиться и без него - никакой дополнительной информации оно не несет (http://ooad.asf.ru/standarts/uml/spr/Merge.aspx).
-
Неужели одновременно идет "передача параметров запроса" и "прием параметров запроса" ???
Один передает, другой принимает. Действия происходят параллельно.
-
http://www.uml2.ru/forum/index.php?topic=1473.msg15820#msg15820
А что за кружки с крестиками? В чем его отличие от конечного кружка?
Вы написали, когда конец безобразию? А разве эти кружки с крестиками и не есть конец?!
-
вряд ли fork, наверно имеется в виду merge. Merge (по-русски слияние?) можно рассматривать как логическое или в отличии от синхронизации, которая тождественна логическому и. Правда с синхронизацией возможны разные варианты.
На первом рисунке не всё правильно, второй, по-моему, правильней и должен также показать возможности синхронизации.
Сорри, имелось ввиду merge .. смотрел на распараллеливание и автоматом написал.