Questão de Engenharia de Software — Gerência de Configuração — FCC 2018
Engenharia de Software›Gerência de Configuração
Código
fc042318
Banca
FCC
Órgão
Câmara Legislativa do Distrito Federal
Ano
2018
Cargo
Analista de Sistemas - Área 2
Para fazer o gerenciamento de configuração de software, as ferramentas de controle de versões normalmente suportam a definição de diferentes políticas de trabalho, como as políticas otimista e pessimista. A política
Aotimista, também denominada inclusive lock, tem como mecanismo o lock reservado, que permite a outro desenvolvedor realizar um commit sobre o arquivo ou item de configuração.
Bpessimista assume que, se um item de configuração for alterado simultaneamente por dois desenvolvedores, a quantidade de conflitos será naturalmente alta, sendo melhor tratar cada conflito individualmente quando ocorrer.
Cotimista, que utiliza o mecanismo merge para unir as modificações efetuadas em paralelo sobre um mesmo item de configuração e produz uma nova versão deste item contendo a soma das modificações.
Dpessimista pode dar origem aos locks, que ocorrem quando um mesmo item de configuração ou arquivo é modificado ao mesmo tempo. O branching é automático na maioria dos casos, mas quando ocorre um lock, este deve ser feito de forma manual.
Epessimista, também denominada update lock, tem como mecanismo o check-in reservado, que permite o paralelismo, mas não permite a outro desenvolvedor realizar um commit sobre o arquivo ou item de configuração.
Revelar gabarito e comentário▾
GabaritoC — otimista, que utiliza o mecanismo merge para unir as modificações efetuadas em paralelo sobre um mesmo item de configuração e produz uma nova versão deste item contendo a soma das modificações.
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”.
Políticas de Controle de Versão (Otimista vs Pessimista)
Gabarito: letra C. A questão cobra o conhecimento das duas principais políticas de controle de versão em sistemas de gerenciamento de configuração: a otimista (baseada em merge, permitindo edição simultânea) e a pessimista (baseada em lock, impedindo edição simultânea). A alternativa C descreve corretamente a política otimista.
Política
Mecanismo Principal
Permite Edição Simultânea?
Tratamento de Conflitos
Nome Alternativo
Otimista
Merge
Sim
Resolvidos após merge
—
Pessimista
Lock (check-in reservado)
Não (impede)
Evitados por lock
Inclusive lock
Políticas de controle de versão
1Otimista
Merge
Edição simultânea
Conflitos resolvidos depois
2Pessimista
Lock
Edição simultânea impedida
Conflitos evitados antes
LEVEL · soulevel.com.br
Análise das Alternativas
Alternativa A — ❌ Incorreta
Afirma que a política otimista é "também denominada inclusive lock" e usa "lock reservado", o que é um equívoco. Na verdade, a política otimista não utiliza locks; ela permite que vários desenvolvedores editem o mesmo arquivo simultaneamente e resolve conflitos posteriormente com merge. O termo "inclusive lock" não é padrão, e "lock reservado" é característica da política pessimista.
Alternativa B — ❌ Incorreta
Descreve a política pessimista afirmando que ela "assume que a quantidade de conflitos será naturalmente alta, sendo melhor tratar cada conflito individualmente". Isso é o oposto: a política pessimista evita conflitos através de locks, enquanto a otimista é que trata conflitos individualmente após ocorrerem. Portanto, a definição está trocada.
Alternativa C — ✅ Correta ⟵ GABARITO
Define corretamente a política otimista: utiliza o mecanismo de merge para unir modificações feitas em paralelo sobre o mesmo item de configuração, produzindo uma nova versão que soma as alterações. É exatamente o princípio: permitir que vários desenvolvedores trabalhem simultaneamente e depois mesclar as mudanças.
Alternativa D — ❌ Incorreta
Afirma que a política pessimista "pode dar origem aos locks, que ocorrem quando um mesmo item é modificado ao mesmo tempo. O branching é automático... mas quando ocorre um lock, este deve ser feito de forma manual." Há vários erros:
Locks não ocorrem como consequência de modificação simultânea; eles são adquiridos previamente para impedir a modificação simultânea.
Branching não é automático; é uma funcionalidade separada.
Em sistemas pessimistas, o lock é adquirido automaticamente no checkout, não manualmente.
Alternativa E — ❌ Incorreta
Descreve a política pessimista como "update lock" com "check-in reservado", que "permite o paralelismo, mas não permite a outro desenvolvedor realizar commit". A política pessimista não permite paralelismo em um mesmo arquivo; quem adquire o lock tem exclusividade. O termo "check-in reservado" não é sinônimo de mecanismo pessimista. A descrição contradiz a essência: se não permite commit de outro, então não há paralelismo.
NÃO CAIA NESSA!
A banca explora a inversão de conceitos entre as políticas otimista e pessimista. As alternativas B e D misturam deliberadamente as características. Lembre-se: otimista = merge (paralelismo); pessimista = lock (exclusão).