Como represento ações aninhadas em um diagrama de atividades UML?


16

Esta pergunta é muito semelhante a esta , mas a resposta não corresponde às minhas necessidades. Ele se concentra em uma ferramenta UML específica (Papyrus), enquanto minha pergunta é mais geral sobre a UML.

Gostaria de representar uma ação aninhada em um diagrama de atividades , mas não sei qual é a maneira comum de fazer isso. A idéia é que exista uma ação com o mesmo escopo que as outras ações, mas mais complexa em sua execução. Eu gostaria de mostrar mais detalhes sobre sua execução e ainda poder mostrar esta ação no mesmo nível que as outras.

No exemplo abaixo, que é um diagrama de atividades que mostra algum tipo de atividade "de volta para casa ", as ações aninhadas estão na Pet the catação. Observe que há outro erro em potencial neste diagrama; veja as erratas no final da pergunta.

Finalmente de volta para casa

Eu usei o nó estruturado, mas não tenho certeza de que é a maneira correta, daí a pergunta. Em um gráfico de estados, o equivalente seria um estado composto, mas não consigo encontrar nada sobre uma ação composta. Com relação ao nó estruturado, depois de ler alguns documentos sobre ele, eu ainda não entendo como ele deve ser usado; portanto, posso estar totalmente errado com este diagrama.

Sei também que existe a possibilidade de me referir a outra subatividade com o símbolo tridente, como na imagem abaixo, mas não corresponde às minhas necessidades, pois gostaria de obter todas as informações no mesmo diagrama (para que eu possa imprimir sem perda de informações):

Subatividade do tridente

Então, qual é a maneira padrão de representar uma ação tão aninhada? Por padrão, quero dizer UML válido, comumente visto e, se possível, possível na maioria das ferramentas de design UML.

Errata não relacionada: Outra coisa está errada nos meus diagramas, as setas que vêm para a mesma ação ( Scratch behind the ears) devem ir para um nó de mesclagem antes para entrar na ação. Veja os comentários abaixo, incluindo esta citação de JOT .


Você não perguntou sobre isso, mas quero ressaltar que a ação "Raspe atrás das orelhas" nunca pode ser executada. Alguém sabe por que isso é verdade?
Jim L.

Bem, eu não sei, mas espero que seja apenas o temperamento do gato, porque o diagrama que finalmente dei ao meu chefe se parece com o seguinte: /
Tim

O motivo é que um token de ambos os caminhos deve ser oferecido à ação para que ele inicie, o que é impossível, pois se trata de algo que nunca acontecerá.
19716 Jim L.

@ JimL.Do quer dizer que ambas as condições devem ser verdadeiras para entrar neste estado? Então, qual seria a maneira de expressar o que pretendo expressar? Um nó de diamante mesclado antes da entrada do estado?
Tim

Estamos falando de uma ação, não de um estado; mas sim, é necessária uma mesclagem para corrigir esse problema.
19716 Jim L.

Respostas:


23

Ambos são "padrão". A primeira imagem conforme as especificações UML é

Nós de atividade estruturada

Um StructuredActivityNode é uma Ação que também é um ActivityGroup (consulte a subcláusula 15.6) e cujo comportamento é especificado pelos ActivityNodes e ActivityEdges que ele contém. Diferentemente de outros tipos de ActivityGroup, um StructuredActivityNode possui os ActivityNodes e ActivityEdges que ele contém e, portanto, um nó ou borda pode estar diretamente contido apenas em um StructuredActivityNode. StructuredActivityNodes pode ser aninhado (como um StructuredActivityNode, como uma ação, também é um ActivityNode); no entanto, uma borda ou nó pode estar indiretamente contido em um número de StructuredActivityNodes aninhados.

Grupos de atividades

ActivityGoups são construções de agrupamento para ActivityNodes e ActivityEdges. Nós e arestas podem pertencer a mais de um grupo. Esta subcláusula descreve dois tipos concretos de ActivityGroups, ActivityPartitions e InterruptibleActivityRegions. StructuredActivityNodes é um terceiro tipo de ActivityGroup, mas também são Actions e são discutidos na subseção 16.11 da Cláusula 16 sobre Actions.

A segunda foto é

Ações de invocação

Uma InvocationAction é uma Ação que resulta, direta ou indiretamente, na invocação de um Comportamento (consulte a subcláusula 13.2). As InvocationActions incluem as CallActions para chamar Operações ou Comportamentos e iniciar comportamentos que foram instanciados anteriormente. Tipos adicionais de InvocationActions permitem o envio direcionado de sinais e outros objetos e a capacidade de transmitir sinais para os receptores disponíveis.

A principal diferença entre os dois casos é a reutilização. Enquanto, em primeiro lugar, você apenas tem alguma complexidade em um único local (o seu Pet the cat); o segundo é quando você (re) utiliza uma determinada ação em vários locais. No entanto, costumo usar a variante de invocação, mesmo que seja apenas para um único uso. Aqui, adiciono um diagrama composto (que no EA é aberto no dbl-click) para mostrar detalhes da ação correspondente. O fluxo principal mostra apenas a visão geral e, se forem necessários detalhes, eles estão a apenas um clique de distância.

Agora, a criação de um diagrama composto no EA é (novamente) diferente. Você precisa criar um AD no nível do pacote e arrastá-lo para o elemento de chamada. Agora, quando você clicar duas vezes nele, o diagrama incorporado será aberto.


Obrigado pela sua resposta. Você poderia dar mais detalhes sobre quando usar qual possibilidade? Acho a especificação UML bastante difícil de ler, do lado do usuário.
Tim

Não é uma palestra na hora de dormir :-) Vou tentar adicionar mais algumas explicações.
qwerty_so

Fiz uma atualização com uma observação em outro EAUI.
qwerty_so
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.