Casos de Uso - Embora seja uma técnica muito utilizada, ainda é mal compreendida – Parte 1

Nosso blog está mudando de endereço. Acesse www.wm2info.com.br.

Estou apresentando o primeiro de uma série de cinco posts que estou escrevendo sobre o assunto Modelagem de Casos de Uso. Cada post irá abordar diferentes aspectos dessa técnica (Bittner, 2003; pag.9) tão utilizada, no mundo inteiro, na elicitação de requisitos de software.

O que me motivou escrever sobre esse assunto foi o fato de perceber uma grande carência de conhecimentos dos fundamentos teóricos que devem referenciar o trabalho dos Analistas de Negócio, Analistas de Requisitos, Analistas de Sistemas, Arquitetos de Software e principalmente dos Gerentes e Líderes de Projeto.

Em cada projeto que me envolvo como consultor, mentor ou coach, noto que os profissionais envolvidos na gestão de requisitos desconhecem os pilares que fundamentam a elicitação de requisitos de software. Heroicamente, eles usam conhecimentos obtidos com colegas que também aprenderam como outros colegas e assim por diante. Admiro a coragem desses profissionais, pois como bons brasileiros são versáteis e “se viram” fazendo o projeto andar. O problema é que o uso equivocado de técnicas pode causar graves danos na qualidade final do produto.

Cada vez mais me convenço de que Casos de Uso é uma excelente técnica que deve ser usada para a elicitação de requisitos de software. Infelizmente ela tem sido bastante mal interpretada pelos membros das equipes de projetos de desenvolvimento de software.

Aproveito a oportunidade para salientar que, com o advento do Use Case 2.0 apresentado recentemente por Ivar Jacobson (Jacobson, 2011), o pai dos casos de uso, poderemos seguramente continuar a usar casos de uso em projetos ágeis, pois, se descritos apropriadamente, se convertem em excelentes contextos para a elicitação de Estórias do Usuário, tão utilizadas em metodologias ágeis como o SCRUM e XP.  

Percebo que muitos gerentes de projetos, ou qualquer profissional associado ao planejamento de projetos de software têm usado casos de uso como um repositório para toda e qualquer especificação endereçada à equipe de construção de aplicações. Com isso obtemos casos de uso extremamente longos, aninhando vários outros artefatos de diferentes níveis de abstrações elevando desnecessariamente a complexidade, dificultado a comunicação e confundindo usuários e desenvolvedores.

Com isso perde-se muito tempo para produzir e validar todos esses artefatos e depois, um outro tempão para compreender o que foi escrito. Frequentemente esses artefatos apresentam problemas de completeza, ambigüidade, falta de clareza, levando o desenvolvedor a retornar aos analistas de negócio ou usuário para completar ou entender os requisitos descritos. Tudo isso leva a um desperdício de tempo onerando o projeto.

Casos de uso é um artefato de nível de abstração conceitual. Não é de implementação. Por isso não deveríamos associá-los a telas. Telas ou protótipos de telas devem estar associados a caso de uso, mas não o contrário. Telas implementam casos de uso e possuem uma forte rastreabilidade entre eles, mas isso não quer dizer que uma tela ou protótipo de tela deva compor a descrição de um caso de uso.

A descrição de casos de uso deve ser feita de forma altamente abstrata, sem nenhuma inferência em soluções de implementação. Dessa forma poderemos deixar os casos de uso independentes e totalmente livres do impacto das freqüentes alterações das interfaces gráficas do usuário. Imagine, cada alteração que tiver na tela, ter que alterar também o caso de uso. Isso é um absurdo, pois irá onerar desnecessariamente o projeto.

Caso de uso é algo bem mais simples do que parece. Para melhor explicar vou contar uma história que resume como e porque surgiu os casos de uso. Em 1979 Tom DeMarco escreveu o livro "Structured Analysis and System Specification" (Claudiomir, 1999) onde ele apresentou os princípios básicos da Análise Estruturada. Paralelamente Gane e Sarson se juntaram às idéias de Tom DeMarco e publicaram o famosíssimo livro “Análise Estrutura de Sistemas”, ainda hoje vendido nas principais livrarias do mundo inteiro. A principal ferramenta apresentada era o Diagrama de Fluxo de Dados (DFD), ainda muito utilizada, principalmente em projetos para alta plataforma.

Isso trouxe uma enorme evolução e padronização na forma de conceber um sistema de software. A intenção original era trazer o usuário para a equipe de projeto no papel de co-autor na concepção da aplicação. Infelizmente isso não ocorreu como se esperava, porque o DFD é uma técnica composta de muitos elementos e regras, tais como Entidades Externas, Funções, Fluxos de Dados, Depósito de Dados, um conjunto de Diagramas mostrando a Decomposição Funcional partindo do nível zero (frequentemente chamado de Diagrama de Contexto) até chegar nas primitivas funcionais que corresponderiam a programas ou módulos de programas a serem codificados em uma determinada linguagem, naquela época, o nosso velho e eficaz COBOL.

