Python 3 - Lernen und professionell anwenden

327

Kapitel 12

Objektorientiertes Modellieren

Objektorientiertes Programmieren hat immer etwas mit Modellieren zu tun. Nicht selten

sind objektorientierte Programme vereinfachte Abbildungen eines Wirklichkeitsausschnitts.

Häufig lassen sich Programmierer auch einfach nur von der Realität inspirieren und ver-

wenden Dinge der Welt als Metaphern, um die Struktur ihres Programms möglichst

anschaulich und einleuchtend zu gestalten, ohne besondere Realitätsnähe anzustreben.

In diesem Kapitel sprechen wir die Phasen der objektorientierten Software-Entwicklung an

und skizzieren an einem Beispiel den Weg von der objektorientierten Analyse einer Pro-

blemstellung bis zum fertigen objektorientierten Programm.

Bisher haben wir nur einzelne Klassen definiert. Ein vollständiges objektorientiertes Pro-

gramm besteht (in der Regel) aus einem ganzen Ensemble von Klassen, die aufeinander

abgestimmt sind und deren Objekte während des Programmlaufs interagieren. Zwischen

den Objekten der Klassen gibt es Beziehungen oder Assoziationen. In den Beispielen dieses

Kapitels werden die wichtigsten Typen von Assoziationen beschrieben. An dieser Stelle ein

Hinweis: In der Web-Dokumentation zu diesem Buch finden Sie noch weitere Beispiele für

objektorientierte Modellierung wie z.B. die Modellierung von Wegesystemen mit Graphen.

12.1 Phasen einer objektorientierten Software-Entwicklung

Die Entwicklung einer Software kann ein aufwändiger und langwieriger Prozess sein, an

dem – bei größeren Projekten – viele Personen beteiligt sind. Um diesen komplexen Vor-

gang einigermaßen überschaubar und beherrschbar zu machen, gibt es aus dem Software-

Engineering Ablaufmodelle, an denen man sich orientieren kann. Ein bekanntes Modell

unterscheidet folgende Phasen:

Objektorientierte Analyse (OOA)

Hier geht es um die Analyse eines Wirklichkeitsausschnitts, der durch ein Software-System

abgebildet werden soll. Gemeinsam mit den zukünftigen Anwendern und Fachexperten mit

Spezialkenntnissen über den zu modellierenden Realitätsbereich wird das erwünschte Ver-

halten des Systems festgelegt und umgangssprachlich beschrieben. Klassen und Beziehun-

gen zwischen ihnen werden herauskristallisiert und benannt – zunächst noch losgelöst von

der Syntax einer konkreten Programmiersprache. Man gelangt zu einem abstrakten Modell,

das man als UML-Klassendiagramm formalisieren kann, das aber noch völlig frei ist von

Aspekten der technischen Realisierung.

Objektorientierter Entwurf (OOD)

Im Entwurf (Object Oriented Design, OOD) wird das abstrakte OOA-Modell konkretisiert und

verfeinert. Erstmals werden Gesichtspunkte der technischen Realisierung und der Effizienz