Erich Silvestre. Ferramentas de fatoração para o ambiente telis

Transcrição

1 Erich Silvestre Ferramentas de fatoração para o ambiente telis 14 de setembro de 2007

2 Erich Silvestre Ferramentas de fatoração para o ambiente telis Orientador: Luiz Fernando Bier Melgarejo 14 de setembro de 2007

3 Ferramentas de fatoração para o ambiente telis Trabalho de conclusão de curso apresentado como parte dos requisitos para obtenção do grau de Bacharel em Ciência da Computação. Prof. Luiz Fernando Bier Melgarejo Orientador Banca Examinadora Prof. Dr. José Mazzucco Jr. Prof. Dr. Rosvelter Coelho da Costa

4 Resumo Resumo

5 Abstract Abstract

6 Sumário 1 Introdução p Objetivo Geral p Objetivos Específicos p. 7 2 Fatoração p Definição p Objetivos da fatoração p O que fatorar p Maus cheiros de código p Código Duplicado p Método Longo p Classes Grandes p Lista de Parâmetros Longa p Alteração Divergente p Cirurgia com Rifle p Inveja dos dados p Grupo de dados p Obsessão por Tipos Primitivos p Comandos switch p Hierarquias paralelas de herança p Classes Ociosas p Generalidade Especulativa p. 14

7 Campo Temporário p Cadeias de mensagens p Classe Intermediária p Intimidade Inadequada p Classes Alternativas com Interfaces Diferentes p Biblioteca de Classes Incompleta p Classe de Dados p Herança Recusada p Comentários p Tabela de fatorações relacionadas a maus cheiros p Ferramentas de fatoração p Linguagem Telis p Adaptação a fatorações automáticas p Implementação p Eclipse p A plataforma RCP p Conceitos da plataforma p Suporte a fatoração na plataforma Eclipse, Eclipse LTK p. 22

8 7 1 Introdução Deseja-se que o software orientado a objeto seja flexível, extensível e de fácil manutenção. Têm-se estudado diversos modos de se maximizar o uso do potencial deste paradigma, as fatorações são uma abordagem disponível em busca deste ideal. As fatorações estão presentes na metodologia de desenvolvimento XP. Ela adota a prática de desenvolvimento guiado por testes, dentro dessa prática as fatoração assumem papel importante, a simplificação do projeto. Com o bom uso de fatorações consegue-se fazer projeto simples, que é o que busca XP. Esse bom uso depende de conhecimento por parte programador do paradigma de orientação a objeto, o que muitas vezes é uma deficiência deste. O Telis é uma linguagem de programação com suporte a orientação a objetos utilizada para o aprendizado de programação. Ela é totalmente em português, possui sintaxe simples e intuitiva, permitindo que pessoas que nunca tiveram contato com programação possam utilizála para iniciar sua prática sem a necessidade de gastar muito tempo para desvendar a sintaxe da linguagem, concentrando-se mais em conceitos de programação, diferente de linguagens comumente utilizadas na indústria. O Ambiente Telis é o ambiente de desenvolvimento da linguagem Telis, possuindo editores integrados. Ele é voltado para aprendizado construtivo, possuindo na tela principal um Turtle Graphics (semelhante ao ambiente LOGO) por onde se desloca uma imagem de uma aranha. Esse ambiente vem sendo desenvolvido desde 1998 e atualmente encontra-se bem estável. O ambiente ao qual as ferramentas de fatoração serão incluídas não é o supra-citado, mas sim um novo que rodará sobre a plataforma Eclipse, diferente do anterior que foi implementado em Java e AWT. Com a inclusão das ferramentas de fatoração ao novo Ambiente Telis, o iniciante em orientação a objeto terá mais facilidade de utilizar fatorações, uma vez que elas poderão ser executadas automaticamente ausentando o programador da verificação da possibilidade ou não de fatorar, da garantia de preservação das características funcionais e de extensas atualizações de

