Knowledge Based Software Engineering

Größe: px
Ab Seite anzeigen:

Download "Knowledge Based Software Engineering"

Transkript

1 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

2

3 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

4

5 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 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

6 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 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 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 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 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 -

7 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 [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

8 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 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 % - Full paper. submitted version + final version 40 % - Vortrag % - 4 -

9 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 -

10 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 -

11 Klonerkennung mittels Metriken - Von der Erkennung geklonter Funktionen zur Erkennung geklonten Javacodes Peter Jelitsch Matr# 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

12 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

13 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% 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 -

14 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

15 /* 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

16 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,

17 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(=) Seite 1

18 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

19 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

20 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

Software Engineering Klassendiagramme weiterführende Konzepte

Software Engineering Klassendiagramme weiterführende Konzepte Software Engineering Klassendiagramme weiterführende Konzepte Prof. Adrian A. Müller, PMP, PSM 1, CSM Fachbereich Informatik und Mikrosystemtechnik 1 Klassenattribut: static Implementierung in Java public

Mehr

Objektorientierte Programmierung. Objektorientierte Programmierung. Klasse. Objekt. Beispiel: Sportfest1. Methode. Eine Einführung mit BlueJ

Objektorientierte Programmierung. Objektorientierte Programmierung. Klasse. Objekt. Beispiel: Sportfest1. Methode. Eine Einführung mit BlueJ Objektorientierte Programmierung Objektorientierte Programmierung Eine Einführung mit BlueJ stellt die Daten, ihre Struktur und ihre Beziehungen zueinander in den Vordergrund. Weniger im Blickpunkt: die

Mehr

Objektorientierte Programmierung. Kapitel 12: Interfaces

Objektorientierte Programmierung. Kapitel 12: Interfaces 12. Interfaces 1/14 Objektorientierte Programmierung Kapitel 12: Interfaces Stefan Brass Martin-Luther-Universität Halle-Wittenberg Wintersemester 2012/13 http://www.informatik.uni-halle.de/ brass/oop12/

Mehr

Softwaremessung und -metrik

Softwaremessung und -metrik Softwaremessung und -metrik AW1 Votrag - Daniel Wojtucki Hamburg, 20. Januar 2010 Inhalt 1 Einleitung 2 Softwarequalität 3 Grundlagen der Softwaremetrik 4 Beispiele bestimmter Metriken 5 Zusammenfassung

Mehr

Grundlagen der Verwendung von make

Grundlagen der Verwendung von make Kurzskript zum Thema: Grundlagen der Verwendung von make Stefan Junghans Gregor Gilka 16. November 2012 1 Einleitung In diesem Teilskript sollen die Grundlagen der Verwendung des Programmes make und der

Mehr

Java Einführung Methoden in Klassen

Java Einführung Methoden in Klassen Java Einführung Methoden in Klassen Lehrziel der Einheit Methoden Signatur (=Deklaration) einer Methode Zugriff/Sichtbarkeit Rückgabewerte Parameter Aufruf von Methoden (Nachrichten) Information Hiding

Mehr

Folge 19 - Bäume. 19.1 Binärbäume - Allgemeines. Grundlagen: Ulrich Helmich: Informatik 2 mit BlueJ - Ein Kurs für die Stufe 12

Folge 19 - Bäume. 19.1 Binärbäume - Allgemeines. Grundlagen: Ulrich Helmich: Informatik 2 mit BlueJ - Ein Kurs für die Stufe 12 Grundlagen: Folge 19 - Bäume 19.1 Binärbäume - Allgemeines Unter Bäumen versteht man in der Informatik Datenstrukturen, bei denen jedes Element mindestens zwei Nachfolger hat. Bereits in der Folge 17 haben

Mehr

Das Studiengangsinformationssystem (SGIS)

Das Studiengangsinformationssystem (SGIS) Das Studiengangsinformationssystem (SGIS) Manual für Typo3-Redakteure Version 1.a Mai 2015 Kontakt: Referat 1.4 - Allgemeine Studienberatung und Career Service Christian Birringer, christian.birringer@uni-rostock.de

Mehr

Autor: Michael Spahn Version: 1.0 1/10 Vertraulichkeit: öffentlich Status: Final Metaways Infosystems GmbH

Autor: Michael Spahn Version: 1.0 1/10 Vertraulichkeit: öffentlich Status: Final Metaways Infosystems GmbH Java Einleitung - Handout Kurzbeschreibung: Eine kleine Einführung in die Programmierung mit Java. Dokument: Autor: Michael Spahn Version 1.0 Status: Final Datum: 23.10.2012 Vertraulichkeit: öffentlich

Mehr

5 ECTS. 4 Modulverantwortlicher Prof. Dr. Francesca Saglietti

5 ECTS. 4 Modulverantwortlicher Prof. Dr. Francesca Saglietti 1 Modulbezeichnung Konstruktives Software Engineering (Constructive Phases of Software Engineering) 2 Lehrveranstaltungen V+Ü: Konstruktive Phasen des Software Engineering (erste zwei Monate der Vorlesung

Mehr

Kapitel 6. Vererbung

Kapitel 6. Vererbung 1 Kapitel 6 2 Ziele Das sprinzip der objektorientierten Programmierung verstehen Und in Java umsetzen können Insbesondere folgende Begriffe verstehen und anwenden können: Ober/Unterklassen Subtyping Überschreiben

Mehr

Übersicht. Informatik 2 Teil 3 Anwendungsbeispiel für objektorientierte Programmierung

Übersicht. Informatik 2 Teil 3 Anwendungsbeispiel für objektorientierte Programmierung Übersicht 3.1 Modell Konto 3.2 Modell Konto - Erläuterungen 3.3 Benutzer Ein- und Ausgabe mit Dialogfenster I 3.4 Benutzer Ein- und Ausgabe mit Dialogfenster II 3.5 Klassen- und Objekteigenschaften des

Mehr

Kapitel 6. Vererbung

Kapitel 6. Vererbung 1 Kapitel 6 2 Ziele Das sprinzip der objektorientierten Programmierung verstehen Und in Java umsetzen können Insbesondere folgende Begriffe verstehen und anwenden können: Ober/Unterklassen Subtyping Überschreiben

Mehr

6 Architektur-Mittel (WOMIT)

6 Architektur-Mittel (WOMIT) 6 Architektur-Mittel (WOMIT) Abb. 6-1: Positionierung des Kapitels im Ordnungsrahmen. Dieses Kapitel befasst sich mit der WOMIT-Dimension des architektonischen Ordnungsrahmens, indem es grundlegende Konzepte

Mehr

Programmieren in Java

Programmieren in Java Programmieren in Java objektorientierte Programmierung 2 2 Zusammenhang Klasse-Datei In jeder *.java Datei kann es genau eine public-klasse geben wobei Klassen- und Dateiname übereinstimmen. Es können

Mehr

PIWIN 1 Übung Blatt 5

PIWIN 1 Übung Blatt 5 Fakultät für Informatik Wintersemester 2008 André Gronemeier, LS 2, OH 14 Raum 307, andre.gronemeier@cs.uni-dortmund.de PIWIN 1 Übung Blatt 5 Ausgabedatum: 19.12.2008 Übungen: 12.1.2009-22.1.2009 Abgabe:

Mehr

syntax.tex Eine Übersicht

syntax.tex Eine Übersicht syntax.tex Eine Übersicht Bernd Worsch 7. Juli 1997 Inhaltsverzeichnis 1 Einleitung 1 2 Bevor es funktioniert... 1 3 Grundelemente von syntax.tex 1 4 Strukturelemente von syntax.tex 3 5 Setzen von Syntaxdiagrammen

Mehr

Einführung in die Java- Programmierung

Einführung in die Java- Programmierung Einführung in die Java- Programmierung Dr. Volker Riediger Tassilo Horn riediger horn@uni-koblenz.de WiSe 2012/13 1 Wichtig... Mittags Pommes... Praktikum A 230 C 207 (Madeleine) F 112 F 113 (Kevin) E

Mehr

Verhindert, dass eine Methode überschrieben wird. public final int holekontostand() {...} public final class Girokonto extends Konto {...

Verhindert, dass eine Methode überschrieben wird. public final int holekontostand() {...} public final class Girokonto extends Konto {... PIWIN I Kap. 8 Objektorientierte Programmierung - Vererbung 31 Schlüsselwort: final Verhindert, dass eine Methode überschrieben wird public final int holekontostand() {... Erben von einer Klasse verbieten:

Mehr

3. Konzepte der objektorientierten Programmierung

3. Konzepte der objektorientierten Programmierung 3. Konzepte der objektorientierten Programmierung 3.1 Basiskonzepte 3.2 Generalisierung / Spezialisierung 3.3 Aggregation 3.4 Assoziation 3.5 Nachrichten 3.6 Polymorphismus 3. Konzepte der Objektorientierung

Mehr

Java Kurs für Anfänger Einheit 5 Methoden

Java Kurs für Anfänger Einheit 5 Methoden Java Kurs für Anfänger Einheit 5 Methoden Ludwig-Maximilians-Universität München (Institut für Informatik: Programmierung und Softwaretechnik von Prof.Wirsing) 22. Juni 2009 Inhaltsverzeichnis Methoden

Mehr

1 Einleitung. 1.1 Unser Ziel

1 Einleitung. 1.1 Unser Ziel 1 Dieses Buch wendet sich an alle, die sich für agile Softwareentwicklung interessieren. Einleitend möchten wir unser mit diesem Buch verbundenes Ziel, unseren Erfahrungshintergrund, das dem Buch zugrunde

Mehr

Kapiteltests zum Leitprogramm Binäre Suchbäume

Kapiteltests zum Leitprogramm Binäre Suchbäume Kapiteltests zum Leitprogramm Binäre Suchbäume Björn Steffen Timur Erdag überarbeitet von Christina Class Binäre Suchbäume Kapiteltests für das ETH-Leitprogramm Adressaten und Institutionen Das Leitprogramm

Mehr

Die Bedeutung abstrakter Datentypen in der objektorientierten Programmierung. Klaus Kusche, September 2014

Die Bedeutung abstrakter Datentypen in der objektorientierten Programmierung. Klaus Kusche, September 2014 Die Bedeutung abstrakter Datentypen in der objektorientierten Programmierung Klaus Kusche, September 2014 Inhalt Ziel & Voraussetzungen Was sind abstrakte Datentypen? Was kann man damit grundsätzlich?

Mehr

Wissen und seine Rolle im und vor dem Übersetzungsprozess. Arbeit mit Hilfstexten

Wissen und seine Rolle im und vor dem Übersetzungsprozess. Arbeit mit Hilfstexten Michal Dvorecký Wissen und seine Rolle im und vor dem Übersetzungsprozess. Arbeit mit Hilfstexten Aufgabe 1 Wissen und seine Rolle im und vor dem Übersetzungsprozess. Aufgabe zur Bewusstmachung der unterschiedlichen

Mehr

Javakurs 2013 Objektorientierung

Javakurs 2013 Objektorientierung Javakurs 2013 Objektorientierung Objektorientierte Programmierung I Armelle Vérité 7 März 2013 Technische Universität Berlin This work is licensed under the Creative Commons Attribution-ShareAlike 3.0

Mehr

Code-Quality-Management

Code-Quality-Management Code-Quality-Management Technische Qualität industrieller Softwaresysteme transparent und vergleichbar gemacht von Frank Simon, Olaf Seng, Thomas Mohaupt 1. Auflage Code-Quality-Management Simon / Seng

Mehr

KompetenzManager http://www.kompetenzmanager.ch/mah Manual für die Benutzung der Website

KompetenzManager http://www.kompetenzmanager.ch/mah Manual für die Benutzung der Website KompetenzManager http://www.kompetenzmanager.ch/mah Manual für die Benutzung der Website Inhalt Inhalt... 1 1. Anmelden beim Kompetenzmanager... 3 2. Erstellen eines neuen Kompetenzprofils... 4 2.1. Wizard

Mehr

Organisatorisches. Proseminar Technische Informatik - 18. Oktober 2013

Organisatorisches. Proseminar Technische Informatik - 18. Oktober 2013 Organisatorisches Proseminar Technische Informatik - 18. Oktober 2013 Michael Frey Distributed, embedded Systems Computer Systems and Telematics (CST) Freie Universität Berlin http://cst.mi.fu-berlin.de

Mehr

Projekt AGB-10 Fremdprojektanalyse

Projekt AGB-10 Fremdprojektanalyse Projekt AGB-10 Fremdprojektanalyse 17. Mai 2010 1 Inhaltsverzeichnis 1 Allgemeines 3 2 Produktübersicht 3 3 Grundsätzliche Struktur und Entwurfsprinzipien für das Gesamtsystem 3 3.1 Die Prefuse Library...............................

Mehr

Mit KI gegen SPAM. Proseminar Künstliche Intelligenz

Mit KI gegen SPAM. Proseminar Künstliche Intelligenz Mit KI gegen SPAM Proseminar Künstliche Intelligenz SS 2006 Florian Laib Ausblick Was ist SPAM? Warum SPAM-Filter? Naive Bayes-Verfahren Fallbasiertes Schließen Fallbasierte Filter TiMBL Vergleich der

Mehr

Von der UML nach C++

Von der UML nach C++ 22 Von der UML nach C++ Dieses Kapitel behandelt die folgenden Themen: Vererbung Interfaces Assoziationen Multiplizität Aggregation Komposition Die Unified Modeling Language (UML) ist eine weit verbreitete

Mehr

Software Engineering mit Übungen. Franz-Josef Elmer, Universität Basel, HS 2015

Software Engineering mit Übungen. Franz-Josef Elmer, Universität Basel, HS 2015 Software Engineering mit Übungen Franz-Josef Elmer, Universität Basel, HS 2015 Software Engineering 2 Organisation Ort: Seminarraum 05.002, Spiegelgasse 5 Ablauf: 15:15 Vorlesung Prüfung: Schriftlich,

Mehr

Software-Qualität sichtbar machen

Software-Qualität sichtbar machen Software-Qualität sichtbar machen Prof. Dr. Claus Lewerentz BTU Cottbus Vortrag im Rahmen des Berlin-Brandenburger Software-Forums Zeit: 28. April 2003,18.30 Uhr Ort: Fraunhofer FIRST Berlin Software Qualität

Mehr

FAQs zum Diplomstudium Publizistik und Kommunikationswissenschaft an der Alpen- Adria Universität Klagenfurt

FAQs zum Diplomstudium Publizistik und Kommunikationswissenschaft an der Alpen- Adria Universität Klagenfurt FAQs zum Diplomstudium Publizistik und Kommunikationswissenschaft an der Alpen- Adria Universität Klagenfurt Stand: Februar 2008 1 Inhaltsverzeichnis 1 ALLGEMEINE FRAGEN ZUM STUDIUM PUBLIZISTIK UND KOMMUNIKATIONSWISSENSCHAFT...

Mehr

Java Schulung (Java 2 Java Development Kit 5 / 6)

Java Schulung (Java 2 Java Development Kit 5 / 6) 2. Grundlagen der Objektorientierung 2.1 Klassen, Attribute, Methoden Klassen Eine Klasse beschreibt als Bauplan Gemeinsamkeiten einer Menge von Objekten ist also ein Modell, auf dessen Basis Objekte erstellt

Mehr

Codierungstheorie Rudolf Scharlau, SoSe 2006 9

Codierungstheorie Rudolf Scharlau, SoSe 2006 9 Codierungstheorie Rudolf Scharlau, SoSe 2006 9 2 Optimale Codes Optimalität bezieht sich auf eine gegebene Quelle, d.h. eine Wahrscheinlichkeitsverteilung auf den Symbolen s 1,..., s q des Quellalphabets

Mehr

Design, Durchführung und Präsentation von Experimenten in der Softwaretechnik

Design, Durchführung und Präsentation von Experimenten in der Softwaretechnik Design, Durchführung und Präsentation von Experimenten in der Softwaretechnik Inhalt 1. Zusammenfassung der Papers 2. Fehler in Design, Durchführung und Präsentation 3. Richtlinien für saubere Experimente

Mehr

Scheinaufgabe im Fach Web Engineering

Scheinaufgabe im Fach Web Engineering Otto-von-Guericke-Universität Magdeburg Fakultät für Informatik Institut für Verteilte Systeme Scheinaufgabe im Fach Web Engineering Thomas Thüm 07. August 2006 Matrikel: 171046 Lehrveranstaltung: Web

Mehr

Objektorientiertes Programmieren für Ingenieure

Objektorientiertes Programmieren für Ingenieure Uwe Probst Objektorientiertes Programmieren für Ingenieure Anwendungen und Beispiele in C++ 18 2 Von C zu C++ 2.2.2 Referenzen und Funktionen Referenzen als Funktionsparameter Liefert eine Funktion einen

Mehr

Ausarbeitung des Interpreter Referats

Ausarbeitung des Interpreter Referats Ausarbeitung des Interpreter Referats Gliederung 1. Programmiersprache 1.2. Syntax 1.2.1. Konkrete Syntax 1.2.2. Abstrakter Syntax Baum (Abstrakte Syntax) 2. Parser 2.1. Syntaktische Struktur einer Sprache

Mehr

4. Objektorientierte Programmierung

4. Objektorientierte Programmierung 4. Objektorientierte Programmierung In Abschnitt 3 ging es um fundamentale Basiskonzepte von Java, wie es sie in jeder anderen gängigen Programmiersprache so oder so ähnlich auch gibt. In Abschnitt 4 nun

Mehr

Erwin Grüner 15.12.2005

Erwin Grüner 15.12.2005 FB Psychologie Uni Marburg 15.12.2005 Themenübersicht Mit Hilfe der Funktionen runif(), rnorm() usw. kann man (Pseudo-) erzeugen. Darüber hinaus gibt es in R noch zwei weitere interessante Zufallsfunktionen:

Mehr

Vgl. die Literaturangaben bzw. Hinweise der einzelnen Lehrveranstaltungen

Vgl. die Literaturangaben bzw. Hinweise der einzelnen Lehrveranstaltungen Modulbeschreibung VI.5.5 Modulbezeichnung Supply-Chain-Management Beitrag des Moduls zu den Studienzielen Die Studierenden erwerben vertieftes Wissen über unternehmensübergreifenden Wertschöpfungsketten

Mehr

Willkommen zur Vorlesung. Objektorientierte Programmierung Vertiefung - Java

Willkommen zur Vorlesung. Objektorientierte Programmierung Vertiefung - Java Willkommen zur Vorlesung Objektorientierte Programmierung Vertiefung - Java Zum Dozenten Mein Name: Andreas Berndt Diplom-Informatiker (TU Darmstadt) Derzeit Software-Entwickler für Web- Applikationen

Mehr

Lösungen zu Übung 3 Objektorientierte Modellierung - Statisches Modell

Lösungen zu Übung 3 Objektorientierte Modellierung - Statisches Modell Universität Stuttgart Institut für Automatisierungs- und Softwaretechnik Prof. Dr.-Ing. Dr. h. c. P. Göhner Lösungen zu Übung 3 Objektorientierte Modellierung - Statisches Modell Aufgabe 3. Assoziation

Mehr

17 Datenbank aufteilen

17 Datenbank aufteilen 17 Datenbank aufteilen Warum teilt man eine Datenbank auf und was bedeutet dies? Eine Access-Datenbankdatei ist ein Monolith. Sie enthält alle notwendigen Objekte wie Tabellen, Abfragen, Formulare, Berichte,

Mehr

Selbstbestimmtes Lernen. Proinformatik III Objektorientierte Programmierung. Format. Inhalt. Buzzwords

Selbstbestimmtes Lernen. Proinformatik III Objektorientierte Programmierung. Format. Inhalt. Buzzwords 4.0 Proinformatik III Objektorientierte Programmierung Michael Kölling University of Kent Canterbury, UK Selbstbestimmtes Lernen Vorlesung Tutorium Übungen Buch Web-Seite Üben, üben, üben! Format Vorlesung:

Mehr

Softwaretechnik WS 2013/14. Fomuso Ekellem

Softwaretechnik WS 2013/14. Fomuso Ekellem WS 2013/14 Organisatorisches Dozentin : Ango (Raum 2.250) Fragen und Übungen: mathe_ekellem@yahoo.com (Nur hier, sonst wird nicht bewertet) Folien: http://www.gm.fh-koeln.de/~afomusoe/softwaretechnik.html

Mehr

E-Commerce: IT-Werkzeuge. Web-Programmierung. Kapitel 4: Einführung in JavaScript Stand: 03.11.2014. Übung WS 2014/2015. Benedikt Schumm M.Sc.

E-Commerce: IT-Werkzeuge. Web-Programmierung. Kapitel 4: Einführung in JavaScript Stand: 03.11.2014. Übung WS 2014/2015. Benedikt Schumm M.Sc. Übung WS 2014/2015 E-Commerce: IT-Werkzeuge Web-Programmierung Kapitel 4: Stand: 03.11.2014 Benedikt Schumm M.Sc. Lehrstuhl für ABWL und Wirtschaftsinformatik Katholische Universität Eichstätt-Ingolstadt

Mehr

Wintersemester Maschinenbau und Kunststofftechnik. Informatik. Tobias Wolf http://informatik.swoke.de. Seite 1 von 22

Wintersemester Maschinenbau und Kunststofftechnik. Informatik. Tobias Wolf http://informatik.swoke.de. Seite 1 von 22 Kapitel 19 Vererbung, UML Seite 1 von 22 Vererbung - Neben der Datenabstraktion und der Datenkapselung ist die Vererbung ein weiteres Merkmal der OOP. - Durch Vererbung werden die Methoden und die Eigenschaften

Mehr

Business Intelligence. Data Warehouse / Analyse Sven Elvers 2005-07-06

Business Intelligence. Data Warehouse / Analyse Sven Elvers 2005-07-06 Business Intelligence Data Warehouse / Analyse Sven Elvers 2005-07-06 Einleitung Dieses Dokument beschreibt einen für das Verständnis relevanten Teil der Präsentation. Business Intelligence Motivation

Mehr

Information & Knowledge Management

Information & Knowledge Management Übergangsbestimmungen für das Masterstudium Information & Knowledge Management an der Technischen Universität Wien von der Studienkommission Informatik beschlossen am 20.9.2006 (1) Sofern nicht anderes

Mehr

Erfahrungen und Erwartungen zum Einsatz von E-Learning in der universitären Lehre

Erfahrungen und Erwartungen zum Einsatz von E-Learning in der universitären Lehre Erfahrungen und Erwartungen zum Einsatz von E-Learning in der universitären Lehre Ergebnisse einer Kurzumfrage unter Studierenden im Fach Politikwissenschaft Bericht: Ingo Henneberg März 2015 Albert-Ludwigs-Universität

Mehr

Ein Beispiel könnte sein: Umsatzrückgang im stationären Handel da Kunden vermehrt online einkaufen

Ein Beispiel könnte sein: Umsatzrückgang im stationären Handel da Kunden vermehrt online einkaufen Finden eines Themas: Ideal ist es, wenn Sie in Ihrer Präsentation den Bezug zur Praxis herstellen können. Gehen Sie also zu Ihrem Vorgesetzten und fragen Sie nach einer konkreten Problemstellung, die in

Mehr

Tutorium Java Ein Überblick. Helge Janicke

Tutorium Java Ein Überblick. Helge Janicke Tutorium Java Ein Überblick Helge Janicke 26. Oktober 2000 1 VORRAUSSETZUNGEN ZUM PROGRAMMIEREN MIT JAVA. 1 1 Vorraussetzungen zum Programmieren mit Java. Was braucht man, wenn man mit Java programmieren

Mehr

Integration geometrischer und fotogrammetrischer Information zum Wiederfinden von Bildern

Integration geometrischer und fotogrammetrischer Information zum Wiederfinden von Bildern Integration geometrischer und fotogrammetrischer Information zum Wiederfinden von Bildern Björn Burow SE Mustererkennung in Bildern und 3D-Daten Lehrstuhl Graphische Systeme BTU Cottbus Inhaltsübersicht

Mehr

PIWIN I. Praktische Informatik für Wirtschaftsmathematiker, Ingenieure und Naturwissenschaftler I. Vorlesung 3 SWS WS 2007/2008

PIWIN I. Praktische Informatik für Wirtschaftsmathematiker, Ingenieure und Naturwissenschaftler I. Vorlesung 3 SWS WS 2007/2008 PIWIN I Kap. 7 Objektorientierte Programmierung - Einführung 1 PIWIN I Praktische Informatik für Wirtschaftsmathematiker, Ingenieure und Naturwissenschaftler I Vorlesung 3 SWS WS 2007/2008 FB Informatik

Mehr

Seminar zur BWL im Wintersemester 2015 / 2016. Maschinenbelegungsplanung in der betrieblichen Fertigung

Seminar zur BWL im Wintersemester 2015 / 2016. Maschinenbelegungsplanung in der betrieblichen Fertigung Institut für Wirtschaftswissenschaft Abteilung für BWL und Unternehmensforschung Prof. Dr. Jürgen Zimmermann (juergen.zimmermann@tu-clausthal.de) Stefan Kreter, M. Sc. (stefan.kreter@tu-clausthal.de) Julius-Albert-Str.

Mehr

Software Engineering Übung 4 Architektur, Modulentwurf

Software Engineering Übung 4 Architektur, Modulentwurf software evolution & architecture lab Software Engineering Übung 4 Architektur, Modulentwurf 1 Informationen 1.1 Daten Ausgabe Di 27.10.2009 Abgabe So 08.11.2009 bis 23:59 Uhr Besprechung am Di 17.11.2009

Mehr

SDD System Design Document

SDD System Design Document SDD Software Konstruktion WS01/02 Gruppe 4 1. Einleitung Das vorliegende Dokument richtet sich vor allem an die Entwickler, aber auch an den Kunden, der das enstehende System verwenden wird. Es soll einen

Mehr

Von Paul Curzon, Queen Mary, University of London mit Unterstützung von Google und EPSRC

Von Paul Curzon, Queen Mary, University of London mit Unterstützung von Google und EPSRC Compu terwissenscha ften mi t Spaßfak tor Spiele gewinnen: der perfekte Tic Tac Toe-Spieler Von Paul Curzon, Queen Mary, University of London mit Unterstützung von Google und EPSRC Spiele gewinnen: der

Mehr

Seminararbeit Ruby Uno Kartenspiel

Seminararbeit Ruby Uno Kartenspiel Seminararbeit Ruby Uno Kartenspiel Autor: Fabian Merki Fabian Merki 05.11.2006 1 von 10 Inhaltsverzeichnis Einleitung... 3 Die Idee... 4 Design und Implementierung in Ruby... 5 Testing... 7 Startbefehle...

Mehr

JMangler. Frithjof Kurtz. Universität Bonn, Seminar Softw aretechnologie WS 03/04, Jmangler Frithjof Kurtz 1

JMangler. Frithjof Kurtz. Universität Bonn, Seminar Softw aretechnologie WS 03/04, Jmangler Frithjof Kurtz 1 JMangler Frithjof Kurtz Universität Bonn, Seminar Softw aretechnologie WS 03/04, Jmangler Frithjof Kurtz 1 JMangler Vortragsgliederung Motivation Java Grundlagen JMangler Grundlagen Transformationen Algorithmen

Mehr

einkonto.zahle(+100); //Transaktion Einzahlung einkonto.zahle(-20); //Transaktion Auszahlung einkonto.zahle(+30); //Transaktion Einzahlung

einkonto.zahle(+100); //Transaktion Einzahlung einkonto.zahle(-20); //Transaktion Auszahlung einkonto.zahle(+30); //Transaktion Einzahlung PIWIN I Kap. 7 Objektorientierte Programmierung - Einführung 28 Testklasse public class TestGirokonto { public static void main(string[] args) { // erzeuge neues Konto Girokonto einkonto = new Girokonto();

Mehr

VIII: Vererbung. Unterklassen einer Klasse. Vererbung von Methoden und Instanzvariablen. Überschreiben von Methoden

VIII: Vererbung. Unterklassen einer Klasse. Vererbung von Methoden und Instanzvariablen. Überschreiben von Methoden VIII: Vererbung Unterklassen einer Klasse Vererbung von Methoden und Instanzvariablen Überschreiben von Methoden Vererbung als Realisierung einer is-a Beziehung. Informatik I VIII: Vererbung 259 Beispiel:

Mehr

Befragung und empirische Einschätzung der Praxisrelevanz

Befragung und empirische Einschätzung der Praxisrelevanz Befragung und empirische Einschätzung der Praxisrelevanz eines Vorgehensmodells zur Auswahl von CRM-Systemen D I P L O M A R B E I T zur Erlangung des Grades eines Diplom-Ökonomen der Wirtschaftswissenschaftlichen

Mehr

Kontinuierliche Architekturanalyse. in 3D

Kontinuierliche Architekturanalyse. in 3D Kontinuierliche Architekturanalyse in 3D Stefan Rinderle Bachelor an der HS Karlsruhe Master "Software Engineering" in München / Augsburg Seit 2013 bei Payback 2 Software-Visualisierung Visualisierung

Mehr

4PLAN Managed Service HR Controlling Prozess und Leistungen

4PLAN Managed Service HR Controlling Prozess und Leistungen World Class HR Controlling 4PLAN Managed Service HR Controlling Prozess und Leistungen Autor: Hanns- Dirk Brinkmann Version: 1.0 1 Einleitung... 3 2 Phasen im Überblick... 3 3 Leistungen... 4 3.1 Monatliche

Mehr

Die Ideen-Landkarte (Mind Map) Kreativ neue Ideen finden und darstellen Autor: Jürgen P. Bläsing

Die Ideen-Landkarte (Mind Map) Kreativ neue Ideen finden und darstellen Autor: Jürgen P. Bläsing QUALITY-APPs Applikationen für das Qualitätsmanagement Probieren und Studieren Die Ideen-Landkarte (Mind Map) Kreativ neue Ideen finden und darstellen Autor: Jürgen P. Bläsing Eine "Ideen-Landkarte" (Gedankenlandkarte,

Mehr

Einführung in die Programmierung mit Java. Hörsaalübung

Einführung in die Programmierung mit Java. Hörsaalübung Einführung in die Programmierung mit Java Hörsaalübung Folie 1 Grundlagen der Objektorientierung Seit Anfang der Neunzigerjahre Standardmethode der Softwareentwicklung. Die OOP Objektorientierte Programmierung

Mehr

Merkblatt des Fachgebiets Empirische Medienforschung und Politische Kommunikation zur Anfertigung von Masterarbeiten

Merkblatt des Fachgebiets Empirische Medienforschung und Politische Kommunikation zur Anfertigung von Masterarbeiten Merkblatt des Fachgebiets Empirische Medienforschung und Politische Kommunikation zur Anfertigung von Masterarbeiten Die hier festgelegten Regeln gelten nur für Arbeiten, die von Mitgliedern dieses Fachgebiets

Mehr

Einführung in die Softwaretechnologie

Einführung in die Softwaretechnologie R O O T S Einführung in die Softwaretechnologie Wintersemester 2011 Dr. Günter Kniesel Institut für Informatik III Römerstr. 164, D-53117 Bonn gk@cs.uni-bonn.de http://sewiki.iai.uni-bonn.de/teaching/lectures/se/2011/

Mehr

Taxonomy of Evolution and Dependability. Integration Engineering SS 2009 Andreas Landerer

Taxonomy of Evolution and Dependability. Integration Engineering SS 2009 Andreas Landerer Taxonomy of Evolution and Dependability Integration Engineering SS 2009 Andreas Landerer Agenda Informationen über Massimo Felici Definition zentraler Begriffe Inhalt des Artikels Kernaussagen des Artikels

Mehr

C# im Vergleich zu Java

C# im Vergleich zu Java C# im Vergleich zu Java Serhad Ilgün Seminar Universität Dortmund SS 03 Gliederung Entstehung von C# und Java Überblick von C# und Java Unterschiede und Gemeinsamkeiten Zusammenfassung und Ausblick Entstehung

Mehr

Praktikum im Bereich Praktische Informatik Echtzeitgraphik in C++ und DirectX10. computer graphics & visualization

Praktikum im Bereich Praktische Informatik Echtzeitgraphik in C++ und DirectX10. computer graphics & visualization Praktikum im Bereich Praktische Informatik Echtzeitgraphik in C++ und DirectX10 Übersicht In den ersten Wochen: Einführung in objektorientierte Programmierung mit C++ Anschließend: Einführung in die programmierbare

Mehr

Software Engineering Interaktionsdiagramme

Software Engineering Interaktionsdiagramme Software Engineering Interaktionsdiagramme Prof. Adrian A. Müller, PMP, PSM 1, CSM Fachbereich Informatik und Mikrosystemtechnik 1 Nachrichtenaustausch Welche Nachrichten werden ausgetauscht? (Methodenaufrufe)

Mehr

eassessment Oracle DB Engine Whitepaper

eassessment Oracle DB Engine Whitepaper eassessment Oracle DB Engine Whitepaper DOKUMENT: TYP: eassessment Oracle DB Engine Whitepaper Plattformdokumentation ERSTELLT VON: nova ratio AG Universitätsstraße 3 56070 Koblenz Deutschland VERSION:

Mehr

Programmierung - Paradigmen und Konzepte

Programmierung - Paradigmen und Konzepte Programmierung - Paradigmen und Konzepte Peter Forbrig, Immo O. Kerner ISBN 3-446-40301-9 Vorwort Weitere Informationen oder Bestellungen unter http://www.hanser.de/3-446-40301-9 sowie im Buchhandel Vorwort

Mehr

Prinzipien Objektorientierter Programmierung

Prinzipien Objektorientierter Programmierung Prinzipien Objektorientierter Programmierung Valerian Wintner Inhaltsverzeichnis 1 Vorwort 1 2 Kapselung 1 3 Polymorphie 2 3.1 Dynamische Polymorphie...................... 2 3.2 Statische Polymorphie........................

Mehr

x 2 2x + = 3 + Es gibt genau ein x R mit ax + b = 0, denn es gilt

x 2 2x + = 3 + Es gibt genau ein x R mit ax + b = 0, denn es gilt - 17 - Die Frage ist hier also: Für welche x R gilt x = x + 1? Das ist eine quadratische Gleichung für x. Es gilt x = x + 1 x x 3 = 0, und man kann quadratische Ergänzung machen:... ( ) ( ) x x + = 3 +

Mehr

3 Variablen. 3.1 Allgemeines. 3.2 Definition und Verwendung von Variablen

3 Variablen. 3.1 Allgemeines. 3.2 Definition und Verwendung von Variablen 3 Variablen 3.1 Allgemeines Variablen werden in Prozeduren, Mustern und Parameter-Dokumenten definiert und verwendet und bei der Jobgenerierung durch die Werte, die ihnen zugewiesen werden, ersetzt. Variablen

Mehr

Agile Software-Entwicklung: Vom Hype zum Daily Business

Agile Software-Entwicklung: Vom Hype zum Daily Business Agile Software-Entwicklung: Vom Hype zum Daily Business Prof. Dr. Sven Overhage Lehrstuhl für Wirtschaftsinformatik, insb. Industrielle Informationssysteme Otto-Friedrich-Universität Bamberg sven.overhage@uni-bamberg.de

Mehr

Bedienung von BlueJ. Klassenanzeige

Bedienung von BlueJ. Klassenanzeige Im Folgenden werden wichtige Funktionen für den Einsatz von BlueJ im Unterricht beschrieben. Hierbei wird auf den Umgang mit Projekten, Klassen und Objekten eingegangen. Abgeschlossen wird dieses Dokument

Mehr

Preisaktualisierungen via BC Pro-Catalogue

Preisaktualisierungen via BC Pro-Catalogue Preisaktualisierungen via BC Pro-Catalogue 1. Allgemein Seite 1 2. Anwendungsfall : Lieferant mit im System bereits vorhandenen Katalog Seite 2-3 3. Anwendungsfall : Neuer Lieferant Seite 4-8 1. Allgemein

Mehr

Binäre lineare Optimierung mit K*BMDs p.1/42

Binäre lineare Optimierung mit K*BMDs p.1/42 Binäre lineare Optimierung mit K*BMDs Ralf Wimmer wimmer@informatik.uni-freiburg.de Institut für Informatik Albert-Ludwigs-Universität Freiburg Binäre lineare Optimierung mit K*BMDs p.1/42 Grundlagen Binäre

Mehr

NH-Schuldenverwaltung 2015 1. Neuerungen 2015. Excel-Ausgabe bei fast allen Auswertungen verfügbar

NH-Schuldenverwaltung 2015 1. Neuerungen 2015. Excel-Ausgabe bei fast allen Auswertungen verfügbar NH-Schuldenverwaltung 2015 1 Neuerungen 2015 Excel-Ausgabe bei fast allen Auswertungen verfügbar Fortan ist es möglich unter dem Menüpunkt Listen nahezu alle Auswertungen der Einzelpunkte auch nach Excel

Mehr

RÖK Typo3 Dokumentation

RÖK Typo3 Dokumentation 2012 RÖK Typo3 Dokumentation Redakteur Sparten Eine Hilfe für den Einstieg in Typo3. Innpuls Werbeagentur GmbH 01.01.2012 2 RÖK Typo3 Dokumentation Inhalt 1) Was ist Typo3... 3 2) Typo3 aufrufen und Anmelden...

Mehr

Software Entwicklungs Praktikum (SWEP) Einführung und Organisatorisches

Software Entwicklungs Praktikum (SWEP) Einführung und Organisatorisches Software Entwicklungs Praktikum (SWEP) Einführung und Organisatorisches Sommersemester 2009 Stand 26.5.2009 Formalia 0 Organisatorisches 2 Studierende mit Haupt und Nebenfach Informatik 6 SWS, Diplom Veranstaltung

Mehr

Praktikum Compilerbau

Praktikum Compilerbau Implementation eines s 20. April 2005 Vorlesungen Vorlesungen, die nützliche für das Praktikum liefern: Automaten, Formale Sprachen und Berechenbarkeit bau Abstrakte Maschinen Programm-Optimierung Fertigkeiten

Mehr

Meeting C++ C++11 R-Value Referenzen

Meeting C++ C++11 R-Value Referenzen Meeting C++ Detlef Wilkening http://www.wilkening-online.de 09.11.2012 Inhalt Motivation L-Values und R-Values R-Value Referenzen Move Semantik std::move Funktionen mit R-Value-Referenz Parametern Fazit

Mehr

Softwarequalitätssicherung

Softwarequalitätssicherung Softwarequalitätssicherung Seminarvortrag Peter Winkelhane 1 Agenda Motivation Taxonomie zur Einordnung von Verfahren im Bereich kontraktbasiertem Testen Drei kontraktbasierte Verfahren Vergleich der drei

Mehr

Methoden der empirischen Sozialforschung (Grundlagen) Reinecke, Jost, Prof. Dr.

Methoden der empirischen Sozialforschung (Grundlagen) Reinecke, Jost, Prof. Dr. Universität Bielefeld Modul: Fakultät für Soziologie Methoden der empirischen Sozialforschung (Grundlagen) Modulschlüssel: 30-M2 Modulbeauftragte/r: Bergmann, Jörg R., Prof. Dr. Reinecke, Jost, Prof. Dr.

Mehr

Eine zu Grunde liegende Typdefinition beschreibt eine Struktur, die alle erlaubten Instanzen dieses Typs gemeinsam haben.

Eine zu Grunde liegende Typdefinition beschreibt eine Struktur, die alle erlaubten Instanzen dieses Typs gemeinsam haben. Der binäre Baum Tree Die geläufigste Datenstuktur ist der binäre Baum Tree. Dieses Beispielskript zeigt im direkten Vergleich zu anderen Sprachen den Umgang mit formalen Typparametern in CHELSEA. Wir steigen

Mehr

Fragebogen zur Evaluation der Vorlesung und Übungen Computer Grafik, CS231, SS05

Fragebogen zur Evaluation der Vorlesung und Übungen Computer Grafik, CS231, SS05 Fragebogen zur Evaluation der Vorlesung und Übungen Computer Grafik, CS231, SS05 Dozent: Thomas Vetter Bitte Name des Tutors angeben: Liebe Studierende, Ihre Angaben in diesem Fragebogen helfen uns, die

Mehr

Software Engineering I

Software Engineering I Software I Übungsblatt 1 + 2 Claas Pinkernell Technische Universität Braunschweig http://www.sse.cs.tu-bs.de/ Seite 2 Welche Werkzeuge? Programmiersprache Java Integrierte Entwicklungsumgebung Eclipse

Mehr

Leitfaden zur Erstellung eines Thesenpapiers

Leitfaden zur Erstellung eines Thesenpapiers Leitfaden zur Erstellung eines papiers Vor Referaten oder mündlichen Prüfungen werden Studierende häufig darum gebeten, ein papier einzureichen. Dieser Leitfaden soll Ihnen daher die verschiedenen Einsatzmöglichkeiten

Mehr

Syllabus BAE 4042-Lean Manufacturing SS2015

Syllabus BAE 4042-Lean Manufacturing SS2015 Lehrveranstaltung: BAE 4042 Lean Manufacturing 2 SWS, 2 Credits, Deutsch, Niveau: fortgeschritten Montag 08:00-09:30 Uhr Raum: THE Die Veranstaltung Lean Manufacturing hat Projektcharakter und ist nur

Mehr

Die 7stufige Notenskala der Neuen Mittelschule Versuch einer Interpretation

Die 7stufige Notenskala der Neuen Mittelschule Versuch einer Interpretation Die 7stufige Notenskala der Neuen Mittelschule Versuch einer Interpretation Um die Beurteilungsskala der Neuen Mittelschule interpretieren und richtig anwenden zu können, scheinen mir zwei grundsätzliche

Mehr

Lösungsvorschlag für das Übungsblatt 1. Aufgabe 1.

Lösungsvorschlag für das Übungsblatt 1. Aufgabe 1. Lösungsvorschlag für das Übungsblatt 1. Aufgabe 1. Zusammengefasst aus Ihren Beiträgen Wie bewerten sie das System ingesamt? Das Watson System verdeutlicht den Fortschritt der Künstlichen Intelligenz Forschung/Computerlinguistik/Informatik

Mehr