Einführung in die objektorientierte Analyse

Diese Einführung in die objektorientierte Systemanalyse ist erstellt worden für die Konferenz der deutschsprachigen FoxPro User Group. Es werden nur dem Autor zum Verständnis wichtig erscheinende Themen und Zusammenhänge dargestellt. Es wird kein Anspruch auf Vollständigkeit und absolute Richtigkeit der Darstellung erhoben. Vielmehr bemüht sich der Autor um die Vermittlung von Denkansätzen, Einblick in die Vorgehensweise und Begriffsklärungen mit Hinweis auf weiterführende Literatur. Diese schriftliche Darstellung wird ergänzt durch einen Vortrag des Autors. Dieser Text darf weiterverwendet werden unter der Voraussetzung der Weitergabe dieses Vorwortes und Nennung des Autors. Desweiteren befindet sich im Begleitmaterial ein Anhang als Dokument mit ergänzenden Angaben zum Vortragsthema.

Einführung

Softwaresysteme werden in Folge der verfeinerten Möglichkeiten, insbesondere der Grafischen , und den immer größeren Anforderungen an die Benutzeroberfläche und Stabilität, immer komplexer. So mal eben etwas von einer Schreibmaschine (Telex) einlesen, verarbeiten und ein paar Zeilen auf einer Schreibmaschine ausgeben, ist heute in der Form nicht mehr erwünscht. Auch hat sich der Benutzer von Softwaresystemen stark gewandelt. Waren es früher hoch spezialisierte Fachleute, so sind es heute Menschen aus allen Bevölkerungsschichten die Umgang mit einem Computer (PC) haben. Dies bedarf eines anderen Softwaredesign, und höheren Anforderungen an die Einfachheit der Handhabung von Software.

Die um Potenzen gestiegene (und weiter steigende) Komplexität der Software erfordert neue Techniken in der Erzeugung derselben. Das spiegelt sich wieder zum einen, in Programmiersprachen die heute wesentlich leistungsfähiger sind als ihre Vorgänger, leistungsfähigeren Betriebssystemen und einhergehend damit auch Planungsinstrumenten die leistunsgfähiger werden mußten um die neuen Möglichkeiten zum einen zu Nutzen und zum anderen aber auch um die komplexeren Systeme „im Griff“ zu behalten .

Es ist bekannt, daß gute Software nur von guter Planung kommt, ähnlich dem Bauwesen und dem Maschinenbau, wo Planung schon seit Jahrhunderten, gar Jahrtausenden ein notwendiges Instrument ist. Das schließt zwar eine Fehlplanung nicht hundertprozentig aus, wir alle haben schon von irgendwelchen Planungsfehlern gehört, aber insgesamt erhöht sich die Qualität eines Produktes erheblich, wenn es vernünftig, Ingenieurmäßig, nach erprobten Methoden geplant und produziert wurde. Das alles gilt für komplexe Softwaresysteme in verstärktem Maße.

Der vorherige Softwareerstellungsprozeß und die damit einhergehende Planung reichte nicht mehr aus, um den neuen Anforderungen im zeitlichen Rahmen und unter Berücksichtigung der menschlichen Resourcen, gerecht zu werden. Man hat sich bei der Suche nach besseren Methoden, wie immer, an der Natur orientiert. Und siehe da, man (schon Plato) stellte bei genauerem hinsehehen fest, daß unser Universum aus Objekten besteht. Diese Objekte haben bestimmte Eigenschaften und die Objekte tauschen untereinander Nachrichten aus. Objekte reagieren auf Nachrichten mit Methoden die in ihnen gespeichert sind. Darwin hat sich um Klassifizierung in größerem Stil bemüht und die Vererbungslehre war bald ein wichtiger Forschungszweig. Die Nutzung der Kenntnisse über Objekte, deren Nachrichtenaustausch, der Vererbung von Fähigkeiten (Attributen und Service) für die Softwareerstellung kam durch Programmiersprachen wie Simula und Smalltalk in Gang. Später wurde der Ansatz dieser Sprachen erweitert und mit bisherigen Sprachen verknüpft. Die gängigste objektorientierte Sprache ist wohl zur Zeit C++ gefolgt von Smalltalk, Objekt Pascal u.a. sowie neuerdings Visual FoxPro.

