Frameworks

34 2. Revis˜ao Bibliogr´afica promovendo independˆencia de cada uma delas. Camadas podem ser utilizadas para encapsular servic¸os de sistemas legados e para proteger os novos servic¸os de clientes legados. Uma desvantagem em adicionar um sistemas em camadas ´e adicionar sobrecarga de processamento reduzindo o desempenho.

• Suporte a c´odigo sobre demanda: REST permite que as funcionalidades do cliente possam ser estendidas baixando e executando o c´odigo na forma deappletsouscripts. Isto sim-plifica os clientes, melhora a extensibilidade, no entanto, reduz a visibilidade, portanto, ´e apenas uma restric¸˜ao opcional.

REST foi desenvolvida focando as necessidades de sistemas como um todo, sem restric¸˜oes, e gradualmente identificou-se e aplicou-se as restric¸˜oes para os elementos de forma incremental.

Vale ressaltar que como estilo arquitetˆonico, REST n˜ao especifica tecnologias, como os forma-tos (XML, por exemplo) ou protocolos (por exemplo, HTTP). Vocˆe pode ter um sistema baseado em REST em qualquer plataforma tecnol´ogica, sendo feito conforme suas restric¸˜oes(Fielding, 2000) (Mazzetti et al., 2009).

2.4Frameworks 35

2.4.1 Classificac¸ ˜ao

Osframeworkss˜ao classificados, quanto a prop´osito, em trˆes grupos (Fayad e Schmidt, 1997):

• Frameworksde Infra-estrutura: s˜ao usados para dar suporte a diversos tipos de aplicac¸˜ao, independentemente dos dom´ınios enderec¸ados por essas aplicac¸˜oes. Exemplos seriam frameworkspara sistemas operacionais, comunicac¸˜ao, redes e construc¸˜ao de interfaces.

• Frameworks de Integrac¸˜ao: normalmente s˜ao usados para integrar aplicac¸˜oes e compo-nentes distribu´ıdos, como frameworksCORBA (Common Object Request Broker Archi-tecture) ORB (Object Request Broker), DCOM (Distributed Component Object Model), implementac¸˜oes do padr˜ao ODMG(Object Data Management Group).

• Frameworksde Dom´ınio de Aplicac¸˜ao: representam esqueletos de aplicac¸˜oes para dom´ınios espec´ıficos, como telecomunicac¸˜oes, manufatura e engenharia financeira. Frameworks deste tipo capturam elementos invariantes de dom´ınio, e deixam em aberto aspectos espec´ıficos de cada aplicac¸˜ao.

Frameworksde Infra-estrutura e Integrac¸˜ao preocupam-se basicamente com problemas in-ternos de desenvolvimento de software e s˜ao independentes de dom´ınio de aplicac¸˜ao, enquanto frameworks de Dom´ınio de Aplicac¸˜ao tˆem o objetivo de apoiar o desenvolvimento de aplicac¸˜oes dirigidas ao usu´ario e produtos em dom´ınios espec´ıficos. Comparados com as outras categorias, frameworks de dom´ınio de aplicac¸˜ao s˜ao os mais dif´ıceis e custosos para se desenvolver e comercializar (Fayad e Schmidt, 1997) (Johnson, 1997).

Uma caracter´ıstica importante dos frameworks ´e que os m´etodos definidos pelo usu´ario para especializ´a-lo s˜ao chamados de dentro do pr´oprio framework, ao inv´es de serem chamados do c´odigo de aplicac¸˜ao do usu´ario (Johnson, 1997). O framework geralmente faz o papel de programa principal, coordenando e sequenciando as atividades da aplicac¸˜ao. Essa invers˜ao de controle d´a forc¸a ao framework para servir de esqueletos extens´ıveis. Os m´etodos fornecidos pelo usu´ario especializam os algoritmos gen´ericos definidos noframework para uma aplicac¸˜ao espec´ıfica.

Dependendo do modo como umframework´e adaptado e estendido, ele pode ser classificado como caixa-branca ou caixa-preta (Fayad e Schmidt, 1997) (Johnson, 1997).

