Entwicklung eines Metamodells zur grafischen Generierung von Business Rules

Praktikumsbericht

zur

Zwischenpräsentation

Professur für Programmierung verteilter SystemeProf. Dr. Bernard Bauer

Betreut von: Vorgelegt von:

Prof. Dr. Bernhard Bauer Matthias Nicolas DrexlMaximilian KochJohannes Metscher

Dipl. Inf. Florian Lautenbacher Matr.-Nr. 791519Matr.-Nr. 831241Matr.-Nr. 834184

Datum: 15.05.2008

Inhaltsverzeichnis

1 Einführung

1.1 Motivation.........................................................................................................................1

1.2 Definitionen......................................................................................................................1

1.2.1 Business Process........................................................................................................2

1.2.2 Business Rule............................................................................................................2

1.2.3 Metamodell................................................................................................................2

1.3 Beispiel: Online Music Store............................................................................................3

2 Theorie und Modellierung

2.1 Theorie..............................................................................................................................4

2.2 Darstellung durch ECAA-Regeln und EPK.....................................................................6

3 Metamodell

3.1 Metamodell zu Geschäftsprozessen................................................................................10

3.1.1 Abstraktes Metamodell zu Geschäftsprozessen......................................................10

3.1.2 Konkreter Syntax.....................................................................................................12

3.2 Metamodell zu Geschäftsregeln.....................................................................................12

3.2.1 Abstrakter Syntax....................................................................................................12

3.2.2 Konkreter Syntax.....................................................................................................14

3.2.3 Beispiele..................................................................................................................15

4 Anwendung zur Modellierung

4.1 Anforderungen................................................................................................................17

4.1.1 Das Model-View-Controller Paradigma.................................................................17

4.1.2 Usability..................................................................................................................18

4.2 Umgebung.......................................................................................................................18

4.2.1 Prerequisites............................................................................................................18

4.2.2 JRWT-Plugin...........................................................................................................19

Literaturverzeichnis

Einführung 1 von 21

1 EinführungHeutzutage muss ein Kunde dynamisch auf den Markt reagieren können um weiterhin kon-kurrenzfähig zu sein.

1.1 MotivationDer klassische Software-Release-Zyklus von Konzeption, Realisierung, Test mit begleitender Qualitätssicherung und Dokumentation ist nicht mehr zeitgemäß.

Einer IDC-Studie (International Data Corporation; Anbieter in den Bereichen Marktbeobach-tung und Beratung der IT- und Telekommunikationsindustrie) zufolge werden immerhin 9 % der Geschäftsregeln täglich, immerhin weitere 17 % wöchentlich und nochmals 17 % monat-lich geändert. Somit sind es schon ca. 45 % der Regeln, die sich innerhalb eines angenomme-nen Release-Zyklus von mindestens einem Monat, ändern würden.

Klar ist auch, dass die Dokumente und die vom Kunden beschriebenen Logiken umso über-holter sind, je mehr Zeit zwischen Analyse und In-Produktionsnahme vergeht. Somit sind also Release-Zykluslänge und Änderungsmenge essenzielle Gegenspieler von Flexibilität im Un-ternehmen.

Statt eines traditionellen Release-Verfahrens soll ein dynamisches, kontinuierliches Lebenszy-klusmanagement der Geschäftsregeln, verwendet werden. Eben die Modellierung von Busi-ness Rules.

Durch diesen graphischen Ansatz lassen sich Regeln kurzfristig ergänzen und modifizieren. Tägliche Releases bieten kontinuierliche Weiterentwicklung sowie eine Automatisierung von Codegenerierung und Dokumentation. Wir reden in dieser Domäne auch nicht mehr über Pro-grammiersprachen und endlose Word-Dokumente mit Anforderungspapieren, die zu bewerten und dann aufwändig in Source Code zu transformieren sind. Analyse, Prototyping, Modellie-rung, Ausführung und Test gehen fast nahtlos ineinander über.

Dadurch wird der Kunde aufgefordert seine Kreativität und sein Know-How einzubringen und auszuleben, wodurch ihm ein Gefühl vermittelt wird, mit ihm auf einer Wellenlänge zu arbeiten.

Damit wird auch der Wunsch des Kunden nach mehr Kontrolle und gleichzeitig mehr Flexibi-lität erfüllt.

