Questão de Engenharia de Software — UML — FGV 2024
Engenharia de Software›UML
Código
fg101723
Banca
FGV
Órgão
TRF - 1ª REGIÃO
Ano
2024
Nível
Superior
Cargo
Técnico Judiciário - Área Administrativa - Especialidade: Desenvolvimento de Sistemas de Informação
Roberto está utilizando a UML para modelar um sistema de gerenciamento e monitoramento de pedidos. Ele definiu um processo assíncrono, que envolve a tela cliente emitindo os pedidos para um serviço, para o tratamento no servidor, além de uma callback no cliente, exibindo a conclusão do processo.Para modelar o fluxo de execução descrito, Roberto utilizou:
Aum diagrama de atividades iniciado com enviar_pedido, do Cliente, seguido de um fork, que abre para um receive signal de concluído, no Cliente, e ler_pedido, seguido da emissão de concluído, no Servidor, com os fluxos sincronizados por um join, tendo na sequência a exibição da conclusão, no Cliente;
Bum diagrama de sequência com Usuario, Cliente e Serviço, onde Usuario invoca enviar_pedido, de Cliente, este invoca ler_pedido, de Serviço, o qual invoca informar_conclusao, de Cliente, ao final da sequência;
Cum diagrama de estados para o canal de comunicação entre Cliente e Serviço, indicando os estados do protocolo;
Dum diagrama de pacotes, contemplando os artefatos Cliente e Servidor, com as respectivas responsabilidades;
Eum diagrama de classes contendo as classes Cliente e Serviço, no qual o Cliente tem os métodos enviar_pedido e verificar, este segundo com marcação assíncrona, e Serviço tem os métodos ler_pedido e informar_conclusao.
Revelar gabarito e comentário▾
GabaritoA — um diagrama de atividades iniciado com enviar_pedido, do Cliente, seguido de um fork, que abre para um receive signal de concluído, no Cliente, e ler_pedido, seguido da emissão de concluído, no Servidor, com os fluxos sincronizados por um join, tendo na sequência a exibição da conclusão, no Cliente;
Comentário gerado por IA. É um apoio ao estudo, ancorado em fontes, mas pode conter imprecisões — confira sempre na fonte oficial (lei, súmula, edital e gabarito da banca). Encontrou um erro? Use “Reportar”.
UML — Diagrama de Atividades
Gabarito: letra A. O enunciado descreve um processo assíncrono com emissão de pedido, tratamento no servidor e callback no cliente — exatamente o que o diagrama de atividades modela com fork, join e ações de envio/recebimento de sinais. A descrição da alternativa A corresponde a um diagrama de atividades típico.
O diagrama de atividades é o mais indicado para modelar fluxos de trabalho que envolvem concorrência e comunicação assíncrona. Ele possui elementos como fork (bifurcação) para criar fluxos paralelos e join (junção) para sincronizá-los, além de ações de enviar sinal (send signal) e receber sinal (accept event). As demais alternativas propõem diagramas que não capturam adequadamente o fluxo de execução descrito.
Característica
Diagrama de Atividades (A)
Diagrama de Sequência (B)
Diagrama de Estados (C)
Modelagem de fluxo de execução
Sim, com ações, forks e joins
Sim, com mensagens entre objetos
Não, modela estados de um objeto
Representação de concorrência/paralelismo
Sim, através de forks e joins
Sim, com mensagens assíncronas e fragmentos
Não
Comunicação assíncrona explícita
Sim, com ações de enviar/receber sinal
Sim, com setas de mensagem assíncrona
Não
Callback (retorno assíncrono)
Modelado como fluxo paralelo sincronizado por join
Modelado como mensagem de retorno ao final
Não se aplica
Adequação ao cenário descrito
Alta – captura perfeitamente o fluxo com fork, join e sinais
Baixa – descrição linear, sem concorrência explícita
Nenhuma – foco em estados, não em fluxo
Alternativa A — ✅ Correta ⟵ GABARITO
A alternativa descreve corretamente um diagrama de atividades: inicia com "enviar_pedido" (ação do Cliente), seguido de um fork que abre dois fluxos paralelos: um no Cliente (receber sinal de concluído) e outro no Servidor (ler pedido e emitir concluído). Os fluxos são sincronizados por um join, e então o Cliente exibe a conclusão. Essa estrutura modela o processo assíncrono com callback, utilizando os elementos típicos de diagrama de atividades: ação inicial, fork, accept event action (receive signal), send signal action (emitir concluído) e join.
Alternativa B — ❌ Incorreta
Apresenta um diagrama de sequência com invocações lineares e síncronas (Usuário → Cliente → Serviço → Cliente). Na descrição, a callback ocorre ao final da sequência, sem indicar assincronia ou concorrência. Um diagrama de sequência pode modelar chamadas assíncronas, mas a descrição dada é de uma sequência simples, não capturando o fork e a espera paralela que caracterizam o cenário. A banca usa esse distrator: o diagrama de sequência é comum para interações, mas não é o mais adequado para este caso específico.
Alternativa C — ❌ Incorreta
Um diagrama de estados (máquina de estados) modela os estados de um objeto/componente ao longo de seu ciclo de vida, não o fluxo de execução de um processo com várias entidades. O enunciado fala de um processo assíncrono entre cliente e servidor, não dos estados do canal de comunicação.
Alternativa D — ❌ Incorreta
Diagrama de pacotes é estrutural: organiza elementos em pacotes, mostrando dependências. Não serve para modelar fluxo de execução dinâmico.
Alternativa E — ❌ Incorreta
Diagrama de classes é estrutural, mostrando classes, atributos, métodos e relacionamentos. Apesar de mencionar métodos e marcação assíncrona, não modela o fluxo de execução temporal ou o comportamento concorrente.
NÃO CAIA NESSA!
A banca explora o fato de que o diagrama de sequência (alternativa B) também é usado para modelar interações, inclusive assíncronas. No entanto, a descrição da alternativa B apresenta uma sequência linear síncrona, sem fork/join ou sinalização explícita. Já a alternativa A contém todos os elementos que caracterizam um diagrama de atividades voltado para fluxos concorrentes. Fique atento aos detalhes: o enunciado destaca "processo assíncrono" e "callback", que são naturalmente representados por ações de envio e recebimento de sinais e pela sincronização de fluxos paralelos — tudo presente no diagrama de atividades.
PEGA ESSA DICA!
Para identificar qual diagrama UML usar, pense na natureza do que se deseja modelar: fluxo de trabalho com concorrência e sincronização → diagrama de atividades; interações com ordenação temporal de mensagens → diagrama de sequência; estados de um objeto → diagrama de estados; estrutura de classes → diagrama de classes. Memorize os elementos-chave de cada diagrama: fork/join/sinais são exclusivos de diagramas de atividades.