Questão de Engenharia de Software — UML — VUNESP 2024
Engenharia de Software›UML
Código
vu083843
Banca
VUNESP
Órgão
Prefeitura de Mogi das Cruzes - SP
Ano
2024
Nível
Superior
Cargo
Analista de Sistemas
O seguinte diagrama de classes UML representa um trecho da modelagem de um sistema de agenda de contatos.De acordo com esse modelo, uma possível representação de um recurso do tipo Pessoa no formato JSON, utilizado em uma API RESTful, é:
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”.
Diagrama de classes UML e serialização JSON em APIs RESTful
Gabarito: letra A. A alternativa correta representa fielmente o diagrama de classes: a classe Pessoa possui os atributos id e nome, e uma associação com a classe Telefone (que possui ddd e numero), com multiplicidade indicando que uma pessoa pode ter vários telefones. Em JSON, isso se traduz em um array de objetos telefones, cada um com seus próprios campos ddd e numero. As demais alternativas ou ignoram a multiplicidade (tratando telefone como atributo único), ou achatam a estrutura (colocando ddd e numero diretamente em Pessoa), ou violam a sintaxe JSON.
O diagrama de classes UML é a representação estática da estrutura de um sistema: mostra as classes, seus atributos, métodos e os relacionamentos entre elas. Quando esse modelo é usado para definir o formato de dados trafegados em uma API RESTful, a serialização em JSON deve respeitar exatamente essa estrutura. A classe Pessoa tem atributos simples (id, nome) e um relacionamento com Telefone. A multiplicidade desse relacionamento é o ponto-chave: se o diagrama indica 1..* (um para muitos), significa que uma Pessoa pode ter vários Telefone, e o JSON deve refletir isso com um array. Se a multiplicidade fosse 1 (um para um), um objeto único seria suficiente.
Na prática, a serialização de um relacionamento de multiplicidade 1..* em JSON segue o padrão de um array de objetos. Cada elemento do array representa uma instância da classe relacionada, com seus próprios atributos. Isso é o que a alternativa A faz: telefones é um array contendo um objeto com ddd e numero. Essa é a forma mais comum e semanticamente correta de representar uma coleção de objetos em JSON, e é o que a banca espera que o candidato identifique.
A pegadinha desta questão está em confundir a multiplicidade do relacionamento com a estrutura dos atributos. O candidato pode ser tentado a:
Tratar telefone como um atributo simples da classe Pessoa (alternativa B), ignorando que existe uma classe separada Telefone.
Achar que ddd e numero são atributos diretos de Pessoa (alternativas D e E), ignorando a associação.
Representar os telefones como um array de strings (alternativa C), perdendo a estrutura de atributos da classe Telefone.
O critério decisivo é: a estrutura do JSON deve espelhar a estrutura do diagrama de classes, incluindo a multiplicidade e os atributos de cada classe envolvida no relacionamento. É exatamente nesse espelhamento que as alternativas se dividem.
Critério
Alternativa A (✅)
Alternativa B (❌)
Alternativa C (❌)
Alternativa D (❌)
Alternativa E (❌)
Representa Telefone como classe separada?
Sim, array de objetos com ddd e numero
Não, trata como atributo simples de Pessoa
Não, trata como array de strings
Não, achata atributos em Pessoa
Não, achata atributos em Pessoa
Respeita multiplicidade 1..*?
Sim, usa array telefones
Não, usa campo único
Sim, usa array, mas sem estrutura de objeto
Não, usa campos únicos
Não, repete campos sem array
Mantém hierarquia Pessoa → Telefone?
Sim
Não
Parcialmente (array, mas sem objetos)
Não
Não
Sintaxe JSON válida?
Sim
Sim
Sim
Sim
Não (chaves duplicadas)
Alternativa A — ✅ Correta ⟵ GABARITO
Esta alternativa representa corretamente a estrutura do diagrama. A classe Pessoa tem id e nome como atributos. O relacionamento com Telefone (multiplicidade 1..*) é representado como um array telefones, onde cada elemento é um objeto com os atributos ddd e numero da classe Telefone. A sintaxe JSON é válida, com chaves, colchetes e vírgulas corretamente posicionados.
Alternativa B — ❌ Incorreta
Esta alternativa trata telefone como um atributo simples da classe Pessoa, com o valor "(11) 9999-9999". Isso ignora a existência da classe Telefone no diagrama, que possui os atributos ddd e numero. A serialização correta deve refletir a associação entre as classes, não achatar a estrutura em um único campo de texto.
Alternativa C — ❌ Incorreta
Esta alternativa representa telefones como um array de strings, como ["(11) 9999-9999", "(11) 8888-8888"]. Embora capture a multiplicidade (vários telefones), ela perde a estrutura de atributos da classe Telefone (ddd e numero). O JSON deve representar cada telefone como um objeto com seus atributos, não como uma string simples.
Alternativa D — ❌ Incorreta
Esta alternativa coloca ddd e numero como atributos diretos da classe Pessoa, ignorando a associação com a classe Telefone. Isso achata a estrutura do diagrama, que define Telefone como uma classe separada. A serialização correta deve manter a hierarquia: Pessoa contém um array de objetos Telefone.
Alternativa E — ❌ Incorreta
Esta alternativa repete os atributos ddd e numero diretamente na classe Pessoa, o que além de ignorar a associação, viola a sintaxe JSON ao repetir as mesmas chaves (ddd e numero) no mesmo objeto. Em JSON, chaves duplicadas em um mesmo objeto são inválidas ou têm comportamento indefinido. A estrutura correta exige um array de objetos para representar a multiplicidade.
De acordo com esse modelo, uma possível representação de um recurso do tipo Pessoa no formato JSON, utilizado em uma API RESTful, é: