Objektorientierte Programmierung OOP

Will man die Zahlenfolge 6, 32, 1, 64, 12 sortieren, so handelt es sich dabei um ein konkretes Problem, für das man auch einfach eine Lösung benennen kann. Die dazugehörige Problemklasse ist jedoch die Sortierung einer beliebigen Zahlenfolge mit einer endlichen Anzahl an Elementen. Dafür kann man keine konkrete Lösung angeben, sondern lediglich ein Verfahren beschreiben, das alle Probleme dieser Art löst. Man könnte das Problem noch allgemeiner formulieren, wenn man nicht nur Zahlenfolgen, sondern Folgen mit beliebigen Elementen mit einer eindeutigen Ordnung sortieren will.

Ein Algorithmus ist eine wohldefinierte Verfahrensbeschreibung, die aus einem oder mehreren Eingabewerten einen oder mehrere Ausgabewerte mit bestimmten Eigenschaften produziert. Ein Algorithmus löst dabei immer eine Klasse von Problemen.

• Terminierung: Ein Algorithmus muss bei allen möglichen Eingaben nach endlich vielen Schritten beendet sein und ein Ergebnis liefern.    • Finitheit: Die Beschreibung des Algorithmus muss endlich sein, ebenso wie der zur Ausführung benötigte Speicher.   • Effektivität: Alle Schritte eines Algorithmus müssen eindeutig und in einer endlichen Zeit ausführbar sein.   • Determiniertheit: Ein Algorithmus liefert bei den gleichen Eingaben immer das gleiche Ergebnis.   • Determinismus: Bei einer Ausführung ist zu jedem Zeitpunkt eindeutig festgelegt, welcher Schritt als nächstes ausgeführt wird.

Ein Algorithmus muss effektiv sein, d. h. in einer endlichen Zeit das Problem lösen. Häufig sind jedoch effiziente Algorithmen gesucht, die das Problem zum Beispiel in relativ kurzer Zeit oder mit wenig Speicher lösen.

Verfahrensbeschreibungen aus anderen Bereichen als der Informatik erfüllen oft nicht alle Eigenschaften, die wir von einem Algorithmus verlangen.

Noch viel früher in der Zeitrechnung als Al-Chwârismî entwarf im 3. Jahrhundert v. Ch. der Mathematiker Euklid aus Alexandria in Ägypten in seinem Buch „Die Elemente“ das noch heute gebräuchliche Verfahren zur Bestimmung des größten gemeinsamen Teilers zweier natürlicher Zahlen. Der nachfolgende Algorithmus bestimmt den größten gemeinsamen Teiler der positiven ganzen Zahlen a und b. 1. Wenn b > a ist, vertausche a und b. 2. Sei c der Rest der Division von a durch b. 3. Wenn c = 0 ist, dann ist der Algorithmus zu Ende und b das Ergebnis. 4. a wird der Wert von b zugewiesen und b der Wert von c. 5. Fahre mit Schritt 2 fort.

 Ein Algorithmus ist korrekt, wenn er sich bei der Ausführung so verhält, wie wir dies bei der Formulierung beabsichtigten. In kritischen Anwendungsbereichen wie der Flugsicherung, der Medizin oder der Prozesssteuerung können durch inkorrekte Algorithmen verursachte Fehlfunktionen katastrophale Schäden anrichten. Ein fehlerhafter Algorithmus in einem Chipentwurf kann erhebliche Kosten für den verantwortlichen Hersteller nach sich ziehen, wenn der Fehler erst nach Auslieferung der Prozessoren entdeckt wird.

Die Aufgabe eines Sortieralgorithmus besteht darin, eine gegebene Folge von Werten  

hd1, d2, d3, . . ., dni  

gemäß einer vorgegebenen Ordnung „≤“ in eine permutierte Folge:

hd ′ 1 , d ′ 2 , d ′ 3 , . . ., d ′ n i

zu bringen, sodass gilt:

d ′ 1 ≤ d ′ 2 ≤ d ′ 3 ≤ · · · ≤ d ′ n

Die Ausgangsreihe ist eine Permutation der Eingangsreihe.

Eine Permutation ist eine Umordnung einer Folge von Elementen in einer Weise, dass kein Element hinzugefügt wird oder verloren geht und auch kein Element verändert wird. Die Anzahl der Permutationen einer Folge mit n Elementen ergibt sich zu n! (Fakultät).

Die Komplexität eines Algorithmus befasst sich mit dem Mindestaufwand, den ein Algorithmus zur Lösung einer Aufgabe benötigt. Die Komplexitätstheorie untersucht sowohl den Rechenaufwand als auch den Speicherplatzbedarf. Beim Rechenaufwand ist nicht die effektive Ausführungszeit auf einem Rechner von Belang, sondern die Zahl der Bearbeitungsschritte in Abhängigkeit von der jeweiligen Eingangsgröße. Auf die Details der Komplexitätsbewertung von Algorithmen können wir im Rahmen dieses Kurse jedoch nicht weiter eingehen.

