Sumarizao de Rastros de Execuo para ca ca Recuperao de Vises de Alto N ca o vel em Sistemas Orientados a Objetos

Luciana L. Silva, Sandra de Amo e Marcelo de A. Maia

Universidade Federal de Uberlndia, Faculdade de Computaao, Brasil a c luciana.lourdes@gmail.com,deamo@ufu.br,marcmaia@facom.ufu.br

Resumo. Vrias abordagens para facilitar a compreenso do compora a tamento de sistemas de softwares tm sido propostas. No entanto, no e a existe uma abordagem amplamente aceita que recupera informaoes em c alto n vel de abstraao sobre a estrutura e comportamento de sistemas c complexos. Neste trabalho apresentada uma abordagem para simplie car tarefas de compreenso de programas orientados a objetos. A abora dagem prope uma tcnica para reconstruo de diagramas estruturais e o e ca comportamentais de alto n baseada na anlise de rastros de execuao vel a c sumarizados. E apresentada avaliaao do desempenho da abordagem em c termos de preciso e recall em dois sistemas pblicos de terceiros, dentre a u eles o servidor Web Tomcat. O resultado sugere a viabilidade da abordagem para uso em sistemas reais de larga escala.

Palavras chave: Sumarizao; Rastros de Execuo; Recuperao de Arca ca ca quitetura; Vises Dinmicas. o a

Introduo ca

Vrias tentativas para facilitar a compreenso de sistemas de software surgiram a a baseadas nas hipteses que o cdigo fonte a unica fonte de informao convel o o e ca a sobre o sistema dispon [1], [3], [5], [7]. Tcnicas atuais para compreenso de vel e a programas so insucientes para habilitar desenvolvedores para compreender a rapidamente a implementao de uma caracter ca stica do software. IDEs recentes fornecem ferramentas de depurao importantes para compreender o comportaca mento do sistema, mas fornecem somente vises rudimentares sobre a arquitetura o que so denidas principalmente pela organizao de pacotes do projeto. a ca Existem vrias tcnicas para ajudar a compreenso de sistemas em alto n a e a vel de abstrao [9], [11]. Estas abordagens usam informaes estticas sobre o ca co a cdigo ou informaes dinmicas de programas, como rastros de execuo ou o co a ca mesmo uma combinao de ambas [6]. Rastros de execuo tm sido aplicados ca ca e para identicar quais partes do cdigo implementam funcionalidades espec o cas [10]. No entanto, rastros de execuo so dif ca a ceis de analisar porque mesmo para cenrios pequenos de sistemas do mundo real, um rastro pode ter centenas de a milhares ou milhes de chamadas de mtodos. o e

Figura 1. Descriao das 4 fases da abordagem proposta. c

Em [3] foi proposto um tipo de simplicao que consiste na remoo de loops ca ca e recurses porque, no geral, chamadas de mtodos repetitivas no fornecem o e a informao interessante para compreender a estrutura do sistema. Alm disso, ca e o benef das repeties parecem no pagar o preo de um rastro de execuo cio co a c ca muito grande. Mesmo com estas remoes, os rastros geralmente permanecem co grandes. A contribuio deste artigo a denio e avaliao de uma nova proposta ca e ca ca para a anlise de rastros de execuo que dene uma noo de chamadas de a ca ca mtodos relevantes. E baseada em uma tcnica que chamamos de sumarizao de e e ca rastros, que promove uma reduo de tamanho dos mesmos, equilibrando com o ca problema de perda de informaes importantes. Embora IDEs possuam mecanisco mos de depurao que auxiliam em compreender como os objetos se interagem ca uns com os outros, a cooperao do ponto de vista global no clara. Nossa ca a e abordagem tem como objetivos fornecer vises estruturais e comportamentais o de alto n vel, sob o ponto de vista global de uma caracter stica do sistema. O restante deste artigo organizado da seguinte maneira. A Seo 2 apree ca senta a abordagem para sumarizao de rastros de execuo. A Seo 3 fornece ca ca ca resultados experimentais em dois sistemas de software. A Seo 4 compara a ca abordagem com trabalhos relacionados e a Seo 5 conclui o trabalho. ca

A Abordagem Proposta

O objetivo desta proposta recuperar informaes importantes dos rastros de e co execuo para auxiliar na redocumentao de sistemas existentes tanto com moca ca delos estruturais quanto comportamentais. As informaes so representadas em co a uma rvore simplicada, onde o analista pode inserir valores de ltros para sima plicar a anlise visual. A Figura 1 ilustra uma viso gero da abordagem proa a a posta. O processo consiste de quatro fases: 1) Denio e Execuo dos Cenrios ca ca a de Execuo, 2) Sumarizao dos Rastros de Execuo, 3) Anlise dos Rastros ca ca ca a Sumarizados e 4) Agrupamento da Tree View.

2.1

Denio e Execuo dos Cenrios de Execuo ca ca a ca