1.2 DefinitionenImmer mehr Unternehmen bezeichnen sich heute als prozessorientiert. Prozessorientierung bedeutet ein konsequentes Denken in Geschäftsprozessen (Business-Processes) und Ge-schäftsregeln (Business-Rules) und damit eine optimale Adressierung der Kundenwünsche.

Einführung 2 von 21

1.2.1 Business ProcessEin Geschäftsprozess ist eine Zusammenfassung von fachlich zusammenhängenden Geschäfts-aktivitäten, die notwendig sind, um einen Geschäftsfall zu bearbeiten. Hier wird zum Beispiel die Kontrolle des Ablaufs der Prozessaktivitäten, Einhalten von Deadlines und Ausnahmebe-handlungen, beschrieben.

Beispiel: Ein Kunde möchte ein Musikalbum in einem Music Online Store kaufen.

Prozesse und Regeln sind zueinander komplementär, denn ein Prozess nutzt typischerweise mehrere Regeln, während eine Regel in verschiedenen Prozessen vorkommen kann.

1.2.2 Business RuleDer Begriff Geschäftsregel legt den genauen Ablauf der Geschäftsprozesse fest und wird als Sammelbegriff für verschiedene Arten von Regeln bezeichnet.

Beispiel: Als Neukunde bekommt man 10% Rabatt auf ein Musikalbum.

Das Thema der Arbeit ist die Modellierung von Business Rules, unter Schaffung eines Meta-modells, deshalb sollte nun der Begriff des Metamodels definiert werden.

1.2.3 MetamodellEin Metamodell ist ein Modell das beschreibt, wie Modelle gebaut werden (Syntax) und zu interpretieren sind (Semantik). Man kann sich zum Beispiel eine leere Karte von Europa als System vorstellen und als Modell dieselbe Karte mit eingezeichneten Klimazonen, die Legen-de zu dieser Karte entspricht hier dem Metamodell.

Beispiel:

● System: Geschäft

● Modell: Business Rules

● Metamodell: Legende des Modells für Business Rules

Im folgendem werden wir uns immer auf das Beispiel eines Online Music Stores als System beziehen. Für dieses System modellieren wir beispielhafte Business Rules und beschreiben anschließend mit unserem Metamodell das Modell - Geschäftsregeln.

Einführung 3 von 21

1.3 Beispiel: Online Music Store

Das Beispiel des Online Music Stores beschreibt eine Internetplattform bei der man sich als Kunde registrieren und anmelden kann, um anschließend online Musik zu erwerben.Der Music Store beinhaltet ein Rabattsystem, bei dem der Kunde belohnt wird, wenn er viel Umsatz erziehlt, oder Freunde geworben werden. Das Rabattsystem wird durch Geschäftsre-geln abgebildet. So erhält der Kunde zum Beispiel 25% Rabatt wenn er mindestens zehn Al-ben auf einmal kauft.

Im folgenden werden die Beispiele exemplarisch anhand des Online Music Stores aufgegrif-fen und modelliert um ein besseres Verständnis über deren Komplexität zu erhalten.

Abbildung 1: Beispiel - Online Music Store

Theorie und Modellierung 4

2 Theorie und Modellierung

2.1 TheorieGrundlagen über Geschäftsregeln

● Präzise Definition geschäftsprozessspezifischer Logik (z.B. Ablauf von Prozessaktivi-täten, Exception Handling - Ausnahmebehandlung, Art und Weise der Abwicklung von Geschäftsprozessen)

● Beschreibung der Entscheidungslogik von prozessübergreifenden Managementpoliti-ken und Prinzipien (Modellierung, Ausführung und Governance der Prozesslogik bei der Entwicklung von Informationssystemen)

● Ein Geschäftsprozess verwendet typischerweise mehrere Geschäftsregeln (1..n). Eine Regel komplementär in mehreren verschiedenen Prozessen vorkommen kann (1..m).

➔ Prozesse und Regeln stehen somit im Verhältnis n:m zueinander

● Kapselung komplexer Regeln in einem gemeinsamen Rule- Service, der wiederum an-dere Rule- Services in seiner Implementierung aufgerufen kann

● Somit werden die Regeln zum Bestandteil einer SOA-Infrastruktur und

