Software Visualisierung im Kontext des Programmdebugging

Größe: px
Ab Seite anzeigen:

Download "Software Visualisierung im Kontext des Programmdebugging"

Transkript

1 Software Visualisierung im Kontext des Programmdebugging Marian Daubner TU-WIEN Bakkalaureatsarbeit , Österreich Abstract Diese Arbeit diskutiert nichttraditionelle Debugging-Techniken. Es beschreibt die Software Visualisierung als ein Mittel für schnelles Fehlerfinden in Programmen. Drei Arbeiten, die sich mit dieser Thema befassen, werden hier erörtert. Die einzelne Ideen haben wir zusammengefasst und verglichen.

2 Inhalt INHALT... 1 EINLEITUNG... 2 FÄRBUNGSTECHNIKEN... 3 CODE VISUALISIERUNG... 7 VISUALISIERUNG MIT UML... 8 OBJEKTDIAGRAMM...10 INTERESSENSGRAD...11 GENERALISATION UND AGGREGATION...13 END-USER TECHNIKEN...15 FEHLERLOKALISIERUNGSTECHNIKEN IN END-USER PROGRAMMEN...16 Die Test-Count Technik...17 Die Blocking Technik...18 Die Nearest Consumer Technik...19 ERGEBNISSE...19 TECHNIKEN...19 VISUALISIERUNGEN...20 SCHLUSSFOLGERUNG...21 REFERENZEN...22 BIBLIOGRAPHIE

3 Einleitung Entwickler verbrauchen den größten Teil der Softwareentwicklung mit Debugging. Der Versuch die Anzahl von Fehlern in Software zu reduzieren wird auf 50% - 80% der Entwicklungs- und Wartungszeit geschätzt. Debugging ist damit das am meisten zeitkonsumierende Verfahren in der Programmentwicklung. Viele Techniken wurden erforscht, um das Verfahren zu vereinfachen und die dafür gebrauchte Zeit zu verkürzen. Aber der größte Teil dieser Techniken ist nicht für große Programme geeignet oder braucht zu viel manuelle Beeinflussung. Symbolische Debugger schaffen einige Hilfe, aber die Aufgabe bleibt komplex und schwierig. Anders als Breakpoint und Tracing helfen diese nicht in den höheren Ebenen des Programms. Das Lokalisieren von Fehlern ist als der schwerste Teil des Debugging. Es wurde bemerkt, dass die Entwickler beim Debugging diese vier Schritte machen: 1. finde Zeilen in Source-code, die am Scheitern beteiligt sind; 2. markiere verdächtige Zeilen, die die Fehler enthalten könnten; 3. schätze die mögliche Fehlerursachen ab; und, 4. ändere das Programm. Ein Source-code Debugger hilft nur bei erster Aufgabe: der Entwickler muss mit einem Testcase, der das Scheitern verursacht hat, durch jede Zeile gehen und das Ergebnis kontrollieren. Ein falsches Ergebnis einer Instruktion hilft den Entwicklern, den Ursprung der Fehler aufzufinden. Das Debugging eines großen Programms ist aber sehr zeitkonsumierend. Darum verwenden die Entwickler oft eine Methode, die slice computing genannt wird. Hier wird versucht, den Fehler so zu lokalisieren, dass man von der betroffener Stelle rückwärts geht. Beim betrachten aller Statements, die die betroffene Stelle (wo der fehlerhafte Wert aufgetreten ist) beeinflussen, kann der Entwickler dann den Ursprung lokalisieren. Diese Methode kann den Entwickler helfen, sich nur auf den wichtigsten Teil des Programms zu konzentrieren. Obwohl diese Techniken den Programmierer bei der Fehlersuche helfen können, gibt es viele Aspekte des Prozesses, die noch verbessert werden könnten. 2

4 Eine Technik, die das Auffinden von Fehlerursprüngen automatisieren oder teilweise automatisieren würde, könnte das manuelle Aufsuchen deutlich verbessern. Die Tools fokussieren den Programmierer oft nur auf eine lokale Sicht und verbergen damit einen Fehler in der Infrastruktur. Ein Prozess, der eine globale Sicht gibt aber auch eine lokale ermöglichen würde, würde den Programmierern viele bedeutsame und reiche Informationen vermitteln. Oft verwenden die Tools nur das Ergebnis einer Programminstruktion, anstelle die Information von mehreren Programminstruktionen zu verwenden. Ein Tool, das den Programmierer mit dieser Information versorgen würde, würde ihm ermöglichen, komplexere Relationen im Programm zu verstehen. Aber mit eine solcher Einstellung wird bei großen und sehr fehlerhaften Programme eine große Menge von Daten erzeugt, die im Text nicht übersichtlich dargestellt werden können. In diese Arbeit werden diverse Techniken diskutiert, die Software- und Datenvisualisierung verwenden, um den Entwicklern bei der Fehlerlokalisierung zu helfen. Wir werden kurz ein Visualisierungstool TARANTULA und eine UML basierte Methode beschreiben und miteinander vergleichen. Dazu werden wir noch eine end-user Fehlerlokalisierungsmethode für Spreadsheetprogramme erörtern. Färbungstechniken Um Fehler zu finden muss man zuerst viele Testfälle schreiben und mit diesen das Programm testen. Das Ergebnis ist eine große Menge von Daten, die verarbeitet werden. Zusammen wird es benutzt, um Fehler zu suchen und zu beheben. Oft enthalten die Daten auch die Erschöpfung von Testfällen. Wenn es noch Stellen gibt, die nie durchgeführt wurden, müssen noch weitere Testfälle erzeugt werden. Die einfachste Methode ist es, einfach zu zählen wie oft eine Zeile (oder Funktion) ausgeführt wurde. Fehlerhafte und erfolgreiche Testfälle werden separat gezählt. Jeder Zeile wird dann eine Farbe zugeordnet. Das einfache Color-Mapping färbt Zeilen grün, 3

5 die nur bei erfolgreichen Testfällen ausgeführt wurden; rot, die nur bei fehlerhaften Testfällen ausgeführt wurden; und gelb alle andere, die bei beiden Testfällen durchgeführt wurden, [Jones et al 2003]. In Abbildung 1 zeigen wir ein Beispiel für ein einfaches Programm, das die mittlere Zahl von drei Zahlen ausgeben sollte. Der Fehler liegt in Zeile 7 (m sollte gleich x sein). mid() { Test Cases int x,y,z,m; 3,3,5 1,2,3 3,2,1 5,5,5 5,3,4 2,1,3 1: Read( Enter 3 numbers:,x,y,z) X X X X X X 2: m=z; X X X X X X 3: if (y<z) X X X X X X 4: if (x<y) X 5: m=y; X 6: else if (x<z) X X X 7: m=y; X X 8: Else X X X 9: if (x>y) X 10: m=y; X 11: else if (x>z) 12: m=x; 13: printf( Middle number is:,m); X X X X X X } Pass/Fail Status P P P P P F Abbildung 1: Gefärbt mit diskreter-drei-farbe Methode [Jones et al 2003]. Es hat 6 Testfälle, die in rechter Seite angezeigt sind. Die Testfalleingabe ist oben dargestellt und mit X sind alle Zeilen markiert, die bei jener Eingabe durchgeführt werden. Die letzte Zeile der Tabelle zeigt, ob der Testfall erfolgreich (P) oder fehlerhaft (F) war. Diese Einstellung wird auch diskrete Methode genannt. Leider, wie man schon auf dem Beispiel sieht, ist diese Methode nicht sehr informativ. Weil das Beispiel größtenteils gelb ist, gibt es auch keine Hinweise, wo der Fehler liegt. In [Jones et al 2003] wird noch eine Methode beschrieben. Diese Methode verwendet eine viel reichere Visualisierung. Es gibt den Analytiker viel mehr Information 4

6 und damit erleichtert es die Fehlersuche. Die Farbabbildung basiert auf einem stetigen Übergang von verschiedenen Farbtönen und Helligkeiten, um anzuzeigen, wie die Statements bei verschiedenen Testfällen partizipieren. Sie wird stetige Einstellung genannt. Der erste Bestandteil der Visualisierung ist die Farbe. Der Farbton repräsentiert die Information über den Prozentsatz von erfolgreichen Testfällen, die das Statement ausführt, im Vergleich zu fehlerhaften Testfällen, die das Statement ausführt. Ye mehr erfolgreiche bzw. fehlerhafte Testfälle das Statement ausführt, desto grüner bzw. roter wird es gefärbt. Wird es ungefähr gleich ab ausgeführt, dann wird der Farbton näher zur gelber Farbe sein. Die Absicht ist, dass die Stellen, durch die mehr als ein fehlerhafter Testfall gegangen ist, den Programmierer auf diese Stelle mehr aufmerksam machen sollte. Der Farbton wird folgender Weise berechnet: color = low color (red) + %passed (s) %passed (s) + %failed (s) * color range (1) In Gleichung (1) ist %passed (s) eine Funktion, die das Verhältnis zwischen der Anzahl von erfolgreichen Testfällen, die durch s gegangen sind, und der Anzahl von allen erfolgreichen Testfällen zurück gibt. %failed (s) ist ähnlich definiert, nur für fehlerhafte Testfälle. low color (red) ist der Wert von der Farbe mit niedrigstem Spektrum, also rot. color range ist die absolute Entfernung zwischen der niedrigste Farbe (rot) und die höchste Farbe (grün); der Wert von grün minus den Wert von rot. Der zweite Bestandteil der Visualisierung ist die Helligkeit. Die Technik in [Jones et al 2003] verwendet die Helligkeit, um den Prozentsatz von durchgeführten Testfällen deutlich zu machen. Erfolgreiche Testfälle werden separat von fehlerhaften Testfällen kalkuliert. Danach wird der höhere Wert genommen. Ye mehr erfolgreiche bzw. fehlerhafte Testfälle durch das Statement s gehen, desto heller wird das Statement markiert. Die maximale Helligkeit ist erreicht, wenn alle erfolgreiche (bzw. fehlerhafte) Testfälle das Statement ausgeführt haben. Das Ziel ist, dass je öfter ein Statement 5

