Questão de Engenharia de Software — Análise e Projeto Orientado a Objetos — INSTITUTO AOCP 2024
Engenharia de Software›Análise e Projeto Orientado a Objetos
Código
qa631608
Banca
INSTITUTO AOCP
Órgão
MGI
Ano
2024
Cargo
Esp ( )
Você é um especialista em desenvolvimento de software no Ministério da Gestão e da Inovação e será o responsável por desenvolver um sistema de controle de documentos oficiais. O projeto visa modernizar e automatizar o processo de arquivamento e consulta de documentos. Durante a fase de análise orientada a objetos, você precisa identificar e modelar os principais objetos e suas interações.
Considere os seguintes requisitos:
1. O sistema deve permitir que os funcionários registrem documentos, incluindo título, autor e data.
2. Funcionários devem poder consultar e atualizar documentos.
3. Deve ser possível buscar documentos por palavras-chave.
4. Administradores do sistema podem adicionar e remover usuários e documentos.
Com base nos requisitos descritos, qual das seguintes alternativas representa corretamente um diagrama de classes inicial, considerando os conceitos de análise orientada a objetos?
AClasses: Documento, Funcionário, Consulta, Administrador; Relacionamentos: Documento possui Funcionário, Funcionário possui Consulta, Administrador possui Documento.
BClasses: Documento, Funcionário, Consulta; Relacionamentos: Funcionário possui Documento, Documento possui Consulta.
CClasses: Documento, Funcionário, Consulta, Administrador; Relacionamentos: Documento é de Administrador, Funcionário realiza Consulta, Consulta inclui Documento.
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: Modelagem Orientada a Objetos
Gabarito: letra D. A alternativa correta apresenta as classes Documento, Funcionário, Consulta e Administrador, com os relacionamentos mais aderentes aos requisitos: Funcionário consulta Documento, Documento tem Consulta e Administrador gerencia Funcionário. Essa modelagem reflete diretamente as ações descritas no enunciado — funcionários registram, consultam e atualizam documentos; administradores gerenciam usuários e documentos —, sendo a mais completa e coerente com a análise orientada a objetos.
Na análise orientada a objetos, o objetivo é identificar as entidades do domínio do problema (as "coisas" relevantes) e modelá-las como classes, com seus atributos e operações, além dos relacionamentos entre elas. O diagrama de classes é a representação estrutural central da UML, mostrando as classes, seus atributos, métodos e os vínculos (associações, agregações, composições, dependências) que as conectam. A qualidade do modelo depende de quão fielmente ele representa os requisitos funcionais do sistema.
No caso do sistema de controle de documentos, os requisitos mencionam explicitamente:
Funcionários registram documentos (título, autor, data) → classe Documento com atributos e classe Funcionário que o cria.
Funcionários consultam e atualizam documentos → relacionamento de associação entre Funcionário e Documento (consulta/atualização).
Busca por palavras-chave → operação de consulta, que pode ser modelada como um método da classe Documento ou como uma classe Consulta que encapsula a operação de busca.
Administradores adicionam/removem usuários e documentos → classe Administrador com operações de gerenciamento sobre Funcionário e Documento.
A alternativa D captura esses relacionamentos de forma natural: "Funcionário consulta Documento" (associação de uso), "Documento tem Consulta" (composição ou agregação, indicando que as consultas pertencem ao documento) e "Administrador gerencia Funcionário" (associação de administração). Essa modelagem é a mais completa e fiel aos requisitos, pois inclui todas as classes relevantes e os vínculos que expressam as interações descritas.
As demais alternativas apresentam problemas: algumas omitem classes essenciais (como Administrador ou Consulta), outras usam relacionamentos semanticamente incorretos (como "Documento possui Funcionário", invertendo a direção lógica) ou introduzem classes desnecessárias (como Transação). A banca explora justamente a confusão entre os papéis de cada classe e a direção correta dos relacionamentos.
NÃO CAIA NESSA!
A banca tenta confundir o candidato com relacionamentos invertidos ou semanticamente estranhos. Por exemplo, "Documento possui Funcionário" (alternativa A) inverte a lógica: quem possui/registra o documento é o funcionário, não o contrário. Da mesma forma, "Documento é de Administrador" (alternativa C) sugere posse, quando na verdade o administrador apenas gerencia. Fique atento à direção dos verbos: "consulta", "tem", "gerencia" indicam associações claras, enquanto "possui" e "é de" podem induzir a relações de composição ou herança indevidas.
Critério
Alternativa D (correta)
Alternativas A, B, C, E (incorretas)
Classes essenciais
Inclui Documento, Funcionário, Consulta e Administrador — todas exigidas pelos requisitos
Omitem pelo menos uma classe essencial (ex.: B omite Administrador; E omite Consulta) ou incluem classe desnecessária (E: Transação)
Relacionamento Funcionário–Documento
"Funcionário consulta Documento" — direção correta (funcionário age sobre o documento)
A inverte ("Documento possui Funcionário"); B e C usam vínculos vagos ou imprecisos
Relacionamento Documento–Consulta
"Documento tem Consulta" — associação coerente (consultas vinculadas ao documento)
B ("Documento possui Consulta") e C ("Consulta inclui Documento") são semanticamente estranhos ou incompletos
Relacionamento Administrador
"Administrador gerencia Funcionário" — reflete a administração de usuários
A ("Administrador possui Documento") e C ("Documento é de Administrador") sugerem posse indevida; E não modela o papel do administrador corretamente
Fidelidade aos requisitos
Cobre registro, consulta, atualização, busca e administração de forma direta
Apresentam inversões lógicas, abstrações artificiais ou omissões que afastam o modelo do enunciado
Alternativa A — ❌ Incorreta
O erro está nos relacionamentos: "Documento possui Funcionário" inverte a lógica — quem registra o documento é o funcionário, portanto o correto seria "Funcionário possui/registra Documento". Além disso, "Administrador possui Documento" sugere posse direta, quando na verdade o administrador apenas gerencia documentos, não os possui. A classe Consulta também aparece, mas o relacionamento "Funcionário possui Consulta" é vago e não reflete a operação de consulta descrita nos requisitos.
Alternativa B — ❌ Incorreta
Esta alternativa omite a classe Administrador, que é explicitamente mencionada nos requisitos ("Administradores do sistema podem adicionar e remover usuários e documentos"). Além disso, o relacionamento "Documento possui Consulta" é semanticamente estranho: consulta é uma operação realizada por funcionários, não uma propriedade do documento. A modelagem fica incompleta e com vínculos imprecisos.
Alternativa C — ❌ Incorreta
O relacionamento "Documento é de Administrador" é incorreto: o documento não pertence ao administrador, ele é apenas gerenciado por este. A expressão "é de" sugere posse ou composição, o que não condiz com os requisitos. Os demais relacionamentos ("Funcionário realiza Consulta" e "Consulta inclui Documento") são mais razoáveis, mas o vínculo com o administrador está errado, comprometendo a alternativa.
Alternativa D — ✅ Correta ⟵ GABARITO
Esta alternativa apresenta as quatro classes relevantes (Documento, Funcionário, Consulta, Administrador) e relacionamentos coerentes com os requisitos: "Funcionário consulta Documento" (associação de uso), "Documento tem Consulta" (composição/agregação, indicando que as consultas estão vinculadas ao documento) e "Administrador gerencia Funcionário" (associação de administração). Essa modelagem reflete fielmente as ações descritas: funcionários registram/consultam/atualizam documentos, e administradores gerenciam usuários e documentos.
Alternativa E — ❌ Incorreta
A classe Transação é desnecessária e não aparece nos requisitos — não há menção a transações no sistema. Além disso, o relacionamento "Funcionário cria Transação" e "Transação envolve Documento" introduz uma camada de abstração que não é justificada pelo enunciado. A alternativa também omite a classe Consulta, que é relevante para a operação de busca por palavras-chave. A modelagem fica artificial e distante dos requisitos reais.
Conclusão: A alternativa D é a única que modela corretamente as classes e relacionamentos exigidos pelos requisitos, representando de forma fiel as interações entre funcionários, documentos, consultas e administradores.