Frameworks e Padrões de Projeto

Apesar dos avanços das técnicas de desenvolvimento de software, o processo de construção de software continua sendo extremamente complexo e relativamente oneroso. Uma das abordagens para diminuir a complexidade e aumentar a produtividade e a qualidade tem sido a proposição da reutilização de software. Entretanto, essa não é uma tarefa fácil, pois, depende de aspectos culturais, de formação e normalmente, as equipes são compostas de pessoas de conhecimentos heterogêneos.

Guia do artigo:

• O que é um Framework?
• Padrões de projeto

De acordo com [Gamma, 1995], uma coisa que os projetistas de software mais experientes sabem é que não devem resolver cada problema a partir de princípios elementares ou do zero, mas reutilizar soluções que funcionaram no passado. No entanto, segundo [Pree, 1995], apesar das óbvias vantagens da reutilização de software, a maior parte dos sistemas continua a ser desenvolvida a partir do zero. Com isso, pode-se concluir que a metáfora da reinvenção da roda é uma prática freqüente no processo de construção de software.

A ideia da reutilização não é nova e tão pouco exclusiva do processo de software. Contudo, ela é antiga e teve início no momento em que as pessoas começaram a encontrar soluções consistentes para os problemas, motivadas pela idéia de que, uma vez encontrada a solução, ela poderia ser aplicada a novos problemas. A aplicação de uma solução, repetida por várias vezes, acaba por torná-la aceita, generalizada e padronizada. Temos visto isso em outras áreas, na Física, Matemática, etc. No âmbito da computação, a Ciência da Computação, em particular a Engenharia de Software, tem buscado estabelecer critérios para definir e projetar soluções que possam ser reutilizadas em diferentes momentos. No entanto, faz-se necessário definir o que caracteriza o termo reutilização de software. Esse é o ponto que estimula o debate, haja vista, que dependendo da escola, ele pode ser definido de diferentes formas. Contudo, de forma genérica, pode-se entender a reutilização como um processo de construir sistemas a partir de software ou artefatos de software existente, ao invés de construí-lo a partir do zero. Não importa se ela se dá em partes ou em sua plenitude, extrapolando a barreira do código.

A Orientação a Objetos – OO surgiu como um poderoso instrumento para o desenvolvimento de sistemas de acordo com os princípios propostos pela Engenharia de software, principalmente no que diz respeito à reutilização. Por esse motivo, ela ganhou maior notoriedade dentre os paradigmas disponíveis, na prática de Engenharia de Software. Segundo [Jones, 2001], os objetos tornaram-se os blocos de construção onipresente do software moderno e a orientação a objetos o paradigma dominante da era contemporânea. O objeto representou para o software o papel desempenhado pelas placas no hardware, buscando estruturar uma arquitetura baseada em componentes. Entretanto, é um erro considerar que a Orientação a Objetos possui como subproduto a reutilização de software. Por isso, se explica que somente por utilizar a orientação a objetos não há garantias da produção de componentes, e conseqüentemente da reutilização em massa.

Um dos benefícios básicos da reutilização é proporcionar uma maior produtividade e melhora na qualidade, haja vista, que, o software reutilizável, demanda mais testes e garantia de qualidade, simplesmente porque as conseqüências de um erro são mais sérias e o uso contínuo ocasiona uma maior probabilidade de detecção de erros.

Uma das propostas da reutilização aceita na área da OO, é a de usar frameworks para domínios específicos, que poderiam ser instanciados para produzir novos produtos no mesmo domínio.

O que é um Framework?

É uma técnica da Orientação a Objetos, voltada para a reutilização que se beneficia de três características das linguagens de programação orientadas a objetos: abstração, polimorfismo e herança.

Um framework descreve a arquitetura de um sistema orientado a objetos, os tipos de objetos e as interações entre os mesmos. Ele pode ser vislumbrado como o esqueleto – template – de uma aplicação que pode ser customizado pelo programador e aplicado a um conjunto de aplicações de um mesmo domínio. Com frameworks não se busca apenas reutilizar simples componentes de software, mas subsistemas, aumentando assim o grau de reutilização e contribuindo para uma melhor qualidade do produto – software.

Para [Johnson, 1997], a visão original de reutilização de software estava baseada em componentes. Os frameworks possuem interfaces mais complexas, mas são de mais fácil customização de que os componentes. O autor percebe frameworks e componentes como técnicas diferentes, mas que cooperam entre si, pois um framework pode facilitar a construção de novos componentes e fornecer uma interface padrão para os mesmos trocarem dados, manipularem erros e chamarem operações.

