 |
Objektorientierte
Analyse (OOA) Analyseprozeß |
S. Spolwig |
|
Der Analyseprozeß - Einleitung Die Grundregel lautet:
Jedes Analyseobjekt hat seine Entsprechung in der natürlichen realen Welt und übernimmt dessen Identität im Modell. "Deshalb verbringen objektorientierte Entwerfer normalerweise ihre Zeit nicht mit akademischen Diskussionen über Methoden, wie Objekte zu finden sind: In der physikalischen und abstrakten Wirklichkeit sind die Objekte modelliert und warte nur darauf, aufgelesen zu werden" [MEYER]. Das Analyseobjekt ist charakterisiert durch Attribute (z.B. Name des Kunden) und Operationen, mit denen es Leistungen anbieten und Aktionen ausführen kann. Das Attribut entspricht dem im Entity Relationship Model (ERM), mit dem Unterschied, daß das Analyseobjekt als Attribut selbst wieder ein Objekt, sprich eine komplexe Datenstruktur sein kann, was bei der Modellierung von relationalen Datenbanken, der klassischen ERM-Domäne, nicht erlaubt ist. Ein objektorientierter Entwurf kennt nur Klassen, deshalb sind die gefundenen Objekte, die als Analyseobjekte bezeichnet werden, darauf zu untersuchen, ob sie einer Klasse zugeordnet werden können oder selbst eine Klasse darstellen. Da der Begriff Objekte in der Informatik mit unterschiedlicher Semantik verbunden ist, wird er hier in diesem Sinne gebraucht und nicht explizit zwischen Klasse und Objekt unterschieden. Ziel des Entwurfsprozesses ist es, ein System von Objekten zu finden und zu arrangieren, die im gemeinsamen Zusammenspiel das reale System nachbilden 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. Um die abzubildenden Objekte zu finden, bieten sich zwei praktisch bewährte Methoden an, die einzeln oder auch zusammen angewendet werden können: Analyse und Gestaltung der Bedienungsoberfläche Eine sorgfältige Analyse und Gestaltung der Bedienungsoberfläche gibt Aufschlüsse über die im System beteiligten Objekte. Dazu ist es nicht schlecht, zunächst einen Entwurf aller Bildschirme, die das System zeigt, anzufertigen. Häufig sind Gegenstände grafisch dargestellt, die Objekte des Systems repräsentieren, z.B. Schachbrett und Figuren, aber auch Buttons, Eingabefelder, Menüs für die Bedienung. Ein- und Ausgaben weisen auf Geräte, Baugruppen, Teile aus der Realwelt hin, z. B. in der Simulation eines Fahrkartenautomaten, Geldwechslers u. ä. Von dieser Methode wurde beim Programm FAHRSCHEINAUTOMAT mit gutem Erfolg Gebrauch gemacht, weil sie sich insbesondere bei Simulationen anbietet. Die gefundenen vorläufigen Objekte sollen in zwei Gruppen geteilt werden: GUI-Objekte zur Bedienung und Systemsteuerung und die Objekte, die das eigentliche Anwendungsproblem abbilden, nämlich die der Fachklassen.
Finden von Objekten am Beispiel Fahrscheinautomat Textanalyse der Anforderungsdefinition Als eine gut geeignete Methode wird für den Unterricht empfohlen, den Text der Anforderungsdefinition auf Nomen und Nominalsätze als Kandidaten für Objekte und auf Verben als Kandidaten für die Operationen zu untersuchen. Diese Methode wird im folgenden näher beschrieben, sie gilt in Teilen natürlich auch für die erstere. Der Entwurfsprozeß erfolgt in drei Schritten:
1. Bestimmung der Klassen: welche Objekte gibt es im System? Die Aufgabe besteht darin, die Anforderungsdefinition zu lesen (oder zu schreiben) und auf Kandidaten für Objekte zu untersuchen:
Bevor nun später alle gefundenen Objektklassen neu entwickelt und gebaut werden, prüft man, ob es nicht in der vielleicht schon vorhandenen Objektbibliothek oder in anderen Programmen fertige gibt, die man übernehmen und wieder verwenden kann.
Eine gewisse Schwierigkeit liegt darin, daß mitunter unklar ist, ob man es mit einem Attribut oder vielleicht sogar mit einem selbständigen Objekt zu tun hat. Dafür bleibt am Ende nur ein Trost - man muß sich nachvollziehbar entscheiden. Die im ersten Anlauf gefundene Klassenstruktur wird sicher nicht das endgültige Ergebnis sein. Im Verlauf der Modellierungsphase wird es immer Änderungen aus neu gewonnen Sichtweisen geben. Am Ende der Modellierungsphase sollte aber ein stabiler Entwurf vorliegen. Wenn schwere Fehler erst bei der Implementation entdeckt werden, kann es problematisch werden. 2. Bestimmung der Verantwortlichkeiten der Objekte: Was tun sie, was kann man mit ihnen tun? Es ist die Frage zu beantworten, welches Wissen die Objekte haben und für welche Operationen sie deshalb zuständig sind. In einigen Veröffentlichungen werden diese Verantwortlichkeiten auch Dienste genannt, die die Objekte anderen andienen. Hier werden also die Methoden festgelegt. Verhalten und Informationen sollen möglichst an einer Stelle abgelegt werden. Deshalb gilt:
Die Anforderungsdefinition wird noch einmal gelesen und untersucht auf Verben, die irgendwelche Aktionen beschreiben. Diese heraussuchen und auflisten. Es gilt auch hier, daß jedes Objekt zunächst für sich betrachtet wird. Wenn die Anforderungsdefinition dennoch nicht genug hergibt, überlegt man die Rolle, die jedes Objekt im System spielt und notiert ihre Aktivitäten. Die Verantwortlichkeiten sind dann den Objekten zuzuordnen z.B. "XYZ weiß, wie ...."; XYZ weiß, was .... ". Bei der Beschreibung der Verantwortlichkeiten und Dienstleistungen, die ein Objekt hat oder anbietet, werden nur die öffentlich zugänglichen und zu exportierenden aufgeführt. Die privaten werden hier noch nicht spezifiziert. Bei unklaren Beschreibungen hilft oft die Frage, wer verantwortlich ist. Die Anforderungsdefinition ist dann umzuformulieren! Die Analyse der Verantwortlichkeiten verläuft in zwei Schritten:
Zu unterscheiden ist, ob es sich um öffentliche Verantwortlichkeiten handelt, die zu exportieren sind oder um private Aktivitäten/Operationen. Für die Verknüpfung spielen nur die öffentlichen eine Rolle. Bei der OOA kann man das Gesamtsystem als ein Spiel mit verteilten Rollen betrachten, bei dem eine Vielzahl von Akteuren mit ein paar Aktionen, für die es nur selbst verantwortlich ist, mitwirken. Daher sollte es als Objekte nicht Riesen und Zwerge oder Superbrain und Idioten geben, sondern die "Intelligenz" ist zu verteilen; z.B. die gesamte Steuerung nicht in einem Objekt/Modul konzentrieren, sondern in Teilaufgaben anderen Objekten zuordnen, wenn sie dafür geeignet scheinen. 3. Bestimmung der Verknüpfung zwischen den Klassen: Wo kann ich was erben? Es können im wesentlichen drei Beziehungsarten unterschieden werden: gerichtete, ungerichtete Beziehungen und Vererbungsbeziehungen, die hier betrachtet werden, weil sie das Prinzip gut darstellen. Das Beziehungsgeflecht der Objekte/Klassen stellt die Gesamtarchitektur des Systems dar. Um dahin zu kommen, sind folgende Fragen zu beantworten:
von welcher Klasse kann sie die erforderlichen Hilfsmittel übernehmen? Sofern Hilfsmittel von einer anderen Klasse benötigt werden, liegt zwischen ihnen eine Beziehung vor. Für die praktische Entwurfsarbeit kann man für jede Klasse eine Karteikarte anlegen mit Eintragungen für Klassenname, Attribute und Methoden (Verantwortlichkeiten).
Durch Herumschieben der Karten versucht man Beziehungen und Zuordnungen aufzudecken, die dann in einer Skizze festgehalten werden. Die Frage ist, was man unter Modellierung versteht, ob es z. B. nur darum geht, daß ein Würfel in einem Spiel nur eine einzige Zahl liefert, weil letztlich nur dieses das gewünschte Ergebnis ist. Dann würde man einen Typ benötigen wie:
Die andere Alternative ist, den Würfel als Gegenstand mit Eigenschaften zu verstehen, die als Attribute beschrieben und modelliert werden, also TWuerfel = OBJECT
Offensichtlich kommt es darauf an, herauszufinden, welche von diesen Attributen tatsächlich gebraucht werden und welche nicht. Dieses ist die Aufgabe der Abstraktion. Ganz sicher sind immer solche Attribute notwendig, wenn auf sie schreibend zugegriffen werden soll. Wenn mit dem Würfel eine echte Darstellung erreicht werden soll auf dem Bildschirm, z. B. daß der Würfel sich bewegt, dann muß offensichtlich die grafische Darstellungsweise mit beschrieben werden. Wenn es nur darum geht, für ein Spiel eine bestimmte Punktzahl zu bekommen, würde die magere Variante ausreichen. Wie sieht es mit den Benutzt-Beziehungen beim Würfelspiel aus? Der Würfel habe eine Methode Werfen, die ihn auf dem Bildschirm rollen läßt und dann das Endergebnis anzeigt. Wenn es einen Spieler gibt als Modul, benutzt der Spieler dann den Würfel; d.h. importiert das Modul Spieler das Modul Würfel und ruft die Prozedur 'werfen' auf? Oder wird die Prozedur 'werfen' durch das Steuermodul oder den Spielleiter aufgerufen? Bei einer Nachbildung der Realität wäre es allerdings nahe liegender zu sagen, daß der Spieler den Würfel benutzt, also WUERFEL assoziiert und die Methode 'werfen' aufruft: SPIELER Hiermit soll noch einmal verdeutlicht werden, daß es sich bei der Entwicklung eines Softwaresystems um Entwurfsentscheidungen handelt. Es gibt keine 100% Lösungen in diesem Bereich. Es gibt bessere, schlechtere, elegantere. Genau das macht den Reiz der Sache und des Informatikunterrichts aus. Während in der Analysephase die Objekte der Problemwelt betrachtet und gefunden werden sollen, um eine möglichst stabile und dauerhafte Klassenstruktur zu erstellen, wird in der Designphase das Augenmerk mehr darauf gerichtet, wie das lauffähige Programm selbst organisiert sein soll. Das scheint zunächst ein Widerspruch zu sein, denn der Anspruch der OOA ist ja, eine Abbildung der Problemwelt auf dem Rechner zu liefern. Jedoch sagt eine Analyseklasse 'Personal' mit der Methode 'erfassen' noch nichts über die Realisierung, Implementation oder die Repräsentation der Datenstruktur auf dem Rechner aus. Ziel der Designphase ist, einerseits eventuell die Klassenstruktur zu
verfeinern, andererseits die Objekthierarchie so zu gestalten, daß die
Implementation möglichst problemlos von vonstatten geht. Daneben
müssen häufig Entscheidungen über die Datenhaltung, Speichermethoden,
über Fehler- und Ausnahmebehandlungen getroffen werden. |
Das einzige Strukturierungsmittel ist das Objekt.