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

Was ist ein Compiler?

Was ist ein Compiler? Was ist ein Compiler? Was ist ein Compiler und worum geht es? Wie ist ein Compiler aufgebaut? Warum beschäftigen wir uns mit Compilerbau? Wie ist die Veranstaltung organisiert? Was interessiert Sie besonders?

Mehr

5.5.8 Öffentliche und private Eigenschaften

5.5.8 Öffentliche und private Eigenschaften 5.5.8 Öffentliche und private Eigenschaften Schnittstellen vs. Implementierungen: Schnittstelle einer Klasse beschreibt, was eine Klasse leistet und wie sie benutzt werden kann, ohne dass ihre Implementierung

Mehr

Einschätzung der Diplomarbeit. Musik im Film- Auswirkungen von Filmmusik auf das Gedächtnis für Filminhalte

Einschätzung der Diplomarbeit. Musik im Film- Auswirkungen von Filmmusik auf das Gedächtnis für Filminhalte Einschätzung der Diplomarbeit Musik im Film- Auswirkungen von Filmmusik auf das Gedächtnis für Filminhalte Von: Wultsch Christina Matrikelnr.: 0411409 LV: Wissenschaftliches Arbeiten (LV-Nr.: 000.002)

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

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

Um zusammenfassende Berichte zu erstellen, gehen Sie folgendermaßen vor:

Um zusammenfassende Berichte zu erstellen, gehen Sie folgendermaßen vor: Ergebnisreport: mehrere Lehrveranstaltungen zusammenfassen 1 1. Ordner anlegen In der Rolle des Berichterstellers (siehe EvaSys-Editor links oben) können zusammenfassende Ergebnisberichte über mehrere

Mehr

3 Objektorientierte Konzepte in Java

3 Objektorientierte Konzepte in Java 3 Objektorientierte Konzepte in Java 3.1 Klassendeklarationen Fragen an die Klassendeklaration: Wie heißt die Klasse? Wer darf auf die Klasse und ihre Attribute/Methoden zugreifen? Ist die Klasse eine

Mehr

1. Zeilenendkommentare: //... 2. geklammerte Kommentare: /*... */ 3. Dokumentationskommentare: /**... */

1. Zeilenendkommentare: //... 2. geklammerte Kommentare: /*... */ 3. Dokumentationskommentare: /**... */ 1 Kommentare im Source-Code Kommentare werden im Source-Code überlesen und wirken wie "white Space" (Leerzeichen, Tabulator, Zeilenvorschub). Mit Ausnahme des @deprecated-tag in Dokumentationskommentaren

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

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

Betragsgleichungen und die Methode der Fallunterscheidungen

Betragsgleichungen und die Methode der Fallunterscheidungen mathe online Skripten http://www.mathe-online.at/skripten/ Betragsgleichungen und die Methode der Fallunterscheidungen Franz Embacher Fakultät für Mathematik der Universität Wien E-mail: franz.embacher@univie.ac.at

Mehr

Anforderungen und Auswahlkriterien für Projektmanagement-Software

Anforderungen und Auswahlkriterien für Projektmanagement-Software Anforderungen und Auswahlkriterien für Projektmanagement-Software Anika Gobert 1,Patrick Keil 2,Veronika Langlotz 1 1 Projektmanagement Payment Giesecke &Devrient GmbH Prinzregentenstr. 159, Postfach 800729,

Mehr

Leitfaden zur Anfertigung von Diplomarbeiten

Leitfaden zur Anfertigung von Diplomarbeiten Leitfaden zur Anfertigung von Diplomarbeiten Das Institut für Europäische Sportentwicklung und Freizeitforschung vergibt in unregelmäßigen Abständen Diplomarbeitsthemen zur Bearbeitung, die teilweise mit

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

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

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

Leitfaden für Masterarbeiten im Master Management & Business Development für den Bereich Kommunikation und PR

Leitfaden für Masterarbeiten im Master Management & Business Development für den Bereich Kommunikation und PR Leitfaden für Masterarbeiten im Master Management & Business Development für den Bereich Kommunikation und PR 1. Wesen und Ziel der Masterarbeit Im Master Management & Business Development erlangen die

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

