Knowledge Based Software Engineering

Knowledge Based Software Engineering Konferenz-Seminar aus Software-Engineering Wintersemester 2004/2005 Lehrveranstaltungsleiter Roland Mittermeir Institut für Informatik-Systeme Universität Klagenfurt März 2005 TR ISYS-05/03-01

Inhaltsverzeichnis Roland Mittermeir: Konferenzseminar aus Software Engineering: Knowledge Based Software Engineering - Vorwort 1 Peter Jelitsch: Klon-Erkennung mittels Metriken: Von der Erkennung geklonter Funktionen zur Erkennung geklonten Java-Codes 7 Robert Kuschnig: Entfernen von Software-Klonen im Kontext von Refactoring 19 Andrea Oblitschnig: An Einführung in das wissensbasierte Verstehen von Programmen 28 Hartmann Schleifer: Wissensbasierte Software Visualisierung 37 Norbert Zeppitz: Wartung und Evolution großer Software-Systeme: Erfahrungsbericht am Beispiel des AMEISE-Systems 46 Melitta Dragaschnig: Testorakel und automatische Verifizierung von Testresultaten 55 Sabrina Schönhart: Knowledge-based Software Reuse 65 Sibylle Kattnig: Anforderungserhebung und Analyse mit Hilfe von wissensbasierten Systemen 76

Konferenzseminar aus Software Engineering Knowledge Based Software Engineering Vorwort Roland T. Mittermeir 1. Rahmenbedingungen und Ablauf Dieses Konferenzseminar aus Software Engineering war nun bereits die 4. Auflage in vergleichbarer Organisationsform. Dennoch hatte es, teils bewusst, teils durch unglückliche Zufälle eine etwas andere Charakteristik als seine Vorgängerveranstaltungen. Wie diese, hatte es als zentrale Rahmenbedingung, dass sich die Studierenden das konkrete Thema ihres Seminarbeitrags aufgrund eines Call for Contributions selbst wählten (siehe Anhang 1). Aufgrund dieses Call for Contributions war nach ca. 14 Tagen ein Titel vorzuschlagen, der vom Lehrveranstaltungsleiter im Regelfall genehmigt wurde. Gegebenenfalls erhielten die Studierenden Hinweise zur Fokussierung, in Sonderfällen wurde auch von der Wahl des gewünschten Vortragstitels abgeraten. Nach weiteren zwei Wochen war ein Extended Abstract mit den Informationselementen Vortragstitel, Gliederung, einseitige Kurzzusammenfassung und den wesentlichsten zur Verwendung beabsichtigten Quellen einzureichen. Dieses wurde von jeweils zwei Studierenden, einem Mitarbeiter und vom Lehrveranstaltungsleiter begutachtet und kommentiert. Diese Gutachten waren in der zweiten Novemberhälfte fällig. Knapp vor Beginn der Weihnachtsferien mussten die Vollversionen der Seminararbeiten abgegeben werden. Diese wurden wiederum an obige Personengruppen zur Begutachtung ausgesandt. Die entsprechenden Gutachten hatten bis zum 9. Jänner (Ende der Weihnachtsferien) vorzuliegen. Dies erlaubte gerade noch genügend Zeit, sie für die Vorträge zu berücksichtigen. Diese fanden an einem universitätsexternen Ort statt. Heuer wurde nach drei Jahren Einschicht am Falkert eine Pension in Techendorf am Weissensee gewählt. Die Präsenzphase (die Konferenz ) war wie bisher durch gute und engagierte Vorträge und angeregte Diskussion sowohl zum Inhalt der Vortrage als auch zu formalen Aspekten des Vortrags gekennzeichnet. Zwischen diesen Arbeitsblöcken bestand die Möglichkeit, sich durch Schifahren oder Eislaufen aufzulockern. Die hier zusammengefassten Arbeiten sind ausnahmslos Überarbeitungen der im Dezember 2004 abgegebenen Vollversionen der studentischen Beiträge. Das Manuskript des Beitrags einer Mitarbeiterin wurde an anderer Stelle veröffentlicht [1]. Wie bisher bestand die Möglichkeit, das aus dem Begutachtungsprozess sowie aus den Diskussionen nach dem Vortrag gewonnenen Erkenntnisse noch einzuarbeiten. (siehe Zeitplan und Seminarregeln beim Call for Contributions, Anhang 1). Es ist hier anzumerken, dass mit Ausnahme der Vorbesprechung am 11. Oktober, 04 einer Organisationsbesprechung am 10. Jänner 05 und den drei Konferenztagen (Anhang 2: Programm) der gesamte Kommunikationsprozess elektronisch abgewickelt werden sollte. Der Lehrveranstaltungsleiter entschied sich jedoch in diesem Semester den Globalkommentar zu den Extended Abstracts in einer eingeschobenen Veranstaltung zu geben und dabei auch ein Referat über Grundsätze der Erarbeitung wissenschaftlicher Arbeiten zu geben. 2. Spezifische Charakteristika Als spezifische Charakteristika dieser 4. Auflage eines SemSE Konferenzseminars sind vor allem der unterschiedliche Mix an TeilnehmerInnen, der zugänglichere Ort, und der Einsatz eines echten Konferenz- Management-Systems zu nennen. Als weiteres Novum ist bei der Besprechung des Erfolgs der Lehrveranstaltung zu erwähnen, dass erstmals, den Regeln eines Begutachtungsverfahrens entsprechend, die Ablehnung eines Beitrags vorgenommen werden musste. 2.1. Teilnehmerschaft Gegenüber früheren SemSE Konferenzsemiaren stach dieses durch eine weit höhere studentische Beteiligung hervor. Wurden bisherige Seminare auch als Forschungsseminare für Mitarbeiter genützt, war diesmal teils geplant, teils durch Unfall- und nötige Vertre- - 1 -

tung in Lehrveranstaltungen an der Universität neben dem Seminarleiter nur eine wissenschaftliche Mitarbeiterin in der Präsenzphase anwesend. Aus inhaltlichen Gründen hatte diese ihren Vortrag erst am letzten Konferenztag. Der Seminarleiter selbst hielt diesmal keinen Vortrag. Die doch sehr unsymmetrische Zusammensetzung führte dazu, dass die bisher zu beobachtende hohe Diskussionsbereitschaft erst etwas zögerlich einsetzte. Ab dem dritten Vortrag war diesbezüglich jedoch das normale SemSE-Klima der offenen Fragen, wohlmeinenden Hinweise und konstruktiven Kritik gegeben. 2.2. Seminarort Wurde bisher die Einsamkeit eines (bzw. zweier) Chalets am Falkert gewählt, fand nun die Präsenzphase in einem Ort (Techendorf) statt. Dies hatte den positiven Effekt, dass ein breiteres Rahmenprogramm gewählt werden konnte (Schifahren und Eislaufen). Es barg jedoch das Risiko der Fluchtmöglichkeit aus der Gruppe.. Zwar bildete sich in der Tat untertags eine Schifahrgruppe und eine Eislaufgruppe, doch Abends blieb das Seminar so wie auch bisher beisammen. Am ersten Abend war Selbstversorgung geplant, am zweiten Restaurantbesuch. Aufgrund eines hohen Überschusses an Nahrungsmitteln wurden es jedoch zwei Selbstversorgungsabende mit reichlichen (und gut zubereiteten) Spaghetti und Unmengen von Salat und Fruchtsalat. Die Fluchtmöglichkeiten, die der Ort an sich geboten hätte, wurden also nicht genutzt. 2.3. Software-Unterstützung Aus organisatorischer Sicht ist als weitere Innovation der Einsatz eines echten Konferenzmanagementsystems für den Begutachtungsprozess zu nennen. Dieser wurde bisher teils mit BSCW, teils nur über e-mail abgewickelt. Da die Begutachtungsformulare zwar echten Konferenzen nachgebildet sind, jedoch einige Adaptierungen, die für studentische Arbeiten in Lehrveranstaltungen nötig sind, enthalten und da weiters hier großer Wert auf ausreichendes inhaltlich-verbales Feedback gelegt wird, sind viele Konferenzmanagement-Systeme für die Unterstützung einer Lehrveranstaltung wie SemSE ungeeignet. Durch Einsatz des open source Systems myreview, das das Einfügen beliebiger Kommentare, und daher auch das Einfügen spezifisch ausgefüllter Review- Formulare erlaubt, konnte diese Hürde jedoch überwunden werden. myreview unterstützt die Zweiphasigkeit des SemSE Begutachtungsprozesses zwar nicht. Dies kann aber durch Neuladen umschifft werden. Der Einsatz dieses Systems brachte für den Lehrveranstaltungsleiter eine deutliche Arbeitserleichterung. Abgesehen davon bot es gleichzeitig einen Systemtest für die im Frühjahr abgehaltene echte Tagung ISSEP 2005. 3. Erfolg Insgesamt darf die Veranstaltung als Erfolg bewertet werden. Allerdings gab es erstmals einen Teilnehmer, dessen Beitrag nicht angenommen wurde. Insgesamt lagen für das Seminar 15 Anmeldungen vor. Von diesen meldeten sich 2 Studierende noch vor Einreichung eines Vortragstitels ab, einer stellte nach Dialog über den Vortragstitel einen Terminkonflikt fest. Zwei weitere Studierende gaben letztlich kein Extended Abstract mehr ab, sodass in der ersten Phase 10 Arbeiten in Begutachtung gingen. Nach dieser Phase ersuchte eine Studierende wegen Überlastung aussteigen zu dürfen. Sie bot sich allerdings, um das Verfahren nicht zu stören, noch als Gutachterin an (worauf allerdings nicht zurückgegriffen wurde). Ein Teilnehmer legte sich allerdings die Latte zu hoch. Obzwar ihm bereits unmittelbar nach seiner Themenwahl mitgeteilt wurde, dass seine Themenstellung für eine Seminararbeit zu komplex sei und auch im Feedback auf das Extended Abstract deutlich der Ruf nach Fokussierung und Konkretisierung ausgesprochen wurde, legte er letztlich eine nicht präsentationswürdige Arbeit vor. Die angebotene Chance, einen sauber bearbeiteten Ausschnitt daraus noch zu präsentieren und anschließend eine akzeptable Arbeit vorzulegen, nützte er aufgrund der Zeitknappheit zwischen Feedback auf die Vollarbeiten und Präsenzphase nicht mehr. Es zeigte sich somit, wie auch im nach ähnlichen Prinzipien abgehaltenen Bakkalaureats-Seminar [2] im Sommersemester 2004, dass die Möglichkeit, ein innerhalb eines Rahmenthema selbst gewähltes Thema zu bearbeiten zwar zu erhöhter Motivation führt, jedoch auch das Risiko in sich birgt, dass man die Ratschläge aus den diversen Feedbacks zu leicht nimmt, sich in eine für ein Seminarthema zu umfassende Problemstellung verkrallt und letztlich daran scheitert. Die verbliebenen acht Arbeiten sind sicherlich von unterschiedlicher Qualität. Sie entsprechen jedoch m.e. dem, was von Studierenden in einem Spezialseminar erwartet werden darf. Dabei ist anzumerken, dass das Rahmenthema Knowledge Based Software - 2 -

