".
Als nächstes kann dann überlegt werden, welche Daten einem Akteur, der den Use-Case gestartet hat, anzuzeigen sind und welches Objekt für die Speicherung und Verwaltung dieser Daten zuständig ist. Auf diese Weise lassen sich vorhandene Objekte (Klassen) verwenden oder auch neue Objekte finden, wenn die passenden Zuständigkeiten noch nicht vergeben wurden.
Benennung von Objekten
Die Vergabe eines treffenden Namens für ein Objekt bzw. einen Objektkandidaten kann ein kritischer Faktor für das Verständnis der Modellierung und die weitere Verteilung der Zuständigkeiten sein. Die Namen der Objekte sollten daher möglichst Auskunft über die Aufgabe des jeweiligen Objektes geben, ohne dabei auf spezielle Funktionen zu verweisen. Ein Objektname ist also ein Begriff des Anwendungsgebietes oder der Programmsteuerung, der kein Verb enthält.
Zum Beispiel wird statt eines Objektes "GUI-Controls enablen" also ein Objekt "GUI-Manager" aufgebaut werden. Dieser erhält als Zuständigkeit, das Enabling und Disabling der GUI-Controls zu managen. Dazu wird dieser GUI-Manager in die Lage versetzt werden müssen, die einzelnen GUI-Elemente zu kennen, er erhält aus der ersten Zuständigkeit (etwas zu tun) also die weitere Zuständigkeit, etwas zu wissen. Daneben wird dieser GUI-Manager, da er derjenige sein wird, der die GUI-Controls kennt, im Zuge der Modellierungarbeit weitere Zuständigkeiten bekommen, die auf das ihm eigene Wissen aufbauen.
Die Namen der Objekte müssen in dieser Phase der Modellierung nicht engültig sein. Wenn festgestellt wird, daß ein Name unpassend ist, oder ein Objekt weitere Zuständigkeiten erhält, die sich in seiner Benennung nicht wiederfinden, sollten die Objekte umbenannt werden.
Regeln im Use-Case
Anhand der im Use-Case genannten Prüfungen und Regeln können Zuständigkeiten gefunden werden. Solche Zuständigkeiten sind z.B.:
- einen Versicherungstarif berechnen
- die tarifrelevanten Daten speichern
- einen errechneten Beitrag liefern.
Die Zusammenfassung solcher Zuständigkeiten anhand einer logischen Aufteilung (hier anhand der Dinge, die mit einem Tarif zu tun haben) führt dann zu Objekten, in dem genannten Fall zu einem Objekt "Versicherungstarif". Sollte also im Use-Case beschrieben werden, wie ein Versicherungstarif berechnet wird, gibt es die Zuständigkeit "Berechnen des Tarifs". Als Objekt, dem diese Zuständigkeit zugeordnet wird, könnte dann ein Objekt "Versicherungstarif" in einem Kollaborationsdiagramm angelegt werden. Diesem werden dann die genannten Zuständigkeiten (s.a. Verwaltung der Analyseobjekte) zugeordnet.
Abgrenzung von Objekten
Ein Objekt sollte bei der Erledigung seiner Aufgaben möglichst oft auf eigene Attribute und weniger oft auf Attribute bzw. Operationen von anderen Objekten zugreifen (Objektkohäsion). Ein in sich geschlossenes und möglichst unabhängiges Objekt (bzw. die dafür definierte Klasse) lassen sich leichter wiederverwenden. Anhand einer hohen Notwendigkeit, externe Datenzugriffe vorzunehmen, also Attribute bzw. Operationen anderer Objekte zu nutzen, kann die dieser Notwendigkeit zugrundeliegende Zuständigkeit ggf. an ein anderes Objekt vergeben werden.
Externe Datenzugriffe heißt in diesem Zusammenhang, daß das Objekt zur Erledigung einer Aufgabe auf Daten in der Zuständigkeit anderer Objekte angewiesen ist. Sind für die Erfüllung einer speziellen Aufgabe mehr Zugriffe auf externe Daten als Zugriffe auf eigene Daten (Eigenschaften) notwendig, so ist zu überprüfen, ob die zu erledigende Aufgabe nicht besser in einem anderen Objekt aufgehoben ist und aus dem aktuellen Objekt die Anfrage zu Erledigung dieser Aufgabe nicht einfach nur weitergegeben (delegiert) wird.
Enthält ein Objekt im Gegensatz dazu durch die Definition einer Zuständigkeit einen Datenwert, der für die eigenen Aufgaben etwas zu tun oder zu liefern (formuliert in ggf. schon angelegten Operationen) nicht verwendet wird, so kann die Verantwortung für die Verwaltung dieses Datenwertes ggf. an ein anderes Objekt weitergegeben werden.
Bei der Weitergabe von Zuständigkeiten, zur Speicherung von Daten und zur Erledigung von Aufgaben an andere Objekte kann das Objekt, das dieser Zuständigkeiten "enthoben" wurde, weiterhin das Wissen behalten, welches Objekt die eigentliche "Arbeit" erledigt. Damit bleibt das Objekt aus Sicht anderer Objekte die Schnittstelle für diesen Datenwert, delegiert aber die Bearbeitung weiter, ohne daß (ggf. viele) andere Objekte von der Delegation wissen müssen.
Konvertierung von vorhandenen Funktionen
Ist Inhalt eines Projektes, das in objektorientierter Technik zu implementieren ist, die Konvertierung einer bestehenden Applikation, so kann auch die vorliegende prozedurale Programmierung in FoxPro 2.x als Grundlage für die Objektmodellierung dienen.
Im Zuge der Analyse der vorhandenen Masken werden dabei ggf. Funktionen gefunden, die auch im neuen System benötigt werden. Diese Funktionen können auf zweierlei Art implementiert werden:
- Implementation als Operation: die bei der Analyse der gefundenen Funktionen sind in der Regel Funktionen, um Geschäftsregeln sicherzustellen. Wurde eine Funktion gefunden, die nicht auf Anhieb einem bereits für diesen Use-Case erstellten Objekt zuzuordnen ist, so muß ggf. ein neues Objekt erstellt werden. Eine Funktion, die z.B. die Summe für alle Nachlässe eines Angebots erstellt, ist nicht so ohne weiteres dem Angebots-, den Preis- oder den Angebotsleistungsobjekten zuzuordnen. In diesem Fall bietet sich an, ein zusätzliches Objekt "Nachlässe" aufzubauen, das als Zuständigkeit bekommt, die Berechnung der Nachlässe für alle Positionen des spezifischen Angebots zu übernehmen.
- Implementation als Prozedur: Funktionen, die nicht ausschließlich in einem Geschäftsobjekt bzw. einer Klasse oder Gruppe von Geschäftsobjekten benötigt werden, können in einer Prozedurbibliothek implementiert werden. Im Zuge der Analysearbeiten an den Angebotsprogrammen sollten solche Funktionen aber nicht mehr neu gefunden werden. Bei einer Unsicherheit, ob eine solche Funktion bereits in einer anderen Klasse vorhanden ist, muß ggf. innerhalb des gesamten Projektteams geforscht werden. Der Ersteller einer solchen Funktion kann auch die Nutzung dieser Klassen bzw. Funktionen erläutern.
Die Implementation von bestehenden Funktionen als Prozedur sollte die rare Ausnahme bleiben, da eine solche Lösung i.d.R. schlecht in eine objektoriertierte Umgebung integrierbar ist. Eine entsprechende Entscheidung sollte sorgfältig auf alternative Möglichkeiten geprüft werden.
Arrays
Die verschiedenen Arrays in einem bestehenden Programm, insbesondere solche, die für die Übergabe von Daten zwischen Programmteilen benutzt werden, können als Objekte betrachtet werden. Im Idealfall hat das Array einen genau spezifizierten Inhalt von auch zusammengehörigen Datenelementen und damit eine "Identität", die sich in einem Begriff zusammenfassen läßt. Der Oberbegriff dieser Datenelemente (z.B. "Angebotsdaten") kann dann als Name für ein Objekt dienen. Die verschiedenen Arrays in einem bestehenden Programm, insbesondere solche, die für die Übergabe von Daten zwischen Programmteilen benutzt werden, können als Objekte betrachtet werden. Im Idealfall hat das Array einen genau spezifizierten Inhalt von auch zusammengehörigen Datenelementen und damit eine "Identität", die sich in einem Begriff zusammenfassen läßt. Der Oberbegriff dieser Datenelemente (z.B. "Angebotsdaten") kann dann als Name für ein Objekt dienen.
Arrays, die dagegen nicht über eine Übereinstimmung des Zwecks ihrer Inhalte verfügen, sondern eine Zusammenfassung von Daten mehrerer bereits in der Objektmodellierung für den Use-Case existierender Objekte darstellen, sollten in die logisch zusammengehörigen Daten aufgeteilt werden. Die einzelnen, dann benannten Teile des Arrays können dann wieder als Begriff für ein oder mehrere neue Objekte dienen.
Daneben dienen die Arrays aber auch oft nur der Zusammenfassung von Daten, um sie per Referenz zwischen Funktionen übergeben zu können. Sollten sich diese Arrays nicht bereits durch die Zuordnung von Funktionen zu den zuständigen Objekten erledigt haben, besteht die Möglichkeit, auch daraus neue Objekte zu bilden. Diese "Transportobjekte" sollten dann über eine begrenzte Anzahl von Eigenschaften verfügen, die das Protokoll des Datenaustauschs zwischen zwei anderen Objekten definieren und damit vereinfachen. Anstatt also zur Übergabe von 10 Datenelementen zwischen zwei Objekten jeweils separate Methoden anzulegen, kann in einer Methode des "Senderobjektes" ein Transportobjekt erzeugt werden, das dem "Empfängerobjekt" übergeben wird. Dieses arbeitet mit den Daten (Eigenschaften) des Transportobjektes, beschreibt also dessen Eigenschaften mit neuen Datenwerten. Diese Eigenschaften sollten immer Kopien der Originaldaten des Senderobjektes darstellen, damit dessen Daten nicht außerhalb der Umgebung, die die Geschäftsregeln beinhaltet, manipuliert werden können. Sollte das Empfängerobjekt Manipulationen an den Daten vorgenommen haben, so sollte das Objekt das Transportobjekt zurückgeben an das ursprüngliche Senderobjekt, damit diese Datenänderungen geprüft und ggf. übernommen werden können.
Abgeleitete Zuständigkeiten
Auch aus einer Zuständigkeit resultierende neue Zuständigkeiten können wieder zu neuen Objekten führen. So ist für die Berechnung eines Tarifs ggf. ein Auslesen von Tarifdaten aus einer Postleitzahlentabelle notwendig. Das Suchen innerhalb dieser Tabelle und das Zurückgeben eines Tarifmultiplikators kann wieder einem speziellen Objekt als Zuständigkeit gegeben werden. Das Objekt hat dann z.B. den Namen "Tarifgebiet" und die Zuständigkeit, für eine Kombination von PLZ und Einkommenshöhe einen Zuschlag oder Abschlag zu berechnen.
Noun-Analysis
Ein bekanntes Verfahren, Objekte bzw. Objektkandidaten in einem Anforderungstext wie z.B. einer Use-Case-Beschreibung zu finden, ist die Untersuchung des Textes auf vorkommende Substantive (engl.: "nouns"). Diese werden auf ihre normale Form (aus Deklinationen und Mehrzahlen wird jeweils der Nominativ in Einzahl gebildet, also wird z.B. aus "… der Verträge" ein Objekt "Vertrag") zurückgeführt und in eine Liste gestellt. Diese Liste dient dazu, Objektkandidaten zu erstellen. Als Ergebnis einer solchen Arbeit entsteht sehr oft eine zu statische Ansammlung einer großen Anzahl von Objekten, die oft auch überschneidende Verantwortlichkeiten haben. Die so erstellten Objekte müssen wieder durchgearbeitet werden und auf ihre Relevanz für das Objektmodell überprüft werden. Bei der Arbeit bietet sich die Erstellung einer Liste der enthaltenen Substantive (s.a. Abgleich der Objektnamen) zu dem Zweck, ein einmal erstelltes Objektmodell zu überprüfen, an. Diese Prüfung kann halbformal erfolgen, indem die Use-Case-Beschreibung nach dem ersten Entwurf der darin "handelnden" Objekte noch einmal auf Substantive durchsucht und geprüft wird, ob diese Substantive bzw. die damit verbundenen Aufgaben innerhalb der bereits modellierten Objekte behandelt werden.
Mehrfach vorkommende Objekte
Tritt ein Begriff des Anwendungsgebietes in der Mehrzahl auf und läßt er sich nicht sinnvoll auf seinen Singular zurückführen, so sollte für die Verwaltung dieser mehrfach vorkommenden Objekte ein neues Objekt eingeführt werden. Dieses Objekt erhält typischerweise einen Namen, der auf ?liste oder ?collection endet. Alle Zugriffe auf die mehrfach vorhandenen Objekte erfolgen dann ausschließlich über dieses Listenobjekt.
Ein Beispiel hierfür ist z.B. die Liste aller Positionen in einem Angebot. Dieses Listenobjekt erhält neben der Zuständigkeit, die einzelnen Positionen zu verwalten, also die Operationen zum Hinzufügen oder Löschen von Positionen, z.B. die Zuständigkeit, die Gesamtsumme aller Angebotspositionen zu liefern.
Verwaltung der Analyseobjekte
Die Objekte für die Geschäftslogik können in einem OO-Tool wie Rational Rose verwaltet werden. Aktuelle Tools zum Verwalten von Objekt- und Klassenmodellen basieren i-d.R. auf der UML , die als Diagramme zur Darstellung von Objekten die Interaktionsdiagramme kennt. Interaktionsdiagramme kommen in zwei verschiedenen Formen vor: Sequenz- und Kollaborationsdiagramme. Im Modell eines solchen Tools bietet sich die Erstellung eines Kollaborationsdiagramms an. Dieses wird dem jeweiligen Use-Case zugeordnet und erhält z.B. den Namen "Geschäftsobjekte". Kollaborationsdiagramme haben gegenüber den Sequenzdiagrammen den Vorteil, daß sich die Objekte frei auf dem Diagramm plazieren lassen. In dem Diagramm werden aber zunächst keine Verbindungen zwischen den Objekten und keine Nachrichten eingetragen. Ziel dieses ersten Arbeitsschrittes ist ausschließlich, Objekte zu finden und sie über ihre Zuständigkeiten zu definieren.
In dem Übersichtsdiagramm "Geschäftsobjekte" wird also für jede Gruppe von Zuständigkeiten ein Objekt angelegt. In der Dokumentation des Objektes werden die Zuständigkeiten für das Objekt eingetragen.
Für jeden Use-Case sollte zumindest das "happy-day scenario" (auch "primäres Szenario") in Form eines Sequenz- oder Kollaborationsdiagramms erstellt werden. Grundüberlegung bei der Erstellung dieses Szenarios sollte sein, was das Ziel des Use-Cases, also das Produkt bzw. Ergebnis ist, das im Erfolgsfall beim Durchlaufen des Use-Cases erstellt bzw. zurückgegeben wird (oft ist die Rückgabe ein Objekt).
In dem primären Szenario wird nun der Ablauf modelliert, der normalerweise mindestens notwendig ist, um den Erfolgsfall zu erreichen. Dabei sollten die Objekte, die in dem Diagramm "Geschäftsobjekte" angelegt wurden, entsprechend ihrer Zuständigkeit verwendet werden. Werden bei der Erstellung des Szenarios Zuständigkeiten gefunden, die sich nicht in einem der Objekte des Diagramms "Geschäftsobjekte" wiederfinden, so ist diese Zuständigkeit entweder einem der vorhandenen Objekte zuzuordnen oder ein neues Objekt in den Geschäftsobjekten anzulegen.
Extraktion der Regeln aus den Use-Cases
Wiederholungen von Regeln und Control-Gruppen
Innerhalb der Use-Cases können Gruppen von Controls auf vielen verschiedenen Formularen auftreten, z.B. zur Erfassung der Daten für eine Adresse. Diese Gruppe kann für viele Adreßtypen wie Kunden- Ansprechpartner- oder Lieferantenadressen verwendet werden. Diese Control-Gruppen verfügen oft auch über die exakt gleichen Regeln zu Überprüfung der Eingaben.
Um die Nachvollziehbarkeit für Leser der Use-Cases in solchen Fällen zu erhalten, werden die benötigten Regeln - anstatt sie direkt in einem Objekt abzubilden - in einem separaten Use-Case zusammengefaßt, auf den eine
<<uses>> -Beziehung aufgebaut wird. Innerhalb der Dokumentation, die die übergeordneten Use-Cases beschreibt, wird ein Hinweis auf den neuen Use-Case angelegt und im Text darauf verwiesen, daß die Prüfung der Regeln in dem referenzierten Use-Case beschrieben ist. Die Objekte, die in dem referenzierten Use-Case enthalten sind, werden wie beschrieben angelegt.
Ungenauigkeiten oder Auslassungen
Enthalten die Use-Cases Ungenauigkeiten oder Auslassungen, die die Erstellung der Kommunikation zwischen den Objekten unmöglich, spekulativ oder ohne Rückfrage über die Maßen zeitaufwendig macht, können - so möglich - für die zu klärenden Sachverhalte "Platzhalterobjekte" eingesetzt werden, die die "Unklarheiten kapseln". Hier können später Regeln eingesetzt werden, die die Interpretation der Antworten auf Fragen, die bei der Erstellung des Objektmodells aufgetreten sind, übernehmen.
Regeln zur Prüfung des Objektmodells
Sind Attribute Objekte?
Keine Objekte im Sinne einer Objektmodellierung sind i.d.R. Datenattribute, die normalerweise auf Feldern der Datenbank beruhen. Dies sind z.B. Angaben zu Vor- und Nachname oder Adressen von Personen. Diese Elemente werden als normale Attribute der Geschäftsobjekte modelliert. Ggf. ist hier das Hinzufügen einer entsprechenden Methode für das Berechnen oder das Setzen eines Wertes an das Geschäftsobjekt anzufügen.
Wann werden Attribute Objekte?
Ein Datenattribut kann zu einem eigenen Objekt werden. Dies gilt dann, wenn für die Bearbeitung dieses Attributs (z.B. ein Rabattwert) mehrere Operationen notwendig werden, die sich auf eine abgeschlossene Anzahl von Attributen beziehen. Hat also ein Attribut "Rabatt" mehrere Nebenattribute, z.B. "Kundengruppe" "AnzahlBanktage" für den Abstand der Tage zwischen Rechnung und Zahlung und gibt es für das Setzen oder Abfragen solcher Attribute mehrere Operationen, so kann daraus ein eigenes Objekt erstellt werden.
Wie reagiert das Objektmodell auf Namens- oder Zustandsänderungen?
Ändern sich Zustände von Objekten oder wird ein Objekt in ein anderes transformiert, so ist nicht zwingend ein neues Objekt aufzubauen. Eine Zustandsänderung oder Transformation ist z.B. an der Namensänderung des Objektes (Beispiel: "Angebot" wird "Auftrag") zu erkennen. Der Aufbau eines neuen Objektes verbietet sich insbesondere dann, wenn die Datenelemente des Objektes nach der Transformation fast völlig identisch sind mit denen des Objektes vor der Transformation und sich nur durch ein Flag unterscheiden. In einem solchen Fall sollte das Flag als Attribut der Klasse modelliert werden und die Bedingungen für den Zustandswechsel sollten in der Dokumentation des Objektes (bzw. der zugehörigen Klasse) genannt werden.
Wie werden die Zuständigkeiten verteilt?
Alle Objekte im Analysemodell sollten eine gewisse Anzahl Zuständigkeiten haben. Diese Anzahl sollte nicht zu sehr von der durchschnittlichen Anzahl der Zuständigkeiten pro Objekt abweichen. Sollten im Analysemodell Objekte enthalten sein, die mehr als doppelt so viele Zuständigkeiten haben, wie der Durchschnitt, sollten diese Objekte ggf. aufgeteilt werden. Objekte, die weniger als 20% der durchschnittlichen Zuständigkeiten haben, sollten ggf. in andere Objekte integriert oder mit anderen kleineren Objekten zusammengelegt werden.
Sollte sich eine Teilung oder Zusammenlegung bei besonders "großen" oder besonders "kleinen" Objekten nicht anbieten, so sind die Gründe, die dagegen sprechen, zu dokumentieren, um bei weiteren Überarbeitungen nicht immer von neuem über die Verteilung der Zuständigkeiten nachdenken zu müssen.
Die durchschnittliche Anzahl der Zuständigkeiten braucht dabei nicht berechnet zu werden, sondern es reicht eine Schätzung.
Wieviel Zuständigkeiten sollte ein Objekt haben?
Als Regel für die Verteilung der Zuständigkeiten gilt, daß sich ein Objekt mit seinen Aufgaben leicht verstehen lassen soll. Daraus ergibt sich, daß die Anzahl der Zuständigkeiten nicht mehr als ca. 5 - 10 sein sollte. Die aus den Zuständigkeiten abgeleiteten Attribute und Operationen sollten jeweils 30 Stück nicht überschreiten.
Neben der genannten Obergrenze sollte ein Objekt auch eine gewisse Mindestanzahl von Attributen und Operationen haben. Diese sollten nicht weniger als jeweils 3 sein.
In beiden Rechnungen sind die Operationen und Attribute, die ausschließlich für die Initialisierung und das Löschen des jeweiligen Objektes notwendig sind, nicht enthalten.
Abgleich der Objektnamen
Die in der Analysephase in den verschiedenen Use-Cases gefundenen Objekte sollten i.d.R. mit Namen aus der Begriffswelt des Anwendungsgebietes benannt werden. Hiermit werden den Objekten Begriffe zugeordnet, die eine Beurteilung der Zuständigkeiten und die Zusammenarbeit der verschiedenen Entwickler erleichtern. Um die Bedeutung der Begriffe über das Anwendungsgebiet zu vereinheitlichen, bietet sich die Erläuterung dieser Begriffe in einem Projektglossar an.
Ein entsprechendes Dokument / Projektglossar beinhaltet eine Aufstellung aller erläuterungsbedürftiger Begriffe sowie eine Anleitung zur Erweiterung und Bearbeitung dieser Liste.
Literaturhinweise:
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
Oesterreich: Objektorientierte Softwarentwicklung, Oldenbourg-Verlag, ISBN 3-486-24319-5, (89,- DM); Überblick über die Elemente der UML und die Techniken zur Modellerstellung, gut lesbar
Riel: Object-Oriented Design Heuristics, Addison-Wesley, ISBN 0-201-63385-X, (ca. 90,- DM); Auflistung von Erfahrungsregeln zum Design von OO-Systemen
Webster: Pitfalls of Object Oriented Development. M&T Books, ISBN 1-55851-397-3 (ca. 60,- DM); Nennt die "beliebtesten" Fehler in OO-Projekten, bietet Ansätze zum Erkennen, Vermeiden und Beheben von Fehlern
Egger: Advanced Object Oriented Programming with Visual FoxPro 6.0, Hentzenwerke Publishing, ISBN 0-96550-938-9, ca. 100,- DM); speziell auf die Notwendigkeiten von VFP eingehendes Buch, das aber auch einen Überblick über den gesamten objektorientierten Entwicklungsprozeß und die dafür verwendbaren Tools gibt
Internet:
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.