zurueckweiter


Gründe für objektorientiertes Modellieren von Geschäftsdomänen

Um sicherzustellen, dass ein "Geschäftsbereichsmodell" wirklich von den ins Auge gefassten Benutzern akzeptiert wird, muss es die Aufgabe dieser Benutzer wesentlich erleichtern. Es ist darum sehr wichtig, das die erforderliche Struktur eines solchen Modelles festgelegt wird, denn die Modellstruktur ist sehr wahrscheinlich das Hauptakzeptanzkriterium seiner Benutzer.

Im Allgemeinen muss eine gewählte Struktur:

Aber es gibt auch besondere Anforderungen, die von der zukünftigen Nutzung eines Modelles abhängen. Das sind insbesondere die richtige Auswahl:

Grundlegende Strukturierungsannahmen

Die angenommene Benutzungsart eines Modelles ist im Kontext dieses Dokumentes die Ableitung und Spezifikation von IS Anwendungsentwicklungsprojekten und die Erstellung der grundlegenden Entwicklungsdokumente ("Pflichtenhefte" oder "Objectives", "Specifications" ...) für geplante kommerzielle Anwendungssysteme. Die primäre Zielgruppe für ein Modell ist in unserem Falle also neben den Ausführenden der Geschäftstransaktionen (business professionals) die das Modell zu warten und zu pflegen haben, die Planer und Architekten von kommerziellen Anwendungssystemen. Die folgenden Entscheidungen basieren auf dieser Annahme.

Möglicherweise ist die Entscheidung über die Ausrichtung einer Modellstruktur die wichtigste Entscheidung, die getroffen werden muss. Nicht nur weil es momentan modern ist, empfehle ich die Objektorientierung auch für die Modellstrukturierung.

Gründe für die Objektorientierung.

Objekte sind ein gutes Modell der Wirklichkeit, die durch ein spezielles System nachgebildet wird. Jedes IS Anwendungssystem hat Daten zu manipulieren und muss Geschäftsfunktionen unterstützen, indem es Prozeduren aber auch Führung durch die erlaubte Ablauffolge von Prozeduren zur Unterstützung der Geschäftstransaktionen anbietet. In bisherigen Analyseprojekten und Entwurfsprojekten wurde die Strukturierung der Problemdomäne meist nach Datengesichtspunkten oder Arbeitsablaufsgesichtspunkten vorgenommen, wobei ein Gesichtspunkt meist das ganze Modellierungsprojekt dominierte. Objektorientierung hebt diese Dominanz auf, denn ein Objekt vereinigt beide Elemente (Information und Funktion) als gleichgewichtige Eigenschaften die normalerweise mit "data and behaviour" bezeichnet werden.

Es gibt einen Aspekt der beachtet werden muß, wenn über Objektorientierung im Zusammenhang mit Modellierung gesprochen wird!

Ein "Objekt" ist normalerweise ein konkretes Ding das ein eindeutiges Identifizierungsmerkmal hat. Wenn wir ein Modell einer Geschäftsdomäne erstellen, dann sind wir in Wirklichkeit nicht an den einzelnen Objekten selbst (z.B. einer bestimmten Rechnung von A an B) interessiert. Vielmehr wollen wir im Modell einen Repräsentanten aller Objekte eines bestimmten Typs darstellen. Solch ein "Objekttyp" wird normalerweise als "Klasse" bezeichnet. Wenn im Modellkontext also der Begriff "Objekt" verwendet wird, dann wird in der Regel eine "Klasse" angesprochen.

Obwohl das Modell objektorientiert sein soll, brauchen wir für ein formales Entwicklungsprojekt auch die datenorientierte Sicht um eine Datenbank aufzubauen und die prozessorientierte Sicht um die Anwendungsprogramme und die Arbeitsabläufe zu erstellen. Das bedeutet, dass das Modell zwei wichtige Diagrammtypen haben muss:

  1. ein allumfassendes informationsorientiertes Objektdiagramm, das alle relevanten Geschäftsobjekte (Klassen), ihre geschäftlichen Beziehungen und ihre Zerlegung in Komponenten aufzeigt.

  2. und
  3. eine Hierarchie von prozessorientierten Diagrammen, die alle Geschäftsprozeduren, ihre Zerlegung hin bis zu den elementaren Komponenten sowie die sie auslösenden externen Ereignisse aufzeigt.

Der nächste Schritt ist zu entscheiden, welche Modellkomponenten erforderlich sind und in welchen Diagrammtypen sie gezeigt werden sollen. Die folgende Tabelle listet die empfohlenen Komponenten auf:

Name Beschreibung Diagramm
Klasse der Typ eines Geschäftsobjektes oder einer seiner Komponenten als unauflösliche Verbindung von Information und Verhalten. Klassen
Attribut ein Informationsfeld als ein Charakteristikum einer Klasse. keines
Service eine elementare Routine(programmtechnisch als Methode bezeichnet), die einen besonderen Verhaltenstyp einer Klasse repräsentiert. keines
Beziehung eine Verbindung zwischen Klassen, die eine bestimmte Beziehung oder Abhängigkeit dieser Klassen ausdrückt. Klassen
Handelnder eine Partei (Organisation) die bestimmte Handlungen innerhalb der Geschäftsdomäne ausführt. Prozedur
Prozedur eine Sequenz von Handlungen, die den Ablauf der Durchführung einer bestimmten Geschäftstransaktion bestimmt. Prozedur
Fluss eine Verbindung zwischen Prozeduren, die die mögliche Reihenfolge der Prozedurdurchführung aufzeigt. Prozedur
Ereignis die Ausgabe einer "externen Prozedur" die die Durchführung einer modellinternen Prozedur anstößt. Prozedur

Legende: Klasse = Klassenhierarchie, Prozedur = Prozeduren Diagramm, keines = in keinem Diagrammtyp direkt sichtbar

zum Seitenanfang
zum Inhaltsverzeichnis

zurueckweiter