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


Diplomarbeit, 2003

96 Seiten, Note: 2,1


Leseprobe


Inhaltsverzeichnis

Abbildungsverzeichnis

Tabellenverzeichnis

Abkürzungsverzeichnis

1 Einleitung
1.1 Stakeholder und Probleme im Gesamtprozess
1.2 Geschäftsprozessmodellierung
1.3 Der Softwareentwicklungsprozess
1.4 Model Driven Architecture

2 Modellierung mit ARIS und UML
2.1 Schaffung von Konvergenz in der GPM
2.2 Geschäftsprozessmodellierung mit ARIS
2.2.1 Einsatzgebiete von ARIS
2.2.2 Sichten und Beschreibungselemente der GPM mit ARIS
2.2.3 Verbindung von Prozess- und Datensicht
2.2.4 Statik und Dynamik der ARIS Modellierung
2.3 Modellierung mit UML
2.3.1 Einsatzgebiete der UML
2.3.2 Systembeschreibung mit UML
2.3.3 GPM unter Verwendung der UML
2.4 ARIS-Integration der UML
2.5 Integration durch objektorientierte Erweiterung der EPK

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

4 Softwareumsetzung und Bewertung
4.1 Reischmann Toolbus
4.2 Phaidros eaSE
4.2.1 Einsatzfelder
4.2.2 Anwendungsentwicklung
4.2.2.1 Systemvoraussetzungen
4.2.2.2 Benutzeroberflächen
4.2.2.3 Datenorganisation und Datenablage
4.2.2.4 Modellierung
4.2.3 Beurteilung und Fazit
4.3 ARIS-ROSE-Bridge
4.3.1 Vorgehens- und Modellierungskonzept
4.3.2 Modellierungskonzepte und Konventionen
4.3.2.1 Modellierung mit Filter
4.3.2.2 Modellierung der Sichten
4.3.3 Überführung und Technik
4.3.4 Beurteilung und Fazit

5 Zusammenfassung und Ausblick

Anhang

Literaturverzeichnis

Onlinequellen und sonstige

Verwendete Software

Eidesstaatliche Versicherung

Abbildungsverzeichnis

Abbildung 1: Stakeholder bei der Anwendungsentwicklung

Abbildung 2: MDA Metamodell

Abbildung 3: (e) EPK-Elemente

Abbildung 4: Beispiel use case in Rational Rose

Abbildung 5: aus Aktivitäten abgeleitete Klasse

Abbildung 6: Beispiel-eEPK

Abbildung 7: aus eEPK generiertes UML Klassendiagramm- nur Funktionen

Abbildung 8: Beispiel activity diagram und aus der zugehörigen eEPK der ARIS-

Abbildung 9: Konvergenz zwischen Modellen beim Einsatz der GPM

Abbildung 10: Der Workspace Inspector in eaSE

Abbildung 11: Der Web Workspace in eaSE

Abbildung 12: Win Workspace in eaSE

Abbildung 13: Navigation und Datenablagestruktur

Abbildung 14: Aufruf der eaSE Importschnittstelle

Abbildung 15: Klassendiagramm (Rose) und Fehlermeldung beim Import

Abbildung 16: Workflow - Modellierungselemente in eaSE

Abbildung 17: Beispiel-Workflow modelliert in eaSE

Abbildung 18: VBS zum Modellierungsbeispiel

Abbildung 19: UML – Modellierungselemente in eaSE

Abbildung 20: UML Klassendiagramm zum Beispiel-Workflow

Abbildung 21: Einfügen von vordefinierten UML-Elementen

Abbildung 22: Teil-Metamodell für die Workflow-Erstellung

Abbildung 23: Zusammenhänge zwischen DrUP, Modellen und Modellierungstools

Abbildung 24: Attributdefinition Granularität

Abbildung 25: zu überführende Beispiel eEPK

Abbildung 26: Beispiel eERM für den Informationsträger „Beschwerdemail“

Abbildung 27: erzeugte Infrastruktur in Rose

Abbildung 28: erzeugtes Klassendiagramm (aus eERM)

Abbildung 29: use cases bei eEPK Funktionsattribut „typisch“

Abbildung 30: Ablage und use cases bei eEPK Funktionsattribut „grob“

Abbildung 31: Ablage und activity Diagramm bei eEPK-Funktionsattribut „fein“

Abbildung 32: übertragener Informationsträger und Verbindungsstruktur

Tabellenverzeichnis

Tabelle 1 : EPK und mögliche daraus ableitbare UML Modelle

Tabelle 2 : getestete ARIS Elemente und Überführungsergebnisse

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

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[1], 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 realiesierenden 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.[2] 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 in dieser Leseprobe nicht 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.2 Geschäftsprozessmodellierung

Bevor ich mit dem thematischen Überblick zur Geschäftsprozessmodellierung beginne, möchte ich den Begriff Geschäftsprozess zunächst etwas präzisieren.

Scheer versteht hierunter :

„Allgemein ist ein Geschäftsprozess eine zusammengehörende Abfolge von Unternehmensverrichtungen zum Zweck einer Leistungserstellung. Ausgang und Ergebnis des Geschäftsprozesses ist eine Leistung, die von einem internen oder externen „Kunden“ angefordert oder abgenommen wird.“[Sch98,S.3]

An dieser Definition ist deutlich der betriebswirtschaftliche Ursprung zu sehen – der Ausrichtung an der im Unternehmen erstellten Leistung. Demnach sind GP systemübergreifend und machen nicht an Abteilungs- und Anwendungssystemgrenzen halt. In erster Linie wird durch die Modellierung der Geschäftsprozesse eine transparente Dokumentation der betrieblichen Abläufe bzw. des Geschäfts angestrebt, die es jedem Mitarbeiter ermöglichen soll, die ihm zugeteilten Aufgaben und Verrichtungen nachvollziehen zu können. Die Modellierung der GP erfolgt in der Regel durch grafische Beschreibung, aufgrund höherer Intuitivität gegenüber textuellen Beschreibungen insbesondere bei parallelen Abläufen. Jedoch sind diese grafische Beschreibungen meist nicht formale Sprachen, so dass es zu den genannten Auslegungsspielräumen des zu beschreibenden Sachverhalts kommen kann. [Rum99,S.12]