Framework caixa-branca aplicam o reuso principalmente por meio do uso de heranc¸a e redefinic¸˜ao de operac¸˜oes, ou seja, o usu´ario deve criar subclasses das classes abstratas contidas noframeworkpara criar aplicac¸˜oes espec´ıficas. Por outro lado,framework caixa-preta aplicam o reuso por composic¸˜ao, ou seja, o usu´ario combina diversas classes concretas existentes no framework para obter a aplicac¸˜ao desejada. Enquanto para utilizar framework caixa-branca

36 2. Revis˜ao Bibliogr´afica o usu´ario deve entender detalhes de como ele funciona, no framework caixa-preta o usu´ario necessita de entender apenas a interface(Fayad e Schmidt, 1997).

2.4.2 Padr ˜ oes de Projeto

O trabalho pioneiro do arquiteto Cristopher Alexander (Alexander et al., 1977) introduziu o conceito de padr˜oes, catalogando um n´umero de 253 padr˜oes usados para resolver problemas da ´area de arquitetura, partindo de problemas de grande escala, como a organizac¸˜ao do mundo em regi˜oes, cidades, definic¸˜ao de espac¸os para agricultura, at´e padr˜oes de menor escala na construc¸˜ao de casas, como colocac¸˜ao de janelas numa casa, criac¸˜ao de alcovas, e assim por diante.

Os conceitos de padr˜oes e linguagens de padr˜oes comec¸aram a ser introduzidos na co-munidade de software no fim dos anos 80 e no in´ıcio dos anos 90, mas foram realmente conhecidos e popularizados com a publicac¸˜ao dos design patterns, da chamadaGang-of-Four, formada pelos pesquisadores Erich Gamma, Ralph Johnson, Richard Helm e John Vlissides (Gamma et al., 1994) . Eles criaram um cat´alogo de padr˜oes para o projeto de software orientado a objeto, documentando as suas experiˆencias na resoluc¸˜ao de problemas de projeto independentes de dom´ınio de aplicac¸˜ao. O cat´alogo registra diversas soluc¸˜oes satisfat´orias que eles encontraram durante o desenvolvimento de frameworks, relacionadas principalmente por problemas de reusabilidade, flexibilidade, modularidade, etc.

Conceitos e Definic¸ ˜oes

Padr˜ao (Pattern) ´e definido como o encapsulamento da descric¸˜ao abstrata e estruturada de uma soluc¸˜ao satisfat´oria para um problema que ocorre repetidamente dentro de um contexto, dado um conjunto de forc¸as ou restric¸˜oes que atuam sobre o problema. A descric¸˜ao de uma padr˜ao deve ser abstrata, pois se trata de um projeto abstrato, n˜ao de um projeto espec´ıfico, mas a descric¸˜ao de um padr˜ao pode fornecer sugest˜oes sobre quest˜oes de potenciais implementac¸˜oes(Gamma et al., 1994). Padr˜oes visam melhorar, formalizar e documentar experiˆencias e conhecimentos de projeto (Alexander et al., 1977) (Gamma et al., 1994).

Existem diversos formatos ou templates para a descric¸˜ao de padr˜oes. Alguns s˜ao quase puramente textuais, escritos em prosa livre, semelhantes ao formato original utilizado por Ale-xander (AleAle-xander et al., 1977), enquanto outros s˜ao mais estruturados, como aquele utilizado pelaGang-of-Four, tais como: Builder,Factory Method,Abstract Factory,Prototype,Memento entre outros (Gamma et al., 1994). N˜ao existe um formato padronizado pela comunidade de software, principalmente porque diferentes tipos e dom´ınios de padr˜oes podem exigir diferentes maneiras de apresentar os padr˜oes.

2.4Frameworks 37 O padr ˜aoPlugin

Aplicac¸˜oes dinamicamente extens´ıveis foram apresentadas por (Szyperski, 1996), atualmente s˜ao conhecidas como aplicac¸˜oes baseadas emPlugins, possuem uma caracter´ıstica importante:

podem ser estendidas ap´os a sua implantac¸˜ao. Esses sistemas oferecem diversas interfaces Plugin(ou pontos de extens˜ao), que podem ser utilizados para adicionar novas funcionalidades