9 8 código, espalhado por todo o projeto. Isso irá familiarizar o iniciante com as próximas linguagens e ambientes de programação que ele encontrará pela frente, já que linguagens utilizadas atualmente como Java, Python e Ruby também possuem ferramentas de fatoração de código. 1.1 Objetivo Geral Estudar a teoria de fatorações automática de código aplicado à linguagem Telis, verificando as facilidades e dificuldades de acordo com as características da mesma. Desenvolvimento de um conjunto de ferramentas automáticas para a linguagem na forma de plug-in que rode sobre a plataforma Eclipse. 1.2 Objetivos Específicos Verificar quais fatorações podem ser implementadas na linguagem Telis Implementar as fatorações na plataforma Eclipse, com a utilização do framework Eclipse LTK Fazer o software de tal modo que seja de fácil utilização por iniciantes em programação

10 9 2 Fatoração A palavra fatoração é bastante utilizada na matemática: quando se deseja somar números racionais que possuam diferentes divisores, deve-se achar o mínimo múltiplo comum entre eles. No processo de achá-lo, utiliza-se o teorema fundamental da álgebra decompondo-se ou fatorando-se os divisores em n primos, a fim de achar fatores em comum. Quando fatora-se os divisores eles continuam sendo os mesmos números, representados de maneira diferente, com intuito de tornar evidente características antes imperceptíveis. A fatoração em termos de software tem relação com a fatoração da matemática, faz-se alterações na estrutura interna do software e o comportamento funcional dele não é alterado, que é o que acontece também nas fatorações matemáticas. Não se sabe ao certo o que deu origem às fatorações. Fowler acredita [?] que as fatorações surgiram devido ao tempo que os bons programadores gastavam em melhorar seu código. A primeira pessoa a publicar um artigo sobre fatorações foi William Opdyke, em 1990, no OOPSLA, com co-autoria de Ralph Johnson, este um dos autores de Design Patterns[?] e a do conceito de frameworks. A idéia de fatoração só foi amadurecida após criação e intensa utilização do paradigma de orientação a objeto com SmallTalk. Isso se deu com a migração de programadores acostumados ao paradigma estruturado ou mesmo inexperientes à programação orientada a objetos, começouse a criar softwares de projeto sofrível, que não faziam uso dos benefícios trazidos pelo novo paradigma. O ambiente de programação SmallTalk permitia um ciclo rápido de alteração de código e execução, permitindo que alterações no código pudessem ser testadas rapidamente. 0 Todos os números inteiros positivos maiores que 1 podem ser decompostos num produto de números primos, sendo esta decomposição única a menos de permutações dos fatores.

11 Definição Segundo [?] as fatorações podem ser definidas de duas formas, fatoração (substantivo) e fatoração (verbo). Como substantivo a fatoração é uma alteração na estrutura interna do software a fim de torná-lo mais fácil de ser entendido e menos custoso de ser modificado sem alterar seu comportamento observável, ou seja, modifica-se a sua estrutura (projeto) sem isto resultar em alterações funcionais. Na forma de verbo a fatoração é ação de reestruturar software aplicando uma série de fatorações sem alterar seu comportamento observável. O desenvolvimento guiado por testes[?] incorporou a fatoração como um processo a ser executado metodicamente e de modo incremental, a cada pequena alteração no código - se necessária - deve ser feita, em contraste às grandes reestruturações à que carecem aos softwares criados sem critério algum. Um avanço mais recente foi a publicação de [?] que faz a combinação das fatorações com os padrões de projeto. Assim como as fatorações, estes foram criados baseados na experiência prática de desenvolvimento de sistemas e na necessidade de resolução de problemas arquiteturais coincidentes entre os mesmos. 2.2 Objetivos da fatoração O que leva a se fatorar o código? Vários são os objetivos que nos levam a fatorar. Podemos estar buscando melhorar a arquitetura do sistema, melhorar a legibilidade de uma classe específica (nomes de atributos, métodos e nome de métodos) ou simplesmente alterar o sistema antes de incluir uma nova funcionalidade. Dá-se sempre enfoque ao código, ele precisa estar claro, entendível por outra pessoa. Quando fala-se no aprimoramento da arquitetura do sistema orientado deve-se fazê-lo com a aplicação de princípios de orientação a objeto e padrões de projeto. As fatorações nos levam naturalmente em direção a eles como comentado em [?]. Com a aplicação da fatoração busca-se além de melhora na arquitetura: simplicidade de projeto. Na definição de Kent Beck, a simplicidade de projeto possui quatro critérios, eles estão dispostos por ordem decrescente de prioridade na tabela abaixo.

