PauloMotta.pro

O processo de análise de sistemas começa com o levantamento do problema que será trabalhado, o maior erro que pode ser cometido é começar a solucionar um problema que não sabemos qual é. Entretanto, uma vez definido e descrito o problema, identificada a solução que vai ser empregada, a próxima etapa é a listagem dos requisitos funcionais e não funcionais. Tendo a lista de requisitos funcionais, precisamos identificar todos os passos para realizar cada um dos requisitos funcionais, e isso é o papel dos casos de uso.

Muitas vezes os casos de uso são confundidos com os diagramas de caso de uso, estes são representações gráficas que permitem visualizar os relacionamentos entre atores e casos de uso além de relações entre casos de uso. No entanto esses diagramas não apresentam quais são os passos necessários para atingir o objetivo do requisito funcional representado. Para que seja possível desenvolver um sistema, precisamos entender qual é a necessidade do usuário, e isso é feito com entrevistas que serão documentadas para nortear a criação ou atualização de módulos no sistema.

É importante utilizar o texto de um caso de uso para descrever, de forma clara e objetiva, o que precisa ser feito em cada funcionalidade do sistema. Neste aspecto uma característica interessante é que existem diversos modelos de casos de uso com mais ou menos seções, cada tipo se adéqua melhor a um tipo de situação ou contexto de trabalho, mas são necessárias pelos menos seis seções:

1. Título – é o nome do caso de uso propriamente dito, pode incluir um código para simplificar as referências
2. Descrição – pequeno texto que descreve a que esse caso de uso se refere, ou seja, explica de forma resumida o que acontece nesse caso de uso.
3. Pré-condições – são todas as condições que devem ser verdadeiras para que o caso de uso possa executar, então para o desenvolvedor significa que terão que ser testadas antes de seguir em frente. Uma pré-condição clássica: “Usuário precisa estar autenticado no sistema,” indica que devemos testar (de alguma forma) se o usuário está autenticado (além de ter autorização para acessar o recurso). Em sistemas web é muito comum tentar quebrar a segurança digitando o endereço de alguma página do sistema diretamente no browser.
4. Pós-condições – são todos os itens que garantimos como válidos se o caso de uso terminar com sucesso. Recibos impressos, dados salvos, e todo tipo de resultado obtido a partir da execução desse caso de uso.
5. Fluxo Principal – aqui descrevemos os passos, em uma lista numerada, para se atingir o objetivo do caso de uso. Aqui não devemos incluir referências a tecnologias específicas (tais como “clicar no botão” ou “fazer um insert no banco”) e consideramos que não acontecem erros, simplesmente porque fica muito mais fácil de entender o que deve ser feito se pensarmos de forma isolada em um caso correto.
6. Fluxos Alternativos – descrevemos aqui todas as situações que podem acontecer em relação ao fluxo principal, situações de erro ou de desvio, por exemplo, usuário escolhe outra forma de pagamento por não ter dinheiro suficiente para a compra. Aqui fica fácil pensar de forma pontual em cada situação de falha ou exceção porque o fluxo principal está completo, então cada item de fluxo alternativo deve começar com o número do passo que referencia no fluxo principal e deve descrever textualmente qual é a situação de erro (ou exceção) que aconteceu, em seguida apresenta uma lista numerada de passos para contornar a situação.

É claro que existem outras seções possíveis, mas muitas vezes trabalhamos com sistemas pequenos/médios nos quais seções extra não agregam muita informação considerando o trabalho necessário para mantê-las. A primeira coisa a ter em mente é que não devemos utilizar associações com tecnologias, não deve ser usada nenhuma instrução de código, referências a tela ou bancos de dados. No entanto podemos ajudar na criação do sistema através do uso de certas palavras-chave para guiar o entendimento, a escrita é uma ferramenta fundamental no desenvolvimento de sistemas. Quando escrevemos que o usuário “seleciona” uma opção isso indica para o leitor que vai haver alguma maneira de escolher entre opções existentes e que serão apresentadas para ele, ou seja, ele não vai escrever um valor, apenas a forma de concretizar isso é que depende da tecnologia. Da mesma forma quando escrevemos que o usuário “informa” um valor, isso indica que deverá existir uma forma para o usuário inserir um texto livre, o que vai restringir será o tipo de dado, se utilizaremos um número inteiro, um número real ou um texto tal como um nome.

Uma outra característica interessante é o fato de que no Fluxo Principal devemos nos concentrar em apresentar para o usuário um cenário sem erros, isso é importante para que fique claro como atingir o objetivo daquele caso de uso, se misturarmos o tratamento de erro ou de exceção aos passos principais, pode ficar confuso o que é parte da solução e o que é situação de erro. Além disso, facilita muito termos um “roteiro” de como atingir o objetivo do caso de uso para então incluir os tratamentos de possíveis erros.