Questão de Engenharia de Software — Análise e Projeto Orientado a Objetos — FCC 2025
Engenharia de Software›Análise e Projeto Orientado a Objetos
Código
fc150567
Banca
FCC
Órgão
TRT 2
Ano
2025
Cargo
TJ TRT2
Um Técnico de TI está modelando um subsistema para agendamento e realização de audiências telepresenciais em um Tribunal Regional do Trabalho. Durante a análise de requisitos, foram identificadas as seguintes entidades e comportamentos: \blacksquare Audiência: Possui id, dataHora, salaVirtual, status (Agendada, EmAndamento, Finalizada, Cancelada). \blacksquare Participante: Uma interface genérica que define o comportamento participar(). \blacksquare Magistrado: Um tipo de participante com atributos como nome, cpf, vara. Implementa participar() para ingressar na sala virtual com suas credenciais. \blacksquare Advogado: Outro tipo de participante com atributos como nome, oab, processo. Implementa participar() para ingressar na sala virtual associada ao seu processo. \blacksquare Servidor: Um tipo de participante com atributos como nome, matricula, funcao. Implementa participar() para gerenciar a sessão da sala virtual (iniciar, encerrar, controlar participantes). \blacksquare Ata: Registra os eventos da audiência, associada a uma única Audiência. Considerando os princípios de orientação a objetos e a modelagem UML 2.5, a representação e aplicação desses conceitos mais adequadas nesse cenário são:
Autilizar apenas classes concretas (Magistrado, Advogado, Servidor, Audiência, Ata) sem interfaces ou herança. Definir métodos participarMagistrado(), participarAdvogado() e participarServidor() diretamente na classe Audiência. Utilizar associações simples entre as classes. Não utilizar pacotes para simplificar o diagrama.
Bdefinir Participante como uma classe concreta com uma implementação padrão vazia para participar(). Fazer com que Magistrado, Advogado e Servidor herdem de Participante e sobrecarreguem o método participar() com diferentes assinaturas (ex: participar(Magistrado m), participar(Advogado a)). Utilizar uma associação de dependência entre Audiência e Participante. Organizar as classes em pacotes físicos correspondentes às pastas do projeto.
Cdefinir Participante como uma interface com o método abstrato participar(). Criar classes Magistrado, Advogado e Servidor que implementam a interface Participante, sobrescrevendo o método participar() com comportamentos específicos para cada tipo. Utilizar uma associação entre Audiência e múltiplos Participantes. Representar a relação entre Audiência e Ata como uma associação de agregação (um para um). Organizar as classes em pacotes lógicos como agendamento, participantes e registro.
Dcriar Participante como uma classe base com um método virtual participar(). Fazer com que Magistrado, Advogado e Servidorherdem de Participante e sobreescrevam o método participar(). Utilizar uma associação de composição (um para muitos) entre Audiência e Participante para indicar que os participantes são criados e destruídos com a audiência. Não utilizar pacotes para manter o diagrama de classes em uma única visão.
Emodelar Magistrado, Advogado e Servidor como classes independentes, cada uma com seu próprio método participar(). Criar associações separadas entre Audiência e os diferentes tipos de participante (um para muitos). Utilizar herança para relacionar Audiência e Ata (Ata herda de Audiência para compartilhar seus atributos). Organizar as classes em um único pacote.
Revelar gabarito e comentário▾
GabaritoC — definir Participante como uma interface com o método abstrato participar(). Criar classes Magistrado, Advogado e Servidor que implementam a interface Participante, sobrescrevendo o método participar() com comportamentos específicos para cada tipo. Utilizar uma associação entre Audiência e múltiplos Participantes. Representar a relação entre Audiência e Ata como uma associação de agregação (um para um). Organizar as classes em pacotes lógicos como agendamento, participantes e registro.
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”.
Modelagem UML 2.5: Interfaces, Herança e Relacionamentos
Gabarito: letra C. A modelagem mais adequada define Participante como uma interface com o método abstrato participar(), implementada pelas classes concretas Magistrado, Advogado e Servidor, cada uma sobrescrevendo o método com seu comportamento específico. Isso aplica corretamente os princípios de polimorfismo e abstração da orientação a objetos, e a relação entre Audiência e Ata como agregação 1 para 1 reflete que a ata registra os eventos de uma única audiência, mas pode existir independentemente dela.
O cenário descreve um subsistema com entidades que compartilham um comportamento comum (participar()), mas com implementações distintas. O princípio de orientação a objetos que melhor captura essa situação é o polimorfismo por interface: define-se um contrato (Participante) e cada classe concreta fornece sua própria implementação. Isso permite que o sistema trate Magistrado, Advogado e Servidor de forma uniforme (como Participante), sem precisar conhecer o tipo específico em tempo de compilação — o que facilita a extensão (novos tipos de participante podem ser adicionados sem alterar o código existente, respeitando o princípio aberto-fechado).
A alternativa C também acerta ao representar a relação entre Audiência e Participante como uma associação (um para muitos), pois os participantes não são propriedade exclusiva da audiência — eles existem independentemente e podem participar de outras audiências. Já a relação entre Audiência e Ata é modelada como agregação (um para um): a ata está associada a uma única audiência, mas pode ser arquivada ou consultada mesmo após a audiência ser encerrada, ou seja, a ata não é destruída quando a audiência é destruída (o que caracterizaria composição).
A organização em pacotes lógicos (agendamento, participantes, registro) também é uma boa prática de modelagem, pois agrupa classes por responsabilidade e melhora a manutenibilidade do diagrama. As demais alternativas apresentam erros conceituais: usar classes concretas sem interface (A), sobrecarga em vez de sobrescrita (B), composição indevida (D) e herança incorreta entre Audiência e Ata (E).
O ponto central que separa as alternativas é a distinção entre interface e classe abstrata, e entre agregação e composição. Guarde esses critérios: interface define um contrato sem implementação; classe abstrata pode ter implementação parcial. Agregação indica relação "todo-parte" com ciclo de vida independente; composição indica ciclo de vida dependente (a parte não existe sem o todo).
❌ Ausente (sobrecarga exige conhecer tipo em compilação)
Alternativa A — ❌ Incorreta
Esta alternativa propõe eliminar interfaces e herança, definindo métodos específicos (participarMagistrado(), participarAdvogado(), participarServidor()) diretamente na classe Audiência. Isso viola o princípio do aberto-fechado (OCP): qualquer novo tipo de participante exigiria modificar a classe Audiência. Além disso, ignora o polimorfismo, que é essencial para tratar os diferentes participantes de forma uniforme. A ausência de pacotes também é uma má prática de organização.
Alternativa B — ❌ Incorreta
O erro central está em usar sobrecarga (diferentes assinaturas: participar(Magistrado m), participar(Advogado a)) em vez de sobrescrita (mesma assinatura, implementações diferentes). A sobrecarga não aproveita o polimorfismo — o código que chama participar() precisaria conhecer o tipo específico em tempo de compilação. Além disso, definir Participante como classe concreta com método vazio é menos flexível que uma interface. A associação de dependência entre Audiência e Participante também é fraca demais: dependência indica uso temporário, não uma relação estrutural duradoura.
Alternativa C — ✅ Correta ⟵ GABARITO
Esta alternativa aplica corretamente os princípios de orientação a objetos:
Interface Participante com método abstrato participar() — define o contrato.
Classes concretas (Magistrado, Advogado, Servidor) que implementam a interface e sobrescrevem o método com comportamentos específicos — polimorfismo.
Associação entre Audiência e múltiplos Participantes (1..*) — relação estrutural correta.
Agregação 1:1 entre Audiência e Ata — a ata registra os eventos, mas tem ciclo de vida independente.
O erro está na composição (1..*) entre Audiência e Participante. Composição implica que os participantes são criados e destruídos com a audiência, o que não é verdade no cenário: magistrados, advogados e servidores existem independentemente e podem participar de várias audiências. A relação correta é associação (como na alternativa C). Além disso, usar classe base com método virtual é aceitável, mas a interface é mais adequada quando não há implementação compartilhada.
Alternativa E — ❌ Incorreta
O erro mais grave é usar herança para relacionar Audiência e Ata (Ata herda de Audiência). Isso é semanticamente incorreto: uma ata não é um tipo de audiência; ela apenas registra eventos de uma audiência. A relação correta é de associação/agregação, não de herança. Além disso, modelar as classes como independentes, sem interface ou herança, perde o polimorfismo, e criar associações separadas para cada tipo de participante torna o diagrama menos flexível.
NÃO CAIA NESSA!
A banca explora a confusão entre agregação e composição. Na composição, a parte é destruída com o todo (ciclo de vida dependente); na agregação, a parte sobrevive ao todo. No cenário, os participantes não são destruídos com a audiência — eles existem antes e depois dela. Por isso, a relação é de associação (ou, no máximo, agregação), nunca composição. A alternativa D tenta induzir ao erro ao usar composição com cardinalidade 1..*.
PEGA ESSA DICA!
Para distinguir agregação de composição, pergunte: "se o todo for destruído, a parte também é?" Se sim, é composição (losango preenchido); se não, é agregação (losango vazio). E para distinguir interface de classe abstrata: interface define apenas o contrato (métodos abstratos); classe abstrata pode ter implementação parcial e atributos. Na prova, quando o enunciado diz "interface genérica que define o comportamento", a resposta quase sempre é interface.