12 11 Projeto Simples 1. O código funciona 2. O código comunica o que faz 3. O código não possui duplicação 4. O código possui o menor número de métodos e classes possível Os quatro critérios convivem na maioria dos casos de forma harmônica, obedecendo-se um tende-se a estar obedecendo a outro. A regra de maior importância é a que fala que o código deve funcionar. Peguemos como exemplo um projeto desenvolvido por um analista de sistemas clássico. Como este saberá se o sistema que ele está projetando se encaixa nos critérios acima estabelecidos? Haja visto que ele só vai ter o projeto funcionando depois de terminar a análise, fazer as modelagens relativas ao projeto ou parte dele e implementar. Há um contraste entre a abordagem clássica e a de Kent Beck com relação a projeto. Ele analisa o projeto de forma a arquitetura), ao contrário dos clássicos que tendem a ver as coisas de modo top-down, pois é o modo como se projeta classicamente o sistema e não têm uma grande preocupação com a legibilidade do código que será gerado (regra 2), desde que funcione. É importantíssimo o código comunicar o que faz, grande parte do tempo gasto com a produção de software é na fase da manutenção do mesmo e é nessa fase em que se torna mais importante o claro e rápido entendimento do que se trata cada classe, cada método. A pessoa que dá manutenção no código pode ou não ser a mesma que o fez, ainda que seja a mesma pessoa que criou o código pode se tornar muito difícil o entendimento se na sua criação não foi criteriosa a escolha dos nomes para campos de classe e métodos ou criou-se métodos muito longos, classes inconsistentes, tais problemas são chamados de maus cheiros (bad smells) de software, serão abordados em seções posteriores. Estão ligados à identificação de partes do software que devem ser fatoradas. Um projeto de código que não possui duplicações (item 3) tem a tendência a ser mais orientado a objetos, mas não necessariamente terá um menor número de classes e métodos que um projeto cheio de duplicações. Devido a hierarquia e aplicação de padrões de projeto o código sem duplicação pode ter maior número de classes e métodos. Há de se ter bom senso: apesar de a prioridade de não se ter duplicação é maior do que a que trata a respeito de número de métodos e classes, um número excessivo de classes e métodos pode tornar o projeto complexo. Por isso se diz o menor número de classes de métodos possível, pois deve-se respeitar todos as outras regras, mas com critério.

13 O que fatorar Os programadores inexperientes em orientação a objeto tem tendência a cometer erros graves de projeto, alguns por não terem sido apresentados de maneira adequada ao paradigma ou terem experiência em programação estruturada e acreditarem que porque estão usando linguagens orientadas a objeto estão programando orientado a objetos. Abaixo estão listados alguns pontos em que costuma se ter dificuldade na orientação a objeto. Utilização de nomenclatura adequada Separação da interface gráfica do modelo Não violação do encapsulamento dos objetos Dividir as responsabilidades entre os objetos do sistema Atribuição de responsabilidade única as classes As dificuldades acima listadas e outras mais, fazem com que o programador criei código com bad smells ou mau cheiros. Em [?] é definida uma lista de fedores e fatorações passíveis de serem aplicadas ao código para removê-los. 2.4 Maus cheiros de código Os maus cheiros de código são alvos para fatoração, ou seja, o que fatorar. Os citados abaixo foram definidos por Kent Beck e Martin Fowler em [?] Código Duplicado É o mau cheiro mais comum. A duplicação de código gera partes redundantes no código e quando uma delas necessita de manutenção, todas as partes duplicadas também o necessitarão. Isso dificultará o trabalho de quem mantém o software, não só por ter de alterar códigos em diversas regiões a cada manutenção, mas pela dificuldade de achar tais partes Método Longo Os métodos longos dificultam consideravelmente o entendimento do que está sendo executado e torna-se difícil dar nome a um método longo, por ele estar fazendo coisa demais.