No primeiro passo, o analista deve denir um cenrio t a pico de execuo, que ca consiste de vrios passos funcionais. Um exemplo de cenrio de execuo que a a ca utiliza a biblioteca de persistncia de objetos Prevayler 1 para transferir fundos e entre duas contas bancrias inclui: 1) Inicializar o Sistema, 2) Criar Conta Cora rente C2, 3) Depositar Dinheiro em C1, 4) Criar Conta Corrente C2, 5) Depositar Dinheiro em C2, 6) Transferir dinheiro de C1 para C2. Por exemplo, o interesse da execuo deste cenrio obter informaes espec ca a e co cas de como uma conta corrente criada e como um depsito efetuado. No prximo passo, para coletar e o e o os rastros de execuo, o sistema alvo deve ser recompilado com suporte a asca pectos para a coleta do rastro pela nossa ferramenta de instrumentao, baseada ca em AspectJ2 . A ferramenta solicita ao analista que informe o in de cada nova cio funcionalidade. Quando a execuo desta funcionalidade termina, o analista inca forma tal evento. Durante a execuo do cenrio, um arquivo de rastro criado ca a e para cada thread disparada. Cada linha do arquivo de rastro corresponde a uma chamada de mtodo com o nome do mtodo qualicado, seu n correspondente e e vel na pilha de execuo (para construo da rvore de chamadas representada em ca ca a uma Tree View ) e o tempo da chamada. 2.2 Sumarizao dos Rastros de Execuo ca ca

O objetivo desta fase sumarizar os rastros de execuo que em muitas vezes so e ca a muito volumosos, mesmo aps a execuo do algoritmo de compresso proposto o ca a em [3] para remover chamadas recursivas e laos, e extrair informao relevante c ca pode ser uma tarefa muito dif cil. A sumarizao de rastros baseada na elimca e inao de chamadas de mtodos com baixa granularidade. A granularidade de ca e uma chamada calculada sobre o nmero de chamadas que ocorreram dentro e u da chamada atual. Quanto maior for o nmero de chamadas internas, maior u e a granularidade e a importncia relativa sobre as outras chamadas. Assume-se a como hiptese que, chamadas de mtodos com granularidades maiores em um o e rastro so os mtodos mais relevantes para a execuo de uma determinada a e ca funcionalidade. Quanto menor a granularidade m e nima escolhida, menor o e nmero de chamadas de mtodos removidas do rastro e assim maior o nmero u e e u de poss veis informaes irrelevantes para analisar, porm menor a chance de co e e descartar chamadas de mtodos relevantes. Com o intuito de descobrir qual seria e a granularidade m nima adequada para a sumarizao dos rastros sem perda de ca informaes relevantes, foram feitos vrios testes preliminares sobre diferentes co a cenrios em sistemas distintos. Aps as anlises, pde-se observar que boas sumaa o a o rizaes ocorreram com taxa de sumarizao em torno 93%. Com base nestes co ca resultados o algoritmo de sumarizao foi automatizado, sem a necessidade do ca analista informar a granularidade m nima. Entretanto, pode-se usar tambm e congurao manual para denir a granularidade m ca nima. Para encontrar a granularidade m nima mais adequada, o analista comea com a granularidade igual c
1 2

http://www.prevayler.org/wiki/ http://www.eclipse.org/aspectj/

Figura 2. (a) Rastro apenas comprimido (b) Rastro comprimido e sumarizado.

a 1 e analisa o resultado correspondente. Se ainda contm muita informao para e ca analisar, a granularidade pode ser aumentada. Se a granularidade maior elimina chamadas de mtodos relevantes, ento a granularidade anterior considerada a e a e ideal. A identicao de chamadas relevantes/irrelevantes depende da percepo ca ca do analista, sendo portanto subjetiva. A Figura 2.a mostra como exemplo um fragmento de um rastro real comprimido representado em uma Tree View. As setas cinzas mostram as chamadas que sero podadas durante a execuo do a ca algoritmo de sumarizao se a granularidade m ca nima for 3. A Figura 2.b mostra o rastro sumarizado. 2.3 Anlise dos Rastros Sumarizados. a

Nesta fase, uma Tree View gerada a partir do rastro de execuo sumarizado e ca para cada funcionalidade executada no cenrio. A ferramenta de visualizao a ca dos rastros possui trs ltros aplicados sequencialmente e afetam somente a Tree e View ocultando os mtodos da visualizao. O sistema sugere valores default para e ca os ltros, tal que no ocorra nenhuma ltragem adicional. Caso a visualizao a ca default no seja satisfatria, o analista pode alterar os valores dos ltros, ocula o tando chamadas com baixa granularidade. O primeiro parmetro de ltragem a a profundidade mxima da rvore, que oculta os ns mais profundos. O see a a o gundo parmetro de ltragem o nmero mximo de ns por n a e u a o vel. O terceiro parmetro de ltragem a porcentagem m a e nima de granularidade de ns em um o n vel, considerando a rvore podada aps a execuo do terceiro ltro. O valor a o ca inicial deste parmetro zero e o usurio vai aumentando em uma unidade at a e a e que todas ou grande parte das chamadas de mtodos com baixa granularidade e sejam omitidas. Por exemplo, se em um n arbitrrio da rvore existem 5 ns o a a o lhos com granularidades cujos valores so 20, 20, 20, 21 e 19 e o parmetro a a 20, ento o quinto n podado. Este ultimo ltro geralmente aplicvel a e a o e e a a rvores de rastros muito profundas, isso depende de cada sistema a ser avaliado. Nos estudos de casos apresentados neste artigo, as rvores tem vrios lhos e a a