Den Softwareerstellungsprozeß unterscheidet man im Wesentlichen in folgende Phasen: Analyse, Design, Implementation und Wartung. Analyse und Design stehen vor der Nutzung einer Programmiersprache (auch wenn manche das nicht warhaben wollen) und deshalb bemühen sich viele kluge Köpfe um die Entwicklung neuer Methoden für diese beiden Phasen. Denn eins ist bereits jetzt ganz klar, für die Nutzung der neuen Sprachelemente bedarf es eines neuen Planungsansatzes und für den optimalen Einsatz einer Objektorientierten Entwicklungsumgebung bedarf es mehr umsichtiger Planung und Analyse als je zuvor. Denn wie in der Natur, sterben verkehrt entwickelte Klassen aus.

Analyseansätze

I. Softwareengineering

Nach I.Sommerville, entstand der Begriff des Software Engineerings in den 60er Jahren. Software Engineering war notwendig geworden durch die neue Leistungsfähigkeit der damaligen Hardware und dem damit verbundenen wesentlich höheren Datendurchsatz, wie auch den neuen Möglichkeiten wie Bildschirmarbeitsplätzen etc. Es entstand die sogenannte „Software-Krise“ aufgrund der Tatsache, daß Kaufleute und Techniker das enorme Potential der Computer für sich erkannten. Bei der Realisierung der Softwareanforderungen erkannte man sehr bald, das die bisherigen Methoden nicht ausreichten um Systeme der neuen Größenordnung stabil und sicher zu entwickeln. Die alten Systeme konnten aber nicht weiter aufgebläht werden und die neuen Systeme kamen zum Teil um Jahre zu spät. Es mußten also neue Softwareentwicklungsmethoden her, die es ermöglichten große Systeme effizient und sicher zu erstellen. Man beschäftigte sich zum ersten Mal mit den Kosten der Softwareentwicklung und untersuchte die Verfahren zur Softwareerstellung genauer und wissenschaftlich. Softwareengineering beschäftigte sich dann auch als erste Dsziplin mit dem gesamten Lebenszyklus einer Software und es wurde ein Vorgehensmodell entwickelt. Der Software Lebenszyklus wurde damals aufgeteilt in: Analyse und Definition, System- und Softwareentwurf, Implementation und Test der Komponenten, System-Test und Betrieb,Wartung. Das Vorgehensmodell war das sogenannte Wasserfallmodell. Die Analyse hatte am Anfang dieser neuen Bemühungen nicht den Stellenwert den sie heute hat, weil sie nur als eine der Phasen betrachtet wurde. Das Ergebnis der Analyse zum damaligen Zeitpunkt war ein schriftliches Dokument, daß die Anforderungen des neu zu erstellenden Systems mehr oder weniger gut beschrieb.

II. Strukturierte Ananlyse

Seit Mitte der 70er Jahre setzte sich dann die strukturierte Analyse durch. Der neue Ansatz war der, daß man sich bemühte, ein grafisches Modell zu entwickeln, daß die Anforderungen des Systems für jedermann verständlich beschrieb. So ein Modell besteht aus Datenflüssen und den Prozessen, die die zufließenden Daten in geeigneter Weise umwandeln in abfließende Daten. Dazu wurden Symbole entwickelt die eine einfache grafische Darstellung ermöglichten, und was ebenfalls wichtig war, es wurden Methoden zur funktionellen Unterteilung eines Systems entwickelt. Das Ergebnis der strukturierten Analyse war jetzt nicht mehr nur ein einfaches schriftliches Dokument, sondern ein Zieldokument (Target Document), daß aus Datenflußdiagramm (DFD), Data Dictionary, strukturierter Beschreibung, Entscheidungstabellen und Entscheidungsbaum bestand. Während die strukturierte Analyse die Prozesse mit den zu- und abfließenden Daten modellierte, entwickelte sich parallel eine andere Technik zum modellieren der Daten, nämlich die ER-Methode. Die Entity-Relationship-Methode zeigt, ebenfalls grafisch, die Beziehungen zwischen den Daten in einem System. Die ER-Methode eignet sich bestens für den Datenbankentwurf und hat sich als Modellierungswerkzeug für Relationale Datenbanken stark durchgesetzt.

