Konvergente Geschäftsprozessmodellierung für die Softwareentwicklung mit
ARIS und UML

Diplomarbeit
zur Erlangung des Grades
eines Diplom Kaufmannes

an der Wirtschaftswissenschaftlichen Fakultät
der Humboldt-Universität zu Berlin

Verfasser: Jörg Krause

Berlin, 12.Mai 2003

 

"Es gibt nichts Neues mehr. Alles, was man erfinden kann, ist schon erfunden worden."
Charles H. Duell, US-Patentamt, 1899

"I think there is a world market for maybe five computers"
Thomas Watson, Chairman of IBM, 1943

"Data processing is a fad that won′t last out the year."
Editor of business books for Prentice Hall, 1957

Inhaltsverzeichnis

Inhaltsverzeichnis ... I
Abbildungsverzeichnis ... II
Tabellenverzeichnis ... III
Abkürzungsverzeichnis ... IV

1 Einleitung ... 1
1.1 Stakeholder und Probleme im Gesamtprozess ... 3
1.2 Geschäftsprozessmodellierung ... 4
1.3 Der Softwareentwicklungsprozess ... 6
1.4 Model Driven Architecture ... 9

2 Modellierung mit ARIS und UML ... 12
2.1 Schaffung von Konvergenz in der GPM ... 12
2.2 Geschäftsprozessmodellierung mit ARIS ... 14
2.2.1 Einsatzgebiete von ARIS ... 15
2.2.2 Sichten und Beschreibungselemente der GPM mit ARIS ... 17
2.2.3 Verbindung von Prozess- und Datensicht ... 18
2.2.4 Statik und Dynamik der ARIS Modellierung ... 20
2.3 Modellierung mit UML ... 21
2.3.1 Einsatzgebiete der UML ... 21
2.3.2 Systembeschreibung mit UML ... 22
2.3.3 GPM unter Verwendung der UML ... 23
2.4 ARIS-Integration der UML ... 26
2.5 Integration durch objektorientierte Erweiterung der EPK ... 29

3 Übertragung der Geschäftsprozessmodelle ... 31
3.1 Transformationen gemäss MDA ... 31
3.2 Mapping ... 33
3.3 Refinement und Konsistenzgestaltung ... 35

4 Softwareumsetzung und Bewertung ... 36
4.1 Reischmann Toolbus ... 37
4.2 Phaidros eaSE ... 38
4.2.1 Einsatzfelder ... 41
4.2.2 Anwendungsentwicklung ... 42
4.2.2.1 Systemvoraussetzungen ... 42
4.2.2.2 Benutzeroberflächen ... 42
4.2.2.3 Datenorganisation und Datenablage ... 45
4.2.2.4 Modellierung ... 47
4.2.3 Beurteilung und Fazit ... 55
4.3 ARIS-ROSE-Bridge ... 58
4.3.1 Vorgehens- und Modellierungskonzept ... 58
4.3.2 Modellierungskonzepte und Konventionen ... 60
4.3.2.1 Modellierung mit Filter ... 60
4.3.2.2 Modellierung der Sichten ... 61
4.3.3 Überführung und Technik ... 63
4.3.4 Beurteilung und Fazit ... 70

5 Zusammenfassung und Ausblick ... 74

Anhang ... 78

Literaturverzeichnis ... 86

Onlinequellen und sonstige ... 88
Verwendete Software ... 89

Abbildungsverzeichnis
Abb. 1: Stakeholder bei der Anwendungsentwicklung ... 3
Abb. 2: MDA Metamodell ... 9
Abb. 3: (e) EPK-Elemente ... 19
Abb. 4: Beispiel use case in Rational Rose ... 24
Abb. 5: aus Aktivitäten abgeleitete Klasse ... 25
Abb. 6: Beispiel-eEPK ... 27
Abb. 7: aus eEPK generiertes UML Klassendiagramm- nur Funktionen ... 28
Abb. 8: Beispiel activity diagram und aus der zugehörigen eEPK der ARIS- ... 29
Abb. 9: Konvergenz zwischen Modellen beim Einsatz der GPM ... 32
Abb. 10: Der Workspace Inspector in eaSE ... 43
Abb. 11: Der Web Workspace in eaSE ... 44
Abb. 12: Win Workspace in eaSE ... 45
Abb. 13: Navigation und Datenablagestruktur ... 46
Abb. 14: Aufruf der eaSE Importschnittstelle ... 48
Abb. 15: Klassendiagramm (Rose) und Fehlermeldung beim Import ... 48
Abb. 16: Workflow - Modellierungselemente in eaSE ... 49
Abb. 17: Beispiel-Workflow modelliert in eaSE ... 50
Abb. 18: VBS zum Modellierungsbeispiel ... 51
Abb. 19: UML - Modellierungselemente in eaSE ... 52
Abb. 20: UML Klassendiagramm zum Beispiel-Workflow ... 53
Abb. 21: Einfügen von vordefinierten UML-Elementen ... 53
Abb. 22: Teil-Metamodell für die Workflow-Erstellung ... 54
Abb. 23: Zusammenhänge zwischen DrUP, Modellen und Modellierungstools ... 59
Abb. 24: Attributdefinition Granularität ... 60
Abb. 25: zu überführende Beispiel eEPK ... 62
Abb. 26: Beispiel eERM für den Informationsträger "Beschwerdemail" ... 62
Abb. 27: erzeugte Infrastruktur in Rose ... 64
Abb. 28: erzeugtes Klassendiagramm (aus eERM) ... 65
Abb. 29: use cases bei eEPK Funktionsattribut "typisch" ... 66
Abb. 30: Ablage und use cases bei eEPK Funktionsattribut "grob" ... 67
Abb. 31: Ablage und activity Diagramm bei eEPK-Funktionsattribut "fein" ... 68
Abb. 32: übertragener Informationsträger und Verbindungsstruktur ... 69