O problema é que o Usuário não estava preparado para tudo isso. O que ele queria (e continua querendo) é somente uma coisa: software funcionando para resolver o problema dele. Como eles eram, e continuam sendo, leigos em Engenharia de Software, isso tudo era muito complexo para eles. Por isso a intenção de ter o Usuário como co-autor ficou frustrada.

Contudo, a necessidade de envolver os usuários em projetos de software continuou aumentando, porque as necessidades dos negócios elevavam constantemente a complexidade das soluções de software. Foi então, que no início da década 90, Ivar Jacobson, um dos três amigos que criaram a UML, desenvolveu uma técnica chamada de Casos de Uso. Seu objetivo era voltar a conquistar o Usuário. Por isso ele criou uma forma de diagrama extremamente simples que qualquer pessoa pudesse entender e usar. Era tão simples que mais parecia um desenho feito por uma criança de quatro anos.

O diagrama de Casos de Uso possui somente três elementos: Ator (representado por um bonequinho), Caso de Uso (representado por uma elipse) e uma Associação entre eles (representada por um tracinho). Veja bem, aquele tracinho não é um fluxo de dados. É somente uma associação, ou seja, um Ator está associado a um Caso de Uso. Nada mais do que isso. Tem mais outra coisa extremamente importante: não tem decomposição funcional. Fica tudo em um único diagrama. Em sistemas muito grandes, com muitos casos de uso, você até pode quebrar um diagrama de casos de uso em outros pequenos diagramas, mas isso é só uma sub-divisão seguindo algum critério para não deixar o diagrama muito grande. Isso NÃO É decomposição funcional. Todos os casos de uso de todos os diagramas possuem absolutamente o mesmo nível de abstração.

Então, logo de cara, vamos aprender uma coisa. Um caso de uso não corresponde a uma função de um DFD. Por favor, se você quer aprender modelagem de Casos de Uso, esqueça DFD. São paradigmas totalmente diferentes. DFD é uma técnica usada no paradigma de Análise Estruturada. Caso de Uso é outra coisa. É uma técnica pertencente ao paradigma Orientado a Objetos.

Vou confessar uma coisa para vocês. No fim da década de 90, quando iniciei meus estudos e pesquisas sobre UML, devido ao fato de já ter usado muito DFD, senti dificuldades para usar o conceito de Casos de Uso porque, inconscientemente buscava fazer uma paridade de um para outro, ou seja, com funções de DFD. Até que um amigo me disse: “enquanto não tirar o “chapéu” da análise estruturada, você não irá conseguir aplicar corretamente os conceitos de casos de uso”. Fiz isso e deu certo. Foi aí que vi que deveria guardar o DFD numa “gaveta”. Veja bem, não é jogar fora. É guardar numa “gaveta” em algum lugar no seu cérebro. Isso quer dizer que você não irá usá-la em projetos OO. Mas toda a experiência (“a manha”) já obtida no relacionamento com Usuário é extremamente bem vinda.

Hoje, como professor, percebo isso muito explicitamente em sala de aula. Alunos que iniciaram suas carreiras usando o paradigma OO entendem e aplicam com muito mais facilidade do que experientes Analistas de Sistema Seniores, com vinte ou mais anos de experiência no paradigma Análise Estruturada. Realmente, os analistas seniores conseguem entender muito bem o conceito de casos de uso, mas sentem dificuldades na hora de aplicar a técnica. Neste caso, além do treinamento formal em sala de aula, se faz necessária a aplicação de um processo de mentoring para ajudar, de forma personalizada, o aluno a aplicar corretamente a técnica.

No próximo post irei comentar sobre os fundamentos teóricos que envolvem a Modelagem de Casos de Uso.

BIBLIOGRAFIA

- Bittner, K; et. al.; Use Case Modeling; Addison-Wesley; 2003.

- Jacobson, I., Spence, I., Bitnner, K.; Use Case 2.0 – The Guide to Succeeding with Use Cases; Ivan Jacobson International, Dez/2011.

- Selner, Claudiomir; Análise de Requisitos para sistemas de informações, utilizando as ferramentas da qualidade e processos de software; Dissertação submetida à Universidade Federal de Santa Catarina para obtenção do grau de Mestre em Engenharia; Florianópolis, Agosto/ 1999; obtido na internet em 20/01/2012;  http://www.eps.ufsc.br/disserta99/selner/cap3.html;