Análise e Projeto de Software

Engenharia de Requisitos
Diagrama de Atividades

Profa. Alessandra Alaniz Macedo

Slides adaptados do Prof. Dr. M. Goulão Ana
Moreira, João Araújo e Vasco Amaral
 ● Diagrama de Atividades
● Representação
● Conceitos Fundamentais
Tópicos ● Organização do Diagrama
de Atividades
● Troca de Informação entre
Atividades
● Sinais
● Casos de Uso e Diagramas
de Sequência
1. Diagrama de Atividades
Diagrama de Atividades
Definição segundo a OMG
An Activity is a kind of Behavior that is specified as a graph of nodes interconnected by edges. A subset of the nodes are
executable nodes that embody lower-level steps in the overall Activity. Object nodes hold data that is input to and output
from executable nodes, and moves across object flow edges. Control nodes specify sequencing of executable nodes via
control flow edges. Activities are essentially what are commonly called “control and data flow” models. Such models of
computation are inherently concurrent, as any sequencing of activity node execution is modeled explicitly by activity edges,
and no ordering is mandated for any computation not explicitly sequenced.

Activities may describe procedural computation, forming hierarchies of Activities invoking other Activities, or, in an object-
oriented model, they may be invoked indirectly as methods bound to Operations that are directly invoked.

Activities may be applied to organizational modeling for business process engineering and workflow. In this context, events
often originate from inside the system, such as the finishing of a task, but also from outside the system, such as a customer
call. Activities can also be used for information system modeling to specify system level processes.

Segundo a OMG (Object Management Group)

Diagrama de Atividades
● Modelam aspectos dinâmicos
● Modelam o fluxo de controle de uma operação,
classe, sistema, subsistema
● Podem ser utilizados para descrever cenários de
casos de uso
● Enfatizam o fluxo de controle por meio de
mensagens entre objetos
Diagrama de Atividades
Descrevem um processo consistindo de:
● Ações e atividades
● Fluxo de controle
● Objetos de I/O
● Decisões
● Concorrências
● etc
2. Representação
Representação
Atividades
● São representadas como redes de nós ligadas por
arestas
● Categorias de nós:
○ Nós de ação: unidade discreta de trabalho, atômica no
contexto de atividade
○ Nós de controle: controlam o fluxo na atividade
○ Nós de objeto: representam os objetos nas atividades
Representação
Atividades
● São representadas como redes de nós ligadas por
arestas
● Categorias de arestas:
○ Fluxo de controle: representa o fluxo de controle na
atividade
○ Fluxo de objetos: representa o fluxo de objetos nas
atividades
 Representação
Exemplo
Nó inicial Nó de ação Nó final
Fluxo

Escrever Endereçar Enviar

carta carta carta
Pré e pós
<<local precondition>> <<local postcondition>>
endereço conhecido carta endereçada condições da
atividade
 Representação
Semântica das atividades
Tokens
● Representam o controle, objetos ou dados
● Deslocam-se do nó inicial (origem) para o nó final (destino), por meio de
aresta de fluxo
● Apenas se deslocam quando TODAS as condições são satisfeitas

Escrever Endereçar Enviar

token carta carta carta
3. Conceitos Fundamentais
Conceitos Fundamentais
Atividades e Ações
● Uma atividade corresponde a execução de um
conjunto de ações
● Uma ação é um evento ou operação atômica, no
contexto de uma atividade
Conceitos Fundamentais
Um diagrama de atividades contém
● Estados de ação
● Estados de atividade
● Transições
● Objetos
● Decisões (branching)
● Disjunção (fork) e junção (join)
● Pistas (swimlanes)
Conceitos Fundamentais
Estados de Ação
● São estados do sistema representando a execução
de uma ação:
○ Exemplo: criar ou destruir um objeto, executar uma
operação em um objeto
● São atômicos
○ Não podem ser decompostos
○ Não podem ser interrompidos
Conceitos Fundamentais
Estados de Ação
● O tempo de execução de um estado de ação é
considerado insignificante