Tabellenverzeichnis
Tabelle 1 : EPK und mögliche daraus ableitbare UML Modelle ... 34
Tabelle 2 : getestete ARIS Elemente und Überführungsergebnisse ... 70

Abkürzungsverzeichnis

[...]

1 Einleitung

Modelle sind in einer zunehmend komplexer werdenden Welt zu unabdingbaren Kommunikationsmitteln geworden, die aufgrund der immanenten Abstraktionskraft Systemzusammenhänge leichter erschließbar machen. Sie sind Abbildungen eines Realitätsausschnittes, die durch Abstraktion von Eigenschaften eines realen Objektes bzw. eines Systems entstehen, wobei die wesentlichen Strukturen und Verhaltensweisen bei der Beschreibung erhalten bleiben. Die Abstraktion, das Weglassen von unwesentlichen Eigenschaften, bestimmt sich einerseits aus dem inhaltlichen Modellierungszweck und aus dern verwendeten Methoden. Diese beiden Aspekte seien besonders hervorgehoben, da sie schon auf eine mögliche Problematik zwischen Modellen verschiedener Methoden und inhaltlicher Beschreibung hindeuten, deren Analyse die Arbeit prägen wird.
Einige Vorteile bei der Modellierung sind zusammengefasst:

• Komplexitätsreduktion der Systeme durch Abstraktion und Zerlegung in Teilprobleme
• Reduktion von Fehlern in der Entwicklung
• Leichterer Zugang zu Systemzusammenhängen und Verbesserungspotential [Sch98]
• Wiederverwendung und Weiterverwendung.

In Abhängigkeit von der Sicht auf ein System können gleiche Sachverhalte, anders ausgedrückt und repräsentiert werden. Dies ist zugleich die Ausgangsbasis für die Analyse, ob sich betriebswirtschaftlich prozessorientierte Systembeschreibungen mit objektorientierten der Softwareentwicklung vergleichen bzw. ineinander überführen lassen. Der erste Ansatz fokussiert auf eine semiformale, fachliche Beschreibung, hingegen beim zweiten steht eine technische, formalisierbare und standardisierbare Systembeschreibung im Vordergrund.
Weshalb sollte man aber GP-Modelle in objektorientierte Modelle überführen wollen?
Eine Antwort auf die Frage, ist die Benutzung und konsistente Weiterverwendung von unternehmensspezifischem Fachwissen, um den Erfolg und die Effizienz von Softwareentwicklungsprojekten zu erhöhen. Weiterhin ermöglicht die bedeutende Entwicklung auf dem Gebiet der Softwaregeneratoren dem versierten Nutzer, nunmehr aus Modellen ein Codegerüst und unter bestimmten Bedingungen, sogar ganze Anwendungen zu erzeugen, die besonders bei komplexen Projekten erheblich Aufwand reduzieren. Daher kann es sinnvoll sein, Individualsoftware über einen generativen Ansatz, der das Wissen von automatisiert weitergereichten und möglicherweise konsistenten Geschäftsprozessmodellen benutzt, herzustellen. Konvergenz¹ , muss dabei gewährleisten, dass die Modelle der einen Beschreibungswelt entweder vollständig oder auch problemorientiert in die andere überführt werden können, ohne dass das Ausgangsmodell zur Findung von relevanten Informationen weitergenutzt werden müsste. Das bedeutet dass alle fachlich und technisch zur Entwicklung benötigten Informationen des Ausgangsmodells in das Anfoderungsanalysemodell der zu erstellenden Anwendung, übernommen werden müssen.

