UML Diagrama de Atividades


Olá pessoal, estamos aqui mais uma vez para apresentar mais um dos diagramas da UML. No último artigo, foram demonstrados os conceitos e os elementos do diagrama de sequência. Utilizamos ainda a ferramenta free ware StarUML para desenhar um exemplo de diagrama de sequência para fixar melhor os conceitos apresentados no artigo.
Desta vez iremos abordar os conceitos do diagrama de atividades, apresentar suas funcionalidades e seus elementos, além de também, descrever passo a passo a utilização do StarUML para o desenho de um diagrama de atividades na parte prática do artigo. Esperamos que tenham uma boa leitura.

 

 

Conceitos iniciais

 

O diagrama de atividades tem por objetivo demonstrar a perspectiva comportamental de processos. Uma atividade é composta por uma sequência estruturada de ações. Nesta estrutura podem seguir um ou mais fluxos, que podem por sua vez tomar outros caminhos através de desvios. Em outras palavras, este diagrama mostra as atividades que compõem um processo e seu fluxo de controle. Mostra também a execução de atividades sequenciais ou concorrentes.
Em seu conceito mais simples o diagrama de atividades até pode ser confundido com um fluxograma, porém o que o distingue de um fluxograma é a possibilidade de criar fluxos que seguem em paralelo, podendo se encerrar ao mesmo tempo ou até terem finais separados. Esta funcionalidade é muito importante, pois com isso pode-se seguir com ações do mesmo segmento e de setores distintos como, por exemplo, a preparação de um produto para a venda, pode-se ter o setor de produção e o setor de vendas dispostos no mesmo. A possibilidade de separar o diagrama por partições/setores é também uma das funcionalidades que o distinguem de um fluxograma, pois o torna muito mais organizado, portanto, mais legível.
Veja na figura 1 um exemplo da estrutura e de alguns elementos do diagrama de atividades.

 

Exemplo_01_02
Figura 1 – Exemplo da estrutura de um diagrama de atividades

 

Neste exemplo já podemos ver vários elementos do diagrama de atividades como o estado inicial e o estado final, a atividade, a separação (Fork) e a junção (Join), o desvio (deve ter condições de guarda para as suas saídas) e a intercalação. Para facilitar o entendimento sobre estes elementos e outros iremos descrever abaixo alguns conceitos e particularidades sobre cada um deles.

 

 

Elementos do diagrama de atividades

 

Nos próximos tópicos nos aprofundaremos mais nos conceitos de cada elemento demonstrado no diagrama da figura 1 e mais outros elementos.

 

 

Action – ação

 

Uma Action é representada por um retângulo com os cantos arredondados, o nome que descreve a atividade fica disposto no interior do retângulo (ver figura 2). Este elemento representa um passo a ser executado, dentre vários que possam ter a fim de executar um processo ou uma atividade completa, cada um destes passos é uma ação a ser executada.

 

Exemplo de Action
Figura 2 – Exemplo de Action

 

 

Subactivity – subatividade

 

A representação gráfica da Subactivity é semelhante a uma Action, com a diferença de ter um símbolo no canto inferior direito que indica que se trata de uma Subactivity (ver figura 3). Este elemento é uma atividade que se divide em ações para se completar. É utilizado quando há necessidade de especificar uma atividade mais abrangente.

 

Exemplo de subatividade
Figura 3 – Exemplo de utilização de uma Subactivity

 

 

Transições

 

As transições são representadas por uma seta contínua (ver figura 3). As transições fazem a ligação entre um elemento e outro do diagrama. Elas determinam o sentido que o fluxo deve seguir até que se chegue ao final do processo.

 

 

Eventos

 

Os eventos são alterações deliberadas de estado que dão início a uma ação. Falaremos de dois tipos de eventos, o Signal Accept State e o Signal Send State.

  • Signal Accept State: este elemento representa a execução instantânea de um evento e logo em seguida a execução de uma Action subsequente ao evento;

  • Signal Send State: este elemento representa a execução automática de um evento logo após o término da execução de uma Action.

 

Seguem na figura 4 exemplos da representação gráfica dos dois eventos citados.

 

Exemplo de eventos
Figura 4 – Exemplo gráfico dos eventos Signal Accept State e Signal Send State

 

 

Object Flow – fluxo de objetos

 