III. Objektorientierte Analyse

Zu einem sehr frühen Zeitpunkt war Softwareentwicklern klar, daß komplexe Softwaresysteme in kleinere, handhabbarere Module aufgeteilt werden mußte. Das Zusammenarbeiten dieser Module wurde aber mit zunehmender Komplexität immer schwieriger und Fehleranfälliger. Vor allem weil man eine logische, als auch physikalische Trennung, zwischen Daten und Datenverarbeitungsprozeß hatte. Es war recht bald klar, daß Softwaresysteme am stabilsten funktionierten, wenn die einzelnen Module autark arbeiteten -also eine starke innere Bindung haben- und nur lose miteinander gekoppelt waren -also wenig voneinander wußten. Erreicht werden konnte so etwas am besten, wenn man Daten und Verarbeitungsprozeß als eine Einheit betrachtet und den Informationsaustausch mit der Umwelt über eine definierte Schnittstelle abwickelte und zwar nur über diese. Objekte und Kapselung waren geboren. Wegen der Forderung nach Wiederverwendbarkeit von Modulen kam noch die Möglichkeit der Vererbung der Fähigkeiten und Kenntnisse an untergeordnete (mehr spezialisierte) Objekte sowie die Klassifizierung von Objekten hinzu. Die Programmiersprachen die diese neuen Möglichkeiten boten, forderten aber ein Umdenken in der Art und Weise wie man mit ihnen programmierte. Diese neue Art zu programmieren braucht aber auch eine neue Art der Analyse, nämlich eine Objektorientierte. Man braucht für ein vollständiges Analysemodell verschiedene Sichten. Darüber wie diese Sichten aussehen soll, gibt es verschiedene Theorien und Ansätze. Im wesentlichen haben sich drei Methoden zur Modellierung und Durchführung, sowie einer dazugehörigen Notation zur grafischen Darstellung durchgesetzt. Nach ihren Begründern genannt sind das die Methoden von Coad/Yourdon, Booch und Rumbaugh. Coad/Yourdon unterteilen die Sichten in die eigentliche Problemdarstellung (PD), menschliche Interaktion mit dem System (HI), Systeminterne Interaktion(SI), dem Datenmanagement(DM) und einer „Jetzt noch nicht“(NT). Rumbaugh unterscheidet nach dem Objektmodell, das die statische Sicht darstellt, dem dynamischen Modell, das das Zeitverhalten darstellt und dem funktionalen Modell, das die funktionalen Zusammenhänge erläutert. Booch macht eine grundsätzliche Unterscheidung zwischen statischem und dynamischen Modell. Diese unterteilt er jeweils wieder in ein logisches und physikalisches Modell. Die logischen Modelle haben bei ihm eine Klassen und Objektstruktur, die physikalischen eine Modul- und Prozeßarchitektur.

Das Vorgehensmodell ist das Baseballmodell. Ein wenig Objektorientierte Analyse (OOA), ein wenig Objektorientiertes Design (OOD), ein wenig Objektorientierte Programmierung (OOP) und das ganze in weiterer Verfeinerung wieder von vorne.

Was ist wichtig für die Design- und Programmierphase in Objektorientierten Softwaresystemen?

Das Ergebnis der Analyse soll mittels Design und Programmierung in ein funktionierendes Programm umgesetzt werden. Anders betrachtet kann man auch sagen, daß das Ergebnis der Analyse die Wunschvorstellung des zukünftigen Systems ist und das das Ergebnis des Designs die Realität widerspiegelt. Die Analyse soll also möglichst genau (d.h. nicht mehr, aber auch nicht weniger) die Forderung des Benutzers, respektive des Auftraggebers darstellen, während das Design die Möglichkeiten, bzw. die Realität des physischen Systems darstellen soll. Je größer die Übereinstimmung zwischen den beiden, umso zufriedener ist der Benutzer.