Die Analyse der Arbeit wird sich auf die Beschreibungsansätze ARIS und UML beschränken und untersucht dabei Konvergenzvoraussetzungen. Nach einer kurzen Einführung zur Modellierung mit ARIS und UML wird die "Methodenintegration" der UML in ARIS anhand eines Beispiels vorgeführt werden, das zeigen soll, dass auch im ARIS-Konzept an einer Überführung gearbeitet wurde. Alternative Versuche einer Integration der Objektorientierung in die Prozessorientierung werden anschließend kurz erläutert und bewertet werden.
In einem weiteren Schritt sollen visionäre Möglichkeiten der Weiterverwendung von überführten GP-Modellen in der Softwareentwicklung sowie Probleme bei einer Überführung der GP-Modelle aufgezeigt werden.
Nachdem die Vorraussetzungen für eine Überführung veranschaulicht wurden, wird sich dem eigentlichen Schwerpunkt der Arbeit gewidmet, der Analyse und Bewertung von Software. Dazu wurden Kandidaten einer Überführung von ARIS nach UML bezüglich ihrer technischen Umsetzung und generellen Funktionsweise sowie anhand von Beispielen untersucht. Der Schluss dieser Arbeit fasst wichtige Ergebnisse zusammen und stellt mögliche Szenarios in Aussicht.
Doch nun werden ausgewählte Probleme und auftretende Entscheidungen exemplarisch erörtert, die im Zusammenhang mit Softwareentwicklungsprojekten entstehen können, bevor der GP dargestellt und in den Entwicklungsprozess eingeordnet wird .

1.1 Stakeholder und Probleme im Gesamtprozess

Mit zunehmender Bedeutung von Software im GP werden auch die zu realisierenden Softwareprojekte komplexer. Daher ist eine Arbeitsteilung zwischen den beteiligten Personen (Stakeholder) bei der Projektdurchführung oft zwingend. Nicht nur bei der GP-Erhebung und innerhalb des Entwicklerteams findet diese Arbeitsteilung statt, sondern auch zwischen den Entwicklern und Anwendern, sowie zwischen den Betreibern der Software (IT-Abteilung). Bei der Arbeitsteilung entstehen häufig Kommunikations-, Vorgehens- bzw. Organisationsprobleme.² Ebenso existieren aber auch Probleme die mit der Erhebung, Repräsentation und Weiterverwendung von Wissen im Zusammenhang stehen, die man versucht durch Modellierung zu lösen bzw. zu reduzieren.

!! Abbildung ist in der Downloaddatei enthalten !!

Abbildung 1: Stakeholder bei der Anwendungsentwicklung

Eine große Bedeutung hat die Entscheidung zwischen zentraler GP-Erhebung, wie zum Beispiel durch einen Analysten (abgebildet) und der Erhebung durch die Mitarbeiter der Fachabteilungen. Falls die Fachabteilungen selbst modellieren, könnte sich dadurch eine schnellere Umsetzung des Projektes und die teilweise Reduktion eines möglicherweise fehlerbehafteten Kommunikationsprozesses oder der Nachinterviews ergeben. Ebenso kann das Prozesswissen direkt an der "Quelle" durch den einzelnen Mitarbeiter eingebracht werden. Ein typisches Modellierungsproblem ergibt sich daraus, dass der Modellierer seine ganz persönliche Sicht auf den Prozess modelliert und somit Interpretationsspielräume bei den GP entstehen die, wenn sie nicht rechtzeitig erkannt werden, "teuer bezahlt" werden müssen. Der Analyst hingegen kann seine Projekterfahrung direkt bei der Erhebung einsetzen, wohingegen Mitarbeiter erst geschult werden müssten. Dies führt zur Frage, welches Tool und somit welche Methode zur GPM respektive zur weiteren Anforderungsanalyse eingesetzt wird, damit Wissen einfach und intuitiv erhoben, vermittelt und weiterverwendet werden kann. In aller Regel wird sich für ein Tool entschieden, dass die jeweilige Projektphase am besten unterstützt. Nicht zuletzt resultiert dies auch aus der bewussten marktstrategischen Produktabgrenzung der Toolanbieter. Im hier zu untersuchenden Fall wird in der Phase der GPM ARIS eingesetzt und bei der weiteren Anforderungsanalyse und anschließendem Systemdesign ein UML-CASE-Tool. Hierbei entsteht aber das Problem, wie zu definierende Ergebnisse der GPM als initiale Anforderungen weiterverwendet und auch weitervermittelt werden können. Eine gemeinsame Verständigungsbasis zur Kommunikation ist hier die UML, die "Sprache" des Entwicklers, seines Teams und der IT-Abteilungen. Jedoch müssten die GP-Modelle, die in einer anderen Beschreibung vorliegen "übersetzt" werden, um in UML weiterverwendet werden zu können.

[...]

1 lat. : Übereinstimmung / Annäherung

2 alle Beziehungen und somit mögliche Problemquellen sind in der Abbildung durch beschriftete Pfeile markiert.