Bis hierher waren meine Forderungen an eine Modellstruktur noch ziemlich allgemeiner Art, weil bisher nur beschrieben wurde, was im Modell aufgezeichnet werden sollte, aber noch nicht, wie es aufgezeichnet werden sollte.
Um eine besondere Art von Struktur zu erzielen, die ein Geschäftsbereichsmodell besonders leicht wartbar macht, sind Regeln erforderlich, die vorschreiben wie Modellinhalte aufgezeichnet und präsentiert werden sollen. Diese Regeln machen wirklich den Unterschied, natürlich mit der Konsequenz, dass ein Analyst nun in einer disziplinierteren Art und Weise arbeiten muß. Ich habe den JADE Modelltyp als einen Geschäftsbereichsmodelltyp definiert, der primär die Informationssicht und die Prozess-Sicht einer Geschäftsdomäne entsprechend objektorientierter Prinzipien verknüpfen soll, der aber zusätzlich noch einen Satz von Regeln umfasst, der vorwiegend dazu dienen soll, eine besonders anschauliche Darstellungsweise der essentiellen Eigenschaften der Geschäftsdomäne zu erreichen. Alles zusammen macht diesen Modelltyp besonders übersichtlich, extrem leicht erweiterbar und dadurch (meiner Ansicht nach) anderen Modelltypen überlegen.
Die folgenden Abschnitte erläutern die für den JADE Modelltyp eingeführten Regeln in Bezug auf die Darstellung von Klassen und Prozeduren.
Im JADE Modell existieren nicht einfach nur Geschäftsklassen wie z.B. "Kunde" oder "Produkt". Vielmehr werden diese Geschäftsklassen in Komponentenklassen aufgespalten. Diese Komponentenklassen sind kategorisiert, und zwar entsprechend ihrer Funktion in der Klassendekomposition als auch nach ihrer Rolle in Beziehungen zwischen Geschäftsobjekten. Diese Kategorisierung erlaubt eine besonderes Klassenarrangement im Klassenhierarchie Diagramm. Dieses besondere Arrangement macht Modelländerungen und Erweiterungen einfach.
Definiert sind die folgenden Kategorien im JADE Modell:
Kategorie Beschreibung Kernel Klasse Eine "Kernel Klasse" (abgeleitet aus den englischen "kernel" = Innerstes, Wesen) ist eine Klasse, die ein "fundamentales Datenkonzept" repräsentiert. Sie ist darum immer eine "top-level" Klasse (eine Klasse an oberster Hierarchieposition) und hat darum in aller Regel eine große Zahl von Sub-Klassen, die jeweils eine Spezialisierung des Datenkonzeptes darstellen. In Wirklichkeit existieren nur eine sehr beschränkte Anzahl solcher "Kernel Klassen". Beispiele dafür sind: "Dokument", "Lokation", "Identifizierbares Objekt" und "Partei". Sub-Klasse Eine Sub-Klasse (Unter-Klasse) ist eine Klasse, die eine Spezialisierung ihrer Mutterklasse darstellt. Sub-Klassen können wiederum Sub-Klassen haben, es gibt keine Beschränkung der Strukturierungstiefe. Beispiel: "Buch" kann eine Sub-Klasse von "Dokument" (einer Kernel Klasse) sein. Komponentenklasse Eine Komponentenklasse ist eine Klasse, die einen wichtigen Teil ihren Mutterklasse repräsentiert. Eine Komponentenklasse umfasst etwas, das als geschlossene Einheit von Eigenschaften betrachtet werden sollte, d.h. der Mutterklasse nur als Gesamtheit zugefügt oder auch wegenommen werden kann, und dies auch mehrfach. Beispiele: Mutterklasse: Fahrzeug, Komponentenklassen: Motor, Fahrgestell, Rad, .... Beziehungsklasse Eine Beziehungsklasse ist eine Klasse, die eine geschäftliche Beziehung zwischen Objekttypen darstellt. Beispiel: "Eigentümer" kann eine Beziehung zwischen "IdentifizierbaremObjekt" und "Partei" (beides Kernel Klassen) sein. Pseudo Kernel Eine Pseudo Kernel Klasse ist eine Klasse, die ein schwaches fundamentales Datenkonzept repräsentiert. Schwach bedeutet dabei, dass dieses Datenkonzept nicht für sich alleine existieren kann. Es ist also eine Art besonderer Komponente einer Kernel Klasse. Beispiel: "DokumentenElement". Ein Dokumentenelement (z.B. ein Rechnungsposten) gibt es ohne das eigentliche "Dokument" (die Rechnung) nicht. Es kann aber eigene Beziehungen zu anderen Klassen haben, so kann z.B. das "DokumentenElement" "Rechnungsposten" einer "Rechnung" ein "Identifizierbares Objekt" (einen Artikel) referenzieren.
Wie schon weiter oben erläutert, zeigt ein JADE Modell vollständigen Geschäftsklassen nicht direkt. Vielmehr zeigt es deren Komponenten. Obwohl dieses Dokument keine Anleitung zur Geschäftsdomänenanalyse sein soll, möchte ich doch kurz darauf eingehen, wie man während eines Analyseprozesses die JADE-konformen Klassenkomponenten von in der realen Welt beobachteten Geschäftsobjekten ableitet. Ich tue das, weil das Auffinden der richtigen Komponenten so wichtig ist für die Erstellung eines guten Modelles.
Lassen Sie mich die einzelnen Schritte, die man ausführen sollte, der Reihe nach auflisten.
Nachdem die richtigen Klassen gefunden sind, erhebt sich nun die Frage: Wie ordnen wir die Klassen JADE-konform im Klassenhierarchiediagramm an, damit das Diagramm von Beschäftigten des beschriebenen Geschäftszweiges leicht verstanden wird und von IS Anwendungsentwicklern ebenso einfach als Teil ihrer funktionellen Beschreibung und ihres Systementwurfes benutzt werden kann.
Alle Klassen im Klassendiagramm werden ungeachtet ihres Typs als Rechtecke dargestellt. Eine Beziehung zwischen Klassen wird als Verbindungslinie dargestellt. Bevor ich die Anordnungsregeln vorstelle, möchte ich aber zuerst die verwendeten Arten der Verbindungslinien erläutern. Zuallererst muss ich aber kurz etwas über "Kardinalitäten" sagen. "Kardinalitäten" drücken aus, wieviele Individuen eines bestimmten Typs zu wievielen Individuen eines anderen Typs (oder auch des selben Typs) Beziehungen haben können.
Im JADE Modell gibt es 3 unterschiedliche Arten von Klassenverbindungen:
Nachdem die existenten Verbindungsarten zwischen den Kästchen, die Klassen repräsentieren, erläutert sind, komme ich zu den Anordnungsregeln:
Alle Kernel Klassen werden in einer einzigen horizontalen Reihe ungefähr in der Mitte des Klassendiagrammes angeordnet. Wenn dies wünschenswert erscheint, dann können die Kernel Klassen von links nach rechts in aufsteigender alphabetischer Reihenfolge aufgeführt werden.
Die Kernel Klassen sind im JADE Modell die wirklich wichtigen Klassen, die das Rückgrat des ganzen Klassendiagrammes bilden. Die waagerechte Linie, auf der die Kernel Klassen aufgereiht sind, teilt das Klassendiagramm in zwei Teile. Wir werden bald erkennen, dass diese Teile signifikant zur Wartbarkeit des Diagrammes beitragen. Kernel Klassen sind nicht untereinander verbunden. Nur Pseudo Kernel Klassen (als eine Art besonderer Komponenten) sind durch eine Komponentenverbindung mit ihrer Mutterklasse verbunden. Diese Komponentenverbindung startet an der rechten Kante der Mutterklasse (immer eine Kernel Klasse) geht nach rechts, knickt nach unten ab und endet an der oberen Kante der Pseudo Kernel Klasse.
Zu Regel 1: Anordnung von Kernel Klassen.
Alle Komponentenklassen einer Mutterklasse werden im JADE Klassendiagramm rechts von dieser Mutterklasse und zwar eine Zeile unter dieser Mutterklasse angeordnet. Wenn dies wünschenswert ist, dann können die Komponentenklassen von links nach rechts in aufsteigender alphabetischer Reihenfolge aufgeführt werden.
Komponentenklassen werden verwendet, um bestimmte Eigenschaften ihrer Mutterklasse hervorzuheben. Sie sind mit ihrer Mutterklasse durch eine Komponentenverbindungen verbunden. Eine Komponentenverbindung beginnt an der rechten Kante der Mutterklasse. Sie geht nach rechts, knickt nach unten ab und endet an der Oberkante der Komponentenklasse.
Zu Regel 2: Anordnung von Komponentenklassen.
Alle Spezialisierungsklassen einer Mutterklasse werden im JADE Klassendiagramm unterhalb dieser Mutterklasse angeordnet, und zwar eine Spalte nach rechts versetzt. Wenn dies wünschenswert ist, dann können die Spezialisierungsklassen von oben nach unten in aufsteigender alphabetischer Reihenfolge aufgeführt werden.
Spezialisierungsklassen werden verwendet, um zwischen verschiedenen Arten der Superklasse zu unterscheiden. Spezialisierungsklassen sind mit ihrer Superklasse durch Spezialisierungsverbindungen verbunden. Eine Spezialisierungsverbindung beginnt an der unteren Kante der Superklasse. Sie geht nach unten, knickt nach rechts ab und endet an der linken Kante der Spezialisierungsklasse.
Zu Regel 3: Anordnung von Spezialisierungsklassen.
Beziehungsklassen werden im JADE Klassendiagramm im oberen Bereich (dem Beziehungsbereich) angeordnet. Die Beziehungsklassen sind verbunden a) mit Kernel Klassen oder Pseudo Kernel Klassen (als oberste Klasse der Hierarchie, zu der die Klassen gehören, zwischen denen die geschäftliche Beziehung etabliert werden soll) und b) mit anderen Beziehungsklassen.
Beziehungsklassen werden benützt, um geschäftliche Beziehungen zwischen Geschäftsobjekten darzustellen. Beziehungsklassen sind nicht direkt verbunden mit der Spezialisierungsklasse die das Geschäftsobjekt repräsentiert. Vielmehr sind sie verknüpft mit der Kernel Klasse (oder Pseudo Kernel Klasse oder in selteneren Fällen mit einer anderen Beziehungsklassen), die die Spitze der entsprechenden Spezialisierungsstruktur darstellt, zu der das Geschäftsobjekt gehört. Dies geschieht, um die Anzahl der Beziehungsverbindungen durch Vermeidung redundanter Beziehungen zu reduzieren (siehe auch: Über die Abstraktion von Beziehungen und ihre Auswirkung auf die Wartbarkeit eines Modells). Eine Beziehungsverbindung beginnt an der linken oder rechten Kante einer Beziehungsklasse. Sie geht nach links oder rechts, knickt nach unten ab und endet an der oberen Kante der Kernel Klasse, Pseudo Kernel Klasse oder einer anderen Beziehungsklasse. Es ist erlaubt, dass beide Endpunkte der Beziehungsverbindung an ein und derselben Klasse enden (rekursive Beziehung). Beispiel: "Partei" der Spezialisierung "Mann" ist "verheiratet" mit einer anderen "Partei" der Spezialisierung "Frau".
Zu Regel 4: Anordnung von Beziehungsklassen.
Wie oben ausgeführt, stellen die Anordnungsregeln sicher, dass ein JADE Klassendiagramm sehr klar und übersichtlich gegliedert ist. Um einen Eindruck vom Aussehen eines wirklich großen JADE Klassendiagrammes zu geben, ist hier das Klassendiagramm eines Projektes abgebildet, das 6 Kernel Klassen, 1 Pseudo Kernel Klasse, mehr als 25 Beziehungsklassen und mehr als 200 Spezialisierungs- und Komponentenklassen umfasst. Das Diagramm wurde "automatisch" vom JADE Anwendungsmodellierer generiert und gezeichnet (siehe "Kostenlose Downloads").
Das Klassendiagramm eines Modelles zeigt direkt nur Geschäftsklassenkomponenten und ihre Bezeihungen untereinander. Es zeigt nicht die Klassenmerkmale (Informationsfelder und Verhaltensmethoden). Diese Information wird im JADE Anwendungsmodellierer durch Dialoge zur Erfassung und Darstellung von Klasseneigenschaften bereitgestellt. Diese Dialoge liegen "hinter" den Kästchen, die die Klassen repräsentieren.
Die folgenden Abbildungen zeigen die Dialoge zur "Klassendefinition", zur "Variablendefinition" und zur "Methodendefinition" wie sie momentan durch den "JADE Anwendungsmodellierer" implementiert sind.
Der Dialog zur Definition von Klassen:
Anmerkung: Der Dialog erlaubt eine beliebige Anzahl von Variablen und Methoden einzubeziehen.
Der Dialog zur Definition von Variablen:
Der Dialog zur Definition von Methoden:
Anmerkung: Der Dialog erlaubt eine beliebige Anzahl von Parametern über den Dialog zur Definition von Parametern einzubeziehen.
Unter Regel 4 wurde gesagt, dass Beziehungen nur zwischen Kernel Klassen eingerichtet werden, um die Anzahl der Beziehungen zu reduzieren. Das muss näher erläutert werden.
Lassen Sie mich am Beispiel einer "Eigentumsbeziehung" zeigen, was damit gemeint ist.
In einem Geschäftsbereichsmodell wird man eine Vielzahl von Spezialisierungen von "Partei" (z.B. Privatperson, Firma, Juristische Person, Gruppe, ....) und auch von "IdentifizierbaresObjekt" (z.B. Gebäude, Automobil, Werkzeug, Boot, Flugzeug,...) vorfinden. Es gibt ganz bestimmt "Eigentumsbeziehungen" zwischen jeder Partei-Spezialisierung und jeder Objekt-Spezialisierung. Privatpersonen können Gebäude, Automobile, Schiffe und Flugzeuge besitzen. Dasselbe gilt auch für Firmen. Wenn eine Eigentumsbeziehung für alle diese Möglichkeiten erstellt würde, dann würde das ohne Zweifel eine große Anzahl von Beziehungsklassen bedeuten.
Aber sind diese vielen Beziehungen wirklich unterschiedlich? Wenn man sie genauer betrachtet, dann stellt man sehr schnell fest, dass sie alle ziemlich gleichartig sind. Man kann sie alle unter einer generellen Eigentümerbeziehung "Partei besitzt IdentifizierbaresObjekt" zusammenfassen. Dies resultiert daraus, dass ein Klassendiagramm nur Beziehungstypen und keine Einzelbeziehungen aufzeigt. Das bedeutet konkret, dass das Diagramm niemals darstellt, dass die Partei mit Namen "XYZ" das Auto mit dem Kennzeichen "UVW" besitzt, sondern es zeigt nur, dass es in der modellierten Geschäftsdomäne "Parteien" erlaubt ist, "IdentifizierbareObjekte" zu "besitzen".
Im JADE Modell werden alle Geschäftsbeziehungen konsequent an die Spitze der Spezialisierungshierarchie gepuscht - und dadurch verliert das Modell keineswegs an Aussagekraft, es gewinnt vielmehr an Klarheit und Übersichtlichkeit. Zudem deckt es bereits Aussagen ab, die möglicherweise gar nicht explizite durch den Analysten erfassst worden sind, aber trotzdem richtig sind. Wenn es wirklich notwendig wird, Unterschiede von Beziehungen darzustellen, dann kann das einfach durch Spezialisierungen und Komponenten erreicht werden.
Betrachten sie das Bild zu Regel 1. Es zeigt einen Beziehungsbereich ("relationship part") und einen Spezialisierungsbereich ("specialization part"). Entsprechend Regel 4 werden alle Beziehungsklassen nur im oberen Teil des Diagrammes angesiedelt. Sind wir nur an den Beziehungen interessiert, dann können wir den unteren Teil des Diagrammes getrost ausklammern, denn es ist wirklich uninteressant, welche Spezialisierungen bestehen, denn die Beziehungen gelten ja für alle Spezialisierungen. Wir können eine neue Beziehung einrichten, und auch die gilt für alle bestehenden Spezialisierungen, ja sie gilt sogar für zukünftig einzufügende Spezialisierungen. Die Einfügung einer neuen Beziehung stört also in keiner Weise den Spezialisierungsteil des Diagrammes, und das ist ein großer Beitrag zur Stabilität des Diagrammes selbst.
Aber das ist noch nicht alles. Wir können auch mit dem unteren Teil (dem Spezialisierungsteil) des Diagrammes arbeiten, ohne auf den oberen Teil zu achten, das heisst, ohne die Struktur des Beziehungsteils zu gefährden. Wir können also problemlos die bestehende Spezialisierungshierarchie einer Kernel Klasse erweitern oder reduzieren, und oh Wunder, alle bereits definierten Beziehungen werden für die neue Spezialisierungsstruktur gültig. So können wir zum Beispiel die neue Spezialisierung "Möbel" in die Struktur von "IdentifizierbaresObjekt" einfügen und es ist nichts falsch mit der bestehenden Beziehung "Besitz", denn alle vorkommenden Arten von Parteien können natürlich auch "Möbel" besitzen.
Kein Zweifel, die Anordnungsregeln machen das JADE Klassendiagramm klar und übersichtlich, denn die Anzahl der erforderlichen Verbindungen reduziert sich durch die zwei relativ voneinander unabhängigen Diagrammbereiche auf ein Minimum, und dadurch ist das Diagramm sehr leicht zur pflegen.
Ein JADE Klassendiagramm zeigt (wie schon öfters erwähnt) nur Klassen, die Geschäftsobjektkomponenten sind. Aber wir müssen doch die natürlichen Geschäftsobjekte darstellen, denn das ist es ja, was Beschäftigte in der modellierten Geschäftsdomäne wirklich sehen.
Es muss darum verstanden werden, wie ein Geschäftsobjekt aus den bestehenden Modellkonstrukten gebildet wird.
Primär ist ein Geschäftsobjekttyp (eine Geschäftsklasse) durch eine Spezialisierungsklasse im Modell repräsentiert. Wenn wir ein individuelles Automobil beschreiben wollen, dann sollte eine Klasse "Automobil" als eine (direkte oder indirekte) Spezialisierung der Kernel Klasse "IdentifizierbaresObjekt" im Modell vorhanden sein. Aber die Klasse "Automobil" enthält nicht alle Eigenschaften, die über ein Automobil aufgezeichnet werden sollten, um es ausreichend (um nicht zu sagen "vollständig") zu beschreiben. Es gibt Eigenschaften, die in der Hierarchie der Spezialisierungen oberhalb der Klasse "Automobil" enthalten sind. Auch diese Eigenschaften gehören definitiv zum Automobil. Weiter gibt es Eigenschaften in Komponenten, die "Automobil" selbst oder Klassen höher in der Spezialisierunghierarchie (hin bis zur Kernel Klasse) zugeordnet sind. Auch diese Klassen gehören zu der "vollständigen" Beschreibung von "Automobil". Ein Geschäftsobjekt "Automobil" wird also durch eine ganze Gruppe von Klassen (Komponenten, Spezialisierungen und Kernel Klasse) dargestellt.
Wenn wir ein individuelles "Automobil" beschreiben wollen, dann haben wir Instanzen all dieser verschiedenen Komponenten zu generieren und wir haben die individuellen Eigenschaften (wie z.B. die Farbe) in den Feldern dieser Instanzen aufzuzeichnen. Was hält aber die Gruppe zusammen. Es ist das "eindeutige Identifikationsmerkmal" des "Automobils" (welche Eigenschaft auch immer dafür ausgesucht worden ist). Nur dieses eindeutige Identifizierungsmerkmal lässt das Geschäftsobjekt existieren und macht es unterscheidbar von anderen Geschäftsobjekten.
Es gibt nur einen logischen Platz für dieses eindeutige Identifizierungsmerkmal, und der ist innerhalb des Kernel Objektes. Weil alle Instanzen aller Spezialisierungen des Kernel Objektes eindeutig identifizierbar sein müssen, muss das Identifizierungsfeld eine Eigenschaft des Kernel Objektes sein, denn das Kernel Objekt als Spitze der Spezialisierungshierarchie ist das einzige Element, das in allen Gruppierungen (Geschäftsobjekten) vorhanden sein muss. Und nur dadurch ist garantiert, dass es keine doppelten Identifizierungsmerkmale innerhalb eine Kernel Objekt Kategorie gibt.
Da ist noch eine letzte wichtige Sache zu erwähnen:
Es kann Komponenten geben, die mehrfach innerhalb eines Geschäftsobjektes vorkommen können (z.B. die 4 Räder eines "Automobiles"). Diese Komponenten benötigen eine Erweiterung des eindeutigen Identifizierungsmerkmales, es muss z.B. eine laufende Nummer eingeführt werden, die es ermöglicht, diese Mehrfachkomponenten voneinander zu unterscheiden.