Des weiteren dient eine Dokumentation der Geschäftsprozesse als Basis für das BPR, dessen Ergebnisse wiederum Veränderungen der Anwendungen nach sich ziehen können. GP-Modelle, die auf eine Einführung/Veränderung eines unterstützenden Anwendungssystems abzielen, enthalten daher eine abstrakte Repräsentation eines Informationssystems und können als Anforderungen an das zu erstellende System angesehen werden. Ist ein GP besonders gut geeignet automatisiert bearbeitet zu werden, dann handelt es sich um einen Workflow, für den es fertige Anwendungsysteme, die Workflow-Managementsysteme gibt. [Rum99,S.12]

Festzuhalten bleibt jedoch, dass GP-Elemente einen bestimmten Detaillierungsgrad aufweisen müssen, damit keine Auslegung bei der Anwendungsentwicklung bzw. keine unnötigen Nachinterviews erfolgen müssen. Die zentrale Frage im Kontext dieser Arbeit ist hierbei, ob sich diese Anforderungsdefinition konsistent in UML-Anforderungsmodelle überführen und weiterverwenden lässt und inwieweit GP-Modelle weiterhin als Dokumentation erhalten bleiben müssen. Deshalb soll zunächst einmal die Einordnung der GPM in den Softwareentwicklungsprozess geklärt werden, um sich eine Vorstellung machen zu können, in welchem Umfang diese zur Anwendungsentwicklung beitragen kann.

1.3 Der Softwareentwicklungsprozess

Den Startpunkt des “eigentlichen” Software-Entwicklungsprozesses markiert die Anforderungsdefinition (requirement definition) eines zu verbessernden Systems. Bei den Anforderungen zur weiteren Systementwicklung wird der Entwickler mit folgenden Herausforderungen konfrontiert [Som01,S.13]:

1. Legacy challenge

Viele Softwaresysteme die heutzutage benutzt werden, sind älteren Ursprungs und/oder haben geschäftskritische Funktionen, die beachtet oder in die Entwicklung, z.B. über Schnittstellen, eingebunden werden müssen. Die Herausforderung hierbei besteht darin, die Softwarefunktion aufrechtzuerhalten oder auf einen neueren Stand zu bringen, so dass zum einen die essentiellen Funktionen weiterhin bestehen bleiben, aber auch unnötige Kosten (z.B. Wartung) vermieden werden.

2. Heterogeneity challenge

Aufgrund der Zunahme verteilter Systeme (z.B. Netzwerke), verschiedener Plattformen oder auch verschiedener Anwendungen ist der Entwickler herausgefordert, flexible und verlässliche Software zu entwickeln, die die Heterogenität von Systemen berücksichtigt.

3. Delivery challenge

Traditionelle software engineering Techniken sind zeitaufwändig, um Qualität zu gewährleisten. Da die heutigen Märkte sich rapide schnell verändern, müssen sich Unternehmen und mit ihnen gleichsam schnell die eingesetzte Software verändern. Um dies zu gewährleisten, muss Software in kürzeren Lieferzeiten, ohne Einschränkungen an die Qualität machen zu müssen, bereitstellbar sein.

Durch die steigende Intensität dieser Herausforderungen sowie der Komplexität und Grösse von Software hat sich die Objektorientierung entwickelt, da ältere Ansätze[3] dem Entwicklungsprozess nicht mehr gerecht wurden. Das objektorientierte Paradigma, dass bei der Anwendung der Objektorientierung in der Systemerstellung Durchgängigkeit und Lösung der obigen Probleme postuliert, verbindet somit auch das BE mit dem software engineering (siehe Abbildung). Allerdings ist diese Verbindung auch nicht unproblematisch, da unterschiedliche Begriffsauffassungen für Objekte existieren, die die oben genannten Auslegungsspielräume durch unversierte Modellierer erzeugen. Aber selbst falls Klarheit in der GPM über den betriebswirtschaftlichen Objektbegriff besteht, kann ein solches Objekt auch auf unterschiedlichem Abstraktionsniveau (granular) beschrieben sein und die Durchgängigkeit gemäss Paradigma ist gestört. Im Software Engineering wird jedenfalls der technische Objektbegriff verwendet.[4] Für die Softwareentwicklung heutiger Systeme benötigt man zudem objektorientierte Methoden, die den gesamten Entwicklungsprozess unterstützen, Komplexität reduzieren und Wiederverwendung auf jeder Entwicklungsstufe erleichtern.

Folgende Makroprozesse bzw. Phasen[5] der Softwarentwicklung sind insgesamt zu identifizieren:

1. Analyse – konkrete Aufgabenstellung zur Softwareentwicklung (auch: requirement)
2. Spezifikation – Dokumentation der späteren Softwarefunktionen
3. Design/Entwurf – Dokumentation der Problemlösung anhand der logischen Gliederung der Funktionen und Daten als fachlichen und der Ablaufstruktur als programmtechnischen Entwurf
4. Implementation – Kodierung der Problemlösung in einer Programmiersprache, Kompilation und Verbinden der Software
5. Testen und dokumentieren – Auffinden von Fehlern
6. Anwendung – Betrieb der Software
7. Modifikation – Anpassung an veränderte Umweltbedingungen[BS00,S.22ff]

Die GPM mit ersten Anforderungsdefinitionen würde nach dieser Grobeinteilung einen Teil der Phase Analyse darstellen, wobei der wirklich kreative Teil der Analyse und des Designs erst im Anschluss erfolgt.

Die obigen Phasen werden in Vorgehensmodellen detailliert und unabhängig von bestimmten software engineering Methoden (strukturierte oder objektorientierte) beschrieben. Sie enthalten z.B. die Aktivitäten, Personen oder Produkte, die in den einzelnen Phasen des Entwicklungsprozesses anfallen. Vorgehensmodelle unterscheiden sich hinsichtlich der berücksichtigten Phasen und werden zudem projektabhängig vom entwickelnden Unternehmen angepasst. Beispiele für Vorgehensmodelle sind das Wasserfallmodell, Spiralmodell, V-Modell und der Unified Process - der ein allgemeinenes Vorgehensmodell für objektorientierte Softwareentwicklung ist und deshalb näher betrachtet wird.

Durch die Entstehung der UML als Notation in Verbindung mit dem UP wurde Softwareentwicklern die Möglichkeit gegeben, eine Methode zu entwickeln, die man auf den gesamten Entwicklungsprozesses anwenden kann. Da der UP nur eine allgemeine Vorlage für das Vorgehen (und Produkte) im Softwareprozess darstellt, sind auch hier konkrete Anpassungen an die Gegebenheiten des verwendenden Unternehmens nötig. Eine angepasste Version bzw. eine „Instanz“ des UP ist zum Beispiel der RUP, der ebenso spezielle Sichten (view) auf ein zu entwickelndes System gemäss dem Entwicklungsprozess vorschlägt.[6] Durch die Zerlegung in Sichten entsprechend Struktur und Verhalten wird unter Verwendung der UML die Komplexität erheblich reduziert.

Wie im Abschnitt zur GPM schon ansatzweise festgestellt wurde, liegt der Übergang von der GPM zur Softwareentwicklung in der Anforderungsanalyse.In Anbetracht dessen, kann ein optimiertes Geschäftsprozessmodell in der Regel auch Grundlage für die objektorientierte Systementwicklung sein und somit in der Anforderungsanalyse verwendet werden.[Sch01, S.203]

Ein methodisches Vorgehen zur Anwendungsentwicklung, wie z.B. mit dem UP und UML, muss also eine GPM berücksichtigen, indem eine zu verwendende GPM-Methode festgelegt wird, auf deren Ergebnisse der Entwicklungsprozess konsistent weitergeführt werden kann. Der Wieder- und Weiterverwendungsgedanke von GP-Modellen führte im wesentlichen zu den Bestrebungen GP-Modelle in die UML zu überführen. Durch die Entwicklung der modellbasierten UML und anderer UML-Beschreibungsstandards kamen verstärkt Bestrebungen auf, automatisiert Modelle einer Beschreibungssprache in die andere zu überführen. Auf Basis der überführten GP-Modelle würde dies dann maximale Wieder- und Weiterverwendbarkeit in der Anwendungsentwicklung bedeuten. Der umgekehrte Fall einer Rücküberführung von UML-Modellen zum BPR wird dadurch ebenso vorstellbar. Doch nun zu einer kurzen Beschreibung des modellbasierten Überführungsansatzes aus der Softwareentwicklung.

1.4 Model Driven Architecture

Ausgehend von den veränderten IT–Anforderungen an die Unterstützung der Geschäftsprozesse (Stichwort E-Business) und der zunehmenden Intensität der oben beschriebenen Herausforderungen, erklärt sich die Dringlichkeit der Etablierung eines Lösungsansatzes für die “neue” Anwendungsentwicklung.

Das Hauptziel der Entwicklungsarbeiten der OMG im Rahmen der OMA ist es, Integration von heterogenen Systemen, also Interoperabilität zwischen verschiedenen, den Geschäftsprozess unterstützenden IT-Anwendungen zu schaffen. Neben der Entwicklung von CORBA, einem Standard für verteilte Unternehmensanwendungen sowie deren Integration über Schnittstellen und der UML als Modellierungsprache, wurden ausserdem die Interoperabilitätsstandards Common Warehouse Metamodel (CWM) für datenbankbasierte Applikationen, XML Metadata Interchange (XMI) zum Austauschen von UML Modellen und MOF zur Definition weiterer Standards und Beschreibungssprachen geschaffen.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2: MDA Metamodell

Quelle : [AB01,S.12]

Das Ziel der MDA ist es, eine Systembeschreibung durchzuführen, die die Funktionalität eines modellierten Systems von Implementationsdetails einer spezifischen Anwendungsplattform trennt, um Wiederverwendung und folglich leichtere Integration zu erreichen. Anders ausgedrückt heisst das, dass mit der MDA ein Architekturrahmen bereitgestellt wird, in dem Modelle unabhängig von der zu verwendenden Plattform modelliert werden können. Mit MDA und den unterstützenden Standards ist es dann möglich, aus den modellierten Systemfunktionalitäten, dem Plattform Independent Model (PIM), durch Mapping verschiedene plattformspezifische Umsetzungen (Platform Specific Model – PSM) in Basistechnologien[7] zu generieren, wobei somit die Möglichkeit des roundtrip engineering[8] eröffnet wird.

Nach der MDA-Definition ist ein Modell eine Repräsentation eines Teils der Funktion, Struktur und/oder Verhaltens eines Systems, dass durch eine Modellierungssprache[9] wiedergegeben wird. Die in dieser Arbeit betrachtete Modellierungssprache ist UML, deren Beschreibungselemente aus MOF definiert sind, mit denen sich Struktur und Verhalten eines Systems beschreiben lässt. Von Bedeutung hierbei ist, dass Geschäftsmodelle in PIM-Form (allerdings in UML) explizit im MDA-Ansatz einbezogen werden. [AB01,S.7]

Im Kontext des MDA wäre eine Überführung deshalb interessant, da GP-Modelle in ARIS auch plattformunabhängig (PIM) bzw. “Computation Independent” erstellt und ebenso Struktur und Verhalten eines Systems abgebildet werden kann.

Die Vorteile der auf diese Art entstandenen PIM lassen sich wie folgt im Bezug auf die GPM und die Überführung zusammenfassen:

