Questão de Engenharia de Software — Conceitos Básicos em Engenharia de Software — FUNDATEC 2025
Engenharia de Software›Conceitos Básicos em Engenharia de Software
Código
qg484491
Banca
FUNDATEC
Órgão
UFRGS
Ano
2025
Nível
Médio
Cargo
Técnico em Tecnologia da Informação/Área: Sistemas de Informação
Em um sistema bancário online, uma rotina de transferência de fundos realiza três operações sequenciais: verificar saldo, debitar conta de origem e creditar conta de destino. Caso qualquer operação falhe, a transação deve ser completamente revertida, garantindo consistência financeira. Para implementar esse comportamento, o desenvolvedor deve:
AIgnorar erros e registrar apenas mensagens de log.
BInserir verificações manuais de saldo antes de cada operação, sem tratamento de exceção.
CRepetir a operação até que nenhuma exceção ocorra, sem rollback.
DApenas exibir mensagens de erro para o usuário e continuar a execução normal.
EUtilizar blocos de tratamento de exceção (try-catch) e aplicar um mecanismo de rollback ou transação atômica.
Revelar gabarito e comentário▾
GabaritoE — Utilizar blocos de tratamento de exceção (try-catch) e aplicar um mecanismo de rollback ou transação atômica.
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”.
Transações atômicas e tratamento de exceções em sistemas bancários
Gabarito: letra E. Para garantir a consistência financeira em uma sequência de operações (verificar saldo, debitar, creditar), é necessário utilizar blocos de tratamento de exceção (try-catch) combinados com um mecanismo de rollback ou transação atômica. Esse padrão assegura que, se qualquer operação falhar, todas as alterações parciais sejam revertidas, mantendo o estado consistente.
A questão testa o princípio de atomicidade em transações, um conceito fundamental em sistemas críticos. As demais alternativas não implementam a reversão completa e, portanto, não atendem ao requisito.
Alternativa A — ❌ Incorreta
Ignorar erros e apenas registrar logs não reverte as operações já executadas. O saldo poderia ficar inconsistente, violando o requisito de reversão total.
Alternativa B — ❌ Incorreta
Verificações manuais de saldo sem tratamento de exceção não garantem reversão em caso de falha após o débito, por exemplo. O sistema não lidaria com erros inesperados de forma robusta.
Alternativa C — ❌ Incorreta
Repetir a operação sem rollback não desfaz as operações bem-sucedidas. Se a falha persistir, o sistema pode executar parcialmente e depois tentar novamente, acumulando inconsistências.
Alternativa D — ❌ Incorreta
Exibir mensagens de erro e continuar a execução normal não reverte as operações. O sistema prosseguiria com débitos sem créditos, violando a consistência.
Alternativa E — ✅ Correta ⟵ GABARITO
Esta alternativa emprega o padrão correto: tratamento de exceção (try-catch) para capturar falhas e um mecanismo de rollback ou transação atômica para reverter completamente todas as operações se alguma delas falhar. Isso garante a atomicidade e a consistência do estado financeiro.
PEGA ESSA DICA!
Em sistemas que exigem consistência (bancos, reservas, pedidos), sempre pense em transações: ou todas as etapas são concluídas com sucesso, ou nenhuma delas tem efeito permanente. Use try-catch + rollback para implementar esse comportamento.