Aspectos de implementação

A ferramenta CRISTA foi desenvolvida utilizando-se o ciclo de vida de prototipação evolutiva. Partindo-se dos requisitos listados anteriormente, foram feitos protótipos para

validar, principalmente, a interface e o leiaute mais adequado à aplicação da técnica de leitura Stepwise Abstraction.

As seguintes decisões de projeto foram tomadas:

• O uso da linguagem Java, devido a sua alta popularidade e portabilidade, seguindo os padrões de codificação sugeridos pela Sun Microsystems Inc. (MICROSYSTEMS, 2008). Além disso, a existência de bibliotecas prontas para a criação de metáforas visuais foi um fator decisivo na escolha dessa linguagem.

• Uso da técnica de visualização Treemap devido ao caráter hierárquico do código fonte. Essa técnica contribui diretamente na identificação dos elementos a serem abstraídos, além de utilizar de forma eficiente o espaço disponível na tela. Nesse caso, para a criação dessa metáfora visual, foi utilizada a biblioteca Java chamada Prefuse (PREFUSE, 2008). Poderia ter sido utilizada qualquer outra biblioteca java para a criação da metáfora visual, como por exemplo (CHRISTOPHE, 2009) e (JTREEMAP, 2009), ou até mesmo poderia ter sido construída a metáfora visual sem o uso de uma biblioteca. O uso da Prefuse (PREFUSE, 2008) deu-se pela sua maturidade e pelas várias funcionalidades já existentes nessa biblioteca, como por exemplo, o controle de eventos externos tais como zoom, seleção das estruturas, etc..

• Opção pelo ambiente desktop visando, principalmente, à inspeção individual. A persistência de dados é feita em arquivos e não em bases de dados. Essa característica provê à CRISTA um ambiente portável, pois as inspeções realizadas por um inspetor podem ser enviadas e abertas por outros inspetores ou pelo moderador da inspeção. Essa propriedade foi incorporada à CRISTA pensando justamente nas inspeções assíncronas, nas quais não é necessário estabelecer nenhuma conexão com qualquer outro computador, o que deixa o inspetor livre para trabalhar onde e quando for desejado.

• Uso do padrão de projeto MVC (Model-View-Controller), de maneira a desacoplar as camadas de regras de negócio, de apresentação e de persistência, deixando o código mais legível e aumentando a sua manutenibilidade. A camada VIEW foi implementada usando a biblioteca Swing do Java, além das bibliotecas Jwizard (JWIZARD, 2008) e JavaHelp (JAVAHELP, 2008) para a construção das janelas de wizard e do help respectivamente.

• Uso do JavaCC (JAVACC, 2008) para a criação de módulos responsáveis por realizar o

parser das novas linguagens, de forma que a ferramenta pudesse carregar códigos em

A Figura 6.2 representa o processo de instanciação da ferramenta para que ela aceite programas escritos em uma nova linguagem de programação.

Definição da Linguagem (Arquivo .jj) JAVACC Parser da linguagem f Linguagem A Código na Linguagem A Metáfora Visual

Figura 6.2 - Utilização do JavaCC na arquitetura da ferramenta CRISTA

Assim, para se disponibilizar uma nova linguagem na ferramenta CRISTA, conforme pode ser visto na Figura 6.2, é necessário realizar os seguintes passos:

1) Criar um arquivo de definição da linguagem (.jj) com algumas instruções Java específicas que serão usadas para montar a metáfora visual do código.

2) Executar o JavaCC com esse arquivo, para serem geradas as classes necessárias para realizar o parser.

3) Empacotar e armazenar essas classes, dentro de um arquivo jar.

4) Colocar o arquivo jar dentro de um subdiretório da ferramenta CRISTA, que lê esse arquivo dinamicamente e assim, realiza o parser da linguagem.

O Apêndice A contém o manual completo de instanciação da ferramenta CRISTA para novas linguagens.

A implementação da CRISTA foi realizada pelo autor deste trabalho usando aproximadamente 254 horas de implementação, considerando-se a construção de protótipos, testes funcionais e documentação. A carga horária está representada na Figura 6.3.

Figura 6.3 - Tempo gasto no desenvolvimento da ferramenta CRISTA mês a mês

Uma pequena parte da solução arquitetural da ferramenta CRISTA pode ser vista na Figura 6.4, em que são representadas as principais classes utilizadas no parser do código fonte. Cada arquivo de definição da linguagem (Arquivo .jj) correspondente a uma classe

LanguageParser. A classe Inspection representa o objeto de negócio inspeção e contém,

além de outras coisas, todas as instruções contidas no código fonte. Essas instruções são obtidas por um objeto LanguageParser, o qual realiza o parser do código fonte e devolve todas as instruções contidas no mesmo. Cada instrução é representada pela classe

Statement e possui, entre outros atributos, uma lista de instruções internas

(InsideStatements), e um delimitador de bloco (BlockDelimiter). A classe BlockDelimiter representa um delimitador de bloco e contém as linhas e colunas de início e fim de uma instrução.

Cada linguagem disponível na ferramenta CRISTA (associada a um objeto

LanguageParser) pode ser associada a um objeto Documenter, o qual será usado para

gerar a documentação interna do código. A classe Documenter é uma classe genérica e, por meio de herança, deve ser implementada para cada linguagem, uma vez que cada linguagem possui uma sintaxe específica para comentários, por meio dos quais será feita a redocumentação do código.

Como pode ser observado na Figura 6.4, a classe LanguageParser possui os atributos actualStatement e bDelimiterTemp, os quais são usados no processo de parser do código fonte, não sendo usados em nenhum outro contexto.

Figura 6.4 - Classes responsáveis por realizar o parser do código fonte

Conforme dito anteriormente, a ferramenta CRISTA utiliza a biblioteca de visualização Prefuse (PREFUSE, 2008), a qual fornece um apoio para a construção de metáforas visuais. Conforme pode se observado pela Figura 6.5, foram necessárias as classes TreeMapDisplay, CRISTASquarifiedTreeMapLayout e TreemapWheelListener para a construção da metáfora visual Treemap, bem como para o tratamento de eventos da mesma. Para tanto, bastou herdar algumas classes da biblioteca Prefuse, bem como implementar os métodos de forma que a representação visual e seus eventos correspondessem ao desejado.

A classe TreeMapDisplay , que foi herdada da classe Display, representa um componente Swing onde será desenha a metáfora visual desejada. Essa classe deve conter todas as regras de negócio e eventos da metáfora visual. Assim, é nessa classe que são definidos como se dá a seleção de um elemento no Treemap, quais elementos são visíveis a partir de determinado ponto, bem como as características visuais de rotulação dos elementos e suas cores. Já a classe CRISTASquarifiedTreeMapLayout, que possui uma relação de herança com a classe TreeLayout, contem as diretrizes para o desenho dos retângulos aninhados, de acordo com a técnica de visualização Treemap. Por fim, a classe

TreemapWheelListener é uma classe separada que foi criada para ser responsável por

gerenciar os eventos de zoom manual no Treemap.