[Home | OOP]

 

Ziel des Analyseprozesses ist es, ein System von Objekten zu finden und zu arrangieren, die im gemeinsamen Zusammenspiel das reale System (Fachkonzept) abbilden und die gestellte Aufgabe mit verteilten Verantwortlichkeiten erledigen.

Damit ist im Grunde die Aufgabe der OOA beschrieben, die bei allen Analysemethoden ähnlich abläuft: zunächst sind die Objekte und Klassen zu finden, dann ihre Attribute und Funktionen zu bestimmen und zuletzt die Beziehungen der Objekte untereinander festzulegen.

Trennung von Anwendung und Benutzungsoberfläche

Dabei ist von vornherein zwischen der Anwendung (Fachklassen) und der Benutzungsoberfläche strikt zu trennen. Nach dem Siegeszug der grafischen Benutzeroberflächen konnte man zum großen Teil Programme wegwerfen, die zwar die Funktionen der Anwendung gut oder sehr gut erfüllten, die aber wegen der fehlenden Trennung dieser Aspekte nicht umgestellt werden konnten. Ich wage die Prophezeiung, dass es bei der nächsten Generation von Computern, die über Sprache oder Augenkontakt mit dem Benutzer kommunizieren werden, das gleiche wieder eintreten wird, wenn dieses Konstruktionsprinzip nicht eingehalten wird.

Abgrenzung zwischen Analyse und Design

Nach Balzert, H.: Methoden der objektorientierten Systemanalyse, 1996:

Bei der objektorientierten Entwicklung fällt es manchmal schwer, die  Phasen gegeneinander abzugrenzen, insbesondere, wenn man eine Grafikanwendung entwickelt. Als Faustregel kann gelten, dass in der

• OOA festgelegt wird, WAS das System tun soll und im

• OOD festgelegt wird, WIE es es tun wird.

Für das OOA-Modell bedeutet dies, dass es

• keine technischen Lösungen,

• keine Optimierungen im Hinblick auf die Zielsprache,

• keine Objektverwaltung (Persistenz) enthält,

• alle Assoziationen im ersten Anlauf als bidirektional ansieht.

Beispiel: OOA - Modell Patientenverwaltung PAT 99

(vgl. OOD Modell)