Olá, aluno(a), seja muito bem-vindo(a) à mais uma lição. Hoje, você aprenderá a construir o Diagramas de Atividade da UML. Esse tipo de diagrama é uma importante ferramenta para compreender o fluxo das informações de um Caso de Uso. Assim como o Diagrama de Sequência, teremos um diagrama de atividade para cada caso de uso apresentado no Diagrama de Caso de Uso. Contudo, no diagrama de atividade, não se usa instâncias das classes ou os métodos das classes, assim como é feito no Diagrama de Sequência. O Diagrama de Atividades é mais simples do que o Diagrama de Sequência e tem uma aplicação diferente. Enquanto, no Diagrama de Sequência, o importante é demonstrar a temporalidade dos eventos dentro do caso de uso, no diagrama de atividade, o importante é demonstrar a sequência de eventos e as condicionais associadas.

O Diagrama de Atividades pode ser bastante utilizado no cotidiano dos profissionais, mesmo que não sejam da área de tecnologia, porque ele se assemelha ao “famoso” Diagrama de Fluxo de Dados, ou Fluxograma (RUMBAUGH; JACOBSON; BOOCH, 1999). Contudo o Diagrama de Atividades na UML tem as suas particularidades, como veremos nesta lição.

Compreender a sequência de eventos que ocorre dentro da funcionalidade (caso de uso) de um software é tão importante para o desenvolvedor quanto saber escrever para um escritor. Sem a devida compreensão do fluxo dos dados dentro de cada funcionalidade do software, é bem provável que erros aconteçam e as funcionalidades não atendam às expectativas dos stakeholders. Assim, para facilitar a modelagem do projeto de software e atender a essa demanda por parte do desenvolvedor, foi criado o Diagrama de Atividade.

O Diagrama de Atividade trata-se de um diagrama da UML que tem suas bases teóricas e práticas alicerçadas em abordagens de desenvolvimento de software mais antigas, como na Análise Estruturada Moderna (YOURDON, 1990). O “primo” do Diagrama de Atividade (DA) é o Diagrama de Fluxo de Dados (DFD) utilizado na Análise Estruturada, e eles possuem muitas semelhanças que podem confundir quem está construindo o projeto do software. Contudo o DA segue paradigmas de desenvolvimento de software diferentes do DFD. A UML segue uma abordagem orientada a objetos enquanto o DFD segue o paradigma estrutural. Nesse momento, é importante para o projetista do projeto compreender bem as particularidades que envolvem o desenvolvimento desse diagrama para não aplicar práticas que fogem ao paradigma de desenvolvimento seguido pela UML.

Os principais desafios, ao desenvolver o DA, é compreender a lógica do Caso de Uso, ou seja, saber, exatamente, qual atividade é executada e em qual momento bem como quais condições são aplicadas ao longo do fluxo dos dados dentro do Caso de Uso. Muitas vezes, a compreensão dessa lógica vem da fase de Engenharia de Requisitos, em que o técnico busca informações sobre as funcionalidades do software junto aos principais stakeholders (veja nossa lição sobre esse tema caso tenha dúvidas).

Após compreender a lógica do Caso de Uso e suas condicionais, é o momento de desenvolver o diagrama de atividade, e é aqui que a nossa lição entra. Como desenvolver um diagrama de atividade? Por onde começar? Quais são os elementos gráficos do diagrama de atividade? Essas perguntas serão respondidas nas próximas páginas. Vamos lá!

Imagine que você está desenvolvendo um software para gerenciar as inscrições de pessoas em um concurso público, um vestibular ou algo semelhante. Sabe-se que esse tipo de software tem várias funcionalidades, mas a primeira delas é a realização da inscrição no concurso/vestibular, correto? O nosso objetivo é apresentar a sequência lógica de etapas que deverão ocorrer nesse software. Assim, devemos utilizar o diagrama de atividade para isso. 

Você já conversou com os stakeholders e sabe como deve funcionar o processo de inscrição no concurso. Chamaremos essa funcionalidade de Caso de Uso “realizar inscrição”. De acordo com as informações que você coletou, o primeiro passo que o candidato deve ter no sistema, após acessar a página, obviamente, é selecionar o concurso que deseja se inscrever. Observe que estou considerando a existência de mais de um concurso ao mesmo tempo. Assim, o candidato seleciona um dos concursos, mas, do lado do sistema, é preciso listar os concursos vigentes. Nesse momento, uma das atividades que devemos apresentar é “listar concursos vigentes”. Observe que precisamos olhar, pela ótica do sistema, aquilo que o sistema realizará (ação) em relação ao usuário, e não o contrário. 

