Comparação de duas abordagens para estruturar um diagrama de atividades (baseado em “Esquilos”)
В modelamos os processos de uma área temática de “conto de fadas” - versos sobre um esquilo de “O Conto do Czar Saltan, seu filho, o glorioso e poderoso herói Príncipe Gvidon Saltanovich e a bela Princesa Cisne”, de A.S. Pushkin. E começamos com o diagrama de atividades, concordando em estruturar o campo do diagrama usando “raias de natação”. O nome da trilha corresponde ao tipo de elementos do diagrama que estão presentes nessa trilha: Artefatos de Entrada e Saída, Etapas do Processo, Participantes e Regras de Negócios. Esta abordagem difere da abordagem padrão, quando as trilhas são designadas pelos nomes dos participantes do processo, atribuindo-lhes assim determinadas áreas de responsabilidade no processo.
Neste exemplo, estou usando o ambiente Enterprise Architect de uma empresa australiana. [1].
Para mais detalhes sobre as abordagens de modelagem aplicadas, consulte [2].
Para obter a especificação UML completa, consulte [3].
Vou repetir a versão do diagrama do artigo anterior (Figura 1) e mostrar um diagrama redesenhado com trilhas “padrão” (Figura 2), tentarei delinear os prós e os contras, talvez um pouco subjetivamente.
Figura 1. Diagrama de atividades – visão geral do processo
Figura 2. Diagrama de atividades – estruturação padrão do diagrama
- Deve-se admitir que o número de setas é um pouco menor no 2º diagrama.
- Mas no 2º diagrama, os objetos ficam “espalhados” por todo o campo do diagrama, o que, para meu gosto, não é muito conveniente.
- A mesma história com notas - regras. E para inserir a regra sobre a nomeação de um diácono, todos os elementos do diagrama tiveram que ser movidos para baixo em algum momento.
- Tive que clonar a etapa “receber/transmitir…” para mostrar que vários participantes estão presentes nesta etapa.
- Na segunda opção, tive que abrir mão de uma ramificação e de uma fusão do processo, enfim, era absolutamente impossível organizá-los “bem”! Felizmente, então seria necessário postar um comentário – regra.
Claro que não há camaradas no sabor e na cor, mas a primeira opção também me parece mais conveniente para coletar dados sobre o processo.
Mas não vou mentir - às vezes é melhor desenhar as duas opções para entender o processo.
Lista de fontes
- Site da Sparx Systems. [Recurso eletrônico] Modo de acesso: Internet:
- Zolotukhina E.B., Vishnya A.S., Krasnikova S.A. Modelagem de processos de negócio. - M.: KURS, NITs INFRA-M, EBS Znanium.com. — 2017.
- Especificação OMG Unified Modeling Language (OMG UML). Versão 2.5.1. [Recurso eletrônico] Modo de acesso: Internet:
Fonte: habr.com