Dando prosseguimento à sequência de publicações que estou fazendo sobre Requisitos de Software, pretendo nesta segunda parte tratar do assunto Caso de Uso, porque é uma ferramenta que tem sido usada em todo o mundo. Corretamente usada, ou não, mas tem sido de enorme valia para projetos de desenvolvimento de sistemas de grande porte e de elevado grau de complexidade para alta e baixa plataformas.
Afinal de contas, o que é Caso de Uso? Existem algumas descrições que busquei na literatura para deixar claro e de forma inequívoca seu significado. Foram obtidas de autores de renome e fontes de aceitação internacional.
• A OMG – Object Management Group, conforme a UML Superstructure Specification, v2.0, Casos de Uso são meios para a especificação de usos necessários de um sistema. Normalmente, eles são usados para capturar os requisitos de um sistema, isto é, o que um sistema é suposto fazer. Observe que a OMG aborda o aspecto voltado para a captura de requisitos de software.
• Kurt Bittner no seu livro “Use Case Modeling”, afirma que Caso de Uso é uma técnica poderosa de modelagem de requisitos. Note que o autor salienta mais uma faceta do Caso de Uso, ou seja é uma técnica que pode ser usada na captura de requisitos de software.
• O RUP, por que vez, classifica Caso de Uso como um artefato. Neste ponto de vista o Caso de Uso é apresentado como um produto de trabalho que possui um ciclo de vida composto de fases que inicia na sua elicitação e termina na forma de um artefato implementado, testado e entregue ao usuário para uso operacional. Deve ser gerenciado como um importante Item de Configuração.
• O RUP acrescenta ainda um outro conceito, que descreve um conjunto de instâncias formadas por sequências de ações realizadas pelo sistema para produzir um resultado de valor observável pelo ator. São interações formando um diálogo entre o Usuário e o Sistema. Essa é a forma mais popular de entendimento do que significa Casos de Uso. Esse diálogo conta uma Estória de relacionamento entre o Usuário e o Sistema. Guarde esse termo “Estória”, pois iremos usá-la posteriormente nas próximas publicações que farei.
• Cockburn, no seu livro “Escrevendo Casos de Uso Eficazes” afirma que um Caso de Uso captura um contrato entre os stakeholders de um sistema sobre seu comportamento. É interessante notar que, usando Casos de Uso, podemos discutir soluções sem necessitar entrar em detalhes de implementação. Particularmente acho isso sensacional, porque nos permite concentrar nossa atenção na obtenção do valor esperado pelo usuário. Nesta ocasião, não estamos preocupados com telas e qualquer tipo de solução de interface gráfica. Estamos preocupados na eficácia do projeto, ou seja, em produzir o resultado de valor do ponto de vista do negócio.
• Cockburn afirma ainda que “casos de uso não especificam interfaces externas, formatos de dados, regras de negócio e fórmulas complexas. Eles constituem somente uma fração (talvez um terço) de todos os requisitos que você precisa coletar – uma fração muito importante, no entanto, uma fração”. Acho essa definição sensacional porque simplifica a especificação dos Casos de Uso, não descrevendo esses elementos (interfaces gráficas, tipos de dados, requisitos não-funcionais, regras de negócio, etc.). As Especificações de Casos de Uso referenciam esses elementos, mas não os descrevem.
Todas as definições acima listadas podem ser resumidas da seguinte forma sobre Casos de Uso:
• É uma técnica usada para a captura de requisitos do sistema.
• É um artefato que deve ser gerenciado como um item de configuração.
• Descreve interações entre o Usuário e o Sistema.
• Descrevem “cláusulas contratuais” entre o usuário e o projeto de desenvolvimento.
• Sua especificação não envolve a descrição de interfaces do usuário, interfaces com outros sistemas, tipos de dados, requisitos não-funcionais, fórmulas complexas e regras de negócio.
Percebo muito claramente os seguintes problemas na Modelagem de Casos de Uso.
1. Os templates usados na descrição dos casos de uso possuem itens desnecessários e contribuem fortemente para que as especificações sejam “gordas”. Noto que alguns analistas de qualidade dão muita atenção à forma, ou seja, à qualidade que eu, evandrionicamente, chamo de “qualidade cosmética”. Esquecem da essência do caso de uso, a qual é a produção do resultado de valor esperado pelo usuário (ainda vou falar muito sobre isso nos próximos posts). A Gestão da Qualidade deve se preocupar com o conteúdo, garantindo que o conjunto dos Casos de Uso entregará os valores esperados pelos stakeholders. A palavra chave é “Valor”. Perde-se muito tempo e esforço no preenchimento obrigatório de campos. Já vi templates que obrigam o analista a justificar porque não está preenchendo um determinado campo que é considerado obrigatório, fazendo com que seja gasto um tempo valioso na tentativa de dar a justificativa exigida pela “qualidade”. Isso é um absurdo. É por isso que eu odeio templates. Veja uma crônica que postei algum tempo atrás sobre esse assunto.
2. Tenho percebido que interfaces gráficas (telas), produzidas a partir de especificações detalhadas de Casos de Uso, são modificadas quando apresentadas ao Usuário para validação. É válido notar que a descrição (detalhada) desses casos de uso já tinha sido validada pelo próprio Usuário. Isso mostra que o detalhamento das interações Usuário X Sistema na especificação de casos de uso, nem sempre tem sido eficaz, porque não é visual. Um protótipo de tala (que é visual) é extremamente mais eficaz do que um texto, por mais detalhado que seja. Por isso, recomendo fortemente que não gastem esforços e tempo no detalhamento das interações Usuário X Sistema. A especificação dos Casos de Uso deverá descrever o essencial, o suficiente para dar a percepção de que o produto de valor esperado pelo Usuário será entregue na ocasião em que ele executar o Caso de Uso. Tenho aplicado essa abordagem em vários projetos e obtido agilidade e melhoramento nas comunicações com os Usuários, Web Designers, Arquitetos, Projetistas e Desenvolvedores. Nos treinamentos que ministramos abordamos largamente todos esses aspectos.
3. A inserção de soluções de tecnologia na especificação de Casos de Uso traz problemas de sustentabilidade. Em outras palavras, os casos de uso, por si só, não se sustentam porque quando chegam na fase de design, frequentemente a tecnologia especificada no Caso de Uso é incompatível com os padrões gráficos ou padrões de navegação usados no projeto. Ocorre, nesta ocasião, um conflito. O que deve prevalecer? O que está especificado no Caso de Uso ou que já está padronizado e combinado com a Empresa contratante do projeto? Certamente, o que irá prevalecer é o padrão que foi definido pelos Web Designers e Arquitetos em conjunto com a equipe técnica da empresa contratante. Esses detalhes de implementação não são de conhecimento dos Analistas de Negócio. Por isso os Casos de Uso precisarão ser alterados para ficar corretos. Isso consumirá recursos, tempo, elevando o custo e reduzindo a produtividade, que é tudo que não queremos. É por isso que muita gente por aí, ingenuamente, joga a culpa nos Casos de Uso. A culpa não está na técnica, e sim naquele que usou erroneamente a técnica.
4. A UML é uma notação que possui itens de estrutura, de comportamento, de agrupamento e de anotações. Tenho observado que profissionais com pouco conhecimento em UML, tendem a inserir na especificação de Casos de Uso, todos esses itens que serão definidos ao longo do ciclo de vida do projeto. Isso eleva desnecessariamente a complexidade do Caso de Uso, além de não resolver o problema de comunicação com a equipe de desenvolvimento, porque geralmente esses elementos adicionais são incompletos e descritos de forma ambígua e inconsistente. Percebi que isso ocorre porque o RUP diz que o Modelo de Casos de Uso influencia na elaboração de todos os demais modelos desenvolvidos (quando é desenvolvido) ao longo do projeto. O RUP está correto, mas isso não significa que elementos desses modelos devam constar da especificação dos Casos de Uso. Modelo de Caso de Uso é uma coisa, Modelo de Design é outra coisa, Modelo de Implementação também é outra coisa, e assim por diante. Esses modelos possuem elementos que realizam os Casos de Uso, mas isso não significa que fazem parte da especificação dos Casos de Uso. Lembrem-se do que Cockburn afirmou (veja acima) que Casos de Uso capturam somente um terço dos requisitos de um sistema. Os demais requisitos são capturados através de outras técnicas e artefatos. Casos de uso não é uma panacéia que veio para resolver todos os problemas da Engenharia de Software. É simplesmente um item de um dos 13 (treze) diagramas oferecidos pela UML.
Conclusão.
• A agilidade em um projeto é obtida, não na pressa, mas nas mínimas coisas, ou seja, na forma que os artefatos são produzidos e principalmente na comunicação. Lembrem-se sempre disso, a comunicação é um dos maiores pontos de atenção de um projeto, pois é fonte de muitos riscos.
• Nunca misture elementos de diferentes níveis de abstração em um único artefato. Por exemplo: Não insira soluções de tecnologia em um documento que deveria abordar aspectos conceituais. Soluções de tecnologia pertencem ao nível de abstração de implementação. Casos de Uso pertencem ao nível de abstração conceitual. É como óleo e água. Não se misturam.
• Caso de uso é uma ferramenta gerencial e operacional. Ela é excelente para o Gerenciamento de Escopo de projetos de software. Com uso do conceito de rastreabilidade, poderemos facilmente gerenciar mudanças de requisitos, tão frequentes nos projetos que participamos.
• Casos de Uso permitem a captura de requisitos. Isso não quer dizer que todos os requisitos capturados são descritos na Especificação dos Casos de Uso. Existem artefatos apropriados para cada tipo de requisito, regra de negócio, estrutura de dados, interfaces gráficas, etc.
• O objetivo da Modelagem de Casos de Uso não é definir as interfaces gráficas e sim definir os valores que o sistema irá produzir para o negócio. Esta é a essência da modelagem de casos de uso. Um bom Modelo de Casos de Uso se converte em um guia para a elaboração do Modelo de Design, Modelo de Implementação, Modelo de Implantação (deploy) e Modelo de Processos da aplicação. O conjunto desses modelos forma o Modelo de Visões Arquiteturais 4+1, que é o cerne da arquitetura de uma aplicação.
• Para concluir gostaria de deixar a seguinte mensagem: “Tudo que for fazer, faça-o com agilidade. Agilidade não é fazer as coisas apressadamente. Agilidade é fazer somente as coisas essenciais”.
BIBLIOGRAFIA.
1. Bittner, K; et. al.; Use Case Modeling; Addison-Wesley; 2003.
2. Jacobson, I., Spence, I., Bitnner, K.; Use Case 2.0 – The Guide to Succeeding with Use Cases; Ivan Jacobson International, Dez/2011.
3. OMG – Object Management Group; UML Superstructure Specification, v2.0.
4. Cockburn, A.; Escrevendo Casos de Uso Eficazes. Bookman, 2001.
5. BOOCH, G.; et al.; UML Guia do Usuário; Editora Campus; 2005.
6. RUP – Rational Unified Process. Versão 2002.
Afinal de contas, o que é Caso de Uso? Existem algumas descrições que busquei na literatura para deixar claro e de forma inequívoca seu significado. Foram obtidas de autores de renome e fontes de aceitação internacional.
• A OMG – Object Management Group, conforme a UML Superstructure Specification, v2.0, Casos de Uso são meios para a especificação de usos necessários de um sistema. Normalmente, eles são usados para capturar os requisitos de um sistema, isto é, o que um sistema é suposto fazer. Observe que a OMG aborda o aspecto voltado para a captura de requisitos de software.
• Kurt Bittner no seu livro “Use Case Modeling”, afirma que Caso de Uso é uma técnica poderosa de modelagem de requisitos. Note que o autor salienta mais uma faceta do Caso de Uso, ou seja é uma técnica que pode ser usada na captura de requisitos de software.
• O RUP, por que vez, classifica Caso de Uso como um artefato. Neste ponto de vista o Caso de Uso é apresentado como um produto de trabalho que possui um ciclo de vida composto de fases que inicia na sua elicitação e termina na forma de um artefato implementado, testado e entregue ao usuário para uso operacional. Deve ser gerenciado como um importante Item de Configuração.
• O RUP acrescenta ainda um outro conceito, que descreve um conjunto de instâncias formadas por sequências de ações realizadas pelo sistema para produzir um resultado de valor observável pelo ator. São interações formando um diálogo entre o Usuário e o Sistema. Essa é a forma mais popular de entendimento do que significa Casos de Uso. Esse diálogo conta uma Estória de relacionamento entre o Usuário e o Sistema. Guarde esse termo “Estória”, pois iremos usá-la posteriormente nas próximas publicações que farei.
• Cockburn, no seu livro “Escrevendo Casos de Uso Eficazes” afirma que um Caso de Uso captura um contrato entre os stakeholders de um sistema sobre seu comportamento. É interessante notar que, usando Casos de Uso, podemos discutir soluções sem necessitar entrar em detalhes de implementação. Particularmente acho isso sensacional, porque nos permite concentrar nossa atenção na obtenção do valor esperado pelo usuário. Nesta ocasião, não estamos preocupados com telas e qualquer tipo de solução de interface gráfica. Estamos preocupados na eficácia do projeto, ou seja, em produzir o resultado de valor do ponto de vista do negócio.
• Cockburn afirma ainda que “casos de uso não especificam interfaces externas, formatos de dados, regras de negócio e fórmulas complexas. Eles constituem somente uma fração (talvez um terço) de todos os requisitos que você precisa coletar – uma fração muito importante, no entanto, uma fração”. Acho essa definição sensacional porque simplifica a especificação dos Casos de Uso, não descrevendo esses elementos (interfaces gráficas, tipos de dados, requisitos não-funcionais, regras de negócio, etc.). As Especificações de Casos de Uso referenciam esses elementos, mas não os descrevem.
Todas as definições acima listadas podem ser resumidas da seguinte forma sobre Casos de Uso:
• É uma técnica usada para a captura de requisitos do sistema.
• É um artefato que deve ser gerenciado como um item de configuração.
• Descreve interações entre o Usuário e o Sistema.
• Descrevem “cláusulas contratuais” entre o usuário e o projeto de desenvolvimento.
• Sua especificação não envolve a descrição de interfaces do usuário, interfaces com outros sistemas, tipos de dados, requisitos não-funcionais, fórmulas complexas e regras de negócio.
Percebo muito claramente os seguintes problemas na Modelagem de Casos de Uso.
1. Os templates usados na descrição dos casos de uso possuem itens desnecessários e contribuem fortemente para que as especificações sejam “gordas”. Noto que alguns analistas de qualidade dão muita atenção à forma, ou seja, à qualidade que eu, evandrionicamente, chamo de “qualidade cosmética”. Esquecem da essência do caso de uso, a qual é a produção do resultado de valor esperado pelo usuário (ainda vou falar muito sobre isso nos próximos posts). A Gestão da Qualidade deve se preocupar com o conteúdo, garantindo que o conjunto dos Casos de Uso entregará os valores esperados pelos stakeholders. A palavra chave é “Valor”. Perde-se muito tempo e esforço no preenchimento obrigatório de campos. Já vi templates que obrigam o analista a justificar porque não está preenchendo um determinado campo que é considerado obrigatório, fazendo com que seja gasto um tempo valioso na tentativa de dar a justificativa exigida pela “qualidade”. Isso é um absurdo. É por isso que eu odeio templates. Veja uma crônica que postei algum tempo atrás sobre esse assunto.
2. Tenho percebido que interfaces gráficas (telas), produzidas a partir de especificações detalhadas de Casos de Uso, são modificadas quando apresentadas ao Usuário para validação. É válido notar que a descrição (detalhada) desses casos de uso já tinha sido validada pelo próprio Usuário. Isso mostra que o detalhamento das interações Usuário X Sistema na especificação de casos de uso, nem sempre tem sido eficaz, porque não é visual. Um protótipo de tala (que é visual) é extremamente mais eficaz do que um texto, por mais detalhado que seja. Por isso, recomendo fortemente que não gastem esforços e tempo no detalhamento das interações Usuário X Sistema. A especificação dos Casos de Uso deverá descrever o essencial, o suficiente para dar a percepção de que o produto de valor esperado pelo Usuário será entregue na ocasião em que ele executar o Caso de Uso. Tenho aplicado essa abordagem em vários projetos e obtido agilidade e melhoramento nas comunicações com os Usuários, Web Designers, Arquitetos, Projetistas e Desenvolvedores. Nos treinamentos que ministramos abordamos largamente todos esses aspectos.
3. A inserção de soluções de tecnologia na especificação de Casos de Uso traz problemas de sustentabilidade. Em outras palavras, os casos de uso, por si só, não se sustentam porque quando chegam na fase de design, frequentemente a tecnologia especificada no Caso de Uso é incompatível com os padrões gráficos ou padrões de navegação usados no projeto. Ocorre, nesta ocasião, um conflito. O que deve prevalecer? O que está especificado no Caso de Uso ou que já está padronizado e combinado com a Empresa contratante do projeto? Certamente, o que irá prevalecer é o padrão que foi definido pelos Web Designers e Arquitetos em conjunto com a equipe técnica da empresa contratante. Esses detalhes de implementação não são de conhecimento dos Analistas de Negócio. Por isso os Casos de Uso precisarão ser alterados para ficar corretos. Isso consumirá recursos, tempo, elevando o custo e reduzindo a produtividade, que é tudo que não queremos. É por isso que muita gente por aí, ingenuamente, joga a culpa nos Casos de Uso. A culpa não está na técnica, e sim naquele que usou erroneamente a técnica.
4. A UML é uma notação que possui itens de estrutura, de comportamento, de agrupamento e de anotações. Tenho observado que profissionais com pouco conhecimento em UML, tendem a inserir na especificação de Casos de Uso, todos esses itens que serão definidos ao longo do ciclo de vida do projeto. Isso eleva desnecessariamente a complexidade do Caso de Uso, além de não resolver o problema de comunicação com a equipe de desenvolvimento, porque geralmente esses elementos adicionais são incompletos e descritos de forma ambígua e inconsistente. Percebi que isso ocorre porque o RUP diz que o Modelo de Casos de Uso influencia na elaboração de todos os demais modelos desenvolvidos (quando é desenvolvido) ao longo do projeto. O RUP está correto, mas isso não significa que elementos desses modelos devam constar da especificação dos Casos de Uso. Modelo de Caso de Uso é uma coisa, Modelo de Design é outra coisa, Modelo de Implementação também é outra coisa, e assim por diante. Esses modelos possuem elementos que realizam os Casos de Uso, mas isso não significa que fazem parte da especificação dos Casos de Uso. Lembrem-se do que Cockburn afirmou (veja acima) que Casos de Uso capturam somente um terço dos requisitos de um sistema. Os demais requisitos são capturados através de outras técnicas e artefatos. Casos de uso não é uma panacéia que veio para resolver todos os problemas da Engenharia de Software. É simplesmente um item de um dos 13 (treze) diagramas oferecidos pela UML.
Conclusão.
• A agilidade em um projeto é obtida, não na pressa, mas nas mínimas coisas, ou seja, na forma que os artefatos são produzidos e principalmente na comunicação. Lembrem-se sempre disso, a comunicação é um dos maiores pontos de atenção de um projeto, pois é fonte de muitos riscos.
• Nunca misture elementos de diferentes níveis de abstração em um único artefato. Por exemplo: Não insira soluções de tecnologia em um documento que deveria abordar aspectos conceituais. Soluções de tecnologia pertencem ao nível de abstração de implementação. Casos de Uso pertencem ao nível de abstração conceitual. É como óleo e água. Não se misturam.
• Caso de uso é uma ferramenta gerencial e operacional. Ela é excelente para o Gerenciamento de Escopo de projetos de software. Com uso do conceito de rastreabilidade, poderemos facilmente gerenciar mudanças de requisitos, tão frequentes nos projetos que participamos.
• Casos de Uso permitem a captura de requisitos. Isso não quer dizer que todos os requisitos capturados são descritos na Especificação dos Casos de Uso. Existem artefatos apropriados para cada tipo de requisito, regra de negócio, estrutura de dados, interfaces gráficas, etc.
• O objetivo da Modelagem de Casos de Uso não é definir as interfaces gráficas e sim definir os valores que o sistema irá produzir para o negócio. Esta é a essência da modelagem de casos de uso. Um bom Modelo de Casos de Uso se converte em um guia para a elaboração do Modelo de Design, Modelo de Implementação, Modelo de Implantação (deploy) e Modelo de Processos da aplicação. O conjunto desses modelos forma o Modelo de Visões Arquiteturais 4+1, que é o cerne da arquitetura de uma aplicação.
• Para concluir gostaria de deixar a seguinte mensagem: “Tudo que for fazer, faça-o com agilidade. Agilidade não é fazer as coisas apressadamente. Agilidade é fazer somente as coisas essenciais”.
BIBLIOGRAFIA.
1. Bittner, K; et. al.; Use Case Modeling; Addison-Wesley; 2003.
2. Jacobson, I., Spence, I., Bitnner, K.; Use Case 2.0 – The Guide to Succeeding with Use Cases; Ivan Jacobson International, Dez/2011.
3. OMG – Object Management Group; UML Superstructure Specification, v2.0.
4. Cockburn, A.; Escrevendo Casos de Uso Eficazes. Bookman, 2001.
5. BOOCH, G.; et al.; UML Guia do Usuário; Editora Campus; 2005.
6. RUP – Rational Unified Process. Versão 2002.
