Conceituando e Entendendo Caso de Uso
Cada vez mais o desenvolvimento de software fica mais complexo. Devemos isso às regras de negócios das grandes corporações que por sua vez estão cada vez mais complexas. O mundo não é mais o mesmo, ele tornou-se pequeno graças à internet. Milhares de pessoas têm acesso às informações e aos produtos vendidos no mercado praticamente de forma instantânea. Isso fez com que as empresas também tivessem que investir para ganhar espaço nesse “Mundo Novo”.
Então, para que o desenvolvimento de software tenha sucesso, é fundamental que nós desenvolvedores de software tenhamos a total compreensão do processo de negócio dos clientes. Com isso pode-se entender claramente a real necessidade dos clientes em relação ao seu próprio negócio. Com o conhecimento sobre o negócio, temos a noção dos riscos para o desenvolvimento e como o software deverá se comportar no dia a dia do cliente.
Mas sabemos que em desenvolvimento de software nada é constante e sim mutável. As regras mudam a toda hora, manutenções são feitas em funcionalidades já entregues, novos sistemas surgem e se comunicam com o nosso através de vários protocolos e tecnologias diferentes. Entretanto, o pior de tudo é quando uma determinada informação do negócio muda ou uma nova funcionalidade passa a existir, pois isso acaba acarretando várias alterações em cascata no desenvolvimento do software, como: fazer novamente a análise, o projeto, a implementação, os testes e etc. Dessa forma, é necessário ter uma maneira de mapear e manter registrado todos os requisitos e regras de negócio do cliente para que no futuro possamos ter uma rastreabilidade de impacto no caso de alteração de um requisito ou de uma regra de negócio. Essa rastreabilidade é de total importância, pois com ela pode-se determinar, por exemplo, a complexidade da alteração, os artefatos (documentos) que necessitarão serem alterados e o prazo da alteração do software, pois como diz o ditado, “tempo é dinheiro”.
Atualmente, existe um artefato muito utilizado que nos permite dirigir todo o desenvolvimento de software. Com ele, podem-se rastrear os impactos nos requisitos de software e nos demais artefatos que foram criados a partir dele. Esse artefato chama-se Caso de Uso (Use Case). O caso de uso é usado em todo desenvolvimento através de vários “cenários” e por vários membros da equipe de desenvolvimento. Por exemplo: na criação da arquitetura do software, na análise e projeto físico, na criação dos planos de testes e etc.
A motivação em escrever este artigo está no fato de ter percebido que muitas pessoas não sabem o que é um caso de uso realmente, ou seja, criam um caso de uso de maneira errada que ao invés de ajudar no desenvolvimento do software, acabará trazendo problemas no futuro. Para que isso não ocorra, temos que primeiro entender o que é um caso de uso antes de sair especificando-o.
Entendendo o que é um Caso de Uso
Muitos analistas de sistemas criam casos de usos e seus diagramas de forma inapropriada. Com isso, todo o desenvolvimento de software é afetado, gerando inúmeras dificuldades no entendimento da aplicação. Na verdade, para um caso de uso ser considerado válido, sua especificação deve seguir algumas regras. Essas regras existem exatamente para deixar os casos de usos com fácil entendimento não só pela equipe de desenvolvimento, mas também pelos clientes. Vejam quais são essas regras:
Um caso de uso é uma seqüência de interações entre o ator (alguém ou algo que interage com o sistema) e o sistema, que acontece de forma atômica, na perspectiva do ator.
Isso significa que quando criamos um caso de uso apenas nos preocupamos com “o que” o sistema deve fazer e não com “o como” deve fazer. E aí está o maior erro existente em vários casos de uso que eu tenho encontrado em meus anos como desenvolvedor de software. Vários analistas quando especificam os casos de uso, acabam colocando como deve ser feito um determinado passo ou fluxo, descrevendo que aquela informação deve ser salva naquela tabela e/ou que aquela informação deve ser lida daquela tabela e daquele campo.
Nunca devemos esquecer que a especificação do caso de uso será lida e validada pelo nosso cliente e que eles podem ser ou não da área de TI. Neste caso, mesmo se forem, o objetivo principal do caso de uso é mapear o que o sistema deve fazer. Essa é a principal validação que o cliente fará no caso de uso e não se as informações ficarão na tabela XYZ e no campo ABC. Mas então, em que momento no desenvolvimento de software deve-se começar a pensar em como o sistema executará as funcionalidades? Isso fica para o projeto físico, onde aí sim nos preocuparemos com toda a parte tecnológica do sistema como banco de dados, servidores de aplicação, linguagem de desenvolvimento, estratégias de transação, alocação de memória e etc.
O fato das interações entre o ator e o sistema serem atômicas na perspectiva do ator, significa que cada passo representa uma única operação tanto por parte do ator quanto do sistema. Também significa que essa operação ao final de sua execução retornará o resultado esperado em caso de sucesso, não podendo haver resultados parciais.
Ao ser executado, um caso de uso deve fornecer um resultado observável e significativo para o ator.
Todo caso de uso deve representar uma solução sistêmica para o negócio do cliente, ou seja, não devem existir casos de uso para soluções tecnológicas como explicado no item anterior. E isso tem bastante influência no resultado que um caso de uso deve retornar para o ator, pois esse resultado também deve estar inserido dentro do contexto do negócio do cliente.
Como exemplo, posso citar um caso de uso para saque de dinheiro em um caixa eletrônico. Quando vamos ao caixa eletrônico para sacar dinheiro nós iniciamos um processo de negócio que conterá vários passos. Ao final do processo o resultado será o dinheiro que a máquina liberará, contando que tudo deu certo durante o processo. Perceba que o ato de sacar dinheiro pelo cliente é uma operação que está dentro do processo de movimentação bancária de qualquer banco existente, assim como as demais operações como transferência, depósito e etc. Portanto, percebemos que o resultado do caso de uso realmente está dentro do contexto do processo de negócio, pois o que se deseja é o dinheiro que é objeto da movimentação.
Um caso de uso representa uma visão externa do sistema. Ficam registradas todas as informações trocadas entre o ator e o sistema. Com isso obtemos o que chamamos de “contorno do sistema” ou “fronteira do sistema”.
Como expliquei no primeiro item, em um caso de uso não se deve colocar como o sistema deve fazer o processo e sim o que ele tem que fazer. Dessa forma podemos determinar as responsabilidades dos atores e do sistema na execução de suas tarefas, pois como veremos mais a frente, atores também podem ser outros sistemas. Então imagine se o nosso sistema tivesse que interagir com outro sistema que já está pronto. Nós apenas queremos saber que tipo de funcionalidade (serviço) esse sistema pode nos oferecer e não como ele executa essa funcionalidade internamente. Vejamos a Figura 1 para entendermos melhor.
Na Figura 1, vemos um diagrama de caso de uso para venda de ingressos pela internet. Nele o cliente envia as informações do seu cartão de crédito para a compra do ingresso. O nosso sistema deverá enviar essas informações para o sistema da operadora do cartão de crédito afim de validação. Repare que o diagrama tem dois atores, um (Cliente) sendo um usuário do nosso sistema e o outro (Operadora de Cartão de Crédito) sendo o sistema externo que validará os dados do cartão de crédito do cliente. Note que, assim vamos obtendo a “fronteira do sistema” que é tudo que o ator enxerga e/ou percebe do sistema, ou seja, as informações passadas para o sistema pelo ator e as informações passadas para o ator pelo sistema. Quando a informação dada pelo ator atravessa a fronteira do sistema, ela está dentro do sistema e o ator não sabe como essa informação será tratada, só importando o resultado.
Casos de uso com poucos passos devem ser avaliados se são realmente significativos para serem casos de uso e não parte de um caso de uso maior.
Esse item deve ser levado com muita atenção, pois às vezes é muito difícil decidir se um caso de uso é na verdade passos de outro caso de uso maior ou se um caso de uso é na realidade vários casos de uso embutidos que devem ser separados. Para tomarmos essa decisão devemos levar em conta alguns aspectos:
- Ter total conhecimento do processo de negócio do cliente;
- Sabermos se os passos de um caso de uso serão usados por outros casos de uso e assim podermos fazer reuso desses passos como outro caso de uso.
Lembre-se que um caso de uso é uma seqüência de interações entre o ator e o sistema e, por isso, casos de uso com poucos passos tendem a não mostrar essa interação de forma que possamos entender o processo de negócio. Por outro lado, existem passos tão importantes no contexto do negócio do cliente que muitas vezes é interessante separá-los para podermos fazer reuso desses passos. Vejamos a Figura 2 para entendermos melhor.
Na Figura 2, vemos um diagrama de caso de uso para movimentação bancária de saque e depósito. Sabemos que nessas movimentações, existem passos que sempre serão executadas e um desses passos é a identificação do cliente, onde o cliente coloca seu cartão e o sistema validará os dados como agência, número da conta e senha para saber se é um cliente válido que pode fazer a movimentação. Por ser um passo de muita importância no contexto do negócio do cliente e por mais de um caso de uso ter esses mesmos passos, nós podemos separá-los a fim de reutilizarmos essa parte da interação ator e sistema. Mas devemos ter muito cuidado ao fazer isso, pois podemos acabar tendo uma enxurrada de casos de uso sem necessidade. A ponderação do que é importante para o negócio e para o sistema deve predominar nesse momento.
Agora que entendemos o que é um caso de uso, mostrarei algumas características importantes de um diagrama de caso de uso.
Características importantes de um diagrama de caso de uso
Ao criarmos um diagrama de caso de uso, também devemos nos atentar para certas características para que o diagrama não fique errado ou confuso no momento da especificação:
Ator
Alguém ou algo que interage com o sistema. Um ator pode ser uma pessoa, um sistema externo (por exemplo: Figura 1) ou um hardware.
Para atores que representam pessoas, não podemos nomeá-los com os nomes das pessoas e sim com os papéis que essas pessoas representam dentro do contexto do negócio. Por exemplo: na Figura 2, temos o ator Cliente que pode efetuar um saque ou um depósito. O nome Cliente representa um papel nesse contexto do negócio do nosso cliente, ou seja, qualquer pessoa que possa sacar ou depositar dinheiro é considerado um cliente. Essa característica é idêntica a um diagrama de classe, sendo o ator a classe e os clientes (João, Maria, José, etc.) as instâncias desse ator.
Para atores que representam sistemas externos, apenas os nomeamos com o nome do sistema.
Para atores que representam um hardware, devemos tomar um pouco de cuidado, pois não é qualquer hardware que será um ator, senão nosso diagrama de caso de uso terá diversos atores e que não representam nenhuma importância para o negócio. Um ator que representa um hardware deve ser de extrema importância para o negócio do cliente. Como exemplo, posso citar uma impressora fiscal que possui funções específicas, um leitor óptico e etc. Novamente a ponderação do que é importante para o negócio e para o sistema deve predominar nesse momento.
Herança de Atores
Outra característica com atores é a possibilidade de criar heranças entre eles (o mesmo que herança de classes). Fazer herança entre atores tem um papel fundamental bem específico no diagrama de caso de uso. Voltando para o exemplo da movimentação bancária (Figura 2), sabemos que não é só o cliente que pode sacar ou depositar dinheiro, mas os próprios funcionários do banco (caixa e gerente) também podem. Nesse caso, poderíamos colocar mais dois atores no diagrama de caso de uso indicando que eles também podem efetuar essas movimentações. Quando nos deparamos com essa situação, poderemos trabalhar com o conceito de herança de atores (Figura 3).
Na Figura 3, foi criado um ator abstrato chamado Usuário que é herdado pelos atores Cliente, Caixa e Gerente. O ator Usuário é quem irá executar os casos de uso Sacar Dinheiro e Depositar Dinheiro, sendo que dependendo do contexto na realidade será ou o cliente ou o caixa ou o gerente. Repare que o caso de uso Identificar Cliente foi renomeado para Identificar Usuário, pois agora pode ser qualquer um dos três a fazer a movimentação.
Outro ganho que temos ao usar a herança de atores é que começamos a mapear as permissões de acesso ao sistema. Por exemplo, na Figura 4 somente o ator Gerente é que pode abrir uma conta na agência, ou seja, os outros atores não terão essa permissão. O ator Cliente participa como ator secundário, pois ele deverá informar a senha da nova conta.
Caso de Uso
Como já explicado, um caso de uso mapeia a interação entre o ator e o sistema. Nesta seção apenas incrementarei as características de caso de uso dentro do diagrama de caso de uso.
Para uma perfeita compreensão do que um caso de uso controla, é fundamental que seu nome esteja dentro do contexto do negócio. Portanto, bons nomes de casos de uso são aqueles que o próprio cliente utiliza no seu dia a dia, por exemplo, Abrir Conta, Sacar Dinheiro e etc.
Herança de Casos de Uso
Assim como podemos criar herança entre os atores, também podemos criar herança entre os casos de uso. Essa característica tem o mesmo objetivo que uma herança de classes em um diagrama de classe, ou seja, quando queremos atribuir novas características ao caso de uso sem perder a sua essência, criamos casos de uso (filho) que herdam do caso de uso mais abstrato (pai). Para entendermos melhor vejamos a Figura 5. Observe que na Figura 5 existe um caso de uso abstrato chamado Consultar Saldo que serve para fazer as consultas do saldo da conta. No entanto, essa consulta pode ser feita na tela de um terminal ou ser impressa e dependendo da opção escolhida, a formatação das informações da consulta será diferente e até mesmo algumas informações poderão ser ou não apresentadas. Para resolver esse caso, foi feita a herança do caso de uso, criando os casos de uso Consultar Saldo Impresso e Consultar Saldo na Tela. O caso de uso Consultar Saldo terá todos os passos e regras comuns que serão usados pelos casos de uso filhos. Repare que a essência deles permanece inalterada, ou seja, consultar saldo. Apenas foram atribuídas funcionalidades diferentes para cada situação.
Reuso de Caso de Uso
Como demonstrado na Figura 4, podemos reutilizar casos de uso para aproveitarmos as mesmas interações entre ator e sistema. Em um diagrama, podemos reutilizar um caso de uso de duas formas possíveis:
Include
Essa característica significa que o caso de uso sempre será chamado. Como exemplo, na Figura 4, onde os casos de uso Sacar Dinheiro e Depositar Dinheiro incluem o caso de uso Identificar Usuário e o caso de uso Abrir Conta inclui Definir Cliente. Isso significa que os casos de uso Identificar Usuário e Definir Cliente sempre serão chamados quando Sacar Dinheiro, Depositar Dinheiro e Abrir Conta forem executados.
Extend
Essa característica significa que o caso de uso poderá ou não ser executado, ou seja, dependerá do resultado de uma condição de negócio para ser decidido se ele será executado. Casos de uso que estendem são executados nos cenários alternativos (cenários alternativos serão detalhados mais para frente). Como exemplo, veja na Figura 6 que o Auxiliar Administrativo ao inscrever um aluno em um treinamento poderá ou não atualizar os dados cadastrais do aluno. Se for a primeira vez que o aluno é inscrito no treinamento, então ele será cadastrado. Se for o segundo treinamento em diante o aluno poderá ter ou não seus dados cadastrais atualizados.
Conclusão
Nesta primeira parte vimos alguns erros na criação e especificação de casos de uso e como evitá-los. Também vimos seus conceitos, características e a importância do caso de uso no desenvolvimento de software. Na segunda parte do artigo explicarei detalhadamente como especificar casos de uso.
