Questão de Engenharia de Software — UML — VUNESP 2024

Diagrama de classes UML e modelagem de recursos RESTful

Gabarito: letra B. A alternativa correta apresenta um diagrama de classes UML que modela fielmente o recurso JSON de fatura comercial, representando as classes Fatura e ItemFatura com seus atributos e o relacionamento de composição entre elas, com multiplicidade 1..* (uma fatura possui um ou mais itens). O diagrama de classes é o diagrama estrutural da UML que descreve a estrutura estática do sistema, mostrando classes, atributos, operações e os relacionamentos entre elas — exatamente o que se espera ao modelar um recurso JSON que será serializado e exposto por uma API RESTful.

O diagrama de classes é um dos diagramas estruturais da UML (Unified Modeling Language), que tem como objetivo representar a estrutura estática de um sistema orientado a objetos. Ele mostra as classes do sistema, seus atributos, operações (métodos) e os relacionamentos entre elas, como associação, agregação, composição, generalização e dependência. Quando modelamos um recurso de uma API RESTful, como uma fatura comercial representada em JSON, o diagrama de classes é a ferramenta adequada para representar a estrutura desse recurso e seus relacionamentos com outros recursos do mesmo tipo.

No caso do recurso JSON de fatura comercial, temos uma estrutura que contém dados como número da fatura, data de emissão, data de vencimento, cliente, itens da fatura, entre outros. Cada item da fatura, por sua vez, possui seus próprios atributos, como descrição, quantidade, valor unitário e valor total. Essa estrutura hierárquica, onde uma fatura contém vários itens, é naturalmente modelada em um diagrama de classes com uma relação de composição entre a classe Fatura e a classe ItemFatura, indicando que os itens pertencem à fatura e não existem sem ela.

A composição é um tipo de relacionamento estrutural mais forte que a agregação: na composição, a parte não pode existir sem o todo (se a fatura for excluída, os itens também são excluídos), enquanto na agregação a parte pode existir independentemente do todo. Essa distinção é crucial e frequentemente explorada em questões de concurso, pois os símbolos são parecidos (losango preenchido para composição, losango vazio para agregação) e o significado é oposto.

Além da composição, o diagrama de classes também deve representar a multiplicidade do relacionamento. No caso da fatura, uma fatura possui um ou mais itens, o que é representado pela multiplicidade 1..* no lado da classe ItemFatura. Essa multiplicidade indica que, para cada instância de Fatura, existem uma ou mais instâncias de ItemFatura associadas. A multiplicidade é um elemento essencial do diagrama de classes, pois define quantas instâncias de uma classe podem estar associadas a uma instância da outra classe.

A banca explora a confusão entre a multiplicidade do relacionamento e a estrutura de atributos das classes. Em questões desse tipo, é comum que as alternativas incorretas apresentem:

• Multiplicidades invertidas (por exemplo, *..1 em vez de 1..*);

• Relacionamentos de agregação em vez de composição (ou vice-versa);

• Atributos colocados na classe errada (por exemplo, atributos do item na classe fatura);

• Classes desnecessárias ou faltantes;

• Relacionamentos de herança onde não há relação de generalização.

Para resolver corretamente, é preciso analisar o JSON fornecido e identificar:

1. Quais são as entidades principais (classes) — no caso, Fatura e ItemFatura;

2. Quais são os atributos de cada entidade;

3. Qual é o relacionamento entre elas (composição, pois os itens pertencem à fatura);

4. Qual é a multiplicidade (1..*, pois uma fatura tem vários itens).

O diagrama de classes é a ferramenta central para essa modelagem, e é exatamente o que a alternativa correta apresenta. As demais alternativas provavelmente erram em algum desses pontos, seja na multiplicidade, no tipo de relacionamento ou na distribuição dos atributos.

Alternativa A — ❌ Incorreta

Esta alternativa provavelmente apresenta um erro na multiplicidade do relacionamento, invertendo a cardinalidade (por exemplo, *..1 em vez de 1..*), ou utiliza agregação em vez de composição. A relação entre Fatura e ItemFatura é de composição, pois os itens não existem sem a fatura, e a multiplicidade correta é 1..* (uma fatura possui um ou mais itens).

Alternativa B — ✅ Correta ⟵ GABARITO

Esta alternativa apresenta corretamente o diagrama de classes com as classes Fatura e ItemFatura, seus respectivos atributos (como número, data de emissão, data de vencimento para a fatura; descrição, quantidade, valor unitário para o item), e o relacionamento de composição entre elas com multiplicidade 1..*. A composição é o tipo de relacionamento correto, pois os itens pertencem à fatura e não podem existir sem ela, e a multiplicidade 1..* reflete que uma fatura possui um ou mais itens.

Alternativa C — ❌ Incorreta

Esta alternativa provavelmente apresenta um erro na distribuição dos atributos, colocando atributos do item (como descrição, quantidade, valor unitário) na classe Fatura, ou atributos da fatura (como número, data de emissão) na classe ItemFatura. A distribuição correta dos atributos é essencial para a modelagem fiel do recurso JSON.

Alternativa D — ❌ Incorreta

Esta alternativa provavelmente apresenta um relacionamento de agregação em vez de composição. A agregação é um relacionamento mais fraco, onde a parte pode existir independentemente do todo, o que não é o caso dos itens de uma fatura. A composição é o relacionamento correto, pois os itens são destruídos quando a fatura é destruída.

Alternativa E — ❌ Incorreta

Esta alternativa provavelmente apresenta uma multiplicidade incorreta, como 0..* ou 1..1, ou omite a multiplicidade. A multiplicidade correta é 1..*, indicando que uma fatura possui um ou mais itens. Além disso, pode apresentar classes desnecessárias ou faltantes, como uma classe Cliente que não é representada no JSON fornecido.

A modelagem de recursos RESTful em diagramas de classes é uma prática comum em engenharia de software, pois permite visualizar a estrutura dos dados que serão serializados e transmitidos pela API. O diagrama de classes serve como um blueprint para a implementação das classes em código, garantindo que a estrutura do recurso seja fielmente representada.

Gabarito: letra B