Escrever
Criar conta
carta

Calcular Gerar
total documento
Conceitos Fundamentais
Estados de Atividade
● Podem ser decompostos; onde se usa uma atividade
pode usar-se outro diagrama de atividades
● Não sendo atômicos, podem ser interrompidas (tem
tempo (significativo) de execução)
Conceitos Fundamentais
Estados de Atividade
● A notação é semelhante a do estado de ação
usando-se uma notação especial para indicar a
existência do respectivo diagrama de atividades

Gerar
documento
Conceitos Fundamentais
Estados de Atividade
Escrever Endereçar carta: Enviar
carta Enderaçar carta carta

<<local precondition>> <<local postcondition>>

endereço conhecido carta endereçada

Endereçar carta
Escrever Escrever Escrever
nome endereço CEP
Conceitos Fundamentais
Transições e Decisões
● Transições: quando a ação ou atividade de um estado se
completa, o fluxo de controle passa imediatamente para
o próximo estado de ação ou atividade
● Decisões (branching): expressões booleanas que
especificam passos alternativos
○ Uma decisão consiste em uma transição de entrada e duas ou
mais saídas
Conceitos Fundamentais
Transições e Decisões
● Condições: Nas transições de saída, as condições
não se devem sobrepor, mas devem cobrir todas as
possibilidades
Conceitos Fundamentais
Transições e Decisões

Receber e-
mail
else [lixo]

Apagar e-
Ler e-mail
mail
 Conceitos Fundamentais
Transições e Decisões
Decisão
Transições (branching)
Receber e-
mail
Palavra Condição
else [lixo]
reservada de guarda

Apagar e-
Ler e-mail
mail

Fusão
(merge)
Exercício
Diagrama de Atividades
Exercícios (sem entrega)
● Faça um diagrama de atividades para compra online
na internet
 Diagrama de Atividades
Exercícios (sem entrega)
Compra online
carrinho pode ser checado
a qualquer momento
Procurar [achou] Checar
item carrinho
[não achou] Adicionar
Ver item
ao carrinho
Ver itens
da loja

Ver Atualizar
carrinho carrinho

Finalizar
compra
 Conceitos Fundamentais
Nós de Objeto

Todas as encomendas

<<selection>>
encomenda: Encomenda encomenda.mes = “Março”

Apenas encomendas
de março
 Conceitos Fundamentais
Objetos como Parâmetros

Output

Input

Pre/pos conditions
Conceitos Fundamentais
Disjunção (fork) e Junção (join)
● Uma disjunção/difusão representa a separação de um fluxo de
controle em dois ou mais fluxos
○ Pode ter uma transição de entrada e duas ou mais transições de saída
● Uma junção representa a sincronização de dois ou mais fluxos
de controle
○ Pode ter 2 ou + transições de entrada e uma de saída
○ Os fluxos concorrentes sincronizam-se assim: espera-se que todos os
fluxos de entrada cheguem ao ponto de junção prosseguindo com
apenas um fluxo depois da junção
Conceitos Fundamentais
Exemplo fork e join
Conceitos Fundamentais
Exemplo fork e join
Conceitos Fundamentais
Concorrência Independente

Trace: A, {(B,C) || (X,Y)}, Z

Onde “||” é o operador de concorrência, usado nas linguagens de

especificação algébrica, por exemplo
Conceitos Fundamentais
Fluxo de Objeto (Object Flow)
● Final Flow: é um nó de controle que termina um fluxo
sem efeito nos outros fluxos

● Final Activity: é um nó de controle que para todos os

fluxos do diagrama (pode haver mais de um em um
diagrama)
Conceitos Fundamentais
Fluxo de Objeto (Object Flow)

Final do
fluxo
[falha no pagamento]

Final da
atividade
 Conceitos Fundamentais
