Интересная особенность Join при моделировании деятельности

Не знаете в какой раздел поместить свою тему? Кладите сюда

Интересная особенность Join при моделировании деятельности

Сообщение antonio » 26 ноя 2009, 22:21

На занятиях, студент задал вопрос, полагаю здесь будет интересно обсудить.

На диаграмме 1 поток управления разделяется, выполняются два действия, создающие по заказу. После этого оба объектных потока объединяются и обрабатываются.

Диаграмма 2 отличается только тем, что финальный узел деятельности заменен на конечный потока.

На диаграмме 3 вместо объектных потоков везде потоки управления.

Так вот, вопрос состоит в том, сколько раз выполнится действие Process на каждой диаграмме?
Вложения
activity.jpg
activity.jpg (24.46 ) Просмотров: 7577
antonio
 
Сообщений: 7
Зарегистрирован: 19 сен 2009, 20:43

Re: Интересная особенность Join при моделировании деятельности

Сообщение Denis.Ivanov » 27 ноя 2009, 16:31

antonio писал(а):Так вот, вопрос состоит в том, сколько раз выполнится действие Process на каждой диаграмме?

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

В отношении же диаграмм 1 и 2 заданный вопрос звучит некорректно.
Интуитивные предположения о том, что на диаграмме 1 будет отработан только первый Order, пришедший на join, а на диаграмме 2 оба Order конечно правомощны, но мы просто не знаем (в стандарте не определена операционная семантика), как должна выполняться модель. И именно в этом состоит суть вопроса студента.

Я на месте преподавателя задал бы студенту вопрос:
Каким образом (с минимальными исправлениями) перерисовать диаграмму 1 (или 2) так, чтобы было понятно, что оба Order, пришедшие от DoOrder1 и DoOrder2, были бы обработаны Process.
Denis.Ivanov
Администратор
 
Сообщений: 223
Зарегистрирован: 07 май 2009, 23:16

Re: Интересная особенность Join при моделировании деятельности

Сообщение antonio » 27 ноя 2009, 22:53

Насколько мне удалось разобраться, в первом случае на join будет накоплено 2 заказа. После чего, первый поступивший будет передан на Process и создан токен управления, который попадет на финальный узел деятельности и деятельность прерывется. Второй заказ, вообще говоря, может и не выполнится на Process (здесь неопределенность, что произойдет раньше - второй заказ на Process или токен управления после Process попадет на финальный узел).

На второй диаграмме токен с управлением просто пропадает в конечном узле потока и второй заказ будет обработан.

На третьей диаграмме два токена управления сливаются в один на join, поэтому Process будет выполнен один раз.
antonio
 
Сообщений: 7
Зарегистрирован: 19 сен 2009, 20:43

Re: Интересная особенность Join при моделировании деятельности

Сообщение Denis.Ivanov » 28 ноя 2009, 00:25

antonio писал(а):Насколько мне удалось разобраться, в первом случае на join будет накоплено 2 заказа. После чего, первый поступивший будет передан на Process и создан токен управления, который попадет на финальный узел деятельности и деятельность прерывется. Второй заказ, вообще говоря, может и не выполнится на Process (здесь неопределенность, что произойдет раньше - второй заказ на Process или токен управления после Process попадет на финальный узел).

На второй диаграмме токен с управлением просто пропадает в конечном узле потока и второй заказ будет обработан.

На третьей диаграмме два токена управления сливаются в один на join, поэтому Process будет выполнен один раз.


Практически со всем согласен.
Хочу только добавить немного по диаграмме 2 (как впрочем и по диаграмме 1), что нам не известно, как поведет себя Process, если во время обработки первого Order на его вход поступит второй Order.

А что по поводу
Denis.Ivanov писал(а):Каким образом (с минимальными исправлениями) перерисовать диаграмму 1 (или 2) так, чтобы было понятно, что оба Order, пришедшие от DoOrder1 и DoOrder2, были бы обработаны Process.
Denis.Ivanov
Администратор
 
Сообщений: 223
Зарегистрирован: 07 май 2009, 23:16

Re: Интересная особенность Join при моделировании деятельности

Сообщение antonio » 29 ноя 2009, 22:28

Повторное параллельное исполнение Process было бы возможно, если бы мы указали свойство {reentrant}, поэтому в данном случа Process поглощает токены только один раз. Насколько я помню, если не указано иное, токены потребляются по-одному. Действие происходит мгновенно, поэтому "во время исполнения" не существует.

Во второй диаграмме оба заказа обрабатываются. Или имеется в виду какое-то конкретное изменение в диаграмме?
antonio
 
Сообщений: 7
Зарегистрирован: 19 сен 2009, 20:43

Re: Интересная особенность Join при моделировании деятельности

Сообщение Denis.Ivanov » 30 ноя 2009, 15:29

antonio писал(а):Действие происходит мгновенно, поэтому "во время исполнения" не существует.

Это верно конечно, только все действия в UML предопределены и такого действия как Process там нет. Зато есть действие - вызов деятельности.

antonio писал(а):Во второй диаграмме оба заказа обрабатываются. Или имеется в виду какое-то конкретное изменение в диаграмме?

Я имел в виду использование expansion region.
Denis.Ivanov
Администратор
 
Сообщений: 223
Зарегистрирован: 07 май 2009, 23:16

Re: Интересная особенность Join при моделировании деятельности

Сообщение antonio » 01 дек 2009, 01:02

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

Использовать ExpansionRegion здесь не получится, так как в нем предполагается, что каждый токен является коллекцией и для каждого элемента коллекции выполняется содержимое ExpansionRegion, а у нас - два токена, не являющиеся коллекциями.
antonio
 
Сообщений: 7
Зарегистрирован: 19 сен 2009, 20:43


Вернуться в Все остальноe

cron