Was ist die Grundidee, die hinter dem objektorientierten Entwurf steht?
Das Grundgedanke der Objektorientierung besteht darin, dass Software-Objekte als Abstraktionen der Wirklichkeit erscheinen. Objekte sind eindeutig identifizierbar.
Sie haben Eigenschaften, die durch Attribute modelliert werden, und sie weisen ein bestimmtes Verhalten auf, das durch Methoden beschrieben wird. Eigenschaften und Methoden werden in einem logischen Verbund gekapselt.
Neben der Kapselung und der Abstraktion sind weitere grundlegende Prinzipien der Objektorientierung die Modularisierung und die Hierarchie. Ein Programmsystem kann aus Objekten zusammengebaut werden, die nebeneinander existieren und untereinander Botschaften austauschen, um fremde Methoden zu benutzen. Objekte werden als Exemplar von Klassen erzeugt. Klassen beschreiben die ihren Exemplaren gemeinsamen Attribute und Methoden. Die Klassen eines objektorientierten Entwurfs sind hierarchisch organisiert, so dass die Objekte einer Klasse die Rolle von Objekten einer Klasse, die an höherer Stelle der Klassenhierarchie rangiert, einnehmen können.
Sie haben Eigenschaften, die durch Attribute modelliert werden, und sie weisen ein bestimmtes Verhalten auf, das durch Methoden beschrieben wird. Eigenschaften und Methoden werden in einem logischen Verbund gekapselt.
Neben der Kapselung und der Abstraktion sind weitere grundlegende Prinzipien der Objektorientierung die Modularisierung und die Hierarchie. Ein Programmsystem kann aus Objekten zusammengebaut werden, die nebeneinander existieren und untereinander Botschaften austauschen, um fremde Methoden zu benutzen. Objekte werden als Exemplar von Klassen erzeugt. Klassen beschreiben die ihren Exemplaren gemeinsamen Attribute und Methoden. Die Klassen eines objektorientierten Entwurfs sind hierarchisch organisiert, so dass die Objekte einer Klasse die Rolle von Objekten einer Klasse, die an höherer Stelle der Klassenhierarchie rangiert, einnehmen können.
KE1: Lernziele
• Die Fachbegriffe eines Anwendungsproblems, ihre Merkmale und typischen Verhaltensweisen verstehen und umfassend beschreiben können.
• Die Anforderungen einer Anwendung erheben und systematisch dokumentieren können.
• Anwendungsfälle, Gegenstände, Beziehungen, Verantwortlichkeiten, Abläufe und andere Phänomene und Erscheinungen von Belang in der Aufgabe erkennen und präzise in der Form eines Fachlexikons und verschiedener Diagrammarten darstellen können.
• Die behandelte Aufgabenstellung vervollständigen und auf ähnliche Aufgaben übertragen können.
• Die Begriffe Objekt und Klasse erläutern und gegeneinander abgrenzen sowie auf die Fachbegriffe einer gegebenen Problemstellung anwenden können.
• Verstehen, wie Objekte zusammenwirken und worin sich der Austausch von Botschaften und Prozeduraufrufe unterscheiden.
• Eine Vererbungshierarchie aufstellen und erklären können, wie sich ihre Klassen und das Verhalten dieser Klassen bestimmen lassen.
• Die Angemessenheit einer Klassenhierarchie beurteilen können.
• Die wesentlichen Merkmale der objektorientierten Programmierung wiedergeben können.
• Die Begriffe Klasse und Objekt und ihre Beziehung zueinander verstehen und anwenden können.
• Die Hauptbestandteile von Klassen und Objekten, nämlich Verhalten und Eigenschaften, erklären und konstruktiv einsetzen können.
• Die Vererbungsbeziehungen zwischen Klassen und ihre Auswirkungen auf den Programmentwurf begreifen.
• Die Anforderungen einer Anwendung erheben und systematisch dokumentieren können.
• Anwendungsfälle, Gegenstände, Beziehungen, Verantwortlichkeiten, Abläufe und andere Phänomene und Erscheinungen von Belang in der Aufgabe erkennen und präzise in der Form eines Fachlexikons und verschiedener Diagrammarten darstellen können.
• Die behandelte Aufgabenstellung vervollständigen und auf ähnliche Aufgaben übertragen können.
• Die Begriffe Objekt und Klasse erläutern und gegeneinander abgrenzen sowie auf die Fachbegriffe einer gegebenen Problemstellung anwenden können.
• Verstehen, wie Objekte zusammenwirken und worin sich der Austausch von Botschaften und Prozeduraufrufe unterscheiden.
• Eine Vererbungshierarchie aufstellen und erklären können, wie sich ihre Klassen und das Verhalten dieser Klassen bestimmen lassen.
• Die Angemessenheit einer Klassenhierarchie beurteilen können.
• Die wesentlichen Merkmale der objektorientierten Programmierung wiedergeben können.
• Die Begriffe Klasse und Objekt und ihre Beziehung zueinander verstehen und anwenden können.
• Die Hauptbestandteile von Klassen und Objekten, nämlich Verhalten und Eigenschaften, erklären und konstruktiv einsetzen können.
• Die Vererbungsbeziehungen zwischen Klassen und ihre Auswirkungen auf den Programmentwurf begreifen.
Geheimnisprinzip
S. 26: (engl. information hiding) bedeutet, dass Eigenschaften und die Implementierung einer Betrachtungseinheit von außen nicht sichtbar sind. Zustandsveränderungen oder Abfragen über den Zustand der Betrachtungseinheit können nur mittels einer wohldefinierten Schnittstelle, die die Gesamtheit der sichtbaren Operationen und ggf. Datentypen angibt, erfolgen.
S. 113: Das Geheimnisprinzip besagt, dass nur die Funktionalität eines Programmmoduls oder einer Klasse, d. h. die von diesem Modul oder der !Klasse angebotenen Operationen bekannt gemacht wird. Die interne Realisierung der Operationen und auch der Aufbau der Datenstrukturen, auf denen sie die Operationen arbeiten, bleiben nach außen verborgen. Das Geheimnisprinzip stellt sicher, dass die Implementierungsdetails eines Moduls oder einer Klasse beliebig oft geändert werden, ohne dass andere Programmteile betroffen sind, solange die Schnittstellen des geänderten Moduls nicht betroffen sind.
S. 113: Das Geheimnissprinzip ermöglicht die arbeitsteilige Entwicklung großer Programmsysteme, weil das Zusammenspiel der Programmmodule unabhängig von deren Implementierung ist. Die Entwickler einzelner Module müssen nur die öffentlichen Schnittstellen der benutzten Module kennen, um deren öffentliche Operationen verwenden zu können. Die Auswirkungen von Programmänderungen werden beherrschbar. Die Auswirkungen von Fehlern werden verringert, weil der Entwickler einesModuls keineMöglichkeit hat, über die dokumentierten Schnittstellen anderer Module hinweg deren Implementierungsdetails in die Implementierung des eigenen Moduls einzubeziehen.
S. 113: Das Geheimnisprinzip besagt, dass nur die Funktionalität eines Programmmoduls oder einer Klasse, d. h. die von diesem Modul oder der !Klasse angebotenen Operationen bekannt gemacht wird. Die interne Realisierung der Operationen und auch der Aufbau der Datenstrukturen, auf denen sie die Operationen arbeiten, bleiben nach außen verborgen. Das Geheimnisprinzip stellt sicher, dass die Implementierungsdetails eines Moduls oder einer Klasse beliebig oft geändert werden, ohne dass andere Programmteile betroffen sind, solange die Schnittstellen des geänderten Moduls nicht betroffen sind.
S. 113: Das Geheimnissprinzip ermöglicht die arbeitsteilige Entwicklung großer Programmsysteme, weil das Zusammenspiel der Programmmodule unabhängig von deren Implementierung ist. Die Entwickler einzelner Module müssen nur die öffentlichen Schnittstellen der benutzten Module kennen, um deren öffentliche Operationen verwenden zu können. Die Auswirkungen von Programmänderungen werden beherrschbar. Die Auswirkungen von Fehlern werden verringert, weil der Entwickler einesModuls keineMöglichkeit hat, über die dokumentierten Schnittstellen anderer Module hinweg deren Implementierungsdetails in die Implementierung des eigenen Moduls einzubeziehen.
Einkapselung
S.25: (engl. encapsulation) bezeichnet ein wichtiges Prinzip beim Programmentwurf. Es unterstützt die Modularität von Programmen und vereinfacht deren Pflege und Weiterentwicklung. Einkapselung wird ermöglicht durch zwei untergeordnete Konzepte:
Bündelung und Geheimnisprinzip.
Letzteres sorgt dafür, dass der Anwender eines Objekts nichts weiter als die Signatur und den Ergebnistyp der öffentlichen Methoden einer Klasse kennen muss, um einObjekt der Klasse benutzen zu können. Die Darstellung seiner Daten und die Implementierung seiner Methoden bleiben verborgen.
Bündelung und Geheimnisprinzip.
Letzteres sorgt dafür, dass der Anwender eines Objekts nichts weiter als die Signatur und den Ergebnistyp der öffentlichen Methoden einer Klasse kennen muss, um einObjekt der Klasse benutzen zu können. Die Darstellung seiner Daten und die Implementierung seiner Methoden bleiben verborgen.
Anwendungsfall
S. 20: (engl. use case) eine zusammenhängende Einheit
von Aktionen, die ein System einem Akteur außerhalb des Systems zur Verfügung stellt. Die Aktionen werden von Akteuren durch Botschaftenaustausch angestoßen, um ein bestimmtes Ziel oder Ergebnis zu erreichen. Die Ergebnisse einer Systemaktion werden gleichfalls durch Botschaftenaustausch den Akteuren in der Umgebung des Systems übermittelt.
Die Summe aller Anwendungsfälle zeichnet überblicksartig ein Bild des Systems.
S. 76 Ein Anwendungsfall (engl. use case) bezeichnet eine typische Interaktion zwischen einem Anwender und einem System aus der Sicht des Anwenders. Ein Anwendungsfall umfasst Folgen von Aktionen, die reguläre, aber auch vom normalen Verhalten abweichende Abläufe beschreiben.
Anwendungsfälle erfassen genau die Systemaktionen, die für das Zusammenwirken zwischen dem System und seinen Benutzerinnen erforderlich sind und dazu beitragen, bestimmte Ziele der Benutzer zu erreichen.
Anwendungsfälle werden durch Anwender oder durch Zeitereignisse angestoßen.
von Aktionen, die ein System einem Akteur außerhalb des Systems zur Verfügung stellt. Die Aktionen werden von Akteuren durch Botschaftenaustausch angestoßen, um ein bestimmtes Ziel oder Ergebnis zu erreichen. Die Ergebnisse einer Systemaktion werden gleichfalls durch Botschaftenaustausch den Akteuren in der Umgebung des Systems übermittelt.
Die Summe aller Anwendungsfälle zeichnet überblicksartig ein Bild des Systems.
S. 76 Ein Anwendungsfall (engl. use case) bezeichnet eine typische Interaktion zwischen einem Anwender und einem System aus der Sicht des Anwenders. Ein Anwendungsfall umfasst Folgen von Aktionen, die reguläre, aber auch vom normalen Verhalten abweichende Abläufe beschreiben.
Anwendungsfälle erfassen genau die Systemaktionen, die für das Zusammenwirken zwischen dem System und seinen Benutzerinnen erforderlich sind und dazu beitragen, bestimmte Ziele der Benutzer zu erreichen.
Anwendungsfälle werden durch Anwender oder durch Zeitereignisse angestoßen.
Akteur
S. 19: (engl. actor) ein Benutzer oder eine Benutzerin eines
zu implementierenden Systems aus der Sicht eines bestimmten!Anwendungsfalls. Ein Akteur ist nicht Teil des Systems, sondern interagiert mit ihm. Ein Akteur kann eine Person oder ein anderes System sein.
Der Begriff Akteur bezeichnet eine Rolle einer Systembenutzerin oder eines externen Programms, das direkt mit dem betrachteten System als Teil einer zusammenhängenden Arbeitseinheit zusammenwirkt. Ein realer Handlungsträger kann mehrere Rollen in den Anwendungsfällen eines Systems wahrnehmen und kann daher durch verschiedene Akteure dargestellt sein.
S. 77: Anwender und externe Systeme, die an Anwendungsfällen teilnehmen aber selbst nicht Teil des zu realisierenden Systems sind, werden als Akteure (engl. actor) bezeichnet.
zu implementierenden Systems aus der Sicht eines bestimmten!Anwendungsfalls. Ein Akteur ist nicht Teil des Systems, sondern interagiert mit ihm. Ein Akteur kann eine Person oder ein anderes System sein.
Der Begriff Akteur bezeichnet eine Rolle einer Systembenutzerin oder eines externen Programms, das direkt mit dem betrachteten System als Teil einer zusammenhängenden Arbeitseinheit zusammenwirkt. Ein realer Handlungsträger kann mehrere Rollen in den Anwendungsfällen eines Systems wahrnehmen und kann daher durch verschiedene Akteure dargestellt sein.
S. 77: Anwender und externe Systeme, die an Anwendungsfällen teilnehmen aber selbst nicht Teil des zu realisierenden Systems sind, werden als Akteure (engl. actor) bezeichnet.
Szenario
S. 38 (engl. scenario) beschreibt eine aktuelle Arbeitssituation im Hinblick auf die Aufgaben im Anwendungsbereich. Es beschreibt ferner die Art und Weise, in der die jeweilige Aufgabe in einzelnen Verarbeitungsschritten auszuführen ist und die Bedingungen, unter denen dies zu erfolgen hat.
S. 79 Wir nennen eine einzelne Abfolge von Aktionen, d. h. einen Ablaufpfad in einem Anwendungsfall, ein Szenario. Szenarien beschreiben aktuelle Arbeitssituationen. Ein Szenario, das die Sicht der Anwender wiedergibt, fasst das zu entwickelnde System als schwarzen Kasten (engl. black box) auf. Die innere Arbeitsweise des Systems bleibt den Anwendern verborgen, von Interesse ist allein das externe Systemverhalten, wie es sich aus der Sicht eines Anwenders darstellt. Das Augenmerk liegt bei dieser Perspektive auf typischen Interaktionen zwischen Benutzern und dem Anwendungssystem.
S. 79 Wir nennen eine einzelne Abfolge von Aktionen, d. h. einen Ablaufpfad in einem Anwendungsfall, ein Szenario. Szenarien beschreiben aktuelle Arbeitssituationen. Ein Szenario, das die Sicht der Anwender wiedergibt, fasst das zu entwickelnde System als schwarzen Kasten (engl. black box) auf. Die innere Arbeitsweise des Systems bleibt den Anwendern verborgen, von Interesse ist allein das externe Systemverhalten, wie es sich aus der Sicht eines Anwenders darstellt. Das Augenmerk liegt bei dieser Perspektive auf typischen Interaktionen zwischen Benutzern und dem Anwendungssystem.
Objekt
S. 33/Glossar: Im täglichen Sprachgebrauch bezeichnen wir mit dem Wort Objekt einen Gegenstand des Interesses, der Beobachtung, der Veränderung, der Untersuchung oder der Messung. Im engeren, programmiersprachlichen Sinn besitzt ein Objekt einen !Zustand (repräsentiert durch Beziehungen und Attribute), es reagiert mit einem definierten Verhalten (durch die Ausführung von Operationen) auf seine Umgebung, und es ist ein bestimmtes Exemplar seiner Klasse. Das Verhalten gilt für alle Objekte einer Klasse gleichermaßen, jedoch besitzt jedes Objekt eine eigene Identität, die es von anderen Objekten unterscheidet.
S. 99/Def: Die objektorientierte Programmierung bezeichnet die Abbilder konkreter Gegenstände und Träger individueller Rollen in Entwurfsdokumenten und Programmen als Objekte.
S. 62: Bei dieser Programmiertechnik werden Datenstrukturen und die sie manipulierende Verarbeitungsmethoden als Einheit betrachtet und Objekte genannt.
Die Ausführung einer Verarbeitungsmethode wird angeregt durch die Ankunft einer Botschaft, in der die zu aktivierende Methode zusammen mit weiterer Information von der Umgebung des Objekts übermittelt wird.
S. 63: Objekte modellieren Dinge, Personen, Begriffe oder Gegenstände der Wirklichkeit. Sie sind eindeutig identifizierbare Einheiten, die Daten und Verarbeitung in sich vereinen. Die Daten repräsentieren wesentlicheMerkmale eines Objekts und seinen Zustand. Die vom Objekt zur Verfügung gestellten Verarbeitungsmethoden bestimmen sein typisches Verhalten. Diese Methoden werden von anderen Objekten oder durch äußere Ereignisse, wie etwa Benutzereingaben, aktiviert.
S. 99/Def: Die objektorientierte Programmierung bezeichnet die Abbilder konkreter Gegenstände und Träger individueller Rollen in Entwurfsdokumenten und Programmen als Objekte.
S. 62: Bei dieser Programmiertechnik werden Datenstrukturen und die sie manipulierende Verarbeitungsmethoden als Einheit betrachtet und Objekte genannt.
Die Ausführung einer Verarbeitungsmethode wird angeregt durch die Ankunft einer Botschaft, in der die zu aktivierende Methode zusammen mit weiterer Information von der Umgebung des Objekts übermittelt wird.
S. 63: Objekte modellieren Dinge, Personen, Begriffe oder Gegenstände der Wirklichkeit. Sie sind eindeutig identifizierbare Einheiten, die Daten und Verarbeitung in sich vereinen. Die Daten repräsentieren wesentlicheMerkmale eines Objekts und seinen Zustand. Die vom Objekt zur Verfügung gestellten Verarbeitungsmethoden bestimmen sein typisches Verhalten. Diese Methoden werden von anderen Objekten oder durch äußere Ereignisse, wie etwa Benutzereingaben, aktiviert.
Klasse
S. 29 (engl. class) umfasst eine Gruppe oder Familie gleichartiger !Objekte und bezeichnet einen Begriff aus dem Anwendungsbereich.
Klassenattribut.
S. 100 Der Begriff Klasse wird in der objektorientierten Programmierung genau dazu benutzt, einen Bauplan für viele ähnliche, aber individuell unterscheidbare Objekte anzulegen. Eine Klasse umfasst eine Gruppe oder Familie gleichartiger Objekte, und bezeichnet einen Begriff aus dem Anwendungsbereich. Klassen werden durch Substantive bezeichnet.
Klassenattribut.
S. 100 Der Begriff Klasse wird in der objektorientierten Programmierung genau dazu benutzt, einen Bauplan für viele ähnliche, aber individuell unterscheidbare Objekte anzulegen. Eine Klasse umfasst eine Gruppe oder Familie gleichartiger Objekte, und bezeichnet einen Begriff aus dem Anwendungsbereich. Klassen werden durch Substantive bezeichnet.
Attribut
(engl. attribute) ein benanntes und typisiertes Datenelement, das in einer Klasse vereinbart wird und Werte eines bestimmten Typs und damit auch Zustandsinformation nachhält. Wir unterscheiden Exemplarattribute oder -variablen, die den Zustand eines einzelnen Attributs erfassen, und Klassenattribute oder -variablen, die Zustandsinformation aufbewahren, die für alle Objekte einer Klasse sichtbar sind. Jedes aus einer Klasse erzeugte Objekt besitzt eigene Kopien der in der Klasse vereinbarten Exemplarattribute, die im Allgemeinen bei verschiedenen Objekten einer Klasse mit unterschiedlicher Werten belegt sind. Klassenattribute gehören zur Klasse und existieren genau einmal, auch ohne dass ein Objekt der Klasse existieren muss. Sie können von den Objekten der Klasse für die Verwaltung gemeinsamer Daten benutzt werden. Jedes Attribut besitzt einen bestimmten Typ und einen Bezeichner, der innerhalb der Klasse eindeutig ist. Für ein Attribut kann in der Klasse ein Initialwert vereinbart werden, den das jeweilige Attribut bei der Erzeugung eines Objekts dieser Klasse annimmt.
S. 101 Die Klassenbeschreibung bestimmt die Eigenschaften und Fähigkeiten aller Exemplare der Klasse. Die Eigenschaften werden durch Merkmale, auch Attribute genannt, dargestellt.
Attribute werden durch Substantive bezeichnet
Bsp: Kennzeichen, Farbe, Anzahl Türen sind Attribute der Klasse PKW.
S. 101 Die Klassenbeschreibung bestimmt die Eigenschaften und Fähigkeiten aller Exemplare der Klasse. Die Eigenschaften werden durch Merkmale, auch Attribute genannt, dargestellt.
Attribute werden durch Substantive bezeichnet
Bsp: Kennzeichen, Farbe, Anzahl Türen sind Attribute der Klasse PKW.
Exemplarattribut
(engl. instance variable) dient dazu, die Eigenschaften und den Zustand der Exemplare einer !Klasse nachzuhalten. Ein Exemplarattribut hat den in der !Klassendefinition vereinbarten Namen und Typ. Der Name ermöglicht den abfragenden oder verändernden Zugriff auf den Wert eines Exemplarattributs. Die Werte von Exemplarattributen können während der Lebenszeit eines
Objekts verändert werden.
Objekts verändert werden.
Klassenattibut
(engl. class attribute oder class variable) gehört nicht einem einzelnen Objekt, sondern einer Klasse und ist von der Existenz der Objekte unabhängig. Das Klassenattribut existiert nur einmal pro Klasse und wird bei der Ausführung der Klassenbeschreibung angelegt und mit einem passenden Standardwert belegt.
Klassenhierarchie, Spezialisierung, Attribut und Verhalten
Ähnlich wie in der Biologie können die Klassen objektorientierterModelle und Programme auf der Basis einer Verwandtschaftsrelation zu hierarchischen Strukturen verknüpft werden. Sie werden Klassenhierarchien genannt.
In einer Klassenhierarchie weisen nachgegliederte Klassen alle Eigenschaften (Attribute) und Fähigkeiten ( Verhalten) der Klassen auf, von denen sie abgeletet wurden. Sie sind Spezialisierungen der übergeordneten Klassen. Sie können die geerbten Eigenschaften und Fähigkeiten neu bestimmen und durch eigene Attribute und Fähigkeiten erweitern.
In einer Klassenhierarchie weisen nachgegliederte Klassen alle Eigenschaften (Attribute) und Fähigkeiten ( Verhalten) der Klassen auf, von denen sie abgeletet wurden. Sie sind Spezialisierungen der übergeordneten Klassen. Sie können die geerbten Eigenschaften und Fähigkeiten neu bestimmen und durch eigene Attribute und Fähigkeiten erweitern.
Unterklasse, Oberklasse, Einfach- und Mehrfachvererbung
Eine Klasse A, die ihre Eigenschaften und Fähigkeiten von einer anderen Klasse B erbt, wird Unterklasse von B genannt. B ist die Oberklasse von A.
Eine Klasse besitzt in der Regel mehr als eine Unterklasse.
In manchen objektorientierten Programmiersprachen kann jede Klasse höchstens eine Oberklasse haben. Man spricht in diesen Fällen von der Einfachvererbung.
Ist Mehrfachvererbung in einem Modell oder einer Sprache zugelassen, kann eine Klasse auch mehr als eine Oberklasse haben.
Eine Klasse besitzt in der Regel mehr als eine Unterklasse.
In manchen objektorientierten Programmiersprachen kann jede Klasse höchstens eine Oberklasse haben. Man spricht in diesen Fällen von der Einfachvererbung.
Ist Mehrfachvererbung in einem Modell oder einer Sprache zugelassen, kann eine Klasse auch mehr als eine Oberklasse haben.
Zugriff statische Methode auf Klassenattribute?
Selbsttestaufgabe 22.4-1:
Selbsttestaufgabe 22.4-1:
Exemplarmethoden operieren auf den Attributen des jeweiligen Objekts, sie können aber auch auf die Klassenvariablen zugreifen.
Erklären Sie, ob und, wenn ja, wie eine statische Methode (wir habe sie auch Klassenmethode genannt) auf die Attribute eines Exemplars der Klasse zugreifen kann.
Um an die Attribute eines Objekts heran zu kommen, muss man einen Verweis auf ein Objekt haben. Eine Klassenmethode kann demnach nur dann auf die Attribute eines Objekts der Klasse zugreifen, wenn sie eine Referenz auf ein Objekt besitzt. Auf dessen Attribute hat sie dann auch Zugriff. Eine Referenz kann durch einen Konstruktor- oder Methodenaufruf oder aber durch die Übergabe eines Objekts als Argument (siehe Kapitel 23) entstehen.
Erklären Sie, ob und, wenn ja, wie eine statische Methode (wir habe sie auch Klassenmethode genannt) auf die Attribute eines Exemplars der Klasse zugreifen kann.
Um an die Attribute eines Objekts heran zu kommen, muss man einen Verweis auf ein Objekt haben. Eine Klassenmethode kann demnach nur dann auf die Attribute eines Objekts der Klasse zugreifen, wenn sie eine Referenz auf ein Objekt besitzt. Auf dessen Attribute hat sie dann auch Zugriff. Eine Referenz kann durch einen Konstruktor- oder Methodenaufruf oder aber durch die Übergabe eines Objekts als Argument (siehe Kapitel 23) entstehen.
KE5: Testen
Eine wichtige Klassifikation unterscheidet Testfahren danach, ob der innere Aufbau des zu testenden Programms bekannt ist und zur Konstruktion von Testfällen herangezogen werden kann oder nicht. Im ersten Fall spricht man von einem Whitebox-Test, im zweiten von einem Blackbox-Test.
Egal, welche Technik man auch wählt, ein gemeinsamer Grundsatz ist, eine möglichst repräsentative und umfassende Menge von Testfällen zu erstellen. Ein Testfall (engl. test case) ist eine Stichprobe, die Bedingungen Testfall über Eingabe-Daten und erwartete Ausgaben, die einem bestimmten Zweck dienen, miteinander verknüpft.
Egal, welche Technik man auch wählt, ein gemeinsamer Grundsatz ist, eine möglichst repräsentative und umfassende Menge von Testfällen zu erstellen. Ein Testfall (engl. test case) ist eine Stichprobe, die Bedingungen Testfall über Eingabe-Daten und erwartete Ausgaben, die einem bestimmten Zweck dienen, miteinander verknüpft.
KE5: Testen: Blackbox
Beim Blackbox-Test überprüft man für jede Methode Spezialfälle der Spezifikation.
Der Methodenrumpf darf nicht berücksichtigt werden. Nur die Methodensignatur und ihr Ergebnistyp werden betrachtet. Man wählt für jeden Parameter der Methode einen Standardwert aus der Mitte des Datenbereichs sowie Grenzwerte des Datenbereichs. Wird die Java Modeling Language (JML) zur Verhaltensspezifikation benutzt, werden Testfälle automatisch aus der Spezifikation erzeugt. Eine Einführung in diesen Spezifikationsansatz von Leavens und Cheon findet man im Internet.
Der Methodenrumpf darf nicht berücksichtigt werden. Nur die Methodensignatur und ihr Ergebnistyp werden betrachtet. Man wählt für jeden Parameter der Methode einen Standardwert aus der Mitte des Datenbereichs sowie Grenzwerte des Datenbereichs. Wird die Java Modeling Language (JML) zur Verhaltensspezifikation benutzt, werden Testfälle automatisch aus der Spezifikation erzeugt. Eine Einführung in diesen Spezifikationsansatz von Leavens und Cheon findet man im Internet.
KE5: Testen: Whitebox
Beim Whitebox-Test orientiert man sich bei der Bestimmung von Testfällen an der Programmstruktur, um alle möglichen unterschiedlichen Fälle von Abläufen beim Testen zu erfassen. Kommen in einer Methodenimplementierung z.B. bedingte Anweisungen und Fallunterscheidungen vor, sollte man mehrere unterschiedliche Ablaufpfade testen. Kommen bedingte Schleifen vor, sollte man zumindest den direkten Abbruch testen, einen Schleifendurchlauf und dann den Abbruch sowie mehrere Schleifendurchläufe mit abschließendem Abbruch.
KE5: Testen: postiv testen
Beim positiven Test überprüfen wir, ob das Programm seine Spezifikation erfüllt.
Positive Tests werden mit gültigen Eingaben durchgeführt, die im mittleren Wertebereiche der Methodenparameter, aber auch an der Grenze der Wertebereiche liegen.
Dies wurde im vorangegangenen Abschnitt am Beispiel der Berechnung des Durchschnitts einer Zahlenreihe vorgeführt. Wir kennen dabei die mathematische Funktion, die eine Zahlenreihe auf ihren Durchschnitt abbildet, und nutzen diese
Kenntnis, um die Ergebnisse der Testfälle zu bewerten.
Positive Tests werden mit gültigen Eingaben durchgeführt, die im mittleren Wertebereiche der Methodenparameter, aber auch an der Grenze der Wertebereiche liegen.
Dies wurde im vorangegangenen Abschnitt am Beispiel der Berechnung des Durchschnitts einer Zahlenreihe vorgeführt. Wir kennen dabei die mathematische Funktion, die eine Zahlenreihe auf ihren Durchschnitt abbildet, und nutzen diese
Kenntnis, um die Ergebnisse der Testfälle zu bewerten.
KE5: Testen: negativ testen
Negative Tests benutzen ungültige Eingabedaten, um herauszufinden, wie sich das Programm bei solchen Eingaben verhält oder schwierige Fälle in Ihrem Programm zu identifizieren und diese Aspekte zu betonen. Im vorigen Abschnitt hatten wir mit der Eingabe einer leeren Zahlenreihe auch einen negativen Test benutzt und dabei einen Programmfehler entdeckt, der zu einer Division durch Null führt.
KE5: Testen: Dokumentation
Um die Bestimmung geeigneter Testfälle zu unterstützen, sollten Sie alle Annahmen, die Sie beim Schreiben ihrer Klasse gemacht haben, aufschreiben. Dies umfasst z. B. Annahmen über:
• erwartete Eingabedaten für Methodenaufrufe,
• die Funktionen, die Eingabedaten mit Ausgabedaten in Beziehung setzt,
• unterschiedliche Anfangszustände von Objekten, die mittels unterschiedlicher Konstruktoren erzeugt wurden, und
• erwartete Werte von Attributen und lokalen Variablen vor und nach dem Verlassen einer Schleife oder einer Auswahlanweisung.
• erwartete Eingabedaten für Methodenaufrufe,
• die Funktionen, die Eingabedaten mit Ausgabedaten in Beziehung setzt,
• unterschiedliche Anfangszustände von Objekten, die mittels unterschiedlicher Konstruktoren erzeugt wurden, und
• erwartete Werte von Attributen und lokalen Variablen vor und nach dem Verlassen einer Schleife oder einer Auswahlanweisung.
KE5: Testen: Integrationstest
Bisher konzentrierten wir uns auf auf das Testen von Klassen. Nachdem mehr und mehr Klassen einer Anwendung konstruiert und getestet sind, müssen wir diese Klassen schrittweise in größere Einheiten zusammenführen und darauf Integrationstests ausführen. Das Ziel der Integrationstests Integrationstest besteht darin, festzustellen, ob die integrierten Programmteile gemäß der Software-Anforderungen zusammenarbeiten und das erwartete Verhalten zeigen.
Für unsere Fallstudie „Mietwagenverleih“ liegt es nahe, die Klassen für einzelne Funktionalitäten wie die Ausfertigung eines Mietvertrags, die Abrechnung eines Vertrags oder den Reservierungsvorgang zu integrieren und zu testen.
Für Integrationstests eignen sich Whitebox-Testverfahren nicht, und das Testen sollte auch von anderen Personen als den Programmentwicklerinnen durchgeführt werden.
Die Gründe dafür liegen auf der Hand: Wenn ein Programm Fehler enthält, haben die Entwickler Anforderungen falsch interpretiert, übersehen oder falsch umgesetzt.
Für unsere Fallstudie „Mietwagenverleih“ liegt es nahe, die Klassen für einzelne Funktionalitäten wie die Ausfertigung eines Mietvertrags, die Abrechnung eines Vertrags oder den Reservierungsvorgang zu integrieren und zu testen.
Für Integrationstests eignen sich Whitebox-Testverfahren nicht, und das Testen sollte auch von anderen Personen als den Programmentwicklerinnen durchgeführt werden.
Die Gründe dafür liegen auf der Hand: Wenn ein Programm Fehler enthält, haben die Entwickler Anforderungen falsch interpretiert, übersehen oder falsch umgesetzt.
KE5: Testen: Integrationstest 2
Die Gefahr, dass diese Fehler bei der Bestimmung von Testfällen durch dieselben Personen wiederholt werden, ist deshalb sehr groß.
Die Abläufe der bei der Aufgabenanalyse erfassten Anwendungsfälle bilden eine geeignete Grundlage für die Festlegung von Testfällen. Für alle im Anwendungsfall vorkommenden Objekte ermitteln wir alle relevanten Attribute und legen für jeden zu testenden Ablauf die erwarteten Werte dieser Attribute fest. Ähnlich wie beim Klassentest gelten auch beim Integrationstest die üblichen Testprinzipien. Es müssen also
• ausgewählte Normalabläufe eines Anwendungsfalls,
• abweichende Abläufe sowie
• Extremwerte
überprüft werden. Dabei können sich schnell sehr viele Kombinationsmöglichkeiten ergeben. Es gibt verschiedene Verfahren, um aus der Menge aller Kombinationen eine Auswahl relevanter Testfälle abzuleiten.
Die Abläufe der bei der Aufgabenanalyse erfassten Anwendungsfälle bilden eine geeignete Grundlage für die Festlegung von Testfällen. Für alle im Anwendungsfall vorkommenden Objekte ermitteln wir alle relevanten Attribute und legen für jeden zu testenden Ablauf die erwarteten Werte dieser Attribute fest. Ähnlich wie beim Klassentest gelten auch beim Integrationstest die üblichen Testprinzipien. Es müssen also
• ausgewählte Normalabläufe eines Anwendungsfalls,
• abweichende Abläufe sowie
• Extremwerte
überprüft werden. Dabei können sich schnell sehr viele Kombinationsmöglichkeiten ergeben. Es gibt verschiedene Verfahren, um aus der Menge aller Kombinationen eine Auswahl relevanter Testfälle abzuleiten.
KE5: Testen: Systemtest
Der nächste Schritt in der Programmprüfung ist der Systemtest. Man versteht darunter den Test des fertigen Programmsystems gegen die im Pflichtenheft und anderen Anforderungsdokumenten festgelegten Funktions-, Leistung-, Zuverlässigkeits- und weiteren Qualitätsanforderungen.
Der Systemtest wird, wie die Integrations- und Klassentests, vor der Auslieferung des Programmsystems im Labor durchgeführt. Demgegenüber werden sog. Feldtests während des realen Einsatzes unter echten Anwendungsbedingungen und in der Laufzeitumgebung der Kundin gefahren.
Auf System- und Feldtest können wir in diesem Kurs nicht weiter eingehen. Mehr dazu finden Sie in [Liggesmeyer02] und anderen Büchern zum Thema „Software testen“.
Der Systemtest wird, wie die Integrations- und Klassentests, vor der Auslieferung des Programmsystems im Labor durchgeführt. Demgegenüber werden sog. Feldtests während des realen Einsatzes unter echten Anwendungsbedingungen und in der Laufzeitumgebung der Kundin gefahren.
Auf System- und Feldtest können wir in diesem Kurs nicht weiter eingehen. Mehr dazu finden Sie in [Liggesmeyer02] und anderen Büchern zum Thema „Software testen“.
KE5: Fehlerbehebung: Debuggen
Beim Testen eines Programms gibt es deshalb häufig Situationen, in denen wir mit Tests zwar Fehler aufdecken, aber allein durch die Auswertung der gescheiterten Testfälle nicht auf die Ursache eines Fehlers schließen können. In solchen Fällen müssen wir auf spezielle Testhilfeprogramme zur interaktiven Fehlersuche und -behebung zurückgreifen, auf sog. Debugger. Auch BlueJ enthält ein Debugger-Programm, das sehr einfach zu handhaben ist und das viele Einblicke in das Verhalten eines Programms gewährt. Folgende drei Aufgaben werden vom BlueJDebugger unterstützt:
• setzen von Programmstopps,
• schrittweiser Durchlauf durch den Code und
• Untersuchen von Attributen, Klassenvariablen und lokalen Variablen.
• setzen von Programmstopps,
• schrittweiser Durchlauf durch den Code und
• Untersuchen von Attributen, Klassenvariablen und lokalen Variablen.
KE5: Dokumentation
Die Java-Umgebung enthält das Dienstprogramm javadoc, das dazu dient, Referenzdokumentationen im HTML-Format aus den Java-Quelltexten zu erzeugen. Die Java-API-Referenz, die wir in Kapitel 26 kennen gelernt haben, ist eine auf diese Weise generierte Referenzdokumentation der Java-Standardbibliothek.
Das Javadoc-Dienstprogramm extrahiert die Dokumentationskommentare, die direkt vor einer Klassen-, Schnittstellen-, Konstruktor-, Methoden- oder Attributdefinition stehen. Die Dokumentationskommentare können noch die in Tab. 31-2 angegebenen Javadoc-Schlüsselwörter, die alle mit dem Zeichen @ beginnen, enthalten.
Sie traten in verschiedenen Programmbeispielen dieses Kurses auch schon auf.
Das Javadoc-Dienstprogramm extrahiert die Dokumentationskommentare, die direkt vor einer Klassen-, Schnittstellen-, Konstruktor-, Methoden- oder Attributdefinition stehen. Die Dokumentationskommentare können noch die in Tab. 31-2 angegebenen Javadoc-Schlüsselwörter, die alle mit dem Zeichen @ beginnen, enthalten.
Sie traten in verschiedenen Programmbeispielen dieses Kurses auch schon auf.
Flashcard set info:
Author: nic08
Main topic: Informatik
Topic: OOP
Published: 12.04.2010
Card tags:
All cards (37)
no tags