Figura 3. Transformao da Tree View para o diagrama de sequncias. ca e

Figura 4. Transformao da Tree View para o diagrama de pacotes do Javac. ca

no so muito profundas. Assim, este terceiro parmetro no foi alterado, pera a a a manecendo o valor default da ferramenta. A Figura 3 mostra a Tree View gerada pela ferramenta de visualizao de rastros e o diagrama de sequncias obtido a ca e partir da Tree View. A funcionalidade selecionada Depositar Dinheiro em C1 e do cenrio do Prevayler apresentado na subseo 2.1. a ca Por meio de anlise da Tree View poss recuperar diagramas de pacotes a e vel do sistema, porque em cada n, que representa uma chamada de mtodo, contm o e e as informaes como nome do pacote, da classe e do mtodo. Ento, para obter co e a uma viso geral da arquitetura do sistema, poss agrupar vrios diagramas a e vel a de pacotes de vrias execuoes de diferentes cenrios em um unico diagrama. A a c a Figura 4 mostra o diagrama de pacotes recuperado dos rastros de execuo do ca compilador Javac do OpenJDK3 6.0, uma implementao do compilador Java. ca 2.4 Agrupamento da Tree View O diagrama de sequncias pode ser constru com n e do veis de detalhes diferentes, de acordo com diferentes parmetros selecionados na fase anterior. No ena
3

http : //openjdk.java.net/

Figura 5. Fases de agrupamento do algoritmo.

tanto, em sistemas complexos o diagrama pode ser dif de compreender porque cil mesmo aps todo o processo de sumarizao, o nmero de chamadas de mtodos o ca u e talvez ainda seja maior que o desejado. A razo que o n de abstrao do a e vel ca cdigo fonte talvez esteja muito detalhado para captar intenes de projeto. Por o co esta razo, o objetivo desta fase agrupar sub-rvores para simplicar a viso a e a a do diagrama de sequncias recuperado. Cada grupo de objetos das sub-rvores e a pode ser visto como um componente. A Figura 5 mostra o algoritmo para agru par sub-rvores de maneira bottom-up. E fornecido como entrada o nmero M de a u componentes esperados. Seja T uma rvore de rastros. No primeiro passo, todos a os ns folhas so selecionados e considerados como sub-rvores de componentes o a a candidatos (Figura 5.b). Inicialmente, o nmero N de sub-rvores obtidas igual u a e ao nmero de folhas na rvore T. No prximo passo, cada n folha nf agrupado u a o o e com seu n pai np se este possuir mais de 1 lho. Neste caso, o n pai passa a ser o o a raiz da sub-rvore obtida. Neste caso, N necessariamente reduz (Figura 5.c). a Nos prximos passos, np agrupa com seu n pai se a mesma condio for satiso o ca feita (Figura 5.d). O processo executado at N no puder ser mais reduzido ou e e a se N igual ao M desejado. A Figura 5.e mostra as principais sub-rvores nais e a de componentes candidatos.

Avaliao da Abordagem ca

O objetivo desta seo avaliar a qualidade de diagramas de sequncias reca e e cuperados pela abordagem proposta em dois sistemas de cdigo aberto. Estes o sistemas foram selecionados com o critrio de possuir diagramas de sequncias e e acess veis, para que a qualidade dos resultados obtidos pudessem ser avaliados. Diagramas de pacotes no sero avaliados devido a falta de espao. O primeiro a a c software a ser avaliado o sistema de simulao ATM4 que possui 24 classes. e ca Uma implementao similar em C++ do mesmo sistema foi usado para valca idar a abordagem proposta em [12]. O sistema possui documentos que inclui casos de uso que so necessrios para denir os cenrios. Possui tambm os a a a e diagramas de sequncias correspondentes aos diferentes cenrios. Com estas ine a formaes poss comparar os resultados obtidos pela abordagem proposta. co e vel
4

www.math-cs.gordon.edu/local/courses/cs211/ATMExample/

