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: Audiência: Possui id, dataHora, salaVirtual, status (Agendada, EmAndamento, Finalizada, Cancelada). Participante: Uma interface genérica que define o comportamento participar(). Magistrado: Um tipo de participante com atributos como nome, cpf, vara. Implementa participar() para ingressar na sala virtual com suas credenciais. Advogado: Outro tipo de participante com atributos como nome, oab, processo. Implementa participar() para ingressar na sala virtual associada ao seu processo. 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). 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:

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.

criar Participante como uma classe base com um método virtual participar(). Fazer com que Magistrado, Advogado e Servidor herdem de Participante e sobrescrevam 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.

modelar Magistrado, Advogado e Servidor como classes independentes, cada uma com seu próprio método participar(). Criar associações separadas entre Audiência e cada um desses 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.

utilizar 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.

definir 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.

Questão 2979434 de Tecnologia da Informação - FCC 2025

Questão

ID 2979434

Disciplina: Tecnologia da Informação

Assunto: Diagramas Estruturais

Ano: 2025 Banca: FCC - Fundação Carlos Chagas Órgão: Tribunal Regional do Trabalho da 2ª Região

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:

Audiência: Possui id, dataHora, salaVirtual, status (Agendada, EmAndamento, Finalizada, Cancelada).
Participante: Uma interface genérica que define o comportamento participar().
Magistrado: Um tipo de participante com atributos como nome, cpf, vara. Implementa participar() para ingressar na sala virtual com suas credenciais.
Advogado: Outro tipo de participante com atributos como nome, oab, processo. Implementa participar() para ingressar na sala virtual associada ao seu processo.
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).
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:

Alternativa A:
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.
Alternativa B:
criar Participante como uma classe base com um método virtual participar(). Fazer com que Magistrado, Advogado e Servidor herdem de Participante e sobrescrevam 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.
Alternativa C:
modelar Magistrado, Advogado e Servidor como classes independentes, cada uma com seu próprio método participar(). Criar associações separadas entre Audiência e cada um desses 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.
Alternativa D:
utilizar 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.
Alternativa E:
definir 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.

Estatísticas Cadernos

Questão 2979434

Continue estudando na plataforma