Final de Fluxo (Exemplo)
● Neste exemplo, uma empresa pode construir e instalar muitos componentes. A
atividade Construir componente é executada iterativamente para cada componente.
Quando o último componente é construído, finaliza-se a iteração de construção,
indicado com um nó Final Flow. No entanto, mesmo que toda a construção de
componentes tenha chegado ao fim, outros nós ainda estão em execução (como
Instalar componente).
 Conceitos Fundamentais
Final de Fluxo e Atividade (Exemplo 2)
● O exemplo 2 ilustra os dois tipos de Nó de fim: Final Flow e Final Activity.
Este exemplo continua o anterior. No modelo estendido, quando o último
componente for instalado, a aplicação é entregue. Quando a entrega da
aplicação é concluída, o controle é passado para um Final Activity -
indicando que todos o processos da Atividade acabaram.
Conceitos Fundamentais
Resumo
● Inicio
● Atividades
● Fork
● Join
● Decisão
● Fusão
● Fim
Conceitos Fundamentais
Resumo
● Nó inicial
○ Começo de fluxo
● Nó final
○ Fim de atividade
● Nó final de fluxo
○ Fim de fluxo sem afetar os fluxos restantes da atividade
● Nó de decisão
○ O fluxo de saída cuja condição verdadeira é atravessada
○ Pode ter, opcionalmente um <<decisionInput>> que permita escolher o
fluxo de saída adequado
● Nó de fusão
○ Copia os tokens de input para o fluxo de output
● Nó de disjunção (fork)
○ Separa o fluxo de entrada em vários fluxos de saída concorrentes
● Nó de junção (join)
○ Sincroniza vários fluxos concorrentes
○ Pode opcionalmente ter uma especificação de junção para modificar a sua
semântica
4. Organização do Diagrama
de Atividades
Organização do Diagrama de Atividades
Pistas (swimlanes)
● Utilizadas para particionar os estados de atividade em
grupos, quando se modela workflows, business process e
processos de software
● Cada swimlane pode ser implementada por uma ou mais
classes
● Transições podem partir de uma swimlane para outra,
mas uma atividade pertence apenas a uma swimlane
Exemplo: Pistas (swimlanes)
Exemplo: Pistas (swimlanes)
Exemplo: Pistas (swimlanes)
Notações de Partições de Atividades
5. Troca de Informação entre
Atividades
Troca de Informação entre Atividades
Fluxo de Objeto (Object Flow)
● Objetos podem estar envolvidos no fluxo de controle associado com um
diagrama de atividade
○ Os fluxos de objeto são dependências que criam, removem ou alteram um objeto
○ Pode-se mostrar o estado ou valores dos atributos do objeto
6. Sinais
● Envio de Sinais
● Aceitação de Eventos
● Aceitação de Eventos
Temporais
Sinais
Envio de Sinais
● send signal: ação de invocação que cria um sinal e o envia
ao objeto destino, onde pode originar a execução de uma
atividade ou a transição de um estado

Depois de Enviar pedido, cria-

se o sinal Notificar cliente
Sinais
Envio de Sinais
● O sinal é enviado de forma assíncrona
● Quem envia não fica esperando uma resposta, ou confirmação
de recepção de sinal
● O sinal pode aceitar parâmetros de entrada na sua criação
Sinais
Aceitação de Eventos
● accept signal: é uma ação que espera que o evento
especificado ocorra (normalmente assíncrona)

A aceitação do evento Aceitar pedido