7 durchgeführt wird, umso größer die Wahrscheinlichkeit wird, dass das Statement einen Fehler bzw. keinen Fehler enthält. Die Helligkeit ist ein Beleg für die Korrektheit des Farbtons. Der Helligkeitsgrad wird in folgender Weise kalkuliert: bright (s) = max (%passed (s), %failed (s)) (2) Die Funktionen %passed (s) und %failed (s) sind die selben wie in Gleichung (1). Gleichung (2) berechnet die Mitwirkung von Statement in dem Testprozess. Die Verwendung der stetigen Methode ist vielversprechender als die der diskreten Methode. Den Unterschied sehen wir in Abbildung 2 (die Farben haben nicht die richtige Farbtöne und Helligkeiten, wegen einer kleinen Farbpalette). mid() { Test Cases int x,y,z,m; 3,3,5 1,2,3 3,2,1 5,5,5 5,3,4 2,1,3 1: Read( Enter 3 numbers:,x,y,z) X X X X X X 2: m=z; X X X X X X 3: if (y<z) X X X X X X 4: if (x<y) X 5: m=y; X 6: else if (x<z) X X X 7: m=y; X X 8: Else X X X 9: if (x>y) X 10: m=y; X 11: else if (x>z) 12: m=x; 13: printf( Middle number is:,m); X X X X X X } Pass/Fail Status P P P P P F Abbildung 2: Zeigt das Auswirken der stetigen Methode auf dieses Beispiel (rot ist orange und dunkelrot ist orange-rot). 6

8 Durch Anwendung der stetige Methode, wurden die Zeilen 1-3 und 13 als gelb; 4-5 und 9-10 als dunkle grün; 8 als helle grün; 6 als orange; und Zeile 7 als orange-rot markiert. Diese Präsentation färbt die potentiellen (und aktuellen) Fehler im Programm deutlicher als die diskrete Einstellung. Code Visualisierung In Abbildungen 1 und 2 haben wir eine effiziente Farbtechnik vorgestellt. Diese Technik lässt den Programmierer alle wichtige Informationen des Testens leicht erfassen. Dennoch fehlt ein Überblick über das ganze Programm. Große Programme würden für diese Visualisierung zu viele Seiten brauchen und nicht übersichtlich bleiben. Darum wird in [Jones et al 2003] eine Visualisierungstechnik vorgestellt, die es ermöglicht, die Menge von Daten übersichtlich darzustellen. Es basiert auf der Annahme, dass der Entwickler während der globalen Suche nach Fehlern, den Source-code nicht braucht. Erst wenn die wichtige (rote) Stelle gefunden ist, inspiziert er den Source-code. Im globalen Überblick werden darum die Source-code Zeilen als eine horizontale Linie von Pixels repräsentiert. Um das noch übersichtlicher zu machen, ist die Länge der Linie proportional zu der Länge der Source-code Zeile. Farbe kann dann mit verschiedenen Methoden (diskrete, stetige,...) berechnet werden. Ein Tool, genannt TARANTULA, präsentiert die Daten mit dieser Strategie. Ein Beispiel ist in Abbildung 3 dargestellt. 7

9 Abbildung 3: TARANTULA, visualiziert mit diskreter Methode. Der Source-code ist in der Mitte dargestellt, eine detaillierte Abbildung von Sourcecode unten links und die Testfalleinformation über dieses Statement unten. Mit der Maus selektiert man im Hauptfenster die Stelle, über die man mehr wissen möchte. Außerdem kann man mit Radiobutton aus verschiedenen Visualisierungstechniken wählen. Als Default wird der Source-code ohne Färbung angezeigt. Um noch größere Programme präsentieren zu können, hat das Tool eine Option, die Visualisierung auf der Ebene der Prozeduren zu berechnen. Die Farbe der Prozedur wird das röteste Statement in der Prozedur sein. Visualisierung mit UML Die Arbeit [Jacobs&Musiall 2003] stellt eine andere Art der Visualisierung vor. Sie fokussiert mehr auf das Verstehen von Prozessen und deren Abläufen in verteilten Systemen. Die Visualisierungstechnik erfasst die Beziehungen und Abhängigkeiten zwischen Prozessen und Daten. Programmverständnis wird durch Verbinden des 8

10 Programmflusses auf wohlbekannte Modelle des Systems erhöht. Durch Visualisierung des Programms auf verschiedenen abstrakte Ebenen, kann der Entwickler unnötige Information verstecken, bis er diese braucht. Dann kann er auf eine detailliertere Ebene wechseln. Animationen und Farben helfen, die dynamische Natur eines Systems, wie Methodenaufrufe oder Zustandsänderungen, zu präsentieren. Nach [Jacobs&Musiall 2003] sollte eine Visualisierungstechnik folgende Kriterien erfüllen. Scope bessere Visualisierungsmethoden präsentieren ein großes Ausmaß von Daten (Source-code, Abläufe, Programmverhalten, usw.) Abstraktion Diese Techniken sollen auch viele (aber nicht zu viele) verschiedene Ansichten und mehrere Abstraktionsebenen, von der Infrastrukturebene bis zum Code, haben. Spezifikationsmethoden Ermöglichen dem Benutzer eine ausreichende Freiheit, Inhalte anders zu präsentieren. Sie sollten mit minimaler Anstrengung des Benutzers wirken und dennoch eine große Flexibilität haben. Interface Schnittstellen sollten intuitiv (direkte Manipulation) und einfach zu verstehen sein. Präsentation Die Präsentationssemantik sollte hinreichend abstrakt und mächtig sein, um die kognitive Last des Benutzers zu reduzieren. Die Visualisierung sollte nicht den Programmablauf stören. Sie sollte keine irreführende Semantik haben, die zu einer falschen Interpretation führen würde. Als die am besten geignette Modellrepräsentation wurde UML gefunden. Diese Sprache ist wohl bekannt, überall verwendet und einfach zu verstehen. Ein Vorteil ist, dass sie oft in Analyse, Entwurf und Design für Repräsentationen verwendet wird, also die Entwickler sind damit oft schon vertraut. 9

11 Objektdiagramm Das Klassendiagramm ist das meist benutzte UML Modell. Grafisch wird hier eine Klasse durch ein Rechteck dargestellt, wobei Klassenname, Eigenschaften und Funktionen durch eine Linie voneinander getrennt sind. Die Beziehungen zwischen Klassen werden mit einer Linie dargestellt. Es ist nicht ungewöhnlich, dass sich ein System aus mehreren hundert Klassen bildet. Analyse und Verständnis solcher Systeme benötigen beides: eine höhere Ebene von Überblick der Systemstruktur, wie auch eine detaillierte Untersuchung von individuellen Klassencharakteristiken; UML-Klassendiagramme sorgen dafür. [Jacobs&Musiall 2003] führt ein Tool vor, das aus ArgoUML [ArgoUML 2002] gebildet wurde. UML-Objektdiagramme wurden für die Repräsentation von Objekten und Beziehungen einer Javaapplikation entwickelt. Java Programm Information wird von Java Virtual Machine extrahiert. Dafür wird das Java Plattform Debugging Architektur (JPDA) benutzt. Wann immer ein neues Objekt in der Applikation erzeugt wird, werden alle wichtige Daten extrahiert und das Objektdiagramm wird aktualisiert. Während des Ablaufs der Applikation wird das aktive Objekt im Objektdiagramm zum höchstem Detailgrad expandiert und die aktive Methode wird markiert. Auf diese Weise kann man beobachten, wie die Objekte zusammenarbeiten. In einer größeren Applikation sind aber mehrere hundert potentiell aktive Objekte. Die Präsentation würde dafür viele Seiten brauchen, was die Navigation des Programmierers in dem Visualisierungssystem fast unmöglich machen würde. Außerdem verliert das System die Möglichkeit, die Architektur der Applikation und die Detailinformationen der Klassen dem Programmierer auf einmal zu präsentieren. Damit verhindert es das Verstehen von Beziehungen, die wichtig für das Verständnis der Einflüsse der Programmänderungen sein können. Um das zu verhindern, wurde eine Version der UML gebaut, die seine Symbole und Semantik behält, aber die Raumeffizienz verbessert. Eine fisheye lens wurde entwickelt, die weniger Informationen für Komponenten mit kleinerem Interessensgrad zeigt. Außerdem wird eine selektive Aggregationstechnik verwendet, um alle Komponenten mit Interessensgrad unter einem bestimmten Wert zu verstecken. Dazu wird noch ein 10