● die Entscheidungslogik Teilmenge der Geschäftslogik, die dadurch schließlich mit ab-gebildet werden kann

● Integration des Rule- Services als Eclipse Plugin (Erweiterung des Java Workflow Tooling - JWT)

Regelbasiertes System – Grundlagen

Geschäftsregeln können durch ein sogenanntes regelbasiertes System dargestellt werden. Das regelbasierte System besteht aus folgenden Elementen.

● Faktenbasis -> Datenbank an Fakten (Extraktion von Fakten aus Geschäftsprozess)

● Regelbasis -> Menge an Regeln (Regeldatenbank)

● Business-Rule-Engine -> Kontrollsystem mit Regelinterpreter

Die Business-Rule-Engine (= Kontrollsystem) identifiziert Regeln in einem Geschäftsprozess der Faktenbasis, kann ausgewählte Regeln in einem Geschäftsprozess anwenden, und aktuali-siert die angelegte Regeldatenbank mit neu angelegten Regeln.

Theorie und Modellierung 5

Regelbasiertes System - Formale Darstellung

Ein Regelsystem ist immer durch eine WENN DANN SONST (IF THEN ELSE) Abfrage ge-kennzeichnet, durch die eine bestimmte Regel (= EVENT) zerlegt und dargestellt wird.

Dabei bildet der WENN Teil als Prämisse die Annahme einer bestimmten Voraussetzung für die Konklusion ( = SONST) durch eine bestimmte Aktion. Eine weitere Abzweigung durch weitere Konklusionen ( = SONST) als Alternative anderer Aktionen ist möglich.

Regelbasiertes System - Allgemeine Notation

EVENTWENN (Prämisse/Voraussetzung) ...

DANN (Konklusion durch eine Aktion) ...SONST (Konklusion durch eine anderer Aktion) ...

Beispiel - Komplexeres Rabattsystem für Kundenempfehlung und -werbung des Online Mu-sic Stores (OMS)

Kauf eines Albums:WENN bereits 3 Kunden geworben UND diese bereits ein Album gekauft haben,

DANN 50% auf ein Album,SONST normaler Preis auf eine Album

Ansicht eines Albums:WENN Freunde oder vom Kunden geworbene Benutzer das Album gekauft haben UND das aktuelle Album dem selben Genre angehört,

DANN zeige Empfehlungen (analog z.B. wie bei Amazon)SONST gebe keine Empfehlung aus

Paketpreis - Skonto:WENN Kunde 10 Alben auf einmal kauft UND bezahlt am gleichen Tag bezahlt,

DANN 75 % Rabatt auf EinkaufSONST 0 % Rabatt

Geschäftsregeln im Kontext der Prozessmodellierung

Es gibt’s sowohl eine technische als auch eine betriebswirtschaftliche Sicht auf Geschäftsre-geln, je nachdem in welchem Kontext die Regeln verwendet werden. So können Geschäftsre-geln die Organisationsstruktur von Unternehmen und deren Abläufe beschreiben und deren Geschäftslogik enthalten. Sie sind somit Teil von Geschäftsprozessen und deren effizienter Durchführung. Geschäftsregeln werden hier auch als organisatorische Regeln bezeichnet.

Kerneigenschaften und Modellierungselemente zur Modellierung von Geschäftsregelsyste-men

● Geschäftsregeln müssen die Geschäftslogik enthalten, eindeutig und präzise formuliert sein

Theorie und Modellierung 6

● Eine erste Formulierung der Geschäftsregeln findet in einer natürlicher Sprache statt. Eine direkte Übersetzung dieser Sprache ist nicht notwendig, eine Formalisierung der Geschäftsregeln muss entsprechend der ECAA durchgeführt werden

● Eine einzelne Regel enthält auf der untersten Modellierungsebene als atomare Regel keine weiteren Regeln

● Globale oder allgemeine Regeln können wiederum weitere Regeln beinhalten

● Die Ab-/Herleitung einer Regel aus anderen Regeln ist möglich muss aber eindeutig nachvollziehbar sein

● Regeln müssen einheitlich strukturiert und formuliert sein, damit deren Komplexität sofort zu erkennen ist und gegebenenfalls reduziert werden kann