No diagrama de atividade, nós temos a possibilidade de modelar laços de repetição. Assim, como podemos ter vários concursos vigentes, o diagrama pode apresentar essa busca dos concursos num formato de loop até que todos sejam apresentados. Esse tipo de modelagem é interessante, porque deixa claro ao desenvolvedor a necessidade de uma estrutura de repetição naquele momento para que todos os concursos sejam apresentados ao usuário.

Após apresentar todos os concursos vigentes, espera-se que o usuário selecione um deles. Nesse momento, a atividade apresentada no diagrama poderia ser “receber concurso escolhido”. Na sequência, a atividade “receber dados do candidato” é utilizada para que haja o preenchimento dos dados de inscrição. Aqui, a depender das conversas que você teve com os stakeholders, podemos considerar duas situações: 1) o candidato nunca se inscreveu num concurso naquele sistema e 2) o candidato já possui um cadastro, logo, não faz sentido ele se cadastrar novamente. Aqui, poderíamos utilizar o recurso de condicional (representado por um losango, ou diamante) — veremos isso mais à frente! —, para modelar que uma situação ou outra poderia ocorrer.

Executada a atividade anterior, num ou noutro sentido, o sistema deve executar a atividade “registrar inscrição”. Como forma de complemento, podemos utilizar o recurso de condicional para informar um erro ao usuário, caso a inscrição não tenha ocorrido com sucesso, ou enviar uma confirmação de inscrição realizada. Essa confirmação pode ser por e-mail, na própria tela, ou WhatsApp, por exemplo. O que definirá isso é a sua conversa com os stakeholders, mas não detalhamos esse meio no diagrama de atividades, apenas a atividade de “confirmar inscrição”.

Por fim, conforme você já estudou em lições anteriores, a UML utiliza representações gráficas para modelar um software. Assim, precisamos conhecer essas representações e os seus significados para construirmos um diagrama de atividade. Vamos lá!

O diagrama de atividade, muitas vezes, é confundido com o diagrama de fluxo de dados da Análise Estruturada Moderna e, em alguns momentos, com o Diagrama de Máquina de Estado da própria UML. Contudo, a partir da versão 2 da UML, o diagrama de atividade passou a ter características únicas que o diferenciam de outras abordagens (GUEDES, 2011). 

O diagrama atividade pode ser utilizado para a modelagem de um processo simples, como parte de um algoritmo, ou um processo complexo com diversas estruturas. Assim, como os demais diagramas da UML, o Diagrama de Atividade possui representações gráficas com significados únicos. Vamos conhecê-las! 

Num diagrama de atividade, a atividade é iniciada com o “nó inicial”, representado, graficamente, por um círculo preenchido, conforme Figura 1.

Na sequência, temos o “fluxo de controle”, que é representado, graficamente, por uma seta direcional, conforme Figura 2.

Uma atividade no diagrama de atividade é representada por um retângulo com bordas arredondadas, conforme Figura 3.

Também, pode ser utilizado, no diagrama de atividade, a estrutura condicional ou nó de decisão. O nó de decisão é representado por um losango, ou diamante, preenchido, conforme Figura 4.

Assim como no diagrama de sequência, também, podemos modelar, no diagrama de atividade, os atores que estão envolvidos no caso de uso. Para isso, fazemos uso da partição de atividade (Horizontal Swimlane), conforme Figura 5.

A partição de atividade nada mais é do que uma divisão realizada no diagrama com o objetivo de modelar aquelas atividades que são executadas pelos atores. Por meio da partição de atividade, é possível saber qual ator usa qual atividade dentro do diagrama.

Por fim, temos o nó de finalização do diagrama. Esse nó indica que o fluxo de dados dentro do diagrama se encerra naquele momento.

Até o momento apenas foram apresentadas as principais representações gráficas do diagrama de atividade. Agora, observaremos algumas modelagens que usam esses elementos de forma relacionada, conforme Figura 7.

A Figura 7 apresenta um diagrama de atividade parcial para o caso de uso chamado “realizar inscrição”. O caso de uso se inicia pela atividade de seleção do concurso que a pessoa deseja se inscrever. Na sequência, os concursos vigentes são listados para que, na terceira atividade, o concurso selecionado seja recebido e a tela de dados para a inscrição seja apresentada. Perceba que não é possível “vermos” essa tela de dados sendo exibida ao usuário, isso ocorre porque essa modelagem é feita no diagrama de sequência, e não aqui, no diagrama de atividade. A quarta atividade do diagrama é a “receber dados do candidato”, obviamente, após o seu preenchimento. Por fim, a última atividade é o registro da inscrição.

