Questão de Engenharia de Software — UML — CESPE / CEBRASPE 2024
Engenharia de Software›UML
Código
ce403864
Banca
CESPE / CEBRASPE
Órgão
ITAIPU
Ano
2024
Cargo
Prof NU Jr ( )
Com relação ao caso de uso acima, que está descrito em UML, assinale a opção correta.
AOs atores Doutor e Secretária podem acionar Procurar registro do paciente.
BO acionamento de Procurar registro do paciente aciona, obrigatoriamente, Marcar consulta.
CÉ necessário primeiro acionar-se Marcar consulta para, na sequência, acionar Cancelar consulta.
DO acionamento de Adiar pagamento permitirá ao seu ator acionar opcionalmente Pagar conta Extension points - Mais tratamento.
EO caso de uso Adiar pagamento é inacessível ao ator Balconista.
Revelar gabarito e comentário▾
GabaritoA — Os atores Doutor e Secretária podem acionar Procurar registro do paciente.
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 UML: atores, relacionamentos e leitura correta
Gabarito: letra A. No diagrama de casos de uso da UML, a leitura correta é que os atores Doutor e Secretária estão associados ao caso de uso "Procurar registro do paciente", podendo ambos acioná-lo — é exatamente o que a alternativa A afirma. As demais alternativas distorcem os relacionamentos de inclusão («include»), extensão («extend») e generalização entre atores, que são os elementos centrais deste tipo de diagrama.
O diagrama de casos de uso é um dos diagramas comportamentais da UML e tem como objetivo mostrar, de forma geral, a funcionalidade do sistema e quem a executa. Ele é composto por três elementos principais: os atores (figuras de palito, fora da fronteira do sistema), os casos de uso (elipses, dentro da fronteira do sistema) e os relacionamentos (linhas e setas que conectam esses elementos). A fronteira do sistema é representada por um retângulo que separa o que está dentro (as funcionalidades) do que está fora (quem interage com o sistema).
Os relacionamentos entre casos de uso são o ponto mais cobrado em provas e o que diferencia a leitura correta da incorreta. Existem três tipos principais:
Inclusão («include) : representada por uma seta tracejada com o estereótipo «include», indica que o caso de uso de origem sempre inclui o comportamento do caso de uso de destino. Ou seja, se o caso A inclui o caso B, toda vez que A for executado, B também será executado obrigatoriamente.
Extensão («extend) : representada por uma seta tracejada com o estereótipo «extend», indica que o caso de uso de origem opcionalmente estende o comportamento do caso de uso de destino. Ou seja, o caso B pode ser executado como uma extensão opcional do caso A, mas não é obrigatório.
Generalização: representada por uma seta com triângulo vazado, indica que um caso de uso ou ator é uma especialização de outro. No caso de atores, a generalização significa que o ator filho herda as associações do ator pai.
Além disso, a associação entre um ator e um caso de uso é representada por uma linha contínua, indicando que o ator pode acionar aquele caso de uso. Um mesmo caso de uso pode estar associado a vários atores, e um ator pode estar associado a vários casos de uso.
A pegadinha clássica da banca neste tipo de questão é inverter o sentido dos relacionamentos: trocar «include» por «extend», afirmar que um caso de uso é obrigatório quando na verdade é opcional, ou atribuir a um ator uma associação que pertence a outro. Para acertar, é fundamental ler o diagrama com atenção e identificar corretamente cada estereótipo e cada linha de associação.
Guarde a distinção entre «include» (obrigatório) e «extend» (opcional) e a regra de que a associação liga o ator ao caso de uso que ele pode acionar: é exatamente nesses dois pontos que as alternativas desta questão se dividem.
Relacionamento
Estereótipo
Obrigatoriedade
Representação
Inclusão
«include»
Sempre (obrigatório)
Seta tracejada com «include»
Extensão
«extend»
Opcional
Seta tracejada com «extend»
Generalização
—
Herança de associações
Seta com triângulo vazado
Relacionamentos entre casos de uso: Inclusão («include») (Obrigatório, A executa B sempre); Extensão («extend») (Opcional, B estende A condicionalmente); Generalização (Ator filho herda associações do pai); Associação (Linha contínua, Ator pode acionar o caso de uso)
Alternativa A — ✅ Correta ⟵ GABARITO
A alternativa afirma que os atores Doutor e Secretária podem acionar "Procurar registro do paciente". No diagrama, ambos os atores estão associados a esse caso de uso por linhas contínuas de associação. Isso significa que tanto o Doutor quanto a Secretária têm permissão para acionar a funcionalidade de procurar o registro do paciente. A leitura está correta e reflete exatamente o que o diagrama representa.
Alternativa B — ❌ Incorreta
A alternativa afirma que o acionamento de "Procurar registro do paciente" aciona, obrigatoriamente, "Marcar consulta". Isso só seria verdade se houvesse um relacionamento de inclusão («include») de "Marcar consulta" em "Procurar registro do paciente". No diagrama, não há essa relação de inclusão entre esses dois casos de uso — ou, se houver, ela não é obrigatória. A palavra "obrigatoriamente" é o erro: ela só se aplicaria a um relacionamento «include», não a uma associação simples ou a um «extend». A banca explora a confusão entre associação e inclusão.
Alternativa C — ❌ Incorreta
A alternativa afirma que é necessário primeiro acionar "Marcar consulta" para, na sequência, acionar "Cancelar consulta". Isso implicaria uma relação de dependência sequencial obrigatória entre os dois casos de uso, o que não é representado no diagrama. Casos de uso são funcionalidades independentes, a menos que haja um relacionamento explícito de «include» ou «extend». A ordem de execução entre "Marcar consulta" e "Cancelar consulta" não é definida por uma relação de precedência no diagrama de casos de uso. A alternativa inventa uma sequência que não existe.
Alternativa D — ❌ Incorreta
A alternativa afirma que o acionamento de "Adiar pagamento" permitirá ao seu ator acionar opcionalmente "Pagar conta" e "Extension points - Mais tratamento". O erro está na mistura de conceitos: "Extension points" é um recurso do relacionamento de extensão («extend»), que indica os pontos específicos onde a extensão pode ocorrer. No entanto, a alternativa trata "Extension points - Mais tratamento" como se fosse um caso de uso a ser acionado, o que é incorreto. Além disso, a relação entre "Adiar pagamento" e "Pagar conta" precisa ser verificada no diagrama: se não houver um «extend» explícito, a afirmação de que é opcional não se sustenta. A alternativa confunde a notação de pontos de extensão com casos de uso.
Alternativa E — ❌ Incorreta
A alternativa afirma que o caso de uso "Adiar pagamento" é inacessível ao ator Balconista. Para que isso fosse verdade, o Balconista não poderia ter nenhuma associação com "Adiar pagamento". No entanto, se o Balconista está associado a um caso de uso que inclui ou estende "Adiar pagamento", ou se há uma generalização entre atores que o conecta, ele pode ter acesso. A alternativa faz uma afirmação absoluta de inacessibilidade que precisa ser verificada no diagrama. Se o Balconista tem qualquer linha de associação que o conecte a "Adiar pagamento" (direta ou indiretamente), a afirmação é falsa. A banca explora a generalização entre atores: um ator filho herda as associações do ator pai, então mesmo que o Balconista não esteja diretamente ligado a "Adiar pagamento", ele pode acessá-lo por herança.