O segundo sistema selecionado o Tomcat5 6.0, uma implementao das tece ca nologias JavaServlet e JavaServer Pages com aproximadamente 163 KLOC. O sistema possui documentos que inclui: uma viso geral da arquitetura do Tomcat, a descrio detalhada com diagramas de sequncia de como o Tomcat inicializado ca e e e como lida com uma solicitao. Os passos denidos da Seo 2 foram seguica ca dos para reduzir a complexidade dos rastros e extrair informao suciente para ca gerar diagramas de sequncias de alto n e vel, para cada funcionalidade em um cenrio de execuo. Aps a construo dos diagramas de sequncia avaliada a ca o ca e e a relevncia das chamadas selecionadas durante a fase de anlise dos rastros. a a As chamadas apontadas como relevantes pela nossa abordagem foram baseadas em suas granularidades. Os ns de chamadas Reais Positivos(RP) usados como o controle so aquelas contidas na documentao e que esto tambm contidas no a ca a e rastro de execuo de um determinado cenrio. Para validar os reais positivos ca a foi feito um estudo nos documentos, juntamente com rastros de execuo e o ca cdigo fonte para compreender se os mtodos que esto na documentao ainda o e a ca existem no cdigo e se existem, compreender o motivo da ausncia no rastro, o e possivelmente por desuso. Com a sequncia RP denida poss e e vel calcular os seguintes valores que so usados para avaliar a abordagem em termos de prea ciso6 e recall 7 . a VP: Verdadeiros Positivos. Ns de chamadas que foram apontadas por o nossa abordagem e estes esto contidos no conjunto RP. a FP: Falsos Positivos. Ns de chamadas apontadas por nossa abordagem, o mas no necessrias, pois no esto em RP. a a a a FN: Falsos Negativos. Ns de chamadas que estavam contidos no conjunto o RP mas no foram apontados por nossa abordagem. a 3.1 Anlise do sistema de simulao ATM a ca

A seguir so descritas as 4 fases da abordagem para recuperar os diagramas de a sequncias e compar-los com os diagramas existentes na documentao. e a ca 1. Denio e Execuo dos Cenrios. O simulador ATM possui as ca ca a seguintes funcionalidades: Depositar Dinheiro, Transferir Dinheiro, Sacar Dinheiro e Consultar Saldo. As 4 funcionalidades do sistema possuem diagramas de sequncias e comunicao que servem de base para analisar a qualidade do ree ca sultados. A Tabela 1 mostram dois cenrios selecionados para avaliar a qualidade a dos diagramas recuperados. 2. Sumarizao dos Rastros de Execuo. Para cada cenrio executado, ca ca a quatro arquivos de rastros foram coletados, um para cada thread disparada. O compressor foi executado sobre os rastros para remover os laos e as chamadas c recursivas. A sumarizao foi feita manualmente, mantendo as chamadas de ca mtodos com granularidade maior que 1, ou seja, somente foram removidas as e
5 6 7

http://tomcat.apache.org/tomcat-6.0-doc/architecture/index E a proporo dos mtodos relevantes que o sistema selecionou, ex.: V P/(V P + F P ) ca e a proporao dos mtodos selecionados que o sistema selecionou corretamente, ex.: E c e V P/(V P + F P )

Tabela 1. Cenrio de Execuao para o Simulador ATM a c Transferir Dinheiro 1. 2. 3. 4. 5. 6. 7. 8. Inicializar o Sistema Acionar ATM Inserir Carto a Inserir PIN Escolher Tipo de Transaao c Conta para Tranferir de Conta para Tranferir para Valor da Transferncia e Consultar Saldo 1. 2. 3. 4. 5. 6. Inicializar o Sistema Acionar ATM Inserir Carto a Inserir PIN Escolher Tipo de Transaao c Escolher Consulta do tipo de conta

folhas das rvores. Na tentativa de remover chamadas de mtodos com granulaa e ridades maiores ou iguais a 2, mtodos espec e cos com as funcionalidades foram removidas, e por isto usou-se a sumarizao anterior. Finalmente, o compresca sor foi executado sobre os rastros sumarizados para remover repeties que no co a foram detectadas na primeira compresso. A Tabela 2 mostra o resultado de cada a passo para reduzir os rastros de um cenrio. A taxa de reduo no ultrapassou a ca a 90% porque o sistema razoavelmente pequeno. e 3. Anlise dos Rastros Sumarizados. Para as duas funcionalidades, as a threads usadas para gerar os diagramas de sequncias foram as threads 3 e 4. Esta e seleo foi feita com base na separao das tarefas, cuja informao foi obtida ca ca ca durante a execuo dos cenrios permite identicar quais threads e chamadas ca a de mtodos foram usadas para executar uma determinada tarefa. Os mtodos e e para criar os diagramas de sequncias foram selecionados por uma simples vee ricao de nomes dos mtodos, classes e pacotes e a granularidade do mtodo ca e e analisado. Nos rastros do ATM, Session, Transaction so classes potencialmente a importantes no sistema porque seus mtodos aparecem em um n mais alto da e vel Tree View com granularidade alta. Essa armao conrmada com anlise na ca e a documentao. Antes de executar todas as tarefas contidas nas funcionalidades ca do sistema, primeiro criada uma sesso, seguida da criao de uma transao. e a ca ca Transferir Dinheiro. Durante a anlise da Tree View, 17 mtodos foram a e selecionados para a criao do diagrama de sequncias. Na documentao do ca e ca ATM contm uma sequncia de 22 mtodos referentes a este cenrio. Portanto, e e e a o RP = 22 para esta funcionalidade. Consultar Saldo. Atravs da Tree View, 16 mtodos foram selecionados e e para a criao do diagrama. Na documentao contm uma sequncia de 21 ca ca e e mtodos referentes a este cenrio. Logo, RP = 21. A Figura 6 mostra o diagrama e a
Tabela 2. Resultados da Compresso e Sumarizaao dos Rastros de Execuao do a c c Simulador ATM Bruto Comprimido Comp-Sumarizado Comp-Sum-Comp Tamanho do Rastro 373 Taxa de Compresso a Tempo de Execuao(ms) c 271 27,34% 902 109 70,78% 248 107 71,31% 36