Software Engineering Analyse und Analysemuster

Software Engineering Analyse und Analysemuster Software Engineering Analyse und Analysemuster Prof. Adrian A. Müller, PMP, PSM 1, CSM Fachbereich Informatik und Mikrosystemtechnik 1 Klassendiagramme in der Analyse Im Rahmen der Anforderungsanalyse

Mehr

Lösungen zu den Übungsaufgaben aus Kapitel 3

Lösungen zu den Übungsaufgaben aus Kapitel 3 Lösungen zu den Übungsaufgaben aus Kapitel 3 Ü3.1: a) Die Start-Buchungslimits betragen b 1 = 25, b 2 = 20 und b 3 = 10. In der folgenden Tabelle sind jeweils die Annahmen ( ) und Ablehnungen ( ) der Anfragen

Mehr

Auswerten mit Excel. Viele Video-Tutorials auf Youtube z.b. http://www.youtube.com/watch?v=vuuky6xxjro

Auswerten mit Excel. Viele Video-Tutorials auf Youtube z.b. http://www.youtube.com/watch?v=vuuky6xxjro Auswerten mit Excel Viele Video-Tutorials auf Youtube z.b. http://www.youtube.com/watch?v=vuuky6xxjro 1. Pivot-Tabellen erstellen: In der Datenmaske in eine beliebige Zelle klicken Registerkarte Einfügen

Mehr

Inhaltsverzeichnis INHALTSVERZEICHNIS 9

Inhaltsverzeichnis INHALTSVERZEICHNIS 9 INHALTSVERZEICHNIS 9 Inhaltsverzeichnis Verzeichnis der Übersichten im Text...15 1. Allgemeine Merkmale wissenschaftlicher Arbeiten...18 1.1 Allgemeine Anforderungen an wissenschaftliches Arbeiten...19

Mehr

7. Objektorientierte Softwareentwicklung/3. Informatik II für Verkehrsingenieure

7. Objektorientierte Softwareentwicklung/3. Informatik II für Verkehrsingenieure 7. Objektorientierte Softwareentwicklung/3 Informatik II für Verkehrsingenieure Überblick FOLGENDE BEGRIFFE/PRINZIPIEN SOLLTEN BEKANNT SEIN Objekte Klasse Attribute Fähigkeiten ZIEL DER HEUTIGEN LEHRVERANSTALTUNG

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

Rhetorik und Argumentationstheorie. [frederik.gierlinger@univie.ac.at]

Rhetorik und Argumentationstheorie. [frederik.gierlinger@univie.ac.at] Rhetorik und Argumentationstheorie 1 [frederik.gierlinger@univie.ac.at] Ablauf der Veranstaltung Termine 1-6 Erarbeitung diverser Grundbegriffe Termine 7-12 Besprechung von philosophischen Aufsätzen Termin

Mehr

1 Einleitung. 1.1 Motivation

1 Einleitung. 1.1 Motivation 1 Einleitung 1.1 Motivation Eine zunehmende Globalisierung in Verbindung mit der Verbreitung des elektronischen Handels, stets kürzer werdende Produktlebenszyklen und eine hohe Variantenvielfalt konstituieren

Mehr

Inhalt Software-Metriken Software-Metriken mit Together FindBugs. Software-Metriken. Raimar Lill Matthias Meitner David Föhrweiser Marc Spisländer

Inhalt Software-Metriken Software-Metriken mit Together FindBugs. Software-Metriken. Raimar Lill Matthias Meitner David Föhrweiser Marc Spisländer Lill, Meitner, Föhrweiser, Spisländer FAU Erlangen-Nürnberg Software-Metriken 1 / 24 Software-Metriken Raimar Lill Matthias Meitner David Föhrweiser Marc Spisländer Lehrstuhl für Software Engineering Friedrich-Alexander-Universität

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

Systemanalyse. - Seminar für AI/DM 3 im Wintersemester 2004/05 -

