Folie 1 Reengineering-Werkzeugen für Webseiten Johannes Martin, University of Victoria Ludger Martin, Technische Universität Darmstadt WSR 2001 Bad Honnef, Mai 2001

Folie 2 Webangebot-Reengineering: Warum? " zunehmendes Alter von Webangeboten " immer größer werdende Datenmengen " Herausforderung für Anbieter: – Wartung und Aktualisierung des Informationsbestandes – Bereitstellung einer ansprechenden und gut zugänglichen Benutzungsschnittstelle " Misserfolg -> Gefährdung des Überlebens

Folie 3 Web-Analysewerkzeuge (kommerziell) " großes Angebot, aber funktional beschränkt auf: – Webseiten-Prüfer " Syntaxanalyse von HTML Seiten " Prüfung von Verknüpfungen – Webstatistik-Werkzeuge " werten Server-Logbücher aus " Statistiken über Nutzung eines Webangebotes

Folie 4 Web-Analysewerkzeuge (Forschungsbeiträge) " Chung und Lee (WISE 2000) – UP und UML zur Darstellung von analysierten Webangeboten – UML-Diagramme zur Veranschaulichung von Verknüpfungs- und Verzeichnisstruktur " Ricca und Tonella (WSE 2000, ICSM 2000) – Graphen zur Darstellung von Struktur und Entstehungsgeschichte von Webangeboten – Analyse von Webseiten mit Frames

Folie 5 Warum das Rad zweimal erfinden? " Software-Reengineering und Web-Reengineering sind verwandt: – Unübersichtlichkeit der Daten wegen großer Datenmenge (Quelltext Webseiten) – Daten ändern sich laufend " Frage: sind Software-Reengineering Werkzeuge flexibel genug, um zum Reengineering von Webangeboten genutzt zu werden?

Folie 6 Fallstudie: Rigi als Web-Reengineering Tool " Rigi besteht aus: – Parsern zur Sammlung von Informationen über zu analysierende Systeme (z.B. Programm-Quelltexte) – Graph-Editor zur Darstellung dieser Informationen – Datenaustausch zwischen Parsern und Graph-Editor geschieht durch gemeinsames Dateiformat und Schema " Alles, was wir brauchen, sind ein Schema und ein Parser für Webseiten

Folie 7 Rigis Webseiten-Schema " Knoten: – HTML-Seiten, Bilddateien, Applets, Webserver,... " Kanten: – Verknüpfungen zwischen den verschiedenen Knoten " Attribute: – URLs der Knoten – MIME-Typen der Knoten – evtl. Zugriffsfehler

Folie 8 Rigis Webseiten-Parser " Verfahren: beginnend mit einem URL – lade URL herunter – suche nach HTML Tags – zeichne Verknüpfungen zu anderen URLs auf – untersuche diese URLs genauso " Optionen: – Einschränkung auf bestimmte URLs – Limitierung der Suchtiefe " programmiert in Java

Folie 9 Beispiel-Analyse:

Folie 10 Beispiel-Analyse (Fortsetzung)

Folie 11 Beispiel-Analyse (Fortsetzung)

Folie 12 Zusammenfassung: " zu analysieren wie ein kleineres Computerprogramm – Layout-Algorithmus zum Gewinnen eines Überblicks – Manuelle Restrukturierung des Graphen " Unterschied: Navigationsmenü und daraus resultierende hohe Verknüpfung von zentralen Webseiten

Folie 13 Beispiel-Analyse:

Folie 14 Beispiel-Analyse (Fortsetzung)

Folie 15 Zusammenfassung: " vergleichbar mit mittelgroßem Computerprogramm – Springlayout nicht mehr sehr hilfreich, lange Laufzeit, dargestellte Struktur ist nicht die logische Struktur – vorhandenes Wissen über Struktur des Systems kann zur Gliederung verwendet werden (hier Verzeichnisstruktur) – einige Details müssen von vorneherein ignoriert werden (Libraries in Programmen, Clipart-Sammlungen hier) – manuelle Manipulation des Graphen ist nicht mehr sinnvoll oder durchführbar, Automatisierung ist nötig

Folie 16 Offene Probleme und Ausblick " unser Parser spiegelt weder die exakte Dateistruktur noch die Benutzeransicht wieder – keine Sonderbehandlung oder Erkennung von Server Side Includes u.ä. – keine Sonderbehandlung oder Erkennung von Frames " Parser-Performanceprobleme: – Java macht es einfach URLs zu bearbeiten, jedoch gibt es Speicherprobleme bei großen Datenmengen – lange Laufzeit da Download der Webseiten nötig – Auswirkungen auf Betrieb der Webserver? " Einbeziehung von Webserver-Logfiles – wer nutzt das Angebot wann, wie, wo und wie oft