Revisão - Casos de Uso

Uma empresa de varejo está desenvolvendo um novo sistema de ponto de venda (PDV) para suas lojas físicas. O sistema deve permitir que os funcionários registrem vendas, processem pagamentos com cartão de crédito e emitam recibos. Além disso, o gerente da loja precisa de uma funcionalidade para gerar relatórios diários de vendas. O sistema de PDV interagirá com um serviço externo de processamento de pagamentos para autorizar as transações com cartão. Considerando a descrição do sistema de ponto de venda (PDV) e as boas práticas de modelagem de casos de uso, identifique o conjunto mais preciso e completo de atores que interagem diretamente com o sistema.

• Funcionário, Gerente da Loja e Cliente, que representa o consumidor final.
• Funcionário, Gerente da Loja e Serviço de Pagamento, que é um sistema externo.
• Sistema de PDV, Serviço de Pagamento e Impressora de Recibos.
• Funcionário, Cliente e Cartão de Crédito, que é o meio de pagamento.

Answer explanation

Os atores são entidades externas que interagem com o sistema. O "Funcionário" e o "Gerente da Loja" são atores humanos que iniciam ações. O "Serviço de Pagamento" é um ator não humano (outro sistema) com o qual o sistema de PDV interage. O "Cliente" interage com o funcionário, não diretamente com o sistema. "Sistema de PDV", "Relatório de Vendas", "Cartão de Crédito" e "Impressora" são, respectivamente, o próprio sistema, uma saída, um dado e um periférico, não atores.

Em um sistema de biblioteca online, o caso de uso "Realizar Empréstimo de Livro" descreve o processo padrão em que um usuário autenticado seleciona um livro, o sistema verifica a disponibilidade e a situação do usuário (e.g., sem multas pendentes) e, se tudo estiver correto, registra o empréstimo. Durante a análise do caso de uso "Realizar Empréstimo de Livro", a equipe identificou duas situações: I. Se o livro selecionado não estiver disponível, o sistema deve oferecer ao usuário a opção de entrar na fila de espera. II. Se o usuário possuir multas pendentes, o sistema deve impedi-lo de realizar novos empréstimos e direcioná-lo para a tela de pagamento de multas. Como essas duas situações devem ser modeladas, respectivamente, na especificação do caso de uso?

• A situação I é um fluxo alternativo e a II é um fluxo de exceção.
• A situação I é um fluxo de exceção e a II é um fluxo alternativo.
• Ambas as situações devem ser tratadas como fluxos alternativos distintos.
• A situação I representa uma inclusão e a II representa uma extensão.

Answer explanation

A situação I (livro indisponível) é um fluxo alternativo, pois é uma variação esperada e válida que ainda leva a um resultado de sucesso (entrar na fila). A situação II (usuário com multas) é um fluxo de exceção, pois impede a conclusão do objetivo do caso de uso (realizar empréstimo) devido a uma condição de erro.

Uma companhia aérea está modelando seu sistema de reservas de voos. Foram identificados os casos de uso: "Reservar Voo", "Reservar Assento" e "Incluir Bagagem Extra". A equipe de análise notou que, tanto para reservar um voo quanto para incluir bagagem extra, o sistema precisa, obrigatoriamente, realizar uma verificação de segurança nos dados do passageiro. Para evitar a duplicação do procedimento de "Verificação de Segurança do Passageiro" e garantir sua execução obrigatória, qual relacionamento da UML é o mais apropriado?

• Um relacionamento de extensão (`<extend>`) a partir de "Verificar Segurança" para os outros casos de uso, tornando-o opcional.
• Um relacionamento de inclusão (`<include>`) de "Reservar Voo" e "Incluir Bagagem Extra" para um novo caso de uso "Verificar Segurança".
• Um relacionamento de generalização, no qual "Verificar Segurança" seria um caso de uso especializado herdado pelos demais.
• Um relacionamento de inclusão (`<include>`) a partir de "Verificar Segurança" para os outros casos de uso, invertendo a direção da dependência.

Answer explanation

