Как мне представить вложенные действия в диаграмме действий UML?


16

Этот вопрос очень похож на этот , но ответ не соответствует моим потребностям. Он ориентирован на конкретный инструмент UML (папирус), в то время как мой вопрос более общий о UML.

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

На приведенном ниже примере, который представляет собой диаграмму действий, показывающую какое-то действие « обратно домой », вложенные действия находятся в Pet the catдействии. Обратите внимание, что на этой диаграмме есть еще одна потенциальная ошибка, см. Ошибки в конце вопроса.

Наконец-то вернулся домой

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

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

Трайдент под-деятельности

Итак, каков стандартный способ представления такого вложенного действия? Под стандартом я подразумеваю действительный UML, который обычно можно увидеть и, если возможно, выполним в большинстве инструментов дизайна UML.

Несвязанные опечатки: в моих диаграммах есть еще одна ошибка: стрелки, которые приходят к тому же действию ( Scratch behind the ears), должны перейти на узел слияния, прежде чем войти в действие. Смотрите комментарии ниже, включая эту цитату из JOT .


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

Ну, я не знаю, но я надеюсь, что это просто кошачье настроение, потому что диаграмма, которую я наконец-то дал моему боссу, выглядит так: /
Тим

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

@ JimL. Вы имеете в виду, что оба условия должны быть верными, чтобы войти в это состояние? Тогда какой будет способ выразить то, что я намерен выразить? Объединяющийся алмазный узел перед государственным входом?
Тим

Мы говорим о действии, а не государстве; но да, для решения этой проблемы требуется объединение.
Джим Л.

Ответы:


23

Оба являются «стандартными». Первое изображение согласно спецификации UML

Узлы структурированной активности

StructuredActivityNode - это Action, которая также является ActivityGroup (см. Подраздел 15.6) и поведение которой определяется посредством ActivityNodes и ActivityEdges, которые она содержит. В отличие от других видов ActivityGroup, StructuredActivityNode владеет содержащимися в нем ActivityNode и ActivityEdges, поэтому узел или ребро могут непосредственно содержаться только в одном StructuredActivityNode. Однако StructuredActivityNodes могут быть вложенными (так как StructuredActivityNode, как Action, также является ActivityNode), так что ребро или узел могут косвенно содержаться в ряде вложенных StructuredActivityNodes.

Группы деятельности

ActivityGoups - это группирующие конструкции для ActivityNodes и ActivityEdges. Узлы и ребра могут принадлежать более чем одной группе. Этот подпункт описывает два конкретных вида ActivityGroups, ActivityPartitions и InterruptibleActivityRegions. StructuredActivityNode - это третий вид ActivityGroup, но они также являются Действиями и обсуждаются в подпункте 16.11 раздела 16 «Действия».

2-й рисунок

Действия призыва

InvocationAction - это Действие, которое прямо или косвенно приводит к вызову Поведения (см. Подпункт 13.2). InvocationActions включает в себя CallActions для вызова операций или поведения и для запуска действий, которые были созданы ранее. Дополнительные виды InvocationActions обеспечивают целевую отправку сигналов и других объектов, а также возможность передачи сигналов доступным приемникам.

Основное различие между обоими случаями заключается в повторном использовании. В то время как во-первых, у вас есть некоторая сложность в одном (вашем Pet the cat) месте, во-вторых, когда вы (повторно) используете определенное действие в нескольких местах. Тем не менее, я склонен использовать вариант вызова, даже если это только для одного использования. Здесь я добавляю составную диаграмму (которая в EA открывается при нажатии dbl), чтобы показать детали соответствующего действия. Основной поток просто показывает обзор, и если нужны подробности, они просто щелкают мышью.

Теперь создание составной диаграммы в EA (опять же) изменилось. Вам нужно создать AD на уровне пакета, а затем перетащить его в элемент вызова. Теперь, когда вы щелкнете по этой кнопке, откроется встроенная диаграмма.


Спасибо за ваш ответ. Не могли бы вы дать более подробную информацию о том, когда вы используете какую возможность? Я нахожу спецификацию UML довольно трудной для чтения на стороне пользователя.
Тим

Это не лекция перед сном :-) Я постараюсь добавить еще несколько объяснений.
qwerty_so 19.09.16

Я сделал обновление с замечанием о другом EAUI.
qwerty_so 19.09.16
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.