1.1 Statik und Dynamik

Struktur + Verhalten

Jede objektorientierte Theorie muss   zwei Bereiche berücksichtigen, zum einen die Modellierung von „Strukturen“ (die es immer gibt, in Programmen, in Datenbanken und in der Unternehmensmodellierung), zum anderen die Modellierung von Verhalten (Abläufen, Verhalten, Geschäftsprozessen, usw.). Auch letztere gibt es immer.

In den Ansätzen vor der Objektorientierung war die Aufteilung recht klar und einfach. Die Strukturen waren informationelle Strukturen und wurden per Datenmodellierung bewältigt. Die „Dynamik“ (Verhalten, Abläufe, Geschäftsprozesse) wurde per Systemanalyse in Modelle umgesetzt, die Geschäftsprozesse wurden nicht oder getrennt betrachtet.

Mit der objektorientierten Theorie wurde dies etwas anders. Es werden zwar „structure“ und „behavior“ (wie die US-amerikanische Literatur es nennt) immer noch getrennt, mit der Einbindung von Methoden bei den Klassen sind diese aber auch gleich mit wichtigen Aspekten von Dynamik ausgestattet. So dass wir hier bezüglich der Thematik „Struktur + Verhalten“ folgende Situation haben:

Statische und dynamische Aspekte des Anwendungs-
bereichs

• Modellierung der Strukturen durch Klassen mit ihren Attributen (hier in den Kapiteln 2 – 6):
• Modellierung der „Dynamik Stufe 1“ durch Methoden/Operationen in den Klassen (hier in Kapitel 7). In der Abbildung unten mit Nachrichtenverkehr bezeichnet.
• Modellierung „Dynamik Stufe 2“ durch die UML-Theorieelemente für die Verhaltensmodellierung (hier in den Kapiteln 9 – 13).

Die folgende Abbildung gibt den daraus folgenden Aufbau der inhaltlichen Kapitel an.

1.2 Innerer Aufbau der einzelnen Kapitel

Basiswissen + Vertiefung

Die einzelnen Kapitel sind so gestaltet, dass in den ersten Abschnitten das Basiswissen zum jeweiligen Gegenstand vorgestellt wird. Etwa so, wie es in einem Bachelor-Studiengang zu vermitteln ist. Es folgen dann Abschnitte, die mit Vertiefung bezeichnet sind. Sie enthalten Themen, die nach den Erfahrungen des Verfassers in weiterführenden Studiengängen, z.B. in Masterstudiengängen, vermittelt werden können. Ihre Bearbeitung würde den zeitlichen Umfang, der in Bachelorstudiengängen zur Verfügung steht, sprengen.

Bei den Kapiteln zu „Strukturen“ ist in der Regel fast der gesamte Text im Grundlagenteil. Bei denen zu „Verhalten“ nicht. Eine Ausnahme stellt Kapitel 10 zu den Aktivitäten dar. Hier sollte – wegen der Bedeutung dieses Themas für die Wirtschaftsinformatik – in einer Bachelorveranstaltung das gesamte Kapitel besprochen werden. Weggelassen werden kann das Tokenkonzept, das im ganzen Kapitel immer wieder angesprochen wird.

Die Abschnitte mit den Beispielen sind wiederum für alle von Interesse – je nach Kenntnisstand. Es wurden bewusst viele Beispiele eingefügt, weil eine Methode, deren Ergebnisse letztendlich als Abbildungen vorliegen, durch grafisch ausgedrückte Beispiele leichter zu vermitteln ist.

Viele System- und Prozessbeispiele

Am Ende der meisten Kapitel erfolgt eine Zusammenfassung (… und Unternehmensmodellierung), die für alle Lesergruppen gedacht ist. Sie wird aber, wieder aus zeitlichen Gründen, in Bachelorveranstaltungen nicht in voller Intensität behandelbar sein.

1.2.1 Viele Begriffe

