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

“Es gibt nichts Neues mehr. Alles, was man erfinden kann, ist schon erfunden worden.“

Charles H  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

konvergente Geschäftsprozeßmodellierung für die Softwareentwicklung mit ARIS und UML

  Abbildungsverzeichnis  III

  Tabellenverzeichnis  IV

  Abkürzungsverzeichnis  IV

  Stakeholder und Probleme im Gesamtprozess  3

  Geschäftsprozessmodellierung  4

  Der Softwareentwicklungsprozess  6

  Model Driven Architecture  9

  Schaffung von Konvergenz in der GPM  12

  Geschäftsprozessmodellierung mit ARIS  14

  Einsatzgebiete von ARIS  15

  Sichten und Beschreibungselemente der GPM mit ARIS  17

  Verbindung von Prozess und Datensicht  18

  Statik und Dynamik der ARIS Modellierung  20

  Modellierung mit UML  21

  Einsatzgebiete der UML  21

  Systembeschreibung mit UML  22

  GPM unter Verwendung der UML  23

  ARIS Integration der UML  26

  Integration durch objektorientierte Erweiterung der EPK  29

  Transformationen gemäss MDA  31

  Mapping  33

  Refinement und Konsistenzgestaltung  35

konvergente Geschäftsprozeßmodellierung für die Softwareentwicklung mit ARIS und UML

  Reischmann Toolbus  37

  Phaidros eaSE  38

  Einsatzfelder  41

  Anwendungsentwicklung  42

4.1  Systemvoraussetzungen  42

4.2  Benutzeroberflächen  42

4.3  Datenorganisation und Datenablage  45

4.4  Modellierung  47

  Βeurteilung und Fazit  55

  ARIS ROSE Bridge  58

  Vorgehens und Modellierungskonzept  58

  Modellierungskonzepte und Konventionen  60

4.1  Modellierung mit Filter  60

4.2  Modellierung der Sichten  61

  Überführung und Technik  63

  Beurteilung und Fazit  70

  Anhang  78

  Literaturverzeichnis  86

  Onlinequellen und sonstige  88

  Verwendete Software  89

konvergente Geschäftsprozeßmodellierung für die Softwareentwicklung mit ARIS und UML

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“

konvergente Geschäftsprozeßmodellierung für die Softwareentwicklung mit ARIS und UML

Abbildung 32: übertragener Informationsträger und Verbindungsstruktur

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

Tabelle 2 : getestete ARIS Elemente und Überführungsergebnisse

Architektur integrierter Informationssysteme

Extensible Markup Language

konvergente Geschäftsprozeßmodellierung für die Softwareentwicklung mit ARIS und UML

Executable UML

konvergente Geschäftsprozeßmodellierung für die Softwareentwicklung mit ARIS und UML

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,

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

Seite 1 von 89

konvergente Geschäftsprozeßmodellierung für die Softwareentwicklung mit ARIS und UML

kann es sinnvoll sein, Individualsoftware über einen generativen Ansatz, der das Wissen

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 lat. : Übereinstimmung / Annäherung

Seite 2 von 89

konvergente Geschäftsprozeßmodellierung für die Softwareentwicklung mit ARIS und UML

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 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

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

Seite 3 von 89

konvergente Geschäftsprozeßmodellierung für die Softwareentwicklung mit ARIS und UML

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]

Seite 4 von 89

konvergente Geschäftsprozeßmodellierung für die Softwareentwicklung mit ARIS und UML

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

Seite 5 von 89

konvergente Geschäftsprozeßmodellierung für die Softwareentwicklung mit ARIS und UML

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

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

Seite 6 von 89

konvergente Geschäftsprozeßmodellierung für die Softwareentwicklung mit ARIS und UML

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

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

4 zum unterschiedlichen Objektbegriff vergleiche [SB,S.8ff] 5 Phasen beschreiben den groben Ablauf des Softwareentwicklungsprozesses.

Seite 7 von 89

konvergente Geschäftsprozeßmodellierung für die Softwareentwicklung mit ARIS und UML

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.

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

Seite 8 von 89

konvergente Geschäftsprozeßmodellierung für die Softwareentwicklung mit ARIS und UML

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 2: MDA Metamodell

Quelle : [AB01,S.12]

Seite 9 von 89

konvergente Geschäftsprozeßmodellierung für die Softwareentwicklung mit ARIS und UML

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

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)

Seite 10 von 89

konvergente Geschäftsprozeßmodellierung für die Softwareentwicklung mit ARIS und UML

ü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 (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

Anwendungsbeispiel hierfür ist das rapid prototyping - das schnelle Erstellen eines lauffähigen Systems, das die wesentlichsten Eigenschaften des End-Softwaresystems

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.

Seite 11 von 89

konvergente Geschäftsprozeßmodellierung für die Softwareentwicklung mit ARIS und UML

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-)

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

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.

Seite 12 von 89