14 Classes Grandes Uma classe grande pode estar fazendo coisas que não deveriam ser de sua responsabilidade, violando o principio de orientação a objeto da responsabilidade única. Com o desrespeito de tal princípio, o código resultante é altamente acoplado, difícil de ser reutilizado e lembra programação estruturada. A existência de classes grandes pode ser também um indício da presença de código duplicado Lista de Parâmetros Longa Lista longas de parâmetros são difíceis de manter e entender. Quando há a necessidade de se obter mais um dado via uma lista de parâmetro que já é longa, fica difícil saber se a lista já contém o dado necessário via delegação de um de seus parâmetros ou se é necessário adicionar outro parâmetro. Isso pode levar a redundância de dados Alteração Divergente A alteração divergente é um problema mais sutil que os outros já discutidos. Ocorre quando uma classe tende a ser alterada freqüentemente por diversos motivos. Ela pode estar unindo comportamento que deveria estar separado entre duas ou mais classes, de volta, o problema da responsabilidade única Cirurgia com Rifle A cirurgia com rifle é o oposto da alteração divergente. Quando se deseja fazer uma determinada alteração no sistema e esta resulta em pequenas modificações em diversas classes, afetando a maleabilidade do software e fazendo com que seja difícil encontrar todas estas partes a modificar Inveja dos dados A inveja de dados ocorre quando uma classe esta interessada demais nos dados de outra, fazendo operações com eles em vez de pedir para a classe que os tem. Nesse caso, as operações ou até alterações de dados de outra classe podem estar violando o encapsulamento e atribuindo erroneamente responsabilidades que deveriam estar na dona dos dados.

15 Grupo de dados Os grupos de dados são dados que são passados como parâmetro, são utilizados em métodos e que comumente aparecem no software juntos. Se for estabelecida uma relação entre eles, como a criação de uma classe para os mesmos, se tornará mais fácil lidar com eles Obsessão por Tipos Primitivos A obsessão por tipos primitivos é o abuso no uso de tipos de primitivos da linguagem. É como utilizar um inteiro para armazenar um valor de uma carta em um jogo de baralho. Nesse caso, operações que poderiam estar isoladas numa classe Carta como por exemplo a comparação entre duas cartas, estarão dispersas entre uma ou mais classes que necessitarão esta informação Comandos switch Uma das grandes diferenças entre código orientado a objeto e código estruturado é a ausência de comandos switch, case e de grandes seqüências de comparação no código OO, justamente pela possibilidade de uso de polimorfismo. Quando há a utilização de switch a possibilidade de haver mais de um switch fazendo comparações com o mesmo conjunto de dados é grande, ou seja, duplicação. Há uma exceção a regra, que é o caso do uso de switch no padrão de projeto Fabrica. Contudo, este padrão tende a não permitir a criação de duplicações de comandos switch, pois centraliza nele a responsabilidade de criação dos objetos e o uso do comando Hierarquias paralelas de herança É um tipo de cirurgia com rifle. Quando é criada uma subclasse de uma determinada classe é necessário criar também uma subclasse de outra classe Classes Ociosas As classes ociosas são classes que não fazem muita coisa. Podem ser resultado da aplicação de uma série de fatorações ou terem sido incluídas para futura alteração que foi prevista e nunca ocorreu. No caso de subclasses, a subclasse pode ser absorvida pela classe da qual é especializada e em certos casos pode ser internalizada.