Engineering in einigen Arbeiten mehr als locker interpretiert wurde. Dies wurde vom Seminarleiter jedoch zugelassen, da letztlich im Seminar nur auf den aus dem sonstigen Lehrprogramm vorhandenen Inhalten aufgebaut werden kann. Sie sind herzlich eingeladen, sich durch Lektüre der folgenden Seiten selbst eine Meinung über die Qualität der Arbeiten zu bilden. 4. Literaturverzeichnis [1] K. Hodnigg: Spreadsheet Didactics: Paradigm and Model basierend auf Hodnigg, Clermont, Mittermeir: Computational Models of Spreadsheet-Development: Basis for Educational Approaches ; Proc. EuSpRIG 2004. [2] R. T. Mittermeir (Hrsg.): Software Qualität: Arbeiten des Bakkalaureatsseminars aus Angewandter Informatik, Sommersemester 2004 ; Universität Klagenfurt, Inst. f. Informatik-Systeme, TR ISYS-04/07-01, Juli 2004. - 3 -

Seminar aus Software-Engineering Vorbesprechung und Anmeldung R. Mittermeir Montag, 10. Oktober 2004, 14:00 Wintersemester 2003/2004 SR 2.42 Conference Course on Software Engineering Knowledge Based Software-Entwicklung Call for Contributions Das Seminar aus Software Engineering wird im Wintersemester 2004/2005 wieder als Conference Course geführt (trotz vieler englischer Begriffe ist die Arbeitssprache Deutsch, Englisch ist aber zulässig). Lehrziel ist, dass Studierende durch selbständige Bearbeitung eines aktuellen Themas aus Software Engineering neben fachlichen Kenntnissen auch methodische Kenntnisse im Verfassen wissenschaftlicher Arbeiten (etwa der Diplomarbeit) erwerben, aber auch durch positive Kritik solcher Arbeiten (Führungs- und Teamfähigkeit) zum Gesamtgelingen beizutragen. Methodisch wird dieses Seminar in Form einer kleinen, durch die Seminarteilnehmer getragenen Konferenz durchgeführt. Während der Entwicklungsphase wird die Kommunikation weitestgehend über E-mail und Groupware bzw. ein Konferenz-Managementsystem durchgeführt. Die eigentliche Konferenz (Vortragsphase) findet im Jänner statt. Studierende, die an Fragen modernen Software Engineerings, an der Übung moderner (künftiger) technologiegestützter Kommunikationsformen und/oder an neuen Lernformen interessiert sind, sind herzlich zur Teilnahme eingeladen Seminarthema Thematik des diesjährigen Seminars wird Knowledge Based Software Engineering sein. Dies berücksichtigt, dass Methoden der künstlichen Intelligenz zusehends Eingang in Werkzeuge zur Unterstützung qualitativ hochwertiger Software Entwicklung bzw. effizienter Entwicklungsprozesse findet und dort teils konventionelle Techniken unterstützt, teils zu diesen in Konkurrenz tritt. Terminplan Siehe Aufruf zur Beitragseinreichung Beurteilungsschema Beurteilt wird die auf Individualleistung und Mitarbeit beruhende Gesamtleistung bestehend aus - Qualität des extended Abstracts 20 % - Leistungen im Reviewprozess. Begutachtung d. extended Abstracts und. Begutachtung d. full papers 20 25 % - Full paper. submitted version + final version 40 % - Vortrag 20 25 % - 4 -

Conference Course on Software Engineering Knowledge Based Software Engineering Aufruf zur Beitragseinreichung Sie sind herzlich eingeladen, einen Beitrag zur Thematik Knowledge Based Software Engineering innerhalb der verschiedenen Phasen des Software-Life-Cycles bzw. Aktivitäten der Software Entwicklung einzureichen. Dabei ist zu berücksichtigen, dass Methoden der künstlichen Intelligenz zusehends Eingang in Werkzeuge zur Unterstützung qualitativ hochwertiger Software Entwicklung bzw. effizienter Entwicklungsprozesse findet und dort teils konventionelle Techniken unterstützt, teils zu diesen in Konkurrenz tritt. Dementsprechend wird speziell zu Beiträgen zu folgenden Themen aufgerufen: Support for Program-Comprehension Requirements Elicitation Support Knowledge Based Support during Constructive Phases Knowledge Based Support for Quality Assessment Knowledge Based Support for Software Evolution Sonstige aktuelle Themen aus Software Engineering Zur Beitragseinreichung und Mitwirkung am Konferenz-Seminar ist folgende Vorgangsweise vorgesehen: 11. Oktober 2004, 14:00 HS6 (Mensagebäude) Vorbesprechung, Anmeldung, Terminvereinbarung - bis So 24. Okt. 2003: Anmeldung eines Vortragstitels/Arbeitsthemas - (spätest. +3 Tage) 27. Okt. 2003: Feedback zum bzw. Bestätigung des Vortragstitels durch PCC - bis So 7. Nov. 2003: Einreichen eines Extended Abstracts,. Vortragstitel. Gliederung. einseitige Kurzzusammenfassung. kurze Literaturliste (die 4 wesentlichsten Werke, die man verwenden will) - bis So 14. Nov. 2003: Einlangen der Reviews (Studenten und wiss. Mitarbeiter) am Server - spätest 19. Nov. 2003: Feedback/Zusammenfassung des Program Chair an Einreicher - bis So 12. Dez. 2003: Einlangen der full papers - bis So 9. Jän. 2004: Einlangen der Reviewer Reports am Server 2. Jänner-Häflte (um den 15. Jänner). bis. Jan. 2004: Konferenz / Vorträge - bis Di 15. Feb. 2004: Einlangen der final papers (camera ready version) - 5 -

