TRANSPORT SERVICES A. Maritime Transport

Antes de entrar nos detalhes sobre a implementa¸c˜ao do plug-in Besouro, ´e preciso deixar claro quais foram as principais motiva¸c˜oes que levaram `a escolha do Zorro como ponto de partida deste trabalho. As op¸c˜oes descritas na Se¸c˜ao 3 foram analisadas a princ´ıpio do ponto de vista de quem realizaria um experimento a respeito dos efeitos do TDD, como aqueles descritos na Se¸c˜ao 2.5.

A escolha do Zorro, trabalho proposto por Johnson e Hongbing [23], se fez frente a duas outras op¸c˜oes: A abordagem utilizada por M¨uller e H¨offer [33], e o TDDGuide,

proposto por Mishali [32]. A abordagem de Wang e Erdogmus, embora muito relevante, parece ter um grau de granularidade maior em sua an´alise, n˜ao chegando a considerar a seq¨uˆencia de atividades realizadas, ou uma formaliza¸c˜ao precisa do processo, como as outras trˆes.

O primeiro fator considerado na escolha entre elas foi a disponibilidade do c´odigo origi- nal, para an´alise e eventual modifica¸c˜ao. Neste quesito, o Zorro encontrava-se prontamente dispon´ıvel em reposit´orio de c´odigo publicamente acess´ıvel4_{, com termos de licen¸ca claros}

e expl´ıcitos. A ´unica pe¸ca do c´odigo que n˜ao possui licen¸ca open-source ´e o framework Jess, cuja substitui¸c˜ao n˜ao ´e de todo uma tarefa dif´ıcil.

O c´odigo de Mishali tamb´em est´a dispon´ıvel5_{, mas n˜ao foi encontrado em um reposit´o-}

rio de c´odigo versionado, e n˜ao possui termos claros sobre sua licen¸ca. O c´odigo de M¨uller e H¨offer, n˜ao foi encontrado publicado, pelo menos at´e onde sabemos, e infelizmente n˜ao pˆode ser obtido com os autores a tempo para a realiza¸c˜ao deste trabalho.

Em rela¸c˜ao `a profundidade das an´alises, os trabalhos de M¨uller e H¨offer [33] e de Johnson e Hongbing [23] s˜ao bastante semelhantes. Ambos consideram a seq¨uˆencia de atividades realizadas pelo programador, em conjunto com outras m´etricas extra´ıdas do c´odigo, e definem um sistema rigoroso de regras que ´e utilizado para classificar os epis´odios realizados ou detectar infra¸c˜oes espec´ıficas com a t´ecnica.

O trabalho de Mishali tamb´em considera as micro-atividades de programa¸c˜ao e sua seq¨uˆencia, mas aparentemente com menos rigor na defini¸c˜ao da t´ecnica. Ou pelo menos com objetivos diferentes, j´a que ele tem o foco principal no aux´ılio ao programador, durante o processo de programa¸c˜ao.

De modo geral, a abordagem apresentada por M¨uller e H¨offer [33] ´e bastante seme- lhante `a de Hongbing e Johnson, uma vez que ambas analisam a seq¨uˆencia de atividades de programa¸c˜ao e definem um sistema de regras que ´e aplicado a esses dados. M¨uller e H¨offer, no entanto, consideram apenas a conformidade de altera¸c˜oes feitas ao c´odigo de produ¸c˜ao, identificando certas infra¸c˜oes `as regras definidas, enquanto a classifica¸c˜ao de epis´odios do Zorro parece ser mais abrangente, classificando toda a seq¨uˆencia, e reconhe- cendo epis´odios de refactorings em c´odigo de testes, dentre outros.

Os crit´erios de compara¸c˜ao s˜ao detalhados na Tabela 3.2. ´

