Forschung und Lehre im Fachgebiet "Wirtschaftsinformatik" beschäftigt sich im Wesentlichen mit dem Einsatz von Informations- und Kommunikationstechnologien im betrieblichen Umfeld. Ein Teilaspekt hiervon sind Fragestellungen bezüglich der Modellierung und Realisierung effizienter Geschäftsprozesse und Workflows. Eine solche Modellierung setzt die Analyse der tatsächlichen betrieblichen Gegebenheiten (z.B. derzeitige Praxis) und ihr Zusammenspiel u.a. mit IuK-Technologien voraus, welche dann in der eigentlichen Modellierung optimiert ausgestaltet werden sollen. Die darauf folgende Realisierung kann u.a. darin bestehen, die Ausführung der Soll-Modelle durch betriebliche Anwendungssoftware zu ermöglichen.
Am Lehrstuhl Wirtschaftsinformatik der FernUniversität in Hagen ist im Rahmen des Kurses "Betriebliche Anwendungssysteme" zu Lehrzwecken ein Ansatz zur Modellierung von Geschäftsprozessen entstanden (vgl. Gehring 1999). Dieser Ansatz umfasst u.a. eine auf anschaulichen Diagrammen basierende Sprache zur Beschreibung von Geschäftsprozessen.
Aufgabenstellung dieser Diplomarbeit ist es, zu analysieren, wie ein Software-Werkzeug zur möglichst weitgehenden Unterstützung dieses Ansatzes der Geschäftsprozessmodellierung gestaltet sein sollte, welches durch Studierende im Rahmen der Bearbeitung des Kurses "Betriebliche Anwendungssysteme" zu Übungszwecken eingesetzt werden kann. Diese Analyse soll in dem Entwurf und der prototypischen Implementierung der Software auf Basis der Eclipse Rich Client Plattform selbst münden.
Inhaltsverzeichnis
1 Einleitung
2 Grundlagen
2.1 Geschäftsprozesse und Workflows
2.2 Geschäftsprozessmodellierung
2.3 Ergonomie von Software-Applikationen
3 Betrachtungsgegenstand
3.1 Geschäftsprozessmodellierung nach Gehring
3.1.1 Erstellung von Geschäftsprozessmodellen
3.1.2 Modellierung definierter Sichten auf Geschäftsprozessmodelle
3.1.3 Geschäftsprozess-Repository
3.2 Der Eclipse Business Process Designer
3.2.1 Funktionsumfang
3.2.2 Ergonomie
3.2.3 Design und technische Realisierung
4 Anforderungsdefinition
4.1 Funktionale Anforderungen
4.1.1 Funktionalität zur Erstellung von Geschäftsprozessmodellen
4.1.2 Funktionalität zur Modellierung der definierten Sichten auf die Geschäftsprozessmodelle
4.1.3 Funktionalität zur Verwaltung eines Geschäftsprozess-Repositories
4.1.4 Funktionalität zur konsistenten Verbindung der verschiedenen Funktionalitäten
4.2 Nicht-funktionale Anforderungen
5 Entwurf
5.1 Entwurf der Benutzungsoberfläche
5.1.1 Programm-Oberfläche
5.1.2 Übersicht und Bearbeitung von Projekten und Repositories
5.1.3 Oberfläche für die Anzeige und Bearbeitung von Diagrammen von Geschäftsprozessmodellen und Sichten
5.1.4 Anzeige und Bearbeitung der Repository-Einträge
5.2 Entwurf der Datenrepräsentation
5.3 Entwurf der Anwendungslogik
6 Implementierung
7 Evaluierung
8 Fazit und Ausblick
A Systemvoraussetzungen und Installation
Literaturverzeichnis
Abbildungsverzeichnis
1 Meta-Geschäftsprozess-Modell nach GEHRING (1999)
2 Meta-Modell der Organisationssicht nach GEHRING (1999)
3 Meta-Modell der Funktionssicht nach GEHRING (1999)
4 Meta-Modell der Datensicht nach GEHRING (1999)
5 Erweitertes Begriffssystem nach GEHRING (1999)
6 Repository-Eintrag der Sektion für Prozessobjekte nach GEHRING (1999)
7 Repository-Eintrag der Sektion für Organisationsobjekte nach GEHRING (1999)
8 Repository-Eintrag der Sektion für Datenobjekte (Dokumente) nach GEHRING (1999)
9 Repository-Eintrag der Sektion für Datenobjekte (Datenspeicher) nach GEH- RING (1999)
10 Skizze der Programm-Oberfläche
11 Skizze des GUI-Bereichs für die Übersicht und Bearbeitung von Projekten und Repositories
12 Skizze des GUI-Bereichs für die Anzeige und Bearbeitung von Diagrammen von Geschäftsprozessmodellen und Sichten
13 Skizze des GUI-Bereichs für die Anzeige und Bearbeitung der Repository- Einträge
14 Die Umsetzung des Datenmodells als UML-Klassendiagramm
15 Hauptfenster des FernUni Geschäftsprozessmodellierers
16 Optionen des Menübalkens und des Kontextmenüs von Prozessobjekten
17 Löschen einer Repository-Entität
18 Diagramm eines Geschäftsprozessmodells
19 Repository-Eintrag zur ausgewählten Entität
20 Diagramm der Datensicht eines Repositories
21 Diagramm der Organisationssicht bezogen auf eine Repository-Entität
22 Exportiertes Bitmap des modellierten Geschäftsprozesses P 2.2.3 aus GEH- RING (1999)
1 Einleitung
Forschung und Lehre im Fachgebiet „Wirtschaftsinformatik“ beschäftigt sich im Wesentlichen mit dem Einsatz von Informationsund Kommunikationstechnologien (IuK-Technologien) im betrieblichen Umfeld. Ein Teilaspekt hiervon sind Fragestellungen bezüglich der Modellierung und Realisierung effizienter Geschäftsprozesse und Workflows. Eine solche Modellierung setzt die Analyse der tatsächlichen betrieblichen Gegebenheiten (z.B. derzeitige Praxis) und ihr Zusammenspiel u.a. mit IuK-Technologien voraus, welche dann in der eigentlichen Modellierung optimiert ausgestaltet werden sollen. Die darauf folgende Realisierung kann u.a. darin bestehen, die Ausführung der Soll-Modelle durch betriebliche Anwendungssoftware zu ermöglichen.
Geschäftsprozessmodellierung kann mit unterschiedlich formalen Sprachen durchgeführt werden (von umgangssprachlicher Beschreibung bis hin zu z.B. logischer Programmierung). Im Prozess der Modellierung zeigen sich aber besondere Anforderungen an eine Modellierungssprache für Geschäftsprozesse: Sie muss auf der einen Seite für Nicht-Experten im Bereich der Wirtschaftsinformatik verständlich genug sein, damit diese am Modellierungsprozess aktiv teilhaben können, auf der anderen Seite aber auch einen notwendigen Grad an Formalisierung aufweisen, damit die erzeugten Modelle eindeutig sind und deren Semantik in der Gestaltung der betrieblichen Software umgesetzt werden kann. Ein gerade im deutschsprachigen Umfeld sehr populärer Ansatz zur Geschäftsprozessmodellierung ist z.B. ARIS (vgl. SCHEER 1998), welcher eine ganzheitliche Betrachtung der Thematik vornimmt und mit den sog. Ereignisgesteuerten Prozessketten (EPKs) eine auf anschaulichen Diagrammen basierende Sprache bereitstellt.
Am Lehrstuhl Wirtschaftsinformatik der FernUniversität in Hagen ist im Rahmen des Kurses
„Betriebliche Anwendungssysteme“ zu Lehrzwecken ebenfalls ein Ansatz zur Modellierung von Geschäftsprozessen entstanden (vgl. GEHRING 1999, 1999b). Wie z.B. auch ARIS umfasst auch dieser Ansatz u.a. eine auf anschaulichen Diagrammen basierende Sprache zur Beschreibung von Geschäftsprozessen.
Wirtschaftsinformatik befasst sich in dem Bereich nicht nur mit der Modellierung und Umsetzung von Geschäftsprozessen selbst sondern als Randgebiet auch mit der Frage der Softwareunterstützung bei der Analyse und Modellierung von Geschäftsprozessen. Software zur solchen Unterstützung kann von einfachen Malund Zeichenprogrammen, die die Syntax der Diagrammsprachen unterstützen, bis hin zu hochintegrierten Systemen reichen, die über die Syntax hinaus auch noch eine semantisch korrekte Modellierung garantieren.
Im Rahmen einer Diplomarbeit ist untersucht worden, wie ein solches Software-Werkzeug für den Ansatz zur Geschäftsprozessmodellierung nach GEHRING (1999) auf Basis des Eclipse- Frameworks gestaltet sein sollte, welches den Studierenden zu Lehrbzw. Lernzwecken vom Lehrstuhl Wirtschaftsinformatik bereitgestellt werden kann (vgl. KLEIN 2005). Ebenfalls ist in der Diplomarbeit eine prototypische Umsetzung in Form des sog. Eclipse Business Process Designers (EBPD) erfolgt. Im Rahmen der Diplomarbeit konnte jedoch der Ansatz nach GEHRING (1999) nicht vollständig betrachtet und auf die Software abgebildet werden. Darüber hinaus ist die Erstellung der Software nicht nach ergonomischen Gesichtspunkten erfolgt.
Aufgabenstellung dieser Diplomarbeit ist es daher, zu analysieren, wie ein Software-Werkzeug zur möglichst weitgehenden Unterstützung des Ansatzes der Geschäftsprozessmodellierung nach GEHRING (1999) gestaltet sein sollte, welches durch Studierende im Rahmen der Bearbeitung des Kurses „Betriebliche Anwendungssysteme“ zu Übungszwecken eingesetzt werden kann. Diese Analyse soll in dem Entwurf und der prototypischen Implementierung der Software selbst münden, welche jeweils auf den Vorarbeiten von KLEIN (2005) aufbauen sollen. Der Fokus dieser Arbeit soll allerdings in erster Linie auf die Umsetzung der Möglichkeiten der Modellierung von Geschäftsprozessen nach der Methode selbst und nicht auf die Erarbeitung und Umsetzung spezieller E-Learning-Konzepte für das Erlernen der Methode gerichtet sein.
Die Arbeit ist dabei folgendermaßen aufgebaut: Zunächst werden in Kapitel 2 die begrifflichen Grundlagen bzgl. Geschäftsprozess und Geschäftsprozessmodellierung sowie ergonomisch gestalteter Softwaresysteme gelegt. Die eigentlichen Betrachtungsgegenstände werden in Kapitel 3 analysiert: Zunächst wird in Abschnitt 3.1 der Ansatz zur Geschäftsprozessmodellierung nach GEHRING (1999) erarbeitet und darauf hin in Abschnitt 3.2 die Ergebnisse von KLEIN (2005) u.a. auf ihre Weiterverwendung im Rahmen dieser Arbeit analysiert. In Kapitel 4 wird auf Basis der Ergebnisse dieser Analysen die Anforderungsdefinition an die in dieser Arbeit zu erstellenden Software aufgeteilt in funktionale (Abschnitt 4.1) und nicht-funktionale Anforderungen (Abschnitt 4.2) entwickelt. Aus der Anforderungsdefinition wird in Kapitel 5 der Software- Entwurf herausgearbeitet, auf dessen Grundlage die Implementierung, welche im Anschluss in Kapitel 6 beschrieben wird, erfolgt. Der Software-Entwurf ist dabei aufgeteilt in die Sichten auf die graphische Benutzungsoberfläche (Abschnitt 5.1), die Datenrepräsentation (Abschnitt 5.2) sowie die Anwendungslogik (Abschnitt 5.3). Der Beschreibung der Implementierung in Kapitel 6 folgt in Kapitel 7 die Evaluierung anhand der exemplarischen Modellierung des kursbegleitenden Beispiels aus GEHRING (1999). Die Arbeit wird durch ein Fazit und einen Ausblick in Kapitel 8 sowie einen Anhang zu den Systemvoraussetzungen und der Installation abgeschlossen.
2 Grundlagen
In diesem Abschnitt werden die für diese Arbeit notwendigen begrifflichen Grundlagen und Konzepte zu Geschäftsprozessen und Geschäftsprozessmodellierung aufbereitet. Zunächst wird der in der einschlägigen Literatur unterschiedlich definierte Begriff Geschäftsprozess (bzw. häufig synonym verwandt Workflow) eingeführt und von den Definitionen von Geschäftsprozess und Workflow von GEHRING (1999b), auf deren Grundlage mit der in dieser Arbeit zu entwickelnden Software Geschäftsprozesse modelliert werden können sollen, abgegrenzt. Darauf folgt eine Übersicht über Systeme zur Geschäftsprozessmodellierung schließlich mündend in der Übersicht ergonomischer Richtlinien zur Gestaltung von Software-Applikationen (speziell solchen mit Dialogsystemen).
2.1 Geschäftsprozesse und Workflows
Für die Analyse des Betrachtungsgegenstandes – die Methode der Geschäftsprozessmodellierung nach GEHRING (1999) – in Hinblick auf die Entwicklung einer Software zur Unterstützung dieser ist es notwendig, zunächst den Begriff Geschäftsprozess zu definieren. Dieser Begriff wird häufig synonym zu dem Begriff des Workflows genutzt (vgl. DIN 1996), von GEHRING (1999b) aber differenziert definiert, weshalb an dieser Stelle ebenfalls eine genaue Abgrenzung der Begriffe untereinander erfolgt; schließlich beeinflusst die begriffliche Einordnung die Art der Software, welche zur Modellierung notwendig ist.
GEHRING (1999b) leitet sein Verständnis von dem Begriff Geschäftsprozess aus verschiedenen Literaturmeinungen ab, welche ausschnittsweise im Folgenden kurz zusammengefasst werden. So wird ein Unternehmensprozeß von HAMMER/CHAMPY (1993) als eine Menge von Aktivitäten bezeichnet, für welche unterschiedliche Eingaben benötigt werden und welche für Kunden ein Resultat mit Wert erzeugen. Dieser Prozess sollte durch einen Prozessverantwortlichen des Managements gesteuert werden. ÖSTERLE (1995) definiert einen Geschäftsprozess als eine Abfolge von Aufgaben, welche über eine Menge organisatorischer Einheiten verteilt sein können. Dieser ist dabei gleichzeitig Produzent und Konsument von Leistungen. Eine Ausführung mit Unterstützung informationstechnologischer Anwendungen ist angedacht. Geschäftsprozesse werden durch SCHEER/JOST (1996) als eine modellhafte Umschreibung der Funktionen, die in einem Unternehmen durchzuführen sind, definiert. Diese werden sowohl inhaltlich als auch zeitlich umschrieben. Funktionen stehen für Aufgaben bzw. Tätigkeiten, werden durch Ereignisse ausgelöst und erzeugen selbst wiederum Ereignisse.
GEHRING (1999b) führt diese Literaturmeinungen zu seiner folgenden Definition von Geschäftsprozess zusammen:
„Ein Geschäftsprozeß ist eine zielgerichtete, zeitlich-logische Abfolge von Aufgaben, die arbeitsteilig von mehreren Organisationen oder Organisationseinheiten unter Nutzung von Informationsund Kommunikationstechnologien ausgeführt werden können. Er dient der Erstellung von Leistungen entsprechend den vorgegebenen, aus der Unternehmensstrategie abgeleiteten Prozeßzielen. Ein Geschäftsprozeß kann formal auf unterschiedlichen Detaillierungsebenen und aus mehreren Sichten beschrieben werden. Ein maximaler Detaillierungsgrad der Beschreibung ist dann erreicht, wenn die ausgewiesenen Aufgaben je in einem Zug von einem Mitarbeiter ohne Wechsel des Arbeitsplatzes ausgeführt werden können.“
Ebenso wie für Geschäftsprozess leitet GEHRING (1999b) sein Verständnis von dem Begriff Workflow auch aus verschiedenen Literaturmeinungen ab. Diese sollen ebenfalls ausschnittsweise an dieser Stelle kurz zusammengefasst werden. So werden Workflows von GALLER und SCHEER (1995) als eine technische Verfeinerung von Geschäftsprozessen gesehen. Ein Workflow zeichnet sich bezüglich des Grades der Verfeinerung dadurch aus, dass er automatisierbar ist; d.h. dass er als Eingabe und Regelwerk für die Steuerung durch ein sog. Workflow-Managementsystem verwendbar sein muss. Auch ÖSTERLE (1995) sieht einen Workflow als einen verfeinerten Geschäftsprozess; jedoch mit weniger starkem technologischen Fokus. Ein Workflow ist demnach ein derart sukzessiv zerlegter Geschäftsprozess, dass seine Aufgaben von Prozessmitarbeitern als Arbeitsanweisung umgesetzt werden können.
Diese Literaturmeinungen führt GEHRING (1999b) zu seiner folgenden Definition von Workflow zusammen:
„Ein Workflow ist ein formal beschriebener, ganz oder teilweise automatisierter Geschäftsprozeß. Er beinhaltet die zeitlichen, fachlichen und ressourcenbezogenen Spezifikationen, die für eine automatische Steuerung des Arbeitsablaufes auf der operativen Ebene erforderlich sind. Die hierbei anzustoßenden Arbeitsschritte sind zur Ausführung durch Mitarbeiter oder durch Anwendungsprogramme vorgesehen. Von dem Workflow als Typ oder Schema eines (teil-)automatisierten Arbeitsablaufes zu unterscheiden ist eine Workflow-Instanz, die eine konkrete Ausführung des Workflows bezeichnet.“
GEHRING (1999b) grenzt Geschäftsprozesse und Workflows bezüglich der Zielsetzung, der Gestaltungsebene und des Detaillierungsgrades voneinander ab. Die Zielsetzung bei der Modellie- rung von Geschäftsprozessen ist die „Analyse und Gestaltung von Arbeitsabläufen im Sinne gegebener (strategischer) Ziele“. Für Workflows ist sie dagegen die „Spezifikation der technischen Ausführung von Arbeitsabläufen“. Entsprechend unterscheiden sich die Gestaltungsebenen in die konzeptionelle Ebene mit Verbindung zur Geschäftsstrategie (Geschäftsprozess) und die operative Ebene mit Verbindung zu unterstützender Technologie (Workflow). Der Detaillierungsgrad wird dahingehend abgegrenzt, dass Geschäftsprozesse „in einem Zug von einem Mitarbeiter an einem Arbeitsplatz ausführbare Prozeßschritte“ darstellen, während in Workflows Arbeitsschritte „hinsichtlich Arbeitsverfahren sowie personeller und technologischer Ressourcen“ konkretisiert werden.
In der Literatur gibt es noch eine Menge weiterer Definitionen von Geschäftsprozess und Workflow, welche im Wesentlichen mit den Definitionen von GEHRING (1999b) übereinstimmen wie z.B. JABLONSKI/BÖHM/SCHULZE (1997), RUMP (1999) oder SCHIMM (2004). Kleinere Unterschiede bestehen z.B. darin, dass JABLONSKI/BÖHM/SCHULZE (1997) speziell Workflow- Managementsysteme zur Ausführung von Workflows definieren sowie in der grundsätzlichen sprachlichen Formulierung. Von GEHRING (1999b) eher abweichend sind die Definitionen von z.B. OBERWEIS (1996), welche eine gemeinsame taxonomische Einordnung von Geschäftsprozessen und Workflows unter dem Oberbegriff des betrieblichen Ablaufs vornehmen.
2.2 Geschäftsprozessmodellierung
Dieser Abschnitt führt den Begriff der Geschäftsprozessmodellierung ein und stellt populäre Ansätze zur Geschäftsprozessmodellierung aus der Literatur exemplarisch dar. Hiermit werden die Grundlagen zur Software-unterstützten Geschäftsprozessmodellierung gelegt. Die für diese Arbeit relevante Methode der Geschäftsprozessmodellierung nach GEHRING (1999) wird im Abschnitt 3.1 im Detail betrachtet.
Geschäftsprozessmodellierung umfasst laut GEHRING (1999b) die Modellierung nach Ebenen, Phasen, Sichten und Methoden. Die Meta-Modellierung ist Teil der Modellierungsmethoden und gibt die Möglichkeiten der eigentlichen Modellierung vor (vgl. SINZ 1996). Alle Entitäten des Modells sind Instanzen von Entitäten des Meta-Modells. Das Meta-Modell stellt somit die Modellierungssprache dar. Die Meta-Modellierung ist daher kein Bestandteil der Geschäftsprozessmodellierung im engeren Sinne, da sie nach Möglichkeit nur einmalig durchgeführt werden muss. Ein Software-Werkzeug zur Unterstützung von Geschäftsprozessmodellierung muss daher auch keine explizite Unterstützung der Meta-Modellierung bieten; vielmehr eine Unterstützung der Modellierung auf Grundlage von bestimmten Meta-Modellen.
GEHRING (1999b) identifiziert drei Ebenen der Prozessmodellierung: Auf der strategischen Ebene erfolgt die Strategieentwicklung durch das strategische Management mit dem Ergebnis einer Geschäftsfeldstrategie. Auf der fachlich-konzeptionellen Ebene erfolgt durch das Geschäftsprozessmanagement die eigentliche Geschäftsprozessmodellierung mit dem Ergebnis von Geschäftsprozessmodellen. Schließlich erfolgt auf der operativen Ebene durch das Workflow-Management die Workflow-Modellierung, welche Workflow-Modelle erzeugt. In dieser Arbeit ist für die weitere Betrachtung daher ausschließlich die fachlich-konzeptionelle Ebene der Geschäftsprozessmodellierung relevant.
Die Phasen der Geschäftsprozessmodellierung definieren ein ingenieurmäßiges Vorgehen bei der Erstellung von Geschäftsprozessen (vergleichbar mit Software-Engineering, z.B. gemäß SOMMERVILLE 2007). Dabei bevorzugt GEHRING (1999b) ein Vorgehen vergleichbar mit dem Phasenmodell von RAUSCHECKER (2000): Die langfristige Strategie sowie weitere visionäre Vorstellungen werden zu einem Ideal-Geschäftsprozess abgestimmt. Dieser Prozess wird unter Betrachtung des Ist-Prozesses schließlich zu einem Soll-Prozess überführt.
GEHRING (1999b) identifiziert verschiedene Sichten auf Geschäftsprozesse wie Prozessmodell, Funktionssicht, Organisationssicht und Datensicht, welche im Detail noch in Abschnitt
3.1 beschrieben werden. Andere Ansätze aus der Literatur verwenden andere Einteilungen und Begrifflichkeiten (z.B. SCHEER 1998 oder ÖSTERLE 1995), beschreiben aber meist ebenfalls Sichten auf die dynamischen, organisatorischen, funktionalen und statischen Aspekte.
Wichtigster Bestandteil der Modellierungs methoden ist sicherlich das Meta-Modell. Dieses definiert die Sprache, in der Geschäftsprozesse modelliert werden können. Das Meta-Modell für die Geschäftsprozessmodellierung nach GEHRING (1999) ist im Abschnitt 3.1 im Detail beschrieben und stellt eine Diagrammsprache unter Verwendung strukturierter und objektorientierter Konzepte dar. Ein weiteres sehr populäres Beispiel für eine Diagrammsprache zur Modellierung von Geschäftsprozessen stellen die sog. Ereignisgesteuerten Prozessketten des ARIS-Modells aus SCHEER (1998) oder die Business Process Modeling Notation der Business Process Management Initiative1 (BPMI) dar. Ebenfalls zur Modellierung von Prozessen ist eine Diagrammsprache im UML-Standard verankert (vgl. OMG 2003). Andere Modellierungssprachen basieren z.B. auf Petri-Netzen (wie z.B. GRUHN/KAMPMANN 1996 oder VAN DER AALST/BASTEN 2002).
Rechnerunterstützung bei der Entwicklung von Geschäftsprozessen hängt im Wesentlichen von der Modellierungsmethode und der Modellierungssprache ab. Für jede dieser Sprachen muss daher (zumindest in Teilen) eine eigene Entwicklung einer Software zur Rechnerunterstützung erfolgen. Für die Modellierungsmethode nach GEHRING (1999) wurde durch KLEIN (2005) mit EBPD bereits eine Software entwickelt, deren Analyse in Abschnitt 3.2 erfolgt. Insgesamt reichen Software-Lösungen von einfachen Malbzw. Zeichenprogrammen wie MSPaint (Bestandteil von Windows XP2) oder StarDraw aus StarOffice3 über spezielle Zeichenprogramme für spezielle Notationen (wie z.B. DIA4 für UML) bis hin zu integrierten Lösungen, welche über das Zeichnen eines Diagramms hinaus die Konsistenz des Modells überprüfen wie z.B. der Oracle BPEL Process Manager5.
2.3 Ergonomie von Software-Applikationen
Die in dieser Diplomarbeit zu entwickelnde Software-Applikation soll in erster Linie dazu dienen, Domänen-Experten (bzw. sich diese Domäne aneignende Studierende) darin zu unterstützen, Geschäftsprozessmodelle auf Grundlage der Methode von GEHRING (1999) zu erstellen. Eine zentrale Betrachtung muss daher der Schnittstelle zwischen Benutzer und Applikation – inklusive der sog. Benutzungsoberfläche – zukommen; eine solche gelungene Schnittstelle ist neben der eigentlichen Funktionalität der Garant für eine gelungene Software (vgl. DALDRUP 1996). Aus diesem Grund werden in diesem Abschnitt ergonomische Anforderungen bzw. Normen für dialoggestützte Software-Applikationen dargestellt, welche Grundlage für die nichtfunktionalen Anforderungen and die Software sowie den Entwurf der Benutzungsoberfläche der Software darstellen. Zwei relevante Normensammlungen für die ergonomische Gestaltung von Benutzungsschnittstellen sind die Richtlinie des Vereins Deutscher Ingenieure (VDI) Nr. 5005 („Software-Ergonomie in der Bürokommunikation“, VDI 1990) und die EN ISO 9241-Norm des Europäisches Komitees für Normung („Ergonomische Anforderungen für Bürotätigkeiten mit Bildschirmgeräten“, EN ISO 1995). Diese werden im Folgenden in Bezug auf die Gestaltung interaktiver Benutzungsoberflächen dargestellt; diese Darstellung entspricht weitestgehend der Darstellung aus HACKELBUSCH (2005).
VDI-Richtlinie 5005
Die Richtlinie des Vereins Deutscher Ingenieure (VDI) Nr. 5005 über Software-Ergonomie in der Bürokommunikation VDI (1990) beschreibt Softw are-Er gonomie anhand der drei Kriterien Kompetenzförderlichkeit, Handlungsflexibilität und Aufgabenangemessenheit (s.u.). Diese
Kriterien werden jeweils unter den Aspekten der Dialoggestaltung sowie der Einund Ausgabegestaltung untersucht.
Als Dialoggestaltung wird die Gestaltung der Bedienungsschritte bzw. -abläufe, welche über die Benutzungsoberfläche realisiert sind, bezeichnet, während die Einund Ausgabegestaltung die Präsentation der dazu notwendigen Informationen auf dem Ausgabegerät beschreibt (vgl. Balzert 2004).
Eine hohe Kompetenzförderlichkeit einer Software liegt dann vor, wenn das angelernte Wissen des Benutzers zur Bewältigung seiner Aufgaben durch die Verwendung der Software zunimmt. Insbesondere soll es ihm möglich sein, dieses Wissen bei ähnlichen mit der Software zu bewältigenden Aufgaben anwenden zu können.
Damit dies erreicht werden kann, sollten z.B. ähnliche Aufgaben mit ähnlichen Bedienfolgen erledigt werden können. Der Benutzer sollte nicht in Sackgassen geraten können, keine syntaktisch falschen Eingaben tätigen können (z.B. könnte dies durch Deaktivierung nicht verfügbarer Eingabeelemente verhindert werden) und nicht gewünschte Eingaben durch eine UNDO- Funktion rückgängig machen können (Dialoggestaltung). Ferner sollte die Benutzungsoberflä- che aufgabenübergreifend über einen einheitlichen Aufbau verfügen, sowie die gebotene Funktionalität unmittelbar erkennen lassen (z.B. durch den Einsatz einer angemessenen Anzahl von Piktogrammen). Ausgewählte Objekte sollten optisch hervorgehoben werden und falsche Eingaben als fehlerhaft gekennzeichnet werden (Einund Ausgabegestaltung).
Als Handlungsflexibilität wird die Möglichkeit des Benutzers bezeichnet, seine Aufgaben je nach Kenntnisstand auf unterschiedlichen Wegen mit der Software zu erledigen. Außerdem sollen geringfügige Änderungen der Aufgabenstellung weiterhin mit Hilfe der Software durchgeführt werden können.
Mit Blick auf die Dialoggestaltung fordert die Richtlinie u.a., dass eine Mengenbildung für auswählbare Objekte möglich sein sollte, so dass Operationen auf allen ausgewählten Objekten gleichzeitig durchführbar sind. Weiterhin sollten nicht-modale Fenster benutzt werden, so dass mit mehreren gleichzeitig geöffneten Fenstern gearbeitet werden kann. Für die Einund Ausgabegestaltung wird empfohlen, dass die Fenster individuell angeordnet werden und ggf. ausgeblendet werden können. Weiterhin sollten Eingaben sowohl mit der Maus als auch mit der Tastatur vorgenommen werden können.
Die Aufgabenangemessenheit einer Software wird danach bewertet, ob die zu erreichenden Ziele mit der Software überhaupt realisiert werden können, und – falls ja – welcher Aufwand der Bewältigung durch die Benutzung der Software gegenübersteht.
Für eine hohe Aufgabenangemessenheit sollte z.B. die notwendige Anzahl von Arbeitsschritten möglichst gering sein. Weiterhin sollte das Beenden und Neustarten der Applikation den Benutzer wieder an die letzte Position im Arbeitsfluss vor dem Beenden bringen (Dialoggestaltung). Darüber hinaus sollten angezeigte Informationen in ihrem Kontext erkennbar und gut strukturiert sein. Die Möglichkeit der Falschbedienung sollte durch sinnvolles Anordnen der Menüpunkte verringert werden (Einund Ausgabegestaltung).
EN ISO 9241-Norm
Insgesamt umfangreicher als die oben beschriebene Norm des VDI ist die EN ISO 9241-Norm über Ergonomische Anforderungen für Bürotätigkeiten mit Bildschirmgeräten, da sie zusätzlich auch Anforderungen an die Hardware (Arbeitsgeräte) und die Umgebung (Büro) stellt. Sie besteht aus insgesamt 17 Teilen, wobei für die Betrachtung in dieser Arbeit ein Überblick über Teil 10 (Grundsätze der Dialoggestaltung) ausreicht.
Bereits der Titel lässt erahnen, dass es teilweise zu Überschneidungen mit der oben vorgestellten Richtlinie des VDI kommt. Teil 10 – Grundsätze der Dialoggestaltung – aus EN ISO (1995) stellt folgende Anforderungen an ergonomische Software:
- Aufgabenangemessenheit: Der Benutzer soll in der Lage sein, „seine Arbeitsaufgabe effektiv und effizient zu erledigen“. Dies bedeutet z.B., dass dem Benutzer nur die Informationen angezeigt werden sollen, die er auch zur Bewältigung seiner Aufgabe benötigt, bei der Komplexität der Darstellung auf die Aufgabe und auf die Qualifikation des Benutzers Rücksicht genommen werden sollte, sinnvolle Automatisierung durch die Software vorgenommen werden sollte, falls vorhanden sinnvolle Standardwerte vorgegeben werden sollten, ursprüngliche Daten wiederherstellbar sein sollten, sowie dem Benutzer keine unnötigen Arbeitsschritte abverlangt werden sollten.
- Selbstbeschreibungsfähigkeit: Durch geeignete Rückmeldungen sollte jeder Dialogschritt unmittelbar verständlich sein oder aber wenigstens auf Verlangen des Benutzers erklärt werden. Das bedeutet z.B., dass nach jedem Schritt sinnvolle und einheitliche Rückmeldungen, welche an den Kenntnisstand des Benutzers angepasst sind, ausgegeben werden sollten. Weiterhin sollte die Software ihren Zustand offenbaren und bei verlangten Eingaben durch den Benutzer ihm Informationen darüber liefern.
- Steuerbarkeit: Die Software ist steuerbar im Sinne der ISO-Norm, falls der Benutzer die Richtung und das Ziel der Dialogschritte bestimmen kann. So sollte der Dialogprozess
z.B. abgebrochen werden können, und wenigstens der letzte entscheidende Schritt rückgängig gemacht werden können.
- Erwartungsk onformität: Hierzu muss ein Dialog konsistent sein, sowie den Merkmalen des Benutzers (z.B. der Qualifikation, des Aufgabengebietes) entsprechen. Unter anderem wird gefordert, dass die Dialoggestaltung insgesamt einheitlich ist, Änderungen auf einheitliche Weise herbeigeführt werden können, und der Wortschatz verwendet wird, den der Benutzer für die Aufgabenbewältigung nutzt. Weiterhin sollten ähnliche Aufgaben durch ähnliche Arbeitsschritte erledigt werden können, Rückmeldungen dort angezeigt werden, wo sie erwartet werden, sowie der Benutzer rechtzeitig über zu erwartende Latenzzeiten unterrichtet werden.
- Fehlertoleranz: Eine fehlertolerante Software sollte das angestrebte Ergebnis trotz erkennbar falscher Eingaben durch den Benutzer mit nur geringen oder optimal ohne Korrekturaufwand seitens des Benutzers erreichen. Hierzu sollten z.B. die Fehler sichtbar gemacht werden und – falls möglich – bereits Korrekturvorschläge offeriert werden. Falscheingaben, die zu schwerwiegenden Fehlern wie z.B. Abstürzen führen können, sollten gar nicht erst zugelassen werden.
- Indi vidualisierbarkeit: Eine hohe Individualisierbarkeit bedeutet, dass die Software an die Vorlieben und Fertigkeiten des Benutzers anpassbar ist. Beispiele hierfür sind die verwendete Sprache, oder die Möglichkeit entsprechend der Aufgabe zwischen unterschiedlichen Wegen zum Erreichen des Ziels zu wählen.
- Lernförderlichkeit: Der Benutzer sollte beim Erlernen der Bedienung der Software angelernt und unterstützt werden.
Schlussfolgerung
Die beiden Normensammlungen enthalten relevante Normen, die bei der Gestaltung interaktiver Software-Applikationen eingehalten werden sollten. Sie sollten daher beim Entwurf und der Implementierung berücksichtigt werden. Bestimmte Normen sind allerdings derart weitläufig (z.B: „Lernförderlichkeit“ oder „Individualisierbarkeit“), dass sie im Rahmen dieser Diplomarbeit nicht vollständig umgesetzt werden können. Priorität haben daher der Entwurf und die Umsetzung der funktionalen Anforderungen an die Applikation.
3 Betrachtungsgegenstand
Nachdem in Abschnitt 2 die begrifflichen und konzeptionellen Grundlagen zu Geschäftsprozessen betrachtet worden sind, wird in diesem Abschnitt der Ansatz der Modellierung von Geschäftsprozessen nach GEHRING (1999), welcher durch die in dieser Diplomarbeit zu entwickelnden Software unterstützt werden können soll, im Detail betrachtet. Darüber hinaus wird in diesem Abschnitt die Software „Eclipse Business Process Designer“ von KLEIN (2005) vorgestellt und analysiert, welche ebenfalls eine derartige Unterstützung ermöglichen soll und ggf. in diesem Zuge zur Erweiterung in Frage kommen könnte.
3.1 Geschäftsprozessmodellierung nach Gehring
Die von GEHRING (1999) erarbeitete Methode zur Modellierung von Geschäftsprozessen erstreckt sich auf folgende Punkte, welche im Folgenden näher betrachtet werden sollen:
- Erstellung von Geschäftsprozessmodellen
- Modellierung definierter Sichten auf Geschäftsprozessmodelle
- Geschäftsprozess-Repository
Bei den folgen Abschnitten zur detaillierten Beschreibung der Methode von GEHRING handelt es sich um eine Zusammenfassung und Analyse der für diese Arbeit wichtigen Ausführungen in GEHRING (1999).
3.1.1 Erstellung von Geschäftsprozessmodellen
GEHRING nutzt für seine Methode drei Modellierungsstufen: Meta-Meta-Modell (Stufe 1), Meta-Geschäftsprozessmodell (Stufe 2) sowie Geschäftsprozessmodell (Stufe 3). Stufe 3 stellt schließlich die Ebene dar, auf der die tatsächlichen Geschäftsprozesse erstellt bzw. modelliert werden können. Modelle dieser dritten Stufe sollen mit Hilfe der in dieser Arbeit zu erstellenden Software modelliert werden können.
Ausgangspunkt für die Modellierung ist das Meta-Meta-Modell von SINZ (1996), welches die Modellierung von Meta-Modellen ermöglicht, die in ihrer Form vergleichbar mit typischen objektorientierten Modellen (z.B. UML-Klassendiagramm, vgl. OMG 2003) sind. Demnach sind Meta-Modelle bestehend aus Meta-Objekttypen und Meta-Beziehen. Diese Beziehungen können als Generalisierungs- („ist ein“) oder als Zuordnungsbeziehungen („hat“) verwendet werden. Für Generalisierungsbeziehungen gelten Kardinalitäten implizit. Bei der Modellierung von
Zuordnungsbeziehungen müssen sie dagegen explizit angegeben werden. Für beide durch die Beziehung verbundenen Objekte wird eine Kardinalität in Bezug auf die Beziehung angegeben, welche eine untere und eine obere Schranke beinhaltet. Es sind die natürlichen Zahlen inklusive 0 sowie „*“ für „mehrere“ als Werte zugelassen. In Vorgriff auf die folgenden Ausführungen sei hier als Beispiel die Beziehung zwischen Kontrollfluss und Ereignis in Abbildung 1 herangezogen: Ein Kontrollfluss hat entweder kein oder genau ein Ereignis („0,1“), während ein Ereignis genau einem Kontrollfluss zugeordnet ist („1,1“).
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 1: Meta-Geschäftsprozess-Modell nach GEHRING (1999)
Abbildung 1 zeigt sämtliche Modellelemente bzw. Symbole aus denen sich Geschäftsprozessmodelle erzeugen lassen. Ein mit diesem Meta-Geschäftsprozessmodell erzeugtes Geschäftsprozessmodell beschreibt genau einen Geschäftsprozess. Es wird dabei ein Prozess mit Einstiegs- und Austiegspunkten, logischen Verknüpfungsoperatoren, (Unter-)Prozessobjekten und diese Entitäten verbindenden Kontrollflüssen mit Ereignissen modelliert. Die Prozessobjekte können zudem mit Organisationsund Datenobjekten auf unterschiedliche Art verbunden sein. Das in Abbildung 1 dargestellte Meta-Modell wird durch Business-Rules konkretisiert, welche ebenfalls im Folgenden dargestellt werden.
Zentrales Objekt im Geschäftsprozessmodell nach GEHRING ist das Prozessobjekt. Dieses kann über gerichtete Kontrollflüsse mit weiteren Prozessobjekten, mit Prozess- konnektoren oder mit Verknüpfungsoperatoren verbunden werden. Über Datenflüsse kann es mit Datenobjekten und über Organisationszuordnungen mit Organisationsobjekten verbunden werden. Ein Prozessobjekt kann entweder ein Geschäftsprozess oder ein Geschäftsprozessschritt sein. Wie sich später noch zeigen wird, symbolisiert ein Geschäftsprozess genau ein solches Modell; d.h. alle Prozessobjekte des Modells sind
„Bestandteile“ (d.h. in der Hierarchiebeziehung direkte Kinder, s.u.) von dem Geschäftsprozess, der durch das entsprechende Geschäftsprozessmodell repräsentiert wird. Ein Prozessobjekt ist mit bis zu zwei Kontrollflüssen verbunden. Dies sind je ein Kontrollfluss, der zum Prozessobjekt hinführt, und ein Kontrollfluss, der vom Prozessobjekt wegführt. Je nach Typ der durch einen Kontrollfluss verbunden Objekte wird eine Spezialisierung von Kontrollfluss verwendet. Jeder Kontrollfluss hat zudem bis zu ein Ereignis. Kontrollflüsse können außerdem in beliebiger Anzahl von und nach Verknüpfungsoperatoren kommen bzw. führen. Der Typ des Verknüpfungsoperators wird durch Spezialisierung festgelegt (entweder UND-Operator, ODER-Operator oder Exklusiv-Oder-Operator). Die Interpretation dieser speziellen Verknüpfungsoperatoren in Verbindung mit Kontrollflüssen ist an die logischer Gatter angelehnt (vgl. z.B. SALCIC/SMAILAGIC 2000) und für die weitere Betrachtung nicht von Relevanz. (Einzig entscheidend für die in dieser Arbeit zu entwickelnde Software ist, dass jeder Typ modellierbar ist. Mögliche die Arbeit erweiternde Features wie Prozesssimulation oder -Verifikation würden eine weitere Betrachtung ihrer Interpretation notwendig machen.) Außerdem können Kontrollflüsse mit Prozesskonnektoren verbunden werden. Von einem Vorgängerkonnektor kann bis zu ein Kontrollfluss wegführen, während zu einem Nachfolgerkonnektor bis zu ein Kontrollfluss hinführen kann. Prozesskonnektoren können entweder einem Geschäftsprozess zugeordnet werden oder einfache Prozesseinstiegs- („Anfang“) bzw. ausstiegspunkte („Ende“) darstellen. Die Zuordnung zu einem Geschäftsprozess kann dabei allerdings nicht zu einem Geschäftsprozess aus dem Modell (also Diagramm) selbst erfolgen, sondern nur zu Prozessobjekten außerhalb des Modells, die auf der selben Hierarchieebene wie der modellierte Geschäftsprozess selber liegen also „Bestandteil“ des selben Geschäftsprozesses sind. Diese Tatsache wird bei der Erläuterung der Funktionssicht auf Geschäftsprozessmodelle deutlich (s.u.). Schließlich kann ein Prozessobjekt mit beliebig vielen Organisationsobjekten über Organisationszuordnungen sowie mit beliebig vielen Datenobjekten über Datenflüsse verbunden werden. Dies gilt auch in die entgegengesetzte Richtung. Datenflüsse selbst verfügen darüber hinaus (wie auch Kontrollflüsse) über eine Richtung. Ähnlich wie Verknüpfungsoperatoren kann die Art der Organisationsobjekte und Datenobjekte über Spezialisierungen festgelegt werden. Je nach Spezialisierung werden diese durch unterschiedliche Symbole dargestellt und verfügen ggf. über unterschiedliche Repository-Einträge (s.u.).
Zudem wird das das Geschäftsprozessmodell darstellende Diagramm in drei Sichten unterteilt. In der Funktionssicht werden die Symbole zur Modellierung von Prozessen als Kontrollflüsse, Prozesskonnektoren, Verknüpfungsoperatoren, Prozessobjekte und Ereignisattribute angeordnet. Datenobjekte wie Datenspeicher und Dokument werden in der Datensicht angeordnet, und schließlich Organisationsobjekte in der Organisationssicht (vgl. Abbildung 5, unten). Aufgrund der Tatsache, dass weitere Meta-Modelle für weitere Modelle (also graphische Darstellungen) in GEHRING (1999) eingeführt werden und diese die Organisations- Funktionsund Datensicht auf mehrere Geschäftsprozessmodelle eines Repositories darstellen (s.u.), werden die bis zu diesem Punkt vorgestellten Modellierungsmöglichkeiten einer sog. Prozesssicht (bzw. einem Prozessmodell, vgl. Abschnitt 2.2) zugeordnet. Diese Prozesssicht sollte es ermöglichen, dass jede Entität als Element mehrfach angeordnet werden kann. Dies erscheint sinnvoll, da somit zur besseren Übersichtlichkeit die Objekte der Organisationsbzw. der Datensicht in Nähe zu den mit ihnen verbundenen Prozessobjekten angeordnet werden können. Für die Funktionssicht ist es sogar unabdingbar, da es z.B. ansonsten nicht möglich wäre, gleiche Geschäftsprozessschritte an mehreren Stellen im Prozess anzuordnen. Auf die graphische Darstellung in Diagrammen wird im nächsten Abschnitt noch näher eingegangen.
3.1.2 Modellierung definierter Sichten auf Geschäftsprozessmodelle
GEHRING definiert drei weitere Meta-Modelle für weitere Sichten auf Geschäftsprozessmodelle eines Repositories (s.u.), welche jeweils auf die Beziehungen zwischen Organisationsobjekten, Prozessobjekten und Datenobjekten untereinander abzielen (wie z.B. Hierarchiebeziehungen). Im Unterschied zu den Modellen aus dem Meta-Geschäftsprozessmodell können Entitäten in den Modellen der in den nächsten Abschnitten erläuterten Meta-Modelle insgesamt nur einmal instantiiert also als Element angeordnet werden, wie im Folgenden noch erläutert wird. Wiederum handelt es sich dabei um die drei Sichten mit den Namen „Organisationssicht“, „Funktionssicht“ und „Datensicht“, welche jeweils für eigene Modelle zusätzlich zur Vorhandenheit in der Prozesssicht instantiiert werden können.
Abbildung 2 zeigt das Meta-Modell der Organisationssicht. Es beschreibt die möglichen Hierarchiebeziehungen von Organisationsobjekten6. Ein Organisationsobjekt kann durch
Abbildung in dieser Leseprobe nicht enthalten
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 2: Meta-Modell der Organisationssicht nach GEHRING (1999) bis zu ein Organisationsobjekt geleitet werden und eine beliebige Anzahl Organisationsobjekte leiten. Hierzu werden Organisationsobjekte durch Hierarchiebeziehungen miteinander verbunden. Dabei ist zu beachten, dass keine Zyklen modelliert werden dürfen; also nur eine baumartige Struktur erzeugt werden kann. Ein Organisationsobjekt kann verschiedenen Geschäftsprozessmodellen in der Organisationssicht der „Prozesssicht“ (auch jeweils mehrfach) angehörig sein (s.o.). In der durch das Meta-Modell der Organisationssicht beschriebenen Organisationssicht ist dagegen jedes Organisationsobjekt genau einmal vorhanden – also auch jedes, das Teil eines Geschäftsprozessmodells ist.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 3: Meta-Modell der Funktionssicht nach GEHRING (1999)
Ebenso werden durch das Meta-Modell der Funktionssicht die Möglichkeiten der Definition von Hierarchiebeziehungen beschrieben. In der Funktionssicht sind die betrachteten Entitätstypen Prozessobjekte. Abbildung 3 zeigt das Meta-Modell der Funktionssicht: Ein Geschäftsprozess kann Teil bis zu eines weiteren Geschäftsprozesses sein. Weiterhin kann ein Geschäftsprozess aus einer beliebigen Menge von Geschäftsprozessen sowie Geschäftsprozessschritten bestehen. Ein Geschäftsprozessschritt wiederum kann Bestandteil bis zu eines Geschäftsprozesses sein, besteht seinerseits aber aus keinen weiteren
Prozessobjekten. Auch dieses Meta-Modell verbietet die Modellierung von Zyklen. Bei Analyse dieses Meta-Modells wird deutlich, dass alle Prozessobjekte, welche Bestandteil eines Geschäftsprozessmodells sind (also der Funktionssicht der „Prozesssicht“), gleichzeitig auch in der Hierarchie direkter Bestandteil des Geschäftsprozesses sein müssen, in dessen Modell sie (auch mehrfach) Teil sind. Ein Prozessobjekt ist zudem genau einmal in der durch das Meta-Modell der Funktionssicht beschriebenen Funktionssicht vorhanden. Ist es darin als Bestandteil eines Geschäftsprozesses definiert, kann es der Funktionssicht der „Prozesssicht“ des entsprechenden Geschäftsprozessmodells beliebig häufig angehören – und nur der.
Stellt man sich nun einen Geschäftsprozessschritt vor, der z.B. das Überprüfen der Liquidität eines Kunden repräsentiert, dann kann man sich leicht klar machen, dass dieser Prozessschritt Teil mehrerer Geschäftsprozesse sein könnte (z.B. „Kredit gewähren“, „Kaufvertrag abschlie- ßen“, ...). Dies lässt das Meta-Modell aber nicht zu. Die gleiche Situation existiert auch bei der Betrachtung von Geschäftsprozessen als Bestandteil von Geschäftsprozessen. Um diesen Missstand zu beheben, sind zwei Möglichkeiten des Vorgehens augenscheinig: Entweder wird das Meta-Modell angepasst, oder die Software, die das Modellieren anhand des Meta-Modells erlauben soll und in dieser Arbeit zu entwickeln ist, bietet eine elegante Möglichkeit, den Missstand zu umgehen (z.B. durch Erzeugen einer Kopie des entsprechenden Prozessobjekts). In dieser Arbeit wurde sich für den zweiten Weg (Softwarelösung) entschieden. Folgende zwei Gründe sind hierfür ausschlaggebend: Zum einen ist der Autor dieser Arbeit nicht der Urheber des Meta-Modells für das ein Modellierungswerkzeug entwickelt werden soll. Zum anderen soll die in dieser Arbeit entwickelte Software von Studierenden als Werkzeug zur Modellierung von Geschäftsprozessen im Übungsbetrieb zu den Kurseinheiten der Fernuniversität (speziell GEHRING (1999)) genutzt werden können. Speziell in diesem Fall verbietet sich eine Differenz zu den Meta-Modellen von GEHRING (1999). In den Abschnitten zu Entwurf und Implementierung wird im Detail auf die Möglichkeiten, welche die Software für das Lösen des gerade motivierten Problems anbietet, eingegangen.
Schließlich definiert Gehring (1999) ein Meta-Modell für die Datensicht. Im Unterschied zu den Meta-Modellen der Organisationsbzw. der Funktionssicht handelt es sich bei dem Meta- Modell der Datensicht nicht um eine Beschreibung der Möglichkeiten, ausschließlich Hierarchiebeziehungen zu modellieren, sondern um die Beschreibung der Möglichkeiten, beliebige Assoziationen zwischen Datenobjekten zu modellieren. Die Datensicht-Modelle sind dabei vergleichbar mit Entity-Relationship-Modellen (vgl. z.B. ELMASRI/NAVATHE 2006). Eine Assoziation kann zwei beliebige Datenobjekte miteinander mit bestimmten Kardinalitä- ten in Verbindung bringen. Gleichzeitig kann jedes Datenobjekt mit beliebig vielen weiteren
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 5: Erweitertes Begriffssystem nach GEHRING (1999)
Die Meta-Modelle werden in GEHRING (1999) durch die Definition eines Begriffssystems prä- zisiert, welches in Abbildung 5 in der erweiterten Form zu sehen ist. Durch das Begriffssystem wird der grundsätzliche Aufbau von Geschäftsprozessmodellen (also den sie darstellenden
[...]
1 http://bmi.omg.org/
2 http://www.microsoft.com/germany/windows/products/Windows XP/default.mspx
3 http://de.sun.com/products/software/star/staroffice/ 4http://www.gnome.org/projects/dia/
5 http://www.oracle.com/technology/bpel/index.html
6 In GEHRING (1999) wird „Organisationsobjekt“ und „Organisationseinheit“ teilweise synonym verwendet, wie auch aus den Abbildungen 1 und 2 deutlich wird.
- Arbeit zitieren
- Richard Hackelbusch (Autor:in), 2007, Entwicklung einer Applikation zur Modellierung von Geschäftsprozessen auf Basis der Eclipse Rich Client Platform, München, GRIN Verlag, https://www.grin.com/document/120095
-
-
-
-
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
-
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
-
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
-
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
-
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
-
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
-
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
-
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
-
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
-
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
-
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
-
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
-
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
-
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen.