| | |
Objektorientierte Analyse | | |
Wie ich schon in der Einleitung erläutert habe, besteht eine
der Innovationen der Objektorientierung gegenüber den frü-
heren Herangehensweisen in der Softwareentwicklung darin,
eine Konzeptsicht anzubieten, die sich stark daran anlehnt,
wie wir Menschen tatsächlich komplexe Systeme begreifen.
Wenn wir uns komplexe Systeme wie zum Beispiel unsere
Galaxie anschauen, dann wenden wir intuitiv Methoden der
Komplexitätsbewältigung an, denn es ist uns nicht möglich,
die Gesamtheit eines so großen Systems auf einmal zu erfas-
sen. Anstatt also in unserer Galaxie einzelne Planeten zu
suchen, unterteilen wir z. B. zunächst Sonnensysteme. Wir
verwenden also Aussagen wie »besteht aus«. Eine Galaxie
besteht also unter anderem aus Sonnensystemen. Auch ein
Sonnensystem besteht wieder aus weiteren Elementen, näm-
lich einer Sonne und Planeten. Auch bezüglich der Planeten
haben wir wieder Planetensysteme, die aus dem Planeten
und eventuellen Monden bestehen. | How I already proposed in at the beginning, | |
Außerdem sind wir gut darin, Dinge zu abstrahieren. Anstatt
immer wieder jedes Ding bei seinem konkreten Namen auf-
zuzählen, bilden wir Abstrahierungen wie »Menschen«,
»Bäume«, »Autos« usw. Wohl wissend, dass es viele unter-
schiedliche Autos gibt, sie aber alle einem gemeinsamen abs-
trakten Konzept angehören, das wir Auto nennen. Man kann
das als eine »Ist ein«-Aussage bezeichnen. Diese Art, unsere
Umwelt zu begreifen, lernen wir schon früh, und wir kom-
men gut klar damit. Was liegt also näher, sich diese Vorge-
hensweise konkret zu eigen zu machen, wenn wir komplexe
Systeme beschreiben wollen, für die wir Softwareanwendun-
gen entwickeln wollen? | | |
In der objektorientierten Analyse nähern wir uns deswegen den Anforderungen (die ja
letztlich nichts anderes als Beschreibungen des komplexen Systems sind, mit dem wir es in
unserem Projekt zu tun haben) aus den beiden genannten Richtungen an, einmal der
Beschreibung »besteht aus« und einmal der Beschreibung »ist ein«. | | |
Nun ist das einfacher gesagt als getan. Wo fängt man an? Nehmen wir mal wieder ein Bei-
spiel, einen Videoverleih. Wo soll man bei einem Videoverleih anfangen, Objekte zu model-
lieren, wenn man noch nichts über das System weiß? Erfahrenen Programmierern fällt das
vielleicht etwas leichter, aber normalerweise wissen die erfahrenen Programmierer noch zu
wenig über das System, um das es geht, und auf Auftraggeberseite wiederum sitzen nur
selten erfahrene Programmierer. In der Praxis hat sich deswegen bewährt, sich dieser Auf-
gabe über ein weiteres Hilfsmittel zu nähern, der Beschreibung von Anwendungsfällen.
Das Gute an der Erstellung von Anwendungsfällen ist, dass jeder daran teilnehmen kann,
auch und gerade Mitarbeiter auf Auftraggeberseite ohne Softwareprojekterfahrung, denn
es sind dazu keine speziellen Kenntnisse erforderlich. Auftraggeber und Auftragnehmer
beschreiben hierbei kleine, in sich geschlossene Szenarien, wie die späteren Nutzer inner-
halb des komplexen Systems interagieren. Es wird hier nicht alles auf einmal beschrieben,
stattdessen pickt man sich einzelne Abläufe heraus. Für unser Online-Videoverleih-Projekt
könnte so ein Ablauf z. B. sein: »Kunde leiht sich ein Video aus« (wie das konkret gemacht
wird, erläutere ich weiter unten im nächsten Abschnitt). | | |