Es gibt noch eine Reihe weiterer Eigenschaften von Algorithmen und Programmen, wie Robustheit, Anpassbarkeit, Wiederverwendbarkeit, die je nach Anwendungsfall mehr oder weniger von Bedeutung sind. Unter Robustheit verstehen wir die Eigenschaft eines Algorithmus, auch in ungewöhnlichen Situationen definiert zu arbeiten, d. h. fehlerhafte und widersprüchliche Eingabedaten abzuweisen und auch umfangreiche Eingabedaten abzuhandeln. Der Aspekt Robustheit ergänzt den Aspekt Korrektheit, denn die Korrektheit betrifft das Verhalten eines Algorithmus im Rahmen der durch die Spezifikation erfassten Fälle und Bedingungen. Robustheit charakterisiert dagegen das Verhalten bei nicht spezifizierten Bedingungen.

Anpassbarkeit ist ein Maß für den Aufwand, mit dem ein Algorithmus an eine geänderte Spezifikation angepasst werden kann. Diese Eigenschaft ist vor allem für große Programmsysteme von erheblicher Bedeutung, weil die Auswirkungen von Änderungen an einer Stelle - anders als in kleinen Programmen - kaum zu überschauen sind.

Die Wiederverwendbarkeit drückt aus, wie einfach ein Algorithmus in vielen verschiedenen Anwendungen ohne Änderung benutzt werden kann.

Aktivität In der UML ist eine Aktivität ein benanntes Verhalten. Ein Aktivitätsdiagramm spezifiziert eine solche Aktivität.  

Eine solche Aktivität kann zum Beispiel das Verhalten einer einzelnen Methode widerspiegeln, aber auch grobgranularer ganze Geschäftsprozesse beschreiben. Im Rahmen des Kurses werden wir Aktivitäten für die Beschreibung einzelner Methoden verwenden

Innerhalb der Aktivität befinden sich die verschiedenen atomaren Kontrollknoten, die die Ausführungsreihenfolge der Aktionen festlegen. Diese sind mit gerichteten Kanten miteinander verbunden. Eine Aktion wird ebenfalls durch ein Rechteck mit abgerundeten Ecken dargestellt. Sie kann beispielsweise für den Aufruf einer Methode stehen, in diesem Fall wird entweder der Methodenname in die Aktion geschrieben oder das Verhalten anderweitig beschrieben. Die Beschreibung kann umgangssprachlich sein, wie zum Beispiel „Adresse erfassen“, oder auch formaler Natur in Form von Berechnungen „c = a + b“. Später werden wir zur Beschreibung solcher Aktionen auch Java-Quelltext verwenden. Im einfachsten Fall besteht eine Aktivität aus einer Sequenz mehrerer Aktionen. Dafür benötigen wir noch den Initial- und den Aktivitätsendknoten. Der Erste von beiden kennzeichnet den Beginn des Ablaufs und der Zweite markiert das Ende der Ausführung.

Entscheidung mit annotierten Entscheidungsverhalten

Ein Aktivitätsdiagramm mit einer enthaltenen Schleife (grau markiert).

Befinden sich zwei korrekte Java-Klassen Kunde und Rechnung in den beiden Dateien Kunde.java und Rechnung.java, so werden diese mit Hilfe des Java-Übersetzers in die beiden class-Dateien Kunde.class und Rechnung.class übersetzt.

Fehler, die zum Zeitpunkt der Übersetzung auftreten, sind syntaktische Fehler. Bei der Ausführung können sowohl Fehler auftreten, die das Programm zum Abbruch zwingen, als auch Fehler im Sinne von falschen Ergebnissen oder fehlerhaftem Verhalten.

Ein Modell ist die Abstraktion eines Realitätsausschnitts oder eines Systems. Ein Modell wird mit Hilfe einer Modellierungssprache beschrieben.

Will man beispielsweise ein Modell für ein Universitätsverwaltungssystem entwickeln, so interessiert dabei der Name, der Geburtstag und die Adresse der Studierenden, nicht aber ihre Haarfarbe oder ihre Lieblingsfarbe. Das heißt, in diesem Modell wird von einigen Eigenschaften der Studierenden abstrahiert.

Die Unified Modeling Language (UML) ist eine in der Softwareentwicklung weit verbreitete Modellierungssprache. Sie unterstützt die verschiedenen Phasen des Entwicklungsprozesses. Wir werden im Laufe des Kurses einige Elemente der UML kennen lernen und nutzen.

Um die Beschreibung verschiedener Sichten zu ermöglichen, definiert die UML Verhaltensdiagramm dreizehn Diagrammarten, die wiederum in Verhaltens- und Strukturdiagramme unterteilt werden. Verschiedene Sichten ermöglichen die Modellierung und Betonung verschiedener Aspekte eines Systems. 

