Seu próximo nível começa aqui
Seu desenvolvimento não pode ter limites. Garanta sua Assinatura Ilimitada e libere uma preparação completa com os melhores professores do Brasil.
Um Técnico de TI está modelando um subsistema para...
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:
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.
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.
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.
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.
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.