Für die Programmierung mit einer objektorientierten Progammiersprache braucht man grundsätzlich erst einmal die Information über die zu erstellenden Klassen und den Objekten mit ihren Attributen und Eigenschaften. Weiterhin braucht man eine Struktur, an der man absehen kann wie die Objekte und Klassen zusammenarbeiten. Man sollte also zu diesem Zeitpunkt schon ziehmlich genau wissen, welche Klassen im System existieren müssen und in welchen Relationen diese zueinander stehen. Weiterhin ist es dann wichtig zu wissen wie die Zusammenarbeit der Klassen gesteuert werden soll und wie die Klassen und Objekte aussehen sollen.

Insgesamt läßt sich an diesem Wenigen schon absehen, daß die Analyse für die neue Art zu programmieren wichtiger ist denn je.

Wie finde ich eine Klasse oder benötigten Klassen ?

Zum einen ist dies die Gretchenfrage, zum anderen gibt es hierauf keine eindeutige Antwort. So wie viele Wege nach Rom führen, so gibt es auch viele Wege die zu einer Klassendefinition führen. Die vorher benannten Begründer der verschiedenen Modellierungstechniken haben dann auch interessante Ideen, wie man die benötigten Klassen ermittelt und zu einer guten Beschreibung dieser gelangt. Ich werde im folgenden eine Auswahl dieser Ideen hier darstellen, ohne Angabe einer Referenz.

Grundsätzlich sind sich alle darüber einig, daß man als allererstes viel Kommunikation mit dem späteren Benutzer und/oder dem Auftraggeber braucht. Am Besten ist es, wenn man mit einem sogenannten Bereichsspezialisten über das Projekt spricht. Bei größeren Systemen können das auch mehrere sein, weil die Software evtl. mehrere Bereiche verknüpfen soll. Diese Gespräche sollten gut dokumentiert werden und das Aneignen einer Fragetechnik ist hier von Nutzen, zumindest für denjenigen der kein natürliches Talent für diese Aufgabe hat.

Im folgenden einige Hinweise auf was zu achten ist:

• Finden sie den Sinn und Zweck des neu zu erstellenden System heraus. Bemühen sie sich die Essenz diese Ergebnisses in 25 oder weniger Worten darzustellen. Dieses ist das Hauptziel. Behalten sie es immer im Auge. Finden sie heraus welche Anforderung zwingend wichtig ist und somit den kritischen Erfolgsfaktor darstellt.
• Finden sie heraus warum gerade dieses System und kein anderes? Warum dieses System gerade jetzt erstellt werden soll.
• Fragen sie den Bereichsspezialisten nach den vier wichtigsten Eigenschaften
  • Welche wichtigen Informationen muß das System speichern ?
  • Was für Verarbeitungen sollen durch das System gemacht werden?
  • Welche Art von Analyse der gespeicherten Informationen soll das System durchführen?
  • Mit welchen anderen Systemen soll/muß das System interagieren ?
• Observieren sie direkt vor Ort. Arbeiten sie mal einen Tag mit im Problembereich.
• Lesen und überprüfen sie evtl. ältere, bereits vorhandene Projektbeschreibungen.
• Lesen sie Arbeitsplatzbeschreibungen.
• Sehen sie sich andere Systeme an die ähnliches tun

Wenn sie alle diese Informationen zusammengetragen haben, dann machen sie daraus ein schriftliches Dokument. Dieses Ergebnis nennen wir die Problembeschreibung. Folgendes muß in der Problembeschreibung enthalten sein:

• Problemumfang
• Beschreibung der Daten, Dokumente die benötigt werden, bzw. die verarbeitet werden sollen
• Beschreibung von Ausgaben (Resultaten) die auf Papier, Bildschirm oder anderen Medien erscheinen soll

Im Allgemeinen sind Klassen statisch und Objekte dynamisch. Klassen müssen statisch sein, weil man sonst nicht auf ihre bekannten Eigenschaften zurückgreifen kann. Wenn wir uns unsere Sprache ansehen und vielleicht dabei eine Problembeschreibung im Auge haben, dann könne wir durch einfache Beobachtung feststellen, das Hauptwörter als solche statisch sind und Verben (Tu-Wörter) dynamisch. Wir können also folgerichtig dazu übergehen, alle (sinnvollen) Hauptwörter aus unserer Problembeschreibung herauszufiltern und haben damit potentielle Klassennamen. Nehmen wir uns noch die zugehörigen Verben dazu, dann haben wir auch noch potentielle Objektnamen.

