Questão de Engenharia de Software — UML — FCC 2025

Orientação a Objetos e UML 2.5: interfaces, polimorfismo e diagramas

Gabarito: letra A. A alternativa A está correta porque o uso de interfaces em componentes reutilizáveis como o Notificador permite polimorfismo — diferentes classes (e-mail, mensagem, log) podem implementar o mesmo contrato —, promove reutilização, facilita testes simulados (mocks) e é perfeitamente representada por diagrama de classes (estrutura) e diagrama de sequência (comportamento), conforme a UML 2.5.

O enunciado descreve um componente reutilizável (Notificador) que envia e-mails, mensagens por aplicativo e registra log de entrega. Em orientação a objetos, a forma mais adequada de modelar esse comportamento é definir uma interface (por exemplo, Notificador) com um método como enviar(), e então criar classes concretas (EmailNotificador, AppNotificador, LogNotificador) que implementam essa interface. Isso permite que o código cliente trate todos os notificadores de forma uniforme, sem conhecer a implementação específica — é o polimorfismo. Além disso, em testes, é possível criar mocks (simulações) da interface para verificar interações sem depender de serviços reais (envio de e-mail, etc.), o que facilita os testes simulados.

A UML 2.5 fornece 13 tipos de diagramas, divididos em estruturais (como o diagrama de classes) e comportamentais (como o diagrama de sequência). O diagrama de classes é adequado para representar a estrutura estática: classes, interfaces, atributos, métodos e relacionamentos (associação, dependência, generalização, realização). O diagrama de sequência é um diagrama de interação que mostra a troca de mensagens entre objetos ao longo do tempo, sendo ideal para validar o comportamento do componente com diferentes eventos judiciais. Portanto, a modelagem com esses dois diagramas reflete corretamente o comportamento OO.

A alternativa B afirma que o diagrama de classes não é adequado para componentes reutilizáveis, o que é falso: o diagrama de classes é justamente o principal diagrama estrutural para representar classes, interfaces e seus relacionamentos, sendo essencial na modelagem de componentes. A alternativa C defende o uso preferencial de herança para todos os tipos de notificadores, mesmo que apenas parte da estrutura seja comum — isso viola o princípio de coesão e reutilização: herança deve ser usada quando há uma relação "é um" real e forte; para comportamentos comuns, a composição ou interfaces são mais adequadas. A alternativa D propõe substituir o diagrama de sequência por um diagrama de estados, mas o diagrama de sequência é exatamente o diagrama de interação que mostra a colaboração entre objetos, sendo relevante em sistemas orientados a eventos. A alternativa E afirma que interfaces devem ser evitadas, o que é contrário aos princípios de OO: interfaces promovem baixo acoplamento, facilitam a extensão e são fundamentais para componentes reutilizáveis.

A pegadinha da banca está em tentar confundir o candidato com conceitos como "herança para maximizar coesão" (quando na verdade herança excessiva reduz coesão) e "diagrama de estados substitui sequência" (quando são diagramas com propósitos distintos). O candidato deve lembrar que interfaces + polimorfismo é a prática recomendada para reutilização e testabilidade.

Alternativa A — ✅ Correta ⟵ GABARITO

A alternativa A está correta porque descreve com precisão os benefícios do uso de interfaces em OO: polimorfismo (diferentes implementações podem ser tratadas uniformemente), reutilização (o componente pode ser usado em diferentes contextos), testes simulados (mocks de interfaces permitem testar sem dependências reais) e a adequação dos diagramas de classe (estrutura) e sequência (comportamento) para modelar o componente. A UML 2.5 define esses diagramas como padrão para representar a estrutura e a interação entre objetos.

Alternativa B — ❌ Incorreta

A alternativa B afirma que o diagrama de classes não é adequado para representar componentes reutilizáveis, sugerindo o uso exclusivo de casos de uso e diagrama de pacote. Isso é falso: o diagrama de classes é o principal diagrama estrutural da UML para representar classes, interfaces, atributos, métodos e relacionamentos, sendo fundamental na modelagem de componentes reutilizáveis. O diagrama de casos de uso é comportamental e foca nas interações entre atores e funcionalidades, não na estrutura interna; o diagrama de pacotes organiza elementos em grupos, mas não substitui o diagrama de classes.

Alternativa C — ❌ Incorreta

A alternativa C defende o uso preferencial de herança para todos os tipos de notificadores, mesmo que apenas parte da estrutura seja comum, pois "maximiza a coesão". Isso é um erro conceitual: herança deve ser usada quando há uma relação "é um" forte e a subclasse realmente é um tipo da superclasse. Quando apenas parte da estrutura é comum, o mais adequado é usar interfaces (para definir contratos) ou composição (para reutilizar comportamentos), pois herança excessiva aumenta o acoplamento e reduz a coesão. A coesão é maximizada quando cada classe tem uma responsabilidade única, não quando se força herança.

Alternativa D — ❌ Incorreta

A alternativa D propõe substituir o diagrama de sequência por um diagrama de estados, alegando que a interação entre objetos não é relevante em sistemas orientados a eventos. Isso é falso: o diagrama de sequência é um diagrama de interação que mostra a troca de mensagens entre objetos ao longo do tempo, sendo essencial para modelar o comportamento de sistemas orientados a eventos. O diagrama de estados modela o ciclo de vida de um objeto (estados e transições), mas não mostra a colaboração entre objetos. Ambos são complementares, não substitutos.

Alternativa E — ❌ Incorreta

A alternativa E afirma que interfaces devem ser evitadas em componentes reutilizáveis, pois aumentam a complexidade e dificultam a extensão. Isso é contrário aos princípios de OO: interfaces definem contratos que promovem baixo acoplamento, facilitam a extensão (novas implementações podem ser adicionadas sem alterar o código cliente) e são fundamentais para reutilização. Sem interfaces, o componente ficaria fortemente acoplado a implementações específicas, dificultando testes e manutenção.

Gabarito: letra A