2.2 Darstellung durch ECAA-Regeln und EPKDie ECAA-Regeln zur Modellierung von Geschäftsregeln wurde im regelbasierten Modellie-rungsansatz aufgegriffen und erweitert, und stellt die Grundlage für eine strukturierte Model-lierung von Geschäftsregeln und -prozessen dar. Die explizite Modellierung einer Bedin-gungskomponente ermöglicht eine praxisnahe Modellierung von Geschäftsregeln, als es bei-spielsweise mit Ereignisorientierten Prozessketten (EPK) möglich ist und bietet zusätzliche Möglichkeiten für eine Modellierung der Ablaufsteuerung.

Der Grundaufbau der ECAA-Regel ist in Abbildung 2 dargestellt.

Einfache Beispiele hierfür werden in Abbildung 3 und 4 dargestellt.

Abbildung 2: Grundaufbau einer ECAA

Abbildung 3: ECAA für 50% Rabatt

ON Kunde erteilt Auftrag

IF

# geworbener Kunden >= 3 and # Einkauf.Album.geworbener Kunden >= 1

DO 50% auf Album

Else 0% auf Album

Abbildung 4: ECAA für 25% Rabatt

ON Kunde erteilt Auftrag

IF # gekaufterArtikel.Album >= 10

DO 25% auf Preis

Else 0% auf Preis

Theorie und Modellierung 7

Ein weiteres komplexeres Beispiel für einen regelbasierten modellierten Prozess wird in Ab-bildung 5 dargestellt. Die abstrakte Betrachtung des Beispiels aus Abbildung 5 wird in Abbil-dung 6 projiziert.

Abbildung 5: Komlexes regelbasiertes Rabatsystem

Abbildung 6: Abstrakte Darstellung einer ECAA

Theorie und Modellierung 8

Eine Geschäftsregel die mithilfe der ECAA-Regel modelliert wurde und die Überführung in ihre entsprechende EPK (Ereignisgesteurte Prozesskette) ist in Abbildung 7 dargestellt.

Abbildung 7: Überführung einer ECAA in ihre entsprechende EPK

Kunde erfassenElse

Kunde ist bekanntDO

Kunde bekanntIF

Kunde erteilt AuftragON

Auftrag erfassenDO

Kunde ist bekannt xor Kunde ist erfasst

ON

Kunde erteilt Auftrag

Kundenbeziehung prüfen

xor

Kunde ist unbekannt

Kunde unbekannt

Auftrag erfassen

xor

Auftrag ist erfasst

Kunde erfassen

Kunde ist erfasst

Metamodell 9

3 MetamodellDie theoretischen Grundlagen der Modellgetriebenen Softwareentwicklung, wie bereits in der Einführung (Kapitel 1) beschrieben, bauen maßgeblich auf die Modellierung eines umfassen-den Metamodells auf. Dies bietet die nötige Abstraktion, um einerseits domänenspezifisches Fachwissen unabhängig von der Implementierung abzubilden und andererseits, wenn möglich und nötig Programmcode automatisiert mit Hilfe des Metamodells zu generieren.

Für die Abbildung von Geschäftsprozessen wurde bereits im Rahmen des Projektes AgilPro ein solches Metamodell angefertigt und dessen abstrakten und konkreten Syntax detailliert be-schrieben. Dieses Metamodell dient gleichermaßen als Referenz und Basis für das Metamo-dell zu Geschäftsregeln. Aus diesem Grund soll hier in kürze auf die wichtigsten Bereiche eingegangen werden.

3.1 Metamodell zu GeschäftsprozessenDie Modellierung des Metamodells orientiert sich bereits syntaktisch und semantisch an der Umsetzung des Eclipse Plugins JWT bzw. AgilPro. Somit sind bereits Elemente zur grafi-schen und logischen Umsetzung des Modells enthalten.

3.1.1 Abstraktes Metamodell zu GeschäftsprozessenUm einen besseren Überblick über das bestehende Metamodell zu erhalten werden im folgen-den signifikante Aussschnitte des Metamodells von JWT bzw AgilPro behandelt.

Abbildung 8: AgilPro – Prozesse [BFS07]

Metamodell 10

