Questão de Engenharia de Software — UML — CESPE / CEBRASPE 2025
Engenharia de Software›UML
Código
ce417756
Banca
CESPE / CEBRASPE
Órgão
TRF 6
Ano
2025
Cargo
AJ TRF6
Julgue o item a seguir, relativo à modelagem de processos em UML 2.5. As atividades são essencialmente formas de realizar controle e fluxo de dados; por padrão, tais modelos são inerentemente sequenciais e não simultâneos, uma vez que o sequenciamento da execução do nó de atividade é modelado com ordenação obrigatória.
CCerto
EErrado
Revelar gabarito e comentário▾
GabaritoE — Errado
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”.
Diagrama de Atividades UML: sequencial ou concorrente?
❌ ERRADO. A afirmação está incorreta porque o Diagrama de Atividades da UML não é inerentemente sequencial — ele é uma ferramenta para modelar tanto fluxos sequenciais quanto fluxos concorrentes (paralelos), usando nós de bifurcação (fork) e junção (join). O sequenciamento é apenas uma possibilidade, não uma obrigação, e a própria UML define que atividades podem ter execução paralela. O gabarito oficial é a letra E.
O Diagrama de Atividades é um dos diagramas comportamentais da UML, usado para modelar o fluxo de controle e de dados de um processo, algoritmo ou caso de uso. Ele descreve a sequência de atividades, mas também permite representar decisões (nós de decisão, em losango), bifurcações (nós fork, que dividem o fluxo em múltiplos fluxos paralelos) e junções (nós join, que sincronizam fluxos paralelos). É exatamente essa capacidade de modelar concorrência que o distingue de um simples fluxograma sequencial.
A UML 2.5 define que um nó de atividade pode ter múltiplas arestas de saída, e a execução pode prosseguir em paralelo quando há um fork. Por exemplo, em um processo de compra online, após o pagamento, as atividades "enviar e-mail de confirmação" e "atualizar estoque" podem ocorrer simultaneamente — isso é modelado com um fork. O sequenciamento é modelado por arestas de controle, mas a concorrência é um recurso nativo e essencial do diagrama.
A banca explora aqui uma pegadinha clássica: inverter a natureza do diagrama. O candidato que decora que "atividades são sequenciais" sem entender o papel dos nós de fork e join cai na armadilha. A palavra-chave é "não simultâneos" — isso é falso, pois a UML permite explicitamente a modelagem de fluxos concorrentes.
NÃO CAIA NESSA!
A banca troca a capacidade de modelar concorrência por uma suposta obrigatoriedade de sequenciamento. O Diagrama de Atividades suporta paralelismo via fork e join; ele não é "inerentemente sequencial". Guarde: sequência é uma opção, não uma regra.
Diagrama de Atividades (UML): Fluxo de controle e dados; Sequencial (Arestas de controle, Ordem condicional (decisão)); Concorrente (Fork (bifurcação), Join (junção)); Nós (Atividade, Decisão (losango), Fork/Join)
Item — ❌ ERRADO
A afirmação diz que "as atividades são essencialmente formas de realizar controle e fluxo de dados; por padrão, tais modelos são inerentemente sequenciais e não simultâneos, uma vez que o sequenciamento da execução do nó de atividade é modelado com ordenação obrigatória".
O erro está em dois pontos:
"inerentemente sequenciais e não simultâneos" — falso. O Diagrama de Atividades é projetado para modelar concorrência com nós de fork (bifurcação) e join (junção). Um fork divide um fluxo em vários fluxos paralelos; um join os sincroniza. Isso é recurso nativo da UML.
"sequenciamento ... com ordenação obrigatória" — falso. O sequenciamento é modelado por arestas de controle, mas não é obrigatório que todos os nós sejam executados em ordem estrita; a ordem pode ser condicional (nós de decisão) ou paralela (fork).
O que a afirmação descreve como regra geral é apenas um caso particular. A UML 2.5 define que um nó de atividade pode ter múltiplas arestas de saída e que a execução pode ser concorrente. Portanto, o item está errado.