16 Generalidade Especulativa Quando acrescenta-se uma funcionalidade ao software sem necessidade atual, nem previsão de que vai ser preciso é o que chama-se de generalidade especulativa. A inclusão de tal funcionalidade só aumenta a complexidade do software sem que se tenha previsão de que será preciso utilizá-la Campo Temporário Campos temporários são campos de classe que passam parte do tempo nula e outra parte do tempo tem algum valor definido. Fica complicado de entender o por que disto, já que espera-se que a classe precise do valor de todas as suas variáveis Cadeias de mensagens As cadeias de mensagens ocorrem quando um objeto obtém por referência outro objeto, e dessa referência pede outro objeto, e desse outro pede outro objeto e assim por diante. Criase uma dependência do objeto com a navegabilidade do sistema, qualquer classe intermediária que esteja nessa cadeia e tenha alteração da relação com outras, como exemplo a remoção da referência a um objeto, resultará na alteração dos objetos que utilizem a cadeia de mensagens Classe Intermediária Uma classe intermediária é aquela que possui muitos métodos que servem apenas para repassar um objeto do qual tem referência, uma possível alteração é os clientes do método intermediário conhecerem diretamente o objeto que eles pedem para a classe intermediária Intimidade Inadequada Quando classes passam muito tempo mexendo em partes privadas de outras, acontece a intimidade inadequada e por conseqüência, violação do encapsulamento. É comum acontecer entre classe e subclasses.

17 Classes Alternativas com Interfaces Diferentes Se no software existem classes que exercem a mesma função e tem assinaturas de métodos diferentes, pode ser o caso de extrair uma interface comum entre elas e agrupar os métodos realmente iguais numa superclasse comum entre as mesmas Biblioteca de Classes Incompleta Às vezes a biblioteca de classes que utiliza-se para a criação do software não tem todas as funcionalidades que deveria e não é possível alterá-la. Caso sejam poucos métodos, pode-se criar métodos externos (estáticos) com tal funcionalidade. Caso sejam muitos, pode-se criar uma extensão local da classe da biblioteca para incluir as funcionalidades Classe de Dados Classes de dados são classes que possuem apenas campos e métodos de acesso a eles. Dentro do sistema é muito possível que haja classes que façam inúmeras operações com esses dados. Neste ponto, volta o mau cheiro inveja dos dados Herança Recusada A herança recusada é o fato de uma subclasse herdar, necessitar implementar métodos dos quais não precise ou até precisar sobrescrever vários métodos da superclasse, para eles terem sentido. É um grave problema na hierarquia Comentários A presença de muitos comentários pode ser indício de que código ruim esteja escondido atrás dos comentários. Deve-se fazer código que comunique o que faz, o que elimina quase totalmente a necessidade de comentários. As exceções são realmente casos específicos, como o caso quando faz-se escolha por um ou outro algoritmo matemático e fica complicado através do próprio código, comunicar o porque de ele ter sido escolhido. Caso haja a necessidade da inclusão de comentário, ele deve dizer porque algo está no código, e não o que está no código.

18 Tabela de fatorações relacionadas a maus cheiros O foco principal é o desenvolvimento de ferramentas de fatoração automática, por isso, detalhará-se as fatorações que serão implementadas, sendo elas aplicadas a linguagem Telis, não vai se dar detalhes sobre como se faz para executar cada fatoração sem aplicação à linguagem, caso haja interesse, há uma literatura extensa sobre isso em [?] e [?]. Porém, é importante relacionar as fatorações aos maus cheiros de código, a tabela 2.1 mostra isso. 2.6 Ferramentas de fatoração A fatoração executada manualmente é diferente da fatoração executada por ferramentas. Na fatoração manual não se tem a garantia da manutenção do comportamento anterior, com a utilização de ferramenta, se esta for implementada de forma correta, têm-se esta garantia, salvo alguns indeterminismos relacionados a paralelismo e alteração no tempo de execução do novo código fatorado. Espera-se também que quando não for possível fatorar ou quando não se sabe se a fatoração resultará em alteração de comportamento, haja interação com o usuário sob forma de notificação de erro ou confirmação para que o mesmo decida o que fazer. Outro ponto importante é a possibilidade de desfazer fatorações, pois permite que o usuário volte atrás caso se arrependa ou uma ou mais fatorações resultem numa alteração de comportamento, tornando a ferramenta mais versátil. A implementação de ferramentas de fatoração requer a utilização de uma base de dados com informações referentes ao programa, com o intuito de verificar se a fatoração é possível e quais lugares precisarão ser alterados. Em [?] diz-se que tal base para ser gerada, necessita de uma árvore de análise semântica, para que sejam resolvidos todos os símbolos do código e sejam extraídas as informações necessárias para efetuar o processo de fatoração como um todo. A capacidade de extração de informação via uso de árvore de análise semântica varia de linguagem para linguagem. Linguagens com checagem estática de tipo possuem muita informação disposta de maneira explícita, tornando mais fácil o processo, em oposição a linguagens de tipagem dinâmica, que o torna mais complicado. A linguagem Telis se encaixa na categoria das linguagens mais complexas de serem fatoradas, por ter checagem de tipos dinâmica.

