Notas de Aula 05: Aplicação de um caso de uso Objetivos da aula: Aprender a aplicar a técnica de casos de uso em um pequeno problema real Identificar as variáveis relevantes a serem consideradas Modelar um caso de uso notável Correlacionar a diagramação e a descrição textual dos casos de uso com o processo de prototipação Recordando... Na aula passada, você aprendeu que um caso de uso pode ser aplicado para modelagem de um negócio e/ou sistema. Você foi exposto as associações de um diagrama de casos de uso da UML e as suas implicações. Além disso, você aprendeu que é necessário descrever textualmente os casos de uso e que o nível de granularidade desta descrição é opcional. Introdução É difícil compreender a aplicação dos casos de uso sem uma experimentação. Esta aula se propõe exatamente para isso: utilizar, baseado um domínio simples, o diagrama de casos de uso e suas associações, juntamente com uma descrição textual e um protótipo de interface. Um breve olhar sobre um problema simples (e real) Considere, como exemplo, o seguinte domínio:
Seja o desenvolvimento de um sistema simples de cadastro de clientes. 1 Por cadastro de clientes, considere que um operador fará, a qualquer momento, uma operação de inclusão de um cliente no sistema com CPF, nome, endereço e telefone. O sistema não pode ter mais de dois clientes com o mesmo CPF. 2 Considere ainda que este mesmo operador poderá buscar os dados deste cliente para consulta futura. 3 Se constatado qualquer erro no cadastro, o operador poderá alterar as informações já inseridas. 4 Quando alguém deixa de ser cliente, o operador executa uma operação de exclusão. A partir do domínio definido, temos a seguinte lista de requisitos: Requisito Funcional Caso de Uso Buscar e exibir os dados de um cliente Buscar Inserir os dados de um cliente Inserir Alterar os dados de um cliente Alterar Excluir os dados de um cliente Excluir A primeira coisa que devemos nos perguntar é: quem interage com os casos de uso listados? Resposta: o operador (linhas 1, 2, 3 e 4). É o operador que é o responsável por manipular o sistema em todos os casos de uso. Nesse sentido, o primeiro caso de uso pode ser facilmente diagramado pois é independente que outro caso de uso (linha 2):
É dito que o operador deve inserir os dados de um cliente no sistema (linha 1). Afinal, o caso de uso buscar só faz sentido se pudermos inserir. Outrossim, inserir um cliente implica em saber se um cliente já está previamente cadastrado. Assim, executar o caso de uso inserir implica na obrigatoriedade da execução do caso de uso buscar (linha 1). Devemos, então utilizar a associação <<include>>. O domínio do nosso sistema também descreve a opção de se alterar ou excluir um cliente previamente cadastrado (linhas 3 e 4). Para se alterar ou excluir os dados de um cliente é razoável cogitar que uma busca deverá ser executada primeiro. Pois, não é possível excluir ou alterar um cliente que não existe, certo? Então não pode haver uma associação direta entre o ator e os casos de uso alterar e excluir. Estes casos de uso são opcionais e podem ser representados pela associação <<extend>>.
O conjunto de casos de uso Buscar, Inserir, Alterar e Excluir são comumente conhecidos como grupo de casos de uso CRUD (Create, Retrieve, Update and Delete). Na verdade, estes casos de uso recebem essa rotulação porque estão geralmente presentes e podem ser aplicados a conjunto diverso de domínio e atores. O que falta, então? Devemos descrever cada caso de uso. Para isso, podemos criar um croqui de uma tela que nos auxilie na descrição do caso de uso. Os protótipos, como mencionado em aulas anteriores, podem ajudar a validar os requisitos: Neste croqui foram colocados os botões que remetem diretamente às ações dos casos de uso Inserir, Alterar, Excluir. Os campos de texto, ao lado das etiquetas, fazem referência aos dados de um cliente. Para buscar um cliente, uma lista de seleção única (combobox) com a etiqueta clientes e o serviço autocompletar permitem ao operador buscar um cliente pelo CPF. Para ficar consonante à diagramação, os botões Alterar e Excluir só ficam habilitados quando cliente é buscado. Para inserir um novo cliente, o operador
deve pressionar o botão Novo. Todos os campos ficarão em branco e o botão inserir ficará habilitado (todos os outros ficarão desabilitados). Estas mudanças de estados nos botões e outros campos, assim como a lógica que os direciona são descritos no roteiro do caso de uso. Em aulas mais à frente, você aprenderá um diagrama que pode auxiliá-lo entendimento desta máquina de estados. Deve-se ressaltar que este é só uma das inúmeras possibilidades de criação de interface. Diagramas de casos de uso não se predem ao uso de uma interface, mas devem ser modelados de acordos com estas (casos de uso de sistemas, é claro). Nesta disciplina não se entra na discussão de qual é o melhor método para criar uma interface de acordo com os parâmetros da Engenharia de Usabilidade. Casos de uso utilizam protótipos de interface para auxiliá-los na construção. Tendo em mente nosso croqui, vamos descrever o caso de uso mais geral. Uma coluna adicional foi colocada para explicar o preenchimento (comentários). Esta coluna não deve existir na documentação. Caso de Uso Buscar Finalidade: Demonstra o uso da funcionalidade de busca de dados de clientes por parte do operador do sistema. Comentários Ator(es): Operador. Somente um operador genérico é citado em toda a descrição do domínio. Pré-condição: Não existe. O nosso domínio é muito simples e não impôs qualquer restrição no uso da funcionalidade. Pós-condição: Dados do cliente exibidos na tela. No croqui da tela, a execução do caso de uso está amarrada pela escolha na combobox. Cenário Principal 1- O operador abre a tela CRUD Clientes. O sistema preenche automaticamente os campos com os dados do primeiro cliente da lista. Cenário(s) alternativo(s): 1a, 1b; 2- O operador seleciona um cliente através da combobox; 2.1- O sistema preenche automaticamente dos dados do cliente selecionado nas caixas de texto referentes às informações de nome, endereço e telefone; 2.2- O sistema habilita os botões Alterar e Excluir. Cenário(s) Alternativo(s): 2.2a, 2.2b, 2,3c; Optou-se em criar uma única tela que abrigasse o conjunto de casos de uso CRUD. No cenário principal, a interface foi projetada para evitar erros. Cenário(s) Alternativo(s) Cenário Alternativo 1a a- O operador não escolhe o CPF na lista, mas digita com recurso autocompletar; a.1 Se o usuário existir Então o fluxo é igual ao do cenário principal a partir do passo 2.1; a.2 Senão Estender Caso de Uso Incluir ; Este recurso poderia ter ficado de fora no protótipo, o que eliminaria a possibilidade de erro (os CPFs estariam limitados ao exibido na combobox). No entanto, a ausência deste recurso inviabiliza um sistema
Cenário Alternativo 1b b- Não existe nenhum cliente cadastrado; b.1 Estender Caso de Uso Incluir ; Cenário Alternativo 2.2a a- Se o botão Alterar for pressionado, uma mensagem pedindo confirmação irá ser emitida. Se confirmado pelo usuário, estender Caso de Uso Alterar ; Cenário Alternativo 2.2b b- Se o botão Excluir for pressionado, uma mensagem pedindo confirmação irá ser emitida. Se confirmado pelo usuário, estender Caso de Uso Excluir ; Cenário Alternativo 2.2c c- Se o botão Novo for pressionado, uma mensagem pedindo confirmação irá ser emitida. Se confirmado pelo usuário, estender Caso de Uso Incluir. com muitos clientes (a lista iria ficar demasiadamente grande) Esta é provavelmente a primeira vez que o sistema foi iniciado. Se não é a primeira vez, então é sinal de que o negócio está indo mal... O fluxo de eventos agora passa a ser tratado pelo Caso de Uso Alterar O fluxo de eventos agora passa a ser tratado pelo Caso de Uso Excluir O fluxo de eventos agora passa a ser tratado pelo Caso de Uso Incluir Agora que descrevemos o caso de uso mais geral, passaremos para o caso de uso que requer validação de campos e que pode (e deve) ocorrer imediatamente após a primeira execução do sistema. Caso de Uso Inserir Finalidade: Demonstra o uso da funcionalidade de inserção de dados de clientes por parte do operador do sistema. Comentários Ator(es): Operador. Somente um operador genérico é citado em toda a descrição do domínio. Pré-condição: Inexistência do cliente no sistema. Como um cliente pode ser inserido a qualquer momento e o modo de busca é feito pela combobox, um trabalho desnecessário poderia ser gerado para o operador caso o cliente já exista. Assim, a interface proposta pode criticar o preenchimento do CPF e evitar o restante do trabalho para o operador. O sistema deve fazer uma busca velada. Pós-condição: Dados do cliente gravados no sistema e exibidos na tela. Cenário Principal 1- Operador abre a tela CRUD Clientes. O operador pressiona o botão novo a qualquer momento da execução; 2- O operador preenche um CPF no campo com etiqueta cpf. Cenário(s) Alternativo(s): 2a. Exceção(ões): 2a; 3- O operador preenche os demais dados do cliente nas caixas de texto referentes às informações de nome, endereço e telefone; 3.1- O sistema habilita o botão Inserir ; O sucesso do caso de uso é, obviamente, a busca bem sucedida posteriormente. Optou-se em criar uma única tela que abrigasse o conjunto de casos de uso CRUD. Não nos preocupamos neste exemplo em validar o telefone e o endereço durante o preenchimento. Entretanto, você pode colocar tantas exceções
3.3 O sistema emite uma mensagem de confirmação positiva em caso de sucesso na inserção. Exceção(ões): 3.3a; quanto queira, como foi o caso do CPF. Cenário(s) Alternativo(s) Cenário Alternativo 2a a- O operador digita um CPF existente; a.1 Estender Caso de Uso Buscar ; Exceção(ões) Exceção 2a a- O operador digita um CPF inválido; a.1 O sistema emite uma mensagem de erro. O sistema posiciona o cursor novamente no campo cpf ; Se o CPF já existe, então significa que não deve ser possível incluir outro cliente com CPF idêntico. Se o CPF é inválido, então não vale deixar o operador prosseguir com a continuação do cadastro. Exceção 3.3a a- O operador deixa um dos campos em branco; a.1 O sistema emite uma mensagem de erro. O sistema posiciona o cursor novamente no primeiro campo que estiver em branco. Cada campo poderia ter uma exceção em específico. Foi adotado, por simplicidade, uma validação final ao pressionar o botão Inserir. Podemos passar para o caso de uso Alterar, que possui muita similaridade com o caso de uso Incluir no que tange a validação de campos. No entanto, no caso de uso Alterar o campo CPF não pode ser modificado. Caso de Uso Alterar Finalidade: Demonstra o uso da funcionalidade de alteração de dados de clientes por parte do operador do sistema. Comentários Ator(es): Operador. Somente um operador genérico é citado em toda a descrição do domínio. Pré-condição: Existência do cliente no sistema. A alteração parte de uma busca bem sucedida no sistema Pós-condição: Dados do cliente atuais gravados no sistema e exibidos na tela. Cenário Principal 1- Operador executa caso de uso Buscar. 2- O operador altera os dados do cliente nas caixas de texto referentes às informações de nome, endereço e telefone; 3.3 O sistema emite uma mensagem de confirmação positiva em caso de sucesso na alteração. Exceção(ões): 3.3a; Exceção(ões) Exceção 3.3a a- O operador deixa um dos campos em branco; a.1 O sistema emite uma mensagem de erro. O sistema posiciona o cursor novamente no primeiro campo que estiver em branco. O sucesso do caso de uso é, obviamente, a busca bem sucedida posteriormente dos dados atualizados. Optou-se em criar uma única tela que abrigasse o conjunto de casos de uso CRUD. Não nos preocupamos neste exemplo em validar o telefone e o endereço durante o preenchimento. Entretanto, você pode colocar tantas exceções quanto queira, como foi o caso do CPF. Cada campo poderia ter uma exceção em específico. Foi adotado,
por simplicidade, uma validação final ao pressionar o botão Alterar. Por fim, o caso de uso Excluir, o mais simples deles: Caso de Uso Alterar Finalidade: Demonstra o uso da funcionalidade de exclusão de dados de clientes por parte do operador do sistema. Comentários Ator(es): Operador. Somente um operador genérico é citado em toda a descrição do domínio. Pré-condição: Existência do cliente no sistema. A exclusão parte de uma busca bem sucedida no sistema Pós-condição: Dados do cliente removidos no sistema. O sucesso do caso de uso é, obviamente, a remoção bem sucedida. Cenário Principal 1- Operador executa caso de uso Buscar ; 2- O operador pressiona o botão Excluir ; 3.3 O sistema emite uma mensagem de confirmação positiva em caso de sucesso na exclusão. Cenário(s) alternativo(s): 3.3a, 3.3b; Optou-se em criar uma única tela que abrigasse o conjunto de casos de uso CRUD. Cenário(s) Alternativo(s) Cenário Alternativo 3.3a a- O cliente excluído é o último existente a.1 Estender Caso de Uso Inserir ; Cenário Alternativo 3.3b a- O cliente excluído não último existente a.1 Estender Caso de Uso Buscar para o primeiro cliente da lista; O que se deve fazer quando o cliente é removido? Depende do estado do sistema... O que se deve fazer quando o cliente é removido? Depende do estado do sistema... Exercícios 1. Baseado no Estudo de Caso 1 (disponível para download) determine os requisitos funcionais. 2. Para cada caso de uso, crie um croqui de interface homem-máquina. Utilize a linguagem ou ferramenta de desenho que preferir. Não é necessário programar. 3. Faça os diagramas de casos de uso. 4. Faça a descrição textual de todos os casos de uso.