Beispiel:

Ein einfaches PKW Fahrtenbuch System

Das Fahrtenbuch dient als Dokumentation gegenüber dem Finanzamt, welche Fahrten eines PKW´s Geschäftsfahrten und welche privater Natur waren. Es muß bis zum 31.12.1995 fertiggestellt werden, weil ab 1996 neue gesetztliche Bestimmungen in Kraft treten.

Dieses System soll aus einer Tabelle bestehen, in der gespeichert wird: Fahrzeug-Kz, Fahrer, Datum, Uhrzeit des Fahrtzeitbeginns, km-Stand bei Beginn der Fahrt, Fahrziel, Fahrtanlaß, Uhrzeit der Ankunft, km-Stand bei Ankunft, Art des Fahrtanlasses. In die Tabelle sollen bei jeder Fahrt alle möglichen Daten erfaßt werden.

Das System soll selbständig die gefahrenen km/Fahrt ermitteln. Es soll am am Monatsende eine Liste ausgedruckt werden mit allen Fahrten/Fahrzeug mit einer Summierung der gefahrenen km/Art des Anlasses

Hauptwörter

Fahrtenbuch, Dokumentation, Finanzamt, PKW, Geschäftsfahrt, Natur, Bestimmungen, Kraft, System, Tabelle, Fahrzeug-Kz, Fahrer, Datum, Uhrzeit, Fahrzeitbeginn, KM-Stand, Beginn, Fahrt, Fahrziel, Fahrtanlaß, Ankunft, Anlaßart, Daten, Monatsende, Liste, Summierung

Im Ansatz sieht das alles einfach aus, aber bei einer Problembeschreibung die über 50 Seiten geht, wird die Liste ziehmlich lang. Es gibt daher Empfehlungen nur solche Hauptwörter zu wählen, die mit einem physischen Gegenstand, irgendeiner Rolle, Ereignis, einem Prozeß oder etwas ähnliches in Zusammenhang stehen. Das ist aber auch nicht immer ganz einfach, weil solche Dinge von der jeweiligen Interpretation abhängig sind. Wie auch immer, man wird irgendwie immer Lehrgeld bezahlen müssen und es steht auch nirgendwo geschrieben, das alles sofort von Anfang an perfekt sein muß. Als erster Ansatz ist dies sehr gut zu gebrauchen. Man muß dann weiter verfeinern und besonders am Anfang durch trial und error herausfinden welche Hauptwörter sich als Klasse eignen. Auf jeden Fall hat man erst mal eine Menge von Klassen und beginnt jetzt zu filtern. Als nächsten Schritt entfernt man Redundanzen und bemüht sich um Abstraktionen.

Übrig bleiben dann z.B. die folgenden Namen als Klassen:

Fahrtenbuch, PKW, Fahrzeug-Kz, Fahrer, Fahrt, Anlaßart

Diese Klassen müssen jetzt weiter überprüft werden und am besten durch Modellierungsversuche auf Funktion überprüft werden. Entsprechend Literatur hat sich für diesen Teil die CRC Methode bestens bewährt. In Kürzedas Prinzip des CRC:

• CRC sind ganz einfache Karteikarten, die als Titel den Klassennamen, darunter die Namen von eventuellen Unterklassen und Superklassen haben. Der Rest der Karte ist geteilt in zwei Hälften. In der einen (linken) werden die sogenannten Verantwortlichkeiten der Klasse eingetragen. Also die Aufgaben die die Klasse respektive ihre Instanzen ausführen soll und auf der rechten Seite werden Partnerklassen eingetragen die der Klasse zuarbeiten.

• Durch Erstellen einer Karte pro Klasse und eintragen der Entsprechenden Informationen, ergeben sich ganz natürlich weitere Klassen und andere, scheinbare Klassen, eliminieren sich. Ein weiterer Vorteil ist das einfache Zusammenstellen von Sub- und Superklassen.