causa a invocação Enviar pedido
Sinais
Envio de Sinal/Aceitação de Evento
Send/Accept signal:
● A atividade Receber pedido origina o envio do sinal Requerer
pagamento
● A atividade Enviar produto espera para receber o sinal
Pagamento confirmado
Exemplo
Validação de cartões
Exemplo com regiões Região de
interrupção Atividade de
interrupção
Sinais
Exemplos Temporais (repetitivos)
Wait time action:
● Ao final do mês ativa-se a atividade Relatório de
leitura do sensor
Sinais
Conector
● Usado para evitar transição comprida
● Não afeta o modelo
Sinais
Conector - exemplo
Estilo de Utilização
Um bom diagrama de atividades
● Comunica um aspecto da dinâmica do sistema em particular
● Mostra apenas os elementos que são essenciais para
compreender esse aspecto
● Oferece apenas o nível de detalhe essencial para ser
compreendido
● Não é excessivamente minimalista, para evitar “desinformar” o
leitor sobre a semântica da atividade
Algumas sugestões:
● Dê ao diagrama um nome que comunique bem o seu
propósito
● Comece modelando o propósito principal do diagrama
● Disponha os elementos de forma a minimizar as linhas
cruzadas, quando possível
● Garanta a consistência com os restantes diagramas e
outros elementos do seu modelo
7. Casos de Uso e Diagramas
de Sequência
Casos de Uso e Diagramas de Sequência
Exemplo – Parte de um diagrama de caso de uso

<<inherits>> <<inherits>>
Caso de uso: Encontrar produto

Descrição: O comprador procura e visualiza o estado de uma encomenda no sistema

Ator principal: Comprador

Atores secundários: Nenhum

Pré-condições: Nenhuma

1. O caso de uso começa quando o comprador seleciona a opção encontrar produto.

2. O sistema pede ao comprador para indicar o critério de pesquisa a usar
3. O comprador introduz os critérios de pesquisa
4. O sistema procura produtos que satisfazem os critérios de pesquisa do comprador.
Fluxo principal:
5. Se o sistema encontra produtos que satisfazem os critérios:
1. O sistema apresenta uma lista de produtos que satisfazem os critérios
6. Caso contrário:
1. O sistema indica ao comprador que nenhum produto foi encontrado

Pós-condições: Nenhuma

Fluxos alternativos: Nenhum

Caso de uso: Encontrar livro

Descrição: O comprador procura e visualiza o estado de uma encomenda no sistema

Ator principal: Comprador

Atores secundários: Nenhum

Pré-condições: Nenhuma

1. (o1.) O caso de uso começa quando o comprador seleciona a opção encontrar livro
2. (o2.) O sistema pede ao comprador para indicar um critério de pesquisa do livro, dentre autor, título, ISBN ou
tópico
3. O comprador introduz os critérios de pesquisa
4. (o4.) O sistema procura livros que satisfazem os critérios de pesquisa do comprador.
5. (o5.) Se o sistema encontra livros que satisfazem os critérios:
1. O sistema mostra o best seller
Fluxo principal:
2. (o5.1.) O sistema apresenta uma lista com até 5 livros que satisfazem os critérios
3. Para cada livro, o sistema mostra o título, autor, preço e ISBN
4. Enquanto houver mais livros para mostrar, o sistema oferece ao comprador a opção de pedir a próxima
página com mais livros
6. Caso contrário:
1. O sistema mostra o best seller
2. (6.1) O sistema indica ao comprador que nenhum produto foi encontrado

Pós-condições: Nenhuma

Fluxos alternativos: Nenhum

Diagrama de Atividades: encontrar livro
Exercício
Diagrama de Atividades
Exercícios (em dupla)
● Faça um diagrama de atividades para o sistema de
matrícula simplificado das últimas aulas
● Faça um diagrama de atividades para o
agendamento ao vivo de consultas médicas
MATERIAL EXTRA
Tutoriais e Documentos
● Vídeo curto (em inglês) explicando todos os
símbolos usados: All About UML Activity Diagrams -
Canal SmartDraw (5 min)
○ https://youtu.be/Wf_xlagfHmg

● Documento de especificação UML

○ https://www.omg.org/spec/UML/2.5.1/PDF
Ferramentas
● Lucidchart: Editor online de diagramas (com modelos
UML, inclusive Diagrama de Atividades)
○ https://www.lucidchart.com
Análise e Projeto de Software
Engenharia de Requisitos
Análise de Requisitos: Diagrama de
Atividades
Profa. Alessandra Alaniz Macedo
Slides adaptados do Prof. Dr. M. Goulão Ana
Moreira, João Araújo e Vasco Amaral