19 18 CHEIRO Alteração divergente Biblioteca de classes incompleta Cadeias de Mensagem Campo Temporário Classe ociosa Classes Alternativas com Interfaces Diferentes Classes de Dados Classes Grandes Código duplicado Comandos switch Comentários Generalidade Especulativa Grupos de Dados Herança recusada Hierarquias paralelas de Herança Classe Intermediária Inade- Intimidade quada Inveja dos dados Lista de parâmetros longa Método longo Obsessão por Tipos Primitivos FAT ORACÕES COMUNS Extrair Classe Introduzir Método Externo, Introduzir Extensão Local Ocultar Delegação Extrair Classe, Introduzir Objeto Nulo Internalizar Classe, Condensar Hierarquia Renomear Método, Mover Método Mover Método, Encapsular Campo, Encapsular Coleção Extrair Classe, Extrair Subclasse, Extrair interface, Substituir Atributo por Objeto Extrair Método, Extrair Classe, Subir Método na Hierarquia, Criar um Método Template Substituir Comando Condicional por Polimorfismo, Substituir Enumeração por Subclasses, Substituir Enumeração pelo Padrão de Projeto Strategy ou State, Substituir Parâmetro por Métodos Explícitos, Introduzir Objeto Nulo Extrair Método, Introduzir Asserção Condensar Hierarquia, Internalizar Classe, Remover Parâmetro, Renomear Método Extrair Classe, Introduzir Objeto Parâmetro, Preservar o Objeto Inteiro Substituir Herança por Delegação Mover Método, Mover Campo Remover Intermediário, Internalizar Método, Substituir Delegação por Herança Mover Método, Mover Campo, Transformar Associação Bidirecional em Unidirecional, Substituir Herança por Delegação, Ocultar Delegação Mover Método, Mover Campo, Extrair Método Substituir Parâmetro por Método, Introduzir Objeto Parâmetro, Preservar o Objeto Inteiro Extrair Método, Substituir Variável Temporária por Consulta, Substituir Método por Objeto Método, Decompor Condicional Substituir Atributo por Objeto, Extrair Classe, Introduzir Objeto Parâmetro, Substituir Vetor por Objeto, Substituir Enumeração por Subclasses, Substituir Enumeração pelo Padrão de Projeto Strategy ou State Tabela 2.1: Tabela de cheiros e fatorações comuns

20 19 3 Linguagem Telis O Telis é uma linguagem de programação totalmente em português, de sintaxe voltada para iniciantes em programação, com suporte a orientação a objetos. Ela é inerentemente paralela, utilizando o modelo de atores: cada objeto instanciado é um ator, que executa concorrentemente no sistema e interage com os demais atores via troca de mensagens síncrona e/ou assíncrona. Ela é fortemente tipada e possui checagem dinâmica de tipos. No suporte a orientação a objeto, a nomenclatura é um pouco diferente da usual utilizada, visando facilitar o entendimento do iniciante. Os modelos em Telis são equivalentes às classes concretas, os moldes equivalem às classes abstratas. Um ator equivale a um objeto, com a diferença de que ele roda paralelamente. As agendas telis, são equivalentes aos métodos. Os modelos e moldes podem ser moldados 1 por moldes, mas não é possível sobrescrever métodos herdados, somente estendê-los. Telis é baseada em pilha, semelhante a linguagem Forth e é sintaticamente é constituída simplesmente por 0 a n instruções, ou seja, tudo são instruções e são elas: texto operador: matemáticos e de comparação operador de empilhamento: empilhar símbolo operador de comunicação direta: chamadas a agendas de atores blocos listas 1 um modelo ou molde ser moldado por um molde tem a mesma semântica de uma classe herdar uma classe abstrata