1. Plattformspezifische Details müssen nicht unbedingt in der GPM erhoben und der Gefahr des Informationsverlustes durch Modellanpassungen in einzelnen Entwicklungsstufen ausgesetzt werden. In der GPM braucht man sich keine Gedanken über die Vollständigkeit der Datenerhebung hinsichtlich möglicher Zielstrukturen machen, so dass auch Fehler beim Modellieren möglicher Realisationen nicht durch den Entwicklungsprozess getragen werden. Aufgrund dessen lassen sich PIM’s auch leichter validieren.

Basierend auf einer gemeinsamen Struktur und Verhalten lassen sich Anwendungsdesign-Kategorien (design patterns) und Implementationen auf verschiedenen Plattformen produktiver erstellen.

2. Die Entwicklung wird durch Überführung der Geschäftsprozessmodelle nach UML effizienter (Zeit, Kosten), da konsistente Weiterentwicklung sofort möglich ist und Redundanzen und Doppelarbeit vermieden werden. Ein wichtiges Anwendungsbeispiel hierfür ist das rapid prototyping - das schnelle Erstellen eines lauffähigen Systems, das die wesentlichsten Eigenschaften des End-Softwaresystems besitzt.

Ein Prototyp eines Anwendungssystems

- liefert frühzeitig wichtiges Feedback von den Anwendern und ermöglicht ihnen einen leichteren Übergang zum neuen System durch frühzeitiges Kennenlernen von Funktionalitäten;
- verringert das Projektrisiko, so dass diese seltener abgebrochen werden, falls man hinter dem Projektzeitplan ist
- verringert das Risiko von Fehlern in kritischen Hauptsystemschnittstellen, da diese als erstes und am häufigsten getestet werden
- ermöglicht Coding und Tests noch vor Abschluss der Design-/Realisierungsphase. [Pag88,vgl.S.261-265]

2 Modellierung mit ARIS und UML

2.1 Schaffung von Konvergenz in der GPM

Die Identifikation der zu verändernden Prozesse und möglicher zu verändernder Anwendungssysteme erfolgt durch die GPM bzw. durch die Analyse ihrer Ergebnisse. Entscheidend für die Effizienz der GPM ist natürlich eine (Modellierungs-) Werkzeugunterstützung.

Um Konvergenz zwischen der GPM und der anschließenden Entwicklungsphase zu gewährleisten, kann ein Kriterium bei der Wahl des Werkzeugs, die angebotenen Schnittstellen sein sowie Überführungsmöglichkeiten zu anderen Modellierungs- und Entwicklungsumgebungen. Jedoch hat die Wahl der Modellierungsmethode (z.B.EPK) einen ebenso großen Einfluss bei dieser Entscheidung und letztendlich auch im Hinblick auf eine mögliche Überführung. Hinzu kommt, dass gerade durch die Vielzahl der beteiligten Personen und insbesondere wenn die Modellierung durch die Fachabteilungen selbst erfolgen soll, bestimmte Kriterien bei der Methodenauswahl entscheidend sind. Scheer [Sch94,S.18] nennt als Methodenauswahlkriterien:

- die Einfachheit und Verständlichkeit der Darstellungsmittel,
- die Eignung für die speziell auszudrückenden Inhalte,
- die Möglichkeit, für alle darzustellenden Anwendungen einheitliche Methoden einsetzen zu können,
- der vorhandene oder zu erwartende Bekanntheitsgrad der Methoden sowie
- die weitgehende Unabhängigkeit der Methoden von technischen Entwicklungen der Informationstechnik.

Wie bereits oben angeklungen, ist sowohl für eine erfolgreiche GPM, als auch einer anschließenden Entwicklung, die Schaffung von institutionellen Rahmenbedingungen nötig. Diese müssen im methodischen Vorgehen fest implementiert sein, da sie auch die einzusetzende Methode bzw. Beschreibungstechnik bestimmen.

1. Schulung und Einweisung

Nach erfolgter Methodenwahl sind die beteiligten Personen, gerade bei der Delegation der GPM an Fachabteilungen, in Konventionen der verwendeten Methoden einzuweisen. Durch diese Maßnahme wird eine einheitliche Prozessdarstellung sowie eine Kommunikation der Modellierungsergebnisse ermöglicht und deren Weiterverwendbarkeit erhöht.

2. Durchführung von Workshops

Um einen Wissenstransfer und eine Durchdringung der fachlichen Ebene herzustellen, sind Workshops mit denen am Prozess beteiligten Personen erforderlich. Bei einer Delegation der Modellierung können Modellierungsergebnisse mit Projektverantwortlichen ausgewertet und zur Analyse durchgesprochen werden. An dieser Stelle wäre es ratsam, Anwendungsentwickler bzw. Systemanalytiker mit einzubeziehen, da fachliche und betriebliche Zusammenhänge und auch Probleme offenbart werden, die ein Auffinden einer Anwendungslösung erheblich erleichtern. Auch Probleme hinsichtlich des Detaillierungsgrades von Modellen (und Elementen) können beurteilt und nachdokumentiert werden, wenn GP-Modellierer und Systemanalytiker (sofern sie nicht ein und dieselbe Person sind) zusammenarbeiten.[Büh01,S.26]

3. Frühe Integration von Entwicklern in den Analyseprozess

Da die Anwendungsentwicklung in der Regel nicht vom Geschäftsprozessmodellierer bzw. dem Projektverantwortlichen (GP-Analytiker) durchgeführt wird, ist eine frühzeitige Einbeziehung von Entwicklern, noch vor der Beendigung der Phase der GPM ratsam. Ziel dabei ist eine frühe Einarbeitung und ein fachliches Verständnis von Unternehmensabläufen und dessen unterstützender IT zu ermöglichen. Es können somit frühzeitig Verständnisfragen geklärt und fehlende Systemspezifikationen dokumentiert werden, solange die GPM-Phase noch nicht abgeschlossen ist. Dadurch reduziert sich, wie schon angesprochen, Nachdokumentationsbedarf in der anschließenden Entwicklungsphase, so dass Anwendungen schneller und eventuell besser umgesetzt werden können.

2.2 Geschäftsprozessmodellierung mit ARIS

Das Konzept von ARIS wurde 1991 am Institut für Wirtschaftinformatik an der Universität des Saarlandes entwickelt und als ARIS-Toolset durch die IDS Scheer AG seit 1994 mit stetig wachsendem Erfolg vertrieben. So wurden 1998 noch 8000 Lizenzen [Rum99][10] und 2002 schon über 33000 Lizenzen[11] verkauft. [IDS03] Da das Konzept schlüssig, benutzerfreundlich und mit nötigem betriebswirtschaftlichen Fachbezug umgesetzt wurde, ist das ARIS-Toolset zumindest in Deutschland zum Standard geworden. [Rum99,S.61] Neben ARIS gibt es zwar noch andere Ansätze zur GPM, wie z.B. den Promet-Ansatz mit Aufgabenkettendiagrammen, die aber insgesamt weniger populär sind.[12]

Die „Architektur integrierter Informationssysteme“ (ARIS) stellt ein „Rahmenkonzept zur ganzheitlichen Analyse (Modellierung) computergestützter Informationssysteme vom Fachkonzept bis zur Implementierung“ zur Verfügung. Hierbei spielt die Unterstützung betriebswirtschaftlicher Geschäftsprozesse durch integrierte Informationssysteme eine besondere Rolle. [Sch98,S.1]

Wie aus dieser Beschreibung ersichtlich wird, sind Informationssysteme bzw. Anwendungen im betrieblichen Systemablauf ein zentraler („integrierter“) Bestandteil der ARIS Methode. Neben der Verbindung von Betriebswirtschaftslehre mit Informationssystemen wurden rein betriebswirtschaftliche Konzepte, wie Prozesskostenrechnung, Prozessoptimierung (BPR) und Qualitätsmanagement in ARIS integriert. Ein wichtiges Ziel der ARIS Modellierungsmethoden ist die Schaffung einer semiformalen Beschreibung von betrieblichen Abläufen und Interaktionsbeziehungen mit bestehenden Anwendungssystemen. Im Hinblick auf Geschäftsprozessoptimierung durch Optimierung der unterstützenden IT Systeme soll diese Beschreibung ausreichend sein, um eine „Ausgangsbasis“ zur Anwendungs- bzw. Softwareentwicklung zu bieten. [Sch98,S.2,Abs.2]

Üblicherweise werden die mit der ARIS-Methodik erfassten Istabläufe dem Sollkonzept entsprechend optimiert. Aus diesen optimierten Geschäftsprozessen ergeben sich dann die Anforderungen an die Software bzw. Anwendungsysteme. Welche Anforderungen jedoch an die Modellierung mit ARIS für eine transformierende Überführung zu stellen sind, soll die Arbeit im weiteren Verlauf und insbesondere im praktischen Teil für spezielle Umsetzungen aufzeigen.

Im Zusammenhang mit ARIS werden häufig die Begriffe „Methode“ und „Konzept“ analog verwendet, was soviel bedeutet, dass ARIS einen fachlichen Bezugsrahmen für die Beschreibung eines betrieblichen Systems bereitstellt. Jedoch ist das ARIS-Konzept selbst methodenneutral, da unter Bezugsrahmen lediglich die Bereitstellung von verschiedenen Methoden zu verstehen ist, die mögliche, noch zu erläuternde Sichtweisen auf das System erlauben. Bei der Erfassung der Geschäftsprozesse wird dabei dem Modellierer anhand vielfältiger Beschreibungsaspekte und deren Zuordnung zu Methoden sowie der Unterstützung beim BE / BPR, die Arbeit erleichtert und systematisiert. [Sch98,S.2-5]Der Hauptfokus dieser betrieblichen Systemanalyse in ARIS konzentriert sich auf den weiter oben schon definierten Geschäftsprozess. Als häufigstes Prozessbeschreibungsmittel in ARIS wird hierfür die eEPK-Methode gewählt.[Rum99]

2.2.1 Einsatzgebiete von ARIS

Scheer nennt folgende „Zwecke zur Aufstellung von betriebswirtschaftlichen Geschäftsprozessmodellen:

- Optimierung organisatorischer Veränderungen im Rahmen des BPR,
- Speicherung von Organisationswissen, z.B. in Form von Referenzmodellen,
- Nutzung der Prozessdokumentationen zur ISO-9000 ff.- Zertifizierung,
- Berechnung der Kosten von Geschäftsprozessen,
- Nutzung der Prozessinformationen zur Einführung und Anpassung (Customizing) von Standardsoftware oder Workflow-Systemen[13].“ [Sch98,S.3]

Wie aus dem ersten Kapitel schon hervorging, ist die Dokumentation von Wissen ein zentrales Ziel der GPM, da Wissen bei allen Veränderungsprozessen im Unternehmen über den Erfolg entscheidet. Es muss sichergestellt sein, dass die Dokumentation auch intuitiv, nachvollziehbar und anwendbar für alle Beteiligten ist, so dass bei der Geschäftsprozessanalyse eine gemeinsame „Sprache gesprochen“ wird. Hier liegt der große Vorteil von ARIS gegenüber anderen GPM-Ansätzen.[14]

