Nos ciclos de desenvolvimento de sistemas, costumamos ter as fases de análise e design. Vamos ver neste artigo, um exemplo de AD orientada a objetos com UML.
Na fase de análise os envolvidos devem obter uma idéia clara do que o sistema deverá fazer, sem se preocupar com detalhes relacionados à maneira como ele irá implementar as funcionalidades levantadas nos requisitos do projeto.
Para buscar este entendimento, podemos utilizar interessantes propostas de mercado, baseado no levantamento e análise dos requisitos do projeto através de Casos de Uso da UML (Unified Modeling Language).
Após entrevistar os envolvidos no projeto da área de negócios do cliente, podemos analisar os Cenários de Caso de Uso identificados, elaborando e refinando diagramas de Caso de uso e de Atividades. Todas as informações levantadas devem ser registradas em algum documento formal baseado em propostas de mercado, veja propostas de Especificação de Caso de Uso e Relatório Sintético de Caso de Uso na referência bibliográfica deste artigo. Estes documentos devem ser validados pelos envolvidos no projeto e divulgados para toda a equipe do mesmo.
Veja abaixo, representação UML do Caso de Uso de um sistema no cenário responsável pela emissão de conta de restaurante.
Este digrama UML mostra claramente um usuário (Ator) e uma funcionalidade do sistema (Caso de Uso) que estaremos implementado em nosso sistema e deve ser elaborado na fase de análise de nosso projeto, vindo a incorporar a documentação técnica a ser aprovada e enviada para os desenvolvedores da aplicação.
A Especificação de Caso de Uso deve conter uma série de informações adicionais. Neste exemplo, poderíamos citar as informações e processamento abaixo para ser possível encerrar a conta:
- Em qual mesa se deseja encerrar a conta.
- Quais itens foram consumidos na mesa e qual o valor de cada um.
- Realizar processamento e emitir a conta.
- Registrar que o consumo da respectiva mesa está encerrado.
Como parte da análise, torna-se extremamente interessante termos o Diagrama de Atividades relacionado ao Caso de Uso. Este diagrama deve ser validado com os donos do requisito, para aprovação e corroboração de nosso entendimento do que deve ser efetivamente desenvolvido, mostrando inclusive regras de negócio envolvidas, quando possível.
Observe no diagrama abaixo como este diagrama torna muito claro o funcionamento, sequencia de eventos e regras de negócio envolvidos no mesmo.
Na fase de análise, podemos definir sem detalhamento as classes envolvidas no Caso de Uso, sendo que na fase de design teremos que detalhar as mesmas. Neste momento, algumas classes sugeridas na fase de análise podem deixar de ser consideradas enquanto muitas outras provavelmente irão aparecer, conforme evoluímos em nosso trabalho.
Veja abaixo, diagrama de classes inicial de nosso processo de modelagem.
Já na fase de design, temos que ter as classes muito bem definidas para termos um desenvolvimento correto, documentado, com facilidades de manutenção corretiva e evolutiva como a modelagem sugerida abaixo.
Na verdade, considero todo este processo muito empolgante e ainda existe muitos detalhes bem interessantes a se considerar na modelagem, tais como patterns, arquitetura, persistência de dados, …
Luck favors the prepared mind!
Veja exemplo completo juntamente com templates em Engenharia de Software na Prática: Editora Novatec, 2010. ISBN 978-85-7522-217-1
2 Comentários
Helio,
Sua abordagem sobre o assunto foi bem interessante.
Obrigado Leonardo 🙂