É possível observar na Figura 7 que alguns elementos que foram apresentados anteriormente não fazem parte do diagrama, como o nó de decisão ou a partição de atividade. Observemos um diagrama atividade mais completo, conforme Figura 8.

O diagrama da Figura 8 pode ser considerado um diagrama de atividade mais completo se comparado com o diagrama da Figura 7. Pode-se observar elementos que são essenciais para um diagrama de atividade, como a partição de atividade modelando os atores que interagem com o sistema e o próprio sistema. Esse tipo de modelagem permite ao desenvolvedor ter uma clareza de qual funcionalidade está do lado do usuário e qual está do lado do sistema.

Também, observa-se, no diagrama, comentários sobre os fluxos (as setas) — esses comentários permitem melhor compreensão do que significam essas ligações. O losango, ou diamante, como também é chamado, representa um nó de decisão e direciona o usuário (candidato) para uma atividade ou outra, conforme você pode observar na Figura 8. Se o usuário já possuir um cadastro no sistema, ele segue para a atividade “registrar inscrição”, porque os dados dele já existem no sistema. Caso ele não possua cadastro, a atividade “receber dados do candidato” deve ser executada e só então o usuário passará para a atividade “registrar inscrição”.

O diagrama de atividade é uma ferramenta bastante poderosa para modelar processos organizacionais e, na modelagem de sistemas computacionais, permite que você tenha clareza do fluxo dos dados e das ações que serão realizados ao longo do processo/caso de uso. Trata-se de um diagrama que deve ser dominado pelo(a) técnico(a), porque precisará construir ou ler esse tipo de diagrama para compreender, exatamente, como as atividades do sistema ocorrerão. Lembre-se que os diagramas da UML se complementam e, nesse momento, você pode perceber que os diagramas de sequência e de atividade, juntos, fornecem valiosas informações sobre o projeto do sistema e como ele deve funcionar. 

A criação de um diagrama de atividade é parte da tarefa do(a) técnico(a) que objetiva desenvolver o projeto de um sistema computacional. Assim como os demais diagramas da UML, o diagrama de atividade tem as suas particularidades e a função específica de modelar as atividades que envolvem os casos de uso do sistema. Dificilmente, o(a) técnico(a) que atua com análise e projeto de sistemas não utilizará o diagrama de atividade no seu cotidiano. Digo isso porque se trata de um diagrama de fácil compreensão, desenvolvimento, mas é bastante poderoso para compreender as funcionalidades (casos de uso) dos sistemas computacionais.

Ademais, o diagrama de atividade pode ser utilizado em momentos distintos da carreira de um profissional das mais diversas áreas do conhecimento. Um gerente de processos ou um gerente de projeto pode fazer uso do diagrama de atividade para modelar processos de uma organização e que não, necessariamente, serão parte de um novo sistema ou da informatização daquela área. O diagrama pode ser usado, simplesmente, para melhor compreensão das etapas existentes dentro da organização ou de um processo produtivo numa fábrica. As possibilidades são inúmeras, basta que você se envolva nos estudos e faça uso adequado e no momento certo do diagrama.

Por fim, deixo algumas dicas e lembretes finais para que os seus diagramas de atividade sejam sempre coesos e autoexplicativos. Primeiro, lembre-se que temos uma ferramenta online e gratuita para a criação de diagramas da UML, o Visual Paradigm (https://online.visual-paradigm.com/). Faça uso constante dessa ferramenta, porque ela segue os padrões de mercado e é utilizada por muitas organizações. Segundo, tenha sempre em mente que os diagramas da UML são complementares. Nunca tente modelar tudo que existe num sistema no mesmo diagrama, pois não é esse o objetivo da UML! Por esse motivo é que temos tantos diagramas, cada um faz uma pequena parte e, juntos, eles permitem a modelagem de todo o sistema. Terceiro, não inicie o seu projeto de software baseado na UML pelo diagrama de atividade. 

Nessa sequência, você terá mais condições de desenvolver bons diagramas de atividade. Para finalizar, mas não menos importante, sempre reavalie a coerência entre os diagramas que você já construiu. Eles precisam “conversar” entre si. Ou seja, se um caso de uso e um ator existem num diagrama, eles, também, devem aparecer no outro diagrama com os mesmos elementos de comunicação. Mantenha a coerência entre os diagramas, sempre!