Questão de Engenharia de Software — UML — FGV 2024
- Código
- fg165497
- Banca
- FGV
- Órgão
- TJ RR
- Ano
- 2024
- Cargo
- AJ ( )
- AF – V – F.
- BV – V – F.
- CF – V – V.
- DF – F – V.
- EV – F – F.
GabaritoA — F – V – F.
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.
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).
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.
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).
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.
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.
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 💪
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