Diagrama de atividades e sua utilização – UML

Lembro-me que uns anos atrás, quando comecei a estudar a UML, os diagramas de atividade não eram muito bem compreendidos pela maioria dos analistas. Era como se aquela peça tivesse sido colocada no lugar de algo que não pertencia ao quebra cabeças da UML, entretanto depois de algum tempo quebrando a cabeça para entendê-lo, passou a ser uma das peças mais importantes para a fase após a identificação dos requisitos do sistema.

Mas então, o que é e para que é usado o diagrama de atividades? É fácil de entender, que uma atividade é um determinado estado de estar fazendo alguma coisa em um determinado momento no tempo. E aqui pode ser usado como um processo do nosso dia-a-dia (mundo real). Como, por exemplo, pedir uma pizza por telefone, ou uma execução sistêmica (processo de software) tal como a execução de uma rotina em C++/Java/C# e etc. para calcular distâncias orbitais entre os planetas, calcular o imposto de renda e etc.

O diagrama de atividades foi criado para descrever a sequência de atividades, tendo também suportes para comportamentos condicionais e paralelismo. Os comportamentos condicionais são delineados pelos desvios chamados de “branches” e pelas intercalações chamadas de “merge”.

Um “branche” é uma transição de entrada, que deve ser única, com várias transições de saídas. É importante observar, que somente uma transição de saída pode ser tomada por vez, de modo que a operação deve ser mutuamente exclusiva. Exemplo, a utilização de [else] como uma sentinela indica que a transição “else” deverá ser usada se a condição for falsa.

Um “merge” tem múltiplas transições de entrada e somente uma única saída. Sendo assim, um “merge” marca o final de um comportamento condicional iniciado pelo “branche”. Gosto sempre de frisar que não é necessário explicitar o losango para desvios e intercalações, uma atividade pode ter múltiplas transições de saída e múltiplas transições de entrada, por isso, use o losango se você desejar deixar claro cada desvio e intercalação em relação as regras de negócio.

Para efetuar o comportamento paralelo usa-se Separações “Forks” e Junções “Joins”. Vamos primeiro falar das separações e em seguida das junções.

Um “Fork” tem uma transição de entrada e diversas transições de saída (ao menos duas). Quando acionamos uma transição de entrada, ou seja, executamos um trigger, todas as transições de saída podem ser executadas em paralelo (não quer dizer que elas serão executadas simultaneamentes).

Isso significa dizer que a sequência entre elas não é relevante. Quando você tem uma separação (Fork), o que importa são os caminhos individuais de cada uma das separações. Um exemplo seria, no caso de dois departamentos de uma empresa trabalhando para entregar um determinado produto ao cliente, ou seja, um departamento poderia estar trabalhando na embalagem do produto enquanto outro poderia estar trabalhando na emissão da nota fiscal.

É importante dizer que o diagrama de atividades permite que se escolha a ordem que se vai executar as atividades. Ele determina as regras essenciais de sequência que devem ser seguidas. Um fluxograma, por exemplo, não tem habilidade para lidar com processos e atividades em paralelo. O que é de grande importância para a modelagem de regras de negócios.

Existe uma linha de modelagem de requisitos que troca as descrições de casos de uso por diagramas de sequencia. Eu inclusive vejo com bons olhos esse formato de trabalho, uma vez que substitui conteúdo textual, muitas vezes ambíguo, pro uma linguagem formal e gráfica, evitando erros de conceito e ainda agilizando o processo no momento de se alterar um determinado requisito de negócio que está obsoleto.

Ainda citando a utilidade dos diagramas de atividade, eles são muito úteis para modelar programas (rotinas) que fazem uso de mult-thread ou processamento paralelo, ainda mais nos dias de hoje em que temos processamento em grid, cloud computing, processadores com multicores e etc. Cada vez mas se faz necessário modelos para processamento paralelo, e é aí que os diagramas de atividade ganham mais força.

Para finalizar o comportamento de uma separação (“Fork”) é preciso sincronizar cada uma das separações que foram abertas. Apresentamos este conceito com a junção (“Join”). Com a Junção, a transição seguinte só ocorre quando todos os estados nas transições de entrada tenham completado suas atividades passando assim ao próximo estágio do fluxo.

Sempre as separações (“Forks”) e junções (“Joins”) devem se completar, ou seja, sempre que houver uma separação, uma junção deverá ocorrer em algum momento futuro. Existem algumas exceções para essa regra, mas basicamente essa é a regra da utilização de “Forks” e “Joins”.

Existe a possibilidade de adicionar ainda um thread condicional ao seu diagrama. Esse tema é um pouco complexo e deve ser muito bem pensado quando for modelado, mas é basicamente o seguinte: existe uma exceção para a regra de que todos os estados de entrada de um “Fork” devem ter suas atividades finalizadas antes que o “Join” possa ser efetuado. Aí que entra o thread condicional, você pode adicionar uma condição para um thread saindo de um “Fork”. Observe que se a condição para esse thread for falsa, esse thread é completado no que tange a junção (“Join”). Apresento abaixo um exemplo de Thread condicional para ilustração do que foi dito.

Outro conceito importante dos diagramas de atividade é a decomposição de uma atividade. Uma atividade pode e (dependendo do caso) deve ser decomposta para melhor entendimento das atividades que a compõe. Esta questão da decomposição das atividades fica a cargo do analista de negócios/sistemas, pois depende do grau de granularidade que se deseja obter na analise destes requisitos. Um exemplo que poderia ser dado para ilustrar é o de uma atividade de Entrega que pode ser decomposta em Entrega Regular e em Entrega Expressa. Dentro da ativdade “Entrega” detalha-se a atividade apresentando as sub-atividades pertencentes àquela atividade macro.

No próximo artigo abordarei mais dois conceitos: Concorrência Dinâmica e Raias (Swimlanes). O mais importante aqui (neste artigo) é entender que o diagrama de sequência é uma ferramenta bastante poderosa e sua aliada quando se fala em analise de sistema e negócio. Você pode (e deve) usá-la para analisar uma caso de uso, para compreender um determinado workflow, descrever um determinado algoritmo complicado e também lidar com aplicações de processamento paralelo.