Inhalt dieses Vortrags sind nicht die starken neuen Features von Visual FoxPro, und wir werden auch nicht die neuesten Programmiertricks von VFP besprechen: in dieser Session werden Sie keinen Quellcode und keine tollen Gimmicks zu sehen bekommen. Ja, VFP wird sogar nur am Rande erwähnt. Ziel des Vortrags ist es, Ihnen einen Einblick in die Metaebenen der objektorientierten Softwareentwicklung zu geben.
In diesem Vortrag möchte ich Ihnen darstellen, welche Überlegungen man sich machen muß, wenn man ein Projekt anfängt. Diese Überlegungen dienen dazu, den gesamten Entwicklungsprozeß eines Produktes mit Hilfe von objektorientierten Entwurfsmethoden zu strukturieren. Wenn Sie sich einmal mit diesen Methoden vertraut gemacht haben, werden Sie merken, wie flexibel diese einsetzbar sind. In unserer Firma wenden wir OO-Methoden inzwischen auch an, um z.B. komplette Netzwerke zu planen und zu dokumentieren. In diesem Vortrag werden Ihnen verschiedene OO-Methoden vorgestellt und gezeigt, wie sie angewendet werden. Generell gilt allerdings: es gibt keine Methode, mit der alle Problemstellungen lösbar sind. Sie müssen sich also mit mehreren Denkmodellen vertraut machen und ggf. verschiedene Ansätze mischen, um eine für Sie bzw. für Ihr Projekt geeignete Arbeitsweise zu finden.
Zunächst aber doch noch ein paar Worte zur Objektorientierung in Visual FoxPro:
von Visual FoxPro haben wir uns alle tolle Features versprochen. Die Zukunft der Applikationsentwicklung schien mit der Version 3.0 endgültig angebrochen:
Alles in allem heißt das ja, daß man vom Schreiben von Quellcode weg will. Die allgemeine Entwicklung in der Softwarebranche geht ja weg von der Programmierung hin zur Diskussion des Problems und zur Modellierung einer Lösung. In USA läuft der Trend auch dahin, sich nicht mehr Programmierer, sondern z.B. „software-engineer“ oder „architect“ zu nennen.
Um diesen Anspruch einlösen zu können, muß man sich auch Gedanken machen über eine Arbeitsweise, die das reflektiert.
Keiner der Entwickler, die ich kenne, möchte die Klassenbibliotheken, die er zu Beginn mit VFP entwickelt hat, wiederverwenden, ganz einfach deshalb, weil niemand mehr weiß, was er dort wirklich programmiert hat. Das allgemeine Motto lautet: „Hoffentlich kommt der Kunde, für den ich die erste Applikation mit VFP gebaut habe nie wieder, um eine Änderung machen zu lassen!“.
Die Verwendung von Komponenten funktioniert auch nicht so, wie die Demonstrationen z.B. auf der Konferenz letztes Jahr es suggeriert haben. ActiveX-Controls kann man meist nicht einfach so verwenden, sondern man braucht eine Wrapper-Klasse, also eine Klasse, die das Control beinhaltet und die eine Schnittstelle so bereitstellt, wie man sie sich selbst vorstellt; eine Schnittstelle, die sich in die Logik des eigenen Frameworks einfügt.
Stichwort Weitergabe von Klassenbibliotheken: Wissen Sie, was Ihnen der Kollege mit seiner Bibliothek sagen wollte? Wer sich einmal verzweifelt durch Tastrade oder die per Wizard generierten Formulare gehangelt hat, weiß, daß man das meist schneller selbst gebaut als abgeguckt hat.
Und, am allerwichtigsten: Weiß Ihr Kunde, was ein Grid ist, wieso Sie den Commandbutton erst in der 8. Vererbungsstufe verwenden? Nein, das ist ihm völlig egal. Ihr Kunde will lediglich, daß Sie etwas liefern, das seine Problemlage löst und dabei hat er ein Recht darauf, daß Sie Ihn verstehen und ihm etwas Passendes liefern!
Den Begriff „Kunde“ wende ich hier nicht nur für externe Auftraggeber von Firmen an, sondern auch der Anwender einer Inhouse-Programmierung ist ein Kunde. Für EDV-Abteilungen in größeren Firmen ist es sogar besonders wichtig, von Ihren „Kunden“ verstanden zu werden, um die Meinung ‘die von der EDV sitzen in ihrem Elfenbeinturm’ zu durchbrechen.
Was ist überhaupt eine Methode? Eine Methode ist eine Prozedur bei der Schritt für Schritt vorgegangen wird. Jeder Schritt ist festgelegt und gegenüber den vorherigen und nachfolgenden Schritten abgegrenzt. Alle Stufen der Prozedur setzen auf Ergebnissen der vorangegangenen Arbeiten auf.
In den objektorientierten Entwurfsmethoden dienen die Schritte dazu, sich von der abstrakten Beschreibung eines Problems, das EDV-technisch gelöst werden soll, immer weiter an die konkrete Umsetzung heranzuarbeiten.
OO-Methoden haben daher einen strukturierten Aufbau mit einzelnen Phasen. Für diese Phasen sind die durchzuführenden Arbeiten festgelegt. Die Anwendung einer Methode bietet damit die Gewähr, wirklich alle relevanten Aspekte einer Softwareentwicklung zu behandeln.
Alle hier vorgestellten Methoden haben eine eigene graphische Darstellung der verwendeten Klassen und ihrer Hierarchien. Damit entfällt die mühsame „Suche nach dem verlorenen Code“ bei der man sich mit dem Klassendesigner oder Klassenbrowser durch die Vererbungsbäume der Klassen arbeitet. Mit einer lückenlosen Dokumentation wird ebenso wie die Frage „was soll die Methode, die hier aufgerufen wird, denn machen?“ geklärt.
Was Sie nicht selbst tun wollen, wenn sie eine Klassenbibliothek einsetzen (nämlich die Dokumentation mühselig aus den Kommentarzeilen im Code herauszusuchen), sollten Sie Ihren Kollegen auch nicht zumuten. Die Übergabe einer per OO-Methode dokumentierten Bibliothek geht ohne tagelange Erklärungen.
Mit den Diagrammen einer OO-Methode erhalten Sie die Möglichkeit, Ihren Kunden zu zeigen, daß Sie sie verstanden haben. Mit Hilfe einer Modellierungsmethode erhalten Sie ein Denkmodell der Applikation, das Ihr Kunde verstehen und beurteilen kann. Er kann Sie also schon in einem frühen Stadium auf Fehlschlüsse aufmerksam machen und Sie vor teuren Fehleinschätzungen bewahren.
Heißt das nun, daß Sie neben VFP auch noch weitere Sachen lernen müssen? Das sind die „bad news“: JA!
Die „good news“: auch Sie selbst haben etwas davon! OO-Methoden dienen dazu, die Konzepte, die per Software umgesetzt werden sollen, abzubilden. Klassen und Objekte und ganz besonders Nachrichten, Vererbung und Aggregation von Objekten werden viel leichter nachvollziehbar. Dadurch, daß Sie Ihren Kunden klarmachen, daß Sie ihre Problemlage verstanden haben und eine tragfähiges Konzept haben, erhalten Sie deren Vertrauen und die Mitarbeit an der Problemlösung.
Mit Hilfe der von den meisten Vorgehensweisen vorgeschlagenen iterativen Arbeitsweise wird die Komplexität des Anwendungsgebietes beherrschbar. Man modelliert immer nur den Teil des Problems, den man gerade bearbeitet und den man verstanden hat.
Methoden bieten also eine Schnittstelle zum Verstehen der Anwendung, für die Kommunikation mit den Kunden und für die Dokumentation, die allein die Grundlage für eine rationelle Wiederverwendung ist.
Alle Methoden haben die Aufteilung in Projektphasen gemeinsam. Die Phasen heißen in den einzelnen Methoden teilweise anders, dienen aber im Prinzip immer dem gleichen Zweck: am Anfang eines Projektes steht immer eine Analyse der Prozesse, die von der Software abzubilden sind. Die Analyse wird anhand von Dokumenten des Kunden und/oder mit dessen Mitarbeit durchgeführt.
Basierend auf den Ergebnissen der Analyse wird dann ein Design des Systems gemacht. Das Design hat den Zweck, zu einer Darstellung des Modells zu gelangen, die eine direkte Umsetzung in eine OO-Sprache erlaubt. Erst in der Implementation wird dann das im Design erstellte Modell in Programmcode umgesetzt.
Mit dem Einsatz einer Methode ist natürlich eine Abstraktion der Programmierarbeit verbunden, denn am Anfang eines Projektes wird fürchterlich viel gelesen, geschrieben und diskutiert aber nicht programmiert.
Alle Methoden bieten eine Sammlung von graphischen Symbolen an, um die Zusammenhänge zwischen den Klassen, Objekten, Aktoren, Modulen usw. abzubilden und kommunizierbar zu machen.
Mit Hilfe dieser Symbole wird ein Prototypmodell (kein Programmprototyp!) erstellt, anhand dessen sich die Umsetzung der Anforderungen (gedanklich) testen läßt.
Noch einmal „good news“: es gibt bereits publizierte, dokumentierte und getestete Vorgehensmodelle. Im Rahmen dieses Vortrags werden behandelt:
OOA/OOD (Object-Oriented Analysis/ Object-Oriented Design) von Coad/Yourdon ist recht einfach gehalten, bietet aber eine Reihe von Prüfungsmöglichkeiten für die gefundenen Konstrukte.
OMT (Object Modelling Technique) von James Rumbaugh ist inzwischen die am meisten verbreitete Methode, was an der relativ gut zu verstehenden Notation liegt. OMT bietet auch Möglichkeiten, das dynamische Verhalten eines Modells zu beschreiben
Booch (nach Grady Booch, auch bekannt als OOAD, Object-Oriented Analysis and Design) ist eine eher umstrittene Methode, was hauptsächlich in der eigenwilligen Notation begründet ist. Sie legt den Schwerpunkt auf das Design und die Implementation von Programmen und bietet hierfür eine große Anzahl von Hilfen.
OOSE (Object Oriented Software Engineering/ „Use-Case-Approach“) wurde von Ivar Jacobson entwickelt. Er legt das Gewicht auf die Anwendungsfälle, die in einer Applikation abgebildet werden sollen und gewinnt daraus die Klassen und ihre Zusammenhänge.
UML (Unified Modelling Language) ist das Ergebnis der Zusammenlegung der drei letztgenannten Methoden. Sie wird von den führenden Gurus innerhalb der Firma Rational entwickelt und hat gute Chancen, von der OMG (Object Management Group) als Standard eingeführt zu werden. Am Beispiel der UML, deren Konstrukte an vielen Stellen auf anderen Methoden basieren, wird auch deutlich, daß es unter den Autoren der verschiedenen Methoden absolut üblich ist, Ideen aus anderen Ansätzen zu übernehmen.
Alle diese Methoden reklamieren nicht, allumfassend zu sein. Ganz im Gegenteil: es gibt ausgesprochene Spezialisten. Daher sollte man sich, bevor man mit der objektorientierten Modellierung anfängt, mit allen Methoden beschäftigen, um aus den verschiedenen Ansätzen die Aspekte verwenden zu können, die einem persönlich liegen bzw. die in dem anliegenden Projekt den besten Erfolg versprechen.
Im folgenden will ich Ihnen einen Überblick über die verschiedenen Methoden und Ihre Schwerpunkte und Anwendung geben. Dieser Überblick erhebt nicht den Anspruch, die Methoden ausführlich darzustellen. Es gibt außerdem teilweise große Überschneidungen in den Diagrammen und Vorgehensweisen, die in den verschiedenen Methoden angewendet werden. Die einzelnen Techniken werden in diesem Vortrag aber nur einmal dargestellt.
Diese Methode hat eindeutig ein Schwergewicht auf der Analyse von Problemstellungen und auf dem Erstellen eines robusten Klassenmodells. Dazu bietet sie einige Mechanismen an, anhand derer man die Klassen und ihre Merkmale überprüfen und den gefundenen Prototypen testen kann. Prototypen meint hier nicht ein Programm, das so aussieht, als wenn es schon eine Implementation wäre, sondern ein Prototypmodell, das die Anforderungen des Kunden abbildet.
Grundlage für das Finden von Klassen-&-Objekten ist die Beschreibung des Anwendungsgebietes. Diese Beschreibung wird entweder durch den Kunden geliefert oder in Zusammenarbeit mit ihm erstellt. In der OOA werden die potentiellen Klassen gefunden, indem man die Beschreibung der Systemaufgabe liest und aus den darin vorkommenden Begriffen diejenigen herausfiltert, die als Klasse geeignet erscheinen. In der Regel sind dies Nominative, die Personen, Dinge, Systeme oder Verfahren beschreiben.
Als wichtiges Kriterium für die Auswahl der potentiellen Klassen gilt, daß sie für die zu entwickelnde Anwendung eine Rolle spielen.
Neben dem Herauslesen aus der Beschreibung ist es auch erlaubt, auf bereits bestehende Erfahrungen zurückzugreifen. In diesem Stadium wird in der OOA nicht unterschieden zwischen Klassen und daraus instanziierten Objekten, daher auch die Bezeichnung „Klassen-&-Objekte“. Es gibt gleichwohl eine Symbolik für Klassen, aus denen Objekte abgeleitet werden (ein grauer Rahmen um das Klassensymbol) und solche, die abstrakte Klassen sind (der graue Rahmen fehlt).
Der Name der gefundenen Klassen wird in der Singularform in das obere Drittel der Symbole geschrieben.
Auch die Strukturen werden aus den Beschreibungen der Systemaufgabe gelesen. Als Struktur im Sinne der OOA gelten Gen/Spec- (Vererbungs-) und Whole/Part- (ein Ganzes und seine Teile-) Strukturen. Die Symbole dafür sind Linien, die die in Frage kommenden Klassensymbole (nicht die Objektsymbole!) verbinden. Diese Linien sind durch einen auf der Basis liegenden Halbkreis für die Vererbung und ein Dreieck für die Whole/Part-Struktur unterbrochen.
Nach den Strukturen werden die Attribute der Klassen-&-Objekte modelliert. Es ist auch hier erlaubt, auf Erfahrungen zurückzugreifen. So ist z.B. auch ohne daß das ausdrücklich erwähnt wird, klar, daß eine Firma einen Namen hat. Wie schon bei der Auswahl der Klassen sollten hier nur die Attribute interessieren, die für die Anwendung eine Rolle spielen.
Natürlich kann es sein, daß eine Firma ein Postfach, eine Lieferanschrift und eine Briefanschrift hat. In ihrer Rolle als Firma in der Anwendung kann das aber uninteressant sein. Es kann völlig ausreichen, nur die Briefanschrift zu modellieren.
Die OOA gibt - wie auch für das Finden der Klassen-&-Objekte und der Strukturen einige Prüffragen mit, anhand derer man die Zuordnung der Attribute prüfen kann:
Haben alle Kunden eine Kundennummer?
Ist das Attribut für alle instanziierten Objekte vom gleichen Typ?
Bezeichnet ein Attribut immer genau eine Eigenschaft?
Die gefundenen Attribute werden im Symbol der Klasse in das mittlere Drittel geschrieben.
Bei der Modellierung der Services (Methoden) der gefundenen Klassen wird genau wie bei den Attributen vorgegangen: die Anwendungsbeschreibung wird unter dem Aspekt gelesen, die darin enthaltenen Tätigkeiten zu finden. Die gefundenen Tätigkeiten machen das Verhalten der Klassen aus. Sie werden den dafür zuständigen Klassen zugeordnet.
Eine Arbeit, die ebenfalls bei der Modellierung der Services erledigt wird, ist das Herstellen der Instanzverbindungen. Instanzverbindungen werden benötigt, wenn ein Objekt den Service eines anderen Objektes aufruft, um die eigene Aufgabe ausführen zu können.
Die Services werden in den Symbolen der Klassen in das untere Drittel geschrieben.
Die Object Modelling Technique beinhaltet ebenso wie die OOA/OOD eine Analysephase, in der die Klassen und ihre Zusammenhänge gefunden werden. Allerdings werden dort keine Fragen vorgesehen, um das Klassenmodell zu überprüfen. Die Notation in OMT ist der von OOA/OOD sehr ähnlich: es gibt Rechtecke mit einer Dreiteilung für Klassennamen, Attribute und Methoden.
Zusätzlich bietet die OMT Techniken an, um das dynamische Verhalten von Klassen zu modellieren. Sie ist daher wesentlich besser für das Design einer Applikation geeignet, da sich die entstandenen Klassenmodelle oft 1:1 in Quellcode umsetzen lassen.
Die Notation der Assoziationen zwischen Objekten unterscheidet sich von der in OOA/OOD lediglich durch ihre Darstellung. Die modellierbaren Zusammenhänge sind die gleichen, wenn auch die Instanzverbindungen über bessere Möglichkeiten verfügen, um die Kardinalität zwischen Klassen abzubilden.
Im dynamischen Modell der OMT werden die Zustände, die ein Objekt annehmen kann und die Wege, die dorthin führen, beschrieben. Das Objekt-Statusdiagramm enthält dazu ein Symbol für die Zustände, in dem sich ein Objekt befinden kann und Pfeile, die den Übergang zwischen diesen Zuständen bezeichnen. Die Zustandsübergänge sind dabei jeweils ein Zeichen für ein Verhalten des Objektes, mithin also seine Methoden. Die Zustände selbst sind durch die Kombination der Objektattribute gekennzeichnet. Bei der Erstellung der Zustandsdiagramme kann man also noch Methoden und Attribute finden, die bei der Interpretation der Systembeschreibung übersehen wurden.
Das Message-Trace- oder auch Interaktionsdiagramm der OMT gibt den Aufruf von Methoden im zeitlichen Ablauf wieder. Dies beinhaltet sowohl die Aufrufe innerhalb eines Objektes als auch die zwischen verschiedenen Objekten. Das Ergebnis ist eine Abbildung, aus der sich der Quellcode praktisch wie von selbst ergibt. Message-Trace-Diagramme wurden aus der OOSE übernommen, werden inzwischen aber von fast allen Methoden verwendet, um den Ablauf von Methodenaufrufen abzubilden.
Neben dem Zustands- und dem Interaktionsdiagramm wird in der OMT noch ein Datenflußdiagramm vorgesehen. Dies hat jedoch eher historische Bedeutung und stammt aus Methoden, die die Vorläufer für objektorientierte Methoden waren. Insbesondere wird in den Datenflußdiagrammen der OMT die Zusammenfassung von Daten und Verhalten, die die objektorientierte Programmierung ausmacht, wieder zum Teil aufgehoben. Dadurch wird die Anwendung dieser Diagramme auf das bereits entwickelte Klassenmodell schwierig.
Die Methode von Grady Booch wird auch (seltener) als OOAD (Object-Oriented Analysis and Design) referenziert.
Sie ist stärker als die bisher vorgestellten Methoden an der Implementierung von objektorientierten Systemen ausgerichtet. Dafür hält sie einige Designregeln parat, die z.B. die Aufteilung in Programmdateien oder die Verteilung von Prozessen ermöglichen sollen.
Die Methode nach Booch ist sehr stark an den Möglichkeiten orientiert, die C++ bietet. Es gibt z.B. eigene Klassentypen für in C++ übliche Template-Klassen oder parametrisierbare Klassen.
Grady Booch hat mehrere andere Ansätze in seine Methode einfließen lassen. So empfiehlt er unter anderem die Analyse nach Coad/Yourdon oder die Bearbeitung von Use-Cases nach Jacobson. Zentrale Aussage seiner Methode ist aber, daß die Erstellung des Modells in kleinen iterativen Schritten passieren soll, die jeweils kleine eigene Analyse-, Design-, Implementations- und Testphasen haben. Damit wird eine stückweise Annäherung an das Gesamtsystem ermöglicht.
Booch schlägt die Zusammenfassung von Klassen in Kategorien vor, um eine Applikation besser strukturieren zu können. Dabei darf eine Klasse nur in einer Kategorie vorkommen. Die Kategorien sind weitestgehend kongruent mit den verschiedenen Ebenen einer Applikation oder den Vererbungsstufen von Klassen. Dadurch, daß Abhängigkeiten zwischen Kategorien nur in einer Richtung bestehen dürfen, ergibt sich eine hierarchische Ordnung der Kategorien. Die Kategorien der obersten Ebene sind innerhalb der Hierarchie diejenigen, die am nächsten an der Schnittstelle der Applikation sind. Die untersten sind die, die die elementarsten Funktionen bereitstellen.
Die OOAD sieht eine Aufgabe für die Modellierung der Implementation darin, die zu erstellenden Dateien zu beschreiben. Diese werden in sogenannten Modulen dargestellt, wobei jedes Modul einer Quellcodedatei entspricht. Quellcodedateien im Sinne von Booch sind auch Headerinformationen (also Include-Dateien). Diese spielen bei der Programmierung in C oder C++ eine große Rolle. In VFP lassen sich Klassen zwar auch in .PRG-Dateien per Quellcode erstellen und zu diesen .PRGs Include-Dateien verwenden, jedoch ist dieser Weg eher unüblich. Auch die Verwendung von je einer .H-Datei für jede Klassenbibliothek bietet sich nicht immer an. An diesem Beispiel kann man gut sehen, daß das Anbieten von Mechanismen zur Implementationsmodellierung sich nicht immer ohne weiteres von der Sprache, in der implementiert wird, trennen läßt. Je nach Projekt und bevorzugter Umsetzungsstrategie lassen sich die Module der OOAD aber im Zusammenhang mit der Einteilung in Kategorien durchaus verwenden.
Ebenfalls implementationsspezifisch ist die Aufteilung in Prozesse. Diese ist eigentlich eher für die Anwendung auf Großrechnern bzw. Rechnernetzen vorgesehen. In diesem Diagrammtyp werden die Rechner, auf denen das System laufen soll und die auf ihnen laufenden Prozesse benannt und ihre Kommunikation dargestellt. Diese Darstellung ist nur dann relevant, wenn das System ein Client-Server-System ist. Es kann also verwendet werden, um Systeme z.B. mit SQL-Backend oder mit Jobservern zu erstellen. Auf den ersten Blick erscheint die Darstellung der Prozesse als trivial, bedenken Sie aber, daß Sie Ihre Entwürfe Ihren Kunden verständlich machen müssen. Eine einfache Darstellung hilft dabei ungemein. Dieses Diagramm dürfte außerdem mit den unter NT 4.0 möglichen Remote-OLE-Aufrufen eine zusätzliche Bedeutung auch für VFP-Entwickler erhalten.
Das herausragende Merkmal der Methode nach Ivar Jacobson sind die Use-Cases. Ein Use-Case ist dadurch gekennzeichnet, daß er durch einen sogenannten Aktor ausgelöst wird. Ein Aktor ist ein Benutzer oder ein beliebiges anderes System, auf jeden Fall aber etwas, das sich nicht innerhalb des zu modellierenden Systems befindet. Auch z.B. Windows mit seinen Ereignissen kann als Aktor betrachtet werden, der Aktionen innerhalb einer Applikation auslöst (z.B. den Shutdown). Das zu erstellende System muß auf eine Anforderung des Aktors reagieren. Aus der Beschreibung der gewünschten Reaktion des Systems werden dann die in Frage kommenden Klassen gewonnen.
In der OOSE wird die Aufteilung der Klassen in verschiedene Typen vorgeschlagen: Interfaceklassen, Controlklassen und Entityklassen. Mit dieser Aufteilung wird die Erstellung von 3-tier-Applikationen stark vereinfacht.
Die Aufteilung des Systems in Use-Cases, die von Aktoren getriggert werden, hat den besonderen Reiz, daß die Beschreibungen der Use-Cases im Lebenszyklus der Applikation mehrfach verwendet werden können: nämlich neben der Beschreibung des erwünschten Verhaltens auch zum Erstellen der Testverfahren und zum Schreiben der Benutzerhandbücher.
Die Use-Cases werden dadurch gefunden, daß der Kunde sagt, was er von einem System erwartet. Im Prinzip ist jeder Wunsch, den der Kunde hat, ein Use-Case. Die Beschreibung, wie diese Anforderung abgearbeitet werden soll, beinhaltet sämtliche Zustände, die das System für diesen Use-Case handhaben soll.
Zu jedem Use-Case gibt es eine beliebige Anzahl von Szenarien. Neben dem „happy day scenario“, das den Verlauf des Prozesses beschreibt, wenn alle geplanten Aktionen ohne Beeinträchtigung hintereinander ablaufen, gibt es mehrere Szenarios, die „nicht normale“ Abläufe beschreiben.
Für die einzelnen Szenarios werden Interaktionsdiagramme (s.a. „OMT anwenden: Message-Trace-Diagramme“) gezeichnet, die den Ablauf von Aktionen nachvollziehbar machen und die jeweils ein Ergebnis für den Aktor hervorbringen.
Die Klassen, mit denen der Aktor umgeht, sind die Interface-Klassen. Diese Klassen beinhalten keine Funktionalität, die die Abarbeitung von Logik in der Anwendung betreffen, sondern geben die Anforderungen von Aktoren lediglich an die Entity- oder die Control-Klassen weiter. Die Control-Klassen dienen der Steuerung des Ablaufes eines Use-Cases, also z.B. der Berechnung von Werten. Die Entity-Klassen beinhalten Methoden für die fachlichen Zusammenhänge der Applikation, arbeiten also direkt auf der Datenbank und nehmen z.B. Validierungen von Werten vor und lesen bzw. speichern Daten. Durch die Trennung in diese drei Klassentypen wird eine hohe Wiederverwertung der Klassen ermöglicht.
Die Unified Modelling Language wird zusammen von Grady Booch, James Rumbaugh und Ivar Jacobson erstellt. Folgerichtig finden sich die Kernsätze dieser Autoren auch in der UML. Die UML bietet ganz bewußt keine feste Vorgehensweise bei der Entwicklung eines OO-Modells an, unterstützt aber sehr stark eine iterative Vorgehensweise in kleinen Schritten.
Interessant ist hier insbesondere, daß diese Entwicklung unter dem Dach der Firma Rational stattfindet. Rational ist eine Firma für Consulting, die aber auch Tools für die objektorientierte Modellierung anbietet. Als zusätzlicher Aspekt ist hier interessant, daß Microsoft und Rational eine strategische Partnerschaft eingegangen sind. Die Entwicklung von UML und ihre Etablierung als OMG-Standard wird aber nicht nur von Microsoft, sondern von vielen anderen Firmen wie HP, Arthur Anderson usw. gefördert. Zur UML gibt es einen speziellen Vortrag von Fabio Peruzzi von der Firma Rational.
Eine methodische Vorgehensweise hat eine starke Analogie zur Architektur von Gebäuden: auch diese bietet Schnittstellen, um mit dem Bauherrn, dem Maurer, dem Elektriker usw. zu kommunizieren.
Methoden kapseln den Entwicklungsprozeß. Sie sind die logische nächst höhere Ebene in der Entwicklung von OO-Software. Sehen Sie sich dazu auch die Dokumentation der UML-Version 0.8 an, die tatsächlich ihre eigenen Konstrukte mit ihrer eigenen Semantik beschreibt.
In den Methoden werden unter dem Begriff ‘Projekt’ teilweise sehr unterschiedliche Abschnitte verstanden. Zum Teil wird darin die Erstellung einer kompletten Applikation auf Basis des Wasserfallmodells gesehen, teilweise die Lösung eines Einzelproblems innerhalb der Erstellung einer Applikation.
Daneben haben die verschiedenen Methoden auch Schwerpunkte in der Art der Applikation, die sich mit ihnen am besten modellieren lassen.
Viele der Methoden beinhalten Konstrukte, um spezielle Features einzelner Sprachen abdecken zu können. Ja nach eingesetzter Sprache (und das gilt besonders für FoxPro) sind die Konstrukte aber entweder nicht mit dem gebotenen Sprachumfang umzusetzen (z.B. parametrisierte Klassen wie in ADA oder Eifel) oder schlicht überflüssig. So sieht UML sogenannte Utility-Klassen vor, die dazu dienen sollen, systemweit benutzte Standardfunktionen abzubilden. Da z.B. Smalltalk nur über Klassen programmierbar ist, sind dort normale prozedurale Funktionssammlungen nicht möglich. Die dafür eingeführten Utility-Klassen sind in VFP aber nicht notwendig, da VFP ja die prozedurale Programmierung voll unterstützt und per „set procedure to“ das Einbinden beliebiger Routinen erlaubt.
Die einzelnen Methoden sind teilweise vor dem beruflichen Hintergrund der Autoren entstanden. Daher ist z.B. die Use-Case Methode besser für technische Systeme, OOA/OOD besser für Geschäftsanwendungen geeignet.
Bauen Sie sich also eine Methode aus den Versatzstücken, die die Ansätze, die ich Ihnen hier vorgestellt habe, bieten. Ihre Methode muß schließlich Ihrer Arbeit zugute kommen und an der Branche, in der Sie arbeiten orientiert sein.
Zuletzt: nehmen sie die Anwendung einer OO-Methode als Chance, eine Qualitätssicherung in Ihrer Firma einzuführen. Der Softwaremarkt wandelt sich dramatisch. Wer in diesem Markt bestehen will, kommt nicht umhin, seinen Kunden genau das zu liefern, was diese verlangen und das zu einem konkurrenzfähigen Preis. Die einzige Möglichkeit, dies zu erreichen, ist die lückenlose Planung und Dokumentation des Prozesses, der zu dem bestellten Programm führt. Nur mit einer am Ingenieurswesen orientierten Vorgehensweise schafft man sich die Basis für zukünftige Wettbewerbsfähigkeit.
Grady Booch: Object-oriented Analysis and Design with Applications, Benjamin/Cummings Publishing, ISBN 0-8053-5340-2; (deutsch bei Addison-Wesley, 79,- DM?) hauptsächlich OO-Design mit eigener Notation, in englisch etwas schwer zu verstehen
Coad/Yourdon: Objektorientierte Analyse, Prentice Hall Verlag, ISBN 3-930436-07-8 (69,- DM); Leitfaden zur Durchführung einer OOA, leicht zu verstehende Notation für Klassen und Beziehungen
Coad/Yourdon: Objektorientiertes Design, Prentice Hall Verlag, ISBN 3-930436-09-4 (59,- DM); setzt mit Notation und Themen direkt auf OOA der gleichen Autoren auf
Rumbaugh u.a. Objektorientiertes Modellieren und Entwerfen, Hanser, ISBN 3-446-17520-2 (88,- DM); komplettes Lehrbuch mit Übungen, Notation ähnlich der von Coad/Yourdan, erweitert um Diagramme zur Zustandsänderung
Ivar Jacobson: Object-Oriented Software Engineering, Addison Wesley, ISBN 1-xxxx-xxx ; nur in englisch erschienen, sehr interessanter Ansatz zur iterativen Entwicklung von OO-Software. Viele der dort vorgestellten Ideen sind von anderen Autoren übernommen worden.
Schäfer: Objektorientierte Entwurfsmethoden, Addison-Wesley, ISBN 3-89319-692-7 (59,90 DM); vergleichender und bewertender Überblick über die Methoden von Booch, Rumbaugh und Coad/Yourdon, weniger als Erklärung für Einsteiger sondern als Entscheidungshilfe für Entwickler geeignet
Gamma: Objektorientierte Entwicklung am Beispiel von ET++, Springer Verlag, ISBN 3-540-56006-8 (69,- DM); Aufzeigen und Systematisieren von wiederkehrenden bzw. wiederverwendbaren Entwicklungsmustern in der OOP
Gamma: Entwurfsmuster, Addison-Wesley, ISBN 3-89319-950-0 (79,90 DM); Übersetzung des Bestsellers Design-Patterns; stellt die gebräuchlichsten Muster von Objektstrukturen dar, ist ohne Vorkenntnisse über Patterns nicht leicht zu verstehen.
Maguire: Strategien der Software-Entwicklung, Microsoft Press, ISBN 3-86063-338-4 (49,- DM, Original: Debugging the Software Development Process, Microsoft Press); leicht lesbare Beschreibung von Managementfehlern, die in einem typischen SW-Projekt gemeinhin gemacht werden und wie sie vermieden werden können.
Pagel/Six: Software-Engineering Band 1, Addison-Wesley, ISBN 3-89319-735-4, (79,90 DM); Darstellung der Phasen in der Softwareentwicklung, die verschiedene Methoden der Analyse und des Managements von SW-Projekten sehr ausführlich beschreibt
Page-Jones: Praktisches DV-Projektmanagment, Hanser, ISBN 3-446-16239-9, (68,- DM); locker geschriebener Leitfaden, der auf die Problematiken in der Managementebene eingeht und Vorschläge für die konkrete Gestaltung des Projektablaufes macht
Thaller: Software-Dokumente, Heise-Verlag, ISBN 3-88229-057-9, (69,- DM); Auflistung von Dokumenten, die während eines SW-Projektes zu erstellen sind, Ausführliche Darstellung von Musterdokumenten für die verschiedenen Phasen des Projektes
http://www.omg.org: Homepage der Object Management Group (OMG); Zusammenschluß von mehr als 400 Firmen, die die Objektorientierung weiterentwickeln und standardisieren wollen
http://www.rational.com: Homepage von Rational Software Corporation; hier sind inzwischen die wichtigsten “Gurus“ (Booch, Rumbaugh, Jacobsen) der OO-Szene versammelt, es soll eine “Unified Method Language“ für OO-Design entwickelt und der OMG als Standard vorgeschlagen werden, Adobe Acrobat Dateien mit dem neuesten Stand werden ständig für den Download bereitgestellt