Die Geschäftsprozesse können abstrakt als Aktivitäten (Activities) modelliert werden. Diese Aktivitäten lassen sich zudem in Eclipse JWT darstellen und in Paketen (Packages) strukturie-ren. Der Scope enthält dabei alle Elemente eines grafischen Modells, wie z.B. Aktivitätskno-ten (ActivityNodes) und Aktivitätskanten (ActivityEdges). Eine Aktion ist ein ausführbarer Knoten (ExecutableNodes), eine Speziallisierung des Aktivitätsknoten. Er wird mit einem Namen versehen und gegenebenfalls mit einem Symbol gekennzeichnet.

Es ist zudem möglich die Inhalte (Aktivitätsknoten und -kanten) eines Scopes selbst wieder-um in einem speziallisierten Aktivitätsknoten zusammenzufassen, dem strukturierten Aktivi-tätsknoten (StructuredActivityNode).

Die Kanten (ActivityEdges) des Graphen lassen sich über die Klasse Guard mit Bedinungen versehen. Diese können sich aus belieb vielen, über boolsche Operatoren (BooleanConnec-tors) verbundene Unterbedingungen (GuardSpecification) zusammensetzen, die aus einer tex-tuellen Beschreibung der Bedingung abgeleitet werden.

Neben den ausführbaren Knoten gibt es auch noch Steuerungsknoten (ControlNode). Für die Modellierung, von Anfang und Ende eines Prozesses wird der Anfangsknoten (InitialNode) und Endknoten (FinalNode), verwendet. Für die Modellierung von parallelen Prozessen und deren spätere Synchronisation verwendet man den Verzweigungsknoten (ForkNode) bzw. den Vereinigungsknoten (JoinNode). Außerdem stehen noch die Knoten für exklusive Entschei-dungen (DecisionNode) und Verschmelzung (MergeNode) zur Verfügung.

Abbildung 9: AgilPro - Steuerungsknoten[BFS07]

Abbildung 10: AgilPro - Organisation[BFS07]

Metamodell 11

Jede Aktion (Action) wird entweder automatisch oder von einer bestimmten Rolle (Role), ei-ner Organisation, ausgeführt. Rollen werden nicht für ein Prozessmodell definiert sondern für jeden Prozess und sind somit referenzierbare Elemente (ReferencableElement). Rollen kön-nen Organisationseinheiten (OrganisationUnit) zugeteilt werden, die wiederum Untereinhei-ten bilden können.

3.1.2 Konkreter Syntax

Aktionen werden durch abgerundete Rechtecke repräsentiert, die durch eine Aktivitätskante (ActivityEdge) miteinander verbunden sind. Der Anfangsknoten (InitialNode) wird durch einen normalen Kreis symbolisiert, im Gegensatz zum Endknoten (FinalNode) der einen aus-gefüllten kleinen Kreis in einem normalen Kreis enthält.

3.2 Metamodell zu GeschäftsregelnAufbauend auf das Metamodell zu den Geschäftsprozessen und damit für JWT wurde das Modell zur Abbildung der Geschäftsregeln entwickelt. Diese sollen sich dabei gut in die be-stehende Geschäftsprozesse einbetten lassen und trotzdem auch unabhängig modellierbar sein.

3.2.1 Abstrakter SyntaxDie bestehenden Möglichkeiten in JWT bedingte Kantenübergänge zu modellieren, beschrän-ken sich auf den Einsatz des Guards (siehe 3.1.1). Dieses Konzept erfüllt jedoch nicht die An-forderung der Komplimentarität von Geschäftsprozessen und -regeln (siehe 1.1 und 2.1) und damit die n:m Beziehung zwischen den Konzepten. Aus diesem Grund wurde das bestehende Modell (JWT) entsprechend um neue Knoten erweitert.

Die neue Klasse bedingter Entscheidungsknoten (ConditionalDecisionNode, siehe Abbildung 12) ist eine Speziallisierung des Enscheidungsknoten (DecisionNode) und des Aktivitätsver-weisknoten (AcitivyLinkNode). Im Gegensatz zur Klasse Entscheidungsknoten, der selbst keine Bedingungen enthalten kann, sondern diese nur über die Kanten (Guards) abgebildet werden können, erlaubt der bedingte Entscheidungsknoten mit Hilfe eines Regelmodellie-rungsgraphen (RuleModellingGraph, siehe Abbildung 13) das Erstellen übersichtlicher und umfassenderen Bedinungen. Auf diesen Regelmodellierungsgraphen wird über die geerbte Klasse Aktivitäsverweisknoten referenziert.