Ausgehend von der Möglichkeit der Anpassung von Standardsoftware soll weitergehend analysiert werden, ob es mit der ARIS Modellierung unter Einbeziehung von Entwicklungstools möglich ist, eine Basis zur Entwicklung von Individualsoftware günstig, schnell und einfach bereitstellen zu können. Dies wird immer dann der Fall sein, wenn keine Standardsoftwarelösung eingesetzt werden kann, z.B. wenn diese nicht die gewünschte Funktionalität besitzt. Hierbei dienen Geschäftsprozessmodelle als Vorlage für die Anforderungsdefinition der zu entwickelnden Anwendung. Bei gegebener Transformationsmöglichkeit in Entwicklungs-Tools könnten Zeit (= Kosten) reduziert und Wissen redundant sowie wiederverwendbar abgelegt werden. Gerade die Eigenschaft der Wiederverwendung der GP–Modelle hat die IDS Scheer als einen wesentlichen Effizienzvorteil von ARIS in nahezu allen Produktbeschreibungen hervorgehoben. Lediglich bis zur Version 4.xx gab es die Möglichkeit, GP-Modelle älterer Versionen zu importieren, danach waren die Importe von Modellen oder ganzen Datenbanken verschiedener Versionen häufig fehlerhaft oder funktionierten überhaupt nicht. Die kurzen Versionierungszyklen mit ungenügender Abwärtskompatibilität von ARIS haben also nicht unbedingt zur postulierten Wiederverwendung beigetragen. Hingegen würde die Überführung nach UML die Lösung dieses Problems darstellen, da die verschiedenen UML-Versionen abwärtskompatibel sein müssen und eine erhebliche Anzahl UML-Tools existieren.[15]

2.2.2 Sichten und Beschreibungselemente der GPM mit ARIS

Bei der Modellierung eines „integrierten“ Informationssystems wird bei ARIS eine Komplexitätsreduktion durch Bildung von Beschreibungssichten erreicht. Innerhalb der Sichten können verschiedene Abstraktionsebenen modelliert werden, so dass einem im Modell enthaltenen Diagramm eine Verfeinerung nicht nur der gleichen Sicht angefügt werden kann. In ARIS werden folgende Sichten bereitgestellt:

- Funktionssicht

Funktionen sind Verrichtungen innerhalb der Leistungserstellung, egal ob es sich um Dienstleistungen oder um eine Gütererstellung handelt. [Rum99,S.55] In der Funktionssicht werden diese mit ihren Abhängigkeiten, zum Beispiel in Form eines Funktionsbaumes, dargestellt.

- Datensicht

Sie soll Informationsobjekte und deren Beziehungen zueinander darstellen und somit Wissen abbilden. [Rum99,S.55] In der Datensicht verkörpert das Entity-Relationship-Modell das bekannteste Modell, das zum Beispiel für die Modellierung von Datenbanken von großem Nutzen ist.

- Organisationssicht

In dieser Sicht werden strukturelle Angaben der Aufgabenträger eines Unternehmens, wie zum Beispiel die Organisationshierarchie bzw. die Aufbauorganisation, modelliert. Ein häufig verwendeter Diagrammtyp ist hier das Organigramm, bei dem sich sogenannte generalisierte Einheitstypen, das bedeutet Klassen von Organisationseinheiten, bis hin zur Ausprägung/Instanz (z.B. Stelle) abbilden lassen.

- Prozesssicht (oft auch Steuerungssicht genannt)

In dieser Sicht erfolgt die eigentliche Abbildung des Geschäftsprozesses, indem die Beziehungen zwischen den vorher genannten Sichten hergestellt werden. Hierzu können Teile der Sichten modelliert bzw. Sichten integriert werden.[Sch98,vgl.S.36]

Der wohl bekannteste und auch erfolgreichste Diagrammtyp der Prozesssicht ist die (e)EPK[16], die deshalb für weitere Betrachtungen besonders relevant ist. Ein weiterer Vertreter der Prozesssicht ist der Office Prozess, der eine „anschaulichere“ und elementreduziertere Variante der eEPK ist und häufig zur Darstellung von Elementarfunktionen genutzt wird. Gleichfalls in dieser Sicht vertreten sind die häufig angewandten Vorgangs- und Wertschöpfungskettendiagramme sowie die noch zu betrachtenden UML-Diagramme.

Die eben aufgezeigten Sichten werden jeweils noch in drei weitere Konzepte unterteilt, die die Modellierung hinsichtlich der betriebswirtschaftlichen oder informationstechnischen Nähe präzisieren. Scheer führt dabei

- das Fachkonzept – die betriebswirtschaftlich angepasste Darstellung (Semantik),
- das DV-Konzept – die Übertragung der Begriffswelt des Fachkonzepts auf die Datenverarbeitung, wobei von konkreten Implementationsaspekten noch abstrahiert wird und als letztes
- das Implementierungskonzept – die konkrete IT (Hard- und Software) des Unternehmens, ein. [Rum99,S.56]

Rump gibt ein sehr anschauliches Beispiel für die Modellierung der Konzepte in der Datensicht. Hierbei wird das ER-Modell auf der Fachkonzept-, das Relationenmodell auf der DV-Konzept- und die konkrete DDL[17] auf Implementationskonzeptebene modelliert. [Rum99,S.56]

Dieser Abschnitt sollte zeigen, dass ARIS über den methodischen Umfang zur Beschreibung von Anwendungen verfügt, wobei das Beispiel auf die im nächsten Abschnitt folgende Verbindung mit der Prozesssicht einleitend hinweist.

2.2.3 Verbindung von Prozess- und Datensicht

Da die eEPK bzw. der Office Process sehr häufig genutzte Beschreibungsmittel der GPM sind, spielen sie für eine mögliche automatisierte Überführung in die UML eine besondere Rolle. Sie enthalten statische und dynamische Aspekte, die sie für eine Weiterverwendung einer Systembeschreibung besonders interessant machen. Beide repräsentieren zeitlich logische Abfolgen eines Geschäftsprozesses innerhalb der Prozesssicht, ohne eine scharfe Trennung der oben genannten Sichten zu postulieren, was ein Grund zum Erfolg der EPK-Methode in der Praxis sein könnte. [Sch98,S.20]