12 Algorithmus verwendet, der die graphische Anordnung verbessert, um die Hierarchie und Beziehungen zwischen Klassen hervorzuheben. Interessensgrad Die graphische Komponenten wurden geändert, um sechs Detailebenen (level of detail - LOD) zu kreieren. LOD 0 enthält den höchsten Detailgrad. Die UML-Klassenrepräsentation enthält den Klassennamen, sowie die Namen von allen Attributen und Methoden mit Typ Information. Klasse 0 Attribut0: int Attribut1: String Methode0():void Methode1():String LOD 1 versteckt den Attributtyp und den zurückgegebenen Typ der Methode. Klasse 0 Attribut0 Attribut1 Methode0(): Methode1(): LOD 2 zeigt nur den Namen der Klasse in einem kleineren Font. Klasse 0 LOD 3 versteckt alle Textinformationen und deutet nur auf die Präsenz der Klasse. 11

13 LOD 4 wie LOD 3, nur kleiner. LOD 5 versteckt die ganze Komponente. Der Detailgrad einer Klasse im Objektdiagramm wird mit Hilfe der degree of interest (DOI) Funktion berechnet. Die Funktion basiert auf der Zugriffsfrequenz der Klasse und der Distanz der Klasse von der Klasse, die ist gerade im Fokus. DOI = log 2 (freq) + (max_visible_doi - dist) (3) In dieser Gleichung ist freq der Anzahl der Benutzerzugriffe auf die Klasse; dist ist die graphische Distanz von der Klasse zum Fokalpunkt in Diagramm und max_visible_doi ist der maximale DOI, für den die Klasse noch sichtbar ist. Ein Vergleich von klassischer UML und ein mit DOI entstandenes Diagramm ist in Abbildung 4 gezeigt. Das Beispiel zeigt, wie UML mit DOI Platz spart. In dieser Abbildung ist Klasse0 der Fokalpunkt des Objektdiagramms und wird damit mit LOD0 dargestellt. Klasse1 ist eine Link vom Fokalpunkt entfernt; also hat sie ein DOI weniger als der Fokalpunkt LOD1. Ähnliches gilt für den DOI der Klasse2, Klasse3 und Klasse4. Immer wenn auf die Komponente zugegriffen wird, wird DOI wieder neu kalkuliert und das Diagramm aktualisiert. Wenn eine Komponente aktiv wird, wird sie temporär mit LOD 1 dargestellt, um den aktuellen Programmlauf hervorzuheben. Sollte das Programm in ein verstecktes Objekt springen, dann werden alle Komponenten zwischen Fokalpunkt und diesem Objekt mit LOD 4 dargestellt. 12

14 Klasse0 Klasse1 Klasse2 Klasse3 newatr: int newatr: int newatr: int newatr: int Methode(): void Methode(): void Methode(): void Methode(): void Klassisches Objektdiagramm Klasse4 newatr: int Methode(): void Klasse0 newatr: int Methode(): void Klasse1 newatr Methode(): Klasse2 Objektdiagramm nach Applikation von DOI Funktion Abbildung 4: Objektdiagramme. Generalisation und Aggregation Generalisation und Aggregation sind ein wichtiger Aspekt des objektorientierten Softwaresystems. Diese sind hierarchische Beziehungen. Die Generalisationsbeziehung verbindet eine generelle Klasse zu einer oder mehreren Klassen, die die Attribute der generellen Klasse erben. Ähnlich verknüpft Aggregation eine Containerklasse zu einer oder mehreren Klassen, die die Bestandteile repräsentieren, die in der Containerklasse kombiniert sind. Diese hierarchische Beziehungen sind gute Kandidaten für selektive Aggregationstechniken, die Klassen mit niedrigerer Hierarchie verstecken. Zum Beispiel hat es nicht viel Zweck zu zeigen, dass ein Auto aus Räder und Motor besteht, wenn der Benutzer nur daran interessiert ist, ob dort überhaupt ein Auto ist. In der Arbeit [Jacobs&Musiall 2003] wird auch ein Model mit selektive Aggregationstechnik beschrieben. Wiederum werden für Repräsentationen von Generalisationen und Aggregationen dieselbe Assoziationen verwendet wie in UML. Um zu indizieren, dass Klassen versteckt sind, wird die passende Symbolik für Aggregation oder Generalisation noch gezeigt, aber die Klasse mit niedrigerem Hierarchiegrad bleibt 13

15 versteckt. Abbildung 5 zeigt ein Beispiel vor und nach Verwendung von selektiver Aggregationstechnik. Nach Applikation von selektiver Aggregationstechnik Ein Teil eines Klassensdiagramms Abbildung 5: Selektive Aggregationstechnik. Eine Link mit kleinem Dreieck (Pfeilspitze) stellt eine Vererbungsbeziehung dar und eine Link mit einem Diamant am Ende symbolisiert eine Aggregationsbeziehung. Die kleinen Symbole stehen immer mit der Klasse mit höherer Priorität in Beziehung. Nach der Anwendung von selektiver Aggregationstechnik bleibt das kleine Dreieck, Diamant und eine kurze Linie sichtbar, um hinweisen, dass die versteckte Klasse diese Beziehung mit der sichtbare Klasse hat. Abbildung 6 zeigt ein Klassendiagramm vor und nach Anwendung der DOI- Funktion und der selektiven Aggregationstechnik. 14

16 Abbildung 6: Klassendiagramme vor und nach Komprimierung. Durch Applikation dieser Visualisierungstechniken ist es also möglich, ein größeres Klassendiagramm einer Applikation zu betrachten. Damit zeigt dieses Modell die gesamte Struktur und die Beziehungen zwischen einzelnen Instanzen der Applikation erfolgreich auf. End-User Techniken Bisher haben wir Software Visualisierungen nur als Hilfsmittel für die Fehlerlokalisation für professionelle Programmierer betrachtet. Der Anzahl von End-User Programmierumgebungen steigt und im Jahr 2005 werden voraussichtlich 55 Millionen. End-User Programmierer im Vergleich zu 2,75 Millionen professionellen Programmierern sein. Es gibt viele diverse End-User Umgebungen, aber als das meist verbreitete könnte man Spreadsheets zählen. Trotz der wahrgenommenen Einfachheit von dieser Art von End-User Programmierung, fabrizieren End-User Programmierer eine große Anzahl von Fehlern. 15

17 Um dieses Problem zu lösen und den End-Usern zu helfen die Anzahl von Fehlern zu minimieren, beschreiben die Autoren von [Ruthruff et al 2003] verschiedene Techniken. Die Autoren beschreiben eine Methodologie bekannt als What you see is what you test (WYSIWYT). Diese Methodologie teilt den End-Usern das testedness (aktueller Testgrad) von jeder Spreadsheetzelle durch inkrementelle low-cost Visualisierungsgeräte mit, wie z.b. Randfarbe. Es reagiert auf die Aktionen von Benutzern und nach jeder Änderung, werden die Visualisierungsgeräte aktualisiert. Wenn der Benutzer erkennt, dass der Wert in einer Zelle korrekt ist, kann er diese Zelle in eine Checkbox gleich neben als korrekt markieren. Als eine Antwort darauf werden die Visualisierungen auf drei Ebenen aktualisiert. Die Ebene von Zellen zeigt den Checkmarker, dass dieser Wert ein Ergebnis von erfolgreichem Test ist. Die Farbe des Zellenrandes von allen Zellen, die zu dem Wert beitragen, wechselt stetig von einer roter Farbe (nicht getestet) auf eine blaue Farbe (getestet). Wenn der Benutzer die Datenflüsse sehen möchte, werden diese als Pfeile in der Farbe der Zelle, auf die sie zeigen, dargestellt. Das testedness von dem Spreadsheet wird immer als ein Prozentsatz sichtbar. Es wird mit einer Methode dataflow-test-adequacy-criterion [Laski&Korel1993] berechnet. Ein adequacy-criterion setzt einen Standard, der definiert, wenn ein Produkt voll getestet ist. Welche Methoden sollen aber angewandt werden, um den Benutzer beim Fehlerorten helfen können, und die dabei schnell genug sind, um dem End-User nach jeder Aktion eine schnelle Visualisierungsantwort geben können? Fehlerlokalisierungstechniken in End-User Programmen Während einer inkrementelle Entwicklung des Spreadsheets, kann ein Benutzer nach seiner Beobachtung von einem Fehler die Zelle markieren. In diesem Moment sollte das System auf diese Aktion reagieren. Am meisten ändert sich die Farbe des Zellenrands. Dabei sollten alle Zellen, die zu diesem Fehler auch beitragen könnten, dem Benutzer mit einer Farbänderung eine visuelle Hilfe über mögliche Fehlerursprünge geben. In [Ruthruff et al 2003] werden drei Techniken vorgestellt. 16

