Questão de Engenharia de Software — UML — FUNDATEC 2025
Engenharia de Software›UML
Código
qg484497
Banca
FUNDATEC
Órgão
UFRGS
Ano
2025
Nível
Médio
Cargo
Técnico em Tecnologia da Informação/Área: Sistemas de Informação
Um analista está modelando um sistema de biblioteca usando um Diagrama de Casos de Uso em UML. O analista identificou as seguintes funcionalidades:1. “Fazer Login”: Deve ser executada obrigatoriamente antes de qualquer outra funcionalidade do sistema.2. “Reservar Livro”: Esta funcionalidade possui um comportamento alternativo e opcional: se o livro estiver em situação de atraso, o usuário será notificado sobre a penalidade antes que a reserva seja concluída.Qual é a correta representação UML para as interações entre os casos de uso “Fazer Login”, “Reservar Livro” e “Notificar Penalidade”?
AUma relação de Extensão (<>) de "Reservar Livro" para "Fazer Login" e uma relação de Inclusão (≪include≫) de "Reservar Livro" para "Notificar Penalidade".
BUma relação de Inclusão (<>) de "Reservar Livro" para "Fazer Login" e uma relação de Extensão (<>) de "Reservar Livro" para "Notificar Penalidade".
CUma relação de Generalização (Herança) de "Reservar Livro" para "Fazer Login" e uma relação de Inclusão (≪include≫) de "Reservar Livro" para "Notificar Penalidade".
DUma relação de Inclusão (<>) de "Fazer Login" para "Reservar Livro" e uma relação de Extensão (<>) de "Reservar Livro" para "Notificar Penalidade".
EUma relação de Extensão (<>) de "Fazer Login" para "Reservar Livro" e uma relação de Inclusão (<>) de "Notificar Penalidade" para "Reservar Livro".
Revelar gabarito e comentário▾
GabaritoB — Uma relação de Inclusão (<>) de "Reservar Livro" para "Fazer Login" e uma relação de Extensão (<>) de "Reservar Livro" para "Notificar Penalidade".
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 – Relacionamentos include e extend
Gabarito: letra B. A funcionalidade “Fazer Login” deve ser executada obrigatoriamente antes de qualquer outra, portanto “Reservar Livro” a inclui (relação <<include>>). Já “Notificar Penalidade” é um comportamento opcional que pode ocorrer quando o livro está atrasado, caracterizando uma extensão (<<extend>>) de “Reservar Livro”. A alternativa B é a única que combina corretamente esses dois relacionamentos, ainda que a direção da seta de extensão (de “Reservar Livro” para “Notificar Penalidade”) seja uma representação aceita em muitas provas, embora a UML 2.5 padronize o sentido inverso.
No diagrama de casos de uso UML, dois dos principais relacionamentos são:
<<include>>: Um caso de uso base sempre inclui o comportamento de outro caso de uso. A seta parte do caso base para o incluído. Exemplo: “Reservar Livro” sempre depende de “Fazer Login”, logo “Reservar Livro” <<include>> “Fazer Login”.
<<extend>>: Um caso de uso de extensão adiciona comportamento opcional a um caso de uso base, sob certas condições. A seta, na especificação oficial, parte do caso de extensão para o base. Exemplo: “Notificar Penalidade” estende “Reservar Livro” quando o livro está atrasado.
Alternativas
Relacionamento
Caso Base
Caso Incluído/Extensão
Direção da Seta (na alternativa)
Correto?
<<include>>
Reservar Livro
Fazer Login
Reservar Livro → Fazer Login
✅ Sim
<<extend>>
Reservar Livro
Notificar Penalidade
Reservar Livro → Notificar Penalidade
⚠️ Direção invertida (padrão UML: Notificar Penalidade → Reservar Livro), mas aceita pela banca
1Reservar LivroCaso base
2<<include>> Fazer LoginObrigatório
3<<extend>> Notificar PenalidadeOpcional
LEVEL · soulevel.com.br
Alternativa A — ❌ Incorreta
Troca os relacionamentos: coloca <<extend>> de “Reservar Livro” para “Fazer Login” (o correto é <<include>>) e <<include>> de “Reservar Livro” para “Notificar Penalidade” (deveria ser <<extend>>).
Alternativa B — ✅ Correta ⟵ GABARITO
Apresenta <<include>> de “Reservar Livro” para “Fazer Login” (correto) e <<extend>> de “Reservar Livro” para “Notificar Penalidade”. Embora a direção da seta de extensão esteja invertida em relação ao padrão UML 2.5, a banca considerou essa representação como válida, sendo a única alternativa que associa corretamente os tipos de relacionamento.
Alternativa C — ❌ Incorreta
Usa generalização (herança) entre “Reservar Livro” e “Fazer Login”, o que não se aplica, pois não há relação de especialização. Mantém <<include>> de “Reservar Livro” para “Notificar Penalidade”, que deveria ser <<extend>>.
Alternativa D — ❌ Incorreta
Inverte o sentido do <<include>>: coloca “Fazer Login” incluindo “Reservar Livro” (o correto é o contrário). A extensão também está com direção errada.
Alternativa E — ❌ Incorreta
Atribui <<extend>> de “Fazer Login” para “Reservar Livro” (não há relação opcional) e <<include>> de “Notificar Penalidade” para “Reservar Livro” (inverte o sentido).
NÃO CAIA NESSA!
A banca explora a confusão entre as direções das setas de <<include>> e <<extend>>. Lembre-se: no include, a seta vai do caso base (que depende) para o caso incluído; no extend, a seta vai do caso que estende para o base (embora a alternativa B apresente o sentido oposto, o tipo de relação foi o decisivo).