Questão de Engenharia de Software — Geral — FUNDATEC 2026

Diagrama de Casos de Uso UML: atores, generalização, include e sistemas externos

Gabarito: letra C — corretos os itens I, II e IV. O item III está incorreto porque, no diagrama, quem possui associação direta com o caso de uso "Envio das informações" é o ator Aluno, mas a responsabilidade de enviar dados ao sistema de faturamento é do Sistema de Faturamento (ator externo), que interage com o caso de uso por meio de associação — não o Aluno. A assertiva mistura os dois atores, atribuindo ao Aluno uma função que pertence ao sistema externo.

O diagrama de casos de uso é um dos diagramas comportamentais da UML e tem como objetivo representar, em alto nível de abstração, as funcionalidades que o sistema oferece (os casos de uso) e quem as utiliza (os atores). Um ator pode ser um humano ou uma entidade máquina que interage com o sistema para executar um trabalho significativo. No diagrama, o ator é representado por um boneco palito (stick man) e deve ser externo ao sistema, ou seja, fora da fronteira do sistema. Os casos de uso, por sua vez, são representados por elipses e ficam dentro da fronteira do sistema.

A generalização entre atores é uma relação de herança: um ator especializado (subator) herda as associações do ator mais geral (superator). Isso significa que, se o ator Usuário está associado a determinados casos de uso, o ator Administrador, sendo uma especialização de Usuário, também participa desses casos de uso, além de poder ter associações próprias. Essa relação é representada por uma linha sólida com um triângulo vazio apontando para o ator mais geral.

O relacionamento <<include>> entre casos de uso indica que o comportamento do caso de uso incluído é obrigatoriamente executado sempre que o caso de uso base é realizado. Em outras palavras, o caso de uso base não se completa sem a execução do caso de uso incluído. A notação é uma seta tracejada com o estereótipo <<include>>, partindo do caso de uso base e apontando para o caso de uso incluído. Esse relacionamento é usado para fatorar comportamentos comuns a vários casos de uso, evitando duplicação.

Já o relacionamento <<extend>> é opcional: o caso de uso base pode, em determinadas condições, ser estendido pelo caso de uso que estende, mas isso não é obrigatório. A diferença fundamental entre include e extend é justamente a obrigatoriedade versus a opcionalidade.

Quando um sistema externo aparece como ator no diagrama, ele representa uma entidade máquina que interage com o sistema modelado. A associação entre o ator externo e o caso de uso indica que o sistema externo participa da execução daquela funcionalidade. No caso do "Envio das informações", o Sistema de Faturamento é o ator que interage com esse caso de uso, recebendo os dados enviados. O Aluno, por sua vez, pode estar associado a outros casos de uso, como "Realizar matrícula" ou "Consultar disciplinas", mas não é ele quem envia dados ao sistema de faturamento — essa é uma função do sistema externo.

A pegadinha da banca está exatamente na assertiva III: ela mistura os dois atores, atribuindo ao Aluno uma responsabilidade que é do Sistema de Faturamento. O candidato que não observa atentamente o diagrama pode confundir as associações e marcar a assertiva como correta. A distinção entre ator humano e ator sistema externo é crucial para interpretar corretamente o diagrama.

Guarde a fronteira entre quem inicia a interação (o Aluno, que envia informações) e quem recebe os dados (o Sistema de Faturamento): é exatamente nessa distinção que a assertiva III se separa das demais.

Item I — ✅ Correto

A assertiva afirma que o ator Administrador é uma especialização do ator Usuário, herdando suas interações com os casos de uso associados. Isso está correto: a generalização entre atores é uma relação de herança, na qual o ator especializado herda as associações do ator mais geral. No diagrama, se o Administrador é representado como uma especialização de Usuário, ele participa de todos os casos de uso aos quais Usuário está associado, além de poder ter associações próprias. A notação é uma linha sólida com um triângulo vazio apontando para o ator mais geral.

Item II — ✅ Correto

A assertiva afirma que o relacionamento <<include>> indica que o comportamento do caso de uso incluído é obrigatoriamente executado sempre que o caso de uso base é realizado. Isso está correto: o include estabelece uma relação de obrigatoriedade, ou seja, o caso de uso base não se completa sem a execução do caso de uso incluído. A notação é uma seta tracejada com o estereótipo <<include>>, partindo do caso de uso base e apontando para o caso de uso incluído.

Item III — ❌ Incorreto

A assertiva afirma que o ator Aluno possui associação direta com o caso de uso "Envio das informações", sendo responsável por enviar dados ao sistema de faturamento. O erro está na segunda parte: quem envia dados ao sistema de faturamento é o Sistema de Faturamento (ator externo), não o Aluno. O Aluno pode até estar associado ao caso de uso, mas a responsabilidade de enviar dados ao sistema externo é do próprio sistema externo. A assertiva mistura os dois atores, atribuindo ao Aluno uma função que pertence ao Sistema de Faturamento.

Item IV — ✅ Correto

A assertiva afirma que o sistema externo Sistema de Faturamento interage com o caso de uso "Envio das informações", indicando integração entre sistemas. Isso está correto: o Sistema de Faturamento é um ator externo que participa da execução do caso de uso, recebendo os dados enviados. A associação entre o ator externo e o caso de uso representa essa integração entre sistemas.

Conclusão: corretos os itens I, II e IV → portanto a alternativa é a letra C.

Gabarito: letra C