quinta-feira, outubro 18, 2007

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

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


Podemos resumir a atividade de Design de Caso de Uso como aquela aonde os elementos de design se encontram com os mecanismo arquiteturais. É onde se refina a análise de caso de uso (se esta tiver sido feita). No design de caso de uso focamos na solução e, portanto, devemos descrever as interações de forma a capturar como o sistema funciona em sua plataforma específica.

Desse modo, a realização de caso de uso de design terá elementos similares à análise de caso de uso. Ele terá um diagrama de classes participantes e um diagrama de interação para cada fluxo do caso de uso. Qual a diferença? Enquanto a análise de caso de uso fala em classes de análise e em estereótipos de classes de fronteira, de controle e de entidade (boundary, control, entity), o design de caso de uso fala em classes de design como JSPs, EJBs, Factory, COM+, etcs.

Lembre-se da grande "sacada" para reduzir o tamanho dos diagramas de interação. Podemos resumir em dois pontos:

1 - Utilizar os mecanismos de design: desse modo deve aparecer apenas a classe ou interface do mecanismo de design dentro do diagrama de interação.

2 - Utilizar os subsistemas: desse modo deve aparecer apenas a interface do subsistema dentro do diagrama de interação.

Com essas duas sacadas o design de caso de uso será mais enxuto e simples de produzir.

Um ponto importante: lembre-se que a modelagem é uma técnica. Sua equipe ou empresa deve definir como prefere criar a solução. Há empresas que preferirão usar o chamado Model-Driven Development (Desenvolvimento dirigido a modelos) ou MDA (Model-Driven Architecture). Portanto criarão os diagramas e a partir destes gerarão parte do código-fonte (a chamada forward engineering). Já outras preferem primeiro criar o código e depois gerar os diagramas a partir do código-fonte (a chamada reverse engineering ou engenharia reversa). Agora, o que é ruim é você ter os modelos totalmente desassociados do código. Isso gera perda de produtividade e frustração para todos os envolvidos.

Os diagramas são úteis não só para documentação mas também para facilitar as discussões e reuniões sobre arquitetura. A mensagem que quero passar é: use o modo que mais convém à sua equipe ou empresa. De qualquer uma das formas você terá bons resultados pois obterá código E modelos. Por isso é importante ter uma ferramenta de modelagem que realmente faça bem a forward/reverse engineering.

Criar manualmente o código a partir dos diagramas ou criar os diagramas a partir do código realmente são soluções "tiro no pé" e um convite à burocracia e lentidão. Otimize seu processo e tenha o bom dos dois mundos (código e modelos) com produtividade e qualidade usando boas ferramentas de modelagem.

Uma dica final: para quem quiser todos os detalhes da atividade de design de caso de uso e ainda contendo um exemplo de ponta a ponta vide o artigo Getting from use cases to code, Part 2: Use-Case Design 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 design de subsistemas e design de classes. Até a próxima!!!

Marcadores: , , ,

0 Comentários:

Postar um comentário

Links para este artigo:

Criar um link

<< Home


Veja as Estatísticas