PADRÕES DE PROJETO E FRAMEWORK NO DESENVOLVIMENTO DE
SOFTWARE
1
Nelson Ribeiro de Carvalho Júnior
RESUMO
Atualmente o cenário mundial cuja dependência do software está cada vez
mais evidente requer que seu desenvolvimento seja de maneira rápida e
eficaz, os padrões de projeto e os frameworks surgem neste cenário como
grandes aliados provendo subsídios para que o desenvolvimento de software
possa ocorrer dentro deste objetivo esperado. Neste artigo, os conceitos
relacionados aos padrões de projetos e de framework serão discutidos de
maneira a prover um entendimento global deste paradigma.
Palavras-chave: Framework, Desenvolvimento de Software, Padrões de
Projeto
1. INTRODUÇÃO
A reutilização do software é um dos temas que tem recebido maior destaque
no meio especializado cujo objetivo é reaproveitar em projetos futuros grande
parte dos métodos e classes produzidas bem como as informações associadas
ao mesmo, de forma a diminuir o custo e aumentar a produtividade no
desenvolvimento e na própria evolução do produto. Desta maneira a idéia
básica deste paradigma é de que componentes de software sejam projetados e
implementados de forma que possam ser reusados em muitos sistemas
diferentes [Gamm95].
Nesta perspectiva os padrões de projeto e os frameworks têm sido
pesquisados na última década como uma forma promissora de reuso, não
1
Mestre em Modelagem Matemática Computacional pelo CEFET-MG. Especialista em Engenharia de
Software pela PUC-MG. Graduação em Ciência da Computação pela UNIPAC-Barbacena. Analista de
Sistemas da PRODEMGE. E-mail: [email protected]
2
somente de código mas também de projeto, análise, arquitetura e processo de
desenvolvimento. Através da utilização de padrões e framework é possível
encontrar soluções para diferentes tipos de problemas que ocorrem ao longo
do processo de desenvolvimento de software. Tais soluções, podem ser
reusadas por outros desenvolvedores ao confrontarem-se com problemas
similares aos problemas já resolvidos e documentados.
As seções seguintes destinam-se a dar uma visão geral sobre padrões de
projeto e frameworks discutindo de forma sucinta os conceitos relacionados a
este paradigma e a grande influência deles no desenvolvimento de software de
qualidade. Desta forma tais seções estão organizadas da seguinte maneira. Na
seção 2 são apresentadas as definições relativas aos padrões. Na seção 3 é
apresentada a definição de frameworks, 4 traz alguns conceitos interessantes
relacionados aos padrões de projetos, e por fim a seção 5 traz uma conclusão
a respeito do trabalho desenvolvido.
2. PADRÕES
2.1 Conceito
A origem dos padrões de projeto surge ao final da década de 70 através dos
livros escritos por [Alex77], livros estes que descrevem seu método para que a
documentação de padrões possa ser realizada. Apesar deste trabalho estar
ligado diretamente à arquitetura, o mesmo possui uma fundamentação básica
que pode ser abstraída e perfeitamente aplicada à área de software.
Porém este conceito fica adormecido por um período e ressurge em meados
da década de 80 em um Workshop sobre Especificação e Projeto para
Programação Orientada a Objetos [Beck87], onde neste workshop é
apresentado uma Linguagem de Padrões para projetar janelas em Smaltalk. A
partir deste momento muitos artigos, revistas e livros surgem com o intuito de
abordar de forma detalhada este tema. Tais trabalhos passam a descrever
uma série de soluções para problemas que ocorrem frequentemente no
3
processo de desenvolvimento de software e que podem ser utilizados por
outros desenvolvimentos, de forma a simplificar o desenvolvimento de novas
aplicações.
[Busc96] descreve um padrão como sendo uma solução para um problema
que ocorre com freqüência durante o desenvolvimento de software,
considerando o mesmo como sendo um par “problema/solução”. Desta forma
projetistas de software que estejam familiarizados com determinados padrões
podem aplicá-los diretamente a problemas de projeto, sem ter que redesenhar
uma solução que já existe.
2.2 Componentes de um padrão
Apesar dos padrões de software estarem definidos em categorias diferentes, a
descrição dos padrões, independentemente da categoria na qual estejam
inseridos, segue um linha comum onde são definidos os componentes
essenciais para que um padrão possa ser identificado. Abaixo estes
componentes são descritos [Appe97]:
•
Name – indica o nome do padrão, sendo que este deve ser o
mais significativo possível, de maneira a referi-se ao padrão e
ao conhecimento ou estrutura descritos por ele.
•
Problem – este parâmetro estabelece o problema a ser
resolvido pelo padrão, descrevendo a intenção e objetivos do
mesmo.
•
Context – estabelece as pré-condições dentro das quais o
problema e sua solução costumam ocorrer e para as quais a
solução é desejável, refletindo assim a aplicabilidade do
padrão.
4
•
Forces – descreve os impactos, influências e restrições
relevantes para o problema a ser resolvido. Bem como se
elas se interagem ou são conflitantes entre si e com os
objetivos a serem encontrados.
•
Solution – descreve os relacionamentos estáticos e a regras
dinâmicas descrevendo como obter o resultado desejado. Na
verdade fornece instruções que descrevem como o problema
é resolvido, podendo utilizar para isto texto, diagramas e
figuras.
•
Exemples – descreve uma ou mais aplicações do padrão,
ilustrando desta maneira como o padrão é aplicado e
transforma um determinado contexto em um contexto final.
•
Resulting Context – denota o retrato do sistema, estado ou
configuração, após a aplicação do padrão, ou seja, descreve
as pós-condições e efeitos colaterais do padrão.
•
Rationale – descreve uma explicação das regras ou passos
do padrão que explicam como e porque ele trata suas
influências contrárias, definidas em ‘Forces’ para alcançar os
objetivos, princípios e filosofia propostos.
•
Related Patterns: relata os relacionamentos estáticos e
dinâmicos desse padrão com outros dentro da mesma
linguagem ou sistemas de padrões
•
Know Users: relata as ocorrências conhecidas do padrão e
sua aplicação em sistemas existentes, ajudando desta
maneira a validar o padrão, verificando assim se o mesmo é
realmente
recorrente.
uma
solução
provada
para
um
problema
5
3. FRAMEWORK
3.1 Conceito
Framework ou arcabouço é uma abstração que une códigos comuns entre
vários projetos de software provendo uma funcionalidade genérica, um
framework pode atingir uma funcionalidade específica durante a programação
de uma aplicação, ao contrário das bibliotecas é o framework quem dita o fluxo
de controle da aplicação, chamado de Inversão de Controle(UFCG,2009).
O framework atua onde há funcionalidades em comum a várias
aplicações, porém para isso as aplicações devem ter algo razoavelmente
grande em comum para que o mesmo possa atingir á várias aplicações como
mostra a figura abaixo:
3.2 Características
O framework por ser criado a partir de um conjunto de classes possui
características peculiares para cada aplicação com um proposito em comum,
as principais características são:
•
Deve ser reusavel, possibilitando seu uso para varias outros
métodos e aplicações.
•
Deve ser extensível, ele contém funcionalidades abstratas (sem
implementação) que deve ser implementada.
•
Deve ser de uso seguro, o desenvolvedor de aplicações não pode
destruir o framework .
•
Devem ser eficiente, devido a seu uso em muitas situações,
algumas das quais poderão necessitar de eficiência
•
Deve ser completo para endereçar o domínio do problema
pretendido
6
4.APLICAÇÃO
4.1. Padrões de Projeto
Um sistema de padrões na verdade não passa de um conjunto coeso de
padrões co-relacionados que trabalham juntos com o intuito de apoiar a
construção e evolução de arquiteturas completas. Além dos sistemas de
padrões serem organizados em grupos de subgrupos relacionados em
múltiplos níveis, a seguir abordaremos os principais tipos com seus principais
padrões que são:
Padrões de criação: abstraem o processo de criação de objetos a partir da
instanciação de classes, exemplos:
Abstract Factory:: Fornece uma interface para a criação de famílias de
objetos relacionados ou dependentes sem especificar suas classes concretas.
Buillder: Ou seja de modo que o mesmo processo de construção possa criar
diferentes representações
Padrões estruturais: tratam da forma como classes e objetos estão
organizados para a formação de estruturas maiores, exemplos:
•
Adapter: Converte a interface de uma classe em outra interface
esperada pelos clientes, permitindo que certas classes trabalhem em
conjunto, pois de outra forma seria impossível por causa de suas
interfaces incompatíveis.
•
Bridge: Separa uma abstração da sua implementação, de modo que as
duas possam variar independentemente.
Padrões comportamentais: preocupam-se com algoritmos e a atribuição de
responsabilidade entre objetos.
•
Strategy: Define uma família de algoritmos, encapsula cada um deles e
os
faz
intercambiáveis,
permitindo
que
independentemente dos clientes que o utilizam.
o
algoritmo
varie
7
•
Templlate Method: Define o esqueleto de um algoritmo em uma
operação, postergando a definição de alguns passos para subclasses.
Permite que as subclasses redefinam certos passos de um algoritmo
sem mudar sua estrutura.
4.2. Framework
O framework por ser criado a partir de um conjunto de classes possui
características peculiares para cada aplicação com um proposito em comum,
as principais características são:
•
Deve ser reusavel, possibilitando seu uso para varias outros métodos e
aplicações.
•
Deve ser extensível, ele contém funcionalidades abstratas (sem
implementação) que deve ser implementada.
•
Deve ser de uso seguro, o desenvolvedor de aplicações não pode
destruir o framework .
•
Deve ser eficiente, devido a seu uso em muitas situações, algumas das
quais poderão necessitar de eficiência
•
Deve ser completo para endereçar o domínio do problema pretendido
Atualmente no mercado existem vários frameworks, prometendo
facilitar o dia a dia dos desenvolvedores de software e tornar mais ágil e
eficazes suas aplicações mas como vimos anteriormente não é nada fácil
encontrar um framework que atenda e supre todas as necessidades das
empresas. Apesar disto vamos ver alguns frameworks que se consolidam no
mercado e de certa forma atende as necessidades da empresas que o
adquiriram, são eles:
•
Microsoft NET (mais comumente conhecido .NET Framework) é uma
iniciativa da Microsoft em que visa uma plataforma única para
8
desenvolvimento e execução de sistemas e aplicações . A plataforma
.NET se baseia em um dos principios utilizados na tecnologia Java
(compiladores JIT), os programas desenvolvidos para ela são duplocompilados, ou seja são compilados duas vezes, uma na distribuição
(gerando um código que é conhecido como "bytecodes") e outra na
execução(wikipedia,2009).
•
NEO
é
um
framework
web
focado
na
produtividade.
Seu
desenvolvimento foi realizado para atender às necessidades dos
programadores. Várias ideias foram utilizadas com o objetivo de facilitar
a criação de sistemas. O NEO é um framework que possui seus códigos
vísiveis e bem distribuídos. Sendo assim, podemos observar melhor
seus relacionamentos e fluxos de mensagens internas (wikipedia,2009)..
•
jCompany Developer Suite é um conjunto de elementos Java EE
especialmente escrito para otimizar o esforço de criação e manutenção,
que vão de sistemas de suporte a processos de negócio. Seu principal
diferencial é a solução de produtividade completa para desenvolvimento
corporativo em Java EE, cujo principal componente é um framework de
integração, responsável por reutilizar, integrar e especializar dezenas de
outros com base em bibliotecas open source (wikipedia,2009).
4.3 Diferenças entre Framework e Padrões de Projeto
A diferença principal entre os Padrões de Projeto e os Frameworks é:
•
Padrões de Projeto é mais abstrato não possuindo codificação
diferentemente do framework,
•
Framework pode conter vários Padrões de Projeto, mas o contrário
nunca ocorrerá.
•
Framework sempre terá um domínio de aplicação particular, enquanto
Padrões de Projeto não ditam uma arquitetura de aplicação particular.
9
5. CONCLUSÃO
Padrões e Frameworks são criados para auxiliar uma parte repetida de um
determinado projeto de software, permitindo desta forma seu entendimento e
aplicação em um contexto particular. Sendo assim eles fornecem aos
projetistas e desenvolvedores de sistema uma ferramenta comum, facilitando a
comunicação entre projetistas e desenvolvedores. Além de que, constituem
uma base sólida de experiência para construção de software reutilizável,
atendendo assim a um dos grandes objetivos atuais da engenharia de
software.
Padrões e Frameworks deixam explícito o conhecimento sobre a
construção de softwares adquiridos ao longo dos anos por especialistas no
assunto, permitindo assim que o processo de desenvolvimento de software
possa ocorrer de forma mais reutilizável possível, sem que haja perdas neste
processo.
REFERÊNCIAS BIBLIOGRÁFICAS
[Alex77]- Christopher Alexander et. al., A Pattern Language, Oxford University
Press, New York, 1977.
[Appe97]- Appleton, Brad. Patterns and Software: Essential Concepts and
Terminology,
disponível
na
WWW
na
URL:
http://www.enteract.com/~bradappdocpatterns-intro.html.
[Beck87]- Beck, Kent; Cunningham, Ward. Using Pattern Languages for
Object-Oriented Programs, Technical Report nº CR-87-43, 1987,
disponível na WWW na URL: http://c2.com/doc/oopsla87.html
[Busc96]- Buschmann, F. et at. A System of Patterns, Wiley, 1996.
[Copl98]- James O. Coplien. Software Design Patterns: Common Questions
and Answers. In Linda Rising, editor, The Patterns Handbook:
Techniques, Strategies, and Applications, p. 311-320. Cambridge
University Press, New York, January 1998.
[Gamm95]-Gamma, E.; Helm, R.; Johnson, R.; Vlissides, J. Design Patterns Elements of Reusable Object-Oriented Software. Reading-MA,
Addison-Wesley, 1995.