21 20 As duas últimas são instruções especiais. As listas e blocos são instruções que contêm de 0 a n instruções em sua estrutura. A diferença entre blocos e listas é que o primeiro é utilizado para definir blocos de instruções a serem executadas e o segundo serve como estrutura de dados. As instruções podem ser vistas na listagem 3.1. Listing 3.1: Exemplo de instruções umtexto = $simboloaempilhar o u t r o S i m b o l o umator. o b t e r I d e n t i d a d e m o s t r a r { } umblocodeinstrucoes m o s t r a r [ umalista com 3 i n s t r u c o e s ] 3.1 Adaptação a fatorações automáticas

22 21 4 Implementação O novo ambiente Telis está sendo desenvolvido sobre a plataforma Eclipse, as ferramentas de fatoração estarão necessariamente integradas a ele e serão também implementadas como plug-ins eclipse. 4.1 Eclipse O Eclipse é um software desenvolvimento por uma comunidade open source Java [?]. O resultado mais eminente desta comunidade são as ferramentas de desenvolvimento Java (JDT), sendo o próprio eclipse muitas vezes confundido com a JDT. Além da JDT, existem ferramentas de desenvolvimento para linguagens como C (CDT), Python, Ruby, Lisp, Haskell e uma infinidade outras linguagens que rodam no eclipse. Num nível abaixo da plataforma de ferramentas de programação, encontra-se a Eclipse Rich Client Platform. Ela é uma plataforma desenvolvida com recursos genéricos para o desenvolvimento de aplicações, sendo o próprio Eclipse IDE uma aplicação que roda sobre a RCP. O azureus[?] é compartilhador de arquivos torrents de código-fonte aberto que roda sobre a plataforma A plataforma RCP A plataforma RCP é constituída basicamente por componentes chamados de plug-ins. Eles podem ser compartilhados entre mais de uma aplicação. Isso permite a modularização do software: pode-se dividir uma aplicação em um certo número de componentes (plug-ins), estes funcionando como peças que podem ser compartilhadas entre diversos projetos. A plataforma tem uma série de plug-ins disponíveis para o desenvolvedor que deseja utilizá-la. Uma série de frameworks de middleware e infra-estrutura são recursos disponibilizados pelo RCP, o que torna mais fácil o desenvolvimento de aplicações cliente, haja visto que itens de infra-estrutura são apresentados de maneira alto nível, tornando desnecessária a implementação dos mesmos.