18 Test-Count Technik (ähnlich zu der Technik, die in TARANTULA benutzt wurde) Blocking Technik Nearest Consumers Technik Die Test-Count Technik Diese Technik stellt die Fehlerwahrscheinlichkeit von Zellen, basierend auf der Anzahl der erfolgreichen Tests (markiert als richtig) gegen die Anzahl von fehlerhaften Testen (markiert als falsch) in denen die Zelle partizipiert hat, dar. Die Test-Count Technik verwendet die Information über erfolgreiche und fehlerhafte Tests um diese Eigenschaften zu halten: 1. Wenn eine Zelle Z oder irgendein Verbraucher (Zelle, die verwendet den Wert von Z) hat den Test nicht erfolgreich überstanden, dann wird Z eine nicht null Fehlerwahrscheinlichkeit. 2. Die Fehlerwahrscheinlichkeit von Z ist proportional zu der Anzahl von fehlerhaften Tests. 3. Die Fehlerwahrscheinlichkeit von Z ist umgekehrt proportional zu der Anzahl von erfolgreichen Tests. Um diese Eigenschaften zu implementieren wird die Gleichung 4 verwendet. Fehlerwahrscheinlichkeit = max( 1, 2*NFT NST ) (4) In Gleichung 4 ist NFT (NumFailingTests) die Anzahl von fehlerhaften Tests und NST (NumSuccessfulTests) die Anzahl von erfolgreichen Tests. Das Ergebnis ist abgebildet auf vier mögliche Wahrscheinlichkeitsskalen: 1-2 niedrige Fehlerwahrscheinlichkeit (FW), 3-4 mittlere FW, 5-9 hohe FW, und 10- sehr hohe FW. Jeder Skala ist dann eine Farbe zugeordnet, blau oder grün als die niedrigste und rot als die höchste FW. 17

19 Die Blocking Technik Diese Technik in Addition zur Test-Count hat eine Skala mehr; sehr niedrig. Es basiert auf den Beobachtungen der Beziehungen zwischen Zellen, die zur Wert der Zelle Z beitragen (Produzenten von Z) und den Verbrauchern von Z. Sie hat also zwei weitere Eigenschaften: 4. Eine Markierung von falschem Wert in Zelle Z blockiert den Effekt von weitern Checkmarkierungen in Verbrauchern von Z auf Produzenten von Z. 5. Eine Markierung von richtigem Wert in Z blockiert den Effekt von Falschmarkierten Verbrauchern von Z auf Produzenten von Z. Mit Ausnahme von FW Eigenschaft verwendet in Eigenschaft 1. Implementierung von diesen weiteren Eigenschaften ist viel komplizierterer als die von Test-Count. Es verwendet vier wichtige Funktionen: NumBlockedFailedTests (NBFT) Anzahl von Verbrauchern von Z, die als falsch markiert sind, aber sind blockiert durch einen Wert, markiert als richtig, entlang des Datenflusses zwischen Z und den Wert markiert als falsch. NumReachableFailedTests (NRFT) das Ergebnis der Subtraktion von NBFT von Anzahl den Verbrauchern von Z. NumBlockedSuccessfulTests (NBST) ähnlich wie NBFT. NumReachableSuccessfulTests (NRST) ähnlich wie NRFT. Wenn eine Zelle Z keine fehlerhafte Tests erhält, ist das FW null. Wenn Z auch fehlerhafte Tests hat, aber keine reachable, dann ist FW von Z sehr niedrig. Sonst wird Gleichung (5) verwendet. Fehlerwahrscheinlichkeit = max(1, NRFT NRST/2 ) (5) Die Skala bleibt die gleiche, wie in Test-Count Technik. 18

20 Die Nearest Consumer Technik Um die sich den fünf Eigenschaften annähern, würde eine dritte Technik in [Ruthruff et al 2003] vorgestellt. Es basiert auf einem greedy Verfahren. Es betrachtet nur den direkten Verbrauchern von Z. Die Fehlerwahrscheinlichkeit von Z ist allein durch die Markierung von Z und den mittleren Wert von FW von allen direkten Verbrauchern von Z. Die Produzenten von Z sind dann gleichsam aktualisiert. Nähmen wir an, dass DV ist die Menge allen direkten Verbrauchern von Z. x ist dann die Anzahl von allen Zellen in DC, die als falsch markiert sind und y die Anzahl von allen Zellen in DC die als richtig markiert sind. w = 1 wenn (x>1 und y=0) oder (x>y und y>0) oder (x>y und Z ist als falsch markiert). Sonst ist w null. Die FW ist dann berechnet mit Gleichung 6. Fehlerwahrscheinlichkeit = Durchschnitt FW von DZ + w (6) Es hat aber drei Ausnahmen. Wenn Z markiert als richtig ist, dann es hat automatisch ein FWGrad sehr niedrig. Wenn Z als falsch markiert ist, aber der Durchschnitt FW von DZ ist kleiner als mittlere FW, dann ist Z mit mittlerem FWGrad bezeichnet. Eine Falschmarkierung von Z verbietet die FW von Z und die FW von seinen Produzenten weiter von ihren letzten FW zu steigen. Ergebnisse Techniken Um die Effizienz dieser Techniken erforschen, wurden Experimente [Jones et al 2003, Ruthruff et al 2003] durchgeführt. Die Ergebnisse liefern die Antworten über die Verwendbarkeiten und Robustheiten dieser Techniken. Die Test-Count Technik hat sich als eine sehr gute Methode bewiesen. Drei empirische Studien wurden gemacht. Zwei befassen sich mit der Verwendung in professioneller Programmierumgebung und eine in End-User Spreadsheets. 19

21 In professioneller Umgebung hat sie in meisten Fällen die fehlerhafte Stelle richtig markiert. Nur in 30% der Fälle hat sie ein nichtfehlerhaftes Statement zwischen orange und rot gefärbt. Probleme sind entstanden nur wenn sich der Fehler in Initialisierungscode befunden hat, oder das Programm mehr als ein Fehler enthält hat. Sogar mit Multifehlern hat es sich besser als gewartet verhaltet. Dabei wurde ein Phänomen beobachtet. Bei Multifehlern wurden nicht alle fehlerhafte Statements identifiziert. Nach der Beseitigung von diesen Statements wurden die andere Fehler entdeckt. Was deutet auf ein inkrementelles Verhalten. In Fehlersuche in Spreadsheets wurde sie auch als ein ausgesprochenes Verfahren beobachtet. Außerdem ist sie als die meist robuste Technik bezeichnet worden. Für ein frühzeitiges Feedback ist sie aber nicht geeignet. Als meist effiziente für frühzeitiges Feedback zeigte sich die Blocking Technik zu sein. Nearest Consumer Technik hat sich nicht als sehr gutes und konsistentes Verfahren entwiesen, obwohl sie ziemlich gut in frühzeitigem Feedback gehandelt hat. Visualisierungen In dieser Arbeit haben wir zwei Visualisierungsmethoden erörtert. Eine die wird in TARANTULA verwendet und die UML Visualisierung. Offensichtlich ist UML Visualisierung besser in Visualisierung der Infrastruktur von Programm. Es hat sich mit der entwickelte UML gelangen übersichtlich 75 Klassen im Bildschirm anzuzeigen. Für ein Experiment wurde ein Demoprogramm mit 84 Klassen und mit ungefähr Zeilen von Code benutzt. In diesem Experiment wurde dieses Programm problemlos debuggiert mit einem Überblick auf statische und dynamische Struktur des Programms. Es wurde berechnet, dass für die Visualisierung mit klassischer UML würde das System drei bis vier Seiten brauchen. Visualisierung in TARANTULA wurde nicht getestet, weil es auch nicht das leitende Ziel war. Bei TARANTULA haben sich mehr auf den Färbalgorithmus konzentriert. Dabei ist aber auch diese Visualisierung nicht schlecht, und es kann leicht berechnet werden, wie viel Code wird auf einer Seite angezeigt. Wenn jedes Statement als eine Pixellinie dargestellt ist, ein Bildschirm ungefähr 1000 vertikale Pixellinien hat 20

Visualisierung verteilter Systeme

Visualisierung verteilter Systeme Visualisierung verteilter Systeme End-User Software Visualizations for Fault Localization Referentin Maren Settekorn Die Autoren Margaret M. Burnett, Professorin am Institut für Informatik der Oregon State

Mehr

ActiveCharts. Verknüpfung von Modellen und Code bei der modellgetriebenen Softwareentwicklung mit UML 2.0

ActiveCharts. Verknüpfung von Modellen und Code bei der modellgetriebenen Softwareentwicklung mit UML 2.0 Jens Kohlmeyer 05. März 2007 Institut für Programmiermethodik und Compilerbau ActiveCharts Verknüpfung von Modellen und Code bei der modellgetriebenen Softwareentwicklung mit UML 2.0 Seite 2 Übersicht

