Fachkonzept - OOM

Ein Modell der Realität

Modelle kennst Du aus verschiedensten Bereichen. In der Biologie benutzt man Modelle des Menschen, in der Chemie beschreibt man Prozesse mit Hilfe von Atommodellen, im Garten lässt man ein Modell eines Flugzeugs fliegen. Allen ist gemeinsam, dass das Modell die Realität vereinfacht. Außerdem ist ein Modell immer nur für einen bestimmten Zweck geeignet. Man kann nicht sagen, dass ein Modell gut oder schlecht ist. Man kann nur sagen, dass ein Modell gut oder schlecht geeignet ist, um eine konkrete Aufgabe zu lösen.

Betrachten wir das Modell eines Menschen einmal genauer. Die Abbildung zeigt ein Modell eines Menschen, so wie es wahrscheinlich in jeder Biologiesammlung einer Schule vorhanden ist. Wahrscheinlich würdest Du intuitiv zustimmen, dass das Modell recht detailliert und gut ist. Wenn man z.B. zeigen möchte, warum ein Mensch seine Beine nur nach hinten, aber nicht nach vorne beugen kann, lässt sich das sehr gut mit Hilfe des Modells erklären. Auch lässt sich vorhersehen welche Knochen bei einem Sturz auf die Seite besonders gefährdet sind. Stellt man sich aber die Frage, wie das menschliche Auge funktioniert, hilft einem dieses Modell gar nicht weiter. Für diesen Fall ist eine einfache Blechdose mit einem kleinen Loch besser geeignet, obwohl man hier intuitiv nicht von einem guten Modell sprechen würde.

Man muss sich bei der Modellierung also immer fragen: Welche Informationen möchte ich aus dem Modell ableiten?

Objektorientierte Modellierung (OOM)

Bei der objektorientierten Modellierung geht es darum, Ausschnitte aus der realen Welt zu erfassen und in Form von Software-Objekten zu beschreiben. Jedes Objekt repräsentiert ein Ding aus der Wirklichkeit, das bestimmte Eigenschaften und Fähigkeiten besitzt. Bei der Modellierung geht es noch nicht darum, wie die Software genau implementiert wird, sondern darum, die Struktur und das Verhalten der Objekte zu planen.

Wir identifizieren zunächst die relevanten Objekte und überlegen, welche Attribute (Eigenschaften) und Methoden (Fähigkeiten) sie haben sollten. Objekte gleicher Struktur und Funktionalität werden in Klassen zusammengefasst, die als Baupläne für die Objekte dienen.

Bei den Attributen machen wir uns auch Gedanken über die Datentypen, also darüber, welche Art von Informationen gespeichert werden soll (z.B. Text, Zahlen, Wahrheitswerte). Bei den Methoden überlegen wir, welche Antwort sie liefern, also welchen Rückgabetyp sie haben sollen. Außerdem geben wir an welche Informationen Methoden zusätzlich benötigen, also welche Parameter sie erwarten und welchen Datentyp diese Parameter haben sollen.

Oft stellt man die Modellierung grafisch in Form von Klassendiagrammen dar. Klassendiagramme (und einige andere Diagrammtypen) sind in der Unified Modeling Language (UML) standardisiert, einem weit verbreiteten Notationssystem für die Softwaremodellierung.

Ein Software-Roboter

Stell dir einen Roboter vor, den du programmieren möchtest. Was muss der Computer über ihn speichern? Was soll er tun können?

Ein Roboter könnte zum Beispiel Attribute wie einen Namen und den aktuellen Ladezustand seiner Batterie haben. Er könnte Methoden besitzen, um zu laufen, sich zu drehen oder sich auszuschalten. Außerdem kann er eine Methode haben, die prüft, ob vor ihm ein Hindernis ist.

Außerdem möchten wir festlegen, dass bei der Erzeugung eines Roboters - also beim Aufruf des Konstruktors - der Name des Roboters angegeben werden muss. Da es keinen speziellen Bereich für Konstruktoren im Klassendiagramm gibt, schreiben wir Konstruktoren im Bereich der Methoden mit auf. Ein Konstruktor ist aber eigentlich keine Methode, da man diesen zur Erzeugung eines Objekts benötigt, während Methoden erst auf einem bereits existierenden Objekt aufgerufen werden können.

Im Klassendiagramm wir dies dann folgendermaßen dargestellt:

Die allgemeine Struktur eines Klassendiagramms lässt sich also wie folgt zusammenfassen:

Wenn der Konstruktor keine Parameter besitzt, wird er üblicherweise nicht mit aufgelistet. Man kann ihn aber auch angeben, um zu verdeutlichen, dass der Konstruktor keine Parameter besitzt.

Quellen

• Foto: Skelett - Urheber: Mikael Häggström, Dake - Lizenz: CreativeCommons BY-SA 3.0