23 22 A RCP consegue aliar a facilidade de uso e alto nível abstração de clientes leves (como o Swing) com execução em modo nativo (como o SWT), o que aumenta a performance dos programas. Para prover a facilidade de execução em modo nativo, para cada sistema operacional é disponibilizada uma versão da RCP, compatível com o mesmo. Quando se deseja desenvolver um plug-in que seja multi-plataforma não há necessidade de desenvolver códigos específicos para cada sistema operacional ou arquitetura, a chamada a recursos nativos do sistema é feita de forma transparente. Exceto que se deseje acessar recursos não disponíveis pela plataforma. O eclipse possui facilidades na geração de distribuição de plug-ins e atualização dos mesmos, podendo-se utilizar como exemplo: Java Web Start, Sites de atualização ou simples cópia de arquivos para estes fins. O próprio eclipse possui plug-ins para o desenvolvimento de plug-ins, o conjunto deles chamam-se PDE (Plug-in Development Environment). Este ambiente de desenvolvimento permite a edição dos vários tipos de recursos dos quais os plug-ins são dependentes, sem a necessidade de edição manual de arquivos de configuração, eles são gerados a partir dos dados fornecidos pelo usuário com a ajuda do sistema que mantém o programador integrado com os outros plug-ins existentes. Através dele pode-se desenvolver, testar e empacotar para distribuição, projetos RCP Conceitos da plataforma Na seção anterior fez-se uma rápida introdução à plataforma RCP e agora de uma maneira mais profunda serão analisadas as diversas partes que compõem a mesma, utilizando uma abordagem top-down, vendo primeiro a plataforma como um conjunto de plug-ins. Conjunto de plugins A menor unidade funcional do eclipse é um plugin.plug-in.tudo no eclipse é composto por plug-ins. Uma aplicação que utiliza a plataforma RCP é na verdade um agrupamento de plugins e a parte runtime, que faz a execução do software. Na figura [?] pode-se ter noção de como o eclipse é arquiteturado.

24 23 Figura 4.1: Plataforma eclipse Suporte a fatoração na plataforma Eclipse, Eclipse LTK O framework LTK faz parte da plataforma eclipse e tem como função o suporte génerico a fatorações, genérico no que diz respeito a fatorações de múltiplas linguagens, independente do paradigma a qual estão elas focadas. Ele é composto por dois plug-ins: org.eclipse.ltk.core.refactoring org.eclipse.ltk.ui.refactoring O primeiro deles é relacionado a parte do modelo de fatoração, suas classes principais são: Refactoring e Change, as duas abstratas. A classe Refactoring representa a fatoração como um todo, incluindo checagem de pré-condições, pós-condições e execução de mudanças. Cada fatoração inclui a execução de uma mudança e cada mudança pode incluir a execução de outras mudanças, estas são declaradas utilizando a classe CompositeChange. Cada Change pode especificar uma outra Change que represente a operação de desfazê-la, caso especificada, isto possibilita ao usuário fazer, desfazer e refazer fatorações. Devido a separação de Refactoring e Change, as mudanças podem ser compartilhadas entre fatorações. O segundo plug-in listado trata da parte de interface com o usuário. É composto por classes de suporte a criação de assistentes de fatoração e previsão de mudanças de pós fatoração.

25 24 Participantes de fatoração O mecanismo de criação de fatorações do LTK, permite que se crie pontos de extensão com a possibilidade de outros plug-ins ou o próprio declarante participarem de uma determinada fatoração. Os participantes de fatoração são os objetos que podem vir a serem executados quando ela for executada. Cada participante de fatoração deve obrigatoriamente definir um enablement que recebe como parâmetro um object representando o objeto que está sofrendo a fatoração, uma lista de natures que são afetadas pela fatoração e um processorid que é o identificador corresponde ao processador da fatoração. O enablement com posse destes parâmetros, faz as verificações que ache necessário para decidir se o participante deve ou não ser habilitado. Algumas fatorações de caráter genérico são por padrão passíveis de se adicionar participantes. Como exemplo, pode-se citar as fatorações rename, delete e move. Quando algum objeto que pode ser afetado por tais fatorações é renomeado, apagado ou movido, todos os participantes que foram adicionados àquela fatoração, são executados. Suponha que deseja-se que ao apagar uma figura que é utilizada por um aplique telis, sejam criadas marcações de erro no editor, nas linhas de código que fazem referencia à figura. Isso pode ser feito adicionando-se um participante de delete configurado para executar quando o object que ele receber como parâmetro seja uma figura e ela esteja sendo utilizada num aplique. Pode-se criar uma fábrica de adaptadores, que adapte um arquivo à figura telis, e deixar que tal adaptador verifique se tal arquivo é ou não uma figura utilizada em código telis, em outras palavras, se é adaptável a figura telis. Caso afirmativo, a ação da inclusão de marcações de erro é executada, ou seja, o participante é habilitado, caso contrário, nada é feito.