Die wichtigsten Beschreibungsmittel der EPK sind Funktionen (Aktivitäten), Ereignisse (Aktivitätsergebnisse) und einfache[18] Regeloperatoren, die die Ablauflogik der Geschäftsprozesse beschreiben. In der Geschäftsprozessdarstellung wechseln sich Ereignisse und Funktionen ab, wobei die Verkettung durch Verknüpfungsoperatoren unterbrochen sein kann. Bei einer eEPK handelt es sich um eine Erweiterung durch zusätzliche Beschreibungselemente. Wie in Abbildung 3 auch zu sehen ist, kommen noch Informationsobjekte und Organisationseinheiten zur Repräsentation der benötigten Daten sowie die ausführende Stelle zur Beschreibung einer Aktivität hinzu.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3: (e) EPK-Elemente

Die Repräsentation aller möglichen Sichten, im oben beschriebenen Sinne, wäre somit durchführbar. Aber reicht die eEPK mit möglichen Verfeinerungen/Hinterlegungen der Prozessschritte aus, um eine Anwendung vollständig zu dokumentieren und Prozessmodelle in eine (UML-) Entwicklungsumgebung zu transformieren? Eine Antwort auf diese Frage ist einerseits abhängig von der Güte der Modellierung, die wiederum von der Granularität der Modellelemente abhängt und andererseits von den Transformationsregeln in die Entwicklungsumgebung.

Da die Datensicht bei der Anwendungsentwicklung von besonderer Bedeutung werden oft ERM’s mit den Prozessbeschreibungen in ARIS zusammen erstellt.[Bur99,S.337]

Das Konzept des ERM wurde in den 1970-er Jahren von Chen entwickelt und wird oft, wie das Beispiel des letzten Abschnittes schon zeigte, zur Modellierung von (meist relationalen) Datenbankanwendungen verwendet.[19] Mit dem ERM lassen sich aber auch sehr gut potentielle Klassen und Klassenbeziehungen sowie Kardinalitäten beschreiben, die für eine Überführung zur Beschreibung der statischen UML-Sicht eine hohe Relevanz aufweisen. Eine zusätzliche Integration der Datensich erfolgt an den Funktionselementen innerhalb der eEPK durch Hinterlegung. Ein detailiertes Vorgehensmodell zur Modellierung mit ERM und EPK wird im „ARIS Framework“ zur „modellgestützten Systementwicklung“ beschrieben. Dort werden sogenannte „Business Objects“ in den ERM’s verwendet, die für die betriebswirtschaftlichen Anwendungen die notwendigen Datenelemente und auf ihnen ausführbare Methoden (i.S.v. Operationen) repräsentieren. [Sch01,S.190ff] Ein Ansatz, der ebenfalls ERM‘s mit der Prozessbeschreibung verbindet, jedoch im Rahmen des erwähnten UP, wird im praktischen Teil genau (4.Kapitel) erläutert.

2.2.4 Statik und Dynamik der ARIS Modellierung

Eine wichtige Basis für die weitere Analyse der Konvergenz zwischen den beiden Modellierungswelten, ARIS und UML, ist die Überprüfung vereinender Grundeigenschaften zur konsistenten Beschreibung des zu modellierenden Sachverhaltes.

Ein System bzw. ein Unternehmen kann durch seine Struktur - der statischen Sicht - und sein Verhalten - der dynamischen Sicht – vollständig beschrieben werden. Wenn nach dem ARIS-Konzept modelliert wird, dann repräsentieren Ereignissteuerung und Nachrichten innerhalb des Systems die Dynamik. Hingegen die Funktions-, Organisations-, Daten- und Leistungssicht[20] beschreiben vorwiegend Strukturaspekte. In der Prozesssicht und im speziellen bei der eEPK sind sowohl strukturelle als auch dynamische Verhaltensaspekte berücksichtigbar.[Sch98,S.32ff] [Rum99,S.55ff]

Die Dynamik wird über Kanten (gerichtete Graphen) dargestellt, die die Interaktion zwischen Systemkomponenten, wie z.B. Organisationseinheiten oder Anwendungssystemen, darstellen. Neben der Festlegung des Kontrollflusses (Ablauf eines Prozesses), geben diese Kanten auch noch Auskünfte über Hierarchieeigenschaften (strukturell) und Datenflüsse (Input/Output). Hiermit sind die beiden Grundvoraussetzungen einer Systembeschreibung mit ARIS geklärt und sollen im Anschluss für die UML gezeigt werden. Ein Ansatz zum Vergleich der Beschreibungselemente für einen Übergang der Prozessorientierung zur UML erfolgt an späterer Stelle.

2.3 Modellierung mit UML

Um die in der Einleitung angesprochenen Herausforderungen[21] bei der Entwicklung von Software leichter verwirklichen zu können, bedarf es geeigneter komplexitätsreduzierender, wiederverwendungserleichternde Methoden, die das software engineering unterstützen. In der Softwareentwicklung existieren verschiedene ältere Ansätze (z.B. Strukturierte Analyse), die versuchen die funktionalen Komponenten eines Systems zu erfassen. Diese Methoden wurden in den 1980/90-er Jahren durch objektorientierte Methoden (z.B. OOSE, OMT)[22] ersetzt. Diese verschiedenen Ansätze führten wenig später dann zum heutigen Standardansatz der grafischen Beschreibung von objektorientierten Systemen – der UML. [Sum01,S.60ff]

Derzeit liegt die Beschreibungssprache UML in der Version 1.5 als Standard vor, jedoch wird gerade über die Neuerungen der Nachfolgerversion 2.0 äußerst kontrovers debattiert. Dies liegt an der Aufspaltung der Interessen der OMG in zwei diametrale Richtungen. Eine Gruppierung um IBM und Rational[23] bevorzugt eine weitere tiefergehende Spezifikation der UML, die andere hingegen will keine weiteren Spezifikationen, um größtmögliche Offenhaltung und Verbreitung des UML Standards zu erhalten. Eine wesentliche Neuerung in UML 2.0 soll die Einführung von XUML sein, bei dem Modellierungselemente mit Sprachelementen in Form von Syntax verbunden sind. Die UML bietet nicht nur die Möglichkeit einer Struktur- und Verhaltensbeschreibung eines Systems auf verschiedenen Abstraktionsebenen, sondern ermöglicht über Erweiterungsmechanismen eine problemspezifische Anpassung der Sprachelemente.[Die02,S.165]

