Questão de Arquitetura de Software — Arquitetura de Software — FADENOR 2026
Arquitetura de Software›Arquitetura de Software
Código
qg668714
Banca
FADENOR
Órgão
Prefeitura de Jequitaí - MG
Ano
2026
Nível
Superior
Cargo
Analista em Tecnologia da Informação
No desenvolvimento de software moderno, a aplicação de princípios de design e metodologias ágeis visa aumentar a qualidade e a manutenibilidade do código. Considerando os princípios SOLID e a prática de testes, assinale a alternativa CORRETA sobre a arquitetura de software.
AMetodologias ágeis como o Scrum desencorajam a realização de testes unitários automatizados, priorizando apenas a entrega de funcionalidades visuais ao cliente ao final de cada sprint.
BO Princípio da Responsabilidade Única (SRP) define que uma classe deve ter múltiplos motivos para mudar, permitindo que ela centralize diversas funcionalidades relacionadas para simplificar o acoplamento global.
CO Princípio da Inversão de Dependência (DIP) sugere que módulos de alto nível devem depender diretamente de módulos de baixo nível para garantir que a implementação concreta dite a arquitetura do sistema.
DO Princípio da Substituição de Liskov (LSP) estabelece que subclasses devem ser capazes de substituir suas classes base sem alterar a corretude do sistema, garantindo que as extensões não quebrem o comportamento esperado da abstração.
ETestes de integração possuem como objetivo principal validar a lógica interna de uma única função ou método isolado, sem considerar a comunicação entre diferentes módulos ou bancos de dados.
Revelar gabarito e comentário▾
GabaritoD — O Princípio da Substituição de Liskov (LSP) estabelece que subclasses devem ser capazes de substituir suas classes base sem alterar a corretude do sistema, garantindo que as extensões não quebrem o comportamento esperado da abstração.
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”.
SOLID e Testes de Software: Análise das Alternativas
Gabarito: letra D. O Princípio da Substituição de Liskov (LSP) estabelece que subclasses devem ser capazes de substituir suas classes base sem alterar a corretude do sistema, garantindo que as extensões não quebrem o comportamento esperado da abstração. As demais alternativas distorcem os conceitos de SOLID ou de testes.
Princípios SOLID
1SRP (Responsabilidade Única)
Uma razão para mudar
2OCP (Aberto/Fechado)
Aberto para extensão
Fechado para modificação
3LSP (Substituição de Liskov)
Subclasse substitui base
Sem alterar corretude
4ISP (Segregação de Interfaces)
Interfaces específicas
5DIP (Inversão de Dependência)
Alto nível não depende de baixo nível
Ambos dependem de abstrações
6Testes
Unitário
Função/método isolado
Integração
Interação entre módulos
LEVEL · soulevel.com.br
Alternativa A — ❌ Incorreta
Metodologias ágeis como Scrum incentivam a automação de testes, inclusive unitários, como parte da definição de "pronto" e da integração contínua. A afirmação contradiz a prática ágil.
Alternativa B — ❌ Incorreta
O Princípio da Responsabilidade Única (SRP) diz que "nunca deve haver mais que uma razão para uma classe mudar". A alternativa inverte o princípio, afirmando o oposto.
SOLID (Wikipédia):
Single Responsibility Principle (SRP): "Nunca deve haver mais que uma razão para uma classe mudar."
Alternativa C — ❌ Incorreta
O Princípio da Inversão de Dependência (DIP) preconiza:
Módulos de alto nível não devem depender de módulos de baixo nível. Ambos devem depender de abstrações.
Abstrações não devem depender de detalhes. Detalhes devem depender de abstrações.
A alternativa afirma o contrário, sugerindo dependência direta de alto para baixo nível.
SOLID (Wikipédia):
Dependency Inversion Principle (DIP): "Módulos de alto nível não devem depender de módulos de baixo nível. Ambos devem depender de abstrações." e "Abstrações não devem depender de detalhes. Detalhes devem depender de abstrações."
Alternativa D — ✅ Correta ⟵ GABARITO
O LSP é corretamente descrito: subclasses devem substituir classes base sem alterar a corretude. Isso mantém o polimorfismo e a confiabilidade.
SOLID (Wikipédia):
Liskov Substitution Principle (LSP): "Funções que recebem ponteiros ou referências de classes base devem conseguir operar com objetos de classes derivadas de forma transparente."
Alternativa E — ❌ Incorreta
Testes de integração verificam a interação entre módulos, serviços e bancos de dados. Testes unitários, por sua vez, validam a lógica interna de uma única função ou método isolado. A alternativa troca os conceitos.
Conclusão: A única alternativa que descreve corretamente um princípio SOLID é a D.