Os Casos de Uso são usados para especificar o que um novo software deve fazer ou o que um software já existente faz (AMBLER, 2000, BOOCH et al., 1999). Para fazer esta especificação, as funções do software são definidas a partir de interações entre o usuário ou outros sistemas e o software. Essas interações são chamadas Caso de Uso e devem representar uma transação do negócio (JACOBSON et al., 1999). Neste contexto, o sistema é visto como uma caixa-preta que provê Casos de Uso, que são formas como o sistema pode ser usado (ERIKSSON et al., 1998, ENGELS et al., 2000).
A visão geral do software é provida por um modelo de Casos de Uso, onde são apresentados todos os Casos de Uso do software, a relação entre eles e os atores que participam de cada Caso de Uso (BOOCH et al., 1999; JACOBSON et al., 1999). Um ator representa um papel desempenhado por um grupo de usuários que
Representação de Requisitos Funcionais
tem um certo objetivo ao interagir com o software. Um Caso de Uso descreve possíveis comportamentos do software através de cenários. O cenário principal é o caso de sucesso, ou seja, aquele em que tudo transcorre conforme o esperado e deve corresponder à grande maioria das transações. Os outros cenários apresentam situações em que alguma barreira ou dificuldade pode provocar comportamentos específicos no software ou até mesmo impedir a realização da transação. O comportamento de um software em um cenário de um Caso de Uso é descrito por uma sequência de atividades que devem se realizar a partir de um evento ou estímulo realizado por um ator (MEDVIDOVIC et al., 2002; KRUCHTEN et al., 2002).
Ao organizar os requisitos de um software baseado em transações de negócio, que são claramente reconhecíveis e validáveis por desenvolvedores e usuários, os Casos de Uso facilitam a identificação, a elicitação e o acompanhamento da evolução dos requisitos durante todo o ciclo de vida do projeto e do software (RUI, 2007).
Ao se desenvolver um projeto orientado por Casos de Uso, como propõe o processo unificado2, estes passam a orientar a especificação, modelagem e programação das
transações de negócio, e com isso, servem como base para rastreabilidade entre todas as etapas do projeto e servir de apoio na manutenção e evolução do software (RUI, 2003; 2007).
O modelo de Casos de Uso é constituído por Diagramas de Caso de Uso e por uma especificação ou descrição do Caso de Uso. Os Diagramas de Caso de Uso são parte da UML e a figura 2 apresenta um diagrama de casos de uso seguindo o padrão UML (BOOCH et al., 1999).
2O Processo Unificado é um processo de desenvolvimento de software iterativo e incremental
bastante utilizado pela indústria no desenvolvimento de sistemas orientados a objeto.
Figura 2 – Exemplo de Caso de Uso
Como pode ser visto, o software tem o ator “Cliente” que participa do caso de uso “Ver Pedido”. Além do relacionamento entre o ator e o caso de uso, os diagramas UML de casos de uso permitem relacionar casos de uso entre si. Os relacionamentos permitidos pela UML entre casos de uso são:
• <<include>>: permite a inclusão de um Caso de Uso em outro e deve ser
usado quando existe no sistema um conjunto de passos comuns a vários casos de uso. Cria-se um Caso de Uso com estes passos comuns e, depois, usa-se o relacionamento <<include>> para referenciar os Casos de Uso incluídos, evitando reescrever os passos;
• <<extend>>: permite a extensão de um Caso de Uso e deve ser utilizado
quando se deseja acrescentar um comportamento no Caso de Uso estendido em determinadas condições. A extensão é usada para definir a partir de um Caso de Uso base, um comportamento opcional que o software pode ter, mas que não é obrigatório para atingir o objetivo do Caso de Uso;
• herança: permite a criação de um Caso de Uso genérico que tem
comportamento, requisitos, restrições e suposições comuns a vários Casos de Uso. Os Casos de Uso específicos herdam as características do Caso de Uso genérico e descrevem aquilo que eles tem de diferente.
Estes relacionamentos permitem uma reutilização de Casos de Uso e, com isso, aumentam a produtividade na especificação de sistemas.
A especificação ou descrição do Caso de Uso é, tipicamente, realizada na forma textual, mas pode ser feita também através de diagramas de sequência, atividade ou
Representação de Requisitos Funcionais
interação (ERIKSSON et al., 1997). Não existe uma forma rígida para especificar um Caso de Uso, mas espera-se que esta especificação contenha os atores, o evento que dá início ao Caso de Uso, as pré-condições, a sequência de atividades que devem ocorrer e as pós-condições. Usualmente define-se um padrão para esta especificação dentro de um projeto onde decide-se o que vai ser feito através de uma descrição textual e o que vai ser feito através de diagramas (BOOCH et al., 1999; JACOBSON et al., 1999).
Este padrão garante uma certa uniformidade na descrição de um Caso de Uso, e pode deixá-lo mais preciso, dependendo do grau de formalismo desejado. Esta flexibilidade no grau de formalismo é também um dos fatores do sucesso dos Casos de Uso (RUI, 2003; 2007). A precisão que pode ser oferecida pelos Casos de Uso é suficiente para a maioria dos projetos, mas não alcança a precisão dada quando se aplicam formalismos matemáticos. Nos poucos projetos que a precisão da especificação dos requisitos é o atributo mais importante, a alternativa são os métodos formais e por este motivo, eles serão detalhados na próxima seção.