2.3.1 Einsatzgebiete der UML

Die UML gibt dem Modellierer eine Sprache in die Hand, mit der wie bei ARIS ein integrierender Ansatz verfolgt wird. Grundsätzlich fokussiert die UML stärker auf die Anwendungsentwicklung, das heißt die UML ist eher technisch auf die Entwicklung und Dokumentation einer Systemanwendung ausgerichtet, als auf die Dokumentation des unternehmerischen Prozesses an sich, obwohl eine solche Modellierung möglich ist. Dies lässt sich nicht zuletzt auch an der Vielzahl technisch orientierter Spezifikationen/Metamodelle (z.B. CORBA) ablesen. Es verwundert deshalb kaum, dass die UML eher von Softwareentwicklern als von Unternehmensberatern eingesetzt wird. Erst in einem zweiten Schritt nach der GPM wird der technische Lösungsbedarf ermittelt und dann erst würde sich die UML als Modellierungswerkzeug für den versierteren Unternehmensberater anbieten. Es müssen zudem auch einige Software-engineering Grundkonzepte, wie zum Beispiel Objektorientierung bekannt sein, um beispielsweise Vererbungskonzepte oder Nachrichten/Dienste zu verstehen. Dies erklärt den theoretischen Nachteil, den die UML bei einem möglichen Modellierungseinsatz in Fachabteilungen eines Unternehmens gegenüber ARIS hat. Man müsste jeden modellierenden Mitarbeiter der Fachabteilung vorher schulen, was hingegen bei der intuitiveren Modellierung mit ARIS unter Verwendung des Easy-Design Filters weniger zwingend wäre.

[...]


[1] lat. : Übereinstimmung / Annäherung

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

[3] z.B. strukturierte Analyse und Design wurden vornehmlich für prozedurale Programmierung eingesetzt

[4] zum unterschiedlichen Objektbegriff vergleiche [SB,S.8ff]

[5] Phasen beschreiben den groben Ablauf des Softwareentwicklungsprozesses.

[6] Views des RUP: use case view, logical view, component view, deployment view

[7] Z.B. Enterprise Java Beans oder CORBA

[8] Roundtrip Engineering umfasst abwechselndes Reverse und Forward Engineering, wobei Forward Engineering die Systemneugestaltung auf Basis abstrakter Spezifikationen ist. Reverse Engineering formuliert Eigenschaften eines vorhandenen Systems auf abstraktem Niveau. [For01,S.128ff]

[9] Sprache ist gekennzeichnet durch Syntax (graphisch/textuell) und Semantik (Definition von Beschreibungselementen und Beziehungen)

[10] Stand : September 1998

[11] Stand : 17.07.2002

[12] In Anhang 1 ist eine Markteinordnung der IDS Scheer abgebildet, deren Aussagehalt nicht ganz zweifelsfrei ist, da sie von einem Marktforschungsunternehmen erstellt wurde, die bekanntlich beauftragt werden können derartige Studien zu veröffentlichen.

[13] Workflows sind GP, die sich aufgrund ihrer formaleren Beschreibung eignen, automatisiert zu werden.[Rum99]

[14] Dies gilt zumindest unter Verwendung des Easy-Design-Filters.

[15] Eine sehr gute und umfassende CASE-Tool Zusammenstellung sowie deren implementierte UML Version kann man unter : www.jeckle.de/umltools.html finden (sowie auf beigefügter CD).

[16] Vgl. [Sch98,S.20] und [Rum,S.61]

[17] Datendefinitionssprache, z.B. SQL

[18] dies gilt zumindest im ARIS-Easy-Design

[19] an dieser Stelle sei aus Platzgründen auf die Literatur zum ERM verwiesen: Chen, P.P-S. : “The entity relationship model“; ACM Transactions on Database System 1(1):9-36, 1976

[20] Die Leistungssicht ist nicht separat als Sicht verfügbar, sondern ist in der Prozesssicht integriert - es gibt aber trotzdem eigene Diagramme dafür (z.B. Leistungsdiagramm)

[21] Vgl. Legacy, heterogeneity, delivery challenge vom Anfang

[22] object oriented software engineering, object modeling techique

[23] Mittlerweile wurde Rational Software von IBM aufgekauft.

Ende der Leseprobe aus 96 Seiten

Details

Titel
Konvergente Geschäftsprozessmodellierung für die Softwareentwicklung mit ARIS und UML
Hochschule
Humboldt-Universität zu Berlin  (Wirtschaftsinformatik)
Note
2,1
Autor
Jahr
2003
Seiten
96
Katalognummer
V22532
ISBN (eBook)
9783638258333
ISBN (Buch)
9783638717434
Dateigröße
1670 KB
Sprache
Deutsch
Schlagworte
Konvergente, Geschäftsprozessmodellierung, Softwareentwicklung, ARIS, UML
Arbeit zitieren
Dipl. Kfm. Jörg Krause (Autor:in), 2003, Konvergente Geschäftsprozessmodellierung für die Softwareentwicklung mit ARIS und UML, München, GRIN Verlag, https://www.grin.com/document/22532

Kommentare

  • Noch keine Kommentare.
Blick ins Buch
Titel: Konvergente Geschäftsprozessmodellierung für die Softwareentwicklung mit ARIS und UML



Ihre Arbeit hochladen

Ihre Hausarbeit / Abschlussarbeit:

- Publikation als eBook und Buch
- Hohes Honorar auf die Verkäufe
- Für Sie komplett kostenlos – mit ISBN
- Es dauert nur 5 Minuten
- Jede Arbeit findet Leser

Kostenlos Autor werden