Este elemento representa explicitamente um objeto, que pode ter sido passado como um parâmetro para a execução de uma ação ou mesmo ter sido gerado ao término de uma. A forma gráfica de se representar um Object Flow é a mesma forma na qual é representado um objeto em outros diagramas da UML, ou seja, um retângulo com o seu nome especificado no interior da figura. Veja na figura 5 um exemplo de utilização do Object Flow.

 

Exemplo de utilização de objetos
Figura 5 – Exemplo de utilização do Object Flow

 

 

Initial State – estado inicial

 

Este elemento é representado graficamente por um ponto preto (ver figura 6). Indica o início de um fluxo dentro do diagrama. Todo diagrama deve ter pelo menos um Initial State, pode-se ter outros Initial States no mesmo diagrama em determinados casos.

 

 

Final State – estado final

 

Este elemento é semelhante ao Initial State, graficamente é representado por um ponto com uma borda circular, esta que é a única diferença entre os dois (ver figura 6). Sua função é indicar o fim do fluxo do processo. Todo diagrama dever conter pelo menos um Final State, isso indica que podem ter outros em determinados casos.

 

 

Flow Final – final de fluxo

 

A representação gráfica do elemento Flow Final é feita através de um círculo com um “X” ocupando toda sua dimensão (ver figura 6). Este elemento não deve ser confundido com o Final State, pois este último indica o fim do processo como um todo, e o Flow Final indica que o fluxo ao qual pertence chegou ao fim, porém podem ter outros fluxos que seguirão no decorrer da execução das atividades do diagrama.
Veja na figura 2 a representação gráfica dos elementos Inicial State, Final State e Flow Final.

 

fig02
Figura 6 – Representações de elementos de início e fim de fluxo

 

 

Decision or Merge – decisão ou fusão

 

Este elemento é representado graficamente por um losango. O que determina se é uma decisão ou uma fusão é a quantidade de entradas e saídas (transições). Por exemplo, se tivermos um elemento com uma entrada e duas ou mais saídas, este por sua vez é um elemento do tipo Decision. Se tivermos um elemento com duas ou mais entradas e apenas uma saída, este será o elemento do tipo Merge.

Quando for um elemento do tipo Decision cada transição de saída deverá ter uma condição de guarda entre colchetes. Ao chegar num elemento do tipo Decision o fluxo deverá seguir pela condição que for satisfeita (verdadeira). Estas condições não podem ser redundantes, isto é, o fluxo deverá seguir por apenas um caminho, não poderão existir duas condições verdadeiras.

Em outras palavras, o uso do elemento Decision se dá em situações condicionais, ou seja, dependendo de uma condição o fluxo segue por um lado, senão vai por outro. Já o uso do elemento Merge se dá para situações em que se faz necessário fazer a junção dos fluxos para seguir em um único fluxo.

Veja na figura 7 um exemplo de utilização do elemento Decision/Merge.

 

Exemplo de decision-merge
Figura 7 – Exemplo de utilização do elemento Decision/Merge

 

 

Synchronization (fork/join) – Sincronização (bifurcação/junção)

 

O elemento Synchronization é representado por uma barra sólida, ela pode ser disposta tanto na horizontal quanto na vertical, isso irá depender do sentido pelo qual os fluxos irão seguir. Este elemento, assim como o elemento anterior, se divide em duas funções denominadas Fork e Join.

O uso do tipo Fork se dá para dividir o fluxo do diagrama em atividades paralelas, ou seja, que serão executadas em modo concorrente. Esta função é uma das que tornam este diagrama tão dinâmico e flexível. O outro tipo de sincronização, o Join, é utilizado para unir as atividades que estão correndo em paralelo, seguindo assim em apenas um fluxo. Simplificando um pouco mais o entendimento deste elemento, o Fork faz a divisão das atividades e o Join faz a sincronização das mesmas.
Veja na figura 8 um exemplo de uso destes elementos.

 

Exemplo de Sincronização
Figura 8 – Exemplo de utilização dos elementos Synchronization, Fork e Join

 

 

Swimlanes – raias (de natação) ou partições

 

Este elemento é muito importante para a organização do diagrama. Com o Swimlane é possível demonstrar como as atividades podem ocorrer com diferentes agentes dentro de um processo, cada Swimlane recebe o nome do agente que representa.