`a aplicac¸˜ao. Pluginspodem ser facilmente instalados e adicionados a um sistema baseado em Plugins, a qualquer momento. A seguir ´e apresentada a descric¸˜ao do padr˜aoPlugin segundo (Mayer et al., 2003) e (Bako et al., 2006), que utiliza basicamente o formato adotado por (Gamma et al., 1994).

Intenc¸˜ao: Este padr˜ao explica como criar uma aplicac¸˜ao para suportar o conceito de Plu-gin permitindo que um aplicativo seja estendido em tempo de execuc¸˜ao, carregando classes dinamicamente n˜ao conhecidos em tempo de compilac¸˜ao.

Motivac¸˜ao: Quando uma aplicac¸˜ao que lˆe v´arios formatos gr´aficos ´e constru´ıda, o desen-volvedor n˜ao ´e capaz de escrever um decodificador para todos os formatos atuais e formatos que podem surgir no futuro. Este problema pode ser resolvido permitindo que terceiros implemen-tem a decodificac¸˜ao desses novos formatos gr´aficos atrav´es dePluginse que sejam adicionados

`a aplicac¸˜ao em tempo de execuc¸˜ao.

Aplicabilidade: O padr˜aoPluginpode ser aplicado para atender os seguintes requisitos:

• Necessidade de expans˜ao durante a execuc¸˜ao, possivelmente desconhecida at´e mesmo na inicializac¸˜ao da aplicac¸˜ao.

• Modularizar os sistemas para reduzir a complexidade.

• Permitir o desenvolvimento de terceiros com base apenas no conhecimento das interfaces.

• Permitir f´acil implantac¸˜ao de novos recursos e atualizac¸˜oes, ap´os a implantac¸˜ao da aplicac¸˜ao.

• Inicializac¸˜ao r´apida e requisitos de hardware de baixa capacidade, especialmente de mem´oria.

Estrutura: pode ser visualizada na Figura 2.11.

O padr˜ao possui os seguintesparticipantes:

• PluginLoader: Procura por implementac¸˜oes da interface dePluginem tempo de execuc¸˜ao, quando necess´ario. Pode realizar chamadas aosPluginsconcretos e permite aos clientes o acesso a todos osPluginscarregados.

• Plugin (Interface): Cont´em todos os m´etodos necess´arios para permitir que os Plugins concretos fornec¸am suas funcionalidades. Ela tamb´em define a semˆantica desses m´etodos

38 2. Revis˜ao Bibliogr´afica

Figura 2.11:O padr˜aoPlugin Adaptado de (Bako et al., 2006)

e o protocolo da interface, isto ´e, as sequˆencias permitidas das chamadas dos m´etodos.

Pode conter m´etodos que definem se os clientes podem ou n˜ao acessar suas funcionalida-des.

• ConcretePlugin: na Figura 2.11 representado pelas classesConcretePluginAe Concrete-PluginB. Implementa a interface doPlugin, utilizando bibliotecas da aplicac¸˜ao, classes pr´oprias complementares podem ser utilizadas. Possivelmente herda de outras classes e implementa interfaces adicionais.

Colaborac¸˜oes: O Pluginloader pode determinar os nomes dos Plugins atrav´es de uma chamada para getName() e permite a inicializac¸˜ao atrav´es do m´etodo init(). Um cliente do Pluginloaderrepresentado na Figura 2.11 pela classeClientpode acessar osPluginsconcretos usando os m´etodos dessa interface.

Usos Conhecidos: O Gimpi, popular programa de processamento de imagem permite a adic¸˜ao de novas funcionalidades atrav´es dePlugins. A ferramenta WEB de gerenciamento de projetosTracfornece customizac¸˜ao atrav´es dePlugins.

Padr˜oes relacionados: O padr˜ao Command (Gamma et al., 1994) ´e bastante semelhante ao padr˜ao Plugin, a principal diferenc¸a ´e que os Plugins n˜ao s˜ao conhecidos em tempo de compilac¸˜ao. A implementac¸˜ao da interface do Plugin ´e normalmente baseada em um grande n´umero de classes, especificamente utilizadas para esta finalidade, esta ´e uma aplicac¸˜ao do padr˜ao Facade (Gamma et al., 1994), onde a classe ConcretePlugin desempenha o papel da fachada. `As vezes, ´e desej´avel que osPlugins de um certo tipo sejam carregados no m´aximo uma vez. Ent˜ao, a fim de garantir essa propriedade, o Pluginloader tem de implementar o padr˜aoSingleton(Gamma et al., 1994).