Vorlesung Software-Reengineering Prof. Dr. Rainer Koschke Arbeitsgruppe Softwaretechnik Fachbereich Mathematik und Informatik Universität Bremen Wintersemester 26/07 Überblick I 1
1 Ausgangsszenario für Statische Analyse Dynamische Analyse Probleme der dynamischen Analyse Statische und dynamische Analysen Fallstudien Inkrementelle Analyse Szenarien, Merkmale, Routinen Bewertung Wiederholungsfragen Rainer Koschke (Univ. Bremen) Vorlesung Software-Reengineering WS 26/27 3 / 37 Lernziele Ausnutzung aller verfügbarer Information (statisch und dynamisch) Suche nach Merkmalen (statt Programmmustern) Kontext Weitere Anwung der Begriffsanalyse Unterstützung der Lokalisierung beim Programmverstehen Rainer Koschke (Univ. Bremen) Vorlesung Software-Reengineering WS 26/27 4 / 37
Szenario für Ihre Aufgabe ist es, für ein System mit mehr als 10,0 Routinen ein Merkmal hinzuzufügen, zu korrigieren oder zu ändern oder einfach die Implementierung eines Merkmals zu verstehen. Wo beginnen Sie? : welche Komponenten eines Systems implementieren ein einzelnes Merkmal bzw. eine Menge von Merkmalen? Rainer Koschke (Univ. Bremen) Vorlesung Software-Reengineering WS 26/27 5 / 37 Merkmale und Komponenten Ein Merkmal ist eine realisierte funktionale oder nicht-funktionale Eigenschaft des Systems. Eine Komponente ist eine ausführbare Einheit, z.b.: eine einzelne Anweisung oder ein Ausdruck, eine Routine (Funktion, Prozedur), ein Modul, ein Subsystem, eine Task, ein Thread oder Prozess. Im Folgen: Merkmal = von außen anstoßbares und beobachtbares Verhalten des Systems, das auf Komponenten abgebildet werden kann. Komponente = Routine. Rainer Koschke (Univ. Bremen) Vorlesung Software-Reengineering WS 26/27 6 / 37
Statische Analyse nach Chen und Rajlich (20) source code call graph extractor call graph call graph traversal Probleme: Wo beginnen? Wo fortfahren? Wo aufhören? Präzision der statischen Extraktion? Rainer Koschke (Univ. Bremen) Vorlesung Software-Reengineering WS 26/27 7 / 37 Zwei dynamische Ausführungs-Traces nach Wilde u. a. (1992) source code compiler executable invoke with feature invoke w/o feature trace trace profiler profiler invoking input set excluding input set difference starting set for static analysis Rainer Koschke (Univ. Bremen) Vorlesung Software-Reengineering WS 26/27 8 / 37
Dynamische Analyse Dynamischer Aufrufgraph unter Verwung des Merkmals Dynamischer Aufrufgraph ohne Verwung des Merkmals Resultat Rainer Koschke (Univ. Bremen) Vorlesung Software-Reengineering WS 26/27 9 / 37 Probleme der dynamischen Analyse Invoking-Input-Set Excluding-Input-Set kann immer noch sehr viele nicht-merkmalspezifische Routinen sowie nicht wirklich merkmalspezifische Routinen enthalten. Resultate hängen von der Eingabe ab; d.h. Resultate bilden nur einen Startpunkt für weitere statische Analysen. Wo soll mit der statischen Analyse begonnen werden? Das Resultat differenziert die identifizierten Routinen nicht weiter. Rainer Koschke (Univ. Bremen) Vorlesung Software-Reengineering WS 26/27 10 / 37
Statisch und dynamisch nach Eisenbarth u. a. (23) invoke feature f1 invoke feature f2 invoke feature fn trace trace trace profiler profiler profiler routines (f1) routines (f2)............,... routines (fn) invocation table compiler executable concept analysis source code call graph extractor call graph call graph traversal concept lattice Rainer Koschke (Univ. Bremen) Vorlesung Software-Reengineering WS 26/27 / 37 Begriffsanalyse I Merkmal f1 Merkmal f2 Merkmal f3 Rainer Koschke (Univ. Bremen) Vorlesung Software-Reengineering WS 26/27 12 / 37
Begriffsanalyse II main r1 r2 r3 r5 r7 r8 r9 r r12 r14 r15 r16 r17 r18 f3 f2 f1 main r1 r3 r5 r7 r8 main r1 r3 r5 r7 r8 main r1 r3 r5 r7 r17 r9 r14 r15 r16 r17 r2 r18 r r12 f2 f3 main r1 r3 r5 r7 r8 r17 f1 f2 f3 main r1 r3 r5 r7 Begriffsverband Kontext: Routinen Objekte Merkmale Attribute r wird aufgerufen für m Relation Rainer Koschke (Univ. Bremen) Vorlesung Software-Reengineering WS 26/27 13 / 37 27-01-21 Vorlesung Software-Reengineering Statische und dynamische Analysen Begriffsanalyse Begriffsanalyse II f3 f2 f1 main r1 r3 r5 r7 r8 r17 r9 r14 r15 r16 f2 f3 main r1 r2 r3 r5 r7 r8 r9 r r12 r14 r15 r16 r17 r18 main r1 r3 r5 r7 r8 r17 main r1 r3 r5 r7 r8 r17 r2 r18 f1 f2 f3 main r1 r3 r5 r7 Begriffsverband main r1 r3 r5 r7 r r12 Kontext: Routinen Objekte Merkmale Attribute r wird aufgerufen für m Relation Die Darstellung der Relation in Form einer Aufruftabelle erfolgt im Kontext der aus Platzgründen konsequent transponiert, da wir es stets mit mehr Routinen als Merkmalen zu tun haben werden.
Kombination Aufrufgraphen ohne Information des Begriffsverbands Aufrufgraph mit Information des Begriffsverbands Top-down / Bottom-up-Traversierung anhand der Merkmalspezifizität der Nachbarn. Rainer Koschke (Univ. Bremen) Vorlesung Software-Reengineering WS 26/27 14 / 37 Fallstudie zweier Web-Browser Kombination statischer und dynamischer Information angewandt auf zwei Web-Browser: Mosaic (51 KLOC C-Code, ohne Bibliotheken) Chimera (38 KLOC C-Code; ohne Bibliotheken) Zwei Experimente: Partielle Architektur der Browser-History Merkmale: Browsing, Back-Button, Forward-Button Partielle Architektur der Bookmarks Merkmale: Öffnen/Schließen des Bookmark-Fensters, Bookmark hinzufügen/löschen/selektieren Rainer Koschke (Univ. Bremen) Vorlesung Software-Reengineering WS 26/27 15 / 37
Reduktion des Suchraumes Rainer Koschke (Univ. Bremen) Vorlesung Software-Reengineering WS 26/27 16 / 37 Fallstudie: Architektur der Firmware eines Chiptesters applications firmware semaphor shared memory message queue YACC parser command constructor response executor executor executor data flow control flow utility functions firmware hardware Rainer Koschke (Univ. Bremen) Vorlesung Software-Reengineering WS 26/27 18 / 37
Begriffsverband für die Firmware Rainer Koschke (Univ. Bremen) Vorlesung Software-Reengineering WS 26/27 19 / 37 Inkrementelle Begriffsanalyse I A1 A2 A3 A4 A5 O1 X X O2 X X X O3 X X O4 X X O5 X X Sei K = (O, A, I) ein Kontext, O O, und A A. Dann ist K = (O, A, I (O A )) ein Subkontext von K und K ist ein Superkontext von K. Annahme: Wir fügen nur Zeilen dazu (für Spalten ist es analog). Rainer Koschke (Univ. Bremen) Vorlesung Software-Reengineering WS 26/27 20 / 37
Inkrementelle Begriffsanalyse II A1 A2 A3 A4 A5 O1 X X O2 X X X O3 X X O4 X X O5 X X Satz. Sei K = (O, A, I) und K = (O, A, I ), wobei O O und I = (I (O A)). Dann ist jeder Inhalt von K ein Inhalt von K. Beweis. Siehe Ganter und Wille (1996). Folgerung. Gemäß dieses Satzes erscheint jeder Intent des Subkontexts im Superkontext. Daraus resultiert die folge Abbildung: (O, A) (σ(a), A) Beweis. Siehe Ganter und Wille (1996). Rainer Koschke (Univ. Bremen) Vorlesung Software-Reengineering WS 26/27 21 / 37 Inkrementelle Begriffsanalyse III Die Abbildung ist eine -erhalte Einbettung, d.h. die partielle Ordnung bleibt vollständig erhalten. Folglich ist der Superkontext eine Verfeinerung des Subkontexts. Mit Hilfe der Abbildung lassen sich alle Begriffe des Subkontexts im Superkontexts wiederfinden. Rainer Koschke (Univ. Bremen) Vorlesung Software-Reengineering WS 26/27 22 / 37
27-01-21 Vorlesung Software-Reengineering Inkrementelle Analyse Inkrementelle Begriffsanalyse Inkrementelle Begriffsanalyse III Die Abbildung ist eine -erhalte Einbettung, d.h. die partielle Ordnung bleibt vollständig erhalten. Folglich ist der Superkontext eine Verfeinerung des Subkontexts. Mit Hilfe der Abbildung lassen sich alle Begriffe des Subkontexts im Superkontexts wiederfinden. Wir erinnern uns, dass Routinen von uns als Objekte betrachtet werden und Merkmale als Attribute und dass die hier gewählte Darstellung der Aufruftabelle der transponierten Relation entspricht. Insofern fügen wir bei der inkrementellen Analyse im Kontext der, bei der wir weitere Merkmale betrachten, tatsächlich nur Zeilen hinzu. Szenarien für ein Zeichenprogramm Em Km Rm Tm Ev Kl Kv Rainer Koschke (Univ. Bremen) Vorlesung Software-Reengineering WS 26/27 23 / 37
Aufruftabelle start draw set center e Em Km Rm Tm x Ev Kl Kv y set right upper set left lower set text set font set size load move circle move ellipse Rainer Koschke (Univ. Bremen) Vorlesung Software-Reengineering WS 26/27 24 / 37 Begriffsverband für den oberen Teil der Tabelle set size set font set text 1 set center e x y 2 3 8 4 5 set right upper set left lower 0 start draw Rainer Koschke (Univ. Bremen) Vorlesung Software-Reengineering WS 26/27 25 / 37
Begriffsverband für die ganze Tabelle set size set font set text 1 set right upper set left lower move ellipse set center e x y 2 3 8 10 4 5 6 7 9 move circle load draw 0 start Rainer Koschke (Univ. Bremen) Vorlesung Software-Reengineering WS 26/27 26 / 37 Szenarien versus Merkmale Ein Szenario kann mehrere Merkmale ausnutzen. Ein Merkmal kann in mehreren Szenarien ausgenutzt werden. Modellierung: Szenario ist eine Menge von Merkmalen Bsp.: Km = {K, m} und Kl = {K, l} und Em = {E, m} Modellierung abstrahiert von Reihenfolge Rainer Koschke (Univ. Bremen) Vorlesung Software-Reengineering WS 26/27 27 / 37
Szenarien S elliptisch Merkmale S M infrastruktur laden malen verschieben start draw Routinen S R Em Km Rm Tm Ev Kl Kv load move circle move ellipse Rainer Koschke (Univ. Bremen) Vorlesung Software-Reengineering WS 26/27 28 / 37 Formaler Kontext K SM = (M, S, S M) mit Begriffsverband B SM : elliptisch malen 1 2 3 4 6 7 verschieben 5 laden 0 infrastruktur Rainer Koschke (Univ. Bremen) Vorlesung Software-Reengineering WS 26/27 29 / 37
set size set font set text 1 set right upper set left lower move ellipse set center e x y 2 3 8 10 4 5 6 7 9 move circle load draw 0 start Rainer Koschke (Univ. Bremen) Vorlesung Software-Reengineering WS 26/27 30 / 37 Begriffsverband für (M R, S, (M S) (R S)) set size set font set text 1 set right upper set left lower move ellipse set center e x y 2 3 8 malen draw 10 4 5 6 7 0 12 elliptisch 9 infrastruktur start move circle verschieben laden load Rainer Koschke (Univ. Bremen) Vorlesung Software-Reengineering WS 26/27 31 / 37
set size set font set text 1 set right upper set left lower move ellipse set center e x y Malen 2 5 6 7 01 8 3 4 0 1 0 1 malen draw 10 0 elliptisch 12 9 move circle verschieben laden load infrastruktur start bedingt spezifisch spezifisch geteilt relevant irrelevant Rainer Koschke (Univ. Bremen) Vorlesung Software-Reengineering WS 26/27 32 / 37 27-01-21 Vorlesung Software-Reengineering Szenarien, Merkmale, Routinen set size set font set text set center e 2 6 3 4 5 7 x 0 1 y 0 1 move circle 0 1 12 8 verschieben elliptisch 10 9 laden load Malen malen draw 0 infrastruktur start bedingt spezifisch spezifisch geteilt relevant irrelevant 1 set right upper set left lower move ellipse spezifischer Begriff. Ein Begriff b aus dem Verband B SR (K SR ) ist für ein Merkmal m genau dann spezifisch, wenn die Szenarien, die das Merkmal m haben, genau den Szenarien entsprechen, die im Inhalt des Begriffes b enthalten sind. Formal entspricht dies σ SM (m) = Inhalt SR (b) relevanter Begriff. Ein Begriff b ist für ein Merkmal m genau dann relevant, wenn der Begriff mehr Szenarien enthält als die, die Merkmal m haben. Im Sinne der Begriffsanalyse heißt das σ SM (m) Inhalt SR (b) bedingt spezifischer Begriff. Ein Begriff b ist von einem Merkmal m genau dann bedingt spezifisch, wenn der Begriff b alle Szenarien enthält, die Merkmal m aufweisen, darüberhinaus aber auch solche, die Merkmal m nicht aufweisen. Formal ist das der Fall, wenn σ SM (m) Inhalt SR (b)
1 27-01-21 Vorlesung Software-Reengineering Szenarien, Merkmale, Routinen set size set font set text set right upper set left lower move ellipse set center e 2 6 3 4 5 7 x 0 1 y 0 1 move circle 0 1 12 8 verschieben elliptisch 10 9 laden load Malen malen draw 0 infrastruktur start bedingt spezifisch spezifisch geteilt relevant irrelevant geteilter Begriff. Ein Begriff b ist für ein Merkmal m genau dann geteilt, wenn der Begriff b Szenarien enthält, die das Merkmal m aufweisen, desweiteren aber auch noch andere Szenarien, dies das Merkmal m nicht haben. In formaler Schreibweise ausgedrückt ist das der Fall, wenn σ SM (m) Inhalt SR (b) aber weder σ SM (m) Inhalt SR (b) noch σ SM (m) Inhalt SR (b) irrelevanter Begriff. Ein Begriff b ist für Merkmal m genau dann irrelevant, wenn keine Szenarien, die das Merkmal m aufweisen, im Begriff b zu finden sind. σ SM (m) Inhalt SR (b) = set size set font set text 1 set right upper set left lower move ellipse set center e x y Elliptisch 2 01 8 3 4 5 0 1 0 1 malen draw 6 12 10 9 01 01 01 0 elliptisch 7 move circle verschieben laden load infrastruktur start bedingt spezifisch spezifisch geteilt relevant irrelevant Rainer Koschke (Univ. Bremen) Vorlesung Software-Reengineering WS 26/27 33 / 37
set center e x y Laden 2 8 set size set font set text 3 4 5 malen draw 10 1 01 01 01 6 7 0 set right upper set left lower elliptisch move ellipse 12 9 move circle verschieben laden load infrastruktur start bedingt spezifisch spezifisch geteilt relevant irrelevant Rainer Koschke (Univ. Bremen) Vorlesung Software-Reengineering WS 26/27 34 / 37 Bewertung Kombination statischer und dynamischer Information und Begriffsanalyse reduziert den Suchraum drastisch. Begriffsverband unterstützt die Navigation bei statischer Suche. Die Relation für Begriffsanalyse ist tatsächlich eine Relation zwischen Routinen und Eingabedaten für Programmläufe Über Relation zwischen Szenarien und Merkmalen ist Verfeinerung möglich Begriffsverbände können unübersichtlich groß werden, wenn viele Merkmale betrachtet werden. Inkrementelle Kombination von Teilverbänden ist notwig (und möglich). Rainer Koschke (Univ. Bremen) Vorlesung Software-Reengineering WS 26/27 35 / 37
Wiederholungs- und Vertiefungsfragen I Wie kann man bei der Lokalisierung von Merkmalen prinzipiell vorgehen, d.h. welche Verfahren kommen in Frage? Wie könnnen Merkmale mit Hilfe der Begriffsanalyse identifiziert werden? Was ist der formale Kontext hierfür? Welche Rolle spielt der Begriffsverband? Wie lässt er sich interpretieren? Welche Rolle spielt die statische Analyse? Warum ist sie notwig? Wie funktioniert die inkrementelle Begriffsanalyse? Und wie kann dies für die ausgenutzt werden? Wie findet man Merkmale, wenn es keine Ein-zu-eins-Beziehung zwischen Merkmalen und Szenarien existiert? Rainer Koschke (Univ. Bremen) Vorlesung Software-Reengineering WS 26/27 36 / 37 1 Chen und Rajlich 20 Chen, Kunrong ; Rajlich, Václav: Case Study of Feature Location Using Depence Graph. In: Proceedings of the 8th International Workshop on Program Comprehension. Limerick, Irland : IEEE Computer Society Press, Juni 20, S. 241 249 2 Eisenbarth u. a. 23 Eisenbarth, Thomas ; Koschke, Rainer ; Simon, Daniel: Locating Features in Source Code. In: IEEE Computer Society Transactions on Software Engineering 29 (23), März, Nr. 3, S. 210 224 3 Ganter und Wille 1996 Ganter, Bernhard ; Wille, Rudolf: Formale Begriffsanalyse: mathematische Grundlagen. Springer Verlag, 1996 4 Wilde u. a. 1992 Wilde, Norman ; Gomez, Juan A. ; Gust, Thomas ; Strasburg, Douglas: Locating User Functionality in Old Code. In: Proceedings of the International Conference on Software Maintenance. Orlando, FL, USA : IEEE Computer Society Press, November 1992, S. 2 205 Rainer Koschke (Univ. Bremen) Vorlesung Software-Reengineering WS 26/27 37 / 37