Die Zahl der Begriffe, die die UML-Autoren bei den Konstrukten zur Verhaltensmodellierung benötigen, ist sehr groß. Um die Übersichtlichkeit zu erhöhen und um die Beziehung zum Originaltext herzustellen, wird daher bei den meisten Kapiteln am Schluss die oben angeführte Auflistung der verwendeten Begriffe angegeben, in ihrer Originalsprache und in der gewählten Übersetzung. Bei übersetzten Begriffen wird auch im Text bei der Erstnutzung der Originalbegriff angegeben, um die Verbindung zum Originaltext herzustellen. Letztendlich wird es unumgänglich sein, für einzelne Fragen den Originaltext zu konsultieren, da sollten diese Angaben eine Hilfe sein.

1.2.2 Abkürzungen für Methoden

Wenn es darum geht, einzelne Teile der objektorientierten Theorie anzusprechen, werden in diesem Buch folgende Kurzbezeichnungen verwendet:

AD, SD, AF, ZA

• Methode AD: alle Theorieelemente zur Erfassung und Darstellung von Aktivitäten
• Methode SD: alle Theorieelemente zur Erfassung und Darstellung von Sequenzdiagrammen.
• Methode AF: alle Theorieelemente zur Erfassung und Darstellung von Anwendungsfällen.
• Methode ZA: alle Theorieelemente zur Erfassung und Darstellung von Zustandsautomaten

Weil in einigen Fällen objektorientierte Methoden zur Geschäftsprozessmodellierung mit der Theorie rund um Ereignisgesteuerte Prozessketten verglichen werden, wird auch noch diese Kurzbezeichnung verwendet:

• Methode EPK: alle Theorieelemente zur Erfassung und Darstellung von Ereignisgesteuerten Prozessketten.

1.3 Abkürzungsverzeichnis

AD         Aktivitätsdiagramm

AF          Anwendungsfall

BPMN   Business Process Modeling Notation

BPR       Business Process Reengineering

EPK       Ereignisgesteuerte Prozesskette

ERP       Enterprise Ressource Planning

IKS        Informations- und Kommunikationssysteme

IT           Informationstechnologie/n

KI           Künstliche Intelligenz

OCL       Object Constraint Language

OID        Objektidentifizierer

ooERP   objektorientierte ERP-Software

SD          Sequenzdiagramm

SPM       Standardprozessmodellierung

UML      Unified Modeling Language

vs.          versus (gegen, kontra)

Web       World Wide Web

ZA         Zustandsautomat

1.4 Objektorientierung als solche

Entwicklungsstand

Die objektorientierte Theorie ist mittlerweile im Bereich der Programmiersprachen fest etabliert. Dies betrifft nicht nur C++, sondern die meisten neuen Sprachen, v.a. auch die für Webanwendungen. Entweder sind sie gleich objektorientiert (wie z.B. Java) oder ihre eigentlich prozedurale Grundstruktur wird um objektorientierte Komponenten erweitert.

Programmierung

Damit und auch unabhängig davon (als Modellierungsinstrument) ist sie in Systemanalyse und -design ebenfalls umfassend eingeführt, wobei zu beobachten ist, dass das Systemdesign noch umfassender objektorientiert erfolgt als die Systemanalyse. Die Ursache liegt sicherlich darin, dass sich die heutigen grafischen Bedienoberflächen sehr leicht und umfassend objektorientiert denken lassen. Auf der anderen Seite ist die Umsetzung der Funktionalität eines Anwendungsbereichs in objektorientierte Modelle oftmals nicht so einfach möglich oder macht zumindest mehr Schwierigkeiten. Zumal es auch Funktionalität gibt, die sich dem objektorientierten Ansatz ganz entzieht.

Systemanalyse
und -design

Noch nicht ganz so weit ist die Entwicklung bei Datenbanksystemen. Hier ist zwar in der Theorie alles vorbereitet und es existieren auch kommerziell verfügbare Datenbanksysteme mit einem „Stück Objektorientierung“, der große Durchbruch in der Praxis lässt allerdings auf sich warten. Und dies schon recht lange.

Datenbanksysteme

Noch ganz am Anfang steht die objektorientierte Theorie bei der Prozessmodellierung. Hier ist noch nicht mal die Frage beantwortet, ob ihr Einsatz überhaupt sinnvoll ist. Dies sieht man auch daran, dass die von den UML-Autoren direkt vorgeschlagene Methode zur Modellierung von Tätigkeitsfolgen – Aktivitätsdiagramme – gar nicht objektorientiert ist, sondern recht unabhängig neben der objektorientierten Theorie her existiert.

