PADRÕES DE PROJETO E FRAMEWORK NO DESENVOLVIMENTO DE SOFTWARE

PADRÕES DE PROJETO E FRAMEWORK NO DESENVOLVIMENTO DE SOFTWARE Nelson Ribeiro de Carvalho Júnior 1 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: nelson.junior@prodemge.gov.br

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 uma solução provada para um problema recorrente.

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 o algoritmo varie independentemente dos clientes que o utilizam.

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.