Systemanalyse. - Seminar für AI/DM 3 im Wintersemester 2004/05 - Systemanalyse - Seminar für AI/DM 3 im Wintersemester 2004/05 - Prof. Dr. Hans-Jürgen Steffens (by courtesy of Prof. Dr. Thomas Allweyer) Fachbereich Informatik und Mikrosystemtechnik Fachhochschule Kaiserslautern,

Mehr

5.4 Klassen und Objekte

5.4 Klassen und Objekte 5.4 Klassen und Objekte Zusammenfassung: Projekt Figuren und Zeichner Figuren stellt Basisklassen für geometrische Figuren zur Verfügung Zeichner bietet eine übergeordnete Klasse Zeichner, welche die Dienstleistungen

Mehr

Software-Metriken. Wolfgang Globke. Seminar Moderne Softwareentwicklung SS 2005. Software-Metriken. Wolfgang Globke. Metriken und Qualitätsmodelle

Software-Metriken. Wolfgang Globke. Seminar Moderne Softwareentwicklung SS 2005. Software-Metriken. Wolfgang Globke. Metriken und Qualitätsmodelle Software- und smodelle Software- Klassische Objektorientierte Seminar Moderne Softwareentwicklung SS 2005 Gliederung Software- und smodelle 1 und smodelle Klassische Objektorientierte 2 Klassische Objektorientierte

Mehr

KT Communications Engineering

KT Communications Engineering KT Communications Engineering IKT im Kontext von (verteilten) Softwareentwicklungsprojekten Sommersemester 2015 LVA-Nummer: 257.131 LVA-Leiter/in: Florian Krenn, MSc Kontakt: Florian.Krenn@jku.at, (0732

Mehr

Alle Inhalte dieses ebooks sind urheberrechtlich geschützt. Die Herstellung und Verbreitung von Kopien ist nur mit ausdrücklicher Genehmigung des

Alle Inhalte dieses ebooks sind urheberrechtlich geschützt. Die Herstellung und Verbreitung von Kopien ist nur mit ausdrücklicher Genehmigung des Alle Inhalte dieses ebooks sind urheberrechtlich geschützt. Die Herstellung und Verbreitung von Kopien ist nur mit ausdrücklicher Genehmigung des Verlages gestattet. Agiles Projektmanagement Scrum, Use

Mehr

Kapitel 12 Dokumentation und Zugriffsrechte

Kapitel 12 Dokumentation und Zugriffsrechte Kapitel 12 Dokumentation und Zugriffsrechte Seite 1 / 6 Kapitel 12 Dokumentation und Zugriffsrechte Lernziele: Dokumentation mit Hilfe von Javadoc Datenkapselung über Zugriffsrechte 12.1 Dokumentation

Mehr

Software Engineering in der Praxis

Software Engineering in der Praxis Software Engineering in der Praxis Praktische Übungen Adersberger, Spisländer FAU Erlangen-Nürnberg Software-Metriken 1 / 26 Software-Metriken Josef Adersberger Marc Spisländer Lehrstuhl für Software Engineering

Mehr

Übungen zur Softwaretechnik

Übungen zur Softwaretechnik Technische Universität München Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering Markus Pister, Dr. Bernhard Rumpe WS 2002/2003 Lösungsblatt 8 10. Dezember 2002 www4.in.tum.de/~rumpe/se

Mehr

Softwaretechnik (WS 11/12)

Softwaretechnik (WS 11/12) Universität Augsburg, LSt. Softwaretechnik, K. Stenzel, H. Seebach, G. Anders Softwaretechnik (WS 11/12) Lösungsvorschlag 5 Aufgabe 1 (System Behavior: System Sequence Diagrams) (10/5 Punkte) a) Was sind

Mehr

Tutorium Use Cases 2.0 im Rahmen der Konferenz Modellierung 2014 in Wien