Geschäftsprozesse

Deshalb findet Prozessmodellierung in der Praxis heute fast ausschließlich klassisch (nicht objektorientiert) statt.

Objektorientierung

Was ist das nun, Objektorientierung? Es bedeutet eine bestimmte Art und Weise, mit der in der Informatik und Wirtschaftsinformatik Realweltphänomene wahrgenommen werden. In der Systemanalyse und Programmierung die der zu programmierenden Anwendung. Im Bereich der Datenbanken der so genannte Weltausschnitt, der zur Modellierung ansteht. Bei der Geschäftsprozessmodellierung der jeweilige Anwendungsbereich, der im Extremfall – bei der Unternehmensmodellierung – das ganze Unternehmen umfasst.

Wahrnehmungs-fragen

Wie oben wird hier und im weiteren der Begriff Anwendungsbereich für die zu modellierende Realwelt verwendet.

Objektorientierte Modellierung

Die objektorientierte Theorie ist also ein Modellierungsansatz, ein Werkzeug zur adäquaten Beschreibung eines Anwendungsbereichs. Für die Anwendungsentwicklung als Systemanalyse und Systemdesign, für Datenbanken als Datenmodell. Diese Modelle dienen dann der konkreten Programmierung bzw. der Einrichtung der Datenbank. Das Ergebnis der Modellierungsbemühungen wird Objektorientiertes Modell genannt.

Objektorientierte Modelle

Zusätzlich zu obigem behaupten wichtige Vertreter der objektorientierten Theorie (vor allem die Autoren der UML, worauf hier immer wieder eingegangen wird) seit einigen Jahren, dass die objektorientierte Theorie auch geeignet sei, Geschäftsprozesse zu modellieren. Dass also das Instrumentarium zur Beschreibung von Abläufen, vom Zusammenspiel in Systemen, auch geeignet sei für die Prozessmodellierung. Es wird in dieser Arbeit zu prüfen sein, ob dies tatsächlich so ist.

Auch für Geschäfts­prozesse?

Wäre dies möglich, dann wäre der objektorientierte Ansatz in seiner gegenwärtigen Ausprägung geeignet, Unternehmen in ihrer ganzen Komplexität zu modellieren, also nicht nur bezüglich der Datenstrukturen, sondern auch bezüglich der Geschäftsprozesse und anderer Eigenschaften. Dann könnte der Schritt zu einem umfassenden objektorientierten integrierten Unternehmensmodell getan werden.

Umfassendes objektorientiertes integriertes Unternehmens-modell?

Diese Hinwendung der Autoren (in der objektorientierten Fachliteratur) zu den Geschäftsprozessen erfolgt nicht zufällig, sondern kommt von dem Bedeutungsgewinn, den die Prozessanalyse in den letzten 15 Jahren gewonnen hat. Trotzdem werden Fragen der Prozessmodellierung in den einschlägigen Veröffentlichungen nur stiefmütterlich behandelt. Dies soll in diesem Buch nicht geschehen.

Meist wurden und werden von diesen Autoren Prozesse mit Systemen gleichgesetzt, was zum gegenwärtigen Stand der Entwicklung der Informationstechnologien (IT) zumindest fragwürdig ist und was hier ja auch hinterfragt werden soll. Zumindest bei einigen Autoren hat sich dies inzwischen auch geändert. Es wurde erkannt, dass es „über“ der Systemebene noch die Geschäftsprozesse gibt und dass diese eine besondere Behandlung verdienen. Ein Grund dafür ist, dass Geschäftsprozesse auch Abläufe betreffen die nicht automatisiert sind, die also nicht durch Software unterstützt werden.

Geschäftsprozesse = Systemverhalten?

Automatisierung

Und doch gibt es in der Praxis heutiger Informations- und Kommunikationssysteme (IKS) in Unternehmen einen Trend, der diese Betrachtungen in einem völlig neuen Licht erscheinen lässt: Den zu fast vollständig automatisierten (d.h. durch Software abgewickelten) Geschäftsprozessen. Die Webunternehmen führen uns diesen Trend gerade eindrücklich vor. Nicht nur der Kontakt zum Kunden, sondern seine Rückmeldungen, das Mahnwesen, Finanzwesen, die Leistungserbringung usw. werden automatisiert abgewickelt.