• die Handlungsträger, • ihr Zusammenwirken und • ihre für die Geschäftsabläufe wesentlichen Handlungen zu erkennen, • die Informationen, die sie austauschen, nachzuvollziehen, • die Gegenstände, mit denen sie umgehen, sowie • die Beziehungen, die zwischen diesen Gegenständen bestehen, zu beschreiben und • erste Ideen zu diskutieren, wie die Geschäftsvorfälle durch Computer unterstützt werden können.

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 seiner Benutzerin erforderlich sind und dazu beitragen, bestimmte Ziele der Benutzerin zu erreichen. Anwendungsfälle werden durch Anwender oder durch Zeitereignisse angestoßen.

Mögliche Anwendungsfälle in unserer Fallstudie sind zum Beispiel die Bestellung bei einem Großlieferanten, die Erfassung einer neuen Premiumkundin oder der Verkauf beliebig vieler Artikel. Diese Anwendungsfälle werden durch die zuständige Mitarbeiterin oder eine Kundin angestoßen.

Anwender und externe Systeme, die an Anwendungsfällen teilnehmen, aber selbst nicht Teil des zu realisierenden Systems sind, werden als Akteure (engl. actor) bezeichnet.

Mögliche Akteure in unserer Fallstudie sind Großlieferanten, die Chefin, Verkäufer, Kunden und Premiumkundinnen sowie der Kurier

Die Teilnahme eines Akteurs an einem Anwendungsfall wird durch eine Assoziation zwischen beiden ausgedrückt. Andere Beziehungen zwischen Akteuren und Anwendungsfällen gibt es nicht.

Ein UML-Anwendungsfalldiagramm beschreibt grafisch die Zusammenhänge zwischen einer Menge von Akteuren und Anwendungsfällen. Ein solches Diagramm besteht aus: • dem System, dargestellt als Rechteck, wobei der Name des Systems im Rechteck steht; • Anwendungsfällen, die als Ellipsen innerhalb des Systems erscheinen und die Bezeichung des Anwendungsfalls enthalten; • Akteure, die als Strichmännchen außerhalb des Systems dargestellt werden, wobei der Name des Akteurs unter das Symbol geschrieben wird; • Assoziationen zwischen Akteuren und Anwendungsfällen, die durch Linien dargestellt werden; • Beziehungen zwischen Akteuren und Anwendungsfällen untereinander.

Die Abbildung zeigt das System, einige Anwendungsfälle, Akteure und ihre Assoziationen untereinander. Die Assoziationen geben an, welche Akteure an welchen Anwendungsfällen beteiligt sind.

Wie die Abbildung veranschaulicht, kann eine Premiumkundin genauso wie ein Kunde direkt im Laden etwas kaufen, sie kann aber darüber hinaus auch etwas telefonisch bestellen und umsonst nach Hause liefern lassen. Eine Premiumkundin ist somit eine Spezialisierung eines Kunden und ein Kunde eine Generalisierung einer Premiumkundin. Ebenso kann eine Chefin die gleichen Aufgaben wie eine Verkäuferin übernehmen, aber eben auch die Bestellungen beim Lieferanten erledigen. Somit handelt es sich bei einer Chefin um eine Spezialisierung von Verkäuferin.

Der Anwendungsfall „Artikelverkauf“ enthält beispielsweise den Anwendungsfall „Bezahlung“.

Eine solche Beschriftung in spitzen Klammern (<<...>>) bezeichnet man in der UML als Stereotyp. Solche Stereotypen kommen bei verschiedenen Elementen zum  Einsatz

Fällt während des Verkaufs eines Artikels auf, dass er gar nicht oder nicht in ausreichender Menge vorhanden ist, so muss eine Nachbestellung erfolgen. Die Bestellung eines Artikels erweitert somit den Verkauf eines Artikels.

Bisher hatten wir nur den allgemeinen Anwendungsfall Bezahlung. Es sollen jedoch laut Fallstudie Barbezahlung, Bezahlung mit Kreditkarte oder per Rechnung möglich sein. Diese Anwendungsfälle können wir als Spezialisierung von Bezahlung modellieren.

So kann ein Anwendungsfall jedes Bezahlverfahren zulassen. Dieser hat dann eine Enthält-Beziehung zum Anwendungsfall Bezahlung, ein anderer wiederum lässt zum Beispiel nur Barbezahlung zu und besitzt deswegen nur eine Enthält-Beziehung zum Anwendungsfall Barbezahlung. Da der Anwendungsfall Bezahlung eine Assoziation zum Akteur Kunde hat, besitzen diese Beziehung auch implizit alle spezielleren Anwendungsfälle.

Wir nennen eine einzelne Abfolge von Aktionen, d. h. einen Ablaufpfad in einem Anwendungsfall, ein Szenario. Ein Szenario, das die Sicht der Anwender wiedergibt, fasst das zu entwickelnde System als Blackbox auf. Die innere Arbeitsweise des Systems bleibt den Anwendern verborgen, von Interesse ist allein das externe Verhalten. Das Augenmerk liegt bei dieser Perspektive auf typischen Interaktionen zwischen Benutzern und dem Anwendungssystem.

Für die Beschreibung der in Anwendungsfällen auftretenden Interaktionen werden Beschreibungsschema wir das in Tabelle angegebene Schema verwenden.