Tutorium Use Cases 2.0 im Rahmen der Konferenz Modellierung 2014 in Wien Tutorium Use Cases 2.0 im Rahmen der Konferenz Modellierung 2014 in Wien Alexander Rachmann, Uwe Valentini, Rüdiger Weissbach A.Rachmann@anforderungsfabrik.de, Uwe.Valentini@hood-group.com, Ruediger.Weissbach@haw

Mehr

Ein Überblick über KDevelop

Ein Überblick über KDevelop Inhalt KDevelop? Was ist das eigentlich? Inhalt KDevelop? Was ist das eigentlich? Was ist KDevelop 4.x? im Kern: C++-IDE basierend auf KDE- und Qt-Bibliotheken Komplettes Rewrite von Version 3 erstes 4.0-Release

Mehr

Objektorientierter Software-Entwurf Grundlagen 1 1. Analyse Design Implementierung. Frühe Phasen durch Informationssystemanalyse abgedeckt

Objektorientierter Software-Entwurf Grundlagen 1 1. Analyse Design Implementierung. Frühe Phasen durch Informationssystemanalyse abgedeckt Objektorientierter Software-Entwurf Grundlagen 1 1 Einordnung der Veranstaltung Analyse Design Implementierung Slide 1 Informationssystemanalyse Objektorientierter Software-Entwurf Frühe Phasen durch Informationssystemanalyse

Mehr

Quelltextähnlichkeit