Was gehört alles zu einem Objekt ?

Bevor wir Aussagen über die Dinge machen die zu einem Objekt gehören, erst einmal ein paar Wort über das was ein Objekt ausmacht. Ein Objekt ist ein greifbares und anfassbares Ding und/oder es ist für uns in irgendeiner Form wahrnehmbar und/oder es ist etwas an das wir denken oder das durch unsere Tätigkeit beeinflußt wird oder beeinflußbar ist. Man kann auch sagen, das ein Objekt etwas ist, was in Raum und Zeit existiert. Sei es auch nur gedanklich. Auf jedenfall ist ein Objekt etwas, was klar definierte Grenzen hat. Eine genauere Beschreibung gibt Booch indem er sagt:

Ein Objekt hat einen Status, ein Verhalten und eine Identität; die Struktur und das Verhalten ähnlicher Objekte sind in ihrer gemeinsamen Klasse definiert; die Begriffe Instanz und Objekt sind austauschbar.

I. Der Status eines Objektes

Was also ist der Status eines Objektes? Er stellt den momentan statischen Zustand des Objektes dar, respektive seine momentan statische Eigenschaft. Die Eigenschaften eines Objektes sind unverwechselbar mit diesem verbunden und machen die Einzigartigkeit eines Objektes an sich aus. Die Eigenschaft eines Flugzeuges ist es eben fliegen zu können und deshalb unterscheidet es sich wohlweislich von einem Auto, auch wenn ein Flugzeug sich mit 150 km/h am Boden bewegen kann. Einem Status oder einer Eigenschaft kann immer ein Wert zugewiesen werden und umgekehrt. Erst der Wert macht aus einer Klasse ein Objekt. Deshalb nimmt ein Objekt auch immer einen Platz in Raum und Zeit ein. Der Status eines Objektes ist normalerweise nicht direkt von außen sichtbar. Dieses verhindern des Zugriffs auf die Interna eines Objektes nennt man Kapselung.

II. Das Verhalten eines Objektes

Abgeleitet von dem eigentlichen Begriff, so wie wir ihn im Alltag für unsere Mitmenschen gebrauchen, kann man sagen, daß das Verhalten eines Objektes seine Reaktion wiederspiegelt aufgrund von Nachrichten die das Objekt erhält. Das Verhalten ist die Eigenschaft eines Objektes die von außen wahrgenommen werden kann und die überprüfbar und wiederholbar ist. Das heißt, ich sende einem Objekt eine Nachricht und erkenne eine Reaktion. Da Objekte nie für sich alleine existieren, sonder immer in relation zu einem anderen stehen, ist dies eine wichtige Eigenschaft die festzuhalten ist. Für „eine Nachricht senden“ kann man auch sagen das man eine Operation auf einem Objekt ausführt. Diese Operationen die ausgeführt werden können, nennt man auch Methoden. Anders ausgedrückt sind es die Methoden eines Objektes, die sein Verhalten bestimmen. Dieses bestimmte Verhalten eines Objektes bezeichnet man aus einer anderen Sicht aber auch als seine Verantwortlichkeit. Man kommt zu dieser Sicht, wenn man nach den Aufgaben eines Objektes fragt und dann sagt, daß dieses Objekt für die und die Aufgabe verantwortlich ist. Aufgaben werden eben über Methoden ausgeführt. Sie können von außen sichtbar sein, aber auch nur privater Natur

III. Die Identität eines Objektes

Die Identität ist sozusagen das Ich eines Objektes. Es ist das, was ein Objekt einmalig und unverwechselbar von anderen Objekten macht.

Modellierung

Bei der Modellierung will ich mich hier auf die Notation von Booch beschränken, weil die Teilnehmer der Konferenz hierzu ein Demo-Tool bekommen haben und damit zu Hause experimentieren können. Auch auf das Für und Wider der verschiedenen Notationen will ich hier nicht eingehen, weil dies weit über eine Einführung hinaus geht.