No ambiente da programação orientada a objetos, os frameworks são compostos por interfaces e classes abstratas e a sua instanciação, uso, ocorre através da especialização ou composição dos seus serviços. Por isso, pode-se afirmar que os frameworks são compostos por pontos fixos – frozen spots - ou também conhecidos como hook points, que são serviços já implementados pelo framework que normalmente realizam chamadas indiretas aos pontos host spots, que são funcionalidades, serviços, e que devem ser implementados, através da característica da realização – herança – pelos desenvolvedores que irão inserir os seus códigos inerentes ao domínio da aplicação. Ou seja, os frameworks são formados de pontos fixos e de pontos extensíveis, ou pontos que necessitam de complementação.

Os primeiros frameworks disponibilizados foram: Smalltalk Model-View-Controller (MVC) e MacApp, Object Liking and Embedding – OLE, Microsoft Distributed Common Object Model – DCOM, etc.

Segundo [Fayad, 1999], a utilização de frameworks apresenta os seguintes benefícios:

1. Melhora a modularização – encapsulamento dos detalhes voláteis de implementação através de interfaces estáveis.
2. Aumenta a reutilização – definição de componentes genéricos que podem ser replicados para criar novos sistemas.
3. Extensibilidade – favorecida pelo uso de métodos hooks que permitem que as aplicações estendam interfaces estáveis.
4. Inversão de controle – IoC – o código do desenvolvedor é chamado pelo código do framework. Dessa forma, o framework controla a estrutura e o fluxo de execução dos programas.

No entanto, para obter os benefícios prometido pelo framework é fundamental investir na qualidade do projeto do framework. O processo de construção de um framework é muito mais complexo do que de uma aplicação tradicional, devido à flexibilidade inerente e a capacidade de variação de um framework. Construir um framework, não é uma tarefa fácil. O caminho até a reutilização prometida é árduo, mas os benefícios justificam os desafios.

Padrões de projeto

Um conceito muito próximo ao dos frameworks é o de padrões de projeto – design patterns – o que freqüentemente confunde o desenvolvedor sobre o que caracteriza cada conceito e quais são as suas particularidades, semelhanças e relações.

Para [Fowler, 1997], os padrões descrevem maneiras comuns de fazer as coisas e são coletados por pessoas que identificam temas repetitivos em projetos. Essas pessoas identificam cada tema e o descrevem de modo que outras pessoas possam ler o padrão e ver como aplica-los.

Um padrão é muito mais que um modelo. Ele também deve incluir a razão pela qual ele é o que é. Freqüentemente diz-se que um padrão é uma solução para um problema em certo contexto. Um padrão deve identificar o problema claramente, explicar porque ele resolve o problema e também explicar em quais circunstâncias ele funciona ou não.

Padrões documentam frameworks e ajudam a garantir o uso correto de sua funcionalidade. Para [Gamma, 1995] o objetivo do uso de padrões é capturar a experiência de projetos de software de forma que os projetistas possam usá-la efetivamente. Além disso, [Johnson, 1997] argumenta que a uniformidade reduz o custo da manutenção de software, pois, os desenvolvedores podem migrar mais facilmente entre aplicações sem necessitar de aprender tudo de novo.

Padrões de projetos facilitam a reutilização de sistemas e arquiteturas bem sucedidas. Para [Johnson, 1997] padrões são elementos micro-arquiteturais de frameworks. Um framework usualmente utiliza muitos padrões, ou seja, padrões são menores do que muito frameworks, podendo ser vistos como seus blocos construtores, ou seja, as partes constituintes de um framework. Entretanto, um framework pode ser também um padrão.

Como os frameworks são descritos através de linguagens de programação, o aprendizado de um framework pode ser difícil para um desenvolvedor iniciante, requerendo muita leitura de código e contato com profissionais experientes. [Johnson, 1997] defende o uso de padrões como uma abordagem para melhorar a documentação de frameworks.

Conclusões

Podemos concluir, que os frameworks constituem uma das mais promissoras correntes tecnológicas para suportar reutilização de software em grande escala, modelando tanto a parte genérica – frozen spots – como as partes variáveis – hot spots – de um sistema. E que eles devem ser construídos fazendo uso dos padrões de projetos – design patterns – para melhor documentar a sua arquitetura e proporcionar um vocabulário uníssono entre os desenvolvedores.

Confira também

Linguagem JavaScript: objetos

Curso

O que são Servlets?

Curso