Konferenz-Seminar aus Software-Engineering Wintersemester 2004/2005 Präsenzphase Mittwoch, 12. Jänner 2005 bis Freitag, 15. Jänner 2005 Ferienwohnungen Knaller-Möd Techendorf 16 A-9762 Weißensee vorläufiges Tagungsprogramm Mittwoch: 13:00. Abreise an den jeweils vereinbarten Treffpunkten (für Einkäufer früher! Uni:Parkplatz West) ab 14:30 Eintreffen in Techendorf, Beziehen des Quartiers anschließend bis 16:00 freie Verfügung, sportliche Aktivität 16:00 16:30 Regenerationsphase 16:30 17:30 Peter Jelitsch: Klon-Erkennung mittels Metriken: Von der Erkennung geklonter Funktionen zur Erkennung geklonten Java-Codes kurze Pause 17:40 18:40 Robert Kuschnig: Erkennen von Software-Klonen im Kontext von Refactoring 18:50 21:00 Küchendienst, Abendessen 21:00 22:00 ggf. 3. Vortrag (Zeppitz, Hodnigg) anschließend freie Diskussion, Sozialphase, Nachtruhe Donnerstag: ab 7:30 Frühstück (aus mitgebrachten Ressourcen!!!) 8:30 9:30 Andrea Oblitschnig: An Einführung in das wissensbasierte Verstehen von Programmen kurze Pause 9:40 10:40 Hartmann Schleifer: Wissensbasierte Software Visualisierung kurze Pause 10:50 12:00 Norbert Zeppitz: Wartung und Evolution großer Software-Systeme: Erfahrungsbericht am Beispiel des AMEISE-Systems 12:00 16:00 freie Verfügung, sportliche Aktivität 16:00 16:30 Regenerationsphase 16:30 17:30 Melitta Dragaschnig: Testorakel und automatische Erstellung von Testorakeln kurze Pause 17:40 18:40 Sabrina Schönhart: Knowledge-based Software Reuse kurze Pause 18:50 20:00 Karin Hodnigg: Spreasdheet Didactics: Paradigm and Model anschließend mit Abendessen extern Plenardiskussion (Leitung wird bekannt gegeben): Reflexionen zum Konferenz- Seminar aus Software-Engineering freie Diskussion, Sozialphase, Nachtruhe Freitag: ab 7:30 Frühstück (aus mitgebrachten Ressourcen!!!) 8:30 9:30 Claus Joachim Pansi: tbd: Konzeptuelle Modellierung, Agenten kurze Pause 9:40 10:40 Sibylle Kattnig: Anforderungserhebung und Analyse mit Hilfe von Wissensbasierten Systemen kurze Pause 10:50 12:00 Roland Mittermeir: Zusammenfassung und Abschluss - 6 -

Klonerkennung mittels Metriken - Von der Erkennung geklonter Funktionen zur Erkennung geklonten Javacodes Peter Jelitsch Matr# 9960079 pjelitsc@edu.uni-klu.ac.at Abstract Unter den Klonerkennungsmechanismen ist der metrikenbasierte Ansatz zumindest für prozedurale Programmiersprachen [6, 8] eine brauchbare Variante. Dabei werden Paare von Codefragmenten anhand der Ähnlichkeit ihrer Metriken als Klone klassizifiert. Um die Treffsicherheit je nach Aufgabenstellung und deren Zielen zu optimieren (entweder Reduktion der False Negatives oder der False Postives - beides ist nicht möglich), können dabei verschiedene Metrikenbandbreiten eingestellt werden. Diese Arbeit beschäftigt sich mit der Frage, wie metrikenbasierte Klonerkennung für objektorientierte Programmiersprachen funktionieren könnte und welche Hindernisse dabei aus dem Weg geräumt werden müssen, um eine hohe Treffsicherheit der Klonerkennung gewährleisten zu können. 1. Einleitung Klonerkennung funktioniert im allgemeinen besonders gut, wenn die zu untersuchenden Codefragmente eine entsprechende Länge haben. In prozeduralen Programmiersprachen sind Funktionen als Fragmente recht beliebt. Objektorientierten Programmiersprachen ist gemeinsam, dass Funktionen als solche meistens nicht mehr existieren (auβer vielleicht in C++, wenn man der Prozeduralität anheim gefallen ist) und stattdessen Klonerkennung auf anderen Fragmenten basieren muss. In Java bieten sich dafür beispielsweise Packages, Klassen und Methoden an. Dadurch, dass diese Fragmente jedoch kleiner sind, bewegen sich auch die Metriken in einer kleineren Bandbreite. In gewisser Weise sind sich dadurch - vom Standpunkt EINER Metrik aus betrachtet - zu viele Fragmente einander ähnlich. Um metrikenbasierte Klonerkennung nach OO allgemein bzw. speziell nach Java zu bringen, sind also ein paar grundsätzliche Überlegungen anzustellen, wie die Treffgenauigkeit der Klonerkennung verbessert werden kann. Nach einigen Definitionen und einer Beschreibung der metrikenbasierten Klonerkennung möchte ich auf die Problematik von Java Code eingehen. Danach möchte ich erklären, welche Codefragmente für die Klonerkennung überhaupt relevant sein können. Anschlieβend diskutiere ich, wieweit die Klassifizierung der Klontypen nach Mayrand für Java brauchbar ist. Es folgt die Klärung des Zusammenhangs zwischen Klontypen und Codefragmenttypen, also welcher Klontyp für welches Codefragment überhaupt sinnvoll ist. Wesentlich für den Erfolg des metrikenbasierten Ansatzes ist die Definition einer Reihe von Metriken und die Klärung der Frage, auf welche Klontypen und Codefragmenttypen sie angewendet werden können. Schlieβlich gehe ich auf Probleme ein, möglichst unabhängigen Metriken zu bestimmen. 2. Definitionen Ein Softwareklon ist ein Stück Code, welches durch Copy&Paste bzw. durch geringfügige Änderungen nach Copy&Paste in einen Sourcecode eingefügt worden ist. [10]. Kapser und Godfrey [5] beschreiben einen Klon als ein Paar von Sourcecodefragmenten, die strukturell und syntaktisch ähnlich sind. Ein Sourcecodefragment ist eine beliebig langes, aber durchgehendes Stück Sourcecode, wobei für die Klonerkennung erst Codefragmente ab einer bestimmten Gröβe relevant sind (vgl. [9]). Die Gröβe hängt von der verwendeten Technik ab. Bellon hat in seiner Diplomarbeit [2] eine Untergrenze von 6 Zeilen Code definiert. Der hier diskutierte metrikenbasierte Ansatz von Mayrand [8] funktioniert ab einzelnen Funktionen. Die deutschsprachige Literatur (z.b. in [2]) unterscheidet vier Klontypen, nämlich exakte Kopien, Kopien mit Identifierumbenennung, Kopien mit Codeveränderungen und semantische Klone. Diese Unterscheidung ist für die metrikenbasierte Klonerkennung allerdings wenig hilfreich. Die Metriken reduzieren Codemerkmale auf einen Metrikenvektor. Gleiche Metrikenvektoren zeigen aber noch lange nicht, dass die zugrundeliegenden Codefragemente gleich sind. 3. Metrikenbasierte Klonerkennung Zwei Ansätze der metrikenbasierten Klonerkennung und ihre Gemeinsamkeiten möchte ich an dieser Stelle er- 1-7 -