de sequncias recuperado a partir dos rastros descrevendo como feito a criao e e ca de uma sesso no sistema relacionados ` consulta de saldo na conta. a a

Figura 6. Diagrama de Sequncias de Consulta de Saldo do Simulador ATM e seus e componentes encontrados.

4. Agrupamento da Tree View. As sub-rvores na Tree View foram a detectadas atravs da execuo do algoritmo GroupTreeView apresentado na e ca Seo 2. Como os diagramas recuperados so pequenos, no h necessidade de ca a a a simplic-los. Os componentes candidados recuperados so Transaction, Transfer, a a Inquiry, NetworkToBank, ReceiptPrinter e CustomerConsole . O componente principal a classe Session , como mostra a Figura 6. e ATM - Anlise dos Resultados. Aps a seleo dos mtodos para constia o ca e tu rem os novos diagramas foi feita uma avaliao de qualidade destes mtodos ca e com os mtodos contidos na sequncia dos Reais Positivos - RP. A sequncia e e e de mtodos selecionada pela abordagem dos rastros referentes ` funcionalidade e a Transferir Dinheiro contm 17 mtodos e a sequncia RP contm 22. Para a fune e e e cionalidade Consultar Saldo contm 16 mtodos e a sequncia RP contm 21. A e e e e Tabela 3 mostra uma anlise dos resultados em termos de VP, FP e FN. Pode-se a observar que a preciso para ambas funcionalidades foram de 100% e que o recall a foi de aproximadamente 76%. Os FN = 5 para os dois cenrios e so os mesmos a a mtodos. Um estudo no cdigo fonte destes 5 mtodos foi feito para identicar a e o e importncia relativa deles na compreenso de cada funcionalidade. Trs so soa a e a mente construtores das classes Message, Receipt e Session , no tendo impacto na a tarefa de compreenso. Os mtodos RP que fazem parte inicializao do sistema a e ca e que no foram apontados pela abordagem so CashDispenser.setInitialCash e a a NetworkToBank.openConnection . O primeiro mtodo faz uma operao de atribuio e ca ca do contedo recuperado pelo mtodo OperatorPanel.getInitialCash que verica a u e quantidade de dinheiro na mquina. O segundo mtodo um stub, no possui a e e a nenhuma linha de cdigo dentro dele. Logo, sua granularidade zero por este o e motivo foi removido pelo algoritmo de sumarizao. Se considerarmos um espao ca c de busca de 373 chamadas originalmente, a preciso obtida com os VP pode ser a considerada signicativa.

Tabela 3. Preciso e Recall para as duas funcionalidades do simulador ATM. a Funcionalidade VP FP FN Preciso Recall a 5 5 100% 100% 77,3% 76,2%

Transferir Dinheiro 17 0 Consultar Saldo 16 0

3.2

Anlise do Tomcat a

As 4 fases a seguir foram executadas com o objetivo de recuperar mtodos ime portantes para a construo dos diagramas de sequncias. ca e 1. Denio e Execuo dos Cenrios. Para avaliar os diagramas reca ca a cuperados do Tomcat, o cenrio selecionado consistiu de duas funcionalidades a existentes: inicializao do servidor e o acesso de dois usurios a uma unica ca a pgina JSP de exemplo, porque existem diagramas de sequncias destas funcioa e nalidades na documentao do sistema para permitir a avaliao. ca ca 2. Sumarizao dos Rastros de Execuo. Durante a execuo do cenrio, ca ca ca a dez arquivos de rastros foram coletados, um para cada thread disparada. O processo de sumarizao similar ao do estudo de caso anterior. Chamadas de ca e mtodos com granularidades menores ou iguais a 2 foram removidas, obtendo e uma reduo no volume dos rastros em mais de 90%. A Tabela 4 mostra o ca resultado de cada passo para reduzir os rastros do cenrio selecionado. a
Tabela 4. Resultados da Compresso e Sumarizaao dos Rastros do Tomcat a c Cr u Tamanho do Rastro 854.255 Taxa de Compresso a Tempo de Execuao(ms) c Comprimido Comp-Sumarizado Comp-Sum-Comp 267.931 68,63% 98.344 32.961 96,14% 3.625 21.651 97,46% 1.068