E preciso reconhecer, contudo, que a abordagem de M¨uller e H¨offer [33] teve grande influencia sobre as id´eias formuladas neste trabalho. Uma delas ´e o armazenamento das v´arias vers˜oes do c´odigo fonte e an´alise de suas diferen¸cas. Outra ´e a instrumenta¸c˜ao do c´odigo para rastrear ou medir as ´areas de c´odigo cobertas pelo teste. Por fim, e talvez o ponto mais importante, na relevˆancia dada `a diferencia¸c˜ao dos epis´odios dos tipos refactoring e production, o que ser´a melhor discutido mais adiante.

A abordagem de Mishali et al. [32] tamb´em teve influˆencia no trabalho aqui apresen- tado. ´E o caso da op¸c˜ao em processar as regras de inferˆencia de modo on-line, criando a possibilidade de dar feedback imediato ao programador - funcionalidade que beneficiaria qualquer uma das abordagens aqui listadas.

4_{Reposit´orio com o c´odigo original do Zorro: http://code.google.com/p/hackystat-ui-zorro/} 5_{http://ssdl-wiki.cs.technion.ac.il/wiki/index.php/Using Aspects to Support the Software Process}

Tabela 3.2: Crit´erios de Compara¸c˜ao entre as Abordagens Abordagem Disponibilidade do C´odigo Profundidade da An´alise Johnson e Hong- bing [23] Dispon´ıvel, versio- nado e devidamente licenseado

Todos os tipos de ati- vidade no c´odigo de produ¸c˜ao e de teste M¨uller e H¨offer [33] N˜ao Dispon´ıvel Apenas infra¸c˜oes `a re-

gra principal no c´o- digo de produ¸c˜ao Mishali [32] Dispon´ıvel, n˜ao versi-

onado e sem termos de licensa expl´ıcitos

Apenas infra¸c˜oes a re- gras, definidas com menos rigor.

Cap´ıtulo 4

O Plug-in Besouro

