Dynamisk analys baseras på insamling av data när programmet körs. Råspår tenderar dock att vara för omfattande och för ostrukturerade för att kunna användas direkt för visualisering och förståelse. Vi hanterar detta problem i två faser: den första fasen väljer undergrupper av data och sedan komprimerar det, medan den andra fasen kodar data i ett försök att dra slutsatser om dess struktur. Våra stora komprimering/urval tekniker inkluderar gprof-stil N-djup samtalssekvenser, urval baserat på klass, komprimering baserat på tidsintervall, och kodning av hela utförandet som en riktad acyklisk graf. Våra strukturinferens tekniker inkluderar run-long kodning, sammanhangsfri grammatikkodning, och byggandet av ändliga tillstånd automata. KEY TEXT Programförståelse, Programspårning, Dynamisk programanalys Programförståelse kräver att man drar slutsatser om beteendet hos programvarusystem. Statiska tekniker gör detta genom att analysera programmets kod, medan dynamiska tekniker är baserade på att köra programmet, coll_ecting data som det körs, och sedan analysera den resulterande data. I det dynamiska fallet finns det inneboende kompromisser om mängden insamlade data, de typer av analyser som kan utföras på dem, och omkostnaderna för insamling. Vi anser att ramar som lämpar sig för dynamisk analys har tre delar. Det nedre skiktet, närmast programmet, är en uppsättning verktyg för att samla information som ett program kör. Det mellersta skiktet väljer relevanta delar av data, som det senare komprimerar och analyserar, effektivt bygga en modell av det. Det översta lagret, närmast användaren, visar dessa modeller. Vi håller på att bygga upp en sådan ram. Den första delen beskrivs i [ 171, men vi går också kort igenom den i avsnitt 2. Huvuddelen av detta papper diskuterar våra 0-7695-1050-7/01 $10,00 0 2001 IEEE mellanlager verktyg. Vi ser det översta lagret som att ha åtminstone kapaciteten hos våra tidigare verktyg [ 151, men med ökade förmågor för att specificera meningsfulla visualiseringar "på begäran", när uppgiften uppstår. Syftet med det mellersta skiktet är att bygga modeller av insamlade data. Det finns två skäl att bygga en modell: För det första är det omöjligt att visualisera rådata, på grund av volymen och komplexiteten i det, och $econd, en modell kan användas för att automatiskt kontrollera egenskaperna hos spåren. Vi vill att våra modeller ska vara användbara i åtminstone följande uppgifter: Sammanfatta delar av ett program exekvering. Sådana sammanfattningar skulle göra det möjligt för oss att visa utförandet på flera detaljnivåer, hjälpa användaren att navigera genom det. 0 Modellerande klassbeteende. Vi kan spåra de externa samtal till metoder som åberopas på alla objekt i en viss klass. Om vi har en serie program som använder klassen korrekt, kan vi använda de abstraktioner som genereras av exekveringsanalys som en modell för hur klassen ska användas. 0 Modellering av biblioteksanvändning. Vi kan se ett helt bibliotek som ett objekt och spåra alla externa samtal till det. Detta skulle göra det möjligt för oss att bygga en modell för korrekt biblioteksanvändning och testa framtida användare av biblioteket mot modellen. Upptäcker ovanliga händelser. Efter att vi har en modell för programmets beteende, bör vi kunna hitta händelser som inte överensstämmer med den modellen. Sådana händelser är ofta betydelsefulla eftersom de utgör exceptionella förhållanden. Till exempel, om ett program utför en sekvens av synkronisering steg nästan hela tiden, men ibland utför en alternativ sekvens, detta betecknar ett potentiellt problem. 0 Kontrollera mot befintliga modeller. Om vi redan har en modell av aspekter av beteendet hos ett system, låt oss säga, från specifikationsprocessen, då bör vi effektivt kunna kontrollera om den modell som produceras av spåren överensstämmer med den ursprungliga. Vi ser också här möjligheten att bygga modeller av designmönster och sedan kontrollera att ett program implementerar dem korrekt. Detta är särskilt användbart för beteendemönster [8], som är svåra att specificera på annat sätt [16]. 221 Ordförande
Liknande spårningskomprimeringstekniker har använts i REF för programförståelse och programvaruvisualisering.
Encoding program executions
{'venue': 'Proceedings of the 23rd International Conference on Software Engineering. ICSE 2001', 'journal': 'Proceedings of the 23rd International Conference on Software Engineering. ICSE 2001', 'mag_field_of_study': ['Computer Science']}