3. Anlise dos Rastros Sumarizados. a Inicializaao do Servidor. Para criar o diagrama de sequncias foram c e selecionadas as threads 1, 2, 3 e 6. Esta informao foi obtida da separao de ca ca funcionalidades na fase anterior. Os mtodos foram selecionados por uma sime ples inspeo de nomes dos mtodos, classes e pacotes e considerando tambm ca e e a granularidade do mtodo que est sendo analisado. Nos rastros do Tomcat, e a Catalina, Bootstrap e StandardServer so classes potencialmente importantes no a sistema porque seus mtodos aparecem no n mais alto da Tree View com grae vel nularidade alta. Em adio, os nomes das classes e mtodos geralmente tem um ca e nome relacionado com a funcionalidade analisada. Por exemplo, a classe Catalina contm os mtodos: main, process, load e start. Estes nomes de mtodos esto e e e a ligados com a inicializao do servidor. A Thread 1 foi selecionada para construir ca o diagrama de sequncias porque contm o Catalina.start e a documentao do e e ca Tomcat disponibiliza um diagrama similar, tornando a comparao poss ca vel. O diagrama de sequncias recuperado pela abordagem no est apresentado neste e a a artigo por falta de espao devido ao seu tamanho. Durante a anlise da Tree c a View, 42 mtodos foram selecionados para a criao do diagrama de sequncias e ca e de inicializao do sistema. Na documentao do Tomcat contm uma sequncia ca ca e e

de 90 chamadas de mtodos referente ao diagrama de inicializao. Estes mtodos e ca e foram vericados juntamente com o rastro de execuo e o cdigo fonte. Dos 90 ca o mtodos na documentao, somente 51 mtodos esto de fato presentes no rastro e ca e a sequencialmente. Portanto, consideramos o RP de inicializao igual 51. Tanto ca na sequncia de mtodos selecionados para a criao do novo diagrama quanto e e ca na sequncia de mtodos presente na documentao contm mtodos repetidos, e e ca e e porque para executar a inicializao do sistema alguns mtodos so executados ca e a mais de uma vez. Trs (3) classes e quatorze (14) mtodos deixaram de existir e e na verso 6.0 do Tomcat. a Acesso de 2 Usurios a uma Pgina JSP. Para o diagrama de sea a quncias foi selecionado a Thread 9. Com a separao de funcionalidades na e ca fase anterior foi detectado que somente esta thread foi executada no momento em que um usurio acessa uma pgina JSP. Os mtodos foram selecionados a a e da mesma maneira que para a funcionalidade anterior. Nos rastros do Tomcat,
Http11Processor, CoyoteAdapter, StandardEngineValve, StandardHostValve, StandardContextValve,

so classes potena cialmente importantes para esta funcionalidade porque aparecem em um n vel alto da Tree View com granularidade alta. Os nomes dos mtodos tambm esto e e a relacionados com a funcionalidade analisada. Por exemplo, InternalInputBuffer.parseStandardWrapperValve, ApplicationFilterFactory e ApplicationFilterChain Headers, Http11Processor.prepareRequest, CoyoteAdapter.service, CoyoteAdapter.postParseRequest.

Um diagrama de sequncias que descreve o processo de solicitao est dispon e ca a vel na documentao do Tomcat, ento poss avaliar os resultados obtidos na ca a e vel aplicao da abordagem. Durante a anlise da Tree View, 15 mtodos foram ca a e selecionados para a criao do diagrama de sequncias mostrando como feito ca e e a solicitao de uma pgina JSP. Na documentao do Tomcat contm uma ca a ca e sequncia de 35 chamadas de mtodos para esta funcionalidade. Estes mtodos e e e foram analisados juntamente com o rastro de execuo e o cdigo fonte. Dos 35 ca o mtodos, somente 14 esto de fato presentes no rastro. Portanto, consideramos e a RP = 14 para esta funcionalidade. Trs (3) classes e dez (10) mtodos deixaram e e de existir na verso 6.0 do Tomcat. a 4. Agrupamento da Tree View. As sub-rvores na Tree View foram a identicadas atravs da execuo do algoritmo GroupTreeView. A lista de obe ca jetos do diagrama obtido na fase anterior foi relativamente grande e suas respectivas classes foram agrupadas dentro de componentes candidatos: Bootstrap, StandardServer, HostConfig, StandardPipeline, Registry e UserDataBaseRealm. Ao invs de dese crever todas as classes no mesmo n vel do diagrama, tornando o diagrama de sequncias com excesso de informao, o diagrama foi simplicado agrupando e ca vrias classes dentro de componentes. Cada componente contm classes, cujos a e mtodos de objetos invocados para uma funcionalidade espec e ca foi encontrada pelas sub-rvores. Por exemplo, a classe StandardServer presente no diagrama prina cipal contm 21 classes executadas a partir desta classe e o componente Bootstrap e contm 45 classes. Os componentes forneceram uma simplicao do diagrama e ca de sequncia original, reduzindo o esforo para compreender a inicializao do e c ca Tomcat porque mostra uma viso de alto n a vel e ainda possibilita o acesso a chamadas de mtodos intermedirios. e a

