Frameworks de Múltiplos Domínios

Uma das principais características dos frameworks é que são específicos de domínio, isto é, oferecem abstrações de um domínio (Johnson, 1991; Gamma, et al. 1995). Assim, naturalmente um framework é considerado satisfatório quando suas variabilidades são potencialmente prováveis de serem usadas nas aplicações do domínio ao qual ele oferece suporte. Na maioria dos casos, não há problema se apenas uma pequena porcentagem das features é usada por uma aplicação, desde que exista a possibilidade das features remanescentes serem utilizadas futuramente. Como as aplicações podem evoluir com o tempo, as demais features podem ainda ser necessárias.

Em geral, frameworks se tornam amplamente empregados e bem aceitos quando oferecem uma enorme gama de features que atendem as mais diversificadas necessidades de implementação. Em consequência disso, é natural

que os frameworks evoluam nessa direção, sempre agregando novas variabilidades para satisfazer as necessidades de seus potenciais usuários. Quando essas evoluções são realizadas sem um gerenciamento ou planejamento adequado, as variabilidades incorporadas podem extrapolar o domínio previamente planejado para o framework, resultando em “Framework de Múltiplos Domínios (FMD)”.

Em alguns casos, ao desenvolver uma aplicação com o apoio de um FMD caixa branca, pode ser necessário concretizar métodos abstratos referentes a variabilidades não utilizadas pela aplicação e isso é algo que não deveria ocorrer. Caso o FMD seja caixa preta, outro problema é a presença de muitas variabilidades desnecessárias durante o processo de reuso, prejudicando a produtividade e podendo implicar em erros. Por exemplo, ao utilizar o framework Hibernate em algum ambiente de programação, uma maneira de selecionar as variabilidades consiste em digitar por um período e selecionar uma das variabilidades em uma lista. Caso o desenvolvedor esteja desenvolvendo uma simples aplicação, que usa poucas variabilidades, ou uma grande e complexa, que usa muitas, o mesmo conjunto de variabilidades aparecem nessa lista. Dessa maneira, considerando um desenvolvedor que atua em um domínio restrito, ele está sujeito a conviver com uma série de variabilidades que nunca irá utilizar. Quando todas as variabilidades estão disponíveis para os desenvolvedores, pode levar maior tempo para selecionar somente as apropriadas ou até mesmo, permitir a seleção acidental. Essas ocorrências também podem contribuir com uma maior tendência a erros no processo de instanciação.

De modo geral, admite-se que os FMDs sejam resultantes de evoluções realizadas de forma indiscriminada para apoiar o desenvolvimento de aplicações que possuem subdomínios distintos. Porém, cada aplicação desenvolvida com o apoio de um FMD, o incorpora integralmente, mesmo que utilize ou futuramente seja utilizada apenas a parte referente a um subdomínio. Possivelmente, a arquitetura desses FMDs pode ser rígida em termos de composição e decomposição de suas variabilidades, fator que impossibilita criar frameworks menores para atender demandas específicas para essas aplicações.

Uma forma de identificar se um framework é um FMD é mediante a análise de um conjunto de aplicações desenvolvidas com seu apoio ou até mesmo o fato de conhecer completamente a estrutura do framework pode ser suficiente. A Figura 14 ilustra a ideia geral das características desse tipo de framework. Na parte (I) da

Capítulo 4 - Frameworks de Múltiplos Domínios e Linha de Produtos de Frameworks 58

Figura há dois conjuntos. O primeiro conjunto, chamado de F, representa um framework com todas suas 9 variabilidades. O segundo conjunto, denominado pela letra A, representa um repositório contendo 17 aplicações desenvolvidas com o apoio de F. Cada variabilidade é representada por uma “peça de quebra-cabeça” contendo o prefixo “v” seguido por um valor numérico, enquanto que as aplicações são representadas por um quadrado contendo o prefixo “a” seguido também por um valor numérico.

Supondo que existe um artefato de mapeamento entre as aplicações e as variabilidades de F, o qual permite identificar quais variabilidades cada aplicação está utilizando, podem-se criar subconjuntos com as variabilidades de F. Conforme ilustrado na parte (II) da Figura, foram criados os subconjuntos S1, S2 e S3. Para a

formação desses subconjuntos, foi considerada a frequência com que as variabilidades foram utilizadas simultaneamente nas aplicações. Além disso, para criar tais subconjuntos, foi necessário averiguar se as variabilidades contidas são suficientes para apoiar não somente o desenvolvimento, como também a evolução dessas aplicações. Por exemplo, a aplicação a4 utiliza somente as variabilidades v4

e v6 e futuramente pode ser evoluída, utilizando também as variabilidades v1 e v9,

mas dificilmente utilizará as variabilidades que estão nos subconjuntos S2 e S3.

Vale ressaltar que podem existir aplicações que abrangem mais de um desses subconjuntos. Entretanto, a ideia dessa separação consiste em abstrair as variabilidades para determinados grupos de aplicações que utilizam ou futuramente utilizarão somente as variabilidades restritas nesses subconjuntos.

Nota-se também que existem variabilidades comuns aos subconjuntos formados, como é o caso da variabilidade v4 que é utilizada por todas as aplicações

analisadas. Assim, essa variabilidade pertence a todos os subconjuntos.

No caso do framework F, podem-se abstrair três subdomínios a partir dos subconjuntos S1, S2 e S3. Diante disso, o ideal seria a existência de três frameworks

menores, um para cada subdomínio. Porém, considerando a forma como o framework é reutilizado, mesmo que existam aplicações que se limitem à utilização de somente um conjunto menor de variabilidades disponibilizadas por F, todas as variabilidades estarão presentes nas 17 aplicações. Esse fato indica que F possui características de um FMD.

Figura 14: Framework de Múltiplos Domínios

De modo geral, a problemática de um FMD está relacionada com os seguintes pontos: (i) arquitetura inflexível, o que impossibilita gerar frameworks menores para determinados conjuntos de aplicações, refletindo na presença de features desnecessárias do framework na arquitetura final das aplicações, (ii) as variabilidades opcionais do framework não são expressas de forma coerente, pois se fossem, ao reutilizar um framework e a aplicação não exigir uma determinada variabilidade que é opcional, o desenvolvedor deveria ter a opção de não incluí-la no release final da aplicação, (iii) presença de muitas funcionalidades que não possuem um papel específico no framework, pois colaboram com a implementação de vários subdomínios, (iv) processo de reúso com alta tendência a erros, pois em alguns casos pode ser necessário concretizar métodos de variabilidades desnecessárias à aplicação e (v) dificuldade para expor as funcionalidades disponibilizadas pelo framework de maneira clara para o usuário do framework.

Considerando essa problemática, torna-se evidente a necessidade de evoluir esse tipo de framework, no sentido de tratar suas limitações. Dessa maneira, apresenta-se na Seção 4.2 o conceito das “Linhas de Produtos de Frameworks”. Essa abordagem, além de ser independente de uma plataforma e linguagem específica de implementação, permite ao EF contornar as dificuldades mencionadas anteriormente.

Capítulo 4 - Frameworks de Múltiplos Domínios e Linha de Produtos de Frameworks 60