computação

Análise Orientada a Objetos
O conceito de orientação a objetos surgiu com o intuito de minimizar os problemas encontrados até então na criação de softwares complexos, projetados por meio de decomposição funcional e sub-rotinas.
Podemos identificar como um dos maiores problemas a não existência de encapsulamento lógico para operações e dados, o que leva a não existência da divisão de tarefas por responsabilidades. O que leva a construção de longos trechos de código, muitas vezes difíceis de compreender devido ao acúmulo de responsabilidade que lhe é atribuído.
Por conseqüência, quanto mais complexo o software se torna, mais difícil se torna também a sua manutenção. Com isso aumentam os custos e o risco de confiabilidade do mesmo.
Nesse artigo veremos como efetuar uma analise orientada a objetos, com base em responsabilidade, extraída a partir das descrições de casos de uso.
Conceituando análise Orientada a Objetos
O foco da análise OO é no mapeamento de uma solução sistêmica para algum processo de negocio.
No inicio da análise OO, elaboramos os casos de uso. Estes juntamente com as descrições dos casos de uso formam uma espécie de ponte funcional entre o processo de negocio e a solução de software a ser produzida.
Outros dois documentos podem ser usados como fontes complementares aos casos de uso na análise OO:
· Glossário: onde estão definidos os significados de todos os termos inerentes ao negócio mapeado nos casos de uso;
· Documento de arquitetura: na utilização de possíveis mecanismos de análise, que são padrões de comportamento ou estrutura de uso recorrente e comprovadamente válido. Iremos falar mais sobre eles mais adiante. Normalmente, o resultado da análise orientada a objetos se traduz em diagramas UML de seqüência e classe, como mostra a Figura 1. Entretanto, outros diagramas UML podem ser usados nessa tarefa, desde que seja verificado algum ganho no entendimento ou mapeamento da solução com seu uso.

Figura 1.