Tomcat - Anlise dos Resultados. Aps selecionar os mtodos que consa o e titu ram o novo diagrama feito uma avaliao de qualidade destes mtodos de e ca e acordo com os mtodos contidos na sequncia dos Reais Positivos - RPs. e e Inicializaao do Servidor. A sequncia de mtodos selecionada pela aborc e e dagem contm 42 mtodos e a sequncia RP contm 51. A Tabela 5 mostra uma e e e e anlise dos resultados em termos de VP, FP e FN. A preciso reete diretamente a a no n de detalhamento do diagrama de sequncias obtido pela abordagem em vel e relao ao da documentao, ou seja, quanto mais baixa a preciso, mais detaca ca a lhado estar o diagrama. Se diminuir a granularidade na fase de sumarizao, os a ca FP aumentam, diminuindo a preciso mas o recall aumenta porque os FN dimina uem. Como ocorreram alguns FN, so apresentadas somente chamadas presentes a na execuo da funcionalidadem na documentao e no rastro cr, mas no preca ca u a sentes no rastro sumarizado. Estes mtodos removidos pelo Summarizer pose suem granularidade zero, por esta razo foram removidos por serem ns folhas a o na rvore. Um estudo foi feito destes mtodos juntamente com o cdigo fonte. O a e o primeiro mtodo que no estava presente na Tree View o Catalina.initDirs . Este e a e mtodo reponsvel por ajustar propriedades como catalina.home e catalina.base e e a . Os seguintes mtodos descritos executam atribuio de valores boleanos. O e ca mtodo HostConfig.setDeployXml ajusta a implantao do componente no arquivo e ca de congurao XML. O mtodo HostConfig.setUnpackWars ajusta o ag de WARs ca e descompactados e HostConfig.setXmlValidation ajusta o ag da caracter stica de validao do analisador XML usado quando analisar instncias XML . Estes mtodos ca a e descrevem em detalhes a execuo de uma tarefa durante a inicializao do servica ca dor. A nossa abordagem ajuda a compreender uma funcionalidade espec ca em um alto n de abstrao. Para estes mtodos estarem presentes na Tree View vel ca e seria necessrio manter os mtodos com granularidade zero. O problema que a e e os rastros seriam volumosos, dicultando a extrao dos mtodos VP. Conseca e quentemente, a preciso seria menor que a apresentada na Tabela 5. a
Tabela 5. Preciso e Recall para as duas funcionalidades do Tomcat. a Funcionalidade VP FP FN Preciso Recall a

Inicializaao do Servidor 29 13 22 69,05% 56,86% c Acessar Pgina JSP a 12 3 2 80,0% 85,71%

Acesso de 2 Usurios a uma Pgina JSP. A sequncia de mtodos sea a e e lecionada pela abordagem contm 15 mtodos e a sequncia RP contm 14. A e e e e Tabela 5 apresenta uma anlise dos resultados em termos de VP, FP e FN. a Um estudo dos mtodos FNs foi feito no cdigo fonte para vericar a ime o portncia relativa desses mtodos. O primeiro StandardContextValve.invoke est a e a presente no rastro sumarizado, foi visualizado na Tree View, foi selecionado para criar diagrama, mas no foi considerado VP por no estar na mesma posio a a ca da sequncia de chamadas de mtodos contidos na documentao. O segundo e e ca mtodo StandardWrapper.invoke no est presente no rastro de execuo cr, por e a a ca u alguma razo na execuo do cenrio este mtodo no foi executado. a ca a e a

Trabalhos Relacionados