Auch bei der Modellierung selbst gibt es verschiedene Ansätze. Jeder Ansatz läßt sich aber (jedenfalls im Wesentlichen) mit jeder Notation darstellen. Deshalb wähle ich den Coad/Yourdon Ansatz, dargestellt in Booch Notation. Coad Yourdon gibt uns zur Aufgabe vier verschiedene Modelle zu erstellen und eine Aufzählung der Dinge, die wir im Moment nicht berücksichtigen wollen. Das wichtigste Modell ist natürlich das, der Problembeschreibung. Die Modelle der menschlichen Interaktion, des Datenmanagements sowie die Modellierung der Beziehungen zu anderen Systemen, sind nachgeordnet.

Coad gibt hervorragende Hinweise, wie die darzustellenden Objekte zu ermitteln sind [5]. Suchen sie nach

• Akteuren bzw. Teilnehmern am Problem (also unser Fahrer)

  stellen sie fest, wie und in welchem Zusammenhang die Person oder Teilnehmer für das System
  interessant ist. Fragen sie auch warum?

• Orte, also Plätze, an denen etwas steht, was in Zusammenhang mit dem Problem steht

suchen sie auch nach Plätzen wo etwas zur Ruhe kommt, Plätze an denen sich weitere Objekte befinden die mit dem System in Zusammenhang stehen fragen sie danach ob das Objekt eines ist, für das das System verantwortlich ist oder über das das System etwas wissen muß?

• Dinge
  suchen sie nach anfaßbaren Objekten. Suchen sie nach Gegenständen und Sepzialisierungen von Gegenständen
• letztendlich, suchen sie nach Ereignissen die gespeichert werden müssen

Für das kleine Beispiel Fahrtenbuch, finden sie einen Modellierungsansatz (PD)

Hier noch einige Hinweise wie man Verantwortlichkeiten bestimmt respektive ermittelt. Grundsätzlich gilt, daß jedes Objekt im Modell ganz bestimmte Aufgaben und die Verantwortung für diese Aufgabe hat. Kennen wir ja wohl auch aus dem täglichen leben. Per Definition können wir sagen, daß ein Objekt alles über sich selbst weis(es sei denn der Programmierer vergisst etwas). Es weis etwas über andere Objekte, nämlich über die mit denen es zusammenarbeitet und ein Objekt tut etwas. Entweder alleine oder in Zusammenarbeit mit anderen. Für die Analyse und Modellierung ist es deshalb ihre Aufgabe, die Aufgaben und Verantwortlichkeiten eines Objektes zu bestimmen und zwar so das die Ziele der Problembeschreibung erfüllt werden. Eine Möglichkeit diese Aufgabenstellung anzugehen ist die, sich vorzustellen das man das Objekt ist und dann die folgenden Fragen zu stellen:

• Was weis ich?

Oder was muß ich wissen, damit ich eine ganz bestimmte Aufgabe erfüllen kann.

• Wen kenn ich?

Oder wen sollte ich kennen damit die Aufgabe durchgeführt werden kann oder von wem kann ich die weiteren benötigten Informationen bekommen zur Lösung meiner Aufgabe.

• Was tue ich?

Oder was muß ich tun um meine Aufgabe ausführen zu können.

Die Beantwortung dieser Fragen führt uns zu den benötigten Attributen.

Wenn ich mir also vorstelle das ich das Fahrer-Objekt bin, dann kann ich folgende Attribute finden:

• Was muß ich wissen um meine Aufgabe als Fahrer erfüllen zu können?
  • Ich muß das Datum kennen
  • Ich muß die Uhrzeit kennen
  • Ich muß den aktuellen KM-Stand kennen
  • Ich muß das Fahrtziel kennen
  • Ich muß meine Fahrer-ID kennen
  • Ich muß meinen Namen kennen
  • Ich muß wissen mit welchem Auto ich fahre
  • Ich muß wissen ob dies eine dienstliche oder eine private Fahrt ist
  • Wen sollte ich kennen, der mir hilft meine Aufgabe zu erfüllen?
  • für Datum und Uhrzeit, das Systemobjekt
  • für den KM-Stand, das PKW-Objekt

   

• Was muß ich tun um meine Aufgabe zu erfüllen?
  • Berechne gefahrene Km

