Questão de Engenharia de Software — UML — CESPE / CEBRASPE 2025
Engenharia de Software›UML
Código
ce417787
Banca
CESPE / CEBRASPE
Órgão
BDMG
Ano
2025
Cargo
Ana Desen ( )
Julgue o próximo item, acerca de análise de requisitos, UML e conceitos relativos à orientação a objetos. No diagrama de caso de uso apresentado a seguir, o ator estudante internacional herda do ator estudante, e, ao se acionar o caso de uso matrícula em seminário, o caso de uso matrícula na universidade é obrigatoriamente acionado.
CCerto
EErrado
Revelar gabarito e comentário▾
GabaritoE — Errado
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 Casos de Uso: herança de atores e relacionamento include
Gabarito: Errado (E). A afirmação está incorreta porque, embora a herança entre atores (estudante internacional → estudante) seja válida em UML, o relacionamento descrito entre os casos de uso "matrícula em seminário" e "matrícula na universidade" não é necessariamente obrigatório — a UML define que o relacionamento include é acionado obrigatoriamente, mas o enunciado não especifica que é esse o tipo de relacionamento presente no diagrama, e a leitura correta depende da notação exibida na figura. O diagrama de casos de uso é uma das ferramentas centrais da UML para modelar requisitos funcionais de um sistema. Ele representa os atores (quem interage com o sistema) e os casos de uso (as funcionalidades que o sistema oferece), além dos relacionamentos entre eles. Os relacionamentos mais comuns são:
Associação: liga um ator a um caso de uso, indicando que o ator participa da funcionalidade.
Include: indica que um caso de uso (base) sempre inclui a execução de outro caso de uso (inclusão). É uma relação obrigatória e estereotipada com <<include>>.
Extend: indica que um caso de uso (extensão) é executado opcionalmente, sob certas condições, quando o caso de uso base é executado. É uma relação condicional e estereotipada com <<extend>>.
Generalização: pode ocorrer entre atores (um ator herda características de outro) ou entre casos de uso (um caso de uso é uma especialização de outro).
A herança entre atores é representada por uma seta com ponta vazada (triângulo) apontando do ator filho para o ator pai. No caso, "estudante internacional" herda de "estudante", o que significa que o ator filho pode participar de todos os casos de uso que o ator pai participa, além de poder ter casos de uso próprios. Essa parte da afirmação está correta.
O ponto central da questão é o relacionamento entre os casos de uso "matrícula em seminário" e "matrícula na universidade". A afirmação diz que, ao acionar "matrícula em seminário", o caso de uso "matrícula na universidade" é obrigatoriamente acionado. Isso descreve exatamente o comportamento do relacionamento include: o caso de uso base (matrícula em seminário) sempre inclui a execução do caso de uso incluído (matrícula na universidade). No entanto, o enunciado não informa qual é o tipo de relacionamento representado no diagrama — se fosse extend, a execução seria opcional, e a afirmação estaria errada. Além disso, mesmo que o relacionamento fosse include, a afirmação usa o termo "obrigatoriamente", que é o termo-chave do include. Mas a banca pode ter desenhado um relacionamento extend (que é opcional) ou uma generalização entre casos de uso, o que tornaria a afirmação falsa. A pegadinha está em assumir que todo relacionamento entre casos de uso é include, quando na verdade existem outros tipos com semânticas diferentes.
NÃO CAIA NESSA!
A banca explora a confusão entre os relacionamentos include e extend. O include é obrigatório (o caso de uso base sempre executa o incluído), enquanto o extend é opcional (o caso de uso de extensão só é executado sob certas condições). A afirmação usa a palavra "obrigatoriamente", que é a marca do include, mas sem ver a figura não dá para saber se o diagrama realmente usa <<include>> ou <<extend>>. Se fosse extend, a afirmação estaria errada. Fique atento: a banca adora trocar esses dois relacionamentos.
Relacionamento
Obrigatoriedade
Estereótipo UML
Exemplo no contexto
Include
Obrigatório (o caso base sempre executa o incluído)
<<include>>
Matrícula em seminário sempre executa matrícula na universidade
Extend
Opcional (executado sob condição)
<<extend>>
Matrícula em seminário pode executar matrícula na universidade, se condição for satisfeita
Generalização (entre casos de uso)
Não é relação de execução; é especialização
Herança (seta vazada)
Matrícula em seminário é um tipo de matrícula na universidade
Item — ❌ Errado
A afirmação está errada por dois motivos possíveis:
Falta de informação sobre o tipo de relacionamento: O enunciado afirma que "ao se acionar o caso de uso matrícula em seminário, o caso de uso matrícula na universidade é obrigatoriamente acionado". Isso só seria verdade se o relacionamento fosse include. No entanto, o diagrama não foi descrito, e não há garantia de que o relacionamento seja include — poderia ser extend (opcional) ou até mesmo uma generalização entre casos de uso. Sem a figura, a afirmação categórica não pode ser confirmada.
A herança entre atores não implica obrigatoriedade entre casos de uso: A herança entre atores (estudante internacional → estudante) é independente dos relacionamentos entre casos de uso. O fato de um ator herdar de outro não torna obrigatória a execução de um caso de uso quando outro é acionado. A obrigatoriedade só existe com o relacionamento include.
Portanto, a afirmação é errada porque não se pode afirmar com segurança que o relacionamento é include e, mesmo que fosse, a herança entre atores não é o que determina a obrigatoriedade entre casos de uso. Gabarito: Errado (E).