wähnen: Der Mayrand-Ansatz [8] erlaubt Klonerkennung nur auf Funktionsebene, kann aber Funktionen in acht verschiedene Klontypen unterteilen. Der von Kontogiannis beschriebene Ansatz [6] erkennt nur vier Klontypen, ist aber granularer einzusetzen, d.h. auch auf kleinere Strukturen als Funtionen. 3.1 Mayrand-Ansatz Mayrand, Leblanc und Merlo [8] schlugen 1996 eine metrikenbasierte Funktionsklonerkennung vor. Dabei vergleichen sie Funktionen paarweise in vier Punkten: dem Namen (N); den Layoutmetriken (L); den Ausdrucksmetriken (A) und den Kontrollflussmetriken (K). Beim Namen unterscheiden sie zwischen Gleichheit und Ungleichheit, bei den drei Gruppen von Metriken jeweils zwischen Gleichheit, Ähnlichkeit und Ungleichheit. Die Ähnlichkeit wird dabei anhand von Bandbreiten bestimmt, die von Metrik zu Metrik unterschiedlich sind. Gleichheit in einer Metrikengruppe ist definiert als gleicher Wert aller Metriken. Ähnlichkeit ist definiert als Abweichung aller Metriken innerhalb ihrer Bandbreite. Sobald eine Metrik auβerhalb dieser Bandbreite ist, gelten zwei Funktionen bezüglich dieser Metrikengruppe als ungleich. In jeder Metrikengruppe sind etwa fünf Metriken zusammengefasst. Für die Layoutmetriken werden die Anzahl der Kommentare, die Leerzeilen und die durchschnittliche Länge der verwendeten Variablennamen gemessen. Bei den Ausdrucksmetriken werden die Anzahl der aufgerufenen Funktionen sowie die Anzahl verschiedener Befehle (deklarative bzw. exekutierbare) gemessen. Beim Kontrollfluss werden schlieβlich Anzahl der Knoten im Kontrollgraph, die Anzahl der Ausstiege aus der Funktion (returns), etc. gemessen. Aus diesen Metriken heraus werden nun Funktionspaare einem bestimmten Klontyp zugeordnet. In der Tabelle 1,,Klontypen nach Mayrand steht = für identische Metriken, für Metriken innerhalb der Bandbreiten und für Metriken auβerhalb der Bandbreiten (für mindestens eine Metrik). Manche Felder sind leer: Ist beispielsweise ein Funktionspaar bereits im Layout nur noch ähnlich, ist in diesem Fall die Namensgleich- oder -ungleichheit unerheblich. Ein Fragmentpaar ist also vom Typ SimilarLayout, wenn sowohl Ausdrucksmetriken als auch Kontrollflussmetriken identisch sind und die Layoutmetriken sich nur innerhalb der Bandbreite unterscheiden. Der Name ist dabei unerheblich. Die Klontypen sind implizit eine Gewichtung des Klongrades. ExactCopy ist schlecht, DistinctControlFlow ist gut. Der Fokus des Reengineering Klontyp N L A K 1-ExactCopy = = = = 2-DistinctName = = = 3-SimilarLayout = = 4-DistinctLayout = = 5-SimilarExpression = 6-DistinctExpression = 7-SimilarControlFlow 8-DistinctControlFlow Tabelle 1: Klontypen nach Mayrand sollte also auf den ExactCopies liegen. DistinctControl- Flow bedeutet gewissermassen, das zwei Funktionen gar nichts gemeinsam haben und mit hoher Wahrscheinlichkeit nicht voneinander geklont sind. In einem nächsten Schritt werden aus den Funktionspaaren heraus die Funktionen klassifiziert. Eine Funktion ist dabei in der Klasse n, wenn es zumindest ein Klonpaar mit dieser Funktion vom Klontyp n gibt und es kein Funktionspaar mit dieser Funktion in einer Klasse < n gibt. Eine Funktion f 1, die mit f 2 in DistinctName vorkommt, aber überhaupt nicht in ExactCopy, wird so als DistinctName klassifiziert. In ihrer Arbeit konnten Mayrand et al auf diese Weise alle Funktionen eines Systems etwa gleichmässig auf die acht Klontypen verteilen, wobei der Typ ExactCopy überdurchschnittlich vertreten ist. Der Fokus des Reengineerings kann damit zuerst auf die ExactCopies gelegt werden, danach auf DistinctNames etc. Es ist anzumerken, dass mit steigendem Klontyp die Klonwahrscheinlichkeit abnimmt. Während es in den Typen ExactCopy und DistinctName fast keine False Positives gibt, steigt der Anteil ab dem Typ SimilarLayout markant an. Die Autoren haben angemerkt, dass die Treffsicherheit erhöht werden kann, wenn die Bandbreiten für einzelnen Metriken parametrisiert werden. Allerdings geht mit einer Reduktion der False Positives gleichzeitig ein Anwachsen der False Negatives einher. Es wird also vom Anwendungsfall abhängen, mit welchen Fehlern man eher leben kann. Für den üblichen Reengineering Process wird es wohl eher angebracht sein, die Menge der Kandidaten in den Typen ExactCopy und SimilarName zu reduzieren. Solche Funktionen werden zumeist durch mangelndes Bottom-Up Design (vgl. [3]) in den Code eingeführt und bieten sich daher an, in Standardlibraries ausgelagert zu werden. Hier ist es wichtig, wenig False Positives zu haben, da diese den manuellen Reengineering Prozess unnötig verlangsamen. Wird eine geklonte Funktion nicht als solche erkannt, ist dies nicht weiter tragisch. Ist das Ziel der Klonerkennung aber beispielsweise, die Codegrösse unter eine gewisse Grenze zu drücken, wird man wohl eher False Positives und damit mehr Zeitaufwand bei der Prüfung des Ergebnisses akzeptieren. 2-8 -

3.2 Kontogiannis-Ansatz Kontogiannis baut in seiner Arbeit [6] auf Mayrand auf. Er schlägt insgesamt nur sieben Features vor (Fanout, benutzte und geänderte globale Variablen, Parametereigenschaften, Fileoperationen,...), aus denen er fünf Metriken ableitet. Ein Vektor mit diesen fünf Metriken wird jedem Codefragment zugeordnet. Anhand der Ähnlichkeit zweier Metrikenvektoren kann danach auf den Klongrad zweier Codefragmente geschlossen werden. Die Ähnlichkeit der Vektoren würde über die Euklidischer Distanz ermittelt werden. Im Gegensatz zu Mayrand erlaubt Kontogiannis aber keine Bandbreiten der einzelnen Metriken, d.h. zwei Codefragmente sind von einander geklont, wenn die Vektoren genau gleich sind. Geringe Abweichungen der Euklidischen Distanz könnten akzeptiert werden, Kontogiannis verzichtet darauf. Diesen Verzicht begründet er damit, dass die Berechnung der Nulldistanz trivialerweise nur ein paarweiser Vergleich zweier Vektoren ist und damit schneller durchgeführt werden kann als eine vollständige Berechnung der Euklidischen Distanz. Die Null-Distanz-Einschränkung bedeutet implizit, dass die verwendeten Metriken eine ganz bestimmte Eigenschaften haben müssen: Sie müssen absolut immun gegen kleinere Änderungen am Sourcecode sein. Da nur fünf Metriken verwendet werden, ist auβerdem eine breite Streuung erforderlich, da sich sonst zu viele Fragmente ähnlich wären. Trotzdem halte ich es für angebracht, die verwendeten Metriken selbst auch für OO Sprachen auszuprobieren und in einen Klonerkennungsansatz nach Mayrand einzubauen. In der gleichen Arbeit macht Kontogiannis aber auch auf ein Problem aufmerksam. Selbst menschliche Experten sind sich hin und wieder nicht einig, ob zwei ausgewiesene Codefragmente voneinander geklont sind. Selbst wenn dieser Sachverhalt geklärt ist, ist es immer noch eine Frage, ob es möglich ist, diesen menschlich festgelegten Grad einer Klonrelation zwischen zwei Codefragmenten auch maschinell festzustellen. Wird diese Idee weitergedacht, sehe ich darin aber ein interessantes Potential. Die Fragestellung der Klonsuche vereinfacht sich: Gesucht ist eine Parametrisierung der Klonerkennung, in der Klone eines a priori bekannten Codefragmentes gefunden werden sollen. Angenommen, in der Wartungsphase ist ein Fehler zu beheben und das Wartungsteam ist sich nicht sicher, ob das Codefragment, in welchem der Fehler behoben worden ist, nicht noch öfters vorkommt. Es wäre interessant, alle Codefragmente zu finden, die genau diesem einem Codefragment ähnlich sind. Das vereinfacht die Komplexitätsproblematik der Klonerkennung wesentlich, nämlich von O(n 2 ) (jedes Codefragment muss mit jedem anderen verglichen werden) auf O(n)(ein bestimmtes Codefragment muss mit allen anderen verglichen werden). Genau hier könnte die Parametrisierung ansetzen. Da die Komplexität Dichte 5,0% 4,0% 3,0% 2,0% 1,0% Tabelle4 Verteilung LOC prozedurale vs. OO Sprachen 0,0% 1 2 3 4 5 6 7 8 9 1011121314151617181920212223242526272829303132333435 LOC LOC Funktionen LOC Methoden Abbildung 1: Verteilungsfunktion LOC der Aufgabe erheblich geringer ist, könnte man quasi in Echtzeit an Parametern drehen, bis man eine vertretbare Menge von Klonkandidaten zu einem bestimmten Codefragment gefunden hat. Das System könnte daraus lernen, indem es sich merkt, für welchen Anwendungsfall welche Parametrisierung (insbesondere der Bandbreiten einzelner Metriken) welche Treffgenauigkeit erzeugt hat. Diese Information könnte in weiterer Folge dazu führen, kein fixen Bandbreiten (weder ±einem fixen Wert noch eine prozentuelle Abweichung) über den gesamten Metrikenbereich zu verwenden, sondern für jeden Metrikenwert jene Bandbreite zu vergeben, die sich in der Vergangenheit als aussagekräftig für ein bestimmtes Problem erwiesen hat. 4. Probleme in Java Die wesentlichen Probleme in OO Sprachen sind wohl, dass einerseits die Codefragmente, die der Klonerkennung zugrunde gelegt werden, tendenziell Seite 1 kürzer sind als in prozeduralen Sprachen, und es andererseits keine vorgeschriebene Ordnung über die Codefragmente gibt. Die Länge der Codefragmente ist dabei das vorrangige Problem. Kann dieses nicht gelöst werden, muss versucht werden, Javacode zu gröβeren Fragmenten zusammenzufassen - zum Beispiel zu Klassen, doch dafür ist dann eine Ordnungsrelation über kleinere Codefragmente erforderlich. 4.1 Länge der Codefragmente Die Abbildung 1,,Verteilungsfunktion LOC verdeutlicht die Problematik der Codefragmentlängen. Sie stellt zwei Weibullverteilungen gegenüber: LOC Funktionen ist mit den Parametern α = 1, 5; β = 46 gewählt und erreicht bei 128 LOC eine Verteilung von 99 %; LOC Methoden ist mit α = 1,3;β = 14 gewählt und erreicht bei 46 LOC 99 %. Diese Werte basieren auf meiner persönlichen Erfahrung mit den Programmiersprachen C und Java. Die Vermutung liegt nahe, dass dies ein allgemeiner Trend ist. Danach sind Funktionen in C üblicherweise kürzer als 200 LOC. Prozedurale Sprachen erreichen etwa bei etwa 20 bis 25 LOC ein Maximum von weniger als 2 %, d.h. die meisten Funktionen sind etwa 20 bis 25 LOC, es 3-9 -