Unser Modell sieht dann wie folgt aus:

Um unsere PD Ansicht zum Ende zu bringen brauchen wir nur noch eine Betrachtung ausführen. Das sind die Transaktionen. Coad [5] definiert die Transaktionen als zeitliche Momente während denen das System dafür verantwortlich ist Dinge zu speichern die zu einem späteren Zeitpunkt gebraucht werden. In unserem Falle also die gefahrenen Km.

Empfohlen ist nach diesem Abschnitt eine dynamische Darstellung des Modells durchzuführen, aber das würde hier im Moment zu weit führen.

Interessanter ist für die meisten wohl die Frage nach dem Modell für die Menschliche Schnittstelle. Diese Schnittstellen sind in den meisten Fällen entweder irgednwelche Fenster(Masken) auf denen Ein- und Ausgabeoperationen laufen, sowie gedruckte Darstellungen.

Es erhebt sich am Anfang wieder die Frage welche Fenster und welche Drucksachen? Am einfachsten ist es, erst einmal jedem Objekt ein Fenster zuzuordnen. Meistens wird man auch noch ein Logon Fenster, ein Setup Fenster und ein Info Fnster gebrauchen. Bei Druckausgaben wird man immer zu betrachten haben ob diese gesetzlich gefordert sind oder für den allgemeinen Geschäftsablauf von Bedeutung sind.

Als Objektnamen benutzen wir jetz Fensternamen. Der Vorgang der Attributfindung, sowie der Aufgabenfindung bleib gleich. Wir fragen wieder:

• Was weis ich?
• Wen kenn ich?
• Was tue ich?

Für ein Logon Fenster könnte das wie folgt aussehen:

Insbesondere Bei Fenstern sollte man sehr bald Hirarchien und Vererbung einführen. Das läßt sich sehr schön mittels der grafischen Darstellung der Objekte machen.

Ausblick

Lieber Leser, ich freue mich, daß ihnen einen kleinen Einblick in das interessante Feld der Objektorientierten Systemanalyse geben konnte. Ich wünsche mir, daß Ihr Interesse so geweckt wurde, daß sie mit Freude und Energie ihre Analysekenntnisse erweitern, in Theorie und Praxis. Ihre Benutzer, Kunden, Kollegen und Mitstreiter werden es ihnen danken und der Erfolg ist ihnen gewiss.

Ausgehend von dieser Einführung kann ich Ihnen nur noch empfehlen viele Modelle zu entwerfen und Erfahrung zu sammeln (Ich bin auch noch dabei). Das Lesen einiger (oder auch aller) Bücher der Bücherliste ist zwar sinnvoll, bringt aber keine Praxis. Alle Autoren sagen dem Leser deshalb auch immer und immer wieder, daß der Spaß zu Kreativität und das Herumspielen mit den Entwürfen der beste Lehrmeister ist. In diesem Sinne ist auch sicherlich der CRC Card Ansatz hochinteressant und lehrreich.

Ich wünsche allen Lesern viel Erfolg und Spaß bei ihren Analysen und Modellierungen.

Literatur

1. Edward Yourdon - Moderne strukturierte Analyse, Wolframs Fachverlag
2. Peter Coad/Edward Yourdon - Object Oriented Analysis, Prentice Hall
3. Robert C. Martin - Designing Object-Oriented C++ Applications Using the Booch Method, Prentice Hall
4. Peter Coad/Jill Nicola - Objekt-Orientierte Programmierung, Prentice Hall
5. Peter Coad u.a. - Object Models, Stragtegies, Patterns & Applications, Yourdon Press
6. Grady Booch - Objektorientierte Analyse und Design, Addison Wesly
7. James Rumbaugh - Objektorientiertes Modellieren und Entwerfen, Carl Hanser+Prentice Hall
8. Nancy M. Wilkinson - Using CRC Cards, SIGS Books New York
9. Sally Shlaer,Stephen Mellor - Object oriented Systems Analysis, Yourdon Press
10. Gary Entsminger - The TAO of Objects, M&T Books
11. Martin Schader, Michael Rundshagen - Objektorientierte Systemanalyse, Springer Verlag