Pular para o conteúdo principal

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

Engenharia de SoftwareUML
Código
fg165497
Banca
FGV
Órgão
TJ RR
Ano
2024
Cargo
AJ ( )
Um bom diagrama pode ajudar a comunicar ideias sobre um sistema, principalmente quando deseja-se evitar muitos detalhes. Na UML, uma ferramenta recomendada para esse fim é o Caso de Uso. Acerca dos diagramas de casos de uso, avalie as afirmativas a seguir e marque (V) para a verdadeira e (F) para a falsa.   ( ) Casos de uso são uma técnica para capturar os requisitos não funcionais de um software.   ( ) Casos de uso representam uma visão externa do sistema, logo não deve haver correlação com as classes internas do sistema.   ( ) Raias, atores e transições são elementos comuns em casos de uso.   As afirmativas são, respectivamente,
  1. AF – V – F.
  2. BV – V – F.
  3. CF – V – V.
  4. DF – F – V.
  5. EV – F – F.
Revelar gabarito e comentário

GabaritoA — F – V – F.

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”.

UML – Diagrama de Casos de Uso

Gabarito: letra A — sequência F – V – F. Casos de uso capturam requisitos funcionais (não funcionais), representam uma visão externa do sistema (sem correlação direta com classes internas) e, na UML, os elementos comuns são atores, casos de uso e relacionamentos — não raias nem transições, que pertencem a outros diagramas (atividades e estados).

O diagrama de casos de uso é uma das ferramentas mais poderosas da UML para comunicar, em alto nível, o que o sistema deve fazer do ponto de vista de quem o utiliza. Ele responde à pergunta: "quem interage com o sistema e para quê?". Cada caso de uso descreve uma funcionalidade ou objetivo do sistema, expresso em linguagem do usuário final, evitando termos técnicos. A técnica foi proposta por Ivar Jacobson e incorporada à UML, sendo amplamente usada na engenharia de requisitos.

A primeira afirmativa é falsa porque casos de uso capturam requisitos funcionais — as funcionalidades que o sistema deve oferecer. Requisitos não funcionais (desempenho, segurança, usabilidade) são tratados por outras técnicas, como especificações suplementares ou requisitos de qualidade. A banca explora exatamente essa confusão: o candidato que sabe que casos de uso são usados na fase de requisitos pode achar que servem para todos os tipos, mas eles são específicos para o que o sistema faz, não para como ele se comporta em termos de qualidade.

A segunda afirmativa é verdadeira: casos de uso representam uma visão externa do sistema, focando na interação entre atores e o sistema, sem se preocupar com a implementação interna. Isso não significa que não haja correlação com as classes internas — na verdade, os casos de uso podem ser realizados por colaborações de classes — mas o diagrama em si não mostra essa correlação. A banca pode tentar confundir dizendo que "não deve haver correlação", mas o correto é que o diagrama não a representa, não que ela seja proibida.

A terceira afirmativa é falsa: raias são elementos do diagrama de atividades, e transições são elementos do diagrama de estados. No diagrama de casos de uso, os elementos comuns são atores, casos de uso (ovais) e relacionamentos (associação, include, extend, generalização). A banca mistura elementos de diagramas diferentes para testar se o candidato conhece a notação específica de cada um.

1Captura requisitos
Funcionais
Não funcionais
2Visão
Externa do sistema
Sem correlação com classes internas
3Elementos comuns
Atores
Casos de uso (ovais)
Relacionamentos (include, extend, generalização)
Raias (atividades)
Transições (estados)
Diagrama de casos de uso
LEVELsoulevel.com.br
Diagrama de casos de uso: Captura requisitos (Funcionais, Não funcionais); Visão (Externa do sistema, Sem correlação com classes internas); Elementos comuns (Atores, Casos de uso (ovais), Relacionamentos (include, extend, generalização), Raias (atividades), Transições (estados))

Alternativa A — ✅ Correta ⟵ GABARITO

A sequência F – V – F está correta. A primeira afirmativa é falsa (casos de uso capturam requisitos funcionais, não não funcionais), a segunda é verdadeira (visão externa, sem correlação direta com classes internas no diagrama) e a terceira é falsa (raias e transições não são elementos de casos de uso, mas de diagramas de atividades e estados, respectivamente).

Alternativa B — ❌ Incorreta

A sequência V – V – F erra na primeira afirmativa, marcando como verdadeira que casos de uso capturam requisitos não funcionais. Na verdade, eles capturam requisitos funcionais — as funcionalidades que o sistema deve oferecer. Requisitos não funcionais (desempenho, segurança, usabilidade) são tratados por outras técnicas, como especificações suplementares ou requisitos de qualidade.

Alternativa C — ❌ Incorreta

A sequência F – V – V erra na terceira afirmativa, marcando como verdadeira que raias, atores e transições são elementos comuns em casos de uso. Raias são elementos do diagrama de atividades, e transições são elementos do diagrama de estados. No diagrama de casos de uso, os elementos comuns são atores, casos de uso (ovais) e relacionamentos (associação, include, extend, generalização).

Alternativa D — ❌ Incorreta

A sequência F – F – V erra na segunda afirmativa, marcando como falsa que casos de uso representam uma visão externa do sistema. Na verdade, eles representam exatamente isso: uma visão externa, focando na interação entre atores e o sistema, sem se preocupar com a implementação interna. A terceira afirmativa também está errada, como já explicado.

Alternativa E — ❌ Incorreta

A sequência V – F – F erra na primeira afirmativa, marcando como verdadeira que casos de uso capturam requisitos não funcionais. Como já explicado, eles capturam requisitos funcionais. A segunda afirmativa está correta (visão externa), mas a sequência como um todo está errada.

NÃO CAIA NESSA!

A banca adora trocar requisitos funcionais por não funcionais e misturar elementos de diagramas diferentes. Fique atento: casos de uso são para o que o sistema faz (funcional), não para como ele se comporta em qualidade (não funcional). E lembre-se: raias são do diagrama de atividades, transições são do diagrama de estados — no caso de uso, o que aparece são atores, ovais e relacionamentos. Com treino, você enxerga essas trocas de longe 💪

PEGA ESSA DICA!

Para não errar, monte uma tabela mental dos diagramas UML e seus elementos principais: caso de uso (ator, caso, relacionamento), atividades (raias, nós, fluxos), estados (estado, transição, evento), sequência (mensagem, linha de vida). Isso ajuda a identificar rapidamente qual elemento pertence a qual diagrama.

Gabarito: letra A

Link permanente: /questoes/fg165497