Tabela 3.2: N´umero total de LOC de cada ferramenta e porcentagem de LOC correspon- dente ao framework e suas instˆancias.
Ferramenta Total de LOC Porcentagem de LOC LOC da Instˆancia
do Framework
EvolutionChecker 179043 99% 1%
CosmosChecker 184821 99% 1%
Java2Cosmos 200786 96% 4%
n˜ao pode-se considerar o reaproveitamento de todas as funcionalidades oferecidas pelo motor de inferˆencia Drools, j´a que apenas parte delas ´e usada.
3.1.4
Limita¸c˜oes do framework
O motor de inferˆencia Drools usado pelo framework de componentes imp˜oem que as regras sejam implementadas por uma das linguagens que o Drools oferece suporte: Java, Groovy ou Python. Outra limita¸c˜ao diz respeito ao desempenho do Drools. Como ele testa todas as poss´ıveis combina¸c˜oes de fatos com as vari´aveis das condi¸c˜oes, um determinado conjunto de regras muito grande no qual muitas s˜ao poss´ıveis combina¸c˜oes ter´a o desempenho prejudicado.
3.2
A ferramenta EvolutionChecker
A ferramenta EvolutionChecker oferece suporte ao modelo de evolu¸c˜ao SACE proposto por Lobo [49] (ver se¸c˜ao 2.2) atrav´es da utiliza¸c˜ao dos novos profiles do RAS, apresentados na se¸c˜ao 2.4. Os novos profiles do RAS descrevem as caracter´ısticas dos componentes (abstratos e concretos) que s˜ao analisadas pelas regras de evolu¸c˜ao e o resultado dessa an´alise determina o n´ıvel de impacto das altera¸c˜oes.
3.2.1
Requisitos do EvolutionChecker
Os requisitos funcionais do EvolutionChecker s˜ao oferecer suporte a um modelo de evolu¸c˜ao e versionar componentes automaticamente. Como o modelo pode ser alterado, ´e inte- ressante que a ferramenta seja modific´avel. Outro atributo de qualidade desej´avel ´e a usabilidade.
Cen´ario de uso
A Figura 3.7 mostra um poss´ıvel cen´ario de uso do EvolutionChecker. Para facilitar o entendimento, dividimos o cen´ario em quatro fases. Na fase 1, suponha que um CompA ´e
34 Cap´ıtulo 3. Ferramentas baseadas em regras
recuperado (check-out) do reposit´orio de componentes junto com seu arquivo de metada- dos no formato RAS. Dentre os v´arios metadados contidos no arquivo, apenas o n´umero de vers˜ao do componente, 1.0.1, ´e destacado. Na fase seguinte, o CompA, assim como seu metadado correspondente, evolui para prover uma interface IB. Entretanto, o metadado do novo componente n˜ao est´a completo at´e que o impacto das altera¸c˜oes (no caso, uma adi¸c˜ao de interface provida) seja analisado. Os metadados do componente original e do evolu´ıdo junto com as regras de evolu¸c˜ao em um formato pr´oprio do Drools (DRL) s˜ao passados como valores de entrada para o EvolutionChecker, na fase 3. Na fase 4, o Evo- lutionChecker analisa as altera¸c˜oes e calcula o novo n´umero de vers˜ao, que completa o metadado do novo componente. Neste caso espec´ıfico, a adi¸c˜ao de uma interface provida tem impacto m´edio e o novo n´umero de vers˜ao ´e 1.1.1 (a se¸c˜ao 2.2 explica com maiores detalhes o modelo de versionamento).
<< metadata >> RAS(XML) versão 1.0.1 EvolutionChecker Repositório de Componentes 1.check-out <<component>> CompA IA IB <<component>> CompA IA 2.evolução 2.evolução
3.entrada Regras de evolução(DRL)
3.entrada 3.entrada 4.saída << metadata >> RAS(XML) versão desconhecida << metadata >> RAS(XML) versão 1.1.1
Figura 3.7: Exemplo de uso do EvolutionChecker
3.2.2
Modelagem da ferramenta EvolutionChecker
O EvolutionChecker utiliza o framework de componentes apresentado na se¸c˜ao 3.1. A Figura 3.8 ´e uma instancia¸c˜ao da figura 3.4 e mostra o projeto do EvolutionChecker. O componente EvolutionMgr envia para o DroolsManager qual ´e o arquivo de regras e os fatos que, neste caso, s˜ao os metadados dos componentes no formato RAS das duas vers˜oes de um componente. O DroolsManager prepara a biblioteca, faz uma asser¸c˜ao4
dos fatos e dispara as regras de evolu¸c~ao.
IDroolsMgt org.drools.ide Regras de evolução (DRL) EvolutionChecker << component >> EvolutionMgr << component >> DroolsManager
Figura 3.8: Projeto do EvolutionChecker
3.2. A ferramenta EvolutionChecker 35
Ap´os mostrar em detalhes a parte est´atica dos componentes, ser´a mostrado um exem- plo de execu¸c˜ao do componente. Por motivos de clareza, apenas uma regra, Target- Platform, ´e disparada neste exemplo.
Foi constru´ıdo um diagrama de seq¨uˆencia mostrado na Figura 3.9 a partir da chamada do componente DroolsManager pelo EvolutionMgr. O diagrama come¸ca com a classe Facade IDroolsMgt que implementa a interface provida IDroolsMgt. A classe DroolsMgr (note que estamos falando da classe DroolsMgr e n˜ao do componente DroolsManager) ´e respons´avel por definir qual ´e o arquivo de regras (passo 1), quais s˜ao os fatos (passo 2) e quando as regras ser˜ao disparadas (passo 3). As regras de evolu¸c˜ao do modelo SACE est˜ao descritas no arquivo EvolutionRules.drl e os fatos s˜ao os metadados dos componentes, antes e depois da evolu¸c˜ao. Ap´os disparar as regras (passo 4) o controle da execu¸c˜ao passa para o motor de inferˆencia Drools. Ele tentar´a executar todas as regras usando combinando os fatos com as condi¸c˜oes de execu¸c˜ao das regras (passo 5). Quando uma condi¸c˜ao for satisfeita, a regra ´e disparada (passo 6). Na figura, a regra TargetPlatform foi disparada. Ela processa os metadados para verificar se alguma altera¸c˜ao foi feita. Caso sim, a classe realiza uma busca na tabela contida no arquivo changeImpact.xml para descobrir o impacto causado pela mudan¸ca. Por fim, retorna o valor desse impacto (passo 7). Esse valor ´e armazenado utilizando a classe RulesManager (passo 8). Os passos 5, 6, 7 e 8 do diagrama de seq¨uˆencia s˜ao repetidos proporcionalmente ao n´umero de regras. Com o fim das regras, o controle da execu¸c˜ao volta para o DroolsMgr (passo 9) e ele recupera o resultado final armazenado em RulesManager (passo 10 e 11), para depois repassar esse valor para Facade IDroolsMgt (passo 12).
A Figura 3.10 mostra a interface gr´afica do EvolutionChecker. Trata-se de uma inter- face simples constru´ıda com Java Swing [10]. O objetivo desta interface ´e apenas ajudar o desenvolvedor a executar o EvolutionChecker. Ela n˜ao auxilia na cria¸c˜ao do arquivo de regras, uma vez que o Drools j´a possui um editor com essa finalidade.
Na figura tamb´em ´e poss´ıvel ver parte da sa´ıda do EvolutionChecker na ´area de texto. O nome de cada regra aparece seguido do impacto que teve a aplica¸c˜ao dessa regra. Por exemplo, a modifica¸c˜ao do estado de manuten¸c˜ao de uma interface (maintenance state of
an interface) de componente abstrato resulta num impacto de n´ıvel alto (high). Na ´ultima
linha da sa´ıda o EvolutionChecker calcula qual ´e o maior impacto resultante da aplica¸c˜ao de todas as regras e determina o novo n´umero de vers˜ao do componente alterado.
A Tabela 3.3 mostra os cinco n´ıveis de impacto e um exemplo de altera¸c˜ao nos com- ponentes que podem resultar nesse impacto. Este impacto por sua vez determinar´a o n´umero de vers˜ao do componente alterado.
36 Cap´ıtulo 3. Ferramentas baseadas em regras
Figura 3.9: Diagrama de seq¨uˆencia da ativa¸c˜ao do EvolutionChecker
Tabela 3.3: Exemplos dos N´ıveis de impacto causados por altera¸c˜oes
N´ıvel de impacto Exemplo
Alto Adi¸c˜ao de interface requerida a um componente abstrato
M´edio Adi¸c˜ao de interface provida a um componente abstrato
Baixo Mudan¸cas no c´odigo-fonte de um componente concreto
Insignificante Mudan¸cas nas pr´e-condi¸c˜oes de uma interface
Regra quebrada Subtra¸c˜ao de um contrato de sincroniza¸c˜ao
3.2.3
Limita¸c˜oes
O EvolutionChecker limita a an´alise dos componentes aos metadados descritos no for- mato RAS. Nenhuma metainforma¸c˜ao ´e obtida atrav´es do pr´oprio componente. Por isso, inconsistˆencias nos metadados geram inconsistˆencias no resultado do EvolutionChecker.
Como o EvolutionChecker utiliza o framework de componentes para desenvolvimento de ferramentas baseadas em regras (ver se¸c˜ao 3.1), todas as vantagens e limita¸c˜oes do
framework tamb´em pertencem ao EvolutionChecker.
Algumas regras como, por exemplo, a que compara os c´odigos-fonte de dois componen- tes concretos dependem da acuidade das informa¸c˜oes fornecidas pelo desenvolvedor. Por isso, esfor¸cos foram feitos para automatizar a extra¸c˜ao de informa¸c˜ao dos componentes.