Após perder alguns contratos por falta de metodologia e boas práticas no desenvolvimento de sistemas, a diretoria executiva da consultoria em que você trabalha decide que a partir do mês que vem todos os projetos irão utilizar Linguagem de Modelagem Unificada.

Após o susto inicial, você percebe que trata-se de UML (Ufa! Pelo menos você já ouviu falar nisso).

No desespero, pois a empresa nunca utilizou estes conceitos no passado, contratam um profissional de mercado que diz ser o “sabe tudo” da UML, que então passa a difundir o conhecimento para a empresa.

Abaixo está um exemplo de diagrama de caso de uso que este profissional (que trabalhou muito com DFD no passado) difundiu pela empresa:

Diagrama de caso de uso real, encontrado em documentação de empresa de grande porte. Sem comentários.

Passados seis meses do início da utilização da UML, a consultoria consegue alguns novos contratos pois agora já utiliza esta ferramenta.

O sentimento dos desenvolvedores é de que a UML só burocratizou e dificultou o processo de desenvolvimento, já que agora nada é feito sem antes ser documentado (com o uso da UML). No entanto os desenvolvedores nem sequer olham para o que foi escrito. Batem um papo de cinco minutos com quem escreveu o documento com o intuito de saber o que precisa ser feito e vão programar em seguida.

Como os analistas de negócio, já perceberam que ninguém lê os casos de uso que escrevem, as rotinas são documentadas com frases como “regra de negócio 01: obter crédito. Dispensa comentários pois todos já conhecem bem a regra”.

A recém criada área de qualidade realiza testes empíricos, sem a consulta aos documentos UML, já que eles dizem muito pouco (ou nada) sobre o negócio e a empresa não entende porque mesmo com a adoção de ferramentas e métodos para melhorar a área de desenvolvimento a empresa não dá o salto imaginado.

Apesar do entendimento do que seja a UML e como extrair melhores resultados desta ferramenta, a história acima ainda é muito comum nos departamentos de TI em nossas empresas.

Abaixo, deixo algumas dicas para você não cair na armadilha acima na hora de escrever um caso de uso (de verdade!).

1. Caso de Uso diz respeito a negócio e não a sistema

Quando for escrever um caso de uso, esqueça as rotinas do programa; pense no negócio e nas regras deste negócio.

Jamais pense em “usuário clica na opção funcionário dentro do menu cadastros, na janela principal da aplicação”.

2. Caso de Uso agrupa funcionalidade e não rotina do sistema

Ao realizar um levantamento inicial para determinar quais casos de uso fazer, pense nos usuários e nos objetivos destes usuários e não nas funções que o sistema terá de executar.

Para cada objetivo dos usuários, escreva um caso de uso.

Por exemplo, em uma clínica médica, o objetivo do usuário é “Recepcionar Cliente” (que deveria ser o nome do caso de uso) e não “Fazer LogIn”, “Manter Cliente”, “Agendar Consulta” e “Efetuar Pagamento”, como tenho observado no dia-a-dia.

3. Caso de Uso agrega valor para o usuário

Ao dar um nome para seu caso de uso, faça com que fique bem claro para qualquer pessoa (principalmente para aquelas que não conhecem nada de informática) qual o valor que o caso de uso agrega para o usuário.

Um bom exemplo é o famoso “Manter Clientes”. Para quem está habituado a trabalhar com TI, fica claro que é um CRUD (cadastro básico) de clientes, mas aos olhos de um diretor de marketing de uma empresa, “Manter Clientes” pode ser entendido como as rotinas básicas de CRM (relacionamento com o cliente).

Ou seja, rotinas para listar os clientes que não compram a mais de “n” meses, rotinas de retenção de clientes por meio de promoções, etc. Ao nomear seus casos de uso, não deixe dúvidas quanto ao valor que está sendo agregado ao usuário.

4. Caso de Uso não deve ser escrito por programadores

Um erro muito comum cometido por empresas é atribuir a programadores a função de escrever casos de uso. Nada contra os programadores, mas em geral eles tem uma cabeça muito voltada a rotinas do sistema o que dificulta enxergar o valor agregado e as regras de negócio separadamente dos códigos de programação.

O ideal é contratar analistas de negócio, preferencialmente que nunca programaram, mas com muita facilidade em descrever processos.

5. Caso de Uso é textual

Caso de Uso é escrito e não usa nenhuma figura para decorá-lo ou deixá-lo “bonitinho”.

Existe o diagrama de caso de uso que deve ser usado para facilitar a visualização macro das funcionalidades do sistema, mas não cometa o erro de fazer somente o diagrama e chamá-lo de caso de uso, sem ter o descritivo completo de cada caso de uso utilizado pelo sistema, contendo os atores, os seus objetivos, o fluxo principal, o fluxo alternativo, quais são as pré e pós-condições e quais as regras de negócio utilizadas.

Espero que este artigo tenha o ajudado a compreender melhor a razão de existência dos casos de uso dentro do modelo unificado e o prepare para escrever casos de uso que sirvam de base para todo o processo de desenvolvimento, sendo aproveitado pelos arquitetos de software para elaboração da arquitetura dos sistemas, pelo pessoal do design para ter a primeira idéia de elaboração de telas, pelos analistas para que escrevam os modelos de classe e pela área de qualidade, para que valide aquilo que o sistema faz.

Caso de uso em sua essência é uma ferramenta absolutamente indispensável para o processo e desenvolvimento de software, mas infelizmente vem sendo subutilizado no dia-a-dia, muito mais como um marketing para vender serviços do que por aquilo que pode acrescentar à empresa em termos de eficiência e redução de erros.

Se você deseja ler um pouco mais sobre UML, sugiro a leitura do livro “Applying UML and Patterns”, que aborda além da UML, o uso desta ferramenta para escrever códigos orientados a objeto.

Para tirar dúvidas ou consultar-me sobre dúvidas na implantação de caso de uso, escreva para falecom@renatoucha.com.br

[Webinsider]

…………………………

Conheça os serviços de conteúdo da Rock Content..

Acompanhe o Webinsider no Twitter.

Renato Ucha

Renato Ucha é formado em administração de empresas, especializado em gestão de projetos. Possui vasta experiência na área, além de dar palestras e escrever sobre o assunto.