Besouro ´e um sistema, projetado como um plug-in para a IDE Eclipse1, que tem por objetivo ajudar a evoluir a defini¸c˜ao operacional de TDD, por meio do sistema de regras proposto pelo trabalho em que Hongbing e Johnson apresentam a ferramenta Zorro [23]. O plug-in ´e sens´ıvel `as atividades de programa¸c˜ao realizadas na interface do Eclipse. Ele as agrupa, assim como o Zorro, e permite que se apliquem um ou mais sistemas de regras semelhantes ao original, para compara¸c˜ao entre eles. Os epis´odios classificados s˜ao apresentados na interface, onde o programador pode registrar discordˆancias com as classifica¸c˜oes apresentadas.

Este cap´ıtulo apresenta em detalhes o sistema, desde sua motiva¸c˜ao inicial (Se¸c˜ao 4.1), passando por sua arquitetura (Se¸c˜ao 4.2), e terminando com uma reflex˜ao sobre a natureza e os objetivos do plugin (Se¸c˜ao 4.3).

4.1

Motiva¸c˜ao

O primeiro impulso para avaliar uma adapta¸c˜ao do c´odigo do Zorro foi devido ao fato de o c´odigo original se encontrar obsoleto em rela¸c˜ao ao sistema sobre o qual foi desenvol- vido originalmente, pelo menos at´e a ´epoca em que este trabalho vinha se delineando: o Hackystat [24]. Tendo este evolu´ıdo sua arquitetura original, em que o Zorro se adequava como um componente, o sistema de regras original precisava j´a de alguma interven¸c˜ao para que pudesse ser usado.

Uma vez que a finalidade inicial da pesquisa era apenas a de utilizar o Zorro como m´etrica da conformidade com TDD, para avaliar os benef´ıcios da t´ecnica em um experi- mento, optou-se por evitar as dificuldades e restri¸c˜oes da arquitetura do Hackystat (da nova e da velha) e adaptar o sistema como um plug-in independente. O que n˜ao foi uma tarefa ´ardua, uma vez que se contava com o c´odigo original, composto por um plug-in que coletava os dados e pelo sistema de regras, integrado ao servidor.

A adapta¸c˜ao do sistema tornou-o mais acess´ıvel, uma vez que simplificou muito o pro- cesso de instala¸c˜ao. Se antes era necess´ario instalar uma aplica¸c˜ao servidora (o Hackys- tat), configurar os componentes necess´arios (SDSA e Zorro) e os coletores de dados como plug-in’s do Eclipse em m´aquinas remotas, agora basta instalar o plug-in pelo sistema de auto-update da pr´opria IDE. Al´em disso, a revis˜ao feita ao c´odigo tamb´em contribuiu para

a facilidade de modifica¸c˜ao do mesmo, uma vez que alguns aspectos distintos do c´odigo foram separados, e o sistema de classifica¸c˜ao completamente isolado.

Mas o motivador mais relevante para a altera¸c˜ao do plug-in, sobretudo no que se refere ao sistema de classifica¸c˜ao, diz respeito a algumas discordˆancias de interpreta¸c˜ao, e a limita¸c˜oes observadas durante os primeiros usos do plug-in, ao final da primeira fase de adapta¸c˜ao do c´odigo.

O primeiro ponto que chamou a aten¸c˜ao consiste na interpreta¸c˜ao do crit´erio de con- formidade dos epis´odios test-addition, regression, refactoring e production. Os autores originais interpretaram que a conformidade desses epis´odios deve depender do contexto em que foram realizados. (Por esse motivo, eles ser˜ao chamados daqui pra frente como epis´odios ”sens´ıveis ao contexto”.) Mais especificamente, esses epis´odios s˜ao considerados ”conformes”com TDD se, e apenas se, forem adjacentes a outro epis´odio conforme.

Uma vez que as ´unicas categorias cujo crit´erio de conformidade n˜ao depende do con- texto s˜ao test-first (conforme), test-last e long (n˜ao-conformes), a conformidade daqueles epis´odios fica subordinada ao fato de serem ou n˜ao adjacentes a epis´odios do tipo test-first.

Vejamos um exemplo, ilustrado na Figura 4.1:

Figura 4.1: Exemplo de sequˆencia de epis´odios

Na figura 4.1, os epis´odios de 3 a 8 s˜ao considerados n˜ao-conformes pelo Zorro, pois comp˜oem uma sequˆencia n˜ao adjacente a TF’s. Considerando que, nesse exemplo, todos os epis´odios tenham a mesma dura¸c˜ao, a medida de conformidade com TDD derivada do sistema original seria de apenas 20%, j´a que esses epis´odios s˜ao considerados como n˜ao conformes. Este contra-exemplo trata-se de um caso em que a m´etrica ´e especialmente deturpada, mas serve bem para ilustrar a arbitrariedade da heur´ıstica escolhida.

A justificativa dos autores originais para essa interpreta¸c˜ao ´e a de que esses tipos de epis´odios podem ocorrer tanto na t´ecnica test-first como na test-last. O foco dessa medida ´

e portanto o de diferenciar entre essas duas t´ecnicas, o que parece ter sido motivado pelo fato de que boa parte dos estudos emp´ıricos sobre TDD publicados at´e ent˜ao utilizam a ”t´ecnica”test-last como caso de controle para avaliar os benef´ıcios de um aspecto bem espec´ıfico da t´ecnica: o fato de a escrita do teste acontecer antes da escrita do c´odigo.

A interpreta¸c˜ao aqui proposta, no entanto, pretende considerar a medida de confor- midade em rela¸c˜ao a uma t´ecnica apenas, e n˜ao a duas. Mesmo porque n˜ao se pode considerar que test-first e test-last sejam duas t´ecnicas ”opostas”. Nesse sentido, os epi- s´odios do tipo test-last s˜ao considerados como desvios ou falhas na aplica¸c˜ao da t´ecnica TDD, mas tratam-se de eventos pontuais, cuja relevˆancia no impacto da m´etrica final deve se limitar a isso.

Nessa interpreta¸c˜ao, os epis´odios da figura 4.1, deveriam apresentar 80% de confor- midade, e n˜ao 20%! Ou seja, mesmo que o programador esteja praticando a t´ecnica test-last, sua conformidade com TDD (test-first ) ser´a relativamente alta, j´a que boa parte dos epis´odios praticados ´e tamb´em conforme com essa t´ecnica.

A proposta apresentada neste trabalho, e experimentada com o sistema Besouro, ´e a de remover a heur´ıstica baseada no contexto, e interpretar a conformidade desses epis´odios com a t´ecnica, o que condiz com as descri¸c˜oes originais da t´ecnica [6]. A interpreta¸c˜ao que se sugere para os epis´odios ´e a seguinte:

• test-additions, regressions, refactorings s˜ao sempre conformes, • productions s˜ao sempre n˜ao-conformes.

Outro ponto importante que motivou a revis˜ao do sistema original Zorro foi a obser- va¸c˜ao de que, gra¸cas `a maneira como as regras foram definidas, acaba-se gerando mais de uma classifica¸c˜ao para cada epis´odio reconhecido. O sistema original, entretanto, escolhe apenas a primeira delas, o que consiste em um crit´erio arbitr´ario e simplista. Isso foi percebido nos primeiros testes feitos durante a adapta¸c˜ao do c´odigo original na forma de um plug-in independente, e durante a primeira fase do estudo, descrita na Se¸c˜ao 5.1.1. ´E ainda um dos principais pontos analisados no Cap´ıtulo 5.

Esses foram apenas os pontos que mais chamaram aten¸c˜ao no sistema. Sempre existi- r˜ao, contudo, poss´ıveis melhorias a serem incorporadas. Esta ´e uma quest˜ao importante, que se discute na Se¸c˜ao 4.3 mais a frente, e para a qual se acredita estar contribuindo tamb´em neste trabalho.