Quelltextähnlichkeit Quelltextähnlichkeit String autor = Tobias Jamin ; String projekt = Arte-Fakt ; String seminar = Transformationen ; Date termin = new Date(3, // Tag 2, // Monat 2006); Presentation praesentation = new

Mehr

Organisatorisches. Ökonometrie I Michael Hauser WS15/16

Organisatorisches. Ökonometrie I Michael Hauser WS15/16 1 / 12 Organisatorisches Ökonometrie I Michael Hauser WS15/16 2 / 12 Web-Seite zum Kurs Web-Seite des Kurses: Auf der Web-Seite finden sie die organisatorischen Regelungen, den Terminplan und Regeln zum

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

How- to. E- Mail- Marketing How- to. Anrede personalisieren. Ihr Kontakt zur Inxmail Academy

How- to. E- Mail- Marketing How- to. Anrede personalisieren. Ihr Kontakt zur Inxmail Academy E- Mail- Marketing How- to How- to Anrede personalisieren Personalisierung ist ein wichtiges Kundenbindungsinstrument, durch das die Aufmerksamkeit des Empfängers erheblich gesteigert werden kann. Dieser

Mehr

Unterscheidung: Workflowsystem vs. Informationssystem

Unterscheidung: Workflowsystem vs. Informationssystem 1. Vorwort 1.1. Gemeinsamkeiten Unterscheidung: Workflowsystem vs. Die Überschneidungsfläche zwischen Workflowsystem und ist die Domäne, also dass es darum geht, Varianten eines Dokuments schrittweise

Mehr

APPS für ios 9 professionell entwickeln

APPS für ios 9 professionell entwickeln thomas SILLMANN 2. Auflage APPS für ios 9 professionell entwickeln // Sauberen Code schreiben mit Objective-C und Swift // Stabile Apps programmieren // Techniken und Methoden von Grund auf verstehen Inkl.

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

Ausfüllkästchen und absolute Bezüge

Ausfüllkästchen und absolute Bezüge Ausfüllkästchen und absolute Bezüge Übungsbeispiel Statistik Teil 1 Im Beispiel Statistik verwenden Sie das Ausfüllkästchen, um Zahlen- und Monatsreihen zu erstellen. Beim Vervielfältigen von Formeln ist

Mehr

Interaktionen zwischen Objekten durch Senden von Nachrichten und Reagieren auf empfangene Nachrichten

Interaktionen zwischen Objekten durch Senden von Nachrichten und Reagieren auf empfangene Nachrichten Objekt Objekt kapselt Variablen und Routinen Interaktionen zwischen Objekten durch Senden von Nachrichten und Reagieren auf empfangene Nachrichten Eigenschaften jedes Objekts: Identität (identisch = mehrere

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

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

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

Software Engineering Klassendiagramme Assoziationen

Software Engineering Klassendiagramme Assoziationen Software Engineering Klassendiagramme Assoziationen Prof. Adrian A. Müller, PMP, PSM 1, CSM Fachbereich Informatik und Mikrosystemtechnik 1 Lesen von Multiplizitäten (1) Multiplizitäten werden folgendermaßen

Mehr

Einführung in die Informatik Tools

Einführung in die Informatik Tools Einführung in die Informatik Tools Werkzeuge zur Erstellung von Softwareprojekten Wolfram Burgard 8.1 Motivation Große Softwareprojekte werden schnell unübersichtlich. Änderungen im Code können leicht

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

Musterlösung zur Vorlesung Modellbasierte Softwareentwicklung Wintersemester 2014/2015 Übungsblatt 9

Musterlösung zur Vorlesung Modellbasierte Softwareentwicklung Wintersemester 2014/2015 Übungsblatt 9 Prof. Dr. Wilhelm Schäfer Paderborn, 15. Dezember 2014 Christian Brenner Tristan Wittgen Musterlösung zur Vorlesung Modellbasierte Softwareentwicklung Wintersemester 2014/2015 Übungsblatt 9 Aufgabe 1 Codegenerierung

Mehr

Leitfaden: Webbasiertes Lehrendeninterface zur Lehrveranstaltungsverwaltung

Leitfaden: Webbasiertes Lehrendeninterface zur Lehrveranstaltungsverwaltung Leitfaden: Webbasiertes Lehrendeninterface zur Lehrveranstaltungsverwaltung Stand: Mai 2008 Lydia Köck Inhaltsverzeichnis 1 Leistungsumfang 3 2 Login im Lehrendeninterface der Universität Wien 4 3 Veranstaltungen

Mehr

5 Zusammenhangsmaße, Korrelation und Regression

5 Zusammenhangsmaße, Korrelation und Regression 5 Zusammenhangsmaße, Korrelation und Regression 5.1 Zusammenhangsmaße und Korrelation Aufgabe 5.1 In einem Hauptstudiumsseminar des Lehrstuhls für Wirtschafts- und Sozialstatistik machten die Teilnehmer

Mehr

Wirtschaftsinformatik I

Wirtschaftsinformatik I Wirtschaftsinformatik I - Tutorium 6/ 7 (April 2010) Zusatzinformationen - Lösungsvorschläge Wirtschaftsinformatik I Tutorium Jochen Daum (4.Semester BWL) Universität Mannheim Rechtshinweis: Diese Präsentation

Mehr

Literaturverwaltung mit Stud.IP

Literaturverwaltung mit Stud.IP Literaturverwaltung mit Stud.IP Voraussetzungen Account für Stud.IP an der Justus-Liebig-Universität Gießen (https://studip.uni-giessen.de) Kenntnisse im allgemeinen Umgang mit Stud.IP Beachten Sie, dass

Mehr

Klassenbeziehungen & Vererbung

Klassenbeziehungen & Vererbung Klassenbeziehungen & Vererbung VL Objektorientierte Programmierung Raimund Kirner teilweise nach Folien von Franz Puntigam, TU Wien Überblick Arten von Klassenbeziehungen Untertypen versus Vererbung in

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

Smart-Grid-Tools Beschleunigen Sie die Erstellung von Bauteilen ZUSAMMENFASSUNG. IM WORKSHOP Tip #14. Die Herausforderung, große Bauteile zu erstellen

Smart-Grid-Tools Beschleunigen Sie die Erstellung von Bauteilen ZUSAMMENFASSUNG. IM WORKSHOP Tip #14. Die Herausforderung, große Bauteile zu erstellen IM WORKSHOP Tip #14 Smart-Grid-Tools Beschleunigen Sie die Erstellung von Bauteilen ZUSAMMENFASSUNG Mai 2007 Autor: Phil Loughhead Die Erstellung von Bauteilen ist ein fundamentaler Bestandteil des Design-

Mehr

etutor Benutzerhandbuch XQuery Benutzerhandbuch Georg Nitsche

etutor Benutzerhandbuch XQuery Benutzerhandbuch Georg Nitsche etutor Benutzerhandbuch Benutzerhandbuch XQuery Georg Nitsche Version 1.0 Stand März 2006 Versionsverlauf: Version Autor Datum Änderungen 1.0 gn 06.03.2006 Fertigstellung der ersten Version Inhaltsverzeichnis:

Mehr

PVS Grobkonzept: Strukturelle und funktionale Erweiterungen bei der Verwaltung der Arbeitszeit und der organisatorischen Zuordnung

PVS Grobkonzept: Strukturelle und funktionale Erweiterungen bei der Verwaltung der Arbeitszeit und der organisatorischen Zuordnung PVS Grobkonzept: Strukturelle und funktionale Erweiterungen bei der Verwaltung der Arbeitszeit und der organisatorischen Zuordnung Bearbeiter: Klopfer, Klopfer Software GmbH Version: 31.10.2010 Abkürzungen

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

IT-Basics 2. DI Gerhard Fließ

IT-Basics 2. DI Gerhard Fließ IT-Basics 2 DI Gerhard Fließ Wer bin ich? DI Gerhard Fließ Telematik Studium an der TU Graz Softwareentwickler XiTrust www.xitrust.com www.tugraz.at Worum geht es? Objektorientierte Programmierung Konzepte

Mehr

3. Tagung des Fachausschusses für technische Fragen

3. Tagung des Fachausschusses für technische Fragen OTIF ORGANISATION INTERGOUVERNEMENTALE POUR LES TRANSPORTS INTERNATIONAUX FERROVIAIRES ZWISCHENSTAATLICHE ORGANISATION FÜR DEN INTERNATIONALEN EISENBAHNVERKEHR INTERGOVERNMENTAL ORGANISATION FOR INTER-

Mehr

3 Objektorientierte Konzepte in Java

3 Objektorientierte Konzepte in Java 3 Objektorientierte Konzepte in Java Bisherige Beobachtungen zu Objekten: werden in Klassen zusammengefasst besitzen Eigenschaften und Verhalten verbergen private Informationen werden geboren, leben und

Mehr

Qualitätsmanagement im Projekt

Qualitätsmanagement im Projekt Software-Engineering Qualitätsmanagement im Projekt Vorlesung im Wintersemester 2008/2009 Fakultät Wirtschaftsinformatik Klaus Mairon, M.Sc. Inhalte Messen und Bewerten: Metriken in der Qualitätssicherung

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

Anleitung zur Bewertung von Projekt-, Studien- und Bachelorarbeiten

Anleitung zur Bewertung von Projekt-, Studien- und Bachelorarbeiten Anleitung zur Bewertung von Projekt-, Studien- und Bachelorarbeiten Prinzip Die Begutachtung von Studien- und Diplom- bzw. Bachelorarbeiten erfolgt in zwei Schritten: 1. Schritt: Schematische Bewertung

Mehr

Gemeinsame Gestaltung und Entwicklung von Geschäftsprozessen und Unternehmenssoftware

Gemeinsame Gestaltung und Entwicklung von Geschäftsprozessen und Unternehmenssoftware Johannes Kepler Universität Linz Institut für Informationsverarbeitung und Mikroprozessortechnik Diplomarbeit Gemeinsame Gestaltung und Entwicklung von Geschäftsprozessen und Unternehmenssoftware mit besonderer

Mehr

Softwaretechnikpraktikum SS 2004. Qualitätsmanagement I. 1. Überblick. Qualität. Qualitätsmerkmal

Softwaretechnikpraktikum SS 2004. Qualitätsmanagement I. 1. Überblick. Qualität. Qualitätsmerkmal Softwaretechnikpraktikum SS 2004 Qualitätsmanagement I 5. Vorlesung 1. Überblick Planungsphase Definitionsphase Entwurfsphase Implem.- phase Fragen Was ist Qualität? Wie kann man Qualität messen? Wie kann

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

Lohnt sich Requirements Engineering?

Lohnt sich Requirements Engineering? Lohnt sich Requirements Engineering? Seminar Messbarkeit von Anforderungen am Fachgebiet Software Engineering Wintersemester 2007/2008 Betreuer: Eric Knauss Oleksandr Kazandzhi Gliederung Einleitung Messen

Mehr

Algorithmen und Datenstrukturen. Große Übung vom 29.10.09 Nils Schweer

Algorithmen und Datenstrukturen. Große Übung vom 29.10.09 Nils Schweer Algorithmen und Datenstrukturen Große Übung vom 29.10.09 Nils Schweer Diese Folien Braucht man nicht abzuschreiben Stehen im Netz unter www.ibr.cs.tu-bs.de/courses/ws0910/aud/index.html Kleine Übungen

Mehr

Planmäßig ausbilden im Kleinbetrieb

Planmäßig ausbilden im Kleinbetrieb Planmäßig im Kleinbetrieb Die Planmäßigkeit der Ausbildung in einem Kleinbetrieb lässt sich mit Hilfe folgender 4 Module verbessern: Ausbildungsplan Lernbögen Motivation Einen Ausbildungsplan erstellen

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

WCF Services in InfoPath 2010 nutzen

WCF Services in InfoPath 2010 nutzen WCF Services in InfoPath 2010 nutzen Abstract Gerade wenn man schreibend von InfoPath aus auf eine SQL-Server Datenbank zugreifen will, kommt man quasi um einen Web Service nicht herum. In diesem Post

Mehr

Inspektionen, Reviews und Walkthroughs. Christian Peucker 12.07.2006

Inspektionen, Reviews und Walkthroughs. Christian Peucker 12.07.2006 Werkzeugunterstützung tzung für f Inspektionen, Reviews und Walkthroughs Christian Peucker 12.07.2006 Gliederung Definition: Review, Inspektion und Walkthrough Tools für Inspektionen Motivation zur Nutzung

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

opsi-401-releasenotes-upgrade-manual

opsi-401-releasenotes-upgrade-manual opsi-401-releasenotes-upgrade-manual Stand: 01.05.2011 uib gmbh Bonifaziusplatz 1b 55118 Mainz Tel.:+49 6131 275610 www.uib.de info@uib.de i Inhaltsverzeichnis 1 Einführung 1 2 Neuerungen in opsi 4.0.1

Mehr

Begutachtungsprozess

Begutachtungsprozess Begutachtungsprozess Mit dem vorliegenden Dokument wird der unter Punkt 8.2 der Bekanntmachung zum zweiten Aufruf des fünften beschriebene Begutachtungsprozess für Skizzen näher erläutert. Dieser wird

Mehr

Innovator 11 classix. Java Reverse Engineering. HowTo. Ralph Schönleber. www.mid.de

Innovator 11 classix. Java Reverse Engineering. HowTo. Ralph Schönleber. www.mid.de Innovator 11 classix Java Reverse Engineering Ralph Schönleber HowTo www.mid.de Mit Innovator Java Reverse Engineering durchführen Inhaltsverzeichnis Voraussetzungen... 2 Java Reverse Engineering... 2

Mehr

4 ANALYSE VON TABELLEN

4 ANALYSE VON TABELLEN MS Excel 2010 Aufbau Analyse von Tabellen 4 ANALYSE VON TABELLEN Lernen Sie in diesem Kapitel die Möglichkeiten kennen, Tabelleninhalte optimal auszuwerten und mit was wäre wenn die Daten zu analysieren.

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

EXTRAKTION UND KLASSIFIKATION VON BEWERTETEN PRODUKTFEATURES AUF WEBSEITEN

EXTRAKTION UND KLASSIFIKATION VON BEWERTETEN PRODUKTFEATURES AUF WEBSEITEN EXTRAKTION UND KLASSIFIKATION VON BEWERTETEN PRODUKTFEATURES AUF WEBSEITEN T-SYSTEMS MULTIMEDIA SOLUTIONS GMBH, 16. FEBRUAR 2012 1. Schlüsselworte Semantic Web, Opinion Mining, Sentiment Analysis, Stimmungsanalyse,

Mehr

Grundlagen der Programmiersprache C++

Grundlagen der Programmiersprache C++ / TU Braunschweig Grundlagen der Programmiersprache C++ Um den Studierenden den Einstieg in die FE-Programmierung zu erleichtern werden die wesentlichen Elemente eines C-Programmes beschrieben, soweit

Mehr

Numerisches Programmieren

Numerisches Programmieren Technische Universität München WS /3 Institut für Informatik Prof Dr Hans-Joachim Bungartz Dipl-Inf Christoph Riesinger Dipl-Inf Dipl-Math Jürgen Bräckle Numerisches Programmieren Programmieraufgabe: Polnominterpolation,

Mehr

Fortbildungsprüfung Geprüfter Controller / Geprüfte Controllerin

Fortbildungsprüfung Geprüfter Controller / Geprüfte Controllerin Fortbildungsprüfung Geprüfter Controller / Geprüfte Controllerin Anmeldung 1. Anmeldeschluss für die Prüfung im Herbst ist jeweils der 1. Juli, Anmeldeschluss für die Prüfung im Frühjahr ist jeweils der

Mehr

Software Technologie Refactoring. Nutzungsverhalten der Entwickler bzgl. des Refactoring. Nguyen Hung

Software Technologie Refactoring. Nutzungsverhalten der Entwickler bzgl. des Refactoring. Nguyen Hung Software Technologie Refactoring Thema 1.1 Nutzungsverhalten der Entwickler bzgl. des Refactoring Nguyen Hung Überblick Refactoring Ziele des Refactoring Refactoring bei Entwicklern Nutzungsverhalten Fragen

Mehr

KREDITVERZEICHNIS Konfiguration Ausgabe: 20.02.13 1/13. Dokumentation KREDITVERZEICHNIS. Teil 2. Konfiguration

KREDITVERZEICHNIS Konfiguration Ausgabe: 20.02.13 1/13. Dokumentation KREDITVERZEICHNIS. Teil 2. Konfiguration KREDITVERZEICHNIS Konfiguration Ausgabe: 20.02.13 1/13 Dokumentation KREDITVERZEICHNIS Teil 2 Konfiguration Stand 20.02.2013 KREDITVERZEICHNIS Konfiguration Ausgabe: 20.02.13 2/13 Inhalt 1. KONFIGURATION...

Mehr

Algorithmische Kernsprache. Zuweisung, einfache und bedingte Anweisung, Blöcke, Schleifen, return, debugging.

Algorithmische Kernsprache. Zuweisung, einfache und bedingte Anweisung, Blöcke, Schleifen, return, debugging. Algorithmische Kernsprache Zuweisung, einfache und bedingte Anweisung, Blöcke, Schleifen, return, debugging. Ausdrücke Anweisungen Ausdrücke bezeichnen einen Wert Kontext stellt Werte von Variablen Werte

Mehr

Willkommen zur Vorlesung Statistik (Master)

Willkommen zur Vorlesung Statistik (Master) Willkommen zur Vorlesung Statistik (Master) Thema dieser Vorlesung: Verteilungsfreie Verfahren Prof. Dr. Wolfgang Ludwig-Mayerhofer Universität Siegen Philosophische Fakultät, Seminar für Sozialwissenschaften

Mehr

Pass by Value Pass by Reference Defaults, Overloading, variable Parameteranzahl

Pass by Value Pass by Reference Defaults, Overloading, variable Parameteranzahl Funktionen Zusammenfassung von Befehlssequenzen als aufrufbare/wiederverwendbare Funktionen in einem Programmblock mit festgelegter Schnittstelle (Signatur) Derartige prozedurale Programmierung erlaubt

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

Materialien für Veranstalter

Materialien für Veranstalter HowTo Blog Seminardoku mittels Weblog Es gibt unterschiedliche Möglichkeiten zur Seminardokumentation und Mitwirkung der Ein Blog oder auch Web-Log, Wortkreuzung aus engl. World Wide Web und Log für Logbuch,

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