Frameworks

Na literatura existem diversas definições para os Frameworks. Segundo Firesmith (1994), Framework é uma coleção de classes colaborativas que capturam os padrões em pequena escala e mecanismos maiores que implementam requisitos e projetos em comum

num domínio de aplicação específico. Johnson e Foote (1988) conceituam Framework como um conjunto de classes que constituem um projeto abstrato para soluções de uma família de problemas. Já para Mattsson (1996), trata-se de uma arquitetura desenvolvida com o objetivo de se obter a máxima reutilização, representada como um conjunto de classes abstratas e concretas, com um grande potencial de especialização.

Assim sendo, um Framework orientado a objetos é uma arquitetura que permite a reutilização de todo ou parte de um sistema. A representação é feita por meio de um conjunto de classes abstratas e concretas que se relacionam pela forma como as suas instâncias interagem, de modo que é disponibilizada uma solução reutilizável para uma família de problemas semelhantes. Esse conjunto de classes deve ser extensível e flexível de maneira que seja possível a construção de várias aplicações empregando esforço reduzido uma vez que grande parte das funcionalidades será reaproveitada e não criada, especificando apenas as particularidades de cada software. Portanto, assim como a maioria das técnicas de reutilização, a abordagem de Frameworks pode reduzir drasticamente o custo inerente ao desenvolvimento de aplicações, pois uma boa parte do núcleo já está implementada, precisando apenas de adaptações (JONSHON, 1997; SOMMERVILLE, 2011; WIRFS- BROCK, JONHSON, 1990).

Classificação e tipos de framework

Existem três tipos de classificação atribuídos aos frameworks, seja quanto à forma de utilização ilustrada no Quadro 3.2 e quanto ao propósito de utilização, conforme descrito no Quadro 3.3 (FUJIOKA, 2011; PROTA, 2009; SILVA, 2000; SILVA e OLIVEIRA, 2006).

Quadro 3.2 – Características dos tipos dos frameworks com relação à forma de utilização.

Fonte: PROTA (2009) ; FUJIOKA (2010).

Em relação à forma de utilização, os frameworks podem ser classificados em: caixa branca, caixa preta ou híbrido. Os frameworks de caixa branca são focados na herança de classes, estendem ou modificam uma funcionalidade pela definição de subclasses com sobreposição de métodos (SILVA, 2000). Já nos de caixa preta, os desenvolvedores devem saber apenas quais objetos estão disponíveis e as regras para combiná-los. Esses objetos não podem ser vistos ou alterados. Nesse tipo de framework o reuso se dá pelas conexões entre os componentes, não havendo preocupação em saber como eles realizam as tarefas individuais. As instanciações e composições feitas determinam as particularidades da aplicação (SILVA, 2000).

A maioria dos frameworks apresenta uma organização híbrida, e são também conhecidos como frameworks de caixa cinza, pois existem funcionalidades prontas e aquelas que podem ser criadas ou alteradas (SILVA e OLIVEIRA, 2006; PROTA, 2009, FUJIOKA, 2011).

Quadro 3.3 – Características dos tipos dos frameworks com relação à finalidade

Tipo Característica

Suporte São raros; provê serviços de nível de infraestrutura (e não de aplicação); Acesso a arquivos; Computação distribuída; Device Drivers

Aplicação Também chamados de framework horizontal; encapsula conhecimento

(“expertise”); aplicável a uma vasta gama de aplicações; resolve apenas una fatia do problema da aplicação, exemplo: framework para construção de interface.

Domínio Também chamado de framework vertical; encapsula conhecimento (“expertise”); aplicável a aplicações pertencendo a um domínio particular de problema; resolve boa parte da aplicação; Exemplo: framework para construir aplicações de controle de manufatura.

Fonte: PROTA (2009) ; FUJIOKA (2011).

Em relação aos problemas que podem ser tratados por frameworks, pode-se categorizar em horizontais, verticais ou de infraestrutura. Os frameworks horizontais destinam-se a resolver apenas uma parte do problema da aplicação e por esse fato conseguem atender a uma grande parcela do mercado. Já os verticais, encapsulam os conhecimentos aplicáveis a sistemas de um domínio particular. Destinam-se a resolver todo ou boa parte do problema, podendo gerar aplicações inteiras (PROTA, 2009; SILVA, 2000; SILVA; OLIVEIRA, 2006). Os de infraestrutura buscam solucionar problemas no nível de infraestrutura (e não de aplicação).

