Qual destes conceitos se refere ao diagrama de atividades a estes diagramas utilizam como primitivas atores casos de uso e relacionamentos?

O que são atividades? Segundo o site Sinônimos é “funcionamento, operação, atuação, laboração, execução”.

No contexto da UML, o Diagrama de Atividades é um diagrama comportamental (que especifica o comportamento do software), e através dele podemos modelar partes do comportamento de um software.

Em projetos de software utilizamos modelos para representar tanto a estrutura quando o comportamento do sistema e com base neles construir, programar o modelo executável, que é o sistema materializado. Eu costumo falar assim: estrutura representa aquilo que é estático, que não muda com o uso do sistema, não muda de estado, não movimenta. Comportamento é o que é dinâmico no sistema, que se altera a partir de ações do próprio sistema ou do usuário”.

O diagrama de atividades ilustra graficamente como será o funcionamento do software (em nível micro ou macro), como será a execução de alguma de suas partes, como será a atuação do sistema na realidade de negócio na qual ele está inserido.

UML e Agilidade

Agilidade não é produzir software com pressa, é produzir software com velocidade, entregando valor no menor espaço de tempo possível, e melhorando isso continuamente.

Para ser ágil, é fundamental ser eficiente.

Não é plausível falar em agilidade sem eficiência, com desperdício.

Em projetos de software, um dos maiores desafios é a boa comunicação.

Deixar claro o que se quer, o que será entregue, como será produzido etc. Isso não é simples quando produzimos software, devido à complexidade inerente a esta atividade.

Quando se entende um requisito do jeito errado, sempre há o custo de fazer errado, desfazer, e fazer certo. Obviamente, este tipo de desperdício custa 3 vezes mais que se tivéssemos feito certo da primeira vez.

E neste contexto, fica claro que o uso racional de diagramas UML com o objetivo de transmitir ideias entre membros de um mesmo time, é uma ferramenta que favorece muito uma cultura ágil.

Objetivos de utilização

O diagrama de atividades, como citado, tem como objetivo principal a especificação do comportamento do software, do ponto de vista funcional, ou seja, das suas funcionalidades. É muito semelhante a um fluxograma, uma ferramenta utilizada há muitas décadas, principalmente na administração.

Pressupõe-se que, antes de se especificar o funcionamento do software, é necessário especificar “o que é o software, para que serve o software” (veremos isso no item “quando não usar”, mais a seguir).

E ainda, como para qualquer outro modelo que segue a notação UML, o objetivo de um diagrama é especificar o que será posteriormente projetado, ou diretamente construído, diminuindo assim o nível de abstração do escopo, facilitando o entendimento sobre o que tem ser feito pelo programador, por exemplo.

Com isso, programadores, por exemplo, podem entender de uma maneira “mais lógica” e “menos abstrata” o que deverá ser codificado no modelo executável. Entenderemos isso melhor mais à frente.

Quando usar

Na prática, é um diagrama como o bombril: tem mil e uma utilidades. 🙂 Mas não significa que isso é bom.

Usar um faca para apertar um parafuso pode até funcionar, mas pode machucar a mão por não ser a ferramenta apropriada para isso, ou ainda, estragar o parafuso.

O diagrama de atividades apresenta uma simplicidade muito tentadora, e em função disso, muitos analistas utilizam o diagrama para modelagem de processos, modelagem de algorítimos, modelagem de sequência etc., quando na realidade, existem diagramas apropriados para isso na UML ou na BPMN.

É pertinente utilizá-lo quando o propósito é:

• Documentar o aspecto funcional (não estrutural) do software, quando é necessário representar o fluxo da informação que o software trabalhará, e quando existam condições/decisões que precisam detalhadas/descritas.

• Mostrar aspectos específicos de alguma rotina do negócio que será automatizada pelo software, como um “zoom” em parte de alguma funcionalidade, por exemplo. Obs.: muito cuidado ao especificar toda uma funcionalidade (uma tela ou rotina batch por exemplo) num diagrama de atividades. Geralmente isso gera diagramas de atividades super complexos, o que pode gerar efeito inverso (ou seja, “subtrair mais que somar”).

• Mostrar como Funcionalidades vão realizar Requisitos Funcionais (funções executadas pelas funcionalidades), e a relação dos Requisitos Funcionais com as Regras de Negócio.

• Documentar de forma macro como o sistema irá funcionar, mas orientado ao software, não ao processo de negócio. Mostrar como os módulos do sistema interagem entre si, as principais as informações trafegadas durante a execução do software, entradas e saídas principalmente.

Quando me refiro a documentar, é importante deixar claro que a documentação só tem razão de existir quando serve para explicar algo para alguém, e deixar uma memória viva e “útil” do projeto do software. Diferente disso é perda de tempo, dinheiro, e aumento da ineficiência do processo produtivo através do aumento desnecessário da complexidade do projeto.

Quando não usar

Não é pertinente utilizar diagramas de atividades para:

• Elicitação de requisitos, pois o foco do diagrama de atividades é no comportamento, no aspecto “funcional” do software. E antes de se pensar no funcionamento do software é fundamental se pensar no conceito do sistema, focando no problema de negócio, e na solução que será aplicada para resolvê-lo. Para isso, utilize Digramas de Bloco ou Diagramas de Decomposição Funcional, por exemplo.