O relacionamento de inclusão (`<include>`) é usado quando um comportamento é comum e obrigatório a mais de um caso de uso. A verificação de segurança é encapsulada em seu próprio caso de uso e "incluída" pelos casos de uso base que dependem dela.

Considere o desenvolvimento de um sistema para uma plataforma de e-commerce. O caso de uso principal é "Finalizar Compra". Durante o fluxo normal, o cliente preenche os dados de pagamento e confirma o pedido. A equipe de marketing solicitou que, opcionalmente, no momento da confirmação do pagamento, seja oferecido ao cliente a contratação de um seguro para os produtos eletrônicos do carrinho, caso existam. A funcionalidade "Contratar Seguro para Eletrônicos" é um comportamento opcional que ocorre sob certas condições em um ponto específico de "Finalizar Compra". Qual relacionamento da UML descreve melhor essa interação?

• Um relacionamento de inclusão (`<include>`), tratando a oferta de seguro como uma parte obrigatória do fluxo de compra.
• Um relacionamento de generalização, onde "Finalizar Compra com Seguro" seria uma especialização do caso de uso base.
• Um relacionamento de extensão (`<extend>`) do caso de uso "Contratar Seguro" para o caso de uso "Finalizar Compra".
• Um fluxo alternativo dentro de "Finalizar Compra", que descreveria todo o processo de contratação de seguro internamente.

Answer explanation

O relacionamento de extensão (`<extend>`) é ideal para modelar comportamentos opcionais que são executados em pontos específicos de um caso de uso base, sob determinadas condições. A contratação do seguro é opcional e estende a funcionalidade principal.

No sistema de um caixa eletrônico (ATM), o caso de uso "Realizar Saque" tem várias etapas que exigem interação do cliente. Um requisito não funcional determina que, se o cliente não interagir com a interface por 30 segundos em qualquer etapa, a sessão deve ser cancelada e o cartão devolvido por segurança. Como o requisito de "timeout" (tempo de inatividade) deve ser documentado na especificação do caso de uso "Realizar Saque"?

• Como um caso de uso incluído (`<include>`), chamado "Monitorar Inatividade", executado em paralelo.
• Como um fluxo de exceção, detalhando a interrupção da meta do usuário devido à inatividade.
• Como uma pré-condição para iniciar o caso de uso, exigindo que o usuário esteja sempre ativo.
• Como um fluxo alternativo, pois o cancelamento da sessão é uma forma válida de terminar o caso de uso.

Answer explanation

O "timeout" representa uma condição de erro que impede o sucesso do fluxo normal. Portanto, é um fluxo de exceção, que descreve como o sistema lida com a falha na conclusão da tarefa principal do ator.

Em um sistema de gerenciamento de conteúdo (CMS), o caso de uso "Publicar Artigo" envolve vários passos. Em qualquer um deles, o usuário pode acionar a funcionalidade "Visualizar Prévia" para ver como o artigo ficará no site. Essa visualização é uma ação opcional. Considerando que a "Visualização Prévia" é opcional e pode ser invocada em múltiplos pontos de "Publicar Artigo", qual a melhor forma de representá-la?

• Utilizar um relacionamento `<include>`, fazendo da pré-visualização um passo obrigatório do fluxo de publicação.
• Descrever a pré-visualização como um fluxo alternativo que diverge do fluxo principal para exibir o conteúdo.
• Utilizar um relacionamento `<extend>` a partir de "Visualizar Prévia" para "Publicar Artigo", com múltiplos pontos de extensão.
• Associar o ator "Revisor" ao caso de uso "Visualizar Prévia", tratando-a como uma funcionalidade de outro perfil.

Answer explanation

O relacionamento `<extend>` é ideal para funcionalidades opcionais que podem ocorrer em vários momentos. O caso de uso base ("Publicar Artigo") define os pontos de extensão, e o caso de uso de extensão ("Visualizar Prévia") é acionado nesses pontos.