sind aber nur rund 2 % der Funktionen genau 25 LOC. OO Sprachen haben bei 4 bis 5 LOC das Maximum von etwa 5 %.Wären nun LOC das alleinige Merkmal für die Klonerkennung, hätte in OO Sprachen eine Methode mit 5 LOC unter Berücksichtigung einer Bandbreite von ±2 LOC Klonpotential mit etwa 21 % aller Methoden. In prozeduralen Sprachen ist dieser Worst Case - selbst mit einer Bandbreite von 5 (nach Mayrand) - etwa 16 % (wiederum auf Basis der hypothetischen Weibullverteilung). Da die Anzahl der Klonkandidaten eine quadratische Funktion von der Menge der Codefragmente ist, wäre der Unterschied zwischen 16 und 21 % nahezu eine Verdoppelung. Es liegt auf der Hand, dass das Ergebnis einer solchen Klonerkennung nicht befriedigend ist: Es gäbe einfach zu viele Treffer, viele von ihnen wären aber False Positives. Die Bandbreiten enger zu gestalten, löst das Problem aber nur teilweise. Es würden möglicherweise Klone gar nicht mehr als solche erkannt werden. Diese Problematik kann man wohl nur durch die Anwendung mehrerer Metriken, die idealerweise nicht zu sehr voneinander abhängig sind, lösen. Eine zweite Möglichkeit wäre, sich auf bestimmte Codefragmente zu konzentrieren, also möglicherweise sehr kurze Methoden (wie es Get- und Setmethoden sind) überhaupt nicht zu berücksichtigen. In prozeduralen Sprachen beschränkt sich die Klonerkennung zumeist auf Funktionsklone, wobei aber die Klonerkennung auf kleineren Codefragmente durchaus möglich wäre. Für Java wäre es allerdings hilfreich, nicht nur Methoden, sondern ganze Klassen oder gar Pakete in die Klonerkennung aufgehen zu lassen. Welche Codefragmente unterschieden und welche Metriken auf sie angewandt werden können, wird im nächsten Kapitel diskutiert. 4.2 Reihenfolge der Codefragmente In C ist eine bestimmte Reihenfolge der Codefragmente vorgeschrieben. Modulvariablen müssen deklariert werden, bevor sie verwendet werden, von Funktionen müssen mindestens die Prototypen existieren, bevor sie referenziert werden. Daraus ergibt sich automatisch eine Reihenfolge der Codefragmente, die eingehalten werden muss, damit der Sourcecode überhaupt kompilierbar ist. In den Funktionen schlieβlich ist fast gar keine Änderung der Befehle mehr möglich, ohne die Semantik des Codes zu ändern. (Datenflussunabhängigkeiten seien hier ausgenommen.) In Java ist es komplizierter. Es gibt mehr Codefragmente und diese sind kürzer. Wenn ich jenseits des metrikenbasierten Ansatzes, z. B. mit Hilfe eines parametric string matchings nach Baker [1], Klone erkennen möchte, ist es erforderlich, zuerst eine Ordnung auf die Codefragmente herzustellen. Eine grobe Ordnung kann durch eine Sortierung nach Fragmenttyp erreicht werden, da- /* Klasse ist Teil des Packages * my.package.name */ package my.package.name; /* Klasse */ public class MyClass { /* Deklaratationen */ static Map cache$; /* Initializer Code */ static { cache$ = CacheProvider. loadcache( myclass ); } /* Innere Klasse */ public class MyInnerClass {... } /* Methodensignatur */ public static final int dosomething(string aparam) { /* Methodenrumpf */ if (cache$.contains( aparam )... } } Abbildung 2: Codefragmente einer Java Klasse nach wird es allerdings schwierig: Eine Sortierung nach Modifiern (,,static,,,final ) bzw. Scopes (,,public,,,private,,,protected,,,<kein Scope> ) gefällt mir nicht so sehr, dass genau solche Attribute im Zuge eines Reengineerings leicht verändert werden. Daher sehe ich die Chance eher in einer Sortierung nach dem Codefragmentnamen (Namen der Variable, der Methode, der InnerClass), wobei eine solche Sortierung auch nicht rein alfabetisch erfolgen sollte, da diese wiederum zu anfällig gegen Refactoring ist. Als Beispiel sei,,rename Method nach Fowler [4] genannt. Stattdessen wäre eine Generierung eines Thesaurus und eine Sortierung nach diesem Thesaurus gefragt. Die Problematik der Reihenfolge der Codefragmente stellt sich im rein metrikenbasierten Ansatz eigentlich nicht, allerdings denke ich, dass die Verwendung eines Thesaurus notwendig werden wird, wenn die Namensähnlichkeit von Identifiern ein Kriterium wird. 5. Relevante Codefragmenttypen Die Definition der Sprache definiert wohl auch die Codefragmente, die eine Klonerkennung verarbeiten können sollte: Packages (in weiterer Folge - vor allem in Tabellen - mit P abgekürzt) sind eine Sammlung von Klassen (K) und Interfaces (I). Klassen bestehen aus Methoden und -rümpfen (MR), Variablen- sowie Konstantendeklarationen (D), Initializer-Code (IC) und inneren Klassen. Interfaces bestehen aus Methodensignaturen (MS), Konstantendeklarationen (D) und inneren Interfaces. Die Abbildung 2,,Codefragmente einer Java Klasse sowie Abbildung 3,,Codefragmente eines Java 4-10 -

/* Interface */ package my.package.name; public interface MyInterface { /* Inneres Interface */ public interface MyInnerInterface { /* (Konstanten)deklaration */ int A_CONSTANT = 42; } /* Methodensignatur */ int calculatemeaningoflive(); } Class Method Body Package Interface Declaration Abbildung 3: Codefragmente eines Java Interfaces Interfaces mögen die einzelnen Fragmente verdeutlichen. Wie weit soll die Aufspaltung von Codefragmenten gehen? Auf Aufspaltung in kleinere Fragmente als Methoden sehe ich insoferne als problematisch, als Methoden selbst schon relativ kleine Codefragmente sind und die metrikbasierte Erkennung von Klonen bei kleinen Codefragmenten wegen der zu geringen Verteilung der Metrik schwierig wird. Innere Klassen und Innere Interfaces verdienen hingegen schon Beachtung. Es ist zu prüfen, ob diese als gleichberechtigt in die Metriken für ein Package eingehen sollen. Die Abbildung 4,,Codefragmente in Java beschreibt, welche Codefragmente für die Klonerkennung von Interesse sind. Die Pfeile geben jeweils an, in welche Richtung Metriken eines Codefragmentes in ein anderes Codefragment aggregiert werden können. Von Klassen interessieren mich also neben der Metriken, die direkt auf eine Klasse berechnet werden können, alle aggregierten Metriken zu den umschlossenen Methodenkörpern, Methodensignaturen, Initializer-Code, (Variablen- bzw. Konstanten)deklarationen sowie die Metriken der inneren Klassen. Von Interfaces sind Aggregationen der Metriken von Methodensignaturen und Konstantendeklarationen sowie der inneren Interfaces von Bedeutung. Die Innerbeziehung ist durch den zirkulären Pfeil bei Klasse und Interface angedeutet. 6. Klontypen in OO Sprachen Ich möchte eine Klassifizierung von Klontypen in Java angelehnt an jene von Mayrand vorschlagen, da ich der Meinung bin, dass sie hier auch funktionieren kann. Voraussetzung ist jedoch, dass die passenden Metriken in ausreichender Zahl gefunden werden können. 6.1 Name als Klassifizierungsmerkmal Zuallererst gibt es eine Einschränkung, dass Initializer Code keinen Namen hat bzw. dass Packages immer unterschiedliche Namen haben müssen. Der Vergleich zweier Namen kann möglicherweise mit Hilfe der Linguistik verbessert werden. Dies würde dann auch eine Aufweichung dieser Klassifikation erlauben. Obwohl es Initializer Code Method Signature Abbildung 4: Codefragmente in Java IParameter getparameter() {...} IParameter getparam() {...} IParameter getpar() {...} IParameter queryparameter() {...} IApplicationContext applicationcontext; IApplicationContext applctx; IApplicationContext ac; IApplicationContext applctxt$; Abbildung 5: Beispiele ähnlicher Namen schwierig erscheint, schlage ich vor, eine Ähnlichkeitsrelation auch für Namen zu definieren. Bei der Ermittlung von ähnlichen Namen kommt uns möglicherweise das Typkonzept von Java zugute: Aus dem Sourcecode könnte ich einen Thesaurus befüllen, der mir anhand von Variablendeklarationen oder auch Methodensignaturen Vorschläge für ähnliche Identifier generiert. Der Thesaurus könnte aus Code wie in der Abbildung 5,,Beispiele ähnlicher Namen ableiten, dass Context Ctxt ctx c ist. (Beim c wäre ich schon etwas vorsichtig.) Gäbe es nun Methoden getapplicationcontext() und getapplcontext(), könnte der Thesaurus Ähnlichkeit vorschlagen. Dasselbe würde mit (inneren) Klassen bzw. Interfaces funktionieren (,,AppCtxGenerator vs.,,applicationcontextgen ). Genauso könnte Gedanken darüber angestellt werden, wie eine Ähnlichkeit in Packagenamen gefunden werden kann. Packagenamen wären dann ähnlich, wenn sie in einer gewissen Anzahl von package-teilnamen gleich wären: at.firma.project.partner.domainobject und at.firma.project.address.domainobject wären in vier von fünf Teilnamen gleich und in einer unterschiedlich. Ob so eine Definition zulässig ist, müsste natürlich anhand des zur Verfügung stehenden Codes geprüft werden. Und auch hier könnte ein Thesaurus zusätzliche Informatio- 5-11 -

nen liefern. Insgesamt würde ich vorschlagen, auch für den Namen eines Codefragmentes drei Unterscheidungen zuzulassen: Neben Gleichheit und Verschiedenheit käme dank des Thesaurus eine Ähnlichkeitsrelation hinzu. Mit Bezug auf die Klonklassen nach Mayrand könnte ich mir eine Änderung insoferne vorstellen, dass zwischen den Klassen ExactCopy und DistinctName noch eine Klasse SimilarName eingefügt wird. Ob diese zusätzliche Klasse sinnvoll ist (signifikant andere Treffsicherheit im Vergleich zu den benachbarten Klassen), ist wohl erst durch ein Experiment festzustellen. 6.2 Weitere Klassifizierungsmerkmale Neben dem Namen klassifiziert Mayrand noch nach dem Layout, den Ausdrücken und dem Kontrollfluss. Beim Layout sehe ich keine Schwierigkeiten, entsprechende Metriken in die OO Welt zu transformieren. Sie dürften allenfalls erst bei gröβeren Methoden oder gar erst bei der Klassifizierung von Klassen wirklich relevant werden. Für Ausdrucksmetriken gilt meiner Meinung nach dasselbe. Allein bei den Kontrollflussmetriken könnte es kompliziert werden. Es gibt zwar eine Reihe von OO-Metriken, die gewissermaβen den Kontrollfluss bestimmen (Vererbungstiefe, Anzahl der überschriebenen Methoden). Andererseits ist aber im Vorgehen von Mayrand der unterschiedliche Kontrollfluss das erste K.O.-Kriterium für weitere Vergleiche ist der Kontrollfluss unterschiedlich, interessieren Ausdrucks- und Layoutmetriken oder gar der Name gar nicht mehr. Schlecht gewählte Metriken in diesem Bereich haben wohl die massivsten Auswirkungen auf die Treffgenauigkeit der gesamten Klonerkennung. 6.3 Klontypen für OO Damit erscheint klar, dass die Klassifizierung anhand bestimmter Merkmale, wie sie Mayrand für prozeduralen Code vorgeschlagen hat, auch für OO Code sinnvoll ist. Eine einzige Erweiterung ist die Definition des Klontyps SimilarName, der zwischen ExactCopy und DistinctName angesiedelt ist. Die Tabelle 2,,Klontypen für OO fasst diese Erkenntnisse zusammen. Dass nicht jeder Klontyp für jedes Codefragment geeignet ist, erscheint ebenso klar. Darauf gehe ich im nächsten Abschnitt ein. Problematischer sehe ich allerdings die scharfe Abgrenzung zwischen den Klontypen. Haben beispielsweise zwei Codefragmente bis auf eine Metrik identische Layoutmetriken und die eine Metrik liegt auβerhalb der Bandbreite, werden diese beiden Fragmente als Distinct- Layout klassifiziert. So etwas kann möglicherweise zu Lasten der Treffgenauigkeit gehen. Hier möchte ich weichere Grenzen vorschlagen. Mayrand arbeitet hier mit einer scharfen Grenze bei den Bandbreiten, aber viel- Klontyp N L A K 1-ExactCopy (EC) = = = = 2-SimilarName (SN) = = = 3-DistinctName (DN) = = = 4-SimilarLayout (SL) = = 5-DistinctLayout (DL) = = 6-SimilarExpression (SE) = 7-DistinctExpression (DE) = 8-SimilarControlFlow (SC) 9-DistinctControlFlow (DC) Tabelle 2: Klontypen für OO leicht sind verschwommene Grenzen in dieser Hinsicht eine Bereicherung. Die Abbildung 6,,Fuzzy Borders verdeutlicht dieses Problem. Bei den scharfen Kanten (dargestellt durch die Rechtecke) sind sich die Fragmente 1 und 2 ähnlich, obwohl sie sich jeweils an der Grenze der Bandbreiten bewegen. Fragment 3 ist in zwei Metriken identisch mit Fragment 1, befindet sich aber bei der dritten Metrik auβerhalb der Bandbreite. Mayrand folgert daraus: Fragment1 Fragment2 und Fragment1 Fragment3. Bei den verschwommenen Grenzen hingegen würde ich mit Wahrscheinlichkeiten arbeiten, wobei die Wahrscheinlichkeit beispielsweise die Höhe des Bandbreitendreiecks sein könnte. Damit hätte Fragment 3 bezüglich der Metriken 1 und 2 eine Übereinstimmung von 1, bei der Metrik 3 von 0.2 verglichen mit Fragment 1, das Fragment 2 käme jeweils nur auf eine Übereinstimmung von 0.5. Einfach ausmultipliziert wäre die Ähnlichkeit (Fragment1, Fragment2) somit 0,125; die Ähnlichkeit (Fragment1, Fragment3) aber 0,2. Fragment 3 wäre dem Fragment 1 somit ähnlicher als das Fragment 2. Das Grenzdreieck muss aber gar nicht ein Dreieck sein, sondern könnte eine beliebige Form annehmen. Somit könnte auch ein spezielles Problem von Mayrand [8](Seite 248) gelöst werden: Mayrand erlaubt für die Anzahl der unabhängigen Pfade durch eine Codefragment eine Bandbreite von 100(!!) und begründet dies damit, dass ein If-Statement, eingefügt am Beginn eines geklonten Fragments, eben die Anzahl der Pfade verdoppelt. Eine spezielle Übereinstimmungsform könnte darauf Rücksicht nehmen und wie in der Abbildung 7,,Grenzen für #Unabhängige Pfade aussehen. Die Form hätte ein globales Maximum bei 100 %, lokale Maxima bei 50 und 200 % und noch einmal abgeschwächt bei 25 und 400 %. Werden Übereinstimmungen mit Wahrscheinlichkeiten definiert, so hat dies natürlich Auswirkungen auf die Zuordnung zu Klontypen. Doch auch hier sehe ich einen Ausweg, indem die Zuordnung zu den Klontypen wiederum mit Wahrscheinlichkeiten erfolgt. Angenommen, zwei Fragmente besitzen folgenden Metrikenübereinstimmung: Kontrollflussübereinstimmung = 0,8 6-12 -

Tabelle5 M1 M1 M2 M2 M3 M3 Fragment 1 Fragment 2 Fragment 3 Fragment 1 Fragment 2 Fragment 3 M1 M1 M2 M2 M3 M3 M3 M3 Abbildung 6: Fuzzy Borders Abbildung 7: Grenzen für #Unabhängige Pfade Ausdrucksübereinstimmung = 0,6 Layoutübereinstimmung = 0,6 Namensübereinstimmung = 0 Gemäβ Abbildung 8,,Ähnlichkeitswahrscheinlichkeiten hätten wir folgende Wahrscheinlichkeiten 0,8: p(=) = 0,63; p( ) = 0,32; p(! =) = 0,05, 0.6: p(=) = 0,37; p( ) = 0,47; p(! =) = 0,16, 0: p(=) = 0,01; p( ) = 0,15; p(! =) = 0,84. Damit wären solche Fragmente wie folgt zu klassifizieren: Klontyp Berechnung p EC (0,63 *0,37 * 0,37) * 0,01 0,00 SN (0,63 * 0,37 * 0,37) * 0,15 0,01 DN (0,63 * 0,37 * 0,37) * 0,84 0,07 DN (0,63 * 0,37) * 0,37 0,08 SL (0,63 * 0,37) * 0,47 0,11 DL (0,63 * 0,37) * 0,16 0,04 DL 0,63 * 0,37 0,23 SE 0,63 * 0,47 0,30 DE 0,63 * 0,16 0,10 DE 0,63 SC 0,32 DC 0,05 Das Fragmentpaar wäre also mit 32 % dem Typ SimilarControlFlow, mit 30 % dem Typ SimilarExpression und mit Wahrscheinlichkeiten um oder kleiner 0,1 den anderen Typen zuzuordnen. Werden Wahrscheinlichkeiten unter 0,1 noch gefiltert, kann von der Zuordnung Wahrscheinlichkeiten der Ähnlichkeitsrelation 1 0,9 0,8 0,7 0,6 0,5 0,4 0,3 0,2 0,1 0 p(=), p(~), p(!=) Mittel 0 0,1 0,2 0,3 0,4 0,50,70,6 0,7 0,8 0,9 1-5 Std Übereinstimmung einer 0,3Metrikengruppe 2 Übereinstimmungp(=) p(~) p(!=) Abbildung 8: Ähnlichkeitswahrscheinlichkeiten 0 0,01 0,15 0,84 0,1 0,02 0,23 0,75 der Fragmentpaare 0,2 ausgehend 0,05die Zuordnung 0,32einzelner 0,63 Fragmente zu 0,3Klonklassen 0,09 (der letzte Klassifizierungsschritt nach Mayrand) 0,4 gleich0,16 bleiben. Allenfalls 0,47ist diese 0,37 0,41 0,5 Zuordnung der 0,5 Fragmente 0,25 wiederum mit Wahrscheinlichkeiten angegeben. 0,6 0,37 0,47 0,16 0,5 0,25 0,7 0,5 0,41 0,09 7. Codefragmenttypen 0,8 0,63 und Klontypen 0,32 0,05 0,9 0,75 0,23 0,02 Als nächstes stellt 1 sich die Frage, 0,84 welche Codefragmente 0,15 0,01 nach welchen Klontypen eingeordnet werden können. Für Methoden ist die Sache einfach, hier ist wohl davon auszugehen, dass die Einordnung jener von Funktionen in prozeduralen Sprachen entsprechen wird. Allenfalls ist zu überlegen, ob Get- und Setmethoden, die häufig ohnehin generiert werden, aus der Klonerkennung überhaupt auszunehmen sind. Eine Klonerkennung auf Methodenebene selbst ist auch durchaus sinnvoll. Initializer-Code kann nach Namen nicht differenziert werden, wohl aber sind Unterscheidungen nach dem Kontrollfluss, nach den verwendeten Ausdrücken und nach dem Layout möglich. Eine Klonerkennung auf Initializer-Code ist sinnvoll. Variablen können nach Namen und Layout klassifiziert werden, bei Expressions (Initialisierungen) wäre ich vorsichtig. Kontrollflussmetriken machen keinesfalls Sinn. Klonerkennung auf einzelne Variablen halte ich nicht für sehr sinnvoll. Nichtsdestotrotz können aggregierte Metriken für die übergeordnete Klasse interessant sein. Klassen (und innere Klassen) haben ihr eigenes Layout und ihren eigenen Namen, Expression- und Kontrollflussmetriken können wohl aus den von der Klasse umschlossenen Codefragmenten abgeleitet werden. Dabei bieten sich diverse Aggregationen an (Durchschnitt, Maximum, etc.). Interfaces (und Innere Interfaces) haben ein eigenes Layout und Namen. Ausdrucksmetriken oder Kontroll- p(!=) p(~) p(=) 7-13 - Seite 1

Fragmenttyp N L A K Package D A A A (Innere) Klasse D D A A (Inneres) Interface D D A - Deklaration D D D - Methodensignatur D D - - Methodenrumpf D D D D Initializer Code - D D D Tabelle 3: Anwendbare Metriken je Codefragment Klontyp P K I D MS MR IC 1-EC D D D D D D 2-SN D D D D D D 3-DN D D D D D D 4-SL A D D D D D D 5-DL A D D D D D D 6-SE A A D D 7-DE A A D D 8-SC A A D D 9-DC A A D D Tabelle 4: Direkte oder aggregierte Klontypbestimmung flussmetriken sind nicht sinnvoll. Für packages schlieβlich sind bezüglich Kontrollfluss, Ausdrücken, und Layout wohl nur aggregierte Werte über die Klassen möglich. Beim Namen ist zumindest eine Klassifikation nach Ähnlichkeit und Ungleichheit möglich. Die Tabelle 3,,Anwendbare Metriken je Codefragment soll dies verdeutlichen. In der ersten Spalte sind einzelne Codefragmente genannt. Im zweiten Bereich der Tabelle ist angegeben, ob Namens-, Layout-, Ausdrucks- und Kontrollflussmetriken für das jeweilige Codefragment direkt ermittelt werden können (D), aggregiert werden müssen (A), oder nicht möglich sind bzw. nicht sinnvoll erscheinen (-). Daraus lassen sich die folgenden Klassifizierung von Codefragmentpaaren ableiten (Tabelle 4,,Direkte oder aggregierte Klontypbestimmung ). D steht dabei wieder für eine direkte Bestimmung, A für Aggregation. Von zwei Packages kann beispielsweise direkt nur festgestellt werden, ob sie einen ähnlichen oder einen unterschiedlichen Namen haben, indirekt kann durch Aggregation allerdings auch jeder andere Klontyp bestimmt werden. Steht also für alle Klassen und Interfaces innerhalb zweier Packages fest, dass sie in der jeweiligen anderen Package eine Entsprechung (z.b. zumindest vom Typ DistinctName) haben, gilt auch für das Packagepaar zumindest die DistinctName-Beziehung. Stehen alle Klassen und Interfaces in der SimilarName oder gar ExactCopy Beziehung und haben die Packages überdies einen ähnlichen Namen, gilt für die Packages die SimilarName Beziehung. 8. Bestimmung von Metriken Teilweise haben die Metriken, die Mayrand vorschlägt, auch für OO Code ihre Aussagekraft. Um mehr interessante Metriken zu erhalten, habe ich mich am Buch von Lorenz und Kidd [7] orientiert. In ihrem Buch wird zwar in erster Linie auf Metriken für Smalltalk-Code und nebenher noch für C++-Code eingegangen. Ich denke aber, dass die einzelnen Metriken (wenn auch modifiziert) durchaus auch in Java verwendet werden können. Jede dieser Metriken ist einerseits genau einer bestimmten Metrikengruppe (Layout, Ausdrücke, Kontrollfluss) zugeordnet. Darüber hinaus sind sie einzelnen Fragmenttypen zugeordnet, wobei sie durch Anwendung von Aggregatsfunktionen in höhere Fragmenttypen gezogen werden können. Allgemein kann wohl behauptet werden, dass die Anwendung von Aggregatsfunktionen auf eine Menge von Metriken eine Generation einer Metrik für die Überkategorie erlaubt. Werden zu Methoden die LOC gezählt, wären avg(loc), modus(loc), median(loc), min(loc), max(loc), sum(loc) wohl mögliche Metriken für Klassen. Insbesondere bei Ausdrucks- bzw. Kontrollflussmetriken können aber auch andere Aggregationen zum Einsatz kommen. Es ist von Fall zu Fall zu überprüfen, ob beispielsweise gewichtetete Summenbildung das Ergebnis verbessert. 8.1 Layoutmetriken Die Layoutmetriken beziehen sich einerseits auf die Kommentierung des Codes, andererseits auf die Länge von Identifiern. Kommentarbezogene Metriken sind nach Mayrand ComDecVol (Volume of declaration comments), Com- StrVol (Volume of control comments) und ComLogNbr (Number of logical comments). Dabei ist jedesmal die Anzahl der alphanumerischen Kommentarzeichen gemeint. Diese Unterscheidung ist für OO-Code fraglich. Ich würde hier eine Unterscheidung in die Kommentierung der einzelnen Codefragmente vorschlagen. Gegebenenfalls kann innerhalb der Methoden noch zwischen Deklarations- und Exekutionskommentaren unterschieden werden. Darüber hinaus könnte man noch eine Unterscheidung zwischen verschiedenen Kommentarstilen vornehmen: /* */ als,,normaler Kommentar // als Zeilenkommentar /** */ als JavaDoc Kommentar auskommentierter Code /* if(...) */ Ich möchte Kommentarstile deswegen getrennt erfassen, weil ich der Meinung bin, dass sich beim Kopieren und Ändern niemand die Mühe machen wird, einen 8-14 -

bestimmten Kommentarstil zu ändern. Ähnlichkeiten in einer Kommentarmetrik könnte daher schon ein Indiz dafür sein, dass der Kommentar eines bestimmtes Codefragmentes (und damit wohl der gesamte Code) kopiert worden ist. Auskommentierter Code ist ebenso ein Indiz dafür, dass Code kopiert und reduziert worden ist. Gewitzte Parserbastler können sich ja überlegen, ob man auskommentierten Code mitparsen und in die Metrikenbestimmung mitnehmen sollte. Ob Kommentar möglicherweise Code ist, lieβe sich linguistisch lösen (hoher Anteil an Schlüsselwörtern und Sonderzeichen). Alles was man dann noch braucht, ist ein fehlertoleranter Parser (wohl ein Widerspruch in sich), der sein Bestes gibt, daraus einen Syntaxbaum zu erstellen. Den Ausdrucksund Kontrollflussmetriken wäre es an dieser Stelle wohl egal, ob sie sich auf Code oder Kommentar beziehen. Eine weitere Layoutmetrik ist die Länge von Identifiern. Neben dem Methodennamen kann ich mir aggregierte Metriken über die Länge der lokalen Variablen oder der Methodenparameter als hilfreiche Layoutmetrik vorstellen. Mayrand streicht an dieser Stelle besonders VarLenAvg, also die durchschnittliche Variablennamenlänge, heraus. LocNbr (Anzahl der Nicht-Leer-Zeilen, die klassichen LOC) hingegen kann wohl auf ganze Klassen (und Inner Classes) wie auch auf Methoden angewandt werden. 8.2 Ausdrucksmetriken Ausdrucksmetriken sind für Methodenrümpfe (inklusive der Methodensignatur) und für Initializer-Code interessant. Für Klassen bzw. Interfaces können Metriken über die Anzahl der Deklarationen interessant sein, darüber hinaus sind aggregierte Metriken über die Methoden und den Initializer-Code möglich. Die Ausdrucksmetriken nach Mayrand zählen Funktionsaufrufe, Entscheidungskomplexität, Anzahl der deklarativen sowie Anzahl der exekutierbaren Befehle. Von Kontogiannis Features können zusätzlich noch die Anzahl genutzter und geänderter globaler Variablen sowie Metriken bezüglich der Parameter erwähnt werden. Von Lorenz können wohl vor allem Gröβenmetriken (der Methoden bzw. der Klassen) herangezogen werden. Kohäsions- und Kopplungsmetriken können hier ebenso zugeordnet werden. Die Tabelle 5,,Ausdrucksmetriken listet eine Reihe von Ausdrucksmetriken und ihre Quelle auf. Scope (,,public,,,protected,,,private,,, (kein Scope)) sowie die Modifiers (,,static,,,final,,,abstract ) können verschieden kombiniert werden. Ich schlage vor, alle Kombinationen einzeln zu zählen, Summenbildungen können je nach Bedarf immer durchgeführt werden. Die Scopes schlieβen dabei jedenfalls einander aus, die Modifiers können kombiniert werden (,,static final,,,static abstract ). Lorenz unterscheidet beispielsweise nach Metrik MR IC K/I Quelle # Methoden (je D Lorenz nach Scope und Modifier) #Deklarationen (je D Lorenz nach Scope und Modifier) Klassenkohäsion D Lorenz Klassenkopplung D Lorenz # der Methodenaufrufe D D A Lorenz, Mayrand, #genutzer / geänderter Variablen (je nach Scope und Modifier) #genutzer / geänderter Methodenparameter # lokale Variablen (# deklarativer Befehle) # ausführbarer Befehle Kontogiannis D D A Kontogiannis D A Kontogiannis D D A Mayrand D D A Mayrand Tabelle 5: Ausdrucksmetriken Anzahl der Klassenmethoden und Anzahl der Instanzmethoden, dies wird in Java durch den Modifier,,static ausgedrückt. Konstantendeklarationen gibt es in Java de facto nicht, Variablen können entweder,,final oder,,static final sein, was eine einmalige Zuweisung eines Ausdrucks erlaubt. Im Falle einer,,static final wäre diese einmalige Zuweisung für alle Instanzen gültig, für,,final nur in einer Instanz. Bei der Anzahl der Methodenaufrufe könnte möglicherweise detaillierter unterschieden werden in Methodenaufrufe innerhalb der Klasse, innerhalb der Klassenhierarchie, innerhalb der Package oder Aufrufe in das gesamte System. 8.3 Kontrollflussmetriken Lorenz und Kidd [7] definieren eine Reihe von Internalmetriken, die etwa Kontrollflussmetriken sind. Die Kontrollflussmetriken sind wohl am schwierigsten zu migrieren, da es in OO-Sprachen möglich ist, Kontrollflüsse in die Klassenhierarchie zu verpacken. Das Codebeispiel in Abbildung 9,,Ähnliche Kontrollflüsse verdeutlicht das Dilemma. In C ist für das Drucken einer Kontenliste eine while()-schleife und ein switch- Statement notwendig. In Java kann das Drucken an die einzelnen Objekte delegiert werden, es wird also nur noch eine Methode anstatt einer Reihe von unterschiedlichen Funktionen aufgerufen. In Smalltalk erkennt man ohne Kenntnis der Semantik (allaccounts ist Plural und 9-15 -

Metrik MR IC K/I Quelle # Kanten im Kontrollflussgraph D D A Mayrand #Entscheidungen im D D A Mayrand Kontrollflussgraph # der Kreuzungen im D D A Mayrand Kontrollflussgraph # der Schleifen D D A Mayrand # der Austrittspunkte D A Mayrand (returns, throws) # Strukturbrüche D D A Mayrand (break, continue auβerhalb eines switch) # Knoten im Kontrollflussgraph D D A Mayrand durchschnittliche Verschachtelungstiefe D D A Mayrand des Kontrollflussgraphen # der Pfade im Kontrollflussgraph D D A Mayrand Vererbungstiefe D Lorenz # implementierte Interfaces D # abstract Methoden D # final Methoden D # überschriebene Methoden D Lorenz #geerbte Methoden D Lorenz # hinzugefügte Methoden D Lorenz Tabelle 6: Kontrollflussmetriken deswegen wahrscheinlich eine Collection, die do: Methode und der Variablenname :each deuten ebenfalls auf eine Collection hin) die Schleife überhaupt nicht mehr. Daher ist es angebracht, die Anzahl der überschriebenen Methoden in die Gruppe der Kontrollflussmetriken aufzunehmen, bzw. Kontrollflüsse gewissermaβen innerhalb der Klassenhierarchie zu messen. Allgemein möchte ich feststellen, dass Kontrollflussmetriken für kleine Codefragmente fast keine Aussagekraft haben werden, bestenfalls sind sie für statischen Code und Methoden ab einer gewissen Länge interessant. Ein Teil der Mayrand-Metriken dürfte trotzdem hilfreich sein. Möglicherweise sind aber insbesondere aus dem Blickwinkel der Vererbung und der Einbettung einzelner Klassen in die Vererbungshierarchie Rückschlüsse auf den Kontrollfluss möglich. Sowas kann nur experimentell festgestellt werden. 9. Bestimmung unabhängiger Metriken /* C */ for (i = 0; i < accounts.size; i++){ switch (accounts[i].type) { case SAVINGS: printsavingsaccount( (struct saving*)accounts[i]); break; case LOAN: printloanaccount( (struct loan*)accounts[i]); break;... default:... } } /* Java */ for (i = 0; i < accounts.length(); i++) { accounts[i].print(); } Smalltalk allaccounts do: [ :each each print]. Abbildung 9: Ähnliche Kontrollflüsse Kontogiannis[6] erwähnt bereits, dass mehrere Metriken die Aussagekraft der Klonerkennung erhöhen können, schränkt aber gleichzeitig ein, dass dies nur bei Metriken zutrifft, die unäbhängig voneinander sind. Er schlägt in seiner Arbeit den Spearman-Pearson-Korrelationstest vor, um die Unabhängigkeit zweier Metriken zu bestimmen. Die Vorgangsweise ist dabei, dass auf einer Stichprobe des zu prüfenden Codes Vektoren zweier Metriken berechnet werden. Diese Vektoren werden danach gereiht: Aus einem Vektor X =< 10, 20, 8, 12 > entsteht so der Rangvektor Rang(X) =< 3,1,4,2 >. Aus den Rangvektoren wird danach ein Korrelationswert ermittelt. Dieser Wert kann zwischen -1 und 1 liegen. -1 bedeutet eine hohe umgekehrte Relation, 1 bedeutet eine hohe direkte Relation. 0 bedeutet, dass zwei Metriken nicht miteinander korrelieren. Ein konstruiertes Beispiel für eine hohe direkte Korrelation wäre die Metriken Anzahl der Instanzvariablen vs. Anzahl der Getter- Methoden. Eine hohe indirekte Korrelation könnte sein, wenn schreibende und lesende Filezugriffe gemessen werden und die einzelnen Fragmente strikt in Ein- und Ausgabefunktionen geteilt wären. Korrelierte Features tragen wenig zur metrikenbasierten Unterscheidung bei. Wünschenswert wären also Metriken, die zueinander nicht korreliert sind, die also ein Rangkorrelationskoeffizienten um 0 haben, denn gerade solche Metriken tragen zu einem Erkenntnisgewinn bei. In der (statistischen) Literatur [11] spricht man bei Rangkorrelationskoeffizienten zwischen -0.5 und +0.5 davon, dass die beiden Metriken nicht korreliert sind. Ich denke, dass die Un- 10-16 -