| |
| Acadêmico(a): Marcio Carlos Grott |
| Título: Reutilização de Soluções com Patterns e Frameworks na Camada de Negócio |
| |
| Introdução: |
Nos últimos anos tem-se verificado o grande avanço no uso da tecnologia de orientação a objetos. Desde o início da década de 90 tem-se acompanhado, a princípio na comunidade acadêmica e após nas empresas, a crescente adoção da orientação a objetos para o desenvolvimento de aplicações. Este avanço deve-se, principalmente, às soluções propostas por esta tecnologia, as quais amenizam os efeitos dos problemas gerados pela crise de software. No começo, algumas empresas viam com ressalvas os benefícios trazidos pela orientação a objetos, devido a pouca produtividade inicial conseguida por seus desenvolvedores; entretanto, passados agora alguns anos, não existem mais dúvidas quanto à sua adoção, sendo apenas uma questão de tempo para completa utilização de seus princípios (GAMA, 2000; SINTES, 2002).
Como conseqüência da adoção da tecnologia orientada a objetos para o desenvolvimento de aplicativos, houve uma explosão de métodos, linguagens e ferramentas que implementam, de uma forma ou de outra, todos os conceitos apresentados por esta tecnologia. Hoje, na indústria de software, existe uma tentativa de padronizar uma linguagem para especificação de sistemas orientados a objetos, a Unified Modeling Language (UML). Em linguagens de programação tem-se uma série delas que favorecem a implementação dos requisitos da aplicação; só para citar alguns casos, tem-se C++, SmallTalk, e mais recente Java.
Para que os softwares possam atender os requisitos cada vez mais complexos, a utilização de orientação a objetos tem proporcionado aos desenvolvedores o uso de herança, encapsulamento e polimorfismo que permite ser feita a reutilização de soluções, o que tem sido procurado por toda a comunidade envolvida no desenvolvimento de novas soluções na implementação de sistemas (SINTES, 2002).
Os projetistas de sistemas devem encontrar os objetos e fatorá-los em classes no nível correto de granularidade, definindo as interfaces das classes e as hierarquias de herança estabelecendo as relações chaves entres eles, criando projetos específicos para resolver o problema, mas também genérico o suficiente para atender futuros problemas e requisitos (GAMA, 2000). Os objetos bem modelados fazem com que os programadores ganhem mais tempo na implementação. Depois de modeladas as classes bases e testadas, os desenvolvedores precisam apenas se preocupar com a implementação da especialização da subclasse criada (ALUR, 2002).
Para se poder reutilizar uma maior quantidade de soluções, não basta ter escrito classes que descrevem toda a complexidade do projeto. Os projetistas novatos tendem a usar técnicas não orientadas a objetos pela sobrecarga de opções disponíveis. Sistemas cada vez mais complexos tendem a ter um número de classes cada vez maior, dificultando o desenvolvedor na codificação. Com o passar dos anos de experiência dos arquitetos em projetar soluções, observou-se que a essência dos problemas é semelhante e que quando especializavam as classes bases, o que é difícil conseguir na primeira vez, ganhavam maior produtividade no desenvolvimento, fazendo a reutilização de soluções corretas e que comprovadamente funcionavam (GAMA, 2000; SUN MYCROSYSTEM, 2002).
Observando que na essência os problemas assemelham-se, os projetistas começaram a documentar as soluções criadas durante os anos. Essa documentação foi sendo aprimorada e formaram um pattern de desenvolvimento. Os patterns, segundo Alur (2002), permitem documentar um problema conhecido e recorrente (que surgem várias vezes durante o projeto) e sua solução em um contexto específico e comunicar esse conhecimento para outras pessoas. Cada pattern tem uma aplicação específica dentro da arquitetura do software composto de multicamadas que separam a lógica de negócio, da interface do usuário e do acesso aos dados persistentes.
Sistemas em multicamadas é uma evolução dos sistemas monolíticos, que concentravam as regras de negócio, os dados e as interfaces do usuário em uma única máquina que predominantemente eram os Mainframes. Surgindo as redes locais que conectavam as máquinas, a arquitetura de sistema Cliente/Servidor difundiu-se separando as camadas de regra de negócio e interface dos dados. Conceitualmente uma aplicação pode ter múltiplas camadas, mas a mais popular é a em três camadas (tree-tier); constituindo em camada de interface do usuário, a camada de regras de negócio e acesso à banco de dados. Cada camada de abstração do sistema tem soluções especiais para problemas recorrentes em um contexto e, dessa forma, os patterns foram capturados em muitos níveis de abstração e em inúmeros domínios (GAMA, 2000; ALUR, 2002).
Os patterns podem ser agrupados em um framework (PREE, 1995). Booch (1994) define “frameworks como coleção de classes que fornece um conjunto de serviços para um domínio particular”, contém um conjunto de classes no qual foram aplicados um ou vários patterns na sua modelagem. Os frameworks proporcionam um alto grau de reutilização, pois a partir do mesmo outros sistemas podem herdar funcionalidades reutilizando a solução desenvolvida e testada em vários outros sistemas já implementados ou que futuramente sejam implementados.
Hoje se tem um bom número de patterns catalogados onde uma análise destes permitirá compreendê-los, avaliá-los nos aspectos que tangem a reutilização da solução seguindo as características do projeto, elucidando sua aplicabilidade na resolução de problemas recorrentes e exemplificá-los com a implementação de soluções visando o reaproveitamento da solução implementada.
|
| |
|