Rastros de execuo tm sido usados em atividades de compresso de prograca e a mas. Discotect [11] uma tcnica que prope discobrir a arquitetura de sistemas e e o orientados a objetos em execuo. Esta tcnica mapeia regularidades na impleca e mentao do sistema e no estilo arquitetural. A arquitetura recuperada repca e resentada em Acme [2]. Um outra proposta baseada em rastros de execuo [9] ca sugere vises dinmicas e estticas de um sistema de software. A representao o a a ca da viso dinmica atravs da coleta de informaes utis extra a a e e co e das da execuo de um conjunto de cenrios que cobrem as caracter ca a sticas que so usadas a frequentemente. As informaes obtidas so embutidas em um processo de recuco a perao de viso esttica. A abordagem une informao esttica e dinmica em ca a a ca a a uma tcnica de recuperao arquitetural baseada em padres. e ca o Uma tcnica similar [4] ` abordagem proposta neste artigo baseada na e a e remoo de chamadas de funes de utilidade. Um algoritmo para classicar o ca co componente baseado em uma mtrica de fan-in/fan-out para decidir se um e e componente chave ou um componente de utilidade. O trabalho teve sucesso na anlise em um rastro de 100K de chamadas do sistema Weka8 . A abordagem proa posta neste artigo usa diferentes abordagens para denir o que um componente relevante baseado na noo de granularidade. Neste artigo foi feito anlises em e ca a rastros maiores e em sistemas de dom nios diferentes. No entanto, os resultados deles foram positivamente avaliados pela equipe de desenvolvimento Weka e este trabalho no teve os resultados avaliados pelos desenvolvedores dos sistemas. a Outro trabalho com objetivo similar [8] prope um algoritmo que compacta o laos presentes em rastros de execuo usando dados de mltiplas fontes: rasc ca u tros, cdigo fonte e informao de depurao. O objetivo reduzir laos em o ca ca e c rastros de programas e apresentar estes laos em diagramas de sequncias. A c e abordagem foi avaliada em sistemas como web browser, um SGBD relacional e uma IDE. Entretanto, o trabalho no fornece amplas vises de alto n a o vel de uma caractar stica espec ca do sistema. Os diagramas recuperados so locais e a no mostram a relao de muitas classes relacionadas, como apresentado aqui. a ca Porm, nosso trabalho no fornece informao para representar laos nos diae a ca c gramas de sequncias, uma vez que o seria necessria uma anlise manual para e a a vericar se algum fragmento da sequncia est dentro de algum lao. e a c

Concluso a

Neste artigo foi proposta uma abordagem semi-automatizada baseada em anlise a dinmica com uma visualizao grca para facilitar a recuperao de informao a ca a ca ca de alto-n vel de abstrao. A tcnica apresentada foi baseada na relevncia ca e a das chamadas baseada em um conceito de granularidade e no n vel das mesmas na rvore visual gerada a partir dos rastros sumarizados. A tcnica foi a e avaliada em dois sistemas de cdigo aberto diferentes. O processo para recuo perar informao atravs dos rastros foi dividida em quatro fases. Primeiro, os ca e
8

http://www.cs.waikato.ac.nz/ml/weka/

cenrios so denidos e executados. Segundo, os rastros so sumarizados retia a a rando chamadas de mtodos com granularidade baixa. Terceiro, uma anlise e a sobre os rastros sumarizados foi feita para selecionar os mtodos considerados e importantes para a compreenso de uma tarefa. E nalmente, um agrupamento a feito em modo bottom-up na rvore que sugerem poss e a veis componentes. Estes componentes candidatos so uma maneira de simplicar o diagrama de sequncia a e que est sendo constru a do. O processo simples por no requerer congurao e a ca complexa e tambm eciente devido a execuo que pode ser razoavelmente e e ca rpida em qualquer computador de prateleira. Os resultados de preciso e recall a a so expressivos considerando o vasto espao de busca, alm do que o alvo em a c e termos de correo no necessariamente precisa ser o que consta literalmente na ca a documentao utilizada como referncia. ca e Embora os resultados sejam bastante promissores, existem melhorias a serem feitas. Por exemplo, considerando as chamadas de mtodos do Tomcat que foram e podados pelo Summarizer e que so importantes para a compreenso, uma suga a esto para a soluo deste problema seria o analista visualizar as chamadas a ca de mtodos removidas que pertencem a classes selecionadas por ele na fase de e anlise dos rastros. Assim, o analista teria um controle individualizado do que a foi podado e que a tcnica apontou como negativo. e

Referncias e
1. Ducasse, S., Pollet, D.: Software Architecture Reconstruction: A Process-Oriented Taxonomy. In: IEEE Trans. on Soft. Eng., vol.35, no.4, pp. 573-591. (2009) 2. Garlan, D., Monroe, R.T., Wile, D.: Acme: An Architecture Description Interchange Language. In: Proceedings of CASCON, pp. 169-183. Ontario, Canada (1997) 3. Hamou-lhadj, A., Lethbridge, T.C.: Compression Techniques to Simplify the Analysis of Large Execution Traces. In: Proc. of the 10th IWPC, pp. 159-168. (2002) 4. Hamou-Lhadj, A., Lethbridge, T.: Summarizing the content of large traces to facilitate the understanding of the behaviour of a software system. In: Proc. of the 14th IEEE ICPC, pp. 181-190. (2006) 5. Lethbridge, T. C., Singer, J., Forward, A.: How Software Engineers use Documentation: The State of the Practice, IEEE Software, vol. 20, no. 6, pp. 35-39. (2003) 6. Mit, M., Ernst, M.: Static and Dynamic Analysis: Synergy and Duality. In Proc. of the 25th International Conference on Software Engineering ICSE, pp 24-27. (2003) 7. Mller, H.A., et al: A reverse-engineering approach to subsystem structure identiu cation. J. of Soft. Maintenance: Research and Practice. 5(4). pp.181-204. (1993). 8. Myers, D., et al: Utilizing debug information to compact loops in large execution traces. in Proc. of the 14th CSMR, pp. 41-50. Madrid, Spain (2010). 9. Sartipi, K., Dezhkam, N.: An Almalgamated Dynamic and Static Architecture Reconstruction Framework to Control Component Interactions. In: Proc. of the 14th WCRE, pp 259-268. Canada (2007). 10. Sobreira, V., Maia, M.: A Visual Trace Analysis Tool for Understanding Feature Scattering. In: Proc. of the 15th WCRE, pp.337-338. Belgium (2008) 11. Yan, H., et al: DiscoTect: A System for Discovering Architectures from Running Systems. In: Proc. of the 26th ICSE, pp. 470-479. Scotland, UK (2004) 12. Briand, L., Labiche, Y., Miao, Y.: Towards the Revese Engineering of UML Sequence Diagrams. In: Proc. of the 10th WCRE, pp. 57-66. Canada (2003)