Um dos maiores problemas do Analista de Sistemas é dar atenção ao “micro” quando ainda não entendeu o “macro”. Antes de pensar no funcionamento do software é necessário pensar no negócio que o software vai automatizar, qual o conceito dessa solução, e o que o software deverá fazer e não como ele deverá fazer. Isso se faz com Engenharia de Requisitos, e depois dos requisitos especificados, estes são “distribuídos” nas funcionalidades do software, que os realizam.

• Quando o assunto é Modelagem de Processos de Negócio. Modelar processos não é modelar software. Software pode ser utilizado para realizar algumas atividades/tarefas do processo de negócio, mas são coisas muito distintas. Existem profissionais que utilizam diagramas de atividades para modelar processos, e diagramas BPMN para modelar software. São notações diferentes, e para quem está acostumado com ambos, pode gerar confusão.
• Modelar o comportamento completo de telas e rotinas batch. Para essas finalidades, diagramas de Caso de Uso ou diagramas de Sequência são opções muito melhores. Utilize o primeiro quando o foco for mais no aspecto funcional da tela ou da rotina e quando usuários ou analistas menos técnicos estiverem envolvidos, e o segundo quando o foco for mais no design (projeto) do software, quando programadores ou arquitetos estiverem envolvidos.

Como usar

Na UML temos dois conceitos importantes de entender: diagramas e elementos. Na imagem que vimos no início do post temos uma relação de todos os diagramas da UML.

As formas gráficas que compoe cada diagrama são chamadas “elementos”. Estes elementos são “o grande lance” da UML, é o que sustenta a ideia de “notação”, é a sintaxe contida nos diagramas.

Cada elemento possui um objetivo específico, e a combinação destes elementos torna-se o diagrama, que gera a semântica do respectivo modelo.

Como tudo na vida, na UML também aplica-se o Princípio de Pareto. Com 20% dos elementos fazemos 80% dos diagramas. Então, vou focar nos elementos mais utilizados do diagrama de atividades.

Activity – É a atividade propriamente dita. Usamos este elemento quando citamos uma atividade no diagrama. Por exemplo: “Processar Pedido” é uma atividade que seria ilustrada com esta forma.

Partition – É comum chamarmos de “Raia”, fazendo uma analogia com as raias de uma piscina. Podem ser representadas na vertical ou na horizontal. Ilustram fronteiras entre módulos, funcionalidades, sistemas ou sub-sistemas, conforme o nível de detalhe e foco do diagrama.

Decision – Representa uma decisão que pode desviar o fluxo ilustrado no diagrama. Utilizado quando lidamos com condições. Por exemplo: “Pagamento aprovado? Se sim, desvia para a atividade Gerar Boleto, se não, vai para atividade “Pagar novamente”.

Initital – É o primeiro elemento do diagrama. Define o início do fluxo. Um diagrama de atividades pode ter mais de um elemento deste, pois seu início pode ser dar em mais de um “local”.

Final – É o último elemento do diagrama. Define o fim do fluxo. Um diagrama de atividades pode ter mais de um elemento deste também, pois o fim do fluxo pode ocorrer em vários partes do diagrama. O ideal é utilizar o elemento “Flow Final”, mas é um conceito mais avançado.

Fork/Join – Na imagem temos dois destes elementos, um na horizontal e outro na vertical. O objetivo é o mesmo para ambas as formas. O Fork tem como finalidade dividir o fluxo em mais de uma direção, e o Join tem finalidade inversa, ou seja, faz a união de várias direções do fluxo em uma única direção.

Exemplo de Uso

Vejamos abaixo um exemplo do uso do Diagrama de Atividades.

O exemplo é simplório, apenas para fins didáticos. Basicamente, temos referências a dois módulos nas duas Partitions (Cadastro de Cliente e E-mail Marketing), e trata-se de um fluxo do sistema, onde um cliente após ser cadastrado sofre uma avaliação, e dependendo do resultado da avaliação (feita através do software) o fluxo pode tomar caminhos diferentes.

Se todo o fluxo completar-se, antes de encerrar-se, o cliente vai para uma situação de “espera”, onde outro fluxo, por exemplo, tratará o envio de uma nova oferta ao cliente que passou em todas as etapas.

Conclusão

O diagrama de atividades é uma excelente opção para especificação de software, desde que empregado da maneira correta, para os fins adequados.

No início processo de produção de software, por possuir um nível de abstração bem próximo do negócio, este diagrama é ideal para especificações que precisam ser compreendidos por profissionais menos técnicos, e até mesmo usuários.

E ainda, auxilia muito na compreensão do escopo do software, servindo tanto para as disciplinas de análise e de projeto.

Se você gostou do conteúdo deste post, deixe seus comentários, para ajudar outras pessoas a encontrarem este material! 🙂

O que representa o diagrama de atividade?

Como identificar atores caso de uso?

Quais os principais componentes do diagrama de atividade?

Qual é o nome da notação UML para um ator?