Com o uso deste elemento pode-se por exemplo detalhar as atividades de um caso de uso, definindo cada ator do caso de uso como uma Swimlane.

Veja na figura 9 o exemplo anterior com a utilização dos elementos Swimlanes, demonstrando os diferentes agentes, Vendas e Estoques, atuando de forma concorrente no decorrer do processo.

 

Exemplo de Swimlanes
Figura 9 – Exemplo de utilização do elemento Swimlane

 

As Swimlanes podem ser utilizadas de várias formas. A utilização deste componente facilita o entendimento do processo do diagrama. Veja na figura 10 outro exemplo de utilização deste elemento.

 

Exemplo de Swimlanes 02
Figura 10 – Outro exemplo de utilização do elemento Swimlane

 

 

Desenhando um Diagrama de Atividades no StarUML

 

O diagrama que iremos desenhar, para auxiliar na fixação dos conceitos abordados neste artigo, consiste no processo de venda de um estabelecimento. Ele irá envolver quatro agentes, são eles: Cliente, Faturamento, Vendas e Estoque. O processo do nosso diagrama de atividades deverá seguir as seguintes instruções:

  • Inicia-se no momento em que o cliente solicitar ao vendedor uma nova venda;

  • O vendedor irá abrir uma nova venda;

  • A qualquer momento o cliente pode solicitar o cancelamento da venda (item 4);

  • Quando solicitado o vendedor irá cancelar a venda e finalizando o fluxo do diagrama;

  • O vendedor irá lançar os itens da venda;

  • Se o item não tiver estoque, verifica se o cliente deseja cancelar a venda; Caso o cliente opte pelo cancelamento da venda, o fluxo deverá seguir para o item 4; Caso o cliente queira lançar novos itens, o fluxo deverá voltar ao item 5;

    Se o item tiver estoque (considerando que o vendedor já lançou os todos os itens que o cliente pediu e todos têm quantidade suficiente em estoque) é solicitada ao setor de estoques a coleta dos itens da venda (Item 7) e em paralelo é solicitado o faturamento da venda (item 8);

  • O setor de estoque recebe a lista de itens a ser separado e faz a coleta dos itens e aguarda o fechamento da venda (item 11);

  • O setor de venda solicita a criação da fatura da venda ao setor de Faturamento;

  • O pagamento da fatura é solicitado ao cliente;

  • Caso o cliente não realize o pagamento, a venda deverá ser cancelada (item 4); Caso o cliente tenha efetivado o pagamento, será solicitado ao vendedor o fechamento da venda (Item 11);

  • O vendedor realiza o fechamento da venda após estar com os itens separados e o pagamento aprovado e libera a entrega dos itens par o cliente (item 12);

  • O setor de estoque realiza a entrega dos itens para o cliente e finalizando o processo.

 

Preparando um novo projeto

 

Vamos agora por as mãos na massa e começar a desenhar nosso diagrama.

