quarta-feira, outubro 10, 2007

Análise de Caso de Uso no RUP e OpenUP / Série Análise e Design - Parte 3

Conforme visto no artigo anterior (parte 2) da série Análise e Design, trataremos agora acerca da atividade Análise de Caso de Uso (Use Case Analysis em inglês).

Primeiro um parênteses importante: quando falamos em análise estamos falando no que o Rational Unified Process chama de uma "solução idealizada". Já estamos desmembrando os elementos e responsabilidades a partir dos requisitos, mas sem ainda definir uma solução e uma plataforma concreta de implementação. Quando falamos da solução concreta então estamos tratando do design.

Podemos resumir a atividade de análise de caso de uso como aquela onde identificamos as classes de nosso sistema, ainda no nível de análise. As responsabilidades(que se transformarão em operações e métodos) das classes de análise são identificadas com o uso de diagramas de interação (O diagrama de sequência e o diagrama de comunicação são os dois tipos de diagramas de interação na UML 2.0). Porém existe um método disciplinado para a criação dos diagramas de classes e os diagramas de interação, e esse ponto é o mais crucial para se entender o processo de elaboração da solução no RUP.

O conceito fundamental para entendermos a disciplina de análise e design do RUP aparece nessa atividade de análise de caso de uso. Esse conceito se chama realização de caso de uso (use case realization). A realização de caso de uso nada mais é que um conjunto de diagramas da UML que, em conjunto, validam as classes, responsabilidades e interações entre objetos necessários para fornecer o comportamento de um caso de uso em particular. Portanto, teremos sempre uma realização de caso de uso para cada caso de uso identificado durante a disciplina de requisitos.

Esse conceito de realização de caso de uso não é apenas central para facilitar o trabalho de desenvolvimento da solução, mas também é o segredo do RUP para manter a rastreabilidade bidirecional entre requisitos e código. A partir do momento que você utilizou o conceito de realização de caso de uso você terá dentro de cada um deles um diagrama de classes participantes. Esse diagrama mostrará todas as classes que compõem um caso de uso. Portanto obterá a rastreabilidade do requisito para o código. Também terá diagramas de sequência (um para cada fluxo), que mostrarão quais operações serão afetadas caso você altere um determinado fluxo (básico ou alternativo).

Caso você queira analisar ao contrário poderá fazer uma busca na sua ferramenta de modelagem (a maioria delas possui essa função) para achar em quais realizações de caso de uso uma determinada classe está. Desse modo você também obtém a rastreabilidade do código para o requisito e obterá uma vantagem significativa para fazer uma análise de impacto de mudanças em um caso de uso. Também poderá se livrar da incômoda e infame matriz de rastreabilidade para rastrear classes para requisitos!

Não descreverei o passo a passo de como fazer a atividade de análise de caso de uso (para isso vide o artigo de Evans citado no final), mas darei algumas dicas e lembretes:

1 - Os principais diagramas de uma realização de caso de uso são: diagrama de classes participantes e diagramas de interação.

2 - Você poderá ter um diagrama de classes participantes para cada realização de caso de uso. Recomenda-se fazê-lo, especialmente se você precisar da rastreabilidade bidirecional

3 - Quantos diagramas de interação você deve fazer? Se seguir a regra do Processo Unificado você fará um diagrama de interação para cada fluxo do caso de uso. Não se faz por cenário porque o número de cenários de um caso de uso tende a ser maior que o número de fluxos e, além disso, ocorreria redundância de informações em cenários que utilizam os mesmos fluxos.

4 - Eu, particularmente, prefiro o uso do diagrama de sequência do que o diagrama de comunicação. O diagrama de sequência facilita a visualização do fluxo temporal das mensagens.

5 - Seja pragmático. Muitas vezes me perguntam se TODOS os fluxos devem possuir um diagrama de sequência. De acordo com o RUP isso seria o ideal. Mas analise a sua situação específica e verifique se eles serão úteis. Fluxos mais simples talvez não necessitem de diagramas de sequência. Mas é recomendável realizar os diagramas de sequência de, pelo menos, todos os fluxos arquiteturalmente significativos da solução.

6 - Lembre-se que o RUP é um framework de processo. Você deve customizá-lo conforme suas necessidades. Há equipes experientes que pulam a etapa de análise de caso de uso para ir diretamente para o design de caso de uso. A análise de caso de uso é útil para equipes inexperientes e também para sistemas onde o domínio do negócio é menos conhecido pelos desenvolvedores. Nada impede também que essa atividade seja feita pelos analistas de requisitos. Lembre-se que a análise de caso de uso ainda não entra nos aspectos técnicos da solução.

Uma dica final: para quem quiser todos os detalhes da atividade de análise de caso de uso e ainda contendo um exemplo de ponta a ponta vide o artigo Getting from use cases to code, Part 1: Use-Case Analysis do grande mestre Gary Evans. Recomendo fortemente a leitura pormenorizada tanto para arquitetos e desenvolvedores novatos como para os experientes.

No próximo artigo trataremos da atividade de Identificação de Elementos de Design. Até lá!

Marcadores: , , ,

1 Comentários:

At 2:08 PM, Blogger Advocatus Diaboli disse...

Olá Papo,
Achei muito interessante o teu artigo, porém fiquei em dúvida quando afirmaste que o RUP orienta que se faça um diagrama de interação para cada fluxo de caso de uso, e não cada cenário de caso de uso. Eu tinha a idéia que é correto pensar em cenários, e criar diagramas para os principais e não lembro de ter lido esta diferenção no RUP. A justificativa que o número de cenários é maior que o de fluxos não cairia por terra com a utilização apenas dos pricipais cenários como diagrama de interação? Fiquei com esta dúvida ao ler o teu post.

Abraços e parabéns pelo webblog!

 

Postar um comentário

Links para este artigo:

Criar um link

<< Home


Veja as Estatísticas