Ainda segundo Sommerville (2007, p. 282), que concorda com (FAYAD; SCHMIDT, 1997), a classificação dos frameworks pode ser feita de três formas distintas:

 Frameworks de infraestrutura de sistema - esses frameworks são compatíveis com o desenvolvimento das infraestruturas de sistemas, como comunicação, interfaces de comunicação, interfaces com o usuário e compiladores (FAYAD; SCHMIDT, 1997);

 Frameworks de integração com middleware - consistem em um conjunto de classes de objetos-padrão e associados, que aceitam a comunicação de componentes e a troca de informação. Entre os exemplos desse tipo de framework estão CORBA (CORBA, 2014), COM e DCOM (MICROSOFT, 2014), e Java Beans (ORACLE, 2014); e

 Frameworks de aplicação corporativa - ocupam-se de domínios específicos de aplicações, como telecomunicação ou sistemas financeiros. Eles incluem o conhecimento de domínio de aplicações e são compatíveis com o desenvolvimento de aplicações para o usuário final.

O framework adaptado neste trabalho é o de infraestrutura, pois provê soluções para gerenciar concorrência, comunicação entre outros aspectos de infraestrutura genéricos, não focando em um tipo de problema específico. Em relação ao tipo se enquadra no tipo caixa cinza, e, em relação à sua finalidade é classificado como de domínio, pois trata de problemas

comuns em aplicações Web tais como controle de acesso, sessões, persistência e separação por camadas.

Framework e padrões de projeto

Padrões descrevem problemas no ambiente e o núcleo da sua solução, de forma que é possível utilizá-los inúmeras vezes, sem nunca aplicá-los do mesmo modo (ALEXANDER; ISHIKAWA; SILVERSTEIN, 1977). São considerados, ainda, como soluções que estão em um nível mais abstrato do que frameworks, os quais são normalmente implementados utilizando linguagens orientadas a objetos como Java,15 C++16, entre outras. Conforme contextualizado, tais padrões descrevem o projeto de uma solução para um problema recorrente, podendo incluir um exemplo de implementação. Consequentemente, frameworks são mais específicos que padrões de projetos, pois estão relacionados a um domínio de aplicação, um aspecto de infraestrutura ou de integração de middleware.

Enquanto um framework pode possuir vários padrões de projeto, o contrário não é verdadeiro.

Framework e componentes

Para Barreto (2009) e Gimenes e Huzita (2005), os componentes de software podem ser classificados como unidades independentes, as quais encapsulam dentro de si seu projeto e implementação e também disponibilizam funcionalidades para o meio externo por meio de interfaces bem definidas. Componentes podem apresentar dois tipos de interface: as interfaces fornecidas, que expõem seus serviços, e as interfaces requeridas, por onde o componente explicita suas dependências. Os frameworks fornecem interfaces bem definidas e os pontos de extensão que as aplicações devem estender. Contudo, enquanto um framework possui necessariamente pontos de extensão, um componente totalmente autocontido não possui interfaces requeridas.

Em função disto, um componente deve ser ligado a uma interface requerida de outro componente, enquanto os pontos de extensão dos frameworks são menos exigentes,

15 _{Java – Java é uma linguagem de programação e plataforma computacional lançada pela primeira vez pela Sun}

Microsystems em 1995. Disponível em: < http://www.java.com/pt_BR/download/faq/whatis_java.xml>. Acesso em: 20 out 2014.

16

C++ - A linguagem C++ foi desenvolvida inicialmente por Bjarne Stroustrup na At&T, de 1979 a 1983, à partir da Linguagem C, tendo como ideia principal a de agregar o conceito de classes, de orientação à objetos, àquela linguagem. Disponível em: <http://www.inf.ufrgs.br/~johann/cpp2004/>. Acesso em: 20 out. 2014.

possibilitando que sejam ligados componentes, classes ou qualquer artefato que realiza o contrato definido.

Assim, conforme Szyperski (1997), pode-se concluir que os componentes podem ser desenvolvidos com a utilização de frameworks, os quais por sua vez podem ser desenvolvidos utilizando componentes, ou seja, essas duas tecnologias são complementares de forma que frameworks podem ser usados para auxiliar o desenvolvimento de componentes e vice-versa.