Para a criação do nosso exemplo prático iremos utilizar a ferramenta StarUML, como já foi dito antes, é uma ferramenta free ware, e está disponível para download na página do desenvolvedor. O endereço é: (http://staruml.softonic.com.br). Outra qualidade do StarUML é a sua interface, que é agradável e bem intuitiva, além é claro de permitir o usuário a personalizar seus padrões de fontes e cores em seus diagramas. A instalação do StarUML segue o padrão (Next, Next, Finish).

Logo ao abrir o StarUML, é exibida a janela “New Project by Approach”, escolha a opção “Default Approach” e clique em “OK”. Com isso o StarUML cria um novo projeto de diagramas com uma estrutura de modelagem padrão já configurada.
Iremos criar um novo Diagrama de Atividades, para isso devemos ir ao painel “Model Explorer” – que por padrão fica disposto na parte superior direita da janela do StarUML – e clicar com o direito do mouse no nó “<<useCaseModel >> Use Case Model”, depois clique na opção “Add Diagram” e logo em seguida na opção “Activity Diagram”. Abrirá na tela uma página em branco para começar a criar o nosso exemplo. Para podermos desenhar o diagrama devemos escolher as ferramentas no painel “ToolBox” – que fica situado na lateral esquerda da tela do StarUML. Veja na figura 11 as ferramentas que estão disponíveis no painel “ToolBox”.

 

Tools StarUML - Diagrama de Atividades
Figura 11 – Ferramentas disponíveis no painel ToolBox do StarUML

 

Neste painel podemos ver todos os elementos citados neste artigo, como já sabemos a utilidade de cada um, vamos partir logo para a criação do desenho.

 

 

Inserindo os elementos no diagrama

 

Adicione na área de desenho do StarUML 4 elementos Swimlane (Vertical). Coloque a seguinte nomenclatura para cada um destes elementos: “Cliente”, “Faturamento”, “Vendas” e “Estoque”. Para informar o nome de cada Swimlane basta dar um duplo clique e em seguida escrever seu relativo nome.  Disponha estes elementos um ao lado do outro seguindo a mesma ordem da nomenclatura sugerida;

Agora vamos adicionar as Actions em nosso desenho. Adicione 9 elementos ActionState, e os disponha da seguinte forma: dois deles ficarão na Swimlane “Cliente”, um na Swimlane “Faturamento”, quatro na Swimlane “Vendas” e dois na Swimlane “Estoque”.

Na partição (Swimlane) “Cliente” nomeie as duas ações da seguinte forma: “Solicita pedido” e “Realiza pagamento”. Na partição “Faturamento” nomeie sua ActionState como “Gerar fatura”. Na partição “Venda” nomeie as quatro ações utilizando a seguinte nomenclatura: “Abre venda”, “Lança item”, “Cancela venda” e “Fecha venda”. E por último nomeie as duas ações da partição “Estoque” com as seguintes nomenclaturas: “Coleta itens” e “Entrega itens”. Vale lembrar que para renomear este elemento, basta dar um duplo clique e adicionar a nova nomenclatura e em seguida teclar “Enter” para confirmar.
Para atender a regra do item 3 de nossa lista, “A qualquer momento o cliente pode solicitar o cancelamento da venda”, vamos adicionar um evento ao diagrama. Para isso selecione no painel ToolBox a ferramenta SignalAcceptState e o disponha na Swimlane “Cliente”. Coloque o nome “Solicita cancelamento” a este evento.

Como sabemos este elemento deve estar ligado a uma atividade que será realizada logo em sequência da ativação deste evento. Ou seja, este evento “Solicita cancelamento” será vinculado com a ação “Cancela venda”. Porém, vamos deixar as ligações entre estes elementos para mais tarde, vamos adicionar os demais elementos ao diagrama e realizar as transições (ligações) após todos os elementos estarem dispostos no escopo do desenho.

Adicione três elementos Decision ao desenho. Cada um deles será responsável por uma tomada de decisão durante o fluxo do diagrama. Através do painel “Properties” – que por padrão fica localizado na parte inferior direita da tela do StarUML – aplique nestes componentes com as seguintes nomenclaturas: “Possui estoque”, “Lança novo item” e “Realizou pagamento”. Para isso basta selecionar o elemento no desenho e alterar o nome na caixa de textos da propriedade Name no painel Properties.

Disponha o Decision “Possui estoque” na Swimlane Vendas, o “Lança novo item” na Swimlane Cliente e o Decision “Realizou pagamento” na Swimlane Faturamento.

O Decision que ficará na partição Vendas será responsável por verificar se o item possui quantidade em estoque. O elemento que ficará na partição Cliente será responsável por verificar se o cliente deseja cancelar a venda ou continuar lançando mais itens na venda em caso de algum item não tiver quantidade disponível em estoque. O último elemento Decision, que estará na partição Faturamento, será responsável por verificar se a fatura foi efetivada pelo cliente.
Agora, selecione o elemento Synchronization no painel ToolBox e adicione dois dele na partição Vendas. Eles serão responsáveis por atribuir as tarefas dos setores de faturamento e de estoque de forma paralela e, logo ao fim de cada uma, juntá-las para que possa ser feito o fechamento da venda. Nomeie-os da seguinte maneira: “Divide tarefas” e “Junta tarefas”.
Por fim nos resta definir onde irá começar e onde irá terminar o fluxo do nosso diagrama, para isto adicione respectivamente os elementos InitialState e FinalState dispondo-os em paralelo com a lateral esquerda da Swimlane Cliente. Nomeie-os como “Estado inicial” e “Estado final”.

Com estes elementos todos adicionados ao desenho, ajuste as disposição de cada um para que fique semelhante ao layout da figura 12. Após isso iremos adicionar as transições entre cada elemento para podermos finalizar o exemplo.

 

Exemplo sem transições
Figura 12 – Exemplo de layout do diagrama

 

 

Adicionando as transições entre os elementos

 

Antes de começarmos a adicionar as transições vamos aprender como utilizá-las. O painel ToolBox possui duas ferramentas para a adição de transições, são elas: Transition e SelfTransition. A única diferença entre elas é que a última se refere a uma chamada de um elemento para si mesmo. Para adicionar uma transição entre dois elementos, devemos considerar os elementos de origem e destino, pois deverá ser clicado com o ponteiro do mouse sobre o elemento origem e em seguida arrastar sobre o elemento destino. A seta da Transition ficará apontada para o elemento destino.

Quando for uma transição partindo de um elemento Decision, esta deverá conter obrigatoriamente uma condição de guarda, para indicar quando o fluxo deverá seguir por ela. Para adicionar uma condição de guarda a uma transição é necessário selecioná-la na área de desenho e depois selecionar no painel “Properties” a propriedade GuardCondition e escrever na caixa de textos qual será a condição, por exemplo, “Sem estoque”.

Veja na tabela 1 a relação de todas as transições entre os elementos deste diagrama. Cada linha da tabela refere-se a uma transição com as seguintes informações: Nome do elemento origem; tipo do elemento origem; condição de guarda (caso necessário); nome do elemento destino e tipo do elemento destino.

 

 

Elemento origem

Tipo

Condição de guarda

Elemento Destino

Tipo

1

Estado inicial

InitialState

 

Solicita pedido

ActionState

2

Solicita pedido

ActionState

 

Abre venda

ActionState

3

Abre venda

ActionState

 

Lança item

ActionState

4

Lança item

ActionState

 

Possui estoque

Decision

5

Possui estoque

Decision

Sem estoque

Lançar novo item

Decision

6

Possui estoque

Decision

Com estoque

Divide tarefas

Synchronization

7

Lança novo item

Decision

Novo item

Lança item

ActionState

8

Lança novo item

Decision

Cancelar venda

Cancela venda

ActionState

9

Cancela venda

ActionState

 

Estado final

FinalState

10

Divide tarefas

Synchronization

 

Coleta itens

ActionState

11

Divide tarefas

Synchronization

 

Gera fatura

ActionState

12

Coleta itens

ActionState

 

Junta tarefas

Synchronization

13

Gera fatura

ActionState

 

Realiza pagamento

ActionState

14

Realiza pagamento

ActionState

 

Realizou pagamento

Decision

15

Realizou pagamento

Decision

Sem pagamento

Cancela venda

ActionState

16

Realizou pagamento

Decision

Realizou pagamento

Junta tarefas

Synchronization

17

Junta tarefas

Synchronization

 

Fecha venda

ActionState

18

Fecha venda

ActionState

 

Entrega itens

ActionState

19

Entrega itens

ActionState

 

Estado final

FinalState

20

solicita cancelamento

SignalAcceptState

 

Cancela venda

ActionState

Tabela 1 – Relação das transições entre os elementos do diagrama

 

Após adicionar todas as transições ao desenho, nosso exemplo estará concluído. Podemos perceber, seguindo os fluxos possíveis do diagrama que ele atende as especificações que foram exigidas para a criação do diagrama. Veja na figura 13 o desenho do diagrama já finalizado.

 

Exemplo Completo
Figura 13 – Exemplo finalizado com todas suas transições

 

 

Conclusão

 

Vimos neste artigo alguns conceitos e elementos que compõe mais um diagrama da UML, o Diagrama de Atividades. Procuramos demonstrar de forma prática e objetiva, quais são suas funcionalidades, citando também exemplos de utilização. Por fim, fizemos uso da ferramenta StarUML para auxiliar na criação de um exemplo prático, e com isso auxiliar na fixação dos conceitos citados no decorrer do artigo.

Espero que tenham gostado. Uma abraço a todos e até a próxima.

 

Sobre o Autor

Lucas Vieira de Oliveira Consultor The Club.

E-mail: suporte@theclub.com.br

The Club - O Maior Clube de programadores do Brasil