Mehr

Unified Modeling Language (UML)

Unified Modeling Language (UML) Kirsten Berkenkötter Was ist ein Modell? Warum Modellieren? Warum UML? Viele, viele Diagramme UML am Beispiel Was ist ein Modell? Ein Modell: ist eine abstrakte Repräsentation eines Systems, bzw. ist eine

Mehr

Visualisierung paralleler bzw. verteilter Programme

Visualisierung paralleler bzw. verteilter Programme Seminar Visualisierung in Informatik und Naturwissenschaften im SS 1999 Visualisierung paralleler bzw. verteilter Programme Holger Dewes Gliederung Zum Begriff Motivation PARADE Beispiel 1: Thread basierte

Mehr

09.01.14. Vorlesung Programmieren. Unified Modeling Language (UML) Unified Modeling Language (UML) Unified Modeling Language (UML)

09.01.14. Vorlesung Programmieren. Unified Modeling Language (UML) Unified Modeling Language (UML) Unified Modeling Language (UML) Vorlesung Programmieren Unified Modeling Language (UML) Prof. Dr. Stefan Fischer Institut für Telematik, Universität zu Lübeck http://www.itm.uni-luebeck.de/people/fischer Unified Modeling Language (UML)

Mehr

Vorlesung Programmieren

Vorlesung Programmieren Vorlesung Programmieren Unified Modeling Language (UML) Prof. Dr. Stefan Fischer Institut für Telematik, Universität zu Lübeck http://www.itm.uni-luebeck.de/people/fischer Unified Modeling Language (UML)

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

Software Engineering, SoSe 07, WSI, D. Huson, (Original Author: A. Zeller), 4. Juni 2007 45

Software Engineering, SoSe 07, WSI, D. Huson, (Original Author: A. Zeller), 4. Juni 2007 45 Software Engineering, SoSe 07, WSI, D. Huson, (Original Author: A. Zeller), 4. Juni 2007 45 7 Programmverstehen + Fehlersuche Nach einer Vorlesung von Prof. Andreas Zeller, Lehrstuhl Softwaretechnik Universität

Mehr

Datenvisualisierung mit JMP

Datenvisualisierung mit JMP Datenvisualisierung mit JMP Patrick René Warnat HMS Analytical Software GmbH Rohrbacherstr. 26 Heidelberg patrick.warnat@analytical-software.de Zusammenfassung Das JMP Paket ist ein Softwareprodukt der

Mehr

Projektmodell Softwareentwicklung: Unified Software Development Process / Unified Process (Teil I)

Projektmodell Softwareentwicklung: Unified Software Development Process / Unified Process (Teil I) Projektmodell Softwareentwicklung: Unified Software Development Process / Unified Process (Teil I) Historisch Kulturelle Informationsverarbeitung Hauptseminar: KLIPS 2.0 Dozent: Prof. Dr. Thaller Referent:

Mehr

Diplomarbeit: Visualisierung konzeptioneller Beschreibungen von Programmieraktivitäten. Arbeitsgruppe: Software-Engineering Nicolas Ngandeu

Diplomarbeit: Visualisierung konzeptioneller Beschreibungen von Programmieraktivitäten. Arbeitsgruppe: Software-Engineering Nicolas Ngandeu Diplomarbeit: Visualisierung konzeptioneller Beschreibungen von Programmieraktivitäten Arbeitsgruppe: Software-Engineering Nicolas Ngandeu Gliederung Einführung Visualisierung Die Akteure Die Inputdaten

Mehr

Test-Strategien. Grundsätzliches Blackbox-Testen Whitebox-Testen Graybox-Testen Ablauf von Tests Zusammenfassung. HS Mannheim

Test-Strategien. Grundsätzliches Blackbox-Testen Whitebox-Testen Graybox-Testen Ablauf von Tests Zusammenfassung. HS Mannheim Test- Grundsätzliches - - - Ablauf von Tests Grundsätzliche Test- -Tests Äquivalenzklassenbildung Randwertanalyse -Tests Man unterscheidet verschiedene Überdeckungsgrade: Statement Coverage Decision Coverage,

Mehr

Java Einführung Umsetzung von Beziehungen zwischen Klassen. Kapitel 7

Java Einführung Umsetzung von Beziehungen zwischen Klassen. Kapitel 7 Java Einführung Umsetzung von Beziehungen zwischen Klassen Kapitel 7 Inhalt Wiederholung: Klassendiagramm in UML Java-Umsetzung von Generalisierung Komposition Assoziationen 2 Das Klassendiagramm Zweck

Mehr

Dr. Hanno Schauer Mons-Tabor-Gymnasium Montabaur. UML-Klassendiagramme als Werkzeug im Unterricht

Dr. Hanno Schauer Mons-Tabor-Gymnasium Montabaur. UML-Klassendiagramme als Werkzeug im Unterricht Dr. Hanno Schauer Mons-Tabor-Gymnasium Montabaur UML-Klassendiagramme als Werkzeug im Unterricht Blitzlicht? In welcher Programmiersprache(n) unterrichten Sie?? In welchem Umfang unterrichten Sie Objektorientierung??

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

Java Einführung Umsetzung von Beziehungen zwischen Klassen. Kapitel 7

Java Einführung Umsetzung von Beziehungen zwischen Klassen. Kapitel 7 Java Einführung Umsetzung von Beziehungen zwischen Klassen Kapitel 7 Inhalt Wiederholung: Klassendiagramm in UML Java-Umsetzung von Generalisierung Komposition Assoziationen 2 Das Klassendiagramm Zweck

Mehr

Schlussbewertung FB VI SOFTWAREPROJEKT II WS 09/10 TEAM. Alexander Kalden Dominik Eckelmann Marcel Pierry Julian Heise Besha Taher

Schlussbewertung FB VI SOFTWAREPROJEKT II WS 09/10 TEAM. Alexander Kalden Dominik Eckelmann Marcel Pierry Julian Heise Besha Taher Schlussbewertung FB VI SOFTWAREPROJEKT II WS 09/10 TEAM Alexander Kalden Dominik Eckelmann Marcel Pierry Julian Heise Besha Taher 729631 745097 736477 745011 741297 Inhalt Schlussbewertung... 3 Bewertung

Mehr

Java TV. Seminar Medientechnik. Kristin Doppler 23.06.2003. Übersicht. Einleitung Umgebungen Java TV API - Kategorien. Service- und Selektions-APIs

Java TV. Seminar Medientechnik. Kristin Doppler 23.06.2003. Übersicht. Einleitung Umgebungen Java TV API - Kategorien. Service- und Selektions-APIs Java TV Seminar Medientechnik 23.06.2003 Übersicht Einleitung Umgebungen Java TV API - Kategorien Service- und Selektions-APIs Definitionen Packages Service Selection API Application Lifecycle APIs (Xlets)

Mehr

Inhalt: Version 1.7.5

Inhalt: Version 1.7.5 Inhalt: Objekte ohne Methoden Objekte mit einfachen Methoden Objekte und Methoden mit Parametern Objekte und Methoden mit Rückgabewert Objekte mit einem Array als Attribut Beziehungen zwischen Objekten

Mehr

Programmiersprache 2 (C++) Prof. Dr. Stefan Enderle NTA Isny

Programmiersprache 2 (C++) Prof. Dr. Stefan Enderle NTA Isny Programmiersprache 2 (C++) Prof. Dr. Stefan Enderle NTA Isny 3. UML Klassendiagramm Nachtrag 3.1 Einführung UML UML ist eine standardisierte Sprache zur Modellierung von Systemen. In UML werden graphische

Mehr

WhiteStarUML Tutorial

WhiteStarUML Tutorial WhiteStarUML Tutorial Autor: Simon Balázs, BME IIT, 2015. Übersetzung: Kovács Márton, 2015. Installation Herunterladen und installieren Sie das WhiteStarUML: http://sourceforge.net/projects/whitestaruml/

Mehr

3D Visualisierung von UML Umgebungsmodellen

3D Visualisierung von UML Umgebungsmodellen 3D Visualisierung von UML Umgebungsmodellen Vortragender: Helmer Krämer Betreuer: Dr. Holger Giese 3D Visualisierung von UML Umgebungsmodellen Krämer Seite 1 Motivation und Anforderungen Das Umgebungsmodell

Mehr

Software Engineering. 13. Qualitätssicherung. Franz-Josef Elmer, Universität Basel, WS 2006/07

