18.01.2014 Aufrufe

Metamodellbasierte und hierarchieorientierte ... - RosDok

Metamodellbasierte und hierarchieorientierte ... - RosDok

Metamodellbasierte und hierarchieorientierte ... - RosDok

MEHR ANZEIGEN
WENIGER ANZEIGEN

Erfolgreiche ePaper selbst erstellen

Machen Sie aus Ihren PDF Publikationen ein blätterbares Flipbook mit unserer einzigartigen Google optimierten e-Paper Software.

18 Gr<strong>und</strong>lagen: Modellierung in ausgewählten Gebieten<br />

prozesse wurden mit EPKs dokumentiert [Men08]. In Abbildung 2.1 ist eine Ereignisgesteuerte Prozesskette<br />

als Beispiel angegeben, die einen Prüfungsprozess für Kreditanträge modelliert.<br />

Der Prozess beginnt mit zwei Startereignissen Credit application arrived <strong>und</strong> Customer advised, die<br />

zusammen auftreten müssen, damit der Prozess beginnen kann. Daraufhin wird der Antrag in einer Aktivität<br />

geprüft. Dort wird des Weiteren entschieden, welcher alternative Pfad im Prozessmodell zu nehmen ist.<br />

Wenn der K<strong>und</strong>e kreditwürdig ist, ist der Antrag anzunehmen, ansonsten abzulehnen. Letztendlich ist der<br />

K<strong>und</strong>e noch über die Entscheidung zu informieren.<br />

Abbildung 2.1: Eine Kreditantragsprozesse modelliert mit einer einfache Ereignisgesteuerten Prozesskette<br />

Die wichtigsten Bestandteile der Modellierung sind Ereignisse <strong>und</strong> Funktionen. Ereignisse <strong>und</strong> Funktionen<br />

werden alternierend in einer Kette mit Pfeilen verknüpft. Zudem können mit Konnektoren Prozesspfade<br />

verzweigt <strong>und</strong> wieder zusammengeführt werden. Prozesse beginnen immer mit Startereignissen <strong>und</strong> enden<br />

mit Endereignissen. Aktivitäten sind dazwischen zu spezifizieren. Startereignisse spezifizieren die Situation,<br />

in der der Prozess zu instanziieren ist. Damit wird modellinhärent angegeben, wann ein neuer Prozess startet<br />

[DM09]. Die EPK wurde des Weiteren in das ARIS-Modellierungskonzept zur Unternehmensmodellierung<br />

eingebettet, was in Abbildung 2.2 zu sehen ist.<br />

Die sehr einfache Modellierung <strong>und</strong> wenigen Modellierungsmittel machen die Sprache auch für Fachexperten<br />

sehr gut verständlich. Außerdem kann man durch die Bezeichnung des Ereignisses hinter einer Funktion<br />

spezifizieren, wann eine Aufgabe erledigt ist. Ereignisse können zudem visuell die Vor- <strong>und</strong> Nachbedingungen<br />

einer Funktion ausgedrücken. Eine weitere Eigenschaft der EPKs ist die Entscheidungsmodellierung.<br />

Semantisch wird bei EPKs vorgegeben, dass Entscheidungen aktiv in Funktionen zu treffen sind [KNS92].<br />

Somit muss unmittelbar vor einem Entscheidungskonnektor eine Funktion stehen. Ein Ereignis ist nicht<br />

erlaubt. Diese Modellierungsvorschrift hat Konsequenzen auf die Bezeichnung der Entscheidungsfunktion.<br />

Typischer Weise werden die Aktivitäten prüfe, untersuche oder entscheide bezeichnet.<br />

Bei den erweiteren Ereignisgesteuerten Prozessketten (eEPKs) werden weitere Modellelemente aus weiteren<br />

Modellen des ARIS-Ansatzes integriert. Dieser umfasst weitere Modelle wie das Daten-, Funktions-,<br />

Organisations- <strong>und</strong> Leistungsmodell. In Abbildung 2.2(a) ist das ARIS-Haus als konzeptionelles Bild<br />

visualisiert. Das Geschäftsprozessmodell als eEPK verbindet die Modelle miteinander. In Abbildung 2.2(b)<br />

ist ein Organisationsmodell-Beispiel angegeben. Das Organisationsmodell wird hierarchisch dargestellt.<br />

Das Unternehmen als ganzes wird in der Wurzel repräsentiert. Daraufhin werden die Abteilungen darunter<br />

modelliert. In Abbildung 2.2(b) gliedert sich die Bank in drei Abteilungen. In der Abteilung Business sind<br />

des Weiteren noch zwei Rollen assoziiert.<br />

Ein Beispiel für das Datenmodell ist in Abbildung 2.2(c) angegeben. Ursprünglich sind in der ARIS-<br />

Methode Entity-Relationship-Diagramme zur Datenmodellierung zu verwenden. Im aktuellen ARIS-Toolset<br />

werden aber auch UML-Klassendiagramme zur Datenmodellierung unterstützt, welche Diagrammart auch<br />

im Beispiel von Abbildung 2.2(c) angewendet wurde. Die benötigten Daten für den Prüfungsantrag für<br />

Kreditanträge sind hier mit den Klassen Customer, CustomerInformation, CreditApplication, Notification<br />

<strong>und</strong> den gegenseitigen Beziehungen modelliert.

Hurra! Ihre Datei wurde hochgeladen und ist bereit für die Veröffentlichung.

Erfolgreich gespeichert!

Leider ist etwas schief gelaufen!