Julgue o próximo item, a respeito de processos de desenvolvimento de software e de UML.
Conforme o diagrama de caso de uso a seguir, todas as vezes que o caso de uso faturar compra for acionado pelo ator sistema, obrigatoriamente também será acionado o caso de uso finalizar compra.
GabaritoE — Errado
Gabarito: Errado (E). A afirmação de que, sempre que o caso de uso "faturar compra" for acionado pelo ator "sistema", obrigatoriamente também será acionado o caso de uso "finalizar compra" está incorreta, pois a relação representada no diagrama é de inclusão (include), e não de extensão (extend). No relacionamento include, o caso de uso base sempre inclui o caso de uso incluído; já no extend, a inclusão é condicional e opcional. A banca inverteu o sentido desses relacionamentos, explorando a confusão clássica entre eles.
O diagrama de casos de uso é um dos diagramas comportamentais da UML, utilizado para representar as funcionalidades do sistema sob a perspectiva do usuário (ator). Os atores podem ser pessoas, sistemas externos ou dispositivos que interagem com o sistema. No enunciado, o ator "sistema" aciona o caso de uso "faturar compra", e a questão afirma que isso obrigatoriamente aciona "finalizar compra". Para analisar corretamente, é preciso entender os dois principais relacionamentos entre casos de uso:
Include (inclusão): o caso de uso base sempre inclui o caso de uso incluído. A execução do caso de uso base obrigatoriamente passa pelo caso de uso incluído. É uma relação de dependência obrigatória. Exemplo: no caso de uso "Fazer compra", o caso de uso "Autenticar usuário" é incluído obrigatoriamente.
Extend (extensão): o caso de uso base pode, opcionalmente, ser estendido pelo caso de uso de extensão, sob certas condições. A execução do caso de uso de extensão não é obrigatória. Exemplo: no caso de uso "Fazer compra", o caso de uso "Aplicar cupom de desconto" estende opcionalmente, apenas se o cliente tiver um cupom.
No diagrama da questão, a relação entre "faturar compra" e "finalizar compra" é de extensão (extend), indicada por uma seta tracejada com a palavra <<extend>>. Isso significa que "finalizar compra" é um caso de uso que pode ser acionado, mas não obrigatoriamente, quando "faturar compra" é executado. A execução de "finalizar compra" depende de uma condição (por exemplo, se o pagamento for aprovado). Portanto, a afirmação de que "obrigatoriamente também será acionado" está errada.
A pegadinha da banca está em inverter o significado dos relacionamentos: a questão descreve o comportamento do include (obrigatoriedade) como se fosse o do extend (opcionalidade). O candidato que confunde os dois relacionamentos cai na armadilha. Para acertar, é fundamental identificar no diagrama o tipo de seta e o estereótipo (<<include>> ou <<extend>>) que acompanha a relação.
A banca troca o relacionamento include pelo extend. No include, a execução do caso de uso incluído é obrigatória; no extend, é opcional e condicional. A questão afirma que "faturar compra" obrigatoriamente aciona "finalizar compra", o que seria verdadeiro apenas se a relação fosse de include. Como a relação é de extend, a afirmação é falsa. Fique atento ao estereótipo na seta: <<include>> = obrigatório; <<extend>> = opcional.
Relacionamento | Obrigatoriedade | Direção da seta | Estereótipo |
|---|---|---|---|
Include (inclusão) | Obrigatório — o caso de uso base sempre executa o incluído | Do caso de uso base para o incluído |
|
Extend (extensão) | Opcional e condicional — o caso de uso base pode ser estendido | Do caso de uso de extensão para o base |
|
A afirmação está errada porque descreve o relacionamento de inclusão (include) como se fosse o de extensão (extend). No diagrama, a relação entre "faturar compra" e "finalizar compra" é de extend, o que significa que "finalizar compra" é acionado opcionalmente, sob determinadas condições, e não obrigatoriamente sempre que "faturar compra" for executado. A obrigatoriedade é característica do include, não do extend.
Gabarito: Errado (E).
Link permanente: /questoes/ce403874