Em um aplicativo de home banking, vários casos de uso, como "Realizar Transferência" e "Pagar Boleto", exigem que o usuário realize uma autenticação de dois fatores (2FA) antes de confirmar a operação. O processo de 2FA é idêntico em todos os cenários. Considerando que a autenticação 2FA é um procedimento obrigatório e reutilizável, a melhor decisão de modelagem seria:

• Utilizar um relacionamento `<extend>` do caso de uso "Autenticar com 2FA" para os casos de uso de transações.
• Documentar a autenticação 2FA como uma pós-condição que deve ser satisfeita ao final de cada transação.
• Utilizar um relacionamento `<include>` dos casos de uso de transações para o caso de uso "Autenticar com 2FA".
• Definir um ator "Sistema de Autenticação" que se especializa a partir do ator "Cliente" para realizar a validação.

Answer explanation

O relacionamento `<include>` é utilizado para extrair um comportamento que é comum e obrigatório para múltiplos casos de uso. Encapsular a 2FA em um caso de uso incluído promove reuso e consistência.

Ao modelar um sistema de caixa eletrônico (ATM), um analista definiu o caso de uso "Realizar Saque". Durante a descrição dos fluxos, ele especificou que, após a inserção do valor, o cliente pode optar por imprimir o recibo ou não. A não impressão do recibo não impede o saque de ser concluído com sucesso. O caminho em que o cliente opta por não imprimir o recibo, mas ainda assim finaliza o saque com sucesso, deve ser modelado como:

• Um Fluxo de Exceção, pois uma ação esperada (imprimir) não foi realizada.
• Um Fluxo Normal, pois é o caminho mais comum.
• Um Fluxo Alternativo, pois representa uma variação bem-sucedida do fluxo normal.
• Um novo caso de uso "Sacar sem Recibo", estendido pelo caso de uso base.

Answer explanation

O Fluxo Alternativo é usado para descrever uma variação do fluxo normal que também leva ao sucesso do caso de uso. A escolha de não imprimir o recibo é uma ramificação do fluxo principal, mas o objetivo (realizar o saque) é alcançado. Não é uma exceção, pois não há erro.

Um sistema acadêmico possui o caso de uso "Inscrever-se em Disciplina". O fluxo normal descreve um aluno selecionando disciplinas. Existem duas variações: 1. Se o aluno for bolsista, pode, opcionalmente, solicitar a isenção de taxas. 2. Se a disciplina estiver lotada, o sistema sempre permite que o aluno entre numa lista de espera. Avaliando a natureza dessas duas variações, uma sendo uma ação opcional e a outra uma ramificação padrão do fluxo, como elas deveriam ser modeladas, respectivamente?

• A primeira como um fluxo alternativo e a segunda com o relacionamento `<extend>`.
• A primeira com o relacionamento `<extend>` e a segunda como um fluxo alternativo.
• Ambas devem ser modeladas como fluxos alternativos dentro do caso de uso principal.
• A primeira com o relacionamento `<include>` e a segunda como um fluxo de exceção.

Answer explanation

A solicitação de isenção é opcional e condicional, caracterizando um `<extend>`. A entrada na lista de espera por falta de vagas é uma variação esperada do processo de inscrição, caracterizando um fluxo alternativo.

Em um sistema de e-commerce, o "Cliente" inicia interações como "Finalizar Compra". O "Administrador" inicia "Gerenciar Catálogo". Um sistema externo de logística é notificado pelo sistema de e-commerce quando uma compra é finalizada para iniciar a entrega. Na modelagem de casos de uso, como o sistema externo de logística deve ser classificado e representado?

• Como um ator principal, pois sua participação é essencial para a conclusão do negócio.
• Como um caso de uso, denominado "Notificar Logística", incluído em "Finalizar Compra".
• Como uma classe em um diagrama de projeto, mas não deve ser representado no diagrama de casos de uso.
• Como um ator secundário, pois ele reage a um estímulo do sistema em vez de iniciar uma interação.

Answer explanation

Atores primários iniciam casos de uso. Atores secundários são aqueles com os quais o sistema interage para completar uma funcionalidade, mas que não iniciam a interação. O sistema de logística recebe informações, sendo, portanto, um ator secundário.