Abbildung 11: Aktionen, Kanten, Anfangs- und Endknoten[BFS07]

Metamodell 12

Die ebenfalls neu eingeführten Klassen Regelgraphanfangsknoten (RuleGraphInitialNode) und Regelgraphendknoten (RuleGraphFinalNode) ermöglichen semantisch und graphtheore-tisch korrekte Einbindung des Regelmodelierungsgraphen (RMG). Sie ermöglichen damit die Verbindung von Bedingungen (Condition) innerhalb des RMG und Aktivitätsknoten, wie z.B. Aktionen (Action) oder Ereignissen (Event), außerhalb.

Der Regelmodelierungsgraphen besteht aus einem spezialisierten Anfangknoten (RuleGra-phInitalNode) und Endknoten (RuleGraphFinalNode). Zudem enthält er mindestens eine Be-dingungen (Condition).

Abbildung 12: Neuer Knotenklassen: ConditionalDecisionNode, RuleGraphInitialNode und RuleGraphFinalNode

Abbildung 13: Klassenmodell RuleModelingGraph

Metamodell 13

Die Bedingung (Condition) ist eine Spezialisierung von der Klasse Referenz und erlaubt da-mit den Verweis auf andere referenzierbare Klassen (ReferenceableElement), wie Rolle (Role) und Anwendung (Application). Über Bedingungen ist es somit möglich auf bestimmte Attribute der referenzierte Objekte zu verweisen und mit Hilfe von logischen Operatoren mit SOLL-Werten (Value) zu überprüfen.

3.2.2 Konkreter SyntaxUm die Business Rules zu modellieren wird der bedingte Entscheidungsknoten (Conditional-DecisionNode) verwendet, der durch ein Sechseck beschrieben wird.

Abbildung 14: Klassenmodell Bedingungen

Zeichnung 1: Bedingter Ent-scheidungsknoten

ConditionalDecisionNode

Metamodell 14

Die drei neuen Bedingungsklassen für Rolle (RoleCondition), Anwendung (ApplicationCon-dition) und Daten (DataConditon) referenzieren jeweils auf die namenszugehörigen Objekte und werden durch spezifische Sechsecke dargestellt.

Der Anfangsknoten (RuleGrapInitalNode) beschreibt den Beginn einer Geschäftsregel und wird durch einen normalen Kreis mit dickem Rand symbolisiert, im Gegensatz zum Endkno-ten, der aus zwei normalen Kreisen besteht die ineinander verschachtelt sind, und das Ende ei-ner Geschäftsregel beschreibt.

3.2.3 BeispieleZu besseren Veranschaulichung der neu eingeführten Notationen und des konkreten Syntax folgen zwei beispielhafte Modellierungen.

An dem Ereignis (Event) „Erwerb eines Albums“ ist ein Kunde und der Webshop beteiligt. Dieses Ereignis wiederum ist mit der Geschäftsregel „Paketbonus“ verbunden. Diese ent-scheid darüber wieviel Prozent des Albumpreises wirklich vom Kunden bezahlt werden muss.

Abbildung 16: Beispiel eines Geschäftsprozesses mit integrierter Geschäftregel

Abbildung 15: Neue Klassen um auf Ereignisattribute zu Referen-zieren

Metamodell 15

Dies wird in den entsprechenden Aktionen „Albumverkauf 100%“ und „Albumverkauf 75%“ abgebildet.

Die Bedinungen werden in lassen sich beliebig in dem RMG mit Hilfe von Kanten und Steue-rungsknoten verbinden. Hier wird über die Rollenbedingung (RoleCondition) das Alter eines Benutzers überprüft und falls er bereits volljährig ist noch weitere Attribute des Webshops über die Anwendungsbedingungen (ApplicationCondition).

Abbildung 17: Beispiel einer modellierten Geschäftsregel

Anwendung zur Modellierung 16

4 Anwendung zur Modellierung

4.1 AnforderungenDieses Kapitel beschreibt grundlegende technische Konzepte und Anforderungen, welche für die Implementierung des Metamodells maßgeblich relevant sind.