Sind Geschäftsprozesse Automaten?

Dazu unten in den Kapitelzusammenfassungen und in der Gesamteinschätzung (Kapitel 14) mehr.

1.4.1 Die UML

Was ist die UML

Objektorientierung gab es vor der UML und wird es auch danach geben, wie das so ist im Wissenschaftsleben. Die Unified Modeling Language stellt aber derzeit einen Standard dar. Die Leistung der UML-Autoren bestand u.a. darin, eine Vereinheitlichung der vielen verschiedenen objektorientierten Theorieansätze durchzuführen.

Es war aber nicht nur die Vereinheitlichung, sondern auch die Präzisierung und Vertiefung, die den Wert der UML ausmacht. Hier vor allem durch eine ausgefeilte Metamodellierung. Vgl. hierzu WebZumBuch_UM03.

Hauptwirkungsbereich der objektorientierten Theorie war und bleibt die Systemanalyse mit ihrer Zweiteilung zwischen Struktur und Verhalten (im Anwendungsbereich). Diese Zweiteilung wurde in der objektorientierten Theorie von Anfang an übernommen [Anmerkung] , vor der UML und dann auch durch die UML-Autoren. Das ist nun mal ein wesentliches Strukturmerkmal von Systemen, aber auch von anderen Anwendungsbereichen, z.B. Geschäftsprozessen (wo sich dies in Abläufen und genutzten Daten artikuliert).

Statik vs. Dynamik –
Struktur vs. Verhalten

Eine Theorie im Bereich der Unternehmensmodellierung wird erstmal textlich formuliert und legt so ihre Begriffe, Konzepte und Konstrukte fest. Typisch für eine Theorie, die Modelle zum Ziel hat, ist die zusätzliche Nutzung von Abbildungen, mit denen Modelle, Modellelemente oder Modellaspekte ausgedrückt werden. Deshalb und auch weil der Verfasser Beispiele für sehr sinnvoll hält die zahlreichen Abbildungen in diesem Buch – für Struktur- und für Verhaltensaspekte, aus dem System- und dem Prozessumfeld. Die folgende Grafik zeigt die Theorieelemente der UML und die verwendeten Abbildungen für die beiden Bereiche, dort werden sie „structure and behavior diagrams“ genannt. Die meisten davon werden in diesem Buch vorgestellt.

Viele Beispiele in Abbildungen

1.4.2 Verwendete Datentypen

In den in den folgenden Kapiteln gezeigten Beispielen werden auch Datentypen angegeben. Folgende werden in den Texten der UML und in [Rumbaugh, Jacobson und Booch 2005] verwendet und sollen deshalb auch hier zum Einsatz kommen:

UML-Datentypen

• Category
• Money
• String
• Date
• Integer
• Boolean
• TimeofDay

Einige Beispiele werden auch in C++ angegeben. Da finden folgende Datentypen Verwendung:

C++

• Char
• Float
• Double
• Int

Wo nötig und sinnvoll sind noch selbsterklärende weitere Datentypen eingefügt.

1.4.3 Formatierung und Schreibweise

Im Text und in den Grafiken wird jeweils ein bestimmtes Schriftformat für Anwendungsbereiche, Objektorientierte Modelle, Objekte, Klassen, Attribute und Methoden verwendet. Außerdem schreibt die UML bei einigen dieser Bezeichner einen bestimmten Aufbau des Wortes bzgl. Kleinschreibung, Großschreibung und Unterstreichung vor. Dieser wird hier schon mal vorgestellt, bei der Einführung des jeweiligen Theorieelements dann erläutert.

Schriftformate für
Anwendungs-
bereiche,
Objektorientierte Modelle,
Objekte,
Klassen,
Attribute
Methoden

Hier die für diesen Text gewählte Formatierung, in Klammern die im Skript gewählte:

• Anwendungsbereiche: Unternehmen (Arial, fett, 11)
• Objektorientierte Modelle: Personalwesen (Arial, fett, Großbuchstaben, 9).
• Klassen: Angestellte (Arial, fett, 9)
• Objekte: Maier:Angestellte (Arial, 8)
• Attribute: datumEinstellung (Arial, 9)
• Methoden/Operationen: einstellen() (Arial, 9)