Abordagem de Frameworks e Design Patterns para desenvolvimento de Aplicações
Approach Frameworks and Design Patterns for Application Development
Demetrio da Silva Passos1 Augusto Nogueira Zadra2
Resumo: Este artigo tem como tema uma análise sobre benefícios do desenvolvimento de aplicativos com a abordagem de Framework e o uso de Design Patterns, tendo em vista que essa abordagem vem crescendo nos últimos tempos, com o surgimento de uma grande diversidade de frameworks para desenvolvimento de novas aplicações que, pode não garantir a confiança e segurança dos aplicativos, pois é desconhecida a forma com que são tratadas as soluções propostas, no que se refere a estrutura, integração de componentes e reuso. Trata-se de uma pesquisa exploratória. Palavras chave: Design Patterns, Framework, Desenvolvimento, Programação Orientada a Objetos (POO).
1 INTRODUÇÃO
Este artigo tem como objetivo fazer uma análise dos aspectos de desenvolvimento de aplicações com abordagem baseada em frameworks, o uso de design patterns, levando em conta suas desvantagens bem como seus benefícios e suas características.
Frameworks para desenvolvimento de aplicações vêm de uma constante evolução que se deu naturalmente da forma como se produz aplicações. Na década de 80, existia um conceito que era denominado de paradigma clássico ou
estruturado3, que a princípio se mostrava este conceito se mostrava promissor, pois
era baseado em uma estruturada linear bem definida, porém com o aumento das demandas por aplicações mais robustas ficava a quem do esperado. (SCHACH 2009).
Com a evolução do paradigma clássico, criou-se o paradigma de Programação Orientada a Objetos (POO), onde se podia, fazer a reutilização do
código, com a modularização4 de trechos aplicações de grande porte poderiam ser
implementadas e mantidas e o processo de construção de aplicações seria
1Graduando em Sistemas de Informação pela Faculdade Infórium de Tecnologia. [email protected] 2
Graduado em Ciência da Computação, Especialista em Engenharia de Software, Mestrando em Tecnologia da Informação.
3Paradigma clássico ou estruturado significa o nome dado a uma das primeiras metodologias no processo de desenvolvimento de
software.
4Modularização é o processo no qual se divide um trecho de código em partes menores no qual pode ser usado em qualquer parte do programa. (SCHACH, 2009).
acelerado, pois não era necessária a reescrita de grande parte do código. A organização de um código modularizado foi um ganho significativo com melhor legibilidade e o processo de manutenção ficou mais fácil. (SCHACH 2009).
Um dos pontos fundamentais da Engenharia de Softwares é prover o reuso com códigos de fácil adaptação e para propósito uso comum, observou-se que a Programação Orientada a Objetos (POO), provia objetos específicos para aplicações específicas, era necessário iniciar uma aplicação do zero a cada novo projeto, tanto na parte lógica quanto na parte estrutural, nesse sentido a necessidade de técnicas que provessem uma forma padronizada e que efetivamente promovesse o reuso de código. O design patterns era uma forma de se ter padrões de projetos e o framework para desenvolvimento de aplicações, se encarregava da questão do reuso de código. (SOMMERVILE 2007).
Os frameworks são aplicações inacabadas, que o desenvolvedor irá modelar para o seu propósito de domínio do negócio, para um framework ter a capacidade de ser escalável e reutilizável, a sua complexidade de funções internas é alta, pois é na maioria das vezes desconhecida a forma como é implementado o framework de aplicações, podendo gerar incertezas quanto aos seus benefícios, as desvantagens e a segurança dos aplicativos a serem gerados com esta abordagem.
Assim delimitou-se o tema deste artigo a elencar os benefícios e as desvantagens do desenvolvimento de aplicações utilizando a abordagem de framework e design patterns.
O objetivo geral é apresentar os benefícios e as desvantagens do uso de Frameworks para Desenvolvimento de Aplicações. São objetivos específicos definir e conceituar Frameworks para Desenvolvimento de Aplicações; Design Patterns; Programação Orientada a Objetos.
A pergunta norteadora deste estudo é no sentido de mostrar os benefícios e as desvantagens do uso de frameworks para desenvolvimento de sotfware.
A pesquisa bibliográfica, fontes secundárias, tem como base e autores tais como Sommervile, (2007); Schach, (2009); Barreto Junior; (2006).
Para compreensão deste tema este artigo foi dividido em quatro seções. A
seção1 introdução é indicativa do conteúdo deste estudo. A seção 2 apresenta uma
Objetos (POO), frameworks para desenvolvimento de aplicativos, o Conceito de
Design Patterns e suas características. A seção 3 mostra a discussão sobre os
benefícios e as desvantagens do uso de framework para o desenvolvimento de
aplicações. A seção4 tece as conclusões do trabalho.
2 ABORDAGEM TEÓRICA
O embasamento teórico deste trabalho tem como base os conceitos gerais sobre a Programação Orientada a Objetos (POO), os conceitos gerais de Design Patterns (Padrões de Projetos) bom como os conceitos de Frameworks de Desenvolvimento de Softwares.
2.1 Programação Orientada a Objetos (POO)
Entre as idéias fundamentais básicas quem compõe a tecnologia orientada a objetos, pode-se destacar alguns conceitos:
a) Objeto
Um objeto pode ser qualquer coisa a que se refira a algo do mundo real ou algo abstrato, a respeito do qual armazena-se dados e os métodos que fazem a manipulação dos mesmos. (MARTIN, 1995).
b) Classe
Uma classe é definida por uma implementação de algum tipo de objeto. Ela pode especificar a estrutura de dados e métodos operacionais que a compõem onde se aplicam a cada um de seus objetos. (MARTIN, 1995).
c) Métodos
Os métodos especificam maneiras que podem conter algum tipo de operação ou processamento pelo qual os dados de um objeto são manipulados. (MARTIN, 1995).
d) Herança
Um tipo de objeto de alto nível pode ser especializado em tipos de objetos com níveis mais baixos, criando-se subtipos que também pode ser denominado de generalização. A generalização declara que as propriedades e métodos de um tipo
de objeto de alto nível podem ser aplicados a seus subtipos, assim a herança ou generalização torna as propriedades e métodos de um objeto pai (objeto de alto nível) fisicamente disponível para reuso por seus objetos filhos (objeto de nível mais baixo). (MARTIN, 1995).
e) Encapsulamento
A forma com que se empacota dos dados e métodos pode ser denominado encapsulamento. O objeto torna invisíveis seus dados para outros objetos e permite que os seus próprios dados sejam acessados por intermédio de seus próprios métodos, protegendo-os contra alterações não permitidas e não intencional. (MARTIN, 1995).
f) Polimorfismo
Métodos constantemente podem exigir um processo de customização a fim de atender a necessidades específicas de uma operação, para conseguir fazer reuso de código, pode se utilizar recursos para que métodos assumem muitas formas de implementação dependendo do tipo de objeto passado, essa abordagem denomina-se polimorfismo. (MARTIN, 1995).
A Programação Orientada a Objetos (POO) pode ser considerada como uma maneira de codificação com foco na reutilização, forma minimizar a escrita de códigos repetidos e na modularização de código que, por sua vez, fornece ao programador condições de organizar o entendimento e facilitar de manutenção de projetos de software seja de pequeno ou de grande porte. Segundo Lundberg & Matttsson(1996) citado por Barreto Júnior (2006, p.33), a orientação a objetos fornece funcionalidades para que classes possam ser reutilizadas, bem como métodos por meios de seus mecanismos de herança e polimorfismo.
A reutilização, segundo Schach (2009), refere-se ao uso de componentes ou códigos de um produto para facilitar o desenvolvimento de um novo produto que, talvez possa ter uma funcionalidade diferente do anterior. Um componente utilizável não precisa necessariamente ser um módulo ou um fragmento do código, ele pode ser um projeto, parte de um manual, um conjunto de dados de teste ou uma estimativa de um de custo de duração de um projeto.
No que se refere a reuso, para Schach (2009), existem dois tipos de reutilização: a reutilização oportunista e a reutilização deliberada, quando
desenvolvedores de um novo produto percebem que, um componente desenvolvido anteriormente pode ser reutilizado, nesse caso se trata de uma reutilização oportunista, pois seu propósito principal não foi a reutilização. Quanto à construção de componentes especialmente para a reutilização futura esta é denominada de reutilização deliberada. Essa abordagem tem como base o conceito de herança, pois o novo componente é baseado e adaptado dentro de uma perspectiva já modelada e com a vantagem de que foi testada e documentada fazendo-se para isso apenas a inclusão ou não de características para uma determinada função ou operação.
A característica da POO é quando um objeto tem a capacidade de reagir de maneiras diferentes e processar um resultado específico em um determinado momento. Para Schach(2009), implementações específicas de métodos derivados de uma classe pai, com tais métodos contendo nomes idênticos, quando chamados, reconhece qual método é o apropriado para o processamento, feito isto em tempo de execução. O ato de associar um objeto ao método apropriado é denominado vinculação dinâmica, além disso, pelo fato de um método poder ser aplicado a objetos de diferentes implementações, é denominado polimorfismo, que significa “capaz de assumir muitas formas”.
Com a crescente demanda por aplicações mais complexas, a tecnologia de POO, que provia melhor a forma de codificação de aplicações específicas, pois o nível de encapsulamento e abstração das classes e métodos abrangiam apenas aspectos de uma aplicação para um determinado fim, então, criou-se a necessidade do uso de um grau mais elevado de se fazer reuso das classes e métodos. Com fundamentos na POO uma aplicação seria facilmente mantida independentemente do nível de tamanho e complexidade, assim o conceito de framework começou a ser estudado e avaliado. (SOMMERVILLE 2007).
2.2 Design Patterns (Padrões de Projeto)
O reuso de código e componentes de software, tem como premissa códigos
adaptáveis e de uso comum. Para Sommerville (2007), quando regras de negócio5
extrapolam a linha comum entre seus componentes e interfaces devido a especificidade de requisitos, pode se tornar inviável o processo de reuso de
componentes. Segundo Sommerville (2007), ao se utilizar componentes prontos, é inevitável que se fique limitado às decisões de projetos do implementador do componente. Eles têm variações de algoritmos específicos aos objetos e interface dos componentes. Quando se tem conflito entre componente e requisitos específicos isto é, uma determinada característica ou propriedade para um único fim que poderá ter, o reuso é impossível ou introduz ineficiência ao sistema.
Para a solução destes conflitos de projetos, conforme Sommerville (2007), é necessário o reuso de projetos abstratos que não incluem detalhes da implementação, podendo o desenvolvedor implementar os projetos para atender à necessidades específicas. Essa abordagem do reuso foi incorporada aos padrões de projetos.
Para Somerville (2007), design patterns é uma descrição do problema e a essência da sua solução, dessa forma pode ser usada em aplicações diferentes. O padrão não é uma especificação detalhada. Pode se pensar nele como uma descrição de conhecimento e experiência acumulada, uma solução comprovada para um problema comum. Assim, padrões e linguagens de padrões são maneiras de descrever melhores práticas, bons projetos, e captam a experiência de uma maneira possível de ser reusada por outros. (SOMMERVILLE, 2007).
Buschmann(1996) citado por Carvalho Júnior(2014) 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.3 A característica do Design Patterns
Gamma, et al.(1995) citado por Sommerville (2007, p.279) definem os quatro elementos essenciais do design patterns:
1. Um nome que seja uma referência significativa para o padrão.
2. Uma descrição da área do problema que explique quando o padrão pode ser aplicado.
3. Uma descrição da solução das partes da solução de projetos, seus relacionamentos e suas responsabilidades, não sendo uma descrição de projeto concreta. É um template que pode ser instanciado de maneiras diferentes, muitas vezes sendo expressa de maneira gráfica que mostra
o relacionamento entre objetos e das classes de objetos na solução. 4. Uma declaração das conseqüências, os resultados e compromissos da
aplicação dos projetos, auxiliando o projetista a compreender se um padrão pode efetivamente ser aplicado em uma determinada situação. 2.4 Framework Conceitos Gerais
Os proponentes iniciais do desenvolvimento orientado a objetos conforme Sommerville (2007) sugeriam que objetos seria a abstração mais apropriada para o reuso. Contudo, constatou-se que objetos são muitas vezes pequenos e especializados demais para uma aplicação específica. Em vez disso, tornou-se claro que o reuso orientado a objetos é mais bem apoiado por um processo de desenvolvimento por meio de abstrações maiores chamadas frameworks.
Para Fayad et al. (1999b) e Johnson & Foote (1988) citado por Barreto Júnior (2006), um framework é um conjunto de classes que constitui um projeto abstrato para a solução de uma família de problemas. As famílias de aplicações podem ser facilmente entendidas quanto ao nível de aspectos comuns para umas com as outras, pois na maioria delas tem-se, por exemplo, interface com o usuário, níveis de acesso, elementos visuais semelhantes.
Neste sentido Sommerville (2007), afirma que um framework (ou framework de aplicação) é um projeto de subsistema composto por um conjunto de classes abstratas6 e concretas e as interfaces7 entre elas (Wirfs-Brock e Johnson, 1990).
Detalhes específicos do subsistema da aplicação são implementados pela adição de componentes e pelo fornecimento de implementações concretas de classes abstratas no framework. Os frameworks raramente são aplicações propriamente ditas. As aplicações são geralmente construídas pela integração de vários frameworks.
Existem atualmente frameworks para diversas categorias de aplicações dentre eles os levantados por Fayad e Schmidt (1997) citado por Sommerville (2007, p. 282):
1. Frameworks de infra-estrutura de sistemas. Com o propósito fornecer um apoio ao desenvolvimento de infra-estruturas de sistemas, como base de 6Classe abstrata são classes que não se pode instanciar, ela contem grupos de características comuns.
(www.javaprogressivo.net/2012/10/Polimorfismo--Classes-abstratas-e-Metodos-abstratos.html).
7Interface de classe trata-se de uma classe abstrata composta somente por métodos abstratos, só contendo as declarações dos métodos e constantes e não possui implementação. (www.javaprogressivo.net/2012/10/Interface-em-Java-implements-O-que-e-para-que-serve-como-funciona.html).
comunicação entre processos, integração com a interface com o usuário e no processo de codificação de compiladores.
2. Frameworks de integração de middleware8. Fornece um conjunto de classes e padrões de objetos gerenciados e associados que apóiam a comunicação e a troca de informações com os componentes de um sistema e fazem uso de componentes padronizados.
3. Frameworks de aplicações empresariais. Estão associados a aplicações de fins específicos podendo ser de grande ou médio porte, usando como princípio o conhecimento de domínio para desenvolvimento de aplicações para usuários finais.
3 BENEFÍCIOS E DESVANTAGENS COM USO DE FRAMEWORKS PARA DESENVOLVIMENTO DE APLICAÇÕES
Os benefícios
Com o reuso sendo um dos fatores principais para do uso de frameworks, Sommerville (2007) destaca benefícios como a confiança nos software, pois software reusado, experimentado e testado, deve ser mais confiável que software novo. Contribui para o uso eficiente dos especialistas, em vez de se fazer um trabalho repetidas vezes, os especialistas podem desenvolver software reusáveis englobando seus conhecimentos.
As vantagens de reuso de software são custos menores, desenvolvimento de software mais rápido e riscos baixos. A confiança no sistema é aumentada e os especialistas podem ser usados mais eficientemente pela concentração de seu conhecimento no projeto de componentes reusáveis. SOMMERVILLE (2007, p. 289).
A redução do risco do processo já que se conhece os custos, fator esse importante para o gerenciamento do projeto que reduz a margem de erro. Utilizar o benefício da conformidade dos padrões que ajudam a estabelecer um grau maior de confiança tanto por parte dos desenvolvedores pois, é preciso o conhecimento das diretrizes do projeto quanto do usuário do software, por exemplo fazendo uso de interfaces similares (SOMMERVILLE, 2007).
A utilização de frameworks no desenvolvimento de aplicações sugere que os sistemas sejam modulares, reusáveis e extensíveis. O encapsulamento promovido
8Um middleware é um software que trabalha no apoio a integração de componentes independentes, facilitando a comunicação entre os
com o uso de módulos pode se mostrar útil, pois há junções entre a aplicação e módulo que são bastante estáveis, juntamente com interfaces bem definidas e um local único de mudanças nos projetos e implementações o que diminui o esforço para se entender e manter uma aplicação construída com framework. O reuso levam a uma leitura do conhecimento em um domínio ou aspectos da infraestrutura da aplicação. As interfaces do framework promovem pontos de extensão que as aplicações estendem gerando instâncias que compartilham funcionalidades já definidas no framework, assim promovendo o aumento da produtividade dos desenvolvedores, que não precisam começar do zero, mantendo um nível de qualidade e confiabilidade do produto (BARRETO JUNIOR, 2006).
As desvantagens
São grandes os benefícios que o uso de Framework para desenvolvimento de aplicações pode proporcionar porém, pode existir alguns fatores que podem ser negativos quanto a utilização de framework. Para Fayad et al. (1999b) Citado por Barreto Júnior (2006), instituições que tentam construir e utilizar frameworks falham se não conseguirem resolver alguns obstáculos: esforço de desenvolvimento, curva de aprendizagem, integração eficiência, manutenção, validação e remoção de defeitos e falta de padrões.
O esforço se dá na fase de projeto do framework, pela alta complexidade de desenvolver aplicações complexas é difícil, desenvolver frameworks de alta qualidade, extensível e reusáveis para domínios de aplicações complexas é ainda mais difícil. (BARRETO JÚNIOR, 2006).
Destaca-se a afirmação de Barreto Júnior (2006, p. 39) sobre a curva de aprendizagem, “Aprender a usar um framework de aplicação leva tempo e incorre em custos. A menos que o esforço do aprendizado possa ser amortizado através do uso do framework em muitos projetos, ou em projetos duradouros o investimento pode não compensar”.
A integração pode ficar comprometida quando se faz o uso do framework de mais de um framework ou com sistemas de tecnologias antigas conforme sugere
Barreto Júnior (2006, p. 39) “O desafio da integração ocorre quando diversos frameworks são usados com outras tecnologias e com sistemas legados não previstos pela arquitetura do framework”.
A eficiência pode ficar comprometida com uso de frameworks. Como o framework usa várias formas de se fazer um determinado comportamento ou implementação, este recurso é imprescindível para tornar-se extensível e reusável, aplicações para uso específico podem ser mais eficiente, pois foi implementado sob um único propósito. Fayad et al. (1999b) citado por Barreto Júnior (2006, p.40), sugerem que para os frameworks de aplicações tornarem-se extensíveis, adiciona-se o nível de indireção. Aplicações genéricas tendem a obter deadiciona-sempenho inferior a aplicações específicas. Barreto Júnior (2006, p.40) indica que “Desta forma o desenvolvedor de aplicações deve considerar se os ganhos advindos do reuso compensam uma potencial perda de desempenho”.
Os Frameworks segundo Barreto Júnior (2006), necessitam de manutenção, seja para correção de erros, acréscimos de funcionalidades, pontos de extensão entre outras. Para tanto os mantenedores precisam ter um conhecimento profundo sobre os componentes internos e suas interdependências, até mesmo, em alguns casos a própria instância do framework pode sofrer alterações para acompanhar a evolução do framework. Cabe ao desenvolvedor da aplicação considerar o esforço gasto para obter os benefícios de uma nova versão do framework. A validação e remoção de erros se tornam um desafio, pois um framework é uma aplicação inacabada, dificultando a fase de testes do framework e de sua instância isoladamente, ate mesmo a depuração é dificultada pois o controle da aplicação é dividida entre o framework e a aplicação.
4 CONCLUSÃO
Sem dúvida o desenvolvimento de aplicações com o uso de frameworks, fornece ao desenvolvedor uma base sólida, com mecanismos e componentes que, agilizarão o processo de desenvolvimento de software e eles elevarão a qualidade do produto, um dos pontos essenciais na engenharia de software e conseqüentemente elevará o nível maturidade e experiência do desenvolvedor com
tais ferramentas. Um ganho importante com framework de desenvolvimento de aplicação, além de vários outros, com o conceito de design patterns já embutido na maioria dos frameworks, traz ao programa codificado uma estrutura interna sólida com classes, métodos e componentes estáveis, que por sua vez, fazendo o desenvolvedor focar-se no domínio da regra de negócio deixando a parte estrutural do sistema a cargo do framework.
Contudo o uso dessa abordagem deve ser feita um estudo minucioso do framework, pois como a complexidade exigida internamente por parte dos mecanismos que provem a parte portátil, extensível e reusável, uma vez que esses são puramente uma casca de software e não uma aplicação completa. Podem resultar em dor de cabeça, por exemplo, um mantenedor de um framework descontinua uma versão ou lança versões incompatíveis com a usada atualmente, seria um problema para futuros bug’s em uma aplicação. Assim a questão do uso ou não da abordagem de uso de frameworks para software, está mais ligado a habilidade do analista de escolher uma ferramenta que satisfaça a proposição do negócio, sem deixar de levar em conta o ciclo de vida da aplicação.
REFERÊNCIAS
BARRETO JÚNIOR, C. nunes. Agregando Frameworks de Infra-Estrutura em uma Arquitetura baseada em componentes: Um estudo de caso no ambiente Aulanet. 2006. 210f. Dissertação - Pontifícia Universidade Católica do Rio de Janeiro - PUC-RIO. Rio de Janeiro. 2006.
BUSINESS RULES GROUP. Disponível em :
<http://www.businessrulesgroup.org/defnbrg.shtml>. Acesso em 25 de novembro de 2014.
CARVALHO JÚNIOR, R. nelson. Padrões de Projeto e Framework no
Desenvolvimento de Software. Revista Pensar Tecnologia, Belo Horizonte, v. 2, n. 1, jan. 2013.
JAVA PROGRESSIVO NET. Disponível em :
<http://www.javaprogressivo.net/2012/10/Polimorfismo--Classes-abstratas-e-Metodos-abstratos.html>. Acesso em 26 de novembro de 2014.
JAVA PROGRESSIVO NET. Disponível em :
<http://www.javaprogressivo.net/2012/10/Interface-em-Java-implements-O-que-e-para-que-serve-como-funciona.html>. Acesso em 26 de novembro de 2014. MARTIN, James; ODELL, J. James. Análise e Projeto Orientados a Objeto.
Tradução José Carlos Barbosa dos Santos. São Paulo :Makron Book, 1995. 639p. SCHACH, Stephen R. Engenharia de Software: os paradigmas clássico & Orientado a Objetos. Tradução Ariovaldo Criesi. 7. ed. São Paulo: McGraw Hill, 2009. 618p. SOMMERVILLE, Ian. Engenharia de Software. Tradução Selma Shin Shimizu Melnikoff; Reginaldo Arakaki; Edilson de Andrade Barbosa. 8. ed. São Paulo: Addison Wesley, 2007. 552p.