4.1.1 Das Model-View-Controller ParadigmaDas Metamodell für die Modellierung von Businessrules soll nach dem Model-View-Control-ler Konzept implementiert werden. Abbildung 8 zeigt die genauen Zusammenhänge des Kon-zepts. Die Architektur strukturiert den Programmentwurf in die drei Einheiten Model, View und Controller, die folgende Aufgaben erfüllen.

Controller

● Der Controller dient der direkten Verbindung zwischen der Model und der View Schicht

● Es werden Benutzerinteraktionen aus der View entgegengenommen, ausgewertet und anschließend eine entsprechendes Interaktion an das Model weitergereicht

● Eine direkte Datenmanipulation durch den Controller auf dem Model findet nicht statt

● Im Graphical Editing Framework (GEF) ist der Controller als Unterklasse von Edit-Part implementiert

● Für jeden EditPart existiert immer genau ein Model und eine View

Abbildung 18: Das Model-View-Controller Konzept

Anwendung zur Modellierung 17

Model

● Das Model speichert alle darzustellende Daten und und die Geschäftslogik des Meta-modells in einem sogennanten Model Container

● Eine Änderungen der gespeicherten Daten wird durch Listener realisiert

● Model kennt keine anderen Teile des Programms

● Für die Kommunikation mit der View ist der passende Controller zuständig

View

● Die View repräsentiert die Daten aus dem Modell und stellt diese auch dar

● Sie selbst enthält keine Daten oder Teile des Models und ist somit auch nicht für deren Weiterverarbeitung zuständig. Falls sich Daten im Model ändern, wird die View dar-über informiert und anschließend aktualisiert

● Darüber hinaus werden durch die View auch Benutzerinteraktion entgegen genom-men, und entsprechend weitergeleitet

● View kennt keine anderen Teile des Programms

● Für die Kommunikation mit dem Model ist der passende Controller zuständig

4.1.2 UsabilityDie Implementierung soll in Anlehnung an die Human User Interface Design Guidelines durchgeführt werden, um eine möglichst intuitive Bedienung des neu entwickelten Plugins zu gewährleisten. Hierbei soll die Modellierung von Geschäftsregeln vor allem für Domänenex-perten einfach zu bewältigen sein um die Einarbeitungszeit und Umgewöhnung von bekann-ten Modellen so gering wie möglich zu halten. Bewährte Konzepte und Notationen wie bei-spielsweise das der EPK oder UML werden übernommen und entsprechend implementiert.

4.2 Umgebung

4.2.1 PrerequisitesDas oben vorgestellte Metamodell wird für Eclipse als IDE für integrierte Java Entwicklung für jedes beliebiges OS (Mac OS X, Windows, Linux) implementiert. Java Vers. 6.0 als IRE muss zur Ausführung des Plugins bereits installiert sein.

Darüber hinaus werden folgende Frameworks zur Ausführung benötigt, um Geschäftsregel Modelle erstellen zu können:

● Eclipse Modelling Framework (EMF - Daten-/Metamodell)

Anwendung zur Modellierung 18

● Graphical Editing Framework (GEF - Editor für die Daten Visualisierung)

● Java Workflow Tooling (JWT - Modellierung von detaillierten Geschäftsprozessen ohne Geschäftsregeln)

Eine Installationsanleitung ist auf den jeweiligen Projektseiten zu finden.

4.2.2 JRWT-PluginWie oben schon kurz angesprochen, soll das JWT-Plugin um die Funktionalität der Ge-schäftsregel Modellierung erweitert werden, damit es nahtlos in Eclipse für jedes beliebige Betriebssystem integriert werden kann. Das JWT basiert auf dem Modeling Editor von Agil-Pro und dient momentan als Referenz für die modellbasierte Softwareentwicklung.

Alle Erweiterungen des Metamodells werden somit in dem Eclipse Plugin JRWT (Java Rule Workflow Tooling) implementiert. Dadurch ist es möglich Geschäftsregeln in konkrete Ge-schäftsprozesse zu integrieren, oder Regeln auch unabhängig von Prozessen zu

modellieren.

Anwendung zur Modellierung 19

Literaturverzeichnis

[BFS07] Bernhard Bauer, Florian Lautenbacher Stephan Roser, 2007, AgilPro Metamo-del description; 14.02.2007 Version 1.5

Weitere Quellen werden in der finalen Ausarbeitung ergänzt.