zurueckweiter


Das JADE Modell, ein besonderer Typ eines Geschäftsmodelles

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.

Kategorien von Klassen

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 findet man JADE-gerechte Komponenten

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.

  1. Erstellen Sie eine Liste der Geschäftsobjekte, die man in der Problemdomäne gefunden hat. Aus diesen Geschäftsobjekten sollten zuerst die erwünschten Kernel Klassen und Pseudo Kernel Klassen herausabstrahiert werden, die im zu erstellenden Geschäftsbereichsmodell verwendet werden sollen. Man kommt zu den Kernel Klassen, indem man eine brauchbare Superabstraktion sucht, der die Geschäftsklasse zugeordnet werden kann. Normalerweise gibt es davon nicht viele. Gute Kandidaten für Kernel Klassen bzw. Pseudo Kernel Klassen sind "Dokument", "DokumentenElement", "Partei", "Angebot", "Identifizierbares Objekt", "Lokation" und "Zeit".


  2. Ermittle die Spezialisierungshierarchie der definierten Kernel Klassen. Leite sie ab aus der Kategorisierung von wichtigen Eigenschaften, die an den Geschäftsobjekten der Geschäftsdomäne beobachtet wurden. Eine Spezialisierung von "Dokument" könnte beispielsweise "Vertrag" sein. Der "Vertrag" könnte wieder "Arbeitsvertrag" und "Kaufvertrag" als Spezialisierungen aufweisen. Es ist zu beachten, dass entsprechend der Regeln für Objektorientierung eine Spezialisierungsklasse alle Eigenschaften ihrer Superklasse ererbt.


  3. Ermittle die passenden Komponenten der festgelegten Spezialisierungen. Gute Kandidaten für Komponenten sind logisch eng miteinander verknüpfte Eigenschaftsgruppen einer Spezialisierung, die durchaus auch mehrfach vorkommen können. Die Komponenten von "Automobil" als Spezialisierung von "Landfahrzeug", wiederum eine Spezialisierung von "identifizierbares Objekt", könnten "Motor", "Getriebe", oder "Rad" (4 davon) sein. Assoziiere die gefundenen Komponenten mit der höchstmöglichen Spezialisierung in der Hierarchie. Es ist dabei zu beachten, dass eine Komponente ein integraler Teil der Spezialisierungs-Subklasse ist und dass eine Komponente selbst wiederum Komponenten und natürlich auch Spezialisierungen haben kann.


  4. Ermittle die in der Geschäftsdomäne bestehenden Beziehungen zwischen Geschäftsobjekten und definiere (wiederum durch Abstraktion) die wünschenswerten Beziehungsklassen. Auch hier ist zu beachten, dass Beziehungsklassen ebenfalls Komponenten und Spezialisierungen haben können. Ein "Automobil" zu "besitzen" kann die Beziehung zwischen "Fahrzeug" und "Natürlicher Person" sein, aber Vorsicht, auch eine "Juristische Person" kann ein Fahrzeug besitzen. Auch sollte beachtet werden, dass Beziehungen ausschließlich auf der "Kernel Ebene" definiert werden, denn es gibt eigentlich niemals Unterschiede in der Art der Beziehungen, die abhängig sind von der Spezialisierungsebene, für die sie gefunden wurden. Eine "Besitz" Beziehung kann also ohne weiteres zwischen "Identifizierbarem Objekt" und "Partei" (also Kernel Klassen) hergestellt werden und sie gilt dann für alle bestehenden Spezialisierungen. Es besteht überhaupt kein Grund, z.B. eine Beziehung zwischen "Auto" und "Privatperson" oder "Schiff" und "Reederei" einzuführen.

Anordnungsregeln für das JADE Klassendiagramm

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:

  1. Spezialisierungsverbindungen, im "Information Engineering" auch als "is a" ("ist ein(e)") Beziehung bezeichnet. Eine Spezialisierungsverbindung ist immer eine "eins zu null" Beziehung. Das bedeutet, dass ein Individuum eines Supertypes nicht unbedingt ein Mitglied eines der definierten Subtypen sein muss, das aber ein Individuum eines Subtyps immer auch ein Mitglied seines Supertyps ist. In anderen Worten: ein Fahrzeug kann entweder ein Auto oder ein Schiff sein, ein Auto ist aber immer ein Fahrzeug.


  2. Komponentenverbindungen, im "Information Engineering" auch als "has" ("hat") Beziehung bezeichnet. Eine Komponentenverbindung existiert im JADE Modell zwischen Klassen und ihren Komponenten; Komponenten, die abgetrennt wurden, um bestimmte Eigenschaften der Mutterklasse hervorzuheben. Eine Komponentenverbindung ist immer eine "eins zu viele" Verbindung. Das bedeutet ein individuelles Mutterobjekt kann viele (genauer: jede beliebige Anzahl, Null eingeschlossen) Komponenten haben, eine Komponente eines bestimmten Typs gehört aber immer zu "einem" Mutterobjekt. Zum Beispiel kann ein Fahrzeug 0, 1, 2, 3, 4, ... Räder haben, "ein" spezielles Rad gehört aber immer zu "einem" bestimmten Fahrzeug.


  3. Beziehungsverbindungen, im "Information Engineering" auch als "many to many" ("viele zu vielen") Beziehungen bezeichnet. Im JADE Modell existiert eine Beziehungsverbindung immer zwischen einer Klasse, die einen Beziehungstyp (z.B. "Besitz") repräsentiert und zwei (manchmal auch mehr) Klassen, zwischen denen die Beziehung besteht. Im Modell werden nur Beziehungstypen und keine individuellen Beziehungen dargestellt. Trotzdem ist eine Beziehungsverbindung eine "eins zu eins" Verbindung. Das bedeutet, dass eine individuelle Beziehung eines bestimmten Beziehungstyps immer zwischen Individuen der in Beziehung stehenden Objekttypen besteht. Zum Beispiel "gehört" das "Auto" mit der Registriernummer "xyz" der "Partei" mit Namen "uvw".

Nachdem die existenten Verbindungsarten zwischen den Kästchen, die Klassen repräsentieren, erläutert sind, komme ich zu den Anordnungsregeln:

Regel 1

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.
rule 1

Regel 2

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.
rule 2

Regel 3

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.

rule 3

Regel 4

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.
rule 4

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").

a big class diagram

Was steckt hinter den Diagrammkästchen

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.

class properties

Der Dialog zur Definition von Variablen:

variable dialog

Der Dialog zur Definition von Methoden:
Anmerkung: Der Dialog erlaubt eine beliebige Anzahl von Parametern über den Dialog zur Definition von Parametern einzubeziehen.

method dialog

Über die Abstraktion von Beziehungen und ihre Auswirkung auf die Wartbarkeit eines Modells

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.

Komposition von Geschäftsobjekten und ihre Identifizierung

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.


zum Seitenanfang
zum Inhaltsverzeichnis

zurueckweiter