Softwareentwicklung in C++ - ASC

148 8. Objektorientierung Allgemein
• Sie besteht aus mehreren verschiedenen festen und flüssigen Nahrungsmitteln
in verschiedenen Zuständen (z.B. warm/kalt). Die Zusammenstellung
ist beliebig.
Fahrzeug: Die Beteiligung des Fahrzeugs wird hier erwähnt für den Fall,
dass die Person nicht zu Fuß zur Arbeit geht. Es gibt verschiedenste
Ausprägungen von Fahrzeugen, z.B. Fahrrad, Auto, Bus, etc., die alle
ganz verschiedene Eigenschaften haben. Eine Eigenschaft ist ihnen allen
gemeinsam: sie sind Fortbewegungshilfen, die man entsprechend ihrer
anderen Eigenschaften verwenden kann.
Gebäude: Ein Gebäude ist ein beliebiges Bauwerk mit vielen möglichen Eigenschaften.
Eine der Grundeigenschaften ist, dass es einen oder mehrere
Räume beinhaltet und (hoffentlich...) zumindest einen Ein- bzw. Ausgang
hat.
Arbeitsplatz: Obwohl der Arbeitsplatz zuvor implizit in ein Gebäude verlegt
wurde, muss das natürlich nicht sein. Ein Arbeitsplatz ist ein beliebiger
Platz mit der einzigen Eigenschaft, dass man dort zumindest zeitweise
seine Arbeit verrichtet.
Ich habe zuvor bewusst ganz einfach hingeschrieben, dass man in das
Gebäude hineingeht und den Arbeitsplatz ansteuert, um zu zeigen, wie
leicht man einen Designfehler begehen kann! Würde man diese Analyse
hier nicht durchführen, kann es nur allzu leicht passieren, dass eine Eigenschaft
eines Arbeitsplatzes ist, dass er in einem Gebäude liegt. Das
ist ganz einfach falsch! Man stelle sich vor, dass eine solche Fehlannahme
Eingang in eine Softwarearchitektur findet und plötzlich muss man
mittels dieser Architektur einen Förster modellieren, der seine Arbeit im
Wald verrichtet... womit sofort die nächste Fehlannahme auffällt: Es
wurde auch impliziert, dass der Weg zur Arbeit zu einem Gebäude führt.
Das ist aber auch nicht zwingend!
Vorsicht Falle: Man sieht, selbst bei einer sehr groben Modellierung eines
völlig alltäglichen Ablaufs kann es schon zu Fehlern kommen. Je detaillierter
man Abläufe beschreibt, umso mehr Chancen hat man, solche Fehler auch
wirklich sofort zu lokalisieren und zu korrigieren. Dies macht man so lange,
bis man im Groben einmal ein schlüssiges Modell von Beteiligten und Interaktionen
zwischen diesen hat. Die Abstraktionsebene darf man dabei nicht
verändern, man steht immer noch als Beobachter außerhalb des Problems
und analysiert das Gesamtmodell.
Im Normalfall modelliert man auch nicht nur einen einzelnen Ablauf, wie
es hier der Fall ist, sondern man modelliert eine ganze Reihe von sogenannten
Use-Cases. Jeder Use-Case ist ein ganz bestimmter Prozess, der mit bzw. in
einem System durchführbar sein muss. Aus der Analyse aller dieser Use-
Cases ergibt sich dann das grobe Gesamtmodell.
Sobald das Modell schlüssig ist, geht man einen Schritt in die Tiefe.
Je nach Problemstellung gibt es verschiedene Interpretationen, was nun ein