Software Engineering. 13. Qualitätssicherung. Franz-Josef Elmer, Universität Basel, WS 2006/07 Software Engineering 13. Qualitätssicherung Franz-Josef Elmer, Universität Basel, WS 2006/07 Software Engineering: 13. Qualitätssicherung 2 Qualitätssicherung Qualitätssicherung (engl. Quality Assurance

Mehr

Orientierte Modellierung mit der Unified Modeling Language

Orientierte Modellierung mit der Unified Modeling Language UML-Basics: Einführung in Objekt- Orientierte Modellierung mit der Unified Modeling Language Michael Hahsler Ziel dieses Seminars Verständnis von Objekt-Orientierung Was sind Klassen? Was ist Vererbung?

Mehr

JAVA PROJEKT. Schiffe Versenken mit GUI. Projektheft

JAVA PROJEKT. Schiffe Versenken mit GUI. Projektheft Anwendungspraktikum aus JAVA Programmierung SS 2006 Leitung: Dr. Albert Weichselbraun JAVA PROJEKT Schiffe Versenken mit GUI Projektheft Marija Matejic Matrikelnummer: 9352571 E-mail: marijamatejic@yahoo.com

Mehr

Automatisierte Expertenfindung zur Fehlerbehebung in großen Softwaresystemen

Automatisierte Expertenfindung zur Fehlerbehebung in großen Softwaresystemen Patrick Schlott Fachbereich Informatik Automatisierte Expertenfindung zur Fehlerbehebung in großen Softwaresystemen Automatisierte Expertenfindung zur Fehlerbehebung in großen Softwaresystemen 1 Gliederung

Mehr

Quellen: Towards a Human Computer InteractionPerspective. Übersicht. Warum visuelle Sprachen? Begriffsdefinitionen: Hinderungsgründe bisher:

Quellen: Towards a Human Computer InteractionPerspective. Übersicht. Warum visuelle Sprachen? Begriffsdefinitionen: Hinderungsgründe bisher: Quellen: Towards a Human Computer InteractionPerspective von B.K. & B.K. LV: Visuelle Sprachen (03-763) Universität Bremen WS 2001/02 Visual Language Theory: Towards a Human- Computer Perspective; N. Hari

Mehr

EINFÜHRUNG IN DIE WIRTSCHAFTSINFORMATIK -ÜBUNGEN- Marina Tropmann-Frick mtr@is.informatik.uni-kiel.de www.is.informatik.uni-kiel.

EINFÜHRUNG IN DIE WIRTSCHAFTSINFORMATIK -ÜBUNGEN- Marina Tropmann-Frick mtr@is.informatik.uni-kiel.de www.is.informatik.uni-kiel. EINFÜHRUNG IN DIE WIRTSCHAFTSINFORMATIK -ÜBUNGEN- Marina Tropmann-Frick mtr@is.informatik.uni-kiel.de www.is.informatik.uni-kiel.de/~mtr FRAGEN / ANMERKUNGEN Vorlesung Neue Übungsaufgaben MODELLIERUNG

Mehr

Grundlagen Programmierung

Grundlagen Programmierung 13. Aufgabe (13 Punkte) Schreiben Sie eine neue Klasse Zahlenanalyse, mit der Integer-Objekte genauer betrachtet werden können. Bei den zu entwickelnden Methoden kann es immer sinnvoll sein, sich den Ablauf

Mehr

Rhapsody in J Modellierung von Echtzeitsystemen

Rhapsody in J Modellierung von Echtzeitsystemen Rhapsody in J Modellierung von Echtzeitsystemen Tobias Schumacher tobe@uni-paderborn.de Rhapsody in J - Modellierung von Echtzeitsystemen p.1/17 Anspruch des Tools Einsatzbereiche/Features Modellierung

Mehr

Datenvisualisierung mit JMP

Datenvisualisierung mit JMP Lehre Datenvisualisierung mit JMP Patrick René Warnat HMS Analytical Software GmbH Rohrbacherstr. 26 Heidelberg patrick.warnat@analytical-software.de Zusammenfassung Das JMP Paket ist ein Softwareprodukt

Mehr

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

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

Mehr

Kontextdiagramm Erstellen von Kontextdiagrammen mit TopEase

Kontextdiagramm Erstellen von Kontextdiagrammen mit TopEase Kontextdiagramm Erstellen von Kontextdiagrammen mit TopEase Version Control: Version Status Datum / Kurzzeichen 1.0 Begründung Copyright: This document is the property of Business-DNA Solutions GmbH, Switzerland.

Mehr

UML Klassendiagramm. Igor Karlinskiy, Mikhail Gavrish

UML Klassendiagramm. Igor Karlinskiy, Mikhail Gavrish UML Klassendiagramm Igor Karlinskiy, Mikhail Gavrish Agenda Wichtigste Eigenschaften Syntaktische Elemente mit entsprechendem C++ Code Analysemodell Designmodell Quellen 2 Klassendiagramm gibt die Möglichkeit,

Mehr

Eine Klasse beschreibt Objekte mit gleichen Attributen und Methoden.

Eine Klasse beschreibt Objekte mit gleichen Attributen und Methoden. Grundwissen Informatik Objekt Attribut Methoden Als Objekte bezeichnet man alle Gegenstände, Dinge, Lebewesen, Begriffe oder Strukturen unserer Welt ( Autos, Räume, Bakterien, Lehrer, Schüler, Kunden,

Mehr

Objektorientierte Programmierung. Kapitel 3: Syntaxdiagramme und Grammatikregeln

Objektorientierte Programmierung. Kapitel 3: Syntaxdiagramme und Grammatikregeln Stefan Brass: OOP (Java), 3. Syntaxdiagramme und Grammatikregeln 1/32 Objektorientierte Programmierung Kapitel 3: Syntaxdiagramme und Grammatikregeln Stefan Brass Martin-Luther-Universität Halle-Wittenberg

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

Semantik-Visualisierung

Semantik-Visualisierung Semantik-Visualisierung Wibaklidama-Herbstworkshop Kawa Nazemi Fraunhofer IGD 3D-Wissenswelten und Semantik-Visualisierung Semantic Visualization semavis: Pipelines Visualization Semantics Layout Presentation

Mehr

Objektorientierte Programmierung

Objektorientierte Programmierung Objektorientierte Programmierung 1 Geschichte Dahl, Nygaard: Simula 67 (Algol 60 + Objektorientierung) Kay et al.: Smalltalk (erste rein-objektorientierte Sprache) Object Pascal, Objective C, C++ (wiederum

Mehr

iphone app - Anwesenheit

iphone app - Anwesenheit iphone app - Anwesenheit Anwesenheit - iphone App Diese Paxton-App ist im Apple App Store erhältlich. Die App läuft auf allen iphones mit ios 5.1 oder höher und enthält hochauflösende Bilder für Geräte

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

Allerdings ist die Bearbeitung von Standardobjekten vorerst eingeschränkt. Wir wollen uns dies im folgenden Beispiel genauer betrachten.

Allerdings ist die Bearbeitung von Standardobjekten vorerst eingeschränkt. Wir wollen uns dies im folgenden Beispiel genauer betrachten. 7. KURVEN UND KNOTEN INFORMATION: Sämtliche Objekte bestehen in CorelDRAW aus Linien oder Kurven. So ist ein Rechteck ein Gebilde aus einem Linienzug, ein Kreis hingegen besteht aus einer Kurve. Zum Bearbeiten

Mehr

4. AuD Tafelübung T-C3

4. AuD Tafelübung T-C3 4. AuD Tafelübung T-C3 Simon Ruderich 17. November 2010 Arrays Unregelmäßige Arrays i n t [ ] [ ] x = new i n t [ 3 ] [ 4 ] ; x [ 2 ] = new i n t [ 2 ] ; for ( i n t i = 0; i < x. l e n g t h ; i ++) {

Mehr

Vererbung & Schnittstellen in C#

Vererbung & Schnittstellen in C# Vererbung & Schnittstellen in C# Inhaltsübersicht - Vorüberlegung - Vererbung - Schnittstellenklassen - Zusammenfassung 1 Vorüberlegung Wozu benötigt man Vererbung überhaubt? 1.Um Zeit zu sparen! Verwendung

Mehr

Inhalt. 1. Sprachspezifische Fehlerrisiken C++ Java. Smalltalk. 2. Coverage - Modelle. Statement Coverage. Branch Coverage

Inhalt. 1. Sprachspezifische Fehlerrisiken C++ Java. Smalltalk. 2. Coverage - Modelle. Statement Coverage. Branch Coverage Inhalt 1. Sprachspezifische Fehlerrisiken C++ Java Smalltalk 2. Coverage - Modelle Statement Coverage Branch Coverage Inkrementelles Testen von Klassen Testen Polymorpher Bindungen Optimistischer Ausblick

Mehr

Softwaretechnik (Allgemeine Informatik) Überblick

Softwaretechnik (Allgemeine Informatik) Überblick Softwaretechnik (Allgemeine Informatik) Überblick 1 Einführung und Überblick 2 Abstraktion 3 Objektorientiertes Vorgehensmodell 4 Methoden der Anforderungs- und Problembereichsanalyse 5 UML-Diagramme 6

Mehr

Kapitel 6. Vererbung

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

Mehr

Prinzipien Objektorientierter Programmierung

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

Mehr

Einführung in die Informatik

Einführung in die Informatik Einführung in die Informatik Jochen Hoenicke Software Engineering Albert-Ludwigs-University Freiburg Sommersemester 2014 Jochen Hoenicke (Software Engineering) Einführung in die Informatik Sommersemester

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

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

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

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

Mehr

Universität Augsburg, Institut für Informatik Sommersemester 2005 Prof. Dr. Werner Kießling 15. Oktober 2005 Dr. Alfons Huhn, Timotheus Preisinger

Universität Augsburg, Institut für Informatik Sommersemester 2005 Prof. Dr. Werner Kießling 15. Oktober 2005 Dr. Alfons Huhn, Timotheus Preisinger Universität Augsburg, Institut für Informatik Sommersemester 2005 Prof. Dr. Werner Kießling 15. Oktober 2005 Dr. Alfons Huhn, Timotheus Preisinger Informatik II Hinweise: Die Bearbeitungszeit beträgt 90

Mehr

Proseminar: Website-Managment-System. NetObjects Fusion. von Christoph Feller

Proseminar: Website-Managment-System. NetObjects Fusion. von Christoph Feller Proseminar: Website-Managment-System NetObjects Fusion von Christoph Feller Netobjects Fusion - Übersicht Übersicht Einleitung Die Komponenten Übersicht über die Komponenten Beschreibung der einzelnen

Mehr

Software Engineering in der Praxis

Software Engineering in der Praxis Inhalt Nachlese Aufgaben Literatur Software Engineering in der Praxis Praktische Übungen Inhalt Nachlese Aufgaben Literatur Marc Spisländer Dirk Wischermann Lehrstuhl für Software Engineering Friedrich-Alexander-Universität

Mehr

Klassendiagramm. (class diagram)

Klassendiagramm. (class diagram) : Klassendiagramm http:///topic95.html Klassendiagramm (class diagram) Klassendiagramm Objektdiagramm Komponentendiagramm Kompositionsstrukturdiagramm Verteilungsdiagramm Einstieg Paketdiagramm Aufbau

Mehr

Standardisieren Sie die manuelle Differenzierung in Ihrem Labor

Standardisieren Sie die manuelle Differenzierung in Ihrem Labor Standardisieren Sie die manuelle Differenzierung Einleitung Die Interpretation von Ausstrichen peripheren Bluts spielt eine große Rolle bei der Diagnose hämatologischer Krankheiten und stellt daher eine

Mehr

Drei-Schichten-Architektur. Informatik B - Objektorientierte Programmierung in Java. Vorlesung 16: 3-Schichten-Architektur 1 Fachkonzept - GUI

Drei-Schichten-Architektur. Informatik B - Objektorientierte Programmierung in Java. Vorlesung 16: 3-Schichten-Architektur 1 Fachkonzept - GUI Universität Osnabrück Drei-Schichten-Architektur 3 - Objektorientierte Programmierung in Java Vorlesung 6: 3-Schichten-Architektur Fachkonzept - GUI SS 2005 Prof. Dr. F.M. Thiesing, FH Dortmund Ein großer

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

Programmieren von Web Informationssystemen

Programmieren von Web Informationssystemen Programmieren von Webinformationssystemen Wolfgang Gassler Databases and Information Systems (DBIS) Institute of Computer Science University of Innsbruck dbis-informatik.uibk.ac.at 1 Web (App) Usability

Mehr

Software Engineering Klassendiagramme Einführung

Software Engineering Klassendiagramme Einführung Software Engineering Klassendiagramme Einführung Prof. Adrian A. Müller, PMP, PSM 1, CSM Fachbereich Informatik und Mikrosystemtechnik 1 Aufgabe Erstellen Sie eine Klasse Person in Java. Jede Person verfügt

Mehr

Erstellen von x-y-diagrammen in OpenOffice.calc

Erstellen von x-y-diagrammen in OpenOffice.calc Erstellen von x-y-diagrammen in OpenOffice.calc In dieser kleinen Anleitung geht es nur darum, aus einer bestehenden Tabelle ein x-y-diagramm zu erzeugen. D.h. es müssen in der Tabelle mindestens zwei

Mehr

Inhalt. Max Lini. ax. inie. Einleitung... VII

Inhalt. Max Lini. ax. inie. Einleitung... VII rst Inhalt Einleitung....................................................... VII 1 Schöne neue Welt: Objektorientierte Programmierung in PHP 5.............. 1 Klassen, Interfaces und Objekte...................................

Mehr

EinfÅhrung in die objektorientiere Programmierung (OOP) unter Delphi 6.0. EDV Kurs 13/2

EinfÅhrung in die objektorientiere Programmierung (OOP) unter Delphi 6.0. EDV Kurs 13/2 EinfÅhrung in die objektorientiere Programmierung (OOP) unter Delphi 6.0 EDV Kurs 13/2 Inhaltsverzeichnis 1 Objekte... 1 2 Klassen... 3 2.1 Beziehungen zwischen Klassen... 4 2.1.1 Vererbung... 4 2.1.2

Mehr

am Beispiel von JUnit

am Beispiel von JUnit Aufbau eines Testwerkzeugs am Beispiel von JUnit Üblicher Ansatz für Tests und Fehlersuche: Print-Befehle, Debugger-Ausdrücke, Test-Skripte möglichst über globale Variable debug steuerbar Command Pattern

Mehr

Entwicklungswerkzeuge

Entwicklungswerkzeuge Entwicklungswerkzeuge Werner Struckmann & Tim Winkelmann 10. Oktober 2012 Gliederung Anforderungen Projekte Debugging Versionsverwaltung Frameworks Pattern Integrated development environment (IDE) Werner

Mehr

BILDBEARBEITUNGSPROGRAMM IRFANVIEW

BILDBEARBEITUNGSPROGRAMM IRFANVIEW Anleitung BILDBEARBEITUNGSPROGRAMM IRFANVIEW 2012, netzpepper Alle Rechte vorbehalten. Nachdruck oder Vervielfältigung auch auszugsweise nur mit schriftlicher Genehmigung des Autors. Stand: 17.02.2012

Mehr

2. ZELLINHALTE UND FORMELN

2. ZELLINHALTE UND FORMELN 2. ZELLINHALTE UND FORMELN Aufgabe: In dem Beispiel Haushaltsbuch entwickeln Sie eine Kostenaufstellung, die alle monatlichen Ausgaben einzelner Sparten enthält. Darauf basierend berechnen Sie mit einfachen

Mehr

5. Abstrakte Klassen. Beispiel (3) Abstrakte Klasse. Beispiel (2) Angenommen, wir wollen die folgende Klassenhierarchie implementieren:

5. Abstrakte Klassen. Beispiel (3) Abstrakte Klasse. Beispiel (2) Angenommen, wir wollen die folgende Klassenhierarchie implementieren: 5. Abstrakte Klassen Beispiel 5. Abstrakte Klassen 5. Abstrakte Klassen Beispiel Beispiel (3) Angenommen, wir wollen die folgende Klassenhierarchie implementieren: Probleme des Implementierungsvorschlags:

Mehr

Von der UML nach C++

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

Mehr

Block R (Rahmen): SE Aktivitäten 21.10.04 2. Vorlesung Methoden des Software Engineering. Block R Rahmen Aktivitäten der Software-Entwicklung

Block R (Rahmen): SE Aktivitäten 21.10.04 2. Vorlesung Methoden des Software Engineering. Block R Rahmen Aktivitäten der Software-Entwicklung Block R (Rahmen): SE Aktivitäten 21.10.04 1 Vorlesung Methoden des Software Engineering Block R Rahmen Aktivitäten der Software-Entwicklung Martin Wirsing Einheit R.2, 21.10.2004 Block R (Rahmen): SE Aktivitäten

Mehr

Software Engineering in der Praxis

Software Engineering in der Praxis Software Engineering in der Praxis Praktische Übungen Meitner, Spisländer FAU Erlangen-Nürnberg Objektorientiertes Design 1 / 16 Objektorientiertes Design Matthias Meitner Marc Spisländer Lehrstuhl für

Mehr

Softwarepraktikum: Enigma

Softwarepraktikum: Enigma Softwarepraktikum: Enigma Martin Steffen Sommersemester 2003 Abschnitt I Softwareentwurf Bereiche der Softwareentwicklung 1 Softwareentwurf eigentliche Softwareentwicklung Projektmanagement Konfigurationsmanagement

Mehr

Brainfuck. 1 Brainfuck. 1.1 Brainfuck Geschichte und Umfeld. 1.2 Esoterische Programmiersprachen

Brainfuck. 1 Brainfuck. 1.1 Brainfuck Geschichte und Umfeld. 1.2 Esoterische Programmiersprachen Brainfuck 1 Brainfuck 1.1 Brainfuck Geschichte und Umfeld Brainfuck ist eine sogenannte esoterische Programmiersprache. Sie wurde 1993 vom Schweizer Urban Müller entworfen mit dem Ziel, eine Sprache mit

Mehr

Application Note. Anbindung von Kunden-Software an SpiderControl Web Visualisierung

Application Note. Anbindung von Kunden-Software an SpiderControl Web Visualisierung 2015-02-25 1 of 6 Application Note Anbindung von Kunden-Software an SpiderControl Web Visualisierung Version ApplicationNote_AnbindungFremdsoftware /Version Seite 1 / 6 Version Datum Kommentar Autor 0.1

Mehr

Evaluation of Database Design and Reverse Engineering Tools for a Large Software System

Evaluation of Database Design and Reverse Engineering Tools for a Large Software System Evaluation of Database Design and Reverse Engineering Tools for a Large Software System Anne Thomas TU Dresden Dr. B. Demuth Pre Press GmbH (Dresden) T. Reuter Gliederung Einleitung Vorgehensweise Kontext

Mehr

DRIVE LIKE A VIRTUAL DEVELOPER Die Poleposition für Ihre Softwareentwicklung

DRIVE LIKE A VIRTUAL DEVELOPER Die Poleposition für Ihre Softwareentwicklung DRIVE LIKE A VIRTUAL DEVELOPER Die Poleposition für Ihre Softwareentwicklung Was für ein Tempo! Das Rad dreht sich rasant schnell: Die heutigen Anforderungen an Softwareentwicklung sind hoch und werden

Mehr

fungen Debugging Boris Tripolskij

fungen Debugging Boris Tripolskij Werkzeuggestützte tzte Softwareprüfungen fungen Debugging Boris Tripolskij Gliederung Motivation für Debugging Aufbau des Debuggers in Eclipse Arten von Debugging Tools Fehlerarten Delta Debugging Vorführung

Mehr

Code und Qualität 2: Testing

Code und Qualität 2: Testing Code und Qualität 2: Testing Proseminar Objektorientiertes Programmieren mit.net und C# Trung Hieu Dao Institut für Informatik Software & Systems Engineering Agenda Motivation Unit Tests in Visual Studio

Mehr

ZENITY - Die Software für Ihre Unternehmens-Releaseplanung

ZENITY - Die Software für Ihre Unternehmens-Releaseplanung ZENITY - Die Software für Ihre Unternehmens-Releaseplanung RELEASEPLANUNG HEUTE Heutige Anwendungen in in Grossunternehmen sind sind keine keine alleinstehenden alleinstehenden Insel-Applikationen Insel-Applikationen

Mehr

Unit-Test Theorie und Praxis. Stephan Seefeld, INGTES AG

Unit-Test Theorie und Praxis. Stephan Seefeld, INGTES AG Unit-Test Theorie und Praxis Stephan Seefeld, INGTES AG Inhalt Was sind Unit-Test? NUnit für.net Demo Seite 2 Quellen Für diesen Vortrag verwendete Quellen: dotnet User Group Berlin Brandenburg http://www.dotnet-berlinbrandenburg.de/

Mehr

3.4 Unified Process. 1999 Ivar Jacobson, Grady Booch, James Rumbaugh: The Unified Software Development Process.

3.4 Unified Process. 1999 Ivar Jacobson, Grady Booch, James Rumbaugh: The Unified Software Development Process. 1999 Ivar Jacobson, Grady Booch, James Rumbaugh: The Unified Software Development Process. 1996 Philippe Kruchten: Rational Unified Process Produkt der Firma Seit 2002 Teil des IBM Konzerns Objektorientiertes

Mehr

Grob- und Detailplanung bei der Implementierung nutzen

Grob- und Detailplanung bei der Implementierung nutzen Softwarearchitektur Grob- und Detailplanung bei der Implementierung nutzen Bereich Realisierung Aktivität Softwareinkrement realisieren Ziele Vermitteln einer Orientierungshilfe für alle Entwickler Etablierung

Mehr

VBA-Programmierung: Zusammenfassung

VBA-Programmierung: Zusammenfassung VBA-Programmierung: Zusammenfassung Programmiersprachen (Definition, Einordnung VBA) Softwareentwicklung-Phasen: 1. Spezifikation 2. Entwurf 3. Implementierung Datentypen (einfach, zusammengesetzt) Programmablaufsteuerung

Mehr

Techniken der Projektentwicklung

Techniken der Projektentwicklung diagramme Termin 6 Denken in Schnittstellen Was nun? Einführung Bisher kennengelernt: Modellierung auf Konzeptlevel Usecase-Diagramme Domänenmodelle Jetzt: Übergang zu Spezifikation und Implementierung!

Mehr

Daniel Warneke warneke@upb.de 08.05.2006. Ein Vortrag im Rahmen des Proseminars Software Pioneers

Daniel Warneke warneke@upb.de 08.05.2006. Ein Vortrag im Rahmen des Proseminars Software Pioneers Design Patterns Daniel Warneke warneke@upb.de 08.05.2006 Ein Vortrag im Rahmen des Proseminars Software Pioneers Design Patterns 1/23 Übersicht Einleitung / Motivation Design Patterns Beispiele Rolle des

Mehr

Universität Augsburg, Institut für Informatik Sommersemester 2005 Prof. Dr. Werner Kießling 16. Juli 2005 Dr. Alfons Huhn, Timotheus Preisinger

Universität Augsburg, Institut für Informatik Sommersemester 2005 Prof. Dr. Werner Kießling 16. Juli 2005 Dr. Alfons Huhn, Timotheus Preisinger Universität Augsburg, Institut für Informatik Sommersemester 2005 Prof. Dr. Werner Kießling 16. Juli 2005 Dr. Alfons Huhn, Timotheus Preisinger Informatik II Hinweise: Die Bearbeitungszeit beträgt 90 Minuten.

Mehr

Vorlesung "Software-Engineering"

Vorlesung Software-Engineering Vorlesung "Software-Engineering" Rainer Marrone, TUHH, Arbeitsbereich STS Vorige Vorlesung Pflichtenheft (requirements specification document) Charakterisierung von Software-Qualität Detaillierte Anforderungsanalyse

Mehr

Vortrag von: Ilias Agorakis & Robert Roginer

Vortrag von: Ilias Agorakis & Robert Roginer MDA Model Driven Architecture Vortrag von: Ilias Agorakis & Robert Roginer Anwendungen der SWT - WS 08/09 Inhalt Was ist MDA? Object Management Group (OMG) Ziele Konzepte der MDA Werkzeuge Vor- und Nachteile

Mehr

Kapitel 6. Vererbung

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

Mehr

The Software Quality Challenge

The Software Quality Challenge The Software Quality Challenge Stanislav Michel Otto-von-Guericke-Universität Magdeburg Gliederung 1. Einleitung 2. Fehlerbeseitigung Probleme 3. Erfolgreiche Qualitätsstrategien 4. Grundsätze der Softwarequalität

Mehr

Objektorientierte Modellierung (1)

Objektorientierte Modellierung (1) Objektorientierte Modellierung (1) Die objektorientierte Modellierung verwendet: Klassen und deren Objekte Beziehungen zwischen Objekten bzw. Klassen Klassen und Objekte Definition Klasse Eine Klasse ist

Mehr

Unit Tests und Fehlersuche

Unit Tests und Fehlersuche Unit Tests und Fehlersuche SE 1 - Softwareentwicklungspraktikum Test Deadline! Sinnvolle Tests kompilierbar im CVS d.h. Schnittstellen zu Strategiemethoden etc. schon erstellen Kommentieren! Besser ein

Mehr

Algorithmen und Datenstrukturen 07

Algorithmen und Datenstrukturen 07 5. Dezember 2011 1 Besprechung Blatt 6 Fragen 2 Vererbung Allgemein abstract Interfaces 3 Unified Modeling Language (UML) Ablaufdiagramme Klassendiagramme Anwendungsfalldiagramme 4 Vorbereitung Blatt 7

Mehr

Kapitel 6. Vererbung

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

Mehr

Client-Server-Beziehungen

Client-Server-Beziehungen Client-Server-Beziehungen Server bietet Dienste an, Client nutzt Dienste Objekt ist gleichzeitig Client und Server Vertrag zwischen Client und Server: Client erfüllt Vorbedingungen eines Dienstes Server

Mehr

Code-Erzeugung aus UML-Klassendiagrammen

Code-Erzeugung aus UML-Klassendiagrammen Dominik 09.03.2009 Universität Ulm Gessenharter Inst. f. Programmiermethodik und Compilerbau Code-Erzeugung aus UML-Klassendiagrammen Theorie und Praxis Seite 2 REConf 2009 München Dominik Gessenharter

Mehr

Methoden zur Visualisierung von ereignisdiskreten Analysedaten

Methoden zur Visualisierung von ereignisdiskreten Analysedaten Fakultät Informatik, Institut für Angewandte Informatik, Professur Technische Informationssysteme Methoden zur Visualisierung von ereignisdiskreten Analysedaten Referent: Hendrik Freund Betreuer: Vladimir

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

5. Abstrakte Klassen

5. Abstrakte Klassen 5. Abstrakte Klassen Beispiel 5. Abstrakte Klassen Angenommen, wir wollen die folgende Klassenhierarchie implementieren: Vogel Amsel Drossel Fink Peter Becker, Programiersprache Java FH Bonn-Rhein-Sieg,

Mehr